HEADSTRONG Consulting

Alerts are critical components for efficient monitoring the health of the System and Business.

The Out-of-the-Box approach

Oracle SOA Provides BAM component for the monitoring needs. BAM captures the events across Event Sources - BPEL, B2B, OSB and OWSM, as BAM proprietary Data Objects. The Data Objects can be mined for providing Reports and Alerts.

Alert Management framework provided by Oracle SOA Suite is depicted below.

BAM Sensor, Oracle BPEL proprietary functionality, allows you to track BPEL composite instances, based on Data.

BAM Adapter, a JCA standard component has a wizard based interface for accessing and operating on BAM Data Objects.

BAM JMS plug-in taps information from JMS Queues and Topics. BAM Data Object� wizard allows you to map the Data to Data Object Schema.

The services of BAM adapter are offered as Web Service Library. The Batching and other JCA capabilities provided by BAM Adapter is not available as a Web Service.

BAM internally converts the Data acquired though the above interfaces into BAM Data Objects.

The Data Objects can be mined to create Dashboards containing Reports and Charts

BAM provides Real-time Caching mechanism to create dynamic alerts.

The Out-of-the-Box approach has few challenges :-

� BAM addresses the monitoring part well, but resolution part is lacking. Resolution scenario involves Manual resolution workflows, Retriggering instances, Auditing the Error and Resolution flows.

� The data stored in BAM Database is only accessible as BAM Reports and Alerts.
The custom resolution components cannot be built on BAM Data Objects since it is exposed only for BAM specific Alerts and Reports.

� Reports have limited functionality and are not flexible enough to frame dynamic SQL queries. This rigidity at the presentation layer, makes BAM's excellent data capture mechanism of less use.

� The configuration is scattered across BAM ( Data Object Design and Mapping, Data Sources ) and Event Source components ( Transforms, Connection information to BAM components, Lookup data for populating Data Objects ).
Ex: Any� changes to the BAM Component, will impact all the composites. -Composite.xml for connection information.� XSL for Data specific changes.

� The BAM UI works only on Internet Explorer.�

Tweaking the Out-of-the-Box approach

We can also tweak the out of the box approach as depicted below.

The Metadata for the framework is stored in a centralized MDS Store ( DVMs, Property files ), which can be accessed across all apps.

The Custom XPath function, used in OSB and BPEL, will wrap the redundant transformation logic needed to form the Event Log.

Now, the BPEL / OSB Code can just pass the minimal Primary IDs and Payload required. The event log is formed with the additional information from configuration store.

B2B Event logs are published to the BAM Data Source Queue, by enabling at the B2B Administration console.
The information provided adheres to B2B Schema which has all the information except for the B2B Payload. A Custom BPEL component forms the Event Log, based on the input and configuration metadata.

OWSM Gateway provides logs to file as standard policy. We can build a Custom Assertion Policy, which publishes the Event Logs to the Event store.

BAM Data Objects can also be created if needed, by tapping the events from the Event Store.

JMS Topic / Queue acts as Event store collating alerts across all event sources.�

The event store, accessible as JMS Queue / Topic will be tapped by� - Work list Apps for Manual resolution, Notification for KPI overshoots or System malfunction, Archival of logs, Custom Dashboards.

How the tweaking helps ?

We are basically tweaking few out-of the box components to obtain a centralized resolution, notification and logging framework.

The Custom component development is mostly one-time effort. Additional interfaces can be plugged in with just additional metadata configuration .

� The Custom XPath function, wraps the redundant functionality in a single static function call. This enables code reuse, thus minimizing development effort required by the BPEL / OSB Developer.�

This functionality replaces the redundant Xforms, we will be performing for populating Data Objects.

� Centralized Configuration Data Store eases Development,� Deployment and Maintenance tasks. Any Schema or other Metadata change is accomplished with MDS update.
This is in contrary to the standard approach wherein we have redundant configuration data across components� BPEL, OSB, B2B and BAM.

� The Business Process Data is published to JMS Topic / Queue, rather storing as BAM Data Objects.

This makes the design modular and independent, rather getting tied to BAM Application.

� The generic event store is thus accessible across various Applications and becomes extensible, providing limitless possibilities.

We can also add BAM Alerts and Reports as an additional External App utilizing the event store data.

Observation and Learning.

� The Custom XPath Function involves coding. �Stick to XSL Transforms, with DVM Lookups for Configuration data, if you want to refrain from coding. This approach will add redundant mapping and Composite wires.

� The Custom XPath Function is a static call. So, make use of static initializers for all global object initialization.

� The JMS publish part need to be an independent transaction. Else the logs will also be rolled as part of the parent BPEL / OSB container. You can set it while creating the JMS Session.

qconnection.createQueueSession( true, Session.CLIENT_ACKNOWLEDGE )

� JAXB to populate the Event Log will lead to expensive marshalling and unmarshalling. Forming the Event log as StringBuffer Object could be another faster option.

� The Composite information can be captured as part of Event Log.

public Object call(IXPathContext iXPathContext,

�� List list) throws XPathFunctionException {

�� // get the cubeContext of bpel instance

�� Map props =

�� (Map)iXPathContext.getVariableValue(null, null, "xpath-function-data");

�� ICubeContext ctx = (ICubeContext)props.get("ICubeContext");

�� com.collaxa.cube.engine.core.ICubeInstance �cubeInstance = CubeContextHelper.getCubeInstance(ctx));

�� cubeInstance .getCompositeInstanceId() / getCompositeName() / getCompositeRevision()

}

� The Composite Instance Link on em console can be formed as below.

http://<hostname>:<port>/em/faces/ai/soa/messageFlow?target=/Farm_<domain_name>/<domain_name>/<server_name>/<partition>/<composite_name>%20[<version>]&type=oracle_soa_composite&soaContext=<partition>/<composite_name>!<version>/<instance_id>

� The MDS Configurations can be accessed as per the source code link.

https://java.net/projects/mds-explorer

� The DVM information can be accessed from Java code with the help of this link.

http://rathinasaba.wordpress.com/2012/06/30/oracle-soa-11g-dvm-from-java-client/

� The Custom XPath Function can be shared across OSB and BPEL components. OSB passes XML as Apache XmlObject. It can be converted to DOM Node.

Epilogue

I don't prefer homegrown custom components as it adds up development and maintenance efforts.

Alert management framework demands few customizations since multiple components provided by Oracle SOA Suite package becomes a curse in disguise. Each component has its core strengths and weakness, major weakness being centralized management console.

Hope future Out-of-the-Box software provides comprehensive solutions for Alerts and Exception Management.