Rule Engine (Patch Level Engine)¶
This page describes about the Rule Engine which is an extension of the Synchronization framework established to support the data synchronization between satellites with different patch levels. Rule engine is necessary since some of the offshore sites will take time to upgrade to the latest patch level.
RuleEngine Process Flow¶
Rule Engine works around set of predefined rules called Synchronization Rules. First the Synchronization Rules are created in the hub based on the patch that is to be applied. Once the rules are created, the rules will be synchronized with the other satellites that are registered for data synchronization. Since then, the rules will act as a filter to the data inflow and manipulate the data line to match the rule of the satellite avoiding any complications.
When the offshore satellite is patched with the latest patch a script is deployed which is obtained from exporting the Synchronization Rules in the Hub. When the script is deployed it will automatically deactivate the rules if the same exist in the patched satellite. Then the modification is sent to the Hub via Application Messages informing that the specific satellite is now in same patch level. Then theHub will deactivate their relevant synchronization rules based on the received Application Messages. Since the ruleset is deactivated after the synchronization, If any modification is needed to the rules, send it through a new ruleset.
Synchronization Rules are the core elements of the Rule Engine. Synchronization Rules are decided and implemented at Hub based on the patch level changes that it is going to apply. For example, A synchronization Rule to skip the messages based on a newly added LU to the hub installation but still not patched in the sat installation sites.
Synchronization Rules are of two types based on the operations that they are bound to perform. They are;
- Rules to perform Logical Unit Operations
- Rules to perform Attribute Operations
Rules which perform Logical unit operations are responsible for the situations like addition of a new Logical Unit in an installation or the removal. Rules that performs attribute operations are responsible for the situations like addition of new attribute, removal of an attribute or the rename of an attribute of an existing Logical Unit.
Logical Unit operations are "Skip Message" operation and "Custom Method" operation. Skip Message operation is used when it is necessary for the receiving end to completely neglect data from specific a Logical Unit. Custom Method operation will allow the customer to call the custom method instead of the default NewModify method.
Attribute Operations are "Modify", "Add" and "Remove". Modify operation is responsible for changing an attribute to suit the receiving site. Add operations adds new attribute and a value which does not exist in the sending site. Remove operation removes an attribute and its value from the receiver.
The required parameters are decided by the rule configuration definition in the Synchronization Basic Data.
Creating a new Synchronization Rule¶
A new Synchronization Rule can be created by clicking new or duplicating an existing rule. The Rule properties should based on the Synchronization Basic Data, relevant to the specific operation. Some properties are mandatory, some properties are optional and some properties are not required when creating Synchronization Rules with certain operations.
Note: Synchronization Rules are always created considering the receiving side of the data synchronization. No Synchronization Rule is applied at the sender.
Enabling and Disabling Synchronization Rules¶
Synchronization Rules can be enabled when it is created at that point itself using the active option button. Once a Synchronization Rule is created it will be synchronized to all the satellites. It is possible to enable or disable a synchronized rule for a single location from the active field in the Rule Location.
Note: Once a rule is synchronized it cannot be enabled using the application neither from the Synchronization Rules nor from Rule Location.
If there is an instance where several Synchronization Rules are used as once it is possible to create them in a single Group with the same Group ID. This makes it easier to export and apply once the patch is deployed.
Exporting Synchronization Rules¶
Synchronization Rules can be exported either as a single rule or as a rule group. This will result in an INS file which can be deployed in the patching site.
Rule Location describes each rule and the sites which it is used. When a Synchronization Rule is created, Rule Location entries are created automatically by the system. Created by system comment is automatically applied when the system creates the entries for every Satellite site registered with the system. It is possible to deactivate the rule for a single satellite using the Active option button. When a patch is applied, an exported Synchronization Rule script is applied with it. Refer Rule Engine Process Flow for more details. Once the script is applied, if the Synchronization Rule is available in the site then it will be automatically disabled by the script. Modified by Script comment is added and the Synchronized Date is updated automatically once that happened.
Note: It is possible to create Rule Locations from the Rule locations form itself if its not auto generated by the system.
Rule usage shows the instances where the specific Synchronization Rule is used in the data replication. Rule Usage entries are made automatically once each rule is associated with an Application Message. Each rule usage shows the relevant Application Message ID and the Application message can be viewed through Application Message Viewer.
Synchronization Basic Data¶
Synchronization Basic Data or the Rule Configuration defines the Logical Unit operations and Attributes operations. Each operation is defined elements which are mandatory, optional and not required. These definitions are checked against the rules that are created and violation will cause an error.
Note: Rule Configurations are provided to the customer by a script and it is unable to create new rule configurations in the application. These Rule Configurations will cover the most of the general situations.