Event-driven architecture overview

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. 

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.

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:  

1. 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.
2. 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.
3. 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).
4. 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.  
5. 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.
6. 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.
7. 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.

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.

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 Configure > Financial Services > Event Management, and then clicking one of the landing pages: Operations or Configurations.

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 Events tab: