Академический Документы
Профессиональный Документы
Культура Документы
Version 7.1
Document Revision 1 December 2009
Copyright Notice
Notice
This document is a proprietary product of Autonomy and is protected by copyright laws and international treaty. Information in this manual is subject to change without notice and does not represent a commitment on the part of Autonomy. While reasonable efforts have been made to ensure the accuracy of the information contained herein, Autonomy assumes no liability for errors or omissions. No liability is assumed for direct, incidental, or consequential damages resulting from the use of the information contained in this document. The copyrighted software that accompanies this document is licensed to the End User for use only in strict accordance with the End User License Agreement, which the Licensee should read carefully before commencing use of the software. No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of the copyright owner. This document may use fictitious names for purposes of demonstration; references to actual persons, companies, or organizations is strictly coincidental.
Autonomy Corporation plc Cambridge Business Park Cowley Rd Cambridge CB4 0WZ Tel: +44 (0) 1223 448000 Fax: +44 (0) 1223 448001 Email: autonomy@autonomy.com
December 2009
Contents
15
15 15 16 18
Chapter 1:
Introduction
Workflow Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Workflow Models with Workflow Modeler . . . . . . . . . . . . . . . . . . . . . . . Adding Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Element Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publishing Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TeamSite and Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19 20 21 21 22 22 23 23 24 24
Chapter 2:
27
Chapter 3:
35
35 37 38 39 41 43 44 45 49 50 52
3
Contents
Overview Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Errors Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a New Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing an Existing Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publishing Workflow Models to TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retrieving Workflow Models from TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading to the Latest Workflow Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53 54 56 59 60 61 63
Chapter 4:
65
Workflow Modeler Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Configurable Variables ($IW_CV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Datasource Variables ($IW_DS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Script Variables ($IW_SCRIPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 TeamSite System Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 TeamSite Macro Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Variable Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Comparison of Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Assigning Common Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Area VPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Brief Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Read Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Transfer Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 EA Finish Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 EA Start Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 WF Variables Finish Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 WF Variables Start Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Assigning Workflow-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Assigning Task-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 CGI Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Deploy Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Email Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Creating a Custom Email Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Email Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 External Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Group Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Metadata Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4
Workflow Modeler Users Guide
Contents
Nested Workflow Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Review Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Submit Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Update Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . URL Task Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Common Link Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Link-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timeout Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conditional Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with Logical Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Node Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GatewayType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X......................................................... Y......................................................... ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
113 114 116 117 118 118 119 119 119 120 120 122 122 123 123 124 124 124 124
Chapter 5:
125
126 127 128 129 130 131 132 132 133 134 134 135 135 135 135 135 136
Chapter 6:
137
137 138 138 140 140 141
5
Contents
Subscribing Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The available_models.xml File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Workflow Model Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combining Access Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Workflow Models Using the Content Tab . . . . . . . . . . . . . . . . . Configuring Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Workflow Models Using the Content Tab . . . . . . . . . . . . . . . . . . Selection Order for Custom Workflow Configuration . . . . . . . . . . . . . . . . . . .
Chapter 7:
Instantiating Workflows
Instantiating Workflows in ContentCenter Professional . . . . . . . . . . . . . . . . . . . . Instantiating Workflow Models With the New Job Option . . . . . . . . . . . . . . . . Instantiating Workflow Models With the Submit Option . . . . . . . . . . . . . . . . . Instantiating Workflow Models With the Assign Option . . . . . . . . . . . . . . . . . Viewing Workflow Models in ContentCenter Professional . . . . . . . . . . . . . . . . . . Viewing Workflow Models Before Instantiation . . . . . . . . . . . . . . . . . . . . . . . Viewing Workflow Models After Instantiation. . . . . . . . . . . . . . . . . . . . . . . . . Instantiating Workflow Models in ContentCenter Standard . . . . . . . . . . . . . . . . . Instantiating Workflow Models from TeamSite Front Office . . . . . . . . . . . . . . . . Instantiating Workflow Models from the Command Line . . . . . . . . . . . . . . . . . . .
157
157 158 160 163 165 165 166 169 171 172
Chapter 8:
175
175 176 177 177 178 179 180 185 185 188 188 199
Chapter 9:
201
201 201 203 203 204 204 204 205 205 205
Contents
Arguments for ListDataSource, MapDataSource, and SortedValuesMapDataSource206 Registering a Datasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Deploying a Datasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Using Datasources in Job Instantiation Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Static Calls for Datasources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 getDatasourceNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 executeComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 An Example for Static Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Dynamic Calls for Datasources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 IWDatasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 IWMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 An Example for Dynamic Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Chapter 10:
215
215 216 217 218 218 219 220
221
221 222 222 223 224 224 226 227 228 229 229 230 231 232 233 233 234 235 236 236 237 238 239
7
Contents
Saving Your Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Publishing Your Workflow Model to TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Testing Your Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
243
Tables
Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7 Table 8 Table 9 Table 10 Table 11 Table 12 Table 13 Table 14 Table 15 Table 16 Table 17 Table 18 Table 19 Table 20 Table 21 Table 22 Table 23 Table 24 Table 25 Table 26 Table 27 Table 28 Table 29 Table 30 Table 31 Table 32 Table 33 Table 34 Table 35 Table 36 Table 37 Table 38
Workflow Modeler Users Guide
Notation Conventions............................................................................................... Installation Shortcut Location Options ..................................................................... Standard Toolbar ..................................................................................................... Links Toolbar ........................................................................................................... Tasks Toolbar .......................................................................................................... Display Toolbar ........................................................................................................ The Options Menu ................................................................................................... TeamSite System Variables..................................................................................... TeamSite Macro Variables....................................................................................... Variable Comparison ............................................................................................... Workflow-specific Attributes..................................................................................... CGI task Attributes................................................................................................... Deploy Task Attributes............................................................................................. Email Task Attributes ............................................................................................. External Task Attributes......................................................................................... Group Task Attributes ............................................................................................ Metadata Task Attributes ....................................................................................... Nested Workflow Task Attributes........................................................................... Review Task Attributes .......................................................................................... Submit Task Attributes........................................................................................... Update Task Attributes .......................................................................................... URL Task Attributes............................................................................................... Operations Summary for Workflow Roles .............................................................. TutorialList of Workflow Elements........................................................................ TutorialWorkflow Attributes .................................................................................. TutorialDummy Task Attributes............................................................................ TutorialMetadata Task Attributes ......................................................................... TutorialSubmit Task Attributes............................................................................. TutorialDeploy Task Attributes............................................................................. TutorialNotify Deploy Task Attributes................................................................... TutorialCreate Metadata Link Attributes .............................................................. TutorialNo Metadata Link Attributes..................................................................... TutorialSubmit After Timeout Link Attributes ....................................................... TutorialNo Deploy Link Attributes ........................................................................ TutorialDeploy Content Link Attributes ................................................................ TutorialNotify Link Attributes ................................................................................ TutorialResolve Problems Link Attributes ............................................................ Error Messages......................................................................................................
15 30 39 40 41 43 44 73 75 77 90 95 96 101 111 112 113 114 114 116 117 118 140 225 227 229 229 230 231 232 233 234 235 236 237 237 238 257
9
Tables
10
Figures
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 Figure 27 Figure 28 Figure 29 Figure 30 Figure 31 Figure 32 Figure 33 Figure 34 Figure 35 Figure 36 Figure 37 Figure 38
Workflow Modeler Users Guide
Workflow Model Lifecycle ........................................................................................... 20 Sample Workflow Model Diagram............................................................................... 21 Introduction Screen..................................................................................................... 28 License Agreement Screen......................................................................................... 28 Product Files Screen................................................................................................... 29 Choose Shortcut Folder Screen.................................................................................. 30 Install Complete Screen.............................................................................................. 31 Introduction Screen..................................................................................................... 32 Uninstall Complete Screen ......................................................................................... 33 Login Dialog Box......................................................................................................... 36 Workflow Modeler User Interface (UI)......................................................................... 38 Options Menu.............................................................................................................. 44 Preference Dialog Box ................................................................................................ 46 Preference Dialog Box - General Node ...................................................................... 47 Preference Dialog Box - Appearance Node ................................................................ 48 Preference Dialog Box - Shortcut Keys Node ............................................................. 48 Project Pane with Workflow Model ............................................................................. 49 Tree Pane ................................................................................................................... 51 Properties Pane .......................................................................................................... 52 Overview Pane............................................................................................................ 53 Errors Pane................................................................................................................. 55 Errors Pane Details..................................................................................................... 55 Project Pane Title Bar ................................................................................................. 57 Workflow Model Properties ......................................................................................... 58 Login Dialog Box......................................................................................................... 61 Retrieve from Server Dialog Box ................................................................................ 62 Configurable Variable Dialog Box ............................................................................... 67 User-defined Configurable Variable Available for Reuse............................................ 67 Datasource Variable Dialog Box ................................................................................. 69 User-defined Datasource Variable Available for Reuse.............................................. 69 Script Variable Dialog Box .......................................................................................... 71 User-defined Script Variable Available for Reuse....................................................... 71 Description Dialog Box................................................................................................ 80 Variables Dialog Box................................................................................................... 83 EA Finish Op Dialog Box ............................................................................................ 84 EA Start Op Dialog Box .............................................................................................. 85 WF Variables Finish Op Dialog Box............................................................................ 87 WF Variables Start Op Dialog Box.............................................................................. 88
11
Figures
Figure 39 Figure 40 Figure 41 Figure 42 Figure 43 Figure 44 Figure 45 Figure 46 Figure 47 Figure 48 Figure 49 Figure 50 Figure 51 Figure 52 Figure 53 Figure 54 Figure 55 Figure 56 Figure 57 Figure 58 Figure 59 Figure 60 Figure 61 Figure 62 Figure 63 Figure 64 Figure 65 Figure 66 Figure 67 Figure 68 Figure 69 Figure 70 Figure 71 Figure 72 Figure 73 Figure 74 Figure 75 Figure 76 Figure 77 Figure 78 Figure 79 Figure 80 Figure 81 Figure 82 Figure 83 Figure 84 Figure 85 Figure 86 Figure 87
12
Due Date Dialog Box .................................................................................................. 90 Global Variables Dialog Box ....................................................................................... 91 VA Variables Dialog Box............................................................................................. 92 PostProcessor Dialog Box .......................................................................................... 93 Deploy TaskVariables Dialog Box............................................................................. 97 OD Variables Dialog Box .......................................................................................... 100 Email TaskVariables Dialog Box............................................................................. 102 Shared By Dialog Box............................................................................................... 112 Reviewers Dialog Box............................................................................................... 115 Timeout Duration Dialog Box .................................................................................... 121 AND Node................................................................................................................. 123 Diagram of the Archival Workflow............................................................................. 126 Diagram of the Author Submit with Deploy Solution Workflow ................................. 127 Diagram of the Author Submit with Email Solution Workflow ................................... 128 Diagram of the Author Submit with Metadata Solution Workflow ............................. 129 Diagram of the Configurable Author Assignment Solution Workflow........................ 130 Diagram of the Configurable Author Submit Solution Workflow ............................... 131 Diagram of the Configurable Default Submit Solution Workflow............................... 132 Diagram of the Publish LiveSiteCS Content Workflow ............................................. 133 Diagram of the Retrieval Workflow ........................................................................... 134 workflowModels Branch ............................................................................................ 141 Content Tab of WorkflowModels Branch .................................................................. 142 Workflow Model Icon................................................................................................. 143 available_models.xml File......................................................................................... 151 Branch Information in available_models.xml File...................................................... 152 Configure Workflow Screen ...................................................................................... 153 Workflow Instantiation Form ..................................................................................... 154 New Job Menu Option .............................................................................................. 158 Select a Workflow Dialog Box................................................................................... 159 Workflow Instantiation Form ..................................................................................... 159 Jobs Listed on the Workflow Tab.............................................................................. 160 Submit Menu Option ................................................................................................. 161 Select a Workflow Dialog Box................................................................................... 161 Workflow Instantiation Form ..................................................................................... 162 New job Listed on the Workflow Tab ........................................................................ 162 Assign Menu Option.................................................................................................. 163 Select a Workflow Dialog Box................................................................................... 164 Workflow Instantiation Form ..................................................................................... 164 New Job Listed on the Workflow Tab ....................................................................... 165 Selected Workflow Model on the Content Tab.......................................................... 166 Jobs and Tasks Links on the Workflow Tab ............................................................. 167 Viewing Workflow Instance Jobs Details ............................................................... 167 Web View of Instantiated Workflow Model................................................................ 168 New Job Link in ContentCenter Standard................................................................. 169 Select A Workflow Screen ........................................................................................ 170 Workflow Instantiation Form ..................................................................................... 171 Check In option in TeamSite Front Office ................................................................. 172 Workflow Model - SampleReview ............................................................................. 177 Configurable Variable - Label (During Design in Workflow Modeler)........................ 181
Figures
Figure 88 Configurable Variable - Label (Member)................................................................... 182 Figure 89 Configurable Variable - Label (Employee) ................................................................ 183 Figure 90 Default Appearance of the Configurable Variable (Employee) ................................. 184 Figure 91 Modified Appearance of the Configurable Variable (Employee) ............................... 185 Figure 92 Modified Instantiation Screen with Additional Fields ................................................. 186 Figure 93 Modified Instantiation Screen (Employee Field is Hidden) ....................................... 187 Figure 94 Datasource Variable Created in Workflow Modeler .................................................. 192 Figure 95 Datasource Variable (With setReadonlyDatasourceItems ()) ................................... 192 Figure 96 Datasource Variable (Without setReadonlyDatasourceItems ()) .............................. 193 Figure 97 Reviewers Property (With setReadonlyReviewerItems ()) ........................................ 194 Figure 98 Reviewers Attribute (Without setReadonlyReviewerItems ()) ................................... 194 Figure 99 Custom Code Workflow ............................................................................................ 216 Figure 100Tutorial: Creating a New Workflow Model ................................................................ 225
13
Figures
14
Intended Audience
This guide is intended for workflow developers and administrators who create, implement, or maintain workflow models. Workflow administrators must be familiar with TeamSite Server administration, or work together with your organizations TeamSite administrator.
Notation Conventions
This manual uses the following notation conventions: Table 1 Bold Notation Conventions
Definition and Usage
Convention
Text that appears in a GUI element such as, a menu item, button, or element of a dialog box, and command names are shown in bold. For example: Click Edit File in the Button Bar. Book titles appear in italics. Terms are italicized the first time they are introduced. Important information may be italicized for emphasis. Commands, command-line output, and file names are in monospace type. For example: The iwextattr command-line tool allows you to set and look up extended attributes on a file.
Italic
Monospace
15
Table 1
Notation Conventions
Definition and Usage
Convention
Monospaced italic
This means that you must replace role and user with your values.
Monospaced bold
Monospaced bold represents information you enter in response to system prompts. The character that appears before a line of user input represents the command prompt, and should not be typed. For example:
iwextattr -s project=proj1 //IWSERVER/default/main/dev/ WORKAREA/andre/products/index.html
Monospaced bold italic text is used to indicate a variable in user input. For example:
iwextattr -s project=projectname workareavpath
means that you must insert the values of projectname and workareavpath when you enter this command.
[] |
Square brackets surrounding a command-line argument mean that the argument is optional. Vertical bars separating command-line arguments mean that only one of the arguments can be used.
This guide also uses the following conventions: The term Windows indicates any supported version of the Microsoft Windows operating system, such as Windows 2000. For TeamSite server, directory paths use UNIX conventions. These conventions mandate using forward slashes (/) in path names. (Windows systems use backward slashes.) The Windows convention is used when referring to a Windows-specific directory. For example:
UNIX: docroot/news/front.html Windows: docroot\news\front.html
Manual Organization
The following chapters are included in this manual: Chapter 1, Introduction. Provides an introduction to the process and tools involved in planning, building, testing, and implementing a workflow model. Chapter 2, Installing Workflow Modeler. Describes the system requirements and procedures for installing and uninstalling the Workflow Modeler.
16
Manual Organization
Chapter 3, Using Workflow Modeler. Provides an introduction to the Workflow Modeler user interface (UI) including drawing tools, activity panes, toolbars and menus. It also describes the procedures for logging into, and publishing your workflow models to your TeamSite Server. Chapter 4, Working with Element Attributes. Describes the attributes (also known as properties) that can be assigned for each type of workflow element (Tasks, Links, and Nodes). Also describes the variable types (CONFIGURATION, SCRIPTING, DATASOURCE, and System) available in the Workflow Modeler. Chapter 5, Predefined Workflow Models. Describes the predefined workflow models that are installed with the Workflow Modeler. You can use these workflow models in your production environment, or modify them to better fit your organizations needs. Chapter 6, Managing and Configuring Workflow Models. Describes the procedures for managing and configuring workflow models that have been published to your TeamSite server. Chapter 7, Instantiating Workflows. Describes the procedure for instantiating workflow models in ContentCenter interfaces. Workflow models are typically instantiated as New Jobs, Submit and Assign operations, and other places within TeamSite. Chapter 8, Customizing the Instantiation Screen Describes the procedure for customizing the instantiation screen. It also provides information on adding dynamic behavior to the instantiation screen. Chapter 9, Using Datasource Framework Provides an introduction to the Datasource framework. In addition, includes information on creating Datasources. Chapter 10, Using Custom Code Provides information on developing custom code that you can execute during the workflow instantiation. You can use this custom code to modify the workflow properties, add files to the workflow, and/or remove files from the workflow. Appendix A, Workflow Modeler Tutorial. Describes how to create a workflow model and make it available to end-users logged in to your TeamSite server. Use this tutorial to learn the basic skills you will need to develop workflow models, and to learn about some of the features available in Workflow Modeler. Appendix C, Datasource Example. Provides information on creating a sample Datasource. Appendix B, Workflow Schemas. Provides information on the configuration files used by workflow models. Appendix D, Troubleshooting. Provides a list of error messages (and possible solutions) you may encounter while working in the Workflow Modeler. These errors listed here are ones that must be resolved before the workflow model can be published to TeamSite.
17
18
Chapter 1
Introduction
Workflow encompasses the procedures, tasks, people, and rules that define business practices and processes within an organization. Using Workflow Modeler to define workflow models and TeamSite to automate themensures that the business practices associated with your content are performed in a logical and consistent manner. This chapter provides an introduction to general workflow models, the Workflow Modeler functionality, and TeamSite integration. The following sections are included: Workflow Lifecycle Workflow Terminology Creating Workflow Models with Workflow Modeler TeamSite and Workflow Models
Workflow Lifecycle
Conceptually, workflow development consists of the following sequential phases: Design. Understanding the business process being modeled and breaking it down into logical tasks. The output from the design phase is a generic workflow model created outside of the Workflow Modeler. Development. Using the Workflow Modeler to create a TeamSite workflow model. Publishing. Transferring the completed workflow model to the TeamSite server and making it available to TeamSite users. Managing workflows. You can control which workflow models are available to each branch. Workflows can be subscribed to from the Manage Workflows link on the Administration tab in ContentCenter Professional. Configuring workflows. For different branches or folders, workflow models which contain variables can be configured to behave differently depending on the branches or folders
19
Chapter 1: Introduction
within which the workflow is instantiated. For more information on configuring the workflow models, see Chapter 6, Managing and Configuring Workflow Models. Execution. Instantiating and executing a job that uses the workflow model. In practice, the phases typically occur iteratively as the underlying business process is better understood and as development and testing occur. The following graphic shows the various stages of a workflow model from development through publishing, managing, and instantiation. It also notes the different users associated with the workflow models lifecycle. Figure 1 Workflow Model Lifecycle
Workflow Terminology
This section defines workflow terminology as it relates to the Workflow Modeler and TeamSite. Many of these terms have more general definitions outside of the context of TeamSite. It includes information on the following terms: Workflow Models Tasks Jobs
20
Workflow Terminology
Workflow Models
A workflow model is a general description of a recurring business process. Each workflow model describes a job consisting of a series of tasks, or units of work, and can be represented by a flow diagram, illustrating the series of tasks and the links (or transitions) between them. The following graphic shows a simple assign-edit-approve-deploy workflow model. Email is sent to the participants at each stage of the process, and an automated content deployment task is performed at the end. Figure 2 Sample Workflow Model Diagram
Tasks
Depending on the context, a task can be two different things: A logical unit of work when describing business processes or workflow models.
21
Chapter 1: Introduction
An actual unit of work performed by a single user or process during the execution of a specific job. Each task is associated with a TeamSite branch and workarea and, possibly, one or more files. The user or process owning a task can modify, add files to, or remove files from the task (provided the task is not a read-only task for content approval). Tasks have two possible states: Active. A task becomes active when its predecessor task signals it to do so (predecessor tasks and conditions for activation are all configured as part of the workflow model). After a task has been activated, users or external programs can work on it. Inactive. Tasks that have been completed, or that have not yet been activated.
Jobs
A job is a specific instance of a workflow model. The previous graphic depicts a generic workflow model that could be transformed into a job by defining specific TeamSite users. For example, Bob could be defined as the editor and Jerry as the author. Additionally, the specific files that need to be edited could be defined as press_release.html and banner.gif. Because jobs follow predefined workflow models, tasks cannot be added to or removed from individual jobs after jobs have been instantiated. In TeamSite, when a job is created, the job creator supplies all the specific information for that job, effectively filling out the workflow model to create a job specification. When a job specification is loaded into the workflow subsystem, it becomes a job.
Creating a workflow model typically includes: Adding Elements Assigning Element Properties Publishing Workflow Models
Adding Elements
TeamSite workflow models (as opposed to the generic workflow models) are constructed using the Workflow Modeler and contain the following elements: One Start node One End node One or more tasks Links between the Start node and a task, between a task and other tasks, and between the final task and the End node. Optional logical nodes for the Boolean operators AND, OR, and NOT. Workflow elements are described in detail in Workflow Modeler GUI Elements on page 37.
23
Chapter 1: Introduction
24
tfo_workflow tt_data
(saving FormsPublisher data records) (deleting FormsPublisher data records in ContentCenter Standard only)
tt_deletedcr
After selecting a listed workflow model, the instantiation screen appears. Depending on your customization, the variables are displayed. Clicking Submit on the instantiation screen creates a job spec and a new workflow job is created. For detailed information about using TeamSite with workflow models, see Managing and Configuring Workflow Models on page 137 later in this document, and TeamSite User Interface Administration Guide for general administrator information.
25
Chapter 1: Introduction
26
Chapter 2
System Requirements
Ensure that you install Workflow Modeler on one of the following operating systems: Windows XP SP1, XP SP2, 2000 SP4, or Vista Linux AS 4.0 Solaris 2.9 or 10
If you encounter any error during the installation, see Appendix D, Troubleshooting. 1. Download or locate the Workflow Modeler package. 2. Extract the package contents.
27
A new folder Wfm is created, and the package files are extracted into this folder. 3. Navigate to the Wfm folder, and run the install.bat file. The Introduction screen appears. Figure 3 Introduction Screen
4. Click Next. The License Agreement screen appears. Figure 4 License Agreement Screen
28
5. Read the license agreement, and if you agree to its terms, select the I accept the terms of the License Agreement option, and click Next. You must accept the terms of the license agreement to install and use the Workflow Modeler. If you accepted the terms and clicked Next, the Product Files screen appears. Figure 5 Product Files Screen
6. Do one of the following: Click Install to accept the default installation folder (for Windows: C:\Interwoven\ WorkflowModeler). Click Choose to navigate to the folder you want to use as the installation folder. After confirming the installation folder, click Install. The Choose Shortcut Folder screen appears.
NOTE
This screen varies based on the operating system you are using. For Windows, the following screen appears.
29
Figure 6
7. Select the location for the Workflow Modeler startup and uninstall shortcuts and click Install. By default, in Windows, the installation program creates the shortcut to start the Workflow Modeler in: C:\Interwoven\iwinstall\modules\wfm. The other shortcut location options are: Table 2
Option
Creates a program group on the Start > All Programs menu. By default, this group is called Interwoven WFM. After selecting this option, you can rename the group. Creates shortcuts to start Workflow Modeler in an existing program group on the Start > All Programs menu. After selecting this option, you can select the existing group from the list. Creates shortcuts to start Workflow Modeler on the Start menu. Creates shortcuts to start the Workflow Modeler on the Windows desktop.
30
Table 2
Option
Creates a shortcut to start Workflow Modeler on the Quick Launch bar. To display the Quick Launch bar: 1. Right-click the task bar near the Start button. 2. Select Toolbars > Quick Launch. Depending on how many programs you have configured to display on the Quick Launch bar, you may need to click the Show All icon (>>) to see the shortcut. This is the default option. It is set to create shortcuts to start Workflow Modeler in: C:\Interwoven\iwinstall\ modules\wfm. You can click Choose to specify a different location for the shortcut. No shortcut icon is created. If you select this option, you must complete the following procedure to start Workflow Modeler: 1. Go to the installation folder selected in step 6. 2. Double-click the WorkflowModeler.exe file.
Other
31
Proceed to Chapter 3, Using Workflow Modeler for information about starting and using the Workflow Modeler.
2. Click Next to remove the Workflow Modeler program files (files created using Workflow Modeler are not removed). The Uninstall Complete screen appears.
32
Figure 9
33
34
Chapter 3
In Windows, if you accepted the default option, WorkflowModeler.exe is located in C:\ Interwoven\WorkflowModeler. The Login dialog box appears. Figure 10 Login Dialog Box
2. Do one of the following: Click Work Offline to work in Workflow Modeler without connecting to a TeamSite server. If you work offline, you will need to connect to the TeamSite server to publish your workflow model by selecting Options > Login to Server in the Workflow Modeler GUI. Enter the following account information and click OK to log in to a TeamSite server. Username. Your TeamSite user name. Password. Your TeamSite password. Domain. The domain where the TeamSite server you are accessing resides, for example, myCompany.com. If you do not know the domain where your TeamSite server resides, contact your TeamSite administrator.
NOTE
For a UNIX server, the domain name is the same as the server name. For example, if your server name is myServer, the domain name, too, is myServer.
36
Port. The ContentCenter HTTP port number. By default, the port no is 80.
After the initial TeamSite login, the same domain, server, and port information is used for future logins. If you need to change any of these settings, click Options to display the corresponding fields. Workflow Modeler appears. The elements contained in the user interface are described in the next section.
NOTE
You can invoke more than one instance of Workflow Modeler. However, Autonomy does not recommend or support this operation.
37
Display toolbar
Properties pane
Project pane
Each of these areas is described in detail in the following sections: Standard Toolbar Links Toolbar Tasks Toolbar Display Toolbar Project Pane Tree Pane Properties Pane
Standard Toolbar
The Standard toolbar includes icons for standard operations such as creating, opening, and saving files. In addition, it includes a few Workflow Modeler-specific operations such as aligning workflow elements, grouping workflow elements, validating workflows, and so on.
38
Standard Toolbar
Name Description
Duplicates the selected workflow elements. Groups the selected workflow elements and creates a subprocess. You can expand or collapse the subprocess. Ungroups the selected subprocess. Arranges all the connected workflow elements horizontally and disconnected workflow elements vertically.
Layout Selected Nodes Arranges the selected workflow elements horizontally if they are connected and vertically if they are disconnected. Automatic Link Layout Hide/Show Property Sheet Validate Workflow Model Sticky Actions Improves the presentation of links. Hides/displays the Properties pane. Validates the workflow. If the workflow contains error(s), the Error pane appears. When enabled, repeats a Project pane drawing operation (for example, adding a User task). You do not have to reselect the same workflow element from the Create menu or the Tasks toolbar.
Links Toolbar
The Links toolbar contains link icons and node icons. Links are placed between tasks and define the transition to the next task. Nodes define the start and end of the workflow model and also include the Boolean operators AND, OR, and NOT.
39
The links and nodes are introduced in the following table. Table 4
Icon
Links Toolbar
Name Description
Start Event
Defines the start of all workflow models. This node is required and must come first. You should add only one Start node for any workflow model. Defines the end of a workflow model. This node is required, must come last, and must be preceded by a Default Link or a Success Link. You should add only one End node for any workflow model. Defines a simple transition from one workflow element to another. Use this link type when there is no need for special logic or conditions. Defines a link that restarts the workflow by an event that precedes it. Defines a link that can be rendered inactive by an event that proceeds it. Defines a link that pauses the workflow for a user-specified period of time. For more information about configuring Timeout Links, see Timeout Links on page 120. Defines the workflow path on which to continue after an event has been successfully completed. Defines the workflow path on which to continue after an event has not been successfully completed. Defines the workflow path on which to continue only if a condition evaluates to True. Two tasks can be linked with any number of Conditional links, but should also be linked by a Default link, so that if all Conditional links evaluate to False, the workflow can continue using the Default link. All tasks linked to this element must be completed before activating a successor task. One of the tasks linked to this element must be completed before activating a successor task. None of the tasks linked to this element must be completed before activating a successor task. Enables you to add text to explain any task or link in a workflow model. It has no bearing on the functionality of the workflow model.
End Event
Default Link
40
NOTE
The links and nodes listed in this table are also available from the Create > Other Elements menu.
Tasks Toolbar
The Tasks toolbar contains task icons. A task is both a logical unit of work, when describing business processes, and an actual unit of work performed by a single user or process during the execution of a specific job. The tasks are introduced in the following table. For more information on their attributes, see Chapter 4, Working with Element Attributes. Table 5
Icon
Tasks Toolbar
Name Description
Defines a task that is assigned to a user. It appears on a users task list in ContentCenter interfaces. Defines a task that specifies one or more users must review assigned work (typically files associated with the task) before the job can continue. Defines a task that is assigned to a group of users. It appears in the task list of each member of the group of users specified in the task. A group task becomes identical in behavior to a user task when one member of the group takes ownership of the task using the ContentCenter interface. Sends email to specified users. You can send emails by specifying a URL (pointing to a class) for the Email Command attribute and by specifying values for the variables using the Variables attribute. Specifies that an external program is run using the
command element.
Group Task
Email Task
Enables you to run a CGI script. Enables the task owner to create metadata for the files associated with the task. Performs a TeamSite Get Latest or Copy to Area operation on files associated with the task.
41
Table 5
Icon
Performs a TeamSite Submit operation on files associated with the task. Performs a deploy operation on files associated with the task. This operation is performed by specifying a URL (pointing to a class) for the Deploy Command attribute. A Deploy task must have a Success outgoing link. For more information on OpenDeploy, see the OpenDeploy documentation. Attempts to acquire locks on files it owns. If it succeeds, it transitions to the successors specified in its success link. If it fails, it transitions to the successors specified by its failure link. This provides users with a way to continue in a job that cannot acquire its locks.
Lock Task
Nested Workflow Task Represents a workflow that can be a job specification file, a workflow model, or a workflow template file. Nested workflows are considered child workflows and the workflow that triggers them is considered the parent workflow. URL Task Dummy Task Specifies a URL to be invoked. Acts as a placeholder for time delays, task resets, or gate transition tasks. A dummy task has no owner or areavpath.
NOTE
The tasks listed in this table are also available from the Create > Tasks menu.
42
Display Toolbar
The Display toolbar contains icons that control the view of the elements displayed in the Project pane. Additionally, some of the icons show or hide panes in the Workflow Modeler GUI. The display tools are introduced in the following table: Table 6
Icon
Display Toolbar
Name Description
Make Selection Active Selects an element in the Project pane. The selected element is outlined in red in the Project pane, and any associated properties are displayed in the Properties pane. Zoom In* Zoom Out* Zoom Box Reset Zoom* Increases the magnification of the area of the Project pane where you click. Decreases the magnification of the area of the Project pane where you click. Defines a rectangular area of the Project pane to display. Resets the magnification of the Project pane to the default setting. This option is not active when the default magnification is selected. Displays all elements in the Project pane as large as possible without cropping out any element. Moves the view displayed in the Project pane by dragging all the elements equally up, down, left, right, or diagonally in the pane. The magnification is not changed by panning. Hides or displays the Tree pane. For information about the Tree pane, see Tree Pane on page 50.
Hide/Show Tree*
Hide/Show Overview* Displays either the Properties pane or the Overview pane. For information about the Properties pane, see Properties Pane on page 52. The Overview pane enables you to modify the display of the elements in the Project pane by dragging the border of the Project pane relative to the elements displayed within it. From the Overview pane, you can click a tab to return to the Properties pane.
43
NOTE
The features marked with an asterisk (*) are also available from the View menu. The View menu also includes an option to display an alignment grid in the Project pane, and to display the Error pane (described on page 54).
Options Menu
The Options menu contains a number of drawing tool options that determine how Tasks, Links, and Nodes are edited, added, and viewed in the Project pane. It also contains the Validate Workflow option, the options for logging into and out of TeamSite, and the options for changing the application settings. Figure 12 Options Menu
A checkmark next to a menu option shows that it is enabled. The Options menu features are introduced in the following table. Table 7
Option
Allow Editing
When enabled, unlocks the Project pane so that the elements can be added, edited, or deleted from the workflow model. Note: When this option is not selected, the editing options throughout the application are disabled. When enabled, this option does not prevent you from selecting an element in the Tree pane, and editing it in the Properties pane.
44
Table 7
Option
Sticky Actions
When enabled, you can repeat a Project pane drawing operation (for example, adding a link) without returning to the Create menu or the Tasks toolbar to reselect it. Displays the Grid Spacing dialog box where you can specify the Project panes grid size (in points). The grid is displayed or hidden by selecting the Grid option in the View menu. Validates the current workflow against an included schema to ensure the workflow model contains the required elements. There is also a toolbar button for this option. For more validation information, see Errors Pane on page 54. Displays the server Login dialog box if you are currently using the Workflow Modeler in the offline mode. Logs you out of the TeamSite server if you are using the Workflow Modeler in the online mode. Enables you to configure the application settings, for example, you can select the desired shortcut key for displaying global variables in the Script editor. For more information, see Configuring Application Settings on page 45.
Grid Spacing
Validate Workflow
45
You can configure the following options using the Preference dialog box: General Appearance Shortcut Keys
NOTE
All these options are enabled in the online mode only. If you are using the Workflow Modeler in the offline mode, some of the options are disabled.
General
Enables you to configure generic settings of the application. To display the General tab of the Preference dialog box, select Options > Preference > General.
46
You can configure the following: Whether a confirmation message should appear after you publish (upload) a workflow model. Whether the application should prompt you to validate a workflow model before saving it. Whether the login screen should appear when you invoke the application. Whether the login screen should display all the fields (username, password, domain, server, and webport fields), at the time of login, as shown in Figure 10 on page 36. By default, this option is selected. You have to provide the values for the username, password, domain, server, and webport fields at the time of login. This option allows you to change the previously entered values for domain, server, and web server port fields. If you deselect this option, the login screen displays the fields for capturing the username and password only. You have to provide values for these two fields. The Workflow Modeler application retains the previously entered information for domain, server, and web server port fields. Click Server Info shown in Figure 10 on page 36 to change the previously entered values for these fields.
NOTE
Appearance
Enables you to change the theme of the application. A theme determines the overall appearance of the application.
47
To display the Appearance tab of the Preference dialog box, select Options > Preference > Appearance. Figure 15 Preference Dialog Box - Appearance Node
Shortcut Keys
Enables you to set or modify shortcut keys for various actions in the application. To display the Shortcut Keys tab of the Preference dialog box, select Options > Preference > Shortcut Keys. Figure 16 Preference Dialog Box - Shortcut Keys Node
48
You can assign a shortcut key for displaying global variables in the script editor, which is used while creating SCRIPT variables. For more information on SCRIPT variables, see Script Variables ($IW_SCRIPT) on page 70.
NOTE
Project Pane
The Project pane is displayed by default as a blank project labeled Unnamed (1). The Project pane is used as the drawing area where you add and arrange visual elements that compose your workflow models. These elements include the Tasks, Links, and Nodes described in Links Toolbar on page 39 and Tasks Toolbar on page 41. The following graphic shows the Project pane containing a simple workflow model. Figure 17 Project Pane with Workflow Model
Note the following in the graphic: The project has been saved in the default location (C:\Documents and Settings\ user_name\My Documents), in a file named test1 using the default extension .ipm. The alignment grid has been activated from the View menu. The project contains the required Start and End nodes.
49
All the tasks and links are displayed with their default labels. These can be modified to be more descriptive as described in Assigning Common Task Attributes on page 79 and Assigning Common Link Attributes on page 118. In general, the model describes a simple workflow where: A user performs some workauthoring a Press Release for examplethen sends it to a reviewer. If the reviewer approves the work, it is submitted to a TeamSite workarea. If it is rejected, it is sent back to the author who must revise it and resubmit it for approval and submittal.
After it is submitted to TeamSite, it is deployedfor example, to a website. The mechanisms for passing the document and notifications in the workflow are not specified. They could be any number of system notifications, typically email. Continue to the next section where the test1.ipm workflow model is used to introduce you to the Tree pane.
Tree Pane
The Tree pane lists the elements in a workflow model in a tree view list. The elements are listed in the order they were added to the project. By default, all projects begin with a Workflow Model node and a Workflow Properties sub-node. These nodes are shown at the top of the following Tree view of the test1.ipm workflow model shown in Figure 18 on page 51.
50
Note the following in the graphic: The task elements in the tree view are listed in the order they were added to the workflow model. Therefore, the tasks are listed before the links (Flow8 through Flow 14). The seventh element that was added to the project was deleted during development. There is not an element labeled Task7 or Flow7. Therefore, this element was added to the project after the End6 node, and then deleted before the first link (Flow8) was added. Each link contains a label that states the tasks that it links. For example, the first of the three Success links comes between ReviewTask3 and SubmitTask4. The links are color-coded to identify the type of link: Black. Default link Blue. Reset link Light Brown. Inactivate link Dark Brown. Timeout link Green. Success link Red. Failure link Gray. Conditional link Continue to the next section where the test1.ipm workflow model (shown in Figure 17 on page 49) is used to introduce you to the Properties pane.
51
Properties Pane
The Properties pane is used to assign and display values and descriptions of the selected element in a workflow model. An element may be selected by clicking it in the Project pane (in which case it is outlined in red) or in the tree view.
NOTE
The Properties pane is displayed by default, but can be hidden if Hide/Show Overview is clicked (see Hide/Show Overview* on page 43).
The following graphic shows the Properties pane for the Workflow Properties element from the test1.ipm workflow model (shown in Figure 17 on page 49). Figure 19 Properties Pane
Note the following in the graphic: Some of the General properties have been assigned.
NOTE
Ensure that the required properties (indicated as bold labels) have values assigned to them. The test1 project is: Described as an Approve/deploy workflow model.
52
Due to be completed (that is, successfully deployed) by September 04, 2006. Dates are displayed using the YYYY-MM-DD format where YYYY is year, MM is month, and DD is day. Owned by $IW_USER. This variable represents the user currently logged in to TeamSite. A Medium priority (0 is Very High, 1 is High, 2 is Medium, 3 is Low, and 4 is Very Low). The minus sign (-) next to the General, Flags, System Variables, and System headings can be clicked to collapse the corresponding property group. If a group is collapsed, a plus sign (+) appears. Continue to the next section where the test1.ipm workflow model (shown in Figure 17 on page 49) is used to introduce you to the Overview pane.
Overview Pane
The Overview pane is similar to the Project pane in that it shows a graphical representation of a workflow model. It differs in that it always shows the entire workflow model, and superimposes a rectangular outline over the graphic to represent the area that is currently shown in the Project pane. Figure 20 Overview Pane
Note the following in the graphic: One of the Zoom tools has been used to magnify the image in the Project pane.
53
The Overview pane shows the entire workflow model and outlines the area currently shown in the Project pane. The Flow11(ReviewTask3->SubmitTask4)is a Success link and it appears in green when not selected. You can drag the black outline rectangle, or click within the Overview pane to move the rectangle, to change what is displayed in the Project pane. You cannot select elements in the Overview pane. When you use the Pan tool ( ) in the Project pane to display a different area of the workflow model, the Overview pane is updated. A tab to display the Properties pane is included at the top of the Overview pane. Continue to the next section where the test1.ipm workflow model (shown in Figure 17 on page 49) is used to introduce you to the Error pane.
Errors Pane
The Workflow Modeler includes a validation feature (click Options > Validate Workflow or click the Validate Workflow Model toolbar button) that ensures your workflow models are valid by comparing them to an included XML schema. If the model you created is not valid, the errors are displayed in the Error Pane at the bottom of the GUI. If you select any of the rows in the Error Pane, then the appropriate element is highlighted (the element appears gray with red border) and its corresponding properties are displayed in the Properties pane. The following graphic shows that the test1.ipm workflow model used to illustrate this section of this manual contains some errors.
54
Note the following in the graphic: The yellow task boxes in the Project pane show that the validation check was run on this workflow model and the elements that are yellow containor are linked with links that containerrors. The Errors pane appears below the Project pane after you attempt to validate a workflow model. The three errors in the workflow model are listed in the errors table in red text. The error details are shown in the following graphic: Figure 22 Errors Pane Details
55
To resolve the errors in the test1 workflow model, you must: Specify at least one user or group name for the Review task. In addition, specify the number of reviewers. Use the Available Groups, Available Users, and Reviewers properties. For more information, see Review Task Attributes on page 114. Specify a valid deployment name. Use the Variables property. For more information, see Deploy Task Attributes on page 96. This concludes the introduction to the GUI elements. Continue to the next section where the procedure for creating a new workflow model is described.
You can also create new models by selecting File > New or clicking New Workflow Model ( ).
3. Specify a name and location for the file and click Save. Do not change the file type. Workflow models must be saved with the default .ipm extension. The Project pane displays the name and location in the Title bar.
56
The current users TeamSite workarea on the //TS_Server/iwadmin/main/ branch if you logged in to TeamSite using the Workflow Modeler. Start Event node icon, move your cursor to the place in the Project pane
4. Click the
where you want to add this element, and then click to add it. The element is displayed in the Project pane and is listed in the Tree pane as Start (Start1) below Workflow Properties. 5. Click Workflow Properties in the Tree pane. The Properties pane displays the properties for the current workflow model (test1).
57
6. Click next to any of the attributes to assign a value or enter a description. Each task, link, and node has its own set of attributes; required properties use bold labels. For more information on setting Flags and System Variables, see Chapter 4, Working with Element Attributes.
NOTE
ID and Name attributes always have same values. A default value is assigned to the Name attribute when you create a workflow element. You have the option to change this default value. The changed value is reflected in the ID attribute once you move the cursor out of the Name attribute. 7. Click a task icon, move your cursor to the place in the Project pane where you want to add this element, and then click to add it. 8. Add a link: a. Click a link icon in the Links toolbar (for information on link types, see Links Toolbar on page 39).
58
b. Click the Start node in the Project pane. c. Click the task icon you added in step 7. The link is drawn between the two elements. d. Click the link in either the Task pane or the Project pane. The link appears in red (to show it is selected), and its default properties are displayed in the properties pane. e. Depending on the type of link you added, you may be able to click next to any undefined properties and assign a value. For example, if you added a Timeout link, you must set the timeout duration in the Properties pane. 9. Continue adding tasks, links, and nodes (also located on the Links toolbar) and define their associated properties as described previously in this procedure. 10. Add an End nodeand a link to itto complete the workflow model. 11. Click
NOTE
When you save a workflow model, .ipm and .xml files are created. Both these are XML files. The .ipm file is the actual workflow XML. It contains information on the workflow elements that form the workflow model. The .xml file contains information on CONFIG, DATASOURCE, and SCRIPT variables that you added in your workflow model. Both these files are needed for the workflow model to work.
3. Double-click the workflow model file you want to edit (they have .ipm extensions). By default, workflow models are saved to:
C:\Documents and Settings\user_name\My Documents
working in Offline mode. Current users TeamSite workarea on the //TS_Server/iwadmin/main/ workflowModels/WORKAREA/iw-wa/Models branch if you logged in to TeamSite you started Workflow Modeler. when
59
The file is displayed in the Workflow Modeler Project pane. 4. Edit any of the elements already contained in the project, or add new elements.
Before submitting the workflow model, a copy is also stored in the following Workarea:
//TS_Server/iwadmin/main/workflowModels/WORKAREA/iw-wa/Models
All files submitted to this branch are subject to a default workflow that: Submits the workflow model (the .ipm file). Validates the workflow model against a schema (BPMNModel.xsd). To publish a workflow model to your TeamSite server, complete the following steps: 1. If you are not logged into your TeamSite server, select Options > Login to Server. The Login dialog box appears.
60
NOTE
If the Domain, Server, and Web Server Port fields are not displayed, click Server Info and ensure that the TeamSite server information is correct. 2. Enter your TeamSite credentials to log into TeamSite, and click OK. 3. Select File > Publish Workflow. A message is displayed confirming the workflow model was published, or that there are errors that must be resolved before it can be published.
NOTE
If the publish operation fails for any reason, then the lock, which is acquired on the workflow model just before publishing, is retained. You need to manually release the lock.
TeamSite) or a published workflow model (located in the Staging area of the workflowModels branch). To retrieve a workflow model: 1. Select File > Retrieve from Server. The Retrieve from Server dialog box appears. Figure 26 Retrieve from Server Dialog Box
2. Identify the workflow model you want to retrieve, select its state (Draft or Published) from the State column, and click OK. If you select the Draft state, the workflow model is retrieved from //TS_Server/iwadmin/
main/workflowModels/WORKAREA/iw-wa/Models
However, if you select the Published state, the workflow model is retrieved from //
TS_Server/iwadmin/main/workflowModels/STAGING/Models
NOTE
After upgrading your TeamSite server, if you retrieve a workflow model using the Published state, you are prompted to overwrite the workflow model in the iw-wa workarea with the one you retrieve from Staging. This happens because the workarea files are marked as modified when the branch and workarea permissions are changed during the upgrade process. You can select any option, because the files have not been actually modified.
62
The only way to convert older .wft models to the new Workflow Modeler models is to manually recreate them using Workflow Modeler. The Create > Convert Workflow option only applies to the workflow models created using the older versions of Workflow Modeler. This option does not convert .wft models to Workflow Modeler models.
The workflow schema has undergone the following changes: The workflow property sheet includes two new attributes: PreProcessor Command and PostProcessor Command. For the Nested task, the following attributes have been replaced with the Workflow attribute: Job Spec File, Workflow Model, and Workflow Template. Deploy task includes a new attribute, OD Variables. In addition, the default value of the Deploy Command attribute has been modified. For the Email task, the default value of the Email Command attribute has been modified.
63
64
Chapter 4
Datasource variable (see Datasource Variables ($IW_DS) on page 68) Script variable (see Script Variables ($IW_SCRIPT) on page 70) These variables are available for most attributes of the workflow model elements. Their values are resolved just before instantiation. Therefore, they appear as strings or Boolean values in the final job specification file. These variables are automatically assigned an ID. You can change the default ID to a more intuitive value (for example, MyVar). However, ensure that the ID: Is unique Begins with a character Does not contain just numbers Does not contain just space(s)
You can define a default value when creating the workflow model and allow that it be changed during customization or instantiation of workflows.
Configurable variables are defined in the dialog box displayed by clicking next to a property in the Workflow Modeler Property pane. The following graphic shows the dialog box for creating a Configurable variable associated with a tasks Brief Description.
66
After creating the variable, it is available for reuse (identified by the variable type, and the ID) from the Properties pane: Figure 28 User-defined Configurable Variable Available for Reuse
In addition to assigning an ID, the configurable variable dialog box prompts you for the following information: Label. This value is displayed in the TeamSite instantiation and configuration forms. Labels are used to identify the variable (required field). Default Value. This is the default value for the property (optional field).
67
Description. This value is displayed in TeamSite instantiation and configuration forms. It provides detailed information about the property than the Label can (optional field). Read only. Specifies whether this property should be read-only or writable during instantiation. Hidden. Specifies whether this property should be hidden or visible during instantiation.
While Datasource variables are more useful for some properties than others, they are included for all the properties.
Datasource variables are defined in the dialog box displayed by clicking next to a property in the Workflow Modeler Property pane. The following graphic shows the dialog box for creating a Datasource variable associated with a tasks Brief Description.
68
After creating the variable, it is available for reuse (identified by the variable type, and the ID) from the Properties pane: Figure 30 User-defined Datasource Variable Available for Reuse
The Datasource variable dialog box prompts you for the following information: ID. Unique system-generated identifier for the variable. You can modify it to a more intuitive value. Datasource Name. Drop-down menu lists all the Datasources registered with your TeamSite server (required field).
69
Autonomy provides out-of the-box Datasources (TS User Picker, TS Branch Picker, and Map User Picker). For more information on using these Datasources, see Using Out-of-the-Box Datasources on page 201. Label. This value is displayed in the TeamSite instantiation and configuration forms. Labels are used to identify the variable (required field). Default Value. This is the default value for the property.
NOTE
This field is automatically populated with the return value of the selected Datasource component. Description. This value is displayed in TeamSite instantiation and configuration forms. It provides more detailed information about the property than the Label can (optional field). Read only. Specifies whether this property should be read-only during instantiation. Hidden. Specifies whether this property should be hidden during instantiation.
In the script editor, you can display a list of global variables using the shortcut key assigned in the Preference dialog box. For more information on global variables, see Global Variables on page 76.
The following graphic shows the dialog box for creating a Script variable associated with a tasks Owner.
70
After creating the Script variable, it is available for reuse (identified by the variable type, and the ID) from the Properties pane: Figure 32 User-defined Script Variable Available for Reuse
The Script variable enables you to write JavaScript for any task, transition link, or node property and have the value returned by the script determine the value assigned to that property. For example, if you create a Script variable for the property MDCaptureUI, you could create the following script to determine which metadata capture screen is displayed to end-users:
71
In this example, $IW_CV(Notify) is a global Configurable variable. If $IW_CV(Notify) is evaluated as true, iwmetadataWithEmail.cgi is set as the value for MDCaptureUI. If $IW_CV(Notify) is evaluated as anything other than true, iwmetadata.cgi is set as the value for MDCaptureUI. The Metadata capture UI that is displayed is determined by which of the two CGI programs (iwmetadataWithEmail.cgi or iwmetadata.cgi) is run. Do not use the return keyword for a statement that directly returns the script result. For example, do not use the following:
where $IW_WFNAME evaluates to the current workflows name. The valid script is as follows:
if("$IW_WFNAME" == "MyWorkflow") { "$IW_WFNAME"; } else { false; }
You can, however, use the return keyword within a function of your script, because the result of a script containing a function is returned using a function call statement. For example:
function myFunction() { 72
The Script variable supports: Dynamic value assignment. Expressions can be defined using global variables and string constants. These expressions are evaluated during runtime and the result is assigned to the appropriate property.
NOTE
Expressions can involve more than one global variable. For example, you could define two global variables named editor and domain. You could then form an expression using these two variables and string constants, and the result can be assigned to the owner of the User task. These two global variables can be used in the expression: domain+\+editor. Conditional task transitions. Tasks can be linked with any number of conditional transitions. If the condition evaluates to True, then that particular transition is used in the workflow model. A Default transition should also be attached to the tasks linked by conditional transitions. If all conditional transitions evaluate to False, the default transition is used. Script verification. The SCRIPT dialog boxes contain an Evaluate tab where you can simulate the execution of the script and verify the results. Previously declared variables.
Variable Name
$IW_HOME
73
Table 8
Variable Name
$IW_PORT
The iwwebd port configured in the iwwebd section of the iw.cfg file that is relevant for the protocol. For example, if the protocol is http (determined by the default_protocol attribute), then the value for this variable is set to the http_port attributes value; else, it is set to the https_port attributes value. If you are hard coding the URL command, make sure there is no mismatch in the protocol and port values as this may lead to errors. For example, having a URL, such as
http://$IW_SERVER:$IW_PORT/ iw-cc/urlexternaltask, may
The iwwebd protocol configured in the iwwebd section of the iw.cfg file. The values can be: http or https. You may use this variable in the URL command of a URL external task, such as $IW_PROTOCOL://
$IW_SERVER:$IW_PORT/iw-cc/ urlexternaltask.
If you are hard coding the URL command, make sure there is no mismatch in the protocol and port values as this may lead to errors.
$IW_STORE $IW_SERVER $IW_SESSION $IW_USER $IW_WORKAREA $IW_AREAOWNER $IW_BRANCH $IW_TIME
Current VPaths store TeamSite server name Current users session ID Current users TeamSite user name Current VPaths workarea Current workareas owner Current VPaths branch Current time in milliseconds
74
Table 8
Variable Name
$IW_WFNAME
Variable Name
%workflow; %workflowid; %task; %taskid; %taskowner; %time; %area; %path; %fullpath; %taskcomment; %filecomment;
Name of the job ID of the job Name of the task ID of the task Owner of the task The current wall clock time VPATH of the task's area Path of the file from area root Full path of the file from server root Task-specific comment added to the extended attribute File-specific comment added to the extended attribute
NOTE
Variable Scope
Workflow Modeler enables you to define variables with the following scopes: Local
75
Global
Local Variables
Variables declared for a task, transition link, or node property can be reused only within that task, transition link, or node. Such variables are called local variables. For example, a configurable variable created for one of the attributes of a task can be used by other attributes of the same task. However, it cannot be used by attributes of other tasks, transition links, or nodes.
Global Variables
Variables declared using the Global Variables attribute of a workflow model are called global variables. These variables are available for reuse across that workflow model. All the elements (tasks, transition links, and nodes) of that workflow model can use these variables. For example, a configurable variable created using the Global Variables attribute for a workflow model can be used by all the elements of that workflow model. However, it cannot be used by attributes of other workflow model elements.
NOTE
Do not include the | symbol for a global variables value, because it is used as a delimiter internally.
For more information on Workflow attributes, see Assigning Workflow-Specific Attributes on page 90. Continue to the next section for details about creating variables in the Workflow Modelers Properties pane.
76
Comparison of Variables
The following table provides a comparison of the variables. Table 10 Variable Comparison
Type Description Resolution Stage Use Case Value Assignment
Configurable Enables you to create a workflow model that contains elements whose values do not need to be assigned until the workflow is customized or instantiated in TeamSite.
The values of these 1. To change the 1. Through UI variables get presentation of the (workflow resolved at the time instantiation instantiation of instantiation. screen. form) The job 2. To add client-side 2. Through specification file validation or to Workflow contains only the introduce dynamic Modeler values of these behavior in the variables. instantiation screen by adding the FormAPI or JavaScript code. For more information, see Chapter 8, Customizing the Instantiation Screen. The values of these 1. To change the 1. Through UI variables get presentation of the (workflow resolved at the time instantiation instantiation of instantiation. screen. form) The job 2. To add client-side 2. Through specification file validation or to Workflow contains only the introduce dynamic Modeler values of these behavior in the variables. instantiation screen by adding the FormAPI or JavaScript code. For more information, see Chapter 8, Customizing the Instantiation Screen.
Datasource
Enables you to retrieve data from any location, including-but not limited to-a database, TeamSite, a user-defined class, or a computer's file system.
77
Script
Enables you to write JavaScript for any task, transition link, or node property and have the value returned by the script determine the value assigned to that property. Enables you to set the scope of Configurable, Datasource, or Script variables. For creating these variables with global scope, see Assigning Workflow-Specific Attributes on page 90. When these variables have a global scope, they are common to a workflow and are available for reuse by all the elements within that workflow. Key (variable name)/ value pairs that are set at the task level for use by a task.
The values of these variables get resolved at the time of instantiation. The job specification file contains only the values of these variables. The values for these variables get resolved at the time of instantiation. The job specification file contains only the values of these variables.
To control the flow of Through Workflow a workflow. For Modeler example, you may dynamically remove task(s) from a workflow depending on the value returned by the script variable. To set the values of multiple properties with the same value as that of the global variable, during the design. For example, you can add a Configurable variable as a global variable and then refer to this Configurable variable in two or more properties of a workflow. 1. Through UI (workflow instantiation form) 2. Through Workflow Modeler (pre and post processor commands)
Global
Task
The job specification file contains the variable element, which stores the key and the value.
To allow separate 1. Through CGI tasks and ContentCenter external tasks to interface communicate with 2. Through each other during the Workflow job execution. Modeler To allow separate 1. Through CGI tasks and ContentCenter external tasks to interface communicate with 2. Through each other during job Workflow execution. Modeler
Job
Key (variable name)/ value pairs that are set at the job level for use by various tasks within a job.
The job specification file contains the variable element, which stores the key and the value.
78
Area VPath
Specifies the TeamSite area associated with this task. This attribute is not available for Dummy tasks. In the Properties pane, click the field next to AreaVPath, and then select one of the following values:
$IW_WORKAREA. Variable that is set to the TeamSite example: /default/main/WORKAREA/pattismith.
79
Brief Description
A brief description of what the task does. In the Properties pane, click the blank field next to Brief Description, and then either type a value or select one of the following values:
CONFIGURABLE. DATASOURCE. SCRIPT.
Description
A description of what the task does. 1. In the Properties pane, click the blank field next to Description to display the Description dialog box. Figure 33 Description Dialog Box
2. Type a value in the text box below the Variable Type drop-down list.
80
Alternatively, click the Variable Type drop-down list, and select one of the following values:
CONFIGURABLE. DATASOURCE. SCRIPT.
Name
The name of the task. Each task in a job must have a unique name. By default: The Tree pane displays task names using the following convention:
task_typeTask#(task_typeTask#)
For example: GroupTask4(GroupTask4). The Properties pane displays only the task_typeTask#. Click the Name field in the Property pane to edit the name. For example, if you edited the previous example GroupTask4(GroupTask4) name to rename it LogoUpdate, the Tree pane would show LogoUpdate(LogoUpdate). The Project pane also displays the updated name.
Owner
Username of the tasks owner. This is the person who is responsible for performing the task. This attribute is not available for Group, Review, and Dummy tasks. In the Properties pane, click the field next to Owner (in some tasks the field is blank, in others $IW_USER is the default value), and then select one of the following values:
$IW_USER. Name of the current user, typically the job creator. When a job is created, all its associated tasks are also created. Therefore, any task or attributes that were specified as $IW_USER have their value set to the job creator's user ID. $IW_AREAOWNER. Name of the owner for the current workarea (if you create the job from the workarea view or by using Submit). CONFIGURABLE. DATASOURCE. SCRIPT.
81
Lock
Specifies whether the task attempts to acquire TeamSite locks on all the files it contains when it becomes active. If the task cannot acquire locks for one or more of the files it contains, it releases any locks it has already acquired and tries again every five minutes until it successfully acquires all locks. The Lock attribute is not available on the Submit, Lock, Nested Workflow, URL, and Dummy tasks. The value can be True, False (this is the default), or set using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
Read Only
Prevents users from adding, removing, or modifying files. The Read Only attribute is not available for the Update, Submit, Lock, Nested Workflow, URL, and Dummy tasks. The value can be True, False (this is the default), or set using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
Transfer Only
When set to True and the Lock attribute is also set to True, files that were locked by a predecessor task will have the lock modified when a task becomes active. The Transfer Only attribute is not available on the Submit, Lock, Nested Workflow, and Dummy tasks. The value can be True, False, or set using one of the following variables:
CONFIGURABLE.
82
DATASOURCE. SCRIPT.
Variables
Variables define a key/value pair that can be stored in and retrieved from job instances. They are used to allow separate CGI tasks and external tasks to communicate with each other during job execution. 1. In the Properties pane, click the blank field next to Variables to display the Variables dialog box: Figure 34 Variables Dialog Box
2. Enter a name for this Task variable in the Name field. 3. Enter a value, or select a value for the variable from the Value drop-down list. The options are:
CONFIGURABLE. DATASOURCE. SCRIPT.
System Variables. See TeamSite System Variables on page 73. 4. Click Add.
83
A variable ID is created using the name you entered in the Name field and the variable name from the Value field. The variable ID takes the form Name=Value(system_generated_ID) and is displayed in the text field. For example: reviewStart=CONFIGURABLE(1145748077956).
NOTE
Variable IDs containing the $IW value do not include the system-generated ID. 5. Click OK.
EA Finish Op
Defines how you can set, append, or delete TeamSite extended attributes on the files associated with a task when the task becomes inactive. 1. In the Properties pane, click the blank field next to EA Finish Op to display the EA Finish Op dialog box: Figure 35 EA Finish Op Dialog Box
2. Select the operation you want to perform on the extended attributes when the task becomes inactive from the Operation drop-down list. The options are: Set Append (this is the default operation) Delete 3. Enter a name for the operation in the Name field.
84
4. Enter a value, or select a value for the operation from the Value drop-down list. The options are:
CONFIGURABLE. DATASOURCE. SCRIPT.
5. Click Add. A variable ID is created using the operation you entered in the Operation field, the name you entered in the Name field, and the variable name from the Value field. The variable ID takes the form Operation:Name=Value(system_generated_ID) and is displayed in the text field. For example:
append:test=CONFIGURABLE(1145749393194).
6. Click OK.
EA Start Op
Defines how you can set, append, or delete TeamSite extended attributes on the files associated with a task when the task becomes active. 1. In the Properties pane, click the blank field next to EA Start Op to display the EA Start Op dialog box: Figure 36 EA Start Op Dialog Box
85
2. Select the operation you want to perform on the extended attributes when the task becomes active from the Operation drop-down list. The options are: Set Append (this is the default operation) Delete 3. Enter a name for the operation in the Name field. 4. Enter a value, or select a value for the operation from the Value drop-down list. The options are:
CONFIGURABLE. DATASOURCE. SCRIPT.
5. Click Add. A variable ID is created using the operation you entered in the Operation field, the name you entered in the Name field, and the variable name from the Value field. The variable ID takes the form Operation:Name=Value(system_generated_ID) and is displayed in the text field. For example:
append:test=CONFIGURABLE(1145749393194).
6. Click OK.
WF Variables Finish Op
Defines how you can set, append, or delete TeamSite workflow variables on the job properties when the task becomes inactive. 1. In the Properties pane, click the blank field next to WF Variables Finish Op to display the WF Variables Finish Op dialog box:
86
2. Select the operation you want to perform on the variable when the task becomes inactive from the Operation drop-down list. The options are: Set Append (this is the default operation) Delete 3. Enter a name for the operation in the Name field. 4. Enter a value, or select a value for the operation from the Value drop-down list. The options are:
CONFIGURABLE. DATASOURCE. SCRIPT.
5. Click Add. A variable ID is created using the operation you entered in the Operation field, the name you entered in the Name field, and the variable name from the Value field. The variable ID takes the form Operation:Name=Value(system_generated_ID) and is displayed in the text field. For example:
append:test=CONFIGURABLE(1145749393194).
6. Click OK.
87
WF Variables Start Op
Defines how you can set, append, or delete TeamSite workflow variables on the job properties when the task becomes active. 1. In the Properties pane, click the blank field next to WF Variables Start Op to display the WF Variables Start Op dialog box: Figure 38 WF Variables Start Op Dialog Box
2. Select the operation you want to perform on the variable when the task becomes active from the Operation drop-down list. The options are: Set Append (this is the default operation) Delete 3. Enter a name for the operation in the Name field. 4. Enter a value, or select a value for the operation from the Value drop-down list. The options are:
CONFIGURABLE. DATASOURCE. SCRIPT.
5. Click Add. A variable ID is created using the operation you entered in the Operation field, the name you entered in the Name field, and the variable name from the Value field.
88
The variable ID takes the form Operation:Name=Value(system_generated_ID) and is displayed in the text field. For example:
append:test=CONFIGURABLE(1145749393194).
6. Click OK.
X
X axis coordinate in the Project pane of the selected element. Click the current value to edit it, or click and drag the corresponding element in the Project pane to change this value.
Y
Y axis coordinate in the Project pane of the selected element. Click the current value to edit it, or drag the corresponding element in the Project pane to change this value.
ID
Unique identifier for the selected element. The ID is same as element name and is a read-only value. If you edit the element name, the ID is updated to reflect the change.
89
Due Date
Due date of the workflow model. That is, the date when the workflow model should be successfully deployed. The date can be set using the Date control available in the Due Date dialog box. Figure 39 Due Date Dialog Box
Priority
Sets the priority level for the workflow model. The priority level helps users in identifying the importance level of a job. The value can be set to 0 - Very High, 1 - High, 2 - Medium, 3 - Low, 4 - Very Low. Specifies whether a text area should be displayed for each of the attached files during instantiation of a new job in TeamSite. The value can be True or False (this is the default).
File Comments
90
Global Variables
Variables that are available across the workflow model. All the workflow model elements can use these variables. You can add more than one variable using the Global Variables dialog box. Figure 40 Global Variables Dialog Box
91
VA Variables VisualAnnotate variables that determine the functionality and appearance of the VisualAnnotate toolbar of the VisualAnnotate tool. VisualAnnotate is a review tool that enables reviewers to annotate HTML pages using tools installed on their web browsers. For more information on the VisualAnnotate tool, see TeamSite Workflow Developers Guide. In the VA Variables dialog box, you can either enter a value or set these variables to a predefined value. Figure 41 VA Variables Dialog Box
92
PostProcessor Specifies commands that are sequentially executed just before the Command workflow job is created, that is, before the job spec XML is generated. After adding the commands, you can specify the order in which they should be executed using the Up and Down buttons.
You can use the post-processor commands to perform a variety of tasks. For example, you can: Modify the properties of a workflow models task. Remove a file attached to a workflow job. Figure 42 PostProcessor Dialog Box
PreProcessor Specifies commands that are sequentially executed just before the Command instantiation screen is rendered. You can use the pre-processor commands to perform a variety of tasks. For example, you can: Modify the properties of a workflow models task. Attach an additional file to a workflow job for submission. The dialog box for the PreProcessor Command property is similar to the PostProcessor Command property. For both PreProcessor Command and PostProcessor Command properties, you can specify in-process and out-of-process commands.
93
NOTE
Autonomy recommends you to use in-process commands, as you can have better control over the properties of all the workflow elements.
For example:
inprocess:com.interwoven.processtest.CustomCodeDemo:role=author
For example:
//TS_Server/iw-home/bin/perl c:/test.ipl
For information on developing custom code for in-process commands, see Chapter 10, Using Custom Code. Besides PreProcessor Command and PostProcessor Command properties, you can set values for all the workflow properties using one of the following variables too:
CONFIGURABLE. DATASOURCE. SCRIPT.
Group Task Attributes Metadata Task Attributes Nested Workflow Attributes Review Task Attributes Submit Task Attributes Update Task Attributes URL Task Attributes
Name of the CGI script to be run. When you specify the name of the CGI script, the TeamSite server automatically locates it because, by default, the script is placed in the following location: iw-home/httpd/iw-bin. Specifies whether a CGI task script can run immediately upon the CGI task becoming activated under the situations listed in the description of the CGI task element. The value can be True or False (this is the default).
Immediate
Alternatively, you can set the values for all these attributes using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
95
Deploy Command
URL for the class that includes implementation for invoking a deployment process on files associated with the task and for processing the variables specified using the Variables attribute. By default, the value for Deploy Command is:
http://$IW_SERVER/iw-cc/urlexternaltask
If the TeamSite server is deployed onto an application server that is running on a port other than the default port 80, then, set the Deploy Command property to http://$IW_SERVER:<changed_port>/iw-cc/ urlexternaltask. For example, if you use port 82, then you must set the Deploy Command to http://$IW_SERVER:82/iw-cc/urlexternaltask. If the TeamSite client EAR is deployed onto an application server that is running on a port other than the default port 8080, perform the configuration changes mentioned for the error numbered 19 in Table 38 on page 257. Retry Specifies whether a failure to execute a task results in a subsequent attempt. You can control the frequency of subsequent attempts using the external_task_retry_wait parameter available in the TeamSite server configuration file, iw.cfg. The iw.cfg file is located in iw-home/etc. Set external_task_retry_wait to the number of minutes you want the workflow engine to wait before it re-attempts to run an external task after failing. Defaults to 1 minute. The value can be True or False (this is the default).
96
Variables
Specifies variables used by the Deploy Command attribute to invoke a deployment process using the specified values. Figure 43 Deploy TaskVariables Dialog Box
You can specify values for the following variables: odDeploymentName (required). A valid deployment name in the OpenDeploy server. Do NOT include the file extension. For example, the deployment name should be test, not test.xml. ClassName (optional). Fully qualified class that contains custom implementation. If you do not specify a class, the following default class is used:
com.interwoven.ui.teamsite.workflow.task.urltask. DeployURLExternalTask
You can create a custom deploy task to suit your business requirements, such as, having two deployments within a task or determining which deployment to run at execution time. For more information on creating a custom deploy task, see Creating a Custom Email Task on page 103, as the steps are similar. odHost (optional). Name of the server where OpenDeploy is running. It is optional if OpenDeploy and TeamSite are running on the same server. odPort (optional). Port where OpenDeploy is running. The default value is 9173. If left blank, the default value is used. It is optional if OpenDeploy and TeamSite are running on the same server.
97
odDeploymentInst (optional). In the Name list-box, type odDeploymentInst to add this variable. This option enables you to creates a unique deployment name for each instance of a deployment configuration. The deployment name and the instance name are combined together to form the complete deployment name. For example, if the value of this variable is foo and the deployment name is test, then the instance name is testfoo. It is equivalent to running the iwodstart CLT with -inst foo.
98
OD Variables
Key-value pairs that are added to the task as task variables. These variables are used by the Deploy task to perform parameterized deployment. Using this option, you can alter the deployment configuration at run-time. The OD variables that are added using the Workflow Modeler are passed as deployment substitution parameters to the OpenDeploy configuration file, when the Deploy task is invoked. So, the OD variables that you add must have a one-to-one relationship with the substitution parameters in the deployment configuration file (present under od-home/conf folder). For example, if there is a parameter srcarea defined in the deployment configuration file, then the corresponding OD variable that you add in the Workflow Modeler must be named srcarea, only. To set the value of the newly added OD variable, either enter a value or choose one of the options from the OD Variable Value list-box (see Figure 44 on page 100). For more information on deployment substitution parameters, see the Parameter Substitution section in the OpenDeploy Deployment Configuration Guide. As a result of addition of the OD variable, a corresponding task variable is added to the Deploy task and is prefixed with odSubst_ (in this example, it is odSubst_srcarea). In addition to the OD variables that you create, the Deploy task makes available the following deployment substitution parameters: area. The filesystem path to the area assigned to the Deploy task. This parameter is useful because OpenDeploy relies on file system paths for deployments. For example, in: Windows: Y:\default\main\WORKAREA\wa Solaris: /iwmnt/default/main/WORKAREA/wa filelist. The path of the temporary file that stores the list of files attached to the workflow. edition_name. The name of the area assigned to the Deploy task. For example, if the areavpath of the task is /default/main/EDITION/ ed_0004, then the value of the edition_name parameter is ed_0004. areavpath. The vpath to the area assigned to the Deploy task. You can use the variables (area, filelist, edition_name, and areavpath) with any deployment configuration. Use of them is not mandatory.
99
100
Email Command
URL for the class that includes implementation for generating an email and for processing the variables specified using the Variables attribute. By default, the value for the Email Command property is:
http://$IW_SERVER/iw-cc/urlexternaltask
You can retain this value and use default email templates, which can be specified using the Variables attribute. If the TeamSite server is deployed onto an application server that is running on a port other than the default port 80, then, set the Email Command property to http://$IW_SERVER:<changed_port>/iw-cc/ urlexternaltask. For example, if you use port 82, then you must set the Email Command to http://$IW_SERVER:82/iw-cc/urlexternaltask. If the TeamSite client EAR is deployed onto an application server that is running on a port other than the default port 8080, perform the configuration changes mentioned for the error numbered 19 in Table 38 on page 257.
101
Variables
Specifies variables used by the Email Command attribute to format the email and to transfer control to the specified task after completing the Email task execution. Figure 45 Email TaskVariables Dialog Box
You must specify values for the following variables: mail_template. Template (XSL) to be used for generating emails. Include the path too. For example, /iwadmin/main/config/
STAGING/workflow/email/ configurableAuthorNotification.xsl
ClassName. Fully qualified class that contains implementation for processing the specified email template. For example,
com.interwoven.ui.teamsite.workflow.task.urltask. AuthorMailNotificationTask
target_task_name. Specify a workflow model task, whose owner will receive a mail from the owner of the Email task. For example, if you set the value of target_task_name to ReviewTask3, then when the Email task gets activated, an email is sent from the owner of the Email task to the owner of ReviewTask3. If you are using default mail templates and classes, use the following combination: For authorNotification.xsl or configurableAuthorNotification.xsl, use the AuthorMailNotificationTask class. For reviewerNotification.xsl or configurableReviewerNotification.xsl, use the ReviewerMailNotificationTask class.
102
Retry
Specifies whether a failure to execute a task results in a subsequent attempt. You can control the frequency of subsequent attempts using the external_task_retry_wait parameter available in the TeamSite server configuration file, iw.cfg. The iw.cfg file is located in iw-home/etc. Set external_task_retry_wait to the number of minutes you want the workflow engine to wait before it re-attempts to run an external task after failing. Defaults to 1 minute. The value can be True (this is the default) or False.
Alternatively, you can set the values for all these attributes using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
After setting these values, modify the iw.cfg file, which is the main TeamSite server configuration file. By default, the file is located in /etc (Solaris) or iw-home/etc (Windows). Under the [iwsend_mail] section of the iw.cfg file, assign appropriate values to the maildomain and mailserver variables. See the following example:
... ... [iwsend_mail] maildomain=mycompany.com mailserver=mail.mycompany.com ... ...
In addition, ensure that correct email IDs are specified for TeamSite users (author, reviewer, and so on) who will receive emails. For information on editing TeamSite user details, see ContentCenter Professional Users Guide or the online documentation for ContentCenter Professional.
103
company logo) or maybe quite extensive. Also, the desired message format maybe different for different situations (different tasks or different workflows). To create a custom Email task: 1. Create a custom class, which implements the CSURLExternalTask interface. 2. Incorporate the appropriate logic in the execute() method of this class. 3. Register your custom class with the TeamSite: a. Navigate to the iw-home/local/config/lib/content_center/customer_src/src/ <package structure> folder and place the source (.java) file in this folder. For example, if the .java file is defined with package com.example.product, then place this file in iw-home/local/config/lib/content_center/customer_src/src/com/
example/product/.
b. From the command prompt, go to iw-home/local/config/lib/content_center/ customer_src and run make_toolkit.ipl. 4. From Workflow Modeler, create a workflow model with an Email task. 5. For the Email task, set the values for the required fields.
NOTE
While setting the values for the various fields, ensure that you specify the fully qualified class that contains custom implementation for the ClassName variable. 6. Publish the workflow. 7. Create a job based on this workflow.
NOTES
For your reference, Autonomy provides a sample email class (MailNotificationTask.java) that is located at iw-home/local/config/lib/ content_center/customer_samples_src/src/com/corp/custom folder. You have the option of customizing the instantiation screen to capture various information such as email IDs, content of the mail, and so on using the task variables. For more information on customizing the instantiation screen, see Chapter 8, Customizing the Instantiation Screen. Incorporate the relevant code in your custom class to process this information. You can use the logging information in the servletd_out.log file for troubleshooting. To achieve this, see the log4j documentation to set your debugging level for your classes in the log4j.xml file that is located at iw-home/local/config/lib/content_center/ customer_src/etc/conf/customer folder.
104
Email Template
You may want to transform your data into the necessary format before transmitting them as an email. For example, you may want to customize your email messages with rich formatting (layout control, fonts, colors, graphics), instead of using plain text messages. As this formatting is applied uniformly across all your email messages, using a template to apply this formatting simplifies your task considerably. This section explains the points to consider before creating an email template. To create your own templates, use one of the two approaches: Create new templates, or Create templates by modifying copies of example templates However, the best approach depends upon the amount of customization for example templates. If you want to make small changes, such as replacing the logo or changing the wording, then it will be easier to just modify copies of the example templates. However, if you are considering a radically different layout, it may be easier to start fresh and just refer to the examples as a guide. If you want to create a template by modifying an example template, we recommend that you copy the template and give it a new name. The example templates are stored at /iwadmin/main/config/STAGING/workflow/email. Here are some recommendations to consider if you are going to create a new template: Try to establish the desired layout and visual design before writing any code. Design a rough layout and identify the key information for typical recipients of the message. Try not to overwhelm the reader with too much detail. Create static HTML pages with typical results using an HTML or text editor. Create alternative proposals and have them reviewed by representative users. Try to display the results in all of the browsers, in all of the email client programs, and on all of the platforms that will be used because the appearance may vary. After creating a static example of the desired output, turn it into a template by replacing static data with the appropriate templating tags. Try to avoid browser-specific features unless your organization has control over the client software. If you include URLs within your message (for example, an image, style sheet, or page reference), consider that the recipient may not be connected to the internet, or may not have access to your intranet, when the message is read. Therefore, the referenced resources may not be accessible. If you create a plain text template, remember that white space is significant. The use of indentation (spaces or tab characters) or blank lines that makes an HTML template much easier to read can produce undesired gaps in plain text.
105
In general, for plain text, consider keeping line lengths to 75 characters or less and assume that any tab character is roughly equivalent to 8 character spaces. However, keep in mind that the text inserted by a tag may be much longer or shorter than the tag itself, so it may be difficult to predict the final line length. Because the development, debugging, and testing of your template will probably require many iterations before you reach the final result, you will want to run the template from a command line, separate from any workflow job. Create an example of an XML input file and then invoke iwpt_compile.ipl directly from the command line.
Example 1
This example provides pointers on adding headers to an email.
NOTE
The comments within the code snippets describe what the following code is intended for. The comments are represented between <!-- --> or /* */ or // symbols and are italicized for ease-of-recognition.
Sample XSL Template 1 The email header has information that travels with every email, containing details about the sender, route, and receiver. Typically, the email headers consist of name-value pairs, such as: To with the recipient's name and email address Date consisting of sent date/time of the email The following example shows setting of name-value pairs with static and dynamic values:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0"> 106
<xsl:output method="html" indent="yes"/> <xsl:param name="webHost" select="//WebHost"/> <xsl:template match="/"> <!-- Header tag containing a name-value pair, where the value is static. --> <header1> <name>ReplyTo</name> <value>abc@interwoven.com</value> </header1> <!-- To dynamically set the value: --> <header2> <name>Subject</name> <xsl:value-of select="//Job/CurrentTask/@Description"/> </header2> <!-- You can add any number of header tags containing name-value pairs. Write suitable java code to handle these tags. --> </xsl:template> </xsl:stylesheet>
Sample Java Class 1 The following code snippet dynamically adds header information to an email; the header information comes from the customized template (see Sample XSL Template 1 on page 106).
/* *Invoke the following code snippet from another java class. * */ import com.interwoven.sharedutils100.mail.MailerConfig; import java.util.Scanner; import org.w3c.dom.Document; import org.w3c.dom.Element; import javax.xml.parsers.DocumentBuilderFactory; import org.w3c.dom.NodeList; import java.io.StringBufferInputStream; import org.w3c.dom.Node; import javax.xml.parsers.DocumentBuilder; public class headerProperties { /* * MailerConfig is an Interwoven provided mail configuration class, which provides you with a host of options to configure your emails as per your requirements. It also supports transforming the data within XSL to email content. * CSExternalTask represents an external task in Teamsite Workflow. 107
*/ public MailerConfig simpleHeaderPropertySetter (CSExternalTask currentTask,MailerConfig mailConfig ) { try { String template = currentTask.getVariable("Specify _the_variable_containing_XSL template path"); CSVPath path = new CSVPath(template); CSSimpleFile cssfile = (CSSimpleFile)(client.getFile(path)); byte[] b = cssfile1.read(0,-1); String str = new String(b); //Using buffered inputstream prevents data loss. StringBufferInputStream sbs=new StringBufferInputStream(str); //Parsing the content. DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newDocumentBuilder(); Document document = db.parse(sbs); Element root = document.getDocumentElement(); // Use a loop here to traverse the xsl elements, if the xsl template contains more than one name-value pairs Element header = (Element)(root.getElementsByTagName("xsl:template").item(0)); NodeList headerElmntLst1 = header.getElementsByTagName("name"); Element headerNmElmnt = (Element) headerElmntLst1.item(0); NodeList headerNm = headerNmElmnt.getChildNodes(); String name= ((Node) headerNm.item(0)).getNodeValue(); NodeList headerElmntLst2 = header.getElementsByTagName("value"); Element headerValElmnt = (Element) fstNmElmntLst2.item(0); NodeList headerVal = headerValElmnt.getChildNodes(); String value=((Node) headerVal.item(0)).getNodeValue(); System.out.println("Title : " + value); //Adds header to the email. mailConfig.addHeaderProperty(name,value); } //Handling the corresponding error catch(Exception e){ System.out.println("ERROR"+e); } return mailConfig; } }
108
Example 2
In this example, data is dynamically retrieved from TeamSite and is then presented in an HTML page. The template defines the layout of the HTML page. Sample XSL Template 2 The following code snippet shows: Retrieving data from the TeamSite server, dynamically Defining the layout of an HTML page
<!-Dynamically retreive DCR data from the TeamSite server. --> <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="html"/> <xsl:template match="item[@name='Pricing']/value"> <tr> <td><b>Season:</b> </td> <td> <xsl:value-of select="item[@name='Season']/value/text()"/> </td> </tr> <tr> <td> <table border='0' colspan='0'> <xsl:apply-templates/> </table> </td> </tr> </xsl:template> <xsl:template match="item[@name='Pricing']/value/item[@name='Time Periods']/ value"> <tr> <td>Per <xsl:value-of select="item[@name='Time Period']/value/text()"/></ td> <td><xsl:value-of select="item[@name='Price']/value/text()"/></td> </tr> </xsl:template> <xsl:template match="item[@name='Included']/value[position()=1]">
109
<xsl:value-of select="text()"/> </xsl:template> <xsl:template match="item[@name='Included']/value[position()>1]"> <xsl:text> </xsl:text> <xsl:value-of select="text()"/> </xsl:template> </xsl:stylesheet>
Sample Java Class 2 The following code snippet presents dynamically retrieved TeamSite assets on HTML pages, whose layout is defined by the template (see Sample XSL Template 2 on page 109).
/* Invoke the following code snippet from another java class. */ String strTemplate = StringUtils.trim(currentTask.getVariable("Specify _the_variable_containing_XSL template path")); CSVPath templateVpath = new CSVPath(strTemplate); CSSimpleFile templateFile = (CSSimpleFile)(client.getFile(templateVpath)); ByteArrayInputStream inputStream = null; ByteArrayOutputStream outputStream = null; try { inputStream = new ByteArrayInputStream(contentXml.getBytes("UTF-8")); outputStream = new ByteArrayOutputStream(); //Generates HTML page. XSLTransformer.transform(inputStream, templateFile, outputStream); } //Handling the corresponding error. catch(Exception e){ System.out.println("ERROR"+e); } //Adds content to the email. mailConfig.addDataSource(new javax.mail.util.ByteArrayDataSource(outputStream.toByteArray(), "text/html")); return mailConfig;
110
Command
Defines the command to be run in conjunction with a task. For example, it may run an anti-virus software to check attachments to an email message in an Email task. You need to specify the full path of the command or program to be run, optionally followed by any initial arguments. You can use variables (for example, $IW_HOME) within the path specification. Specifies whether a failure to execute a task results in a subsequent attempt. You can control the frequency of subsequent attempts using the external_task_retry_wait parameter available in the TeamSite server configuration file, iw.cfg. The iw.cfg file is located in iw-home/etc. Set external_task_retry_wait to the number of minutes you want the workflow engine to wait before it re-attempts to run an external task after failing. Defaults to 1 minute. The value can be True or False.
Retry
Alternatively, you can set the values for all these attributes using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
111
Shared by
Specifies a set of users or set of groups who share this group task. Clicking the Shared by text field displays a dialog box where you can add TeamSite users and groups. You can enter the User and Group values directly. Figure 46 Shared By Dialog Box
Retain Owner Specifies whether the owner of a Group task retains the ownership of the task upon subsequent activations (for example, during a looping process). The value can be True or False (this is the default). Alternatively, you can set the values for all these attributes using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
112
MD Capture UI
By default, it calls iwmetadata.cgi (the metadata capture CGI program) to display the metadata capture GUI where end-users can associate metadata with the files associated with the task. Click the MD Capture UI field to display a dialog box where you can specify the CGI program. For more information on using metadata to describe data in files, and organizing and managing the files, see the TeamSite Administration Guide. Specifies whether a metadata capture script can run immediately when the Metadata task is activated in the situations listed in the description of the Metadata task element. The value can be True or False (default value).
Immediate
Alternatively, you can set the values for all these attributes using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
113
The ability for the child job to cause a transition to occur in the parent task upon the child jobs completion. The lifetime of a nested job is dependent upon its parent tasks workflow lifetimeit should not be removed from the Content Store until its parent task is deleted. Workflow tasks can be specified with a path to a job specification file. Upon activation of the workflow task, TeamSite compiles and instantiates a new job using the specification file. In addition to the common attributes (described on page 79), you can assign the following task-specific attribute for Nested Workflow tasks: Table 18 Nested Workflow Task Attributes
Property Description
Workflow
Specifies a workflow that can be a job specification file, a workflow model (.ipm), or a workflow template file (.wft). You can enter the value directly or set it using one of the following variables: CONFIGURABLE. See Configurable Variables ($IW_CV) on page 66. DATASOURCE. See Datasource Variables ($IW_DS) on page 68. SCRIPT. See Script Variables ($IW_SCRIPT) on page 70.
Available Groups
Specifies a list of groups available for review. You can identify group(s) of reviewers from this list in the Reviewers dialog box and during workflow configuration and instantiation in TeamSite. Specifies a list of users available for review. You can identify reviewers from this list in the Reviewers dialog box and during workflow configuration and instantiation in TeamSite.
Available Users
114
Reviewers
Specifies the reviewers. This attribute is required. The value specified for this attribute is saved in the WorkflowModelName_config.xml file, and is referenced in the workflow model using the $IW_Reviewer variable. In the Reviewers dialog box, you can select users and/or groups from the lists of available users and available groups. Figure 47 Reviewers Dialog Box
You can use the Minimum Number of Reviewers field to specify the minimum number of reviewers required to complete the Review task. Note that a group is considered as one reviewer. Any user of the group can take the review ownership. For the Minimum Number of Reviewers field, if you specify a value higher than the selected number of reviewers, you will not be able to instantiate a job in TeamSite. This is not validated at the client-side, that is, Workflow Modeler does not validate it. However, during a job instantiation in TeamSite, you are prompted to select at least the specified number of reviewers. You can modify the selected list of reviewers and the minimum number of reviewers for different branches or folders during the workflow configuration. However, you cannot modify the lists of available users and available groups. If you need a different set of users and groups, add new users and groups in the workflow model using Workflow Modeler.
115
Specifies whether the workflow will return to the author as soon as a single reviewer rejects, bypassing all remaining reviewers. This field cannot be changed if the Review Type attribute is set to Concurrent. The value can be True or False (the default value). The type of review. It can use one of the default types: Serial. After one approver approves the content it is passed to the next reviewer. It is returned to the author if it is rejected. Concurrent. Multiple reviewers have the opportunity to approve or reject the content simultaneously. Specifies whether emails should be sent to the reviewers. Note that an email is sent only if the reviewer is a user. If you specify a group as the reviewer, the email is not sent. The value for this attribute can be True or False (the default value).
Review Type
Notify Reviewer
Alternatively, you can set the values for all these attributes (except Reviewers) using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
Submit comments for the associated files. Displays a dialog box where you can enter a comment. Submit information for the associated files. Displays a dialog box where you can enter a comment. Specifies whether conflicting versions of files in the staging area can be overwritten. The value can be True or False (the default value).
116
Save Comments
Specifies whether to allow comments that were directly associated with the files during the course of the workflow to remain associated with those files after the files have been submitted. The value can be True or False (the default value). Specifies that files with conflicts cannot be submitted. The value can be True or False (the default value). Specifies that locked files cannot be submitted. The value can be True or False (the default value). Specifies that files be unlocked after the submit operation. The value can be True or False (the default value).
Alternatively, you can set the values for all these attributes using one of the following variables:
CONFIGURABLE. DATASOURCE. SCRIPT.
Specifies the source area from where the files are copied. This value is required. The value can be entered directly. Specifies whether deleted files are propagated to the destination area. The value can be True (this is the default value) or False. Specifies whether to overwrite conflicting versions of files in the destination area. The value can be True or False (this is the default value).
Delete
Overwrite Mode
Alternatively, you can set the values for all these attributes using one of the following variables:
CONFIGURABLE.
DATASOURCE. SCRIPT.
URI
Uniform Resource Identifier to be invoked by an external command. A dialog box appears where you can enter the URL or have it set by one of the following variables: CONFIGURABLESee Configurable Variables ($IW_CV) on page 66. DATASOURCESee Datasource Variables ($IW_DS) on page 68. SCRIPTSee Script Variables ($IW_SCRIPT) on page 70.
118
Name
The Name property uses the form: FlowNumber where Number represents the total number of elements in the workflow model after the link is added. For example, if you add a Default link to a workflow model that contains only a Start node and a User task, the link is the third element added to the workflow model and is assigned the name Flow3. You can click the assigned name in the Property pane and type a new name. The Tree pane reflects the change.
Type
The Type property is one of the following link types: Default Reset Inactivate Timeout For more information on these link types, see Links Toolbar on page 39. Success Failure Conditional
ID
The ID property is a unique, read-only, system-generated identifier for the link. It is always the same as the links Name property. For example, if you add a Timeout link between User Task2 and User Task3, and the link is the eleventh element added to a workflow model, it is assigned the Name and ID Flow11 in the Properties pane. The same link appears as Flow11(UserTask2->UserTask3) in the Tree pane, and is represented by a purple line labeled Timeout in the Project pane (the Project pane displays any link type in red when it is selected).
119
Timeout Links
Timeout links specify a time limit for the completion of a task. When the user-defined time period has passed, the task becomes inactive and the tasks connected by the link are made active.
NOTE
To create a Timeout Duration attribute for a Timeout link: 1. Click a Timeout link in the Tree view or Project pane. 2. In the Properties pane, click the text field next to the Timeout Duration property. The Timeout Duration dialog box appears.
120
3. Optionally, you can select one of the following variables to represent the timeout duration from the unlabeled drop-down list:
CONFIGURABLE. DATASOURCE. SCRIPT.
4. Select one of the following Timeout type options: Absolute. The task becomes inactive and the workflow is transitioned to the next task on a specific date and time. Relative. The task becomes inactive and the workflow is transitioned to the next task after a specified amount of time has passed since the current task became active, for example, 48 hours after a task was assigned to a user.
121
5. Do one of the following: To construct an Absolute timeout, select a month, year, day of the month, hour of the day, and minute of hour from the corresponding GUI elements. The Absolute timeout duration uses a 24-hour clock, so if the Hours field is set to 16, and the Minutes field is set to 20, the task transitions at 16:20 or 4:20 PM. To construct a Relative timeout, set the number of hours and minutes in the Hours and Minutes fields. 6. Click OK.
Conditional Links
Conditional links define the workflow path on which to continue only if a condition evaluates to True. You can link two tasks with any number of conditional links, but you should also link them by a Default link, so that if all conditional links evaluate to False, the workflow can continue using the Default link. To create an Expression attribute for a Conditional link: 1. Click a Conditional link in the Tree view or Project pane. 2. In the Properties pane, click the text field next to the Expression property (the default value reads False). A drop-down list displays the following options:
False.
The workflow continues over this link if the condition of the current task evaluates to False. See Configurable Variables ($IW_CV) on page 66.
The workflow continues over this link if the condition of the current task evaluates to True.
All tasks linked to this node must be completed to activate a successor task.
OR.
One of the tasks linked to this node must be completed to activate a successor task. None of the tasks linked to this node must be completed to activate a successor task.
NOT.
When a task is completed, it signals the successor task that evaluates the logic defined by the logical node to determine if it should be activated. For example, if you want UserTask3 to be activated only if UserTask1 and UserTask2 have been completed, create links from UserTask1 and UserTask2 to an AND node, then create a link from the AND node to UserTask3: Figure 49 AND Node
GatewayType
The GatewayType property is one of the following three node types:
AND OR NOT
123
Name
The Name property uses the form: GatewayNumber where Number represents the total number of elements in the workflow model after the node is added. For example, if you add an AND node to a workflow model that contains only a Start node and a User task, the node is the third element added to the workflow model and is assigned the name Gateway3. You can click the assigned name in the Property pane and type a new name. The Tree pane and Project pane reflect the change.
X
X axis coordinate in the Project pane of the selected node. Click the current value to edit it, or click and drag the corresponding node in the Project pane to change this value.
Y
Y axis coordinate in the Project pane of the selected node. Click the current value to edit it, or drag the corresponding node in the Project pane to change this value.
ID
The ID property is a unique, read-only, system-generated identifier for the link. It is always the same as the links Name property. For example, if you add an OR node to a workflow model, and the node is the eleventh element added to a workflow model, it is assigned the Name and ID Gateway11 in the Properties pane. The same link appears as Gateway11(Gateway11) in the Tree pane, and is represented by the OR node icon in the Project pane (the Project pane displays the node outlined in red when it is selected).
124
Chapter 5
These workflow models are available for your use and also illustrate the tasks and transitions included in the workflow models. They have features and supporting files that make them easier to use. It is recommended that you use or revise these workflow models when possible. The configurable steps for these workflows are marked as optional.
NOTE
To ensure that your existing sample workflows are not overwritten, the latest sample workflows (which include some changes) are deployed at: iw-home\install\AdminStore\ workflowModeler\Models. If required, you can get the latest sample workflows from this location.
The sample workflows are: Archival Workflow Author Submit with Deploy Author Submit with Email Author Submit with Metadata Configurable Author Assignment Configurable Author Submit Configurable Default Submit Publish LiveSite Content Workflow
125
Archival Workflow
Figure 50 illustrates the archival workflow. Figure 50 Diagram of the Archival Workflow
2. Email notification of the success or failure to archive the Edition to DigitalSafe is sent to users of your choice.
End
126
Review Work
Author Work
reject
approve
Submit iw_areaowner
3. Author clicks Review Work to submit modified files. 4. Author-submitted content is sent to an approver. The approver is defined as the owner of the workarea from which the files are submitted. 5. The approver either: Approves the work. Rejects the work (which is sent back, as a task, to the author who modifies the work, and resubmits it for approval by clicking Review Again on that task). 6. When approved, the files are submitted to the staging area. 7. The files are then deployed to the specified location. Note: The deploy script need to be configured before using this workflow model.
127
Author Finish
Author Work
Email to Approver
reject
Submit iw_areaowner
End
128
Metadata
Author Work
1. When a new job is instantiated, the author is prompted for the following information: Submit comment (required) Information comment (optional) Individual file comments (optional) 2. Author clicks Metadata to capture metadata. 3. Author-submitted content is then processed for metadata capture (by either the TeamSite Tagger GUI or through MetaTagger integration). 4. Author-submitted content is sent to an approver. The approver is defined as the owner of the workarea from which the files are submitted. 5. The approver either: Approves the work. Rejects the work (which is sent back, as a task, to the author who modifies the work, and resubmits it for metadata capture and approval by clicking Author Rework on that task). 6. When approved, the files are submitted to the staging area.
129
reject
Submit iw_areaowner
End
New Job
1. A new job is initiated; the initiator may have already selected files to be worked on by the author (prior to initiating the job) or may attach them to the job. 2. (Optional) Email notification of the assigned work and any associated files is sent to the author. 3. Author completes assigned work and marks the task as Done.
Author Work
4. (Optional) Content is processed for metadata capture (by either the TeamSite Tagger GUI or through MetaTagger integration). 5. Work is submitted to the reviewer for approval or rejection.
reject
Review approve (optional) Submit iw_areaowner failure (optional) Deploy retry End Resolve Deployment Problem iw_areaowner Email Notification of Deployment Problem
6. The reviewer either: Approves the work, in which case the files are submitted to the staging area. Rejects the work, in which case the job is returned to step 2. 7. (Optional) The file is deployed to the specified location (email is sent to the initiator if there is a deployment problem).
cancel job
130
Submit
Author Work
reject
1. Author submits modified files, which initiates a new job and prompts the author for the following information: Submit comment (required) Information comment (optional) Individual file comments (optional) 2. (Optional) The author selects additional files to be submitted. 3. (Optional) Author-submitted content is then processed for metadata capture (by either the TeamSite Tagger GUI or MetaTagger integration). 4. Work is submitted to the review subflow for approval or rejection.
Review approve Submit iw_areaowner failure (optional) Deploy retry End Resolve Deployment Problem iw_areaowner (optional) Email Notification of Deployment Problem
cancel job
5. The reviewer either: Approves the work and the files are submitted to the staging area. Rejects the work, in which case an optional email requesting revisions is generated and a revision task occurs. 6. (Optional) The file is deployed to the specified location (email is sent to the initiator if there is a deployment problem).
131
Submit
End
cancel job
132
1. User initiates the workflow by clicking Submit in ContentCenter Professional. 2. User chooses the deployment environment: development or production LSCS server. 3. If the user opts for the development environment, the file is: Submitted to STAGING, if the user chooses this option. Deployed to the LSCS development server. 4. If the user opts for the production environment, the file is: Submitted to STAGING. Deployed to the LSCS production server.
Production Submit
End
This workflow is packaged as part of lscs-sample.spar, which is a part of the TeamSite package. For this workflow to be available, you need to install the spar using the install_archive script. For more information on running the script, see the Configuring TeamSite section of the LiveSite Content Services Installation and Administrators Guide.
133
Retrieval Workflow
Figure 58 illustrates the retrieval workflow. Figure 58 Diagram of the Retrieval Workflow
Start
1. Start retrieval of the archived edition from DigitalSafe. 2. Depending on your choice, the Edition is either retrieved onto a new Workarea or an existing Workarea is overwritten. 3.Email notification of the success or failure to retrieve the Edition is sent to users of your choice.
End
Each of the configurable workflows has a number of configurable options. CONFIGURABLE and DATASOURCE variables are used to hold values for configurable options. These configurable variables are specified in an external configuration file called WorkflowName_config.xml. For example, the configurable_author_submit.ipm file has a corresponding configuration file
134
called configurable_author_submit_config.xml. This configuration file is described in Workflow-Specific Configuration Files on page 135.
configurable_author_submit_config.xml
Add Files Deployment Email Notification Metadata Capture Review
configurable_default_submit_config.xml
Deployment Email Notification Metadata Capture
configurable_author_assignment_config.xml
Add Files Deployment
135
Using or adapting these solutions eliminates the need to build separate VisualAnnotate workflows. Global variables are used for VisualAnnotate. For more information about VisualAnnotate and its configuration, see TeamSite Workflow Developers Guide.
NOTE
As VisualAnnotate is not supported on non-English servers, remove the VisualAnnotate functionality from these workflows before using them on a non-English server.
136
Chapter 6
137
WorkflowUser Role
By default, all TeamSite users should be able to use workflow models. To achieve this, the workflowModels branch of the iwadmin store is shared for iwEveryone with the WorkflowUser role. However, the users with this role have bare minimum permissions, just enough to execute and view workflows. Users do not have permissions to design and publish a workflow.
NOTES
The iwEveryone group is automatically added to the workflowModels branch with the WorkflowUser role. You do not have to add it manually. Permissions of the WorkflowUser role have been reduced in TeamSite 6.7.1 SP1 onwards. In TeamSite 6.7.1, the iwEveryone group had the Modify access to the iw-wa workarea. However, from TeamSite 6.7.1 SP1 onwards, the iwEveryone group has the Readonly access.
WorkflowAdmin Role
All TeamSite users are not allowed to publish, subscribe, and configure workflow models. Only a certain group of users are allowed to perform these operations. The WorkflowAdmin role is for those users. Normally, these users include workflow developers or TeamSite administrators. The WorkflowAdmin role has privileges to publish and save workflow models to TeamSite. In addition, it has privileges to manage, configure, and debug the workflow models. You should manually add users to the workflowModels branch with the WorkflowAdmin role. You should not assign this role to the iwEveryone group, unless required.
NOTE
Users who belong to the WorkflowAdmin role should also have the Modify access in the iwadmin/main/workflowModels/WORKAREA/iw-wa workarea. You need to add this manually. In addition, you need to manually assign full permissions for each folder (and its files) of the iw-wa workarea: Config, Instance, Internal, and Models.
Users with the WorkflowAdmin role can perform the following operations in TeamSite: Configure workflow model Copy files and folders Create file Create folder
138
Delete files and folders Download Edit Import Lock file Manage workflow model Modify file extended attributes Move files and folders Preview file Publish workflow model Submit Transition task Unlock file Update workarea View file history Web view workflow model The operations specific to workflow models have been included under the Workflow category. The key operations are as follows: Manage Workflow Model. Users can add or remove workflows allowed for a branch or Vpath. They can specify the users who can instantiate these workflows. They have access to the Manage Workflows link in the Properties link present in the Content tab. Publish Workflow Model. Users can use Workflow Modeler to publish workflows to TeamSite. Configure Workflow Model. Users can configure or customize the workflows for different branches. They can provide default values or make certain fields hidden or visible during instantiation. Webview Workflow Model. Users can view the workflow in a browser. They can check the values of the properties for each task and track the workflow after instantiation.
139
Publish Workflow
Manage Workflow
Configure Workflow
Execute/Run Workflow
Yes No
Yes No
Yes No
Yes Yes
Yes Yes
(shown in )
140
141
Contains subfolders of the format modelName_config (where modelName is the file name of the published workflow model) that contain the configuration file (default_config.xml) associated with a each workflow model. The default_config.xml file includes default values for the workflow instantiation form fields.
Instance. Contains the ModelInstance folder that includes the workflow model XML file created when a workflow model is instantiated to create a new job. The file is named as jobid_modelName.ipm. After the job is finished, the file is deleted.
Config.
NOTE
The file deletion does not happen synchronously. It may take a few seconds, depending on the server load. File deletion depends on the event subsystem. Therefore, if the event subsystem is stopped on the TeamSite instance, files will not get deleted and you have to manually delete the files associated with each workflow job. In these instance models, the configuration information is resolved and saved within the model itself. The instance models are used to produce the in-progress web view of the model that shows the status of a job on the Workflow tab:
142
Contains the following two files (normally). It can contain any other files too.
available_models.xml. Determines which workflow models are available and their subscription information. If you are familiar with the previous versions of TeamSite workflow, you will find this file similar to the available_templates.cfg workflow template file. This file is described in detail in Subscribing Workflow Models on page 144. default_config.cfg.
Default Customization screen that appears for all workflows. It enables end-users to customize a workflow for a given branch, folder, or workarea.
NOTE
default_config.cfg includes a specific reference to the DTD filehttp://localhost/ iw-cc/workflowModeler/ProcessModelConfiguration.dtd. If the TeamSite server URL
is changed (for example, if the port number or the machine name is changed), you need to edit this file and specify the correct URL. For any other reason, you should not modify files or subfolders contained within the Internal folder.
Models.
Contains the workflow model files (.ipm) that have been published from Workflow Modeler.
For information on the functionality available on the Workflow tab, click the Help link contained in either screen.
143
Concurrent updates to the available_models.xml file are not supported. For example, while user 1 is editing the available_models.xml file, if user 2 opens, edits, and saves the file, then user 1 will not be able to save the changes.
attribute. Specify whether (true) or not (false) workflow models selection screen will include a branch/workarea chooser if workarea context is not present. Most of the out-of-the-box workflow model examples require this to be enabled (require_workarea="true") to work properly. Default value is true. element. An example code snippet is shown below:
model
<available_models require_workarea="true"> <model debug="true" active="true" filename="Author_Submit" name="Author Submit"> ... ... </model> </available_models>
is not created, instead the XML content is displayed within the job instantiation screen.
144
Indicate whether (true) or not (false) the workflow model is enabled. The default value is true. If active is set to false, the workflow will not be visible to users for instantiation.
filename. Specify the name of the workflow model file without its extension (.ipm). For example, if the file name is Author_Submit.ipm, the attribute value is as follows: filename="Author_Submit" name.
active.
This value is used as the display name for the workflow model. The name specified here must be unique.
Within the model element is the allowed element, where you can configure user access by matching workflow commands with user roles:
<model ...> <allowed> ... </allowed> </model>
145
Command Access
Workflow commands are specified by the command element. The command element specifies the user-activity that starts the corresponding workflow. For example, the following configuration:
<command name="submit"/>
specifies that the associated workflow is started when performing a Submit and that it cannot be invoked by other means. The valid command values that you can associate with a workflow are:
archive_job
(submitting files) (assign button or menu item) (new job) (new job, in TeamSite FrontOffice)
new_job
tfo_workflow tt_data
(saving FormsPublisher data records) (deleting FormsPublisher data records in ContentCenter Standard only)
tt_deletedcr
NOTE
The tt_data command is valid in ContentCenter Standard and can be configured in ContentCenter Professional; see the User Interface Customization Guide. The tt_deletedcr command is only valid when users are using the ContentCenter Standard interface; in ContentCenter Professional, this command is not valid and data records are treated like any other assets.
Role Access
Access based on TeamSite roles is specified by the role elements name attribute. For example, the following configuration:
<role name="author"/>
Group Access
Access based on user groups is specified by the group element:
146
<group name="marketing"/>
User Access
Access based on individual user name is specified by the user element:
<user name="jdoe"/>
Branch-vpath Access
Access based on a TeamSite branch is specified by the branch-vpath element. You can also specify whether the workflow model should be available to the subbranches or not. For example, the following configuration:
<branch-vpath vpath="/default/main" include-subbranches="true"/>
specifies that the workflow model is also available to the subbranches of /default/main, because the include-subbranches attribute is set to true.
Vpath-regex Access
Access based on regular expressions is specified by the vpath-regex element. You can use regular expressions to search for a specified pattern and specify what to do when matching patterns are found. Using regular expressions allows a greater level of flexibility when adding items. For example, if you want only the users in the three administration_1 branches (a1, a2, and a3) to access a workflow model, you can set the following constraint:
<allowed> <or> <branch-vpath vpath="/default/main/administrator_1/a1"/> <branch-vpath vpath="/default/main/administrator_1/a2"/> <branch-vpath vpath="/default/main/administrator_1/a3"/> </or> ... </allowed>
If a new branch called a4 is added to /default/main/administrator_1 you could manually update the available_models.xml file to allow access for users in the new branch by adding the branch element to the existing ones:
<branch-vpath vpath="/default/main/administrator_1/a4"/>
Alternatively, you could modify the available_models.xml file to use the following regular expression and, thus, automate the constraints placed on the a4 branch:
147
This regular expression allows users from any branch under /deault/main/administrator_1 to have access to the workflow model. As the Archival and the Retrieval workflows are meant to archive or retrieve Editions, it is recommended that you specify the Edition path for the vpath-regex element. For example,
<vpath-regex regex="/default/main/<branch_name>/EDITION"/>
Path Separators When using regular expressions, the path-separators (\, \\, /) are all translated to / in both the pattern and the string to match against before attempting the match. In the following example:
<vpath-regex regex="foo"/>
any branch path that includes the string foo will be matched. Here the following examples match:
/default/main/food/... /default/main/barfoo/...
any branch path that begins with the value-string will be matched. Here the following example matches:
/default/main/food/...
The following examples are all treated as identical on both Windows and UNIX.
<vpath-regex <vpath-regex <vpath-regex <vpath-regex regex="^/default/main/foo"/> regex="^\default\main\foo"/> regex="^\\default\\main\\foo"/> regex="^/default\main\\foo"/>
148
the following individuals have access to the Author Submit workflow: Those who are authorized to perform submit commands. Those who have the author or editor role. Those who are members of the marketing group. Those who have the admin role, with the exception of the user jdoe. If no access category is specified, it is assumed that category has full access to the workflow model. The available_models.xml file is validated against the Subscription schema (Available_Models1.0.xsd). For more information on the Subscription schema, see Available_Models1.0.xsd (Subscription schema) on page 243 Workflow Modeler Users Guide.
NOTE
The Subscription schema has been modified. Using ContentCenter Professional, when you access the available_models.xml file for the first time, it is automatically updated to adhere to the revised Subscription schema. However, if you do not access the XML file, the old XML file
149
will still be valid. This is because both old and revised versions of the Subscription schema are supported in this release.
When the available_models.xml file is saved, TeamSite checks each branch with an entry in the file to see if there is a custom configuration file, custom_config.xml, available for that branch. If the branch has a custom configuration file defined for it, the workflow instantiation form is generated from the custom configuration file (as described in Configuring Workflow Models on page 151). If the branch does not have a custom configuration file defined for it, the default configuration file (located in iwadmin/main/workflowModels/WORKAREA/iw-wa/ Config/workflowModelName_config) is used to generate the workflow instantiation form. You can manage a workflow models availability to one or more TeamSite branches using one of the following tabs: Administration tab Content tab
151
The Current Configuration column indicates that one of the following configuration files is being used for each of the branches: Default. Default configuration file. Custom. Configuration file being created after configuring a workflow model. Outdated. A custom configuration files that becomes outdated when the configured workflow model is modified and republished. For more information, see on page 155. 7. Click Actions in the Edit Configuration column, and then select Edit Configuration to change the configuration file used by the corresponding branch. If you want to use a custom configuration file for all branches, click Actions for the All Branches option.
152
8. Edit one or more of the variables to customize the information that is displayed on the workflow instantiation form generated on the specified branch. 9. Click Save. When you save the custom configuration, TeamSite does the following: a. Creates a custom_config.xml file for the specified branch(es). b. Replicates the directory structure of the branch(es) under the
//TS_Server/iwadmin/main/workflowModels/WORKAREA/iw-wa/ Config/<WorkflowModelName>_config folder, and stores the custom_config.xml
file
in that location.
TS_Server/default/main,
For example, if you configure the samplereview workflow model for the branch // the Vpath of the custom_config.xml file is as follows:
//TS_Server/iwadmin/main/workflowModels/WORKAREA/iw-wa/ Config/samplereview_config/default/main
c. Submits the custom_config.xml file to the Staging area. Considering the above example, the Staging area Vpath of the custom_config.xml file will be as follows:
//TS_Server/iwadmin/main/workflowModels/STAGING/ Config/samplereview_config/default/main 153
When you instantiate the workflow model, the workflow instantiation form is generated using the custom information for the workflow model. For example, if you enter Information in the Label field, and Enter information in the Value field in step 7, the form would look like this: Figure 65 Workflow Instantiation Form
NOTE
TinyMCE and VisualFormat are not supported in the workflow instantiation screen.
154
NOTE
The default_config.xml file resides at this level. Considering the previous example, the vpath of the default_config.xml file is //TS_Server/iwadmin/main/workflowModels/STAGING/
Config/samplereview_config.
If you do not have a custom_config.xml file at this level, then system generates a file with the default text, textarea, or radio, depending on the widget defined in the default_config.xml file. The custom_config.xml file is only used for populating the fields of the workflow instantiation form with default values. To change the default presentation of the workflow instantiation form, you need to create a custom_instantiation.cfg file for the required branch, sub-branch, and/ or folder. For more information on creating a custom_instantiation.cfg file, see Chapter 8, Customizing the Instantiation Screen.
155
156
Chapter 7
Instantiating Workflows
If you are familiar with instantiating previous versions of TeamSite workflow templates (.wft), you will find that workflow models (.ipm) are instantiated the same way. Workflow models can be instantiated with the following commands (either from the command line or in the GUI): New Job Submit Assign
tfo_workflow tt_data
(saving FormsPublisher data records) (deleting FormsPublisher data records in ContentCenter Standard only) command-line utilty
tt_deletedcr iwmodelc.bat
NOTES
The tt_data command is valid in ContentCenter Standard and can be configured in ContentCenter Professional; see the User Interface Customization Guide. The tt_deletedcr command is only valid when users are using the ContentCenter Standard interface. In ContentCenter Professional, this command is not valid and data records are treated like any other assets. The iwmodelc.bat command is for Windows users only. UNIX users must use the iwmodelc.sh command.
New Job Submit Assign Each of these options is described in the corresponding section that follows.
158
NOTE
The Select a Workflow list contains template-based workflows (Author Assignment in this example) and workflow models (all others). Workflow models are identified by the icon. 3. Select a workflow model, and click Next. The workflow instantiation form appears: Figure 68 Workflow Instantiation Form
159
NOTES
The workflow instantiation form is generated using a Data Capture Template (DCT). As TeamSite provides a facility to create customized forms using DCTs, you have the flexibility to customize these forms. For information on creating a custom instantiation form, see Chapter 8, Customizing the Instantiation Screen. For detailed information on DCTs, see the FormsPublisher Developers Guide. TinyMCE and VisualFormat are not supported in the workflow instantiation screen. Depending on the forms configuration settings (described in Configuring Workflow Models on page 151) the fields may already contain one or more entries, be read-only, or display different values depending on the branch. 4. Provide the requested information, and click Submit. You can view the new job you instantiated by clicking the Workflow tab: Figure 69 Jobs Listed on the Workflow Tab
160
The Select a Workflow dialog box appears. Figure 71 Select a Workflow Dialog Box
161
NOTE
The Select a Workflow list contains template-based workflows (Author Assignment in this example) and workflow models (all others). Workflow models are identified by the icon.
3. Select a workflow model, and click Next. The workflow instantiation form appears. Figure 72 Workflow Instantiation Form
Depending on the forms configuration settings (described in Configuring Workflow Models on page 151) the fields may already contain one or more entries, be read-only, or display different values depending on the branch. 4. Provide the requested information, and click Submit. You can view the new job you instantiated by clicking the Workflow tab: Figure 73 New job Listed on the Workflow Tab
162
163
NOTE
The Select a Workflow list contains template-based workflows (Author Assignment in this example) and workflow models (all others). Workflow models are identified by the icon.
3. Select a workflow model, and click Next. The workflow instantiation form appears: Figure 76 Workflow Instantiation Form
164
Depending on the forms configuration settings (described in Configuring Workflow Models on page 151) the fields may already contain one or more entries, be read-only, or display different values depending on the branch. 4. Provide the requested information, and click Submit. You can view the new job you instantiated by clicking the Workflow tab: Figure 77 New Job Listed on the Workflow Tab
165
4. Click the Preview link. Web view of the selected workflow model appears (see Figure 81).
NOTE
You can display the web view of a workflow model from the Staging area only. In other words, web view is available for workflow models that are submitted to the Staging area.
166
3. In the Job Details (or Task Details) area, click the Actions link for the selected workflow model, then select View Workflow Instance. Figure 80 Viewing Workflow Instance Jobs Details
167
2 3 4 5 6 7
10 1. Overview Area. Use it to get a bird's-eye-view of the workflow model, as it displays the entire workflow model in a miniature form. It is useful when all parts of the workflow model are not within the visible region of the main diagram area. 2. Select Tool. Use it to select various elements on the web view screen. 3. Zoom Mode. Use it to magnify selected parts of the main diagram area. You need to use the click-and-drag action to select a region. 4. Pan Mode. Use it to pan the main diagram area. When active, the cursor turns into a hand. 5. Show All. Use it to fit the content (workflow model) within the visible region of the main diagram area. 6. Zoom In. Use it to increase the magnification of the content in the main diagram area. 7. Zoom Out. Use it to decrease the magnification of the content in the main diagram area.
168
8. Pan Tool. Use it to pan the main diagram area in various directions. You can use it for viewing all (not-in-view) parts of the main diagram area 9. Property Sheet. Use it to view the properties of the workflow model elements.
NOTE
Properties with empty values are not displayed in Property Sheet. In addition, co-ordination properties (x and y) are not displayed. 10. Legend Area. Use it to identify the status of each element of the workflow model. This area appears after the instantiation of the workflow model.
169
NOTE
The Select a Workflow list contains template-based workflows (Author Assignment in this example) and workflow models (all others). Workflow models are identified by the icon. 3. Select a workflow model, and click Next. The workflow instantiation form appears:
170
Depending on the forms configuration settings (described in Configuring Workflow Models on page 151) the fields may already contain one or more entries, be read-only, or display different values depending on the branch. 4. Provide the requested information, and click Next. A message appears stating that the operation was successful. 5. Click Done. For more information about working with workflows, tasks, and jobs, see the How Do I... and topic-specific online help in ContentCenter Standard.
171
For more information on working with workflow, jobs, and tasks in TeamSite Front Office, see the TeamSite Front Office documentation.
172
NOTE
The iwmodelc.bat command is for Windows users only. UNIX users must use the iwmodelc.sh command.
173
174
Chapter 8
The following FormAPI objects are not supported in the context of workflow: Data Capture Form
IWDatacapture.save ()
175
Event Registry
onClose OnGenerate OnPreview onSaveNameSpecified onSaveDone
DCR Information Name Factory Page Generation Presentation Template For additional information on these and other FormAPI objects, see FormsPublisher: FormAPI Developer's Guide. Workflow Modeler supported by TeamSite 6.7.1 onwards, supports the datacapture.6.0.DTD only. For more information on the DCT syntax, see the TeamSite FormsPublisher Developer's Guide. TinyMCE and VisualFormat are not supported in the workflow instantiation screen. In the custom instantiation screen, inline commands are not supported for the Reviewers property in a Review task. For example, within a Reviewers property of the Review task, you cannot call an inline command which executes a Perl script. In such scenarios, use Datasources.
176
NOTE
A custom instantiation screen can contain only those fields that are exposed as Configurable or Datasource variables in the workflow. An exception to this is a Review task. Every Review task has a Reviewers variable associated with it; its value can be changed in the instantiation screen.
2. Publish this workflow model. The default_config.xml file is created. This file contains the following code snippet:
177
The out.txt file that is generated contains the configuration information for the SampleReview workflow model.
NOTE
See the default_config.xml file of the workflow model to know the contents for the custom DCT. 2. Rename the generated out.txt file with custom_instantiation.cfg. The code snippet for the custom_instantiation.cfg file is as follows:
<data-capture-requirements dtd-system-identifier="http://localhost/iwcc/datacapture6.0.dtd" dcr-validation="reject-invalid" xmlns="http://www.interwoven.com/schema/datacapturedtd"> <ruleset name="Config"> <script> var reviewersIdList = null; . . . function init() {} function setReadonlyDatasourceItems(){...} function setHiddenDatasourceItems() {...} function loadReviewersValues(reviewerItem) {...} function setReadonlyReviewerItems() {...} function enforceMinNoOfReviewers() {...} function getOptionValues(option, parentItem, newOptions) {...}
178
var startingItem = IWDatacapture.getItem("/Config/iw-StartingItem"); . . . </script> <root-container location="Config" name="Config"> <container location="iw-StartingItem" name="iw-StartingItem"> <label/> <item pathid="iw-hiddenbugworkaround" name="iw-hiddenbugworkaround"> <hidden/> </item> </container> </root-container> </ruleset> </data-capture-requirements>
3. Edit the custom_instantiation.cfg file to meet your requirements. See the following sections for more information: a. Changing Default Property Appearance on page 180 b. Adding Client-Side Validation on page 185 c. Adding New Fields on page 185 d. Adding Dynamic Behavior on page 188
179
The default value assigned to a property while designing a workflow model is stored within the value tags of the default_config.xml file. This value is not stored in the custom_instantiation.cfg file. You should not remove or modify the contents of the default_config.xml file.
The following is an example of how to change the Label of a property. 1. Start the Workflow Modeler, and log on. 2. Select File > Open. 3. Double-click the SampleReview workflow model that you created. 4. Select User_Task. 5. For the Description property, set the Variable Type field to CONFIGURABLE. 6. In the Label field, type Member as shown in Figure 87 and click OK.
180
The old version of the default_config.xml file gets overwritten. 8. Create the custom_instantiation.cfg file. For more information on how to create this file, see Customizing the Default Instantiation Screen on page 178. Place this file in the appropriate location, and then submit it to the staging area.
NOTE
Each property has a unique ID that differentiates it from other properties. Usually, the ID starts with the characters ID followed by numbers (0 to 9). When you customize the instantiation screen, ensure that the IDs of the various properties match in the default_config.xml and custom_instantiation.cfg files. For each property, its id in the default_config.xml file should be the same as the pathid in the custom_instantiation.cfg file. In the following code snippet, note the id for the Description property, which is present in the default_config.xml file:
<ProcessModelConfiguration xmlns="http://www.interwoven.com/schema/ modelConfig"> <Config id="ID1211817909655"> <Label>Member</Label> 181
<Description/> <Value/> <Hidden>false</Hidden> <Readonly>false</Readonly> <Property name="NodeId">UserTask2</Property> <Property name="Mandatory">false</Property> <Property name="PropertyName">Description</Property> <Property name="NodeType">UserTask</Property> <Property name="IsGlobal">false</Property> <Property name="UIWidget">textarea</Property> </Config> </ProcessModelConfiguration>
In the following code snippet, note the pathid for the Description property, which is present in the custom_instantiation.cfg file:
<item pathid="ID1211817909655" name="ID1211817909655"> <label>Member</label> <description/> <textarea required="f"/> </item>
NOTE
In the above example, for the Description property, the id in the default_config.xml file and the pathid in the custom_instantiation.cfg file are identical. 9. Create a new job based on this workflow. Figure 88 illustrates how the label appears in the instantiation screen. Figure 88 Configurable Variable - Label (Member)
182
10. Perform the following steps to change the value of the Label field by editing the custom_instantiation.cfg file manually. After you make these changes, the Label field displays Employee instead of Member. a. Open the custom_instantiation.cfg file in a text or XML editor. b. In the custom_instantiation.cfg file, replace the label Member with Employee within the label tags of this Configurable variable, as shown below:
<item pathid="ID1211817909655" name="ID1211817909655"> <label>Employee</label> <description/> <textarea required="f"/> </item>
c. Save the custom_instantiation.cfg file and submit it to the staging area. d. Create a job based on this workflow. Figure 89 illustrates the modified instantiation screen. Figure 89 Configurable Variable - Label (Employee)
The following is an example of how to change the widget type of a property. The appearance of a variable in the instantiation screen is determined by the type of widget that is present in the default_config.xml file or the custom_instantiation.cfg file. In the SampleReview workflow model that you created, the Configurable variable (Employee) is displayed as a textarea, as shown in Figure 90. This appearance is because of the following code that is present in the custom_instantiation.cfg file:
<textarea required="f"/>
If the custom_instantiation.cfg file is not present, then, the appearance of the variable is determined by the following code that is present in the default_config.xml file:
Property name="UIWidget">textarea</Property>
You can change this default setting by modifying the widget in the custom_instantiation.cfg file.
NOTES
You should not remove or modify the contents of the default_config.xml file.
To change the Configurable variable (Employee) to use the text widget instead of the textarea widget: 1. Open the custom_instantiation.cfg file in a text or XML editor. This file has the following code snippet, which specifies that the widget that is used for the Configurable variable (Employee) is textarea.
<item pathid="ID1211817909655" name="ID1211817909655"> <label>Employee</label> <description/> <textarea required="f"/> </item>
Figure 90 illustrates the appearance of the Configurable variable in the instantiation screen when the widget type is textarea. 2. In the custom_instantiation.cfg file, change textarea to text, as shown below:
<item pathid="ID1211817909655" name="ID1211817909655"> <label>Employee</label> <description/> <text required="f"/> </item>
3. Save the custom_instantiation.cfg file and submit it to the staging area. 4. Create a new job based on this workflow. Figure 91 illustrates the modified instantiation screen.
184
Ensure that the values that are captured in these new fields are assigned to the variable that was created during design using the Workflow Modeler. In the SampleReview workflow model, concatenate the values of Last_Name and First_Name and assign this concatenated value to the
185
Configurable variable, Employee, which was created using the Workflow Modeler. See step 8 on page 187 for more details.
To create two new fields in the instantiation screen: 1. Open the custom_instantiation.cfg file in a text or XML editor. 2. Add two new fields in this file (Last Name and First Name) as shown below:
<item pathid="IDLast_Name" name="Last_Name"> <label>Last Name</label> <description/> <text required="t"/> </item>
NOTES
Provide unique IDs to each of these new fields. Start the ID with an alphabetic character. 3. Save the custom_instantiation.cfg file and submit it to the staging area. 4. Create a new job based on this workflow. Figure 92 illustrates the modified instantiation screen. Figure 92 Modified Instantiation Screen with Additional Fields
5. If the Employee field needs to be hidden in the instantiation screen, add the <hidden/> tag in the custom_instantiation.cfg file as shown below:
<item pathid="ID1211817909655" name="ID1211817909655"> <label>Employee</label> <description/> <hidden/>
186
6. Save the custom_instantiation.cfg file and submit it to the staging area. 7. Create a new job based on this workflow. Figure 93 illustrates the instantiation screen in which the Employee field is not visible because of the modification you made in the custom_instantiation.cfg file. Figure 93 Modified Instantiation Screen (Employee Field is Hidden)
8. Incorporate the JavaScript code shown below, which concatenates the values of Last_Name and First_Name and assigns it to the Employee field. This JavaScript must be incorporated in your custom_instantiation.cfg file in such a way that it is executed. In the SampleReview workflow example, you can include this script in the function enforceMinNoOfReviewers() so that it is executed when the user clicks Save or Submit.
function enforceMinNoOfReviewers() { var finalname = IWDatacapture.getItem("/Config/ID1211817909655"); var firstname = IWDatacapture.getItem("/Config/IDFirst_Name"); var lastname = IWDatacapture.getItem("/Config/IDLast_Name"); var firstnameString=firstname.getValue(); var lastnameString=lastname.getValue(); var finalNameString=lastnameString+firstnameString; finalname.setValue(finalNameString); . . . }
9. Save the custom_instantiation.cfg file and submit it to the staging area. 10. Create a job based on this workflow.
187
If you do not require the default functionality provided by the JavaScript that is present in the custom_instantiation.cfg file, you can remove it. You can also add your own JavaScript code to this file. If you create the custom_instantiation.cfg file manually, the default JavaScript is not included automatically. You have to write your own JavaScript code. If you create your own JavaScript code, ensure that the IDs are appropriately mapped in the custom_instantiation.cfg and default_config.xml files. For additional information, see the section step 8 on page 181.
188
These variables allow you to add client-side validations and functionality to the widgets, which are used to display the Datasource variables and Reviewers properties in the instantiation screen. All of these variables have a global scope within the <script> tag as shown below.
<script> var reviewersIdList = null; var reviewersIdReadonlyList = null; var datasourceIdReadonlyList = null; var datasourceIdHiddenList = null; . . . </script> reviewersIdList
This variable holds the IDs of all the Reviewers properties associated with the Review tasks in a workflow. For example:
var reviewersIdList = "ID1211877859386, ID1194860561111";
In this code snippet, there are two Reviewers properties (that is, two Review tasks) in the workflow; the IDs of these properties are assigned to the variable reviewersIdList. Each of these IDs is separated by a comma.
reviewersIdReadonlyList
This variable holds the IDs of all the Reviewers properties set as Readonly.
189
For example:
var reviewersIdReadonlyList = "ID1194860561111";
In this code snippet, there is only one Reviewers property that is set as Readonly in the workflow.
NOTE
If there are multiple Reviewers properties in the workflow that are set as Readonly, each of these IDs is separated by a comma when it is assigned to this variable.
datasourceIdReadonlyList
This variable holds the IDs of all the Datasource variables set as Readonly. For example:
var datasourceIdReadonlyList = "ID1211870771865";
In this code snippet, there is only one Datasource variable that is set as Readonly in the workflow.
NOTE
If there are multiple Datasource variables in the workflow that are set as Readonly, each of these IDs is separated by a comma when it is assigned to this variable.
datasourceIdHiddenList
This variable holds the IDs of all the Datasource variables set as Hidden. For example:
var datasourceIdHiddenList = "ID1194857923092";
In this code snippet, there is only one Datasource variable that is set as Hidden in the workflow.
NOTE
If there are multiple Datasource variables in the workflow that are set as Hidden, each of these IDs is separated by a comma when it is assigned to this variable.
Function Declaration
The next section of the JavaScript in the custom_instantiation.cfg file contains the following functions:
init() setReadonlyDatasourceItems() setHiddenDatasourceItems()
190
This function is invoked when the instantiation screen or DCT is loaded. It invokes other JavaScript functions to introduce dynamic behavior in the instantiation screen. The various functions that are invoked by the init() function is as indicated below:
function init() { setReadonlyDatasourceItems(); setHiddenDatasourceItems(); var reviewerItem = null; reviewerItem = IWDatacapture.getItem("/Config/ ID1211877859386");loadReviewersValues(reviewerItem); setReadonlyReviewerItems(); } setReadonlyDatasourceItems()
This function prevents the user from editing the values of all the datasource widgets that were set as read-only during the workflow design. The datasource widgets are not set as Readonly in the DCT, as they do not get rendered properly in the UI. Therefore the widgets are loaded as editable and then set as Readonly using this function. To illustrate the significance of this method: a. Create a Datasource variable for the Owner property of the User_Task in the SampleReview workflow model and set it to Readonly as shown in Figure 94.
191
b. Publish the workflow. c. Create the corresponding custom_instantiation.cfg file using the iwmodeldct command. d. Save the custom_instantiation.cfg file and submit it to the staging area. e. Create a job based on this workflow. Figure 95 illustrates the Datasource variable in the instantiation screen. Figure 95 Datasource Variable (With setReadonlyDatasourceItems ())
If you remove this method from the custom_instantiation.cfg file, you can still set the values of the Datasource variable to Readonly by adding the <readonly> element to this file as shown below. However, the value for this variable appears as shown in Figure 96.
<item pathid="ID1211870771865" name="ID1211870771865"> <label>TeamSite user Picker</label> <description/> <readonly/> <select required="t"> <inline command="Datasource:executeComponent:TS User Picker"/> 192
</select> </item>
setHiddenDatasourceItems()
This function hides all the datasource widgets in the instantiation screen that were set as Hidden during the workflow design.
NOTE
If this function is removed from the custom_instantiation.cfg file, the datasource widgets that were set as Hidden during design are visible to the user in the instantiation screen.
loadReviewersValues(reviewerItem)
A Review task contains the Reviewers variable that appears in the instantiation screen. This variable is rendered as a List box and lists all the reviewers that were selected during the design of the workflow. Based on your workflow design, some of the reviewers may be specified by Configurable variables, Datasource variables, a user name or a group name. This function performs the following: Replaces all the Configurable variables with their default values. Evaluates all the Datasource variables with their results. Lists these values in the List box. By default, it also selects all the values in the List box.
setReadonlyReviewerItems()
This function prevents the user from editing the values of all the Reviewers widgets that were set as read-only during the workflow design. The Reviewers widgets are not set as Readonly in the DCT, as they do not get rendered properly in the UI. Therefore the widgets are loaded as editable and then set as Readonly using this function. To illustrate the significance of this function: a. Create a Review task in the SampleReview workflow model. b. Assign values for the properties Available Users, Available Groups, and Reviewers. c. Set the Reviewers property to Readonly. d. Publish the workflow.
193
e. Create the corresponding custom_instantiation.cfg file using the iwmodeldct command. f. Save the custom_instantiation.cfg file and submit it to the staging area.
g. Create a job based on this workflow. Figure 97 illustrates the Reviewers property in the instantiation screen (with each value in a separate line). Figure 97 Reviewers Property (With setReadonlyReviewerItems ())
If you remove this method from the custom_instantiation.cfg file, you can still set the values of the Reviewers property to Readonly by adding the <readonly> element to this file as shown below. However, the values of this property appear as shown in Figure 98 (with a comma separating each value).
<item pathid="ID1211877859386" name="ID1211877859386"> <label>List of Reviewers</label> <description/> <readonly/> <select multiple="t" required="t"/> </item>
enforceMinNoOfReviewers()
This function performs the validation to check whether the user has selected the minimum number of reviewers in the instantiation screen. This function is invoked when the user clicks Submit in the instantiation screen. It checks whether the number of reviewers selected from the list box of the Reviewers variable is equal to or greater than the minimum number of reviewers that was specified for this property during workflow design.
getOptionValues(option, parentItem, newOptions)
This is a utility function that populates the results returned by a Datasource into a Listbox widget of the review task. This function is invoked from within the function loadReviewersValues(reviewerItem).
194
The following code registers the function init() with the onFormInit event of the instantiation screen.
IWEventRegistry.addFormHandler("onFormInit", init);
This section of JavaScript code also contains the code to hide a dummy item in the beginning of the DCT. The DCT contains a starting element, startingItem. The sole purpose of this element is to prevent the JavaScript error that appears if the first element is an item and is set to hidden/ not visible when it receives focus. If the first item is a container, this error does not occur. The code is as follows:
var startingItem = IWDatacapture.getItem("/Config/iw-StartingItem"); startingItem.setVisible(false);
Default JavaScript
The default JavaScript that is generated when you create the custom_instantiation.cfg file using the iwmodeldct command is as follows:
<script> var reviewersIdList = "ID1211877859386"; var reviewersIdReadonlyList = "null"; var datasourceIdReadonlyList = "ID1211870771865"; var datasourceIdHiddenList = "null"; function init() { setReadonlyDatasourceItems(); setHiddenDatasourceItems(); var reviewerItem = null; reviewerItem = IWDatacapture.getItem("/Config/ID1211877859386"); loadReviewersValues(reviewerItem); setReadonlyReviewerItems(); } function setReadonlyDatasourceItems() { var dsItemId = datasourceIdReadonlyList.split(","); 195
for(i=0;i<dsItemId.length;i++) { var dsItemObj = IWDatacapture.getItem("/Config/" + dsItemId[i]); if((dsItemObj != null) && (dsItemObj != undefined)) { try { for(r=0;r<5000;r++){ } dsItemObj.setReadOnly(true); } catch(e){} } } } function setHiddenDatasourceItems() { var dsItemId = datasourceIdHiddenList.split(","); for(i=0;i<dsItemId.length;i++) { var dsItemObj = IWDatacapture.getItem("/Config/" + dsItemId[i]); if((dsItemObj != null) && (dsItemObj != undefined)) { try { for(r=0;r<5000;r++){ } dsItemObj.setVisible(false); } catch(e){} } } }
function loadReviewersValues(reviewerItem) { var options = reviewerItem.getOptions(); var newOptions = new Array(); if((options != null) && (options != undefined)) { for(j=0;j<options.length;j++) { newOptions = getOptionValues(options[j], reviewerItem, newOptions);} while(options.length >= 1) { reviewerItem.removeOption(reviewerItem.getOptions().length -1); options = reviewerItem.getOptions(); } 196
reviewerItem.setOptions(newOptions); } } function setReadonlyReviewerItems() { var reviewersId = reviewersIdReadonlyList.split(","); for(i=0;i<reviewersId.length;i++) { var reviewerObj = IWDatacapture.getItem("/Config/" + reviewersId[i]); if((reviewerObj != null) && (reviewerObj != undefined)) { reviewerObj.setReadOnly(true);} } } function enforceMinNoOfReviewers() { if((reviewersIdList != null) && (reviewersIdList != undefined)) { var reviewersId = reviewersIdList.split(","); for(i=0;i<reviewersId.length;i++) { var reviewerObj = IWDatacapture.getItem("/Config/" + reviewersId[i]); var minNoOfReviewersObj = IWDatacapture.getItem("/Config/" + reviewersId[i] + "-minNoOfReviewers"); var minNoOfReviewer = minNoOfReviewersObj.getValue(); var options = reviewerObj.getOptions(); var selectedOptions = 0; if((options != null) && (options != undefined)) { for(r=0;r<options.length;r++) { if(options[r].selected) { selectedOptions++;} } } if(selectedOptions < minNoOfReviewer && (reviewerObj.isVisible() && reviewerObj.isReadOnly())) { reviewerObj.setFocus(); alert("Select atleast " + minNoOfReviewer + " reviewers"); return false; } else { } } 197
} return true; } function getOptionValues(option, parentItem, newOptions) { if((option != null) && (option != undefined)) { optionValue = option.text; if(optionValue.indexOf("$IW_CV(") > 0) { var prefix = optionValue.substring(0,2); var beginIndex = optionValue.indexOf("$IW_CV("); var offset = "$IW_CV(".length; beginIndex = beginIndex + offset; var endIndex = optionValue.indexOf(")",beginIndex); var variableId = optionValue.substring(beginIndex,endIndex);var reviewerOption = IWDatacapture.getItem("/Config/" + variableId); var variableValue = reviewerOption.getValue(); var cleanValue = variableValue; if(cleanValue.length < 1) { var oriName = optionValue; var newName = oriName.substring(2,oriName.length); newOptions[newOptions.length] = new Option(newName,oriName,false,true); } else { var oriName = optionValue; newOptions[newOptions.length] = new Option(variableValue,oriName,false,true); } } else if(optionValue.indexOf("$IW_DS(") > 0) { var prefix = optionValue.substring(0,2); var beginIndex = optionValue.indexOf("$IW_DS("); var offset = "$IW_DS(".length; beginIndex = beginIndex + offset; var endIndex = optionValue.indexOf(")",beginIndex); var variableId = optionValue.substring(beginIndex,endIndex); var reviewerOption = IWDatacapture.getItem("/Config/" + variableId); var dsOptions = reviewerOption.getOptions(); for(i=0;i<dsOptions.length;i++) { if((dsOptions[i] != null) && (dsOptions[i] != undefined)) { var dsOptionValue = dsOptions[i].text;
198
if(dsOptionValue.length > 1) { newOptions[newOptions.length] = new Option(dsOptionValue,prefix + dsOptionValue,false,true); } } } } else { newOptions[newOptions.length] = new Option(optionValue.substring (2,optionValue.length),optionValue,false,true); } } return newOptions;} var startingItem = IWDatacapture.getItem("/Config/iw-StartingItem"); startingItem.setVisible(false); /*_iwdcwin.IWDCEventRegistry.addListener("onSave", enforceMinNoOfReviewers);*/ IWEventRegistry.addFormHandler("onSave", enforceMinNoOfReviewers); IWEventRegistry.addFormHandler("onFormInit", init); </script>
199
NOTES
Workflow Modeler supported by TeamSite 6.7.1 onwards, supports datacapture.6.0.DTD only. Ensure that you include the following DTD information in the custom_instantiation.cfg file.
<data-capture-requirements dtd-system-identifier="http://localhost/iw-cc/datacapture6.0.dtd" dcr-validation="reject-invalid" xmlns="http://www.interwoven.com/schema/datacapturedtd">
Ensure that the IDs of the properties match in the default_config.xml and custom_instantiation.cfg files. For additional information, see the section step 8 on page 181.
200
Chapter 9
If you are upgrading to Workflow Modeler 7.0, for the existing Datasources to function appropriately, you need to remove all references to the CSLocalFactory object and replace it with the CSJavaFactory object, in the Datasource code. For more information on CSJavaFactory, see the ContentServices for TeamSite Release Notes.
201
Map User Picker. Renders a map; the key field of the map contains the actual value and the value field of the map contains the display name. (It is assumed that no modification has been done in the DataSourceConfig.xml file, till now.) 1. Navigate to the iw-home/local/config folder. 2. Edit the DataSourceConfig.xml file. 3. Remove the comments. 4. Replace getafix with the TeamSite server name as shown below. For example, to use TS Branch Picker:
<datasource> <name>TS Branch Picker</name> <classname>com.interwoven.datasource.examples.TSBranchPicker</classname> <param name="servername">TeamSite server name</param> <param name="serviceBaseURL">http://TeamSite server name:80</param> <param name="csFactory">com.interwoven.cssdk.factory.CSJavaFactory</ param> </datasource>
5. Save the file. 6. At the command prompt, navigate to the following folder:
iw-home/local/config/lib/content_center/customer_src
7. Run make_toolkit.ipl. 8. Log on to Workflow Modeler, connect to the TeamSite server from Workflow Modeler, and create a worklfow model with a Datasource variable.
NOTE
If you are already logged on to Workflow Modeler and connected to the TeamSite server, then disconnect from the TeamSite server and re-connect. 9. For this Datasource variable, select one of out-of-the-box Datasources from the Datasource Name drop-down list.
NOTE
If the Datasources are not listed, then you have to run the iwreset -a command from the command prompt. From Workflow Modeler, re-connect to the TeamSite server. For the Datasource variable created in step 8, select one of out-of-the-box Datasources from the Datasource Name drop-down list.
202
Creating a Datasource
Creating a Datasource
To create a Datasource: 1. Implement a Datasource interface, see Implementing Datasource Interfaces on page 203. 2. Register the Datasource with TeamSite, see Registering a Datasource on page 206. 3. Deploy the Datasource in TeamSite, see Deploying a Datasource on page 207.
The ArrayDataSource interface has been deprecated and will not be supported after a few releases. Therefore, it is recommended that you use the ListDataSource interface (instead of ArrayDataSource), as it provides similar capability.
All your Datasource implementations have to implement at least one of these interfaces to be recognized by the Datasource framework. These interfaces are located in the following file:
iw-home/httpd/webapps/content_center/WEB-INF/lib/datasource.jar
After you create a class that implements one of these interfaces, perform the following steps: 1. Compile the file to create a .class file.
203
NOTE
Ensure that the datasource.jar and DataSourceFrameworkSchema.jar files are in your projects class path. 2. Create a .jar file using the .class file. The .jar file can have any name, for example, SampleDatasource.jar. 3. Register the Datasource by adding an entry for it in the Datasource configuration file. For information on registering Datasources, see Registering a Datasource on page 206.
SimpleDataSource
You must implement this interface if you are creating a Datasource that returns a String.
Signature
public interface SimpleDataSource { public String execute(String sessionId, String context, Map param); }
ArrayDataSource
You must implement this interface if you are creating a Datasource that returns an array of values.
NOTE
Signature
public interface ArrayDataSource { public String[] execute(String sessionId, String context, Map param); }
Creating a Datasource
sessionId. context.
TeamSite vpath.
param. Hash map containing the additional parameters passed using the Datasource configuration file DataSourceConfig.xml or passed while calling the Datasource in the FormsPublisher DCT.
ListDataSource
You must implement this interface if you are creating a Datasource that returns a list of values. It is mostly used for populating a list.
Signature
public interface ListDataSource { public List<String> execute(DataSourceContext context); }
MapDataSource
You must implement this interface if you are creating a Datasource that returns a map. It is mostly used to populate different display names and display values in lists. Key field of the map contains the actual value and the value field of the map contains the display name.
Signature
public interface MapDataSource { public Map<String,String> execute(DataSourceContext context); }
SortedValuesMapDataSource
You must implement this interface if you are creating a Datasource that returns a map whose values are sorted. It is mostly used to populate different display names and display values in lists. Key field of the map contains the actual value and the value field of the map contains the display name.
Signature
public interface SortedValuesMapDataSource 205
For more information, see Javadocs of this class. The class is located under:
com.interwoven.datasource.core.DataSourceContext
Registering a Datasource
Every Datasource must be registered with the Datasource framework. To register a Datasource, you need to add an entry for that Datasource in the Datasource configuration file DataSourceConfig.xml, which is present under iw-home/local/config.
NOTE
The Datasource configuration file also enables you to pass additional information to the Datasource component as parameters.
The structure of the DataSourceConfig.xml file with an entry for a sample Datasource (for example, TS User Picker) can be as follows:
... ... <datasource> <name>TS User Picker</name> <classname>com.interwoven.datasource.examples.TSUserPicker</classname> <namespace>IW-WFM</namespace> <param name="servername">abc-w2ks</param> <param name="serviceBaseURL">http://abc-w2ks:80</param> <param name="csFactory">com.interwoven.cssdk.factory.CSJavaFactory </param> </datasource> ... ...
206
Creating a Datasource
where,
name:
Unique name for the Datasource. You can use any name for your Datasource, provided it is unique in relation to other registered Datasources on that TeamSite server. Fully qualified name of the Datasource class.
Classname:
namespace (optional): Specifies the Datasource scope and thereby restricts its availability to a particular module of TeamSite. In addition, it helps in resolving the naming conflict. In other words, you can use the same Datasource name for Datasources belonging to different namespaces. For example, you can have a TS User Picker Datasource for Workflow Modeler and one for FormsPublisher.
NOTES
If you do not specify the namespace element, the Datasource is available to both Workflow Modeler (IW-WFM) and FormsPublisher. You must not use namespace names starting with IW-, as they are restricted.
param:
Use this element to pass any additional information that your Datasource may need, for example, database URL, LDAP server name, and so on.
The structure of the DataSourceConfig.xml file is based on the DataSourceConfig.xsd schema. A copy of the DataSourceConfig.xsd file is present under:
//TS_Server/iwadmin/main/workflowModels/STAGING/Internal
For more information on the DataSourceConfig.xsd schema, see DataSourceConfig.xsd on page 247.
Deploying a Datasource
After you register the Datasource, perform the following steps to deploy the Datasource: 1. Place the .jar file into the following location:
iw-home/local/config/lib/content_center/customer_src/lib
3. Run make_toolkit.ipl. You can now use the newly created Datasource in Workflow Modeler and DCTs.
207
NOTE
To use the newly created Datasource in Workflow Modeler, you may have to re-login to TeamSite.
For information on creating a custom instantiation form, see Chapter 8, Customizing the Instantiation Screen.
One of the ways to customize a DCT is to use Datasources. You can use Datasources for any DCT UI widget that supports the <option> tag. To call Datasources in a DCT, you can use one of the following: Static Calls (inline) Dynamic Calls (FormAPI)
getDatasourceNames
Retrieves names of all the Datasources registered with TeamSite. You can also retrieve a filtered list of names based on namespaces; for example, you can retrieve names of all the Datasources belonging only to the Workflow Modeler namespace (IW-WFM).
208
Syntax
<command-prefix>:<method-name>:<namespace>
where,
command-prefix. method-name
namespace (optional). This is the namespace identifier used while registering Datasources. For example, for Datasources belonging to Workflow Modeler, it should be IW-WFM.
This sample command retrieves names of all the Datasources belonging only to the Workflow Modeler namespace (IW-WFM).
executeComponent
Executes the specified Datasource (for example, UserPicker) and displays the values returned by that Datasource.
Syntax
<command-prefix>:<method-name>:<component-name>: <param-name>=<param-value>:<param-name>=<param-value>
where,
command-prefix. method-name.
This is a constant and should always be executeComponent; it is case-insensitive. This is a name of a component that you want to execute, for example,
(optional, unless parameter value is specified). This is a name of a parameter that can retrieve a specific value. (optional). This is a value for the passed parameter.
param-value
In this sample code, the UserPicker Datasource returns users with the master role from the TeamSite server.
210
IWDatasource
Javascript function that enables you to work with Datasources. To use dynamic calls for Datasources, you need to create an instance of this Javascript function and call its methods. It includes the following methods:
getDatasourceNames
Retrieves a list of registered Datasources for the specified namespace. This is an asynchronous call. Arguments
callbackfunction. Name of the user-defined callback Javascript function that is capable of
handling the Datasource names. The signature of the callback function should be of the following form: <functionName>(Array, String, IWMap).
namespace. Namespace of the Datasource. If you pass an empty string, all the registered Datasources are returned. contextParams (optional). An IWMap object that contains a list of name-value pairs. These values are returned to the callback function as is. You can use them to pass the contextual information. As this is an asynchronous call, you can pass object names, widget names, and so on, so that when you receive a response in the callback function, you can map the response with the request and take appropriate action.
Return Value Returns void; calls the callback function with the result, default value, and contextParams.
executeDatasource
Executes the specified Datasource component. This is an asynchronous call. Arguments
callbackfunction. Name of the user-defined callback Javascript function, which is capable
of handling the Datasource names. The signature of the callback function should be of the following form: <functionName>(Array, String, IWMap).
dsComponentName. UserPicker. dsParams
(optional). An IWMap object that contains a list of name-value pairs. These name-value pairs are passed to the Datasource. These values are different from the name-value pairs specified while registering the Datasource.
211
(optional). An IWMap object that contains a list of name-value pairs. These values are returned to the callback function as is. You can use them to pass the contextual information. As this is an asynchronous call, you can pass object names, widget names, and so on, so that when you receive a response in the callback function, you can map the response with the request and take appropriate action.
contextParams
Return Value Returns void; calls the callback function with the result and contextParams.
addOptionsToSelect
Adds the result of a Datasource into a Data Capture Form (DCF) select item. It is a utility method.
IWMap
Simulates a Java Map object in Javascript. You should pass an instance of this type of object to the methods of IWDatasource. The IWMap object contains the following methods:
put().
For example:
mapObj.put(key,value); get().
For example:
mapObj.get(key); key().
For example:
mapObj.keys(); length().
For example:
mapObj.length();
... function init() { getDatasourceNames(); /*Add listners to this component */ var propertyItem = IWDatacapture.getItem ("press-release/Heading/head/datasourcedemo/dcapidsComponent"); IWEventRegistry.addItemHandler(propertyItem.getName(), "onItemChange", setValueForDatasource); } function setValueForDatasource(item, defaultValue) { if(item.getValue() != null) { var selectedDSValue = item.getOptions()[ item.getValue()].value; var datasourceObj = new IWDatasource(); var dsParams; var returnParams = new IWMap(); returnParams.put("selectItemVpath", "press-release/Heading/head/datasourcedemo/dcapiUsers"); datasourceObj.executeDatasource( "setDatasourceValueCallback", selectedDSValue, dsParams, returnParams); return; } } function setDatasourceValueCallback(resultObj, ctxParams) { var selectItemRef; if(ctxParams != undefined) { selectItemRef = ctxParams.get("selectItemVpath"); } var datasourceObj = new IWDatasource(); datasourceObj.addOptionsToSelect(resultObj, selectItemRef, getItemValue(selectItemRef)); top.hiddenFrameRunning = true; return; } function getDatasourceNames() { var returnParams = new IWMap(); returnParams.put("selectItemPath", 213
"press-release/Heading/head/datasourcedemo/dcapidsComponent"); var datasourceObj = new IWDatasource(); datasourceObj.getDatasourceNames("setDatasourceNamesToSelect", "", returnParams); } function setDatasourceNamesToSelect(resultObj, returnParams) { alert("3"); var selectItemPath; if(returnParams != undefined) { selectItemPath = returnParams.get("selectItemPath"); } alert("Result received = " + resultObj); var datasourceObj = new IWDatasource(); datasourceObj.addOptionsToSelect(resultObj, selectItemPath, getItemValue(selectItemPath)); return; } function getItemValue(itemName) { var propertyItem = IWDatacapture.getItem(itemName); var value; try{ value = item.getOptions()[propertyItem.getValue()].value; return value; }catch(e){} try{ value = propertyItem.getValue(); return value; }catch(e){} } ... ...
214
Chapter 10
215
Pre-processor commands are executed during the workflow instantiation (just before the instantiation screen is rendered), whereas post-processor commands are executed after the instantiation screen is rendered and before the workflow job is created.
NOTE
You cannot remove a CONFIGURABLE, DATASOURCE, or SCRIPT variable using Workflow APIs, within a PreProcessor Command or PostProcessor Command. Workflow APIs only support removing simple text values and not variables.
216
NOTE
For out-of-process commands, you can develop a class or script and place it any location. You need to specify the location in the PreProcessor Command or PostProcessor Command property of a workflow model.
NOTES
In addition, your project should have the modelerworkflowapi.jar file in its classpath. The modelerworkflowapi.jar is available at the following location: iw-home/httpd/webapps/
content_center/WEB-INF/lib/
In your class, you need to provide implementation for the execute() method. It enables you to make modifications to a workflow model. It returns the WFMWorkflow object, which contains the workflow instance. You can add files, change the owner, change properties of the workflow, and return the workflow object. Syntax
public WFMWorkflow execute(WFMWorkflow workflow, Map<String,String> params)
Parameters
workflow.
A WFMWorkflow instance. You can make changes to this instance; the changes are reflected in the workflow.
params. Additional parameters passed while specifying a command for the PreProcessCommand or PostProcessCommand property.
217
The key parameter is the instance of the WFMWorkflow interface. This interface represents a workflow model and includes methods (such as addFile(), getTasks(), setOwner(), and so on) for modifying the workflow model. Using this interface, you can add files to or remove files from the workflow model. In addition, you can modify the properties of the workflow model.
NOTE
You cannot change the structure of the workflow model. In other words, you cannot add additional workflow elements (for example, tasks, links, and so on).
Additional Interfaces
In addition to the WFMWorkflow interface, TeamSite provides interfaces for all the workflow elements. Some of them are as follows:
WFMTask WFMUserTask WFMReviewTask WFMEmailTask WFMDeployTask WFMSubmitTask WFMFlow WFMDefaultFlow WFMConditionalFlow
All the interfaces include methods that enable you to retrieve and set properties of their respective tasks. For example, using the WFMUserTask interface, you can retrieve and set the properties of a User task. You can find more information on the interfaces and their methods in the Javadocs included in the modelerworkflowapidoc.jar file, which is located at:
iw-home/httpd/webapps/content_center/WEB-INF/lib
Example One
The following sample code snippet illustrates how you can use the WFMWorkflow, WFMTask, and WFMURLTask interfaces. Similarly, you can use other interfaces in your custom code.
public class CustomCodeDemo implements InProcessJavaCommand { public WFMWorkflow execute(WFMWorkflow workflow, Map<String,String> params) 218
{ //Add a file to the workflow WFMFile file=new WFMFile("//abc/main/WORKAREA/myarea/Task.txt", "Comment Sample"); workflow.addFile(file); //Retrieve all the tasks of the workflow //and store them in an array of WFMTask WFMTask[] tasks=workflow.getTasks(); //Loop through the array, identify the URL task, //and modify its properties for (int i = 0; i < tasks.length; i++) { if(tasks[i] instanceof WFMURLTask) { WFMURLTask urltask=(WFMURLTask)tasks[i]; ... ... urltask.addVariable("WHO","TSMaster"); urltask.setBriefDescription("Modified Brief Description"); urltask.setDescription("Modified Description"); ... ... } } return workflow; } }
Example Two
To validate the files that are attached to a workflow and based on the validity, determine the course of the workflow: 1. Add a new variable to the workflow, either at the Job or Task level, for example, testVariable. 2. Set this variable as a CONFIGURABLE variable. If you do not want this variable to appear in the instantiation screen, make it a hidden variable. 3. In the PreProcessor Command property of your workflow, use the getFiles API and retrieve a list of all the files attached to the job. 4. Convert this into a string representation, and set it as the value of testVariable.
219
5. In the instantiation screen, use FormAPI to read the value of the CONFIGURABLE variable and perform any UI related actions, such as showing error message, stopping the user from creating a new job, and so on.
4. Run make_toolkit.ipl. Your custom code will be called during instantiation after you add the command in Workflow Modeler for the PreProcessor Command or PostProcessor Command properties.
220
Appendix A
Prerequisites
Before you begin, you need to ensure the following: The TeamSite server is installed and configured as described in the TeamSite Installation Guide. Workflow Modeler client is installed as described in this manual. For more information, see Chapter 2, Installing Workflow Modeler. You have privileges to Publish workflow models to the TeamSite server. You have the TeamSite server name and the Web daemon (iwwebd) port number available.
221
You are familiar with basic TeamSite administration tasks (or have access to the TeamSite documentation). The WorkflowAdmin role has been created for you in TeamSite. For more information on the WorkflowAdmin role, see Understanding Workflow Roles on page 137.
Tutorial Overview
In a real-world implementation, before developing a workflow model, you need to analyze your business requirements and develop a design for the same. As these stages are out of the scope of this tutorial, this chapter focuses only on the development and use of Workflow Modeler workflow models, which follow this pattern: Development. A workflow model developer creates a workflow model that describes the flow of tasks in a particular job. Deployment. The workflow model developer makes the workflow model available to job creators by publishing the workflow model to the TeamSite server and adding an entry of the workflow model in the available_models.xml file. For more information on publishing the workflow model and adding an entry in the available_models.xml file, see Publishing Workflow Models to TeamSite on page 60 and Subscribing Workflow Models on page 144. Job Instantiation. In ContentCenter Professional, a job creator selects the workflow model that describes the job to be created. A screen appears into which the job creator enters data specific to that job. The presentation and default values for this screen can be configured. For more information, see Configuring Workflow Models on page 151. Although this tutorial covers only the development and deployment phases, the following sections use the tutorial project to describe the three phases of workflow development and use, so that you can gain a broad understanding of this process.
Development
In this tutorial you, the workflow developer will develop a workflow model, similar to Configurable Default Submit, which describes a job comprising the following tasks: A user whose work does not need review submits a file. Start Task. Defines the start of the workflow model.
222
Tutorial Overview
Dummy Task. If metadata generation for the file is not required, the job proceeds to a dummy task. A dummy task is used as a placeholder for time delays, tasks resets, or gate transition tasks. The file is sent for submission after the specified time limit. Metadata Task. If metadata generation for the file is required, the job proceeds to the Metadata task, which calls the iwmetadata.cgi program to create metadata. After the metadata is created, the file is sent for submission. Submit Task. The job transitions to the Submit task and TeamSites Submit operation is performed. The file is submitted to the Staging area. The job proceeds to the End task if deployment is not required or proceeds to the Deploy task for deployment. Deploy Task. The file is deployed to the specified location. If the deployment operation succeeds, the job proceeds to the End task. If it fails, it proceeds to the Notify Deploy task. Gateway. The Gateway ensures that the job proceeds to Notify Deploy and Resolve Deploy Problems tasks only if the Deploy Task fails. Notify Deploy Task. An email is sent to the job initiator if there is a deployment problem. Resolve Deploy Problems Task. The job transitions to the Resolve Deploy Problems task and the deployment problem is resolved. After the deployment problems are resolved, the job transitions to the Deploy Task to be redeployed to the specified location. If the deployment operation is cancelled, the job transitions to the End task. End Task. The job ends after the task is completed.
Deployment
When the workflow model development is complete, you can save or publish it to the TeamSite server. If you select Save to Server, the draft workflow model is saved to //TS_Server/iwadmin/main/ workflowModels. However, if you select Publish Workflow, the workflow model is saved to // TS_Server/iwadmin/main/workflowModels/STAGING/Models.
NOTE
Whenever you select Publish Workflow, a copy of the workflow model is automatically saved to //TS_Server/iwadmin/main/workflowModels.
To make the workflow model available to job creators, you need to add an entry for the workflow model in the available_models.xml file. This file helps you manage a workflow models availability to one or more TeamSite branches. For information on managing workflows, see Subscribing Workflow Models on page 144.
223
Instantiation
When job creators initiate a new job, the creator first selects a workflow in a ContentCenter interface, and then fills in the required job parameters (for example, job description, task owner, and so on) in the form. You will configure the tutorial workflow model in such a way that some job parameters are extracted automatically by the workflow model, and others must be supplied by the job creator. You can customize the following aspects of new job forms: The type of form element that displays for any given line of input (for example, a text area instead of a text field). The default value for each form element.
For a UNIX server, the domain name is the same as the server name. For example, if your server name is myServer, the domain name too is myServer. Server Name. The name of the TeamSite server. Port Number. The Web daemon (iwwebd) port number.
224
3. Click OK. 4. Select File > New Workflow. By default, a workflow model labeled Unnamed (#) (where # is the total number of workflow models you have created) is displayed. 5. Place the following workflow elements on the Project pane, so that your workflow model is identical to the one in the following figure: Figure 100 Tutorial: Creating a New Workflow Model
The following table lists the elements used in this workflow model: Table 24 TutorialList of Workflow Elements
Element Name Element Type
Start Event Dummy Task Conditional Link Conditional Link Timeout Link
225
Submit Files Metadata Capture Submit Deploy Content No Deploy Deploy Task Gateway Notify Notify Deploy Resolve Problems Resolve Resolve Deploy Problems Deploy Success Deploy Failure Retry Cancel End
Default Link Metadata Task Submit Task Conditional Link Conditional Link Deploy Task AND Gateway Conditional Link Email Task Conditional Link Default Link User Task Success Link Failure Link Default Link Default Link End Event
These tasks and links have been renamed using their Name attribute.
Variables Overview
In this tutorial, you will create two new variables supported by the TeamSite workflow engine. The new variables are as follows: variable. Enables you to create a workflow model that contains elements whose values do not need to be assigned until the workflow is customized or instantiated in TeamSite. For example, if you have an AreaVPath property set as a configurable variable, you do not need to provide the value when you are creating the workflow model. Instead, its value can be assigned by end-users in TeamSite.
CONFIGURABLE
variable. Enables you to write JavaScript for any task, transition link, or node property and have the value returned by the script determine the value assigned to that property. For example, if you create a Script variable for the property MDCaptureUI, you could create a script to determine which metadata capture screen is displayed to end-users.
SCRIPT
226
These variables are available for most attributes of the workflow model elements. Their values are resolved just before instantiation. Therefore, they appear as strings or Boolean values in the final job specification file. For more information on these variables, see Workflow Modeler Variables on page 65.
Name
Specifies the name that Type Sample WorkflowModel displays in the list of available jobs in the ContentCenter interfaces Provides a brief description for the workflow model. Type Sample Workflow.
Brief Description
227
Global Variables
Variables that are available across the workflow model. All the workflow model elements can use these variables.
Click the blank field next to the Description attribute, and create three global CONFIGURABLE variables with the following details (while creating these variables, make sure that you select the Hidden and Readonly check boxes before clicking Add): Variable 1 IDType includeMetadata LabelType Include Metadata Default ValueType true Select the Hidden and Readonly options Variable 2 IDType includeDeploy LabelType Include Deploy Default ValueType true Select the Hidden and Readonly options Variable 3 IDType notifyDeployFailure LabelType Notify Deploy
Failure
Default ValueType true Select the Hidden and Readonly options The values (true or false) set for these variable and the script used for the conditional links determine the workflow path. These attributes are common to all the workflow tasks. For more information on attributes specific to the workflow, see Assigning Workflow-Specific Attributes on page 90.
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces Provides a brief description of what the task does.
Allows the job creator to 1. Click the blank field next to the enter a description of the new Description attribute. task 2. In the text box of the Description dialog box, type Dummy Task.
Name
Specifies the name that Type Metadata Capture displays in the list of available jobs in the ContentCenter interfaces Provides a brief description of Type Metadata Capture what the task does.
Brief Description
229
Description
Allows the job creator to enter 1. Click the blank field next to the a description of the new job Description attribute. 2. In the text box of the Description dialog box, type Metadata Task.
Name
Specifies the name that Type Submit displays in the list of available jobs in the ContentCenter interfaces Provides a brief description of Type Submit Files what the task does Allows the job creator to enter 1. Click the blank field next to the a description of the new job Description attribute. 2. In the text box of the Description dialog box, type Submit Task. Allows the job creator to specify submit comments for the associated files. Click the blank field next to the Submit Comment attribute, and create a CONFIGURABLE variable with the following details: IDType sbmtComment LabelType Comment DescriptionEnter submit comment
Submit Comment
230
Submit Info
Allows the job creator to Click the blank field next to the specify submit information for Submit Info attribute, and create a CONFIGURABLE variable with the the associated files. following details: IDType sbmtInfo LabelType Info DescriptionEnter submit information
Name
Specifies the name that Type Deploy Task displays in the list of available jobs in the ContentCenter interfaces Enables you to set values for 1. Click the field next to the Variables variables pertinent to this task attribute. 2. From the Name field, select odDeploymentName. 3. In the Value field of the Variables dialog box, set a valid value for the odDeploymentName variable. You need to ensure that Open Deploy has been configured. For information on the Open Deploy configuration, see the Open Deploy documentation.
Variables
231
Name
Specifies the name that Type Notify Deploy displays in the list of available jobs in the ContentCenter interfaces Provides a brief description of Type Notify Deploy Failure what the task does Allows defining values for variables Click the field next to the Variables attribute. 1. In the Name field, select mail_template, and in the Value field, select a default mail template. Click Add. 2. In the Name field, select ClassName, and in the Value field, select a default class name. Click Add. 3. In the Name field, select target_task_name, and in the Value field, select Resolve Deploy Problems. Click Add. Note that if you are using default mail templates and classes, use the following combination: For authorNotification.xsl or
configurableAuthorNotificatio n.xsl, use the AuthorMailNotificationTask
232
Specify the email address to which you want the notification to be sent. To do this, complete the following steps: a. Log in to TeamSite. b. Select the Administration tab. c. In the left pane, under Roles and Permissions, select Manage Users. A list of users is displayed in the right pane. d. Click Edit against the pertinent user. e. In the User Details page, enter the email address in the Email text box, and click Save. Specify the mail domain and server values. Complete the following steps: a. Navigate to the TeamSite server configuration file, iw.cfg file. By default, the file is located in /etc (Solaris) or iw-home/etc (Windows) b. In the iw.cfg file, specify the mail domain and mail server names. Example:
maildomain=MyCompany.com mailserver=smtp.MyCompany.com
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces
233
Expression
Indicates (using true or false) whether the link should be used for the workflow path
1. Select SCRIPT from the field next to the Expression attribute. 2. In the Source tab, type the following:
if("$IW_CV(includeMetadata)" == "true") { true; } else { false; }
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces
Type No Metadata
234
Expression
Indicates (using true or false) whether the link should be used for the workflow path
1. Select SCRIPT from the field next to the Expression attribute. 2. In the Source tab, type the following:
if("$IW_CV(includeMetadata)" != "true") { true; } else { false; }
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces
Timeout Duration
1. Click the field next to the Timeout Duration attribute. 2. In the Timeout type option, select either Absolute or Relative. 3. In the Minute field, type 1. 4. Click OK.
235
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces Indicates (using true or false) whether the link should be used for the workflow path
Type No Deploy.
Expression
1. Select SCRIPT from the field next to the Expression attribute. 2. In the Source tab, type the following:
if("$IW_CV(includeDeploy)" != "true") { true; } else { false; }
236
2. In the Properties pane, specify values for the following attributes: Table 35 TutorialDeploy Content Link Attributes
Attribute Description Action
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces Indicates (using true or false) whether the link should be used for the workflow path
Expression
1. Select SCRIPT from the field next to the Expression attribute. 2. In the Source tab, type the following:
if("$IW_CV(includeDeploy)" == "true") { true; } else { false; }
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces
Type Notify.
237
Expression
Indicates (using true or false) whether the link should be used for the workflow path
1. Select SCRIPT from the field next to the Expression attribute. 2. In the Source tab, type the following:
if("$IW_CV(notifyDeployFailure)" == "true") { true; } else { false; }
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces
238
Expression
Indicates (using true or false) whether the link should be used for the workflow path
1. Select SCRIPT from the field next to the Expression attribute. 2. In the Source tab, type the following:
if("$IW_CV(notifyDeployFailure)" != "true") { true; } else { false; }
Other Links
For all other links, you need to set the Name attribute only. To specify a name for a link: 1. On the Project pane, select a link. 2. In the Properties pane, click the field next to the Name attribute. 3. Type a name for the link.
2. Click Yes. If the workflow model has error(s), the Error pane appears at the bottom of the application screen with a list of errors. You need to fix the errors, if any. For more information on the Error pane and fixing errors, see Errors Pane on page 54. If there are no errors, the Save As dialog box appears. 3. In the Save As dialog box, navigate to the required directory. 4. Name the file Sample_WorkflowModel.ipm. 5. Click Save. Now that you have validated your workflow model and saved it, you are ready to publish it to the TeamSite server.
Now you need to make the workflow model available to job creators. To make the workflow model available to job creators, you need to add an entry for the workflow model in the available_models.xml file. This file helps you manage a workflow models availability to one or more TeamSite branches. For information on managing workflows, see Subscribing Workflow Models on page 144. Finish the tutorial by testing your work. In the next section, you will invoke your workflow model from a ContentCenter interface and create a new job with it.
240
If you do not select the specified minimum number (or more) reviewers, you will not be able to instantiate the job. 5. Specify values for the blank fields. 6. Click Submit. This step will initiate the job. 7. Click the Workflow tab. The job you just created has placed a task in your Task list. Complete all the tasks of the job. Congratulations! You have successfully completed the Workflow Modeler tutorial.
241
242
Appendix B
Workflow Schemas
Workflow schemas are available in \iwadmin\main\workflowModels\STAGING\Internal. They are as follows:
Available_Models1.0.xsd.
Defines the schema for the available_models.xml file. It contains a collection of declarations (elements and attributes) that describe the expected document structure.
BPMNModel.xsd.
Defines the schema for the workflow model file (.ipm), which includes information on the workflow elements (for example, User task).
ProcessModelConfigutation.xsd.
Defines the schema for a workflow models default configuration file. This configuration file contains information about the CONFIGURABLE, DATASOURCE, and SCRIPT variables added in the workflow model.
DataSourceConfig.xsd.
Defines the schema for the DataSourceConfig.xml file, which is used to register Datasources.
The following sections include detailed information on the key schemas (Aavailable_Models1.0.xsd and DataSourceConfig.xsd).
Defines an element and what it can contain. Defines the attributes that are allowed for an element. file is available in \iwadmin\main\workflowModels\STAGING\
ATTRIBUTE.
243
The following Available_Models1.0.xsd defines the default behavior of the available_models.xml file:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!-- edited with XMLSpy v2005 rel. 3 U (http://www.altova.com) by Hayden Ridenour (Interwoven, Inc.) --> <xs:schema xmlns="http://www.interwoven.com/modeler/schema/subscription10" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http:// www.interwoven.com/modeler/schema/subscription10" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:complexType name="available_modelsType"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element ref="model"/> </xs:sequence> <xs:attribute name="require_workarea" default="true"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:element name="available_models" type="available_modelsType"/> <xs:complexType name="modelType"> <xs:sequence> <xs:choice minOccurs="0"> <xs:element ref="allowed"/> </xs:choice> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="filename" type="xs:string" use="required"/> <xs:attribute name="active" default="true"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="debug" default="false"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType>
244
</xs:attribute> </xs:complexType> <xs:element name="model" type="modelType"/> <xs:complexType name="allowedType"> <xs:sequence> <xs:choice minOccurs="0"> <xs:element ref="command"/> <xs:element ref="branch-vpath"/> <xs:element ref="vpath-regex"/> <xs:element ref="role"/> <xs:element ref="user"/> <xs:element ref="group"/> <xs:element ref="and"/> <xs:element ref="or"/> <xs:element ref="not"/> </xs:choice> </xs:sequence> </xs:complexType> <xs:element name="allowed" type="allowedType"/> <xs:complexType name="andType"> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element ref="command"/> <xs:element ref="branch-vpath"/> <xs:element ref="vpath-regex"/> <xs:element ref="role"/> <xs:element ref="user"/> <xs:element ref="group"/> <xs:element ref="and"/> <xs:element ref="or"/> <xs:element ref="not"/> </xs:choice> </xs:sequence> </xs:complexType> <xs:element name="and" type="andType"/> <xs:complexType name="orType"> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element ref="command"/> <xs:element ref="branch-vpath"/> <xs:element ref="vpath-regex"/> <xs:element ref="role"/> <xs:element ref="user"/> <xs:element ref="group"/> <xs:element ref="and"/> <xs:element ref="or"/> 245
<xs:element ref="not"/> </xs:choice> </xs:sequence> </xs:complexType> <xs:element name="or" type="orType"/> <xs:complexType name="notType"> <xs:choice> <xs:element ref="command"/> <xs:element ref="branch-vpath"/> <xs:element ref="vpath-regex"/> <xs:element ref="role"/> <xs:element ref="user"/> <xs:element ref="group"/> <xs:element ref="and"/> <xs:element ref="or"/> <xs:element ref="not"/> </xs:choice> </xs:complexType> <xs:element name="not" type="notType"/> <xs:complexType name="userType"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:element name="user" type="userType"/> <xs:complexType name="groupType"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:element name="group" type="groupType"/> <xs:complexType name="roleType"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:element name="role" type="roleType"/> <xs:complexType name="commandType"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:element name="command" type="commandType"/> <xs:complexType name="branch-vpathType"> <xs:attribute name="vpath" type="xs:string" use="required"/> <xs:attribute name="include-subbranches" default="true"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> 246
DataSourceConfig.xsd
<xs:element name="branch-vpath" type="branch-vpathType"/> <xs:complexType name="vpath-regexType"> <xs:attribute name="regex" type="xs:string" use="required"/> </xs:complexType> <xs:element name="vpath-regex" type="vpath-regexType"/> </xs:schema>
DataSourceConfig.xsd
The structure of the DataSourceConfig.xml file is based on the following schema (DataSourceConfig.xsd):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!-- edited with XMLSpy v2005 rel. 3 U (http://www.altova.com) by Hayden Ridenour (Interwoven, Inc.) --> <!--W3C Schema generated by XMLSpy v2005 rel. 3 U (http://www.altova.com)--> <xs:schema xmlns="http://www.interwoven.com/schema/datasourceFramework" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http:// www.interwoven.com/schema/datasourceFramework" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="classname" type="xs:string"/> <xs:complexType name="datasourceType"> <xs:sequence> <xs:element ref="name"/> <xs:element ref="classname"/> <xs:element name="namespace" type="xs:string" minOccurs="0"/> <xs:element name="param" type="paramType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="datasources"> <xs:complexType> <xs:sequence> <xs:element name="datasource" type="datasourceType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="name" type="xs:string"/> <xs:complexType name="paramType"> <xs:simpleContent> 247
<xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:schema>
248
Appendix C
Datasource Example
To create a Datasource, you must implement the SimpleDataSource, ListDataSource, MapDataSource, or SortedValuesMapDataSource interface. For information on these interfaces, see Implementing Datasource Interfaces on page 203.
NOTE
To create a sample Datasource: 1. Write a java class that implements the MapDataSource interface. For your reference, we have included the actual code of an out-of-the-box Datasource interface, MapUserPicker. For more information on using the Map User Picker out-of-the-box Datasource, see Using Out-of-the-Box Datasources on page 201.
//MapUserPicker.java package com.interwoven.datasource.examples; import import import import import import import import import import import import import com.interwoven.datasource.ArrayDataSource; com.interwoven.datasource.MapDataSource; com.interwoven.datasource.core.DataSourceContext; com.interwoven.log100.Logger; com.interwoven.log100.LoggerFactory; com.interwoven.cssdk.common.CSClient; com.interwoven.cssdk.common.CSRemoteException; com.interwoven.cssdk.common.CSException; com.interwoven.cssdk.common.CSIterator; com.interwoven.cssdk.access.*; com.interwoven.cssdk.factory.CSFactoryInitializationException; com.interwoven.cssdk.filesys.CSVPath; com.interwoven.cssdk.filesys.CSBranch;
249
import java.util.*; /** * Datasource class, which retrieves all TeamSite users and sends back the * shortname and display name. */ public class MapUserPicker implements MapDataSource { private static final Logger log = LoggerFactory.getLogger(MapUserPicker.class.getName()); /** * This method returns Map<String,String> containing names of all the * TeamSite users. It uses CSClientUtil.java class * to get the CSClient object from the session string passed by the * Datasource framework. * Key contains the user's shortname and value contains the user's * display name */ public Map execute(DataSourceContext context) { String sessionId = context.getSessionId(); String vpath = context.getServerContext(); Map<String,String> params = context.getAllParameters(); if(sessionId != null) { Map test = new HashMap(); test.put("rsk1","rshamanth1"); test.put("rsk2",null); test.put("rsk3","!)@(@#*#)&_$$#&%_@$#%+_#+($)#%$\":>>?|{}{|)"); test.put("rsk4","dude"); test.put("rsk4","dude duplicate"); test.put("",""); return test; } CSClient client = null; String role = null; if(log.isDebugEnabled()) { log.debug("Received session id = " + sessionId); log.debug("Received vpath = " + vpath); log.debug("Received params = " + params); } try { //Getting the CSClient object from sessionId client = CSClientUtil.getCSClient((String)sessionId,params); 250
} catch (CSInvalidSessionStringException e1) { e1.printStackTrace(); } catch (CSFactoryInitializationException e1) { e1.printStackTrace(); } catch (CSExpiredSessionException e1) { e1.printStackTrace(); } catch (CSAuthenticationException e1) { e1.printStackTrace(); } catch (CSRemoteException e1) { e1.printStackTrace(); } catch (CSException e1) { e1.printStackTrace(); } if(client == null) { return new HashMap<String,String>(); } CSIterator iterator = null; try { iterator = client.getPrincipalManager().getAllTSUsers(); } catch (CSException e1) { e1.printStackTrace(); } if(log.isDebugEnabled()) { log.debug("Total number of users = " + iterator.getTotalSize()); } ArrayList userObjList = new ArrayList(); Map userNameList = Collections.synchronizedSortedMap(new TreeMap<String,String>()); while(iterator.hasNext()){ try{ Object userCs = iterator.next(); CSUser user=(CSUser)userCs; userObjList.add(user); if(user.getDisplayName() == null) { userNameList.put(user.getName(),user.getName()); } else { userNameList.put(user.getName(),user.getDisplayName()); } if(log.isDebugEnabled()) { 251
log.debug("User name =" + user.getName() + " display name = " + user.getDisplayName()); } }catch(Exception e) { e.printStackTrace(); } } if(params.get("Role") != null) { //Role is present, so try to get all users matching this role in the given vpath role = (String)params.get("Role"); if(log.isDebugEnabled()) { log.debug("Role received = " + role); } Map userWithSpecifiedRole = Collections.synchronizedMap(new TreeMap<String,String>()); for(int i=0;i<userObjList.size();i++) { try { CSUser user = (CSUser) userObjList.get(i); if(log.isDebugEnabled()) { log.debug("User name = " + user.getName()); } if(vpath != null) { //Vpath is present, so get all users who have this //role in this vpath CSVPath csvpath = new CSVPath((String)vpath); CSBranch branch = client.getBranch(csvpath,true); CSRole[] roles = user.getRoles(branch); for(int j=0;j<roles.length;j++) { if(log.isDebugEnabled()) { log.debug("Roles of this user = " + roles[j].getName()); } if(roles[j].getName().equalsIgnoreCase(role)) { if(!userWithSpecifiedRole.values(). contains(user.getName())) 252
{ if(user.getDisplayName() == null) { userWithSpecifiedRole.put (user.getName(),user.getName()); } else { userWithSpecifiedRole.put (user.getName(), user.getDisplayName()); } } } } } else { //As vpath is null, we cannot get roles for the //user. So, just return an empty array Map defaultUsers = new HashMap<String,String>(); defaultUsers.put("$IW_AREAOWNER","AREAOWNER"); defaultUsers.put("$IW_USER","CURRENT USER"); return defaultUsers; } } catch(Exception e) { e.printStackTrace(); //Just ignore and go to next iteration. } } return userWithSpecifiedRole; } else { //If no role is specified return all users //Add default users also userNameList.put("$IW_AREAOWNER","AREAOWNER"); userNameList.put("$IW_USER","CURRENT USER"); return userNameList; } } } // Code for the CSClientUtil.java, which is used in the MapUserPicker.java // file is as follows: 253
package com.interwoven.datasource.examples; import java.util.Locale; import java.util.Map; import java.util.Properties; import import import import import import import import import import com.interwoven.cssdk.access.CSAuthenticationException; com.interwoven.cssdk.access.CSExpiredSessionException; com.interwoven.cssdk.access.CSInvalidSessionStringException; com.interwoven.cssdk.common.CSClient; com.interwoven.cssdk.common.CSException; com.interwoven.cssdk.common.CSRemoteException; com.interwoven.cssdk.factory.CSFactory; com.interwoven.cssdk.factory.CSFactoryInitializationException; com.interwoven.log100.Logger; com.interwoven.log100.LoggerFactory;
/** * Utility class with a method to retrieve the CSClient object * from a session string corresponding to a user's session on the TeamSite * server. */ public class CSClientUtil { private static final Logger log = LoggerFactory.getLogger(CSClientUtil.class.getName()); public static final String SERVERNAME = "servername"; public static final String SERVICEBASEURL = "serviceBaseURL"; public static final String CSFACTORY = "csFactory"; public static final String LOCALE = "locale"; public static final String APPLICATION_CONTEXT = "appcontext"; /** * Retrieves the CSClient object for the given sessionString * @param sessionString * @param param should contain the following parameters as keys * servername * serviceBaseURL * csFactory * locale [Optional] * appcontext [Optional] * @return * @throws CSInvalidSessionStringException * @throws CSExpiredSessionException * @throws CSAuthenticationException 254
* @throws CSRemoteException * @throws CSException * @throws CSFactoryInitializationException */ public static CSClient getCSClient(String sessionString, Map param) throws CSInvalidSessionStringException, CSExpiredSessionException, CSAuthenticationException, CSRemoteException, CSException, CSFactoryInitializationException { if(log.isDebugEnabled()) { log.debug("session string :"+sessionString); log.debug("map is :"+param); } Locale locale = null; String serverName = null; CSFactory factory = null; String appcontext = null; //Read the properties from the Map and set it to the Properties object Properties props = new Properties(); //TeamSite server name serverName= (String)param.get(SERVERNAME); //Read Service base URL; it should be of the format // http://<servername>:<port> //or // https://<servername>:<port> props.setProperty(SERVICEBASEURL, (String)param.get(SERVICEBASEURL)); //Set the CSFactory object to be used //For example: com.interwoven.cssdk.factory.CSJavaFactory props.setProperty("com.interwoven.cssdk.factory.CSFactory", (String)param.get(CSFACTORY));
}else { locale=Locale.getDefault(); } if(param.get(APPLICATION_CONTEXT)!=null) { appcontext=(String)param.get(APPLICATION_CONTEXT); }else { appcontext= "workflowModeler"; } //Get the CSClient object return factory.getClient(sessionString,locale,appcontext,serverName); } }
2. Compile the file to create a .class file. 3. Create a .jar file using the .class file. The .jar file can have any name, for example, SampleDatasource.jar. 4. Register the Datasource by adding an entry for it in the Datasource configuration file (DataSourceConfig.xml). For more information, see Registering a Datasource on page 206. 5. Deploy the Datasource in TeamSite. For more information, see Deploying a Datasource on page 207.
256
Appendix D
Troubleshooting
This chapter provides troubleshooting information for the errors that you may encounter while working with the Workflow Modeler application. The following table lists some error messages and their possible cause and solution. Table 38 Error Messages
No. Error/Scenario Possible Cause and Solution
BrowserLaunchingInitiali The which command is unable to find the browser. zingException message is Ensure that: logged in the WorkflowModeler.log /usr/bin is always in the PATH. file. <browser executable> is present in at least one of the locations used by the which command to find the browser. In the Choose Shortcut Click Choose to select another location for the Folder screen, after shortcut. This action enables the Cancel, Previous, selecting a folder using the and Install buttons. Choose button, if you click Previous, then the Cancel, Previous, and Install buttons are disabled. Unable to find the bpmn.css file on the file system. Some of the functions may not work as expected. An exception occurred while creating the toolbar for tasks. Please check the log file for more information. The bpmn.css file, typically located in
installation_directory\resources\ilog\ views\bpmn, has been moved, renamed, or deleted.
Reinstall the Workflow Modeler application or copy the bpmn.css and bpmncore.css files from the Workflow Modeler installation CD. The activities.xml file, typically located in installation_directory\data\palettes, is corrupt. You can find more information in the
installation_directory\WorkflowModeler.log
257
Appendix D: Troubleshooting
An exception occurred while creating the toolbar for events, flows, gateways, and so on. Please check the log file for more information. An exception occurred while initializing the Workflow Modeler. Check the log file for more information.
file. Reinstall the Workflow Modeler application. The Workflow Modeler installation is incorrect or corrupt. You can find more information in the
installation_directory\WorkflowModeler.log
Unable to initialize the UI The Workflow Modeler application is trying to use appearance according to an appearance (look and feel) that is not supported the preferences. by the current system. Edit the PreferencesSettings.cfg file located in installation_directory\resources folder. The ProcessModeler_LookandFeel entry must have the following value:
ProcessModeler_LookandFeel=com.sun.java.swi ng.plaf.windows.WindowsLookAndFeel
The samples.properties file, typically located in installation_directory\resources\ directory, has been moved, renamed, or deleted. Reinstall the Workflow Modeler application or copy the samples.properties file from the Workflow Modeler installation CD. The workarea iwadmin/main/workflowModels/ WORKAREA/iw-wa/Models is missing from the TeamSite iwadmin store. Create the missing workarea in the iwadmin store. The Models directory does not exist on the TeamSite server. Create the missing directory: iwadmin/main/
workflowModels/WORKAREA/iw-wa/Models
Target directory does not exist on the TeamSite server. Parent directory does not exist on the TeamSite server. File update failed because the target directory is read-only.
10
11
For the current user, the iwadmin/main/ workflowModels/WORKAREA/iw-wa/Models directory is read-only on the TeamSite server. Provide write permission for the current user for this directory.
258
12
Unable to save the workflow model. Please view the log file for more information.
There can be several reasons for this error. Some common reasons are: User does not have write permission on the directory where the workflow model needs to be stored. The file may be in use by some other application. You can find detailed information in the
installation_directory\WorkflowModeler.log
file. If the problem is one of the two listed here: Assign appropriate permissions to save the file on the local file system. Close the file if it is in use by another application. 13 Unable to load the workflow model. User does not have appropriate permissions to retrieve models from the TeamSite server. Assign appropriate permissions on the TeamSite server for the current user. When the external tasks run, they are restricted to the permissions associated with the task owner. For the external tasks to run without impersonation (that is, to run as system account instead of the task owner), you have to set disable_ext_task_impersonation=true in iw.cfg file. For more information, see the knowledge base article, 60319. For more information on the cause of this error, see the knowledge base article, 61083. The resolution is as follows: Mark /iw-cc/urlexternaltask as Unprotected URL in SiteMinder. 16 Publish Workflow option not enabled after SiteMinder integration. For more information on the cause of this error, see the knowledge base article, 61083. The resolution is as follows: Create the following Realm in SiteMinder: Realm Name - Unprotected_wfm Realm Type - Unprotected Resource Filter - /iw/services/cm
14
15
259
Appendix D: Troubleshooting
17
Workflow Modeler cannot The Workflow Modeler application uses CSSDK connect to TeamSite after SOAP to connect to the TeamSite server. When a SiteMinder integration. Workflow Modeler user enters a username and password from Workflow Modeler client to log in, the SOAP request goes to the Web Daemon (iwwebd). As the http request does not contain a valid SMSESSION cookie, the SiteMinder web agents challenge/response mechanism intercepts the request and sends a challenge (prompts for username and password) back to the Workflow Modeler application which results in a SOAP exception. All SOAP requests are of the format of http:/ servername/iw/services/cm. If the URL /iw/ services/cm/ is marked as un-protected URL in the SiteMinder, then the initial login SOAP request is forwarded directly to the SOAP server which will authenticate the login parameters. If the Active Response Module is used, then: Instead of creating the following Realm: Realm Name - unprotected_iw Realm Type - Unprotected Resource Filter - /iw/services/cm/2.0/
accessservice
Create the following Realm: Realm Name - unprotected_iw Realm Type - Unprotected Resource Filter - /iw/services/cm If the Active Response Module is not used, then: Create the following Realm: Realm Name - unprotected_iw Realm Type - Unprotected Resource Filter - /iw/services/cm For more information on Active Response Module and Realms, see TeamSite documentation.
260
18
Make sure that Content Services (web services) is functioning on your TeamSite server, as the Workflow Modeler application relies on it for communication with TeamSite (to load, save, publish workflow models, and so on). Navigate to the following URL using your browser: http://
servername/iw/services/cm/2.0/ contentservices/WSDL. (Replace servername with
your TeamSite servers name). When functioning, the following response appears:
<wsdl:definitions targetNamespace="http:// content-services.org/services2.0.wsdl" <wsdl:import namespace="http:// content-services.org/access/ services2.0.wsdl" location="http:// localhost:6060/iw/services/cm/2.0/ contentservices/AccessService.wsdl" /> . <wsdl:import namespace="http:// content-services.org/commonservice/ services2.0.wsdl" location="http:// localhost:6060/iw/services/cm/2.0/ contentservices/common.wsdl" /> . <wsdl:import namespace="http:// content-services.org/filesys/ services2.0.wsdl" location="http:// localhost:6060/iw/services/cm/2.0/ contentservices/FileSys.wsdl" /> - <wsdl:service name="AccessServiceService"> - <wsdl:port name="AccessService" binding="access:AccessServiceBinding"> <wsdlsoap:address location="http:// localhost:6060/iw/services/cm/2.0/ contentservices/" /> </wsdl:port> </wsdl:service> . - <wsdl:service name="WorkflowServiceService"> - <wsdl:port name="WorkflowService" binding="workflow:WorkflowServiceBinding"> <wsdlsoap:address location="http:// localhost:80/iw/services/cm/2.0/ workflowservice" /> </wsdl:port> </wsdl:service> </wsdl:definitions>
If you do not get this response, check whether CSSDK SOAP Server service is started; if not, start this service.
261
Appendix D: Troubleshooting
19
TeamSite client EAR deployed onto an application server running on a port other than the default port, 8080.
If the TeamSite client EAR is deployed onto an application server that is running on a port other than the default port 8080, then change the servlet_port entry in the [teamsite_servlet_ui] section of the iw.cfg file so that it matches the ListenPort setting of the application server. The application server can be Apache Tomcat server, BEA WebLogic server, or IBM WebSphere server.
Interwoven\WorkflowModeler
1. Navigate to the folder where the log4j.properties file resides. 2. Open the log4j.properties file for editing. 3. Uncomment log4j.category.com.interwoven.modeler=DEBUG and remove the comma after DEBUG. The logger level is now set to DEBUG. The logger level enables you to have a greater control over the log output. These levels decide which log statement is logged in the log file and allow only those log requests that have a logger level equal to or greater than its own. This technique prevents log statements of lesser importance from being logged. You can set the logger levels to any one of the following (mentioned in the order of ascending priority):
DEBUG..
Specifies fine-grained informational events that are most useful to debug an application.
INFO. Specifies informational messages that highlight the progress of the application at a
coarse-grained level.
WARN. 262
ERROR. FATAL.
Specifies error events that might still allow the application to continue running. Specifies very severe error events that will presumably lead the application to
Depending on the logger level settings, the errors are now logged into the WorkflowModeler.log file. Use the WorkflowModeler.log file to debug any errors that occur in the Workflow Modeler application. Use the servletd_out.log file to debug any errors that occur in TeamSite. For example, to debug errors that you may encounter after a workflow is instantiated. To achieve this, see the log4j documentation to set your debugging level for your classes in the log4j.xml file that is located at iw-home/local/config/lib/content_center/
customer_src/etc/conf/ customer.
There maybe performance issues if you set the logger level to a lower priority, as it captures most of the events in the log file. For more information on log4j, see http:// logging.apache.org/log4j/1.2/manual.html.
263
Appendix D: Troubleshooting
264
Glossary
Configurable variable Enables you to create a workflow model that contains elements whose values do not need to be assigned until the workflow is customized or instantiated in TeamSite. Datasource framework Provides you an easy way to write your own Datasources that can extract data from within TeamSite or any external source. Datasource variable Enables you to retrieve data from any location, including-but not limited to-a database, TeamSite, a user-defined class, or a computer's file system. Job Specific instance of a workflow model. Job variable Key (variable name)/value pairs that are set at the job level for use by various tasks within a job. Pre-processor commands These commands are executed during the workflow instantiation (just before the instantiation screen is rendered). Use it to modify the properties of a workflow models task or attach an additional file to a workflow job for submission. Post-processor commands These commands are executed after the instantiation screen is rendered and before the workflow job is created. Use it to modify the properties of a workflow models task or remove a file attached to a workflow job. Script variable Enables you to write JavaScript for any task, transition link, or node property and have the value returned by the script determine the value assigned to that property.
265
Task Both a logical unit of work, when describing business processes, and an actual unit of work performed by a single user or process during the execution of a specific job.
Task variable Key (variable name)/value pairs that are set at the task level for use by a task. Workflow Encompasses the procedures, tasks, people, and rules that define business practices and processes within an organization. Workflow model General description of a recurring business process. Each workflow model describes a job consisting of a series of tasks, or units of work, and can be represented by a flow diagram, illustrating the series of tasks and the links (or transitions) between them.
266
Index
Symbols
$IW_USER 23, 53 .ipm file 56 .ipm files 20 .wft files 24 Author Submit with Deploy 127 Author Submit with Email 128 Author Submit with Metadata 129 author_submit_with_deploy.wft file 127 author_submit_with_email.wft file 126, 128, 134 author_submit_with_metadata.wft file 129 available_models.xml 24 structure 144 Available_Models1.0.xsd schema 243
A
accessing workflow model 145 active tasks 22 adding client-side validation 185 dynamic behavior 188 links to workflow model 58 new fields 185 tasks to workflow model 58 administering workflow model 24 alignment grid 44 Allow Editing option 44 AND node 40 AND operator 23 application setting configuring 45 application theme configuring 47 approval cycle workflow models 24 Archival Workflow 126 arranging all elements 39 links 39 selected elements 39 Assign option instantiating workflow 163 attributes defined 23 elements 23 variables 23
Workflow Modeler Users Guide
B
Boolean operators 39 branch workflowModels 141 business processes and tasks 41
C
CGI task 41 attributes 95 changing application theme 47 client-side validation 185 color-coded links 51 combining workflow model access 145 command instantiating workflows 157 workflow model access 146 Conditional link 40 Config folder workflowModels branch 142 Configurable Author Assignment 130 configurable author assignment workflow model 134 Configurable Author Submit 131 configurable author submit workflow model 134 Configurable Default Submit 132 configurable default submit workflow model 134
267
configurable_author_assignment.wft file 130 configurable_author_assignment_config.xml 135 configurable_author_submit.wft file 131, 133 configurable_author_submit_config.xml 135 configurable_default_submit.wft file 132 configurable_default_submit_config.xml 135 configuration file configurable_author_assignment_config.xml 135 configurable_author_submit_config.xml 135 configurable_default_submit_config.xml 135 workflow 135 configuring application settings 45 shortcut keys 48 workflow 137 Content tab 152 workflow validation prompt 46 converting workflow model 63 Create menu 41, 42 creating workflow model 224 custom workflow configuration selection order 154 custom_config.xml file 154 customize adding client-side validation 185 adding dynamic behavior 188 adding new fields 185 Email task 103 instantiation screen 178 property appearance 180 workflow models 24
instantiation screen 177 JavaScript 195 functionality 188 local location of workflow models 57 nodes in Tree pane 50 project name 49 workflow model name 56, 225 Default link 40 default_config.cfg file 143 Deploy task 42 designing workflow model 224 Display toolbar 43 displaying Properties pane 39 draft workflow model retrieving 61 Dummy task 42 duplicating elements 39
E
editing existing workflow models 59 elements adding to workflow models 57 assigning properties 23 duplicating 39 grouping 39 Properties pane 52 Tree pane 50 ungrouping 39 Email task 41 customizing 103 End Event node 40 error messages troubleshooting 257 Error pane illustrated 55 validation results 54 executable file Workflow Modeler 27
D
Datasource interfaces 203 out-of-the-box 201 sample 249 default file extension 56 installation folder 29
268
I
icon New 56 Open 59 Start Event 57 icon, workflow models 24 Inactive link 40 inactive tasks 22 installation file 27 installing default location 29 prerequisites Workflow Modeler
F
Failure link 40 file .ipm 20, 56 .wft 24 available_models.xml 24 configuration 20 installation 27 workflow configuration 20 workflow templates 24 WorkflowModler.exe 36 Fit to Contents tool 43
G
grid alignment 44 show or hide 44 spacing option 45 Grid Spacing option 45 group workflow model access 146 Group task 41 grouping elements 39 GUI elements illustrated 38 introduced 37
H
Hide/Show Overview option 52 Hide/Show Overview tool 43 Hide/Show Tree tool 43 hiding Properties pane 39 hiding and showing GUI panes 43
installing 27 startup shortcut icons 30 system requirements 27 Instance folder workflowModels branch 142 instantiating workflow 157 instantiating workflow Assign option 163 command line 172 commands 157 ContentCenter Professional 157 ContentCenter Standard 169 New Job 158 Submit 160 TeamSite Front Office 171 instantiation screen adding dynamic behavior 188 adding new fields 185 customize 178 property appearance 180 default 177 default JavaScript functionality 188 interfaces Datasource 203 Internal folder workflowModels branch 143 invoking login screen 46
269
J
JavaScript 195 functionality 188 jobs defined 22 job instance 22 job spec 25 job specification 22
L
lifecycle, of workflow models 19 link adding to Project pane 58 links arranging 39 color-coded 51 Conditional 40 Default 40 duplicating 39 Failure 40 icons illustrated 40 repeating 39 Success 40 Timeout 40 Links toolbar 39 local default location for workflow models 49 Lock task 42 Login dialog box 36 login option 45 Login to TeamSite option 45 Logout from TeamSite option 45 logout option 45
Options 44 View 44 Metadata task 41 model access combining 145 command 146 group 146 role 146 user 147 model element attributes 144 path separators 148 Model Properties node 50 Models folder workflowModels branch 143 modes Offline 36 Online (logged into TeamSite) 36 modifying application theme 47 applications settings 45 shortcut keys 48
N
Nested Workflow task 42 New icon 56 New Job instantiating workflow 158 nodes AND 40 duplicating 39 End Event 40 grouping 39 icons illustrated 40 introduced 23 Model Properties 50 NOT 40 OR 40 repeating 39 Start Event 40, 57 Text Annotation 40 ungrouping 39 Workflow Model 50
M
Make Selection Active tool 43 managing workflow 137 menus Create 41, 42
270
O
Offline mode 36 Online mode (logged into TeamSite) 36 Open icon 59 operators Boolean 39 optional elements 23 Options menu Allow Editing 44 Grid Spacing 45 introduced 44 Login to TeamSite 45 Logout from TeamSite 45 Sticky Actions 45 Validating Workflow 45 validating workflow models 44 OR node 40 OR operator 23 organizing all elements 39 selected elements 39 out-of-the-box Datasource 201 Overview pane illustrated 53 versus the Project pane 53
Priority property Properties Priority 53 Project pane adding link 58 adding tasks 58 displaying the alignment grid 44 grid 45 illustrated 49 Options menu setting 44 versus the Overview pane 53 properties assigning to elements 23 required 58 variables 23 Properties pane 52 hiding 39 showing 39 showing or hiding 52 property appearance customize 180 Publish LiveSite Content Workflow 132 Publish LiveSiteCS Content Workflow 133 published workflow model 140 published workflow model retrieving 61 publishing workflow model 60, 240
P
Pan tool 43, 54 panes Error 54 Overview 53 Project 53 Properties 52 Tree 49, 50 password, TeamSite 36 path separators model element 148 preference setting 45
R
regular expressions path separators 148 repeating elements 39 required elements 23 required properties 58 Reset link links Reset 40 Retrieval Workflow 134 retrieving workflow model 61
271
S
sample Datasource 249 saving workflow model 239 schemas validation against in Error pane 54 selection order custom workflow configuration 154 setting preference 45 shortcut keys setting 48 shortcuts for starting the Workflow Modeler 30 starting without 36 startup (illustrated) 35 showing Properties pane 39 showing and hiding GUI panes 43 solutions workflows author_submit_with_deploy.wft file 127 author_submit_with_email.wft file 126, 128, 134 author_submit_with_metadata.wft file 129 configurable author assignment 134 configurable author submit 134 configurable default submit 134 configurable_author_assignment.wft file 130 configurable_author_submit.wft file 131, 133 configurable_default_submit.wft file 132 Standard toolbar 38 Start Event node 40 starting the Workflow Modeler 35 states of tasks 22 Sticky Actions option 45 Submit instantiating workflow 160 Submit task 42 Subscription schema
272
T
task adding to Project pane 58 tasks active 22 adding from the Tasks toolbar 41 as business processes 41 as units of work 41 CGI 41 defined 21 Deploy 42 Dummy 42 duplicating 39 Email 41 External 41 Group 41 grouping 39 icons illustrated 41 inactive 22 Lock 42 Metadata 41 Nested Workflow 42 repeating 39 Review 41 states 22 Submit 42 ungrouping 39 Update 41 URL 42 User 41 Tasks toolbar 41 TeamSite 45 administering workflow models 24 branches and workflow models 24 logging into from Workflow Modeler 36 new features for workflow models 24 Option menu login option 45 Option menu logout option 45
password 36 tsadmin store 60 user name 36 Workflow Modeler compatibility 24 workflowModels branch 60 TeamSite branches 60 terminology, workflow 20 testing workflow model 241 Text Annotation node 40 Timeout link 40 toolbars Display 43 Links 39 Standard 38 Tasks 41 Tree pane default nodes 50 element list 50 illustrated 50 troubleshooting error messages 257 tsadmin store 60 tutorial Workflow Modeler 221
V
Validate Workflow option 45 Validate Workflow tool 44 validating workflow 39 validating workflow models from the Options menu 44 results in Error pane 54 variable $IWUSER 53 variables $IWUSER 23 introduced 23 View menu 44 viewing workflow models 165 viewing workflow models after instantiation 166 before instantiation 165 ContentCenter Professional 165 VisualAnnotate 136 extended attributes 136 introduced 136 VisualFormat 154
U
ungrouping elements 39 uninstalling default program location 32 icon on All Programs menu (illustrated) 35 Workflow Modeler 32 Update task 41 upgrading workflow model 63 URL task 42 user workflow model access 147 user name TeamSite 36 User task 41
W
workflow configuration files 135 configuring 137 managing 137 terminology 20 validating 39 VisualAnnotate 136 Workflow Model node 50 Workflow Modeler 24 creating workflow models 22 executable file 27 GUI elements 37 starting 35 TeamSite compatibility 24 uninstalling 32 workflow models 57 adding link 58
273
adding tasks 58 administering in TeamSite 24 approval 24 availability to branches 24 available_models.xml 24 configuring 151 creating (overview) 22 customizing 24 defined 21 differentiating from workflow templates 24 editing existing 59 example of (illustrated) 21 icon that identifies 24 instantiating 24 introduced 19 jobs 22 lifecycle 19 lifecycle (illustrated) 20 managing 24, 144 optional elements 23 published 140 publishing 24, 240 required elements 23 retrieving 61 saving 239 submitting in TeamSite 24 tasks 21 testing 241 upgrading 63 validating 54 workflow templates differentiating from workflow models 24 workflowModels branch content 141 workflowModels branch 60 Config folder 142 Instance folder 142 Internal folder 143 Models folder 143 WorkflowModler.exe file 36
Z
Zoom tools 43
274