soa ch19 online chapter complement cep partone

7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne

1/52

Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011

19-1

(pn)Part IV

(pt)Beyond the Basics

(cn)Chapter 19

(ct)From live data to real-time insight and action using Complex Event Processing and Business

Activity Monitor

(1)Monitoring temperature sensors

St Matthews is going to put CEP to good use. All over the hospital, it has many hundreds

of temperature sensors, in dozens of areas (floors, wards, buildings), measuring the temperature

in maternity wards, normal patients rooms, refrigerating storage units and other places. These

sensors report the temperature once every few seconds. Sensors are configured in clusters ofthree: the temperature is to be calculated per unit by taking the average of these three sensors.

This cluster arrangement ensures that up to two sensors can break down without the knowledge

of the temperature at its location being lost.

All these sensors produce up to 100,000 signals per hour. And CEP comes to the rescue

as most of these can be discarded right away; if we learn about the temperature in a room or

fridge once every minute, that would be quite enough. And because when we do need to respond,

we probably should do so instantaneouslyin real time.

Some of the information we hope to learn from all the temperature signals and the

actions we may need to trigger as a result:

- Find failing heaters or open windows (detected from sudden temperature drops ,steady decline, deviation of more than 3 degrees Fahrenheit from 66F)

- Discover potential fires- Find failing refrigerating equipment (steady increase in temperature above the preset

temperature)

- Report on average temperature in special areas like maternity wards and intensivecare units

- Find faulty sensors (no signal for longer than 30 seconds)


2/52


19-2

Lets see how we can set up CEP to get some of these answers.

(2)Getting started with CEP

We will assume here that you have installed Oracle CEP 11g Server as well as Eclipse

with the Oracle CEP plugin (for example following the instructions in the Online Chapter

Complement on installation.

Another preparation that needs to be made is the configuration of a JMS Queue with

JNDI name jms/temperatureReadingsQueue. For convenience sake later on, we will create all

JMS artefacts in the SOA Module and target them at the SOA server:

(3)Creating the JMS Queue

Open the WebLogic Server Administration Console at http://localhost:7001/console.

Open the node Services, then Messages and click on node JMS Modules:


3/52


19-3

Click on the SOAJMSModule in the table.

Click on the New button above the table of currently available JMS resources.


4/52


19-4

Select Queue as Resource Type, then click on Next.


5/52


19-5

Enter the name (temperatureReadingsQueue) and JNDI name jms/temperatureReadingsQueue.

Click on Next.


6/52


19-6

Select the SOAJMSServer as target and press the Finish button.

The new JMS Queue is created and will be available for the CEP applications we are about to

create for publishing events to and consuming events from. JMS Queues will be used to

communicate with Oracle BAM as well as with the SOA Suite.


7/52


19-7

(2)The temperature sensors simulator

In your development environment, you may not have hundreds of temperature sensors

that send temperature readings to JMS queues every other second and neither have I. In

preparation for the next steps where we want CEP to find the average temperature per room or

clinic and detect faulty sensors and spot fire, we need to set up a simulation of those sensors. One

way of doing this, would be to create a simple Java application that puts messages onto a JMS

Queue. However, we can also use CEP itself to do this. A simple CEP application will be able to:


8/52


19-8

Use a custom adapter to create temperatureReadingEventssimple POJOs thatcarry the temperature value and the sensors identification

Channel these events to a JMS queuethat makes these events available tovarious consumers including a second CEP applicationthe one that could alsobe used to process the real temperature sensor readings

Such an application that simulates or provides a mock implementation of the real event

producers is frequently useful to develop and test a CEP application as we may not have access

to real events during development and we definitely have a need to explicitly hide needles in

haystacks in order to thoroughly test our CEP applications capability to find those needles.

(3)Steps for creating the TemperatureReadingsSimulator application

A high level overview of the steps we go through in creating our first real CEP application:

1. Create new Oracle CEP project in Eclipse, based on the HelloWorld template; this

template adds some initial objects to the application that serve as a good example of what we

need to develop ourselves, including a simple EPN and an example of a custom adapter (class

HelloWorldAdapter).

2. Rename file META-INF/spring/helloworld-context.xml to

temperatureSensorSimulator-context.xml. This file contains the Event Processing Network

(EPN), the heart of the application (or rather the brains).

3. Create a new class called TemperatureSensorSimulator. It implements the CEP

interface StreamSourcewith a single method setEventSender that allows the CEP framework

to inject the StreamSender object through which our adapter can start emitting events. The class

also implements interface RunnableBean (methods run and suspend)as it will run in a thread

and suspend itself to be reactivated some time later and fire another burst of events when therun() method is invoked. The class initializes a List of TemperatureSensor objects that each

emulate a temperature sensor, with its identifier, a cluster reference, a base temperature and a

range of variation over which the sensors reported value will randomly swerve.


9/52


19-9

In every burst of activity, all sensors are iterated and for each one an event pojo

TemperatureReadingEventis filed with the injected EventSender. Every 20 bursts, one sensors

is randomly selected and disabled, not to emit temperature readings anymore. This is the needle

we will later need to have our CEP application detect.

4. Open the temperatureSensorSimulator-context.xml filein folder META-INF/spring-

in the EPN editor. It will visually show the Event Processing Networkcurrently the

HelloWorld network that we will delete later on, but which now serves as a good example.

We will new components in the EPN from the context menu: adapter

temperatureSensorsSimulator, channel temperatureReadingsChannel and another adapter

temperatureReadingsQueueJmsOutbound. The channel is wired to this outbound adapter and

likewise the temperatureSensorsSimulator adapter to the inbound side of the channel.

The Event Processing Network for simulating temperature sensors as seen in the EPN

Editor

5. Configure the JMS provider in the wlevs\config.xml file.

The project will look like this in Eclipse:


10/52


19-10

6. Add the application to the CEP Server and publish.

7. Monitor the JMS queue jms\temperatureReadingsQueue in the WLS Console to see the

messages being produced by the CEP application.

(3)Executing the detailed implementation steps

1. Create new Oracle CEP project in Eclipse

Create a new project in Eclipse.


11/52


19-11

Select the Oracle CEP Application Project type.


12/52


19-12

Specify TemperatureSensorsSimular as the name for the new project.


13/52


19-13

Press Next. Enter the details for the Oracle CEP Application Content:


14/52


19-14

Press Next.


15/52


19-15

Elect to base the new project on the HelloWorld template; this template adds some initial

objects to the application that serve as a good example of what we need to develop ourselves,

including a simple EPN and an example of a custom adapter (class HelloWorldAdapter).

2. Rename file META-INF/spring/helloworld-context.xml

Rename file META-INF/spring/helloworld-context.xml to temperatureSensorSimulator-

context.xml. This file contains the Event Processing Network (EPN), the heart of the application

(or rather the brains).

3. Create a new class called TemperatureSensorSimulator.

Create new class TemperatureSensorSimulator in package TemperatureSensorSimulator.

It implements the CEP interface StreamSourcewith a single method setEventSender that


16/52


19-16

allows the CEP framework to inject the StreamSender object through which our adapter can start

emitting events. The class also implements interface RunnableBean (methods run and suspend)

as it will run in a thread and suspend itself to be reactivated some time later and fire another

burst of events when the run() method is invoked. The class initializes a List of

TemperatureSensor objects that each emulate a temperature sensor, with its identifier, a cluster

reference, a base temperature and a range of variation over which the sensors reported value will

randomly swerve.

In every burst of activity, all sensors are iterated and for each one an event pojo

TemperatureReadingEventis filed with the injected EventSender.

public class TemperatureSensorSimulator implements RunnableBean, StreamSource {

private static final int SLEEP_MILLIS = 2500;

private StreamSender eventSender;

private boolean suspended;

private List sensors = new ArrayList();

private int burstCounter =0;

public TemperatureSensorSimulator(){

sensors.add(new TemperatureSensor("XT.0191", "MW.A.100", 23.5f, 1.2f));

sensors.add(new TemperatureSensor("XT.3921", "MW.A.100", 23.6f, 0.7f));

.... add more sensors

}

public void run() {

suspended = false;

while (!isSuspended()) { // Generate messages forever...

generateTemperatureSensorBurst();


17/52


19-17

try {

synchronized (this) {

wait(SLEEP_MILLIS);

}

} catch (InterruptedException e) {

e.printStackTrace();

}

}

}

private void generateTemperatureSensorBurst() {

// send the messages - one for each sensor

for (TemperatureSensor sensor : sensors) {

if (!sensor.isBroken()) {

float temperature =

sensor.getBaseTemperature() + (float)(Math.random() *

sensor.getRange()) -

(float)0.5 * sensor.getRange();

TemperatureReadingEvent event = new TemperatureReadingEvent();

event.setTemperature(temperature);

event.setSensorId(sensor.getSensorId());

event.setClusterId(sensor.getClusterId());

eventSender.sendInsertEvent(event);

}

} // all sensors simulated once

// System.out.println("sent out sensor readings burst "+burstCounter++ );

// stick a needle in the haystack


18/52


19-18

// break a sensor if needs be, once every 50 bursts

if ((++burstCounter%50) ==0) {

int sensorToBreak = (int)(sensors.size() * Math.random());

if (!sensors.get(sensorToBreak).isBroken()) {

System.out.println("Sensor

"+sensors.get(sensorToBreak).getSensorId()+" has just broken down (in burst

"+burstCounter+")!");

sensors.get(sensorToBreak).setBroken(true);

}

}

}

public synchronized void suspend() {

suspended = true;

}

private synchronized boolean isSuspended() {

return suspended;

}

public void setEventSender(StreamSender sender) {

eventSender = sender;

}

Every 50 bursts, one sensors is randomly selected and disabled, not to emit temperature

readings anymore. This is the needle we will later need to have our CEP application detect.

Supporting classes TemperatureSensor and TemperatureReadingEvent are

straightforward:

package com.stmatthews.hospital.facilities;

public class TemperatureSensor {

private String sensorId;


19/52


19-19

private String clusterId;

private float baseTemperature;

private float range;

private boolean broken;

public TemperatureSensor(String sensorId, String clusterId,

float baseTemperature, float range) {

super();

this.sensorId = sensorId;

this.clusterId = clusterId;

this.baseTemperature = baseTemperature;

this.range = range;

this.broken = false;

}

public void setSensorId(String sensorId) {


}

public String getSensorId() {

return sensorId;

}

public void setClusterId(String clusterId) {


}

public String getClusterId() {

return clusterId;


20/52


19-20

}

public void setBaseTemperature(float baseTemperature) {

this.baseTemperature = baseTemperature;

}

public float getBaseTemperature() {

return baseTemperature;

}

public void setRange(float range) {

this.range = range;

}

public float getRange() {

return range;

}

public void setBroken(boolean broken) {

this.broken = broken;

}

public boolean isBroken() {

return broken;

}

}

and


21/52


19-21


public class TemperatureReadingEvent {

private float temperature;



public float getTemperature() {

return temperature;

}

public void setTemperature(float temperature) {

this.temperature = temperature;

}


return sensorId;

}



}


return clusterId;

}



}

}


22/52


19-22

4. Edit the Event Processing Network

Open the temperatureSensorSimulator-context.xml filein folder META-INF/spring- in

the EPN editor. It will visually show the Event Processing Networkcurrently the HelloWorld

network that we will delete later on, but which now serves as a good example.

We are about to create new components in the EPN from the context menu: adapter

temperatureSensorsSimulator, channel temperatureReadingsChannel and another adapter

temperatureReadingsQueueJmsOutbound. The channel is wired to this outbound adapter and

likewise the temperatureSensorsSimulator adapter to the inbound side of the channel.

The Event Processing Network for simulating temperature sensors as seen in the EPN

Editor

Open this file in edit source modefor example by double clicking any of the

components in the EPN. Add an event-type TemperatureReadingEvent to the element event-

type-repository, based on a class with the same name. Set the event-type attribute of the channelyou created to this event type. Set the provider attribute for the outbound JMS adapter to jms-

outbound. You may now remove all elements that refer to hello world in any way. The file

should look like this:

com.stmatthews.hospital.facilities.TemperatureReadingEvent


23/52


19-23

5. Configure the JMS provider.

Now open the file META-INF/wlevs/config.xml. In this file, we need to configure the

JMS provider - with a name that corresponds to the id use for the (jms outbound) adapter in the

file temperatureSensorSimulator-context.xml. The exact configuration depends on yourparticular environment, but with the standard installation the JMS adapter can be configured like

this:

temperatureReadingsQueueJmsOutbound

TemperatureReadingEvent

t3://localhost:8001

jms/temperatureReadingsQueue

weblogic

weblogic1

JettyWorkManager

1


24/52


19-24

false

nonpersistent

6. Add the application to the CEP Server and publish.

Open the Servers viewusing menu path Window, Show View, Others, Server/Servers.

The view that opens contains the CEP server that we configured in the previous section. From

the context menu on this server, select the option Add and Remove. In the window that pops up,

select the TemperatureSensorsSimulator application to add to the server and press Finish. The

server is started if it is not already running and the application is deployed and starts running

right away.

Deploying the CEP application TemperatureSensorSimulator to the CEP Server


25/52


19-25

after some time the console will contain messages indicating the failure of temperature

sensors (logged by the simulator, and to be found by the next (the real) CEP application:

7. Monitor the JMS queue jms\temperatureReadingsQueue in the WLS Console

We can check for messages being published to the JMS queue in the WebLogic

Administration console. Note: since we are using JMS Queue in the WebLogic soa_server1, we

have to ensure that this server is up and running before trying to execute the CEP application.


26/52


19-26


27/52


19-27


28/52


19-28


29/52


19-29

(2)The temperature readings processor

After our first introduction to CEP applications and an EPN, we are ready to create an

application with some real CEP logic in it. The TemperatureReadingsProcessor will read the

incoming temperature sensor readings from the JMS Queue jms/temperatureReadingsQueue and

analyze them in two ways:

The complex event processor is enlisted to consolidate the very large number oftemperature readings, in two ways: the application publishes the average

temperature per cluster of three sensors, every 30 seconds using the readings from

the last 60 seconds. The derived aggregate temperature findings are published on

a second JMS Queue, called TemperatureFindingsQueue. This queue feeds into

the Business Activity Monitor with more meaningful information at a sensible

pace.

The CEP will also be tasked with finding faulty temperature sensors. A sensor isconsidered faulty if it has not produced a signal for longer than 30 seconds. Failed

detectors are reported on another JMS Queue, this one called

failedTemperatureSensorsQueue

The logic of this application is defined through two processor elements that each run a

CQL Query that continuously scans incoming events and produces finding events.

(3)Prepare two additional JMS Queues

In much the same ways as before, we need to create two additional JMS Queues that the

CEP application will use The derived aggregate temperature findings are published on the JMS

Queue TemperatureFindingsQueue. This queue feeds into the Business Activity Monitor with

more meaningful information at a sensible pace. Failed detectors are reported on the new JMS

Queue failedTemperatureSensorsQueue.

Go to the WebLogic Admin Console and configure these two JMS queues.


30/52


19-30


31/52


19-31


32/52


19-32

And the same steps for the failedTemperatureSensorQueue:


33/52


19-33

(3)Overview of steps to create CEP application TemperatureReadingsProcessor

The steps for creating this application are the following:


34/52


19-34

1. Create a new CEP Project in Eclipse. Call it TemperatureReadingsProcessor.

2. Create classes TemperatureReading, TemperatureFinding and FailedSensorDetection

that represent the event types coming into the application (the former) and flowing out of it (the

latter two).

3. Configure the event type repository in the context file temperatureReadingsProcessor-

context.xml

4. Configure the JMS Adapters in the META-INF/wlevs/config.xml file, in the same way

we saw before, using the queue names we mentioned above and using event types

TemperatureReading, TemperatureFinding and FailedSensorDetection. These event types are

defined in the event-repository in temperatureReadingsProcessor-context.xml, referring to

POJOs with simple properties.

5. Design the Event Processing Network. Adapter consumeTemperatureReadings

consumes events from the inbound JMS Queue with temperature readings. Two processors

temperatureAggregator and failedSensorDetector process the readings, one to find failed

detectors and the other one to calculate aggregartes. Two other adapters

temperatureAggregatePublisher and failedSensorDectectionPublisherare both outbound JMS

Queue publishers for the aggregates and failed detector events. Finally, we will add a simple

monitor event sink to locally monitor the CEP application.

6. Configure the Event processors temperatureAggregator and failedSensorDetector

7. Deploy to CEP Server


35/52


19-35

8. Run and Monitor the CEP Application - watching for messages on the outbound JMS

queue.

(3)Create CEP application TemperatureReadingsProcessor

The detailed step by step instruction for creating the TemperatureReadingsProcessor:

1. Create a new CEP Project TemperatureReadingsProcessor

Create a new project of type Oracle CEP Application project, in Eclipse. Call it

TemperatureReadingsProcessor.

2. Create classes TemperatureReading, TemperatureFinding and FailedSensorDetection

Create three classes that represent the event types coming into the application (the

former) and flowing out of it (the latter two).


public class TemperatureReading {





return temperature;

}



}


return sensorId;

}


36/52


19-36



}


return clusterId;

}



}

}


public class TemperatureFinding {




return temperature;

}



}


return clusterId;

}public void setClusterId(String clusterId) {


}

}


37/52


19-37


public class FailedSensorDetection {




return sensorId;

}



}


return clusterId;

}



}

}

Also create class TemperatureReadingTesterSink:


import com.bea.wlevs.ede.api.StreamSink;

public class TemperatureReadingTesterSink implements StreamSink {

public void onInsertEvent(Object event) {

if (event instanceof TemperatureReading) {

TemperatureReading te = (TemperatureReading)event;

System.out.println("Reading Processor received Sensor

"+te.getSensorId()+" - temperature "+te.getTemperature());


38/52


19-38

}

if (event instanceof TemperatureFinding) {

TemperatureFinding te = (TemperatureFinding)event;

System.out.println("Temperature Reading Processor derived average

temperature for Cluster "+te.getClusterId()+" - temperature

"+te.getTemperature());

}

}

}

3. Configure the event type repository

The event types that are used for the communication through the channels in the CEPapplication are to be defined in the event-type-repository in the context file

temperatureReadingsProcessor-context.xml. Define event types TemperatureReading,

TemperatureFinding and FailedSensorDetection based on the classes with the same names.

com.stmatthews.hospital.facilities.TemperatureReading

com.stmatthews.hospital.facilities.TemperatureFinding

com.stmatthews.hospital.facilities.FailedSensorDetection


39/52


19-39

4. Configure the JMS Adapters

in the META-INF/wlevs/config.xml file, in the same way we saw before, using the queue

names we mentioned above and using event types TemperatureReading, TemperatureFinding

and FailedSensorDetection. These event types are defined in the event-repository in

temperatureReadingsProcessor-context.xml, referring to POJOs with simple properties.

consumeTemperatureReadings

TemperatureReading

t3://localhost:8001

jms/temperatureReadingsQueue

weblogic

weblogic1

JettyWorkManager

1

false

persistent

temperatureAggregatePublisher

TemperatureFinding

t3://localhost:8001

jms/TemperatureFindingsQueue


40/52


19-40

weblogic

weblogic1

JettyWorkManager

1

false

persistent

failedSensorDectectionPublisher

FailedSensorDetection

t3://localhost:8001

jms/failedTemperatureSensorsQueue

weblogic

weblogic1

JettyWorkManager

1

false

persistent

5. Design the Event Processing Network.

Adapter consumeTemperatureReadings consumes events from the inbound JMS Queue

with temperature readings. Two processorstemperatureAggregator and failedSensorDetector


41/52


19-41

process the readings, one to find failed detectors and the other one to calculate aggregartes. Two

other adapterstemperatureAggregatePublisher and failedSensorDectectionPublisherare both

outbound JMS Queue publishers for the aggregates and failed detector events. Finally, we will

add a simple monitor event sink to locally monitor the CEP application.

Open the context file in the EPN editor. Add an adapter consumeTemperatureReadings

that consumes events from the inbound JMS Queue with temperature readings. Add two

processorstemperatureAggregator and failedSensorDetector. Add two other adapters

temperatureAggregatePublisher and failedSensorDectectionPublisherboth outbound JMS

Queue publishers. Create the temperatureReadingsChannelwith event type set to

TemperatureReadingthat is the conduit between the incoming adapter and the two processors.

Also create channels temperatureAggregatesChannelconnecting temperatureAggregator to

temperatureAggregatePublisher carrying event type TemperatureFindingand finally

failedSensorDetectionsChannel that links failedSensorDetector to

failedSensorDectectionPublisher with event message of type FailedSensorDetection.

We also slip in a bean logTemperatureReadingEvents- based on class

TemperatureReadingTesterSink - that also listens in on the temperatureAggregateChannel. This

class will write to the console whatever it hears on the channel.


42/52


19-42


43/52


19-43

6. Configure the Event processors

First configure the processor temperatureAggregator. This processor reads

temperatureReading events and should aggregate them in two ways: first the readings for

multiple sensors in the same cluster should be aggregated together resulting in an average.

Then, instead of multiple readings per second, the aggegrator should produce a single

temperature finding per cluster once every 30 seconds. The value that is calculated should be the

average over all readings in a 60 second (sliding) window:

Double click the processor temperatureAggregator to edit the CQL query it needs to execute.

Edit the xml file that opens and specify the query as follows:

select avg(temperatureReadingsChannel.temperature) as temperature

, temperatureReadingsChannel.clusterId as clusterId

from temperatureReadingsChannel [range 60 slide 30]

group by temperatureReadingsChannel.clusterId

]]>

This relatively simple CQL statement processes events (of type TemperatureReading)

that appear on the temperatureReadingsChannel. Range 60 instructs the CQL engine to take the

events in this channel for the last 60 seconds and slide 30 is an instruction to produce a result

every 30 seconds. The average temperature is calculated over all temperature reading events

events in the 60 second window and all sensors grouped by their cluster. The events that are

produced by this query have two properties set: temperature and clustered.

Please be reminded that this query may look a lot like a regular SQL query that is used in

queries against relational data sources. However, there are some really important distinctions: the

CQL: query operates on a stream of events, a dynamic data source that can change all the time.

The work of the query is never doneas events continue to arrive on the stream, the query

continuous to execute and potentially publish events.


44/52


19-44

temperatureAggregator

select avg(temperatureReadingsChannel.temperature) as temperature

, temperatureReadingsChannel.clusterId as clusterId

from temperatureReadingsChannel [range 60 slide 30]

group by temperatureReadingsChannel.clusterId

]]>

The second processor failedSensorDetector is slightly more interesting. It has a tougher

job to perform than the first processor we created. Spotting a faulty detector is done by finding a

lack of eventsone of many event patterns that CQL can unravel. It produces

FailedSensorDetection events (or at least a combination of values that can be cast to

FailedSensorDetection events).

The MATCH_RECOGNIZE section of the next query is where the pattern must be

matched. This section is partitioned by sensorId as we want to find events or spot missing

eventsper sensor. This values returned by this section are sensorId and clustered, the two

measures that are defined. The pattern clause indicates what combination of occurrences we are

looking forusing a simple regular expression like syntax. Here we have indicated that we are

looking for an occurrence of A followed by one more occurrences of B. A is an anchor event for

this pattern: every temperature reading fits the bill for A. B occurs when there is an event that


45/52


19-45

has a different sensorId value than the A event. However, as we have partitioned the events by

sensorId, this really should not happen, wouldnt you say so?!

If a sensor fails, the last A event is not followed by an event with the same sensorId

instead it will be followed by a heartbeat event a null event. The combination ofinclude timerevents and duration multiples of 30 is responsible for producing the null event when the duration

expiresthat is: after 30 seconds. The null event does not have the same sensorId as the A event

it follows and that means that the (A B*) pattern is detected. An output event is produced with

the measures set as specified.

failedSensorDetector

select 'SENSOR HAS BROKEN DOWN (30 secs no reading):

'||sensorReadings.sensorId as sensorId

, sensorReadings.clusterId as clusterId

from temperatureReadingsChannel

MATCH_RECOGNIZE(

partition by sensorId

MEASURES A.sensorId as sensorId

, A.clusterId as clusterId

all matches

include timer events

PATTERN(A B*)

duration multiples of 30

DEFINE A as A.temperature > -100, B as B.sensorId != A.sensorId)

as sensorReadings


46/52


19-46

]]>

Add the following heartbeat definition to the wlevs\config.xml file. This heartbeat

ensures that every 10 seconds (10000ms) a heartbeat event will be generated on the

temperatureReadingsChannel in the absence of any other event (the channel will never go

entirely quiet). We need this heartbeat to establish the fact that one event is not followed by the

expected subsequent event (but by an otherwise meaningless heartbeat event).

temperatureReadingsChannel

10000

7. Deploy to CEP Server

We have created two CEP applicationsone to simulate a bunch of hyperactive

temperature sensors and produce a load of events on a JMS Queue and second one to process and

analyze those temperature readings. This yields consolidated average temperature values, once

every 30 seconds, and the detection of faulty sensors. Both results are published to JMS queues.

8. Run and Monitor the CEP Application

We can deploy these applications to the CEP server and have them run. There would be

no spectacular displaysin fact no visual output at all, except the arrival of messages on the

JMS queues that we can monitor in the WebLogic Administration console


47/52


19-47

and the output in the console from the logTemperatureReadingEvents bean.

(3)Create a Monitoring application

A third and very small CEP application can also be used, to tap into the JMS Queue for

failed detector eventsat jms/failedTemperatureSensorsQueue. This application feeds events

through a channel into an EventBean component based on a custom class FailedSensorTrapper

that implements the EventSink interface. This class write a message to the console for every

failed sensor event it receives. This gives us an easy, almost no programming way to monitor the

CEP applications.


48/52


19-48

Class FailedSensorEvent:


public class FailedSensorEvent {




return sensorId;

}



}


return clusterId;

}



}

}

and the FailedSensorTrapper class:


import com.bea.wlevs.ede.api.StreamSink;

public class FailedSensorTrapper implements StreamSink {

public void onInsertEvent(Object event) {

if (event instanceof FailedSensorEvent) {

System.out.println("Failed Sensor Detected "

+ ((FailedSensorEvent) event).getSensorId());


49/52


19-49

}

}

}

Now configure the context file:

com.stmatthews.hospital.facilities.FailedSensorEvent


50/52


19-50

The events read from the failedSensorDectectionConsumer inbound jms adapter are propagated

to the CollectFailedSensorAlerts processor that propagates all events, thanks to its CQL query:

CollectFailedSensorAlerts

[Now] ]]>

The events are propagated through the sensorAlertsChannel that the trapSensorAlerts bean is

listening to.

The JMS Adapter needs to be configured in the config.xml file:

failedSensorDectectionConsumer

FailedSensorMessage

t3://localhost:8001


51/52


19-51

jms/failedTemperatureSensorsQueue

weblogic

weblogic1

JettyWorkManager

1

false

persistent

(3)Monitoring the failedTemperatureSensorsQueue through the Visualizer

All three CEP applications can now be added to the CEP server. This will deploy and

start them. And this time we will be using the browser based CEP Visualizer tool, an

administration console with run time application editing capabilities, for example to edit CQL

queries. The CEP Visualizer can be accessed at the url: http://localhost:9002/wlevs. You can

connect with wlevs/wlevs. We can find the console output in the visualizer tool under Non

Clustered Server/Services.


52/52


Monitoring the console output of the CEP applications in the CEP Visualizer

administration console.

When the simulator decides to take a sensor off-line, it write a message to the console.

Approximately 30 seconds later, the CEP processor failedSensorDetector has detected the lack of

events from this sensor and produced a FailedSensorDetection event on thefailedTemperatureSensorsQueue queue. The TrackFailedSensors application consumes messages

from that particular queue and logs about them. The console output in the CEP Visualizer shows

how various sensors start to fail from the simulator and after some time are being detected. The

figure highlights the case of sensor AB.6351 that fails and is detected as having passed away

.

soa ch19 online chapter complement cep partone

Documents