Question
We have observed when an entity update has happened using a partial override update all attributes are retained in the final entity but when we check on history at the different timestamp, we noticed that system deletes the attributes and add them back later.
However, the major issue here is, that when the update has been posted, the entity changed the message posted to the AWS SQS queue without that dropped attributes and this is causing the downstream team not to get the latest member updates.
Answer
The historical slice scenario falls into the "working as designed" where:
- We have an entity with an attribute value A that was created at time 0.
- Operation1 started at time 1 and the operation added attribute value B and finished at time 1 end.
- Operation2 started at time 2 and the operation added attribute value C and finished at time 2 end.
- If time 1 < time 2 < time 2 end < time 1 end then in history we will have:
-
- time 0: attribute values = [A]
- time 1: attribute values = [A, B, C]
- time 2: attribute values = [A, C]
- It appears like attribute value B was deleted. But the attribute has not been deleted.
AWS does not guarantee the sequences, so you may receive the messages in an unexpected order.
Therefore, if you look at the following from the same profile's history, you will see that:
- 05/04 04:42:55, 1S0SO4G1 was created.
- 05/04 04:42:59, the was created (MBR_10490628500_10490628500_B0000001_Facets_310 as an integration key)
- 05/04 04:43:29 the 1CwEzcl6 merged with 1S0SO4G1 where both MBR_10490628500_10490628500_B0000001_Facets_310 and MBR_10490590400_10490590400_B0000002_Facets_310 are applied to the entity.
- 05/04 04:43:48 (according to the history), the partial update to 1S0SO4G1 occurred (where 10490590400 external member Id was added). The reality is that the partial update started and was completed milliseconds before the merge.
- The true state of the entity was the result of the merge on 05/04 where both MBR_10490628500_10490628500_B0000001_Facets_310 and MBR_10490590400_10490590400_B0000002_Facets_310 were applied.
For the processing of CRUD events, please keep in mind the following definition (refer to https://docs.reltio.com/events/messagestreamingcrud.html.)
Note: If you are processing messages using message streaming, to identify the latest event
amongst several events for an object, use the objectVersion property. The objectVersion
property identifies the message with the latest object state. For more information,
see CRUD Events.
You cannot use the timestamp in the createdTime and updatedTime properties since it is
only used to indicate the start of the operation that creates or updates the object record.
The timestamp does not indicate the time when the object record is committed to the database.
When two or more operations are executed simultaneously, the updatedTime property may not
reflect the latest object state if one operation started earlier than the other but is not
committed to the database immediately. 
Comments
Please sign in to leave a comment.