Property View

The Property View is used to edit all parameters for the currently selected BPMN2 element. BPMN2 Modeler uses tabbed property sheets that are based on Eclipse Forms widgets (see screenshot below).

Figure 13: Tabbed Property View

Although the number of tabs and their contents depends on which BPMN2 element is selected, the first tab of each element is similar. This is the Description tab which contains the element’s name (if it has one), a brief description of the element type, and a Documentation edit box which can be used to document the element.

*       The Description text can be hidden by changing the Editor Behavior preferences.

The element’s ID attribute will also be displayed on this tab, if its visibility is enabled (see Editor Behavior preferences.)

Editing Widgets

If you are familiar with Eclipse Forms, most of the Property View editing widgets should be familiar (e.g. Text Editing fields, Check Boxes, Combo Boxes, etc.) The Eclipse Plug-in Manifest editor is an example of how these Form widgets look and behave.

BPMN2 Modeler uses a unique editing widget, which deserves further explanation, called the “List and Detail”. This is essentially a table (the “List”) with several editing controls at the top, and an optional Detail panel that pops out to the right when the edit button is clicked. The figures below illustrate the List and Detail widget in its normal and expanded form:

Figure 14: List and Detail widget in normal an expanded views

Here the List portion of the widget is automatically collapsed to make room for the Detail panel, which appears to the right of the List. The Detail panel typically contains more information than can be displayed in the List.

List and Detail widgets can also be nested, as shown here with the Interfaces tab:

Figure 15: Nested List and Detail widgets

Here, the Interface Details panel contains an Operation List and Detail, which is also shown expanded.

*       You may wish to use a popup dialog instead of the sliding Detail Panel. See the Editor Behavior preferences section for information.

The List and Detail widget control buttons should already be familiar:

 Add a new entry to the List

 Remove an entry from the List.

 Re-order items in the List.

 Edit the selected List item by opening the Detail panel to the right of the List, or a popup dialog depending on preference.

 Delete the selected entry entirely from the model. This is different from  in that the selected entry and all of its contained entries (as with the Interface List mentioned above) are deleted.

 Close the Detail panel

 This button is seen in conjunction with other Text widgets and typically opens a new Dialog from which values can be selected for the Text widget.

Property Tabs

In this section we discuss all of the Property Tabs and their contents for each of the BPMN2 element categories.


Process Diagram

This Property Tab is displayed when the Drawing Canvas is clicked, or if a Process element is selected from the Outline View.

Process Tab

The Process tab defines attributes specific to the selected Process:

Figure 16: Process Tab

·         Name – the Process name for identification purposes only. This may or may not be required by the execution engine.

·         Process Type – can be either “Private” or “Public”; “None” indicates no decision has been made about the Process Type and is flagged as an error by the BPMN2 Core validator.

o    Private – indicates the Process is internal to a specific organization. A Private Process can be either executable or non-executable (see below.)

o    Public – represents the interaction between a Private Business Process and another Process or Participant

·         Is Executable – indicates if the Process is designed to be executable or not. If this box is checked, the Process must contain enough information so it can be deployed to an execution engine. Thus, information needed for execution, such as formal condition Expressions are typically not included in a non-executable Process.

·         Is Closed - In some applications it is useful to allow additional Messages to be sent between Participants that may not be explicitly declared in the Collaboration. If this box is checked then Participants may not send any Messages other than those declared.

Interfaces Tab

The Interfaces tab contains Process Interface definitions:

Figure 17: Interfaces Tab

·         Interface List – list of all defined Interfaces, both consumed and exposed. Clicking the  button displays the Interface Definition details:

o    Name – the Interface name

o    Implementation – the concrete artifact in the underlying implementation technology, such as a WSDL Port Type.

o    Operation List – a list of the Operations provided by the Interface. Clicking the  button displays the Operation Definition details:

§  Name – the Operation name

§  Implementation – the artifact in the underlying implementation technology, such as a WSDL Operation.

§  In Message – the request message definition provided by the Process and sent to the service that implements this Interface. Messages are defined in the Definitions tab, below.

§  Out Message – the response message returned by the invoked service.

§  Error Refs – a list of possible error responses that may be returned by the invoked service. Errors are defined in the Definitions tab, below.

·         Interfaces Provided by Process – lists only those Interfaces exposed by this Process. Clicking the  button allows you to select from the list of defined Interfaces.

Definitions Tab

The Definitions tab defines a list of imported resources, Data Types, Messages, Errors, Signals, Escalations and Resources. This tab also contains additional process attributes as follows:

Figure 18: Definitions Tab

·         Name – the name of the root element of this XML document. This is different from the Process name, primarily for documentation purposes.

·         Target Namespace – the Target Namespace of this XML document. This will be specific to the organization or service that owns this process.

·         Type Language – identifies the type system used by the data elements in this file. By default, this is but may be any URI supported by the Target Runtime.

·         Expression Language – identifies the default language implementation used in condition expressions. The Default is but can be overridden for each expression as needed.

·         Import List – Imports are external files that may define data structures, services, processes, etc. that are required by this Process. See also File Import Dialog.

·         Data Type List – Data Types define the structure of Messages, variables, Data Objects and other data. See also the Data Type Dialog and a discussion of Data Types In the Appendix.

·         Resource List – This is a list of actors involved in the Process. See also the Resource Dialog and definition of a Resource.

·         Data Store List – defines all Data Stores used. See also the Data Store Dialog.

·         Message List – defines all Messages used. See also the Message Dialog.

·         Error List – defines all Data Stores used. See also the Error Dialog.

·         Escalation List – defines all Escalations used. See also the Escalation Dialog.

·         Signal List – defines all Signals used. See also the Signal Dialog.

Data Items Tab

The Data Items tab contains global Process variable and Resource Role definitions. See the Variable Dialog and the discussion of Variables in the Appendix. Also see the Resource Dialog and the discussion of Resources in the Appendix for more information.

Figure 19: Data Items Tab


This section describes the Property Tabs used for of these Activities:

·         Task

·         Business Rule Task

·         Service Task

·         User Task

·         Manual Task

·         Receive Task

·         Sub-Process

·         Ad Hoc Sub-Process

·         Script Task

·         Send Task

·         Transaction

·         Call Activity

Each specialized Activity has its own Property tab (see the following sections), but all contain these common items:

Figure 20: Manual Task Tab

·         Is For Compensation – if this box is checked this Activity is only activated when a Compensation Event is detected and initiated; if not checked, the Activity is run as part of normal execution flow.

·         Loop Characteristics – determines whether the Activity is run once (Loop Characteristics = “None”) or multiple times (“Standard” and “Multi-Instance”), and whether instances of the Activity run concurrently or in parallel. This property is quite complicated and is discussed in more detail in the following sections.

·         Variable List – list of “local” variables. Local variables are visible only to the Activity itself, not to the Process or other Activities. See the Variable Dialog and the discussion of Variables in the Appendix for more information.

·         Resource List – defines the resource that will perform or will be responsible for the Activity. See the Resource Dialog and the discussion of Resources in the Appendix for more information.

Standard Loop Characteristics

The “Standard” loop semantics is to simply execute an Activity as long as some Expression condition evaluates to true. The condition can be tested before or after the Activity is executed. Also, a maximum limit may be set on the total number of executions.

Figure 21: Standard Loop Characteristics

·         Test Before – if this box is checked, test the Loop Condition before the Activity is executed

·         Loop Condition – a script executed by the process engine. If it evaluates to true, the process engine will execute the Activity.

·         Loop Maximum – maximum number of times the Activity will be executed. For example, if an Activity should be executed exactly 10 times the Loop Condition expression would be “true” and Loop Maximum would be set to 10.

Multi-Instance Loop Characteristics

The “Multi-Instance” loop semantic is a bit more complicated, and looks like this:

Figure 22: Mult-Instance Loop Characteristics

·         Sequential instead of Parallel Execution - determines whether an Activity is executed sequentially (box checked) or in parallel (not checked). The number of instances of the Activity created is either specified by an integer Expression or the number of items in a specific data item collection (described by the next property). When this box is checked, the Property sheet expands to show the Completion Condition widget:

·         Number of Instances determined by – can be either an integer Expression, or a data item collection. When the Integer Expression radio button is checked, the Property sheet expands to show the Expression widget:

If the Collection of Data Items radio button is checked instead, the Property sheet expands to show the Input Data Items widget:

An Input Instance Parameter can be defined that will hold the value of each item in the Input Data Collection. This value can then be accessed by the Activity during execution.

·         Activity Execution Produces Output – if this box is checked, the Activity is expected to produce output, and the Property sheet expands to show the Output Data Items widget:

As with Input Data Items (above) a parameter can be defined that can be accessed by the Activity. The value of this parameter will be added to the output collection when the Activity completes.

·         Throw Behavior - defines if and when an Event is thrown from an Activity instance that is about to complete. It has values of None, One, All, and Complex, assuming the following behavior:

o    None - an Event Definition is thrown for all instances completing.

o    One - an Event Definition is thrown upon the first instance completing.

o    All - no Event is ever thrown.

o    Complex - the Complex Behavior Definition List (below) is consulted to determine if and which Events to throw. The Property sheet expands to show the Complex Behavior Definition List:

Each entry in this List contains a Condition Expression which, if it evaluates to true, will cause the associated Event to be thrown by the Activity. The details dialog to edit the Condition Expression and assign a Throw Event is shown below:

I/O Parameters

The I/O Parameters Property tab is used to define the inputs and outputs for an Activity and how these are associated with (“mapped to”) other data items from the Process that are available to the Activity. This Property tab contains lists of Input Sets, Input Data Associations (“Mappings”), Output Sets and Output Data Associations.

*       See the discussion of Data Associations and Input and Output Sets in the Appendix for more information.

Figure 23: I/O Parameters Tab

When adding or editing an Input Set item, the following details panel is displayed:

·         Name – is the Input Set name

·         Data Inputs - is the list of Data Inputs for the Activity (a.k.a. “Input Parameters”) defined in the Input Parameter Mapping list

·         Optional Inputs – is a list of Data Inputs that may be unavailable when the Activity starts execution

·         While Executing Inputs – is a list of Data Inputs that can be evaluated while the Activity is executing

·         Output Sets – is a list of Output Sets produced by the Activity

Input Parameter Mapping determines how the Input Parameters are filled before the Activity is executed. Similarly, Output Parameter Mapping determines how data is pulled from Output Parameters after the Activity has finished.

In the following discussion, only the Input Parameter Mapping will be shown; the behavior of Output Parameter Mapping is similar except that the “From” and “To” directions are reversed.

The “To” section identifies the Input Parameter, its Data State and Data Type.

The “From” section of the Mapping Details panel identifies the source of the data for the Data Input:

·         Variable – the source is a Process Variable, Data Object or Data Store. This data item must have the same Data Type as the Input Parameter.

·         Transformation – the transformation expression is executed and must populate the Input Parameter.

·         Expression – the Input Parameter is populated by evaluating the Expression.

·         Assignments – allows for any number of assignment expressions that copy data from any available data items to the Input Parameter.

The figures below illustrate these different sources.

Variable: here the Process variable “username” is copied to the Input Parameter “greeting”.

Figure 24: Parameter Mapping Details

Transformation: here an expression is evaluated that transforms source data items to the Data Type required by the Input Parameter.

Expression: the expression is evaluated and the Input Parameter is populated. This source type is simply a convenience for an Assignment (see below) that has an expression as the source, and the Input Parameter as a target. The difference between Expression and Transformation is in their execution semantics: if a Transformation is specified, any Assignments are ignored.

Assignments: this allows for multiple source expressions to populate individual elements of the Input Parameter. Shown here is an Input Parameter “address” being populated with different bits of information from Process variables.

The Output Sets and Output Parameter Mapping Lists are similar to their input counterparts, but with the “from” and “to” directions reversed.

Ad Hoc Sub-Process

Figure 25: Ad Hoc Sub-Process Tab

·         Triggered By Event - if this box is checked, the Sub-Process is used for event handling. See the Appendix for constraints on event handlers.

·         Cancel Remaining Instances – if this box is checked, any running inner Activities will be canceled once the Completion Condition is evaluated and is true.

·         Ordering – may be either “Sequential” meaning only one inner Activity may execute at a time, or “Parallel” if more than one Activity may start at the same time.

·         Completion Condition – a condition expression that is evaluated after completion of any inner Activity: if the condition is false, other inner Activities can be executed; if true, the Ad Hoc Sup-Process completes and no other Activities will be executed.

Business Rule Task

Figure 26: Business Rule Task Tab

·         Implementation – the underlying technology used to implement the Business Rule execution. See the Appendix for a discussion of service implementations.

Call Activity

Figure 27: Call Activity Tab

·         Called Activity – the Activity to be executed. This can be either a Process or Global Task.

Receive Task

Figure 28: Receive Task Tab

·         Implementation – the underlying technology implement by the Receive Task. See the Appendix for a discussion of service implementations.

·         Operation – the Operation through which the Receive Task receives the Message.

·         Message – the Message expected by the Receive Task.

·         Map Incoming Message Data To I/O Parameter mapping that specifies how the Message payload is copied to a Process data item.

·         Instantiate – if this box is checked, this will create a new instance of its containing Process to handle the Message.

Script Task

Figure 29: Script Task Tab

·         Script Format – defines the format of the script. This attribute value must be specified with a mime-type format (e.g. “application/javascript” and “application/x-sh”). This is required if a script is provided.

·         Script – the script to be executed.

Send Task

Figure 30: Send Task Tab

·         Implementation – the underlying technology implement by the Send Task. See the Appendix for a discussion of service implementations.

·         Operation – the Operation through which the Send Task sends the Message.

·         Message – the Message sent by the Send Task.

·         Map Outgoing Message Data From I/O Parameter mapping that specifies how the Message is populated.

Service Task

Figure 31: Service Task Tab

·         Implementation – the underlying technology implement by the Service Task. See the Appendix for a discussion of service implementations.

·         Operation – the Operation through which the Send Task sends the Message.

·         Map Service Request Message Data From I/O Parameter mapping that specifies how the service request Message is populated.

·         Map Service Response Message Data To I/O Parameter mapping that specifies how the service response Message payload is copied back into the Process as, e.g. a Data Object, Process Variable, etc.


Figure 32: Sub-Process Tab

·         Triggered By Event - if this box is checked, the Sub-Process is used for event handling. See the Appendix for constraints on event handlers.


Figure 33: Transaction Tab

·         Triggered By Event - if this box is checked, the Sub-Process is used for event handling. See the Appendix for constraints on event handlers.

·         Method - the method used to commit or cancel a transaction.

·         Protocol - the transaction protocol to use. See the Appendix for a description of Transaction Protocols.

User Task

Figure 34: User Task Tab

·         Implementation – the underlying technology implement by the User Task. See the Appendix for a discussion of service implementations.


Gateways also share some common properties, as shown below.

Figure 35: Gateway Tab

·         Gateway Direction – specifies whether the process flow is merged (diverging) or joined (converging) or neither. See the Appendix for a discussion of Gateway behavior.

·         Sequence Flow List – contains a list of all outgoing Sequence Flows, which can be configured for the Gateway behavior. Clicking the  button displays the Sequence Flow detail panel as shown:

The Add Condition button will expand the Property sheet to show a Condition Expression widget, like so:

The Remove Condition button will delete the Condition Expression.

Note that a Parallel Gateway creates (Diverging) or merges (Converging) parallel process flow paths without checking any conditions, so the Property sheet does not contain the Sequence Flow List.

The Property sheet for a Complex Gateway also includes an Activation Condition expression which, when it evaluates true, will cause the Gateway to trigger.

The Event Based Gateway Property Tab looks like this:

*       Please refer to the Appendix for a discussion of Event Based Gateways and the meanings of these properties.


Events come in three flavors: Catching, Throwing and Boundary. The Boundary Event is also a Catching event, but is attached to an Activity. All Event types have an Event Definitions List as shown below:

Figure 36: Event Tab

Event Definitions determine the behavior of the Event. There are ten different types of Event Definitions but not all of them apply to all types of Events.

*       Please see the Appendix for a discussion of Events and Event Definitions.

Clicking the  button in the Event Definitions List displays the Event Definition selection dialog:

Figure 37: Event Definitions Selection Dialog

The list of available event definitions will depend on the type of Event (Catching, Throwing, Start, End or Boundary) and where in the Process the Event is declared.

Some Event Definitions may involve the transfer of data, either flowing out of the Process to the Event Definition (for Throwing Events) or coming into the Process (Catching Events). This data is transferred through variables attached to the Event and the mapping mechanism to associate Process data with these variables is similar to the I/O Parameters described in the Activities Property Tabs section.

Event Definitions With Data Items

Some Event Definitions may optionally have a data payload associated with them, they are:

·         Error

·         Escalation

·         Message

·         Signal

Error Event Definition

The Details panel for an Error Event Defintion looks like this:

Figure 38: Error Event Definition Details

The label “Map Incoming Error Data To:” indicates that this is a Catching Event, and that the Error data payload that was thrown by the Throwing Event will be copied into a process variable named “error_info”. The Data Type of the payload that was sent by the corresponding Throwing Event must match the Data Type of the receiving “error_info” variable.

Escalation Event Definition

The Details panel for an Escalation Event Definition is similar:

Figure 39: Escalation Event Definition Details

Here the Event is a Throwing Event (“Map Outgoing Escalation Data From:”) and in this example, an Expression is used to populate a variable in the Event. The payload (a String in this case) will be passed to the Catching Event triggered by this Throwing Event.

Message Event Definition

Message Event Definitions require a message identified by either an Operation/Message pair, or just a Message defined within the Process:

Figure 40: Message Event Definition Details

In this example, the contents of the process variable “addressRequest” will be copied to the Event variable and transferred to the Catching Event that is triggered by this Throwing Event. The “addressRequest” Data Type must be the same as the Message. The Catching Event must specify the same message type in its Message Event Definition.

Signal Event Definition

This is similar to the Error and Escalation Event Definitions:

Figure 41: Signal Event Definition Details

Data Items

Data Items fall in to three categories:

·         Data Objects

·         Data Inputs and Outputs

·         Data Stores

The Property Tabs for these are very similar and all define a Data Type and Data State. The Is Collection check box indicates the data item is a collection of objects:

Figure 42: Data Object Tab

Data Objects and Data Stores are reusable entities, thus we can have multiple visual representations of the same data instance on the Drawing Canvas. These are known as “References” to the original and have an additional Reference tab:

A Reference may be in a different Data State than the original object, as shown above.

Data Stores may also specify a fixed capacity, or may be “unlimited” in size:

Sequence Flows

The Sequence Flow Property Tab allows an optional condition expression to be added to the Sequence Flow as shown here:

Figure 43: Sequence Flow Tab

*       See also the Property Tab for Gateways.