Reltio Connect

Hi,

We have a scenario where some records failed in the real time and were send back to reltio but they have updatedate older than what data is currently present in Reltio.
Ex- Attribute x in Reltio is present with value - 50 on 7th jan 2021
Now the record which is now being re-loaded for the same attribute x is with value - 30 but with updatedate as 6th jan 2021 (this date being part of the crosswalk).
We see, this data is being updated along with the LUD in reltio but ideally it should not. Is this anything related to 'updateAttributeUpdateDates' to be set in the physical configuration ? Kindly provide your inputs as ideally the behavior should be to not accept the old data/back dated data.

Note - This attribute has survivorship rule as LUD. Also, we are updating the data using partial override and giving the complete payload of the entity(not just attribute x).
Thanks!

Thanks Anuja,

If I understand your scenario correctly, the data was loaded before the 6th but failed.  So it was actually loaded the 7th.  There is other data that is correctly loaded on the 6th.  Using Last Updated Date, is your desired result that the value from the 6th or 7th be the surviving value?

Hi Gino,

Scenario is as follow -
1)Data loaded on 6th jan at 3PM IST--Failed
2)Data loaded for the same crosswalk with updated value on 6th jan at 3:30PM IST(partial override with full payload) - Successful
3)Data re-loaded for the same record which failed on 6th jan at 3pm IST (now data is being sent at 4PM as part of reprocessing of failed records) - Successful.

We see that 3) point data is also loaded but this is not the most updated data. It is point 2) . In an Idea scenario,the point 3) data should be rejected as its LUD is less than what is present in reltio(which 6th Jan 3:30PM IST).
My end goal is that point 2) data should survive.

Thanks !

Hi Anuja,

Can you please provide me with a few more details.

1. Is the attribute(s) in question a simple or nested attribute ?
2. When you say you're updating the

Hi Anjua,

Can you please provide a few more details for me to fully understand the scenario.

1. Is the attribute(s) in question a simple or nested attribute ?
2. When you are posting the data, are you populating the crosswalks.createDate and / or, more importantly, the crosswalks.updateDate ? Remember if these are not populated, they will be set to the reltioLoadDate which is the current timestamp - Reltio will populate reltioLoadDate itself (always) and crosswalks.createDate and crosswalks.updateDate if not submitted in the request.

It is important to understand the sequencing of requests to Reltio. If you partially overrode the crosswalk and contributed data at a later date, with older data... Reltio does not know it is stale data and it would be considered most recent.

My suggestion is to experiment with the updateAttributeUpdateDates option as part of the partial override request.
Reference: https://docs.reltio.com/entitiesapi/createentities.html?hl=updateattributeupdatedates 

If you are loading data in this reverse order, you may need to strip out the unchanged attributes from the payload... so they don't all get set with the older date.

So in this case you would send 'attribute C' in the payload with value '30' and updateAttributeUpdateDates set to true, with that update date bing some time on 6th January.
When this is complete, you should then be able confirm that a 'crosswalks.singleAttributeUpdateDates' for 'attribute X' was set when you GET the entity.

This will then allow Reltio to factor in this older attribute date against the generic 'crosswalks.updateDate' (which applies to all attributes contributed by that crosswalk, unless 'superseded' by a 'crosswalks.singleAttributeUpdateDates' for that attribute) and be leveraged by your LUD (Recency) rule.

Hope this helps !

Thanks Jacques.
The attribute is a simple attribute and we are sending only crosswalks.updateDate.
I have tried with the updateAttributeUpdateDates also along with partialoverride option but there seemed no difference when updating data without updateAttributeUpdateDates parameter. So,to confirm my understanding, reltio would not stop from accepting backdated/old data (when sending the entire payload with the updated attribute and crosswalk.updatedate)?

For the crosswalks.singleAttributeUpdateDates, I see that this value is populated only when we are sending the updated attribute(partial override) with the crosswalk.updatedate which is always greater than or equal to the current date. In case the crosswalk.updatedate is backdated/old, the crosswalks.singleAttributeUpdateDates is not populated. We want this should be populated in all cases when only the updated attribute is being sent with partialoverride. Is there any way,  it can be done?

Hi Anuja,

I believe you are correct and there is a validation that prohibits backdated dates that are earlier than the overall crosswalk update date.

If this use case is a requirement for your overall solution design, I suggest filing an Idea for this at https://reltio.ideas.aha.io/

Thanks,
Jacques

Thanks Jacques for the response. I am not able to register / login to the link you provided. Can you help me with the registration process here.

Thanks!