Accounting for supplemental attributes
Supplemental attributes are any attributes that you want to maintain in addition to the information stored for the persisted entity. These attributes are stored and managed in physical MDM only.
About this task
After you persist data from virtual MDM to physical MDM, you might consider creating supplemental attributes to augment your party. For example, you might need to add information about party privacy preferences for a persisted party if this information does not reside in any virtual MDM source systems.
When defining the hybrid MDM model, a mapping is created to define the attributes that will be managed in virtual MDM and potentially persisted in physical MDM. Any attributes contained in this mapping cannot be treated as supplemental attributes. Supplemental attributes are stored and managed in physical MDM only. If there is an attribute in the mapping that is not managed by a virtual MDM source system, consider removing this from the mapping so that it can be centrally managed as a supplemental attribute in physical MDM.
Physical MDM business objects that are contained in the mapping from virtual MDM to physical MDM are referred to as mapped objects.
Physical MDM element names that are contained in the mapping from virtual MDM to physical MDM are referred to as mapped elements.
Physical MDM code types that are mapped to virtual MDM attribute codes are referred to as mapped code types. For example, PERLEGALNAME corresponds to TCRMPersonNameBObj.NameUsageType =1.
Please refer to links at the end of this topic for complete lists of mapped objects, element names, and code types based on the default mapping.
| Business object of supplemental attributes | Add transactions | Update transactions |
|---|---|---|
| TCRMPartyPrivPrefBObj | Yes | Yes |
| TCRMAlertBObj | Yes | Yes |
| TCRMPersonNameBObj | ||
| - mapped NameUsageTypes (1, 2, 3, 4, 5, 6, 7, 8) | No | You can only update non-mapped elements, for example, SourceIdentifierType. |
| - non-mapped NameUsageTypes (e.g. NameUsageType = 99) | Yes | Yes |
| TCRMOrganizationNameBObj | ||
| - mapped NameUsageTypes (1, 2, 3) | No | You can only update non-mapped elements, for example, SourceIdentifierType. |
| - non-mapped NameUsageTypes | Yes | Yes |
| TCRMPartyAddressBObj | ||
| - mapped AddressUsageTypes (1, 2, 3, 4, 5, 6, 7) | No | You can only update non-mapped elements, for example, ResidenceType. |
| - non-mapped AddressUsageTypes | Yes | Yes |
| TCRMPartyContactMethodBObj | ||
| - mapped ContactMethodUsageTypes (1, 2, 3, 4, 5, 6, 7, 8) | No | You can only update non-mapped elements, for example, UndeliveredReasonType. |
| - non-mapped ContactMethodUsageTypes | Yes | Yes |
| TCRMPartyIdentificationBObj | ||
| - mapped IdentificationTypes (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12) | No | You can only update non-mapped elements, for example, SourceIdentifierType. |
| - non-mapped IdentificationTypes | Yes | Yes |
| TCRMPartyBankAccountBObj | ||
| - mapped AccountTypes (1, 2, 3, 4, 5, 6, 7) | No | You can only update non-mapped elements, for example, DepositorName. |
| - non-mapped AccountTypes | Yes | Yes |
| TCRMPartyChargeCardBObj | ||
| - mapped CardTypes (1, 2, 3, 4) | No | You can only update non-mapped elements, for example, OnCardName. |
| - non-mapped CardTypes | Yes | Yes |
| TCRMPersonBObj | No | You can only update non-mapped elements, for example, NumberOfChildren. |
| TCRMOrganizationBObj | No | You can only update non-mapped elements, for example, DisplayName. |
All the objects listed in this table are supported for deletion via the persistEntity API. However, if you are adding other business objects as supplemental attributes, you need to customize the delete rule to delete parties with other supplemental attributes. You can do so by augmenting the external rules related to delete capability. For more information, see the link at the end of this topic about deleting party information.
You can create supplemental attributes regardless of whether the virtual MDM entity was persisted in full or entity registration mode.
Party data, including the supplemental attributes, can be retrieved using hybrid MDM enabled inquiry transactions (getParty, getPerson, getOrganization, getPartyByEntityId, and getPartyByAdminSysKey) according to the inquiry level. A supplemental attribute is returned only if it is included in the inquiry level.
When a persisted entity is moved or deleted using persistEntity, the changes to the business objects are published to the broadcast queue using the Data Change Broadcast mechanism and implemented using the DeleteHybridPartyBroadcast behavior extension. Broadcast messages are in xml format that is compliant with the broadcast.xsd file. For example, if a singleton entity that had supplemental attributes is moved to another entity, the supplemental attributes are not automatically moved to the new entity. To implement that behavior, you can make the appropriate changes based on the information in the message published to the broadcast queue. For more information, see the link at the end of this topic about understanding Data Change Broadcast.