How to: OSB - FMW SCA 11g interoperability supporting transaction propagation

Currently, the BPEL transport in OSB is not supporting FMW 11g. However, I just found a way, although it still is proven in theory based on my knowledge, to enable transaction propagation between OSB and FMW 11g SCA composites. The basic idea is that you have to communicate between OSB and FMW 11g SCA composites using the SDO - EJB binding in 11g. The t3 protocol used as the communication protocol between the ejb client and the SCA (soa_infra) engine should take care of the transaction context propagation.

This should do the trick until OSB gets native support for FMW 11g interoperability. One disclaimer; I still have to prove my theory by running a test, but I am quite sure that it will work so therefore I shared it already here. I also still have to elaborate on which MEPs could be supported with this solution, so any thoughts are welcome.

Oracle FMW B2B 11g: How to collect HTTP header info from inbound messages using Java Callouts

In Oracle FMW B2B 11g the Java callout functionality makes it possible to add Java hooks to an inbound or oubound message flow. Callouts van be written and configured per agreement or per delivery channel (transport callouts). More info about managing callouts can be found here

In this blog posting, I will show how you how an agreement callout can be used to collect HTTP headers from an inbound message, which is received by the default B2B transportServlet. I use an agreement callout because it is not possible to define a transport callout for an inbound http host channel.

The callout implementation is rather simple:

package nl.oracle.com.b2bcallout;

import oracle.tip.b2b.callout.Callout;
import oracle.tip.b2b.callout.CalloutContext;
import oracle.tip.b2b.callout.CalloutMessage;
import oracle.tip.b2b.callout.exception.CalloutDomainException;
import oracle.tip.b2b.callout.exception.CalloutSystemException;


public class HttpHeaderAgrCallout implements Callout {

    public void execute(CalloutContext arg0, List input,
                        List output) throws CalloutDomainException,
                                            CalloutSystemException {
        try {
            CalloutMessage cm1 = (CalloutMessage)input.get(0);
            
            
            System.out.println("parameters - "+cm1.getParameters().toString());
            
            CalloutMessage cmOut = null;
            String msg = cm1.getBodyAsString();

            String headerStr = cm1.getParameters().toString();
            System.out.println("Print transport header ::");
            System.out.println(headerStr);
            

            cmOut = new CalloutMessage(msg);
            output.add(cmOut);

        } catch (Exception e) {
            e.printStackTrace();
        }

    }

}

The getParameters() methods returns all the HTTP transport header attributes in a Properties object.

Compile the callout code and deploy it to a jar file. The jar file has to be copied a location that can be accessed by the B2B server (or all B2B nodes if you have a clustered environment). Have a look at the B2B callout documentation to find out how you configure the callout with your inbound agreement.

It is wise to put Agr or Transport in the callout name to make a clear distinction between the types of callouts as they appear together in the callout selection drop down list in the B2B management console.

So why do you need this anyway..well for example to extract a specific HTTP header attribute that is, for example, set by the front-end HTTP Server and enrich the message with it.