Plugin port

The entry point of a flow that is published as a plugin ("flow as plugin"). Other flows then use the published flow like any other component: what they send to its Input pin comes out of Request here, and what this flow sends to Response (or to a Plugin port response component) comes out of the component's Output pin in the calling flow.

Pins

Pin	Kind	Types	Description
Request	output	the type of its outgoing connection	Emits each request sent by the calling flow. The type on the (first) outgoing connection becomes the request type, i.e. the Input type of the published plugin.
Response	input	any	The reply for the calling flow. Its type becomes the Output type of the published plugin.
Initialize	continue	same as input	Called once when the plugin flow starts inside a calling flow (see Behaviour).

Configuration

Field	Type	Default	Description
EnableVisitorSupport	boolean	false	When true, the generated plugin declares visitor support and answers "can handle" for every record, so the calling flow delivers records to it through the visitor routing instead of by connection type.

Behaviour

• Publishing: a flow with exactly one Plugin port can be published as a plugin. The flow must use its own namespace (not the default one), all responses (Response pin and Plugin port response components) must use one type, and the version needs four numeric parts. The configuration class selected when publishing becomes the plugin's configuration; when the plugin starts, its configuration values are copied into the flow configuration properties with the same names.
• Request: when the calling flow sends a record to the plugin's Input, a new metadata instance is created for this flow (only CorrelationId and SessionId are taken over) with an EntryPoint entry (Viaducta.Plugins.EntryPoint.EntryPointMetaData: BridgeKey, RequestId) that identifies the request. The record is emitted on Request.
• Response: a record arriving at Response with that metadata is converted to the plugin's output type and emitted on the calling component's Output, together with the caller's original metadata. Each request can be answered once.
• A record arriving at Response without request metadata (for example produced by a Timer inside the plugin flow) is emitted on the calling component's Output with fresh metadata. This lets a plugin flow push events to its caller.
• Initialize: at start the system calls unconnected input pins; when Response has no incoming connection (responses are sent with Plugin port response components), this call fires Initialize once.
• The whole path is synchronous: the caller's component waits while the plugin flow processes the request up to the point where the response is sent.

Notes

• The Plugin port only works when the flow runs as a plugin inside another flow. When you start the flow on its own, nothing is emitted on Request and responses are ignored; test the logic through a calling flow.
• This is not the mechanism of Start flow or Sync call: Start flow only starts another deployed flow by id (no data in or out), and Sync call only orders two branches of the same flow (Output first, then Continue). Use a published flow plugin when you need to pass data to another flow and get a reply.
• A request that never reaches a response produces no output in the calling flow (no timeout).
• Use Plugin port response components to send responses from several places of the flow.

Example

{ "EnableVisitorSupport": false }

Plugin flow: Plugin port Request → Database reader → Data mapper → Plugin port Response

Calling flow: Http listener → published plugin → Http response