Getting Started with Complex Event Processing Nodes · CEP and the WebSphere Message Broker ... Version 1.2 Getting Started with Complex Event Processing Nodes ... Version 1.2 Getting

Getting Started with Complex Event Processing Nodes

Wayne M. Schutz

[email protected] Solutions Architect, WebSphere MQ Family

IBM Software Services for WebSphere

Sterling Forest, New York, USA

Version 1.2

Property of IBM.

mailto:[email protected]

Table of ContentsNotices ..........................................................................................................................................................4

Trademarks and Service Marks ...................................................................................................................4Changes.............................................................................................................................................................5Acknowledgments.............................................................................................................................................5Introduction.......................................................................................................................................................5

What is Complex Event Processing?...........................................................................................................5The Building Blocks of CEP........................................................................................................................5

Events....................................................................................................................................................5Event Grouping Keys.............................................................................................................................6Lifespans................................................................................................................................................6Situations...............................................................................................................................................6CEP and the WebSphere Message Broker..............................................................................................6

Installing the CEP Tooling...........................................................................................................................8About the instructions............................................................................................................................8The CEP SupportPac..............................................................................................................................8Installing the SupportPac.......................................................................................................................8Verifying the Installation........................................................................................................................8

Lab 1: Your First Complex Event....................................................................................................................12Overview of this step.................................................................................................................................12Creating the Bank_Project_1 AMiT Project...............................................................................................12Creating the ATM_Withdrawal Event Class..............................................................................................12Creating the Event Grouping Keys.............................................................................................................16Creating the Lifespan.................................................................................................................................22

A quick word about Aliases.................................................................................................................24Creating the Possible Fraud Situation........................................................................................................24

Situation Results...................................................................................................................................27Running the Simulator...............................................................................................................................28

Creating the Environment File.............................................................................................................28Exporting the Project into an XML file................................................................................................28Creating Test Data ...............................................................................................................................29Creating the Launch Configuration......................................................................................................31

Lab 2: Actually Detecting fraud.......................................................................................................................35Lab 3: Resolving a little problem.....................................................................................................................39

Controlling the way Lifespans start ...........................................................................................................40Terminating Lifespans...............................................................................................................................41Adding more attributes to situations..........................................................................................................44

Lab 4: An improvement in the logic................................................................................................................45Backing Up Your workspace...........................................................................................................................48Lab 5: Compound Event Types.......................................................................................................................49

Creating the “For_24_Hours” lifespan ......................................................................................................49Creating the “Fraud_Detected” situation ...................................................................................................49Running the Simulator...............................................................................................................................51

Lab 6: Detecting Aggregation Situations.........................................................................................................53Creating the “withdrawal_Start” lifespan..................................................................................................53Creating the “Too_Much_Withdrawn” situation.......................................................................................53

Running the Simulator..........................................................................................................................55Lab 7: Multiple Event Classes and the not situation........................................................................................57

Defining the event classes..........................................................................................................................57Defining the grouping keys..................................................................................................................57

Defining the lifespan .................................................................................................................................58Defining the situation.................................................................................................................................58Running the simulation..............................................................................................................................59

Making it work in the Broker..........................................................................................................................62

Version 1.2 Getting Started with Complex Event Processing Nodes Page 2 of 76


Installing Toolkit and Broker Plugins........................................................................................................62Lab 8: Using the SituationManager node in a flow..........................................................................................62

Exporting the project definition ................................................................................................................62Create the MQ Queues...............................................................................................................................63Create the Message flow............................................................................................................................63Deploy the Message flow...........................................................................................................................65Create and Load Test Data ........................................................................................................................65Inspect the results......................................................................................................................................66

Internal Situations................................................................................................................................68Lab 9: Using the IntelligentFilter node in a flow.............................................................................................70

Deploying and running the flow.................................................................................................................70Advanced CEP Features..................................................................................................................................73

Thirteen situation operators. .....................................................................................................................73Templates .................................................................................................................................................73Using a Database to Store CEP's State.......................................................................................................74Using a Recovery Database........................................................................................................................74Reading CEP definitions from a database..................................................................................................74Runtime control messages.........................................................................................................................74Rule sets ...................................................................................................................................................74LocalEnvironment enrichment...................................................................................................................75RouterList Enrichment...............................................................................................................................75MQDestinationList Enrichment.................................................................................................................75



Notices The following paragraph does not apply in any country where such provisions are inconsistent with local law.

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore this statement may not apply to you.

References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates.

Any reference to an IBM licensed program or other IBM product in this publication is not intended to state or imply that only IBM's program or other product may be used.

Any functionally equivalent program that does not infringe any of the intellectual property rights may be used instead of the IBM product.

Evaluation and verification of operation in conjunction with other products, except those expressly designated by IBM, is the user's responsibility.

IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, New York 10594, USA.

The information contained in this document has not be submitted to any formal IBM test and is distributed AS-IS. The use of the information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item has been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

Trademarks and Service Marks The following terms, used in this publication, are trademarks of the IBM Corporation in the United

States or other countries or both:

• IBM

• WebSphere Business Integrator Message Broker

• DB2

• MQSeries

• MQSeries Integrator

• WMQI

• MQSI

• WebSphere Message Broker

The following terms are trademarks of other companies:

• Windows NT, Microsoft Corporation

• Windows XP, Microsoft Corporation



ChangesVersion 1.2 of this document includes updates for Version 6 of WebSphere Message Broker.

Version 1.1 of this document includes the “Expression Builder” function of the CEP toolkit.

AcknowledgmentsSpecial thanks to Guy Sharon from IBM Haifa Lab for providing guidance, support and editorial feedback.

IntroductionThis document will teach you the fundamentals of IBM's Complex Event Processing (CEP) tooling

for the WebSphere Message Broker. It is assumed that the reader has a good understanding of WebSphere MQ, WebSphere Message Broker and the Eclipse framework.

What is Complex Event Processing?Many computer based systems exist that allow for the processing of a single “event”. There are

many types of events, such as a withdrawal from an ATM, the passage of a railroad train past a detection point, the placement of a stock purchase order on the Internet. While many “business rules” engines in the market allow for complex processes following the occurrence of a single event, there are not many facilities available to handle the correlation of multiple events. Systems that have been developed which allow the correlation of events, such as all the events surrounding an Internet order (the order, shipping the order, the customer receiving the order, getting paid for the order, “low inventory indicators”) tend to have been of an “ad hoc” nature.

IBM's CEP is a generalized, cross industry tool that allows for efficient and effective correlation of events into meaningful business situations. This document develops a CEP scenarios based on ATM (teller machines) generated events. The situations that we will deal with are the detections of possible fraud. Additional labs deal with processing of Internet orders.

In the ATM situations, the bank that owns the accounts from which funds are being withdrawn at ATM's wishes to use CEP to detect possible fraud. Imagine a scenario where all ATM transactions are copied to a system which contains the CEP processing engines. We determine that fraud has possibly occurred when we see two ATM withdrawals from the same account within 1 hour that are more than 100 miles apart. We are also interested in a second situation where more than $1000 has been withdrawn from an account within a 24 hour period.

For a complete treatment of Complex Event Processing, refer to the book "The Power of Events" by David Luckham.

The Building Blocks of CEPIBM's CEP is a rich environment that allows for the detection of situations based on sophisticated

rules. However, we begin by introducing the fundamental building blocks that are required to define the simplest CEP scenario.

EventsEvents are the fundamental elements in CEP. It is the combinations of events, or the absence of

them, that causes situations. Events have attributes. In our example of ATM withdrawals, the “event” is the withdrawal of money from an ATM. The attributes of the event might include: the customer account number, the date and time of the withdrawal, the amount of the withdrawal and an ATM identification code. In CEP, these attributes have a type: string, integer, double, date, boolean, and object. To be able to use events in CEP, we must define event classes. An “event class” is a description of the types of events we are expecting to deal with. So “ATM withdrawals” is an “event class”. When someone actually withdraws money from an



ATM, that is an “event instance” of the “ATM withdrawals” class.

Event Grouping KeysEvent Grouping Keys are the definitions which allow us to associate different events together. In

our example, if we are interested in correlating events for a given customer, then the key would be the “customer account” attribute. This means that events are “grouped” by the customer account attribute.

In a different scenario, we might be interested in detecting situations relating to the ATM itself. For example, we might wish to know if more than $10,000 had been withdrawn from the ATM in a given hour period. In that case, we would specify the “ATM Identification” code as the event grouping key.

If there are multiple event classes, then the event grouping key would list the correlating field for each event. As an example, if we were also receiving credit card purchase events, and the attribute name was “customer number”, then the key object would contain two segments. The first segment would be “customer account” for the ATM events and the second segment would be “customer number” for the credit card purchase events. This allows CEP to determine which events are related to each other.

LifespansA lifespan object is used to define what period of time we are interested in for determining if a

situation exists. Lifespans have a beginning and an end. CEP allows us to start lifespans in one of two ways: a lifespan can begin when the system starts or when a given event occurs. Likewise, we can define when lifespans terminate. It can end at a fixed time, it can end as the result of an event, it can end after a period of time, or it can never end.

In our examples above, we might define two lifespans. The first lifespan would begin when an ATM withdrawal event arrives, and ends 1 hour later. The second lifespan begins when a ATM withdrawal event arrives and ends when more than $1000 has been withdrawn.

SituationsSituation objects are used to define the rules for detecting situations. We define these rules by

specifying the applicable lifespan and listing the events that must occur (or must fail to occur) to detect the situation. We can also write expressions to further qualify the conditions for detecting the situation.

In our examples above, the events that must occur are the ATM withdrawals. For the first example, we would write a rule that says if any two transactions take place more that one hundred miles away from each other (within the “one hour lifespan”), then detect the situation. In the second example, we apply the “summing” operator to the amount of withdrawal of each ATM event, and if the sum is greater than $1000 (within the “all day” or “more than $1000 withdrawn” lifespans), then the situation is detected.

Situations are themselves events: each detected situation is considered as an input event. This means that situations can be used to detect other situations, to begin or terminate other lifespans. In certain scenarios we may choose to use situations only as input events. Such situations can be marked 'internal' and will not be reported like regular 'external' situations.

CEP and the WebSphere Message BrokerCEP delivers two plug-in nodes which are installed into the WebSphere Message Broker runtime

environment. See “ Illustration 1: The relationship between CEP and the Message Broker“. These nodes are wired into WebSphere Message Broker flows by using the build time authoring toolkit. Events of different format and from multiple sources are send to the In terminal of the plug-in nodes. The CEP SituationManager node analyzes incoming events and situations based on the current rules conditions. Upon detection of a situation, the node posts an MQ message that lists the situation attributes on an MQ queue (or potentially multiple queues). Furthermore, detected situations are also fed back into the runtime engine and treated as input events.




Illustration 1: The relationship between CEP and the Message Broker


Installing the CEP Tooling

About the instructionsIn this document, we will use the following convention. If we want to show you when to “type”

something into the application, it will be in “double quotes”. If we want to talk about something you will see on the screen, it will be in italics, and if its a button to push, then it will be in bold.

The CEP SupportPacCEP is a category 3 SupportPac, meaning that it is a WebSphere family product extension and

should be considered part of the WebSphere Message Broker. The SupportPac number is IA0S. IBM's CEP is available from the IBM WebSphere MQ supportPac page and may be downloaded from there. The URL for the SupportPac page is:

http://www.ibm.com/software/integration/support/supportpacs/category.html#cat3

The IA0S web page includes two downloads:

The SupportPac user guide (IA0S.PDF)

Installation zip files

Installing the SupportPacThe CEP SupportPac supplies three components:

1. A “AMiT” perspective for the Eclipse framework. This perspective allows you to write and test the rules which control how the runtime engine will operate.

2. Two Eclipse “plugins” for inclusion in message flows. These plugins allow you to wire the runtime engine into your message flows.

3. A .PAR file which you must copy to your broker environment. This PAR file provide the runtime engine for the broker to use.

With Version 6 of the Broker toolkit, you will install plugins into the Broker toolkit directory which allows you to open an AMiT perspective to develop and test the CEP rules. The supportpac includes other toolkit installation files which allows you to use a standalone version of eclipse for authoring the CEP rules. This is provided for those users who are using V2.1 or V5.0 of the Broker tooling. Users who have V5.1 and V6.0 of the Broker tooling should install the files which allows them to use the same tooling for the AMiT perspective and the Broker Application Development perspective.

The supportPac user's guide gives detailed instructions for installing the CEP toolkit, the Broker toolkit plugin nodes and the Broker runtime plugins. Follow those instructions now. Later in the document, we will export the CEP definition for use in an WebSphere Message Broker flow. To include the CEP runtime engine in a broker flow, you must install the CEP plugins into your Broker toolkit. Once the broker flow has been developed, you will want to deploy it to a broker. To included the CEP runtime engine in your broker environment, there are several files that must be copied from your CEP source directory to the broker. Refer to the supportPac user's guide.

Verifying the InstallationSince the CEP tooling and the WebSphere Broker tooling are both Eclipse based, it is assumed that

you are familiar with the basic usage of using the Eclipse tooling. If not, take the guided tour from “Help...



http://www.ibm.com/software/integration/support/supportpacs/category.html#cat3

Help Contents ... Rational Application Developer (under “Included Products”).

After you have installed the CEP development tooling, you should verify that it is properly installed. To do this, we will run the simulator against the “NetSalesSync” sample project that is included in the tooling.

The following assumes that you have included the AMiT Perspective into an existing WebSphere Message Broker Toolkit installation. If you haven't, then you must open the stand-alone tooling instead.

1. Open the WebSphere Message Broker V6 tooling

2. Open the AMiT Perspective (Window... Open Perspective... Other..., AMiT)

3. Import the NetSalesSync project (File... Import..Existing AMiT Project into Workspace) from the

“WMB CEP Detector Nodes\6.x.x.x\Samples\NetSales\NetSalesSync” directory of the unzipped supportpac location.1

4. In the AMiT Navigator pane you should see the AMiT projects: NetSalesSync.

5. Expand the NetSalesSync project to view the definitions of events, keys, lifespans and situations.

6. Open the runtime environment by selecting Run->Run... on the action menu.

7. Select AMiT under Configurations, and press the New button at the bottom to create a new runtime configuration.

8. Name the configuration “NetSalesSync”.

1 The exact path will depend on the version of CEP being used.



9. Use the Browse button to select the AMiT Project “NetSalesSync” (if not already selected).

10. The environment, definitions and simulation files are stored in the runtime directories under the NetSalesSync workspace directory. Use Illustration 2: Setting up the NetSalesSync Runtimeenvironment to guide you in selecting the needed files.

11. Select the Run button in the bottom corner and after a few minutes you should see the results of a simulation run. 2

12. If you see a screen that looks similar to “Illustration 3: The results of the simulation run“, then you have properly installed the CEP development tooling. You might need to scroll down on the AMiT Run view to see the events. We will explain the meaning of this screen later in the primer.

2 Be patient, it takes several minutes for the first simulation to run,


Illustration 2: Setting up the NetSalesSync Runtime environment


13. You can close this view by clicking the Close button on the AMiT Run tab. Please note that there are two eclipse perspectives: the AMiT Perspective and the AMiT Run Perspective. When editing the AMiT definitions discussed in this primer, you should be in the AMiT Perspective.


Illustration 3: The results of the simulation run


Lab 1: Your First Complex Event3

Overview of this stepIn this first step, we will define all the basic elements necessary to run a CEP simulation. By the end

of this lab, you will have defined all the CEP elements necessary to take withdrawal events from an ATM and detect when a single customer makes two ATM withdrawals. We will enhance this in future labs to detect more realistic situations.

We will define an ATM_withdrawal event class and give it four attributes (customer account, amount withdrawn, date and time of withdrawal, and ATM Identification).

We will then define an Event Grouping Key which will be used to correlate events based on the customer account number.

Next, we will define a Lifespan, which will begin when an ATM withdrawal event arrives .

The situation we will then define will be very simple, it will detect when a second ATM withdrawal event arrives for the same customer. In real life, this would mean the bank would be detecting possible fraud if you made two withdrawals an ATM. We will build on it later to make it more realistic.

Lastly, we will run the simulator to ensure that the definitions have been properly entered.

Creating the Bank_Project_1 AMiT ProjectYou should be in the AMiT perspective. If not, open that perspective "Window->Open Perspective-

>Other...>AMiT". We need to create a new project, so right click in the "AMiT Navigator" pane and select New....then select AMiT Project In the AMiT Project dialog box, enter a project name of “Bank_Project_1” and click Finish. Expand the project and expand the Base Definitions folder. See Illustration 4: New AMiTProject Dialog.

Creating the ATM_Withdrawal Event ClassIn AMiT, there are two ways to define event classes. If you have a sample XML file which

describes the event, you may use the AMiT – Import WBI Event Type action (from File..Import..) to automatically create an AMiT event class from that file. You may also manually enter the event and its attributes by using the AMiT event editor. We'll manually enter the event class definitions.

3 All labs are provided as eclipse projects in the WMB CEP Detector Nodes\6.x.x.x\sample\Primer directory.



Now, right click on the Bank_Project_1, select New..., then Event Class. The project should be Bank_Project_1 (if not, select that) and enter an event class name of “ATM_Withdrawal”.


Illustration 4: New AMiT Project Dialog

Illustration 5: New Event Class Dialog


Click Finish. You should have a screen that looks similar to this one:

The top part of the editor panel contains a section called: General Information. In this section you may enter descriptive information about the events if you choose.

Now, we must enter the attributes of the ATM_Withdrawal event. Select the Add button under event attributes. You will see a small dialog box (Add Attribute) where you can enter the attribute name and select the type.


Illustration 6: The Event Editor Pane


Enter a name of “Body.ATM.Customer_Number” 4 and select a type of Integer. Press the OK button. Enter the remaining attributes according to this table:

Attribute Name Attribute Type

Body.ATM.Customer_Number integer

Body.ATM.Withdrawal_Amount double

Body.ATM.Withdrawal_Date date

Body.ATM.ATM_Id integer

After you have entered and verified these attributes, save your work by pressing Ctrl+S. Your new event class should be visible in the AMIT perspective pane:

4 As you'll see when we use CEP in conjunction with the Message Broker, these attribute names refer to the logical message structure of the event message.


Illustration 7: The Add Attribute Dialog


Creating the Event Grouping KeysWhen CEP receives events, it must make a determination how these events are to be grouped

together. In our example, we are using Customer_Number to group events together. This means that all events for Customer_Number “1” are to be grouped together. Customer_Number “2” events are grouped separately. After all, we wouldn't want to indicate a possible fraud situation if two different accounts withdrew funds more than 100 miles apart.

We'll create an Event Grouping Key and specify the ATM_Withdrawal.Customer_Number as the key segment. Its called a key segment because we can use multiple attributes to define the “grouping key”, as we'll see later.

Right click on the "Amit Navigator" pane, select New... then Key. You will have the New Event Grouping Key dialog box (See Illustration 9: Event Grouping Key Dialog). Ensure the project is Bank_Project_1 and enter a name of “Customer_Number_Key”. Press Finish.


Illustration 8: The Event Editor with the Event Attributes added


In the event grouping key editor, we must first enter the key type. Since Customer_Number is an integer, select that from the drop-down box. Then press the Add button in the Key Segment portion of the editor. See Illustration 10: The Event Grouping Key Editor.


Illustration 9: Event Grouping Key Dialog


When you press the “add” button, you should see the Add Key Segment dialog box. From the dropdown, select the “ATM_Withdrawal” event. On the Expression field, click the button on the right which contains the three periods (...). See Illustration 11: Add Key Segment Dialog.

You will then be in the “Expression Builder” dialog. See Illustration 12: The Expression Builder. The expression builder allows you to quickly create simple or complex expressions. In our case, we will use the it simply select one attribute from the ATM_Withdrawal event. Start by clicking the “Event” icon as shown in the illustration.


Illustration 10: The Event Grouping Key Editor

Illustration 11: Add Key Segment Dialog.


When you click the “events” icon, you'll see a list of all the events in the project. Select the “ATM_Withdrawal” event and you'll then see a list of all the attributes of that event. To use an attribute, double click on the name of the attribute and it will appear in the expression box. See Illustration 13: Completing the Expression.


Illustration 12: The Expression Builder


Now click OK to use the generated expression. We'll show another example of using the Expression Builder later on. The editor should now look like Illustration 14: The Key Editor when complete Press CTRL+S to save your work.


Illustration 13: Completing the Expression



Illustration 14: The Key Editor when complete


Creating the LifespanLifespans are used to define the period of time within which a situation can occur. In our example,

we want the lifespan to begin as soon as the first ATM_Withdrawal event occurs. For now, we'll say that the lifespan never ends, but we'll change that as we develop the example.

To create a lifespan, right click on the "AMiT Navigator" pane, select New... then Lifespan. In the New Lifespan dialog dialog box, (see Illustration 15: Create Lifespan Dialog) ensure that Bank_Project_1 is selected and enter a lifespan name of “From_withdrawal”. In the “Select Source” section, leave the “empty lifespan” radio button selected. New lifespans (and situations) can be created from templates, however, in this case we are creating a lifespan from scratch. Click Finish.

You are now in the lifespan editor. Add an event by selecting the Add button in the Event Initiators' Table pane. In the Add Initiator Event dialog box, use the dropdown to select the ATM_Withdrawal event. For an alias, type “init_ev”. Press the OK button. See Illustration 16: The Lifespan Editor.


Illustration 15: Create Lifespan Dialog


Now select the Terminator & Keys tab in that editor (at the bottom of the pane). In the Keys section, press the Add button and select Customer_Number_Key from the dropdown box, then press Ok. Now, put a checkmark next to the Never Ends checkbox in the Terminators section, then Ctrl+S to resolve the Task List errors and to save your work. See Illustration 17: Lifespan Editor - Termination & Keys Tab.


Illustration 16: The Lifespan Editor


A quick word about AliasesWhat was that init_ev alias that we entered into the Add Initiator Event dialog box? In CEP, aliases

are used to refer to events and allow us to differentiate where events are being used. In our example, we'll use the ATM_Withdrawal event in two places. We've just used it in the Lifespan object. We'll also use it in the Situation object. Suppose we need to compute how long it has been between these two transactions. The best way to do that is to subtract the actual time the transactions occurred, as reported in the Withdrawal_Date attribute. When we define the situation, we'll give the event that we define there an alias also (we'll call it sit_ev). So to compute the elapsed time, we prefix the attribute name with the alias name and do that math:

sit_ev.Body.ATM.Withdrawal_Date - init_ev.Body.ATM.Withdrawal_Date

As you can see, aliases allow us to indicate to CEP exactly which event we are referring to in computations. Another way to think of an alias is as a way to TAG an event so that you can refer to that instance of an event in an expression.

Creating the Possible Fraud SituationThe last object we need to create prior to running the simulation is to create the Situation. To begin

with, we'll create an easy (and probably unrealistic) situation. The situation will use the From_withdrawal lifespan and will be detecting when an ATM_Withdrawal event is received.


Illustration 17: Lifespan Editor - Termination & Keys Tab


Right click on the AMIT perspective, select New... then Situation. In the New Situation dialog dialog box, ensure that Bank_Project_1 is selected and enter a situation name of “Possible_Fraud”. The Select Source... Empty of type...all should be pre-selected in the dialog box. Click Finish. See Illustration18: The Situation Dialog.

In the Situation Editor, press the Add button in the Events section. In the Add Event dialog box, use the dropdown to select the ATM_Withdrawal event. For an alias, enter “sit_ev” and leave threshold blank. Click Ok.

Ignore any error messages you see in the Tasks panel for now.

Now select the Condition & Result tab in that editor (at the bottom of the pane). In the Condition section, select the dropdown box for Lifespan and select From_withdrawal.

In the Result section, click the Add button. In the Add Attribute dialog box, enter a name of “CustNumber”, select a Type of integer and use the expression builder to create “sit_ev.Body.ATM.Customer_Number” as the Expression. Press OK. Press Ctrl+S to save your work.

The Situation editor should look like Illustration 19: The Situation Editor - General & Event tab and Illustration 20: The Situation Editor - Condition & Result Tab.


Illustration 18: The Situation Dialog



Illustration 19: The Situation Editor - General & Event tab


Situation ResultsWe created a situation result with a name of CustNumber. What is a situation result? A situation

has attributes associated with it; these are the attributes that are of interest when the situation is detected and will be included in the notification that the runtime engine provides when it detects that the condition specified in the situation was fulfilled. In our example so far, we have defined an attribute associated with the situation and that is the customer number. The expression (sit_ev.Body.ATM.Customer_Number) says that for this situation, the CustNumber attribute comes directly from the Customer_Number field of the sit_ev alias. Remember that the sit_ev alias refers to the ATM_Withdrawal event which actually caused the situation. We could have entered “init_ev.Body.ATM.Customer_Number” in this field instead and the result would be the same. Why?

Remember that in the Keys section of the From_withdrawal lifespan we specified Customer_Number_Key. We previously defined Customer_Number_Key as a key with one segment: the Customer_Number of the ATM_Withdrawal event. This says that we are to group ATM_Withdrawal events with the same Customer_Number together. Therefore, we expect that the event that started the lifespan and the event that triggered the situation would have the same Customer_Number, and therefore we could use either event to source the CustNumber field.5

5 A third way of getting the value of key is in Expression Builder selecting "Keys" on the left lets you pick the keys for the situation and has the same value as the other two (from init_ev and sit_ev)


Illustration 20: The Situation Editor - Condition & Result Tab


Running the SimulatorOkay, now its time to run the simulator and see what we have done. To run the simulator we must

create a runtime environment that has three files: an Environment file, a file containing our project definition, and test data file.

Creating the Environment FileTo create the Environment file, right click in the AMIT perspective, select New...Environment.

Ensure the project is Bank_Project_1 and leave the name Environment1. Pressing Finish will place you in the environment editor. You can accept all the defaults and close this editor

Exporting the Project into an XML fileTo create the project definition, we must Export our project. Select Bank_Project_1 and right click

to select Export.. In the Export dialog box, select AMIT – Export to an XML file and click Next. In the next Export dialog box, place a checkmark next to Bank_Project_1 and press the Browse button. When you go to the Browse dialog, you will be in the “Exports” subdirectory of the project directory. Complete the file name “Bank_Project_1.def”. Click Save, then click Finish. See Illustration 21: The AMiT - Export to an XMLFile dialog.



Creating Test DataNow, to create test data, right click in the AMIT perspective and select New...Simulation Data. Ensure the project is Bank_Project_1 and leave the name Simulation1 .


Illustration 21: The AMiT - Export to an XML File dialog


Pressing Finish will place you in the simulation editor. Press the Add button to open the Add Event Instance dialog box. See Illustration 24: The Simulation Data editor. This will open a Add Event Instance Dialog. Use the dropdown to select the “ATM_Withdrawal” event., the press OK. See Illustration 23: TheAdd Event Instance dialog.

After pressing OK, you will see an instance of the event in the editor pane. Open the event by clicking on the “+” sign by the Instance Name (ATM_Withdrawal). This will cause all the defined attributes for the event to be displayed. Enter the data as you see it in Illustration 24: The Simulation Data editor.


Illustration 22: The Simulation Data dialog

Illustration 23: The Add Event Instance dialog


Use this table to enter test data. Use the ADD button to add five additional events.

Body.ATM.Customer_Number Body.ATM.Withdrawal_Amount Body.ATM.ATM_Id Body.ATM.Withdrawal_Date

1 250 1 31/12/2004-12:12:006

2 300 1 31/12/2004-12:13:00

3 140 1 31/12/2004-12:14:00

1 100 21 31/12/2004-12:42:00

2 300 102 31/12/2004-13:12:00

3 300 99 31/12/2004-13:13:00

To check that you have entered your data correctly, double click on the Simulation1.scn file in the navigator panel, when you are done, you should have six rows of data.

Creating the Launch ConfigurationNow that you have entered all the data, we must create a launch configuration. Select Run Run..

6 Dates in CEP are entered as strings in the form: dd/mm/yyyy-hh:mm:ss. The expression builder can also be used to enter dates: select "Constants" on the left and "Absolute time" in the middle.


Illustration 24: The Simulation Data editor


from the toolbar. This will bring up the runtime configuration editor. Select “AMiT” then press the New button. In the Name: field, enter a name of “Bank_Run_1”, From the Project Name field, drop down the selection list and select “Bank_Project_1”.

For the Environment file field, enter: “..\eclipse\workspace\Bank_Project_1\Runtime\Environments\Environment1.env”.

For the Definitions file field, enter: “..\eclipse\workspace\Bank_Project_1\Runtime\Exports\bank_project_1.def”.

For the Simulation file field, enter: “..\eclipse\workspace\Bank_Project_1\Runtime\Inputs\Simulation1.scn”.

You should leave Data Rate at “1.0”. Press Apply. Hint: if the Run button is grayed out and there is a little red X, double check your entries. See the top of the dialog box for info on which file is in error. See Illustration 25: The Run Configuration Editor.

Finally, press the Run button. You will be placed into the AMIT Run perspective and you should see a screen that looks like Illustration 26: The Amit Run results.

The simulation results screen is divided into three sections. In the top left section we have a


Illustration 25: The Run Configuration Editor


graphical representation of lifespans, events and situations. The “X” axis of the graph represents time. Each “lighting bolt” icon represents an event received. Since we defined our Lifespans to start when an event was received, we see the lifespans represented by the red lines. Notice that there are three lifespans shown. This is because we entered data for three customers and we indicated in the lifespan definitions that they are to use event grouping keys. The “Y” axis represents the starting of a new lifespan. Each time a new lifspan is initiated, a new line appears along the “Y” axis.

On each lifespan line we see a second event. Because we defined situations to detect when an ATM_Withdrawal event was received, the second event causes the Possible_Fraud situation (represented by the icons with the multiple lightening bolts).

Note that it takes two events for each customer to cause the situation. The first event starts the lifespan and the second event detects the situation.

The bottom part of the screen shows the details panel. Here is a list of events and situations. You may select the expand button (+) to see more details for the events. If you expand the first event, you'll see the Customer_Number (which is shown because it is the event grouping key), the lifespan created (From_withdrawal) and the situation that might be detected (Possible_Fraud).

If you select the Properties tab in the bottom pane and then click on an event (or situation) in the run view, you will see all the attributes for that event. As you click on event and situation icons, you'll see the properties pane automatically update.

Close the perspective (right click on the perspective tab and select Close).


Illustration 26: The Amit Run results




Lab 2: Actually Detecting fraud

So far, we setup CEP to detect two ATM withdrawals for the same customer . Now we need to make a simple addition to detect whether or not those ATM's are more than 100 miles apart. We are going to take a shortcut and use the ATM_Id field as an indicator of the locations of the ATM's. So, for now, let the ATM Ids indicate how far the ATM is from 590 Madison Avenue in New York City7. Therefore, the ATM with an id of “1” is one mile away from 590 Madison. The ATM with an id of “51” is fifty-one miles away from 590 Madison, and so on.

In reality, a system would compute this distance by reading the location of the given ATM in a Cartesian co-ordinate system which would give a “x” and “y” location of the ATM from some fixed point on the globe. CEP provides a distance function which computes the distance between two points if the “x” and “y” coordinates of those points are specified. A real solution would be implemented by taking the ATM ID, querying a database to get the “x” and “y” coordinates, and then using the distance function to compute the actual distances between the ATMs.

We need to add a condition to the Possible_Fraud situation. The condition is simply this: if the difference of the two ATM_Ids is greater than 100 (miles), and the time of the withdrawals is less than 60 minutes, then the situation is detected. To form the expression, we subtract the second ATM_Id from the first and compare it to 100 and subtract the times and compare it to 3600000 (time in milliseconds):

Open the Possible_Fraud situation, then select the “Condition & Results” tab. In the Condition section, press the ellipses (“...”) button on the “Condition” like to use the Expression builder.

Now, remember that sit_ev is the alias for the second ATM_Withdrawal event and init_ev is the alias for the first event. Open the Possible_Fraud editor, select the Condition & Result tab, and enter the above expression in the Condition entry field. You can use the Expression Builder to enter this expression by clicking on the “Expression Builder button” (...) next to the Expression Input field. See Illustration 28 Usingthe Expression Builder.

7 And if thats not bad enough, we must assume all the ATM's radiate out from that point in a straight line.


Abs(sit_ev.Body.ATM.ATM_Id - init_ev.Body.ATM.ATM_Id) > 100 AND (sit_ev.Body.ATM.Withdrawal_Date - init_ev.Body.ATM.Withdrawal_Date < 3600000)



Illustration 27: The Situation editor Condition & Result tab


Save your changes (Ctrl+S), re-export your project definition (File... Export... AMIT Export to an XML File ... select Bank_Project_1 and ensure the destination is the same as above, click Finish. You should see a dialog box warning you that the file already exists, select Yes).

Rerun the simulator. (Run... run .. ensure the “Bank_Run_1” configuration is selected then press Run)


Illustration 28 Using the Expression Builder


You should see the output from Illustration 29: The simulation run with the enhanced situation. This time notice that only Customer 2 detects a situation. This is because Customer 2 made withdrawals from ATM's 1 and 102 (101 miles apart) in 59 minutes, whereas customer 1 made withdrawals from ATM's 1 and 21 in 30 minutes (okay, maybe it is impossible to travel 20 miles in New York City in one-half hour!) and customer 3 has gone 98 miles in 59 minutes. Close the AMiT Run tab.


Illustration 29: The simulation run with the enhanced situation


Lab 3: Resolving a little problem.Suppose we enter a little more data into the problem. Add the following data then save the file.


3 300 201 31/12/2004-13:15:00

Now the problem is that customer 3 made his second withdrawal at ATM 99 at 13:13:00 hours and has made a third withdrawal from ATM 201 at 13:15:00. He has traveled 102 miles in two minutes! Run the simulator with this new data and you'll see that no situation is detected!

The reason that no situation is detected is because our computation is always comparing the initial withdrawal event (init_ev) again the most recent event (sit_ev). This means we're comparing the withdrawal at ATM #201 against the withdrawal made at ATM #1 (200 miles in 1 hour and 1 minute). What we want to do is to always compare the last two events against each other. To do this, we cause each event to start its own lifespan, so the condition specified in the Possible_Fraud situation is always comparing the last two events.

We'll fix this up by changing some attributes of the lifespan. While we're at it, we'll add some attributes to our situation to make it easier to understand what is happening in the simulator.


Illustration 30: The simulation run -- no situation is detected for customer 3 !


Controlling the way Lifespans start

By default, when a lifespan is started by an event. However, other events of the same class and key do NOT start additional lifespans. We see this in our example because the 2nd ATM withdrawal does not cause a 2nd lifespan to start. However, to detect the situation above, we'll start a second lifespan when the 2nd

ATM event is received. To do this, go to the From_withdrawal lifespan editor and on the Initiators tab, press the Show Advanced button.

New attributes will appear for the ATM_Withdrawal event (namely Correlation and condition). Using the drop-down box under the Correlation column, change the correlation type from Ignore to Add. Exit the field and save your work with Ctrl+S.

What this says is that each time a ATM_Withdrawal event is received, start a new lifespan, even if a lifespan for this event already exists.

Export your project into the runtime definition and re-run the scenario. Your results should match Illustration 32: Situation for customer 3 is now detected.


Illustration 31: Adding the "add" correlation in the Lifespan editor


As you can see, this time the third withdrawal by customer 3 was detected.

Terminating LifespansFor various reasons, we don't want these lifespans active forever (as they currently are). Lifespans

take up resources and should be terminated once they are no longer useful. For this reason we'll terminate lifespans in two ways: (1) after 2 hours have passed8 or (2) when a Possible_Fraud situation is detected.

To make these changes, open the From_withdrawal lifespan editor and select the Terminator & Keys tab. Unclick the “Never Ends” checkbox. This will allow you to press the Edit button by Relative Time checkbox. Change Hours to “02” and press the Ok button. Now press the Add button by the By Events editor. In the Add Terminator Event dialog box, use the dropdown to select the Possible_Fraud situation and enter an alias of “pfraud_ev”. Click the Ok button and save your work with Ctrl+S. See Illustration 33: Specify termination conditions for a lifespan.

8 We choose two hours to ensure that delayed ATM_Withdrawal events are still processed. We're assuming there will be no more than an one hour delay.


Illustration 32: Situation for customer 3 is now detected


Now, you should see some errors concerning event grouping keys and the Possible_Fraud situation. We must add a second key segment to the Customer_Number_Key key so that CEP knows which attribute from the Possible_Fraud situation is to be used to determine which lifespans are to be terminated.

Open the Customer_Number_Key key editor and in the Key Segment section press the Add button. In the Add Key Segment editor, use the drop down box to select the Possible_Fraud situation and use the expression builder to enter an expression of “CustNumber”. Press OK. (see Illustration 34: Adding a secondkey to the Customer_Number_key) Remember that “CustNumber” is one of the attributes of the Possible_Fraud situation. (If you don't remember, go to the Possible Fraud situation editor and look at the attributes on the Condition & Result tab).


Illustration 33: Specify termination conditions for a lifespan


Save your work with Ctrl+S and re-export the project to the runtime. Rerun the simulator (see Illustration 35: The run with terminating lifespans, compare with previous run). The two new events (circled) are actually the situation events which are terminating the lifespans (in this case, they are terminating the lifespans started by the original withdrawal, we'll have more on controlling this later on).


Illustration 34: Adding a second key to the Customer_Number_key


Adding more attributes to situations.Perhaps you have noticed that its difficult to determine why a given situation was detected. If we

expand the situation in the Run View pane, we see the customer number and other information about the situation, but we'd like to see more. For this reason, we'll add two more attributes to the situation: ElapsedTime and Distance.

To do this, go to the Possible_Fraud situation editor and click on the Condition & Results tab. Select the Situation Attributes Add button and enter the information as show in the table (don't forget to use the expression builder to generate the expressions).

Name Type Expression

ElapsedTime double (sit_ev.Body.ATM.Withdrawal_Date – init_ev.Body.ATM.Withdrawal_Date)/1000

Distance Integer Abs(sit_ev.Body.ATM.ATM_Id – init_ev.Body.ATM.ATM_Id)

Save your work, re-export the project and re-run the simulator. You should now see these attributes


Illustration 35: The run with terminating lifespans, compare with previous run


for the Possible_Fraud situation (see Illustration 35: The run with terminating lifespans, compare withprevious run, bottom “Properties” pane).

Lab 4: An improvement in the logicInstead of detecting that the customer has traveled more than 100 miles in 60 minutes, it might make

more sense to compare the distance traveled against the time between the transactions. A more reasonable formula for the situation condition would then be:

This formula says that if the distance (in miles) is greater than the time (in minutes), then detect the situation. In other words, if they have traveled more than 60 miles per hour between ATM machines, we might have fraud. Enter this formula in the Condition field of the Possible_Fraud situation, replacing the formula we previously entered. Save your work, re-export the project and re-run the simulation.

See Illustration 36: Using the improved algorithm. However, there is a problem!

Remember that the new algorithm says that you can't travel more than a mile per minute between withdrawals. To see what the problem is, look at this table:


Abs(sit_ev.Body.ATM.ATM_Id – init_ev.Body.ATM.ATM_Id) > (sit_ev.Body.ATM.Withdrawal_Date – init_ev.Body.ATM.Withdrawal_Date ) / 60000

Illustration 36: Using the improved algorithm


Customer 1 2 3

Withdrawal 1 ATM 1 at 12:12:00 ATM 1 at 12:13:00 ATM 1 at 12:14:00

Withdrawal 2 ATM 21 at 12:44:00 ATM 102 at 13:12:00 (pfraud)

ATM 99 at 13:13:00 (pfraud)

Withdrawal 3 ATM 201 at 13:15:00 (pfraud)

You see that the Possible_Fraud situations were properly detected for customer 2 and the 2nd

withdrawal for customer 3, but we should have detected a third situation when customer 3 made his third withdrawal. Why didn't we?

The answer lies in the way we are terminating the lifespans. In CEP, when we terminate lifespans by events, we have choices as to which lifespans are terminated by a given event. The default is each, meaning every lifespan that is active with the same event grouping key as the terminating event is ended. So even though we started a new lifespan when the 3rd withdrawal arrived for customer 3, it was terminated when we detected the Possible_Fraud situation from the second lifespan. This is not what we wanted.

We will change the lifespan definition so only the first9 lifespan is terminated, not every lifespan. This way, only the lifespan that caused the situation to be detected is ended. To accomplish this, go to the From_withdrawal lifespan editor, select the Terminator & Keys tab, and in the Terminators section press the Show Advanced button. In the quantifier field of the ATM_Withdrawal event, use the dropdown to change the value from each to first. (See Illustration 37: Setting the Quantifier to "first") Save your work, re-export the project and re-run the simulation. You should now see a third situation detected (See Illustration 38: Customer "3" possible fraud now detected).

9 Actually, this doesn't really mean the First lifespan, it means the first lifespan that is still active.




Illustration 37: Setting the Quantifier to "first"


Backing Up Your workspaceNow would be a good time to take a checkpoint and backup your work. The simplest way to do this

is to take a copy of the exported definition file that we use in the simulation. Using the Windows explorer, navigate to this file (it should be called:

“..\eclipse\workspace\ATM_Project_1\Runtime\Exports\atm_project_1.def”) and make a copy of it to a safe place.

When you have a definitions file, you can import it into an existing AMIT Project and this will import the events, lifespans, keys and situations that we have defined. However, the Runtime artifacts are not saved in the definition file (that is, the Environment and Inputs files.) For this reason, you might want to take a copy of the entire project directory (“..\eclipse\workspace\Bank_Project_1\”) and keep it someplace safe.


Illustration 38: Customer "3" possible fraud now detected


Lab 5: Compound Event TypesWell, you might have noticed that there is still a fatal flaw in our logic: if a customer uses an ATM

at an airport, then gets on an airplane and travels a great distance, and then uses the ATM at the destination airport, we'll detect a Possible_Fraud situation (unless, of course, there are flight delays!). To correct this problem, we'll make a rule that says if three Possible_Fraud situations are detected within a twenty-four hour time period, we'll detect a second situation which we will call Fraud_Detected. This is an example of using situations as input events for other lifespans and situations. In this case, it's a situation (Possible_Fraud), that initiates a lifespan and second situation.

Creating the “For_24_Hours” lifespan To create a new lifespan, right click on the "Amit Navigator" pane, select New... then Lifespan. In

the New Lifespan dialog dialog box, ensure that Bank_Project_1 is selected and enter a lifespan name of “For_24_Hours”. Click Finish.

You are now in the lifespan editor. This lifespan will be initiated when rhe Possible_Fraud event occurs. Press the Add button in Event Initiator's Table pane. In the Add Initiator Event dialog box, use the dropdown to select the Possible_Fraud event. For an alias, type “init_pf_ev”. Press the OK button.

Now select the Terminator & Keys tab in that editor (at the bottom of the pane). In the Keys section, press the Add button and select Customer_Number_Key from the dropdown box, then press Ok. Press the Edit button by the Relative Time pane. Change Hours to “24” and press the Ok button. Save the lifespan by pressing Ctrl+S.

Creating the “Fraud_Detected” situation Right click on the AMIT perspective, select New... then Situation. In the New Situation dialog

dialog box, ensure that Bank_Project_1 is selected and enter a situation name of “Fraud_Detected”. In the Select Source... Empty of type...dropdown box, select nth. Click Finish. See Illustration 39: ThePossible_Fraud situation dialog.



In the Situation Editor, find the Add button in the Events section. Press the Add button. In the Add Event dialog box, use the dropdown to select the Possible_Fraud event. For an alias, enter “sit_pf_ev” and leave threshold blank. Click Ok.

Now select the Condition & Result tab in that editor (at the bottom of the pane). In the Condition section, select the dropdown box for Lifespan and select For_24_Hours. Change Detection Mode to Immediate and Quantity to “2”. If we didn't change the Detection Mode to immediate, then the situation would only be detected when the lifespans ends, which is 24 hours after we detected the first Possible_Fraud event. We want to be informed immediately about detected fraud, so we change the value to Immediate. We want the situation detected after three Possible_Fraud events, remembering that the first event starts the lifespan, we set Quantity to “2” to detect two more occurences.

In the Result section, click the Add button. In the Add Attribute dialog box, enter a name of “CustNumber”, select a Type of integer and for Expression enter “key.Customer_Number_Key” (You can use the expression builder to do this). Press OK then Ctrl+S to save your work.


Illustration 39: The Possible_Fraud situation dialog


Perhaps you'll notice that this time, for the situation attribute, we used an expression of key.Customer_Number_Key. This is a special syntax that says use the event grouping key as the value for this expression. Compare this to the expression we used when we created the Possible_Fraud situation.

Running the SimulatorWe need to add one more withdrawal for customer “3' to cause the Fraud_Detected situation to be

detected. Add this event:


3 300 601 31/12/2004-13:25:00

Re-export the project and run the simulator. See Illustration 41: AMiT run showing theFraud_Detected situation.


Illustration 40: Setting the attributes of the Fraud_Detected Situation


Notice this time that only customer 3 raises the Fraud_Detected situation. This is because customer 3 caused three Possible_Fraud situations to be detected. The first Possible_Fraud situation started the For_24_Hours lifespan. The next two situations counted towards the detection of the Fraud_Detected situation (remember we set Quantity to 2 in the editor).

Make a backup of your project.


Illustration 41: AMiT run showing the Fraud_Detected situation


Lab 6: Detecting Aggregation SituationsSo far, we have defined an ATM_Withdrawal event, a lifespan, event grouping keys and the

Possible_Fraud situation. This situation was based on receiving two withdrawal events that are geographically distant yet close in time. We also showed how you can use a situation as an input event to a second situation. Now, what we would like to do is to detect a situation where too much money is withdrawn by a single customer from ATM's in a single 24 hour period.

To do this, we will create a new lifespan which will start when the first ATM_Withdrawal event is received and lasts for 24 hours. We will then create a new situation which will aggregate (sum) the amount of the withdrawals during this lifespan. If the amount of withdrawals exceeds $1000, then the new situation will be detected.

The situation we will create will be of the crosses type. A crosses situation is used to detect when the sum of a given field in its events crosses a value10. In our example, we'll be summing the Withdrawal_Amount field and comparing that sum to the value “1000”. We could have used the “report” operator as well. For a brief description of all the operators, see Advanced CEP Features on page 73.

Creating the “withdrawal_Start” lifespanBefore we start, lets create a new project called “Bank_Project_2” to work in. See Creating the

Bank_Project_1 AMiT Project on page 12 for instructions on creating AMIT projects.

Next, recreate the “ATM_Withdrawal” event in the new project. You might find it easier to type event attributes directly into the “event/type” table by clicking on a row and typing the attribute name instead of pressing the Add button.11

We also need to recreate the event grouping key, see Creating the Event Grouping Keys on page 16. The event grouping key should only contain the ATM_withdrawal event, not the Possible_Fraud event in the key segments. 11

To create a new lifespan, right click on the "AMiT Navigator" pane, select New... then Lifespan. In the New Lifespan dialog dialog box, ensure that Bank_Project_2 is selected and enter a lifespan name of “From_Withdrawal”.

Under the Event Initiator's Table use the Add button to add an event. In the Add Initiator Event dialog box, use the dropdown to select the ATM_Withdrawal event. For an alias, type “init2_ev”. Press the OK button.

Now select the Terminator & Keys tab in that editor (at the bottom of the pane). Select the Customer_Number_Key as the event grouping key for this lifespan. Click Finish. For a terminator, enter a relative time of 24 hours.

Save your work with Ctrl+S.

Creating the “Too_Much_Withdrawn” situationCreate a new situation in the Bank_Project_2 project called “Too_Much_Withdrawn”. Use the

dropdown box to make the Source type an “Empty of Type ... crosses” type. Press the Finish button.

In the situation editor, click the Show Advanced button in the Events section. Then press the Add

10 Other operators are support in addition to sum. We can use: maximum, minimum and average.11 It is also possible to use eclipse's cut and paste capability to copy the event, key and lifespan definitions

from Bank_Project_1 directly to Bank_Project_2. Don't forget to change the init_ev alias to init2_ev in the lifespan and delete the Possible_Fraud event from the grouping key and lifespan. Lastly, you should change the correlation in the lifespan back to “ignore”.



button in that section.

Select the ATM_Withdrawal event, give it an alias name of “sit2_ev”. For the Sum Expression field, enter “sit2_ev.Body.ATM.Withdrawal_Amount” using the expression builder and enter “true” for the Sum Condition field. This tells CEP to keep a running sum based on the Withdrawal_Amount attribute of the ATM_Withdrawal event. The value true in the Sum Condition field indicates that we always want to include this event. We could put a condition in that field if we wanted to exclude some events. Press OK. See Illustration 42: The "Advanced" add event dialog.

On the Condition & Results tab, select the “From_Withdrawal” lifespan. For Status Function enter “sit2_ev.sum+init2_ev.Body.ATM.Withdrawal_Amount” and enter “(1000)” for Boundaries(X,Y,Z,...). The special keyword sum is used in this expression to indicate that we want to test using the “sum expression” of the sit2_ev event. (remember that the sum expression was sit2_ev.Body.ATM.Withdrawal_Amount.) One of the properties of the crosses type situation is that the event that initiated the lifespan is not included in the summing operator. To compensate for this, we must therefore add init2_ev.Body.ATM.Withdrawal_Amount to the expression.

In the Result section, click the Add button. In the Add Attribute dialog box, enter a name of “CustNumber”, select a Type of integer and for Expression enter “key.Customer_Number_Key”. Press Ctrl+S to save your work. Add a second attribute with a name of “AmountWithdrawn”, a type of “double” and an expression of “sit2_ev.sum +init2_ev.Body.ATM.Withdrawal_Amount”. See Illustration 43: Specifying Status Function and Boundary.


Illustration 42: The "Advanced" add event dialog


Running the Simulator.Before we can run the simulator, we need to create the runtime environment.

1. Create an Environment file. See “Creating the Environment File“ on page 28

2. Export Bank_Project_2 into the Exports directory of the project. We recommend you name the file “Bank_Project_2” See “Exporting the Project into an XML file“ on page 28

3. Create the simulation data. You should use eclipse's cut and paste facility to copy the simulation1.scn file from the ..\Bank_Project_1\Runtime\Inputs directory to ..\Bank_Project_2\Runtime\Inputs directory.

4. Create a new launch configuration called “Bank_Run_2”, specifying the above listed files. See “Creatingthe Launch Configuration“ on page 31.

5. Run the simulation.


Illustration 43: Specifying Status Function and Boundary


You should see one instance of a the Too_Much_Withdrawn situation and if you look at the attributes of that situation you'll see that CustNumber is “3” and the AmountWithdrawn is “1040.0”. Remember that customer 3 made four withdrawals: $140, $300, $300 and $300 dollars.

You should also be aware that when we set the lifespan to “24 hours” that is really 24 hours and we would have to run the simulator for 24 hours before the lifespan terminated.


Illustration 44: The "Too_much_Withdrawn" situation


Lab 7: Multiple Event Classes and the not situation.So far, we have explored three types of situations: all, nth and crosses. The all situation says that all

the events listed in the situation must arrive (in any order). We only had one event defined, so this was a trivial use of this operator. The nth situation detects the situation when the nth event arrives, in our case we used it to detect the third Possible_Fraud situation. And then we used the crosses situation to detect when more than $1000 had been withdrawn from an account.

For our last situation, we'll use the not situation type. This situation is detected if an event is not received. We'll have to change our example a bit to make good use of this situation. For this situation we'll track Internet orders for online stock purchases. Well use CEP to track orders that are sent to an equities purchasing system and ensure that we get an “order executed” response within a reasonable period of time (10 seconds).

We'll define two event classes in this example: the “stockOrder” event and the “orderResponse” event. Begin by creating a new project “Online_Trades_Project” See “ Creating the Bank_Project_1 AMiTProject“ on page 12 for instructions on creating AMIT projects, but do not create any new event classes yet.

Defining the event classesUsing the Event Class editor, create the “stockOrder” event. Give the event the following attributes:

Attribute Type

Body.stockOrder.customer string

Body.stockOrder.symbol string

Body.stockOrder.quantity integer

Then create the “orderResponse” event with the following attributes:

Attribute Type

Body.orderResponse.customer string

Body.orderResponse.responseType string

Body.orderResponse.symbol string

Body.orderResponse.quantity integer

Body.orderResponse.totalCost double

The attribute responseType has one of these values: “received” , “rejected”, or “purchased”.

Defining the grouping keysUsing the Key editor, create an event grouping key with a name of “Customer_Key”. Make the key

type “string”. Create two key segments:

Event Expression

stockOrder stockOrder.Body.stockOrder.customer

orderResponse orderResponse.Body.orderResponse.customer



Unlike the previous projects, this project requires a more complex key structure. We could group events by only the customer identifier, but a given customer might make two or more purchases for stock (they might want to buy IBM and Microsoft). To properly correlate the response with the order, we'll also match the stock symbol and the quantity. To do this, create two more event grouping keys.

Using the Key editor, create an event grouping key with a name of “Symbol_Key”. Make the key type “string”. Create two key segments:

Event Expression

stockOrder stockOrder.Body.stockOrder.symbol

orderResponse orderResponse.Body.orderResponse.symbol

Using the Key editor, create an event grouping key with a name of “Quantity_Key”. Make the key type “integer”. Create two key segments:

Event Expression

stockOrder stockOrder.Body.stockOrder.quantity

orderResponse orderResponse.Body.orderResponse.quantity

Defining the lifespan Using the lifespan editor, create a lifespan named “Ten_seconds”. This lifespan will be initiated by

the stockOrder event (use an alias of “init_so”). Add the three event grouping keys we defined above to the lifespan and set the lifespan terminator to be a relative time of 10 seconds.

Defining the situationUsing the situation editor, create a situation named “order_not_executed”, empty of type: not. In

the section where the event is “not to occur”, select the orderResponse event. Give an alias of “st_or” and specify a Threshold Condition of “Body.orderResponse.responseType = 'purchased'”. Specify the Ten_seconds lifespan and use the following table to specify the results.

Attribute Type Expression

Customer string key.Customer_Key

Symbol string key.Symbol_Key

Quantity integer key.Quantity_Key



Running the simulationCreate a runtime environment as we did in the prior projects. Don't forget to export your project

definition into the Exports folder. Now we must create test data. The following figure shows the XML representation of the data that must be used. You may either use the simulation editor to enter these events and their attributes one at a time, or create a simulation file, close the editor, and then use notepad to cut and paste the given XML into the simulation1.scn file in the ..\Runtime\Inputs directory of the Online_Trades_Project directory.


Illustration 45: Threshold condition for Lab 3


Now run the simulator, you should see results that looks like Illustration 46: The Online TradeProject simulation run.


<?xml version="1.0" encoding="UTF-8"?><amt xmlns="http://www.ibm.com/amt/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/amt/ amt.xsd"> <scenario name="Simulation1" updateDefinition="add"> <identification createdBy="mayab" createdOn="5/25/06"/> <instance name="stockOrder"> <attribute name="Body.stockOrder.customer" value="Wayne"/> <attribute name="Body.stockOrder.symbol" value="ibm"/> <attribute name="Body.stockOrder.orderTime" value="31/12/2004-13:25:00"/> <attribute name="Body.stockOrder.quantity" value="100"/> </instance> <instance name="stockOrder"> <attribute name="Body.stockOrder.customer" value="Jeff"/> <attribute name="Body.stockOrder.symbol" value="msft"/> <attribute name="Body.stockOrder.orderTime" value="31/12/2004-13:25:00"/> <attribute name="Body.stockOrder.quantity" value="10"/> </instance> <instance name="stockOrder"> <attribute name="Body.stockOrder.customer" value="Dror"/> <attribute name="Body.stockOrder.symbol" value="msft"/> <attribute name="Body.stockOrder.orderTime" value="31/12/2004-13:25:00"/> <attribute name="Body.stockOrder.quantity" value="1"/> </instance> <instance name="stockOrder"> <attribute name="Body.stockOrder.customer" value="Dror"/> <attribute name="Body.stockOrder.symbol" value="ibm"/> <attribute name="Body.stockOrder.orderTime" value="31/12/2004-13:25:00"/> <attribute name="Body.stockOrder.quantity" value="1000"/> </instance> <instance name="orderResponse"> <attribute name="Body.orderResponse.totalCost" value="1000.00"/> <attribute name="Body.orderResponse.purchaseTime" value="31/12/2004-13:25:00"/> <attribute name="Body.orderResponse.quantity" value="10"/> <attribute name="Body.orderResponse.customer" value="Jeff"/> <attribute name="Body.orderResponse.responseType" value="received"/> <attribute name="Body.orderResponse.symbol" value="msft"/> </instance> <instance name="orderResponse"> <attribute name="Body.orderResponse.totalCost" value="1000.00"/> <attribute name="Body.orderResponse.purchaseTime" value="31/12/2004-13:25:00"/> <attribute name="Body.orderResponse.quantity" value="50"/> <attribute name="Body.orderResponse.customer" value="Dror"/> <attribute name="Body.orderResponse.responseType" value="purchased"/> <attribute name="Body.orderResponse.symbol" value="ibm"/> </instance> <instance name="orderResponse"> <attribute name="Body.orderResponse.totalCost" value="1000.00"/> <attribute name="Body.orderResponse.purchaseTime" value="31/12/2004-13:25:00"/> <attribute name="Body.orderResponse.quantity" value="1"/> <attribute name="Body.orderResponse.customer" value="Dror"/> <attribute name="Body.orderResponse.responseType" value="purchased"/> <attribute name="Body.orderResponse.symbol" value="msft"/> </instance> </scenario></amt>

Test data for the Online_Trades_Project


Notice that since the order for IBM stock by Wayne was never acknowledged, this cause a situation to be detected. The order placed by Jeff was acknowledged, but only with a responseType of “received”.

This event message was not counted because of the threshold we entered into the situation definition: Body.orderResponse.responseType = 'purchased'. The first responses for Dror did not count because they although it had a response type of purchased, it did not match any order quantity (i.e., there was no order by Dror for 50 shares of IBM stock. The last response message did match, because the type was “purchased”, the customer matched (Dror), the symbol matched (msft) and the quantity matched (1).


Illustration 46: The Online Trade Project simulation run


Making it work in the BrokerIn this section, we'll finish the installation of CEP so that we can actually run in the WebSphere

Business Integration Message Broker environment.

CEP delivers two nodes that you can use in a message flow:

The SituationManager node can be wired into a flow as an observer. This means that it receives events on its input terminal and propagates these events unchanged to its output terminal. However, it is using these events that pass thru to monitor for the initiation and termination of lifespans and the detection of situations. When a situation is detected, the node will create an WebSphere MQ message and place this message on a designated queue.

The IntelligentFilter node can also be wired into a flow. However, in addition to being able to detect situations, it can also affect the routing of the incoming events to different output terminals (similar to a normal broker filter node). If a situation has been detected, then the routing of input events can be altered.

In this section we assume that you have installed and configured the WebSphere Message Broker toolkit, Configuration Manager and the Broker itself (the execution engine).

Before we start, refresh your memory about this project by re-reading the “Lab 1: Your FirstComplex Event3” chapter on page 12.

Installing Toolkit and Broker PluginsThe supportPac User's Guide located in the supportPac gives instructions for configuring the broker

toolkit and broker execution engine to use CEP. You should read the relevant chapters in that manual and ensure that both the plugins for the eclipse toolkit and the plugin (PAR file) for the Message Broker have been properly installed.

Lab 8: Using the SituationManager node in a flowWe'll use the first CEP project we created: Bank_Project_1, in our exercise. These are the steps

we'll follow:

1. From the CEP editor, export the Bank_Project_1

2. Create the queues necessary for the message flow

3. Create a message flow using the SituationManager node.

4. Deploy the flow to the broker

5. Create test data and load the data onto the input queue

6. Inspect the results.

Exporting the project definition From the CEP editor, export the project definition for the Bank_Project_1 (using the AMIT –

Export to an XML file option) to the file: “c:\temp\ bank_project_1.def”12 See Exporting the Project into anXML file on page 28.

12 Normally, we wouldn't export these to a “temporary” directory but instead we would export the definitions to a directory under the MQ broker tree. We're just doing this for demonstration purposes today. Also, this assumes you have a directory called: “c:\temp”.



Create the MQ Queues

Using the MQ Explorer, create the following queues as local queues on the queue manager that the MQ Broker uses:

• CEP.BANK1.IN

• CEP.BANK1.OUT

• CEP.BANK1.SITUATION

• CEP.BANK1.CONTROL

These queues will be used as the input and output event message queues for our first flow, the queue where situation messages will be placed by CEP, and a special queue used by CEP to reload CEP definitions when we change them (this allows us to reload definitions without needing to restart the broker itself) and to change the CEP tracing level.

Create the Message flow

Using the Broker toolkit, create a new message flow project (call it “Bank_MsgFlowProject_1”) and then create a new message flow within that project. (called “Bank_MsgFlow_1”). Place two “MQ Input” nodes and an “MQ Output” node on the editor pane. If you properly installed the CEP toolkit components, you should see a folder for “AMIT” and a situation node (its the node with the ampersand “&” as its icon). See “ Illustration 47: The AMiT Nodes“. Place the situationManager node on the editor pane and wire the


Illustration 47: The AMiT Nodes


output terminals of the two “MQ Input” nodes to the “Control” and “Input” terminals of the situationManager node. Then wire the “Output” terminal of the situationManager node to the input terminal of the “MQ Output” node.

Change the name and the “queue” property of the “MQ Input” node which is connected to the situationManager input terminal to “CEP.BANK1.IN”. Also change the “message domain” to “XML”.

Change the name and the “queue” property of the “MQ Input” node which is connected to the situationManager control terminal to “CEP.BANK1.CONTROL”. Also change the “message domain” to “XML”.

Change the name and the “queue” property of the “MQ Output” node which is connected to the situationManager output terminal to “CEP.BANK1.OUT”.

Now, open the properties dialog of the situationManager node. Use the following table to set the attributes on the “Basic” tab.

Attribute Meaning Set attribute to this value

outputQueue List of queues to which situation messages should be sent

“CEP.BANK1.SITUATION”

messageNaming The name of the field which identifies the event class

Body.ATM.Ev13

amitDefinitonFile Name of flat file holding CEP exported configuration

“c:\temp\bank_project_1.def”

13 CEP determines the name of the event by combining the XML root name (“ATM” in our case) with the value of the field pointed to by the messageNaming attribute. In our case, we specified “Body.ATM.Ev” as the field, and it will have a value of “Withdrawal”. The combination of the two fields gives us “ATM_Withdrawal”.


Illustration 48: The AMiT Message Flow



logDirectory Directory where CEP will write log files

“c:\temp”

logLevel Level of logging detail “INFO”

Ensure that the check boxes for “amitDefinitionFile”, “messageNaming” and “logDirectory” are checked. Save your changes and save the message flow.

Deploy the Message flowConnect to your local configuration manager in the “Broker Administration Perspectice”. Then,

create a bar file and deploy the flow to the broker. Make sure to check that the deploy succeeded by viewing the messages in the “Event Log”

Create and Load Test Data We'll now create a number of MQ messages to feed into our message flow. Using your favorite

editor, create these messages:


Illustration 49: The Situation Manager Node properties dialog


Using your favorite utility to load these messages into the CEP.BANK1.IN queue. Do not use amqsput as it will truncate the messages. (example: using the q.exe for supportPac MA01 by Paul Clarke, issue: q.exe -oCEP.BANK1.IN -mWBRK_QM -f bank1_project.msgs) The first time you run this, you might want to use the Flow Debugger in the broker toolkit to ensure you have a properly formed message.

Inspect the resultsAfter running the data through the broker, you should have five messages on the situation queue.

Four messages should be Possible_Fraud situations and one message should be a Fraud_Detected message. Using either the MQ Explorer or RFHUTIL (supportPac IH03 by Jim McNair), view the CEP.BANK1.SITUATION queue and you should see possible_fraud situation messages (See Illustration 50: The "possible_fraud" situation messsage.) and Fraud_Detected situation messages (See Illustration 51: The"Fraud_Detected" situation message.).

If there are errors in CEP, they will be in the file: “c:\temp\<broker-name>-<execution group>-Bank_MsgFlow_1-SituationManager.log”. You should look at this file to ensure that CEP is working the way we intend.

Now is the time to remember that CEP is a stateful technology. This means we cannot simply re-run the test data into the broker, because CEP remembers the state of the previous data (and it would think that time is going backwards). So, before running further test cases, you must shutdown and restart the broker if it is necessary to cause CEP to forget its state. We'll have more to say about this in “Advanced CEP Features“ later.


<ATM Ev="Withdrawal" ATM_Id="1" Withdrawal_Amount="250" Customer_Number="1" Withdrawal_Date="31/12/2004-12:12:00"></ATM>








Test Data for Bank_Project_1 and Bank_Project_2



Illustration 50: The "possible_fraud" situation messsage


Internal SituationsYou'll notice that in addition to the Fraud_Detected situation message, we received Possible_Fraud

situation messages. We might decide that we don't want the Possible_Fraud situation messages in our system. We can tell CEP not to generate these messages by marking them as internal.

Go to the Possible_Fraud editor in the CEP toolkit, and on the Condition & Result tab, select “Show Advanced” in the Condition section. You should then be able to check mark the Internal checkbox. Save your change, and reexport the definition to “c:\temp\ bank_project_1.def”. See Illustration 52: Makingthe situation an internal event.

Restart the broker (mqsistop WBRK_BROKER/ mqsistart WBRK_BROKER) and rerun the test data from above and you see only the Fraud_Detected situation message. You do not see Possible_Fraud situations anymore because they have been marked as internal situations and therefore messages are not created in the situation queues.


Illustration 51: The "Fraud_Detected" situation message



Illustration 52: Making the situation an internal event


Lab 9: Using the IntelligentFilter node in a flowNow, we'll deploy the second bank project (Bank_Project_2) into a message flow where we will be

using the IntelligentFilter node. This node is similar to the normal broker Filter node in that it can route messages to one of two output terminals. If no situation has been detected, then any message received on the Input terminal is routed to the Out terminal. If a situation has been detected, then the message which caused the situation is routed to the conditionalOut terminal.

Before we start, refresh your memory about this project by re-reading the “Lab 6: DetectingAggregation Situations” chapter on page 53.

Deploying and running the flow

Create the following local queues:

• CEP.BANK2.IN

• CEP.BANK2.CONTROL

• CEP.BANK2.OUT

• CEP.BANK2.CONDITIONAL.OUT

Create a new message flow project (“Bank_MsgFlowProject_2”) and then a new message flow (“Bank_MsgFlow_2”). Drag two MQInput nodes and two MQOutput nodes to the editor and then drag an IntelligentFilter node. Wire the output terminals of the two “MQ Input” nodes to the “Control” and “Input” terminals of the situationManager node. Then wire the “Out” and “conditionalOut” terminals of the IntelligentFilter node to the input terminal of two “MQ Output” nodes.

Change the name and the “queue” property of the “MQ Input” node which is connected to the intelligentFilter input terminal to “CEP.BANK2.IN”. Also change the “message domain” to “XML”.

Change the name and the “queue” property of the “MQ Input” node which is connected to the intelligentFilter control terminal to “CEP.BANK2.CONTROL”. Also change the “message domain” to “XML”.

Change the name and the “queue” property of the “MQ Output” node which is connected to the intelligentFilter out terminal to “CEP.BANK2.OUT”. Change the name and the “queue” property of the “MQ Output” node which is connected to the intelligentFilter conditionalOut terminal to “CEP.BANK2.CONDITIONAL.OUT”.



Now, open the properties dialog of the intelligentFilter node. Use the following table to set the attributes on the “Basic” tab.


messageNaming The name of the field which identifies the event class

Body.ATM.Ev

amitDefinitonFile Name of flat file holding CEP exported configuration

“c:\temp\bank_project_2.def”

logDirectory Directory where CEP will write log files

“c:\temp”

logLevel Level of logging detail “INFO”

Save the message flow, add it to a BAR file and deploy it to your broker.

From the CEP editor, export the project definition for the Bank_Project_2 (using the AMIT – Export to an XML file option) to the file: “c:\temp\ Bank_Project_2.def” See Exporting the Project into anXML file on page 28.

Using the same data we used in the previous exercise, load the data into the CEP.BANK2.IN queues. Using the MQ explorer, you should see that 7 messages went to the CEP.BANK2.OUT queue and the last message went to the CEP.BANK2.CONDITIONAL.OUT queue. This is because the last event message (for customer 3) caused the daily limit of $1000 to be exceeded and therefore the message itself was rerouted to a different queue.

We see that the intelligentFilter node reroutes the ATM transaction based on the fact that this transaction caused a situation (the Too_Much_Withdrawn situation.) However, if you were to send the last test message again into the broker (the withdrawal for $300 at ATM 601 by customer 3), that message would not be re-routed. This last message does not cause the situation to be detected again because the situation is only detected when the sum crosses $1000 (that is, when the sum goes from less than $1000 to more than


Illustration 53: Message flow with Intelligent Filer node


$1000). This is not the behavior we probably want.

To remedy this problem, we'll create a second lifespan that is initiated when the Too_Much_Withdrawn is detected and a second situation using that lifespan. This second situation will be detected whenever any ATM_Withdrawal is received for the customer that caused the Too_Much_Withdrawn situation.

Create a lifespan named “situation_Detected”. Set the lifespan to start when a Too_Much_Withdrawn event is received (use an alias of “init3_ev”). For the key, use Customer_Number_key. Set the terminator to Never Ends. Save this lifespan.

You'll need to add the CustNumber attribute of the Too_Much_Withdrawn event as a key segment to the Customer_Number_key. Save the key.

Now create a new situation called “block_withdrawals” of type “all”. Specify the ATM_Withdrawal event in the Events section using an alias of “atmw”. For the lifespan, select situation_Detected. Have the result of the situation be named “CustNumber” of type integer using an expression of “key.Customer_Number_Key”.

Save your work and re-export the project definition to “c:\temp\ bank_project_2.def”. Restart the broker and rerun the original data set along with the additional ATM withdrawal transaction for customer three. This time, you should see two messages in the CEP.BANK2.CONDITIONAL.OUT queue. One for the message that caused the Too_Much_Withdrawn situation and one for the block_Withdrawals situation.



Advanced CEP FeaturesThis section describes other advanced features of IBM's CEP that you should be aware of. All of

this material is excerpted from the CEP and supportPac User's Guide. You should refer to those manuals for complete information on these topics.

Thirteen situation operators. A quick description of them follows. See the User's guide for more information.

• Join operators

• All: the situation is detected if all the listed events arrive in any order.

• Sequence: the situation is detected if all the listed events arrive in exactly the order of the operands.

• Count operators

• At least: at least n events that satisfy the conditions during the lifespan.

• At most: at most n events that satisfy the conditions by the end of the lifespan.

• N-th: the situation is detected when the nth event arrives during the lifespan.

• Absence operators

• Not: none of the listed events have arrived during the lifespan.

• Unless: if at least one instance of the first event class occurred and no instances of the second event class occurred during the lifespan. Only two event classes are allowed.

• Temporal operators

• Every: the situation is detected every x time units since it was initiated.

• After: the situation is detected x time units after an event has occurred (this event is called the triggering event).

• At: the situation is detected at the time specified in the timePattern attribute of the situation. The time pattern format is: dd/mm/yyyy hr:min:sec. The time pattern can be specified using wild cards (not yet implemented).

• Aggregation operators

• Report: enables the detection of a situation regardless of any condition. For example: alert if more than 100 requests weren t handled on time.

• Percentage: detects a situation when the calculated percentage passes a predefined percentage.

• Crosses: detects a situation when some predefined boundaries are crossed within a certain resolution. For example, report whenever the average service time of requests that were handled crosses (minServiceTime, maxServiceTime) minutes.

Templates Templates allow subject matter experts to write lifespan and situation definitions which contain one

or more parameters. Templates contain all the elements of the situations or lifespans, with the ability to specify a variable instead of part of the definition. As an example, if you wanted to terminate a lifespan at an absolute time, (say at 5pm each day), you could define a lifespan with a termination of “absolute time”. However, when you specify absolute time as a terminator, you need to specify the date and time values. Templates allow you to specify the time by using a variable (variables are enclose in dollar signs, example:



$termTime$). When creating situations or lifespans, you can use a template as the “base definition”. You may specify a value for the template parameters at build time (when you are in the editor), or templates can receive their paramters at run time. Templates are either static, meaning that all the template parameters are specified at build-time or dynamic, meaning that parameters will be resolved at run-time.

Using a Database to Store CEP's StateAs described in the CEP manual, CEP can store part of its state in a database instead of in memory.

This is particularly important in cases where the definitions contain long lifespans, and where holding the state in memory can be costly. At build time, the CEP Toolkit allows you to specify for each situations if its state will be stored in memory or in a database.

Using a Recovery DatabaseAs described in the manual, CEP can periodically store its state in a database in order to be able to

recover from failures. In order to use the recovery feature, you should define in the node's properties editor the name of the JDBC driver to use, as well as the URL of the database, the username and the password to use, and two additional parameters that will be used to fine-tune the process of writing recovery data into the database. More details about these parameters can be found in the CEP manual.

Reading CEP definitions from a databaseThe SituationManager and IntelligentFilter nodes can read CEP definitions from either a file (the

XML file created by the CEP Toolkit) or a database. If the definitions are to be read from a database, you should define in the node's properties editor the name of the JDBC driver to use, as well as the URL of the database, the username and the password to use, the name of the table to use, and the ID of the definitions that the node should load. Please note that the password you enter in the node's properties editor is not encrypted. The Toolkit can export definitions to a database. Each set of definitions you export is given an ID that is used by the node to identify the definition set. In addition, each time you export a set of definitions, a timestamp is kept. Each time definitions are loaded, the node will load the set of definitions with the latest timestamp.

Runtime control messagesThe SituationManager and IntelligentFilter nodes have a control input terminal. This input terminal

is used to accept control message that trigger administrative tasks in the node.

Triggering a reload of the CEP definitions from the definition file or database.

The message format is:

<AMiTControlMessage> <updateDefinitions> </updateDefinitions> </AmiTControlMessage>

Changing the log level of the node.

LEVEL can be one of the following: SYSTEM, ERROR, WARNING, INFO, DEBUG.

Message format is:

<AMiTControlMessage> <setLogLevel> <newLogLevel>LEVEL</newLogLevel> </setLogLevel> </AmiTControlMessage>

Rule sets In order to efficiently manage a large number of rules, you can group them in rule sets. Rule sets are

created as an ordinary resource. When creating a new rule resource, you are prompted whether to put the new resource in the default location or in a rule set. In the latter case, you have to choose a rule set out of a rule set list.



LocalEnvironment enrichmentThe IntelligentFilter node always add information about the detected situation to the “CEP” folder of

the “LocalEnvironment” tree. The information added includes both the name of the detected situation and all its attributes. See Illustration 54: LocalEnvironment enrichment by the Intelligent Filter node.

RouterList EnrichmentIn scenarios where the IntelligentFilter node feeds messages to a 'RouteToLabel' node, the node can

set the label to which the message will be routed to. The IntelligentFilter node can write the names of the detected situations into the "Destination.RouterList" sub-tree of the local WebSphere MQ Integrator Thus, a message output by the IntelligentFilter node can be fed into a RouteToLabel node, and dynamically routed to an appropriate part of the flow. This behavior is controlled by the “enrichRouteDestination” property setting of the “Routing” tab of the Intelligent Filter node.

MQDestinationList EnrichmentThe IntelligentFilter node can be used to set the destination queue to which an MQOutputNode will

write the message. The node can write the names of the detected situations into the "Destination.MQDestinationList" (or "Destination.MQ") sub-tree of the local environment of the message. Thus, a message output by the IntelligentFilter node can be fed into an MQOutputNode node, and dynamically written to an appropriate queue or queues. If the detected situation contains an attribute called "queueName", then the value of this attribute is the one written to the MQDestinationList. Otherwise, the name of the situation itself is assumed to be the queue name. This behavior is controlled by the “enrichMQDestination” property setting of the “Routing” tab of the Intelligent Filter node.


Illustration 54: LocalEnvironment enrichment by the Intelligent Filter node


*** End of Document ***



Documents

Getting Started with Complex Event Processing Nodes · CEP and the WebSphere Message Broker ... Version 1.2 Getting Started with Complex Event Processing Nodes ... Version 1.2 Getting