Configuring event-driven architecture
As part of the business with customers, many potential events can occur from many different internal and external sources. A financial institution must identify and process a change, such as a customer updating their address or an identification document expiring. Failing to do so can lead to non-compliance and increased risk. Forcing manual checks on every change can delay or suspend revenue generation for the financial institution’s customers and incur high operational costs.
You can use event-driven architecture to define and configure business events. Certain events are processed automatically, while others require manual attention. When an agent rule identifies an event, it immediately triggers the respective validation and decision mechanisms to take appropriate actions.
For example, a financial institution periodically reviews customers. Customer X was onboarded into a financial institution on the 1st of January 2016. Based on the risk profile of the customer and organizational policies, the system sets the next review date to the 1st of January 2018. The system automatically triggers a customer review case on or before 1st January 2018.
You must save the scheduling agents into your application layer in order to use them in an event-driven architecture operation.
- In the header of Dev Studio, expand .
- Filter the Queue Class to PegaCLMFS and save it into your ruleset.
- Stop each agent.
- Click on the name of an agent. The system opens an agent rule that you can copy into your implementation ruleset for changes.
- Review the configuration of the agent (frequency, access group, and so on) and save the changes.
Creating a new event
You can create new events for your financial institution. In this example, the documents provided by the customer during onboarding are set to expire, and the financial institution has to ask the customer to provide the latest documents to adhere to due diligence processes.
For more information about references rules, see Event-driven architecture.
To implement this example, do the following steps:
- Create a new property to store the valid end date of the uploaded document.
For example, call the property validenddate. Place this property on the document collection UI screen. If the documents collected are stored in a content management solution (such as Alfrecsco), ensure that while accessing the customer documents, the validenddate property is also brought up in the journey.
- Create an event code and event type for the document review case and map it in the MapFSEvents map value.
- Create an advanced agent which runs at required intervals.
These intervals are determined by the duration in which the documents are valid. Use the CreateCustomerReviewEvents agent rule as a basis for this rule.
- Create an activity that retrieves the customer profiles whose documents are expired. Link this activity to the advanced agent in step 3, which calls it periodically.
- Create a report definition that retrieves the customers whose documents are about to
expire, per the validenddate rule.
Use the UnqueuedExpiredCustomerProfiles report definition as a basis for this rule. If the documents collected are stored in a content management solution, make sure that, while accessing the customer documents, the validenddate is also brought up in the journey which is required for the report definition.
- Create an activity to check if a case has already been created for customers with documents
that are about to expire.
Use the QueuedCustomerDetails report definition as a basis for this rule.
- Create an activity which creates a document review case and add this activity to the
FSIFEventDrivenProcess decision table.
Use the CreateCustomerScheduleReviewEvents activity rule as a basis for this rule. The FSIFAgentProcess checks the FSIFEventDrivenProcess decision table for the activity to be run for the Document review event type, which creates the document review case.
Previous topic Configuring the Case summary feature Next topic Configuring asynchronous processing