When linking Point A to Point B, integration specialists often use or enforce integration design patterns. From canonical data model patterns and façade design patterns to signaling, routing, and composition patterns, there are hundreds of integration design patterns to choose from.
These integrations of architecture patterns act as a “formula” for connecting data, software, processes, and devices successfully. If it’s to relay events from one PEGA application to another or to ingest PEGA application messages as they become available, each pattern has a particular function.
Often integration experts adopt integration architecture patterns without ever understanding it. More critically, the majority of integration professionals re-use these trends to implement faster, save time and effort, and, as a result, meet company objectives on time.
The issue occurs when reuse is achieved by copy-and-paste — much like taking a paragraph from one text and pasting it into another. When you combine using this “copy-and-paste” process, you end up with a jumble of objects and patterns, none of which are completely reusable.
If you are interested to learn Pega you can enroll for free live demo Pega Online Training
Reusability and integration architecture trends
Assume a company has a standard integration architecture template for implementing security. This canonical pattern applies to the development of a communication or data model that can then be routed into an integration platform (such as an enterprise service bus) and translated to a canonical standard format.
Let’s pretend that an integration expert copies and pastes the canonical template into the next interface or asset if they need it.
This strategy worked with this organization for years, and they had no issues. Three years back, after a new Chief Security Officer (CSO) took over the organization, everything changed. This CSO notices a flaw in the canonical integration architecture pattern and requests that the team fix it.
The integration team at this company, on the other hand, never created a connection between the “copy-and-pasted” integration architecture pattern and the original canonical iteration of that pattern by using a “copy-and-paste” approach to reusability.
Since there is no connection to the original canonical version of the pattern, all PEGA applications or assets that use the “copy-and-pasted integration architecture pattern” will need to be manually modified one by one.
If, on the other hand, any device or asset pointed to the original canonical template pattern (i.e., the paradigm is not copied around the organization), all interfaces must immediately adjust as the original pattern shifted.
Integration style patterns that can be reused
Integration architecture practices occurring in businesses around industries and regions, at the end of the day. The key is to not only use the best form of integration pattern for your use case but also to make sure that reusing a concept isn’t achieved in a “copy-and-paste” way. Integration experts should instead return to the original pattern to reuse it.
Organizations must take a new approach to integration: API-led networking, to further optimize integration architecture. Learn more about API-led networking and how it can help companies reuse integration architecture trends more efficiently.
Patterns of data control
Data access patterns are basic structures for successfully handling data in a Pega PlatformTM through a PEGA application. For use in PEGA applications, the Pega Platform supports three data access patterns. The collection and refreshing of data in a case are influenced by the data access pattern chosen.
Access to data contained in another device or program is provided by the system of record method. The documentation is still present and the PEGA application always applies to the system of record.
Data is copied into the case using the snapshot pattern. Since the program only applies to the replicated data, the data is only valid as of the time it was copied.
The comparison pattern helps a PEGA application to use data without having to apply it to the PEGA application’s data model. The comparison data pattern is often used to populate user interface controls including drop-down lists. The user’s chosen value is copied to the instance.
Pattern tracking system
When you always need to return to the most recent data from an external device or program, use the system of record (SoR) pattern. There is no backup of the data in the scenario. Instead, when the data from the source is requested, the program refers to it.
The SoR pattern guarantees that the details shown in the Pega framework are up to date. When data from the situation is retrieved, for example, if an account holder has a new phone number, the modified number is shown.
Select the Refer to a data page alternative in the Data Access portion of the property record to apply the SoR pattern on a property. The type of property (page or page list) must match the data page’s layout (page or list). On the first reference to the land, a new data page is generated.
The property that belongs to the data page does not store any data. As seen in the clipboard screenshot below, the property only includes a connection to a data file.
refer to the clipboard on the data tab
Using the SoR pattern to reload data
The data reloads according to the refresh technique defined on the data page while using the SoR pattern. The property still refers to the most recent data page update.
A new data page is generated if a data page parameter is changed. After that, the property points to the new page.
A pattern of a snapshot
When you need to copy data to a case at a certain point in time, follow the snapshot pattern. If the request parameters change, the data copied to the case is not recovered from the source again.
When a person makes an insurance claim, for example, the program copies insurance liability details from an external device to the claim. The insurance liability details registered in the case remain unchanged any time it is opened.
Pick the Copy data from a data page alternative in the Data Access portion of the property record to apply the snapshot pattern to a property. The type of property (page or page list) must match the data page’s layout (page or list).
Copy the property from the data tab
The data page is generated and the data is copied to the property the first time the property is referenced. Optional data transformation allows you to choose a data transform for data mapping.
Using the snapshot pattern to reload data
The data is stored in the property as you copy data from a data page. If a parameter varies, the data page is not accessed again. A new data page is generated when the parameter shifts. The data that has been affected is copied to the property and overwrites the current data.
Pattern of reference
To populate UI controls with dynamic data, use the comparison pattern. Only the chosen value is copied to the case’s data model while you use the comparison pattern. You may use the comparison pattern to fill drop-down lists of countries and nations, for example.
Using a data page from a record rather than a property to enforce the comparison pattern. The following example shows how to use values from a data page to populate a drop-down control. When the property is referenced for the first time, the program produces the data page.
The data reloads with the reference pattern according to the refresh technique defined on the Data tab. The control always points to the most recent data page update. You can learn more about design and integration methods through PEGA training.