SOA CH19 Online Chapter Complement CEP PartOne

Oracle 11g SOA Suite Handbook:Chapter 19 (pn)Part IV (pt)Beyond the Basics (cn)Chapter 19
September 21, 2011
(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 of three: 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 instantaneously in 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 intensive care units Find faulty sensors (no signal for longer than 30 seconds)
19-1
Oracle 11g SOA Suite Handbook:Chapter 19
September 21, 2011
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:
19-2
Oracle 11g SOA Suite Handbook:Chapter 19 Click on the SOAJMSModule in the table.
September 21, 2011
Click on the New button above the table of currently available JMS resources.
19-3
September 21, 2011
Select Queue as Resource Type, then click on Next.
19-4
September 21, 2011
Enter the name (temperatureReadingsQueue) and JNDI name jms/temperatureReadingsQueue. Click on Next.
19-5
September 21, 2011
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.
19-6
September 21, 2011
(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:
19-7
September 21, 2011
Use a custom adapter to create temperatureReadingEvents simple POJOs that carry the temperature value and the sensors identification
Channel these events to a JMS queue that makes these events available to various consumers including a second CEP application the one that could also be 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 StreamSource with 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 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.
19-8
September 21, 2011
In every burst of activity, all sensors are iterated and for each one an event pojo TemperatureReadingEvent is 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 file in folder META-INF/springin the EPN editor. It will visually show the Event Processing Network currently 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:
19-9
September 21, 2011
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.
19-10
September 21, 2011
Select the Oracle CEP Application Project type.
19-11
September 21, 2011
Specify TemperatureSensorsSimular as the name for the new project.
19-12
September 21, 2011
Press Next. Enter the details for the Oracle CEP Application Content:
19-13
September 21, 2011
Press Next.
19-14
September 21, 2011
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 temperatureSensorSimulatorcontext.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 StreamSource with a single method setEventSender that 19-15
September 21, 2011
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 TemperatureReadingEvent is 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<TemperatureSensor> sensors = new ArrayList<TemperatureSensor>(); 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();
19-16

try { synchronized (this) { wait(SLEEP_MILLIS); }
September 21, 2011
} 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
19-17
September 21, 2011
// 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-18

private String clusterId; private float baseTemperature; private float range; private boolean broken;
September 21, 2011
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) { this.sensorId = sensorId; }
public String getSensorId() { return sensorId; }
public void setClusterId(String clusterId) { this.clusterId = clusterId; }
public String getClusterId() { return clusterId;
19-19

}
September 21, 2011
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
19-20
September 21, 2011
package com.stmatthews.hospital.facilities;
public class TemperatureReadingEvent {
private float temperature; private String sensorId; private String clusterId; public float getTemperature() { return temperature; } public void setTemperature(float temperature) { this.temperature = temperature; } public String getSensorId() { return sensorId; } public void setSensorId(String sensorId) { this.sensorId = sensorId; } public String getClusterId() { return clusterId; } public void setClusterId(String clusterId) { this.clusterId = clusterId; }
19-21
Oracle 11g SOA Suite Handbook:Chapter 19 4. Edit the Event Processing Network
September 21, 2011
Open the temperatureSensorSimulator-context.xml file in folder META-INF/springin the EPN editor. It will visually show the Event Processing Network currently 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 mode for example by double clicking any of the components in the EPN. Add an event-type TemperatureReadingEvent to the element eventtype-repository, based on a class with the same name. Set the event-type attribute of the channel you created to this event type. Set the provider attribute for the outbound JMS adapter to jmsoutbound. You may now remove all elements that refer to hello world in any way. The file should look like this:
<wlevs:event-type-repository> <wlevs:event-type type-name="TemperatureReadingEvent">
<wlevs:class>com.stmatthews.hospital.facilities.TemperatureReadingEvent</wlevs:cla ss> </wlevs:event-type> </wlevs:event-type-repository>
19-22
September 21, 2011
<wlevs:adapter id="temperatureReadingsQueueJmsOutbound" provider="jmsoutbound" />
<wlevs:adapter id="temperatureSensorsSimulator" class="com.stmatthews.hospital.facilities.TemperatureSensorSimulator"> <wlevs:listener ref="temperatureReadingsChannel" /> </wlevs:adapter>
<wlevs:channel id="temperatureReadingsChannel" eventtype="TemperatureReadingEvent"> <wlevs:listener ref="temperatureReadingsQueueJmsOutbound" /> </wlevs:channel>
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 your particular environment, but with the standard installation the JMS adapter can be configured like this:
<jms-adapter> <name>temperatureReadingsQueueJmsOutbound</name> <event-type>TemperatureReadingEvent</event-type> <jndi-provider-url>t3://localhost:8001</jndi-provider-url> <destination-jndi-name>jms/temperatureReadingsQueue</destination-jndi-name> <user>weblogic</user> <password>weblogic1</password> <work-manager>JettyWorkManager</work-manager> <concurrent-consumers>1</concurrent-consumers>
19-23
September 21, 2011
<session-transacted>false</session-transacted> <delivery-mode>nonpersistent</delivery-mode> </jms-adapter>
6. Add the application to the CEP Server and publish. Open the Servers view using 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
19-24
September 21, 2011
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.
19-25
September 21, 2011
19-26
September 21, 2011
19-27
September 21, 2011
19-28
September 21, 2011
(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 of temperature 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 is considered 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.
19-29
September 21, 2011
19-30
September 21, 2011
19-31
September 21, 2011
And the same steps for the failedTemperatureSensorQueue:
19-32
September 21, 2011
(3)Overview of steps to create CEP application TemperatureReadingsProcessor The steps for creating this application are the following:
19-33
September 21, 2011
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 temperatureReadingsProcessorcontext.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 failedSensorDectectionPublisher are 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 19-34
September 21, 2011
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).
package com.stmatthews.hospital.facilities; public class TemperatureReading { private float temperature; private String sensorId; private String clusterId; public float getTemperature() { return temperature; } public void setTemperature(float temperature) { this.temperature = temperature; } public String getSensorId() { return sensorId; }
19-35
September 21, 2011
public void setSensorId(String sensorId) { this.sensorId = sensorId; } public String getClusterId() { return clusterId; } public void setClusterId(String clusterId) { this.clusterId = clusterId; } } package com.stmatthews.hospital.facilities; public class TemperatureFinding { private float temperature; private String clusterId; public float getTemperature() { return temperature; } public void setTemperature(float temperature) { this.temperature = temperature; }
public String getClusterId() { return clusterId; } public void setClusterId(String clusterId) { this.clusterId = clusterId; } }
19-36
September 21, 2011
package com.stmatthews.hospital.facilities; public class FailedSensorDetection { private String sensorId; private String clusterId; public String getSensorId() { return sensorId; } public void setSensorId(String sensorId) { this.sensorId = sensorId; } public String getClusterId() { return clusterId; } public void setClusterId(String clusterId) { this.clusterId = clusterId; } }
Also create class TemperatureReadingTesterSink:

package com.stmatthews.hospital.facilities; 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());
19-37

}
September 21, 2011
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 CEP application 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.
<wlevs:event-type-repository> <wlevs:event-type type-name="TemperatureReading"> <wlevs:class>com.stmatthews.hospital.facilities.TemperatureReading</wlevs:cl ass> </wlevs:event-type> <wlevs:event-type type-name="TemperatureFinding"> <wlevs:class>com.stmatthews.hospital.facilities.TemperatureFinding</wlevs:cl ass> </wlevs:event-type> <wlevs:event-type type-name="FailedSensorDetection">
<wlevs:class>com.stmatthews.hospital.facilities.FailedSensorDetection</wlevs:class > </wlevs:event-type> </wlevs:event-type-repository>
19-38
Oracle 11g SOA Suite Handbook:Chapter 19 4. Configure the JMS Adapters
September 21, 2011
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.
<?xml version="1.0" encoding="UTF-8"?> <n1:config xmlns:n1="http://www.bea.com/ns/wlevs/config/application">
<jms-adapter> <name>consumeTemperatureReadings</name> <event-type>TemperatureReading</event-type> <jndi-provider-url>t3://localhost:8001</jndi-provider-url> <destination-jndi-name>jms/temperatureReadingsQueue</destination-jndiname> <user>weblogic</user> <password>weblogic1</password> <work-manager>JettyWorkManager</work-manager> <concurrent-consumers>1</concurrent-consumers> <session-transacted>false</session-transacted> <delivery-mode>persistent</delivery-mode> </jms-adapter>
<jms-adapter> <name>temperatureAggregatePublisher</name> <event-type>TemperatureFinding</event-type> <jndi-provider-url>t3://localhost:8001</jndi-provider-url> <destination-jndi-name>jms/TemperatureFindingsQueue</destination-jndiname>
19-39

<user>weblogic</user> <password>weblogic1</password>
September 21, 2011
<work-manager>JettyWorkManager</work-manager> <concurrent-consumers>1</concurrent-consumers> <session-transacted>false</session-transacted> <delivery-mode>persistent</delivery-mode>
</jms-adapter>
<jms-adapter> <name>failedSensorDectectionPublisher</name> <event-type>FailedSensorDetection</event-type> <jndi-provider-url>t3://localhost:8001</jndi-provider-url> <destination-jndi-name>jms/failedTemperatureSensorsQueue</destinationjndi-name> <user>weblogic</user> <password>weblogic1</password> <work-manager>JettyWorkManager</work-manager> <concurrent-consumers>1</concurrent-consumers> <session-transacted>false</session-transacted> <delivery-mode>persistent</delivery-mode> </jms-adapter> </n1:config>
5. Design the Event Processing Network. Adapter consumeTemperatureReadings consumes events from the inbound JMS Queue with temperature readings. Two processors temperatureAggregator and failedSensorDetector 19-40
September 21, 2011
process the readings, one to find failed detectors and the other one to calculate aggregartes. Two other adapters temperatureAggregatePublisher and failedSensorDectectionPublisher are 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 processors temperatureAggregator and failedSensorDetector. Add two other adapters temperatureAggregatePublisher and failedSensorDectectionPublisher both outbound JMS Queue publishers. Create the temperatureReadingsChannel with event type set to TemperatureReading that is the conduit between the incoming adapter and the two processors. Also create channels temperatureAggregatesChannel connecting temperatureAggregator to temperatureAggregatePublisher carrying event type TemperatureFinding and 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.
<wlevs:adapter id="consumeTemperatureReadings" provider="jms-inbound"> <wlevs:listener ref="temperatureReadingsChannel" /> </wlevs:adapter>
19-41
September 21, 2011
<wlevs:event-bean id="logTemperatureReadingEvents" class="com.stmatthews.hospital.facilities.TemperatureReadingTesterSink"> </wlevs:event-bean>
<wlevs:channel id="temperatureReadingsChannel" event-type="TemperatureReading"> <wlevs:listener ref="temperatureAggregator" /> <wlevs:listener ref="failedSensorDetector" /> </wlevs:channel> <wlevs:processor id="temperatureAggregator"> <wlevs:listener ref="temperatureAggregatesChannel" /> </wlevs:processor> <wlevs:adapter id="temperatureAggregatePublisher" provider="jms-outbound"> </wlevs:adapter> <wlevs:channel id="temperatureAggregatesChannel" event-type="TemperatureFinding"> <wlevs:listener ref="temperatureAggregatePublisher" /> <wlevs:listener ref="logTemperatureReadingEvents" /> </wlevs:channel> <wlevs:adapter id="failedSensorDectectionPublisher" provider="jms-outbound"> </wlevs:adapter> <wlevs:processor id="failedSensorDetector"> <wlevs:listener ref="failedSensorDetectionsChannel" /> </wlevs:processor> <wlevs:channel id="failedSensorDetectionsChannel" eventtype="FailedSensorDetection"> <wlevs:listener ref="failedSensorDectectionPublisher" /> </wlevs:channel>
19-42
Oracle 11g SOA Suite Handbook:Chapter 19 6. Configure the Event processors
September 21, 2011
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:
<query id="aggregateTemperatureReadings"> <![CDATA[ select avg(temperatureReadingsChannel.temperature) , from as temperature
temperatureReadingsChannel.clusterId as clusterId temperatureReadingsChannel [range 60 slide 30]
group by temperatureReadingsChannel.clusterId ]]> </query>
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 done as events continue to arrive on the stream, the query continuous to execute and potentially publish events.
19-43

<?xml version="1.0" encoding="UTF-8"?>
September 21, 2011
<wlevs:config xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"> <processor> <name>temperatureAggregator</name> <rules> <query id="aggregateTemperatureReadings"> <![CDATA[ select avg(temperatureReadingsChannel.temperature) , from as temperature
temperatureReadingsChannel.clusterId as clusterId temperatureReadingsChannel [range 60 slide 30]
group by temperatureReadingsChannel.clusterId ]]></query> </rules> </processor> </wlevs:config>
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 events one 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 events per 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 for using 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
19-44
September 21, 2011
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 of include timer events and duration multiples of 30 is responsible for producing the null event when the duration expires that 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.
<?xml version="1.0" encoding="UTF-8"?> <wlevs:config xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"> <processor> <name>failedSensorDetector</name> <rules> <query id="failedSensorDetection"> <![CDATA[ select 'SENSOR HAS BROKEN DOWN (30 secs no reading): '||sensorReadings.sensorId , from as sensorId
sensorReadings.clusterId as clusterId 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
19-45

]]></query> </rules> </processor> </wlevs:config>
September 21, 2011
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).
<channel> <name>temperatureReadingsChannel</name> <heartbeat>10000</heartbeat> </channel>
7. Deploy to CEP Server We have created two CEP applications one 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 displays in fact no visual output at all, except the arrival of messages on the JMS queues that we can monitor in the WebLogic Administration console
19-46
September 21, 2011
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 events at 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.
19-47
September 21, 2011
Class FailedSensorEvent:
package com.stmatthews.hospital.facilities; public class FailedSensorEvent { private String sensorId; private String clusterId; public String getSensorId() { return sensorId; } public void setSensorId(String sensorId) { this.sensorId = sensorId; } public String getClusterId() { return clusterId; } public void setClusterId(String clusterId) { this.clusterId = clusterId; } }
and the FailedSensorTrapper class:

package com.stmatthews.hospital.facilities; 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());
19-48

} } }
September 21, 2011
Now configure the context file:

<wlevs:event-type-repository> <wlevs:event-type type-name="FailedSensorMessage"> <wlevs:properties> <wlevs:property name="sensorId" type="object" /> <wlevs:property name="clusterId" type="object" /> </wlevs:properties> </wlevs:event-type> <wlevs:event-type type-name="FailedSensorEvent" >
<wlevs:class>com.stmatthews.hospital.facilities.FailedSensorEvent</wlevs:class> </wlevs:event-type> </wlevs:event-type-repository>
<wlevs:adapter id="failedSensorDectectionConsumer" provider="jms-inbound"> <wlevs:listener ref="failedSensorMessagesChannel" /> </wlevs:adapter> <wlevs:processor id="CollectFailedSensorAlerts"> <wlevs:listener ref="sensorAlertsChannel" /> </wlevs:processor> <wlevs:channel id="sensorAlertsChannel" event-type="FailedSensorEvent"> <wlevs:listener ref="trapSensorAlerts" /> </wlevs:channel>
19-49
September 21, 2011
<wlevs:channel id="failedSensorMessagesChannel" eventtype="FailedSensorMessage"> <wlevs:listener ref="CollectFailedSensorAlerts" /> </wlevs:channel> <wlevs:event-bean id="trapSensorAlerts" class="com.stmatthews.hospital.facilities.FailedSensorTrapper"> </wlevs:event-bean>
The events read from the failedSensorDectectionConsumer inbound jms adapter are propagated to the CollectFailedSensorAlerts processor that propagates all events, thanks to its CQL query:
<wlevs:config xmlns:wlevs="http://www.bea.com/ns/wlevs/config/application"> <processor> <name>CollectFailedSensorAlerts</name> <rules> <query id="collectFailedSensorMessages"> <![CDATA[ select sensorId , clusterId from failedSensorMessagesChannel [Now] ]]> </query> </processor> </wlevs:config> </rules>
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:

<jms-adapter> <name>failedSensorDectectionConsumer</name> <event-type>FailedSensorMessage</event-type> <jndi-provider-url>t3://localhost:8001</jndi-provider-url>
19-50
September 21, 2011
<destination-jndi-name>jms/failedTemperatureSensorsQueue</destinationjndi-name> <user>weblogic</user> <password>weblogic1</password> <work-manager>JettyWorkManager</work-manager> <concurrent-consumers>1</concurrent-consumers> <session-transacted>false</session-transacted> <delivery-mode>persistent</delivery-mode> </jms-adapter>
(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.
19-51
September 21, 2011
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 the failedTemperatureSensorsQueue 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 .
19-52

SOA CH19 Online Chapter Complement CEP PartOne

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SOA CH19 Online Chapter Complement CEP PartOne

Transféré par

Droits d'auteur :

Formats disponibles

Oracle 11g SOA Suite Handbook:Chapter 19 (pn)Part IV (pt)Beyond the Basics (cn)Chapter 19

September 21, 2011

(1)Monitoring temperature sensors

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

(2)Getting started with CEP

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Select Queue as Resource Type, then click on Next.

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

(2)The temperature sensors simulator

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

(3)Executing the detailed implementation steps

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Select the Oracle CEP Application Project type.

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Specify TemperatureSensorsSimular as the name for the new project.

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

public class TemperatureSensorSimulator implements RunnableBean, StreamSource {

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

} catch (InterruptedException e) { e.printStackTrace(); } } }

// stick a needle in the haystack

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

Supporting classes TemperatureSensor and TemperatureReadingEvent are straightforward:

public class TemperatureSensor { private String sensorId;

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

public void setSensorId(String sensorId) { this.sensorId = sensorId; }

public String getSensorId() { return sensorId; }

public void setClusterId(String clusterId) { this.clusterId = clusterId; }

public String getClusterId() { return clusterId;

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011

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; }

Oracle 11g SOA Suite Handbook:Chapter 19

September 21, 2011