First and foremost: A HUGE thank you to my fellow Reltians Pavitra Hari and Roger Mukai. This blog post is a result of their support. To the extent something is correct in this post, they should get the credit, to the extent that something is wrong, please blame me!
As most Reltio users are aware, Reltio has a number of cleansers built in. These include Phone and Email Cleansers as well as Address which is validated. By default, these cleansers are enabled and operate on the data as long as the minimum required attributes are populated. This works fine for almost all of our customers.
But recently, a prospect asked about conditionally cleansing this data. Why would someone want to do this? In this case the prospect had external services that performed additional cleansing that the Reltio cleansers do not. If the data came from one of those services, cleansing the data again could be counterproductive. But if the data had not been cleansed they wanted to use the Reltio Cleanser. This also might make sense for a use case that conditionally demanded that the data not be touched at all.
Configuring Reltio cleansers is beyond the scope of this blog post. The purpose of this blog post is how to modify the existing cleansers so they can become conditional. Please note that this is not boolean functionality where the attribute is True/False where the value controls the logic to drive the cleanser. Instead, it functions in a way where if an attribute is populated the cleanser will operate. If the attribute is not populated the cleanser will not operate. So configuring this attribute as a boolean will give a non intuitive user experience.
The first thing to note is that these attributes are nested or reference. The modification we will discuss here is only for these types of attributes. This will not work on simple attributes. The next thing to note is that this uses Reltio cleansers. The cleanser used must be registered in the tenant physical configuration. This is not directly modifiable by customers. So if you need to register your cleanser, a ticket will be required and support will get this done for you. In the end, it will be easier if you use the out of the box cleansers that are already registered.
Once this is done, the cleanser can be modified to be conditional. The process overview looks like this:
-
Create simple attribute in the nested/reference attribute
-
Modify the cleanser to use this attribute
-
Test
The Reltio Console Data Modeler can be used to add an attribute to the nested/reference attribute. The configurator should add an attribute of a type that is compatible with the cleanser. In this example, we'll be using a string cleanser so the attribute added is of type String. The attribute should NOT be populated to be governed by Reference Data Management (RDM). RDM interferes with the cleanser functionality and will prevent the conditional configuration from working properly. For the purpose of this blog post, let's assume that the attribute we want to make conditional is phone and the attribute configured is of type string with URI configuration/entityTypes//XXX/Attributes/Phone/Attributes/CleansePhone where XXX is the entity type. In our example, this will be HCO.
Since in our example we'll be doing this for HCO, the next part is to modify the cleanser. The cleanser is found in the configuration/entityTypes/HCO part of the configuration file. Within the HCO, there is a cleanseConfig object. Within that there is an infos array. Within the infos array, pick the cleanser you are interested in. For out of the box configuration for the Phone attribute, there is only one cleanser, PhoneCleanserFn (yours may be different depending on the Velocity Pack or accelerator in use). Within the infos array there is a sequence array and inside of that there is a chain array. The chain array has one element. We will add a second attribute, before the existing attribute.
What should the object to be added to the array look like? Well, it looks a lot like all the other cleansers! Let's look at the example below (Please ignore the yellow highlighting in the screen shot!).
The cleanseFunction parameter should use the cleanser that was added to the physical configuration that was set up in the pre work above. proceedOnSuccess should be true, proceedOnFailure should be false. This is the key to why this configuration works. If the cleanser actually cleanses a string, it succeeds. If it succeeds it continues on to the next part of the configuration, which is in this case cleanses the phone. If the first part fails, the cleanser stops and does not continue to the next part of the configuration. The first part will fail if the configured attribute is not populated, as there is nothing to cleanse. This is the conditional functionality.
The input/output mapping values are both the URI of the attribute that was created. The params value should reflect any optional parameters for the specific cleanser that you are using.
Here is the result of the configuration. I've created an HCO with two phone numbers. In this first example with the 401 area code, note that the 'Cleanse Phone?' attribute is blank.
For the area code 405 number, the 'Cleanse Phone?' attribute is populated, in this case with an 'x' although any value will do
The result of this is that the 405 area code number is cleansed and the 401 area code number is not.
This approach should work with phone, email and address cleansers as well as any other cleanser working with a reference or nested attribute.
NOTE: This configuration has been tested with Reltio version 2024.2
#Blog
#Featured