New in this release, the ACE Toolkit provides a watsonx Code Assistant chat experience for the first time. The feature utilizes a watsonx Code Assistant service instance running on IBM Cloud. Several pricing plans are available, including a 30-day free trial and an Essentials plan which starts at approximately $2 per 20 task prompts. Once you have a provisioned instance and an IBM Cloud API Key for access purposes, this can be provided to your ACE 13.0.4.0 Toolkit installation without the need for any further installations.

The feature provides a generative AI coding companion which is designed to accelerate software development when using the ACE Toolkit Eclipse IDE.  An interactive chat window is provided which generates code suggestions based on natural language prompts. Examples of the kind of use cases which we anticipate this feature helping with include:

• Asking generalized questions
• Providing explanations for existing code
• Generating instance data to match a schema
• Generating a schema by providing example instance data
• Generating Java code snippets through natural language
• Generating ESQL code snippets through natural language
• Generation of Unit tests

The watsonx Code Assistant provides a Prompt library with some example prompts to help get you started:

The watsonx Code Assistant also lets you rename or delete individual chats:

The Windows > Preferences panel can be used to update your API Key (which is safely encrypted in Eclipse secure storage) if you ever need to change it:

Over time, as further training is applied to the IBM Granite Large Language Model (LLM) upon which this feature depends, we expect to further improve the accuracy of responses for ACE specific use-cases and more tightly embed the experience into other aspects of the ACE Toolkit development experience.

ACE 13 introduced a new web browser based authoring experience for creating message flows called the Designer. Designer provides a no-code experience more geared towards citizen integrators who aren't necessarily integration specialists. With this user persona in mind, we continue to enhance the Designer tool to make it as simple as possible to create integrations, and in ACE 13.0.4.0 we have added two new features called Mapping Assist and Data Assist, which are both based upon pre-trained Artificial Intelligence (AI) algorithms which provide intelligent, customized data mapping suggestions.  Mapping Assist uses Natural Language Processing schema matching to find the closest match between the source and target field mappings. No pre-training is required to get started – Mapping Assist suggestions are provided by the algorithm as soon as you start building a flow. The algorithm assigns a percentage of confidence to each mapping suggestion based on semantic proximity to a target field, using business object metadata such as the field name, description, and display name to find the correct match. 

Mapping Assist runs locally where Designer is installed on your laptop development environment, so with this feature there are no connections to a cloud service, further securing your privacy and increasing suggestion generation speed. Your Mapping Assist AI model and runtime data is your intellectual property – this feature does not share data with others.  To exploit this new feature, you will need to download and run a single IBM-provided container which hosts the LLM - you could use Podman or Docker for example. After logging in to the IBM Container registry, a one-line pull command downloads the container to your local machine and then a further one-line command runs the container. This configuration process is described in our documentation here. 

The designer.conf.yaml file provides configuration information to control the way that Designer operates. A new stanza with a few properties is added to this yaml file in 13.0.4.0 to direct Designer how to locate the container, and what percentage minimum threshold should be applied when suggesting mappings:

# ACE Designer AI mapping assist
# To use mapping assist, the mapping assist image needs to be hosted in an accessible container environment,
# then configure the endpointURL to point at the running container and set the enabled property to true.
MappingAssist:
  enabled: true
  endpointURL: 'http://localhost:43893'           # Url to access the container hosting the mapping assist AI
  automapThreshold: 80                            # Minimum threshold for automapping

Let's consider an example response body structure in a Designer Flow for API. The picture below shows the structure which describes a person, before any mapping has been done. You can click the button named Preview 8 mapping suggestions to invoke the help of the AI model:

The display will update with some suggestions. In this example, an earlier part of the flow included retrieving contact information from Salesforce. As a result some broadly sensible suggestions are presented that involve various fields from the Salesforce contact object. You can click the Apply suggestions button to accept what is presented:

Using the same technology described above in the Mapping Assist section, a second new AI-based Designer feature named Data Assist is provided in ACE 13.0.4.0 which helps users construct JSONata expressions that can be used within a graphical mapping. In the Response body example shown below, the MobileNumber field is taking its value from the Mobile Phone field in the Salesforce Contact object. 

ACE 13.0.4.0 introduces some helpful simplifications in the Toolkit message flow programming model that will make it significantly easier for new users to create message flows, especially when utilizing the discovery connector nodes.  Historically, when creating a message flow in the ACE Toolkit, developers who are using the main transformation nodes in the product (such as the Compute node, JavaCompute and Graphical Map node) can choose the contents of the in-memory logical tree that gets copied to the later nodes in a message flow. Individual discovery connectors also expect specific inbound and outbound structures to be present in the in-memory logical tree (typically defined as JSON).  This means that it can sometimes be difficult later in a message flow to combine together the outputs from multiple earlier message flow nodes, unless you are familiar with these concepts ... until now! In ACE 13.0.4.0 we are introducing a major advance in this area - an immuteable (read-only) "Context tree" will hold output data from each discovery connector node which will be propagated forward through the message flow so that it is available when doing mapping tasks with later nodes in the flow. The context tree will also be available as a read-only input for logic written in a Compute node.

The details of this major improvement are perhaps most easily explained using an example. Consider a message flow (shown below) which is triggered by the creation of a bug in Jira. A Github Request node later in the flow aims to create a new equivalent issue in GitHub.  Some of the data from Jira can be used by the GitHub Request node courtesy of the new context tree which has been automatically propagated from the Jira Input node, through the Trace node, and passed to the GitHub Request node. The flow developer did not have to take any action to make this happen - the context tree is automatically available.  The trace node is only included in this example to demonstrate that a flow developer could also use this node to start understanding the shape of how data is being arranged in the context tree.  After the GitHub Request node, a Compute node creates an XMLNSC domain output message which contains values provided by both the Jira Input (the Jira Bug id) and also the GitHub Request node (the GitHub Issue number).

Here is a picture of the message flow shown in recording mode in the Flow Exerciser:

( ['MQROOT' : 0x1f6b2dac2c0]
  (0x01000000:Name):FlowDetails       = (
    (0x03000000:NameValue):FlowName              = 'ContextTreesExampleFlow' (CHARACTER)
    (0x03000000:NameValue):ApplicationName       = 'ContextTrees' (CHARACTER)
    (0x03000000:NameValue):LibraryName           = '' (CHARACTER)
    (0x03000000:NameValue):IntegrationServerName = 'TEST_SERVER' (CHARACTER)
    (0x03000000:NameValue):IntegrationNodeName   = 'integration_server' (CHARACTER)
    (0x03000000:NameValue):HostName              = 'redacted' (CHARACTER)
    (0x03000000:NameValue):ProcessId             = 38916 (INTEGER)
  )
  (0x01000000:Name):InvocationDetails = (
    (0x03000000:NameValue):Timestamp = GMTTIMESTAMP '2025-06-20 13:06:18.075001' (GMTTIMESTAMP)
    (0x03000000:NameValue):ThreadId  = 39332 (INTEGER)
    (0x03000000:NameValue):NodeName  = 'Jira Input' (CHARACTER)
  )
  (0x01000000:Name):Nodes             = (
    (0x01000000:Name):Jira Input = (
      (0x01000000:Name     ):PayloadDetails = (
        (0x03000000:NameValue):Domain         = 'JSON' (CHARACTER)
        (0x03000000:NameValue):Encoding       = 546 (INTEGER)
        (0x03000000:NameValue):CodedCharSetId = 1208 (INTEGER)
        (0x03000000:NameValue):Model          = 'gen/ContextTreesExampleFlow.Jira_Input.response.schema.json' (CHARACTER)
        (0x03000000:NameValue):Message        = '' (CHARACTER)
        (0x03000000:NameValue):PhysicalFormat = '' (CHARACTER)
      )
      (0x01000000:Object   ):Payload        = ( ['json' : 0x1f6b2ca4b90]
        (0x01000000:Object):Data = (
          (0x03000000:NameValue):issueId      = '10066' (CHARACTER)
          (0x01000000:Object   ):fields       = (
            (0x01000000:Object   ):issuetype                = (
              (0x03000000:NameValue):self           = 'https://redacted.atlassian.net/rest/api/2/issuetype/10013' (CHARACTER)
              (0x03000000:NameValue):id             = '10013' (CHARACTER)

<Message><JiraIssueNumber>10013</JiraIssueNumber><GithubIssueNumber>5</GithubIssueNumber></Message>

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

• Azure Service Bus Request node:  Azure Service Bus is a cloud messaging service from Microsoft which enables reliable messaging between applications and services. It helps decouple components, ensuring scalability, fault tolerance, and asynchronous communication. Some key features of Azure Service Bus include the ability to send messages to an Azure Service Bus Queue or Topic thus enabling publish-subscribe messaging for multiple consumers. Use the Azure Service Bus Request node to connect to Azure Service Bus and issue requests to create, retrieve, update or delete objects such as Queues, Topics, and Subscriptions .
• IBM Planning Analytics Request node:  IBM Planning Analytics is a planning, budgeting, and forecasting solution that helps organizations make better decisions by providing a flexible and dynamic way to analyze data.  Use the IBM Planning Analytics Request node to connect to IBM Planning Analytics and issue requests to create, retrieve, update or delete objects such as Cells, Chores, Cubes, Dimensions, Elements, Files, Groups, Hierarchies, Processes and Users.

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 Azure Service Bus policy type:

From ACE 13.0.4.0 we have also added two new Discovery Input Message Flow nodes:

• Amazon Event Bridge Input node:  Amazon Event Bridge is a serverless event bus service that simplifies your application architecture by allowing you to create scalable events from your applications that can integrate with Amazon Web Services (AWS). You can set up routing rules to determine where to send your data to build application architectures that react in real time to all of your data sources. Event Bridge enables you to build event-driven architectures that are loosely coupled and distributed.  Use the Amazon Event Bridge Input node to monitor and accept input from Amazon. New AWS events or custom events can be used to trigger the input node to start a propagation through a message flow.
• Azure Service Bus Input node:  Azure Service Bus is a cloud messaging service from Microsoft which enables reliable messaging between applications and services. It helps decouple components, ensuring scalability, fault tolerance, and asynchronous communication. Some key features of Azure Service Bus include the ability to send messages to an Azure Service Bus Queue or Topic thus enabling publish-subscribe messaging for multiple consumers. Use the Azure Service Bus Input node to monitor and accept input from Azure Service Bus which can be used to trigger the input node to start a propagation through a message flow.

This feature enables robust data handling and minimizes downtime in event-driven flows which start from a Salesforce Input node.  The Salesforce Input node can be used to trigger a Toolkit message flow when new objects are created or updated in your Salesforce system, such as new accounts, new cases, or new contacts for example. This latest release of ACE 13.0.4.0 further extends the abilities of the Salesforce Input node by providing an Advanced tab of properties carrying a State persistence policy:

There can be architectural situations where a message flow is temporarily not running, but Salesforce events might still be being generated, and therefore would typically be "missed" by ACE. When the ACE message flow is then restarted (perhaps in a container situation for example when Kubernetes moves a workload from one physical worker to another), it can be desireable for the input node to be able to return to a prior point of processing in the Salesforce event stream, and pick up events from the point at which they were last successfully processed. In order to provide this capability, a state persistence mechanism beyond the borders of the ACE product is required. This feature introduces a new State persistence policy to specify how ACE should communicate with this external persistence provider.

The Persistence type can take the value of REDIS or FILE. To locate Redis, the state persistence policy provides a link to a Redis policy name. It is this Redis policy that provides the required connection information for Redis.

The State Persistence policy has been deliberately described in a generic way in order to facilitate its future use with other discovery connector input nodes which have a need to store their state such as for example the last time a system was polled, a most recent stream position, or the last time an event was processed, all of which would allow for processing to resume from the same place after a restart.

The Redis key prefix property provides a default specification for a prefix which can be used with the Redis keys, for the purpose of tracing and maintainability. The default choice here is helpgul for us to be able to prefix all keys with the name of the relevant integration node and integration server.

OpenTelemetry is a Cloud Native Computing Foundation project (initially formed as a result of merging the OpenTracing and OpenCensus projects) that was accepted to the CNCF in 2019 and which then moved to the incubating maturity level in 2021. OpenTelemetry provides a collection of APIs, SDKs and tools that help provide a vendor and tool agnostic framework for observability.  OpenTelemetry tracing in particular helps to track activity which crosses the borders of multiple applications and transports in an integration architecture describes all of the activity in a single "transaction" as a Trace.

ACE has a long track record for adoption and support for Open Telemetry tracing. Initially in ACE 11 we provided a Transport Tracking User Exit interface layer with a sample that could be used as the basis for implementing a user exit to emit telemetry events through callbacks. In ACE 12 we revisited this design for improved performance and built in a solution of our own for emitting OpenTelemetry traces which removed the need for the exit. This OpenTelemetry support allowed events to be emitted from the following message flow nodes:

• MQInput, MQOutput, MQReply, MQGet, MQPublication
• HTTPInput, HTTPReply, HTTPRequest, HTTPAsyncRequest, HTTPAsyncResponse
• RESTRequest, RESTAsyncRequest, RESTAsyncResponse
• SOAPInput, SOAPReply, SOAPRequest, SOAPAsyncRequest, SOAPAsyncResponse
• CallableInput, CallableReply, CallableFlowInvoke, CallableFlowAsyncInvoke, CallableFlowAsyncResponse

After this initial support we have revisited the OpenTelemetry topic with enhancements multiple times:

• In ACE 12.0.7.0 built-in OpenTelemetry tracing support was provided for Linux x86-64
• In ACE 12.0.8.0 built-in OpenTelemetry tracing support was extended for Windows and Linux zSeries
• In ACE 12.0.10.0 built-in OpenTelemetry tracing support was extended for AIX and pLinux
• In ACE 13.0.2.0 you can also carry a new Basic Auth security identity in the header of the OpenTelemetry messages which are propagated to an external OpenTelemetry Collector

In this latest release of ACE 13.0.4.0 we have now added OpenTelemetry support to the ACE Toolkit Kafka message flow nodes:

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 instead of passwords.  ACE 13.0.4.0 introduces support for using the OAuth2 standard when making outbound requests using either the REST Request message flow node or the HTTP Request message flow node. 

The REST Request node is associated with credentials of type rest. The HTTP Request node is associates with credentials of type http. When creating these credentials with ACE 13.0.3.0 or earlier versions, both of these credential types were limited to the following supported Authentication Types:

• apiKey: This Authentication type results in the credential defining an apiKey property
• basic: This Authentication type results in the credential defining a username property and a password property
• basicApiKey: This Authentication type results in the credential defining an apiKey property, a username property and a password property

From ACE 13.0.4.0, the supported authentication types for rest and http credentials have now been extended to also include:

• bearerToken: This Authentication type results in the credential defining a bearerToken property
• client: This Authentication type results in the credential defining a clientId property, and a clientSecret property
• oauth: This Authentication type results in the credential defining an accessToken property, a clientId property, a clientSecret property, and a refreshToken property
• oauthPassword: This Authentication type results in the credential defining an accessToken property, a clientId property, a clientSecret property, a refreshToken property, a username property and a password property

Aside from the credential itself (which is stored securely in an ACE vault, and then referred to by the ACE runtime when the message flow reaches the request node which is invoking the OAuth 2.0 secured service), the direct properties of the REST Request and HTTP Request message flow nodes have not needed to be changed in order to provide support for this feature. In the case of the REST Request node, security scheme configuration can be provided by the Open API document associated with the node. In the case of message flows using an HTTP Request node to communicate with HTTP endpoints that are secured using OAuth 2.0, we have added 6 new properties to the HTTP policy which are shown in the picture below:

ACE 13.0.4.0 declares new explicit support for version 5 of the MQTT protocol.  This feature does not require any direct change to the MQTT Publish message flow node or to the MQTT Subscribe message flow node. Internal changes have been made to the connector and then externalized through the MQTT Publish policy type and the MQTT Subscribe policy type. These policies have been extended with an additional property named MQTT Version. The potential values which you can use for this new property are as follows:

• MQTT Version = 3.1.1, 5
  • This is the default. This means try to establish a connection using version 3.1.1 and if unsuccessful then try version 5
• MQTT Version = 5, 3.1.1
  • This means try to establish a connection using version 5 and if unsuccessful then try version 3.1.1
• MQTT Version = 3.1.1
  • This means only try to establish a connection using version 3.1.1
• MQTT Version = 5 
  • This means only try to establish a connection using version 5

In the previous mod release of ACE, version ACE 13.0.3.0 we introduced a new implementation of our Embedded Global Cache, for sharing in-memory data between message flows deployed to different integration servers. Following this update, in 13.0.4.0 we have added a small enhancement to provide an upsert method which makes it slightly more convenient when inserting data into an existing map where in some circumstances the key for the data will already exist, and in other cases it will not.  Consider a very simple example message flow containing a JavaCompute node, which as part of its processing could include interactions with the Embedded Global Cache:

Within the JavaCompute node's java, with ACE 13.0.4.0 you can now utilize code like this: