Solutions commonly include special rules for survivorship and can be implemented via business actions that run as survivorship rules.
Note: A survivorship rule should only update values owned by the golden record itself. This includes attributes on the golden record, data containers on the golden record, and references from the golden record. This does not include references to the golden record, as reference are typically owned by their source node.
In match and merge, the survivorship rules always compare one source object against the golden record at a time. When merging multiple golden records from the clerical review task list, or unmerging multiple golden records in the unmerge screen, all survivorship rules are applied between the survivor and one source record before being compared to the next source record.
Business action survivorship rules in match and merge can use the following binds defined in the online help Resource Materials documentation:
-
Survivorship Rule Source Objects Bind topic (here)
-
Match and Merge Survivorship Context Bind topic (here)
For more information, refer to the Business Actions topic in the Business Rules documentation (here)
Important: In match and merge survivorship rules, source records are often only available as non-persistent objects. Many of the operations available in the API are not applicable to non-persistent objects and will fail. Examples of operations that cannot be used successfully are approval and workflow-related operations. Operations related to reading and modifying attributes values, references, and data containers can be used successfully.
In match and merge, it is not possible to implement a trusted source pattern with the business action survivorship rule as the source information for an existing value on the golden record is not available in the JavaScript API.
Match and Merge Web Service Endpoint
When using a SOAP web service endpoint for a match and merge solution (defined in the Web Service Endpoint - Match and Merge topic of the Data Exchange documentation here), JavaScript business actions can be used for survivorship rules. By default, when multiple JavaScript survivorship rules are to be run during matching, if a rule fails with an exception, rules that already completed without error are not rolled back and the rules following the one that failed are not run at all.
To change this functionality and ensure all changes are rolled back on a SOAP web service, a property can be added to the sharedconfig.properties file that sets parallel configuration to commit after each job. Because this setting can negatively impact performance, you must contact Stibo Systems Support for activation.