Skip to main content
Skip table of contents

Modeling Tasks

Tasks are the heart of each business process - they are where the actions of the process are implemented. Actually, you can directly connect a start event to an end event and draw a process without any tasks but this would be not meaningful in most cases.

With BPMN models in Scheer PAS Designer, you can model the following types of tasks:

Type

Usage

Reference Documentation

Execution

State (Example)

  • Task that contains implementations that are executed automatically when the process reaches the task.

  • The process continues to the next element when the execution ends.

Service Task

  • On Exit

Executed_Do_something

  • Process engine waits for an external trigger message to arrive.

  • Once the message has arrived, the process continues at this point.

Receive Task

  • On Exit

Waiting_for_Receive_a_message

  • Process engine waits for an external trigger message to arrive when a User Task is reached.

  • In most cases, a user form would be related to this type of task.

  • The process engine continues once the form has been filled in and send back.

User Task

  • Get Data

  • On Exit

Waiting_for_User_Task

Service Tasks

A Service Task contains implementations that are performed during process execution.

BPMN_Service_Task_Example

Click here to download a simple example project that shows what you can do with Service Tasks in Scheer PAS Designer.

The screenshot below displays the BPMN diagram of the BPMN_Service_Task_Example service, and the execution diagram related to service task Sort words in message:

service_task_example.png

Although the Designer allows for service tasks without any execution diagram, this does not make much sense.
Empty execution diagrams will be reported by the compiler with a warning.

Once the service task has been reached during process execution, the process state machine will switch to a state Executed_<name of the service task with underscores>. In the example that would be Executed_Sort_words_in_message.

Implement Execution

For service tasks, you can add the following execution:

Execution

Description

API / Example

On Exit

Contains the execution to be performed in this process step.

No API.

You can also delete the On Exit execution entirely. In this case, the service task does nothing but logging that this process step has been passed.

Error Handling

If the implemented execution is erroneous, the process goes to an error state. The process provides a retry functionality. Upon retry, the service task will be restarted from the beginning and the implemented execution will be performed once again. This means, before triggering a retry you need to fix the error.

Refer to Persistent State Transaction Concept in the xUML Service Reference Guide for more information on persistent state transaction handling.

Receive Tasks

A Receive Task can be used to introduce data into a process other than via a user input.

BPMN_Receive_Task_Example

Click here to download a simple example model that shows what you can do with Receive Tasks in Scheer PAS Designer.

The screenshot below displays the BPMN diagram of the BPMN_Receive_Task_Example service, and the execution diagram related to service task Receive a Message:

receive_task_example.png

Although the Designer allows for receive tasks without any execution diagram, this does not make much sense. You will at least may want to persist the incoming message to be available in the next steps of your process.
Empty execution diagrams will be reported by the compiler with a warning.

Once the receive task has been reached during process execution, the process state machine will switch to a state Waiting_for_<name of the receive task with underscores>. In the example that would be Waiting_for_Receive_a_message.

Implement Execution

For receive tasks, you can add the following execution:

Execution

Description

API / Example

On Exit

This execution is performed in the exit behavior of the related process state, once the message has been received. This execution gets the message that has been send as a parameter, and you can persist it to have access to the contents later on in the process.
Refer to Modeling Message Reception for more information on message handling.

POST /{id}/<name of the receive task with underscores>
POST /{id}/Receive_a_message

Besides persisting the message, you can add more executional parts but consider the pitfalls of error handling (see below) in this case. You can also remove the On Exit execution entirely. In this case, the message parameter is dropped.

Error Handling

If the implemented execution is erroneous, the process goes to an error state. The process provides a retry functionality but note the following in case of retry:

  • On Exit is executed when the state related to the receive task (e.g. Waiting_for_Receive_a_message) is left. A retry will start from the process step that follows the receive task.

  • The (partly erroneous) implementations of the receive task will not be processed again on retry. So consider wisely which activities to put in to the On Exit execution of a receive task.

Do not implement activities that e.g. rely on backend systems that may be down, or other data processing. We recommend to put these into a service task as a next process step, as error handling of service tasks differs from receive tasks.

Refer to Persistent State Transaction Concept in the xUML Service Reference Guide for more information on persistent state transaction handling.

User Tasks

Similar as with Receive Tasks, the process engine waits for an external trigger message to arrive when a User Task is reached. In most cases, a user form would be related to this type of task, and the process engine continues once the form has been filled in and send back.

BPMN_User_Task_Example

Click here to download a simple example model that shows what you can do with User Tasks in Scheer PAS Designer.

The screenshot below displays the BPMN diagram of the BPMN_User_Task_Example service, and the execution diagram related to service step User Task:

user_task_example.png

Although the Designer allows for user tasks without any execution diagram, this does not make much sense. You will at least may want to persist the incoming message/form data to be available in the next steps of your process. Empty execution diagrams will be reported by the compiler with a warning.
User tasks can be associated with forms. Refer to Using Forms for more information on form handling, and all other possibilities.

Once the user task has been reached during process execution, the process state machine will switch to a state Waiting_for_<name of the user task with underscores>. In the example that would be Waiting_for_User_Task.

Implement Execution

For user tasks, you can add the following execution:

Execution

Description

API / Example

Get Data

This execution is performed before showing the related form. It will also be called if you restart or refresh your Browser before having sent back the form.

You can use this execution to prepopulate form elements. It has a generated return parameter of type form class (see Using Forms > Form Elements in the Data Model).
Refer to Using Forms > Prepopulate Data Into a Form for more information on form handling.

GET /{id}/<name of the user task with underscores>
GET /{id}/User_Task

On Exit

This execution is performed in the exit behavior of the related process state, once the message containing the form data has been received. It gets the form data as a parameter, and you can persist it to have access to the contents later on in the process.
Refer to Using Forms > Process Data From a Form for more information on form handling.

POST /{id}/<name of the user task with underscores>
POST /{id}/User_Task

Besides persisting the message, you can add more executional parts to On Exit but consider the pitfalls of error handling (see below) in this case. You can also remove the On Exit execution entirely. In this case, the message parameter is dropped.

Error Handling

If the implemented execution is erroneous, the process goes to an error state. The process provides a retry functionality but note the following in case of retry:

  • On Exit is executed when the state related to the user task (e.g. Waiting_for_User_Task) is left. A retry will start from the process step that follows the user task.

  • The (partly erroneous) implementations of the user task will not be processed again on retry. So consider wisely which activities to put in to the On Exit execution of a user task.

Do not implement activities that e.g. rely on backend systems that may be down, or other data processing. We recommend to put these into a service task as a next process step, as error handling of service tasks differs from user tasks.

Refer to Persistent State Transaction Concept in the xUML Service Reference Guide for more information on persistent state transaction handling.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.