Integration versioning

The development of a Pega application parallel to the development of an Enterprise Service Bus (ESB) or another form of integration to a legacy system is common. The integration data model has its unique internal dependencies. The mapping code depends on the current state of the integration data model for conversion to the business logic data model. Even after an application is placed into production, these internal dependencies might change.

Mapping code acts as an insulator between the business data model, which is subject to change, and the integration data model, which is also subject to change. This structure is also known as loose coupling.

To deal with changes to integration data models, generate the models with new integration base classes such as <Org>-Int-<service,v2, v3>.

Note that the new data model may create code redundancy. This issue is quickly addressed by generating the mapping code into a different ruleset. Over time, when there is no need to return to a previous ruleset, you can remove the ruleset from the application definition. Ideally, you remove the unused ruleset when versioning the application.

Changes to the integration root classes need to be accounted for. Use dynamic class referencing to accommodate those changes. Because data pages support when conditions, you can use those conditions to determine which integration version to use based on the application version. You can also use a Data-Admin-System-Setting value to a data page to accommodate the interface data model change.