WFM 71 User v01 en

Workflow Modeler Users Guide
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.
Trademarks and Copyrights

Copyright 2009 Autonomy Corporation plc and all its affiliates. All rights reserved. Interwoven, iManage, ConfirmSite, ContentServices, ControlHub, DataDeploy, DeskSite, FileSite, iManage, iManage Universal Search, iManage WorkSite, LiveSite, MediaBin, MetaCode, MetaTagger, OffSite, OpenDeploy, Primera, iManage RecordsManager, Scrittura, TeamPortal, TeamSite, VisualAnnotate, WorkDocs, WorkPortal, WorkRoute, WorkSite, WorkSite Express Search, WorkTeam, the respective taglines, logos and service marks are trademarks of Autonomy Corporation plc and its affiliates, which may be registered in certain jurisdictions. All other trademarks are owned by their respective owners. Some or all of the information contained herein may be protected by patent numbers: US # 6,505,212, GBRI # 1053523, US # 6,480,944, US# 5,845,270, US #5,430,812, US #5,754,704, US #5,347,600, AUS #735365, AU 7830068, GB #GB2333619, US #5,845,067, US #6,675,299, US #5,835,037, AUS #632333, CAN #2,062,965, FRAN / GRBI / SPAI / SWED #480941, GERM #69020564.3, KORS 10-0576487, JAPA #2968582, MX #219522, NZ #516340, SING #109524, SG #89006, SG #89086, SG #74973, SG #85502 US #5,065,447, US #6,609,184, US #6,141,017, US #5,990,950, US #5,821,999, US #5,805,217, US #5,838,832, US #5,867,221, US #5,923,376, US #6,434,273, US #5,867,603, US #4,941,193, US #5,822,721, US #5,923,785, US #5,982,938, US #5,790,131, US #5,721,543, US #5,982,441, US #5,857,036, US #6,697,532, US #6,792, 454, US #6,928,149, US #7,092,969 or other patents pending application for Autonomy Corporation plc and its affiliates. All other trademarks are the property of their respective owners.
Notice to Government End Users

If this product is acquired under the terms of a DoD contract: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of 252.227-7013. Civilian agency contract: Use, reproduction or disclosure is subject to 52.227-19 (a) through (d) and restrictions set forth in the accompanying end user agreement. Unpublished-rights reserved under the copyright laws of the United States. Autonomy, Inc., One Market Plaza, Spear Tower, Suite 1900, San Francisco, CA. 94105, US.
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
About This Book

Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manual Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . New or Changed Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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:
Installing Workflow Modeler
27
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Installing Workflow Modeler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Uninstalling Workflow Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 3:
Using Workflow Modeler

Starting Workflow Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow Modeler GUI Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Links Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Display Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Application Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tree Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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:
Working with Element Attributes
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
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:
Predefined Workflow Models

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publish LiveSiteCS Content Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retrieval Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configurable Workflow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow-Specific Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WorkflowName_config.xml File Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . configurable_author_submit_config.xml. . . . . . . . . . . . . . . . . . . . . . . . . . . configurable_default_submit_config.xml . . . . . . . . . . . . . . . . . . . . . . . . . . configurable_author_assignment_config.xml . . . . . . . . . . . . . . . . . . . . . . . VisualAnnotate and Configurable Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . .
125
126 127 128 129 130 131 132 132 133 134 134 135 135 135 135 135 136
Chapter 6:
Managing and Configuring Workflow Models

Understanding Workflow Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WorkflowUser Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WorkflowAdmin Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations Summary for Workflow Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . Published Workflow Models in TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WorkflowModels Branch Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . .
144 144 145 149 150 150 151 152 154
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:
Customizing the Instantiation Screen

Why Customize the Instantiation Screen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Which Workflow Fields can be in a Custom Instantiation Screen? . . . . . . . . . . . . How to Customize the Instantiation Screen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Default Instantiation Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customizing the Default Instantiation Screen . . . . . . . . . . . . . . . . . . . . . . . . . Making the Custom Instantiation Screen Available . . . . . . . . . . . . . . . . . . . . . Changing Default Property Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Client-Side Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding New Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Dynamic Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default JavaScript Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the Custom Configuration File Manually. . . . . . . . . . . . . . . . . . . . . .
175
175 176 177 177 178 179 180 185 185 188 188 199
Chapter 9:
Using Datasource Framework

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Out-of-the-Box Datasources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Datasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing Datasource Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SimpleDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ArrayDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arguments for SimpleDataSource and ArrayDataSource . . . . . . . . . . . . . . ListDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MapDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SortedValuesMapDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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:
Using Custom Code

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Custom Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing the InProcessJavaCommand Interface . . . . . . . . . . . . . . . . . . . . Additional Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying Custom Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
215
215 216 217 218 218 219 220
Appendix A: Workflow Modeler Tutorial

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tutorial Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a New Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variables Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Workflow Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dummy Task (Dummy Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata Capture (Metadata Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Submit (Submit Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploy Task (Deploy Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notify Deploy (Email Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Link Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create Metadata (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . No Metadata (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Submit After Timeout (Timeout Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . No Deploy (Conditional Link). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploy Content (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notify (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resolve Problems (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Appendix B: Workflow Schemas
243
Available_Models1.0.xsd (Subscription schema) . . . . . . . . . . . . . . . . . . . . . . . . . 243 DataSourceConfig.xsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Appendix C: Datasource Example Appendix D: Troubleshooting Glossary Index
249 257 265 267
Debugging with WorkflowModeler.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
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
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 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
About This Book

Workflow Modeler Users Guide describes how to install Interwoven Workflow Modeler, how to use Workflow Modeler, and how to troubleshoot Workflow Modeler problems.
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
About This Book
Table 1
Notation Conventions
Definition and Usage
Convention
Monospaced italic
Monospaced italics are used for command-line variables.For example:

iwckrole role user
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
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
About This Book
New or Changed Information

Workflow Modeler Users Guide includes the following key changes: The look and feel of the installer screens have changed (see Chapter 2, Installing Workflow Modeler). The CSLocalFactory object has been deprecated. The Datasource code must not have any references to CSLocalFactory (see Chapter 9, Using Datasource Framework). The out-of-the-box workflows now include the archival workflows, Publish LiveSite Content workflow, and Publish LiveSiteCS workflow (see Chapter 5, Predefined Workflow Models). New commands have been added to invoke the archival workflows (see Chapter 5, Predefined Workflow Models). Additions and corrections to this document (when available) can be downloaded in the PDF format from the following web site: https://customers.autonomy.com.
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
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 Workflow Models with Workflow Modeler

You have likely seen or created flowcharts like the graphic on page 21 to represent a business model or process in your organization. These graphic representations are typically created using word processor programs, general graphics programs, or specialized flowchart programs. The Workflow Modeler incorporates many of the same easy-to-use drawing tools included in these programs, and adds sophisticated workflow rules that are automated and enforced by the TeamSite workflow engine. The result is that workflow models are easy to create and implement for workflow model developers, and easy to understand and respond to for TeamSite administrators and end-users.
22
Creating Workflow Models with Workflow Modeler
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.
Assigning Element Properties

Workflow elements must be assigned properties. Properties include: Attributes. Changeable characteristics that can be set to different values that describe or define an element. Different task types have different possible attributes. Some attributes are mandatory and some are optional. For example, in a Review task, the associated file could be assigned a read only attribute to ensure the contents are not altered by a reviewer. Variables. Attributes that are subject to change. For example, a person who is the owner of a task is defined later when the job is run. When the workflow model is created, the $IW_USER variable is used to represent the user who is assigned the task, until the variable substitution can be made at runtime. Attributes and variables are described in detail in Assigning Common Task Attributes on page 79.
23
Publishing Workflow Models

Completed workflow models can be published to a TeamSite server from the Workflow Modeler, provided the user has appropriate permissions in TeamSite. For detailed information, see Publishing Workflow Models to TeamSite on page 60.
TeamSite and Workflow Models

The Workflow Modeler is included with TeamSite 6.7.1 (and later versions) and cannot be used with earlier TeamSite versions. The following TeamSite features have been added or modified to accommodate the Workflow Modeler: Admin store (iwadmin) Default workflowModels branch under //TS_Server/iwadmin/main Workflow model icon ( ) that differentiates workflow models from workflow templates (.wft) when they are displayed together (for example, in the New Job window or the Workflow tab) In general, the activities associated with administering and using workflow models in TeamSite are as follows: Workflow model approval cycle. Workflow models are actually content stored in TeamSite. Therefore, they may be subject to an approval process like any other content that is managed in TeamSite. Managing workflows. The available_models.xml file controls which workflow models are available to each branch. Workflows can be subscribed to from the Manage Workflows link on the Admin tab in ContentCenter Professional. Customize workflows. For different branches or folders, workflow models which contain variables can be configured to behave differently depending on the branches or folders within which the workflow is instantiated. Instantiate workflows. Instantiation of a workflow is the creation of an instance (job) of an abstraction (the workflow model). Workflows can be instantiated by clicking the following buttons or links anywhere they appear in TeamSite: New Job Submit Assign In addition, workflows can be instantiated in TeamSite using the following commands:
24
TeamSite and Workflow Models
tfo_workflow tt_data
(new job, in TeamSite FrontOffice)
(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
26
Chapter 2

This chapter contains the following sections: System Requirements Installing Workflow Modeler Uninstalling Workflow Modeler
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

After ensuring that you have satisfied the system requirements, complete the following procedure to install Workflow Modeler on your system.
NOTE
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
Chapter 2: Installing Workflow Modeler
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
Choose Shortcut Folder Screen
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
Installation Shortcut Location Options

Shortcut Location
In a new Program Group In an existing Program Group
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.
In the Start Menu On the Desktop
30
Table 2
Option
Installation Shortcut Location Options (Continued)

Shortcut Location
In the Quick Launch Bar
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
Dont create icons
The Install Complete screen appears. Figure 7 Install Complete Screen
3. Click Done to complete the installation and exit the installer.
31
Proceed to Chapter 3, Using Workflow Modeler for information about starting and using the Workflow Modeler.
Uninstalling Workflow Modeler

When you install the Workflow Modeler, an uninstallation program called WorkflowModeler.bat is installed on your system. In Windows, if you selected the default installation folder, the uninstallation program is installed at: C:\Interwoven\iwinstall\products\WorkflowModeler\UninstallerData. To uninstall the Workflow Modeler: 1. Run the WorkflowModeler.bat file. The Introduction screen appears. Figure 8 Introduction Screen
2. Click Next to remove the Workflow Modeler program files (files created using Workflow Modeler are not removed). The Uninstall Complete screen appears.
32
Uninstalling Workflow Modeler
Figure 9
Uninstall Complete Screen
3. Click Done to complete the uninstallation procedure.
33
34
Chapter 3
Using Workflow Modeler

This chapter contains the following sections: Starting Workflow Modeler Workflow Modeler GUI Elements 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
Starting Workflow Modeler

To start Workflow Modeler: 1. In Windows, double-click the shortcut placed on your system by the Workflow Modeler installation program. Depending on your response to the installation prompt (step 7 on page 30), the shortcut ( ) can be located in one of the following locations: In a user-specified Program Group on the Start menu. On the Start Menu. On the Desktop. On the Quick Launch bar. You could also have specified that no shortcut be created during installation. In this case, you must start Workflow Modeler by running WorkflowModler.exe from the installation folder you specified in step 6 on page 29.
35
Chapter 3: Using Workflow Modeler
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
Server. The name of the TeamSite server.
Workflow Modeler GUI Elements
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.

The following graphic shows the major areas of Workflow Modeler that are displayed after the first startup (there is also an Error pane that is not displayed by default; it is described in Errors Pane on page 54).There are a number of ways you can modify which panes and toolbars are displayed to customize the look of Workflow Modeler.
37
Figure 11 Workflow Modeler User Interface (UI)

Standard toolbar Tree pane Tasks toolbar Links toolbar
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
The key operations are introduced in the following table. Table 3

Icon
Standard Toolbar
Name Description
Duplicate Selection Group Selection
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.
Ungroup Selection Layout All Nodes
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
Reset Link Inactivate Link Timeout Link
Success Link Failure Link Conditional Link
AND Gateway OR Gateway NOT Gateway Text Annotation
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
User Task Review Task
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
External Task CGI Task Metadata Task Update 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
Tasks Toolbar (Continued)

Name Description
Submit Task Deploy Task
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.
Fit to Contents* Pan
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
The Options Menu

Description
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
The Options Menu (Continued)

Description
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
Login to Server Logout from Server Preference
Configuring Application Settings

You can configure the application settings using the Preference dialog box. To display the dialog box, select Options > Preference.
45
Figure 13 Preference Dialog Box
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
Figure 14 Preference Dialog Box - General Node
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
In the offline mode, the first two options are disabled.
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
You can set the theme to Windows (default), CDE/Motif, or Metal.
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
In the offline mode, the Shortcut Keys option is disabled.
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
Figure 18 Tree Pane
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
Figure 21 Errors Pane
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.
Creating a New Workflow Model

To create a new workflow model: 1. Start the Workflow Modeler and log in as described on page 35. A workflow model labeled Unnamed (#) (where # is the total number of workflow models you have created) is displayed by default. 2. Select File > Save As.
NOTE
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
Creating a New Workflow Model
Figure 23 Project Pane Title Bar
By default, workflow models are saved to:

C:\Documents and Settings\user_name\My Documents
on the local system if you are
working in the offline mode.

workflowModels/WORKAREA/iw-wa/Models
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
Figure 24 Workflow Model Properties
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
Editing an Existing Workflow Model
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
Save, or select File > Save to save the project.
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.
Editing an Existing Workflow Model

To edit an existing workflow model: 1. Start the Workflow Modeler, and log in as described on page 35. A workflow model labeled Unnamed (#) is displayed by default. You can either close it or leave it open. 2. Select File > Open, or click Open Workflow Model.
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
on the local system if you are
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.
Publishing Workflow Models to TeamSite

After completing a workflow model you can publish it to the TeamSite server, if your role has the required permissions in TeamSite. Note that workflow models can be treated like any other content that you manage in TeamSite. Therefore, they may also be subject to a workflow model where, for example, they are subject to an approval process before they can be made available for subscription. When you publish a workflow model, it is submitted to a branch called workflowModels in the iwadmin store:
//TS_Server/iwadmin/main/workflowModels/STAGING/Models
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
Retrieving Workflow Models from TeamSite
Figure 25 Login Dialog Box
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.
Retrieving Workflow Models from TeamSite

Using Workflow Modeler, you can retrieve workflow models from TeamSite. This feature is useful if you want to update your draft workflow model (located in the iw-wa workarea of
61
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
and is by default stored (for Windows) in

C:\Program Files\Interwoven\WorkflowModeler\data\examples\drafts.
However, if you select the Published state, the workflow model is retrieved from //
TS_Server/iwadmin/main/workflowModels/STAGING/Models
and is by default stored (for Windows) in

C:\Program Files\Interwoven\WorkflowModeler\data\examples\published.
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
Upgrading to the Latest Workflow Schema
Upgrading to the Latest Workflow Schema

When you open a workflow model developed using an older version of Workflow Modeler, you will be prompted to convert the workflow model to the latest version of the workflow schema. If you click Yes, the workflow model is converted to the latest version. Any new workflow element that you add to the converted workflow model conforms to the latest workflow schema. However, the existing workflow elements do not conform automatically. You can identify and resolve the non-conformance by validating the workflow model and fixing the errors listed in the Error pane. If you click No, the workflow model is not converted to the latest version, and any new workflow element that you add to this workflow model continue to conform to the old version. Alternatively, you can upgrade your workflow models to the latest workflow schema by selecting Create > Convert Workflow.
NOTE
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
Working with Element Attributes

Workflow elementstasks, transition links, and nodesall have special attributes that you must configure when you create a workflow model or job. Attributes (also known as properties) are changeable characteristics of a workflow element that can be set to different values. Each workflow element has a different set of possible attributes. Some attributes are required, some are optional, and some can be set using variables. Variables are values that change depending on unknown conditions or information determined when a job is instantiated, or after a workflow is in process. If attributes are set using variables, the workflow model can be considered a form or template that must be completed when invoked through the New Job menu item or the Submit button in TeamSite. If user variables are not used to set attributes, the workflow model describes a specific job. This chapter includes the following sections: Workflow Modeler Variables Assigning Common Task Attributes Assigning Workflow-Specific Attributes Assigning Task-Specific Attributes Assigning Common Link Attributes Assigning Link-Specific Attributes Working with Logical Nodes
Workflow Modeler Variables

The Workflow Modeler includes new variables in addition to the TeamSite System and Macro variables already supported by the TeamSite workflow engine. The new variables are: Configurable variable (see Configurable Variables ($IW_CV) on page 66)
65
Chapter 4: Working with Element Attributes
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)
Configurable Variables ($IW_CV)

The $IW_CV 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. Any property, except Name and coordinates (X, Y), of a task, transition link, or node can be exposed as a Configurable variable. 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.
NOTE
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
Figure 27 Configurable Variable Dialog Box
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.
Datasource Variables ($IW_DS)

TeamSite now includes a framework called Datasource framework. It enables you to write Java classes that implement a specific predefined interface. These classes can retrieve data from any location, includingbut not limited toa database, TeamSite, a user-defined class, or a computers file system. This data is stored in the $IW_DS Datasource variable. For more information on the Datasource framework, see Chapter 9, Using Datasource Framework. Before creating Datasource variables, the Java classes must be registered with TeamSite. The Datasource is available to workflow model developers the next time they log in to TeamSite from within the Workflow Modeler. The value returned by the Datasource can be used to set the value for any property of a task, workflow model, transition link, or node. For example, if you define UserPicker as a Datasource variable, you need to specify the name of the Datasource it uses and select one of the values returned by that Datasource as the default value.
NOTE
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
Figure 29 Datasource Variable Dialog Box
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.
Script Variables ($IW_SCRIPT)

Script variables are defined in a script editor located on the Source tab of the SCRIPT dialog box. You can display the dialog box by clicking next to a property in the Workflow Modeler Property pane.
NOTE
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
Figure 31 Script Variable Dialog Box
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
if("$IW_CV(notify)" == "true") { "iwmetadataWithEmail.cgi"; } else { "iwmetadata.cgi"; }
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:
if("$IW_WFNAME" == "MyWorkflow") { return "$IW_WFNAME"; } else { false; }
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
return("Have a nice day!") } myFunction();
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.
TeamSite System Variables

You can use the following list of TeamSite System variables in any Workflow Modeler task, transition link, or node property or in conjunction with other Script variable scripts. Table 8 TeamSite System Variables
Description
Variable Name
$IW_HOME
TeamSite installation directory
73
Table 8
TeamSite System Variables (Continued)

Description
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
generate an error, if the

default_protocol attribute is set to https. In this case, irrespective of having the term http explicitly in the URL, the $IW_PORT value is set to https_port attributes value. $IW_PROTOCOL
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
TeamSite System Variables (Continued)

Description
Variable Name
$IW_WFNAME
Current workflows name icon.
System variables are identified by the
TeamSite Macro Variables

You can use the following list of TeamSite Macro variables in any Workflow Modeler task, transition link, or node property. These variables are of the form %name, and are expanded before being set as an extended attribute. They are identified by the icon. Table 9 TeamSite Macro Variables
Description
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
Macro variables are available to EA Finish Op and EA Start Op only.
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
Table 10 Variable Comparison (Continued)

Type Description Resolution Stage Use Case Value Assignment
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
Assigning Common Task Attributes

This section describes the attributes that you can assign in the Properties pane of each task type. It begins with a section about the attributes that are common to most tasks, then describes the remaining attributes for each task type. You can assign the following attributes for most Workflow Modeler tasks (exceptions are noted where appropriate): Area VPath Brief Description Description Name Owner Lock Read Only Transfer Only Variables EA Finish Op EA Start Op WF Variables Finish Op WF Variables Start Op X Y ID
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.
workarea associated with the task, for
79
CONFIGURABLE. DATASOURCE. SCRIPT.
See Configurable Variables ($IW_CV) on page 66.
See Datasource Variables ($IW_DS) on page 68.
See Script Variables ($IW_SCRIPT) on page 70.
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:
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:
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:
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:
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:
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:
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:
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
Figure 37 WF Variables Finish Op Dialog Box
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:
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:
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:
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
Assigning Workflow-Specific Attributes

In addition to some of the common attributes (described in the beginning on page 65), you can assign the following attributes for a workflow model: Table 11 Workflow-specific Attributes
Property Description
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
Table 11 Workflow-specific Attributes (Continued)

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 an in-process command, the syntax is as follows:

inprocess:<fully-qualified-classname>:[additional parameter]
For example:
inprocess:com.interwoven.processtest.CustomCodeDemo:role=author
For an out-of-process command, the syntax is as follows:

<path to the program that can execute your custom code> <path to your custom code (executable/script)>
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:
Assigning Task-Specific Attributes

The following sections list tasks that have properties that are unique to them or are shared between only a few task types: CGI Task Attributes Deploy Task Attributes Email Task Attributes External Task Attributes
94
Group Task Attributes Metadata Task Attributes Nested Workflow Attributes Review Task Attributes Submit Task Attributes Update Task Attributes URL Task Attributes
CGI Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for CGI tasks: Table 12 CGI task Attributes
CGI Script Name
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:
95
Deploy Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Deploy tasks: Table 13 Deploy Task Attributes
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
Table 13 Deploy Task Attributes (Continued)

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

Figure 44 OD Variables Dialog Box
100
Email Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Email tasks: Table 14 Email Task Attributes
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
Table 14 Email Task Attributes (Continued)

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
Table 14 Email Task Attributes (Continued)

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.
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.
Creating a Custom Email Task

You can customize email messages with rich formatting (layout control, fonts, colors, graphics), instead of using plain text messages. The customization may be simple (for example, adding the
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.
Using the Customized Email Template

To use the created template with the Email task: 1. Create a custom java class. Follow step 1 and step 2 mentioned in Creating a Custom Email Task on page 103. While creating the class, make sure that you specify the location of the newly created XSL template within the class, by either: Hard coding it, or Dynamically specifying it 2. Follow the steps 3 to 7 mentioned in Creating a Custom Email Task on page 103.
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="/">  <header1> <name>ReplyTo</name> <value>abc@interwoven.com</value> </header1>  <header2> <name>Subject</name> <xsl:value-of select="//Job/CurrentTask/@Description"/> </header2>  </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
External Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for External tasks: Table 15 External Task Attributes
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
For an External task example, see TeamSite Workflow Developers Guide.
111
Group Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Group tasks: Table 16 Group Task Attributes
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:
112
Metadata Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Metadata tasks: Table 17 Metadata Task Attributes
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
Nested Workflow Attributes

A nested workflow is a workflow that is contained within a job. It is initiated by one of the tasks of the job. The implementation of a nested workflow is similar to External and CGI tasks, where the activation of tasks is either automatically or manually instantiated, causing an association of a new job with the workflow task. The nesting process creates a parent/child relationship with the task as the parent and the job as the child. The relationship between a workflow task and its nested workflow includes: The ability to pass variables and file lists from the parent task to the child job. The ability for nested jobs to pass some or all variables and file lists to the parent job upon the child jobs completion.
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
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.
Review Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Review tasks: Table 19 Review Task Attributes
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
Table 19 Review Task Attributes (Continued)

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
Table 19 Review Task Attributes (Continued)

Return On First Reject
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:
Submit Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Submit tasks: Table 20 Submit Task Attributes
Submit Comment Submit Info Override
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
Table 20 Submit Task Attributes (Continued)

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).
Skip Conflicts Skip Locked Unlock
Update Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Update tasks: Table 21 Update Task Attributes
Source Area V Path
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
CONFIGURABLE.

117
DATASOURCE. SCRIPT.
URL Task Attributes

In addition to the common attributes (described on page 79), you can assign the following task-specific attribute for URL tasks: Table 22 URL Task Attributes
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.
Assigning Common Link Attributes

Like tasks, links also have common and link-specific attributes associated with them in the Workflow Modeler Property pane. The common properties are described in this section and the link-specific properties in the next section. All links have the following three properties in common: Name Type ID These properties are described in the following sections.
118
Assigning Common Link Attributes
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
Assigning Link-Specific Attributes

The following links have link-specific attributes that you can set in the Properties pane: Timeout Links Conditional Links
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
A Timeout link should not precede an End event node.
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
Assigning Link-Specific Attributes
Figure 48 Timeout Duration Dialog Box
3. Optionally, you can select one of the following variables to represent the timeout duration from the unlabeled drop-down list:
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.
CONFIGURABLE. DATASOURCE. SCRIPT. True.
The workflow continues over this link if the condition of the current task evaluates to True.
Working with Logical Nodes

Workflow Modeler includes three logical nodes that enable links to be qualified with the logical gates AND, OR, or NOT. These nodes specify the conditions under which a task becomes active.
AND. 122
All tasks linked to this node must be completed to activate a successor task.
Working with Logical Nodes
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
Logical Node Attributes

Similar to tasks and links, logical nodes also have the following attributes that you can assign in the Properties pane: GatewayType Name X Y ID
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
Predefined Workflow Models

This chapter describes the sample workflow models shipped with the product. These sample workflow models are located at the following location:
An editable version is also stored in the following workarea:

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
Chapter 5: Predefined Workflow Models
Publish LiveSiteCS Content Workflow Retrieval Workflow
Archival Workflow
Figure 50 illustrates the archival workflow. Figure 50 Diagram of the Archival Workflow
1. Start archival of the Edition.

Start
Archive Edition success failure
2. Email notification of the success or failure to archive the Edition to DigitalSafe is sent to users of your choice.
Email notification of the successful archival of the Edition.
Email notification of the failure to archive the Edition.
End
126
Author Submit with Deploy

Figure 51 illustrates an author submit combined with a deployment. Figure 51 Diagram of the Author Submit with Deploy Solution Workflow 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. When the job is initiated, an email notification is sent to an approver.
Approve iw_areaowner
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
failure Deploy retry End Resolve Deployment Problem
Author Submit with Email

Figure 52 illustrates an author submit combined with an email. Figure 52 Diagram of the Author Submit with Email Solution Workflow 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. When the job is initiated, an email notification is sent to an approver. 3. Author submits modified files. The files are sent to the approver, who is defined as the owner of the workarea to which the files are submitted. 4. 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 Author Rework on that task). When resubmitted, another email is sent to the approver). 5. When approved, the files are submitted to the staging area.
Author Finish
Author Work
Email to Approver
reject
Approve iw_areaowner approve
Submit iw_areaowner
End
128
Author Submit with Metadata

Figure 53 illustrates an author submit with metadata capture. Figure 53 Diagram of the Author Submit with Metadata Solution Workflow
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
Metadata Capture iw_user
reject
Approve iw_areaowner approve
Submit iw_areaowner
End
Configurable Author Assignment

Figure 54 illustrates a configurable author assignment. Figure 54 Diagram of the Configurable Author Assignment Solution Workflow
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.
(optional) Add Files to Job
(optional) Email to Author
Author Work
(optional) Metadata Capture
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
Configurable Author Submit

Figure 55 illustrates a configurable author submit. Figure 55 Diagram of the Configurable Author Submit Solution Workflow
Submit
(optional) Add Files to Job (optional) Email to Author
Author Work
reject
(optional) Metadata Capture iw_user
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
Configurable Default Submit

Figure 56 illustrates a configurable default submit. Figure 56 Diagram of the Configurable Default Submit Solution Workflow 1. A userwhose work does not need reviewsubmits a file. 2. (Optional) Content is processed for metadata capture (either in the TeamSite Tagger GUI or through MetaTagger integration), then submitted to the staging area. 3. (Optional) The file is deployed to the specified location (email is sent to the initiator if there is a deployment problem).
Submit
(optional) Metadata Capture iw_user
Submit iw_user failure (optional) Deploy retry
(optional) Email Notification of Deployment Problem
Resolve Deployment Problem iw_areaowner
End
cancel job
Publish LiveSite Content Workflow

For more information on the Publish LiveSite Content workflow, see the Default SitePublisher Workflows chapter in the TeamSite SitePublisher Users Guide.
132
Publish LiveSiteCS Content Workflow

Figure 57 illustrates a Publish LiveSiteCS Content Workflow. Figure 57 Diagram of the Publish LiveSiteCS Content Workflow
Initiates workflow
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.
Development (optional) Submit (optional) STAGING Deploy LSCS Development Server
Production Submit
STAGING Deploy LSCS Production Server
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.
Create/Overwrite a Workarea success failure
Edition Retrieval failure
Email notification of the failure
Email notification of the success
End
Configurable Workflow Overview

The following three solutions workflows are activated by default and are configurable:
configurable_author_assignment.ipm configurable_author_submit.ipm configurable_default_submit.ipm
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
Workflow-Specific Configuration Files
called configurable_author_submit_config.xml. This configuration file is described in Workflow-Specific Configuration Files on page 135.
Workflow-Specific Configuration Files

This section introduces the workflow-specific configuration files used by the workflows in the / /TS_Server/iwadmin/main/workflowModels/STAGING/Models folder.
WorkflowName_config.xml File Overview

Each WorkflowName_config.xml file contains entries for a number of optional features. The configuration of a feature (for example, email notification) is identical in each workflow where it is included. The following list contains the configurable features that are available in each of the WorkflowName_config.xml files.
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
Metadata Capture Review
VisualAnnotate and Configurable Workflows

VisualAnnotate is a review tool that is installed by the TeamSite installation program. It enables users to annotate HTML pages from within their browser window. Reviewers can draw, change text, and add sticky notes directly on the pages they are viewing. These annotations are stored separately from the file as extended attributes. VisualAnnotate reviews are implemented within the following solution workflows:
Configurable_Author_Submit Configurable_Author_Assignment
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
Managing and Configuring Workflow Models

This chapter primarily describes the procedures for managing and configuring workflow models after they are published to the TeamSite server from Workflow Modeler. It includes the following sections: Understanding Workflow Roles Published Workflow Models in TeamSite Subscribing Workflow Models Configuring Workflow Models
Understanding Workflow Roles

The ability to publish, manage, and configure workflow models is subject to the role defined in TeamSite. To maintain existing privileges given to TeamSite users and to ensure that Workflow Modeler functions properly, the following out-of-the-box roles are available in TeamSite: WorkflowUser Role WorkflowAdmin Role Various operations that are permitted for each of these roles can be customized by the administrator using the unified administration interfaces User Management tab. For more information, see the User Roles section in the User Management chapter of the unified administration interface guide.
137
Chapter 6: Managing and Configuring Workflow Models
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
Understanding Workflow Roles
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
Operations Summary for Workflow Roles

The following table provides a summary of operations allowed for the WorkflowAdmin and WorkflowUser roles. Table 23 Operations Summary for Workflow Roles
Role
WorkflowAdmin WorkflowUser
Publish Workflow
Manage Workflow
Configure Workflow
Web View Workflow
Execute/Run Workflow
Yes No
Yes No
Yes No
Yes Yes
Yes Yes
Published Workflow Models in TeamSite

When you publish a workflow model from the Workflow Modeler, it is published to the Staging area on a branch called workflowModels in the iwadmin store:
(shown in )
An editable version is also stored in the following Workarea:

140
Figure 59 workflowModels Branch
WorkflowModels Branch Contents

The Content tab of the workflowModels branch contains a folder structure that stores the files used by TeamSite to implement and configure workflow models. The structure is shown in the graphic, which is followed by the structure description.
141
Figure 60 Content Tab of WorkflowModels Branch
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
Figure 61 Workflow Model Icon
Workflow model icon Internal.
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
Subscribing Workflow Models

The available_models.xml file controls which workflow models are available to each branch. It is an XML configuration file that lists all of the workflow models that are available for use on the TeamSite server. For each workflow model, this file indicates the name of the workflow model, branch(es) for which the workflow model can be instantiated, and the conditions under which the workflow model is available.
NOTE
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.
The available_models.xml File

This section provides detailed information on various elements of the available_models.xml file. The container element in the available_models.xml file is the available_models element. This element contains the following:
require_workarea
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>
The model element has the following attributes:

debug. Specify whether the workflow model is in the debug (true) or production (false) mode. If debug is set to true, a radio button appears in the job instantiation screen, which enables you to select the mode. If debug is selected, the workflow job
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.
Specify the title of the workflow model, for example:
name="Author Submit Workflow"
This value is used as the display name for the workflow model. The name specified here must be unique.
Specifying Workflow Model Access

You can configure access to each workflow model listed in the available_models.xml file by using any combination of the following categories: command role group user branch-vpath vpath-regex You can combine categories using boolean terms such as AND, OR, and NOT to include and exclude those that meet the inclusion or exclusion criteria. Workflow model access is configured within the allowed element, which is a sub-element of
model.
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
(archiving Edition to DigitalSafe) an archived Edition from DigitalSafe)
retrieve_job(retrieving submit assign
(submitting files) (assign button or menu item) (new job) (new job, in TeamSite FrontOffice)
new_job
(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"/>
specifies that if the user is logged in as an 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
<allowed> <and> <vpath-regex regex="/default/main/administrator_1/.*"/> </and> ... </allowed>
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/...
In the next example:

<vpath-regex="^/default/main/foo"/>
any branch path that begins with the value-string will be matched. Here the following example matches:
/default/main/food/...
while this one does not:

/default/main/barfoo/...
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
Combining Access Categories

Pairings of individual or multiple access elements can be included or excluded using the and, or, and not elements within the allowed element. You can use boolean logic to create combinations of categories that can either have access to a specific workflow model, or be excluded from it. In the following example:
<model filename="Author_Submit" debug="true" active="true" name="Author Submit Workflow"> <allowed> <and> <command name="submit"/> <or> <role name="author"/> <role name="editor"/> <group name="marketing"/> <and> <role name="admin"/> <not> <user name="jdoe"/> </not> </and> </or> </and> </allowed> </model>
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
Managing Workflow Models

You can manage a workflow model, either through: The Content tab of TeamSite. For more information, see Managing Workflow Models Using the Content Tab. The Configuration tab or Workflows tab of the unified administration interface. For more, see the Configuration chapter or Workflows chapter of the unified administration interface guide.
Managing Workflow Models Using the Content Tab

To manage a workflow model using the Content tab: 1. Log in to ContentCenter Professional. 2. Click the Content tab. 3. Navigate to the store that contains the branches you want. 4. Open the main branch. If sub-branches exist, navigate through them to the branch or folder you want. 5. Click Properties > Workflow Management > Manage Workflows The contents of the available_models.xml file are displayed. Repeat steps 4 through 6 mentioned under the section Managing Workflow Models.
150
Configuring Workflow Models
Figure 62 available_models.xml File

TeamSite provides you the flexibility to configure workflow models (listed in the available_models.xml file) for any of the specified branches. When you configure a workflow model for a branch, a custom configuration file, custom_config.xml, is added for that branch. You can manage a workflow models availability to one or more TeamSite branches using one of the following: The Content tab in TeamSite. For more information, see Configuring Workflow Models Using the Content Tab. The Configuration tab or the Workflows tab in the unified administration interface. For more, see the Configuration chapter or Workflows chapter of the unified administration interface guide.
151
Configuring Workflow Models Using the Content Tab

To configure a workflow model using the Content tab: 1. Log in to ContentCenter Professional. 2. Click the Content tab. 3. Navigate to the store that contains the branches you want. 4. Open the main branch. If sub-branches exist, navigate through them to the branch or folder you want. 5. Click Properties > Workflow Management > Configure Workflows The workflow models that have been subscribed to a branch or folder are displayed (see Figure 63). 6. Select the workflow model you want to configure, and then click Next. The branch information is displayed from the available_models.xml file. Figure 63 Branch Information in available_models.xml File
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
The Configure Workflow screen appears. Figure 64 Configure Workflow Screen
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.
Selection Order for Custom Workflow Configuration

When you instantiate a workflow model from a branch or folder, a custom workflow configuration is selected in the following order: 1. If you have a custom_config.xml file in the corresponding vpath (including folder) of iwadmin, then that file is used. 2. If you do not have a custom_config.xml file in that vpath, then the immediate parents branch-level file is used. A workarea-level file is never considered. 3. If you do not have a custom_config.xml file at the branch level, then the global-level file is used; that is, a custom_config.xml file defined for the workflow.
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
(new job, in TeamSite FrontOffice)
(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.
Instantiating Workflows in ContentCenter Professional

The ContentCenter Professional contains three options for instantiating workflow models:
157
Chapter 7: Instantiating Workflows
New Job Submit Assign Each of these options is described in the corresponding section that follows.
Instantiating Workflow Models With the New Job Option

The ContentCenter Professional enables you to instantiate a workflow model using the New Job option from a workarea. To instantiate a workflow model using the New Job option: 1. On the Content tab of the Content Center Professional, click Actions. 2. Select New Job from the menu that appears. Figure 66 New Job Menu Option
The Select a Workflow dialog box appears.
158
Figure 67 Select a Workflow Dialog Box
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
Instantiating Workflow Models With the Submit Option

The ContentCenter Professional enables you to instantiate a workflow model using the Submit option from a workarea. To instantiate a workflow model using the Submit option: 1. On the Content tab of the Content Center Professional, select a file you want to submit, and then click Actions. 2. Select Submit from the menu that appears.
160
Figure 70 Submit Menu Option
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
Instantiating Workflow Models With the Assign Option

The ContentCenter Professional enables you to instantiate a workflow model using the Assign option from a workarea. To instantiate a workflow model using the Assign option: 1. On the Content tab of the Content Center Professional, select a file you want to assign, and then click Actions. 2. Select Assign from the menu that appears. Figure 74 Assign Menu Option
The Select a Workflow dialog box appears.
163
Figure 75 Select a Workflow Dialog Box
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
Viewing Workflow Models in ContentCenter Professional
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

You can view workflow models either before or after they are instantiated. Each option is described in the corresponding section: Viewing Workflow Models Before Instantiation on page 165 Viewing Workflow Models After Instantiation on page 166
Viewing Workflow Models Before Instantiation

To view a workflow model before instantiation: 1. Click the Content tab in ContentCenter Professional. 2. Navigate to //TS_Server/iwadmin/main/workflowModels/STAGING/Models. 3. Select the workflow model you want to view.
165
Figure 78 Selected Workflow Model on the Content Tab
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.
Viewing Workflow Models After Instantiation

After workflow models have been instantiated, you can view their progress from the following areas on the Workflow tab: View Jobs View Tasks Job Details Task Details To view an instantiated workflow model: 1. Click the Workflow tab in ContentCenter Professional. 2. Click the Jobs or Tasks link.
166
Figure 79 Jobs and Tasks Links on the Workflow Tab
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
Web view of the selected workflow model appears.
167
Figure 81 Web View of Instantiated Workflow Model 1 8 9
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
Instantiating Workflow Models in ContentCenter Standard
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.
Instantiating Workflow Models in ContentCenter Standard

To instantiate a workflow model in ContentCenter Standard: 1. Log in to ContentCenter Standard. The ContentCenter Standard portal page appears. 2. In the Tasks area, click New Job. Figure 82 New Job Link in ContentCenter Standard
The Select A Workflow screen appears.
169
Figure 83 Select A Workflow Screen
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
Instantiating Workflow Models from TeamSite Front Office
Figure 84 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 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.
Instantiating Workflow Models from TeamSite Front Office

You can instantiate workflows from the TeamSite Front Office Check In menu option.
171
Figure 85 Check In option in TeamSite Front Office
For more information on working with workflow, jobs, and tasks in TeamSite Front Office, see the TeamSite Front Office documentation.
Instantiating Workflow Models from the Command Line

Workflow models can also be run from the command line using the iwmodelc.bat command. The iwmodelc.bat command-line utility is installed by default in the iw-home/bin directory. It is similar to iwjobc.exe documented in the TeamSite Command-Line Utility Guide. You can find the valid options and arguments for iwmodelc.bat by executing the following command at the command prompt: iwmodelc.
172
Instantiating Workflow Models from the Command Line
NOTE
The iwmodelc.bat command is for Windows users only. UNIX users must use the iwmodelc.sh command.
173
174
Chapter 8
Customizing the Instantiation Screen

The workflow instantiation screen is a form into which a workflow user enters additional, required information when a workflow is instantiated. The instantiation screen is based on a Data Capture Template (DCT) and is generated dynamically during workflow instantiation. TeamSite provides a default instantiation screen for Workflow Modeler related workflows. As a workflow developer, you can customize the instantiation screen so that it looks and performs appropriately for different situations and sets of requirements. For example, you can change the layout and appearance of the screen so that it is more intuitive and user-friendly for a specific set of users. The following sections describe why you might choose to customize the instantiation screen, which workflow fields you can customize, and how to perform the customization.
Why Customize the Instantiation Screen?

By creating a custom instantiation screen, you can: Change the presentation of the instantiation screen. For example, you can arrange the items in a more logical way or change the widget type of a property. Add client-side validation or introduce dynamic behavior in the instantiation screen by adding the FormAPI or JavaScript code.
NOTES
The following FormAPI objects are not supported in the context of workflow: Data Capture Form
IWDatacapture.save ()
175
Chapter 8: Customizing the Instantiation Screen
IWDatacapture.setIsModified () IWDatacapture.enableImagePreview (enable) IWDatacapture.getDCTPath(O/P undefined)
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.
Which Workflow Fields can be in a Custom Instantiation Screen?

While designing a workflow model using Workflow Modeler, you can use placeholders for values of certain properties. You can provide values for these properties during instantiation or customization of the workflow in TeamSite. To achieve this, make any property of the workflow a Configurable or Datasource variable during design. Users can enter final values for these properties during the workflow instantiation using the instantiation screen.
176
How to Customize the Instantiation Screen?
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.

You can create a custom instantiation screen in two ways: By creating an instantiation screen DCT file manually using a text or XML editor. You should use this method only if you are proficient at creating DCT files as described in the TeamSite FormsPublisher Developer's Guide. See Creating the Custom Configuration File Manually on page 199 for workflow-specific considerations if you use this method. By first creating a default instantiation screen DCT file using the Command-Line Tool (CLT) and then modifying that file. This method is explained in the following sections.
Creating a Default Instantiation Screen

Perform the following steps to create a default instantiation screen. After creating the default screen, see Customizing the Default Instantiation Screen on page 178 for customization steps. 1. Create a workflow model with some Configurable/Datasource variables. For example, create a SampleReview workflow model, as shown in Figure 86.
NOTE
This example is for Windows users only.
Figure 86 Workflow Model - SampleReview
2. Publish this workflow model. The default_config.xml file is created. This file contains the following code snippet:
177
<ProcessModelConfiguration xmlns="http://www.interwoven.com/schema/ modelConfig"/>
Customizing the Default Instantiation Screen

Perform the following steps to customize the default instantiation screen. When you are done, see Making the Custom Instantiation Screen Available on page 179 for location and check-in details. 1. Go to iw-home/bin/ and run the CLT iwmodeldct. You can find the valid options and arguments for iwmodeldct by executing the iwmodeldct command at the command prompt. Implementation of this command generates the instantiation screen DCT for a workflow. For the SampleReview workflow model, type the following at the command prompt to create an instantiation screen DCT file named out.txt:
iw-home/bin/ iwmodeldct "y:/iwadmin/main/workflowModels/WORKAREA/iw-wa/ Config/SampleReview_config/default_config.xml" "c:\out.txt"
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
Making the Custom Instantiation Screen Available

Perform the following steps to make the custom instantiation screen available. 1. Move the custom_instantiation.cfg file into the /iwadmin/main/workflowModels/ WORKAREA/iw-wa/Config/SampleReview_config directory. 2. Submit the custom_instantiation.cfg file to the staging area. Different instantiation screens can be made to appear for different branches/stores. You can do this by placing the custom_instantiation.cfg file in a location that represents the VPath of the branch/store. For example, if you want the custom instantiation screen for the workflow SampleReview to appear only for the workflows residing in the branch default/main/shoppers, place the custom_instantiation.cfg file in the following location (shown here as a VPath):
/iwadmin/main/workflowModels/WORKAREA/iw- wa/Config/SampleReview_config/default/ main/shoppers/
179
Changing Default Property Appearance

You can change the look and feel of properties in the instantiation screen by modifying the custom_instantiation.cfg file. Follow the steps mentioned below to change the label and widget type of a Configurable variable.
NOTES
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
Figure 87 Configurable Variable - Label (During Design in Workflow Modeler)
7. Publish the workflow.

NOTE
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)
The corresponding code in the custom_instantiation.cfg file is as follows:

<item pathid="ID1211817909655" name="ID1211817909655"> <label>Member</label> <description/> <textarea required="f"/> </item>
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
The following widgets are supported in the custom_instantiation.cfg file:

183
checkbox radio text textarea select
You should not remove or modify the contents of the default_config.xml file.
Figure 90 Default Appearance of the Configurable Variable (Employee)
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
Figure 91 Modified Appearance of the Configurable Variable (Employee)
Adding Client-Side Validation

In the Workflow Modeler, there are certain properties that do not require a default value to be specified at the time of design. For example, you need not provide a default value for the Description property. However, you may want to add some client-side validation code that requires the user to enter values for these properties in the instantiation screen. The following is an example of how to add validation code. In the SampleReview workflow model that you created, note that you assigned a Configurable variable to the Description property and renamed its label with Employee. To ensure that the user enters data for this property, modify the custom_instantiation.cfg file to include the validation code by replacing required="f" with required="t". If the user does not enter the data for this property, the user sees an error and is not be able to submit the job. The modified code is as follows:
<item pathid="ID1211817909655" name="ID1211817909655"> <label>Employee</label> <description/> <text required="t"/> </item>
Adding New Fields

The following is an example of creating two new fields (First_Name and Last_Name) for the SampleReview workflow model by modifying its custom_instantiation.cfg file.
NOTE
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>
<item pathid="IDFirst_Name" name="First_Name"> <label>First 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
<text required="t"/> </item>
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
Adding Dynamic Behavior

You can introduce dynamic behavior by incorporating FormAPI features or JavaScript in your custom_instantiation.cfg file. When you create the custom_instantiation.cfg file using the iwmodeldct command, some JavaScript code is automatically included along with the XML code. The functionality provided by the default JavaScript is explained in the section Default JavaScript Functionality on page 188.
NOTES
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.
Default JavaScript Functionality

The default JavaScript in the custom configuration file provides dynamic behavior and certain validations to the instantiation screen. This script can be divided into the following three sections: Variable Name Declaration Function Declaration FormAPI Event Association The JavaScript is enclosed within the <script> tag, as shown below.
<script> var reviewersIdList = null; . . . function init() {} function setReadonlyDatasourceItems(){...} function setHiddenDatasourceItems() {...} function loadReviewersValues(reviewerItem) {...} function setReadonlyReviewerItems() {...} function enforceMinNoOfReviewers() {...} function getOptionValues(option, parentItem, newOptions) {...}
188
var startingItem = IWDatacapture.getItem("/Config/iw-StartingItem"); . . . </script>
Variable Name Declaration

The first section of the JavaScript in the custom_instantiation.cfg file contains the declaration of variables. This section is generated automatically based on the types of variables that are present in the workflow. The following variables are declared in this section:
reviewersIdList reviewersIdReadonlyList datasourceIdReadonlyList datasourceIdHiddenList
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
loadReviewersValues(reviewerItem) setReadonlyReviewerItems() enforceMinNoOfReviewers() getOptionValues(option, parentItem, newOptions)
The functions are explained in detail as follows:

init()
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
Figure 94 Datasource Variable Created in Workflow Modeler
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>
Figure 96 Datasource Variable (Without setReadonlyDatasourceItems ())
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>
Figure 98 Reviewers Attribute (Without setReadonlyReviewerItems ())
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
FormAPI Event Association

In the last section of the JavaScript code in the custom_instantiation.cfg file, some of the functions are associated with FormAPI events. This association allows you to invoke these functions whenever a particular event occurs. The following code registers the function enforceMinNoOfReviewers() with the onSave event of the instantiation screen.
IWEventRegistry.addFormHandler("onSave",enforceMinNoOfReviewers);
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>
Creating the Custom Configuration File Manually

See TeamSite FormsPublisher Developer's Guide for details about creating the custom_instantiation.cfg file manually.
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
Using Datasource Framework

Introduction
Datasource framework provides you an easy way to write your own Datasources that can extract data from within TeamSite or any external source. You can use Datasources for the variables of workflow models developed using Workflow Modeler or for Data Capture Templates (DCTs) in TeamSite. The following points summarize the uses of Datasources: Datasources can pull data from any external application such as LDAP, database, and so on. Datasources can pull data from within TeamSite. You can use CSSDK inside Datasources to communicate with TeamSite to fetch the data.
CAUTION
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.
Using Out-of-the-Box Datasources

Autonomy provides the following out-of-the-box Datasources. To use these Datasources, you have to set the Datasource Name property of a Datasource variable to any one of these Datasources. TS User Picker. Retrieves and renders the TeamSite users. TS Branch Picker. Retrieves and renders the TeamSite branches.
201
Chapter 9: Using Datasource Framework
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
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.
Implementing Datasource Interfaces

Datasource framework exposes the following interfaces, which are available for creating Datasources: SimpleDataSource ArrayDataSource (deprecated) ListDataSource MapDataSource SortedValuesMapDataSource
NOTE
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
Javadocs for these interfaces are available in the following file:

iw-home/httpd/webapps/content_center/WEB-INF/lib/datasourcedoc.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
This interface has been deprecated; use ListDataSource instead.
Signature
public interface ArrayDataSource { public String[] execute(String sessionId, String context, Map param); }
Arguments for SimpleDataSource and ArrayDataSource

The description of the parameters used by the SimpleDataSource and ArrayDataSource interfaces is as follows:
204
sessionId. context.
Session ID of the currently logged in user.
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
{ public Map<String, String> execute (DataSourceContext context); }
Arguments for ListDataSource, MapDataSource, and SortedValuesMapDataSource

The description of the parameter used by the Datasource interfaces is as follows:
context. An instance of the DataSourceContext getSessionId, getServerContext, and so on.
class. This class contains methods such as
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
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
2. At the command prompt, navigate to the following folder:

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.
Using Datasources in Job Instantiation Forms

Job instantiation forms, which are displayed when you create a new job, are generated using Data Capture Templates (DCTs). TeamSite gives you the flexibility to create custom instantiation forms (DCTs) and customize the presentation of these forms.
NOTE
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)
Static Calls for Datasources

You can make static calls using inline commands. Datasource framework supports the following inline commands:
getDatasourceNames executeComponent
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
This is a constant and should always be Datasource; it is case-insensitive.
.This is a constant and should always be getDatasourceNames; it is case-insensitive.
namespace (optional). This is the namespace identifier used while registering Datasources. For example, for Datasources belonging to Workflow Modeler, it should be IW-WFM.
You can call this command as follows:

<inline command="Datasource:getDatasourceNames: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 Datasource; it is case-insensitive.
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,
component-name. UserPicker. param-name
(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
You can call this command as follows:

<inline command="Datasource:executeComponent:UserPicker: role=master:server=TeamSite"/> 209
In this sample code, the UserPicker Datasource returns users with the master role from the TeamSite server.
An Example for Static Calls

The following code snippet demonstrates the use of the getDatasourceNames and executeComponent inline commands:
... ... <item name="DataSourceComponent" pathid="dsComponent"> <label>Datasources</label> <description>Lists all the registered datasources present in the system.</description> <select> <inline command="Datasource:getDatasourceNames"/> </select> </item> <item name="Users" pathid="@Users"> <label>Author</label> <description>Select a user who is a TeamSite author</description> <select> <inline command="Datasource:executeComponent:TS User Picker:Role=author"/> </select> </item> ... ...
Dynamic Calls for Datasources

In addition to static calls, you have the option of calling Datasources using FormAPI. These are remote server calls and are asynchronous in nature, similar to the callserver() method. However, the syntax is a slightly different from the callserver() method. For more information on FormAPI, see the FormAPI Developers Guide. To support dynamic calls, the following JavaScript objects have been introduced:
IWDatasource IWMap
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
Name of the Datasource component to be executed, for example,
(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().
Adds a new entry into the map.
For example:
mapObj.put(key,value); get().
Retrieves an entry from the map for the specified key.
For example:
mapObj.get(key); key().
Retrieves an array of keys present in the map.
For example:
mapObj.keys(); length().
Returns the number of items present in the map.
For example:
mapObj.length();
An Example for Dynamic Calls

The following code snippet demonstrates the use of objects and methods that support dynamic calls for Datasources:
... 212
... 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
Using Custom Code

Overview
TeamSite gives you the flexibility to execute custom code during the workflow instantiation. Using the custom code, you can modify the workflow properties, add files to the workflow, and/ or remove files from the workflow. To perform these actions, you need to call in-process (recommended) or out-of-process commands. You can use Workflow Modeler to add these commands for the two new properties PreProcessor Command and PostProcessor Command of any workflow model. In addition, you can specify the order in which these commands should be executed. The following figure illustrates the sequence in which the pre-processor and post-processor commands are executed during the workflow instantiation.
215
Chapter 10: Using Custom Code
Figure 99 Custom Code Workflow
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.
Creating Custom Code

To create your custom code for an in-process command: 1. Implement the InProcessJavaCommand interface, see Implementing the InProcessJavaCommand Interface on page 217. 2. Deploy the custom code in TeamSite, see Deploying Custom Code on page 220.
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.
Implementing the InProcessJavaCommand Interface

To develop custom code for an in-process command, you must implement the InProcessJavaCommand interface. For example:
public class PreProcessorURLTask implements InProcessJavaCommand { ... ... }
NOTES
Your class must include the following import statement:

import com.interwoven.modeler.workflow.commands.InProcessJavaCommand;
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.
Deploying Custom Code

To deploy your custom code: 1. Create a JAR for your class. 2. Place the .jar file into the following location:
iw-home/local/config/lib/content_center/customer_src/lib
3. At the command prompt, navigate to the following folder:

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
Workflow Modeler Tutorial

This tutorial shows you how to create a workflow model similar to Configurable Default Submit, which is shipped with TeamSite. In addition, it shows you how to make the workflow model 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. By the end of this tutorial, you will learn how to perform the following tasks: Create a workflow model that uses various workflow elements such as Submit Task, Deploy Task, and so on. Use CONFIGURABLE and SCRIPT variables. Make your workflow model available to job creators. The concepts and procedures included in this tutorial are designed to get you through the creation of your first actual workflow model. Some features that are not specific to the creation of this project are not explained. These optionsand other advanced Workflow Modeler featuresare described in detail in other chapters of this book.
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.
Creating a New Workflow

To complete this tutorial, you must work in the online mode; that is, you need to log in to the TeamSite server. For information on logging in to the TeamSite server, see Starting Workflow Modeler on page 35. To open the tutorial and begin your project: 1. Launch Workflow Modeler. The Login dialog box appears. 2. Enter the following information in the Login dialog box: User Name. Your TeamSite user name. Password. Your TeamSite password. Domain. The domain where the TeamSite sever 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. 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 Dummy Task Create Metadata No Metadata Submit After Timeout
Start Event Dummy Task Conditional Link Conditional Link Timeout Link
225
Table 24 TutorialList of Workflow Elements (Continued)

Element Name Element Type
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.
Specifying Workflow Attributes

In this section, you will specify two workflow attributes. To specify values for the workflow attributes: 1. In the Tree pane, select Workflow Model. 2. In the Properties pane, specify values for the following attributes: Table 25 TutorialWorkflow Attributes
Attribute Description Action
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
Table 25 TutorialWorkflow Attributes (Continued)

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.
Specifying Task Attributes

In this section, you will specify the attributes for each task. Each task has some common and some unique set of attributes. For details about these attributes, see Assigning Common Task Attributes on page 79 and Assigning Task-Specific Attributes on page 94.
228
Dummy Task (Dummy Task)

You need to specify the following attributes for the Dummy task. To specify values for Dummy task attributes: 1. In the Project pane, select the Dummy Task. 2. In the Properties pane, specify values for the following attributes: Table 26 TutorialDummy Task Attributes
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.
Type Dummy Task
Brief Description Description
Type Submit In Progress
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.
Metadata Capture (Metadata Task)

You need to specify the following attributes for the Metadata Task. To specify values for Metadata task attributes: 1. In the Project pane, select the Metadata Task. 2. In the Properties pane, specify values for the following attributes: Table 27 TutorialMetadata Task Attributes
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
Table 27 TutorialMetadata Task Attributes (Continued)

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.
Submit (Submit Task)

You need to specify the following attributes for the Submit Task. To specify values for the Submit Task attributes: 1. In the Project pane, select the Submit Task. 2. In the Properties pane, specify values for the following attributes: Table 28 TutorialSubmit Task Attributes
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
Brief Description Description
Submit Comment
230
Table 28 TutorialSubmit Task Attributes (Continued)

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
Deploy Task (Deploy Task)

You need to specify the following attributes for the Deploy Task. To specify values for Deploy Task attributes: 1. In the Project pane, select the Deploy Task. 2. In the Properties pane, specify values for the following attributes: Table 29 TutorialDeploy Task Attributes
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
Notify Deploy (Email Task)

You need to specify the following attributes for the Notify Deploy task. To specify values for the Notify Deploy task attributes: 1. In the Project pane, select the Notify Deploy task. 2. In the Properties pane, specify values for the following attributes: Table 30 TutorialNotify Deploy Task Attributes
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
Brief Description Variables
class. For reviewerNotification.xsl or

configurableReviewerNotificat ion.xsl, use the ReviewerMailNotificationTask
class. In addition, you need to do the following:
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
Specifying Link Attributes

In this tutorial, you will use Default, Conditional, Success, and Failure links. You need to specify an intuitive name for each link, because these names will appear on the buttons that help you proceed to the next task of the job.
Create Metadata (Conditional Link)

You need to specify the following attributes for the Create Metadata link. To specify values for the Create Metadata link attributes: 1. In the Project pane, select the Create Metadata link. 2. In the Properties pane, specify values for the following attributes: Table 31 TutorialCreate Metadata Link Attributes
Name
Specifies a name that displays in the list of available jobs in the ContentCenter interfaces
Type Create Metadata
233
Table 31 TutorialCreate Metadata Link Attributes (Continued)

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; }
No Metadata (Conditional Link)

You need to specify the following attributes for the No Metadata link. To specify values for the No Metadata link attributes: 1. In the Project pane, select the No Metadata link. 2. In the Properties pane, specify values for the following attributes: Table 32 TutorialNo Metadata Link Attributes
Name
Type No Metadata
234
Table 32 TutorialNo Metadata Link Attributes (Continued)

Expression
if("$IW_CV(includeMetadata)" != "true") { true; } else { false; }
Submit After Timeout (Timeout Link)

You need to specify the following attributes for the Submit After Timeout link. To specify values for the Submit After Timeout link attributes: 1. In the Project pane, select the Submit After Timeout link. 2. In the Properties pane, specify values for the following attributes: Table 33 TutorialSubmit After Timeout Link Attributes
Name
Type Submit After Timeout
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
No Deploy (Conditional Link)

You need to specify the following attributes for the No Deploy link. To specify values for the No Deploy link attributes: 1. In the Project pane, select the No Deploy link. 2. In the Properties pane, specify values for the following attributes: Table 34 TutorialNo Deploy Link Attributes
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
if("$IW_CV(includeDeploy)" != "true") { true; } else { false; }
Deploy Content (Conditional Link)

You need to specify the following attributes for the Deploy Content link. To specify values for the Deploy Content link attributes: 1. In the Project pane, select the Deploy Content link.
236
2. In the Properties pane, specify values for the following attributes: Table 35 TutorialDeploy Content Link Attributes
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 Deploy Content.
Expression
if("$IW_CV(includeDeploy)" == "true") { true; } else { false; }
Notify (Conditional Link)

You need to specify the following attributes for the Notify link. To specify values for the Notify link attributes: 1. In the Project pane, select the Notify link. 2. In the Properties pane, specify values for the following attributes: Table 36 TutorialNotify Link Attributes
Name
Type Notify.
237
Table 36 TutorialNotify Link Attributes (Continued)

Expression
if("$IW_CV(notifyDeployFailure)" == "true") { true; } else { false; }
Resolve Problems (Conditional Link)

You need to specify the following attributes for the Resolve Problems link. To specify values for the Resolve Problems link attributes: 1. In the Project pane, select the Resolve Problems link. 2. In the Properties pane, specify values for the following attributes: Table 37 TutorialResolve Problems Link Attributes
Name
Type Resolve Problems.
238
Saving Your Workflow Model
Table 37 TutorialResolve Problems Link Attributes (Continued)

Expression
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.
Saving Your Workflow Model

In this section, you will save your workflow file and use the Validate feature to find and correct an error in the workflow model. When you save a workflow model, Workflow Modeler checks for errors. If errors exist, the Error pane displays information about each error. You can validate your workflow model at any time by selecting Options > Validate Workflow. To save the workflow model on your local system: 1. Select File > Save As. A dialog box prompts you to validate the workflow model.
239
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.
Publishing Your Workflow Model to TeamSite

When you are ready to make a workflow model available to TeamSite users, you must publish it to the TeamSite server. To publish the workflow model to the TeamSite server, select File > Publish Workflow. This will save the workflow model to //TS_Server/iwadmin/main/workflowModels/STAGING/ workflow model is automatically saved to //TS_Server/
Models. In addition, a copy of the iwadmin/main/workflowModels.
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
Testing Your Work
Testing Your Work

Test your work by creating a new job with your workflow model in TeamSite. 1. Open a browser and log in to your TeamSite server. 2. Navigate to any workarea. 3. Select Actions > New Job. The Select Workflow window displays with Sample_WorkflowModel included in the list of available workflows. 4. Select Sample_WorkflowModel, and click Next. A new job form appears. Notice that the form includes blank text areas for all the configurable variables you defined while designing the workflow model.
NOTE
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).
Available_Models1.0.xsd (Subscription schema)

The Available_Models1.0.xsd file is a collection of declarations divided into two types:
ELEMENT.
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.
The Available_Models1.0.xsd Internal.
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"?>  <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
Available_Models1.0.xsd (Subscription schema)
</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"?>   <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
For this example, we have used the MapDataSource interface.
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
Appendix C: Datasource Example
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));
//Get the CSFactory factory=CSFactory.getFactory(props); if(param.get(LOCALE)!=null) { locale=(Locale)param.get(LOCALE); 255
}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
file. Reinstall the Workflow Modeler application.
257
Appendix D: Troubleshooting
Table 38 Error Messages (Continued)

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.
The common.xml file, typically located in

installation_directory\data\palettes, is corrupt. You can find more information in the installation_directory\WorkflowModeler.log
file. Reinstall the Workflow Modeler application. The Workflow Modeler installation is incorrect or corrupt. You can find more information in the
file. Reinstall the Workflow Modeler application.
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
Unable to find the TeamSite CSSDK properties file.
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
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
External workflow tasks not working in TeamSite.
15
URL external tasks not working after SiteMinder integration.
259

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
Unable to connect to TeamSite server from Workflow Modeler.
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

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.
Debugging with WorkflowModeler.log File

Logging enables you to capture important events that occur in your application and can aid you during the debugging process. There are lots of logging utilities out of which the Workflow Modeler application supports Apache log4j framework. By default, in Windows, the installation program creates the log4j.properties file in the C:\ folder. However, if you choose a different location to install the Workflow Modeler application, this file is created in the installation folder. For example, if you install the Workflow Modeler application in the C:\WFM folder, the log4j.properties file is created in the C:\WFM folder. Configure the log4j.properties file in WorkflowModeler.log file. To do this: such a way that the events are captured in the
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
Specifies potentially harmful situations.
Debugging with WorkflowModeler.log File
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
abort. 4. Save the file.

NOTES
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
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
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
extended attributes annotations 136 External task 41
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
IWorkflow Modeler logging into TeamSite 36
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
NOT node 40 NOT operator 23
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
Review task 41 role workflow model access 146
Available_Models1.0.xsd 243 Success link 40 system requirements, for installing 27
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

WFM 71 User v01 en

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

WFM 71 User v01 en

Transféré par

Droits d'auteur :

Formats disponibles

Workflow Modeler Users Guide

Trademarks and Copyrights

Notice to Government End Users

About This Book

Installing Workflow Modeler

Using Workflow Modeler

Workflow Modeler Users Guide

Working with Element Attributes

Predefined Workflow Models

Managing and Configuring Workflow Models

Workflow Modeler Users Guide

144 144 145 149 150 150 151 152 154

Customizing the Instantiation Screen

Using Datasource Framework

Workflow Modeler Users Guide

Using Custom Code

Appendix A: Workflow Modeler Tutorial

Workflow Modeler Users Guide

Appendix B: Workflow Schemas

Available_Models1.0.xsd (Subscription schema) . . . . . . . . . . . . . . . . . . . . . . . . . 243 DataSourceConfig.xsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Appendix C: Datasource Example Appendix D: Troubleshooting Glossary Index

249 257 265 267

Debugging with WorkflowModeler.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Workflow Modeler Users Guide

Workflow Modeler Users Guide

Workflow Modeler Users Guide

Workflow Modeler Users Guide

Workflow Modeler Users Guide

About This Book

Workflow Modeler Users Guide

About This Book

Monospaced italics are used for command-line variables.For example:

Monospaced bold italic

Workflow Modeler Users Guide

Workflow Modeler Users Guide

About This Book

New or Changed Information

Workflow Modeler Users Guide

Workflow Modeler Users Guide

Workflow Modeler Users Guide

Workflow Modeler Users Guide

Creating Workflow Models with Workflow Modeler

Workflow Modeler Users Guide

Creating Workflow Models with Workflow Modeler

Assigning Element Properties

Workflow Modeler Users Guide

Publishing Workflow Models

TeamSite and Workflow Models

Workflow Modeler Users Guide

TeamSite and Workflow Models

(new job, in TeamSite FrontOffice)

Workflow Modeler Users Guide

Workflow Modeler Users Guide

Installing Workflow Modeler

Installing Workflow Modeler

Workflow Modeler Users Guide

Chapter 2: Installing Workflow Modeler

Workflow Modeler Users Guide

Installing Workflow Modeler

Workflow Modeler Users Guide

Chapter 2: Installing Workflow Modeler

Choose Shortcut Folder Screen