Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Functionality already exists
Workspace App Connect
Created by Guest
Created on Nov 9, 2023

Callable flows from designer to enterprise to set message properties, so message body can be returned

As discussed in the case number TS014404341, when using a callable flow node from an app connect designer instance, the message properties are not set in ACE, as they are when using a callable flow node from ACE to ACE.

This causes the message body to always be returned empty whenever you use this callable flow, unless you manually set these values within the ACE flow, which will of course lead to worse integration design. Especially if an ACE flow needs to be called by different callable flow nodes, one from designer needing to manually override these values, one from ACE which sets these values themselves as needed.

Because of this reason, I would like to have an update that makes the callable flows set message properties sufficiently so that designer can receive the message body that the callable flow returns from ACE.

Idea priority Medium
  • Guest
    Jan 9, 2024

    Hi Ben,

    Your explanation is satisfactory.

    It seems that most likely my issue was then a configuration error that we could not figure out in the support ticket.

    I was only using it to internally have a knowledge base of the software, so we are not looking to delve deeper in the issue I had at the moment as you and your collegues did not encounter the issue.

    Kind regards,

    Wannes Vande Cauter

  • Admin
    Ben Thompson
    Jan 5, 2024

    Idea review. Thank you for taking the time to raise this suggestion. I have gone through the case which was raised with our Service channel which resulted in this enhancement request being opened, and have also run some tests involving a Designer flow running on ACEaaS on AWS invoking an ACE Toolkit flow running in a node-owned integration server on-premise (on my Windows laptop), and I was able to show data successfully being passed between the two flows. It appears that there may be some confusion relating to the Properties folder which ACE Toolkit users will be familiar with, and whether or not it is required in these kind of scenarios. The properties folder is a Toolkit / ACE integration server runtime concept which is not required by a Designer flow author (as opposed to the more specialist Toolkit flow author), and for this reason the Properties folder is not exposed in the Designer programming model, and it is not shown in the Designer authoring UI, and furthermore it is not needed when successfully integrating callable flows between Designer and Toolkit. I will expand on these points below with some screenshots in order to fully explain but for these reasons, we are closing this idea request with the status "Functionality already exists" because it is already possible to fully integrate the two flow types without need for specifying bespoke values in the properties folder. Two separate examples are shown below:

    1. The first example involves invoking the Toolkit Callable flow from the Designer Callable Flow Invoke node but not passing any data in to the Toolkit flow. In my examples I utilized a Designer REST API flow ... I chose to use a REST API as opposed to an Event driven flow just for testing convenience ... this does not influence the validity of these examples which would be equally achievable from a Designer event driven flow too.

    2. The second example involves invoking the Toolkit Callable flow from the Designer Callable Flow Invoke node but also passes a data structure which has a field named "NewField".

    In both examples, the Toolkit Callable flow, when invoked, has a graphical mapping node whose purpose is to add two fields to the message ... "timestamp" is injected with the current time value ... and "called_messageflow" is injected with the name of the Toolkit message flow. In both cases, the Designer flow can get access to these values which were created in the Toolkit flow. In my example, I log the message which is returned from the Toolkit flow to the Designer flow using a Designer Log node (pictures attached show the log entry and the layout of the Designer flow). After the log node, I also used a JSONParse node to pick out one of the fields (carrying the name of the Toolkit message flow) which I then returned to the initial client which invoked the Designer REST API.

    The screenshots attached show that if Designer invokes Toolkit flow without specifying a message body, then no Properties folder is created ... but Toolkit can still create and return the message body (JSON in this example) back to the Designer flow ... and the screenshot also shows that if Designer invokes Toolkit flow by passing an input message body, then a largely empty Properties folder is created in addition to a message body (JSON in this example) ... which the Toolkit flow subsequently adds fields into, and returns successfully back to the Designer flow.

    In conclusion then, the Properties folder's existence or otherwise does not influence the Toolkit message flow's ability to send data back to Designer, nor does it stop Designer being able to parse the JSON reply and use it downstream in the Designer message flow.

    Hopefully this explanation makes sense and resolves any lingering doubts about the scenario, but if we have misunderstood anything or if you would like to discuss further please feel free to reach out to us either through RFE or through a direct email to me (Ben Thompson - Best Regards!