Duplicate JMS message consumption in cluster

We come across common situation where we have duplicate JMS message consumption from BPEL where there is a cluster


For example, if we have a cluster of 3 nodes then when we deploy BPEL to consume message then there will be three BPEL instances processing same JMS message.This is because the nature of how distributed topics combined with clustered environment works

Obviously nobody wants to process same message multiple times.
To make sure only one node processes the message we need to set below property in JMS .JCA file

<property name="DurableSubscriber" value="UniqueSubscriberName"/>

This property name is used to identify a durable subscription. When working with durable subscriptions ensure that ClientID is also specified in addition to DurableSubscriber property. ClientID is specified as part of the factoryProperties property when defining a JMS adapter managed connection factory instance
Weblogic jms expects the combination of durable subscription + clientID to be unique across the durable subscriptions, just client ID or durable subscriber property alone does not suffice.

To set ClientID on deployment JNDI, follow below steps

1.Log in in to the WLS console.
2.Navigate to => Deployments and select "JmsAdapter" from the right hand side.
3.On the configuration tab expand oracle.tip.adapter.jms.IJmsConnectionFactory and select your connection factory (e.g. "eis/wls/Topic")
4.In the "FactoryProperties" add the Id (e.g. "ClientID=SOAClientSubscription1;")
5.Click on save and follow the onscreen instructions and remember to update the JmsAdapter, in order for the changes to take effect

[OSB Kernel:398139] The binding type of service is based on wsdl, the service should have ws-policy configuration

If anybody has encountered below error message when importing OSB projects into sbconsole, then no need to panic we have a solution to correct that

Error
OSB Kernel:398139]The binding type of service is based on wsdl, the service should have ws-policy configuration

Cause
This happens when we have OSB service already existing with different security policy setup than importing one.

I would like to discuss one of possible causes here

Lets say if we have existing service in the server is(policies are being referred from WSDL)

and importing one with below security policy configuration(policies are being referred from OWSM store)

This will conflict

Solutions

1. A simple solution would be remove existing service and import new one
2. Import new OSB code with WSDL chosen (if WSDL has already reference policy)
3. Change existing service in OSB to to refer policies from OWSM

Hope this would help

BPEL 11g Default JMS Properties

When I was working on a project I observed BPEL 11g is putting some useful JMS message properties when message is being produced from BPEL to JMS queue/topic.

Following are JMS message properties  that BPEL engine copies automatically

tracking_ecid
tracking_compositeInstanceId
tracking_parentComponentInstanceId
tracking_conversationId

We can use above proprieties in many ways and to solve certain correlation problem between BPEL instance that generated it and applications that are consuming.

For example, we build a reporting application which reads messages from JMS destination and report messages onto dashboards. If we wanted to display composite instance id that generated the message then we can simply resort to this property .