---
id: flow--entry-point
title: "Plugin port"
summary: "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."
audience: user
keywords: "request, response, initialize, enablevisitorsupport"
---
# 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

```json
{ "EnableVisitorSupport": false }
```

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

Calling flow: Http listener → *published plugin* → Http response