Integration
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 (https://ideas.ibm.com).
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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
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
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 - bthomps@uk.ibm.com) Best Regards!