Question
The team is still not clear on what needs to be done to have the MDM data reflect changes to the RDM canonical values. In January of this year, we updated our “Address Type” canonical values in RDM and remapped values from all of our sources to align with them. We expected the MDM profiles to reflect the new values and mappings, instead, the results were mixed. Some profiles were updated, others were not and there didn’t seem to be a clear delineation between them.
Answer
There are two physical tenant properties that should be defined. It is always a good practice to perform this in your lower environment first. It is important to remember that if resolveLookCode is set to true, you will need to reload the data.
- resolveLookupCode should be set to false.
Property Definition
resolveLookupCode = true. This means that the lookup code is stored in C*, no matter lookup code or lookup value was specified in the entity POST request. So, lookupCode is used in the list of calculations above for matches to be found.
resolveLookupCode = false (default). The “raw” value of the lookup attribute (which was specified in the entity POST request) is recorded to C*. In this case, lookupRawValue is used to define matches.
Once the lookup code configuration is enabled (resolveLookupCode=true), it is not possible to revert the data back to its original state without reloading your profile data.
- resolveLookupStrategy should be set to "LOOKUP_CODE".
Property definition
NONE: lookups will not be resolved for matching, raw attribute values will be used
LOOKUP_CODE: lookup will be resolved and lookup code will be used for matching instead of the attribute value.
LOOKUP_VALUE: lookup will be resolved and lookup value will be used for matching.
- Make sure that you have cleaned up any unmapped lookup value. If you have unmapped values, you can fix them by drag&drop unmapped on the mapping tab. After that, when you save changes, UI creates new mapping and removes the unnecessary unmapped. This is a single way to “clear“a list of unmapped values.
-
- If you have an unmapped value and have the same lookup mapping, you could use an RDM API request to remove redundant unmapped values (as defined below)
- You can execute the following task to remove all redundant unmapped values.
POST https://rdm.reltio.com/tasks/<rdmTenant>
{
"type": "deleteUnmapped"
}
- After fixing unmapped errors, you should perform the following tasks to execute reindex entities to resolve unresolved RDM lookups in MDM.
POST https://{{rdm-service}}/tasks/{{tenantId}}
Authorization: Bearer {{token}}
{
"type": "cleanupIndex"
}POST https://{{rdm-service}}/tasks/{{tenantId}}
Authorization: Bearer {{token}}
{
"type": "reindex"
}
- If you are making a bulk change in the L3 (data model) to attributes that are using the RDM lookup value, please perform a full MDM reindex (where the task builds a new index). This will immediately fix the lookup change if resolveLookupCode is set to false. If resolvelookupcode is true, MDM doesn't keep source code for successfully transcoded records. The only real option here is to perform a bulk update (please refer to https://reltio.zendesk.com/hc/en-us/articles/7121283419917)
POST {ApplicationURL}/reindex?tenantId={tenantId}?enableSeparateIndexing=true
- If you are making a change to the lookup code for relations.
Example:
"attributes": [
{
"label": "Code",
"name": "Code",
"type": "String",
"hidden": false,
"important": false,
"system": false,
"required": false,
"attributeOrdering": {
"orderingStrategy": "LUD"
},
"uri": "configuration/relationTypes/OrgToAccount/attributes/Codes/attributes/Code",
"lookupCode": "rdm/lookupTypes/CODE",
"skipInDataAccess": false
},
- Make sure that searchStorageConfiguration.indexRelations is set to true.
POST /reltio/{tenantId}/reindexRelations?forceIgnoreInStreaming=true&enableSeparateIndexing=trueReference
- https://docs.reltio.com/tasksapi/ReindexRelationsTask.html
- https://docs.reltio.com/tasksapi/ReindexDataTask.html
Comments
Please sign in to leave a comment.