In the real business scenario of integrating SOA/AIA applications with Oracle Business Activity Monitoring (BAM), one common requirement is that such integration should not impact the operations of business systems running on SOA/AIA in terms of high availability and performance. To achieve this goal, one option is to use BAM Adapter or BAM Sensor Actions with Batching enabled. This article explains how batching works in Oracle BAM Adapter.

Why You Need Batching

When talking about batching, the first impression you may have is that you put a set of data into a package or a batch, and send it across for processing as a whole. In the BAM Adapter context, batching not only allows a group of XML payloads to be sent to the BAM Server side, but also changes the behavior of a synchronous invocation to BAM Server API to Async.

In mission critical applications, the preferred approach to integrate Oracle BAM with live data feed is using the Fire and Forget Message Exchange Pattern (MEP). Fire and Forget MEP has two major benefits compared to synchronous integration pattern:

• High Performance – Threads invoking BAM Adapter APIs are not blocked by down stream operations. Thus the slow execution of down stream code should not impact the performance of the core business system.
• High Availability – The failures including application failure such as errors due to invalid payload,  and system failures such as system outage due to maintenance, will not impact the normal operations of the main system. For example, in the Order to Cash (O2C) flow of AIA Communication PIPs, data integration between AIA and BAM should be in an asynchronous manner, thus, failures and outage of BAM will not impact AIA operations.

When Oracle BAM Adapter or BAM Sensor Actions is used, you should always enable batching to leverage the Fire and Forget MEP. In the next section, you will see how BAM Adapter works with batching enabled.

How Batching Works

Oracle BAM Adapter is a JCA compliant adapter that primarily converts Oracle BAM operations (Insert, Upsert, Update, and Delete) into the standard Web Services Interface described by WSDL.

By default, BAM Adapter operates in a synchronous manner as shown in the following diagram.

The caller thread T1 initiated in Oracle BPEL Process Manager invokes BAM Adapter operations in a synchronous way, and the same thread T1 continues executing BAM Server (Active Data Cache) API.

The behavior changes if batching is enabled shown in the following diagram.

Oracle BAM Adapter works in the following way when batching is enabled:

1. The caller thread T1 sends the request in the XML format to Oracle BAM Adatper.
2. Oracle BAM Adapter processes the request and delegates the operation to BatchProcessor, which is a module in BAM to handle batch processing.
3. BatchProcessor inserts the request message into a batch and release the caller thread T1.
4. BatchProcessor determines when to send the batch to an internal queue based on the following rules: The number of messages in the batch reaches the threshold specified by the Batch_Lower_Limit attribute or the timer specified by the Batch_Timeout attribute expires (5 secs by default).
5. The batch in the queue is scheduled to be flushed to BAM by an external thread T2. The queue size is specified by the Number_Batches atribute.

So you can see that the caller thread T1 is not block by BAM server operations.

Summary

In summary, batching should be always enabled if integrating BAM with mission critical applications (for example, O2C PIP) using Oracle BAM Adapter.