Together Workflow Editor

Together Workflow Editor (TWE) is a graphical editor for creating, editing, managing and reviewing WfMC XPDL process definition files.

Workflow management is an evolving technology with lots of vendors claiming their approach is the best. We have chosen an approach which relies on WfMC and XPDL, thus supporting efforts to establish the standard. Together Workflow Editor is based on version 2.1 of the XPDL XML schema published by WfMC.

The editor makes creating and editing XPDL easy. It represents all XPDL elements graphically through property panels and a graph component using BPMN graphical notation, to give the user a better understanding and an overview of the process definitions. Various functions help in finding specific activities, participants, applications, errors in the model, etc.

The final output of the editor is an XML file (using the standardized WfMC XPDL schema) which can then be interpreted and executed by all WfMC XPDL compliant workflow engines.

Together Workflow Editor accomplishes three main goals:

Before version 4.x, Together Workflow Editor was XPDL 1 editor that coverd the whole XPDL 1 Meta-Model. It was the best open-source (and we believe also the best of all) editor which allowed any vendor to create the XPDL 1 based workflow processes for their workflow engines. It was used by many vendors to (graphically) design their process definitions. Beside that, it was always the example for other implementors of such editors to see how to correctly interpret XPDL specification.

Beside the core features that allows anyone to easily model XPDL processes, the flexibility and configurability of the editor, that includes configuration by only changing the existing component's properties, branding, and writting a special "configuration" modes for an editor, makes TWE powerful, and easily adjustable for the usage with any specific workflow engine.

The version 4.x brings XPDL 2 and BPMN support. Although not fully covering XPDL 2 and BPMN, TWE now allows users to use the old powers of the editor and new BPMN notation which goal is to standardize graphical process representations, and thus making them uniform accross different editor tools, and understandable by the users knowing BPMN standard.

The great feature of this new version is that it automatically converts XPDL 1 process definitions into XPDL 2 definitions, which minimizes the efforts of the migration to XPDL 2. Editor currently supports the sub-set of XPDL 2 specification necessary to conform to "simple" BPMN requirements.

In the future, editor will support more and more of BPMN and XPDL 2 specification, but we will always make our focus to first implement things that provide the modeler writting the workflow definitions for the real life human workflow scenarios.

The WfMC Workflow Management Coalition promotes the advancement of process management technology standards and their use by the industry.

The Java 2 SDK or Java 2 JRE can be downloaded from http://www.oracle.com/technetwork/java .

The Together Workflow Editor home page is located at http://www.together.at/prod/workflow/twe.

JGraph is an open-source swing graph component used in Together Workflow Editor.

Enhydra Shark - the most flexible Open Source WfMC XPDL workflow engine available

The source code of the project can be obtained either via SVN (please read instructions how to check out sources at SourceForge) or by downloading the latest twe-x.y-z.src.zip/twe-x.y-z.src.tar.gz package from SourceForge.

Execute the configure script from the root directory of the project source. Specific JAVA version can be set for building (different from the one registered with your system) by executing:

(Where JAVA_HOME is the path to your JDK installation)

Possible parameters for the configure script are:

configure             - Creates build.properties file with default values
                        for all possible parameters. It can work only if 
                        there is a default JAVA registered with the system.
configure -help       - Displays Help screen
configure -version    - Sets the version number for the project.
configure -release    - Sets the release number for the project.
configure -buildid    - Sets the build id for the project.
configure -jdkhome    - Sets the "JAVA HOME" location of Java to be used 
                        to compile the project.
configure -instdir    - Sets the location of the installation dir used when
                        executing make script with install target specified.
configure -rebranding - ONLY FOR WINDOWS. Flag that determines if the project 
                        will be "rebranded" with the context of branding folder. 
                        Possible values [true/false].
configure -language   - ONLY FOR WINDOWS. Used by NSIS when creating setup 
                        (normally used for rebranding). 
                        Possible values [English/Portuguese/PortugueseBR].

Multiple parameters can be specified at once.


Example:

configure -version 3.3 -release 1 -buildid 20110721-0808 -jdkhome C:/jdk1.6 -instdir C:/JaWE

The configure script will create/change the build.properties file based on the parameters provided. This file can also be manually changed to adjust your environment/parameters for building the project from the sources.

Execute the make script with the buildAll target from the root directory of the project source. When the building process finishes, the project binaries will be in output/twe-[version]-[release] folder.

Possible build targets for the make script are:

make help            - Displays Help screen
make buildAll        - Builds and configures TWE with documentation
make buildNoDoc      - Builds and configures TWE without documentation
make buildDoc        - Builds documentation only
make debug           - Builds TWE JAR files with included debug information
make install         - Installs and configures TWE into directory defined 
                       by parameter install.dir in build.properties file. 
                       This parameter can be set by using command: 
                       configure -instdir PATH_TO_DIR.
                       It should be called only after make buildAll target 
                       is executed!
make clean           - Removes the output and distribution folder (in order 
                       to start a new compilation from scratch)
make distributions   - Builds and configures TWE with all documentations 
                       and creates distribution package

Assuming that the environment is already configured as described previously, to create the project distribution packages, execute:

make distributions

When the building process finishes, the distribution folder will be created in the root directory of the project source containing the appropriate OS specific binary distributions.

On Windows, to have the resulting ‘.exe’ file automatically signed, the file called ‘sign.properties’ should be placed in the root directory of the projects source with the following properties:

sign.tool       - absolute path to the sign tool executable file
sign.privatekey - absolute path to the private key used for signing
sign.pwd        - password for signing
sign.alias      - sign alias

example sign.properties file:

sign.tool=D:/signtool/signtool.exe
sign.privatekey=D:/signtool/privatekey.pfx
sign.pwd=agles87t24e25NDwas
sign.alias=pvktmp:3852567a-45er-567y-w456-23456789sdft

Sign alias can be produced by the usage of Java's keytool by executing the command:

keytool -v -list -storetype pkcs12 -storepass PRIVATE-KEY-PASSWORD -keystore PATH-TO-PRIVATE-KEY

where PRIVATE-KEY-PASSWORD is the same as the property sign.pwd from sign.properties file described above, and PATH-TO-PRIVATE-KEY is the same as the property sign.privatekey from this properties file.

TWE build procedure enables you to create so called "rebranded" version of TWE distribution under Windows.

It means that at the end you can get the windows setup file fully "rebranded" as if the product is under your own ownership. E.g. instead of calling the product "Together Workflow Editor", you can call it "XYZ Workflow Editor", and during the build procedure replace all other things neccessary for the "rebranding".

To build rebranded product, first you have to configure TWE by executing the following configure command in %TWE_HOME% folder:

configure -rebranding true

If you also want to use a different language in the windows setup wizard, you should execute e.g. the following:

configure -language Portuguese

NOTE: currently possible values are English, Portuguese and PortugueseBR.

After that, several things needs to be done in the %TWE_HOME%/branding folder:

There are several sub-folders in %TWE_HOME%/branding folder which content needs to be edited,removed or appended in order to rebrand the application distribution. The following table explains the meaning of the sub-folders and how can you perform TWE branding by changing their content:

After modifying the content of branding folders, simply continue with normal distribution packaging procedure, and the resulting output files in distribution folder will be rebranded.

The latest binary packages of Together Workflow Editor can be downloaded from SourceForge

The only prerequisite to be able to run TWE on Windows or Linux system is Java JRE 1.6 installed on the machine.

There are several binary packages for Windows and Linux operating systems that can be used to install TWE.

If TWE is installed on Windows using twe-x.y-z.exe package, just follow the setup procedure. The similar is with twe-x.y-z.noarch.rpm package on Linux.

If TWE is installed from twe-x.y-z.zip or twe-x.y-z.tar.gz package on Windows/Linux respectivly, the packages should be un-packed, and in the root of the folder where they are unpacked, configure script should be executed. If JAVA_HOME environment variable exists, configure script can be executed without parameters, otherwise it should be called with a parameter specifying JAVA_HOME value, e.g:

configure -jdkhome c:\jdk1.6.0_20

This will create proper run script in bin directory that should be used to run TWE.

TWE has possibility to silently install via twe-x.y-z.exe file. To do that, rename the twe-x.y-z.silent.properties.txt file comming with TWE distribution into twe-x.y-z.silent.properties, put it into the same folder with the twe-x.y-z.exe, and normally start the installation. During the installation, there will be no dialogs asking you to chose Java, place to install, etc. This information is taken from twe-x.y-z.silent.properties file. Here is the content of that file, with the properties you should modify to customize your installation:

# Where to install Together Workflow Editor (default value is C:\Program Files\twe-x.y-z)
inst.dir=C:\Program Files\twe-4.1-1

# Path to local java installation (obligated - has no default value)
jdk.dir=C:\Program Files\Java\jdk1.6.0_24

# Startup menu name. (default value - Together Workflow Editor x.y-z)
startup.menu.name=Together Workflow Editor 4.1-1

# Create quick launch icon (on/off)
create.quick.launch.icon=on

# Create start menu entry (on/off)
create.start.menu.entry=on

# Create desktop icon (on/off)
create.desktop.icon=on

This is the core of the Together Workflow Editor. All the actions needed for opening, creating and manipulating XPDL files and elements are here.

The actions in the main menu are organized in the following groups:

As explained in the previous section, the main menu covers all actions needed for creating, viewing and editing XPDL definitions. The Main tool bar contains shortcuts for various actions of the main menu.

Figure 4.2. Main tool bar

Main tool bar shortcuts are organized similar to the actions in the main menu. All actions are explained in the previous section.

Figure 4.3. Main tool bar shortcut groups

The Info bar shows some basic information about the selected workflow elements. It displays the package name, the process name and the file/package that is being edited.

Figure 4.4. Info bar

The Info bar offers the possibility to select the desired package, process or file:

The Graph Overview is just what its name says - a graphical overview of the process and activity set graph. It shows the whole graph of the selected process or activity set in a way that you can see all the graph elements in the overview area at once.

This overview also provides an easy way to select elements by clicking on the elements or dragging a selection rectangle in the small graphics. All selections done in the overview are immdiately reflected in the main graph. This way even bigger portions of the graph can be selected at once without having to scroll through the main graph. If the element that is currently not visible in the main Graph is selected in the Graph Overview, the main graph is automatically scrolling to show the selected element thus making graphical navigation in large process graphs very easy.

The Graph Overview can be hidden by clicking on the "Overview" tab with the right mouse button and selecting "Close". It can be shown again by selecting "Add Overview" in the context menu of the "External package relations" tab or the background of the "Special Area".

The External Package Relations component gives you a graphical tree overview of the current package and all of its directly or indirectly referrenced external packages. So it provides you the information about the relations between packages starting at the current package.

The picture on the left hand side shows a package (called "Business Example") that references three other external packages: "Participant Repository", "Application Respository" and "Process Repository". The external package "Process Repository" again references (the same) two external packages: "Participant Repository" and "Application Repository". The "Expand All" and "Collapse All" buttons on top of the tree can be used to show or hide the subtree. The External Package Relaltions can be hidden by clicking on the "Overview" tab with the right mouse button and selecting "Close". It can be shown again by selecting "Add External package relations" in the context menu of the "Overview" tab or the background of the "Special Area".

The External Package relations background color can be changed through the extpkgrelations.properties file. (BackgroundColor = R=?,G=?,B=?)

As with all other components you are also able to change the content of the toolbar and the order of the toolbar buttons.

Transient packages are not related to any part of the WfMC XPDL specification but are a unique feature of Together Workflow Editor.

Transient packages are always available to the editor user (independently of the main package that is currently being edited) and the editor user can always copy elements (such as commonly used Activities and Transition structures, Applicatons or Participants definitions, etc.) from the transiently referrenced package into the currently edited package. XPDL Packages imported as transient are neither being validated for errors nor are these transient referrences stored in the current XPDL file. They are just shown for your convenience during modelling work. If a transient package is referencing other packages the user must be aware that the referenced packages won't be imported automatically.

The Transient Package Pool displays all the transiently opened packages. Using the buttons on top you are able to add new or remove existing transiently referrenced packages from the editor. The Transient Package Pool can be hidden by clicking on the "Transient package pool" tab with the right mouse button and selecting "Close". It can be shown again by selecting "Add Transient package pool" in the context menu of the "Overview" tab or the background of the "Special Area".

You are able to pre-configure Together Workflow Editor to load certain XPDL packages in transient mode (see the section called “Property file togwebasic.properties”) at startup to have access to most commonly needed XPDL elements for copying them into the XPDL package you are editing. This feature is typically used for copying certain workflow design patterns from a pattern pool into processes. Predefined common workflow patterns can be found in the Together Workflow Editor installation directory "...\examples\valid\WorkflowPatterns\".

You should be aware that there is a major difference in reusing XPDL elements from external packages and copying XPDL elements from other (transiently loaded) XPDL packages. Common subflows, application or participant definitions should normally be reused by modelling externally referenced packages instead of copying definitions redundantly into other packages.

The Transient Package Pool background color can be changed through the transientpkgpool.properties file. (BackgroundColor = R=?,G=?,B=?)

As with all other components you are also able to change the content of the toolbar and the order of the toolbar buttons.

The Graph is the main component of Together Workflow Editor. It displays the graph representing the selected process or activity set. It offers the possibility to insert new elements into the graph and to visually define the flow / logic of the workflow process you are modelling.

Figure 4.5. Graph Panel

The Graph has its own toolbars with action Shortcuts to customize the view of the process, inserting new process elements or modify existing process elements.

The toolbar on top of the graph component consists of the following actions:

	This action saves the graphical view of the current graph into a JPG format file.
	This action saves the graphical view of the current graph into a SVG format file.
	This action saves the graphical view of the current graph and process information into a PDF format file.
	This action zooms into the graph.
	This action displays graph in its actual size.
	This action zooms out of the graph.
	This action moves the selected participant up or left depending on the current participant orientation of the graph.
	This action moves the selected participant down or right depending on the current participant orientation of the graph.
	This action displays the part of the graph shown before the current part.
	This action displays the part of the graph shown after the current part.
	This action inserts the missing start and end events into the graph.
	This action removes all the start and end events from the graph.
	This action makes text describing transition condition to be shown in the graph.
	This action makes text describing transition condition to be hidden in the graph.
	This action shows artifacts (and associations) in the graph.
	This action hides artifacts (and associations) from the graph.
	This action changes the graph's swimlane orientation from left/right to top/bottom and vice versa.
	This action performs an automatic layout of the graph.
	This action inserts a new activity set.
	This action inserts a lane representing an existing participant into the graph.
	This action selects an existing activity set.

The toolbar below the one described above consists of the following actions:

	This action switches the mouse cursor to the selection mode.
	This action creates a new participant (on the package level) and inserts a new lane representing this participant into the graph.
	This action inserts a new "free text expression" lane into the graph.
	This action inserts a "common expression lane" into the graph.
	This action inserts a data object artifact.
	This action inserts a text annotation artifact.
	This action inserts a start event activity.
	This action inserts an end event activity.
	This action inserts an activity without implementation (manual activity performed by a human) into the graph.
	This action inserts a task-application activity into the graph
	This action inserts a subflow activity into the graph.
	This action inserts a block activity into the graph.
	This action inserts a exclusive gateway - route activity into the graph.
	This action inserts a parallel gateway - route activity into the graph.
	This action inserts a conditional transition into the graph.
	This action inserts an unconditional transition into the graph.
	This action inserts an otherwise transition into the graph.
	This action inserts an exception transition into the graph.
	This action inserts a default exception transition into the graph.
	This action inserts a directional association into the graph.
	This action inserts non-directional association into the graph.
	This action inserts bi-directional association into the graph.

The Graph provides all functions to handle lanes (representing participants), activities and transitions. All standard editor functions like insert, delete, move and select are supported.

When new Workflow Process is created, TWE automatically creates a Pool for that process, and generates a new Graph representing this workflow process. This graph contains only a swimlane representing Pool. The first thing that need to be added/drawn are the lanes (a swimlanes representing the participant). When at least one (swim)lane is visible you can add activities, artifacts, transitions and associations into the graph.

New elements are inserted into the graph in two steps. First select the button of choice in the graph toolbar to change the mouse cursor into the appropriate insert mode. Then click into the graph to insert the selected element. The mouse cursor will remain in the current insert mode until you click the right mouse button, press the ESC key on your keyboard or switch to another mode by selecting a different button in the graph toolbar.

Inserting transitions and associations into the graph is somewhat different: Transitions' begin and end points must be activities, and associations' begin/end points must be activity and artifact. Clicking on the empty background of the graph while inserting a transition/assocation will insert a graphical break/routepoint. If insertion of a transition/association is started and the right mouse button or the ESC key is pressed, the current insert operation is cancelled and the mouse cursor stays in transition/association insert mode.

Elements in the graph are selected by simply clicking on them with the left mouse button. You can select a group of elements by clicking the left mouse button on the empty background of the graph and dragging a rectangle around some elements or by using the SHIFT or CTRL key during left mouse clicks on the individual elements.

To move elements to a new location just drag them with the left mouse button whereever you like.

Double clicking on a graph element opens the property dialog for the element (except for block and subflow activities for which the appropriate graph will be opened).

A right mouse click on an element in the graph will open the context popup menu of the element. The content of the context popup menu depends on which element was clicked on:

Figure 4.6. Graph element context popup menus

As mentioned, when the graph is empty (e.g. when a new process is created, and only Pool for this process is displayed) the first thing to be added/drawn is a lane representing the participant. When at least one lane is visible activities, artifacts, transitions and associations can be inserted into the graph.

The available types of lanes are:

The available types of activities are:

The available types of transitions are:

There are three association types available:

When inserting new lane into the graph using the toolbar buttons, the new participant on the package level is created, and its type is "Role". To change the participant type double click on the swimlane title to get its property panel.

The lanes for already existing participant can be inserted by using the choice button from the top of the graph component. The lane will be inserted at the bottom of the Pool (or at the bottom of the already selected lane - this will be nested lane in that case).

Free text expression lane and Common expression lane are not representing participants but it is a special visualization of performer expressions for activities.

The Graph represents activity performers as swimlanes. When an activity is inserted or moved into a particular swimlane, it's performer will be updated to the participant represented by the swimlane. In the case of Common expression and Free text expression participants the activity's performer will be set to the expression defined as a property of the graph's common expression participant swimlane object. When the activity is inserted or moved into the free text expression participant any expression can be set for the activity performer field but by default performer expression won't be defined.

Together Workflow Editor allows you to nest lanes thus making possible to visually represent organizational structure. To nest one lane into another, select the parent lane and then create new lane either by selecting the participant it will represent using the lane choice button , or by selecting one of the lanes buttons (, , ) and pressing on the wanted parent lane. Here is a sample of the process with a Pool that contains nested lanes:

Figure 4.7. Nested lanes sample

Normal activity enables you to insert an activity that will be performed by a human (so called manual activity) - it will appear in the user's worklist.

Task-Applicationl activity enables the definition of applications that are required for the enactment engine to run in order to perform the activity.

Subflow activity is a type of activity whose implementation is another workflow process definition.

Block activity executes an ActivitySet (set of self-contained activities/transition maps). It is something like an embedded subflow process.

Route activity, in the forms of Exclusive and Parallel gateways, does not implement any action. It is used for synchronization and conditional branching only.

A transition binds two activities but it can also be a circular transition from a certain activity to itself. A straight line with an arrow pointing to the target object represents the transition in the Graph. Depending on the transition type, it will have a different color or additional graphical descriptions according to BPMN specification. The toolbar offers several kinds of transitions: the one describing uncontrolled flow , the one describing conditional flow (a circle on the left will be drawn according to BPMN spec only in the case the source of the transition is not a gateway), the one describing default flow (otherwise transition) and two kinds of exception transitions and (default exception). The type of a transition can be changed through its property panel.

There are two types of artifacts that can be inserted into the graph, data object artifact and text annotation . Artifacts describe e.g. document flow through the process, or make some comment that should be visible in the graph. The artifacts has to be connected to the activities using associations.

Associations are connecting an artifact with an activity. There are three types of associations offered by the TWE, directional , non-directional and bi-directional . The type of association can be changed through its property panel.

The Graph configuration is done through the togwegraphcontroller.properties file.

The following parameters can be set:

As with all other components, you are also able to change the content of the toolbar and the order of toolbar buttons.

The XPDL view provides an XPDL text view of the selected elements. It shows the structure of the selected XML element as it will be saved in the XPDL file. Every time the selection is changed or a selected element is being updated, the XPDL View is automatically updated also.

If the selected element is a whole XPDL package then the XPDL View displays the whole package definition in the exact form as it will be written into the XPDL file (when the document is saved). Otherwise the XPDL View will display the part of the XPDL which holds the definition of the selected element. So, when a particular process is selected, the XPDL view displays the process definition part of XPDL as it will be written to the XPDL file, etc.

The following examples show different XPDL Views depending on the element type that is currently selected:

Figure 4.8. XPDL View of a Package

Figure 4.9. XPDL View of a Process

Figure 4.10. XPDL View of an Activity

The XPDL view also offers a search box for finding desired text fragments in the currently shown XPDL fragment.

The Navigator displays a hierarchical view of the XPDL model. It shows packages, processes, activity sets and activities. It is also very useful for finding XPDL elements which are not valid according to the XPDL specification. These elements will be marked with error () or warning () icons. The Navigator makes navigation through the XPDL model easier and offers a good way of element selection. It can also ease editing of XPDL by opening property dialogs directly from the elements in the tree. The available actions in the Navigator toolbar are expand all and collapse all. When expand all is selected the hierarchical tree will be expanded so that every element is visible. When collapse all is performed, only top element(s) will be made visible. A right mouse click on tree will display a popup menu. Besides the standard edit functions (cut, copy, paste, delete and edit properties) there are Expand all, Collapse all, Duplicate and References. Expand all and Collapse all will act like the actions on the toolbar with the selected element used as the root element of the action. So Expand all will make all children of the selected element visible. Duplicate will create a copy of the selected element. The only difference will be in the element id and name attributes (if they exist) which will get new values. The References action will search for references to the selected element in the whole XPDL model.

The background and the selection colors can be set through the packagenavigator.properties file.

BackgroundColor. Values: R=?,G=?,B=? (where ? represents an integer from 0 to 255).

and

SelectionColor. Values: R=?,G=?,B=? (where ? represents an integer from 0 to 255).

As with all other components you are also able to change the content of the toolbar and the order of toolbar buttons.

Similar to the Navigator the Package tree also displays a hierarchical view of the XPDL model. The difference between these two trees is the level of details. While the Navigator just shows packages, processes, activity sets and activities, The Package tree shows almost every element of the XPDL model.

The Package tree offers the most detailled hierarchical view of the XPDL model. It graphically displays the whole hierarchy tree of all XPDL elements of the model you are editing, Id attributes, names, the package header, etc.

The Package tree makes navigation through the XPDL elements easierIt can also ease editing of XPDL by opening property dialogs directly from the elements in the tree. The available actions in the Package tree toolbar are expand all and collapse all. When expand all is selected the hierarchical tree will be expanded so that every element is visible. When collapse all is performed, only top element(s) will be made visible. A right mouse click on tree will display a popup menu. Besides the standard edit functions (cut, copy, paste, delete and edit properties) there are Expand all, Collapse all, Duplicate and References. Expand all and Collapse all will act like the actions on the toolbar with the selected element used as the root element of the action. So Expand all will make all children of the selected element visible. Duplicate will create a copy of the selected element. The only difference will be in the element id and name attributes (if they exist) which will get new values. The References action will search for references to the selected element in the whole XPDL model.

The Package tree component can be configured through detailpackagenavigator.properties file.

You are able to customize the Package tree in order to hide some complex element's sub-elements. For example: To hide Activity's Id, Deadlines, Priority and Limit, you should set the property

HideSubElements.Activity

to the following value:

HideSubElements.Activity = Id Deadlines Priority Limit

You are also able to customize which elements of some collection shouldn't be displayed. For example: To hide extended attributes which name attribute is "SpecEA" or "EASpec", you can define the property:

HideElements.ExtendedAttributes.Name = SpecEA EASpec

If you want to hide all elements use *. For example: To hide all extended attributes use:

HideElements.ExtendedAttributes.Name = *

As with all other components you are also able to change the content of the toolbar and the order of toolbar buttons.

Properties component displays selected XPDL element's properties.

Figure 4.11. Properties component

By selecting an element, this component automatically displays the most relevant data about that element (such as name, id etc.).

Besides data, this component also offers a couple of operations:

	Displays properties of previously selected element (that element again becomes selected).
	Displays properties of element selected after this element selection (the following element again becomes selected).
	Discards new values of properties (reverts to the values applied with last 'apply' action call).
	Applies new values of properties.
	Opens a dialog with a full set of the properties for the displayed element.
	Shows parent XPDL element panel.

This component can be configured through propertiespanelcomponent.properties file.

There are properties which can be adjusted to fine-tune the basic element property panels L&F, such as alignment, TOP, BOTTOM, RIGHT, LEFT empty space in the panels, the width and height of the text boxes, etc. These are defined by the following set of the properties:

XMLBasicPanel.RightAllignment=false
XMLBasicPanel.EmptyBorder.TOP=0
XMLBasicPanel.EmptyBorder.LEFT=3
XMLBasicPanel.EmptyBorder.BOTTOM=4
XMLBasicPanel.EmptyBorder.RIGHT=3
XMLBasicPanel.SimplePanelTextWidth=250
XMLBasicPanel.SimplePanelTextHeight=20

You are able to customize so called "group" panels, used to display some complex elements, in order to hide some complex element sub-elements. For example, in order not to display Activity's Id, Deadlines, Priority and Limit, you should set the property

HideSubElements.XMLGroupPanel.Activity

to the following value:

HideSubElements.XMLGroupPanel.Activity = Id Deadlines Priority Limit

You are able to customize which elements of some collection shouldn't be displayed within so called "table" panels. For example, if you don't want to display extended attributes which name attribute is "SpecEA" or "EASpec", you can define the property:

HideElements.XMLTablePanel.ExtendedAttributes.Name = SpecEA EASpec

You are able to customize so called "table" panels, used to display some complex element collections, in order to specify which sub-elements will be shown as a table columns. For example, when displaying activities, you can specify to show Activity's Id, Name, Performer, Type, Start mode, Finish mode and Deadlines:

ShowColumns.XMLTablePanel.Activities = Id Name Performer Type StartMode FinishMode Deadlines

There is another customization possible for the so called "combo box" panel. Hence, you can define for which elements the combo box will be disabled (by default nothing is disabled). For example, if you want to disable combo boxes for displaying Activity's Performer and Transition's From and To properties, you should specify the following:

XMLComboPanel.DisableCombo = Performer From To

As with all other components, you are also able to change the content of the toolbar, and the order of toolbar buttons.

Search component displays results of a References or Search action. It shows all elements that have a reference to the selected element in the first case, or all the elements found based on entered criteria in second case. Results are shown in hierarchical view.

Figure 4.12. Search Results

Besides search results, this component also offers a couple of operations:

	Expands hierarchical results view.
	Collapses hierarchical results view.
	Clears the result page.

While left click on result select that element, right click will also bring popup menu. Popup menu has action for expanding and collapsing, bringing up properties and performing References action for selected element.

The background color could be changed through searchnavigator.properties file. (BackgroundColor = R=?,G=?,B=?)

As with all other components, you are also able to change the content of the toolbar, and the order of toolbar buttons.

Problems component lists all the problems currently present in the XPDL model(s). If option for design-time validation (found in togwecontroller.property) is set to 'true', this list will be automatically refreshed (except for schema errors).

Figure 4.13. Problems component

Results of action 'check validity' are also shown here, so if design-time validation is off, you can always re-check the XPDL model validity by calling this action from the Package's menu/toolbar.

The result table has five columns:

Clicking on Element column selects the exact element which has an error/warning described. By clicking on any other column, appropriate parent element will be selected (e.g. if error is with actual parameter, clicking on element will select actual parameter, while clicking on some other column will select activity) - as already explained, sometimes these two are the same.

On the other hand, double-clicking opens a dialog for editing problematic element.

There is also a possibility to sort entries by the column - just click to the column header, and entries will be sorted by this column.

Problem component background color could be changed through problemnavigator.properties file. (BackgroundColor = R=?,G=?,B=?)

As with all other components, you are also able to change the content of the toolbar, and the order of toolbar buttons.

Having this component, you are able to connect to a workflow engine which supports WfMC interface defined by WfMC, and to manage XPDL files on the engine.

To connect to a workflow engine, valid registry service URL must be entered. After you enter it, and press the button right to the URL, you should connect to the engine, and get a list of the process definitions already uploaded to the engine, as on the picture below:

Figure 4.14. WfXML Component

The toolbar for this component contains buttons for performing actions for managing XPDLs on the engine. The actions are described in the following table:

	Downloads XPDL from the engine.
	Uploads XPDL to the engine.
	Updates XPDL to the engine.
	Clears the history (which you are able to select from a combo box) of most recently entered URLs of WfXML compliant engines.

As with all other components, you are also able to change the content of the toolbar, and the order of toolbar buttons.

This component enables you to connect to the LDAP based system, search for users and groups and import them into XPDL as Participants.

Figure 4.15. LDAP Component

To be able to do this, you first need to configure LDAP parameters by selecting corresponding action from component's toolbar. This will bring you a dialog where you define how to access LDAP, names of attributes representing group and users, etc. as shown on the picture below:

Figure 4.16. LDAP Configuration Dialog

The toolbar for this component contains buttons for performing actions for managing LDAP access. The actions are described in the following table:

	Opens a dialog to configure parameters neccessary to connect to an LDAP and search for users and groups.
	Performs a LDAP search based on parameters entered in as a search criteria, and displays results in a table.
	Imports selected LDAP entries as XPDL Participants.
	Imports all LDAP entries as XPDL Participants.

As with all other components, you are also able to change the content of the toolbar, and the order of toolbar buttons.

The advantage of using "LDAP defined participants" is that one can connect the LDAP server of its organization and create processes using the real user/group logins for participant Ids. When the engine enacts such a process, it could also browse the LDAP server for the certain users/groups, so you do not have to do "participant to real user mapping".

The default LDAP properties can be defined in ldap.properties configuration file:

#LDAPReferralHandling = follow

#LDAPCountLimit = 0

#LDAPTimeLimit = 0

#LDAPPageSize = 1000

#LDAPHost=localhost

#LDAPPort=389

#LDAPBaseDN=

#LDAPObjectClassFilter=group

#LDAPObjectClassFilterChoices=group,organizationalUnit,organizationalRole,user,person,organizationalPerson,inetOrgPerson,AllListed

#LDAPSearchScope=SCOPE_SUB

#LDAPSecurityLevel=UserAndPassword

#LDAPSecurityUserDN=username@company.com

#LDAPSecurityPassword=somepwd

#LDAPGroupUniqueAttributeName=sAMAccountName

#LDAPGroupNameAttributeName=displayName

#LDAPGroupDescriptionAttributeName=description

#LDAPUserUniqueAttributeName=sAMAccountName

#LDAPUserNameAttributeName=displayName

#LDAPUserDescriptionAttributeName=description

#LDAPDistinguishedNameAttributeName=distinguishedName

#Toolbar.ActionOrder.defaultToolbar = ConfigureLDAP SearchLDAP - ImportSelected ImportAll

Standard dialog are dialogs for manipulation with input/output files.

Save or discard changes dialog

If changes made to the package are about to be discarded, the warning message appears asking if the changes should be saved. If the answer is "Yes", the current package will be saved. "No" will discard any changes since last save, and "Cancel" will drop out selected function.

File open dialog

This dialog offers file system browsing and choosing file to open. It is displayed when you want to open a new XPDL file for editing in TWE, when adding new external package reference, ...

Save As dialog

This dialog offers file system browsing and choosing the location where you want to save an XPDL file or process or activity set picture, as well as defining the file name and extension.

The most of the dialogs for editing XPDL elements have a toolbar with a buttons for navigation between property panels, as well as for applying/reverting the changes in the currently displayed property panel.

The toolbar buttons are:

	Shows previous panel.
	Shows next panel.
	Discards changes made after last apply action (reverts to previous state).
	Applies the changes made in the panel.
	Applies the changes made in the panel and closes the dialog.
	Shows parent element panel.

Each XPDL element is represented by appropriate property panel for editing its properties.

There are some standard panels like the ones for entering element information through the text box, by choosing an item from a combo box, for managing a group of elements through a table or a list, the group panels containing that contain other panels, tab panels, etc.

Each panel can be displayed separately, or inside a more complex panel such as a group panel.

Property panels that display any kind of a table or a list representing a group of the same kind of XPDL elements have toolbar with buttons to handle these elements. Elements may be processes, activities, activity sets, participants, transactions, applications, namespaces, workflow variables, type declarations, formal parameters, etc.

The toolbar is displayed just above the table/list of elements:

	Creates new element.
	Edits selected element.
	Deletes selected element.
	Duplicates selected element.
	Finds all other elements that are referencing selected element. The list of referencing elements is displayed within Search component.
	This action is available only for the FormalParameters and DataFields tables. It converts selected Formal parameter into a Data field object (workflow variable), or vice-versa.

When the element from the property table/list is selected, appropriate event is send to all other TWE components in order to refresh their view, and to show their view of the selected element. For example, if we have displayed a property table panel for handling activities, clicking on table rows, different activities will be displayed in all other TWE components - Graph, Overview, Navigator and Package tree components will mark this activity, and XPDL View component will show the part of XML structure representing selected activity. On the other hand, External package relations, WfXML, Search and Problems component won't update the display.

The toolbar buttons are either enabled or disabled, depending if the action they are representing can or can't be performed on the current selection.

The meta-model identifies the basic set of entities and attributes for the exchange of process definitions.

Figure 6.1. Package Meta-Model

For each of the above entities, there is an associated set of attributes (some mandatory and others optional) which describe the characteristics of the entity. If there is a need of using an additional characteristics, "extended attributes" for various entities may be defined to allow extension of the scope of the Meta-Model in a controlled manner.

All those entities except "Message Flow" and "Group" type artifacts are maintained by TWE. The current version of TWE is written as an XPDL 1 extension towards XPDL 2, and still does not support the whole XPDL 2 Meta-Model but only the parts necessary to support simple BPMN conformance, and still to allow workflow engines to execute XPDL 1 "migrated" process definitions.

"Resource Repository " is external to the workflow process definitions. In some complex processes, participant declaration may refer to a resource repository, which may be on Organisational Model (OM). WfMC Meta-Model specification defines a simple in-built (Minimal) Organisational Model or permits access to an externally defined OM. Note that XPDL specification does not define or require a resource repository.

TWE works only with a Minimal Organisational Model so there is no external Organisational Model provided. In this model, there aren't any relationships between participants. TWE may refer (import) any external XPDL structure - External Package. That External XPDL file may contain whole Organisational Model, so that External Package can act like Resource Repository.

As it is shown in the previous picture, minimal process model includes various entities whose scope may be wider than a single process definition. In particular the definitions of participants, applications and workflow relevant data may be referenced from a number of process definitions. The Meta-Model assumes the use of a common process definition Resource Repository. Repository holds the various entity types comprising the process definition. Within the repository itself and to support the efficient transfer of process definition data to/from the repository, the concept of a PACKAGE is introduced, which acts as a container for the grouping of common data entities from a number of different process definitions, to avoid redefinition within each individual process definition. Each process definition contained within the package will automatically inherit any common attribute from the process model container, unless they are separately re-specified locally within the process definition.

It is possible to define several processes within one package, which may share the same tools (applications) and participants.

The Package acts as a container for grouping together a number of individual process definitions and associated entity data, which is applicable to all the contained process definitions.

You can chose to create one package per workflow process, which should contain all the necessary workflow processes as well as all the associated tools (workflow applications) and workflow participants. Another approach is to define just parts of one process definition or common parts of several processes within one package (e.g. a workflow participant list or a workflow application list), and then to reference it from other packages. Within a package, the scope of the definitions of some entities is global and these entities can be referenced from all workflow process definitions contained within the package. Those entities are:

TWE provides a way to manage above listed entities (within one package). On Figure 4.3, “Main tool bar shortcut groups”, you can see where is the toolbar part for handling the properties of the selected Package.

To create a new Package in TWE, you simply select File->New, or click appropriate button in the toolbar (the first button on the left). If you are currently editing some other XPDL file and there are some unsaved changes there, prior to creating a new Package, TWE will ask you if you want to save the changes.

It is important to say that actions represented by buttons shown on the toolbar picture (and also corresponding menu items) are applied to the currently selected package, which can be the main one or one of the externally referenced packages.

If you select the main package, you can modify its properties, but this is not possible for the external packages. Those external packages are read-only, and you can only read their properties.

Package property panel

In TWE, the icon from package toolbar (or package menu) is used for defining above mentioned properties, as well as all other package properties and sub-elements, through appropriate property panels. Also, you can get property panel for any Package element by selecting it in Package tree component, and choosing Properties action from the edit menu or toolbar.

Package property panel contains a lot of different data about the main XPDL element - Package. Actually, you are able to access almost any XPDL element panel by navigating through the Package properties panel. All information are organized in several tabs: general, package header, redefinable header, external packages, type declarations, participants, applications, workflow variables, pools, associations, artifacts, workflow processes and namespaces

All the tabs that will be mentioned can be also displayed as a separate property panels.

General tab - displays general package data

Tab has tree parts. First part contains package's id, name and graph conformance. As already mentioned, TWE supports and validates XPDL depending on specified conformance level. Second part contains information about script language: type, version and grammar. Third part displays list of package's external attributes and offers toolbar with operations to handle extended attributes

Package header tab

Default value for field XPDL version is 2.1, and for field vendor is (c) Together Teamsolutions Co., Ltd. Field Created contains creation time and date, and field Description contains short package's description. Documentation field binds external file with package. button opens a choose file dialog for finding appropriate one.

Redefinable header tab

Tab has two parts. First part contains the following fields: Publication status (can have one of the following values: under revision, under test, or released), Author (package's author), Version (version number for the package), Codepage and Country key. As already mentioned, TWE lets you save your work despite the errors if you didn't set Publication status to Released. In the case you've set it to released, it won't be permitted to save your work until you correct all the errors. This behaviour can be configured in togwecontroller.properties file, by setting the value of property AllowInvalidPackageSaving to true.

Second part, called Responsibles, contains list of all responsibles for the package and operations for managing the list. Any participants known to this package can become the responsible.

When you press the button for defining new responsible, this action invokes a window with a combo box with a list of all possible participants you can chose.

Responsible person must be a participant that is already defined. When adding "Responsibles" for the whole package, participants defined inside that package or inside externally referenced packages can be added, and when adding "Responsibles" for a process, you can also add participants defined for this process.

Beside the combo box with a list of the responsibles, there is a shortcut button. If you press this button, the property panel for the participant selected in combo box will be shown.

External packages tab

It contains a list of all external packages for the package and toolbar buttons for managing the listed external package elements.

Type declarations tab

It contains information about all type declarations in a form of a table and operations for their managing. Each table row (type declaration) is described with id, name (optional value) and type. It contains toolbar buttons for managing the listed type declaration elements.

Participants tab

It contains information about all package's participants. Each table row (participant) is described with id, name (optional value) and participant type. It contains toolbar buttons for managing the listed participant elements.

Applications tab

It contains information about all package's applications. Each table row (application) is described with id and name (optional value). It contains toolbar buttons for managing the listed application elements.

Workflow variables tab

It contains information about all package's workflow variables. Each table row (workflow variable) is described with id, name (optional value) and data type. It contains toolbar buttons for managing the listed workflow variable elements.

Associations tab

It contains information about all associations between Artifacts and Activities defined in the Package. Each table row is described with id, name (optional value) , source and the target of an association and association direction. It contains toolbar buttons for managing the listed elements.

Artifacts tab

It contains information about all artifacts defined in the package. Each table row is described with id, name (optional value), artifact type and text annotation (optional value). It contains toolbar buttons for managing the listed elements.

Pools tab

It contains information about all the package's pools for workflow processes. Each table row (pool) is described with id, name (optional value), orientation, process (a reference to the process or activity set) and Lanes. TWE does not allow creation or removal of the pools. Whenever new Workflow process is created or removed, corresponding pool gets created/removed. There is a toolbar where only the button that allows to edit the pool properties is enabled.

Workflow processes tab

It contains information about all package's workflow processes. Each table row (workflow process) is described with id, name (optional value) and Access level (optional value, can have one of the values: private or public). It contains toolbar buttons for managing the listed workflow process elements.

Namespaces tab

This property panel shows all namespaces defined within the XPDL document. User can add additional namespaces. Usually, additional namespaces are needed to insure document validity when user defines "complex" extended attributes. It contains information about all package's namespaces in a form of a table and operations for their managing. Each table row (namespace) is described with name and location. It contains toolbar buttons for managing the listed namespace elements.

The Process Definition entity provides contextual information that applies to other entities within the process. This describes the process itself. It is a container for the process itself and provides information associated with administration (creation date, author, etc.) or to be used during process execution (initiation parameters to be used, execution priority, time limits to be checked, person to be notified, simulation information, etc.). Definition entity thus provides header information for the process definition and is therefore related to all other entities in that process.

Figure 6.2. Workflow Process Meta-Model

The Workflow Process Definition defines the elements that make a workflow. It contains definitions or declarations, respectively, for Activity and, optionally, for Transition, Application, and Process Relevant Data entities.

A Workflow Process may run as an implementation of an activity of type subflow; in this case parameters may be defined as attributes of the process.

TWE provides a way to manage process definition entities. On Figure 4.3, “Main tool bar shortcut groups”, you can see where is the toolbar part for handling the propertiesOn Figure 4.3, “Main tool bar shortcut groups” you can see the organization of the selected WorkflowProcess.

If you create (override) some process with the same Id as the one from the external package, only the one from the current package can be used as the implementation process of sublfow activity.

Typically, you will create a new process by pressing the button from the main toolbox or selecting appropriate item from Package menu.

Workflow Process property panel

In TWE, you can get the property panel to edit all workflow process attributes by clicking on a toolbar icon , or selecting the appropriate menu item.

It contains a lot of different data about workflow process. All information are organized in several tabs: general, process header, redefinable header, participants, applications, workflow variables, formal parameters, activities, transitions and activity sets.

All the tabs that will be mentioned can be also displayed as a separate property panels, either by selecting appropriate element in a Package tree, and asking for its properties, or by selecting appropriate toolbox button or menu item.

General tab - displays general process data

Tab has two parts. First part contains process id, name (this name will appear in window's title bar) and access level (can be private or public). Second part shows all process extended attributes and also offers operations with them.

Process header tab

This dialog defines elements and attributes of XPDL's ProcessHeader element. Field Duration unit can have one of the following values: second, minute, hour, day, month, year. Field Created displays the process creation date and field Description is place for short description of this workflow process.

Redefinable header tab

Tab has two parts. First part contains the following fields: Publication status (can have one of the following values: under revision, under test, or released), Author (author of the process), Version (version number for the process), Codepage and Country key. Second part, called Responsibles, contains list of all responsibles for the process and operations for managing the list.

Participants tab

It contains information about all participants of the workflow process. Each table row (participant) is described with id, name (optional value) and participant type. It contains toolbar buttons for managing the listed participant elements.

Applications tab

It contains information about all applications of the workflow process. Each table row (application) is described with id and name (optional value). It contains toolbar buttons for managing the listed application elements.

Workflow variables tab

It contains information about all workflow process's workflow variables. Each table row (workflow variable) is described with id, name (optional value) and data type. It contains toolbar buttons for managing the listed workflow variable elements.

Formal parameters tab

It contains information about all workflow process's formal parameters. Each table row (formal parameter) is described with id, mode and data type. It contains toolbar buttons for managing the listed formal parameter elements.

Activities tab

It contains information about all activities of the workflow process. Each table row (activity) is described with id, name (optional value) and performer (optional value). It contains toolbar buttons for managing the listed activity elements.

Transitions tab

It contains information about all workflow process's transitions. Each table row (transition) is described with id, from (source), to (target) and condition (optional value). It contains toolbar buttons for managing the listed transition elements.

Activity sets tab

It contains information about all activity sets of the workflow process. Each table row (activity set) is described with id, activities and transitions. It contains toolbar buttons for managing the listed activity set elements.

Swimlanes are used to facilitate the graphical layout of a collection of processes and the activities they contain. They may designate participant information at the process level and performer information at the activity level. The Swimlane structure is depicted by a collection of non-overlapping rectangles called Pools. Each Pool may be further subdivided into a number of Lanes.

Pools

A Pool acts as the container for flow objects (activities and artifacts) and Sequence Flow (transitions and associations) between them. Together Workflow Editor does not allow users to create or remove a pool. Pool is automatically being created or deleted whenever workflow process gets created/deleted. The property panel for the pool shows the pool attributes which are editable, except the text field that displays the Id of referenced Workflow Process/Activity Set, and has only the link button to display the properties of the referenced Workflow Process/Activity Set.

Lanes

Lanes are used to subdivide a Pool. All the activities within a Lane may inherit one or more properties from the Lane. A typical use of this is to give the Lanes "role names" and have the Activities inherit these role names as "Participant assignment/Performer expressions".

Together Workflow Editor does not allow users to create lanes using properties dialogs. The only way to create or delete a lane is by using TWE's Graph component. Lane is always being created as a representation of the Participant. Lanes are implicitly created whever user wants to insert a lane representation for the existing or a new participant into the graph. When activity is put into the lane (using graph component), the activity's performer becomes the participant which is a representation for that particular lane. As described in the section called “Graph” , TWE also alows nesting of lanes. The property dialog of the lane shows lane properties Id, Name, Performers and Nested Lanes. The Id and the name are editable fields. The performer of the lane is also editable. You can change the performer of the lane to link it with an another participant, or you can write your own expression for the performer. which are editable (including a performer of the lane), but you can not add or the remove the performer of the lane. The Nested Lanes can't be added or removed as well (it is possible only through the Graph component).

External package concept allows you to re-use common Participant, Application and WorkflowProcess definitions contained within other Package definitions. You just need to define these common entities ones, and store it within a XPDL file, and then re-use it afterwards in all other XPDLs you create

TWE provides possibility of referencing external Packages. After referencing it, automatically, every participant, application, type declaration or workflow process defined there in will be accessible from the main package.

If external package we referenced also contains the references to other external packages, all of the package references will be imported in TWE in read-only mode.

TWE's External package relations component will show the relations of the main package external packages, their external packages, and so on.

Adding External Packages

This dialog appears when you press the package toolbar button, or Package menu item for adding external packages . It enables you to select the XPDL file from your disk, and to reference it as an external package for the package you are currently editing. As already mentioned, after adding external package, you are able to use participants, applications and workflow processes defined in that package. NOTE: You can't add external package if the main XPDL package you are working on is not yet saved to the disc.

Removing External Packages

Action Remove external packages from the toolbox, or External packages menu removes external package from the current package.

If this external package is not referenced by any other external package of the main package, it will be really removed from TWE's memory. In the case some of the elements from this external packages are in use (Applications, Participants or WorkflowProcesses), you'll be asked for the confirmation.

The external package mechanism allows packages and its elements (applications, processes and participants) to be multiple referenced. Before the removement of the selected external package, if it contains any element that is referenced, and the external package reference that will be deleted is the last one, the warning message about removement of the external package is displayed.

External Participants

To get the following dialog, click button (or appropriate menu item from External Packages menu).

This dialog shows all participants of package's external packages. Every external participant is presented with its Id, Name (optional data), Participant Type and Description (optional data).

External Processes

To get the following dialog, click button (or appropriate menu item from External Packages menu).

This dialog shows all workflow processes of package's external packages. Every external process is presented with its Id, Name (optional data) and Access level (optional data).

External Applications

To get the following dialog, click button (or appropriate menu item from External Packages menu).

This dialog shows all applications of package's external packages. Every external application is presented with its Id, Name (optional data) and Description (optional data).

External Type Declarations

To get the following dialog, click button (or appropriate menu item from External Packages menu).

This dialog shows all type declarations of package's external packages. Every external type declaration is presented with its Id, Name (optional data) and Description (optional data).

WfMC assumes a number of standard data types (string, reference, integer, float, date/time, etc.); such data types are relevant to workflow relevant data, system or environmental data or participant data. Expressions may be formed using such data types to support conditional evaluations.

Sometimes set of data types that XPDL provides won't be enough, or you want to represent some data type with a special name to easily use it when defining Formal/Actual parameters. This XPDL feature allows you to declare new data type.

Attributes for TypeDeclaration are:

This property panel shows an example of a type declaration. This panel can be get e.g. by selecting an existing TypeDeclaration in a Package tree, and asking for its properties. To create a new TypeDeclaration, you can press button which will bring you the property panel with all defined Type declarations for the package. There in, you can press a button for creating new Type declaration. TWE maintains all of WfMC data types that are provided: BasicType, DeclaredType, ShemaType, ExternalReference, RecordType, UnionType, EnumerationType and ArrayType.

The following table describes the basic data type:

External Reference data type has the following attributes:

Using External Reference data type you may define e.g. some Java class as a new data type (for e.g. location = "com.abc.purchases.PO").

WfMC Meta-Model specification defines a simple in-built (Minimal) Organisational Model or permits access to an externally defined OM. Participants in TWE are just part of an Organisational Model - Minimal OM. The connection with the Organisational Model is used in Activity Definition (performer of an activity) and in the Process Definition (responsible of a process).

Workflow Participants have a scope and visibility equivalent to extended attributes. All referenced Workflow Participants have to be defined in the scope where they are used, at least in the same package.

The Workflow Participant is defined by a type and related information, which is a set of type specific attributes. This definition contains a basic set of 6 Workflow Participant types: resource set, resource, organizational unit, role, human, or system. A role and a resource are used in the sense of abstract actors. This definition is an abstraction level between the real performer and the activity, which has to be performed. During run time these abstract definitions are evaluated and assigned to concrete human(s) and/or program(s).

These attributes are used to define a Workflow Participant:

The Participant entity type attribute characterizes the participant to be an individual, an organisational unit or an abstract resource such as a machine. Here is a list of possible participant types:

TWE provides the way to define participants at Package level and at Process Definition level. In order to do that, you can select appropriate toolbar button or menu item for showing all the participants defined at package/process level. This will bring a table property panel, where you'll have a button for creating a new participant.

You are able to insert the lanes representing all the defined participants into a TWE graph using the following choice button from graph's toolbar , and it'll be represented as a new swim-lane in a graph. Then, you can put the activities (and artifacts) in there, which actually means that activity's performer is the participant represented by the swim-lane. Even if you do not define any participant, TWE's graph component has special lanes that can be used to define activity's performer as an expression (can be created by toolbar buttons and ). All the activities which performer is not a reference to an existing Participant will be graphically displayed inside those special graph swim-lanes. There is another way of defining Package level Participants, and this is by using a Graph's toolbox button. Pressing this button , and than clicking in the graph will automatically add another participant represented as a new swim-lane in currently selected WorkflowProcess's graph. This participant's type will be Role, and you can change it through the property panel.

These are some of the attributes for application entity which are defined by WfMC specification:

There is more than one way of getting Workflow Application Declaration settings. One way would be choosing an icon at main toolbar. Another way would be selecting Package's Applications in a Package tree component, and then right clicking and selecting Properties action (or directly selecting this action from Edit menu). User can create new instance for application entity, edit some existing application or delete it (modification and deletion of application entity is not allowed if it is the entity from externally referenced package). The picture on the right shows a property panel for editing application attributes. Workflow applications that are defined for the package are accessible by any activity that is defined at any package's workflow process. When defining a Tool for an activity, you'll be able to chose amongst all applications defined inside the particular WorkflowProcess definition, Package definition, or inside definition of the Package's external packages. If the application from the process level has the same Id as the one from the package level (it overrides the one from the package level), the one from the package level won't be displayed. The same stands for overriding the application from external package.

As it is shown on the picture, there are two choices for Invocation Parameters:

Formal Parameters

Formal Parameters are parameters that are interchanged with the application via the invocation interface. They are passed during invocation and returned of control (e.g. of an invoked application or invoked sub-process). The order of formal parameters can be changed by dragging an item with the mouse. Using appropriate toolbar buttons, you can create a new FormalParameter, edit, delete or duplicate selected one, as well as to get all the references to the selected FormalParameter.

The attributes that define Formal Parameter are:

Table 6.15. Formal Parameter

Name	M/O	Description
Id	M	Identifier for the parameter
Mode	M	IN Input Parameters OUT Output Parameters INOUT Parameters used as input and output
Name	O	Name of the parameter
Is Array	O	If it is an array type
Data Type	O	Data type of the formal parameter
Initial value	O	Initial value for parameter
Description	O	Textual description of the formal parameter
Length	O	The length of the data.

Workflow Relevant Data (or, in XPDL, Data Field) represent the variables of a Process Definition or Package Definition. They are typically used to maintain decision data (used in conditions) or reference data values (parameters), which are passed between activities or sub-processes. The workflow relevant data list defines all data objects, which can be used within the workflow process. The attribute TYPE explicitly specifies all information needed for a workflow management system to define an appropriate data object for storing data, which is to be handled, by an active instance of the workflow process.

Workflow Relevant Data can be defined in a Workflow Process (the Workflow Process Relevant Data) and in a Package (the Package Relevant Data). The scopes differ in that the former may only be accessed by entities defined inside that process, while the latter may be accessed by entities inside any process defined within that model.

Workflow Relevant Data has a scope that is defined by the directly surrounding meta-model entity and is not nested. The visibility of its identifier is also defined by that entity.

Attributes of Workflow Relevant Data are:

When parameters are passed to a called subflow outside the current model definition, it is the responsibility of the process designer(s) to ensure that data type compatibility exists across the parameter set.

Workflow relevant data naming must be unique within a process model. If such data is passed between processes as parameters, the convention at this version of specification is that copied semantics will be used. Responsibility rests with process designers / administrators to ensure consistent name / datatype usage within process definitions / models to support sub-flow operations (including any required remote process interoperability).

There is an icon in Package's part of the Toolbar and icon in process's part of the toolbar, and also on appropriate menus, for displaying all workflow relevant data for the selected Package/WorkflowProcess.

Like other similar table property panels, amongst others, there are also buttons "New" and "Edit" for adding new or editing existing Workflow Relevant Data. The picture on the left shows property panel for editing Workflow Relevant Data. When defining (or editing) an workflow variable, the following attributes can be set: id (mandatory attribute), name, initial value , length, IsArray (array indicator), Type, description and extended attributes. The attribute Type explicitly specifies all information needed for a workflow management system to define an appropriate data object for storing data, which is to be handled, by an active instance of the workflow process. If you are at process level, and you create (override) some workflow relevant data with the same Id as the one from the package level, only one of them (the one from the process level) can be used as a reference from other entities. E.g. you can choose just the one from the process level to be the actual parameter for some application or subflow.

XPDL contains most of the entities, which are likely to be required in the process definition modelling. Sometimes, there is a need for some additional information (user or vendor specific). Extended Attributes are the primary method to support such extensions. These are attributes defined by the user or vendor, where necessary, to express any additional entity characteristics.

TWE provides use of the Extended Attributes like follows: you can define "simple" part of Extended Attribute by entering Name and Value attributes. If you want to define "complex" part of Extended Attribute, which could be consisted of tags that belong to the XPDL or some other namespace, you have to enter it as a free-text in the Complex content field. The picture on the left shows property panel representing extended attribute. When defining new ExtendedAttribute (or modifying one already defined), user has possibility to choose its name amongst the names of extended attributes already defined for that element type (Activity, Participant, ...). The list of names depends on the names already defined in opened XPDL (and its externally referenced XPDLs). The list of names is refreshed each time new ExtendedAttribute is being added or when one already defined is being re-defined or deleted.

An activity set is a self-contained set of activities and transitions. Transitions in the set should refer only to activities in the same set and there should be no transitions into or out of the set. Activity sets can be executed by block activities.

Typically, you will create a new activity set in the WorkflowProcess using Graph component's toolbar icon for doing that. Previously you must insure that the graph for the WorkflowProcess where you want to insert the activity set is visible. The picture on the right shows property panel for editing ActivitySet. Every activity set is presented with its Id, activities (number of activities in the activity set) and transitions (number of transitions in the activity set). As you can see, there is only one attribute to define, and that is the Id. There are two tables where you can see short description of all activities and transitions already defined for this ActivitySet. As with other table panels, you are able to manage them.

Generally, any process comprises a number of steps, which lead towards the overall goal. Workflow process consists of a number of workflow activities. The workflow activity is a piece of work that will be done by combination of resources and computer applications.

Activities are associated with their performers (which are workflow participants), and application assignments. Optional information about activity may be associated with: starting and stopping manner, usage of specific workflow relevant data, preconditions for starting and postconditions for finishing the activity.

The following diagram illustrates the generic structure of activities:

Figure 6.3. Generic Structure of Activities

Activities and other activity-like objects are inserted using buttons on graph's "Toolbox" toolbar.

Activities and Graph component

Although it is possible to create a new activity through the property panels, the usual way to do it is through the graph component.

The following table shows the picture of how the graph represents a certain XPDL activity type, and short description of each type of the activity:

	Start event activity - the place where the process begins.
	End event activity - the place where the process ends.
	Manual (No implementation) activities are atomic (Generic Activities). They are the smallest units of work, although even this activity may produce more than one work item for its performer.
	Task-Application activities are atomic (Generic Activity). They are the smallest units of work.
	Subflow is another activity type. It implements a whole new workflow process. Process definition within the subflow is entirely independent from the first one (where subflow activity resides). It has its own set of activities, internal transitions, participants, application definitions and other workflow relevant data. When clicking on the box with the "plus" sign, the graph of the sub-flow gets shown.
	An activity may be a block activity that executes an activity set , or map of activities and transitions. Activities and transitions within an activity set share the name space of the containing process. When clicking on the box with the "plus" sign, the graph of the activity set gets shown.
	Dummy (route) activity does nothing on its own. This type of activities is used for exclusive synchronization and constructing complex and sophisticated "exclusvie" transitional conditions
	Dummy (route) activity does nothing on its own. This type of activities is used for parallel synchronization and parallel (unconditional) branching

Icons for inserting different types of activities from the graph toolbox are the same as the ones included in the previously explained picture of the activities in the graph. Graph's toolbox icon for inserting Start event activity into the graph is and for inserting End event activity into is . For the manual activity, there is a toolbox icon , for Tool activities , for subflow activities, for block activities and for route activities (for exclusive gateway route activity) and (for parallel gateway route activity). Once selected, mouse cursor will show what type of object you'll insert. Activity is created using some default values for their properties, which typically are to be changed. Right clicking the object in the graph shows a context menu, and there is item representing action for getting property panel. Different than others, Block and SubFlow activities have additional menu item "descend into..." which is used to display the graph of the referenced ActivitySet/Workflow Process.

Beside this, TWE offers a special feature to select an Icon for particular activity. When you open activity's property panel, for the Icon entry you can select some of the additional Icons we offer (this list can be easily extended by putting more icons in tweactivityicons.jar file). The selected icon will appear instead the default one.

Activity property panel

In this section are explained various property panels concerning different types of activities: activities without implementation (manual), sub-flow, route, tool and block activities. All information are organized in several tabs: general, type, transition restriction, simulation information, and extended attributes.

General tab - displays general activity data

Tab has tree parts. First part contains activity id, name, performer (can be a reference to a participant or an expression), start mode (can be automatic or manual) and finish mode (can be automatic or manual). Second part shows all deadlines and also offers toolbar buttons with options to handle list of deadlines. Third part contains priority (describes initial priority for activity), limit (expected duration - for time management purposes), icon (reference to the icon representing this activity), documentation (reference to an external document) and description. Fields icon and documentation have drop down list to select one of the offered icons. If selected, this icon will replace the original one representing this activity within the graph. (the list of available icons can be extended by putting additional icons within the tweactivityicons.jar file)

Type tab

This tab contains some specific data concerning the particular type of an activity. For activities without implementation (manual) this tab doesn't contain any specific data.

Block activity type property panel contains information about activity set id, which is a reference to defined ActivitySet (re-usable block of activities and transitions which shares the context of the workflow process where defined). A block activity executes referenced ActivitySet or self-contained activities/transitions map. When block activity is being executed, the execution proceeds to the first activity within the ActivitySet it references, and continues within the set until it reaches ActivitySet's exit activity (an activity with no output transitions). Execution then returns to follow the output transitions of the block activity.

Task-application activity property panel enables to define a reference to the application required for enactment engine to run, in order to perform the activity. Basically, this tab allows you to pick the desired application by selecting it from the combo-box, and then allows definition of actual parameters (variables or expressions) to pass to the referenced application depending on its formal parameters.

Subflow is type of activity whose implementation is another workflow process. Firstly, attribute id should be set. Id defines workflow process that will be executed. In TWE you are setting this attribute by picking the one of the WorkflowProcesses defined within the combo box. Beside the combo, you have a shortcut to display the properties of the WorkflowProcess selected within the combo. Then, execution (mode) attribute should be set. Synchronous execution mode suspends execution of calling process until sub-flow is finished. Asynchronous mode, spawns a new thread of execution for sub-flow process, which is then executed at its own pace, independently from calling workflow process. While entering actual parameters that will be passed to subflow process, TWE shows the list of corresponding formal parameters of the referenced sub-process.

When gateway (routing) activity is selected, type tab allows to change the gateway type from parallel to exclusive or vice-versa. In the case of exclusive gateways with more than one outgoing transition from the gateway, the order of calculating outgoing transition conditions is important. This order is determined in XPDL by the order of TransitionRef elements within its TransitionRefs collection. From here, you can control that order. The way of doing it is to simply change positions of the target activities (the activities that outgoing transitions are leading to) within the given list.

Simulation Information tab

Here are defined various information about simulation: whether the activity is instantiated once or multiple times, cost, waiting and working times and duration.

Extended Attributes tab

It contains information about all extended attributes of the selected activity in form a of a table and operations for their managing. Every table row (extended attribute) is described with name and value.

To satisfy additional modeling concepts that are not part of the basic set of flow elements (activities and transitions), BPMN provides the concept of Artifacts that can be linked to the existing Activity object through Associations. Thus, Artifacts do not affect the basic sequence flow, nor do they affect mappings to execution languages.Artifacts are used to show additional information about a Process that is not directly related to its sequence flow.

At this point, BPMN provides three standard Artifacts: A Data Object, a Group, and an Annotation. TWE currently allows you to use the first two types of artifacts.

An Artifact is a graphical object that provides supporting information about the Process or elements within the Process. However, as mentioned, it does not directly affect the flow of the Process. BPMN provides a specific graphical representation for the different artifacts:

Figure 6.4. BPMN Notation for Artifacts

In BPMN, a Data Object is considered an Artifact because it does not have any direct affect on the sequence flow of the Process, but it does provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name - Data Object may imply an electronic document, it can be used to represent many different types of objects, both electronic and physical.

As an Artifact, Data Objects generally will be associated with activities. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process.

The following is a sample of process modeled with an artifact showing the information about the document flowing from one activity to another:

Figure 6.5. Artifact Sample

The following table shows the picture of how the graph represents different XPDL artifact type:

	Data object artifact.
	Text annotation artifact.

Icons for inserting different types of artifacts from the graph toolbox are for dataobject artifact, and for text annotation artifact. The picture on the right shows property panel for defining artifact properties.

Link between two activities is established by transitions. Transitions are more than just the links between activities. They also describe the condition that must be satisfied in order to get from the source to the target activity (This condition is evaluated during workflow execution).

Typically, you will insert the transitions using TWE's Graph component (although it is possible to do it through the property panels).

Graph component allows you to chose between conditional , unconditional , otherwise , exception and default exception transition for the insertion. If you want to insert a circular transition (a transition from activity to itself), you can chose the type of the transition you like, and double-click on the activity within the graph.

If insertion of the transition is not allowed by some rules (e.g. you can't insert two transitions connecting the same activities), you'll be notified or graph component will simply deny to insert such transition.

Here is the table of transition attributes:

The picture on the left shows a dialog for editing Transition attributes. TWE helps you when you are composing Transition condition - by clicking the arrow right to the text box for entering condition, you get a list of possible variables you can use within condition. Also, you can change transition from/to attributes by chosing another from the combo-boxes. There is a link next to those combo boxes to navigate to the selected Activity.

Link between activity and artifact is established by association.

An Association does not have a specific mapping to an execution language element. These objects and the Artifacts they connect to provide additional information for the reader of the BPMN Diagram, but do not directly affect the execution of the Process.

Typically, you will insert the association using TWE's Graph component (although it is possible to do it through the property panels).

Graph component allows you to chose between directional , non-directional and bi-directional association for the insertion.

If insertion of the association is not allowed by some rules (e.g. you can't insert two associations connecting the same artifact and activity, or you can't insert association between two artifacts or two activities), graph component will simply deny to insert such association.

Here is the table of transition attributes:

Picture on the right shows a dialog for editing Association attributes. You can change association source/target attributes by chosing another from the combo-boxes. There is a link next to those combo boxes to navigate to the selected Activity/Artifact.

This property file contains some basic TWE settings like:

This configuration file contains information about which component (Graph, XPDL View, Navigator, ...) will be used in a runtime. It also defines default tab area for the component, and default placement order of the component inside the tab.

To specify that a certain component should be used in a runtime, you must define at least two properties:

The parameters that end with .ComponentOrder are used for setting tab order for each of the TWE frame sections (areas). E.g. to add Graph component to be initially the second one in the 'Main' tab, it should be something like:

Main.ComponentOrder = XPDLViewController GraphController

Note that parameters UpperStatus and LowerStatus do not have action order, because these areas contain only one component.

This file defines TWE's frame organization (how will it be divided in areas), main menu, tool bar and info bar settings, and TWE's default actions and possibilities. There are a lot of parameters that define these features.

The following parameters can have either value true, or value false:

The parameter UndoHistorySize should have an integer value, and it defines the number of XPDL model related actions that can be undone/redone. If this number is less than zero, TWE will be configured to have unlimited undo/redo history.

There are also other parameters that can have different string values:

The following parameters are defining initial TWE frame settings:

There are a lot of parameters that are defining toolbar and menubar content and order, ...

E.g. to change the order of menu items in the File menu, or to leave out some items, you can modify the following:

SubMenu.ActionOrder.File = NewPackage Open Reopen Close - Save SaveAs - @RecentFiles - Exit

Here are described elements used in TWE: their types and information about them (what should be their color).

For example, the following section defines the properties for an activity which type is BlockActivity

#JaWETypes.ActivityType.Id.block = ACTIVITY_BLOCK
#JaWETypes.ActivityType.LangDepName.block = BlockActivityKey
#JaWETypes.ActivityType.Icon.block = org/enhydra/jawe/images/blockactivity.gif
#JaWETypes.ActivityType.Color.block = R=255,G=165,B=121
#JaWETypes.ActivityType.XPDLTemplate.block = 

Changing the color used to represent this kind of activity will have effect only to the graph component.

There is another advanced feature of TWE which can be utilized through jawetypes.properties file. You can define custom XPDL object types, and even provide the XPDL template fragment to define properties they should have. E.g. if you want to define new type of activity called loop activity, you can have the following configuration:

JaWETypes.ActivityType.Id.loop = ACTIVITY_LOOP
JaWETypes.ActivityType.LangDepName.loop = LoopKey
JaWETypes.ActivityType.Icon.loop = org/enhydra/jawe/samples/loopactivity/
images/loopactivity.gif
JaWETypes.ActivityType.Color.loop = R=255,G=155,B=15
JaWETypes.ActivityType.XPDLTemplate.loop = sampleactloop.xml

where sampleactloop.xml have to be placed under templates subfloder of the configuration you are using. The content of sampleloop.xml file can be something like:

<Activity>
   <BlockActivity BlockId=""/>
   <ExtendedAttributes>
      <ExtendedAttribute Name="LoopCondition" Value=""/>
      <ExtendedAttribute Name="LoopType" Value="While"/>
      <ExtendedAttribute Name="BackToPool" Value="false"/>
      <ExtendedAttribute Name="SetTemporary" Value="false"/>
   </ExtendedAttributes>
</Activity>

To define custom language strings, you should edit jawelanguagemisc.properties file in the target configuration folder, and add appropriate [key,value] pairs. For the previous example, you should add a only following [key,value] par:

LoopKey = Loop

If you need language specific entries for other languages, you just put corresponding property file into the target configuration folder, and define the same property. E.g. you define jawelanguagemisc_de.properties file if you need German translation.

This newly defined activity will automatically appear in the Graph's component toolbox ones you start TWE for this configuration mode.

This file defines the properties for the dialog component used to display XPDL element property panels:

There are properties which can be adjusted to fine-tune the basic element property panels L&F, such as alignment, TOP, BOTTOM, RIGHT, LEFT empty space in the panels, the width and height of the text boxes, etc. These are defined by the following set of the properties:

XMLBasicPanel.RightAllignment=false
XMLBasicPanel.EmptyBorder.TOP=0
XMLBasicPanel.EmptyBorder.LEFT=3
XMLBasicPanel.EmptyBorder.BOTTOM=4
XMLBasicPanel.EmptyBorder.RIGHT=3
XMLBasicPanel.SimplePanelTextWidth=250
XMLBasicPanel.SimplePanelTextHeight=20

You are able to customize so called "group" panels, used to display some complex elements, in order to hide some complex element sub-elements. For example, in order not to display Activity's Id, Deadlines, Priority and Limit, you should set the property HideSubElements.XMLGroupPanel.Activity to the following value:

HideSubElements.XMLGroupPanel.Activity = Id Deadlines Priority Limit

You are able to customize which elements of some collection shouldn't be displayed within so called "table" panels. For example, if you don't want to display extended attributes which name attribute is "SpecEA" or "EASpec", you can define the property:

HideElements.XMLTablePanel.ExtendedAttributes.Name = SpecEA EASpec

You are able to customize so called "table" panels, used to display some complex element collections, in order to specify which sub-elements will be shown as a table columns. For example, when displaying activities, you can specify to show Activity's Id, Name, Performer, Type, Start mode, Finish mode and Deadlines:

ShowColumns.XMLTablePanel.Activities = Id Name Performer Type StartMode FinishMode Deadlines

There is another customization possible for the so called "combo box" panel. Hence, you can define for which elements the combo box will be disabled (by default nothing is disabled). For example, if you want to disable combo boxes for displaying Activity's Performer and Transition's From and To properties, you should specify the following:

XMLComboPanel.DisableCombo = Performer From To

As with all other components, you are also able to define the action order inside a toolbar.

This file enables limitation of number of incoming or outgoing transition for each specific activity type.

For block activity the following parameters are important:

For generic activity the following parameters are important:

For route activity the following parameters are important:

For sub-flow activity the following parameters are important:

For tools activity the following parameters are important:

The XPDL validator will validate XPDLs also according to the previously mentioned properties.

This file contains several settings that determine some details about validation of XPDL files:

In order to make the life easier for the XPDL developers, and to make developing of XPDLs less error prone, it could be a good idea to customize TWE. One way of customization can be introduction of new activity types (e.g. automated activities for sending e-mails with customized property panels for entering all the information, a special kind of deadline element, a special XPDL template for creating a new workflow process, ...).

Thanks to its internal architecture, TWE can be easily customized in order to support these requirements.

To illustrate previous statement, let's say that in all of our processes, we are intensivelly using Tool activity for sending e-mails.

If we use standard TWE implementation, everytime we want to insert such activity in the process (e.g. via Graph component), we first need to insert a standard Tool activitiy using TWE's Graph component toolbox. After that, we need to open the property panel for the activity, go to the Type section, and create a new Tool for this activity. When new Tool is created, we need to edit it, where we need to select a reference to the Application definition for sending e-mails, and than to create as many ActualParameters for the Tool as there are FormalParameters for the Send E-Mail Application definition. And finally, we need to enter appropriate values for this ActualParameters (either a references to the variables, or some text expressions).

You have to admit that there is a lot of work to do, and it can be quite anoying if you have to do it many times. Also, it is error prone.

What we can do is to extend standard TWE functionallity, and to introduce a new type of an activity for sending e-mails, which will be the customization of the standard Tool activity. We can offer a new button in Graph's toolbar for creating such kind of an activity. This button would have a special icon, and e-mail-ing activity when inserted into graph would also have this icon to be diferentiated amongst others. Also, when such activity is created, its XPDL content would be automatically pre-filled, so it would always have a Tool which would reference the Application for sending an e-mails, and this Tool would already have a default values for all necessary ActualParameters. But this is not all, we can also offer a special property panel for entering e-mail parameters (ActualParameters) - e.g, we can have a combo-box with a list of e-mail addresses (which could be filled through the LDAP), we can have a text box for entering mail subject, and a text area for entering mail content.

TWE distribution comes with several customized configurations. You can switch from one configuration to another one if you select Settings->Configuration and select desired configuration. TWE will be re-configured to use selected configuration.

Available configurations are: