Publish and unpublish workflows

Publishing

A workflow can be used to perform analyses only if it is published. Publishing makes the workflow a program ready to be executed either programmatically, using the NL Flow API, or interactively, with the test GUI.

You can publish the workflow you are working on from within the editor or you can publish one or more workflows from the Runtime view of the main dashboard.
Only workflows associated with at least one API key can be run programmatically through the API, while all workflows, regardless of key association, can be run in test mode from the GUI. Find more information about API keys and how to manage them in the description of the Runtime view of the main dashboard.
A workflow can be published in synchronous or asynchronous mode.

In synchronous mode it responds to the caller only when the analysis is complete and the response contains the results.

In asynchronous mode, instead, analysis requests create analysis tasks.
The caller (quickly) gets a task ID instead of the workflow's results. The analysis request is queued and processed after previously queued requests. Results are cached, so, to obtain them, the caller must inquire about the status of the analysis task and, when this is completed, request the results.
As mentioned above, 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 block 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 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.
NL flow runtime also imposes limits on the number of workflows published and the number of JavaScript 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.
The publication status of a workflow is represented by a colored dot in the (Workflows, Models and Runtime) views of the main dashboard and in the editor.

Detail information about the publication status can be obtained in the editor or via NL Flow API.
A published workflow can be edited and re-published without the need to unpublish it. The re-publishing procedure is the same as for publishing.

Publishing wizard

The publishing wizard starts when you choose to publish one or more workflows. The wizard consists of two or four steps, depending on whether the publishing mode is synchronous or asynchronous.

In the first step of the wizard you choose the workflows to publish and the associated API keys. The step differs based on the GUI control you start the operation from. See the article about the editor and that about the Runtime view to know about this step.

The next steps of the wizard are described below and are essentially the same regardless of the starting point.

Second step

In the second step you have to choose the publication mode between synchronous and asynchronous.
It also shows graphically 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.

Each published asynchronous workflow has an implicitly added block—the asynchronous queue manager—which requires extra resources equal to 250 thousandths of CPU and 256 MiB of RAM.
This extra increment is visualized as a bordered rectangle with diagonal lines.

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, or in the case of publication started from an API key with the choice of multiple workflows, Publish # workflow, where # is the number of workflows.

If you published your workflow in synchronous mode and you edit it with components that require an asynchronous publishing:

Unpublish the workflow.
Publish the workflow again.

Note

The same procedure must be followed in the opposite case.

If you skip step 1, a message in the Runtime load dialog will appear.

Select Unpublish now to unpublish the workflow and keep following the steps described in the page.

Third step

This and the next step of the wizard are only there if you publish the workflow in asynchronous mode.

In the third step the retry policies are configured.

Fourth step

In the fourth step the autoscaling parameters of the workflow are configured.

Unpublishing

Unpublishing renders a workflow unusable and frees up any computational resources that may have been allocated to it. If the workflow was published asynchronously, all queued tasks are dropped and must be canceled through the appropriate NL Flow API requests.

It is good practice to unpublish unused workflows in order to make more resources available for other workflows and, especially in the case of Cloud installations, to reduce costs and energy consumption.

An unpublished workflow is still defined and can be edited and republished if necessary.

To unpublish a workflow use the editor or the Workflows view of the dashboard.