comparativePreviewCollapseMultipleParties

Description
This transaction can be used to preview the source party and multiple suspect parties along with the new, surviving collapsed party. The preview aligns all child business object collections. This is a nonpersistent transaction; therefore, it does not collapse or inactivate the two suspect parties, nor add the new party to InfoSphere® MDM.
Web Services
Operation name: comparativePreviewCollapseMultipleParties
Service name: PartyService
Example
Usage 1
The Data Steward selects a party and finds A1 match suspects in the database. The new party is created based on survivorship rules. Prior to collapsing the parties and adding the new party to the database, the Data Steward previews the party details aligned side-by-side.
Usage 2
The Data Steward provides multiple parties that are suspects of each other. The new party is created based on survivorship rules. Prior to collapsing the parties and adding the new party to the database, the Data Steward previews the party details aligned side-by-side.
Usage information
InfoSphere MDM provides a number of transactions and processes to manage the integrity of a single correct version of a party.

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

Preconditions
Given source party must exist.

Collapsing parties (if provided) must exist and be a suspects of the given source party.

Mandatory input
  • Given source PartyId
Inquiry levels
Not applicable
Filter values
Not applicable
Transaction behavior
Usage 1
The request Party List contains a vector of one Party business object. The Party ID must be provided, but no other details are required.

When provided with the Party ID, this transaction performs the following steps:

  • Reads the suspect table and finds all suspects of the provided party using an externalized rule (FindAllSuspectMatchRules.java).
  • Creates a new party using an externalized rule of data survivorship (CollapseMultiplePartiesRule.java).
  • Aligns all the child object collections across the 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 FindAllSuspectMatchRules.java will return all A1 matches found, or return an error if no A1 match is found. The maximum number of A1 matches returned from this rule is configurable in the Configuration and Management component. If the number of A1 matches found is higher than the number set in the Configuration and Management component, the transaction sorts the A1 matches by match score (highest first), and then returns only the set number of A1 match records.

The default implementation of the externalized rule of data survivorship navigates through all data associated with the source party and A1 match parties, and copies all unique data (based on business keys) to the new party. If common data is found in the source and suspect parties, then the business object with the latest Last Update Date (LUD) is copied to the new party. If the LUD is the same for A1 match 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 multiple Party business objects, and party IDs must be provided for all listed parties. No other details are required. All of the listed parties are previewed for collapse even if a better match exists in the database.
When provided with these party IDs, this transaction performs the following steps:
  • Creates a new party using an externalized rule of data survivorship (CollapseMultiplePartiesRule.java).
  • Aligns all the child object collections across the parties to ensure that the child objects with the same business keys appear at the same index for each party.
If multiple Party IDs and target party definitions are supplied in the request, this transaction performs the following steps:
  • Creates a new party using an externalized rule of data survivorship (CollapseMultiplePartiesRule.java).
  • Ignores the target party (new party) defined in the request.
  • Generates a warning message alerting the user that the target party (new party) is ignored.
  • Aligns all the child object collections across the 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.

Request message
<TCRMTxType> comparativePreviewCollapseMultipleParties

<TCRMTxObject> TCRMConsolidatedPartyBObj

<TCRMObject> TCRMConsolidatedPartyBObj

with the mandatory business object: and with optional business objects (if multiple collapsing parties are provided):
  • TCRMPartyBObj
Response objects
TCRMConsolidatedPartyBObj
Special note
Not applicable