From RuleCore Support

Contents 1 Introduction 2 Default Implementation 3 Customization 3.1 Event Inputs 3.1.1 Sample JMS Event Input 3.2 Event Preprocessing 3.3 Error Handling

Introduction

As mentioned in the logical model, a successful deployment of a Complex Event Processing and Situation Detection solution using the ruleCore Engine is ultimately dependent on two things;

1. receiving all the events that play part of the particular CEP setup
2. receive those events in order of increasing event time stamp.

To not only meet the above requirements but also allow for a quick, efficient and versatile deployment model the choice of software platform for the Event I/O module fell upon Mule. Mule is an open source Enterprise Service Bus and Integration Platform that has been around for a while and has grown into a very competent and useful piece of software -- sporting an extensive feature set and is highly customizable and extensible.

Taken from the Mule Introduction, the primary goals of Mule project are:

• to provide a scalable messaging framework that should handle most of the complexities of systems integration.
• to provide an easy to use, yet powerful server that can operate over complex topologies.
• to allow for simple autonomous component development and deployment
• to allow for code reuse. If all components are self-contained, independent units of work they can be plugged into any other system
• to allow for rapid time to market. Using Mule will provide time-saving features and functionality with no development or maintenance overhead.
• to be flexible. A powerful configuration that should be easy to manage over a distributed environment.

Default Implementation

The default Mule configuration used for the Event I/O module contains a setup that implements what is described in the logical model, i.e. a series of basic event streams (endpoints) and event preprocessing steps (components) tied to together -- building up the complete event processing flow, inbound as well as outbound. The setup also exposes, apart from the standard components and their properties, a set of integration points to which one may attach additional components that could enhance the functionality of the Event I/O module.

Mule-specific details about various default components, choose from the list below:

• Event Input
• Event Validator
• Event Access Control
• Event Sequencer

Customization

The Event I/O module has been designed so that it may be easily changed and tweaked to accommodate the needs of the particular CEP solution. The following sections describes the parts that you most likely need or would consider changing.

Event Inputs

Perhaps the most important part when it comes to customizing the Event I/O module, is that of adding new or modifying existing Event Inputs. Adding a new event input is very easy, thanks to the Mule platform. As of this writing, a total of 24 different transports are shipped with Mule and, if the transport you need is not publically available, it is not too difficult to write your own.

The event inputs are defined in a standard Mule way (no strings attached) and the only requirement is that the events received by the event input component are routed, in ruleCore Event XML format, to the InboundEvents endpoint.

Sample JMS Event Input

Below is an example how to configure a JMS event input in Mule:

<?xml version="1.0" encoding="UTF-8"?>
 
<!DOCTYPE mule-configuration PUBLIC "-//MuleSource //DTD mule-configuration XML V1.0//EN"
                                "http://mule.mulesource.org/dtds/mule-configuration.dtd">
 
<!--  This is a sample file for the Event IO project -->
 
<mule-configuration id="EventIO-config" version="1.0">
    <description>
        Configuration for a ruleCore Event I/O JMS input.
 
        Queue name: rulecore.input
    </description>
 
    <model type="inherited" name="EventIO">
        <mule-descriptor name="EventInputJMS1"
            implementation="com.rulecore.mule.components.EventReceiver">
            <inbound-router>
	        <endpoint address="jms://queue:rulecore.input"/>
            </inbound-router>
 
            <outbound-router>
                <router className="org.mule.routing.outbound.FilteringOutboundRouter">
                    <global-endpoint name="InboundEvents" />
                 </router>
            </outbound-router>
        </mule-descriptor>
    </model>
</mule-configuration>

Event Preprocessing

The default Mule configuration is made in a way to allow for easy modification and extension of the event preprocessing. Depending of the environment and other functional requirements you might need to or consider doing some customization. Some examples of such customization are:

• event transformation/reformatting
• additional or specialized event logging
• event enrichment, retrieve data from external sources
• implement a custom authorization scheme
• wiretapping the normal event flow and log to file or database

Error Handling

Even though the default configuration provides an error handling scheme that catches most errors (user, system and access) and redirects them to different outputs, you might come to the point where you might need something different. In much the same way you configure event inputs you also configure your own error handling. The default setup provides a set of extensions points to where you hook up the Mule components of your liking. The following Mule endpoints are available;

• AccessErrors
• SystemErrors
• UserErrors