IBM App Connect Enterprise

Applications
An application is a container for all the resources that are required to create a solution. An application
can contain IBM® App Connect Enterprise resources, such as flows, message definitions, libraries, and
JAR files.

You use applications to group all the resources that are required to deliver an integration solution,
enabling easier development and management. If you are developing resources for multiple integration
solutions in the IBM App Connect Enterprise Toolkit, then consider grouping your resources into
applications. The use of a shared or static library helps organization by grouping reusable resources
together. A shared library can also be used by other applications, services, shared libraries, or
integration projects.

mhanje jevha aplyala thodech like 2-3 resources lagtat tevha apan fakta application la store kela tari
chalel but jevha aplayala khup resources lagat tevha apan shared library create karun tyamadhe
resources store karto ani ti library link karto application madhe.

Consider using applications if you need to ensure that updates to one group of deployed resources do
not affect another group. For example, use an application when you want to control which flows pick up
the latest version of an ESQL module.

Runtime isolation and resource sharing with applications and libraries

You can use applications to encapsulate resources for a solution or to provide runtime isolation. You can
use libraries to group common resources or share routines and definitions between teams, projects, or
integration nodes.

Applications provide runtime isolation whereby resources inside the application are not visible to other
resources, such as message flows, libraries, or other applications that are running outside the
application. Consider using applications if you need to ensure that updates to one group of deployed
resources do not affect another group. For example, use an application when you want to control which
flows pick up the latest version of an ESQL module.

The following example illustrates how you can use applications to contain separate solutions, and
libraries to contain shared error-handing code.
The graphic shows the resources that are described in the preceding text.

The ClothesOrderApp application contains the following resources:

 A message flow called ClothesOrderFlow

 A reference to a static library called ClothesOrderLibrary, which contains XSD schema files that
are specific to the order type

 A reference to a shared library called CommonErrorHandling, which contains some common

error-handling ESQL code

The HomewareOrderApp application contains the following resources:

 A message flow called HomewareOrderFlow

 A reference to a static library called HomewareOrderLibrary, which contains XSD schema files
that are specific to the order type

 A reference to a shared library called CommonErrorHandling, which contains some common

error-handling ESQL code

The following diagram shows the resources in the Integration Explorer view after they are deployed. The
shared library is deployed with or before the applications that reference it.
The graphic shows the deployed applications in the Integration Explorer view. The ClothesOrderApp
application has as child resources the ClothesOrderFlow and ClothesOrderLibrary. The
HomewareOrderApp application has as child resources the HomewareOrderFlow and
HomewareOrderLibrary. The CommonErrorHandling shared library is deployed at the same level as the
applications that reference it.

The shared library appears at the same level as the applications that reference it. The static libraries are
shown nested under the applications that reference them. Resources in the applications and their
referenced static libraries are not visible to other resources outside those applications.

Applications provide this isolation at run time. This isolation also applies if a resource that is contained in
an application is also deployed separately to the same integration server.

Assume that a static library is deployed to an integration server with a message flow that references that
library. The same static library is also contained in an application that is deployed to the same
integration server. If that static library is updated in the IBM® App Connect Enterprise Toolkit and
redeployed, the message flow that is deployed to the integration server can see the changes. However,
the application cannot see the changes. For the application to pick up the updated static library, you
would need to rebuild and redeploy the BAR file that contains the application.

Viewing applications

Applications are shown in the Application Development view. Resources that are contained in an
application are also shown, whether an application refers to them directly or indirectly.

Applications are represented by the application icon Icon for an application.

Applications that have been deployed to an integration server are displayed directly beneath the
integration server in the IBM App Connect Enterprise Toolkit and the web user interface. Libraries that
are referenced by applications are displayed directly beneath the application. Shared libraries are
contained in a Referenced Libraries folder, and static libraries are contained in an Included Libraries
folder. You can also view deployed applications by using theIBM Integration API or the mqsilist
command

-> mqsilist integrationNodeName -e integrationServerName -k applicationName

This command specifies whether the application is running, and on which integration server. You can
also see the deployed objects that are contained in that application, and a list of shared libraries that are
referenced by the application.

Integration services

Last Updated: 2024-06-16

An integration service is a specialized application with a defined interface and structure that acts as a
container for a web services solution. services define a prescribed interface, which specifies how data is
exchanged with the service.

In IBM® App Connect Enterprise, an integration service is a specialized application with a defined
interface that acts as a container for a web services solution:

 It contains message flows to implement the specified web service operations.

 The interface is defined through a WSDL file.

an integration service can reference resources in shared libraries.

Interfaces :

An interface consists of one or more operations and a binding style.

An operation is a description of an action that is implemented by the service. Each operation can have
either of the following types:

 Request-response type operations mean that a request is sent and a response returned to the
interface.

 One-way type operations mean that only a request is sent, and no response is needed.
Integration service API :

You can generate a JavaScript client API from an existing integration service. The JavaScript client API
provides operation functions that you can call from a program that is running in a JavaScript
environment.

Logical Tree Structure

Local Environment:
Local Environment has the information of the message which has scope of the
current node and next node

The local environment tree is a part of the logical message tree in which you can
store information while the message flow processes the message.
The root of the local environment tree is called LocalEnvironment. This tree is
always present in the input message, it is created when a message is received by
the input node. Some input nodes create local environment fields, others leave it
empty.
The local environment tree is made up of the following structure:
 Anything in the format of
LocalEnvironment.Destination.output_or_request_node_name
decides what happens when information is going into an output or request
node.
 Anything in the format
of LocalEnvironment.WrittenDestination.output_or_request_node_name,
for example; LocalEnvironment.WrittenDestination.FTE, gives you
information about the processed output of an output or a request node.
 Anything in the format of LocalEnvironment.input_node_name.input, for
example; LocalEnvironment.Adapter.Input, contains information that has
been stored by an input node.
 Use the local environment tree to store variables that can be referred to
and updated by message processing nodes that occur later in the message
flow. You can also use the local environment tree to define destinations
(that are internal and external to the message flow) to which a message is
sent

Message flows overview

Last Updated: 2023-06-21

A message flow is a sequence of processing steps that run in the integration

node when an input message is received.
You define a message flow in the IBM® Integration Toolkit by including a
number of message flow nodes, each of which represents a set of actions
that define a processing step. The way in which you join the message flow
nodes together determine which processing steps are carried out, in which
order, and under which conditions. The path that you create between one
node and another is known as a connection.

Integration servers and

integration nodes
Last Updated: 2024-08-16

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.
An integration node
An integration node is a set of execution processes that hosts one or more
message flows to route, transform, and enrich in flight messages.

Application programs connect to and send messages to the integration node,

and receive messages from the integration node. Code your applications to
use one of the supported protocols for interacting with the integration node

The integration node routes each message by using the rules that you have
defined in message flows and message model schema files, and transforms
the data into the structure required by the receiving application.
Subflows
Last Updated: 2023-06-21

You define a subflow to provide a common sequence of actions to be used by

several message flows, applications, or integration services.

You define a subflow once, and use it in more than one message flow,
application, integration service, and integration project.

A subflow provides the following benefits:

 Reusability and reduced development time
 Consistency and increased maintainability of your message flows
(consider a subflow as analogous to a programming macro, or to inline
code that is written once but used in many places)
 Flexibility to tailor a subflow to a specific context (for example, by
updating the output queue or data source information)

Libraries
Last Updated: 2024-06-16

A library is a logical grouping of related code, data, or both. A library typically contains reusable helper
routines and resources such as subflows, ESQL modules, message definitions, maps, and Java™ utilities.
You can use a library to group resources of the same type or function, and to aid the management and
reuse of such resources

Consider using libraries for the following functions:

 To group common types of resource (such as all your ESQL routines)

 To group resources by function (such as all your error-handling routines)

 To share routines and definitions across multiple teams or projects

 To use different versions of a coherent set of routines and definitions

Two types of library :

Shared libraries
Last Updated: 2023-06-21

You might want to develop a set of common resources and make them
available to multiple applications. If you want to deploy and manage just one
copy of those common resources, use a shared library.
Any application can reference the resources in that deployed shared library.
If that shared library is updated, the changes are immediately picked up by
all referencing applications.

If you use a static library to contain resources, each application that

references that static library is deployed with its own private copy of that
library. If a static library is updated, each application that references it must
be repackaged and redeployed with the updated static library.

Static libraries
Last Updated: 2023-06-21

A static library can be referenced by one or more applications. Changes that

are made to the library in the IBM® Integration Toolkit are available to all
applications that reference that library. However, when the applications are
packaged into a BAR file and deployed, each application has its own private
copy of the library and the resources that are contained in it. If you update
a static library, you must repackage and redeploy each application
that references that library.

Policies overview
Last Updated: 2024-06-16

Policies can control particular node properties,

Developers can use policies to control runtime behavior and reuse

configuration information

policies are used to override message flow properties at run time,

information like connection details can be updated without having to update
message flows.
 Operators can use policies to monitor and modify configuration data
dynamically.

Message model
A message model is used by IBM Integration Bus to model a message
format. The message models used by IBM Integration Bus are based on
W3C XML Schema.

A message set is the original container for message models used by IBM Integration Bus.

message model schema files contained in applications and libraries are the preferred way to
model messages for most data formats

Types of Queues

Queue
type Description

A local queue is a definition of both a queue and the set of messages that a
Local
associated with the queue. The queue manager that hosts the queue
queue
receives messages in its local queues.
 Transmission queues are a special type of local queue. When the queue
manager sends a message to a queue on a remote queue manager, the
Transmissio
transmission queue stores the message locally until the queue on the remo
n queue
queue manager is available. To create a transmission queue, create a local
queue and change its Usage attribute to Transmission.

Remote queue definitions are definitions on the local queue manager of

Remote
queues that belong to another queue manager. To send a message to a
queue
queue on a remote queue manager, the sender queue manager must have
definition
remote definition of the target queue.

Alias queues are not actually queues; they are additional definitions of
existing queues. You create alias queue definitions that refer to actual local
queues but you can name the alias queue definition differently from the loc
Alias queue
queue (the base queue). This means that you can change the queues that a
application uses without needing to change the application; you just create
an alias queue definition that points to the new local queue.

A model queue is a template for queues that you want the queue manager
create dynamically as required. When an application tries to put a message
Model
on a model queue, the queue manager dynamically creates a local queue
queue
with the same name as the model queue. Queues that are created in this w
can either be temporary or permanent.

Cluster A cluster queue is a queue that has been shared in a cluster so that all of th
queue queue managers in the cluster can put and get from the queue using cluste
channels. For more information, see Queue manager clusters.
z/OS® only. A shared queue is a queue that has the queue sharing group
Shared disposition of Shared. All of the queue managers in the queue sharing group
queue can put and get from the queue without needing active channels. Only loca
queues can have the disposition of Shared. For more information, see Queue
sharing groups.
z/OS only. A group queue is a queue that has the queue sharing group
Group disposition of Group. Each of the queue managers in the queue sharing grou
definition has a copy of the queue (with the disposition Copy) stored on their own page
queue set. Local, remote, alias, and model queues can have the
disposition Group. For more information,
Queue managers
Last Updated: 2024-01-31

A queue manager is a program that provides messaging services to

applications. Applications that use the Message Queue Interface (MQI) can
put messages on queues and get messages from queues. The queue
manager ensures that messages are sent to the correct queue or are routed
to another queue manager.

MQ queues
Last Updated: 2024-01-31

A queue is a container for messages. Business applications that are

connected to the queue manager that hosts the queue can retrieve
messages from the queue or can put messages on the queue.

The message headers

Last Updated: 2021-03-03

A message header is a part of a message that contains information used to

process the message, but that is not part of the message body

IBM MQ rules and formatting header 2 (MQRFH2):

 The MQMD contains information specific to IBM MQ. It contains the
control information needed to handle the exchange of messages
between applications and FTM SWIFT

 The MQRFH2 contains information specific to IBM Integration Bus.

Folders in the MQRFH2 contain the control information that FTM
SWIFT services require to perform their specific functions.
 The MQRFH2 can contain any number of folders. Each folder has a
NameValueData field (which contains the data in the folder) and a
NameValueLength field (which specifies the length of the data in the
NameValueData field)
MQInput node
Last Updated: 2021-03-01

Use the MQInput node to receive messages from clients that connect to the
broker
Termi
Description
nal
The output terminal to which the message is routed if an error
Failur
occurs. Even if the Validation property is set, messages
e
propagated to this terminal are not validated.
The output terminal to which the message is routed if it is
Out
successfully retrieved from the WebSphere MQ queue.
The output terminal to which the message is routed if an exception
Catch
is thrown downstream and caught by this node.

PROPERTIES

1. Description

2. Basic

3. MQ connections

4. Input message parsing

5. Parser options

6. Advanced

7. Validation

8. Policy

9. instance

10. Monitoring

11. Security
MQReply node
Last Updated: 2021-03-01

Use the MQReply node to send a response to the originator of the input
message.

The MQReply node is a specialized form of the MQOutput node that puts the
output message to the WebSphere® MQ queue that is identified by the
ReplyToQ field of the input message header.

We have to define the queue in to which we want to send response to in the

esql compute file which is

SET OutputRoot.MQMD.ReplyToQ = ‘out’;

Where,

out is the queue name

Terminals and properties

The MQReply node terminals are described in the following table.
Terminal Description

The input terminal that accepts a message for processing by

In
the node.

The output terminal to which the message is routed if a failure

Failure
is detected when the message is put to the output queue.

The output terminal to which the message is routed if it has

Out been successfully put to the output queue, and if further
processing is required in this message flow.

Properties :
1. Description

2. MQ connections
 3. Advanced

4. Validation

5. Policy

6. Security

Difference MQREPLY and MQOUTPUT

Certainly! Here's a point-to-point comparison of the MQ Reply node and the MQ Output node
in IBM App Connect Enterprise (ACE):
Feature MQ Reply Node MQ Output Node
Sends messages to an MQ queue
Primary Sends a reply message in response to a
without specific regard to request-reply
Function request.
patterns.
Used for sending messages in various
Specifically used in request-reply
Usage Context messaging patterns, including one-way
messaging scenarios.
messaging.
Sends to any specified queue, including
Queue Sends to a reply queue as specified in
request queues, reply queues, or other
Configuration the request message.
queues.
Does not inherently handle correlation;
Correlation Often uses correlation identifiers to
message sending is not tied to request-
Handling match replies to the original request.
reply patterns.
When you need to respond to a When you need to send messages to a
Typical Use request message with a reply, ensuring queue for further processing, logging, or
Case that the response is sent to the correct distribution, regardless of request-reply
reply queue. context.
Configured with specific settings for Configured with general settings for
Configuration
handling replies, often involving sending messages, including attributes
Details
correlation IDs. like priority and persistence.
Used in flows where a request Used in flows where messages need to
Message Flow message is received, processed, and a be routed to MQ queues for various
Context response needs to be sent back to the purposes without a specific request-
requester. reply relationship.
 MQGet node
The MQGet node reads a message from a specified queue, and establishes
the processing environment for the message

You can use an MQGet node anywhere in a message flow, unlike

an MQInput node, which you can use only as the first node in a message
flow. The output message tree from an MQGet node is constructed by
combining the input tree with the result tree from the MQGET call. You can
set the properties of the MQGet node to control the way in which messages
are received;

Terminal Description
The input terminal that accepts the message that is being processed by the
In
message flow.
The output terminal to which the output tree is propagated if an error (with a CC
that indicates a warning) occurs in the node while trying to get a message from
Warning the queue. The MQMD part of the message is parsed, but the rest of the message
is an unparsed BLOB element. The warning is discarded if the terminal is not
connected, and there is no output propagation from the node at all.
The output terminal to which the input message is routed if an error (with a CC
Failure that indicates an error that is more severe than a warning) occurs in the node
while trying to get a message from the queue.
The output terminal to which the message is routed if it is retrieved successfully
Out
from the WebSphere MQ queue.
The output terminal to which the input message is routed if no message is
available on the queue. The output message that is propagated to the No
No
Message terminal is constructed from the input message only, according to the
Message
values of the Generate mode, Copy message, and Copy local
environment properties.
Table 1. The terminals of the MQGet node

MQHeader node
Last Updated: 2021-03-01

Use the MQHeader node to add, modify, or delete MQ Message Descriptor

(MQMD) and MQ Dead Letter Header (MQDLH) headers.
You can add or remove a whole header, or you can change only certain fields
in a header

Terminal Description
The input terminal that accepts a message for
In
processing by the node.
The output terminal to which the input message is
Failure
routed if a failure is detected.
The output terminal to which the transformed message
Out
is routed if the input message is processed successfully.

Properties:

1. Description

2. MQMD

3. Report

4. MQDLH

5. MOnitoring

MQPublication node
Last Updated: 2024-08-16

Use the MQPublication node to filter output messages from a message flow
and transmit them through an MQ pub/sub broker to subscribers who have
registered an interest in a particular set of topics.

Use the MQPublication node to publish a message through the IBM®

MQ queue manager specified on the integration node (the MQ pub/sub
broker). Applications that expect to receive publications must register a
subscription.
Variables:
 An ESQL variable is a data field that is used to help process a message.

 To define a variable and give it a name, use the DECLARE statement.

 The names of ESQL variables are case-sensitive

 If an initial value is not specified, scalar variables are initialized with the special
value NULL

 ESQL Variables declared at Module level 'belong' to a single node. However,

variables declared at the Schema level are also given to each node that
references that schema. So although variables at schema level are only declared
once, each ESQL node has its own copy, which is not shared with any other node
(unless the variable is marked SHARED).

The scope, lifetime, and sharing characteristics of variables describe how widespread
and for how long a particular ESQL variable is available:

Scope

Is a measure of the range over which a variable is visible. In the broker environment, the
scope of variables is typically limited to the individual node.
 Lifetime

Is a measure of the time for which a variable retains its value. In the broker
environment, the lifetime of variables varies but is typically restricted to the life of a thread
within a node.

Sharing characteristics

Indicate whether each thread has its own copy of a variable or whether one variable is
shared between many threads. In the broker environment, variables are typically not shared

Types of variable

External

External variables (defined with the EXTERNAL keyword) are also known as user-defined
properties

They 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.

Normal

Normal variables 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.

Shared
 Shared variables can be used to implement an in-memory cache in the message flow,
see Optimizing message flow response times. Shared variables have a long lifetime and are
visible to multiple messages passing through a flow, see Long-lived variables. Shared variables
exist for the lifetime of the integration server process, the lifetime of the flow or node, or the
lifetime of the node SQL that declares the variable (whichever is the shortest). Shared variables
are initialized when the first message passes through the flow or node after each broker startup.