Semantic Exception
(SEMANTIC_EXCEPTION)

The error message is displayed as an information dialog, which can be closed by clicking the 'OK' button or the 'X' icon in the upper right corner.

Process Exception
(PROCESS_EXCEPTION)

The error message is displayed as an error dialog, which can be closed by clicking the 'OK' button or the 'X' icon in the upper right corner.

By clicking on 'More', details of the error (or abort) can be displayed. Among other information, the text value of the Error code parameter (if used) appears there.

By clicking the 'Create bug report' button, this data can also be downloaded as an error report (html document).

Notification: Success
(NOTIFICATION_SUCCESS)

On the right side of the screen the error message appears for a few seconds as a notification of the 'Success' type with the title 'Info'.

Notification: Warning
(NOTIFICATION_WARNING)

On the right side of the screen the error message appears for a few seconds as a notification of the 'Warning' type with the title 'Warning'.

Notification: Error
(NOTIFCATION_ERROR)

On the right side of the screen the error message appears for a few seconds as a notification of the 'Error' type with the title 'Error'.

Notification: Info
(NOTIFICATION_INFO)

On the right side of the screen, the error message appears for a few seconds as a notification of the 'Info' type with the title 'Info'.

Suppress
(SUPPRESS)

The workflow canceled without any notification.

Configuration:

Runtime example: Current locale: 'English'

Runtime example: Current locale: 'Deutsch'

►NOTE◄ The Object property resolver for the first parameter returns the field 'ID' (id) of the reference object in the context of the Abort.

Localization for error code::
(according to error bundle in Localization)
Access denied: Can't access {0} for {1}

Runtime example: with Error type 'Notification: Error'

Runtime example: with Error type 'Notification: Error'

The actions in the Client workflow behaviour are configured as shown on the right:

• Initially, a Search (Event action) is executed whose return value is assigned to the searchResult variable.
  
  

• The subsequent If then else event action checks whether the search was successful. This is done by checking the searchResult variable in an Entity property rule with a negated Is empty compare type:
  
  

  • If the Entity property rule is passed, the returned user account in the searchResult variable is passed to the Execute with event action in the then branch below. Since further details about the processing are not to be discussed here, it appears collapsed in the image.
    
    

  • If the Entity property rule is not passed because the searchResult variable is empty, the Abort event action is executed in the Else branch on the right.
    
    ►NOTE◄ Parameterization of the Abort event action is completely omitted here, since no notification takes place in the Client workflow anyway and in the specific use case no Actions on 'false' are provided that would access the 'Error information' object.

In the behaviour with Client workflow shown above, a Show alert action is set up under the Actions on 'false' as shown on the right, which makes visible the error message triggered by the Abort:

• The Alert title refers to the errorLevel field so that the Error type selected in the Abort event action, if any, can be traced at least by its index number.
  
  

• The Alert message is taken completely from the errorText field of the 'error information' object.
  
  

• Since the Type can only be set statically – and not depending on the errorLevel, for example – 'Notification: Error' was selected here.

Runtime example:

►NOTE◄ The example takes into account the adjustments to the configuration for the Abort event action in the Client workflow shown below.

• The Error type 'Semantic exception' has an effect in the runtime example (top left) only in the Alert title as value 0 for the 'ERROR LEVEL' (see also note below).
  
  

• The defined Default error message names the class ('User') relevant for the failed search indirectly, i.e. via a placeholder and a value configuration for a parameter.

The condition configuration for the existing behaviour ('userSearch') is adjusted as shown on the right:

• Under Actions on 'false', a Show alert action is now no longer executed. Instead, three instances of the Execute behaviour action are created. Each instance refers to one of the behaviours only hinted at below ('abort_Exception', 'abort_Error', 'abort_Warning') by Behaviour name, in each of which a Show alert action with specific characteristics is executed.
  
  

• The Value expression in all cases is defined as the input value ($input), i.e. the 'error information' object returned by the Client workflow on 'Abort'.
  
  

• The check expression (Only if check expression is true) defines one specific condition each that must be met for the behaviour named by Behaviour name to be executed. The check expression in the image checks for the errorLevel value 3. This errorLevel value is therefore linked to the call of the 'abort_Warning' behaviour, which generates a corresponding message:
  Runtime example:
  The Error type for the Abort event action in the Client workflow has been changed to 'Notification: Warning' so that the errorLevel value is 3.
  

►NOTE◄ The specific check expressions should be defined so that each errorLevel value always satisfies exactly one (or no) check expression, so that multiple messages do not appear at the same time.

As Triggering events should be selected the Triggering events from the category Working state (Events), which refer to Working state, whose assignment should be reconfirmed.

The Validating rule here uses a Check type of the 'Order' type.

The only Action on passed rule is configured as a User callback event action as shown on the right:

• Parameters for the query:
  
  

  • The Title is determined by static text ('CONFIRM?').
    
    

  • As Text for the query, the working state to be confirmed is named, which is returned by the Triggering event value resolver.
    
    

  • A Max. wait time (s) of 10 seconds is specified.
    
    

• Case distinction configuration:
  
  

  • No specific event actions are provided in the Yes branch. The current transaction is simply meant to be completed.
    
    

  • In the No branch, an Abort event action is configured with the Error type 'Suppress'. At runtime, a rollback is executed for the transaction. A user who explicitly presses the 'No' button does not receive explicit feedback about it.
    
    

  • In the timeout branch, an abort event action with the Error type 'Semantic exception' is configured, which informs the user via Default error message that a rollback is executed due to the timeout for the reconfirmation of the working state change.

The static text in the Title is in English, so it matches the internal name for the triggering event (FINISHED).

In contrast, the 'Yes' and 'No' buttons appear with the default locales for the Current locale.

The user can let the 10 seconds waiting time pass without selecting 'Yes' or 'No' or to end the dialog by clicking on the 'X' (='No'). Then the message above appears.

The predefined title and the 'OK' button are labeled with the localization for the Current locale.

The message appears, according to the configuration for the Default error message parameter (see above) in English. However, for the placeholder {0} in the message text, the applicable localization ('Finished') appears for the working state assigned by Parameter (FINISHED), which is provided by the Triggering event value resolver at runtime. Here the exception described in the 'Parameter' section (above) for the localization of dynamic enumeration values takes effect.