You can raise business events when a situation of interest occurs. For example, in a loan flow scenario, a BPEL process service component executing a loan process can raise a loan completed event at the completion of the process. Other systems within the infrastructure of this application can listen for these events and, upon receipt of one instance of an event:

• Use the event context to derive business intelligence or dashboard data.

• Signal to a mail department that a loan package must be sent to a customer.

• Invoke another business process.

• Send information to Oracle Business Activity Monitoring (BAM).

Business events are typically a one-way, fire-and-forget, asynchronous way to send a notification of a business occurrence. The business process does not:

• Rely on any service component receiving the business event to complete.

• Care if any other service components receive the business event.

• Need to know where subscribers (if any) are and what they do with the data.

These are important distinctions between business events and direct service invocations that rely on the Web Services Description Language (WSDL) file contract (for example, a SOAP service client). If the author of the event depends on the receiver of the event, then messaging typically must be accomplished through service invocation rather than through a business event. Unlike direct service invocation, the business event separates the client from the server.

A business event is defined using the event definition language (EDL). The EDL is a schema used to build business event definitions. Applications work with instances of the business event definition.

The EDL consists of the following:

• Defined events

  One or more event definitions (event-definition element) with the same namespace (targetNamespace attribute of definitions root element), each having a local name (name attribute of the event-definition element). The namespace and local name constitute an event name (QName).

• Payload definition

  The most common use for a definition is an XML Schema (XSD). The payload of a business event is defined in an XSD that is imported (through the schema-import element) into the EDL. Each defined event (that is, event-definition element) can have a reference to an imported payload XSD element (the element attribute of the content element). The schema URI is contained in the root element of the payload.

The following example shows an EDL file with two business events in the BugReport event definition: bugUpdated and bugCreated. The namespace (/model/events/edl/BugReport) and associated schema file (BugReport.xsd) are referenced.

<?xml version = '1.0' encoding = 'UTF-8'?>
<definitions targetNamespace="/model/events/edl/BugReport"
 xmlns:ns0="/model/events/schema/BugReport"
 xmlns="http://schemas.oracle.com/events/edl">
   <schema-import namespace="/model/events/schema/BugReport"
 location="BugReport.xsd"/>

   <event-definition name="bugCreated">
      <content element="ns0:bugCreatedInfo"/>
   </event-definition>

   <event-definition name="bugUpdated">
      <content element="ns0:bugUpdatedInfo"/>
   </event-definition>
</definitions>

These two events are available for subscription in Oracle Mediator and a BPEL process.

Business events are deployed to the Oracle Metadata Services Repository (MDS Repository). Deploying a business event to the MDS Repository along with its artifacts (for example, the XSDs) is known as publishing the EDL (or event definition). This action transfers the EDL and its artifacts to a shared area in the MDS Repository. An object in an MDS Repository shared area is visible to all applications in the Resources window of Oracle JDeveloper. After an EDL is published, it can be subscribed to by SOA components such as Oracle Mediator or a BPEL process.

A subscription is for a specific qualified name (QName) (for example, x.y.z/newOrders). A QName is a tuple (URI, localName) that may be derived from a string prefix:localName with a namespace declaration such as xmlns:prefix=URI or a namespace context. In addition, subscriptions can be further narrowed down by using content-based filters.

Business events are published to the EDN. The EDN runs within every Oracle SOA Suite instance. Raised events are delivered by EDN to the subscribing service components. Oracle Mediator service components and BPEL process service components can subscribe to and publish events.

The EDN is based on a standard JMS messaging infrastructure that supports business event-based interactions among Oracle SOA Suite components and non-Oracle SOA Suite components. The EDN provides two JMS-based types:

• Oracle WebLogic Server JMS: By default, all business events use a single, default Oracle WebLogic Server JMS topic.

• Oracle Advanced Queueing (AQ) JMS

You can create additional JMS topics (Oracle WebLogic Server JMS or AQ JMS) and map different event types to these additional JMS topics in Oracle Enterprise Manager Fusion Middleware Control.