Model and Manage Process Execution

The principal idea of the Stages Process Execution concept is to use process information in Application Lifecycle Management (ALM) Systems to work process compliant and to automate workflows.

Find technical details for the ALM Systems here:

Process Execution with IBM Engineering Workflow Management (RTC)

Process Execution with Atlassian Jira (server version)

In Stages the existing process information is used regularly. The execution information is attach 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.

After exporting the Stages Process into the ALM System, the System has access to process and execution elements. This leads to the advantage that events (like saving or changing the state) from within the System can run automation and follow the process.

Also Stages is capable of triggering such events in the Workflow Management System with the Executable-Activator.

Top level steps to use the Stages Process Execution in Stages are:

• activate execution configuration in config.xml
• equip your process with Execution Activators
• create a process version and set this as valid version
• export the process to the ALM system (see individual links above for a system specific howto)

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

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.

You have to activate process execution by adding the ALM system type to the config.xml. You can choose to activate Jira and/or RTC:

<enactment>
    <enactment-system name="rtc">
    </enactment-system>
    <enactment-system name="jira">
    </enactment-system>
</enactment>

It’s recommended to add server configuration information:

<enactment>
    <enactment-system name="jira">
        <enactment-server ident="jiraProduction" url="https://jira.example.com/jira" displayName="Jira Production">
            <enactment-property name="username" value="user" />
            <enactment-property name="password" value="secret" />
        </enactment-server>
    </enactment-system>
</enactment>

The following types of process execution elementtypes are provided:

The purpose of the step-by-step-Activator is to execute a workflow step wise. 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

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)

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).

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 Activator-types with “legacy” in the name are for V6 migration purposes only.

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).

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)