Design pattern for integration data mapping
Design pattern for integration data mapping
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:
- PreMapTo/FromEntity_EXT.
- MapTo/FromEntity
- PostMapTo/FromEntity_EXT
The calling order is depicted in the following flow chart.
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.
Implementation
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
MapToEntityWrapper:
Usage example:
Work to Integration class mapping
MapFromEntityWrapper:
Usage example:
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.