Reltio Connect

I'm still learning so hopefully my terminology is correct.

When I create a new cross walk using the REST API that should automatically merge to an existing Entity ID, I get a new Entity ID because the match and merge process is asynchronous.

In order to be notified of the final Entity ID we have to use the Reltio Events API.

Is the ENTITY_CREATED event before or after the match and merge process or are there no guarantees.

The ENTITIES_MERGED only triggers when there is a merge.

Can ENTITIES_MERGED ever be published before ENTITY_CREATED or is guaranteed to always be after?

The gap in the API I am confused about is how to know that a record is added and does not get merged because the match and merge process has confirmed it should remain where it is. i.e. a cross walk record is recreated and no automatic merge occurs.

Ideally, we want one message in from the source system into Reltio, and one message out for that transaction to send back. From what I can tell we might have listen for the two events and potentially send up to two messages back.

------------------------------
Vincent Tran
IMT
------------------------------

I am very interested in this, too.  We use the message streaming as well.  The auto-merge is not always a merge-on-the-fly and can take a few (sometimes several) seconds to actually merge, by which time we have already assumed there is not an existing match and started another process which results in duplicate entities being created.

Hi Vincent!

Good question.  I assume you want the 'final' value because you need to refer to it later in your process.  The good news is that this is unnecessary.  If you GET and entity by the. ID before it was merged, you get back the same information as if you had the ID of the entity that it was merged into.  Is that helpful?

Although it is useful it doesn't address the issue.

In my tenant if I create a new cross walk using API to get  entities/SstrZ94

If I then add a new cross walk the response of that will be entities/00tTdkb

If I then retrieve the entity by cross walk id it will continue to be 00tTdkb for about 7 seconds in an inactive training tenant before it becomes SstrZ94.

This is because match and merge is asynchronous. We do not want to continually poll the tenant because that will lead to performance issues.

Another Question: A Reltio employee said that there is a parameter that can be used when creating the entity to have it wait for match merge to complete before responding. I cannot find it in the documentation. Create Entities | Reltio

If there is no parameter then the best option is to use the Events API.

The challenge is the following:

Souce system sends a new cross walk for a new Contact.

I get ENTITIES_CREATED from Events API. 

At what time / when should I send that back to the source system for their cross walk as their final Entity ID given that match and merge is asynchronous. There may be a ENTITIES_MERGE 5+ seconds later depending on the size of the tenant queue. There may not be an ENTITIES_MERGE at all because it is a new Contact. How do I know that the match and merge has completed for the cross walk without continuously polling?

------------------------------
Vincent Tran
IMT
------------------------------

Have you folks considered adding a basic "search before create" concept into your flow where you could essentially first check if an exact replica of the record already exists before trying to save a new one?  You could use a filter condition or even the real-time match API.  At least this way you don't have to go back to the queue to look for merges after the fact.  Not sure of your volumes and whether you're running big batch processes vs real-time transactional adds/updates.  Going this route would add to the number of tasks used but if it's really important that you know up front that a similar record already exists, then it may be worth the additional tasks to do the check.  

Regards.

Search before create | Reltio

I don't believe it will work because Search Indexing is Asynchronous as well. This means you can create a new Crosswalk/Entity ID, but you cannot search for the record using attributes until X seconds later as well. 

If there was a stream of messages for the same brand new Contact (some source systems can be very chatty), for each one of those messages we need to send back the Entity ID. Doing a search before create will constantly create new records until search indexing is complete.

------------------------------
Vincent Tran
IMT
------------------------------

While it's true that the search index is updated in an asynch manner, the only time a record won't appear in your search before create scenario is if someone else just created the exact same record within the last second or two.  I've no idea how likely that is in your scenario but if you do go that route (search before create), you should easily be able to eliminate a lot of unnecessary duplicates that don't even have to go through the match / merge process in the first place.