Publish a flow as a plugin

Build a piece of logic once as a flow and use it in other flows as a single component. A published flow appears in the toolbox next to the built-in plugins, with its own name, icon, category and configuration fields. Typical uses: a "Create customer" step that wraps several API calls, a lookup against a reference system, a company-wide way to send notifications.

How it works

The flow you publish starts at a Plugin port component.

• What a calling flow sends to the published component's Input pin comes out of the Plugin port's Request pin.
• What your flow sends to the Plugin port's Response pin, or to a Plugin port response component, comes out of the published component's Output pin in the calling flow.

The call is synchronous: the calling component waits until your flow has sent the response. Each request is answered once.

Calling flow:   Http listener → [Create customer] → Http response

Published flow: Plugin port (Request) → Data mapper → Http client → Data mapper → Plugin port (Response)

Build the flow

1. Give the flow its own namespace. A published flow can't use the default namespace viauser. Pick one that names your organisation and area, such as Acme.Crm.
2. Add one Plugin port. A flow can be published with exactly one.
3. Connect the request. Connect the Plugin port's Request pin to the first component of your logic. The type on this connection becomes the type of the published component's Input pin.
4. Send the response. Connect the end of your logic to the Plugin port's Response pin. When the answer is produced in several places, for example in a success branch and an error branch, place a Plugin port response component in each place instead of drawing every connection back to the Plugin port. All responses must use the same type; it becomes the type of the Output pin.
5. Add configuration fields. Every property you add to the flow's configuration becomes a field of the published plugin, with the same name, type, default value and validation. When a calling flow starts, the values set on the component are copied into these properties, so your flow reads them like any other flow setting.
6. Describe it. The flow's Description becomes the plugin's description in the toolbox.

A Plugin port only emits requests when the flow runs as a plugin inside another flow. To test it, publish it and call it from a small test flow.

Publish

Open the flow and click Publish flow in the designer toolbar. The flow is validated first; fix any errors it reports. The Publish flow dialog has four pages:

Page	Fields
Plugin	Plugin name, the name in the toolbox. Config name, the name of the configuration class generated from your flow's configuration properties, or No config when the plugin has no fields of its own. Package name, the name of the built assembly. Category, the toolbox group the plugin appears in. Major, Minor, Build and Revision version.
Types	The flow types other flows may use once the plugin is installed, for example the types of the request and response fields.
Vendor	Name, Author and Email, shown in the plugin information.
Icon	An SVG file dropped onto the page, one of the Predefined icons, or SVG source pasted in. Without one, the plugin gets a default icon.

Click Publish. Viaducta compiles the flow in release mode, packs it with its types and dependencies, and adds it to the plugin repository. Every designer of your tenant gets the plugin in its toolbox at once, under the category you chose, and the plugin is available in all environments of the tenant.

The dialog remembers what you entered, so the next publish of the same flow starts with the same values.

Use it

Drag the plugin from the toolbox into a flow like any other component. Connect its Input and Output pins, and fill in its configuration fields; expression settings and bindings work as for every other component.

Update it

Change the flow and publish it again with a higher version. The new version replaces the old one in the toolbox, and earlier versions stay in the plugin repository.

Each component chooses which version it runs, in the Version row of its properties:

• Always use latest version of the plugin: the component runs the newest version each time its flow is compiled and started. New components get this setting while the flow's Use latest plugin versions (auto update) option is on, which is the default.
• Always use specific version of the plugin: the component stays on the version you pick from the list.

A running flow picks up a new version the next time it is started.

Delete it

Plugins published by your tenant show a delete icon in the toolbox. Deleting removes every version of the plugin, including the versions flows still use, so check first that no flow needs it.

Things to know

• No timeout. A request your flow never answers produces no output on the calling side. Make sure every path ends in a response, or in an error that goes back to the caller.
• Push events to the caller. A record that reaches the Plugin port's Response pin without a request, for example from a Timer inside the published flow, comes out of the caller's Output pin with fresh metadata. Use this for plugins that report events on their own.
• Metadata. The published flow gets new metadata for each request, with the caller's correlation and session id. The response returns to the caller with the caller's original metadata.
• Other ways to combine flows. Start flow starts another flow without passing data, and Pipe client / Pipe listener send records to a flow that is already running. See Flows calling flows.