Introduction 

Customer journey often cuts across multiple applications. It is most often needed to have the ability to exchange relevant data and even have dependencies among the applications involved.  

In this article, we will explore the possibility of how different cases across different applications can be configured to be able to exchange data and be able to even have dependency logic defined over them. 

Use Case 

U+ Financial Services, a hypothetical organization, has a need to perform a KYC for all customers taking a new product/offering.  

Let us consider the Pega applications in U+ Financial Services organization as follows–  

• U+ KYC 

• U+ Loan Management 

• U+ Retail Banking 

• U+ Commercial Banking,  

• Etc. 

In this situation, there is a need to establish dependency between U+ Loan Management application and U+ KYC application. Whenever a new Loan Application is created, a related KYC must be created. Loan application should not proceed without the completion of KYC.  

Design approach 

The above use case can be depicted and implemented in a simple three-step process –  

1. Intimate KYC to create a related case based on data from Loan Application 

2. Loan Application to wait for KYC to complete 

3. KYC to publish its status to Loan Application 

4. Loan Application to proceed its execution after KYC is resolved-completed 

As part of the design, let us consider that there will be a Kafka that is available to which the events from both the Loan Management application and KYC application are publishing the events to and also reading the events from. 

The sequence of steps can be depicted as below:  

Note: Data Flows in Pega are scalable pipelines that move data from one or more sources to one or more destinations 

Implementation approach 

Step 1: Create KYC based on data from Loan Application 

U+ Loan Management application is created using Pega Blueprint. Loan Application is a Case Type in this application, configured with real-time data extraction with Kafka channel. Extract rule holds the related configurations to push the updates of Loan Application case to the Kafka stream.  

Below screenshot indicates how such configuration can be provided for Loan Application. As part of the event that gets published, the details of the loan application’s reference identifier (pzInsKey) also gets published. 

Note: Real-time data extraction is supported only for Case and Data objects that are persisted into Pega database only! Such capability is not available in Infinity’24 for those objects that are not stored in Pega database! 

Now, lets consume the data from Kafka and create the KYC in the U+ KYC application. Below is how the related configurations can be considered.  

The Data Flow in KYC application is configured to identify those events for which KYC case needs to be created. The rule ‘Loan application event processing’ depicted above has the step titled ‘Process Loan Application message’. It is in this activity the case creation of KYC is implemented. 

As events from Loan Application are received, KYC case is created using the data obtained from the related event. 

Step 2: Loan Application to wait for KYC to complete 

Introduce a WAIT in the Loan Application Case Type, and configure it to wait for KYC case to be completed. 

In this scenario, WAIT is configured on a date-time field within the Loan Application, such that if the related KYC case is not completed in three business days (information received as event from KYC application), then the Loan Application is considered as reject.  

The application logic to move the Loan Application further based on the updates from KYC will be explained in the next section.  

Step 3: KYC to publish its status to Loan Application 

U+ KYC will be publishing the updates happening on the KYC case. Real-time data extraction capability will be leveraged to publish the changes into the Kafka, similar to how Loan Application was configured. 

As part of the event that is getting published, the reference identifier (pzInsKey) of the loan application case will also be published. 

Step 4: Loan Application to proceed its execution after KYC is resolved-completed 

U+ Loan Management application consumes the KYC updates using Data Flow. The Data Flow is configured to run a procedural logic, ie Process KYC Updates (Activity) which processes the Loan Application case based on the KYC status received through the Kafka. Among the events published, only the resolved-completed events will be considered. As the events also have the Loan Application reference identifier (pzInsKey), the activity implemented will exactly know the case instance that it need to update.  

With such update considered through the activity, the WAIT condition can be resolved and the Loan Application case will proceed with its execution as defined in its definition 

Note: As Loan Management application receives the updates from KYC cases, it is possible to ensure that the KYC info maintained in the Loan Application cases can also be kept updated.