Introduction
Workflows are processes linked together: one triggers the next according to the defined steps in the workflow configuration.
Workflows can be simple (example) or perform very complicated actions. For example, the checkout for shoppings cart or installation in deployment use workflows. The same can be done by hand, but it would require a lot of navigation, button clicking, and user interaction – that’s when a workflow comes in handy.
Workflows work similarly to processes in Architect: they can have input parameters, decision steps, etc., but there are differences. Any workflow exists and is configured in the application, not in a component.
You can read how to run a workflow in this post, but first you need to create a workflow configuration. Let’s get started!
To start with a workflow
Add a component M3046. It is required to create and run a workflow, but there are also many optional components that allow to configure and start workflows for the specific record type. For example:
Check the appserver > search for “Novulo Worflows bij” + the data model name.
Workflow configuration
A workflow configuration consists of:
- settings on the configuration page;
- workflow steps;
- transitions.
The optimal way to prepare a workflow configuration is:
- define the steps: what so you want to do in your workflow? Which values to cache, which record(s) to add/edit, which buttons/inputs to show for a user to click/fill in?
- define the initial transition (from None to the first step) and, if needed, workflow parameters;
- starting to link steps to each other: from the initial transition > to the next step > via outgoing transition > to the next step, etc.
- define where/when the workflow must stop and add outgoing transition(s) to None.
Settings on the configuration page
When the needed component(s) is/are added > go to Settings > Workflow configurations > fill in the form:
- Description,
- Active,
- Requires initial state > checkbox allows you to add workflow parameter(s) to the configuration, which must be filled in at the start of a workflow,
- Start in foreground,
- Default error handling > if you want to use generic error handling, you need to add and configure the “Error step” > set “Default error handling” to true > choose the “Error step” in the drop-down,
- Run in specific queue > name a queue from the scheduled task
Workflow parameters
This grid is visible when you set the checkbox “Requires initial state” = yes. Here, you can define input parameters that you need to run your workflow. They are similar to the input parameters at the “Start” of an Architect process. Workflow parameters can be required or optional, and are passed to the workflow before starting it.
Workflow steps
They are processes that are performed while running a workflow. Steps have a Step type. There are four of them:
- User interaction,
- Process call,
- Wait for a data trigger,
- Preserve record in state.
User interaction step type
A step with a User interaction type will interact with a user: asks a question (= show the field to fill in), shows a button, etc.
As soon as you choose a User interaction step type (1) > Questions and Buttons grids will appear.
Check Questions (2):
- internal name (3),
- data type (4) > what kind of input you are waiting for,
- mark as (not) required (5).
Check Buttons (1):
- internal name (2),
- button label (3),
- visibility condition (4).
Process call step type
The process call step type triggers a process that is set in the process call field. The search link shows the list of all “Process action definitions”.
Check here how to add a process action definition.
For example, you might want to add a new activity. So you created a process action definition to add/edit a record and clicked “Determine parameter and return values”:
So now in your workflow configuration you can add a step with type “Process call” and choose the needed process action definition among options.
As soon as you choose a process call, its parameters will appear. They are the inputs for the process.
In our example the record in the parameters must be activities:getnull(). This means “add a record with the data type = activities, and this record doesn’t exist yet (= null)”.
While adding a new activity you might want to set a description. This field (= property, column) exists for the activities table. You can always can check the available fields and their data types via the data model button at the Expression debugger).
Notice! Be very attentive to the values you set as parameters. If you add or edit a record for example, the parameters must exactly match the field names this specific record.
Expression syntax
In the example “date” refers to the property of an activity record and the Novulo expression fills it in with the valid data type.
If you want to update several properties, use this format: [ <“key1”,“value1”>,<“key2”,“value2”> ]
Note: Parameters are case sensitive!
Read more about the expression syntax in the Novulo expressions post > jump to the Syntax chapter in the table of contents.
Wait for data trigger step type
This step is basically the data process. As soon as you set this step type > the form “data change specification” appear where you define a record and operation type to “listen to”: update a product, insert a user, etc.
In the example below the workflow checks if the the first product with the “Kate” in the name is updated:
Preserve record in state step type
This step type requires an expression: what record to preserve.
Transitions
Every step of every type requires transitions: incoming and outgoing. The workflow itself needs an initial transition.
Every transition has fields “From” and “To”: from which step to which step to go.
The first (initial) transition starts from “None” (means “beginning”) to chosen process. The last (outgoing) transition in the worflow go to “None” (means “stop”).
Message field in not required, but could be helpful. It shows text inside the worflow form while running the process. (For example, while deploying > “Finish in the installer”).
If you click on the step (1) > you will be redirected to this step (2) and see incoming transitions (3) (from where your step is triggered and what is the condition = expression (4)). Below the incoming transitions is the outgoing transitions grid.
Notice that while the incoming transitions are not defined for a step, you context is limited: you can reach this.workflow record (parent) only. But as soon as you add a transition, an incoming record is available withing the process.
For example, in the step edit_activity you get add_activity as an incoming transition (1):
Then you can use this record within your step (for example, updates its description):
Outgoing transitions
In the “Outgoing transitions” inside a step you can define which step will be called next and what is a condition for it. A condition is set at the expression field, it is similar to the decision step in Architect:
If you set the expression = true > the step will always run; expression = false > never run. But it is better to think of what you want to happen and what if something doesn’t go according to your plan. If you use a user input, will you need an extra validation check? What happens if a user pushes the wrong button?
Example. For a long time in the installer were only 2 buttons: Yes or No (keep changes). As soon as a user pressed No, the workflow immediately threw the current database out and started to replace it with the backed-up one. It has been changed so now pressing No requires an explanation and cannot be performed by a No-click only.
If you add an outgoing transition “From” your current step “To” nothing, the workflow stops.
Notice! If the last step doesn’t have any outgoing transations > a workflow will return error.
You can add several outcoming transitions and set priority > it will define the order for running steps. Example below: first > check the user input date (and run this step if it meets the requirements), second > edit activity, third > finish the process if success = false.
Run a workflow
When the workflow configuration is ready, and can add a workflow and run it: How to run a workflow