Event-driven architecture overview
Every day, financial institutions receive high numbers of customer-related events, any of which might represent an increase in risk to their business. These organizations must automatically assess all events and efficiently exercise due diligence to understand any associated risk changes.
The event-driven architecture (EDA) is an infrastructure that facilitates these event-driven processes. EDA manages the reception of events from different sources and routes them to the appropriate applications and processes in charge of their resolution. The solution involves multiple actors, data entities, and processes, which all facilitate the end-to-end event processing. The most significant elements of the EDA architecture are:
- Event producers: Depending on the architecture and business needs of your organization, different systems in the enterprise can produce events.
- Event processing: Each event type has its own characteristics, including a very specific data model, validation rules, and enrichment logic.
- Case management: Each event type can have different case processing needs.
The Perpetual Know-Your-Customer (PKYC) functionality uses EDA to receive events and run event-driven review cases in Pega Client Lifecycle Management and Pega Know Your Customer™. For more information about the event-driven review cases that PKYC events and processes ultimately produce, see .
In the following image, click the + icons to learn more about the key components of the EDA infrastructure:
Entry channels
Depending on the architecture and business needs of each organization, very different systems in the enterprise can produce events. Many of them are external systems that interact with Pega Client Lifecycle Management and Pega Know Your Customer through the EDA REST/JSON interface or through any other channel that you enable. Some examples of external systems that can generate events are CRM applications, transaction monitoring systems, and screening services. We call those systems event producers.
Pega Client Lifecycle Management and Know Your Customer, the recipients of the events that these systems generate can be considered event producers themselves, as they can generate new events and inject them into the EDA engine for their subsequent processing. For example, during the onboarding of a customer, an organization might determine that a full customer review of a related party is required. The event to trigger that customer review journey can be routed through EDA by using the queue processors that are available for that purpose.
The EDA engine currently supports two different mechanisms of receiving events:
- A REST/JSON service: This mechanism is for external applications that need to inject messages into the engine (for example, transaction monitoring systems or e-screening services).
- Direct invocation: This mechanism is for the injection of events from other Pega Client Lifecycle Management and Pega Know Your Customer modules and from the EDA engine itself. You can add custom reception channels to integrate through other mechanisms, such as Kafka, JMS, or SOAP/HTTP.
When the EDA engine receives the JSON message, the entry channel process starts. The process parses the message, validates the payload, registers the event, and then proceeds with the remaining phases.
The EDA engine consumes the event to a certain point in the overall channel process before sending a response back to the event producer. If the event manages to go through all the phases of the channel, the response message includes status information of the processes that ran on the event. These processes might have finished successfully or with errors, or they might not have finished yet if they are set to run under other domains.
Events and processes
The nature of the events that the EDA engine can process varies significantly. While some events might represent simple changes in customer data (for example, a change of address or a change of legal name), others might represent new findings of an ongoing screening service or changes to the risk level that is associated with a given country. Therefore, each event type has its own characteristics, including a very specific data model, validation rules, and enrichment logic.
In addition, every event type can have different processing needs. One change-of-address event, for example, might require the creation of a new event-driven review journey to assess the impact of the change on the customer. A change in bank policy regarding the risk of a particular country, however, might translate into something different, such as a remediation process for all the customers from that country. Some events might even trigger multiple processes at the same time, for example, a customer review and a notification to an external organization. You configure each event type in EDA to follow one or more processes.
For more information about the creation and configuration of new event types, see Configuring new event types.
Processing channel
Regardless of the nature of the events, the entry channel, and the processes to run on them, all events go through a similar process called the EDA channel. The process includes the following basic phases:
- Validation
During this phase, the system ensures that the event contains the minimum metadata that is required (for example, event type and event subtype), that the payload of the event meets the data model that is defined for the event type, and that the event was not sent before. If the event does not pass this check, the system rejects the event and, if the event comes through a channel where a response is expected (for example, REST/JSON), the system includes the rejection information in the response to the producer. - Registration
When the system determines that the event data is complete, it assigns a unique identifier to the event and registers the event within the event tracking table. From that point, the system uses this table to track the progress and status of the event. - Enrichment
The event data is then enriched in a number of different ways, including the retrieval of additional data (from other systems or from internal sources such as the Customer Master Profile), or the generation of data that the system can use later during the next steps of the event life cycle (for example, an event qualifier that indicates the risk that is associated with the event or the customer type). - Preparation
During this phase, the system determines which processes to run on the event and creates the necessary entries in a process tracking table to independently track the progress of each specific process. - Dispatching
Some processes might need to run in a security context (also known as domain in EDA), different than the one where the system received the event. In that case, the system uses this phase to queue the event again into the EDA channel to run under the appropriate application context. - Processing
The system runs in sequence the processes that can run in the same security context or domain where the event was received. Depending on the outcome of the process, the status of the entries in the process tracking table is updated. - Wrap-up
The last phase implements the consolidation of statuses across all the processes into one. If all processes are successful, the status is Success. If all processes fail, the status is Failed. If some processes are successful and some end in failure, the status becomes Partial Success. If the system has not run one of the processes (for example, a process that the system sends to a different domain), the status is Pending.
Any new event that the system receives goes through these seven phases. If one of the phases fails, the system stops running the process, sets the status of the event to Error, and then records the latest phase that is run to mark the phase where the process can restart later.
All the phases of the channel last milliseconds in most cases. The channel process is structured with different phases to facilitate the implementation of certain features such as a retry mechanism. However, all phases are to occur one after another and with an overall response time ideally under one second. Therefore, this phase-based orchestration process is not a regular flow of stages and steps; this process is a convenient arrangement of the logic that is traditionally implemented under a single activity or automation rule in similar modules.
Tracking and registries
The EDA engine uses a set of database tables, called registry tables, to maintain event and process configurations. Administrators maintain these tables in design time, and then use them at run time at many points of the process.
Additionally, during the management of events, the EDA engine feeds three tables that facilitate the status tracking of events, processes, and bundles, which are the main entities in the module. These tables are called tracking tables.
Bundles provide a very light infrastructure that helps the system track those processes that require event bundling.
Administration
EDA offers a configurations console for administrators to maintain the registry tables and general processing settings. In the console, during the design time, administrators can register new event types and new processes, configure domains and access groups, change engine processing settings, activate and deactivate configurations, and so on.
Along with the configurations console, administrators can access the content of the tracking tables through the operations console. The console provides a list of all the events that the system receives and the processes that the system ran on those events. The tool also gives the ability to trigger some corrective action, such as the retry of a certain event or its re-injection into the system.
You can access these configurations and operations consoles in Dev Studio by selecting Operations or Configurations.
, and then clicking one of the landing pages:The Events - Operations landing page provides administrators with all the necessary information about events and processes in EDA that occurred in the system, with separate tabs for events and bundles.
The default view shows only the events that the system received on the last day, but administrators can change the date range to last day, last week, or a custom range.
The landing page provides the following additional information for events on the Events tab:
- The Type, Subtype, and Event purpose fields provide important information that identifies the types of events.
- The Event ID is a unique identifier that EDA creates, whereas the Source and Source ID parameters refer to the event producer and the unique identifier that it generated. These details are useful for reviewing the list.
- The Reference key and Reference value fields show the ID of the customer for the event. You can configure these values.
In the following image, click the + icons to see more about the different details that are available on the tab:
The Bundles tab shows information about bundles that are in progress or complete.
Each row in the table displays information about the status of one bundle, the domain in which to run the bundle, its type and subtype, and other related properties. The row also contains information about the dependencies that the bundle needs to meet before you can run it. You can apply the following dependency scenarios when you design the bundle:
- No dependency: The bundle does not have any dependency and you can run it at any time. The DependencyType property has no value.
- Time: The bundle is awaiting a certain point in time to run. In this scenario, the DependencyValue property contains the exact time the bundle waits before the run.
- Customer subscription: The bundle is waiting for all the cases that are associated with a given customer to finish before processing. In this scenario, the DependencyValue property contains the unique identifier of the customer.
The additional information for bundles that this tab displays includes the following data:
- The Process, Domain, Type, and Subtype fields provide important information for identifying the types of bundles.
- The Dependency value field specifies the dependencies that the bundle needs to monitor before running.
In the following image, click the + icons to learn more about the different details that are available on the and tabs:
Check your knowledge with the following interaction:
This Topic is available in the following Modules:
Want to help us improve this content?