Topic
  • 10 replies
  • Latest Post - ‏2013-01-11T01:26:37Z by SystemAdmin
Evyatar
Evyatar
12 Posts

Pinned topic SDP (Perfect Match) behavior on Update Party

‏2009-10-19T09:45:10Z |
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)?

Thanks in advance,
Evyatar
Updated on 2013-01-11T01:26:37Z at 2013-01-11T01:26:37Z by SystemAdmin
  • mdm_newbie
    mdm_newbie
    15 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-19T17:27:16Z  
    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.

    Thanks,
    Vj
  • Evyatar
    Evyatar
    12 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-20T12:17:42Z  
    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.

    Thanks,
    Vj
    Hey,

    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).

    Thanks,
    Evyatar
  • mdm_newbie
    mdm_newbie
    15 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-20T15:56:12Z  
    • Evyatar
    • ‏2009-10-20T12:17:42Z
    Hey,

    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).

    Thanks,
    Evyatar
    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.

    Thanks,
    Vj
  • Evyatar
    Evyatar
    12 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-21T15:16:47Z  
    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.

    Thanks,
    Vj
    Hey,

    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?

    Thanks in advance,
    Evyatar
  • mdm_newbie
    mdm_newbie
    15 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-21T17:22:32Z  
    • Evyatar
    • ‏2009-10-21T15:16:47Z
    Hey,

    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?

    Thanks in advance,
    Evyatar
    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);
    }
  • mdm_newbie
    mdm_newbie
    15 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-21T17:25:04Z  
    • Evyatar
    • ‏2009-10-21T15:16:47Z
    Hey,

    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?

    Thanks in advance,
    Evyatar
    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.

    Thanks,
    Vj
  • mdm_newbie
    mdm_newbie
    15 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-21T17:28:46Z  
    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.

    Thanks,
    Vj
    Evatayar,

    Pls ignore Post# 6 in this thread..My Mistake..

    Thanks,
    Vj
  • Evyatar
    Evyatar
    12 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-22T08:07:45Z  
    Evatayar,

    Pls ignore Post# 6 in this thread..My Mistake..

    Thanks,
    Vj
    There are no records in CONTACTCDC, as we allow all changes (configelement "/IBM/Party/CriticalDataChangeProcessing/enabled" = false).

    Are you suggesting to change that configelement value to "true" and then create the changes you mentioned?

    Regards,
    Evyatar
  • Evyatar
    Evyatar
    12 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2009-10-25T16:26:05Z  
    • Evyatar
    • ‏2009-10-22T08:07:45Z
    There are no records in CONTACTCDC, as we allow all changes (configelement "/IBM/Party/CriticalDataChangeProcessing/enabled" = false).

    Are you suggesting to change that configelement value to "true" and then create the changes you mentioned?

    Regards,
    Evyatar
    I will rephrase -

    When a Party is updated to have the exact same details as an existing Party, we want to activate Auto Collapse functionality.

    Can someone please assist with detailed instructions?

    Thanks in advance,
    Evyatar
  • SystemAdmin
    SystemAdmin
    345 Posts

    Re: SDP (Perfect Match) behavior on Update Party

    ‏2013-01-11T01:26:37Z  
    • Evyatar
    • ‏2009-10-25T16:26:05Z
    I will rephrase -

    When a Party is updated to have the exact same details as an existing Party, we want to activate Auto Collapse functionality.

    Can someone please assist with detailed instructions?

    Thanks in advance,
    Evyatar
    Hi, did you got the auto collapse for update implemented? If yes, could you please share the details.