Publish a workflow

Introduction

A workflow can be used to perform analyses only if it is published in a runtime. Publishing makes the workflow a program that the runtime will execute in response to NL Flow API calls or test calls.

A workflow which is already published can be re-published after changes to its definition has been saved, to reflect the changes, without the need to unpublish it: the procedure is the same as described below.
Re-publishing instead of unpublishing and publishing again is advisable, because NL Flow smartly tries to keep the workflow available to users, based on the type of changes made.
If, for example, the change consists in increasing or decreasing the number of replicas for one or more blocks, NL Flow will turn on the additional replicas and turn off the excess ones, without turning off the others, which will thus allow the workflow to remain responsive during the operation, without disrupting the service.

Start the wizard

You publish a workflow with a wizard.
To start the publishing wizard:

Open the workflow's workspace, select Publish or Async on the main toolbar at the top right of the page.
The presence of Async instead of Publish means that, due to the version of some block (for example version 2.0.0 of a JavaScript Interpreter block), the workflow can only be published in asynchronous mode.

Or:

In the Runtimes view of the dashboard, select a connected runtime—it's status icon must be green—from the list on the left then:
- Select Publish a new workflow on the right panel.
Or:
- Select a workflow from the list in central section of the page and select Republish workflow on the right panel.

The wizard consists of two or four steps, depending on whether the publishing mode is synchronous or asynchronous.

To cancel the wizard at any step select Cancel.
To go back to the previous step select Back.

First step

In the first step of the wizard you define:

The workflow to publish.
The runtime to publish in.
Any API keys to associate with the publication.

Depending on how you started the wizard, the workflow may already be set and not editable, otherwise choose it from the Workflows drop-down list.

Again depending on how you started the wizard, the runtime may already be set, but you can always choose another one from the Runtime drop-down list.

The optional API keys can also be pre-set when NL Flow "remembers" the keys that were associated with the workflow during a previous publication in the same runtime, but you can add, change or remove them freely.

To use a published workflow through its API, one or more API keys must be associated with the workflow at publication time: in each request to the API, in fact, the value of one of these API keys must be specified for authentication purposes. However, it is possible to publish a workflow without associating API keys to it: interactively testing the workflow will still be possible.

To associate an existing API key to the workflow:
1. Select Add API key: a new drop-down list appears, showing available API keys.
2. If you want to filter the list, type something in the field and the list will show only API keys with matching names. Clear the field to cancel the filter and see all the keys again.
3. Select an API key from the list.
4. Repeat from step a to link more keys.
To remove the association with an API key, select Remove to the right of the key.
To change an associated key, click its name. All API keys, if any, whose name contains that of the pre-selected key will be shown in a drop-down list, with the current key marked with a check mark.
To see additional API keys, edit the key name: all keys whose name contains what you type will be listed. If you remove all characters, all the API keys will be listed.
To make the change, select the new API key from the list.
To create a new API key and link it to the workflow, select Create new API key and do as described in the article about key creation.

When done select Next to move on to the second step of the wizard.

Second step

In the second step you have to choose the publication mode between synchronous and asynchronous.

In synchronous mode the workflow responds to the caller only when the analysis is complete and the response contains the results: the caller remains "stuck" and cannot do anything else for the entire duration of the analysis.
In asynchronous mode, instead, analysis requests create analysis tasks.
The caller immediately gets a task ID instead of the analysis results and can do something else.
The analysis task is queued by NL Flow and taken in consideration only after all the other previously queued tasks for the same workflow have been processed.
When, eventually, the task is submitted to the workflow, its results are cached: to obtain them, the caller must inquire the workflow about the status of the task and, if completed, request its results.

The mode is already set if it is a published workflow or one whose previous publication NL Flow remembers. You can however change the choice.

The dialog of the second step also shows how much of the overall capacity of the NL Flow runtime is already allocated to other published workflows and—in brackets and with an accent color—the allocation increase (or decrease) that the publication would cause.
As mentioned in the introduction, a published workflow is a program and, like any computer program, it needs computational resources (CPU, RAM) to run.
The maximum amount of CPU and RAM needed by a block of the workflow, depending on the component type, can be negligible or that declared in the deployment properties of the block multiplied by the number of replicas (see for the example the deployment properties of model blocks).
The maximum amount of CPU and RAM required by the whole workflow is therefore the sum of the requirements of all its blocks plus, but only in the case of asynchronous mode, a fixed amount, the so called "async weight". This entire amount of resources must be available inside the runtime in order to publish the workflow, even if, in the case of asynchronous publication with autoscaling (see below), it is possible that not all of the resources are allocated at publication time.
The NL flow runtime also imposes limits on the number of workflows published and the number of JavaScript Interpreter blocks used.
An asynchronous workflow can, if chosen by the user, be subject to autoscaling.
With autoscaling, the replicas of workflows' building blocks (for those components that allow for replication) are dynamically turned on and off based on the status of the task queue in order to spare computational resources. Find more information about this in the article about autoscaling parameters.

If there are not enough resources for publishing, a warning appears and it is not possible to proceed, the operation must be cancelled.

If you choose synchronous mode, this is the last step of the wizard and just choose Publish workflow to start the publication process, otherwise select Next to go to the third step of the wizard.

Third step

This step is exclusive of asynchronous mode publication.

In the third step you have to check or change:

The retry policies.
The overall workflow timeout.

When done select Next to go to the fourth step of the wizard.

Fourth step

This step, as the previous, is exclusive of asynchronous mode publication.

In this step you have to check or change the autoscaling parameters of the workflow.

When done, select Publish workflow to start the publication process.