Developing asynchronously callable message flows

To split processing asynchronously by using callable flows, first create a calling message flow that contains a CallableFlowAsyncInvoke node. Then create a callable message flow that contains CallableInput and CallableReply nodes. Finally, create a response message flow that contains a CallableFlowAsyncResponse node.

The following steps describe how to create a calling flow, a callable flow, and a response flow that can send information to each other.

1. In the IBM App Connect Enterprise Toolkit, create the calling message flow, which must include a CallableFlowAsyncInvoke node.

   The CallableFlowAsyncInvoke node parses the incoming message in full so that it is in a suitable format to send to the CallableInput node. Therefore, validate the message before it reaches the CallableFlowAsyncInvoke node. If the message fails validation at this point, it can be rolled back.

2. In a different application, create a callable message flow, which must begin with a CallableInput node, and contain a CallableReply node.

   A CallableFlowAsyncInvoke node calls a callable flow by referring to the endpoint name on the CallableInput node, and the application that contains the callable flow. Therefore, you must include all callable flows in applications.

3. On the CallableInput node of the callable flow, use the Endpoint Name property to provide a name for the callable flow.

   Application and endpoint name pairs must be unique on a single integration server. You can have multiple callable flows that share 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.

4. On the CallableInput node of the callable flow, edit the Supported Domains properties as described in CallableInput node.
   This step provides the option for incoming messages that are received by the CallableInput node to be rejected if they do not match the Supported Domains table entries. For more information, see Domain checking in callable message flows.
5. On the CallableReply node of the callable flow, edit the Supported Domains properties as described in CallableReply node.
   This step provides the option an exception to be thrown if response messages that are to be sent by the CallableReply node do not match the Supported Domains table entries. For more information, see Domain checking in callable message flows.
6. On the CallableFlowAsyncInvoke node of the calling flow, set the following properties:

   Table 1. CallableFlowAsyncInvoke node properties

   Property	Value
   Target Application	Set this property to the name of the application that contains the callable flow.
   Target Endpoint Name	Enter the name of the Endpoint Name property of the CallableInput node. This name is case-sensitive. The Target Endpoint Name must match the Endpoint Name of the CallableInput node exactly.
   Request timeout (sec)	Set the time within which the callable flow must be called, in seconds. If the callable flow is not called within the specified time, an error message is issued.
   Call Preference	If your main and callable flows are in the same integration server, set this property to Prefer local calls. If your flows are split between App Connect Enterprise and IBM App Connect Enterprise as a Service, set this property to Remote calls only.

7. In a different application, or in the same application that was used to create the calling flow in step 1, create a response message flow that starts with a CallableFlowAsyncResponse node.
8. Set the Unique identifier property of the CallableFlowAsyncResponse node to match the value that is set in the CallableFlowAsyncInvoke node that was created in step 1.
   You now have three separate message flows: a calling flow, a callable flow, and a response flow:

   
9. Package the applications that contain your calling and response message flows into a BAR file, and package the callable message flow into a separate BAR file.
10. Deploy the BAR files to the appropriate integration servers.

    If you are splitting processing between App Connect Enterprise and App Connect Enterprise as a Service, deploy one BAR file on premises and upload the other to the cloud. For more information about deploying BAR files to App Connect Enterprise as a Service, see Deploying integrations in the App Connect Enterprise as a Service documentation.