A message flow can call another flow directly. You can deploy both flows to IBM® Integration Bus or to IBM Integration Bus on Cloud. You can also deploy one flow to IBM Integration Bus and one flow to IBM Integration Bus on Cloud.
A message flow can complete many different actions. If any of those actions are labor-intensive, you can split them from the main flow and complete them somewhere else. Callable flows also facilitate reuse because they can be called by multiple message flows. You can split your flows between different applications in the same integration server, or between different integrations servers, which can also be in different integration nodes. Your callable flows must be in applications. You cannot deploy callable flows in libraries or integration projects.
Some parts of a message flow might logically belong in a specific location. For example, if your flow queries an on-premises database, performance is better if that part of the flow remains on premises. But if part of your flow queries a website multiple times, performance might be improved by running that part of the flow in the cloud. You can call the cloud-based flow from your on-premises flow, and the flow in the cloud does not use any of your on-premises resources.
If your callable flows are both deployed to IBM Integration Bus, or both deployed to IBM Integration Bus on Cloud, they can communicate with each other as soon as you deploy them. You do not need to set up communication between them.
If you are splitting processing between different integration servers, or between IBM Integration Bus and IBM Integration Bus on Cloud, your flows communicate by using a Switch server and connectivity agents. The Switch server is a special type of integration server that routes data. You cannot deploy anything to the Switch server. The connectivity agents contain the certificates that your flows require to communicate securely with the Switch server. The connectivity agents must be running in the integration servers where you have deployed your on-premises message flows. To start the agents, and to ensure that they are using the correct certificates to communicate securely with your cloud-based flow, you run the mqsichangeproperties command for each integration server.
You can split flows into multiple callable flows. However, for simplicity, this topic assumes that you are using two flows only: a calling flow and a callable flow.
A message flow in an IBM Integration Bus integration server calls a message flow in the same integration server, but in a different application. For this scenario, you do not need to set up a connection agent. This scenario is supported on all operating systems.
A message flow in an IBM Integration Bus integration server calls a message flow in a different integration server.
If your flows are split between different integration servers in IBM Integration Bus, you must run a command that creates some configuration files. You use one of the configuration files to create the Switch server, and the other file to configure connectivity agents for each integration server. This scenario is supported on Windows and Linux only.
A message flow in IBM Integration Bus calls a message flow in IBM Integration Bus on Cloud, or a message flow in IBM Integration Bus on Cloud calls a message flow in IBM Integration Bus.
If your flows are split between IBM Integration Bus and IBM Integration Bus on Cloud, the Switch server is managed by IBM Integration Bus on Cloud. You download a file from the cloud that configures an on-premises connectivity agent. This scenario is supported on Windows and Linux only.
This scenario is described in detail in Callable message flows in the IBM Integration Bus on Cloud product documentation.
When you decide how to split your message flow processing, create your message flows. The calling flow includes a CallableFlowInvoke node, which calls a CallableInput node in a second (callable) flow. When the message is processed by the callable flow, a CallableReply node returns information to the CallableFlowInvoke node in the calling flow. The calling flow uses a combination of the application name and the endpoint name of the CallableInput node to identify which callable flow to call.
The CallableFlowInvoke node parses the incoming message in full so that it is in a suitable format to send to the CallableInput node. Therefore, you should validate the message before it reaches the CallableFlowInvoke node. If the message fails validation at this point, it can be rolled back.
Multiple message flows can call the same callable flow. Therefore, your callable flow might complete a set of actions that are common to multiple flows.
You can add multiple CallableFlowInvoke nodes to a message flow. You can also include CallableFlowInvoke nodes in your callable flows. Application and endpoint name pairs must be unique on a single integration server. You can have multiple callable flows that have the same application and endpoint names, but they must be in different integration servers. In this case, the Switch server acts as a load balancer.
After you develop your message flows, you package the containing applications into BAR files and deploy them to the appropriate locations. If the flow accesses on-premises resources, deploy its BAR file on premises. If the flow will run in the cloud, upload its BAR file to IBM Integration Bus on Cloud.
When the calling flow receives an input message, the CallableFlowInvoke node uses the application name and the Endpoint Name on the CallableInput node to identify and start the callable flow.
The Callable Flows tutorial in the Tutorials Gallery demonstrates how to use the callable flow nodes to split processing between flows. In the IBM Integration Toolkit, click , then select Callable Flows.
For detailed information about how to configure callable message flows, see Splitting the processing of message flows.