Data Object CRUD operations Middleware
Overview
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.
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
- Open Visual Studio Project and create a new project with output type "Class Library".
In the example, we name it Imagoverum.CUSTBizLogic. - Add a reference to "<AppFolder>/svc/bin/Matrix42.Persistence.dll".
- Add a new class to the Project. E.g. CUSTIncidentBehavior
- 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.
- Add a new class to the Project which implements an interface Matrix42.Hosting.Contracts.IDependencyRegistrator and inherits the DependencyRegistratorBase class.
- 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>(); entityBehaviorProvider.Register<IncidentRecord>( 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>')
Example:
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.
- 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.
- Compile the Project
- Deploy the project assembly (e.g. Imagoverum.CUSTBizLogic.dll) and the Config file (e.g. Imagoverum.CUSTBizLogic.dll.config) to ESM 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.