Events and Scripts

yuuvis® RAD designer • 10.x »

Scripts are implemented for server-side events in the flow of processes. The relevant script is executed when an event is triggered. The script API can be used only in these event scripts.

The two main types of server-side process events are condition events and general events.

For conditions, each event script must return a Boolean value.

General events do not require a return value.

In addition to the following overview, detailed information can be found in the API documentation, which is part of the installation and accessible via the following address:

<host-gateway>/rest-ws/#PAGE:bpm_script_api

General Events

  • ActivityCreateCondition: The corresponding start condition script must return a Boolean value. If it is true, the process engine creates the task for the process instance; if it is false, the activity is not created and no subsequent transitions or activities are created on this process path.
  • BeforeStartActivity: This event is triggered after a task is created. No user interaction has taken place yet if the activity is of type 'work item.' No container content has been executed yet if the activity is of type 'Container.'
  • BeforeEndActivity: This event is triggered after a task has been successfully forwarded. This means for work item activities that all user interactions are completed. For container activities, the entire container content is completed.

These events all run in the context of the system user.

Transition Events

A transition is a sequence flow between two activities. It is possible to define a script condition that determines whether this transition should be executed. The transition event is triggered when a completed activity has an outgoing transition. The transition event must return a Boolean value since it is a condition event. If it is true, this path is executed and the activity will be created at the end of the transition; if it is false, the activity is not created and no subsequent transitions or activities are created on this process path.

Deadlines/Delays

Several additional events are available when time periods are defined in the process model:

  • DeadlineExpired: support through deadlines. This event is triggered upon expiration of a deadline.
  • DelayFinished: support through delays. This event is triggered when a delay is over.

These events are completely detached from the process execution and run in the context of the system user.

Specific Activity Event Types

Container

The contents of the container are executed after the ActivityCreateCondition script returns true and after the BeforeStartActivity event is triggered. A scope is created when entering the container and the event SubScopeStarted is triggered. This scope is closed when all activities contained in the container and created there are completed and the event SubscopeCompleted is triggered.

Both events also run in the context of the system user.

Loop

The 'Loop condition' event is triggered at each iteration. The time at which the event is triggered depends on the loop type:

  • A loop condition (WHILE-DO) checking whether the implementation took place triggers the event before the container is entered.

  • A loop condition (REPEAT-UNTIL) checking whether the implementation took place triggers the event after the contents of the container have been executed, meaning that the subscope has been completed.

For this activity type, the SubScopeStarted and SubScopeCompleted events are triggered for each loop iteration.

Multi-Instances (MIByData, MIByNumber, MIByPerformer)

For this activity type, the SubScopeCreated and SubScopeCompleted events are triggered with each executed instance of the container content.

Route

For this activity type, it is sufficient to implement a script for either BeforeStartActivity or AfterStartActivity.

The reason being is that these events are triggered one after the other without any activity in between.

Subprocess

For this activity type, the BeforeStartActivity event is used to start the subprocess and the BeforeEndActivity event is used to transfer data from completed subprocesses to the main process.

Work Item

The work item activity offers the following event types that run in the context of the user:

  • WorkitemPersonalized: This event is triggered when a task in the inbox is personalized.
  • WorkitemCanceled: This event is triggered when a user returns a task.
  • WorkitemSaved: This event is triggered when a user saves or forwards the task’s data.

These events depend on the user’s actions in the inbox. For this reason, they can be triggered more than once. For example, if a user saves a form ten times, the WorkitemSaved event will also be triggered ten times.

It is possible to use the $.sudo method in the event script to switch to the context of the system user.

The scope of the user interaction starts after the ActivityCreateCondition script returns true and the BeforeStartActivity is triggered.

A work item in the context of the user creates tasks in the inbox depending on the configuration.