Time correlation
The purpose of time correlation is to remove duplicate events. For example, if multiple updates to the same record are made within a short period of time, you might not want to generate a separate message for every update because those messages would be duplicates or near-duplicates.
Time correlation is used for most standard outbound Sync BODs triggered by M3 database events.
The time correlation rule subscribes to data events published by Event Analytics, with the document name TimeCorrelation and the operation Request. Only events published by Event Analytics rules can trigger time correlation.
Time correlation requires a data correlation ID to group events. When multiple data events
having the same data correlation ID are received, only the data for the last of these events
is used when a new event is published for this data correlation ID after the timeout. The data
correlation ID is set by the virtual field dataEventId, which should contain what the data correlation ID represents, and
the whole or part of the primary key. As an example, the dataEventId specified by standard BOD
rules for the noun ItemMaster is 'ItemMaster_' + CONO + '_' + ITNO where
'ItemMaster' is what the correlation ID represents, and the fields
CONO and ITNO make up the primary key. Multiple rules can
use the same time correlation and share the same value for the virtual field dataEventId. For example, the standard BOD session
M3BODs_ItemMaster contains 31 rules using this dataEventId.
The virtual field correlatedEventName is used to define what document name the events published by the time correlation rule have. For BODs, you should set this virtual field to 'M3BEBOD’ because the time correlated events are received by the M3 BOD Processor.
The virtual field correlatedEventOperation is used to define what operation the events published by the time correlation rule have.
By default, a fixed two-minute time window is used in the time correlation rule. Every two minutes, one event is published per dataEventId value for events received during the time window. Data for the last received event per dataEventId is used. Then, all stored data is deleted and the process is repeated.
To explain this process, this diagram shows a horizontal timeline formatted from left to right, showing events in chronological order:
Blue arrows represent received events that have the same dataEventId and purple arrows represent published events. The smaller red arrows indicate which received event data is used for the published events.
If you need a shorter delay between the received events and the published events, you can set a guaranteed waiting time for time correlation by using the virtual field correlatedWindowTime. When this virtual field is used by at least one rule in Event Analytics, the time correlation logic changes to use 20 seconds time window. You set a guaranteed waiting time in seconds for the first received event per dataEventId. The minimum value is 20 seconds and the maximum value is 120 seconds. A new event is published after the guaranteed waiting time when the current 20 second time window ends. Data for the last received event having the same dataEventId is then used. Then, all data for this dataEventId is deleted, and the process is repeated.
When correlatedWindowTime is set to 120 seconds, or if this virtual field is missing but another rule is using it, time correlation works in a slightly different way compared to when guaranteed waiting time is not used.
To explain this process, this diagram shows the same received events as for the previous diagram:
A gray line is added under the timeline to show the guaranteed wait time from the first event received.
Events are now published at different times compared to when the standard two-minutes time window is used. When you need to remove duplicate events with a shorter delay, for example for time-critical messages, you can use a shorter guaranteed wait time.
To explain this process, this diagram shows the same received events as for the previous diagrams, but with correlatedWindowTime set to 60 and 30 seconds respectively:
correlatedWindowTime is not used by standard rules.
The virtual fields dataEventId, correlatedEventName, correlatedEventOperation, and correlatedWindowTime are not included in the events the time correlation rule publishes, but all other copied and virtual fields defined in the rule are included. Do not include fields that you do not use because they take up unnecessary space in the system. If multiple rules use the same dataEventId value, all copied and virtual fields should be the same for all rules, because you do not know which of those rules publish an event whose data is used when the time correlation rule publishes a new event.
The system field *processorName, which contains the name of the rule, for example “com.infor.event.analytics.smartrules.M3BODsItemMaster.MITMAS_UPDATE_ItemMaster”, is also included in the event published by the time correlation rule. You can use this field to see which rule created the data used by the time correlation to publish the event.
This table shows an overview of the virtual fields used to control time correlation from data events:
| Virtual field | Description |
|---|---|
| dataEventId | Data correlation ID to group events. This field is required. |
| correlatedEventName | Document name for time correlated events. This field is required. |
| correlatedEventOperation | Operation for time correlated events. You must use one of these exact values:
This field is optional. The default operation is 'CREATE'. |
| correlatedWindowTime | Guaranteed waiting time in seconds. This field is optional. The default value is
120 seconds. The minimum value is 20 and the maximum value is 120. Note: Using this field affects time correlation for all rules in
Event Analytics.
|
These events must have the publisher EventAnalytics, the document name TimeCorrelation, and the operation Request.
See the standard BOD session M3BODs_ItemMaster and rule MITMAS_UPDATE_ItemMaster for an example on how to use time correlation in Event Analytics.