Out-of-order message handling
- Last UpdatedFeb 24, 2025
- 3 minute read
Sometimes, update data requests might arrive in a different order than they were created. This could be due to a variety of communication delays.
Scenarios
Consider the case where three update record submissions arrive at almost the same time. The time difference between requests might be a few seconds. Depending on the order of arrival, the outcome can be different and unpredictable.
The submit request that arrives last determines the value.
Scenario 1: Ash = 20 arrives last
|
Data Creation Time |
Arrival Time |
Update Requests |
|---|---|---|
|
10:30:03 |
10:30:09 |
Update Record 1 with Ash = 10 |
|
10:30:09 |
10:30:10 |
Update Record 1 with Ash = 15 |
|
10:30:06 |
10:30:11 |
Update Record 1 with Ash = 20 |
|
Ash = 20 |
Scenario 2: Ash = 15 arrives last
|
Data Creation Time |
Arrival Time |
Update Requests |
|---|---|---|
|
10:30:03 |
10:30:09 |
Update Record 1 with Ash = 10 |
|
10:30:06 |
10:30:10 |
Update Record 1 with Ash = 20 |
|
10:30:09 |
10:30:11 |
Update Record 1 with Ash = 15 |
|
Ash = 15 |
RecordDateTime field
Since it's not ideal to have a small amount of time affect the outcome so significantly, we want to be assured of more reliable and predictable results. We have added a RecordDateTime field to handle cases where record submissions arrive almost simultaneously or out of order.
An external system provides the RecordDateTime value to make sure that AVEVA™ Production Management recognizes the most up-to-date value for the record.
Scenario 3: Ash = 18
The RecordDateTime field determines the creation timestamp and the processing order.
|
RecordDateTime |
Update Requests |
Action |
|---|---|---|
|
10:30:08 |
Update Record 1 with Ash = 20 |
Updated |
|
10:30:10 |
Update Record 1 with Ash = 15 |
Updated |
|
10:30:15 |
Update Record 1 with Ash = 18 |
Updated |
|
10:30:12 |
Update Record 1 with Ash = 16 |
Ignored |
|
Ash = 18 |
Modules
Each of these modules has a RecordDateTime standard field under its module configuration folder. The default behavior for the RecordDateTime field is not mandatory. You must enable IsMandatrory = True to activate the RecordDateTime feature.
-
Note: RecordDateTime is not supported when using Matching Movements to Plan.
When you set the value for the RecordDateTime standard field at the module level, all reporting points in the module inherits this behavior. You can set the property at the reporting point level to override the inherited behavior.
Insert Record scenarios
The results for an Insert Record request can vary depending on whether the RecordDateTime is mandatory and whether a data capture value is present.
|
RecordDateTime = Mandatory |
DataCapture = Present |
Result |
|---|---|---|
|
Not mandatory |
No data capture present |
Creates new record |
|
Not mandatory |
Yes |
Creates new record |
|
Yes |
No data capture present |
Error occurs |
|
Yes |
Yes |
Creates new record |
Update Record scenarios
The results for an Update Record request can vary depending on whether the RecordDateTime is mandatory and whether a data capture value is present.
|
RecordDateTime = Mandatory |
DataCapture = Present |
Existing Record |
Result |
|---|---|---|---|
|
Not mandatory |
No data capture present |
No existing value |
Behaves as before |
|
Not mandatory |
Yes |
No existing value |
Overwrites existing value |
|
Not mandatory |
Yes |
Existing value is older |
Overwrites existing value |
|
Not mandatory |
Yes |
Existing value is same |
Overwrites existing value |
|
Not mandatory |
Yes |
Existing value is newer |
Record is unchanged |
|
Yes |
No data capture present |
No existing value |
Error occurs |
|
Yes |
Yes |
No existing value |
Overwrites existing value |
|
Yes |
Yes |
Existing value is older |
Overwrites existing value |
|
Yes |
Yes |
Existing value is same |
Overwrites existing value |
|
Yes |
Yes |
Existing value is newer |
Record is unchanged |