SOA CH19 Online Chapter Complement CEP PartOne
Transcript of 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)
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
2/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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:
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
3/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-3
Click on the SOAJMSModule in the table.
Click on the New button above the table of currently available JMS resources.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
4/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-4
Select Queue as Resource Type, then click on Next.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
5/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-5
Enter the name (temperatureReadingsQueue) and JNDI name jms/temperatureReadingsQueue.
Click on Next.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
6/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
7/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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:
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
8/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
9/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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:
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
10/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
11/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-11
Select the Oracle CEP Application Project type.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
12/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-12
Specify TemperatureSensorsSimular as the name for the new project.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
13/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-13
Press Next. Enter the details for the Oracle CEP Application Content:
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
14/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-14
Press Next.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
15/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
16/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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();
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
17/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
18/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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;
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
19/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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) {
this.sensorId = sensorId;
}
public String getSensorId() {
return sensorId;
}
public void setClusterId(String clusterId) {
this.clusterId = clusterId;
}
public String getClusterId() {
return clusterId;
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
20/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
21/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-21
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;
}
}
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
22/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
23/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
24/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
25/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
26/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-26
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
27/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-27
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
28/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-28
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
29/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
30/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-30
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
31/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-31
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
32/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-32
And the same steps for the failedTemperatureSensorQueue:
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
33/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-33
(3)Overview of steps to create CEP application TemperatureReadingsProcessor
The steps for creating this application are the following:
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
34/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
35/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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).
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;
}
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
36/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-36
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;
}
}
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
37/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-37
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());
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
38/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
39/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
40/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
41/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
42/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-42
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
43/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
44/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
45/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
46/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
47/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
48/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-48
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());
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
49/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
19-49
}
}
}
Now configure the context file:
com.stmatthews.hospital.facilities.FailedSensorEvent
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
50/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
51/52
Oracle 11g SOA Suite Handbook:Chapter 19 September 21, 2011
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.
-
7/31/2019 SOA CH19 Online Chapter Complement CEP PartOne
52/52
Oracle 11g SOA Suite Handbook:Chapter 19 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 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
.