Data Mapping in EDR

Skip to end of metadata
Go to start of metadata


Mapping data between Provider Objects and a Domain Object.

  • Data Mapping should also be able to reverse, from the Domain Object to the Provider Object.


A clear statement on how data should be mapped will ease the implementation of EDR. This statement will also simplify the transition from basic to advanced mapping strategies.


We recommend using data mapping. Data Mapping is a extension to EDR, not mandatory.


  • Objects dedicated for Mapping
  • XSLT - Using XML and XSL to transform data from one object to the other
  • External tool to perform the mapping.
  • Mapping service (advanced mapping)

We do not recommend that the Service Factory or Repository Controller contains the code to perform the Data Mapping for the following reasons:

  • Cluttering of concerns
  • Harder to let the code evolve as experience with the functionality is gained.
    [Mapping New Object based on two domain objects]
    [Mapping Update with simple rules]
    [Mapping Merge Contact Person]

    Mapping New Object based on two domain objects

    Address from CRM
    Account number from ERP system (eg. SAP)

Merge a contact person that are defined in both systems


Mapping service


  • Handle advanced mappings of datatypes.
  • Handle that one or more sub systems are unavailable for read and update.
  • Decision rules for update.
  • Detect inconsistency in the same data, in different subsystems.
  • Automatically update or report findings of inconsistent data.
  • Single point of entry for all data mappings, regardless of service used.
pattern pattern Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.