​

In a global financial institution, a wide range of events can occur from many different internal and external sources. A financial institution must be able to 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. Requiring manual checks on every change can delay or suspend revenue generation for the financial institution’s customers and incur high operational costs. With event-driven architecture, financial institutions can define and configure their business events to automate the process of handling them.

Pega Foundation for Financial Services’ event-driven architecture is based on Pega Platform Queue Manager architecture. This helps increase performance, provide multithreading, and track event history.

The event handling architecture is extended in Pega Foundation for Financial Services, so it can be reused across other financial services applications such as Pega Client Lifecycle Management for Financial Services and KYC. The architecture has some additional features such as workload anticipation, rescheduling capabilities, and the ability to define event types and processing methods.

The following image shows Asynchronous Pega Foundation for Financial Services agent architecture built on the Pega Platform Queue Manager architecture.

The Pega Platform queue management architecture is extended with the following additional components:

• The System-Queue-FSEvents class, inherited from System-Queue-. This enables separate tracking and management of items created using the event-driven architecture.
• An agent activity to process events from the System-Queue-FSEvents class. The agent is defined at the application level (PegaCLMFS). The activity of the agent is defined at the PegaFS level so that applications can reuse the agent.
• The CreateEvent activity. This enables applications to generate new events and route them to the appropriate receivers through the new system queue.

Events

System-Queue-FSEvents

Events are stored in the System-Queue-FSEvents class.

Events are temporarily stored (between creation and processing) in the database table fsf_events_queue.

Event types

The details of the event types are stored in the MapFSEvents map value rule. This rule contains the event codes for the various event types that are supported by the application. The application contains the following events.

All these events are currently in used by Pega Client Lifecycle Management and KYC to manage different Customer Review scenarios (see Customer Review).

If you create a new event, the event should be added to this table so that the system can use it during event creation to add a time stamp to the items routed to the event queue and the processor can use the appropriate handler.

Creation of events

The CreateEvent activity is used by the event detection modules to create events. Below are the main steps of the activity:

1. The activity determines if the event is already queued in the event table by calling the QueuedCustomerDetails report definition, which looks for events in the table with the same CustomerID and event type. If an event for the customer already exists in the queue event table, the activity skips creating a new event with duplicate information.
2. The activity calls the CheckPendingCasesOnEvent extension activity to determine if there are any pending cases that were created for a customer for a similar event. If there are existing events, the Param.CaseExists parameter will mark them as existing and the CreateEvent activity will discard the event.
3. The activity creates a new page for the System-Queue-FSEvents class and uses it to queue the event, setting the parameters on the clipboard. The activity initiates the queue operation by calling Queue-For-Agent on the new page.

When an event is created, the following attributes are added, in addition to the base set of properties listed for System-Queue-FSEvents.

Below are some important rules related to the implementation of CreateEvent.

Event processing

The FSEventQueueConsumer agent controls the reception and processing of events. The agent runs periodically and triggers the FSIFAgentProcess activity. Each Financial Services application needs to create their own agent.

the agent invokes the appropriate activity to handle the different types of events by using the event type and context as input and the FSIFEventDrivenProcess decision table to decide which activity rule processes the specific type of event.

When a new event type is created, the FSIFEventDrivenProcess decision table must be updated with the specific activity to trigger the appropriate action for handling the new event type. The handler activities should apply to System-Queue-FSEvents class.

Configuring and extending this functionality

Overview

 The main levels of configuration or extensibility are listed as follows:

• Configuration of agents, map values, and dynamic system settings (DSS)
• Extension of core assets, such as activities and report definitions, to modify the business logic

For more information about extending this feature, see the Implementation Guide for the Financial Services application that you are implementing.

Configuration of Agents, Map values and DSS

Agents

The frequency of the following agents should be reviewed in a customer implementation:

• FSEventQueueConsumer: Use this agent to identify events. This is a standard agent that runs periodically and triggers an activity to run the FSIFAgentProcess agent, which calls the appropriate action.

Map values

The following map values should be reviewed in a customer implementation:

• AgentOperatorId: The operator for the event agent that uses the EventDrivenAgent operator for all types of events. You can use this map value to configure EventDrivenAgent to run different operators for various events.
• MapFSEvents: Map value to hold the details of events associated with the application. Several event codes can be configured for various events.

Decision table

The following decision table should be reviewed in a customer implementation:

• FSIFEventDrivenProcess: Returns the appropriate activity based on the event type and event context. If required, update this decision table with additional activities that trigger the appropriate actions. By default, the type and context trigger the CreateCustomerReviewCase activity, but you can change the type and context to trigger a different activity. These activities are stored in the System-Queue-FSEvents class.

Extension of rules to modify the business logic

CheckPendingCasesOnEvent

This activity checks whether any pending work objects exist for the given customer and event type. If a work object already exists for the customer, a new event is not created. Consuming applications can pass the required event type and set criteria for determining the existence of duplicate cases.

Using queue-processors instead of agents

The Pega FS Event Driven Architecture has been enhanced in Pega Foundation for Financial Service v8.8 to channel the processing of events through queue-processors instead of agents, something that provides a significant leap in terms of processing capacity and reliability (see Using job schedulers and queue processors instead of agents). All the infrastructure defined in this document is still valid and in use (i.e., the System-Queue-FSEvents class, the CreateEvent activity, the map values and decision tables used for configuration and routing, settings, etc.) except the agent FSEventQueueConsumer, which has been replaced by a queue processor of a same name.

It is important to note that this functionality will become active as soon as Pega Foundation for Financial Service v8.8 is installed. No changes at the consumer applications are expected though - the system ensures that events that were previously queued are processed using the legacy agents and queue the newly created ones through queue-processors.

Infrastructural changes

In order to support the processing of events through queue processors, some changes have been done in the underlying infrastructure.

When the module is configured to work using legacy agents, the events created using CreateEvent are stored as instances of the custom class System-Queue-FSEvents. The platform, which periodically scans the database table associated to that class, detects the presence of the events and route them to the FSEventQueueConsumer standard agent, which in turn invokes to the FSIFAgentProcess activity.

When the module is configured to work using queue-processors, the events created using CreateEvent are temporarily created as instances of System-Queue-FSEvents, but then wrapped and stored as instances of the new class System-Queue-FSEventsByPass. The new instances are then queue for the dedicated queue-processor FSEventQueueConsumer, which upon reception of events execute the activity FSIFAgentProcessByPass. This activity executes the original FSIFAgentProcess as it is done when configured to work with agents and remove the entry from the System-Queue-FSEventsByPass class.

It is important to note that these changes enable the use of queue-processors without any change from the consumer applications. Applications should still use the CreateEvent activity to push events and refer to their processes from FSIFAgentProcess.

Configuration

Activation

The activation of functionality is managed through the following Dynamic System Setting:

• Pega FS fs/BackgroundProcessActiveGeneration: When this setting is set to 2, the system uses queue-processors. If it has a different value or the setting is not present, then it uses legacy agents.

Queue-processor

The new functionality makes use of the following queue-processor:

• PegaFS FSEventQueueConsumer: by default, the queue processor is configured for immediate execution and to use 5 threads. Review and change this configuration according to your needs.

​