Client workflow
The Client workflow behaviour allows the configuration of client-side executable processes using the otherwise strictly server-side Event handling methodology.
The configuration of the actual 'Client Workflow' is based on the structure of Event handling, insofar as the logical return value of a 'Validating rule' decides whether the event actions configured 'below' are executed. For these two levels, only the selected Event actions, Rules and values are available, i.e. the components that are technically suitable for client-side use.
Unlike Event handling, the configuration in the 'Client Workflow' does not recognize Triggering events, because the context of the behaviour already implies that it is 'triggered'.
For processes that...
... are to be triggered starting from the context of a specific form,
... are configurable with components from the context of event handlings (rules, value resolvers, event actions), but
... do without server communication, i.e. are 'purely client-side executable',
The Client workflow behaviour is a more streamlined alternative to the traditional approach of defining a Custom action event and triggering a corresponding event handling via the Dispatch custom action event (Form designer) behaviour.
With regard to the periphery for calling the workflow, the behaviour is strongly oriented to the form and logic of the behaviour Dispatch custom action event (Form designer):
In the context of an input form, the corresponding object data of the relevant entity (e.g. a business object) is automatically available in the workflow via the event variable entity.
The input data of the behaviour ($input) is passed by default (see screenshot) via the parameter value into the corresponding event variable.
Further parameters can be added in a similar way to fill event variables with the same Name for the workflow per Expression (see Calculation expression).
The optional Result expression (see Calculation expression) defines, if necessary, the data passed to the actions of the behaviour. It can refer directly to the fields of the variable storage and thus also directly access event variables.
If no result expression is defined, then the return behaviour depends on the input data for the behaviour:
If an entity is passed (via the event variable entity), its data is returned – possibly in a manipulated state.
Otherwise, an automatic attempt is made to read the event variable formData.
The Result expression can also refer to the event variables formData and entity based on the same case distinction.
The Edit Button opens the graphical editor for the configuration of the actual workflow (see screenshot at the very top), which works largely analogous to the Configuration of events.
Example
A simple example will show the basic principle of the client workflow:
The contents of a text field are transferred to the client workflow and processed. Subsequently, the response of the program is written back to a second text field.
When clicking on the Send button, the content of the Message text field is transferred to the client workflow as the workflow variable 'message'.
The value in the variable 'answer' after the workflow has been terminated is then written to the Answer text field with the action 'Set value'.
As a workflow program, simply check if the value of 'message' starts with the word 'hello'.
If the answer is yes, 'Hello as well!' and if the answer is no, 'Wrong input!' should be written to the 'answer' variable.
This very easy example is only intended to show a very simple approach, because the possible combinations and applications are almost unlimited and arbitrarily complex.
The example in action:
|
Input |
Output |
|
|
|
|
|
|
Further details and examples: See Dispatch custom action event (Form designer).