Skip to content

Publish and unpublish workflows

Publishing

A workflow can be used to analyze documents only if it is published. Publishing makes the workflow a program ready to run on demand, which can be obtained 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 used programmatically through the API, while all can be tested 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 as synchronous or asynchronous. If synchronous, it responds to the caller only when the analysis is complete.
    If asynchronous, instead, the analysis requests are placed in a queue from which they are taken and submitted to the workflow as soon as it is available. The results are cached.
    When a caller submits an analysis request it gets a task ID instead of the analysis results. The analysis task is queued and carried out when the workflow becomes available, the results are cached. To obtain them, the caller must inquire about the status of the task and, when this is completed, request the cached results.
  • A published workflow, in order to work, needs computational resources (CPU, RAM) corresponding to the deployment properties of its building blocks (see for the example the deployment properties of model blocks).
    If multiple replicas are required for a block, the required resources will be those set as deployment properties multiplied by the number of replicas.
    All the computational resources required by a workflow must be available at the time of publication, even if, in the case of asynchronous publication with autoscaling (see below), it is possible that they are not allocated immediately. Also, the NL flow runtime imposes limits on the number of workflows published and the number of Javascript blocks used.
  • An asynchronous workflow can, if specified by the user, be subject to autoscaling.
    With autoscaling, all the replicas of the workflows's building blocks can be turned on and off dynamically depending on the workload, in order to spare computational resource. Find more information about this in the article about autoscaling parameters inside the reference section.

  • The publishing 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.

    • Gray dot: not published
    • Green dot: published synchronous workflow
    • Green dot surrounded by smaller dots: published asynchronous workflow
    • Yellow dot: synchronous workflow still in the publishing phase, but already usable because at least one replica of each building block is on
    • Orange dot: synchronous workflow being published and not yet usable

    Detail information about the publishing 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.

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.