Design pattern for integration data mapping

From PegaWiki
MapToEntityWrapper and MapFromEntityWrapper design pattern for integration data mapping. /
Revision as of 11:00, 22 June 2021 by WSBotScript (talk | contribs) (Bot action - changed email parameter value)

(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
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[edit]

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[edit]

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[edit]

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.

Implementation[edit]

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[edit]

MapToEntityWrapper:

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[edit]

MapFromEntityWrapper:

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[edit]

  • 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.