Find technical details for the Process execution systems here:

Process Execution with IBM Engineering Workflow Management (RTC)

Process Execution with Atlassian Jira

The principal idea of the Stages Process Execution concept is to use existing process information and attach execution information as an addition to it. Ideally this leads to the situation that whenever the process is changed or tailored, the execution changes behavior without changing the execution information.

Hence it is possible to attach execution information only to parts of a process, it can be taken into execution selectively.

As a consequence, there are two data spaces: Process space and Execution space

The Process space contains the process elements like activities, roles, work products etc. The Execution space contains elements like Activators, Execution Properties and Execution Scripts. Both spaces are part of a process version, so that also the execution information is subject of versioning.

Top level steps to use the Stages Process Execution are:

• activate execution configuration in config.xml
• equip your process with execution information
• create a process version and set this as valid version
• export the process to the Excution system

After export your Process execution will work in the Execution system and you can use Stages to run Executable Activators.

Here is an example for this concept:

The “Software Design”-Workflow contains four activities and got attached an “Step-by-Step”-Activator. When this activator gets executed the attributes define the behavior in the Execution System (e.g. Atlassian Jira). In this case the Workflow is executed as “Story” and the activities are instantiated as “task”. The Activator takes care that whenever a task is done (ChildEndState: Closed) the next task is created. So, the activities are executed step by step.

In this way every workflow in Stages can easily get ready to be executed by attaching an Activator to it.

The following types of process execution elementtypes are provided:

The purpose of the step-by-step-Activator is to execute a workflow stepwise. When one activity is done, the object in the execution system for the next activity is created.

The Activator is reactive, meaning that it gets into action when an execution object of type “issue Type” changes state from “Start State” to “End State”. This triggers the creation of the execution object for the first activity. This is created with type “Children Issue Type”

Can be attached to process elements of type Workflow

Issue Type: defines the type of execution object which represents the workflow

Start State & End State: defines the state transition from start to end state for which the activator is triggered (the first child Execution Object is created)

Parent Next State: defines the state of the execution object which represents the workflow when all children are in end state (e.g. the workflow is finished)

Bound-to-process: indicates whether this activator triggers for every Execution Object of type “Issue Type” (bound to process = false) or only when the Process Element is associated to the Execution Object (bound to process = true).

Children Issue Type: defines the type of execution object a child-element is created with

Children Issue Initial State: defines the state of execution object a child-element is created with (RTC only)

Children Start State & Children End State: defines the state transition from start to end state for which a child is to be considered as done and the next child is created

XXX State is a group: defines whether the given state is the name of a single state or a state group (RTC only)

The purpose of the all-at-once-Activator is to create an execution object for every activity of the workflow when the activator gets triggered.

The Activator is reactive, meaning that it gets into action when an execution object of type “issue Type” changes state from “Start State” to “End State”. This triggers the creation of the execution object for all activities of the workflow. Those are created with type “Children Issue Type”.

Can be attached to process elements of type Workflow

Issue Type: defines the type of execution object which represents the workflow

Start State & End State: defines the state transition from start to end state for which the activator is triggered (the children Execution Objects are created)

Bound-to-process: indicates whether this activator triggers for every Execution Object of type “Issue Type” (bound to process = false) or only when the Process Element is associated to the Execution Object (bound to process = true).

Children Issue Type: defines the type of execution object a child-element is created with

Children Issue Initial State: defines the state of execution object a child-element is created with (RTC only)

XXX State is a group: defines whether the given state is the name of a single state or a state group (RTC only)

The purpose of the Transition Workflow Activator is to define a trigger when the given Execution Script is executed. The Activator is reactive, meaning that it gets into action when an Execution Object of type “Issue Type” changes state from “Start State” to “End State”.

Can be attached to any Process Element

Requires an associated Execution Script

Issue Type: defines the type of execution object which triggers the activator

Start State & End State: defines the state transition from start to end state for which the activator is triggered and the Execution Script is executed

Bound-to-process: indicates whether this activator triggers for every Execution Object of type “Issue Type” (bound to process = false) or only when the Process Element is associated to the Execution Object (bound to process = true).

XXX State is a group: defines whether the given state is the name of a single state or a state group (RTC only)

The purpose of the Executable-Activator is to trigger a script in the Execution System from the UI of Stages. It is especially useful to create an Execution Object bound to a Process Element to set the basis for the execution of a Step-by-step-Activator or an All-at-once-Activator.

When an Executable-Activator is associated to a Process Element, in the Process Execution widget a “play-button” is visible to run the Executable-Activator (user triggered)

The purpose of the Issue Property is to define exceptions for a particular Process Element e.g. for an activity in an step-by-step-Activator execution.

Issue Type: defines the type of execution object for the Process Element

Issue Initial State: defines the state of execution object when it gets created (RTC only)

Event Start State & Event End State: defines the state transition from start to end state for which the desired event is triggered

Bound-to-process: indicates whether this activator triggers for every Execution Object of type “Issue Type” (bound to process = false) or only when the Process Element is associated to the Execution Object (bound to process = true).

XXX State is a group: defines whether the given state is the name of a single state or a state group (RTC only)

An execution script wraps a Javascript file which contains the execution system dependent instructions to achieve the desired behavior.

Execution scripts can be attached to Activators only.

The state values are used to define the transitions for which the Stages activators are executed. Generally all states are applicable which are defined in the Execution System configuration.

Caution: the definition requires the technical name of a state which not necessarily is equivalent to the displayed value in the Execution System.

Besides that, there are special values for the states:

• anyState: wildcard including all states also notExistsState
• existsState: describes the state of an element with the only criteria that is exists before
• notExistsState: describes the state of an element before it got created

They can be used to describe the following transitions:

• notExistsState → anyState: an Execution Object got created into an arbitrary state
• existsState → anyState: arbitrary transition with the only criteria that the element existed before (not newly created)
• anyState→anyState: the Execution Object has been saved (state may have changed or not)