Customer journeys often cut across multiple applications. These journeys require that the involved applications can exchange relevant data and even have dependencies among them.
In this article, we will explore how you can configure different Cases across different applications to exchange data and even define dependency logic over them.
Use case
Suppose that U+ Financial Services wants to perform a KYC for all customers who will receive a new product or offering.
Consider the following Pega applications in U+ Financial Services organization, available across multiple deployments:
- U+ KYC
- U+ Loan Management
- U+ Retail Banking
- U+ Commercial Banking
In this situation, there is a need to establish a dependency between the U+ Loan Management application and the U+ KYC application. Whenever a new Loan Application Case is created, a related KYC Case must be created. A loan application should not proceed without the completion of KYC.
Design approach
The use case can undergo implementation through a simple four-step process:
- Create a KYC Case based on data from the Loan Application Case.
- The Loan Application Case waits for the KYC Case to complete.
- The KYC Case publishes its status to the Loan Application Case.
- The Loan Application Case runs after the KYC Case is Resolved-Completed.
As part of the design, a Kafka system will be available. Both the Loan Management application and KYC application will publish the events to this Kafka system and also read the events from it.
The following figure depicts the sequence of steps:
Note: Data Flows in Pega Platform™ are scalable pipelines that move data from one or more sources to one or more destinations.
Implementation approach
Create a KYC Case based on data from the Loan Application Case
U+ Loan Management application is created using Pega GenAI Blueprint™. Loan Application is a Case Type in this application, configured with real-time data extraction with a Kafka channel. The extract Rule holds the related configurations to push the updates of the Loan Application Case to the Kafka stream.
The following figure indicates how such a configuration can work for the Loan Application Case. As part of the event that gets published, the details of the loan application’s reference identifier (pzInsKey) are also published.
Now, let’s consume the data from Kafka and create the KYC in the U+ KYC application. The following figure shows how you can consider the related configurations:
The configuration of the Data Flow in the KYC application identifies the events that require the creation of the KYC Case. The Loan Application event processing Rule depicted in the previous figure contains the Process Loan Application message Step. It is during this activity that the Case creation of KYC is implemented.
As the system receives events from the Loan Application, the KYC Case is created using the data obtained from the related event.
Loan Application Case waits for the KYC Case to complete
Introduce a Wait Step in the Loan Application Case Type, and then configure it to wait for the completion of the KYC Case.
In this scenario, the Wait Step is configured on a date-time field in the Loan Application Case so that if the related KYC Case is not completed in three business days (information received as an event from the KYC application), then the Loan Application is considered rejected.
The next section will explain the application logic to move the Loan Application further based on the updates from KYC.
KYC Case publishes its status to the Loan Application Case
U+ KYC will publish the updates that occur in the KYC Case. The company will apply the real-time data extraction feature to publish the changes to Kafka, similar to the configuration of the Loan Application Case.
As part of the event that is getting published, the system will also publish the reference identifier (pzInsKey) of the Loan Application Case.
Loan Application Case runs after the KYC Case is Resolved-Completed
The U+ Loan Management application consumes the KYC updates by using a Data Flow. The configuration of the Data Flow runs a procedural logic, for example, Process KYC Updates (activity), which processes the Loan Application Case based on the KYC status received from Kafka. The system will consider only the Resolved-Completed events among the published events. Because the events also have the Loan Application reference identifier (pzInsKey), the implemented activity will know exactly the Case instance that it must update.
With such an update considered through the activity, the system can resolve the Wait Step condition, and the Loan Application Case will proceed with its run as defined.
Summary
Now that you've got a glimpse into configuring data exchange between cases across applications in Pega Infinity 24.2, it's time to put it into action! With Kafka handling event exchanges, seamless communication between your applications is within reach. Ready to dive in? Try it out and see how it enhances your workflows!
Related Resources
- Business Intelligence Exchange
- Learn about Extract rules
- Learn about Data flows
- Connecting to Kafka through Data Set
Don't Forget
- JOIN THE CONVERSATION on Support Center
- FOLLOW @PegaDeveloper on Twitter