Scribd
Upload
24 views3 pages

QNA For IIb

IBM Integration Bus (IIB) v10 allows for flexible integration architectures by making MQ optional on distributed platforms, unlike previous versions that required a dedicated Queue Manager. Message models, flows, and various node types like Filter and Compute are utilized for processing messages, while Logical Trees represent the internal structure of messages. Error handling in IIB includes connecting terminals for exception processing and configuring Backout Queues to prevent messages from going to the Dead Letter Queue.

Uploaded by

shamanthck.work
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
24 views3 pages

QNA For IIb

IBM Integration Bus (IIB) v10 allows for flexible integration architectures by making MQ optional on distributed platforms, unlike previous versions that required a dedicated Queue Manager. Message models, flows, and various node types like Filter and Compute are utilized for processing messages, while Logical Trees represent the internal structure of messages. Error handling in IIB includes connecting terminals for exception processing and configuring Backout Queues to prevent messages from going to the Dead Letter Queue.

Uploaded by

shamanthck.work
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Frequently Asked Questions about IBM Integration Bus (IIB)

1. What is the significance of IBM Integration Bus (IIB) v10's flexible topology
regarding MQ, and how does it differ from previous versions?

IIB v10 introduced a significant change by making MQ optional for the IIB runtime on
distributed platforms (Windows, Linux, Unix). In contrast, versions up to v9 required MQ as a
mandatory component, with each Integration Node needing a dedicated Queue Manager. In
v10, Integration Nodes can be created without any Queue Manager, associated with one
default Queue Manager, or connect to multiple Queue Managers (locally or remotely).
Queue Managers can even be shared across multiple Integration Nodes. This flexibility
allows for more adaptable and potentially less resource-intensive integration architectures.

2. How are message models created in IIB, and what types of sources can be used?

Message models define the structure and format of messages processed by IIB. They can
be created using several methods:

●​ Using the mqsicreatemsgdefs command-line utility to import definitions from C


header files, COBOL copybooks, XML DTD files, or XML Schema files.
●​ Using the mqsicreatemsgdefsfromwsdl command-line utility to import definitions from
WSDL (Web Services Description Language) files.
●​ Directly using the IIB Toolkit, a graphical development environment.

3. What are message flows in IIB, and how do they process messages?

A message flow is a sequence of processing steps (defined by message flow nodes) that
dictate how IIB integrates source and target applications. Each message flow node performs
a specific action on the message, and the connections between nodes determine the
processing order. Each message flow has predefined terminals for entry and exit points,
including 'Out' for successful processing, 'Failure' for handling node-specific exceptions, and
'Catch' for handling exceptions occurring downstream. The Input node is the starting point
and specifies the message domain and model definition used for parsing the input bit
stream.

4. What are Integration Projects, Applications, and Libraries and how do they differ in
IIB?

These are containers for packaging resources within the IIB Toolkit:

●​ Integration Project: An unstructured container for developing message flows and


related resources. When packaging resources, you choose which resources are
deployed together.
●​ Application: A container for resources that are required to create a solution, and that
should be deployed and managed together as a single unit, providing encapsulation.
●​ Libraries: Logical groupings of related code and/or data, typically containing
reusable resources. Libraries can be either shared or static. Shared libraries can be
updated independently and the changes are immediately picked up by referencing
applications, whereas static libraries create a private copy for each application that
refers to them.

5. What is the purpose of Logical Trees in IIB, and what are the main types of trees?

Logical trees are the internal representation of a message within IIB. The main types of
logical trees are:

●​ Message Tree: Contains the actual application message data (payload). It has a
Root, Properties, and a Body.
●​ Environment Tree: Used for storing variables and passing information between
nodes during message processing. There is only one instance for the entire message
processing.
●​ LocalEnvironment Tree: Used for storing information for routing purposes and
message-related data for specific protocols. Each node can create and modify its
own instance, and changes are reverted on rollback.
●​ ExceptionList Tree: Stores error details when a message flow fails, similar to an
Exception object in Java.

6. What is ESQL in IIB, and how is it used within message flows?

ESQL (Extended Structured Query Language) is an interface provided in IIB for reading,
writing, and manipulating Logical Trees and working with databases. Nodes like Compute,
Filter, and Database nodes use ESQL to implement their logic. ESQL logic is saved in .esql
files, and multiple nodes can refer to the same ESQL module for reusability. ESQL supports
different types of variables (Normal, Shared, External) and a range of functions (e.g., THE,
CARDINALITY, EXISTS, LENGTH, CONTAINS, CAST, PROPAGATE, EXTRACT).

7. Can you briefly describe the main purposes of the Filter, Route, Compute and
JavaCompute nodes?

These are common message flow nodes with the following purposes:

●​ Filter Node: Routes messages based on simple if-else logic using ESQL. Does not
modify the logical trees.
●​ Route Node: Routes messages based on filtering conditions using XPath. Allows the
creation of custom output terminals.
●​ Compute Node: A general-purpose node primarily used for transforming logical
trees using ESQL. Can also be used for content-based routing, business process
logic, and database operations.
●​ JavaCompute Node: Similar to the Compute node, but uses Java programming
language for transformation and logic implementation. It interacts with Logical Trees
through a Message Assembly object.

8. How does IIB handle errors, and what options are available for preventing
messages from going to the Dead Letter Queue (DLQ)?

IIB offers multiple ways to handle errors:


●​ Connecting the "Failure" terminal of a node to a sequence of nodes that processes
the internal exception.
●​ Connecting the "Catch" terminal to handle exceptions that are generated
downstream of the node.
●​ Using TryCatch nodes to catch and process exceptions at specific points in the
message flow.
●​ Ensuring that all messages received by an MQInput node are either processed in a
transaction or not processed in a transaction, and that they are either persistent or
not persistent.
●​ Configuring a Backout Queue for the Input Queue.

To prevent messages from going to the DLQ: connect the Failure or Catch terminal, or
configure a Backout Queue for the Input Queue. The transactional status of a Message Flow
is determined by the Transaction Mode property of the Input Node.

You might also like