IIB Best Practices
IIB Best Practices
Introduction
This document presents some findings and recommendations concerning the use of
IBM Integration Bus. These findings were developed from previous experiences of
various integration projects. It covers the aspects of IIB development encompassing
Message Set guidelines, Message Flow guidelines and Deployment guidelines.
• The first key to successful Technical Design and Interface Development is a firm know-
ledge of the intended business logic and structure
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
• Each IIB Interface designed for the project should have certain characteristi-
cs, which are assumed to be common across all implemented interfaces
• These common characteristics generally refer to some common routines and
flows or sub-flows, which are recommended to be used globally
across all interfaces in that project
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
• The flow of each message through a IIB interface should be ‘Control Hand-
led’ for audit and logging purpose. For this reason,there is a requirement to
have a ‘Control Mechanism’ in each and every message flow
• It is recommended to have a ‘Common Control Handling’ routine/compon-
ent that can be re-used extensively by all interfaces of the project
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
• The interface designer has the option of building any required in-
tegration logic in the adapters or message flows
• It is recommended that as much business logic as possible will be
performed in message flows rather than in the adapters. In essence logic
is only to be located in adapters if that is the only option for the interface
• In other words, adapters will me made as simple as possible. The core of the
business logic should be kept in WMB.
The benefits of this approach are:
• The interface solutions are pattern based, with the patterns represented by
WMB message flows. Being pattern based, enhances reusability.
• Scaling and resilience is simplified with fewer complex components to consi-
der.
• Maintenance requirements are easier to define and execute, by largely avoi-
ding the need to change one component to accommodate the change in an-
other requirement
• Routing within the flow should be minimized where possible. When routing
is required, then the rule about minimizing the number of nodes still applies
• For a number of reasons, some message flows process more than one mess-
age type. In this case it is important to understand the distribution of these
different message types and their importance so that the most critical or
most frequent messages go through the cheapest path; i.e. the one with fe-
west and simplest nodes
• When more than one message is processed in a flow, or when there is a
requirement for dynamic logic inside a flow based on message content,there
are at least two ways to direct the processing logic inside the flow
• One way is through the use of RouteToLabel node. This node makes use of
the Destination List array of the LocalEnvironment Tree of a message flow.
When the message arrives, the DestinationList is populated according to the
business requirement, and the RouteToLabel and Label nodes are used to di-
rect subsequent processing
Sub-Flows
• Message Flows can be divided into SubFlows.Essentially, a Sub
flow is a sequence of nodes that begins with an Input node
and ends in an Output node. The object of using SubFlows
is that functions can be logically segregated in a way that
increases maintainability and offers opportunity for reuse
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
Use of CARDINALITY
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
• If the MQMD backout count is less than the Backout Requeue Threshold
attribute specified in the queue definition,the message is propagated throu-
gh the output terminal of the MQInput Node for normal processing once
again
• If the MQMD backout count is not less than the Backout Requeue Threshold
attribute specified in the queue definition,the message is propagated throu-
gh the Failure terminal of the MQInput Noden
• If the Failure terminal is wired then it follows that path but, if it is not wired
the Backout Requeue Name attribute is looked for and if a queue
name found in this attribute, the message is put into that queue
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
• If the message could not be written to the Dead Letter Queue then
it remains in the Input Queue
• The following are the standard Unit Test Conditions that should be consid-
ered by a developer while performing Unit Test on an interface:
• When a valid Test Data is passed through the message flow one or more
output message(s) are created on the output queue(s)
• When an invalid Test Data is passed through the message flow the messa-
ge is propagated to the error handling queue for error processing
• All fields of the output message are of correct length and have been correc-
tly formatted according to the requirements
• Where the message has repeating fields or structure, the interface works
correctly for both single and multiple instances of the field or structure
• Where the message has an optional field or structure, the interface works
correctly for both with and without the field or structure in the message
Important Structures
Field Description
StrucId Structure Identifier
Version Structure Version Number
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
Field Description
Feedback Feedback or Reason Code
Encoding Numeric Encoding of message Data
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
Field Description
MsgSeqNumber Sequence number of logical message within group
Offset Offset of data in physical message from the start
of logical message
MsgFlags message MsgFlags
The MQRFH2 structure defines the layout of the rules and formatting header.
This header can be used to send string data that has been encoded using an
XML-like syntax.It allows Unicode string to be transported without translatio-
ns, and it can carry numeric data-types.
The following table summarizes the fields in the structure:
Field Description
StrucId Structure Identifier
Flags Flags
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
The Properties tree is the first element of the message tree and
holds information about the characteristics of the message.
Field Description
Debug Tracing
In the event of an error in a message flow, a debug level trace should be set
for the flow. This is done with the help of a set of commands
to generate the debug trace file for diagnostics
• Open a command prompt window
• Execute the command mqsichangetrace <Broker Name> -u-
e < Execution Group Name > -l debug -f < Message Flow
Name > -r
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015
www.miraclesoft.com
• Execute the message flow with the message that you want to
trace
• Execute the command mqsireadlog <Broker Name> -u -e <Execu+
tion Group Name> -l debug -f <Message Flow Name> -o <Temporary
File Name>
• Execute the command mqsiformatlog –i <Temporary File Name> -o <Trace
File Name>
• Open the generated Trace files in a text editor and perform diagnosis
C 2015 Miracle Software Systems, Inc. Technical Article | April 6th, 2015