MuleESB / IBM Integration Bus (IIB) Interview questions

You can use IBM Integration Bus to connect applications together, regardless of the message formats or protocols that they support.

The 3 main components in IIB/WMB are Runtime, Development and Administration.

• Runtime, the broker runtime is the main processing component to which development artifacts are deployed.
• Development, the Toolkit is used for development of message flows and other development artifacts.
• Administration Message Broker Explorer is an administration tool used to perform deploys, create brokers or new execution groups, and enable flow monitoring. WMB V8 provides a WebUI tool to view the broker runtime or resources deployed in a browser.

Websphere MQ is a software that uses the AMQ(Asynchronous messaging protocol). You can achieve asynchronous messaging between your applications via Websphere MQ, which will make your infrastructure loosely coupled(Applications can keep working even though other applications are down in the infrastructure).

However with the MQ, we need to create your own program using the Websphere MQ API for message transformations. IIB/WMB allows you to create programs very easily and a lot faster.

MQ is providing you the infrastructure for messaging: queues and topic. IBM Integration Bus (formerly known as WebSphere Message Broker) allows you to apply the common EAI patterns, e.g. Routing, Transformation.

Enterprise Application Integration (EAI) is the process of connecting disparate systems to allow for "communication" and data sharing between them.

Root is used in the Database content changing and in the Filter node. Output Root is used in the ESQL code for a Compute node that creates a new output message based on the input message.

Extended Structured Query Language (ESQL) is a programming language defined by IBM Integration Bus to define and manipulate data within a message flow.

ESQL is based on Structured Query Language (SQL) which is in common usage with relational databases such as IBM DB2. ESQL extends the constructs of the SQL language to provide support for you to work with message and database content to define the behavior of nodes in a message flow.

A set of activities that are executed under a single unit of work.

Broker (aka, integration node) is a set of execution processes that hosts one or more message flows to route, transform, and enrich in-flight messages.

The BAR file (broker archive file) is a compressed file to which you can add a number of deployable resources. BAR files pack flows and sets that are to be deployed in it and sent to the configuration manager.

BAR file is the unit of deployment to the integration node.

An execution group is a named grouping of message flows that have been assigned to a broker. The broker enforces a degree of isolation between message flows in distinct execution groups by ensuring that they execute in separate address spaces, or as unique processes.

Once a broker is started, the following processes get started and they can be seen in Task Manager (on Windows) and/or ps listing (on UNIX).

• bipservice: This is a bootstrap process that starts the broker runtime.
• bipbroker: This main administration manages the broker runtime.
• biphttplistener: This is the HTTP server process that provides HTTP and SOAP functionality in Message Broker.
• DataFlowEngine: This is the Execution Group process that runs message flow threads. Each message flow runs in this process as a thread.

Local Environment and Environment are message trees used by the message flow during message processing. The Lifetime of this tree structure may be throughout the flow or limited to some nodes. Use these trees to carry variables that need to be accessed in nodes throughout the flow.

Environment variable will live the whole thread lifetime of a flow. LocalEnvironment tree may or may not live throughout the thread lifetime. That means there is a mechanism that decides whether or not to pass the LocalEnvironment trees throughout the flow. The "Compute mode" property of a compute node will decide whether or not the local environment tree is copied to the downstream nodes of the flow.

If you want to send information using LocalEnvironment to the next immediate node, then set it in OutputLocalEnvironment. To access the information use InputLocalEnvironment. Whereas using Environment, we use the same variable to access or set information.

The exception list tree is a part of the logical message tree in which the message flow writes information about exceptions that occur when a message is processed.

The root of the exception list tree is called ExceptionList, and the tree consists of a set of zero or more exception descriptions. The exception list tree is populated by the message flow if an exception occurs. If no exception conditions occur during message flow processing, the exception list that is associated with that message consists of a root element only. This list is, in effect, an empty list of exceptions.

• Module Variable (Normal variable), have a lifetime of just one message passing through a node. They are visible to that message only. To define normal variables, omit both the EXTERNAL and SHARED keywords.
• External Variable (user-defined properties), exist for the entire lifetime of a message flow and are visible to all messages passing through the flow. You can define external variables only at the module and schema level.
• Shared Variable (long Lived variable), can be used to implement an in-memory cache in the message flow. Shared variables have a long lifetime and are visible to multiple messages passing through a flow.

User trace and Service trace.

A message flow is a sequence of processing nodes that are connected together, through which a message passes. The nodes in a message flow can perform a variety of tasks, such as filtering messages, transforming data, or routing messages to different destinations.

Input nodes are responsible for receiving messages from an external source, such as a message queue.

Output nodes are responsible for sending messages to an external destination, such as a message queue.

Processing nodes are responsible for performing some kind of transformation or processing on the message, such as routing it to the correct output node.

ACE is the newest iteration of IIB and offers several improvements over its predecessor. The first and perhaps most notable of these is that ACE is designed to work with more modern application development frameworks such as Node.js and AngularJS. This allows businesses to easily develop new applications that can integrate with their existing system using ACE.

Another key improvement in ACE is its support for containerized deployments.

IBM App Connect Enterprise processes messages in 2 ways: message routing and message transformation.

Message routing: Messages can be routed from sender to recipient based on the content of the message. The message flows that you design control message routing. A message flow describes the operations to be performed on the incoming message, and the sequence in which they are carried out.

Message transformation: Messages can be transformed before being delivered, one format to another or transform by modifying, combining, adding, or removing data fields.

An integration server is used to provide an isolated runtime environment for a set of deployed message flows and resources. Each integration server runs as a unique process in a separate address space. You can configure integration servers to be associated with an integration node that looks after them, or to run independently of an integration node.

The IBM App Connect Enterprise web user interface enables users to access integration server resources by using a web browser, and provides integration administrators with a method of administering those resources.

You can perform the following administrative tasks from the web user interface:

• View and manage integration server resources, such as deploying application BAR files, and stopping, starting, or deleting deployed applications.
• Work with statistics and accounting data for your message flows. Also work with statistics for the resources that are used by your integration servers.
• Start and stop user trace and service trace.
• View and replay recorded data.

The IBM App Connect Enterprise Toolkit is an integrated development environment and graphical user interface based on the Eclipse platform.

Application developers work in separate instances of the IBM App Connect Enterprise Toolkit to develop resources associated with message flows. The IBM App Connect Enterprise Toolkit connects to one or more integration servers to which the message flows are deployed.

Yes.

The IBM Integration API is a remote programming interface that your custom integration applications can use to control integration nodes and their resources.

• ACE makes low utilization of resources such as CPU, Memory, and Disk.
• ACE uses only a single OS process while IIB needs multiple processes for a single Integration server.
• ACE does not provide a data flow engine process because it removed dependency on Integration while IIB runs on multiple processes such as bipbroker, bipservice, bipMQTT, and DataFlowEngine.
• ACE supports single-step deployment and configuration with policies in the BAR file while in IIB we would use config services to override or abstract some specific property needed by our message flow