Transition (workflows)
The priority can control the order of the checked transitions in the transition check if there are multiple transitions. If a particular transition is checked or there is only one, the priority does not matter.
The first checked transition that has no conditions or whose conditions are fulfilled is executed. All others are not.
An executed transition can execute actions (waiting and non-waiting).
After that, the transition causes the workflow job to change from the current state into the subsequent state it is connected to.
If no transition with fulfilled conditions is found in the transition check, the workflow job remains in the current state.
Settings
(1) Language key: A language key can be specified here. If it is defined in the dictionary, its value (matching the language in which you logged in) is used instead of the name of the transition. The icon on the right can be used to select a key directly from the dictionary.
(2) Documentation URL: Here you can specify any URL that contains documentation of this transition, which can be called via the icon on the right. You can also insert system constants into the URL there.
(3) Priority: If several transitions originate from one state, the priority of those transitions can be used to control the check sequence. The transition with the highest priority is checked first.
(4) Set conditions, Edit functions: A checked transition is executed only if no conditions are specified or if the specified conditions are fulfilled. Note: Either the calculated value or a fixed value can be used as the result of each individual function.
(5) Retry after: This is a somewhat exotic setting option that you can ignore as a beginner. The setting only becomes visible when at least one function has been set in (4). In case this specific transition was triggered externally, e.g. with function fire workflow-event(), from this point on this transition (and no other) will be checked again cyclically (here every minute) until the workflow job is no longer in this state. An example can be found in section Profiles as Workflow Master .
(6) Actions : Actions to be executed (profiles, other workflows, ASM entries, ETL/ELT pipelines, Content Inspectors) if the check in (4) is successful.
If you use profiles, you have to distinguish between cron profiles ( time-driven ) and non-cron profiles ( event-driven ). For cron profiles, always set option Start cron profile via the context menu . This marks that the profile is only triggered and fetches its own data. Non-cron profiles get their input data from workflow variable VAR_SYS_WF_DATA or VAR_SYS_WF_FILE (see details there). If the variables do not supply any data, the profile generates an error.
Each action by itself can be executed only once, but any number of actions can be selected, i.e. a profile MyProfile can be selected only once, but further profiles can be added. The same applies to the other action types.
The actions are performed in order (from top to bottom). The next action starts when the previous one is finished.
A profile as action is considered finished when it has been processed or immediately if (7) is set. A workflow, ETL/ELT entry, ASM entry or Content Inspector as action is considered finished when it has been successfully started.
A profile as action is considered erroneous if it ended with an error. A workflow, ETL/ELT entry, ASM entry or Content Inspector as an action is considered erroneous if its start was unsuccessfully, for example, because the entry no longer exists.
If more than one action is specified, the behaviour of the action chain can be defined for the case that one of these actions fails. If an action fails and Ignore error is set, the action chain simply continues. If an action fails and Stop on error is set, the action chain terminates, but not the workflow job.
(7) Run in background: Synchronous/asynchronous profiles. If this checkbox is set, the action chain (and therefore the workflow job) does not wait for the termination of started profiles ( asynchronous) . The successful start of a profile is then considered as a successfully executed profile, even if an error should occur later in the profile. This setting has no effect on all other action types. Note: The list of actions is processed in sequence in the background in a separate thread.
State and subsequent state
As soon as a workflow job changes to a state (when the workflow job is started or after a successfully executed transition of a predecessor state), it remains in this state until a triggered transition check finds a valid transition. The workflow job then changes to the subsequent state connected with this transition. In addition, actions may be executed.