Interaction between event runtime and outer application happens using the various connectors. The event runtime starts collecting and filtering the business event information it receives from the connectors that have been implemented and business users have described and stored. The event runtime environment sorts through the volume of event information it receives and associates the relevant information it detects, it can then match whether the event is pertinent to the defined patterns and correlations that the business users have described and sorted.
Business information can be from short activity, combination of multiple events or may be complex events processing, once runtime senses a defined pattern it initiates action which can be anything defined by the system. Once we deploy the event runtime it retrieves the assets and uses them as instructions during event handling to do tasks such as creating business objects, evaluating filters in event rules and firing actions.
The picture below depicts high level architecture for Business Orchestration Server (The event runtime)
As shown in the picture above Business Orchestration Server (rhe event runtime) is implemented on WebSphere Application Server. It is installed and deployed as an application (wberuntimeear) with in WebSphere Application Server to take advantage of all the benefits of WebSphere Application Server including high availability, scalability, security and transparency of operations and use.
Since event runtime is actually an application running within WebSphere Application Server its access is controlled by WebSphere Application Server. The event runtime is based on publish/subscribe architecture and it supports messaging layers of WebSphere Application server and utilizes WebSphere messaging platform. Basic concept and mechanism on which event runtime works on is CBE (Common Base Events) and CEI (Common Event Infrastructure)
CBE is defined as standard/platform independent XML schema to be used for the format of business events to be sent to runtime using connectors
CEI is an event notification and event transmission framework that is used as a mechanism for passing events in CBE format to event runtime
The CEI is IBM's implementation of a consistent, unified set of APIs and infrastructure for the creation, transmission, persistence and distribution of a wide range of business, system and network CBE-formatted events
CEI provides public interfaces to:
- Publish (or emit) an event
- Subscribe to events that match a particular filter (event group)
- Consume an event
- Query historical event data (if the optional event data store is enabled, this can be achieved via a published interface)
The CEI provides a point of integration to consolidate events from a number of potentially disparate and diverse sources. It also provides the ability to distribute these events to consumers. These events are represented using the CBE model described.
Using CEI products, applications and functions are able to integrate their events. This enables the support of the end-to-end business-centric process views that these services make up.
At the runtime during the execution of Business Events we need to have database system configured as the runtime configuration for Business Events is stored within the database and at the time of initialization and real run time it retrieves the data to process the incoming events. For complex processing of events and executing actions database can also be configured to store information about for subsequent processing.
The event runtime supports almost all Professional RDBMS databases
The picture below depicts the Business Orchestration server run-time architecture
- The event runtime is the core of Business Events. This is where the logic of business event processing takes place.
- Connectors are internal system components that provide codeless connection to and from touchpoints via a variety of protocols.
- The repository provides shared, secured storage for definitions of Business Events assets.
Business Orchestration Server (The event runtime) mostly consists of these following components:
- WebSphere Application Server Network Deployment
- A RDBMS to contain the repository such as business objects, events, actions….
- The Decision Server Events application for business event processing (BEP), wberuntimeear
- The WebSphere Business Events application installed and deployed with in WebSphere Application Server Network Deployment.
- Java Message Service message queue managed by a message queue server such as WebSphere Application server ND service integration bus or WebSphere MQ.
- Event connectors and action connectors for touchpoints
- A database manager to serve as a message store for persistent messages
- A LDAP or Microsoft Active Directory, if user authentication is required
- JDBC drivers for database access at runtime
The following picture depicts the event runtime processing:
The event runtime manages the real-time business event coordination that was defined during application development. As an event occurs in a touchpoint that potentially requires one or more actions in another touchpoint, the relevant data (field name, field type, and value), called an event payload, and is passed using the connector of the touchpoint to the JMS message queue. Web services environments that employ SOAP to package messages and other protocols like HTTP, can direct those messages through the JMS queue.
The event runtime retrieves the message from the JMS queue and populates the appropriate intermediate objects with the values contained in the event payload. The event runtime parses the event, identifies the interaction sets that reference the event and determines whether any filters exist that require further evaluation.
If an action includes a filter, the event runtime attempts to evaluate it to determine if the filter conditions for a given action have been met. For complex event processing, this includes determining if referenced events or actions have occurred or not occurred as described in the filter condition. If any values are missing, the event runtime will attempt to retrieve the missing information from an external data source. The action is initiated only if the filter condition is true.
If the action does not include a filter, then the appropriate action will be initiated.
The event runtime passes the relevant data (field name, field type, and value) associated with the action from intermediate objects as an action payload to the outbound message queue, where it is picked up by the appropriate connector. The connector pushes the data to the appropriate touchpoint(s) and initiates logic within the touchpoint to perform the appropriate activity. The connector might return a result back to the JMS queue, where it is retrieved by the event runtime as a new event and processed appropriately.
If the action requires human intervention, it is directed to User Console, where the user can access it. When the user responds to the information displayed on the screen, the response is sent back to the JMS queue as a result event, where it is retrieved by event runtime as a new event and processed appropriately.
History for events, actions and filters used in event rule group evaluation is stored in a History database manager. This information is retrieved, formatted and displayed as charts in real time in Business Space by the Event Chart widget.
Alok Keshri, a Technical Manager for Prolifics focusing mainly on ILOG-JRules and WODM 7.5, has over eleven years of experience in the IT industry spanning across various industries. He is an experienced and resourceful enterprise software Tech Lead/Architect and has worked with J2EE/ SOA/BRMS/ BPM technologies. He is specialized in Object Oriented Analysis, Design, Development, and Estimation of projects with heterogeneous Web technologies in complex business systems based on a variety of platforms. He has extensive experience in IBM middleware products such as WebSphere Application Server, WebSphere ILog-JRules, WebSphere Message Broker and other products in the IBM BPM stack. He is also certified in WebSphere ILOG-JRules and FileNet. Alok received his BE in Electrical Engineering in 2000.
