Let's say we have two Party records:
Person A with First Name "aaa", Last Name "bbb", DoB 01/01/1980 and a full Address X (Party ID 1)
Person B with First Name "ccc", Last Name "ddd", DoB 01/01/1970 and a full Address Y (Party ID 2)
Now we get an updateParty request for Person B with all the relevant idPK and LastUpdateDate values.
However, the request is to change the values of Person B to be exactly like Person A.
According to the documentation, the parties should be automatically merged (A1 match).
What would happen in terms of DB records and IDs?
Should we get in the updateParty (for Person B) response Party ID 1 (of Person A)?
When the updateParty request is received for Person B with all critical data elements same as Person A (leading to A1 match), the Person B will be updated. Once updated, suspects are reidentified, therefore, Person A and Person B are A1 matches. An A1 suspect record is created in the SUSPECT table.
Based on the auto collapse rule configured, you may be able to see a brand new party created in the database due to the collapse of Person A and Person B, with Person A and Person B party records inactivated.
That sounds good.
How do I verify that the auto collapse rule is configured?
In our implementation there's not going to be any manual handling at the moment (SDP would result either a perfect match or a new party and never a suspect).
Check Rule 11. Out-of the-box it is configured to use AutoCollapsePartiesProductionExtRule class which does not do anything.
Set the Rule 11 to execute AutoCollapsePartiesExtRule class instead. This might do the auto-collapse.
I did what you said, assuming you meant to running the following SQL command -
update JAVAIMPL set JAVA_CLASSNAME ='com.dwl.tcrm.externalrule.AutoCollapsePartiesExtRule',last_update_dt = current_timestamp where EXT_RULE_IMPL_ID = 1011;
However, it seems that the transaction doesn't go into that rule.
I think it might be related to the fact that the procedure of "re-identifying suspects" doesn't happen either.
We have in configelement /IBM/Party/CriticalDataChangeProcessing/enabled set to "false", which enables "free" update of critical data.
Is it related?
(I'm asking that because it seems like the Reidentifying process happens after approving CDC...)
What is the solution in that case?
Check if there are any entries in the CONTACTCDC table related to the PartyId being updated.
If there are entries, this means Critical Data Change Processing is not allowed.
Create a custom rule class eg: CustomCDCAllowRule.
public Object execute(Object input, Object componentObject)
throws Exception {
if (logger.isFineEnabled()) {
logger.fine(debugStr);
}
return new Boolean(false);
}
Check if there are any entries in the CONTACTCDC table related to the PartyId being updated.
If there are entries, this means Critical Data Change Processing is not allowed.
Create a custom rule class eg: CustomCDCAllowRule and return Boolean True.
public Object execute(Object input, Object componentObject)
throws Exception {
return new Boolean(true);
}
Configure it as Rule 124. This will allow CDC to be processed real time.
