Use the CallableInput node to split message flow processing. A message flow that contains a CallableInput node can be called by a message flow in another location.
You can split message flows so that you do processing in different locations, such as IBM® App Connect Enterprise and IBM App Connect on IBM Cloud. A calling flow processes information in one location, then calls another flow in another location. The calling flow includes either a CallableFlowInvoke node or a CallableFlowAsyncInvoke node, depending on whether the flow will be invoked synchronously or asynchronously. The node that you have included in the calling flow (the CallableFlowInvoke or CallableFlowAsyncInvoke node) calls a CallableInput node in a second (callable) flow.
When the message is processed by the callable flow, a CallableReply node returns message body and local environment folder data to either the CallableFlowInvoke node in the original flow (if a CallableFlowInvoke node was used to call the CallableInput node) or to the CallableFlowAsyncResponse node in a separate response flow (if a CallableFlowAsyncInvoke node was used to call the CallableInput node).
You specify an endpoint name on the CallableInput node of the callable flow. The CallableFlowInvoke or CallableFlowAsyncInvoke node calls the correct callable flow by specifying the application that contains the callable flow, and the endpoint name that is specified on the CallableInput node. Therefore, you must deploy all callable flows in applications.
Application and endpoint name pairs must be unique on a single integration server.
The CallableInput node is contained in the Callable Flow drawer of the palette, and is represented in the IBM App Connect Enterprise Toolkit by the following icon:
When you have put an instance of the CallableInput node into a message flow, you can configure it; see Configuring a message flow node. The properties of the node are displayed in the Properties view. All mandatory properties for which you must enter a value (those that do not have a default value defined) are marked with an asterisk.
Terminal | Description |
---|---|
Failure | The output terminal to which the message is routed if a failure is detected during processing. |
Out | The output terminal to which the compound message is routed when processing completes successfully. |
Catch | The output terminal to which the message is routed if an exception is thrown downstream and then caught by this node. |
The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value when no default is defined); the column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).
Property | M | C | Default | Description |
---|---|---|---|---|
Node name | No | No | The node type (CallableInput) | The name of the node. |
Short Description | No | No | A brief description of the node. | |
Long Description | No | No | Text that describes the purpose of the node in the message flow. |
Property | M | C | Default | Description |
---|---|---|---|---|
Endpoint name | Yes | No | A name that identifies the callable message
flow. A CallableFlowInvoke or CallableFlowAsyncInvoke node uses this name to call this message flow. This name is case sensitive and must match the Target Endpoint Name property of the CallableFlowInvoke or CallableFlowAsyncInvoke node. |
Property | M | C | Default | Description |
---|---|---|---|---|
Events | No | No | None | Events that you have defined for the node are displayed on this tab. By
default, no monitoring events are defined on any node in a message flow. Use
Add, Edit, and Delete to
create, change or delete monitoring events for the node. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |