Skip to main content
Matrix42 Self-Service Help Center

Data Object CRUD operations Middleware


The Solution Builder for each Configuration Item declared in the Schema allows designing Dialogs, which in runtime are used for creating, reading and updating different objects. Layout Designer provides a mechanism to author different logic, which affects the related Object. But this approach is very easy, and flexible, but has one downside, it is executed on the client (Browser), which means, the logic can be compromised. For example, some control input validation can be omitted.
There are many cases when the logic needs to be executed on the Business Layer (Server) on modifying the Object, regardless of which process caused the change. As an example, Solution Builder offers to ways of the generic data update, 1) over the UUX Dialogs; or 2) Generic Data Service Public API. To customize each concrete Configuration Item CRUD operations the Solution Builder offers the concept of the Configuration Items Behaviors.


The Solution Builder implements a concept of the Configuration Item Behavior, a special .NET classes, which are registers in the Solution Builder Middleware, and associated with the concrete Configuration Item. The concept provides a possibility to intrude to the standard mechanism of the  Configuration Items CRUD operations, and implement business logic. The System supports the definition of multiple Behaviours for a single Configuration Item, which gives additional possibilities for customization of the default Business Logic by registering custom Behavior, which adjusts the modified Object after the default (Product)  Behaviors are executed. 


 When the Object is modified in Solution Builder, the System finds the registered Behaviors and executes the corresponding injection point (method) with operation context object.

Implement Configuration Item Behavior

The following instructions define the steps that need to be undertaken to implement and register a custom Behavior for a Configuration item. And as an example implements custom behavior for the "Incident" CI which adds a journal record on any Incident update.

Step 1: Implement .NET class

  1. Open Visual Studio Project and create a new project with output type "Class Library".
    In the example, we name it Imagoverum.CUSTBizLogic. 
  2. Add a reference to "<AppFolder>/svc/bin/Matrix42.Persistence.dll". 
  3.  Add a new class to the Project. E.g. CUSTIncidentBehavior
  4. Inherit the new class from the Matrix42.Persistence.GenericEntityBehavior<TRecord>
public class CUSTIncidentBehavior<T> : GenericEntityBehavior<T>  where T : IncidentRecord

For more details please find "CUSTIncidentBehavior.cs" in the article attachment

Step 2: Register Behavior in Dependency Injection (Unity) repository

The Product provides two alternatives to register the Behaviour for the Configuration Item.

In Code Registration

The implemented .NET class has to be associated with the concrete Configuration Item. 

  1. Add a new class to the Project which implements an interface Matrix42.Hosting.Contracts.IDependencyRegistrator and inherits the DependencyRegistratorBase class.
  2. Set the dependency between the Configuration Item and the implemented Behavior in the method Register 

Your Project can have only one implementation of the IDependencyRegistrator  interface. In method Register, you can configure as many Behaviours as you like.

namespace Imagoverum.CustBizLogic
    public sealed class CUSTDependencyRegistrator : DependencyRegistratorBase, IDependencyRegistrator
        public CUSTDependencyRegistrator()
        public void Register(IDependencyContainer container, IDependencyResolver resolver)
           var entityBehaviorProvider = resolver.Get<IEntityBehaviorProvider>();
               new CUSTIncidentBehavior<IncidentRecord>(resolver), "SPSActivityTypeIncident");

Declarative Registration

In contrary to "In-code registration" the declarative approach does not require creating and compiling new code changes, and it is enough the just add a new record to the corresponding Configuration Item Metadata in the Production database. 

INSERT INTO [Schema-MetaInfo] (Name, BelongsToType, Value)
VALUES('BehaviorType', '<CI_ID>', '<BehaviorTypeQualifiedName>')


Setup behavior for custom Data Provider Configuration

Some custom "Data Provider Configuration" requires setting a Password (SPSGenericConnectorConfigurationClassBase.Password), which needs to be properly encrypted. This logic is implemented in base Behavior for Data Provider Configuration.

INSERT INTO [Schema-MetaInfo] (Name, BelongsToType, Value, IsSchemaObject, Description)
VALUES('BehaviorType', '<Custom_Data_Provider_Configuration_CI_ID>', 
     'Matrix42.Connectors.BizLogic.EntityBehaviors.GenericConnectorConfigurationEntityBehavior, Matrix42.Connectors.BizLogic',
      0, '<Empty string or some description here>')

To make the change effective the "iisreset" is required.

Step 3: Register the custom assembly 

The assembly which keeps the class with the Behaviors registration (implementation of the IDependencyRegistrator interface) has to be properly registered in Solution Builder to be correctly initialized on the Application start and then all declared Behaviors automatically applied on appropriate Configuration Item modification.

  1. Add configuration file to the Project 
    - If the Project does not has the configuration file, add a new item to the Project "Application Configuration File" . The Visual Studio adds a new file "app.config" to the Project
    - To the section <appSettigns> add a new node: 
            <add key="module-list:include-module" value="true"/>
    - In case the Business Components registered in the DLL  over the "Dependency Registrator" requires other Business Components from other assemblies being registered in the dependency container first, it is possible to set this relation with the setting module-list:dependencies with comma-separated assemblies list, which need to be registered prior to the current assembly.
  2. Compile the Project
  3. Deploy the project assembly (e.g.  Imagoverum.CUSTBizLogic.dll) and the Config file (e.g. Imagoverum.CUSTBizLogic.dll.config) to SASM application folder "svc/bin".
    Attention: Coping DLL to svc/bin folder automatically recycle the "m42srv" application pool, which causes the application a few seconds downtime.

If for some reason there are no sources, and you have only the assembly, you can manually compose and deploy the configuration file. The only you need just to download the example "Imagoverum.CUSTBizLogic.dll.config",  rename it <yourAssemblyName>.config and deploy it to svc/bin folder.

The alternative way to register an assembly in the Dependency Container is by listing it in the svc/host.config file. But the approach is highly not recommended, as far as each product update overwrites the host.config file, the file needs to be adjusted every time after the update. 


  • Was this article helpful?