Thursday Aug 23, 2012

Integrating Oracle E-Business Suite with Fusion Cloud Applications

Business Event Propagation Pattern


How do you propagate business events raised by an on-premise Oracle E-Business Suite application to a SaaS-based Oracle Fusion Application in a reliable and scalable manner?


  • On-premise Oracle E-Business Suite application triggered a business event.
  • SaaS applications such as Fusion Applications will want to execute business processes based on occurrence of the business events.
  • You need to propagate the business events via the internet to a SaaS-based Oracle Fusion Application behind a firewall.
  • The business event should not be lost at any point and you need to ensure the reliability.


Following are side effects, challenges, and other issues you should expect when implementing a solution to address this problem:

  • You need to strike a fine balance with respect to choosing the event payload. You need to pass adequate information to limit chatty conversations, while at the same time, you must ensure that large amounts of data is not passed, thereby mitigating the abuse of resources.
  • Expecting the SaaS application to always be available at the time of occurrence of business events in the Oracle E-Business Suite application is not realistic.
  • Propagation of business events must be scalable.
  • There could be situations where the SaaS applications might be unavailable for certain period of time due to various reasons - resulting in accumulation of these events in the source system. And the availability of the target application after extended period of outage could result in a flurry of events being sent to the target application

Use Cases

Some of the Fusion Application (FA) processes need to be triggered when a business event is raised in Oracle E-Business Suite

  • Multiple business events would be raised in Oracle E-Business Suite following the creation of a Purchase/Sales Order document.
  • All these business events should be propagated from Oracle E-Business Suite to FA processes.
  • Fusion Application processes need to execute relevant tasks for a business event.


Design an integration process to handle business event propagation between the on-premise Oracle E-Business Suite application to a SaaS based Fusion Application behind a firewall.

The design must accommodate the following:

  1. Ensure reliable and scalable event propagation.
  2. Take into account the current technical capabilities of the on-premise application.

One option to address the above design requirements is having an event capture service that receives and persists the event data in the target application before invoking the actual event processing service:

The event capture service should:

  • Provide a synchronous web service interface that can receive the business event payload from the on-premise Oracle E-Business Suite application.
  • Allow the client application to send a unique identifier for each event. This could enable the event capture service to ensure that it is not processing any duplicate requests.
  • Persist the business event data within the SaaS-based application-specific tables to provide reliability. This should be the primary responsibility of the event capture service.
  • Reply to the on-premise Oracle EBS application with a success or error status.
  • Invoke the FA event processing service that has an asynchronous interface.

Optionally, after reliably persisting events, actual processing of the persisted event by a downstream application/event processing service can be triggered either by invocation or polling methodology. As for the invocation approach, the event capture service can be coded to trigger the downstream application/event processing service that can act upon the persisted event. As for the polling approach, the downstream application/event processing service can be designed to look for the arrival of new events in the application tables.

In the case of any event-capture service invocation failure, an EBS workflow notification will be raised by the EBS infrastructure. EBS administration can then act upon the notification and resubmit the failed events after resolving any system errors, such as problems with the network, unavailable Fusion Application services, and so forth.

In case of event processing service invocation failure, Fusion Application services should capture this information and populate it to application specific dashboard that can allow resubmission of a faulted event.


The following diagram illustrates the high-level steps involved in the implementation of this pattern:

Here are the high-level implementation tasks:

  1. The Oracle E-Business Suite application raises a business event using PL/SQL API WF_EVENT.Raise. (Developer task)

The event data can be passed to the Event Capture Service within the call to the WF_EVENT.Raise API. Alternatively, if the event data or message payload is required for a subscription, the Event Capture Service can obtain the data or payload by calling the generate function of the event.

We recommend that the event contain minimal data (the unique transaction ID, for example) when the business event is raised.

    • One way to enrich the event with the full payload data required for the call to the event capture web service is to use a generate function defined on the business event itself. However, the drawback of using a generate function is that it is defined at the business event level and would therefore make the business event specific to integration with a specific application module.
    • A generic way to accomplish the event enrichment would be to create a custom Java Rule Function class that extends WebServiceInvokerSubscription. You would then indicate this custom class as the Java Rule Function while configuring the business event subscription. This would make the subscription specific to a specific application module, but not specific to the entire business event.
    • Another event enrichment approach would be to have the FA event processing service call the Oracle E-Business Suite web service by passing the business transaction ID as a parameter to get the entire event payload.

There are pros and cons to each of the above approaches. The first two approaches can help to avoid round tripping between FA and EBS while the third approach can reduce the message payload size that needs to be transferred across the network.

For more information about the WF_EVENT.Raise API, see Oracle Workflow API Reference, "Event APIs."

  1. The Oracle Workflow Business Event System (BES) identifies that the event has a subscription with the Java Rule Function (Administration task: Configure the business event subscription.)

For more information about creating the event subscription, see Oracle E-Business Suite Integrated SOA Gateway Implementation Guide, "Implementing Service Invocation Framework". Because the phase on the local subscription is >100, the business event instance will be enqueued to the WF_JAVA_DEFERRED AQ so that it can be handled asynchronously. (Administration task: The phase can be configured while specifying the Execute condition of the business event subscription.)

  1. The Java Deferred Agent Listener running on a concurrent tier will dequeue the event message and then dispatch the event to the Java Business Event System. The seeded Java Rule Function and its associated event subscription information will then be retrieved and executed to synchronously invoke the web service exposed by the SaaS application. (Infrastructure task)
  2. The SaaS application interface for Oracle E-Business Suite should capture the event payload, persist it, and send an acknowledgment back to the E-Business Suite Service Invocation Framework. The event capture service can implement these tasks by creating a BPEL-based SCA Composite. (Developer task)
  3. It is important that the event capture service is designed to be as lightweight as possible. This is to ensure the latency is minimal. It should persist the event into the application-module-specific event capture tables in the SaaS application's data store and send an acknowledgment back to EBS in a synchronous manner. The event capture service should have a synchronous interface and issue a fault when there is an event payload persistence failure. (Developer task)
  4. E-Business Suite's Service Invocation Framework will call this event capture service synchronously. (Infrastructure task)
  5. A failure in the synchronous invocation of the Java function calling the SaaS-enabled FA event capture service results in a fault in the EBS Service Invocation Framework. (Infrastructure task)
  6. When the service invocation performed by the EBS Service Invocation Framework returns a fault or an exception due to service unavailability, the event is enqueued to the WF_JAVA_ERROR queue for error processing. This triggers the execution of the error event subscription that launches an error workflow to create a workflow notification for the SYSADMIN. (Infrastructure task)
  7. Because the event capture service is exposed to the external world, it will invariably be protected by either SSL or WS Security. Hence, the E-Business Suite Service Invocation Framework must use the appropriate client policy (SSL-based web service invocation over the HTTPS protocol or web service (WS) security through UsernameToken-based Web Service authentication) to invoke the event capture service. (Administration task: WS-Security can be configured while configuring the business event subscription.)
  8. SaaS-enabled FA event processing services should read the persisted events and split the information into module-specific tables. (Developer task)
  9. The services should identify duplicate business events raised by EBS using unique business document/event identifiers created using composite keys formed by different business transaction identifiers. (Developer task)
  10. With the help of error processing, notification, and event resubmission features, EBS can successfully ensure the reliability of sending the event payload to the SaaS application at least once. (Administration task)


Implementation of this design pattern is based on the following assumptions:

  • The SaaS-based Fusion Application would return an immediate response after executing very limited amount of processing like persisting the captured event.
  • This implementation assumes that source application does take responsibility to limit the number of events being passed to the SaaS application. Consolidation of multiple-fine grained events to generate a coarse grained event by source application is one approach.
  • This pattern may be used in use cases involving trickle feed integrations. However, in situations in which events could be produced at a rate of 100 per second, for example, consider using the Bulk Event Propagation Design Pattern instead.
  • If a large number of events are being raised concurrently, one option that could be considered is to have Oracle E-Business Suite application stage the events locally on the EBS server and then transport them to the cloud via FTP. The SaaS interface should be able to process these uploaded files to read the contents and populate them into event capture tables. This will be discussed in detail in the blog on  bulk event propagation design pattern.

Related Patterns

Bulk Event Propagation Design Pattern (coming soon)


This is the blog about Oracle Business Integration Design Patterns. Our team which is part of Business & Data Integrations Development Organization at oracle, focuses on providing technical and architectural guidance & support to Fusion Applications, AIA as well as Product Development teams across various Global Business Units on designing & building integrations. This blog focuses on discussing the different types of integration use cases we have come across and how the design patterns prescribed, could be used to implement similar use cases leveraging various components (BPEL, OSB, Mediator, OBR, BAM, BPM, CEP, WLS) available in Oracle SOA & BPM Suite.


« August 2016