The inbound OSB file transport flow explained

The working of the OSB file transport can be explained  as follows:

• File written to a polling directory
• Metadata messages posted in internal JMS queue by the file transport and file moved to staging directory
• OSB Proxy Service triggered by message on the JMS queue
• Proxy service reads file from staging directory and moves the file to the archive folder when completed

This blogs explains the behavior when you suspend the flow on 3 different places of the flow. In general I think disabling the Proxy Service will be the best alternative in most situations. Anyway, by writing this blog I also hope to increase awareness about the internal working of the file transport in OSB. 

Note: I have tested this all before 11.1.1.7, but I have not read anything that indicates that the behavior should be different between 11.1.1.6 and 11.1.1.7

Action: Disabling the production internal file jms queue

    Error in OSB log:

weblogic.jms.common.IllegalStateException: Destination jmsResources!wlsb.internal.transport.task.queue.file is paused for new message production
        at weblogic.jms.dispatcher.DispatcherAdapter.convertToJMSExceptionAndThrow(DispatcherAdapter.java:110)
        at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncTran(DispatcherAdapter.java:53)
        at weblogic.jms.client.JMSProducer.toFEProducer(JMSProducer.java:1289)
        at weblogic.jms.client.JMSProducer.deliveryInternal(JMSProducer.java:796)
        at weblogic.jms.client.JMSProducer.sendInternal(JMSProducer.java:541)
        Truncated. see log file for complete stacktrace

• Message read from the polling directory, but placed in the error directory because of the above error

Action: Disabling the consumption internal file jms queue

•     Messages read from the polling directory on each poll cycle
•     Messages moved to the stage directory on each poll cycle
•     Messages not picked up by the proxy service and remain in the staging directory
•     After enabling consumption again the stage directory was immediately emptied and messages eventually ended up in the archive folder

Action: Disabling proxy service

    The following error can be seen when the proxy is disabled during a poll cycle execution:

#### <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <88685c90d4ac9d24:-768bd09e:1392b67272a:-8000-000000000000029f> <1345055025030>  javax.ejb.EJBException: nested exception is: com.bea.wli.sb.transports.TransportException: ProxyService default/PS_FILE_INBOUND has been disabled.
javax.ejb.EJBException: nested exception is: com.bea.wli.sb.transports.TransportException: ProxyService default/PS_FILE_INBOUND has been disabled
        at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.__onMessage(PolledMessageListenerMDB.java:55)
        at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.access$000(PolledMessageListenerMDB.java:31)
        at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB$1.run(PolledMessageListenerMDB.java:41)
        at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB$1.run(PolledMessageListenerMDB.java:39)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
        at weblogic.security.Security.runAs(Security.java:41)
        at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.onMessage(PolledMessageListenerMDB.java:39)
        at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583)
        at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486)
        at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388)
        at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659)
        at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345)
        at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821)
        at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115)
        at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

• The error above ONLY occurs when messages are picked up from the polling directory and in-flight when the PS is disabled. All 10 messages of that poll cycle are moved to the error directory. From here they can be recovered
•  No messages are picked up from the polling directory after the PS is disabled

OSB 11g - JCA polling adapter: StuckThread trace in the server log

I recently had to configure in OSB 11g the JCA AQ adapter to poll for new messages on an AQ inbound queue. This is quite easy using this tutorial.

However after I had configured the adapter and run some successful tests I saw the following stack trace in the server log after a period:

    <[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "600" seconds working on the request "weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@4b936059", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
        java.net.SocketInputStream.socketRead0(Native Method)
        java.net.SocketInputStream.read(SocketInputStream.java:129)
        oracle.net.nt.MetricsEnabledInputStream.read(TcpNTAdapter.java:564)
        oracle.net.ns.Packet.receive(Packet.java:295)
        oracle.net.ns.DataPacket.receive(DataPacket.java:94)
        oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:176)
        oracle.net.ns.NetInputStream.read(NetInputStream.java:121)
        oracle.net.ns.NetInputStream.read(NetInputStream.java:96)
        oracle.net.ns.NetInputStream.read(NetInputStream.java:81)
        oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:124)
        oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:80)
        oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1087)
        oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1062)
        oracle.jdbc.driver.T4Caqdq.receive(T4Caqdq.java:338)
        oracle.jdbc.driver.T4CConnection.doDequeue(T4CConnection.java:4067)
        oracle.jdbc.driver.PhysicalConnection.dequeue(PhysicalConnection.java:16057)
        oracle.jdbc.driver.PhysicalConnection.dequeue(PhysicalConnection.java:16138)
        oracle.jdbc.OracleConnectionWrapper.dequeue(OracleConnectionWrapper.java:1594)
        weblogic.jdbc.wrapper.XAConnection_oracle_jdbc_driver_LogicalConnection.dequeue(Unknown Source)
        weblogic.jdbc.wrapper.JTAConnection_weblogic_jdbc_wrapper_XAConnection_oracle_jdbc_driver_LogicalConnection.dequeue(Unknown Source)
        oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.dequeue(AbstractDequeueAgent.java:356)
        oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.dequeueMessage(AbstractDequeueAgent.java:259)
        oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.getInputRecord(AbstractDequeueAgent.java:232)
        oracle.tip.adapter.aq.v2.database.AbstractDequeueAgent.run(AbstractDequeueAgent.java:101)
        weblogic.work.ContextWrap.run(ContextWrap.java:41)
        weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
        weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
        weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Apparently, this StuckThread trace occurs 10 minutes after the server has been started and is caused by the fact that WebLogic uses by default 1 polling thread which remains active, or in other words is never released by the adapter, by design. Therefore the stuck thread trace can be ignored.

Please look in the OSB JCA transport guide for a detailed explanation and the configuration steps that can be applied to prevent stuck thread traces for polling threads (use a special configured Workmanager)

How-to: Oracle Service Bus 10gR3 - Oracle FMW B2B 11g interoperability

In this posting I will describe how you can integrate Oracle B2B 11g and Oracle Service Bus 10gR3 to send messages to Oracle B2B 11g from an OSB 10gR3 service.

The most easy way to integrate Oracle B2B 11g and OSB 10gR3 is by using JMS. Oracle B2B 11g supports JMS as protocol for its internal inbound and outbound delivery channels out-of-the-box.To enable JMS set the Use JMS Queue as default property to true in the Administration -> Configuration tab in the Oracle B2B 11g management console in order to switch on the usage of the JMS queues B2B_IN_QUEUE and B2B_OUT_QUEUE.

I have reused the ebXML configuration that I have described in a previous blog posting in this example. In Oracle Workshop 10gR3 (shipped with OSB 10gR3) you now have to make a simple OSB service that accepts a message through a proxy service and enqueues the message on the B2B_OUT_QUEUE of Oracle B2B 11g using a business service. Below I will describe the details that require special attention while implementing the OSB 10gR3 service.

Business Service - JNDI string
The BS serves as a JMS wrapper for the B2B_OUT_QUEUE. Use the following JNDI string to locate the
ConnectionFactory and Destination:

    jms://(ofm b2b 11g host):(port)/jms.b2b.B2BQueueConnectionFactory/jms.b2b.B2B_OUT_QUEUE

Proxy Service - message flow
Oracle B2B 11g expects several user header properties in the JMS transport header to be set. A list of the required properties can be found here. You have to use the property names defined in the second column. To set the user header properties use the Transport Header action in the request lane of the Routing action (assumed you use a Routing action). Click on Add Header to add a new header property and select Other to define a custom header property. Add header properties for all listed properties in the table expect the last four in the table (at least I didn't set them)

Here's a screen shot of my OSB 10gR3 configuration:



After you have completed the message flow publish your configuration to the server and use the SB console test functionality to execute a test.

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.