Configure Groovy Script Based Agreement Rules
In this example, we are operating in a complex business ecosystem where it's not always appropriate to merge certain accounts that have been identified as duplicates.
When the conditions that prohibit a merge from happening are encountered, the data steward needs to see an informative message explaining exactly which records blocked the merge, and for what reasons. The conditions that can prevent a merge are as follows:
When the conditions that prohibit a merge from happening are encountered, the data steward needs to see an informative message explaining exactly which records blocked the merge, and for what reasons. The conditions that can prevent a merge are as follows:
-
A non-master record is integrated with the Legal Hold system
-
A non-master record has a Certification Score value of 100
Steps to Perform
-
Enable Groovy Scripts to select master records:
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Customer Data Management
-
Functional Area: Customer Hub
-
Task: Manage Customer Data Management Options
-
-
In the Merge Behavior section under the Duplicate Resolution Options tab, select the Default agreement rules with groovy scripts option for the Agreement Rules Type field.
-
-
Create an Application Composer sandbox. Refer to the Create an Application Composer Sandbox topic for the steps.
-
Populate the sample script in the
AccountMergeAgreement
template:-
Navigate to Common Setup and click Data Quality Rules.
-
Click
AccountMergeAgreement
.
-
-
Copy and paste the code given in the Sample Code section in the Edit Data Quality Rules page.
-
Click Save and Close.
-
Test the code. Refer to the Test the Survivorship and Agreement Rules Configuration topic to test the code.
-
Deploy the code after you're satisfied with the results of the agreement rules. See the topic: Deploy the Survivorship and Agreement Rules Configuration.
What the Sample Script Does
The script begins by calling the getNonMasters()input function
to access the non-master records
in the merge request. Note that the result of a Set Master groovy
scripts is expressed in getMaster()
and getNonMasters()
responses in
Agreement Rule and Attribute Selection scripts. Next, the script loops
through each of the row records to test for the two different conditions
that would lead to the merge being rejected. The first test is to
evaluate the source system reference assignments of the records to
determine if the record is integrated with the Legal Hold system.
The second test is to check the Certification Level value of the non-master
records. If a given record matches either of the tests, a partial
rejection message is added to the vetoMessages
array.
After all the non-master rows in the merge request
have been tested, the script checks to see if the vetoMessages
array has any data in it. If it does, then
a final rejection message is constructed from the data in the vetoMessages
array and the merge is rejected
with that constructed message being displayed to the data steward
in the duplicate resolution UI.
Sample Code
try {
def rowNonMasters = getNonMasters();
def sMsg = "";
def rejectMsg = "";
def vetoMessages = [];
for (row in rowNonMasters){
def OSRs = row.getAttribute("OriginalSystemReference");
OSRs.reset();
sMsg = "";
while(OSRs.hasNext()) {
def OS = OSRs.next();
if (OS.getAttribute("OrigSystem") == "LEGAL_HOLD" && sMsg == "") {
sMsg = "A legal hold has been placed on Account " + row.getAttribute("PartyNumber");
vetoMessages.add(sMsg);}
}
sMsg = "";
if (row.getAttribute("CertificationLevel") == "100") {
sMsg = "A Certification Level of 100 was found on Account " + row.getAttribute("PartyNumber");
vetoMessages.add(sMsg);}
}
if (vetoMessages.size()) {
rejectMsg = "Merge rejection reasons: ";
vetoMessages.eachWithIndex { item, index ->
rejectMsg += ((index +1) + ") " + item + " ");
}
rejectRequest(rejectMsg);
}
}
catch(Exception e) {
def sMsg = "Exception in Account Merge Agreement: " + e.getMessage();
println(sMsg);
}