Design pattern for integration data mapping

From PegaWiki
MapToEntityWrapper and MapFromEntityWrapper design pattern for integration data mapping. / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Design pattern for integration data mapping

Description This article explains a unique design pattern for data mapping by comparing it with traditional approach
Version as of 8.1
Application Pega Platform
Capability/Industry Area Data Integration

This article explains the traditional way of a mapping integration data to and from a work object. It describes a unique design pattern that solves your problems in a traditional way and also helps you understand how the design pattern improves readability, maintenance, and extensibility.

Traditional approach

Consider the following clipboard page structure for data mapping:

  • Work object = Claim. RenderingProvider
  • Integration class = claim. renderingProvider

To map provider-related properties, use a data transform rule for mapping:

  • In this example, the data transform is called MapToProviderData (core rule).

To provide extensions for the implementation layer, include the following rules. These rules are explicitly created and configured inside the MapToProviderData core rule at the beginning and ending of it:

  • MapToProviderDataPre
  • MapToProviderDataPost

With this approach, you explicitly create 3 rules: core, pre, and post rules. The core rule is used for mapping Pega-provided properties, and pre and post extension rules facilitate customers to extend the mapping without overriding the core rule.

The main drawback with this traditional approach is the number of rules created. You create pre and post rules because you assume that the customer needs them and increase the code base rule count for each entity you are mapping, such as.claim.renderingprovider, in this case.

The following approach avoids this drawback. It provides a more elegant solution to configure the mapping rules without creating extension rules explicitly, but still provides an option to configure extension rules and call them if available.

To start with this approach, you need an @baseclass data transform rule MapToEntityWrapper/MapFromEntityWrapper.

About the MapToEntityWrapper/MapFromEntityWrapper pattern

MapToEntityWrapper/MapFromEntityWrapper is a simple data transform rule with the following configuration, which acts like a controller:

  1. PreMapTo/FromEntity_EXT.
  2. MapTo/FromEntity
  3. PostMapTo/FromEntity_EXT

The calling order is depicted in the following flow chart.

MapTo/FromEntityWrapper configuration
MapTo/FromEntityWrapper configuration

Once the depicted skeleton is in place and all the rules in each step are created in @baseclass as stubs, you can use this wrapper data transform to call and override the MapTo/FromEntity data transform into the respective mapping classes or entity.

How the configuration works

This configuration uses a dynamic polymorphism concept to determine the right implementation invocation for the MapTo/FromEntity data transform during run time. It invokes the respective class MapTo/FromEntity data transform based on page context.


Call the MapTo/FromEntityWrapper rule with the appropriate page context so that @baseclass. MapTo/FromEntityWrapper is invoked first. Pega Platform uses dynamic polymorphism to identify the right rule to call based on the page context in the calling step that is defined in the wrapper data transform.

With this setup, you still need the integration page for mapping. You must pass the integration page as a parameter and avoid using named pages in order to be more dynamic, as shown in the following example:

Sample code to set integration page parameter:

param.IntegrationPage = @Utilities.pxGetStepPageReference()

The following example shows how the holistic configuration looks with the same clipboard page structure described in the Traditional approach section.

Clipboard page structure:

  • Claim. RenderingProvider for Work Object
  • claim. renderingProvider for Integration class

Integration to Work class mapping


Map To Entity Wrapper
Map To Entity Wrapper

Usage example:

Map To Entity Wrapper usage
Map To Entity Wrapper usage

Work to Integration class mapping


Map From Entity Wrapper
Map From Entity Wrapper

Usage example:

Map From Entity Wrapper usage
Map From Entity Wrapper usage

With the baseclass version of MapToEntityWrapper, MapFromEntityWrapper, it will allow any integration class to and from the work object mappings to call them and follow this pattern.

Advantages of using this pattern

  • You do not have to create extension points for each mapping class explicitly, as this pattern helps call them dynamically if available. If not, the default baseclass stub extension points are used. The implementation layer can create them on demand instead of a built-on application creating the extension rules unnecessarily.
  • Every class has the MapTo/FromEntity, which makes it easy to recognize mapping data transforms.

Note: If multiple input channels exist with different input formats, you can append _XML or _JSON or _EDI to clearly distinguish between channel and format mapping rules.