Your SlideShare is downloading. ×
It's happening - on Event Driven SOA, Part Two (EDN patterns, ADF BC integration BAM) - ODTUG Kaleidoscope 2010
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

It's happening - on Event Driven SOA, Part Two (EDN patterns, ADF BC integration BAM) - ODTUG Kaleidoscope 2010

2,336

Published on

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 …

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).

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,336
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. Define the EDN Event Types • PatientDataRequestEvent and PatientDataResponseEvent
  • 6. Publish Event & Initiate Correlation
  • 7. 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
  • 8. 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
  • 9. Demo • Create test event using ‘generate XML document from XSD’ • For detector cluster …
  • 10. (test) Event turned into Human Task
  • 11. 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
  • 12. 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?
  • 13. (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
  • 14. ADF and EDN
  • 15. ADF Faces Web Application PatientAdministration Application Module PatientsService View Object PatientsVw ADF Entity Object Business Patient Components PATIENTS
  • 16. 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
  • 17. 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
  • 18. Configure ADF BC Entity Objects
  • 19. The Business Event definition
  • 20. Consume Event in SOA Suite
  • 21. And…. Action!!
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. Introducing Business Activity Monitoring ADF Application
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. Data Object PatientAppointment
  • 31. Add BAM Adapter
  • 32. Configure BAM Adapter Service
  • 33. Feeding Status Updates to BAM
  • 34. 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
  • 35. 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
  • 36. Appointment Unscheduled
  • 37. BPEL Monitor • BPEL process can be decorated with monitors that report into BAM
  • 38. BPEL Monitoring • Activate monitoring on the BPEL process • Create and configure the monitors – Counter – Interval – Business Indicator
  • 39. BPEL Monitors: Counter
  • 40. BPEL Monitors: Counter
  • 41. BPEL Monitors: Business Indicator
  • 42. 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

×