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.

After changes to the workflow design that are ready to be made available to the final users, the workflow can be published even if already published. This re-publish procedure is the same as described below. During it the blocks of the old version of the workflow are kept up & running until the new are ready, then they are shut down. This is better and faster than unpublishing the workflow and publishing it again.

Start the wizard

You publish—or re-publish—a workflow using a wizard.
To start the 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 choose:

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

Depending on where you started the wizard from, the workflow may already be determined, otherwise choose it from the Workflows drop-down list.

Again, depending on where you started the wizard from, the runtime may already be selected, but you can always choose another one from the Runtime drop-down list. For each runtime the list shows:

The runtime icon in the runtime item's identifying color.
The name of the runtime item.
The publishing modes (synchronous, asynchronous) that the runtime supports and, for asynchronous mode, the possible support for autoscaling, which allows publishing in Eco and Sport modes.
The core features that the runtime provides.

Runtimes that are incompatible with the workflow because they do not support the requested publishing mode or do not have all the core features required by the workflow blocks, are grayed out and cannot be selected.
To find the exact issues with a grayed out runtime, hover over the lines showing its characteristics: tooltips will appear, showing the missing capabilities.

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 of the publishing wizard you:

See the amount of computational resources required by the workflow and whether the runtime has sufficient capacity.
See if the publication is going to exceed some other limit of the runtime, such as the maximum number of workflows.
If the runtime has sufficient capacity to host the workflow, see or choose the publishing mode, between synchronous and asynchronous.

As mentioned in the introduction, a published workflow is a program and, like any computer program, it needs computational resources, that is CPU and 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, in the case of asynchronous mode, the amount due to shared services. This entire quantity of resources must be available inside the runtime at publish time even if, in the case of asynchronous publication with autoscaling, it is possible that not all of the resources are allocated immediately. With autoscaling, in fact, the replicas of workflows' building blocks that allow for replication are dynamically turned on and off based on the "pressure", that is the amount or queued analysis tasks or their submission frequency. This allows the workflow to become more powerful to meet high demand and to automatically reduce its footprint when less used. Find more information about this in the article about autoscaling parameters.
Every runtime also has other two limits: the maximum number of workflows in can host and the overall, maximum number of JavaScript Interpreter blocks that can be used in synchronous workflows.

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 pre-set if the workflow is already published and you are publishing a new version of it or set to asynchronous and not modifiable if the workflow uses components that are only compatible with asynchronous mode.

In case of synchronous mode, this is the last step of the wizard, so 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.