By Juergenkress-Oracle on Feb 20, 2015
customers face a crisis in production system when, for some reason,
they end up with several B2B messages stacked up in the system, that may
not be of a high priority to be processed at that point in time. In
other words, it would greatly help many customers if, in such critical
situations, they had an option to flush the backed-up messages from the
system for later resolution and simply continue with processing of the
A-Team has been involved with different customers worldwide helping them implement such a solution for emergency use. Without getting into too much technical details, a high-level approach for such a solution is discussed here. The methodology accomplishes two key tasks, that are of primary importance during an emergency crisis within a B2B production gateway:
- Allows to flush the event queue while the gateway is down, so that the gateway can be brought up quickly
- Introspect the messages created from the event queue for resubmission or rejection
The primary objective of this framework is to allow the B2B engine to come back up quickly after flushing the messages from the event queue. The recovery or resubmission of messages is usually reviewed manually by the operations and business teams off-line and takes a longer cycle to complete. But this should not affect the down-time of the production system after the fast removal of the messages from the event queue. The downtime, thus encountered, is only driven by the first task, as listed above.
consists of immediate cleanup of messages from the system. The entries
will be stored in files. After the files are created, the gateway will
be ready for normal processing without any impact of messages that were
previously present in the system.
After the gateway is opened for normal business, the analysis of the file contents can be carried out, in parallel, to decide which messages will be resubmitted or discarded. This analysis can be done via scripts to extract relevant pieces of business data for the messages removed. The scripts are decoupled for various types of transient message data and built on basic query utilities. The basic building blocks for data introspection are typically custom scripts, that are created based on specific business needs for analysis.
The analysis will create 2 lists of message IDs – one for resubmission and the other for rejection. Existing command-line utilities can be invoked to resubmit the messages in a scripted loop with configurable delays in between the resubmissions. For rejection, there is typically no processing required. However, the list of IDs will be used to update the database to reflect a final state for the appropriate messages.
Tasks and Activities
sections describes the tasks in greater detail. Sections I and II cover
the activities that need to be completed while the gateway is down.
Sections III and IV include the post-mortem phase for analysis of
messages removed from the system.
The flowchart below can be used as a reference for the critical cleanup tasks covered in Sections I and II.
I. Preparation of Environment Read the complete article here.
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.