collapseMultipleParties

Description
This transaction collapses multiple suspect parties, marking them inactive and creating a new party based on externalized rules of survivorship.
Web Services
Operation name: collapseMultipleParties
Service name: PartyService
Example
Usage 1
Given a specific party, find all A1 suspect matches on the database and collapse the parties according to survivorship rules.
Usage 2
Given multiple parties, collapse them according to survivorship rules.
Usage 3
Given multiple parties to be collapsed, plus a new party definition, collapse the parties, and create the new party as per the new supplied party definition.
Usage information
IBM® InfoSphere® Master Data Management provides a number of transactions and processes to manage the integrity of a single correct version of a party. The collapseMultipleParties transaction addresses the situation of multiple distinct parties that all represent the same single person or organization.

This situation could result from insufficient or incorrect information on the parties such that IBM InfoSphere Master Data Management could not identify the parties as the same person or organization, or as a result of suspect processing (a configurable option) being turned off when the parties were initially added.

Preconditions
  • Given source party must exist.
  • Collapsing parties (if provided) must exist and are 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, and no other details are required.

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

  • Reads the suspect table and finds all A1 suspects of the provided party using an externalized rule (FindAllSuspectMatchRules.java).
  • Creates a new party using an externalized rule of data survivorship (CollapseMultiplePartiesRule.java).
  • Inactivates parties that were collapsed.
  • Creates suspects for the newly created party.
  • Creates party links between inactivated original source parties and the new target party.

The default implementation of the externalized rule for FindAllSuspectMatchRules.java will return A1 match record(s) found, or return error if no A1 matches 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 that set in the Configuration and Management component, it will sort the A1 matches by match score (highest first), then return only the set number of A1 match records.

The default implementation of the externalized rule of data survivorship will navigate through all data associated with the source party and A1 match parties, and copy all unique data (based on business key) to the new party. If common data is found on 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 all party IDs must be provided. No other details are required. These parties are collapsed even if a better match exists on the database.

When provided with these two party IDs, this transaction performs the following steps:
  • Creates a new party using an externalized rule of data survivorship (CollapseMultiplePartiesRule.java).
  • Inactivates parties that were collapsed.
  • Creates suspects for the newly created party.
  • Creates party links between inactivated original source parties and the new target party.

The default implementation of the externalized rule is as discussed above under Usage 1.

Usage 3

The request Party List contains a vector of multiple Party business objects: source party, given multiple collapsed parties, and one target party. The source party IDs and given multiple collapsed party IDs must be provided and the target party must include all business objects that should be copied to the new party. These parties are collapsed even if a better match exists in the database.

When provided with the Party IDs and target party definition, this transaction performs the following steps:
  • Creates a new party as defined in the request.
  • Inactivates parties that were collapsed.
  • Creates suspects for the newly created party.
  • Creates party links between inactivated original source parties, given multiple collapsed parties and the new target party.
Request message
<TCRMTxType> collapseMultipleParties

<TCRMTxObject> TCRMConsolidatedPartyBObj

<TCRMObject> TCRMConsolidatedPartyBObj

with the mandatory business object: and optional business objects (if multiple collapsing parties are provided):
Response objects
TCRMConsolidatedPartyBObj
Special note
By default, when two or more parties are collapsed in InfoSphere MDM, their corresponding product-party roles survive in the newly created party.