Resequencer feature has been added to Oracle Service Bus 12c (12.1.3), it utilises the same resequencer engine as Oracle Mediator.  The objective of this feature is to provide you with the ability to resequence the incoming messages that arrive in random order and send them to the target services in an orderly manner.  In this blog, I will give you a bit more information about this new feature in OSB and how to debug it if you encounter an issue.

As mentioned in the official doc, the resequencer doest not support any XML and any SOAP service type, you need to define a WSDL in order to use the resequencer feature in OSB, and this WSDL must be only one-way, and must not contain any response elements.

The OSB Resequencer Strategies work in the same manner as Oracle Mediator;  it supports Standard, FIFO, and Best Effort.  The differences between the resequencer implementation in Oracle Mediator and OSB are the ways in which both dispatch the message.  In OSB, pipeline acts as a Resequencer component. Users cannot configure resequencer at any other OSB component.  After resequencing, the ordered messages will be processed further in the pipeline.  As soon as the message is pushed to the resequencer, the caller will get a successful response. Though resequencer is part of the pipeline configuration, it will be invoked just before the pipeline is invoked.

Just like the Oracle Mediator,  OSB Resequencer also relies on the database for processing messages.  The database tables are automatically created when you run the repository creation utility (RCU) while creating the OSB domain.  The JNDI name used by the OSB resequencer is jdbc/SOADataSource.  The tables used by the resequencer are shown below:

You can use the Enterprise Manager to configure the throughput for resequenced messages.  Following are the properties specific to OSB resequencer:

• Resequencer Maximum Groups Locked : the Maximum number of groups locked by Resequencer in each attempt it makes to obtain locks on the groups. Locks are obtained on the groups so that only one managed server node processes the group at a time.

• Resequencer Locker Thread Sleep : The number of seconds the Resequencer would pause between each iteration to obtain locks on the groups.

• Purge Completed Messages : Delete messages after successful execution. The default value will be set as true.

Through the EM console, you will be able to see all the successful (if instance tracking is on) and the faulted instances.  You can also recover the faulted groups either by resubmitting the failed message or skipping to the next message by aborting the faulted message. In addition, you are also able to recover the timed-out groups by skipping to the next available message, however, if the missing message comes in after the timeout then it will not be executed by the resequencer, in this case, you need to manually execute this message through EM.   However, due to bug 19826309 in the current release (12.1.3), you will not be able to recover or abort resequencer messages in the Enterprise Manager ->SOA->Service-Bus->Resequence Messages tab, you will notice the payload is missing when you recover/abort a resequence message (see screenshot below).  This issue only occurs if you are using the production distribution to setup your environment, you will not encounter this issue in the integrated server in JDEV or a compact domain using the quick-start installation.

To reprocess/recover the faulted resequence message, you need to update the STATUS column to “0” in both OSB_GROUP_STATUS and OSB_RESEQUENCER_MESSAGE tables, below are some of the valid combination status values for the group and message STATUS columns:

Some design considerations:

• OSB Resequencing is supported for one way (xml type) messages only.

• Supported Service types:

  • WSDL Web Service – OSB Resequencing will only be allowed for operations with only request type.

  • Message Type - Request message type to be xml and Response message type as None

• OSB Resequencing for the large message is not supported as the payload needs to be persisted in the DB before it is sequenced.

Debugging

In order to isolate a problem, you need to enable tracing for the pipeline by changing the OSB ODL configuration: oracle.osb.debug.pipeline to “TRACE: 32”, and use the Log action with debugging severity to see the resequenced messages.  But you have to disable the “Purge Completed Message” configuration first.  This will enable you to retain the completed messages in the OSB_RESEQUENCER_MESSAGE table, thus making it easier for you to investigate the error.