When should a process start or a service be activated? The trigger can be a requirement in an application, process, or service that then invokes the service or process. However, frequently the link is not that straightforward. When 'something happens' (a business event!), that should lead to the start of other actions or the continuation or redirection of running processes. However, whose responsibility is it to determine that a business event has taken place, and even more importantly, who to notify? The process instance that happens to produce an event should not bare the burden of finding out who needs to be notified—especially as the list of interested parties can be hugely dynamic. Nor should the event be presented to any service, composite application, or process to check out whether perhaps it wants to consume it.
This session discusses Event-Driven SOA—an architecture where applications, processes, and services can produce business events, and interested consumers are notified of those events—through the mediation by the SOA Suite 11g Event Delivery Network (EDN). In this session, we will see how business events are defined across the enterprise, and how an interest in specific types of business events (with specific payloads) can be registered. The session demonstrates how events can be produced, how they are processed by the EDN, and handed to the interested parties. Special attention is given to the correlation of events, ensuring that the correct composite instance is provided with the event. We will discuss how the events can not only originate within the SOA Suite, but also outside of it, through AQ, PL/SQL and Java, ADF BC, and JMS. As a last step, we will discuss Complex Event Processing (CEP) as a potential source of business events. CEP will handle large volumes of small, usually insignificant events. However, by filtering, aggregating, and analyzing for deviations and threshold transgressions, CEP will occasionally find business events that are subsequently sent to the Event Delivery Network. This session has many demonstrations (end-to-end).
Scaling API-first – The story of a global engineering organization
It's happening - on Event Driven SOA, Part Two (EDN patterns, ADF BC integration BAM) - ODTUG Kaleidoscope 2010
1. What’s Happening?
Part Two
ODTUG Kaleidoscope 2010
Thursday, 30th June
Lucas Jellema
AMIS, The Netherlands
2. 2. Event Patterns, ADF, BAM
• Discussion Forum Pattern
• Turn event into Human Task via Mediator
• Missing Event Detection
• ADF BC publishing onto the EDN
– ADF consuming events
• Business Activity Monitoring
3. “EDN == OTN”
Discussion Forum Pattern
• Asking a question – of no one in particular
– Publish the question
– Hope for an answer
– From any one at all (or multiple responders
– Be notified of the response when it is available
• Instead of sending an email to a specific
individual
– Who may not know the answer or be away on
vacation or whose email address you do not have
4. Discussion Forum Pattern for
Composite applications
• Service A publishes a request
– In the form of an event
– With Correlation initiated (based on a GUID in the event
payload)
• The event can be consumed by multiple composites,
such as Service B
• Service B publishes a response with the GUID in the
payload
• Service A receives the response and continues
processing
5.
6.
7. Define the EDN Event Types
• PatientDataRequestEvent and
PatientDataResponseEvent
9. Set up correlation
in a BPEL process
• Create Correlation Set
• Create Property in Set
• Create Property Aliases
for every message
(inbound or outbound)
involved in correlation
10.
11. When an EDN Event should trigger
a human task
• We can create a Mediator or BPEL process
that consumes the event
• And then instantiates the Human Task
– For example: Failed Temperature Sensor
12.
13.
14. Demo
• Create test event using ‘generate XML
document from XSD’
• For detector cluster …
16. Missing Event Detection
• Patient arrived – but never left
• Bags went into the airport luggage handling
system – never to come out again
• There should be a signal at least once every
hour, but it has been quiet for five fours now
• There have been no cars coming out of the
tunnel for the last 10 minutes
• The visitor to the White House went into the
secure zone- but has failed to come out again
17. How do you detect something that
is not there?
• Missing events are … missing
– So how are they detected?
• Typical pattern for Complex Event Processing
– And also supported in BAM
• In general one would need to know what to
expect when, check at that time and find that
either the event is there or it is not….
• What can we do in the SOA Suite?
18. (somewhat clunky)
implementation in SOA Suite
• BPEL process subscribes to the expected event
– Through correlation on the payload
• BPEL process is instantiated knowing when
the event should be arriving
• BPEL processes contains a pick activity
– Waiting until the deadline
– Waiting for the event to arrive
• When the deadline arrives (and the event
does not) the whistle is blown
20. ADF Faces Web Application
PatientAdministration
Application Module
PatientsService
View Object
PatientsVw
ADF Entity Object
Business Patient
Components
PATIENTS
21. ADF Application for Patient
Administration
• One Business Event defined at St. Matthews is
the ‘Patient has moved’ event
• Any application, process or service that (first)
registers or detects that event should publish it
• The Patient Administration application is one
point of origination for this business event
– And therefore should publish it to the EDN
• ADF Business Components has an easy
integration with EDN
22. ADF Faces Web Application
PatientAdministration
Application Module
PatientsService
View Object SOA Suite
PatientsVw
E
ADF Entity Object D
Business Patient N
Components
PatientHas
Moved
PATIENTS
27. Demo
• ADF PatientAdministration Application
– Used to manipulate a patient’s address
• EDN events fired by the ADF Application
– And consumed by the
‘ConsumePatientHasMoved’ composite
application
28. ADF consuming EDN events
Steps:
• EDN events published on JMS
• ADF Faces application has registered as
listener on the JMS queue
– An application scope bean collects events in
‘active data collection’
• ADF Faces page contains Active Table based
on the ‘active data collection’
– New EDN events are pushed to the ADF Faces UI
29. Introducing
Business Activity Monitoring
• Operational Business Intelligence
• Data fed in from many sources:
– RFID sensors, BPEL, Database Triggers, RSS, ODI
• Real Time insight
• Dashboard
• Live updates
• Looking for threshold crossing, exceptions, trends,
missing events
• Display visually and turn into alerts & notifications
31. Live & Real Time dashboard in
regular ADF Web Application
• Active Data Service (‘server push’) will pick
changes in the
BAM Data Control
– Underlying BAM
ADC Data Object
• And push them to
the chart (or table)
in the ADF page
32. BAM reporting on operations in
the SOA Suite
• SOA Composite applications can report to BAM
in multiple ways
– Using the BAM Adapter
– From BPEL using the BAM Sensor action
– From BPEL using the Monitors
– Or: invoking a BAM WebService or using JMS
• Signals from Composite applications are
applied to Data Objects in Active Data Cache
– Leading to dashboard updates & alerts fired
33. DEMO: BAM & SOA Suite
• Create BAM Data Object: Patient
– Attributes Name, Age, Country
• Create Report on top of Data Object
– Bar Chart with # per country
– Gauge with average age?
• Add BAM Adapter Service to SOA Composite
application PatientCreator
– Feed data from SOA Composite to BAM Data
Object
34. PatientAppointmentService
feeding into BAM
• BAM Data Object PatientAppointment
• SOA Composite doing create and update on
Patient Appointments
• BAM Dashboard reports on:
– Number of new appointments over time
– 3d bar chart # appointments per status
– Gauge for # of unscheduled appointments
– Age distribution under patients
– Priority Assignments
42. BAM Alert Rules
• Specify Conditions on Data Objects
– In terms of attributes, functions and operators
• Specify how frequently the rule should be
verified against the Data Objects
• Specify the action to be taken when violated
43. BAM missing event detection
• Appointment goes unscheduled for over 72
hours
• Steps:
– Add a calculated attribute schedulingDeadline:
initialReceptionData + 72 hours
– Create a rule: schedulingDeadline > now()
– Alert action: send email when rule is violated
• When scheduling has not taken place within the
allotted timeframe
51. Summary
• Discussion Forum pattern – use events for
anonymous two-way communication
• Missing Event Detection
• ADF BC publishing events onto EDN
• Business Activity Monitoring – visual real time
insight – fed from SOA Suite, JMS, ODI, …
– BAM Adapter
– BPEL Monitor