Friday, December 6, 2013

Oracle BAM. Looking at different integration options

In order to monitor process flow, Oracle Business Activity Monitoring (BAM) can be used. Oracle BAM is part of the Oracle SOA Suite. What are the options for implementing Oracle BAM in the context of Oracle SOA composites? When should you use which method to integrate with BAM? In this post I'll describe the different methods of integration with Oracle BAM and the work required in order to get it working. The below screenshot was taken from; to illustrate what an Oracle BAM dashboard looks like.

Integration methods

The below actions need to be performed for every integration type. In order to get Oracle BAM working and allow integration from Oracle SOA composites, the following actions need to be performed;
- extending the SOA domain with BAM libraries and creating a BAM managed server (see this pretty easy with the Weblogic Domain Configuration Wizard)
- configure the BAM adapter (described on

The below sections describe integration options on composite level and on BPEL level.


When feeding BAM with information at the composite level, there are two JDeveloper IDE supported options available. Both require the definition of Data Objects in BAM and a mapping to these Data Objects. You can also create a custom integration with a JMS queue. For all described options on composite level, custom dashboards need to be created in BAM.

Using the BAM adapter

Using the BAM Adapter is similar to using the DbAdapter.

Using sensors with sensor actions for BAM

Using sensors and sensor actions has the added benefit of also allowing searching for specific messages (sensor values) in the dehydration store from the Enterprise Manager. The following post nicely illustrates that;

Custom JMS

Of course custom integrations are also possible by using JMS queues, but you get less IDE support to accomplish that. Not only do you need to configure Data Objects, but also Enterprise Message resources in BAM. For processes which cannot easily use the BAM adapter, this is a viable alternative.


At the BPEL level you can of course use the same methods as at composite level. However in BPEL you can also use the activity monitoring option from the monitoring view.

The BAMAdapter deployment needs to be configured even when using the Activity Monitoring option in BPEL since this adapter is still used in this case, however not visible in the composite editor.

Although Monitor Express is a dashboard is supplied by default, it is not installed by default! Read SOA_HOME/bam/samples/bam/MonitorExpress/README.txt on how to install it.

In my case I had to add;


to /u01/Middleware/Oracle_SOA1/bam/config/BAMICommandConfig.xml
and run from /u01/Middleware/Oracle_SOA1/bam/samples/bam/monitorexpress/bin

After having deployed the dashboard, I could access it in BAM Viewer. When testing with a BPEL process, I got the following errors;

[2013-12-06T11:46:50.666+01:00] [soa_server1] [ERROR] [] [oracle.soa.bpel.engine.sensor] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 11d1def534ea1be0:-3f1c784c:142c7691cff:-8000-000000000000095e,0:2] [APP: soa-infra] [ soa-infra] [ fabric] [ helloworld_client_ep] [ HelloWorld_pt] [composite_instance_id: 30050] [component_instance_id: 30050] [composite_name: HelloWorld!1.0] [component_name: HelloWorld] Error in publishing data to BAM[[ Connection refused
        at Method)

After updating the BAM adapter, checking the Monitor Config (monitor.config)

<?xml version = '1.0' encoding = 'UTF-8'?>
    <BAM dataObjectsFolder="/Samples/Monitor Express/" adapterConnectionFactoryJNDI="eis/bam/rmi" batch="true" deploymentProtocol="http">
  <Deployment ignoreErrors="true"/>

and redeploying the process, it worked. Maybe the error was caused because the dashboard had not been available on initial deployment and the dataObjectsFolder is part of the configuration in monitor.config. The result was that in Monitor Express, my BPEL test process (helloworld) was visible in BAM. The Monitor Express dashboard allows 'zooming in' to specific processes and even to the activity level. Depending on how the process is modeled and how activities are named, the dashboard is probably only usable by people with a bit of insight on how the implementation of a business process looks like in BPEL.

Oracle BPM also has specific integration options with Oracle BAM similar to BPEL. I will not describe this separately since the mechanism is similar. The usability by business users however will be greater since BPMN activities are more easily readable by business users.

Comparing the integration methods

In order to compare the different methods, three variables are taken into account.
- Actions required
- Business value
- Technical value

These three variables were taken because they appeared to differ most among the different methods.

The number of actions required in order to get it working, is counted. The following actions are counted;
- Define BAM data objects and map data
- Define BAM dashboard
- Define BAM enterprise message resource

The score can thus be a value from 0 to 3. Lower indicates less effort is required to get it up and running.

The business value is estimated as the potential to provide business friendly dashboards. The technical value is estimated as the amount of information which can be extracted from the dashboard (which might be useful for operators). Of course it is possible to make complex Data Objects and spend a lot of time at making everything available in BAM dashboards and have your error handling also linked to sending messages to BAM, this is however not a usual way of using BAM. Thus when creating custom dashboards I have considered a focus on measuring KPI's and not values with only technical meaning.

Please keep in mind that this list is a personal evaluation. I have not taken into account stability and performance. Also I have not looked at potential problems when running in a high available environment.

I can imagine that using sensors costs a little extra since the data is saved in BAM and as sensor data in the SOAINFRA schema. Most likely direct use of JMS (not using JMSAdapter) will be faster then using the BAMAdapter since JCA has some overhead. However, without measures, these assumptions might be incorrect.

The JMS / Enterprise Message Resource method has high reuse potential while the BPEL Activity Monitor, although easily implemented, only has the scope of configured BPEL processes. Depending on specific requirements, one of the methods will be most suitable. This is not a one size fits all story.

No comments:

Post a Comment