Transitions determine the sequence of activities. A transition connects an activity with its successor activity. It also allows to set a condition - only if this condition is fulfilled at runtime the transition is processed and the next activity will be executed.
To create a transition between two activities:
Figure: Creating a Transition between Activities
You can also create a transition connection directly in the diagram canvas:
Figure: Creating a Transition in the Diagram
If you have created at least one link type with target and source type Activity,
you have the choice to select between the custom link types and the standard transition.
Please refer to chapter Specifying Arbitrary Link Types
for information on custom link types.
Figure: Select the Type of Transition
To draw a transition, you can choose the way it will connect an element to another. You have the following three options:
To select the routing option:
Figure: Select Routing Option
The option Default sets the default value according to the type of transition.
Manhattan routing is set as default for transitions of the following elements:
The Shortest Path routing option is set as default for transitions of the following elements:
This option draws the shortest path between two elements. If there is no element between these two elements this means a direct straight line.
Figure: Shortest Path with no Obstacle
In case an element is between, the shortest path around this element is drawn to avoid overlapping.
Figure: Shortest Path with Obstacle
The Manhattan routing option uses a combination of vertical and horizontal lines to connect the symbols.
Figure: Transition with Manhattan Routing Option
The Explicit Routing option gives the possibility to adjust the transition line. When you click the transition line, a dragging cross appears as bendpoint in the middle of the line. You can drag this bendpoint to another place on the canvas. While dragging a bendpoint, a new bendpoint is created for each of the two lines divided by this bendpoint. In this way you can create as many bendpoints you need.
Figure: Transition with Explicit Routing Option
You can select several bendpoints and move them synchronously:
Figure: Move Bendpoints
It is possible to create cyclic transitions. This means that an activity cycle involves repetitive execution of one or more activities until a condition is met.
To create a cyclic transition between activities:
In this example the last activity Start_Campaign is only instantiated if
the data Status has the value 1 (see also Specifying
Transition Conditions ) or else the process continues with Order Media.
To delete a transition, use the option Delete in the transition's pop-up menu.
To remove a transition symbol from the diagram, choose the option Delete Symbol in the transition's context menu. After this operation the transition between the two activities will still exist in the model.
Having removed transition symbols, you can always restore them in your diagram:
Figure: Reload Connections
The properties of a transition are accessible in its properties dialog. To open this dialog, right-click the transition symbol in a model diagram and select the option Properties.
Besides name, id and description, the general properties of a transition include a condition type option and a condition expression field. The Fork on traversal option of a transition controls the synchronism and concurrency behavior during the execution of the corresponding process instances. Please refer to section Activity Thread of chapter Runtime Behavior for details on the Fork on Traversal functionality.
You can set the View Fork on Traversal flag on the Drawing Preferences page to visualize how Stardust Engine traverses during transition conditions.
For details on the generic properties, please refer to section General Properties of chapter Viewing and Editing Properties of Models and Model Elements.
In the Condition Type field you can select the types
OTHERWISE or CONDITION:
Figure: Select the Condition Type.
Please note that switching between those types will remove transition conditions already entered.
The condition type CONDITION enables entering code in the
Condition Expression editor. The return value of this expression will be
checked to be true.
If the condition type OTHERWISE is selected, the transition
is only evaluated to true, if all the other conditions on the split have
the value false. The Condition Expression editor is
disabled.
Note
In case an activity has more than one outgoing transition and none of them has been marked as default (of type
OTHERWISE), a validation warning is displayed in the Problems view accordingly.

Figure: Warning if no default transition is set
In the Condition Expression field you can specify a condition. The transition is then only traversed and the next activity performed if this condition is fulfilled.
Transition conditions are specified if the successor activity is only to be performed under particular circumstances. Please refer to the chapter Transition Conditions of the Basics Control Flow chapter for detailed information on the operators and variables that can be used in transition conditions.
If the return value of a transition condition is true, the transition
will always be traversed and the successor activity executed. To specify a transition
condition, open the transition's properties dialog and enter a predicate in the
Condition Expression field:
Figure: Setting a Transition Condition
In this example it will be checked whether the state of the SupportCaseData is
neither closed nor rejected. The value is referenced via the dereferentiation path
SupportCaseData.Product.State.
A JavaScript based editor is provided, e.g. to add arithmetic, relational and logical operators as well as string matching operators.
You can combine operators and values retrieved via dereferentiation paths with JavaScript language. Here are some examples for possible transition conditions:
Primitive.charAt(2)=="A"
function toUpper(stringArg) {
return stringArg.toUpperCase();
}
Primitive == toUpper(SupportCaseData.Name)
var id=0;
for (var i = 0; i < 10; i++) {
id = id*10 + i;
}
SupportCaseData.Id == id
Errors and warnings are indicated in a transition condition on the left side of the expression. A tooltip gives detailed information about the kind of error or warning.
Figure: Indicated Error in Transition Condition
The following sections describe further issues concerning the transition condition editor usage:
Pressing Ctrl-Space in the transition condition editor
provides you with a list to choose from all available
data, e.g.:
Figure: Default Proposals for Data.
While typing the expression, you can press Ctrl-Space to
show and choose from proposals for available methods or attributes:
Figure: Default Proposals for Methods.
Syntax and other errors in the condition expression editor are underlined in red and highlighted with a status symbol at the beginning of the mapping column:

Figure: Error in Condition Expression
Tool tips for syntax problems are provided:

Figure: Error Tool Tip
Please be aware that no errors or warnings will be displayed in
case you use an unsupported assignment to a Stardust variable, because
the validation of the JavaScript code is correct. For
example, if you enter SupportCaseData.Product.State="R"
instead of SupportCaseData.Product.State=="R", there will be no
warning and during the process an assignment instead a comparison will
tried to be performed, which fails.
Moving the mouse over a function, variable or field, will invoke a window with information derived from the Javadoc for functions and fields.

Figure: Showing JavaDoc Information.
In case the return value of a transition condition is undefined, for example
when all code is commented out, the transition condition will be evaluated
as TRUE at runtime.
Note that some XSD types specified in structured data will be converted to JavaScript types when used in transition conditions. Please refer to the section Mapping XSD Types of chapter Using Structured Types in Process Data for detailed information on how this mapping is performed for specific XSD types.
Please note that decimal xsd types are mapped as String values and thus are compared like Strings in transition conditions. To avoid this, use a Number typecast, e.g.:
Number(StructData1.decimal) > Number(StructData2.decimal)

Note that some identifiers, which can be used in structured data types, are not supported in JavaScript. The following identifiers are not supported:
whereby underscores, digits or dots not used as first character are supported (e.g. first_data, data1, data.dot).
In case you use identifiers containing hyphens or dots in JavaScript, you can set
the identifier in square brackets and quotation marks as a workaround. For example
as referencing a structured data via StructData.name.with.dot would cause an error,
you could use StructData["name.with.dot"] instead. The following screenshot
shows example expressions using brackets to access structured data containing a dot or a
hyphen:

Figure: Identifier Workaround Mapping Example
For general restrictions on model element identifiers, please refer to chapter Model Element Identifiers of the Key Concepts.
The following scenarios are supported when using Enumeration types in the transition condition:
This section describes the usage of enumeration, which is defined in the modeler via Structured Types > New Enumeration. Afterwards the different values are provided as values in the corresponding property page of the created structured type.
Figure: Example Structured Data Enumeration
In this scenario, the following possible example expressions would be valid as part of a transition condition:
StructType.Color == PrimEnumColor.blue; StructType.Color == JavaEnumColor.blue;
Hereby, an interchange of the left hand side and the right hand side is supported.
Figure: Example Condition Expression
This section describes the usage of Java-bound enumerations.
An example Java class could look like the following:
public class EnumClass {
public enum Currency {
USD, EUR, CHF, INR, GBP
}
public enum Color {
red, blue, yellow, black, white
}
}
In this example, the Currency and Color enumeration values can be
used to define Java-bound Enumeration Structured Types.

Figure: Java-bound Enumeration Type
In this scenario, the following possible example expressions would be valid as part of a transition condition:
ColorResult == JavaEnumColor.white;
This section describes the usage of a structured type that is defined with several attributes. An additional attribute is defined, which refers to an already defined enumeration, e.g.:
Figure: Example Structured Data Enumeration
In this scenario, the following possible example expressions would be valid as part of a transition condition:
StructType.Color = PrimEnumColor.blue;
Hereby, an interchange of the left hand side and the right hand side is supported.
Figure: Example Condition Expression
StructType.Color = JavaEnumColor.black.toString();
Hereby, an interchange of the left hand side and the right hand side is supported.
Figure: Example Condition Expression
In a transition condition, you can achieve information about an
activity instance from where the transition starts, by using the engine access
point activityInstance. Code completion is provided with proposals of
methods to retrieve specific information.

Figure: Proposals for retrieving Activity Instance information
In the following example the state of the activity instance is achieved and used in the transition condition:
Figure: Using the Activity Instance Information in the Condition.
Per default 200 pixels of a transition condition are visible in a
process diagram. If the transition condition is longer, this is indicated by dots. You
can change this limitation in the Drawing Preferences
page of the Preferences dialog. An entry field
Visible Transition Condition length in Pixels
is provided to set an Integer value between 1 and 1000.
Please refer to section
Visible Transition Condition length in chapter
Setting Process Manager Preferences for details.
For example, the following transition condition expression requires more than 200 pixels:
Figure: Transition Condition displayed with 200 pixels
To display this expression in full length, enter a greater limit in the Preferences dialog, e.g. 300.
Figure: Changing the limit for the displayed transition condition length