IBM App Connect Enterprise (ACE) v12 –

Comprehensive Integration Guide

Introduction to IBM App Connect Enterprise (ACE)
IBM App Connect Enterprise (ACE) v12 is IBM’s premier integration middleware (formerly known as IBM
Integration Bus or WebSphere Message Broker). It enables business applications to exchange data through
message flows – pipelines of logic that route, transform, and enrich messages between sources and
targets 1 2 . As an Enterprise Service Bus (ESB), ACE supports connecting diverse systems over multiple
protocols (e.g. HTTP, SOAP, JMS, IBM MQ, databases, files, etc.) with rules to route and transform data 2 .
This guide provides an intern-friendly manual for using ACE v12 on Windows, covering key concepts
(integration nodes, servers, message flow nodes), command-line administration, and integration with IBM
MQ, Oracle DB (via ODBC), and testing tools (Postman, SOAP UI, etc.).

ACE Architecture: Integration Nodes, Servers, and Flows

Integration Node (Broker): The central runtime component in ACE is the integration node (also called a
broker). An integration node is a named container or process that can host one or more integration servers
(similar to execution groups in older versions) 3 4 . It serves as a management point for deployed
applications and can be associated with an IBM MQ queue manager for messaging capabilities 5 .

Integration Server: An integration server is an isolated runtime environment within a node, running a set of
deployed message flows and resources as a separate process 6 . Each integration server has its own
memory and execution space, providing isolation (e.g. you might separate flows by department or
sensitivity) 7 8 . In ACE v12, integration servers can either be associated with a node (managed by the
broker) or run independently (standalone processes) 9 10 . For development on a single Windows
machine, it’s common to define one integration node and run multiple integration servers under it (unless
containerizing or using independent servers for quick tests) 11 12 .

Message Flows and Nodes: The actual integration logic is implemented in message flows. A message flow
is a sequence of processing steps, each step being a node that performs a specific function on the message
(input, transform, route, call service, output, etc.) 13 . You build message flows in the ACE Toolkit (an
Eclipse-based IDE) by dragging nodes from a palette and wiring them together to define how messages
move through the flow 14 . ACE provides a rich set of built-in nodes for connectivity to various protocols
and systems, including IBM MQ, JMS, HTTP/HTTPS, web services (SOAP/REST), files, databases (ODBC/JDBC),
Enterprise systems (SAP, Siebel), and more 15 . These nodes allow ACE to mediate between different
applications – for example, an HTTP Input node can receive a REST request, a Compute node can transform
or enrich the data (perhaps querying a DB), and an MQ Output node can put a message on a queue 16 .

Integration with IBM MQ: If your flows use IBM MQ (for JMS or queue messaging), the integration node
can be created with an associated queue manager. This allows ACE message flows to directly get/put

1
messages to queues. (You can also connect to MQ in client mode without associating a queue manager, but
associating one simplifies usage of MQ nodes.) When an integration node is created with a queue manager,
features that require MQ (like MQInput/MQOutput nodes or the integration node’s HTTP listener in some
modes) become available 5 .

ACE integration architecture: An integration node (broker) can host multiple integration servers, each running
message flows. The node may be tied to an IBM MQ queue manager for messaging. Message flows use
various nodes to connect to external systems (HTTP clients, MQ apps, databases, etc.). Tools like the ACE
Toolkit or command console are used to deploy and manage these resources.

Administration and Tools: ACE can be administered via the ACE Toolkit (graphical interface), a web UI, or
the command-line. In development, you’ll often use the Toolkit to deploy flows directly to an integration
server for quick testing 17 18 . In production, you typically package flows into a BAR (broker archive) file
and deploy via commands or automation 19 . ACE v12 also includes a web-based admin console (by default
on port 4414 for the first integration node) for monitoring and managing integration servers and deployed
flows 20 .

Installing and Setting Up ACE on Windows

Installation and Environment: After installing IBM ACE v12 on Windows, you’ll have the ACE Toolkit and
the runtime. To use command-line tools, open the IBM App Connect Enterprise Command Prompt (which runs
mqsiprofile to set up environment variables) 21 22 . On Windows, ensure you run the command
console as Administrator (elevated privileges) for management tasks 23 .

Creating an Integration Node: Use the mqsicreatebroker command to create a new integration node
(broker). You must give it a name, and optionally you can specify a default queue manager ( -q ) and a
service user account ( -i for user, -a for password) under which it will run as a Windows service 24 . For
example:

mqsicreatebroker INODE -i myUser -a myPass -q ACEQMGR

This creates a broker named “INODE” associated with queue manager ACEQMGR (which should exist and
be running when you start the node) 25 . The -i / -a options specify the Windows user credentials that
the broker’s service will run as 26 . If you omit -q , the node is created without MQ – you can still use ACE
for integration flows that don’t require MQ, but MQ-based nodes/features will be unavailable 5 .

When the broker is created, configuration files and directories are set up under %PROGRAMDATA%
\IBM\MQSI\components\<nodeName> (by default) to store the node’s settings (node.conf.yaml) and, once
you create them, subdirectories for integration servers and their configurations 27 28 . On Windows, the
default work path would be C:\ProgramData\IBM\MQSI\components\INODE\... for a node named
INODE.

Starting and Stopping the Integration Node: Once created, start the integration node with mqsistart
<NodeName> and stop it with mqsistop <NodeName> 29 30 . For example:

2
 mqsistart INODE

This will start the broker process (on Windows, it starts the corresponding Windows service) 31 . All
integration servers under that node will start automatically as well, unless they were previously marked to
not auto-start (e.g. via a .stopped flag file) 32 . When stopping, you can use mqsistop INODE to
gracefully shut down the broker and all its servers 30 . If the broker had an associated queue manager, you
may also issue endmqm ACEQMGR to stop the MQ queue manager (and strmqm ACEQMGR to start it) 33
34 .

You can verify the node’s status with mqsilist . Running mqsilist with no arguments lists all brokers
on the machine; it will indicate if a node is running and its web admin URI (e.g. “...Integration node
'NODE1' ... is running” or “... is stopped”) 35 36 . For more detailed info (like which servers and applications
are deployed), you can use mqsilist <NodeName> or other flags (as described later in this guide).

Creating Integration Servers (Execution Groups): By default, a new integration node may not have any
running integration servers until you create one (in older versions a default server named “default” was
created automatically – if not, you can create one manually). To add an integration server to a node, use:

mqsicreateexecutiongroup INODE -e Default

This example creates an integration server named “Default” under node INODE 37 38 . (In ACE, “execution
group” is an older term; the command is the same but it creates a new integration server process.) Once
created, the server will by default start along with the node. If needed, you can start or stop a specific
integration server without stopping the whole node by using the mqsistartmsgflow and
mqsistopmsgflow commands with the -e (execution group name) option 39 . For example:

mqsistartmsgflow INODE -e Default

mqsistopmsgflow INODE -e Default

These commands start/stop all message flows in the specified integration server (essentially bringing that
integration server process up or down) 39 . After creating, say, “Default” server, you could deploy your
applications to it. You can list integration servers in a node with mqsilist INODE – it will show each
server and its status 40 .

Web User Interface: When you started the integration node, ACE also started a web management UI by
default. The first integration node uses port 4414 for web admin; subsequent nodes use 4415, 4416, etc.
20 . You can open this in a browser (e.g. http://<hostname>:4414 ) to see a dashboard of integration

servers, applications, message flows, and to perform some management tasks. ⚠ Note: By default (with no
security enabled), the web UI will allow full access to manage the node by any user 20 . In a team setting or
production, you’d secure this with credentials or disable it if not needed. For now, as an intern on a local
setup, you can use it for convenience. If needed, the port or security can be configured in the
node.conf.yaml or via mqsichangeproperties command later.

3
Developing Integration Flows in ACE Toolkit
Toolkit Overview: The IBM App Connect Enterprise Toolkit is the Eclipse-based IDE used to design and
develop integration solutions 41 42 . In the Toolkit, you organize your work into applications or
integration projects (which bundle message flows and related resources). You drag nodes from the palette
onto a canvas to build a message flow, connecting nodes with arcs to define how messages pass through
the flow 13 43 . Each node has configurable properties (set in a properties pane) to define its behavior (e.g.
an MQ Output node’s properties include the queue name, an HTTP Input node’s includes the URL path, etc.).

Common Node Types: ACE provides many node types; below are some key categories and examples:

• Input Nodes (Source): Start of a flow, waiting for incoming messages or triggers. For example:
• HTTP Input – receives REST/HTTP requests on a specified URL/port.
• SOAP Input – listens for SOAP web service requests (with a WSDL interface).
• MQ Input – gets messages from an MQ queue (triggers flow on message arrival).
• File Input – reads files from a directory.
• Timer or Kafka Input – triggers flows on a schedule or from a Kafka topic, etc.
• Output Nodes (Target): Endpoints to send out messages or responses:
• HTTP Reply – sends response back to the HTTP client (completing an HTTP Input).
• SOAP Reply – sends SOAP response.
• MQ Output – puts a message to an MQ queue 16 .
• File Output – writes out to a file.
• Transformation & Processing Nodes:
• Compute – allows ESQL (Extended SQL) scripting to build or transform messages in code. (This is a
powerful node for any custom logic, where you can manipulate message trees using an SQL-like
language or even call Java if needed.)
• Mapping – a graphical mapping node to map fields from input to output (often used for
transforming formats, e.g. XML to JSON).
• Java Compute – similar to Compute but lets you write Java code to handle the message.
• Mapping, XSLT, .NET nodes – for mapping or calling external logic (e.g. .NETCompute node to
execute .NET code, if using Windows/.NET integration).
• Routing and Control Nodes:
• Filter – evaluates a Boolean condition (in ESQL) and directs the message to either a True or False
output terminal (or an Unknown terminal if condition is not satisfied) 44 45 . This is typically used
for simple content-based routing (e.g. if OrderTotal > 10000 then go down one path, else
another).
• RouteToLabel & Label – used together for more complex routing. A RouteToLabel node can direct
flow to a dynamic Label node (like a goto) based on some criteria.
• Switch – (in newer versions) can route to multiple outputs based on XPath or JSONata expressions
(for XML/JSON messages).
• FlowOrder – to enforce sequence (ensures one path finishes before the next starts, useful for
sequential processing).
• Throw/Catch – for exception handling (Throw node generates an exception, a TryCatch node or the
flow’s failure path can catch errors).

• Loop (not a single node but can wire nodes in a loop or use the Propagate statement in Compute for
looping).

4
 • Integration Nodes for External Connectivity:

• MQ nodes – MQ Input/Output (as above), MQGet (to fetch specific message), MQReply.
• Database nodes – Database (for making a simple SQL query/update in a flow), Retrieve/Insert/
Update/Delete nodes (which are specialized for database ops without coding, though Compute node
ESQL is often used for complex DB logic).
• Email nodes – to send email (EmailOutput) or retrieve (EmailInput).
• SAP, Siebel, JMS, etc. – ACE has nodes to connect to enterprise systems (like calling SAP BAPI, or
reading JMS messages from other providers). These often require configuration or adapter
installation.
• File nodes – FileInput/FileOutput as mentioned, plus FileRead, etc.
• Transformation nodes – we covered Compute (ESQL) and Mapping. Also there’s a Translation (for
message model-driven parsing with MRM, deprecated for new JSON/XML in favor of DFDL or app-
based parsing).

In practice, as an intern, you’ll likely focus on a subset: e.g. HTTP/REST nodes, MQ nodes, Database nodes,
and perhaps SOAP nodes. ACE’s connectivity is quite broad, but the concepts are consistent – each node
abstracts the connection to that system.

Developing a Simple REST Flow: For example, suppose we need a REST API that, given some input,
retrieves data from a database and returns a response. We would do the following in Toolkit: 1. Create a
new Application (e.g. MyRestApp). 2. In it, create a Message Flow (e.g. GetCustomer.flow). 3. From the
palette’s Connectivity drawer, drag an HTTP Input node onto the canvas. Set its properties: an HTTP method
(GET/POST etc.), and URL path (e.g. /getCustomer ). 4. Drag a Compute node next, connect the HTTP
Input’s out terminal to the Compute node. In the Compute node properties, set the Compute Mode
(whether you’re building a new message, etc.) and crucially set the Data Source if you want to access a
database directly from ESQL (the Data Source property would be the ODBC DSN name – more on
configuring this below) 46 . Then click Open ESQL to write ESQL code that, for example, does a SELECT from
the database using an ESQL SELECT or PASSTHRU query, and builds the output message (perhaps in JSON
format) to include in the HTTP response. 5. Drag an HTTP Reply node and connect it to the Compute node’s
out terminal. This will send the response back to the requester. The message that flows into HTTP Reply
(particularly the OutputRoot.HTTPResponse or OutputRoot.JSON tree in the message) will be sent as
the HTTP response body. 6. Optionally, add error handling: connect the failure terminal of nodes (like HTTP
Input or Compute) to a failure processing subflow (maybe a Trace node to log errors and a generic HTTP
Reply with an error status). Or use a TryCatch node around the Compute to catch exceptions and build an
error response.

You would then deploy this flow to an integration server (either by right-clicking the Application in Toolkit
and selecting Deploy to your running integration node/server, or by exporting a BAR file and using
command line). Once deployed and running, you can test it with Postman by sending an HTTP request to
your integration server’s host and port (more on testing later).

Applications vs Libraries vs Services: ACE organizes deployment artifacts in a few ways: - An Application
is a container for flows and resources that is deployable as a unit. It provides isolation – resources in one
application aren’t directly visible to another (unless explicitly shared via Libraries). - A Library is a reusable
collection of resources (subflows, schemas, ESQL, etc.) that can be referenced by applications. It’s a way to
avoid duplication. - Integration Services are a specialized type of application geared for SOAP web services

5
(with an WSDL interface), grouping request flow, response flow, and fault flow. You might use this if
implementing a SOAP service in ACE, as the toolkit can generate some flows from a WSDL. - You can also
deploy “loose” message flows (independent resources) but using Applications is recommended for clarity.

For a simple project, you can just use one Application that contains all your flows. If you have common
subflows or ESQL that might be used by multiple applications, consider placing them in a Library.

Deploying Flows: In development, deploying directly from Toolkit is easiest (just right-click and deploy to
the integration server). Under the covers, the Toolkit creates a BAR file and uses the mqsideploy
command. For command-line deployment: 1. First create a BAR file using mqsicreatebar (for ACE v12,
the ibmint package command can also be used). For example:
mqsicreatebar -a MyRestApp.bar -k MyRestApp (where -k specifies the application/project to
include). This packages all flows and resources of MyRestApp into MyRestApp.bar. 2. Then deploy the BAR to a
running integration server: mqsideploy INODE -e Default -a MyRestApp.bar (deploy BAR to the
“Default” integration server under node INODE) 47 48 . You could also deploy to a specific application
within a server, but usually deploying the whole bar is fine. The mqsideploy command output or the ACE
event log will indicate success or any errors in deployment.

IBM MQ Setup and Integration

IBM MQ is often used with ACE for reliable messaging. In your environment, you have IBM MQ installed –
ensure it’s properly set up before integrating with ACE. Key steps to set up MQ on Windows:

• Create a Queue Manager: The queue manager (QM) is the MQ server instance. Use the crtmqm
command in an MQ command prompt (or MQ Explorer GUI). For example, to create a QM called
ACEQMGR:

crtmqm ACEQMGR

After creation, start the queue manager with:

strmqm ACEQMGR

You should see a message that the queue manager has started 49 . (If using MQ Explorer, you can create
and start a queue manager through the GUI instead.)

• Create Queues: Once the QM is running, define the queues needed for your flows. Enter MQ’s
interactive console by:

runmqsc ACEQMGR

This puts you at a MQSC> prompt. To create a local queue, use the DEFINE QLOCAL command. For
example, to create a local queue named REQUEST.Q:

6
 DEFINE QLOCAL(REQUEST.Q)

You should get feedback that the queue is created 50 . Similarly create any other queues (e.g., a reply
queue or error queue if needed): DEFINE QLOCAL(REPLY.Q) .

If your integration node was created with -q ACEQMGR , it will automatically try to use ACEQMGR for MQ
operations. In ACE Toolkit, when you drop an MQInput or MQOutput node into a flow, if you leave the
“Queue Manager” property blank, it will use the broker’s associated queue manager (ACEQMGR). So the
queue names you enter in those nodes will refer to queues on ACEQMGR. If you didn’t associate a queue
manager, you would have to specify the queue manager name in each MQ node and ACE will connect as an
MQ client.

• Security Considerations (MQ Permissions): By default on Windows, IBM MQ defines a user group
mqm that has full authority. The user that runs ACE flows (e.g., the service user specified at broker
creation, or the account running the integration node) should have permission to access MQ
queues. Easiest way in dev is to add that user to the mqm group (which gives admin-level MQ
access). Alternatively, you can use MQ’s authorization commands to grant access. For example, to
allow a user IntegrationUser to put/get on REQUEST.Q , in runmqsc you could do:

SET AUTHREC PROFILE(REQUEST.Q) OBJTYPE(QUEUE) PRINCIPAL('IntegrationUser')

AUTHADD(PUT,GET)
SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('IntegrationUser') AUTHADD(CONNECT)

This grants that user connect authority on the QM and put/get on that queue 51 52 . MQ security can get
complex; for a controlled intern setup, running ACE under an account in mqm or using the default
MUSR_MQADMIN (for the MQ service) is simplest to avoid MQRC_NOT_AUTHORIZED (2035) errors. If you
see such errors, it’s likely a permissions issue.

• Define Listener and Channel (for external clients): If you plan to use an external tool (like an app
on another machine or MQ Explorer from your PC) to put/get messages to ACEQMGR, you need a
listener and SVRCONN channel. The listener opens a port (default 1414) for client connections. Define
one in runmqsc:

DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR)

START LISTENER(TCP.LISTENER)

Then define a server-connection channel (SVRCONN) which clients use:

DEFINE CHANNEL(ACE.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP)

To secure this channel, MQ by default from v8 blocks any user not specifically allowed. A quick way (though
not secure for production) to allow connections on that channel is to disable CHLAUTH for it or set a rule to
allow your user. For instance:

7
 SET CHLAUTH(ACE.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)
ACTION(REMOVE)

(This removes default blocking rules on ACE.SVRCONN). And potentially set MCAUSER('mqm') on the
channel to force all connections to mqm authority – again, fine for dev, but be cautious as it gives full
access.

Once listener and channel are set, you can connect a tool like IBM MQ Explorer or any client (including ACE
running on another host) to ACEQMGR using that channel and port.

For our scenario (ACE and MQ on the same machine), if the integration node is tied to ACEQMGR, ACE will
use a fast in-process connection to MQ (bindings mode), so no need for a client channel for ACE itself. The
above matters if you want to test MQ outside ACE (like using IBM MQ Explorer on your PC, or writing a
sample program to put messages).

Using MQ Nodes in ACE Flows: In ACE Toolkit, to integrate with MQ: - Use an MQ Input node in a flow to
receive messages from a queue. Set the Queue Name property to the name of the queue (e.g.,
REQUEST.Q ). If your broker has a default queue manager, leave the Queue Manager field blank (it will use
ACEQMGR). The MQ Input node will then automatically connect to ACEQMGR and listen on that queue. If a
message arrives, it triggers the flow. - Use an MQ Output node to put messages to a queue. Again, specify
the queue name and (if needed) the queue manager. The node will put the message to the target queue
(within the transaction of the flow if the flow is transacted). - For request/reply patterns, ACE provides
MQReply node which replies to the ReplyToQueue/ReplyToQueueManager set in the incoming message’s
MQMD. Typically, you’d use MQReply in a flow that was triggered by an MQInput and needs to send a
response back to the originator of the message.

Example: Suppose you want to read a message from ORDER.IN queue, call a database to enrich it, then
put a result message to ORDER.OUT queue. You could design a flow:

[MQ Input (QUEUE=ORDER.IN)] -> [Compute (lookup DB and enrich)] -> [MQ Output
(QUEUE=ORDER.OUT)]

The MQ Input node gets a message from ORDER.IN (from ACEQMGR). The Compute node does ESQL logic
(perhaps reading DB – see next section). Then MQ Output puts the transformed message to ORDER.OUT (on
ACEQMGR). If any error occurs in processing, you can catch it with a TryCatch or have the MQ Input’s Failure
terminal wired to an error handling subflow (for example, put the failed message to an error queue and/or
use a Trace node to log the error).

MQ Client vs Bindings: If ACE and MQ are on the same server (and ACEQMGR is associated), ACE will use
bindings mode (inter-process communication, faster and with full MQ API support). If ACE needed to
connect to a remote queue manager (MQ on another machine), you’d have to configure an MQ Client
connection. That can be done by setting MQ node properties (Queue Manager name, and either using a
client connection policy or environment variables like MQSERVER). For completeness: you can set up a MQ
Connection Policy in ACE (a policy project of type MQEndpoint ) specifying the channel, connection name,

8
etc., and reference that in your MQ nodes. Or simply ensure the environment has MQSERVER set (e.g.
MQSERVER="ACE.SVRCONN/TCP/RemoteHost(1414)" ) for ACE runtime. In our case, we stick to local MQ.

Database Integration (Oracle XE via ODBC)

IBM ACE can connect to databases either via ODBC (primarily on Windows and Linux for supported DBs) or
JDBC. On Windows, ACE provides DataDirect ODBC drivers for databases like Oracle and MS SQL by default
53 54 . We will use ODBC to connect ACE to Oracle Database XE.

Setting Up the ODBC Data Source: On Windows, ODBC data sources are configured through the ODBC
Data Source Administrator (64-bit, since ACE is 64-bit). Steps to set up Oracle DSN for ACE: 1. Open Data
Sources (ODBC) (64-bit) from Control Panel > Administrative Tools. Go to the System DSN tab (system DSNs
are needed so that the ACE service, which runs under the system or another user, can access it). 2. Click
Add, and select the driver named IBM App Connect Enterprise (11.0.x or 12.0.x) DataDirect Oracle Wire
Protocol 55 . (The exact name will include the version number of ACE – for v12 it might show 12.0.0.x in the
name – this is the DataDirect ODBC driver for Oracle included with ACE.) 3. The Oracle ODBC Driver Setup
dialog appears. On the General tab, enter: - Data Source Name (DSN): a name you choose, e.g., ORAXE_DS
(we’ll use this in ACE). - Hostname: the host where Oracle is running (e.g., localhost if it’s on your PC). -
Port: the Oracle listener port (default 1521 for Oracle XE). - Service Name: the Oracle service name or SID
(for XE default is usually XE ). 56 4. Switch to the Advanced tab. Enable SQLDescribeParam and
Procedure Returns Results options (check these boxes) 57 . These settings ensure the ODBC driver can
work properly with ACE for parameterized SQL and stored procedures. Also set Login Timeout to 0 (no
timeout) on that tab. There may be an Extended Options field – a common recommended setting for
Oracle is to add:

WorkArounds=536870912;EnableNcharSupport=0;

as suggested by IBM docs 58 (this addresses some Oracle data type quirks). 5. Click Test Connect (if
available) to verify the details. It will prompt for Oracle username and password. Enter the DB user (e.g.,
HR or whatever schema you have) and its password. You should get a "Connection successful" message if
everything is correct 59 60 . Then click OK to save the DSN. Now the DSN ORAXE_DS is defined in the
system.

At this point, ACE knows how to connect to Oracle in theory, but we must supply credentials to ACE and
ensure it uses the DSN.

Providing Database Credentials to ACE: We do not want to hard-code the DB username/password in

flows. Instead, ACE uses the command-line utility mqsisetdbparms to securely store credentials for a
given resource (in an encrypted credentials vault). Run the following command to set the Oracle DSN
credentials for ACE:

9
 mqsisetdbparms INODE -n odbc::ORAXE_DS -u dbUsername -p dbPassword

• INODE should be replaced with your integration node name (use -w <workDir> instead of
INODE if you’re using an independent integration server without a node) 61 62 . In our example, if
our broker is INODE, we use that.
• The -n odbc::ORAXE_DS tells ACE we’re setting credentials for the ODBC DSN named ORAXE_DS
63 . (ACE allows prefixes like odbc::DSN , jdbc::name , ftp::id etc. The odbc:: prefix is
optional on some ACE versions for DSNs – but using it is clear).
• -u and -p provide the Oracle DB username and password that the DSN should connect with.

This stores the credentials in ACE’s vault. ACE will use these when flows attempt to connect to that DSN,
rather than requiring the flow to supply them. You only need to run this once per DSN (or whenever the
password changes). You can verify that ACE accepted it by running mqsisetdbparms INODE -n
odbc::ORAXE_DS with no -u/-p – it won’t show the password, but if it lists an entry, it means it’s set.
Alternatively, use mqsicvp (next step) which will implicitly test it.

Testing the ODBC Connection (mqsicvp): ACE provides the mqsicvp (Connectivity Verification) command
to test DSN connections. You can run:

mqsicvp INODE -n ORAXE_DS

This will attempt to connect to the DSN using the stored credentials under the integration node, and it will
report success or any error messages 64 . If successful, you know ACE can connect to Oracle. If not, check
the error – common issues could be Oracle client not installed (with DataDirect that’s not needed), wrong
host/port, wrong credentials (ORA-1017 invalid username/password), or missing mqsisetdbparms step.

Using the DSN in Flows: Now in your ACE message flows, when you want to interact with the Oracle DB: - If
using a Database node (which is a simpler node for one-off SQL): set the Data Source property of the node
to ORAXE_DS (the DSN name). Then in the node, you can specify an SQL query (the node can be
configured for select, insert, update, etc., and you supply the table and columns or even an entire SQL
statement depending on how you use it). - If using a Compute node with ESQL: in the node’s Basic
properties, set Data Source to ORAXE_DS 46 . Then in your ESQL code within that Compute node, any
reference to the database (like SELECT ... FROM Database.Schema.Table ) will use that DSN. For
example, in ESQL:

DECLARE C CURSOR FOR SELECT NAME, BALANCE FROM Database.ACCOUNT_SCHEMA.ACCOUNTS

AS A WHERE A.ACCT_ID = InputRoot.JSON.Data.AccountId;

Here, Database.ACCOUNT_SCHEMA.ACCOUNTS refers to the table ACCOUNTS in Oracle schema

ACCOUNT_SCHEMA via the DSN. When the Compute node runs, ACE will connect using ORAXE_DS, log in
with the credentials you set, execute the query, and fetch results. (Make sure the Oracle user has proper
rights on the schema/table you query.)

Alternatively, you can use PASSTHRU for complex SQL or stored procedures:

10
 PASSTHRU('{call MYPROC(?,?)}', InputRoot.XMLNSC.OrderID,
OutputLocalEnvironment.Variables.OutStatus);

The DSN would likewise apply for this.

• If using a Mapping node or other higher-level nodes that need a DB, you would also specify the DSN
in their properties or via a configurable service or policy. But as a beginner, Compute or Database
node are most direct.

Example: Suppose in our earlier HTTP flow example, we want to query Oracle for customer details. We
would: - Configure an ODBC DSN (as above, say ORAXE_DS ). - Run mqsisetdbparms INODE -n
odbc::ORAXE_DS -u ORAUSER -p pass . - In the Compute node after HTTP Input, set Data Source =
ORAXE_DS . In ESQL, do:

SELECT C.Name, C.Address, C.Phone INTO Environment.Variables.CustInfo[]

FROM Database.MYSCHEMA.CUSTOMER AS C
WHERE C.CUST_ID = InputRoot.JSON.Data.CustID;

Then build the OutputRoot.JSON.Data from the selected data (the Environment.Variables.CustInfo). -
The Compute node will fetch from Oracle and build the output JSON, which the HTTP Reply will send.

ODBC vs JDBC: ACE on Windows leans on ODBC for Node-level integration (Compute, Database nodes use
ODBC DSNs). ACE also supports JDBC type-4 connections (especially if you use the JavaCompute node or the
JDBCConnector capability). For instance, you could define a JDBC configurable service for Oracle. But the
simplest path is ODBC as described. The benefit of ODBC in ACE is that the same ESQL code (with
Database.<schema>.<table> ) can work across different databases by just changing DSN and
credentials, making your flow portable.

SQL Developer & Testing: You have Oracle SQL Developer to run SQL queries directly on Oracle XE. This is
useful for: - Verifying that your Oracle database has the data you expect and that the user can access it. -
Checking results after ACE has inserted/updated data via a flow. - Preparing test data for ACE to retrieve.

Before running an ACE flow that depends on DB, use SQL Developer to ensure the schema (user) has
correct tables and maybe insert sample rows. For example, if testing a “get customer” flow, in SQL
Developer do SELECT * FROM CUSTOMER to see what’s there, or insert a test row if needed.

Content-Based Routing with Filter Nodes

In integration scenarios, you often need to route messages down different paths based on content (e.g.,
order value, message type, etc.). ACE provides the Filter node for simple yes/no routing logic. The Filter
node evaluates an ESQL boolean expression and propagates the message to one of its outgoing terminals: -
True terminal if the expression returns TRUE, - False terminal if FALSE, - Unknown terminal if the result is
null or unknown (or if you code a RETURN without an expression) 44 45 . - There is also a Failure terminal
(if an error occurs during evaluation).

11
You write a small ESQL snippet (much like in a Compute node) inside the Filter node. The last statement in
that snippet must be a RETURN <boolean expression>; 65 . For example, your filter ESQL might be:

DECLARE total REFERENCE TO InputRoot.XMLNSC.Order.TotalAmount;

RETURN total > 10000;

This will route the message out the True terminal if the Order’s TotalAmount is greater than 10000,
otherwise out the False terminal. You can then connect those terminals to different subflows (e.g., True ->
proceed to premium processing, False -> regular processing). If a terminal isn’t connected, any message
propagated there would be discarded 66 – so typically you ensure to handle both True and False paths (and
maybe Unknown).

Using Filter vs Other Routing Nodes: The Filter node is handy for binary decisions. For multiple-choice
routing (more than two paths), you would either chain filters or use a RouteToLabel/Label combination, or
the Graphical Data Map’s routing, or a Switch node. The Filter node cannot modify the message (it’s like a
read-only check; any attempt to change message content in a Filter node is not allowed – its purpose is only
to route) 67 68 . If you need to route and transform, you might use Compute node logic or the Mapping
node with route expressions. Nonetheless, Filter node keeps your flows visually clean for simple branching
and is optimized for that use.

Example: Suppose you have a flow processing transactions and you want to separate high-value
transactions. You can do:

[MQ Input] -> [Filter: if ${Root/Transaction/Amount} > 10000] ->(True)->

[Compute: special handling] -> ...
\->(False)-> [Compute: normal handling] -
> ...

In the filter’s ESQL you might write:

DECLARE amt DECIMAL InputRoot.XMLNSC.Transaction.Amount;

RETURN amt > 10000;

The flow then clearly splits at the Filter node.

If more complex routing logic is needed (like evaluating multiple conditions), you can either cascade filters
(one after another) or use a Compute node to set a routing indicator and then use a RouteToLabel.

12
Logging and Debugging Integrations
Robust integrations require visibility into what’s happening. ACE provides multiple ways to log and debug:

• Trace Node (Logging in flows): The Trace node is a special node you can insert in message flows to
record message content or custom text to a log file, user trace, or Windows Event Log 69 70 . This is
extremely useful for debugging – you can “print” the message at certain points in the flow. For
example, you might put a Trace node after a Compute node with a pattern like:

${Root} -- ${ExceptionList}

which would output the entire message tree and exception (if any) to the trace. Or you can craft a
more specific pattern:

OrderID:${Root.XMLNSC.Order.OrderID} Status:${Environment.Variables.Status}

to log only certain fields with some context text. The output of the Trace node can go to:
• User Trace (an ACE-generated binary trace log that you later format with commands),
• Local Error Log (which on Windows writes to the Application Event Log) 71 72 ,
• File (a specified text file).

You set this via the Trace node’s Destination property 70 . For quick debugging during development, writing
to a file or user trace is common. Writing to the Windows Event Log is also possible but can be noisy;
typically Event Log is used for production error messages rather than verbose traces.

Example: You can configure a Trace node to write to a file "C:\tmp\order_trace.txt" and set Pattern to
something like:

Order ${Root.XMLNSC.Order.OrderID} processed. Total=$

{Root.XMLNSC.Order.TotalAmount}, Result=${Environment.Variables.Outcome}

Each message passing that node will append a line to the file with those details. Important: Remove or
disable Trace nodes in production flows or set them to output minimal necessary info, because tracing can
impact performance 73 74 . ACE allows you to switch Trace nodes on/off dynamically without redeploying
the flow 75 . In Toolkit or via commands, you can enable/disable a Trace node which is handy to toggle
logging when troubleshooting.

• Service Trace and User Trace (debugging): Apart from Trace nodes, ACE has built-in tracing at the
integration server or node level. You can enable a user trace via the mqsichangetrace command,
which will record all activity of message flows (entering/exiting nodes, exceptions, etc.) to an internal
log. Then you use mqsireadlog and mqsiformatlog to dump that trace to a human-readable
text. This is often used when diagnosing problems in detail (it’s like verbose debug logging of the
broker). As an intern, you might not need this unless you hit a tricky issue, but it’s good to know:

13
 • mqsichangetrace INODE -e Default -l debug would turn on debug-level tracing for flows in
the “Default” integration server.
• Run your test, then mqsichangetrace INODE -e Default -l none to stop tracing.
• Then mqsireadlog INODE -e Default -o trace.bin -t (reads the raw trace out) and
mqsiformatlog -i trace.bin -o trace.txt (formats it). The resulting trace.txt will
show step-by-step execution, which is useful if something is failing silently or you need to see
computed values and node-by-node progression.

This user trace is separate from Trace nodes (but Trace node output to user trace will appear in it too).
Usually, try using Trace nodes first for targeted info. The user trace is more exhaustive and can be
overwhelming, but invaluable for deep debugging.

• The ACE Toolkit Debugger: ACE Toolkit has a debugger that lets you set breakpoints in a message
flow and step through it (similar to an IDE debugger). This requires running the integration server in
debug mode (enabling a debug port). If your Toolkit is set up and you have an execution group
running, you can right-click the flow and choose Debug – the Toolkit will attach to the flow, and you
can inspect message trees at breakpoints. Under the covers, this uses the Java debug port in the
integration server (which Adil’s commands snippet showed how to set via
mqsichangeproperties ... jvmDebugPort 76 , but the Toolkit automates most of it). If your
PC has performance issues, the debugger might be slow, so Trace nodes might be a simpler route
for now.

• Logging to External Systems: If the built-in Trace node or user trace is not flexible enough (for
example, you want to log to a custom file with specific format, or to send logs to a logging service),
some solutions include:

• Using a Compute node to write to a file (via ESQL FileWrite or Java file I/O in a JavaCompute).
• Using Event Logging: ACE can emit events (which can be captured by IBM App Connect Enterprise
Toolkit or by subscriber flows).
• Third-party support packs: e.g., there is an IBM-provided support pack that offers a Log4j node for
ACE to log using Log4j framework 77 . This is optional, but in advanced projects, it’s used to
integrate ACE logging with enterprise logging systems.

For your internship tasks, the Trace node is likely sufficient for logging runtime info during tests.

Example – Adding Logging: Suppose we have a flow and we want to log the input and output of a
Compute node. We could add: - A Trace node immediately after an input node (or at start of flow) with
pattern like: Input message: ${Root} to capture the entire message received. - Another Trace node
after Compute, pattern: Output message: ${Root} . - Both Trace nodes set to output to a file or user
trace. This way, we get a record of what came in and what went out, useful for debugging and audit. (Be
mindful of sensitive data – if messages have personal data, logs should be handled securely.)

• Error Handling: When errors occur (say a database is down, or a compute node throws an
exception), by default ACE will propagate the exception back through the flow. If not caught, for
input nodes like MQInput, ACE will roll back the message to the queue (putting it to a backout queue
if configured or re-queueing for retry), or for an HTTP flow, it might send an HTTP 500 with a generic
error. It’s often important to handle errors gracefully:

14
 • Use a TryCatch node around sections of your flow that might fail, so you can catch exceptions and
perform an action (like send an error response or route the message to an error queue). For
example, wrap a DB call in TryCatch: on Catch terminal, send a failure response with a JSON error
message instead of letting it propagate.
• Use the Catch (Failure) terminal of input nodes. E.g., the MQInput node’s Catch terminal can be
wired to a flow that logs the error and perhaps writes the failed message to an Error queue.
Similarly, HTTP Input node’s Failure terminal can be wired to a flow that sets an HTTP error status
and reply.
• The ExceptionList tree in ACE carries error details. A Trace node printing ${ExceptionList} will
show the error cause (like SQL error codes, stack traces).

For learning purposes, you might experiment with forcing an error (e.g., call a non-existent DB table) and
see how ACE behaves, then implement a TryCatch to handle it. Logging the ExceptionList via Trace is a good
way to see what info is available.

Testing the Integrations

After developing flows, you will use various tools to test and exercise them:

• Postman (for REST/HTTP): Postman is ideal for sending HTTP requests to your ACE REST APIs or
HTTP flows. You can compose GET, POST, PUT requests with headers and body as needed. For
example, if your ACE HTTP Input node is configured for URL /getCustomer on port 7800, and if
your integration server is using the default embedded listener on port 7800, you would in Postman
enter http://localhost:7800/getCustomer (with correct method GET/POST and any JSON
payload in the body if required) to hit the flow. Postman will show you the response from ACE (e.g.
the JSON document returned, or an error code). Things to keep in mind:
• If your ACE flow expects certain headers or content type, set them in Postman (e.g.
Content-Type: application/json if sending JSON).
• ACE by default might not enforce content-type on HTTP Input, but setting it properly is good
practice.

• You can use Postman’s collections to save test cases for each API you implement.

• SOAP UI (for SOAP Web Services): If you develop SOAP-based services in ACE (using SOAP Input/
SOAP Reply nodes and WSDLs), SOAP UI is a great tool. You’d import the WSDL file of your service
into SOAP UI, which creates a test project with sample requests for each operation. Then you can fill
in request data and run them. ACE will listen typically on a SOAP HTTP URL (the SOAP Input node’s
properties define this, often using the integration node’s listener or a specified port). You might need
to ensure the ACE integration node’s SOAP listener is enabled or use the embedded listener on a
port (similar to HTTP). By default, SOAP nodes use the same ports (7800 for HTTP, 7843 for HTTPS) as
HTTP nodes if using embedded listener 78 79 . Check your SOAP Input node properties for “Use
embedded listener” or if configured to use integration node’s listener. If the integration node’s
listener on 7080 is used for SOAP, you’d send requests to that. Otherwise, the default embedded port
7800 would handle both HTTP and SOAP for that integration server (the SOAP nodes register their
paths).

15
• Testing MQ Flows: For flows that start with MQ Input or otherwise read/write queues, you can test
them using:

• IBM MQ Explorer: a GUI to put messages onto a queue and view/get messages. You can create a
test message (e.g., an XML or JSON) and put it to the input queue of your flow. ACE will pick it up and
process. If the flow puts a reply or output message, you can browse the output queue.
• Sample programs (amqsput/amqsget): IBM MQ comes with sample utilities. For example,
amqsput ORDER.IN ACEQMGR will open the ORDER.IN queue on ACEQMGR and let you type a
message, ending with an empty line. amqsget ORDER.OUT ACEQMGR will get messages from
ORDER.OUT and print them to console. These are quick for basic tests but for structured messages,
MQ Explorer or writing a small app might be easier.

• Another flow: You can also test one flow with another in ACE. For instance, create a simple flow that
has an HTTP Input to receive test data and an MQ Output to put it to the target queue. Or an
MQInput to read a queue and HTTP Reply to send out – essentially bridging MQ to HTTP for test
introspection. But that’s usually not needed if tools above suffice.

• SQL Developer (for DB changes): If your flow writes to the database (e.g., inserts a record), after
running the flow you should query the DB with SQL Developer to see if the record is there. If your
flow reads from DB, you might use SQL Developer beforehand to ensure the data is present or to set
up the test scenario.

• Integration Node Logs: Check the Windows Event Viewer Application Log for any ACE runtime
errors. ACE logs important messages (like startup of integration node, errors that aren’t caught in
flow, etc.) to the Event Log on Windows 80 81 . For example, if an integration server crashes or a
flow throws an uncaught exception, you might see an entry with a BIP error code in the Event Log.
These BIP codes are documented and can help identify issues. (You can search the IBM knowledge
center or the error logs documentation for a given BIPxxxxE error message.)

• Troubleshooting Tips:

• If your HTTP requests aren’t reaching ACE, confirm the port. By default, integration servers use port
7800 for HTTP nodes (and 7843 for HTTPS) 79 . If you have multiple integration servers on one node,
each will auto-increment ports (7800, 7801, etc.) unless you override in server.conf.yaml 79 . The
integration node listener (if used) defaults to 7080. Use mqsireportproperties to see what ports
are in effect:
◦ mqsireportproperties INODE -e Default -o HTTPConnector -a will list the HTTP
listener settings for that server (embedded listener) 82 83 .
◦ mqsireportproperties INODE -b httplistener -o HTTPConnector -a for the
integration node’s listener 82 .
• If MQ flows aren’t picking up messages, ensure the integration node is associated with the correct
QM and that the QM is running, and that the queue names match exactly (MQ is case-sensitive for
queue names unless defined otherwise). Use mqsilist INODE -e Default -d2 to see if the
flow is running and has the MQInput node active 84 .
• For DB issues, the user trace ( mqsicvp or logs) will show if the DSN connection failed. One
common hiccup: the Oracle ODBC driver in ACE might require the Oracle client or certain
environment. With DataDirect, usually it’s self-contained, but if there’s an Oracle error, ensure Oracle

16
 XE’s listener is up and the service name is correct. The error ORA-12154 (could not resolve connect
identifier) means the DSN details might be wrong; ORA-12541 means no listener (DB not reachable);
ORA-1017 means invalid credentials (mqsisetdbparms credentials might not match DB user).
• Use Test data: If possible, write small test flows or use existing samples to ensure each piece works.
E.g., make a simple flow just to test DB connectivity: an HTTP Input -> Compute (SELECT from DB) ->
HTTP Reply. Test it. This isolates DB issues from other logic.
• Leverage ACE samples and tutorials: IBM provides default examples (like patterns or sample apps)
which can be loaded via Toolkit to see how things are done (for instance a REST sample or an MQ to
DB sample). These can be great learning aids.

Finally, practice and iteration are key. Build a simple integration (HTTP to DB, MQ to file, etc.) and test it
end-to-end. Then gradually add complexity (add a filter node, add error handling, logging, etc.) and observe
how the behavior changes. This stepwise approach will solidify your understanding of how ACE components
work together.

With IBM ACE v12, you have a powerful toolkit at your disposal – capable of connecting almost anything to
anything. By mastering integration nodes/servers, common nodes, and the command-line tools covered
above, you should be well-equipped to tackle integration tasks throughout your internship, even if your
work PC setup is finicky. Always refer to IBM’s documentation for deeper dives (IBM’s Knowledge Center is
excellent for detailed info and examples 16 44 ), and don’t hesitate to use the logging and debugging
techniques to understand and validate your integration flows. Good luck, and happy integrating!

Sources

• IBM App Connect Enterprise Overview and Concepts 16 6 7

• IBM ACE Integration Nodes and Servers 9 5

• IBM MQ Setup and Commands (Windows) 85 86
• IBM ACE ODBC Database Connectivity 87 57
• IBM ACE Commands and Deployment 24 47
• IBM ACE Message Flow Nodes (Filter, Trace etc.) 44 69

1 2 IBM App Connect Enterprise - Wikipedia

https://en.wikipedia.org/wiki/IBM_App_Connect_Enterprise

3 4 Name changes in IBM Integration Bus Version 10.0

https://www.ibm.com/docs/en/integration-bus/10.0?topic=100-name-changes-in-integration-bus-version

5 20 21 22 23 24 25 26 27 28 Creating an integration node by using the command line

https://www.ibm.com/docs/en/app-connect/11.0.0?topic=node-creating-integration-by-using-command-line

6 7 8 9 10 11 12 Integration servers and integration nodes

https://www.ibm.com/docs/en/app-connect/11.0.0?topic=overview-integration-servers-integration-nodes

13 14 15 16 17 18 19 41 42 43 IBM App Connect Enterprise technical overview

https://www.ibm.com/docs/en/app-connect/11.0.0?topic=overview-app-connect-enterprise-technical

29 30 31 32 33 34 35 36 80 81 Starting and stopping an integration node on Windows, Linux, and UNIX

systems
https://www.ibm.com/docs/en/app-connect/11.0.0?topic=ssin-starting-stopping-integration-node-windows-linux-unix-systems

17
37 38 39 40 47 48 76 82 83 84 IBM ACE 12 Commands. BASIC COMMANDS: | by Adil Abdullah |
Medium
https://adilabdullah.medium.com/ibm-ace-12-commands-1be493749f8e

44 45 46 65 66 Filter node
https://www.ibm.com/docs/en/integration-bus/10.0?topic=nodes-filter-node

49 50 51 52 85 86 Setting up the server using the command line on Windows

https://www.ibm.com/docs/en/ibm-mq/9.2.x?topic=windows-setting-up-server-using-command-line

53 54 Enabling ODBC connections to the databases

https://www.ibm.com/docs/en/app-connect/11.0.0?topic=databases-enabling-odbc-connections

55 56 57 58 87 Connecting to a database from Windows systems

https://www.ibm.com/docs/en/app-connect/11.0.0?topic=databases-connecting-database-from-windows-systems

59 60 61 62 63 Integrate Oracle SQL Database with IBM App Connect Enterprise | by Mohammed Ahmed

Siddiqui | Medium
https://medium.com/@ahmed.siddiqui423/oracle-sql-db-integration-with-ace-34cc98681181

64 mqsicvp command - IBM

https://www.ibm.com/docs/en/app-connect/11.0.0?topic=commands-mqsicvp-command

67 routing mechanisms-filter node - Medium

https://medium.com/@kevinnjagi83/routing-mechanisms-filter-node-3bdaaf99ec13

68 Explain Filter Node In IBM App Connect - Pronteff

https://pronteff.com/filter-node-in-ibm-app-connect/

69 70 73 74 75 Testing your message flow by adding Trace nodes

https://www.ibm.com/docs/en/app-connect/12.0?topic=ttmf-testing-your-message-flow-by-adding-trace-nodes

71 72 Trace node
https://www.ibm.com/docs/en/integration-bus/10.0?topic=nodes-trace-node

77 Using the Log Node in IBM App Connect Enterprise - DZone

https://dzone.com/articles/using-the-log-node-in-ibm-app-connect-enterprise

78 IIB Flow with HTTP Input Node at beginning returns "Unsupported ...
https://stackoverflow.com/questions/46435775/iib-flow-with-http-input-node-at-beginning-returns-unsupported-method-get

79 Switching from embedded listeners to an integration node listener

https://www.ibm.com/docs/en/app-connect/11.0.0?topic=listeners-switching-from-embedded-integration-node-listener

18