Variables (workflows)
Each workflow has variables (as you know it from profiles). Available data types are String, Integer, Double, Date, Boolean, Float, BigDecimal, BigInteger, TimeStamp, Blob.
The context menu can be used to add, modify and delete workflow variables and to import variables from profiles and ETL entries.
User-defined workflow variables
These variables are created in the workflow by the user.
System workflow variables
These variables are (almost all) created and set by the workflow module itself when a workflow job is started.
Name |
Type |
Description |
VAR_AUTOSERIALIZE_DATA |
String |
Important note: Please follow the import instructions. (a) If you use the prefix autoserialize_ for maps or lists in a workflow transition function, these are automatically serialised. When accessing them in another transition afterwards, they are then automatically deserialized. (The variable does not have to be touched and only serves the internal mechanism.) Workflow_WF_automatic_serialize_deserialize.obj (b) You can also autoserialize in a workflow transition function and then autodeserialize in a workflow action profile. Profile-auto_deserialize_in_profile.pak Workflow_WF_serialize_action_profile.obj (c) You can also autoserialize in a workflow action profile and then autodeserialize in a workflow transition functions. Profile-auto_serialize_in_profile.pak Workflow_WF_deserialize_action_profile.obj (d) You can also autoserialize in a profile and then autodeserialize in a workflow started by the profile. Note: When calling functions start new workflow(), fire workflow-event(), add/set workflow variable() autoserialization is done immediately and not after phase 3, as is usually the case in profiles . |
VAR_SENDER |
String |
The Lobster Integration or DataCockpit (prefix "WebMonitor:") user who started the workflow job or filled in the last form. If the workflow job was started with function start new workflow(), the variable contains the name of the profile that used this function. |
VAR_SYS_WF_ACCESSLIST |
String |
If this variable exists and is filled, the set DataCockpit users/roles for access to a form are temporarily overwritten in all forms. You can specify DataCockpit roles (e.g. myRole) or DataCockpit users with the prefix WebMonitor: (e.g. WebMonitor:myUser). Multiple entries are separated with commas. Note: See also function change permission of workflow-form(). |
VAR_SYS_WF_ATTACHMENT_ACCESSLIST |
String |
If this variable exists and is filled, the set DataCockpit users/roles for access to attached files are temporarily overwritten in all forms. You can specify DataCockpit roles (e.g. myRole) or DataCockpit users with the prefix WebMonitor: (e.g. WebMonitor:myUser). Multiple entries are separated with commas. |
VAR_SYS_WF_DATA |
String |
Must be created. The content of this variable is used to provide input data to non-cron profiles in actions (see sections Transition, State, Finale Action), but only if variable VAR_SYS_WF_FILE does not provide any data. If this method does not return any data, an action error occurs. Important note: If a profile is supplied with data from this variable, the variable is emptied. It must therefore be filled again before another call. |
VAR_SYS_WF_DISPLAYNAME |
String |
The name of the workflow job. |
VAR_SYS_WF_FILE |
String |
Must be created. The variable needs to contain a path to a file. Example: ./webapps/root/upload/test.txt. See also section File upload. The content of this file is used to provide input data to non-cron profiles in actions (see sections Transition, State, Finale Action). If this method does not deliver any data, the method described for variable VAR_SYS_WF_DATA is tried. Important note: If a profile is supplied with data from this file, the file is deleted afterwards. |
VAR_SYS_WF_ID |
String |
The ID of the workflow job. |
VAR_SYS_WF_LINK |
String |
If the checkbox Enable HTTP agent is set in the Main Settings of the workflow, this variable contains the URL key of the workflow. Example: V0YtLTI4NDAyMTExMw. See details there. |
VAR_SYS_WF_STATE |
String |
The state in which the workflow job currently is. |
VAR_SYS_WF_TERMINATED |
Boolean |
If a workflow is terminated due to an exceeded waiting time in a state, this variable receives the value true. This is useful if a (local) final action is executed afterwards and therefore the workflow may still be running until this action is finished. Default: false. |
Concept of workflow variables
Workflow variables serve as a connecting data layer between workflows and profiles, other workflows, ETL entries and Content Inspectors. On the one hand, the variables of the workflow are automatically passed on to called profiles, ETL entries and other workflows. In addition, the variables of the workflow can be set with functions from there. More on this below.
Workflow variables are also used to communicate with state forms, i.e. to display values in the form or to pass data entered in the form to the workflow job. The variables can then be used in the conditions of transitions, for example, to control the course of the workflow.
Workflow variables in state forms
A form can be defined in each state of a workflow. In this form, you can define variable fields. These are input fields in the form whose content is linked to a workflow variable. I.e. on the one hand the field shows the value of the variable and on the other hand the variable takes over the entered value.
Passing/Returning workflow variables
In general, please make sure that the types of the variables are identical in all places, otherwise unwanted implicit type conversions may occur.
Passing workflow variables to other workflows
If a workflow calls another workflow, the called workflow takes over all values for variables with the same name (must be created explicitly). The values for the system workflow variables VAR_SYS_WF_ID, VAR_SYS_WF_LINK, VAR_SYS_WF_DISPLAYNAME and VAR_SYS_WF_STATE are not transferred.
Passing workflow variables to profiles
If a workflow calls a profile, variables of the same name with the prefix MSG_CALL_ in the profile take over the values of the workflow variables . Example: Workflow variable VAR_NEW_1 and profile variable MSG_CALL_VAR_NEW_1. Note: This also applies to data profiles in form profiles in state forms.
Passing workflow variables to ETL entries
If a workflow calls an ETL entry, the called ETL entry takes over all values for variables with the same name (must be created explicitly) if option Changeable at start is set for the corresponding ETL variables.
Returning workflow variables from other workflows/profiles/ETL entries
See function add/set workflow variable().
Handling in workflow transitions
See function add/set workflow variable().
Passing profile variables to workflows
If you start a workflow job from a profile with function start new workflow(), you can also pass variable values. All workflow variables having the same name as a profile variable are filled with the value of the corresponding profile variable. So if there is a profile variable VAR_NEW_1, the existing workflow variable VAR_NEW_1 will be filled with the value of the profile variable. Thus, no prefix MSG_CALL_ is necessary. Note: If you ever want to pass more complex data, take a look at the functions serialize map/list() and deserialize map/list() . In addition, it is possible to include lists and maps as nodes in the source structure of profiles. See section Source structure menu. This can be very useful in profile actions in transitions, especially when it comes to vertical integration. Note: A workflow can also be started via the error handling of a profile.
Autoserialized lists and maps
See workflow variable VAR_AUTOSERIALIZE_DATA above.