Workflow COMOS. Platform Workflow. Trademarks 1. Overview. Starting example 3. Base data of the workflow 4. Revisions in the workflow

Transcription

1 Trademarks 1 Overview 2 COMOS Platform Operating Manual Starting example 3 Base data of the workflow 4 Revisions in the workflow 5 Designer 6 Using workflows 7 A Appendix 02/2011 A5E

2 Legal information Legal information Warning notice system This manual contains notices you have to observe in order to ensure your personal safety, as well as to prevent damage to property. The notices referring to your personal safety are highlighted in the manual by a safety alert symbol, notices referring only to property damage have no safety alert symbol. These notices shown below are graded according to the degree of danger. DANGER indicates that death or severe personal injury will result if proper precautions are not taken. WARNING indicates that death or severe personal injury may result if proper precautions are not taken. CAUTION with a safety alert symbol, indicates that minor personal injury can result if proper precautions are not taken. CAUTION without a safety alert symbol, indicates that property damage can result if proper precautions are not taken. NOTICE indicates that an unintended result or situation can occur if the relevant information is not taken into account. If more than one degree of danger is present, the warning notice representing the highest degree of danger will be used. A notice warning of injury to persons with a safety alert symbol may also include a warning relating to property damage. Qualified Personnel The product/system described in this documentation may be operated only by personnel qualified for the specific task in accordance with the relevant documentation, in particular its warning notices and safety instructions. Qualified personnel are those who, based on their training and experience, are capable of identifying risks and avoiding potential hazards when working with these products/systems. Proper use of Siemens products Note the following: WARNING Siemens products may only be used for the applications described in the catalog and in the relevant technical documentation. If products and components from other manufacturers are used, these must be recommended or approved by Siemens. Proper transport, storage, installation, assembly, commissioning, operation and maintenance are required to ensure that the products operate safely and without any problems. The permissible ambient conditions must be complied with. The information in the relevant documentation must be observed. Trademarks All names identified by are registered trademarks of Siemens AG. The remaining trademarks in this publication may be trademarks whose use by third parties for their own purposes could violate the rights of the owner. Disclaimer of Liability We have reviewed the contents of this publication to ensure consistency with the hardware and software described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. However, the information in this publication is reviewed regularly and any necessary corrections are included in subsequent editions. Siemens AG Industry Sector Postfach NÜRNBERG GERMANY A5E P 09/2011 Copyright Siemens AG Technical data subject to change

3 Table of contents 1 Trademarks Overview Starting example Requirements Example workflow Administration Preparing the base data Editing the workflow sequence Using the example workflow Base data of the workflow Task base objects (activities) Overview of the tasks/activities Creating CDevice-based activities General activities Activity classes Summary "Data" tab "System" tab Miscellaneous information about activity base objects Script blocks for activities Sequence of an activity base objects "Data" tab "System" tab Miscellaneous information about workflow base objects Base data for a revision workflow Base data for the documents Base data of the workflow Revisions in the workflow Overview Revision workflow sequence Designer Starting the Designer Interface Positioning activities Processing fault handlers Basic principle...43 Operating Manual, 02/2011, A5E

4 Table of contents Display mode for fault handling Using the fault handler for operating system activities Using fault handlers for COMOS activities Activities library "System" tab "Comos" tab Configuring the properties of activities Overview Rule condition editor / conditions Incorporating activities as elements Setting the base object of an activity Using workflows Project options Root node for project management Checking the workflow status A Appendix A.1 General A.2 base object: System tab A.3 Status of activities Operating Manual, 02/2011, A5E

5 Trademarks 1 Trademarks Registered trademark: COMOS Operating Manual, 02/2011, A5E

6 Trademarks 6 Operating Manual, 02/2011, A5E

7 Overview 2 This functionality creates and manages workflows that are capable of running within COMOS on the basis of a graphic interface. Hence we can also talk of a "Macrodesigner". Creating workflows A workflow consists of individual "activities". The single activities are connected in with the Designer by means of a simple flow diagram and thus make up an action flow, the workflow. All the predefined activities within the Designer are offered in the form of a list from which you can drag an activity into a two-dimensional work area using Drag&Drop. Alternatively, you can drag the activities from the Navigator into the action flow (workflow). Examples for actions: Sending s Creating an object Monitoring attributes Importing data Editing revisions Types of activity There are two types of activity: Activities that can be used without any further preparation when defining the workflow Activities that are built around base objects in which additional settings and defaults need to be applied to allow the relevant activity to be carried out This second group of activities can be increased to any desired number by the administrator. This results in the creation of activities that have been tailored specifically to the company-specific stock of data and hence minimize possible sources of error and the amount of user effort required. Using workflows A workflow instance is created for a workflow base object. The start of the workflow depends on the definition: Automatic start depending on other events within COMOS Manual start, for example, with a "Start " button The Monitor can be started via the context menu at the instance of the workflow to display the current execution status. Operating Manual, 02/2011, A5E

8 Overview 8 Operating Manual, 02/2011, A5E

9 Starting example Requirements You have activated the workflow functionality in the project properties. See also Project options (Page 55) 3.2 Example workflow This example shows you how to create a workflow that monitors an attribute of a pump. The workflow is to be started manually. Monitoring itself is automatic. At the end the user can call up an information message that reports the status. 3.3 Administration Preparing the base data Developing a rough concept The first step involves drawing up a rough concept of what the workflow should look like. This concept can be produced on paper or done in your head. The only thing that matters is that you have a rough idea of which work steps are required for the workflow. There are only a few work steps in this simplified example: Creating and starting the workflow This step is not implemented in an activity but is part of the workflow itself. Selection of the pump Observation of the pump (to be more exact: observation of the attribute at the pump) User-controlled concluding message Operating Manual, 02/2011, A5E

10 Starting example 3.3 Administration Creating a workflow base object Start by creating a dedicated workflow base object: 1. Click on the "Base data" tab in the Navigator. 2. Open the "@WF > WF s" branch. 3. Optional: Create a test folder by selecting "New > New base object" and the "Structure" creation option from the context menu. 4. Create the workflow base object by selecting "New > New base object" from the context menu. Entering a rule-based label as early as the base object has the following advantage: In the engineering view, the workflow is given a new name after startup that contains the workflow ID. s are difficult to distinguish between on the basis of the ID. If the object has a label, then the name is hidden in the Navigator and the label is shown. As soon as you have created the first activities, you will continue to work with the workflow base object. "Select pump" activity 1. Open the "@WF > TA Tasks" branch. 2. Optional: Create a test folder by selecting "New > New base object" and the "Structure" creation option from the context menu. 3. Create the activity base object by selecting "New > New base object" from the context menu. 4. Open the base object properties, "System" tab. 5. In the "Comos activity class" field, select the "ComosTaskActivity" entry. This is the most general of all the activity classes. In this starting example it has the advantage that no other automatic mechanisms run. You configure the activities to meet company-specific requirements on the "Data" tab. You must confirm this activity manually. The easiest way to do this is to copy the "Confirm task" button from an activity that has already been set up in the ComosDB: 1. Select the "@WF > TA > 02 > CCTConfirm/cancel task" node. 2. Open the properties. 3. Open the context menu in the free area of the "Attributes > Data" tab and select "Design mode". 4. Select the "Confirm task" button and copy it via the context menu. The button has a special script in the "OnClick" script block. 5. Switch to the actual activity, "Select pump": 6. Open the properties. 7. Open the context menu in the free area of the "Attributes > Data" tab and select "Design mode". 8. In the context menu, select "Paste". 10 Operating Manual, 02/2011, A5E

11 Starting example 3.3 Administration Alternative method: Create a new button and copy just the script. The starting example requires a field in which the user can set an object. To do this, use an attribute of the "Reference" type of display: 1. Open the properties of the activity. 2. Open the context menu in the free area of the "Attributes > Data" tab and select "Design mode". 3. In the context menu, select "New > Attribute". 4. Set the properties of the attribute: "Name": any desired one, for example, "PO1" "Type of display": "Reference" To make it easier to edit the set object in the workflow, it is also passed on to the instance of the workflow. This is done by creating an attribute with the following properties at the "PO1" attribute that has just been created: "General" tab "Type of display": "Reference" "Link" tab: "Link type": "By owner" The workflow is the owner of the activity. "Value": "Full dynamic" "Attribute": "Data.MOB" This entry must match the corresponding attribute at the workflow. Up until now this attribute has not existed in the workflow. Although you have created the workflow base object, you have not yet edited it further. Further editing of the workflow base object 1. Open the properties of the workflow base object. 2. Open the context menu in the free area of the "Attributes > Data" tab and select "Design mode". 3. In the context menu, select "New > Attribute". 4. Set the properties of the attribute: "Name" The name must match the name entered in the attribute link at the activity. Otherwise it is random. For the example: You must enter "MOB", because you entered the link to the name "MOB" at the activity. "Type of display": "Reference" Nothing further is entered at this point, and in particular no links. The attribute at the workflow is updated from the activity. Operating Manual, 02/2011, A5E

12 Starting example 3.3 Administration Activity Observe pump attribute Create an activity with the "ComosTaskActivity" activity class. This activity is to run automatically. To achieve this, create a monitored attribute: 1. Open the properties of the activity. 2. Open the context menu in the free area of the "Attributes > Data" tab and select "Design mode". 3. Create a new attribute: "Name": Prefix "WFREFOBS_" followed by a name of your choosing The prefix is a key telling the workflow that this attribute is to be monitored automatically by COMOS. "Type of display": "Reference" 4. So that the monitored attribute takes over from the workflow the pump that has been set there, use a static link: Properties of the attribute, "Link" tab: "Link type": "By owner" The workflow is the owner of the activity. "Value": "Static" "Attribute": "Data.MOB" This entry must match the corresponding attribute at the workflow. Further above the attribute at the workflow base object was created in this way. The special point about a static link in an activity is that it is automatically evaluated at the start of the activity in question. You find information about the exact sequence of the activities and the data flows in Using the example workflow (Page 14) and Sequence of an activity (Page 28). The pump is now monitored. 5. Define which attribute changes the workflow responds to. This definition is made at the activity, in the "CheckTaskState" script block. The script block is checked automatically. If Comos finds the following instruction, the activity is closed automatically and the next activity is started: CheckTaskState = True For the starting example, monitor an attribute of the pump in the script block and set "CheckTaskState" to "True" as required. Example script for the "CheckTaskState" script block: Set lo = device.spec("data.wfrefobs_obs").linkobject If Not lo Is Nothing Then If lo.spec("pi010.pia047").value = "2" Then CheckTaskState = True Exit Function End If End If CheckTaskState = False End Function 12 Operating Manual, 02/2011, A5E

13 Starting example 3.3 Administration The script monitors the value of the "PI010.PIA047" attribute. In the ComosDB, this is the temperature of the pump. As soon as temperature "2" is input, the activity is closed automatically and the next activity is started. "Messagebox" activity Define the user-controlled concluding message: 1. Open the > TATasks" branch. 2. Create the activity base object by selecting "New > New base object" from the context menu. 3. Open the base object properties and click on the "Attributes > System" tab. 4. In the "Comos activity class" field, select the "ComosScriptActivity" entry. 5. So that the user starts the concluding message via a button, create a "Run script" button. To do this, copy a template from the ComosDB: Select the "@WF > TA > 03 Scripts" branch. Open the properties and click on the "Attributes > Data" tab. Open the context menu in the free area of the tab and select "Design mode". Select the "Run script" button and copy it via the context menu. Switch to the actual activity "Messagebox". Open the properties and click on the "Attributes > Data" tab. Open the context menu in the free area of the tab and select "Design mode". In the context menu, select "Paste". The copied button contains "OnClick a script" in the script block. This script can remain unchanged for the starting example. The special feature of an activity of class "ComosScriptActivity" is that the following script block is evaluated automatically: "OnExecuteScriptActivity" This script block contains the following script, for example: MsgBox "TaskSystemUID: " & device.systemuid & " CDevice SystemUID: " & device.cdevice.systemuid Result The base data is now ready. Operating Manual, 02/2011, A5E

14 Starting example 3.4 Using the example workflow Editing the workflow sequence You edit the workflow sequence in the Designer. Procedure 1. Start the Designer by selecting " Designer" in the context menu of the workflow base object. 2. Click on the "Comos" tab in the Designer. This tab contains the activities you have set up. 3. Put the activities in the following order: "Select pump" activity "Monitor pump" activity "Messagebox" activity You can set this activity to "AutomaticExecution" = "True" in the properties area, so that when the workflow reaches this activity, it is started automatically. This concludes all preparations. The workflow can be used. 3.4 Using the example workflow Creating an instance Create an instance of the workflow base object: 1. Show the workflow base object in the Navigator in the detail window. To do this, drag&drop it onto the strip on which the names of the tabs appear in the Navigator. 2. Switch to the "Units" tab in the Navigator. 3. Drag&drop the workflow base object from the detail window and create it underneath the unit. There are not yet any other objects underneath the workflow instance. Starting the workflow 1. Open the properties of the workflow instance. 2. Click on the "Start workflow" button on the "Data" tab. The first activity is started. You can see the "Select pump" activity underneath the workflow instance. 3. Open the properties of the activity and drag a pump into the reference field from the engineering data. The pump is entered at the corresponding attribute of the workflow instance. 14 Operating Manual, 02/2011, A5E

15 Starting example 3.4 Using the example workflow Confirming the activity To allow the workflow to continue to run, you must confirm the activity manually. Click the "Confirm task" button to do this. Result COMOS automatically creates the next activity, "Monitor pump", under the workflow instance. This activity automatically evaluates the static link to the workflow instance in this way the pump is acquainted to the activity. Furthermore, the "CheckTaskState" script block is initiated automatically. You find information about the technical sequence involved in running an activity in Sequence of an activity (Page 28). You can see two activities in the Navigator: The "Select pump" activity This activity is displayed with the text "DONE". The "Monitor pump" activity The status of this activity depends on the starting status of the temperature of the pump: If the temperature was not equal to "2", the text "ACT" appears. If temperature was equal to "2", the activity was closed automatically and the third activity created. Entering values If the temperature of the pump did not have the starting status "2" initially, enter the value "2" for this example. Result The "Monitor pump" activity is closed automatically and the third activity is created. Now you can see three activities underneath the workflow instance: The "Select pump" activity This activity is displayed with the text "DONE". The "Monitor pump" activity This activity is displayed with the text "DONE". The "Messagebox" activity This activity is displayed with the text "ACT". Running a script In the properties of the "Messagebox" activity, click on the "Run script" button on the "Data" tab. Result The defined message appears. The workflow is now ended. Operating Manual, 02/2011, A5E

16 Starting example 3.4 Using the example workflow 16 Operating Manual, 02/2011, A5E

17 Base data of the workflow Task base objects (activities) Overview of the tasks/activities Groups The workflow is based on a list of activities, also known as tasks in the base data. This list is divided into two groups: System activities Activities through Comos System activities System activities come from the operating system environment. However, not all possible activities are offered, but only selected ones. See "System" tab (Page 47). Activities through COMOS These activities have been written especially for COMOS and only function in COMOS. They are divided into two types: Ready-made activities These activities are only configured in the Designer. See "Comos" tab (Page 47). CDevice-based activities These activities are mandatorily based on a CDevice, at which the main settings for the activity are made. The quantity of CDevice-based activities can be changed and extended as desired and thus can be tailored to meet company-specific needs Creating CDevice-based activities General activities Activities requiring a CDevice must be created in the base data underneath the following node: "@WF > TA Tasks" Operating Manual, 02/2011, A5E

18 Base data of the workflow 4.1 Task base objects (activities) The principle of hierarchical inheritance from owner means that new base objects have all the necessary defaults. You just need to enter the following information: "Name" The name controls the visible sequence of the activities on the "Comos" tab in the Designer. "Description" The description of the activities is displayed in the Designer. The activities in the Designer cannot be identified without a description. "Attributes > System" tab: "Comos activity class" field A CDevice-based activity cannot work without an activity class and hence is not offered within the Designer. See Activity classes (Page 18). In addition, the activity class defines which hard-coded attributes are required. "Attributes > Data" tab The attributes of the tab control the activity. In many cases the administrator already presets the attributes in the base data view. However, it is also possible for the user to supplement or amend the details. A CDevice-based activity will not function without the necessary attributes on the "Data" tab. Exactly which attributes are required as a minimum depends on the activity class, see Activity classes (Page 18). When testing, the simplest method is to copy a preconfigured activity and supplement it with attributes of your own Activity classes Definition Activity classes specify the particular features of activities: When and where can the activity be used? What are the other capabilities of the activity? All the activities of an activity class are offered in the Designer underneath a common node. If no activity class has been set, the activity is not offered at all within the Designer. A list of activity classes and their hard-coded attributes on the "Data Data" and "SYS System" tabs appears below. You cannot add information to the list of activity classes. "ComosTaskActivity" activity class This class is the base class for all COMOS activities. However, it can also be used directly. It can be switched to Done and Canceled. It is intended, for example, for tasks that are not suitable for automation but have to be executed fully by the user and confirmed or discarded at the end. Fixed attributes: None 18 Operating Manual, 02/2011, A5E

19 Base data of the workflow 4.1 Task base objects (activities) "ComosRevisionStepActivity" activity class Activities with this class execute one revision step or several successive revision steps in a document. Fixed attributes: "SYS.WFREFOBS_Revision" Reference to the revision: This is set by script. This involves an observed attribute due to the "WFREFOBS_" prefix. "SYS.RE" Specifies up to which revision step the revision is to be conducted. "Data.RLB" Optional. The label of the revision. "Data.RDE" Optional. The description of the revision. "Data.SLB" Optional. The label of the revision step. "Data.SDE" Optional. The description of the revision step. "ComosSignRevisionActivity" activity class Activities with this class sign a revision. Important: A PDF of the revision must exist when it is signed. In this case, the option "PDF in the first step" must be set in the project settings in the revision options. The "esign" option is no precondition. Fixed attributes: "SYS.WFREFOBS_Revision" Reference to the revision: This is set by script. This involves a monitored attribute due to the "WFREFOBS_" prefix. "Data.ESG" Optional. The name of the signature attribute that is to be used on the "ESIGN" tab in the revision can be entered here. If a signature attribute with this name already exists, then this signature is used and any existing signatures are deleted first. Otherwise, a new attribute with the specified name is generated. "ComosSendToSharepointActivity" activity class Activities with this class send the last closed revision of a document to a Sharepoint server. If no revision of this type exists, then the original document is sent. Operating Manual, 02/2011, A5E

20 Base data of the workflow 4.1 Task base objects (activities) Fixed attributes: "Data.DP" The document to be sent. "Data.SPF" Target folder on the Sharepoint server. "Data.SPDL" The Sharepoint document library. "Data.SURL" The URL to the service on the server. (A special service that communicates with COMOS must be installed on the server.) "Data.SPDN" The name under which the document is to be stored on the server. "ComosInvokeActivity" activity class Activities with this class start another/a new workflow within a workflow. By default, the values (i.e. link objects, values, and XValues) of the attributes of the activity device are copied to attributes with the same name of the workflow device that has just been created. The "SUID" and "GUID" attributes are exceptions to this rule. Fixed attribute: "WFREFOBS_Status" The attribute is only used by COMOS. Background The activity "ComosInvokeActivity" can be executed in two different ways: The activity is closed directly after it has called the workflow. The activity is only closed if the workflow that was called has been closed. In the second case, a position at which you can observe the status of the starting workflow is required. This is done with the monitored attribute "FREFOBS_Status". "ComosSend Activity" activity class Activities with this class send an . Fixed attributes: "Data.RCP" Query to define the recipient 20 Operating Manual, 02/2011, A5E

21 Base data of the workflow 4.1 Task base objects (activities) Column "Recipient type" Use "To" or "CC" "Recipient" The address Configuration: Manual input Drag&drop a user from the "User management" project. Column context menu, "Address book" command: Selection from the Outlook address book This requires that Outlook is installed along with the "CDO.dll" component (dependent upon the Outlook version). "Description" Explanatory text for recipient Optional Not evaluated further "Data.ATS" Query to define the attachments Column Use "Attachment" Reference to a document or a document group Only documents/document groups managed in COMOS are permitted as attachments. To add an attachment, drag&drop the document/document group onto the column from the COMOS Navigator. "Format" The format in which the file is sent: "File": The file is sent in its original format. "File as PDF/TIFF": The revision printer currently set in COMOS creates a PDF/TIFF file and sends it. This process takes time (how long depends upon the file size). "Last revision": The most recent revision file is sent. For COMOS reports only: "DWG", "DXF", and various Excel formats: The report is exported and sent in the selected format. Operating Manual, 02/2011, A5E

22 Base data of the workflow 4.1 Task base objects (activities) "Data.ZIP" Option activated: All attachments are compressed in a single ZIP file. "Data. SBJ" Subject "Data.BOD" The text (not HTML) "ComosScriptActivity" activity class Activities with this class run a script. This script is defined in the "OnExecuteScriptActivity" script block at the activity CDevice, see Script blocks for activities (Page 26). Fixed attributes: None Summary In any case the activities that do not require any base objects are available in the Designer. In most cases, you must predefine additional CDevice-based activities before you can work with the Designer. The default activities in the ComosDB are sufficient for initial tests "Data" tab General data on the tab Name: "Data" Description: "Data" Requirements The tab must not be renamed or deleted because it is hard-coded. Its hard-coded attributes vary dependent upon activity class. Some of the hard-coded attributes are optional, others must not be renamed or deleted. See Activity classes (Page 18). Purpose of the tab This tab is used for making company-specific modifications or creating company-specific activities. You can create as many additional attributes as you wish here. You can create individual workflows by extending the list of CDevice-based activities and then creating each of the required attributes on the "Data" tab. The activities on this tab must contain all information that is required for the user to execute the activity or to edit the activity. 22 Operating Manual, 02/2011, A5E

23 Base data of the workflow 4.1 Task base objects (activities) Since a workflow essentially involves handing over of information from one activity to the next, the linking of attributes is of central importance. Effect of static links Before activating an activity, COMOS first evaluates all static links of this activity. In most cases, an attribute takes over the value of another attribute by means of a static link. Attributes of the "Reference" type of display are an important exception. In the case of attributes with display type "Link" a static link takes over the object that had been set. Following evaluation, the object is set at the source attribute and at the target attribute. Monitoring attributes You can configure attributes so that they are monitored automatically. Attribute properties: Display type "Link" Name: Prefix "WFREFOBS_" followed by a name of your choosing. Example: "WFREFOBS_OBS" You find information about the precise monitoring mechanism in Monitoring objects (7.1) (Page 57). The activity is notified as soon as the object to which the reference attribute points changes. Usually this is followed by a check to determine whether the activity had been completed "System" tab General data on the tab Name: "SYS" Description: "System" Requirements This tab is used internally by the system. Configure the tab as described in this section. Do not make any other changes. Attributes of the tab The attributes of the tab belong to the following groups: Attributes set by COMOS on the basis of user actions Attributes which must be set by the administrator (mandatory attributes) Operating Manual, 02/2011, A5E

24 Base data of the workflow 4.1 Task base objects (activities) Attributes to which the administrator can add more information (optional attributes) They are not processed further by Comos. Attributes used internally in the system Attributes set by COMOS on the basis of user actions Start time End time Status Task closed Task canceled The entry in the "Status" field depends on the status. Mandatory attributes "Comos activity class" field (previously called ComosTaskActivity) This field offers the fixed list of possible activity classes. You find information about the intended purpose of activity classes and the available activity classes in Activity classes (Page 18). Optional attributes "User group" field You can assign user groups or users to a workflow here. Name: "SYS.UG" Type of display: "Reference" This hard-coded attribute uses dedicated script blocks to ensure that only objects from the "@Groups" branch" can be set. If this attribute has been set, then only members of the user group are permitted to edit the activity. This setting can be overridden by "SYS.US". "User" field If this hard-coded attribute is set, only this user is permitted to edit the activity. The attribute takes priority over "SYS.UG". Name: "SYS.US" Type of display: "Reference" "Critical duration" field Here you can input time details in hours, days, or weeks. Name: "CD" 24 Operating Manual, 02/2011, A5E

25 Base data of the workflow 4.1 Task base objects (activities) "Expected duration" field Name: "ED" As "CD" Text field with text editor Name: "Info" You can describe the activity in more detail here. Attributes used internally in the system Do not use the following attributes: "SystemUID" field Name: "SUID" " SystemUID" field Name: "WFS" "Guid" field Name: "GUID" " Guid" field Name: "WFG" "Qualified activity name" field Name: "QNM" Miscellaneous information about activity base objects Creating a folder structure Within the Designer, all activities that fulfill the following conditions are offered: Activity class is set. Creation option is "Normal". The best way to create folders is by giving an activity the "Structure" creation option. The result is that the folder objects are displayed in the Navigator in a different color (pale pink) and they are not displayed at all in the Designer. Objects lying underneath are displayed again in the Designer if they meet the above criteria. Incorporating activities as elements See Miscellaneous information about workflow base objects (Page 32). Operating Manual, 02/2011, A5E

26 Base data of the workflow 4.1 Task base objects (activities) Context menu for the activity base object "Set Task done command Used for test purposes. It may be removed from future versions. This context menu was added by means of perfectly normal customizing (the "OnMenuCreate" script block was used in the base data of the ComosDB) Script blocks for activities "CheckTaskState(Device, Attribute)" script block The script checks whether an activity can be closed. The script is called once for the "ComosTaskActivity" class when the activity is activated (with Attribute = Nothing). Subsequently the script is always called if an object that is being observed by the activity has changed. In this case, "Attribute" is the reference attribute that points to the modified object. See General (Page 57). Parameter: "Device" The activity device "Attribute" The attribute of display type Link an the activity, to which the amended object is linked. Can be "Nothing". Return value type: "Boolean" "True": If the activity can be closed. "False": In all other cases. "OnExecuteScriptActivity(Device)" script block The script runs in the "ComosScriptActivity" activity class. "Device" parameter: The activity device Return value: "int" type "0": The activity closes. Not equal to "0": The activity remains open and the script can be called again. "OnTaskActivated(TaskDevice)" script block This is called up after activating an activity. "TaskDevice" parameter: The activity device 26 Operating Manual, 02/2011, A5E

27 Base data of the workflow 4.1 Task base objects (activities) "OnTaskDone(TaskDevice)" script block This is called up after executing an activity. An activity counts as having been run if its status is "Done" or "Cancel". Every activity can take on both of these statuses. Cancel is saved as an attribute at the activity. See section Status of activities (Page 58). "TaskDevice" parameter: The activity device See also Activity classes (Page 18) Operating Manual, 02/2011, A5E

28 Base data of the workflow 4.1 Task base objects (activities) Sequence of an activity Introduction The following figure provides a simple overview of the sequence of an activity: You can also control and monitor an activity right at the beginning and right at the end using the "OnTaskActivated" and "OnTaskDone" script blocks. In "OnTaskActivated", you do not yet have access to the monitored attributes ("WFREFOBS_"). It is not possible to open the activity again in "OnTaskDone".. 28 Operating Manual, 02/2011, A5E

29 Base data of the workflow 4.1 Task base objects (activities) The following figure illustrates the sequence of an activity in detail: Operating Manual, 02/2011, A5E

30 Base data of the workflow 4.2 base objects 4.2 base objects Principle To define a workflow, you need a base object. The workflow base objects must be located under the following node in the base data: "@WF > WF " The principle of hierarchical inheritance from owner means that new base objects have all the necessary defaults. Each workflow must have a unique name. Testing the workflow functionality You can test the workflow functionality by copying a preconfigured workflow and adding your own attributes "Data" tab General data on the tab Name: "Data" Description: "Data" Requirements Do not rename the tab and do not delete it. Purpose The tab is used to model customer-specific workflows. Add the necessary attributes to the tab as appropriate for the task performed by the workflow you have modeled. Attributes in the ComosDB For most of the preconfigured workflows in the ComosDB, the tab only has the "Start workflow" button. 30 Operating Manual, 02/2011, A5E

31 Base data of the workflow 4.2 base objects "System" tab General data on the tab Name: "SYS" Description: "System" Purpose The tab is used internally in the system. Do not change it. Attributes " status" field Name: "WST" Set by COMOS. "Created by" field Name: "CB" Set by COMOS. "Completeness" field: Name: "COM" Optional Set by the user. "ID for project management tree" field Name: "WPMID" Controls the storage of the workflow object on the "Units" tab. See Root node for project management (Page 55). "Output monitoring" field Name: "DBG" Used by COMOS for outputs. Set by a dedicated activity, see "Comos" tab (Page 47), "ComosWriteDebugMessageActivity". Or a fault handler makes an entry, see Basic principle (Page 43). Attributes for incorporating revisions into workflows See Base data of the workflow (Page 33). Operating Manual, 02/2011, A5E

32 Base data of the workflow 4.3 Base data for a revision workflow Miscellaneous information about workflow base objects Incorporating activities as elements Activities can be elements of a workflow. To incorporate an activity as an element, you must use the Designer. See Incorporating activities as elements (Page 51). Context menu of the workflow base object " Designer" command: Used for test purposes. It may be removed from future versions. 4.3 Base data for a revision workflow Base data for the documents You find information about the steps involved in making revisions in a workflow in Revisions in the workflow (Page 35). Overview If document revisions are made available in a workflow, the documents must have the following tabs: "System" "s" "System" tab General data on the tab: Name: "SYS" Description: "System" Inheritance source: "@10 > BAS > 3 > 06 > SYS" 32 Operating Manual, 02/2011, A5E

33 Base data of the workflow 4.3 Base data for a revision workflow Attributes of the tab: "Revision workflow" field Name: <As desired> In the ComosDB: "WorkFlow1" Type of display: "Reference" Value: Reference to the workflow base object controlling the revision process "-controlled" field Name: "WFControl" Type of display: "Checkbox" This option prevents you from being able to edit the revision steps at the document on the "Revision" tab. The revision can only be edited via the activities in the workflow. The "IsRevisionAllowed" script block is provided at the document for this purpose. If the script block supplies a return value ("string" type), then any revision of the document is prevented. "s" tab General data on the tab: Name: "WF" Description: "s" Inheritance source: "@WF > 01 > 01 > WF" Attribute of the tab: Name: "WF" Description: "WF" Purpose: Displays the revision workflows for the document. Type of display: "Object query" Base data of the workflow Additional attributes necessary If document revisions are incorporated into a workflow, the base object of the workflow and the base object of the activity on the "Attributes > System" tab must have additional attributes. Operating Manual, 02/2011, A5E

34 Base data of the workflow 4.3 Base data for a revision workflow Attributes on the "System" tab at the workflow base object "Document" field Name: "DP" Type of display: "Reference" Use: Here COMOS automatically enters which document started the revision workflow. "Revision" field Name: "RP" Type of display: "Reference" Use: Here COMOS automatically enters the revision to which the revision workflow belongs. In the ComosDB, these attributes have been prepared for the workflows underneath the "@WF > WF > RDC Document revision workflow" node. Attributes on the "System" tab at the activity base object "Revision" field Name: "WFREFOBS_Revision" Type of display: "Reference" With static link to owner Use: Must point to the attribute in which the revision object is saved at the workflow. "Revision element" field Name: "SYS.RE" Type of display: "Edit field" Use: The activities must be compared with the revision elements that had been prepared in the base data. To do this, specify (at the activity) up to which revision element an activity is to apply. The activity only covers the revision elements which have not yet been processed. Which revision elements are actually covered is determined by the workflow definition. Example: A workflow has two activities. The second activity has the value "3" for "RE". Therefore, in principle, it applies for all revision elements up to the third element, which have not yet been processed. However, the first activity has already processed the first revision element. On account of this, the second activity only covers the second and third revision elements. Note It is, therefore, not possible to use names or labels to link the revision elements to an activity. The only thing that matters is the number and sequence of the revision elements. In the ComosDB, these attributes have been prepared for activities created for creating, checking, and releasing a revision. 34 Operating Manual, 02/2011, A5E

35 Revisions in the workflow Overview You find information about how to configure the base data for a revision workflow in Base data for a revision workflow (Page 32). Overview Revision activities allow users to make document revisions available in a workflow. When a document is revised, the workflow is updated accordingly. In the workflow, the users can see which revision steps have already been completed. There is the option to derive the revision steps at the workflow. The "Revision" tab of the document is updated accordingly. The user can thus tell in the document which revision steps have already been completed. This is achieved by the administrator creating a workflow definition in the base data in which all the revision steps are taken into consideration. The workflow requires two attributes with which the connections to the document and to the revision can be managed. In addition, you require activities that are assigned to a revision element. Alternatively, an activity can also work through a series of sequential revision elements. At the document, an attribute which can be used to set a workflow base object must have been prepared in advance in the base data. In the engineering view, the user selects a workflow base object at the document, provided that the administrator has not already set the attribute in the base object view. Operating Manual, 02/2011, A5E

36 Revisions in the workflow 5.2 Revision workflow sequence 5.2 Revision workflow sequence Starting state in the planning data First of all, there is a document that has a link to a workflow base object. A revision has not yet been created at this stage: Generating a revision The revision process begins by creating a revision ("Create Revision"). You do this in the usual way via the "Revision" tab at the document. This has the following effects: A revision object is created invisibly in the Navigator. The revision object appears as a row on the "Revision" tab of the document. The workflow for the revision is created automatically in the planning data. The workflow that has been created is displayed in the document. In addition, you can also find the workflow in the Navigator and there edit the revision steps. Among other things, the workflow has these two attributes: "SYS.DP" A reference via which the document is registered at the workflow "SYS.RP" A reference via which the revision is registered at the workflow 36 Operating Manual, 02/2011, A5E

37 Revisions in the workflow 5.2 Revision workflow sequence 1 Revision 1 1 SYS.DP SYS.RP Background: Each document can have multiple revisions which can even be active (open) at the same time. For that reason, it is not sufficient if the document has been registered at the workflow. Information about which revision of the document belongs to this workflow is also required. Operating Manual, 02/2011, A5E

38 Revisions in the workflow 5.2 Revision workflow sequence Editing revision steps When the revision that has been created is edited, then the revision elements are created in the Navigator invisibly underneath the revision. These revision elements are likewise objects in COMOS. Furthermore, the workflow is compared automatically. To do this, activities are created and worked through underneath the workflow. In order to give a better overview, the document in the following illustration has been shifted to the right and the documents are no longer arranged one after another as in the Navigator: 1 In the illustration, you can see that the activity has a monitored attribute: "WFREFOBS_Revision" attribute This attribute fetches the details concerning the revision object in question (Line 1 in the drawing) from the workflow in the form of a static link. The special point here is that not a single string containing information about the object (the "RelativName", for example) is input. Instead, the object itself is set. Once the monitored attribute has fetched the information about the revision from the workflow, the revision object itself is input at the activity (Line 2 in the drawing). The "WFREFOBS_Revision" attribute is monitored directly by COMOS. See the figure in Sequence of an activity (Page 28). In the example above, the monitored attribute registers each and every change in Revision 1. This also includes when a new revision element is created, i.e. a revision step is executed. After every change, COMOS checks if the activity has been processed with this information. 38 Operating Manual, 02/2011, A5E

39 Designer Starting the Designer Procedure Select the workflow base object and select " Designer" from the context menu. Result If the workflow has been edited previously, the XML definition of the workflow is loaded automatically from the workflow base object. If there is not yet a WF workflow definition at the workflow base object, a blank workflow is created automatically. Operating Manual, 02/2011, A5E

40 Designer 6.2 Interface 6.2 Interface Basic structure The interface of the Designer is based on the Visual Studio extension for the Windows Foundation: 1 Menu bar 2 Activities library 3 Working area 4 Properties area Menu bar "Save to file" and "Load from file" buttons Saves the XOML definition of the workflow as a file in the file system and loads a workflow definition from an XOML file respectively. See General (Page 57). "Reload" button Discards all changes made since the last save operation by reloading the workflow definition at the base object. Corresponds to "Undo All". 40 Operating Manual, 02/2011, A5E

41 Designer 6.3 Positioning activities Activities library The activities library contains all available activities for you to place on the working area. Working area Here you define the workflow by placing activities and specifying their order. Properties Displays the properties of the activity selected in the working area. You can configure the properties. See also Configuring the properties of activities (Page 49) Activities library (Page 47) Positioning activities (Page 41) 6.3 Positioning activities Drag&Drop from the library You can drag an element from the activities library onto the working area using drag&drop. A prohibition sign appears as long as you are still on the general part of the working area. Green plus signs indicate where you can insert the activity: Operating Manual, 02/2011, A5E

42 Designer 6.3 Positioning activities Alternatively, you can drag an activity CDevice from the Navigator onto the working area. Inputting mandatory attributes Once an activity has been placed, COMOS checks for missing information (missing mandatory attributes, for example, or if it is essential to assign another activity as a child to the activity). If any information is missing, an exclamation mark appears at the top right of the activity: You get an error message if you click on the exclamation mark. If you click on this error message, the properties of this activity are automatically loaded in the properties area and you can then supplement the missing details. Note The absence of exclamation marks does not mean that the workflow can be executed. Upon saving, COMOS checks whether there are any further design errors in the workflow and creates a "Confirm save" message if necessary. The message lists the problems found. Editing a workflow definition in the working area <Ctrl>+mouse click To select one or a number of activities in the working area. You can move the selected activity with drag&drop. <Ctrl>+drag&drop To copy the selected activities. Alternatively, you can use the menu bar at the top or the context menu. Setting placeholders For CDevice-based activities, you can also place the folder node as a wildcard. The "CDeviceSystemFullName" property remains blank. You have to select the activity base object subsequently. See Setting the base object of an activity (Page 49). 42 Operating Manual, 02/2011, A5E

43 Designer 6.4 Processing fault handlers 6.4 Processing fault handlers Basic principle Introduction Fault handling in the workflow works on the principle of a Try-Catch Block: An exception is thrown in the event of an error based on the current position when processing the workflow. Each workflow element in which can contain an activity possesses is can be used with a fault handler. The RuntimeEngine tries to find a fault handler in the next higher logical block that will catch this exception. In this case the "internal" activity first of all attempts to find a fault handler in the "external" activity. If this is not successful, the exception is passed further upwards. Finally, a fault handler for this exception is searched for in the workflow. If one is not found here either, the exception is then passed to the RuntimeEngine. abort and output monitoring On being passed an exception, the RuntimeEngine terminates the workflow and writes the error message to the "SYS.DBG" attribute at the workflow. The existing content of "SYS.DBG" is not deleted; new entries are appended at the end Display mode for fault handling To define fault handling, you must switch to the handler display for the activity or the entire workflow. Switching the activity to fault handling Each activity that can contain a fault handler can be switched over individually to the handler display. The rest of the working area is not affected by this switchover and the selected display is retained. Proceed as follows: 1. On the working area, move the mouse pointer so that it is positioned on the name of the activity. You see a button with an arrow: 2. Click on the button and select "View Fault Handlers" from the menu. Operating Manual, 02/2011, A5E

44 Designer 6.4 Processing fault handlers Switching the workflow to the fault handling mode To switch over all of the workflow activities to the fault handler, proceed as follows: 1. Click on the button next to the green arrow at the top of the working area: 2. Select "View Fault Handlers" from the menu Using the fault handler for operating system activities In this section, fault handlers are assigned to the "ParallelActivity" activity from the "System" tab as an example. Principle When you place the "ParallelActivity" activity in the workflow, it gets the name "parallelactivity1". When you switch the activity in the working area over to the fault handling display, you see this: The "faulthandlersactivity1" box is displayed underneath the "parallelactivity1" node. This is where you define the fault handlers. The plural name shows that you can create multiple fault handlers. For each fault handler, proceed as follows: 1. Place a fault handler. 2. Set a fault type 3. Place activities the fault handler is to run. Creating fault handlers Drag the "FaultHandlerActivity" activity from the "System" tab to the "Drop FaultHandlerActivity Here" box in "faulthandlersactivity1". 44 Operating Manual, 02/2011, A5E

45 Designer 6.4 Processing fault handlers The "faulthandleractivity1" fault handler is created. Following placement, it is selected in the working area: Setting the fault type Every fault handler needs a fault type. To set the fault type, proceed as follows: 1. Select the fault handler in the working area. 2. Click on the "..." button in the "FaultType" row in the properties area. You see a window listing all available exceptions. 3. Set the fault type in the "Type Name" field. The input support in the field helps you to find the exception you are looking for quickly. The most general exception is "System.Exception". Handle exceptions by means of activities In the next step, you create activities for the fault handler which react to the exception caught. To send an , for example, place the "Send (extended)" activity from the "Comos" tab in the "DropActivitiesHere" field under "faulthandleractivity1": Operating Manual, 02/2011, A5E

46 Designer 6.4 Processing fault handlers Sequence of fault handlers The fault handlers are processed in exactly the same sequence in which they are created inside the "faulthandlersactivity" box. When an exception is thrown, the fault handlers are checked one after the other to identify which can handle the exception. The first suitable fault handler handles the exception. The sequence does not move on to subsequent fault handlers. Therefore, you should place special fault handlers before general fault handlers in the sequence. You can use drag&drop to change the sequence of the fault handlers. Example If "System.Exception" is the first fault handler, subsequent fault handlers are never reached, since by definition "System.Exception" is responsible for all exceptions Using fault handlers for COMOS activities Principle For COMOS activities, you have to proceed in a slightly different way than as described for operating system activities. You do not select a "FaultType" but an "ErrorMode". When a fault occurs in a COMOS activity, COMOS writes an entry to the "SYS.DBG Output monitoring" attribute regardless of the "ErrorMode". This does not apply automatically for errors relating to operating system activities. 46 Operating Manual, 02/2011, A5E

47 Designer 6.5 Activities library Procedure To set the ErrorMode, select the activity in the working area and select one of the following values in the "ErrorMode" field in the properties area: "WaitForRetry" The workflow remains active and waits for user input. "CancelTask" The activity is closed with the status "canceled". The workflow processing is continued. "ThrowException" An exception is thrown and needs to be handled by the fault handlers as described for operating system activities. 6.5 Activities library "System" tab Operating system activities The operating system activities are listed on the "System" tab. You find documentation for MS activities on the Microsoft MSDN website, in the US version of the library: ( Select ".NET Development >.NET Framework 3.5 >.NET Framework Class Library > System..Activities" "Comos" tab The COMOS-specific activities are listed on this tab. Operating Manual, 02/2011, A5E

48 Designer 6.5 Activities library Grouping The COMOS activities are divided into two groups: CDevice-based activities These activities are mandatorily based on a CDevice, at which the main settings for the activity are made. All CDevice-based activities are sorted according to activity class and then offered under a shared node. Thus CDevice-based activities with the activity class "ComosScriptActivity" can be found underneath the "ComosScriptActivity" node. It is of no importance how the activity objects are organized in the base data; the activity class alone decides where the activities are located. For details, see Task base objects (activities) (Page 17). Ready-made activities The following activities can ultimately be configured in the Designer: "ComosSetValueActivity" "ComosCompeteActivity" "ComosReplicatorActivity" "ComosWriteDebugMessageActivity" "ComosSetValueActivity" Sets a string either as the value of an attribute at the workflow and/or at an internal workflow object. The workflow object has a dictionary that stores key-value pairs of strings. Thus, for example, it is possible to display the progress of a workflow in percentage by updating the progress attribute with the aid of the activity at defined points within the workflow. "ComosCompeteActivity" What is known as a CompositeActivity; i.e. it can contain more than one activity. As soon as the first activity is done, the other activities are canceled. This can be useful in conjunction with a DelayActivity, for example. "ComosReplicatorActivity" Replicates the activity that is contained. The NestedName of a column of a list attribute is specified at the workflow device. The activity is replicated once for each entry in the column. Optionally you can also specify the NestedName of an attribute at the activity device. The value from the column is then written to this attribute. Replicators are especially useful when setting "SYS.US" or "SYS.UG" attributes, as the elements of the column list are interpreted as user names or user groups here. This means, for example, that you can replicate a "ComosSignRevisionActivity" for any number of users. ComosWriteDebugMessageActivity This activity writes a message to the "Output monitoring" attribute at the workflow device. See "System" tab (Page 31). 48 Operating Manual, 02/2011, A5E

49 Designer 6.6 Configuring the properties of activities 6.6 Configuring the properties of activities Overview You can configure activities placed in the working area in more detail in the properties area. Procedure When you select an activity in the working area, the properties of that activity are displayed in the properties area. To edit the properties, click in the corresponding fields. General properties "Name" The name of the activity base object Must be unique within the workflow. Has no effect on the progress of the workflow in the engineering data. "Enabled" "True": The activity is incorporated into the workflow. "False": The activity has been taken out of the workflow. Properties of CDevice-based activities "AutomaticExecution" "True": When the workflow reaches the activity, it is started automatically. "False": The activity is started by means of user intervention. "CDeviceSystemFullName" The SystemFullName of the activity base object Use the "..." button to make one of the following settings: Incorporate the activity as an element of the workflow. See Incorporating activities as elements (Page 51). Change the base object of the activity. See Setting the base object of an activity (Page 53). "ErrorMode" Defines the fault handler of the activity. See Using fault handlers for COMOS activities (Page 46). Operating Manual, 02/2011, A5E

50 Designer 6.6 Configuring the properties of activities Properties of activities of the operating system which control the control flow "Condition" To define conditions. See Rule condition editor / conditions (Page 50) Rule condition editor / conditions There are activities that control the control flow in the workflow and make a branch ("IfElseActivity") or a loop ("WhileActivity") possible, for example. These activities are controlled using the "Condition" property. Procedure 1. Place the activity in the working area. 2. Select the activity in the working area. You see the properties of the loop or the IfElse branch in the properties area. 3. "Condition" field Select "Declarative Rule Condition". A node appears on the left of the "Condition" field. 4. Expand the node. You see the "ConditionName" and "Expression" fields. 5. "ConditionName" field Enter the name of the condition. 6. "Expression" field: Click on the "..." button. The rule condition editor opens. Enter an expression defining the condition as described below. 50 Operating Manual, 02/2011, A5E

51 Designer 6.6 Configuring the properties of activities Declarative rule condition The condition is formulated in C# syntax and must yield "True" or "False" at runtime. Internally, COMOS uses a workflow class of its own that is derived from a Microsoft workflow class but has additional properties such as "SystemUID". Methods which can be used here as conditions are defined at this COMOS class. In particular, there are two methods with which the "DisplayValue" at the workflow device or at an activity device can be read out: "GetSpecDisplayValue" Input: NestedName of the attribute "GetTaskSpecDisplayValue" Input: NestedName of the attribute Input: Name of the activity device Example this.gettaskspecdisplayvalue("sys.ctc", "TASKXY") == "1" This example returns "True" if the "Task canceled" checkbox is set at the "TASKXY" activity. Hence the activity name needs to be known during the design phase. The rule condition editor supports IntelliSense, and thus offers the member names, for example, when you enter "this." Incorporating activities as elements Activities can only be incorporated as elements in the Designer. They cannot be incorporated in the properties of the workflow base objects. Principle You can incorporate activities as elements. This is recommended for two reasons: The activity is only required once in a special form The activity is to be linked in the engineering view The activity is only required once in a special form From a technical point of view, it is possible to create an activity base object in the base object view and configure it for this special case. In extreme circumstances, this results in a huge library of base objects that would all be needed only in a single case. Instead, you can create an activity as an element of a workflow and configure it locally. This provides a means of implementing mail activities with different configurations, for example. The activity is to be linked in the planning view Scripts or conditions use methods which access attributes at the activity device. For these methods, the name of the activity device to be created must already be known when designing the workflow. Operating Manual, 02/2011, A5E

52 Designer 6.6 Configuring the properties of activities Procedure To incorporate an activity as an element, proceed as follows: 1. Select a CDevice-based activity in the working area. The properties of the activity are displayed in the properties area. 2. Click on the "..." button in the "Comos" node for the "CDeviceSystemFullName" property. The "Select task CDevice" window opens. The window contains a tree with the activity base objects. The activity you selected in the working area is selected in the tree: 3. Activate the "Create the task CDevice as a workflow element" option. The activity that is currently being edited is inserted at the base object of the workflow that is currently being edited on the "Elements" tab. The workflow base object is selected and expanded in the tree in the "Select task CDevice" window. You can see that the activity has been created as an element underneath the workflow. 4. Optional: If the activity is to be linked in the engineering view, activate the "Set the 'Virtual' property of the element to 'Default'" option. The option sets the "Virtual" option to "Default" at the element. 5. Click "OK" to close the window. See also Base data of the workflow (Page 17) 52 Operating Manual, 02/2011, A5E

53 Designer 6.6 Configuring the properties of activities Setting the base object of an activity Use You must set the base object of an activity in the following cases: You have used a wildcard You want to set a different activity base object for a CDevice-based activity Procedure To replace the base object of an activity, proceed as follows: 1. Select the activity in the working area. 2. Click on the "..." button next to the "CDeviceSystemFullName" field in the properties area. The "Select task CDevice" window opens. 3. Select the required activity base object. Operating Manual, 02/2011, A5E

54 Designer 6.6 Configuring the properties of activities 54 Operating Manual, 02/2011, A5E

55 Using workflows Project options Project properties, "s" tab "Activate workflows" option Enables the "Comos..ComosManager" component and thus the workflow compatibility of a project. If you do not use workflows, deactivate this option to enhance performance. "Recover running workflows when project is opened" option For future use. "Scan periodically for workflows with expired timers" option This is required for time-controlled activities and regularly scans whose timer has expired. 7.2 Root node for project management A simple form of management for workflow objects is set up in the ComosDB by means of customizing. First of all, you can create workflow objects on the "Locations" tab or freely in the unit view. However, as soon as the workflow is started, the workflow object is collected underneath the following node: "Units" tab: "@ProjectManagement" The exact location is determined by the ID for project management tree (Page 31) attribute. A string that is interpreted as the name of the owner structure is input in this attribute. Example string: "BES.ING" In this case, COMOS searches underneath the "@ProjectManagement" unit for the unit with the name "BES", and underneath that unit for the unit with the name "ING". If a part of this owner structure is not found, then the workflow is created at the next higher level. If "BES.ING" is not found, the workflow object is created underneath "BES". If "BES" is not found either, the workflow object is created underneath the root node "@ProjectManagement". Operating Manual, 02/2011, A5E

56 Using workflows 7.3 Checking the workflow status 7.3 Checking the workflow status Select " Monitor" in the context menu at the workflow engineering object. The Monitor opens: Completed activities are shown with a check mark. Running activities are marked with a green "Play" arrow. Although you can set milestones with "ComosSetValueActivity", they are not displayed on the monitor. 56 Operating Manual, 02/2011, A5E