User callback
Event action – Abstract
Purpose: Shows a user-defined Yes/No dialog in the client and interrupts event processing until the user has made a selection or a defined maximum waiting time (timeout) has been exceeded.
The Benutzer Rückfrage event action displays a user-defined Yes/No dialog in the client (see screenshot) and interrupts event processing until the user has made a selection or a defined Max. wait time (s) ('timeout') has been exceeded.
Afterwards, event processing continues depending on the result in one of three branches of a case distinction.
|
|
|
►IMPORTANT◄ The Timeout branch is particularly relevant if the event action is not only triggered interactively but also, for example, by events in the context of an Import job. This can happen if work status changes can be initiated via the interface and a certain target status triggers an event handling that includes a Benutzer Rückfrage. In this case, there is no addressee to respond to the 'callback'. Effectively, the Import job (on the Lobster_data system) simply waits until the time has expired. Afterwards, the event actions configured in the Timeout branch are executed, if any.
Configuration
Output texts for the Title and Text parameters can optionally (see example below) be entered directly or as return value of a value resolver. The value resolver Value from localization can also include localization entries from the Localization or Company specific localization adaptations, so that the 'callback' appears either in the language of the logged-in user or, if necessary, in a language that specifically alternates from it.
The Max. wait time (s) parameter contains a static integer that specifies the maximum number of seconds for which the 'User callback' dialog is displayed in the client if there is no response from the user. The default value suggested is 30 seconds.
►IMPORTANT◄ If a value of 0 seconds is specified for the Max. wait time (s), this is interpreted as an 'infinite' waiting time. The dialog is then never closed automatically. This setting should only be made if it is sufficiently certain that the event handling is not triggered by an interface (e.g. an Import job) under any circumstances, since otherwise the interface may wait 'forever' for a Timeout.
Below the parameters, event actions can optionally be added in each of the case differentiation branches (Yes, No and Timeout) by clicking on the 
icon.
At runtime, depending on the reaction, precisely one of the branches of case differentiation is processed. Afterwards, the event processing – independent of the processed branch – is continued 'below' the event action, unless a Abort is executed or an error occurs.
Example
Before the data of a shipment is transferred via 'Export' to an interface to another system, an explicit confirmation for this step should be obtained from the user who has interactively triggered this transfer.
It should be taken into account that the corresponding trigger (e.g. a change to a certain Working state) can also be triggered by an update of the shipment data via interface. Then the export is to be executed automatically.
Configuration:
|
For this purpose, the Benutzer Rückfrage is inserted within an event handling for the respective broadcast and parameterized as shown on the right:
|
|
|
At runtime, the callback appears as a dialog with the Yes and No buttons, taking into account specific shipment data, e.g. as shown on the right, if the process was triggered interactively. If, on the other hand, the process goes back to an Import via interface, then the export (after 30 seconds waiting time) is executed automatically. |
|
►NOTE◄
In practice, either the approval or the rejection is to be accepted for the query in the event of a Timeout. Technically, the relevant event actions must then be configured redundantly, since there is no way to 'redirect' from the Timeout branch to one of the other branches. In the example, the redundancy is limited to the event action Eigenes Aktionsevent auslösen (Aktion), which is then used to trigger the same process in a different event handling.
Alternatively, it may be useful to store the result of the query with a Set value action in each result branch in a variable (e.g. as a Boolean value) to subsequently handle the actual case distinction in an If then else event action starting from the value of the variable. Then, in case of a Timeout, simply set the value (true or false) corresponding to the Yes or No branch.