getPartyByEntityId

The transaction uses a virtual MDM entity ID to return information for a given party.

Description
This inquiry transaction uses a specified virtual MDM entity ID to return party details for a given party. Depending on whether or not the entity has been fully persisted in a hybrid MDM implementation, the transaction returns either the persisted party data or the configured composite view of the party from virtual MDM.
Web Services
Operation name: getPartyByEntityId
Service name: getPartyByEntityId
Example
Retrieve person or organization party details using the unique entity ID assigned by virtual MDM.
Retrieve the configured composite view of the entity from virtual MDM since only the cross reference keys for the entity have been persisted.
Retrieve the persisted view of the entity from physical MDM since the entity has been fully persisted.
Usage information
The required inputs for this transaction are:
  • a virtual MDM entity identifier, EntityId
  • an EntityType
  • an inquiry level
When using the default Party model in virtual MDM, the values for EntityType are:
  • 'mdmper' for a person entity
  • 'mdmorg' for an organization entity

The inquiry level controls the amount of information returned for the party being queried.

Preconditions
Hybrid MDM mode must be enabled.
Mandatory input
  • EntityId
  • EntityType
  • InquiryLevel
Inquiry levels
PartyInquiryLevel:
  • Level 0 - returns Party data including names, identifications, party privacy preferences, line of business relationships, and either personal data, if a Person, or organizational data, if an Organization.
  • Level 1 - returns level 0 data plus all party addresses and contact methods.
  • Level 2 - returns level 1 data plus all party relationship data.
  • Level 3 - returns level 2 data plus all party bank account, party charge card, and income source data.
  • Level 4 - returns level 3 data plus all party value data.
Tip: The default inquiry levels are configured for use with physical MDM and are based on the data model for physical MDM. For hybrid MDM implementations, special inquiry level 98 is available for use.
Filter values
Not applicable
Transaction behavior

The transaction uses both entity link status and entity status to determine whether to retrieve the party details from physical MDM or from virtual MDM. If the entity is fully persisted, then the persisted party in physical MDM is returned. If only the cross-reference keys of the entity are persisted (entity registration), or if the entity status indicates that the last update of a fully persisted entity has failed, then the configured composite view of the entity from virtual MDM is returned. Supplemental attributes added to the entity in physical MDM are also returned if the attributes are included in the inquiry level specified.

Table 1. Summary of where Party details are retrieved from in a Hybrid MDM solution
Entity Link Status: Entity Status: Party details are retrieved from:
1 (entity registration) <null> Virtual MDM
1 (entity registration) 1 (Persisted entity is up-to-date) Virtual MDM
1 (entity registration) 2 (Last entity update from virtual MDM failed) Virtual MDM
2 (full persistence) <null> Physical MDM
2 (full persistence) 1 (Persisted entity is up-to-date) or <null> Physical MDM
2 (full persistence) 2 (Last entity update from virtual MDM failed) Virtual MDM

Supplemental attributes added to the entity in physical MDM are also returned if the attributes are included in the inquiry level specified.

Request message
<InquiryType> PartyByEntityIdRequestBObj

<tcrmParam name= "EntityId">

<tcrmParam name= "EntityType">

<tcrmParam name= "InquiryLevel">

Response objects
Party details, depending on the value of InquiryLevel.
Special notes
  • The entity in the request has to be already persisted in hybrid MDM.
  • In a hybrid MDM implementation, if InquireAsOfDate is provided in the request for a historical inquiry, then any historical records returned by the transaction apply only to the party records persisted in physical MDM.