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. Rather than using the default inquiry levels, consider creating custom inquiry levels that account for how the person or organization entities are defined within the shared virtual MDM and physical MDM data models.
- 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.
- 0 includes:
- 1 includes level 0 plus:
- TCRMPartyAddressBObj list, each with associated TCRMAddressBObj
- TCRMPartyContactMethodBObj list, each with associated TCRMContactMethodBObj
- 2 returns the same data as level 1
- 3 includes level 2 plus:
- TCRMPartyBankAccountBObj list
- TCRMPartyChargeCardBObj list
- TCRMIncomeSourceBObj list
- 4 includes level 3 plus TCRMPartyValueBObj
- 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.