Publishing process information using sensors and AQ

Sensors in Oracle BPEL PM provide a nice mechanism to publish in-flight process data in a fire-and-forget fashion. The information that is published (sensor data) is separated from the communication mechanism (sensor action) which is a good thing: it promotes separation of concerns. JMS and BAM are supported communication mechanisms to publish sensor data, native Oracle AQ is not. It is however possible to use JMS over AQ instead of in-memory or file-based JMS for transactional and persisted message delivery and integration with database components. I’ve described the involved steps to publish sensor data from BPEL PM to AQ-backed JMS and subscribe to these events from ESB since it is bit of a configuration-nightmare. These steps apply to SOA Suite 10.1.3.4:

• Create a new AQ queue or topic (multi-consumer queue) in the database; e.g. MyQueue. These AQ destinations are typically created in the schema “JMSUSER”. Make sure its payload is of type JMS text (SYS.AQ$_JMS_TEXT_MESSAGE) and not XMLType. If not already there, configure a connection pool and data source in OC4J that refers to the database schema that owns the AQ destinations.
• Create a Database Persistence provider in OC4J. In Enterprise Manager go to oc4j_soa –> Administration –> Database Persistence and click “Deploy”. You could e.g. use JMSUserRP as Resource Provider name and JMSUserRA as Resource Adapter name. Point to the data source as described in the previous step.
• Create a Resource Adapter connection factory for the newly created Resource Adapter by navigating to oc4j_soa –> Applications –> Default. Select the module from the Resource Adapter list that you’ve just created. Create a new Connection Factory and new Administered Object. Use the queue interfaces -e.g. javax.jms.XAQueueConnectionFactory- in case you publish to an AQ queue, and the topic interfaces if you use a multi-consumer AQ queue -e.g. oracle.j2ee.ra.jms.generic.AdminObjectQueueImpl. Examples of JNDI names are JMSUserRA/XAQCF for the connection factory and JMSUserRA/Queue for the administered object.
• Define a sensor and sensor action in BPEL PM. Either choose “JMS Queue” or “JMS Topic” as “Publish Type” in the sensor action. Enter the connection factory JNDI name from the previous step as JMS Connection Factory, e.g. JMSUserRA/XAQCF and the JNDI location of the AQ queue or topic. The last value should be like: [JNDI name of the "Administered Object"]/[either "Queues" or "Topics" depending on the AQ type]/[Name of the AQ queue or topic]; for example JMSUserRA/Queue/Queues/MyQueue.

Now, you can create an ESB project that subscribes to the published sensor events and actually does something useful with it.

• Create an inbound JMS adapter in a new ESB project. Enter the Resource Adapter connection factory -e.g. JMSUserRA/XAQCF- as JNDI name in the first step and select the correct AQ destination from the browse list in the next step.

And voila you’re done.

There are two sides to this. First of all -not the most important one however- is the technical implementation and configuration details as described above.

Secondly it provides a nice pattern. You can use sensors to publish relevant in-flight process data from running instances. This promotes decoupling since BPEL PM does not (need to) know who is interested in the sensor data. It might be that nobody is interested in it. Secondly, you can use ESB’s fan-out and content-based routing patterns and connectivity features to route process data to all interested components, possibly filtering and transforming its data.