Design patterns for Integration Designer using App Studio

From PegaWiki
Design patterns for Integration designer using app studio / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Design patterns for Integration Designer using App Studio

Description Design patterns for Integration Designer using App Studio
Version as of 8.6
Application Pega Platform
Capability/Industry Area Data Integration

Citizen developers can easily generate and integrate their application with external systems through the Integration Designer in App Studio. This article outlines the design patterns and best practices in building and maintaining the integrations from App Studio.

Design patterns

In the following enterprise class structure, there are 5 integration layer design patterns. Based on the applicability of the reusability requirement and the business value that the external service is offering, you might follow one of the following patterns.

1.      Build the artifacts at top-level integration layer (Pega-provided [INT-])

2.      Build the artifacts at enterprise integration layer (Org-Int-)

3.      Build the artifacts at framework integration layer (e.g., Org-FW-Int-)

4.      Build the artifacts at application integration layer (Org-App-Int-)

5.      Build the artifacts at divisional integration layer (Org-Div-Int-)


Build the integration layer using the Integration Designer in App Studio following the steps in the wizard. The wizard supports REST integrations with the OpenAPI mime type application/json and direct Endpoint URL[MD1] connections that allow GET, POST, PUT, and PATCH methods.


Integrating systems from App Studio makes every step of the application development journey easy for IT and businesses. With Integration Designer, you can easily visualize, map, and manage all your data sources and integrations in one place with a low code, drag-and-drop approach. This section describes the advantages of authoring the integrations in App Studio.

1.      The Integration Designer wizard offers a simple, guided approach in authoring the integration artifacts.

2.      This wizard in App Studio supports authoring integrations from an OpenAPI specification.

3.      Citizen users can easily use the visual mapper to form the relationship between external systems and the Pega application.

4.      The transformation of data via request and response is auto-generated using JSON transforms, which helps accelerate processing.

5.      Using the property qualifier pzExternalName if the JSON element definition starts with an unsupported property naming convention is not required, which helps accelerate processing.

6.      For methods POST and PUT, the Integration Designer creates savable data pages with artifacts generated in the DATA layer, not the INT layer. The INT layer is the general pattern with the Dev Studio – Rest Integration wizard and Pega Platform versions prior to 8.6.

7.      The Authentication and Endpoint URL will automatically leverage Application settings ensuring the "in the model" approach, which helps during the API version update.

8.      The integration landscape provides quick insights into how the system is integrated with other systems.

Integration landscape viewer

9.      Replacing or updating the source systems and APIs from App Studio is easy.

10.    The system simulation configurations can clearly be displayed and enabled easily.

Best practices

1.      Each integration connector must be built in a separate ruleset for easy maintenance and independent deployment. The appropriate layer should be chosen based on reusability needs within the enterprise.

2.      The layer must have either pattern or direct inheritance from the Pega-provided top-level integration layer.

3.      You should use class names judiciously (base class name) as there is an upper limit of 56 characters on the overall class name that is generated.

4.      Leave the auto-generated cryptic class names as-is, if the rule name exceeds the character limit of 56. This assures reuse of the existing classes and artifacts during the service update. Se the following image for an example.

auto-generated cryptic class names
auto-generated cryptic class names

5.      Make sure to subclass the Integration layer by API version if you need to support API versioning.

Example: MyCo-Int-Customer-V1-GetCustomerInformation & MyCo-Int-Customer-V2-GetCustomerInformation

6.      Define the appropriate INT layer at application record to build the artifacts using the Integration Designer in App Studio.

7.      Create, update, and manage the artifacts from App Studio. The property pzIsAutoGenerated in the rule XML form must always have the value as TRUE.

8.      Use Application settings to dynamically refer the endpoint URL based on the production level.

9.      During an update, make sure you update the service. Do not replace the service. Do not delete or withdraw the rules to ensure backward compatibility. Instead, mark them as deprecated.


10.  Manage the CRUD operations on the auto-generated request and response JSON data transforms from App Studio using the visual mapper. For further details, check the References section below.