In a previous post – Oracle 11g SOA Suite – Straightforward Mediator example (employees from file to database) – I demonstrated how we can quickly implemented a Service Composite that reads files with Employee data and turns them into new HR database records (well, simply creates records in the SCOTT.EMP table). In this article, we will start with that Composite and have it Publish Business Events. The Business Event of course is the arrival of a new employee. This composite that reads the initial ‘ new employee document’ is the first outpost in the enterprise to witness the event. And as such has the ability and responsibility to make that fact known to every interested party in the organization, without even knowing what the interested parties are. That is what the EDN is for and what Business Events help do: in a very loosely coupled way can one process inform others.
The ReadNewEmployees Mediator Component will be extended in this article to do one additional thing: it will publish an event whenever it reads a new employee file. The event is handed over to the EDN and is no longer the responsibility of the Mediator component. Whether anyone consumes the event – it does not know or care. Note: previously we could achieve something very similar using JMS Topics that ESB Services of BPEL Processes published to and other ESB Services or BPEL processes could be started from.
1. Before we create the event definition, let’s first define the element that we base the event payload on.
In JDeveloper, create a new XSD document
Specify the name for the XSD document
Specify the Element – in this case NewEmployee – with its Child Elements and their types:
2. Now return to the Composite diagram. In the upper left hand corner, you will find an icon to click on for creating a new Event Definition File:
Enter a name for the event definition file – in which multiple event types can be created:
After pressing Finish, the event editor is opened.
3. Click on the Add Event icon. Next enter the name for the event type and find the Element from an XSD document to base the event on.
Close the Add an Event dialog.
Add this point, the Business Event has been defined. No one produces it. No one consumes it. It sits in the middle – waiting for publishers and subscribers to start taking advantage of it.
Let’s introduce a Publisher of this event. The ReadNewEmployee Mediator Component discussed in the article referred to above is a likely candidate: by picking up a file with new employee details, it registers the fact of a new employee and can turn that fact into an event published for the benefit of others.
4. From the RMB menu on the Mediator Component, select the option Add Published Events
The Event Chooser dialog opens. This dialog allows us to choose the event type for which the component will be publishing events. Well, we only have the one event type to choose from – so select the NewEmployee event:
and press OK.
The Composite diagram shows with the little lightning icon that the Mediator Component publishes an (at least one type of) event. It also shows in the little Published Box which type of event it is: NewEmployee.
5. We now have to make sure that when that event is published, it has a proper payload. Double click on the Mediator component to edit the Routing Rule to the Business Event:
Click on the Mapping icon to create the mapping between the Employee data read from the File (passed in by the File Adapter Service) and the Business Event payload (the NewEmployee element).
As the payload of the NewEmployee business event is seen as an AnyType, we cannot use the graphical mapper. Instead, we need to do some dirty XSL-T work ourselves.
In this case, the following piece of XSLT will do the job:
This template builds up the newEmployee element with child elements as specified in the XSD definition. It uses the xsl:value-of instructions to copy values from the children of the Employee element produced by the File Adapter Service to the newEmployee element.
With this mapping complete, we can redeploy the SCA Composite to the SOA runtime environment (the Integrated OC4J Server in this case).
When deployment is complete, every new employee whose file is read will also trigger a Business Event. At this point, sadly enough, there are no listeners to the event. But that is really part of the beauty of the decoupled approach of the Event Driven Architecture.
This look at the audit trail for an instance of the ReadNewEmployee composite demonstrates that the NewEmployee Event was published.
Hi Lucas,
Just one question, We are trying to capture error when EDN is down at the time of publishing the Event.
How can we capture that error.
Manish
Lucas,
Your note “Note: previously we could achieve something very similar using JMS Topics that ESB Services of BPEL Processes published to and other ESB Services or BPEL processes could be started from.”
Does this mean that if the subscriber is down that the event it is interested in will be lost to it just like a JMS Topic subscriber?
Â
Brett