Service tasks

Service tasks are essential components of every workflow template. They define the actions available in the BPMN designer and drawn in the workflow template.

Service tasks can be either standard or triggerable.

• Standard service tasks execute and complete the action they are called to perform, and then the workflow continues. An example of standard service task is the RenameFile service task that executes and completes the rename task.

• Triggerable service tasks do not perform a specific action, but rather, initiate a request to start an operation. The instance enters a paused state, waiting for a completion notification to trigger it. The spPush service task, for example, delivers a file to a remote host using a specific transport protocol. It sends a request to STENG to initiate the file transfer and then waits. Once the transport finishes, the process is triggered again upon receiving the completion event.

Primeur can offer additional Service tasks with a separate license.

The description of how to use service tasks to create workflow templates is on the Create a user-designed workflow template page.

In Data Mover, service tasks can belong to these categories:

• Logging

• Local Operations

• Remote Operations

• Compression and Encryption

• FSR - File Service Registry

• Miscellaneous

• Virtual Paths

• Virtual Box

• group.rule-operations.title ??????

• Activities

???? REMOVE

STENG peers perform triggerable tasks that are often related to long-lasting operations, like transports.

The main action is to request the schedule of an operation from a subsystem and to save the exit code in the RC variable if it exists.

When the service task finishes, the flow does not continue immediately. Instead, it enters a wait state that uses no resources until the scheduled operation is complete. At that point, the process engine will resume. The value of the RC variable will be updated to replace the scheduled exit code with the actual code from the completed action, and then the instance will be re-triggered to move to the next step.

By design, all triggerable service tasks wait for a trigger before proceeding to the next step and that is why they always throw a BpmServiceException when receiving a schedule return code that is not 0 (Return Code OK). Otherwise, they will wait for an event that will never come, since the scheduled operation failed.