Understanding the Party domain mapping

In the MDM Workbench, you will use the IBM® Graphical Data Mapper to manage the mapping between virtual MDM attributes and physical MDM attributes.

The graphical data map (.map files) graphically represent your source (virtual MDM) and target (physical MDM) data structures. You can find the .map files in the MDMHybridMapping project, which you created as part of your hybrid MDM configuration. In the Graphical Data Mapper, use drag actions to make connections, select transforms, and build logic to transform your attribute data structures without programming.

When you open the VirtualPerson.map file or the VirtualOrganization.map file in the Graphical Data Mapper, you might notice that some attributes are linked by lines with boxes labeled Move while others are linked with boxes labeled Custom XSLT.

Attribute associations that are labeled Move indicate an association where the value of the virtual MDM attribute is directly moved to its mapped target physical MDM attribute. The case and formatting of the value being moved is preserved. Most associations are of this type.

Other attributes are linked by lines with boxes labeled Custom XSLT. As you might expect, these associations involve data transformation as part of the mapping. The mappings between attributes involve a physical MDM business object whose type is determined by the code table (for example, TCRMPersonNameBObj.NameUsageType = 1). The mappings leverage a Custom XSLT transcoding template (transcode.xsl) that is provided for data transformation.

An image of the Graphical Data Mapper shows attributes connected by a box that reads Custom XSLT.

An image of an interface for editing the transcode.xsl file.

As an example, the default mapping for Person defines a virtual MDM attribute called PERNAME. The PERNAME attribute is mapped to the TCRMPersonNameBObj business object in physical MDM. The PERNAME attribute also has an attrCode field which gets mapped to the corresponding entry in the name usage type code table in physical MDM. The transcoding function, or Custom XSLT function, that is defined for this association reads the attrCode value and looks up the corresponding codetype value required by physical MDM. The transcoding function uses two parameters: attr (whose value is attrCode) and transcodePairs (whose value is LOOKUP_PERNAME). LOOKUP_PERNAME itself is a variable you define as part of the mapping. It contains a set of key-value pairs of the form PERLEGALNAME=1, PERBUSNAME=2, PERNICKNAME=3 and so on. When persisting an entity, this transcoding function simply picks up the corresponding code type for a virtual MDM attribute from the defined LOOKUP_PERNAME variable in the mapping.

Note: As with any physical MDM transaction, if invalid code type or value information is used, it fails to ensure that the appropriate code table types and values are defined in the relevant physical MDM code tables.

When physical MDM code tables need to be considered for attribute mapping, you can use either the Move function or the Custom XSLT function. Use transcoding for mapping the predefined values for business object subtypes in physical MDM, that is, objects that have usage types such as name usage type, address usage type. Use the Move function when a virtual MDM attribute can hold many different values. When mapping reference data attributes, such as marital status type which may be stored in many different languages use the Move function. Again, note that if the values supplied in these fields do not have associated values in physical MDM code table, the services used to maintain the impacted object fail.

The remaining sections provide more information about the Party domain mappings, how to customize your hybrid mapping to accommodate new attributes, and how to account for the mandatory fields that are typically encountered when choosing to store virtual master data elements centrally in physical MDM.