comparativePreviewCollapseParties

Usage 1

The Data Steward selects a party and finds the best suspect (best match) on the database. The new party is created based on survivorship rules. Prior to collapsing the two parties and adding the new party to the database, the data steward uses a user interface to preview the three party details aligned side-by-side.

Usage 2

The Data Steward provides two parties that are suspects of each others. The new party is created based on survivorship rules. Prior to collapsing the two parties and adding the new party to the database, the data steward uses a user interface to preview the three party details aligned side-by-side.

The comparativePreviewCollapse transaction can be used to preview the source and suspect parties along with the collapsed (new) party. In addition, this transaction will align all the child object collections across the three parties by ensuring that the child objects with the same business keys appear at the same index for each party.

Secondary party (if provided) must exist and be a suspect of the given party

• Given PartyId
• Secondary PartyId

Usage 1

The request Party List contains a vector of one Party business object, the Party ID must be provided, no other details are required.

Provided with the Party ID, this transaction will perform the following steps:

• Read the suspect table and find all suspects of the provided party.
• Find the best suspect match using an externalized rule. Refer to the Configuring External Business Rules section of the developer documentation for details.
• Create new party using externalized rule. Refer to the Configuring External Business Rules section of the developer documentation for details.
• Align all the child object collections across the three parties to ensure that the child objects with the same business keys appear at the same index for each party.

The default implementation of the externalized rule for best suspect match will return the following, in this order: only A1 match found; or best A1 match found (based on highest match relevancy score); or only A2 match found; or best A2 match found (based on highest match relevancy score and lowest non-match relevancy score); or return error if neither A1 or A2 match found (No suspect found for collapse).

The default implementation of the externalized rule of data survivorship will navigate through all data associated with the source party and best suspect, and copy all unique data (based on business key) to the new party. If common data is found on the source and suspect party, then the business object with the latest last update date (LUD) is copied to the new party. If the LUD is the same for both parties (this may occur if the data was directly loaded into the database), the data from the source party is copied to the new party.

Usage 2

The request Party List contains a vector of two Party business objects, and both party IDs must be provided, no other details are required. These two parties are previewed for collapsed even if a better match exists on the database.

Provided with these two party IDs, this transaction will perform the following steps:

• Create new party using externalized rule. Refer to the Configuring External Business Rules section of the developer documentation for details.
• Align all the child object collections across the three parties to ensure that the child objects with the same business keys appear at the same index for each party.

If two party IDs and target party definition is supplied in the request, this transaction will perform the following steps:

• Create new party using externalized rule. Refer to the Configuring External Business Rules section of the developer documentation for details.
• The target party (new party) defined in the request is ignored.
• Warning message generated alerting the user that the target party (new party) is ignored.
• Align all the child object collections across the three parties to ensure that the child objects with the same business keys appear at the same index for each party.

This transaction does not collapse or inactivate the parties supplied in the preview collapse request. The new party is not added to InfoSphere MDM.

<TCRMTxObject> TCRMPartyListBObj

<TCRMObject> TCRMPartyListBObj