The source code in the following example shows how the composite.xml source changes for the subscribed and published events of a BPEL process service component.

<component name="EventBPELProcess">
   <implementation.bpel src="EventBPELProcess.bpel"/>
   <property name="configuration.monitorLocation" type="xs:string"
             many="false">EventBPELProcess.monitor</property>
   <business-events>
     <subscribe xmlns:sub1="http://mycompany.com/events/orders"
                name="sub1:OrderReceivedEvent" consistency="oneAndOnlyOne"
                durable="true" runAsRoles="$publisher"/>
     <publishes xmlns:pub1="http://mycompany.com/events/orders"
                name="pub1:ProductSoldAlert" persistent="true" priority="7"
                timeToLive="36000000"/>/>
   </business-events>
</component>

    <business-events>
      <publishes xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO"
 name="pub1:NewOrderSubmitted" persistent="true" priority="7"
 timeToLive="36000000"/> 
    </business-events>
  </component>

While not explicitly demonstrated in this example, you can define XPath filters on events. A filter is typically present in event subscriptions. The subscribe element limits the type of event to which this service component is subscribed, and the filter section further limits the event to specific content in which the component is interested. In the following example, the event is accepted for delivery only if the initial deposit is greater than 50000.

    <business-events>
        . . .
        . . .
        <filter>
            <xpath xmlns:be="http://oracle.com/fabric/businessEvent"
                 xmlns:ns1="http://xmlns.oracle.com/singleString"
                   <xpath expression= "/be:business-event/be:content/
                   sub1:AccountInfo/Details[@initialDeposit > 50000]" />
        </filter>
      . . .
      . . .
    </business-events>

The standard BPEL activities such as receive, invoke, onMessage, and onEvent (in BPEL 2.0) are extended with an extra attribute bpelx:eventName, so that the BPEL process service component can receive events from the EDN event bus. The schema for the eventName attribute is shown in the following example:

<xs:attribute name="eventName" type="xs:QName">
        <xs:annotation>
            <xs:appinfo>
                <tns:parent>
                    <bpel11:onMessage/>
                    <bpel11:receive/>
                    <bpel11:invoke/>
                </tns:parent>
            </xs:appinfo>
        </xs:annotation>
    </xs:attribute>

The following example shows how the eventName attribute is used in the BPEL source file:

<receive name="OrderPendingEvent" createInstance="yes"
         bpelx:eventName="ns1:OrderReceivedEvent"/>
<invoke name="Invoke_1" bpelx:eventName="ns1:ProductSoldAlert"/>

If the bpelx:eventName attribute is used in a receive, invoke, onMessage, or onEvent (in BPEL 2.0) activity, then the standard attributes such as partnerLink, operation, or portType are not present. This is because the existence of the bpelx:eventName attribute shows that the activity is only interested in receiving events from the EDN event bus or publishing events to the EDN event bus.

The XSD file for the BPEL process service component is slightly modified, so that the partnerLink, operation, and portType attributes are no longer mandatory. The Oracle JDeveloper validation logic enforces the presence of either the bpelx:eventName attribute or the partnerLink, operation, and portType attributes, but not both. The following example shows the modified schema definition of a BPEL receive activity:

<complexType name="tReceive">
        <complexContent>
           <extension base="bpws:tExtensibleElements">
                <sequence>
                    <element name="correlations" type="bpws:tCorrelations" minOccurs="0"/>
                    <group ref="bpws:activity"/>
                </sequence>
                <!- BPEL mandatory attributes relaxed to optional for supporting BPEL-EDN ->
                <attribute name="partnerLink" type="NCName" use="optional"/>
                <attribute name="portType" type="QName" use="optional"/>
                <attribute name="operation" type="NCName" use="optional"/>
                <attribute name="variable" type="NCName" use="optional"/>
            </extension>
        </complexContent>
    </complexType>

The schema definition for the invoke and onMessage activities are modified similarly.