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
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
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
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.
SOA & BPM Partner Community
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.
Blog Twitter LinkedIn Facebook Wiki