Outbound Flow Link Component
The Outbound Flow Link component can be used together with the Inbound Flow Link component to connect flows with each other. This enables you to split up bigger integrations in several reusable flows.
This component can be used multiple times in a flow to sent messages to other flows that have an Inbound Flow Link component.
Configuration
This component has the following configuration options:
Target flow
Description
When opening the properties modal all available target flows will be fetched. These are flows that start with an Inbound Flow Link component that has the same Transport. When they are fetched you can select the flow that you want to connect with.
Remarks
- The first flow in the list will be automatically set as the target flow.
- When the original target flow can't be targeted anymore then the target flow will be reset to the first flow of the list or become empty when there are no target flows. A warning message will show up below the input when this happens.
- If transport type is set on queues and the request-reply option is chosen, the own flow name will be hidden in list of flows.
Transport
Options
DefaultSynchronousAsynchronousQueues
Description
The transport mechanism used between flow steps (components). Default is the best setting in most cases.
| Transport | Queue | Explanation | Usage |
|---|---|---|---|
| Default | Yes | Uses queues between flows | Most cases |
| Synchronous | No | When you configure your flow to be synchronous, the output of the next flow will be used as a response to the first flow. | For synchronous (request/response) interactions. Especially to keep the message order. Note the calling flow must be running. |
| Asynchronous | Yes | When you configure your flow to be asynchronous, messages are stored an in-memory blocking queue between flows. | For asynchronous (fire-and-forget) interactions. Especially to increase performance. Note the calling flow must be running. |
| Queues | Yes | Same as default. All messages will pass through a queuing mechanism. This means that the messages are stored on a broker outside of the flow until the next flow has received and acknowledged it. | For synchronous (request/response) or asynchronous (fire-and-forget) interactions with large messages and guaranteed delivery. |
Remark
- If you are not familiar with how the different transport types work, we recommend you leave it at Default.
- You can't sent messages to an
Inbound Flow Link component that has a different
Transport. For example: a asynchronous Outbound Flow Link component can't send messages to a synchronous Inbound Flow Link component.
Exchange pattern
Options
One way(default)Request reply
Description
This option determines how the messages are sent to the connected flow. One way
means that for every messages that is sent there will be no response from the
connected flow. It can be compared with the term "fire and forget". This option
is recommended when you don't need the response from the connected flow in your
current flow, for example when you sent messages to your own logging solution.
Request reply is the opposite of the One way option. For every message that is
sent to the connected flow there will be a response message from the connected
flow. This option is recommended when you need the processed message in
your current flow.
Remarks
- For
Request replythe timeout option of the flow may need to be increased when the connected flow takes some time to process the messages. - The response to the caller will be the existing Exchange body before reaching the first
One waycomponent in the flow.
Remarks
- To see the full origin/target flow chain in the tracing, all connected flows should have tracing enabled.