DCR Split Process

Overview

A Reltio DCR can be split into multiple child DCRs which can be routed independently to different destinations. This allows attributes on a parent DCR to be broken up and verified independently by different validators. The only type of DCR that can be split is Update DCRs.

Split DCR for Update DCRs

An update DCR is a DCR that can be used on an existing customer. When an Update DCR is raised by a source system, it may contain attributes that are validated and non-validated. Examples of validated attributes are Name, Specialty, Title, SLN, NPI and examples of non-validated attributes are phone, email and fax. It is possible to take an update DCR and route it's validated and non-validated attributes to different systems for validation. This is accomplished by splitting the original parent DCR’s attributes into child DCRs, which can then be routed to different systems for validation. Child DCR attributes can be validated by Data Stewards, External Validators (example: OneKey),Auto-Approved or Auto-Reject.

The split DCR configuration can also be configured to auto reject certain attributes based on a business use case. For example, in a given client’s Reltio configuration specific attributes for a given entity might be marked as read-only but source systems may not be configured the same way and can send DCRs for updates for these very attributes. See the section for Auto-Reject (destination: Reject) in the sample DCR Split configuration screenshot.

Child DCRs is created according to a configuration file that specifies the mappings between Reltio attribute types and validation destinations.

After the child DCRs are created and routed to their specified validation system, the original parent DCR is routed to the Parent Queue where it can remain until all it'schildren have completed their validation. At this point the status of the Child DCRs is analyzed and used to update the status of parent DCR. Parent DCR statuses can be one of the following: APPROVED, REJECTED or PARTIALLY_APPROVED. The PARTIALLY_APPROVED status indicates that some attributes in the original DCR were approved and some were rejected.

Sample Execution

We would like to create a DCR with multiple attributes which is routed to different locations for validation. In this example, for creating the child DCRs, we can use the following attributes and routings:

  • NPI - Route to Auto Approve

  • Phone - Route to Auto Approve

  • First Name - Route to 3rd Party

  • Address - Route to 3rd Party

To implement this, the following entity type split configuration can be used:

The relation type split configuration can be used as shown below:

Next, In the Reltio UI, create a DCR with the attributes previously mentioned. After modifying these attributes and waiting a brief time for the enrichment stream to process the dcr, you can see the following in the Reltio UI.

This process can create 2 child DCRs. One was auto-approved so the attributes (NPI and Phone) were already applied. The second child DCR was routed to 3rd Party Submit. Additionally, the original DCR was routed to the Parent Queue. The parent DCR can then remain in the Parent Queue until all it'schild DCRs are resolved. In this example, after OK approves (or rejects) the child DCR, the parent can update it'sstatus based on the status of it'schild DCRs and then is removed from the Parent Queue. Possible parent DCR statuses include the following:

  • APPROVED

  • REJECTED

  • PARTIALLY_APPROVED

You are able to look up the DCR status in the Reltio UI to view the Parent DCR Status.

A child DCR can be set to be Auto-Reject in the split DCR configuration in the same way it’s done for Auto-Approve.

Configurable Parent DCR Status

If the client choses, the parent DCR status can be made configurable, for example, if there are two children for a parent DCR – childDCR1 and childDCR2 and their states are “APPLIED” and “REJECTED”, by default the Parent DCR status is “Partially_Approved” but if the client wants it to be “Partially_Rejected”, it can be done in the client specific configuration for Parent DCR status. This client configuration can be added to the same split DCR configuration file ($PMRootDir/configuration/dcr_definition_splits.json).

There are two levels of configuration – primary and secondary. Primary configuration is the configuration which provides the configuration settings, as to what should be the status of the parent DCR based on the overall children status in Reltio. For example, for a given parent DCR, let’s say there are three children and at a given point when the Parent Queue session is run, if the children are in the states – Approved, Pending and Rejected, then according to the configuration example shown below, the parent DCR status is “Partially Rejected”. If the client wants to implement only the primary configuration, then the parent DCR’s status is resolved based on the children status combination found in this configuration. The secondary configuration is to enforce the parent DCR status based on the split label (splitLabel1.. splitLabel5, discussed in another subsection under split DCR) values. If the client implements and provides both the primary as well as the secondary configuration then the parent DCR’s status is mainly based on the splitLabel value(s) provided in the secondary configuration. The status resolution can still happen from the primary configuration (it is elaborated in the following sections).

If the secondary configuration values do not match with any of the children DCR, the children dcr is considered to be “Default” (see the screenshot below) and the value set for this status are the DCRStatus value for the parent DCR.

Here is a screenshot of the parent DCR status configuration (which is part of the main split-DCR configuration):

In the above screenshot, both primary and secondary level configurations are provided. Below are some example use cases:

  • Client wants the parent DCR status to be based on only one child. For that child, let’s assume, the client provides splitLabel1 configuration value to be “Type1”. For this use case, the client can need to setup the secondary configuration as below:

    Copy 
    "parent-secondary-config": {
    "externalInfo.json.SplitInfo.splitLabel1": "Type1"
    }

This indicates that the parent DCR’s status should be based on the child which has the value for SplitInfo attribute splitLabel1 to be “Type1”.

  • If the secondary configuration contains the value for splitLabel that does not belong to any of the children then the parent DCR status is derived from the “Default” status in the configuration:

    Copy 
    "parent-secondary-config": {
    "externalInfo.json.SplitInfo.splitLabel1": "Type7"
    }

  • Client wants the parent DCR status to be based on two children only. For this use case the secondary configuration should be as below:

    Copy 
    "parent-secondary-config": {
    "externalInfo.json.SplitInfo.splitLabel1": "Type1, Type2"
    }

In this case the parent DCR’s status is based on two children dcrs which have the values for splitLable1 values to be Type1 and Type2.

It should be noted that the secondary configuration should have valid value(s) for the splitLabel1 (externalInfo.json.SplitInfo.splitLabel1). If the value provided does not match with any of the children’s splitlabel1 value, then the parent DCR’s status update cannot happen properly.

It should be noted that the primary configuration is always read to set the value of the parent DCR.

Children DCR Split Labels and DCR Routing

The client can modify the default DCR configuration to add up to 5 split labels (splitLabel1, splitLabel2, splitLabel3, splitLabel4, splitLabel5) which iscome part of the child DCR’s externalInfo, under the sub-attribute ‘SplitInfo’ (as shown in this below screenshot), when the DCR is created with this configuration.

These labels can be used to route the children DCRs to a desired destination in the DCR routing process by adding proper routing configuration for this in the internal/external routing configuration file, rather than choosing the destination in the split-DCR configuration. This, for example, allows flexibility to route the dcr for the same attribute but for different countries to different destinations.

The internal/external Routing configuration for this is something like this:

This configuration can route the DCR for which the nodepath value is Type1, highlighted above, to Internal for Address countries – US, CH and NL. Similarly, another configuration block can be added to route the given DCR to a different destination for a different address country.

Child DCR Split Configuration Based on Country

The split DCR configuration can be customized to make it country specific by adding “Check-Condition” to the split DCR configuration as shown below:

Multiple blocks of split configuration for different countries can be added to the same configuration file if the client wants to setup different split rules for different countries. If we wish to use the Country at the entity-level, instead of the country at the address level, we can do so. Below is an example setting for it:

Copy 
"Check-Condition": [

{

"nodePath": "attributes.Country",

"nodeValueField": "lookupCode",

"matchValue": [

"US",

"CH",

"NL"

]

}

A default block of split-DCR configuration should still be provided, in case none of the conditions match with the given DCR.