SOA11G: BPEL OneWayInvocation Issue - BUG

What is OneWay Invocation?
An Adapter (say File) reading inbound message from EIS and posting to BPEL for processing is pure OneWay invocation.

How does OneWay Invocation Works in BPEL?
Adapter reads the inbound message and then posts this message to BPEL Engine using OneWayDelivery Policy.

The oneWayDeliveryPolicy is from the Oracle 10g configuration property deliveryPersistencePolicy. The new configuration property name is bpel.config.oneWayDeliveryPolicy in composite.xml.



The oneWayDeliveryPolicy property controls database persistence of messages entering Oracle BPEL Server. By default (async.persist), incoming requests are saved in the delivery service database table dlv_message. These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process. This property persists delivery messages and is applicable to durable processes.

Something on OneWayDeliveryPolicy values:
Value	Description
async.persist (Default)	Delivery messages are persisted in the database in table dlv_message. With this setting, reliability is obtained with some performance impact on the database. When the client initiates a process instance, an invocation request is placed in an internal queue. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests. When a message is dequeued, Oracle BPEL Server allocates a thread to process the message.
async.cache	Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered. Message are not dehydrated into dlv_message table. Rest all is same as async.persist.
sync	Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance. So there is no role of invoke queue and worker bean here.

Issue:
We have many BPELs being invoked through Inbound Adapters. What we observed is that the Adapter instances are being generated, BUT the further BPEL instance never comes up. And this is happening only with OneWayInvocation BPELs and not with Request-Response BPELs. We checked dlv_message table. The inbound messages were being saved in it.

So we tried changing the OneWayDeliveryPolicy value to “sync” and BPEL instance started generating.

This leads us to the issue – Either invocation requests are not being enqueue into invoke queue OR the WorkerBeans are not able to de-queue them.

SOA11G: SOAP Header in Mediator 11G - BUG

Passing SOAP Header in Mediator is supported in 11G with very GUI support.

To receive the SOAP elements in mediator expression builder it is necessary that a SOAP Header is explicitly declared in the WSDL of the mediator. Likewise to send SOAP elements from Mediator to a target SOAP service, for expression builder a SOAP Header is to be defined explicitly in the WSDL of target SOAP Service.

For better understanding on defining SOAP Header in WSDL -
http://www.ibm.com/developerworks/xml/library/ws-tip-headers/index.html

Defining SOAP Header in the WSDLs:


In Mediator Expression Builder for Assign Values, we can select SOAP Header:


In Mediator Expression Builder for Assign Values, we can assign SOAP Header:


This way SOAP Header could be passed.

BUG Description: Observe how the root element of the SOAP Header has ns2_ETHHEADER (namespacePrefix_ElementName). Now what if the Element name itself has an Underscore in it, i.e. ETH_HEADER. Its an identified BUG with Oracle and has been solved in 11.1.1.6.

SOLUTION:
• Oracle has given a back-port FIX for 11.1.1.4
• Don’t have underscore in the SOAP root element.
• Go for SOA 11.1.1.6

SOA11G: Sending SOAP Header from BPEL 11G – JDEV BUG

This Article is regarding a JDEV bug which I hit while setting SOAP Header in BPEL.

JDEV Version: 11.1.1.4
Bug 12541901 - JDEV SETS INCORRECT BPELX:HEADERVARIABLE INSTEAD OF BPELX:INPUTHEADERVARIABLE
Solution: JDEV PATCH 12541901 (Download through Metalink).

Receiving and Sending of SOAP Header from a BPEL Component is done as below:

Create a BPEL variable of type string, to be received and passed through SOAP Header.
If we want to pass a Complex data through SOAP then we have to have the corresponding schema for that.
SOAP Header Variable to be used in BPEL could be SimpleType, MessageType or ElementType.

For BPEL we need not to have SOAP Header explicitly defined in WSDL.
For Mediator we need to define the SOAP Header Explicitly in WSDL.

For better understanding on defining SOAP Header in WSDL -
http://www.ibm.com/developerworks/xml/library/ws-tip-headers/index.html.


Receiving SOAP Header in BPEL:

In our SOAP BPEL – Receive Activity



This activity code looks like:


This BPEL is ready to read in the SOAP Header into variable gvarSOAPETHHeader.

Sending SOAP Header from a BPEL:

In Invoke Activity of BPEL under Header tab:


This activity code comes out as:


Above is wrong, it’s a JDEV BUG. It should be setting bpelx:inputHeaderVariable=”gvar...” instead of what we have above. Now we need to go to source and manually change it to:


Oracle identified it as a BUG(12541901) and has released a PATCH for JDEV: patch 12541901