Event-driven architecture
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.
Property | Class |
CustomerId | Stores the customer ID, provided by the application generating the event at the time of its creation. |
EventType | Stores a unique identifier of the event type, provided by the application generating the event at the time of creation. |
EventTypeDesc | Stores the event description, which is later moved to a central repository of event types. |
DeadlineTimestamp | Stores the time stamp for the deadline of event execution. |
Detail | Stores an event description provided by the customer. If none is provided, the description of the event is pulled from the EventTypeDesc property. |
OverriddenExecutionTimeStamp | Time stamp of override event execution. |
OverriddenExecutionBy | Operator ID of the operator who has the authority to override the normal event execution. |
OverriddenExecutionDetail | Stores the details about why the event was overridden. |
BlockedBy | Operator ID of the operator who blocked the event from normal execution. |
BlockedTimestamp | Time stamp of the blocking event. |
BlockedDetail | Stores the details about blocking the event from normal execution. For example, the events were blocked because of an external audit. |
Source | Stores the application name where the event has been triggered. The property is passed by this application at the time of creation. |
Target | The property or identifier on which the occurrence of an event is determined (for example Customer Risk). The property is passed by the application generating the event at the time of creation. |
Context | The class in which the target property is defined (for example, Customer master profile). The property is passed by the application generating the event at the time of creation. The property is used to explain the context of the event. |
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.
Event Code | Event Type |
FEV1 | Customer periodic review |
FEV2 | Document expiry |
FEV3 | Relevant related party risk change |
FEV4 | Reference data change |
FEV5 | Customer remediation |
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:
- 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.
- 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.
- 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.
Property | Class |
pyMinimumDateTimeForProcessing | Initial wait until the item is selected by the queue engine for the first execution. 0 represents immediate selection. The item is processed during the next agent execution. |
pyMaxattempts | Stores the maximum number of attempts for processing the event before it goes into a broken process. The default is 3 attempts. |
RetryEveryBase | Number of minutes that the system will wait after an error before another attempt is made. 0 represents an immediate attempt. The event is processed during the next agent execution. |
RetryEveryFactor | The waiting period between execution attempts. The factor is applied on the previous waiting period to set the new interval. For example, if an item is queued with a RetryEveryFactor of 3 seconds and a factor of 1.5, the system will wait 3 seconds between attempts 1 and 2, 4.5 seconds between attempts 2 and 3, 6.75 seconds between attempts 3 and 4 and so on. |
Below are some important rules related to the implementation of CreateEvent.
Rule name | Rule type | Ruleset | Description |
CreateEvent | Activity | PegaFS | Creates an event in the fsf_events_queue table for the passed parameter page of System-Queue-FSEvents |
QueuedCustomerDetails | Report definition | PegaFS | Fetches the list of the customers who are queued for the event. The rule uses the EventType and CustomerId parameters. |
CheckPendingCasesOnEvent | Activity | PegaFS | Specializes the extension activity for open customer review cases. Sets the parameter CaseExists in the activity if the case exists. |
CreateEventConfig | Decision table | PegaFS | Sets different values depending on the event type. Sets default values for: MaxAttemps (3), MinAgeForProcessing (0), RetryBase (60), RetryFactor (2). |
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.
Previous topic Financial Services Industry Foundation data model Next topic Event-driven architecture