Processing Rules for Service Bus Integration
Processing Rules
Processing rules allow to limit the processing of messages which do not have dedicated handlers and therefor are processed by the generic message handling. Limiting the scope can be useful to increase performance or prevent overwriting data from distinct sources.
By not updating the many multi fragments in a message like hard disks, network cards or processors the processing time and load can be significantly reduced.
Basic function:
- Each processing rule defines the data which is considered for a given configuration item (CI). This works as a white list. Not provided data definitions and properties will be ignored.
- Several rules can be configured per CI and platform combination but only one can be enabled at a time.
- Each rule apples for a platform (i.e. Empirum, Silverback)
- If no processing rule exists for a CI the generic processing will be used.
General processing order
Each message is processed in the following order by the first match:
- Custom handler if defined
- Processing rule if defined
- Generic processing
Defining Processing Rules
Processing rules are managed in Administration -> Integration -> Enterprise Service Bus -> Processing Rules.
Each rule has the following properties:
- Configuration Item (CI): is used for rules which process objects in message.
- Name: a user defined name.
- Platform Identifier: Limits the rule to the provided platform. Examples are Empirum, Silverback, EgoSecure, WebRC (Remote Assistance).
- Description: additional info about matching rule.
- Filtering Rule: List of filters for the message type.
- Data Definition: is used for rules to process multi fragments in message
- Properties: list of processed objects. All not listed objects are ignored.
- Predefined: Matrix42 provides some processing rules which address some standard use cases. All are disabled by default and can be enabled on demand.
To create a new processing rule select the action "Add Processing Rule":
- Select the desired Configuration Item. As an example for the message which usually creates computer select SPSComputerType. Based on the selected CI filter rules are added based on the matching criteria.
- Enter a name
- Enter the platform identifier. As an example for messages from Empirum type Empirum. See the "Nodes" for the currently connected platforms.
- Choose if the processing rule should be enabled after saving. Only one rule per CI/platform identifier combination can be enabled at a time.
- Enter a description.
- Edit the filter rules. See dedicated section for details.
- Save & Close
Enable the processing rule by selecting the list entry and click on the action "Enable". Only one rule can be enabled per platform.
Predefined Processing Rules
Extensions can provide pre-defined processing rules for convenience which cover standard scenarios.
The UEM Extension 24.0.1 or newer provides rules for Empirum and Silverback which can be enabled to reduce the processing effort for devices as the data is usually transferred via a data provider one a day anyway.
As with all processing rules only one can be enabled per platform at a time.
Filter rules
Each filter rule describes the attributes which are processed if exists in the message of the configured CI. This works as a white list. Not provided data definitions and properties will be ignored.
Each rule has the following properties:
- Data Definition Name: The name of the data definition from the list of all which have a relation to the CI.
- Properties: One or more properties of the selected data definition. All listed properties will be considered when processing the messages.
Examples of Filter Rules
Use Case for Message CI |
Data Definition |
Example of property |
Base computer information: SPSComputerType |
SPSComputerClassBase |
LastScanDate, NT4DomainName, Name, PrimaryMACAddress, SystemSerialNumber, WindowsDomainName |
Match computer with relation to domain: SPSComputerClassAD |
SPSComputerClassAD |
Any property. I.e. NBName |