App Connect

App Connect

Join this online user group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.


#Applicationintegration
#App Connect
#AppConnect
#Integration
#Automation
 View Only

Explore the new features in App Connect Enterprise 13.0.8.0

By Ben Thompson posted 07/19/26 07:30 PM

  
iStock_000020343379_XXXLarge


We are very pleased to mark the recent delivery of IBM App Connect Enterprise 13.0.8.0 software.  We aim to provide regular quarterly mod releases for ACE 13 which contain both new features and regular maintenance.

  • IBM App Connect Enterprise 13.0.1.0 was released in September 2024 - more information here
  • IBM App Connect Enterprise 13.0.2.0 was released in December 2024 - more information here
  • IBM App Connect Enterprise 13.0.3.0 was released in March 2025 - more information here
  • IBM App Connect Enterprise 13.0.4.0 was released in June 2025 - more information here
  • IBM App Connect Enterprise 13.0.5.0 was released in September 2025 - more information here
  • IBM App Connect Enterprise 13.0.6.0 was released in December 2025 - more information here
  • IBM App Connect Enterprise 13.0.7.0 was released in March 2026 - more information here
  • IBM App Connect Enterprise 13.0.8.0 has just been released in June 2026 - more information below

This blog post summarizes all the latest and greatest capabilities which were made available in IBM App Connect Enterprise 13.0.8.0:

Inbound OAuth for the HTTP Input node and REST APIs
About 6 months ago, ACE 13.0.6.0 added support for message flows to use the OAuth 2.0 authorization framework when using outbound requests to communicate with external REST APIs. The current release ACE 13.0.8.0 further extends our use of OAuth to incorporate inbound requests arriving at an HTTP Input node or coming into an ACE REST API.  OAuth 2.0 is an authorization framework that allows third-party applications to access protected resources on a user's behalf without needing to directly share the user's credentials. In the context of REST APIs, OAuth 2.0 enables secure access to resources by delegating authorization to an authorization server and then using access tokens granted by the authorization server to check what an application is allowed to do, instead of relying on passwords. This approach has several important benefits:
  • Applications no longer store the user's password
  • Applications receive limited access, not full account access
  • Users can revoke an applications access without changing their password
  • If an application is compromised, the user's password is not exposed
For inbound OAuth, the ACE integration server is fulfilling the role of Resource server. ACE uses token introspection to validate that an OAuth token that has been presented by a connecting client is active. ACE then checks the required scopes for the resourcebeing requested and validates that the token has the correct permissions in place. These OAuth scopes can be defined within the new OAuth Policy type, or within an OpenAPI document.  To enable an HTTPInput node to use OAuth:
  1. Begin by creating a policy of type OAuth, which is configured with the connection details of the OAuth server.
  2. Next, create a policy of type Security profiles, from which the OAuth policy is referenced.
  3. The last step is to associate the HTTPInput node with the Security profiles policy (helpfully, this keeps the new security settings for the HTTPInput node consistent with prior authentication and authorization options for the node).
For example, the picture below shows step 2 - a policy of Type Security Profiles. The Authorization property is set to the new enumeration of OAUTH, and the Authorization configuration property references the policy name MyOAuthPolicy inside the policy project named MyPolicies:
image
The picture below shows step 1 - the policy named MyOAuthPolicy of Type OAuth which is referenced above:
image
Note that in this example the Scopes location is set to POLICY ONLY, which means that only scopes defined within the OAuth policy will be consulted. The Scopes property defines a space separated list of scopes. The alternative to POLICY ONLY is a setting of CUMULATIVE which causes the set of scopes to be consulted to be a super set of those defined in the policy and those defined in an OpenAPI document should one also be configured.
The final configuration step is to apply the Security Profile to the HTTP Input node which is done on the Security properties tab where the Security profile property is set to the value {MyPolicies}:MySecurityProfilePolicy:
image
For more information, take a look at the ACE documentation for Configuring HTTPInput nodes to use OAuth, the ACE documentation for Configuring a REST API to use OAuth and the ACE documentation for Creating a security profile for OAuth.
Toolkit - New graphical IF node for conditional logic
The If node is a new mid-flow node, contained in the Routing drawer of the Toolbox section of the flow palette. It provides a graphical interface that helps message flow developers define conditional routing logic. ACE Toolkit has quite a few different historical alternatives for defining conditional logic such as Filter nodes (which are limited to True and False output terminals, and are configured using ESQL expression logic), Route nodes (which provide multiple dynamic output terminals and the conditions are configured using XPath expressions), and RouteToLabel nodes (which provide multiple dynamic outputs using Label nodes, and work in conjunction with destinations that are assigned into the Local Environment tree so they will work with any type of transformation node). Given these other options, some users might reasonably ask "why provide an If node now?!". The If node leans heavily on technology which is used to model and map messages using pre-defined JSON schema. Readers may be familiar with the JSONata Transformation node, or they may have used the Web browser based Designer authoring tool. The look and feel of the IF Node is very similar to these other examples which offer a cleaner interface particularly aimed at integrators who prefer graphical tools to programmatic interfaces. Aside from improved and easier usability compared to some of the other historic options for defining conditional logic in a Toolkit flow, the other reason for adding an IF node to the Toolkit is to help us in our longer term strategy of providing the conditions whereby Designer authored flows can be converted into Toolkit authored flows. This is not yet a supported feature of the ACE product, but by adding the IF node to the Toolkit palette, we have another basic building block ready should we decide to add this kind of conversion feature in a future release.
image
 
When configuring the new If node, the Configure button lets you define output terminal names dynamically (in the above picture we have chosen a Terminal name of GB), and provide a JSONata expression for the conditional logic that can refer to fields from the message context. In the example above, the value of the Country field is checked to see if it equals the value GB.  When the configuration page is closed, the updates are reflected in the Properties page of the Toolkit node as shown below:
image
For more information, take a look at the ACE documentation about the If node.
Toolkit - New Log4j node for logging
For many years, ACE provided a category 2 support pac containing a Log4j node. Category 2 support pacs are provided in good faith and as-is. There is no warranty or further service implied or committed and any supplied sample code is not supported via IBM product service channels. This support pac was then later moved to our OT4I (Open Technologies for Integration) organization on GitHub.com here.  From ACE 13.0.8.0 we have now incorporated a Log4j node (largely inspired by the support pac node) into the core product capability, which is fully supported just like other functions of the product.
image
 
The Log4j node is found in the Error handling drawer of the message flow palette and it has one input terminal and one output terminal.  As its name suggests, when a message reaches an instance of the Log4j node in a flow, a log message is written and then the message is propagated unchanged to the output terminal.
The Log4j node provides another alternative for logging application message content as it passes through a message flow in a similar manner to the Trace node and Log node; the Log4j node is not intended as a replacement for user trace, service trace, or diagnostic logging. The properties of the Log4j node define how logging should occur:
  • The Log level property specifies the severity level for the log message. You can assign one of the enumerated values from DEBUG / INFO / WARN / ERROR / FATAL
  • The Log text property specifies the message text to be written to the log. The text can carry plain text such as "Order processed successfully", variable references such as $Environment.Variables.Log4j.LogText$ (note the dollar symbol at the beginning and end of the variable reference which differentiates it from plain text) which are then substituted from the in-memory message tree at runtime, or a mixture of both.
  • The Logger name property specifies the name of the Log4j logger to be used by the node. The name must match a logger that is defined in the Log4j configuration file (more on this topic below). You can override the value of the Logger name property at run time by setting the LocalEnvironment.Log4j.LoggerName environment variable.
The log4j configuration file that defines the available Log4j loggers and where they write to on the file system, is specified in the integration server's server.conf.yaml file in the Log4jManager section of the file as shown below:
image
Centralising the log4j configuration file on a resource manager makes the configuration of multiple log4j nodes easier, and also allows the same loaded classes to make it simple to provide a new built-in ESQL function that is also capable of logging using log4j loggers.  The example Compute node ESQL shown below demonstrates how the new LOG4J function in ESQL can be used:
For more information, take a look at the ACE documentation about using Log4j.
Toolkit - Using Expression Navigator for easy access to Context trees

In ACE 13.0.8.0 the Toolkit provides a new visual interface for helping you build up expressions that refer to fields in the in-memory message tree passing through a message flow. When editing certain message flow node properties, a data location expression is needed to help the flow developer select a field from the message tree whose value will be used for a particular purpose by the node. For example, consider a File Output node's Request properties tab. One of the properties named Request directory property location specifies the directory which the File Output node will write its file to:

image

In ACE 13.0.7.0, clicking the Edit button (marked by the red box in the picture above) launched the XPath Expression Builder as shown below:

As its name suggests, the XPath Expression Builder utilized XPath expressions when navigating through the message tree, which although functionally rich, can appear a little bit complex for less experienced users, and can be somewhat non-intuitive when navigating an in-memory tree that does not represent XML data(!) This editor also did not support Context trees. To improve this part of the product, from ACE 13.0.8.0 in place of the XPath Expression Builder we now launch the new Expression Navigator instead. As shown below, the Expression Navigator can be used with Context Trees. You can use the Filter box to search for specific fields. You can expand and collapse the sections of the tree and double click a field to select it (which will populate the Expression property shown at the base of the window). If you want to switch back to the product's old behaviour, you can use the link at the base of the window to Open the Xpath expression builder:

image
For more information, take a look at the ACE documentation about the Expression Navigator.
OpenTelemetry tracing for Compute nodes
OpenTelemetry is a Cloud Native Computing Foundation project that provides an open-source framework for observability. It provides a standardized set of APIs, SDKs, and tools to generate, collect, process, and export telemetry data aligned around three pillars of Metrics (capturing numerical measurements over time), Logs (text events, errors and exceptions) and Tracing (tracking end-to-end transactions across multiple applications). Within the OpenTelemetry standards, ACE has a long track record of promoting the OpenTelemetry approach to tracing, which helps users to diagnose the elapsed time spent by a piece of data within different applications. ACE offers configuration for emitting trace events when interacting with the MQ nodes, HTTP nodes, REST nodes, SOAP nodes, Callable Flow nodes, Kafka nodes, Discovery Connector nodes and, from ACE 13.0.8.0, Compute nodes too. A trace typically consists of many Spans, where a span typically represents the actions that occurred within a particular application and has information to make querying and debugging easier such as a name, a status, a span kind, and time-related data.
 
Here's a reminder of the recent OpenTelemetry enhancements brought to ACE in version 13 mod releases:
  • ACE 13.0.2.0: OpenTelemetry authentication improvements. Security credentials for HTTP and GRPC connections. Basic Auth, API Keys and Bearer Tokens supported.
  • ACE 13.0.4.0: Kafka nodes enabled for OpenTelemetry tracing by default. Discovery Connector node OpenTelemetry traces emitted by setting openTelemetryScope to the value extended in the server.conf.yaml settings.
  • ACE 13.0.4.0: Access to telemetry data from Trace nodes and Compute node ESQL (OPENTELEMETRY_TRACE_ID, OPENTELEMETRY_TRACE_PARENT, OPENTELEMETRY_SPAN_ID, OPENTELEMETRY_TRACE_STATE)
  • ACE 13.0.8.0: Compute node OpenTelemetry traces emitted by setting openTelemetryScope to the value extended in the server.conf.yaml settings.
When enabled, every Compute node execution will now emit an OpenTelemetry span. The span carries some basic information about the Compute node processing:
  • The attribute compute.mode carries the value of the Compute mode property
  • The attribute compute.return specifies whether the ESQL returned TRUE or FALSE
  • The attribute compute.propagate.to specifies the propagation target type
  • The attribute compute.propagate.terminal specifies the terminal name (when propagating to a terminal)
  • The attribute compute.propagate.label specifies the label name (when propagating to a label)
The Compute node will create one span for every PROPAGATE statement in the Compute node ESQL, plus one for the final return from the node. This means if your Compute node doesn't do an explicit propagate then you would get 1 span. 
An error span will also be marked in the following circumstances:
  • If the Compute node propagates to the failure terminal
  • If the Compute node propagates to an invalid label
  • If the Compute node catches an exception and rethrows

For more information, take a look at the ACE documentation about OpenTelemetry tracing.

WS-Security with SAML and Kerberos in Java 17 Integration Servers
ACE 13.0.8.0 completes full feature support with Java 17 integration servers. In the area of WS-Security, support for UserNameTokens and X509 came in 13.0.7.0 and now in ACE 13.0.8.0 we have also added support for SAML Tokens and Kerberos Tokens. An additional feature has been added to assist with migrating Java 8 WS Policy Sets and Bindings files. From within the Toolkit, right-click on a Binding and select the option to Migrate (Java 8) WS Policy Sets and Bindings. 
You can use Kerberos authentication with WS-Security either as a service or as a client.  Kerberos is a network authentication protocol that enables mutual authentication with symmetric keys. Users and services on a network authenticate with each other through a Key Distribution Center (KDC), as a trusted third party. You can use message flows to call web services that are secured with Kerberos by using a SOAP Request node and you can also provide web services that are secured with Kerberos by using SOAP Input Nodes. The WS-Security header passes Kerberos tokens. You can then sign and encrypt either parts or all of a SOAP message by using Kerberos tokens.
For more information about using WS-Security with Java 17 integration servers, please check out this documentation page.
For more information about ACE support periods and the transition of multiple features from Java 8 to Java 17, please check out this detailed blog post.
New Toolkit Discovery Connector Request nodes: HashiCorp Vault, Salesloft, SAP Commerce Cloud

Continuing our mission to expand the available Toolkit message flow nodes for easy connection to third party applications, this quarter ACE 13.0.8.0 has added three new Discovery Connector Request Message Flow nodes:

image
  • HashiCorp Vault (IBM Vault) Request node: HashiCorp Vault (IBM Vault) is a secrets management and data protection platform that securely stores sensitive information, controls access, and provides auditing capabilities.  A HashiCorp Vault secrets engine is a plugin-style component responsible for storing, generating or encrypting data. Secrets engines are enabled at specific mount paths and are incredibly flexible, so they can vary in their allowed functional capabilities. Secrets engines are provided some set of data, they take some action on that data, and they return a result.  The App Connect HashiCorp Vault Request node provides support for a wide range of secret engines including: alicloud, aws, azure, consul, cubbyhole, database, gcp, gcpkms, keymgmt, kmip, Kubernetes, kv, kv-v2, ldap, mongodbatlas, nomad, pki, RabbitMQ, ssh, terraform, totp, transform, transit.  You can use the HashiCorp Vault (IBM Vault) Request node in a message flow to connect to HashiCorp Vault (IBM Vault) and issue requests to perform actions such as Create, Retrieve, Update and Delete on objects such as config (you must be signed in to your account to view the objects linked to it).  The HashiCorp Vault (IBM Vault) Request node operations are synchronous and non-transactional.
  • Salesloft Request node: Salesloft provides a task-focused user interface that centralizes sales activities and enables users to manage engagements, track progress, and access insights efficiently across key workspaces.  Use the Salesloft Request node to connect to Salesloft and issue requests to perform actions on objects such as Accounts, Cadences, Cadence memberships, Calls, Emails, Notes, People and Users.
  • SAP Commerce Cloud Request node: SAP Commerce Cloud is a cloud-based digital commerce solution that enables organizations to deliver personalized and scalable e-commerce experiences across multiple channels. It provides capabilities for product content management, order management, customer experience personalization, and integration with enterprise systems. Use the SAP Commerce Cloud Request node to connect to SAP Commerce Cloud and issue requests to perform actions on objects such as Addresses, Base sites, Cart delivery modes, Cart entries, Cart promotions, Carts, Catalogs, Cost centers, Countries, Currencies, Customer groups, Customers, Languages, Orders, Payment card types, Payment details, Products and Stores.

Each new type of connector also has a corresponding new policy type, which helps Toolkit users define configuration properties for easy connection to the applications. These policies also link to credential information that can be encrypted and stored in an ACE vault, enabling the ACE runtime to safely and securely connect to your applications. For example, here's a picture of the new HashiCorp Vault policy type:

image
For more information, take a look at the ACE documentation about the HashiCorp Vault (IBM Vault) Request node, the ACE documentation about the Salesloft Request node. and the ACE documentation about the SAP Commerce Cloud Request node. 
New Toolkit Discovery Connector Input node: Salesloft
Continuing our mission to expand the available Toolkit message flow nodes for easy connection to third party applications, this quarter ACE 13.0.8.0 has added another new Discovery Connector Input Message Flow node:
 
image
  • Salesloft Input node: Salesloft provides a task-focused user interface that centralizes sales activities and enables users to manage engagements, track progress, and access insights efficiently across key workspaces. Use the Salesloft Input node in a message flow to connect to Salesloft and monitor and accept input. For example, you can use the Salesloft Input node to monitor Salesloft for new emails. When a new event is created, the Salesloft Input node generates a event tree that represents the business object with details of the new event. The message tree is propagated to the Out terminal so that the rest of the message flow can use the data to update other systems or to audit the changes.

For more information, take a look at the ACE documentation about the Salesloft Input node.

New Designer Discovery Connector node: Hive

In addition to the new Toolkit Discovery Connector nodes mentioned above, ACE 13.0.8.0 also provides a new discovery connector type (which can be used as an Event connector or as a Request connector) which can be used in a flow authored in the Designer tooling. This new Designer Discovery Connector node is for communicating with Hive.  Hive is a data warehouse and SQL query engine that is built on the Hadoop ecosystem. It provides an SQL like interface to query and analyze large volumes of data, access data that is stored in databases and file systems that integrate with the Hadoop ecosystem, and connect to Hive compatible platforms.

image

Importing and Exporting artifacts in Designer

From ACE 13.0.8.0 the Designer authoring tool provides a new Import and Export experience that allows developers to export Accounts, Flows and Proxies from one instance of Designer and then import them into a different instance of Designer. This makes it easy for more than one developer to collaborate on a solution. 

The Export designer interchange wizard provides three tabs for selecting Accounts, Flows and Proxies for export. On the Flows panel, you can select one of more Flows for export. In the example shown, the BatchFlowDemo message flow has been selected. The option to Include linked accounts has also been selected:

image
Switching to the Accounts tab, the wizard has automatically selected the accounts which are required by the flow:
image
Later in the wizard, because credentials are being exported they are secured using an archive key which is added to the wizard as shown below:
image

For more information, take a look at the ACE documentation for Exporting a design interchange file and the ACE documentation for Importing a designer interchange file. 

Commands: ibmint  display bar and ibmint generate overrides
ACE 13.0.8.0 introduces two ibmint commands which help users to more easily promote their Designer flows through to higher deployment environments:
 
Admin REST API for Summary Statistics

ACE 13.0.8.0 also adds a new option to the administrative REST API that retrieves real-time summary statistics for integration servers, applications, message flows, and nodes. The summary statistics record provides immediate access to performance metrics without waiting users having to wait for time-based intervals, enabling you to monitor message flow performance and resource utilization in real time. These minor API changes provide an excellent foundation for further future enhancements in the area of MCP Tools for troubleshooting ACE.

For more information, take a look at the ACE documentation for Accessing summary statistics through the admin REST API.

0 comments
274 views

Permalink

https://community.ibm.com/community/user/blogs/ben-thompson1/2026/06/25/ace-13-0-8-0