September 11, 2023 / August 23, 2024 by Danail Iliev

Reltio Tips & Tricks – Part I

Building Query Filter Using UI

If you have ever struggled with building a filter for your API calls or SQS queue then this tip is for you. Simply open the Network tab of your browser console – the exact way to do this depends on your OS and browser. Make sure the network requests are being recorded and don’t forget that if you, for any reason, refresh the web page – your network tab is probably going to blank out and you have to do it again. Navigate to the Advanced Search feature on the Reltio UI and setup the filter the way you want it:

When you are done with configuring your filter in the Reltio UI you can easily grab it’s code representation from the HTTP request that your browser sent out:

You may notice how some fields are encoded (the %2C%27 symbols), but if you right click on the filter and copy the value it will be copied in your clipboard unencoded.

But The Result Is Different in the UI

As Reltio consultant I have heard this many times – “the result we are observing on the UI does not match the result we get back from the API call”. The solution is the same as per the previous top. You should open the Network tab on your browser and do the action in the UI so that you can capture the HTTP requests. Then thoroughly inspect the request with all the parameters and payload which the Reltio UI performed. Compare what the Reltio UI sent vs what you are sending in your API call to find where the two differ.

Creating Multiple Users with Your Email

Trying to create a user (even if the user name is different) under the same email will result in the following error: “Email danail.iliev@ulpia.tech is already in use”. However, with this hack you could create virtually endless number of users under your email. This is often required for testing with different roles. To create a new user under your email simply add + followed by a suffix that makes sense for the user. For example: my email would be transformed to danail.iliev+tipsntricks@ulpia.tech. Then I could choose whatever user name serves my purpose and the user creation will not be blocked. You will receive an email on your main address prompting you to change the password and thus you could log in into the new account you created.

SQS Queue: Unique Conditions per Event Type

Sometimes we may want to do a more complex filter condition on our SQS. For example:

On ENTITY_CREATED, only send the Organization records to the queue if the Name = ‘Temp Org’ (imagine that we are creating temp organizations which are sent to a queue, we then pick those from the queue and perform some transformations on them. But we want to do this only when the temp org is created)
On ENTITY_CHANGED – send all Organization records regardless of their name

Records matching both conditions should be sent to the same queue. But how can we achieve this? A straight-forward approach would be to try and use a filter similar to:

(equals(type,’configuration/entityTypes/Organization’) and equals(event, ‘ENTITY_CHANGED’)) or (equals(type,’configuration/entityTypes/Organization’) and equals(attributes.Name, ‘Temp Org’) and equals(event,’ENTITY_CREATED’)) but this doesn’t really work – we have no way to filter on the event in the queue configuration.

What you could do instead is add two configurations for the same queue. That way they would be logically combined with or statement. In this case we will end up with:

Queue configuration 1: Type filter is set to ENTITY_CREATED only and object filter is set to equals(attributes.Name, ‘Temp Org’) and equals(type,’configuration/entityTypes/Organization’)
Queue configuration 2: Type filter is set to ENTITY_CHANGED only and object filter is set to equals(type,’configuration/entityTypes/Organization’)

We now have the desired result

Don’t Compare to Current View, Compare to the Previous One Instead

In my experience this is one of the things in Reltio that many have fallen victim to. It is very easy to miss something when debugging a problem that may lie into your integration layer. The reason for that is that people will often use the History tab on the UI to look for when a value has changed from A → B, but people tend to forget that the default option for the history is the one seen below:

For easier debugging I would recommend you switch from this one to the second option. This is of course not the perfect solution for every time, it is important to understand what each option provides:

Compare to Current View will highlight the differences of the attribute values compared to the entity as it is today
While Compare to Previous View will highlight the differences between a point in time X and the previous timestamp of update X-1

Struggling to Find Out When Attribute Changed

Wile we are on the topic of history, there is one more functionality offered by the Reltio UI that is often forgotten. If we use the filter icon – just left of the three dots for “Compare to Previous view”, the following menu will open for us: