Pipe client

Calls a Pipe listener in another flow: every input record is sent to the selected listener over a local TCP pipe, and the listener's response (for two-way listeners) is emitted on Output. Use it to split logic into reusable flows (sub-flow / service style calls) on the same machine.

Pins

Pin	Kind	Types	Description
Input	input	listener's request type	Data sent as the request. The type is set when you pick the listener.
Output	output	listener's response type	Response of a two-way listener, with the caller's metadata.
Timeout	timeout	same as input	Called with the input data when no response arrived within Timeout.

Configuration

Field	Type	Default	Description
Name	flow port explorer (max 512)		The listener to call, shown as <flow name>/<port name>. Pick it with the explorer button (see Pairing).
FlowId	string (hidden)		Id of the flow that contains the listener. Filled by the explorer.
PortName	string (hidden)		Name of the Pipe listener in that flow. Filled by the explorer.
StartFlow	boolean	true	Intended: start the listener's flow if it is not running (see Notes).
IsAsynchronous	boolean	false	false: the call blocks until the response arrives. true: the call returns after the listener acknowledged the request; the response is emitted on Output later.
Timeout	integer (seconds, max 86400)	60	Maximum time to wait for the response. 0 = one day.
RetryCount	integer (optional, max 1024)	0	Number of attempts. 0 or empty means one attempt.
MaxParallelRequests	integer	1024	Maximum number of outstanding requests on the pipe.

Pairing

• The flow port explorer lists all Pipe listeners of the repository. Selecting one stores Name = <flow name>/<port name>, FlowId = the listener's flow id and PortName = the listener's Name.
• It also imports the listener's request and response types into this flow (as locked types) and sets them as the Input and Output pin types. Re-select the listener when its types change.
• At runtime only FlowId + PortName are used: the client asks the environment for the port registered as <FlowId>/<PortName>, which the listener registers when it starts. If the listener is renamed, pick it again.

Behaviour

• The pipe connection is created on the first record and reused; it reconnects automatically after a disconnect (heartbeat every 5 s).
• Synchronous (IsAsynchronous = false): the request is sent and the component waits. A two-way listener's response is emitted on Output with the original metadata (only when Output is connected); a one-way listener only acknowledges, nothing is emitted.
• Asynchronous (IsAsynchronous = true): the call finishes after the acknowledgement; the response is emitted on Output when it arrives, with a copy of the request's metadata.
• Correlation and session id of the metadata are passed to the listener's flow.
• An exception in the listener's flow comes back as an exception of this component.
• On timeout: if Timeout is connected it receives the input; otherwise an exception is thrown. In asynchronous mode a missing response also ends on Timeout (or as a recoverable exception).
• Not connected: waits 1 s and retries up to RetryCount attempts, then throws "The pipe client failed to send request".

Notes

• StartFlow is ignored: the runtime always asks the environment to start the target flow if it is not running.
• Synchronous timeout with Timeout connected: the Timeout pin is called once per attempt, and after the last attempt an exception "failed to send request" is still thrown.
• Timeout and MaxParallelRequests are taken when the pipe is first created; changing them needs a flow restart.
• Pipes use the loopback address: both flows must run on the same machine.
• A two-way listener whose flow never reaches its Response pin for a request leaves the caller waiting until Timeout.

Example

{ "Name": "Customer service/GetCustomer", "IsAsynchronous": false, "Timeout": 30, "RetryCount": 3 }

Http listener → Pipe client (→ Pipe listener "GetCustomer" in flow "Customer service") → Http response