wfm_71_user_v01_en

Workflow ModelerUser’s Guide

Version 7.1Document Revision 1

December 2009

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: [email protected]

December 2009

Copyright Notice

•

Contents

About This Book 15Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Manual Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16New or Changed Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 1: Introduction 19Workflow Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Workflow Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Creating Workflow Models with Workflow Modeler . . . . . . . . . . . . . . . . . . . . . . . 22Adding Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Assigning Element Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Publishing Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

TeamSite and Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 2: Installing Workflow Modeler 27System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Installing Workflow Modeler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Uninstalling Workflow Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 3: Using Workflow Modeler 35Starting Workflow Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Workflow Modeler GUI Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Standard Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Links Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Tasks Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Display Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Options Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Configuring Application Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Project Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Tree Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Properties Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Workflow Modeler User’s Guide 3• • •••

Contents

4

Overview Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Errors Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Creating a New Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Editing an Existing Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Publishing Workflow Models to TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Retrieving Workflow Models from TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Upgrading to the Latest Workflow Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 4: Working with Element Attributes 65Workflow Modeler Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Configurable Variables ($IW_CV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Datasource Variables ($IW_DS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Script Variables ($IW_SCRIPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70TeamSite System Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73TeamSite Macro Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Variable Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Local Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Comparison of Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Assigning Common Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Area VPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Brief Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Read Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Transfer Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83EA Finish Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84EA Start Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85WF Variables Finish Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86WF Variables Start Op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Assigning Workflow-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Assigning Task-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

CGI Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Deploy Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Email Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Creating a Custom Email Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Email Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

External Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Group Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Metadata Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Workflow Modeler User’s Guide

• • • •••

Contents

•

Nested Workflow Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Review Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Submit Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Update Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117URL Task Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Assigning Common Link Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Assigning Link-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Timeout Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Conditional Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Working with Logical Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Logical Node Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

GatewayType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Chapter 5: Predefined Workflow Models 125Archival Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Author Submit with Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Author Submit with Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Author Submit with Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Configurable Author Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configurable Author Submit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Configurable Default Submit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Publish LiveSite Content Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Publish LiveSiteCS Content Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Retrieval Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Configurable Workflow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Workflow-Specific Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

WorkflowName_config.xml File Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 135configurable_author_submit_config.xml. . . . . . . . . . . . . . . . . . . . . . . . . . . 135configurable_default_submit_config.xml . . . . . . . . . . . . . . . . . . . . . . . . . . 135configurable_author_assignment_config.xml . . . . . . . . . . . . . . . . . . . . . . . 135

VisualAnnotate and Configurable Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Chapter 6: Managing and Configuring Workflow Models 137Understanding Workflow Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

WorkflowUser Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138WorkflowAdmin Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Operations Summary for Workflow Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Published Workflow Models in TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140WorkflowModels Branch Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141


Contents

6

Subscribing Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144The available_models.xml File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Specifying Workflow Model Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Combining Access Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Managing Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Managing Workflow Models Using the Content Tab . . . . . . . . . . . . . . . . . 150

Configuring Workflow Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Configuring Workflow Models Using the Content Tab . . . . . . . . . . . . . . . . . . 152Selection Order for Custom Workflow Configuration . . . . . . . . . . . . . . . . . . . 154

Chapter 7: Instantiating Workflows 157Instantiating Workflows in ContentCenter Professional . . . . . . . . . . . . . . . . . . . . 157

Instantiating Workflow Models With the New Job Option . . . . . . . . . . . . . . . . 158Instantiating Workflow Models With the Submit Option . . . . . . . . . . . . . . . . . 160Instantiating Workflow Models With the Assign Option . . . . . . . . . . . . . . . . . 163

Viewing Workflow Models in ContentCenter Professional . . . . . . . . . . . . . . . . . . 165Viewing Workflow Models Before Instantiation . . . . . . . . . . . . . . . . . . . . . . . 165Viewing Workflow Models After Instantiation. . . . . . . . . . . . . . . . . . . . . . . . . 166

Instantiating Workflow Models in ContentCenter Standard . . . . . . . . . . . . . . . . . 169Instantiating Workflow Models from TeamSite Front Office . . . . . . . . . . . . . . . . 171Instantiating Workflow Models from the Command Line . . . . . . . . . . . . . . . . . . . 172

Chapter 8: Customizing the Instantiation Screen 175Why Customize the Instantiation Screen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Which Workflow Fields can be in a Custom Instantiation Screen? . . . . . . . . . . . . 176How to Customize the Instantiation Screen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Creating a Default Instantiation Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Customizing the Default Instantiation Screen . . . . . . . . . . . . . . . . . . . . . . . . . 178Making the Custom Instantiation Screen Available . . . . . . . . . . . . . . . . . . . . . 179Changing Default Property Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Adding Client-Side Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Adding New Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Adding Dynamic Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Default JavaScript Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Creating the Custom Configuration File Manually. . . . . . . . . . . . . . . . . . . . . . 199

Chapter 9: Using Datasource Framework 201Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Using Out-of-the-Box Datasources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Creating a Datasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Implementing Datasource Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203SimpleDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204ArrayDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Arguments for SimpleDataSource and ArrayDataSource . . . . . . . . . . . . . . 204ListDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205MapDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205SortedValuesMapDataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205


• • • •••

Contents

•

Arguments for ListDataSource, MapDataSource, and SortedValuesMapDataSource206Registering a Datasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Deploying a Datasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Using Datasources in Job Instantiation Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Static Calls for Datasources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

getDatasourceNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208executeComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209An Example for Static Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Dynamic Calls for Datasources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210IWDatasource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211IWMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212An Example for Dynamic Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Chapter 10: Using Custom Code 215Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Creating Custom Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Implementing the InProcessJavaCommand Interface . . . . . . . . . . . . . . . . . . . . 217Additional Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Example One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Example Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Deploying Custom Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Appendix A: Workflow Modeler Tutorial 221Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Tutorial Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Creating a New Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Variables Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Specifying Workflow Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Specifying Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Dummy Task (Dummy Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Metadata Capture (Metadata Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Submit (Submit Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Deploy Task (Deploy Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Notify Deploy (Email Task) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Specifying Link Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Create Metadata (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233No Metadata (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Submit After Timeout (Timeout Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235No Deploy (Conditional Link). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Deploy Content (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Notify (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Resolve Problems (Conditional Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Other Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239


Contents

8

Saving Your Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Publishing Your Workflow Model to TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Testing Your Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Appendix B: Workflow Schemas 243Available_Models1.0.xsd (Subscription schema) . . . . . . . . . . . . . . . . . . . . . . . . . 243DataSourceConfig.xsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Appendix C: Datasource Example 249Appendix D: Troubleshooting 257

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

Glossary 265Index 267


• • • •••

•

Tables

Table 1 Notation Conventions............................................................................................... 15Table 2 Installation Shortcut Location Options ..................................................................... 30Table 3 Standard Toolbar ..................................................................................................... 39Table 4 Links Toolbar ........................................................................................................... 40Table 5 Tasks Toolbar .......................................................................................................... 41Table 6 Display Toolbar ........................................................................................................ 43Table 7 The Options Menu ................................................................................................... 44Table 8 TeamSite System Variables..................................................................................... 73Table 9 TeamSite Macro Variables....................................................................................... 75Table 10 Variable Comparison ............................................................................................... 77Table 11 Workflow-specific Attributes..................................................................................... 90Table 12 CGI task Attributes................................................................................................... 95Table 13 Deploy Task Attributes............................................................................................. 96Table 14 Email Task Attributes ............................................................................................. 101Table 15 External Task Attributes......................................................................................... 111Table 16 Group Task Attributes ............................................................................................ 112Table 17 Metadata Task Attributes ....................................................................................... 113Table 18 Nested Workflow Task Attributes........................................................................... 114Table 19 Review Task Attributes .......................................................................................... 114Table 20 Submit Task Attributes........................................................................................... 116Table 21 Update Task Attributes .......................................................................................... 117Table 22 URL Task Attributes............................................................................................... 118Table 23 Operations Summary for Workflow Roles.............................................................. 140Table 24 Tutorial–List of Workflow Elements........................................................................ 225Table 25 Tutorial–Workflow Attributes .................................................................................. 227Table 26 Tutorial–Dummy Task Attributes............................................................................ 229Table 27 Tutorial–Metadata Task Attributes ......................................................................... 229Table 28 Tutorial–Submit Task Attributes............................................................................. 230Table 29 Tutorial–Deploy Task Attributes............................................................................. 231Table 30 Tutorial–Notify Deploy Task Attributes................................................................... 232Table 31 Tutorial–Create Metadata Link Attributes .............................................................. 233Table 32 Tutorial–No Metadata Link Attributes..................................................................... 234Table 33 Tutorial–Submit After Timeout Link Attributes ....................................................... 235Table 34 Tutorial–No Deploy Link Attributes ........................................................................ 236Table 35 Tutorial–Deploy Content Link Attributes ................................................................ 237Table 36 Tutorial–Notify Link Attributes ................................................................................ 237Table 37 Tutorial–Resolve Problems Link Attributes ............................................................ 238Table 38 Error Messages...................................................................................................... 257


Tables

10
• • • •••

•

Figures

Figure 1 Workflow Model Lifecycle ........................................................................................... 20Figure 2 Sample Workflow Model Diagram............................................................................... 21Figure 3 Introduction Screen..................................................................................................... 28Figure 4 License Agreement Screen......................................................................................... 28Figure 5 Product Files Screen................................................................................................... 29Figure 6 Choose Shortcut Folder Screen.................................................................................. 30Figure 7 Install Complete Screen.............................................................................................. 31Figure 8 Introduction Screen..................................................................................................... 32Figure 9 Uninstall Complete Screen ......................................................................................... 33Figure 10 Login Dialog Box......................................................................................................... 36Figure 11 Workflow Modeler User Interface (UI)......................................................................... 38Figure 12 Options Menu.............................................................................................................. 44Figure 13 Preference Dialog Box ................................................................................................ 46Figure 14 Preference Dialog Box - General Node ...................................................................... 47Figure 15 Preference Dialog Box - Appearance Node................................................................ 48Figure 16 Preference Dialog Box - Shortcut Keys Node............................................................. 48Figure 17 Project Pane with Workflow Model ............................................................................. 49Figure 18 Tree Pane ................................................................................................................... 51Figure 19 Properties Pane .......................................................................................................... 52Figure 20 Overview Pane............................................................................................................ 53Figure 21 Errors Pane................................................................................................................. 55Figure 22 Errors Pane Details..................................................................................................... 55Figure 23 Project Pane Title Bar ................................................................................................. 57Figure 24 Workflow Model Properties ......................................................................................... 58Figure 25 Login Dialog Box......................................................................................................... 61Figure 26 Retrieve from Server Dialog Box ................................................................................ 62Figure 27 Configurable Variable Dialog Box ............................................................................... 67Figure 28 User-defined Configurable Variable Available for Reuse............................................ 67Figure 29 Datasource Variable Dialog Box ................................................................................. 69Figure 30 User-defined Datasource Variable Available for Reuse.............................................. 69Figure 31 Script Variable Dialog Box .......................................................................................... 71Figure 32 User-defined Script Variable Available for Reuse....................................................... 71Figure 33 Description Dialog Box................................................................................................ 80Figure 34 Variables Dialog Box................................................................................................... 83Figure 35 EA Finish Op Dialog Box ............................................................................................ 84Figure 36 EA Start Op Dialog Box .............................................................................................. 85Figure 37 WF Variables Finish Op Dialog Box............................................................................ 87Figure 38 WF Variables Start Op Dialog Box.............................................................................. 88


Figures

12

•

Figure 39 Due Date Dialog Box .................................................................................................. 90Figure 40 Global Variables Dialog Box ....................................................................................... 91Figure 41 VA Variables Dialog Box............................................................................................. 92Figure 42 PostProcessor Dialog Box .......................................................................................... 93Figure 43 Deploy Task–Variables Dialog Box............................................................................. 97Figure 44 OD Variables Dialog Box .......................................................................................... 100Figure 45 Email Task–Variables Dialog Box............................................................................. 102Figure 46 Shared By Dialog Box............................................................................................... 112Figure 47 Reviewers Dialog Box............................................................................................... 115Figure 48 Timeout Duration Dialog Box .................................................................................... 121Figure 49 AND Node................................................................................................................. 123Figure 50 Diagram of the Archival Workflow............................................................................. 126Figure 51 Diagram of the Author Submit with Deploy Solution Workflow ................................. 127Figure 52 Diagram of the Author Submit with Email Solution Workflow ................................... 128Figure 53 Diagram of the Author Submit with Metadata Solution Workflow ............................. 129Figure 54 Diagram of the Configurable Author Assignment Solution Workflow........................ 130Figure 55 Diagram of the Configurable Author Submit Solution Workflow ............................... 131Figure 56 Diagram of the Configurable Default Submit Solution Workflow............................... 132Figure 57 Diagram of the Publish LiveSiteCS Content Workflow ............................................. 133Figure 58 Diagram of the Retrieval Workflow ........................................................................... 134Figure 59 workflowModels Branch ............................................................................................ 141Figure 60 Content Tab of WorkflowModels Branch .................................................................. 142Figure 61 Workflow Model Icon................................................................................................. 143Figure 62 available_models.xml File......................................................................................... 151Figure 63 Branch Information in available_models.xml File...................................................... 152Figure 64 Configure Workflow Screen ...................................................................................... 153Figure 65 Workflow Instantiation Form ..................................................................................... 154Figure 66 New Job Menu Option .............................................................................................. 158Figure 67 Select a Workflow Dialog Box................................................................................... 159Figure 68 Workflow Instantiation Form ..................................................................................... 159Figure 69 Jobs Listed on the Workflow Tab.............................................................................. 160Figure 70 Submit Menu Option ................................................................................................. 161Figure 71 Select a Workflow Dialog Box................................................................................... 161Figure 72 Workflow Instantiation Form ..................................................................................... 162Figure 73 New job Listed on the Workflow Tab ........................................................................ 162Figure 74 Assign Menu Option.................................................................................................. 163Figure 75 Select a Workflow Dialog Box................................................................................... 164Figure 76 Workflow Instantiation Form ..................................................................................... 164Figure 77 New Job Listed on the Workflow Tab ....................................................................... 165Figure 78 Selected Workflow Model on the Content Tab.......................................................... 166Figure 79 Jobs and Tasks Links on the Workflow Tab ............................................................. 167Figure 80 Viewing Workflow Instance – Jobs Details ............................................................... 167Figure 81 Web View of Instantiated Workflow Model................................................................ 168Figure 82 New Job Link in ContentCenter Standard................................................................. 169Figure 83 Select A Workflow Screen ........................................................................................ 170Figure 84 Workflow Instantiation Form ..................................................................................... 171Figure 85 Check In option in TeamSite Front Office ................................................................. 172Figure 86 Workflow Model - SampleReview ............................................................................. 177Figure 87 Configurable Variable - Label (During Design in Workflow Modeler)........................ 181

Workflow Modeler User’s Guide• • •••

Figures

•

Figure 88 Configurable Variable - Label (Member)................................................................... 182Figure 89 Configurable Variable - Label (Employee) ................................................................ 183Figure 90 Default Appearance of the Configurable Variable (Employee) ................................. 184Figure 91 Modified Appearance of the Configurable Variable (Employee) ............................... 185Figure 92 Modified Instantiation Screen with Additional Fields................................................. 186Figure 93 Modified Instantiation Screen (Employee Field is Hidden) ....................................... 187Figure 94 Datasource Variable Created in Workflow Modeler .................................................. 192Figure 95 Datasource Variable (With setReadonlyDatasourceItems ()) ................................... 192Figure 96 Datasource Variable (Without setReadonlyDatasourceItems ()) .............................. 193Figure 97 Reviewers Property (With setReadonlyReviewerItems ()) ........................................ 194Figure 98 Reviewers Attribute (Without setReadonlyReviewerItems ()) ................................... 194Figure 99 Custom Code Workflow ............................................................................................ 216Figure 100Tutorial: Creating a New Workflow Model ................................................................ 225


Figures

14

•

Workflow Modeler User’s Guide• • •••

About This Book

Workflow Modeler User’s Guide describes how to install Interwoven Workflow Modeler, how to use Workflow Modeler, and how to troubleshoot Workflow Modeler problems.

Intended AudienceThis 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 organization’s TeamSite administrator.

Notation ConventionsThis manual uses the following notation conventions:

Table 1 Notation Conventions

Convention Definition and UsageBold 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.

Italic Book titles appear in italics. Terms are italicized the first time they are introduced.Important information may be italicized for emphasis.

Monospace 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.

Workflow Modeler User’s Guide 15

• • • •••

About This Book

16

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 OrganizationThe 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.

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.

Table 1 Notation Conventions

Convention Definition and Usage


• • • •••

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 organization’s 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.


• • • •••

About This Book

18

New or Changed InformationWorkflow Modeler User’s 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.


• • • •••

https://support.interwoven.com

https://support.interwoven.com

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 them—ensures 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


• • • •••

Chapter 1: Introduction

20

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 model’s lifecycle.

Figure 1 Workflow Model Lifecycle

Workflow TerminologyThis 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”


• • • •••

Workflow Terminology

Workflow ModelsA 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

TasksDepending on the context, a task can be two different things:

A logical unit of work when describing business processes or workflow models.


• • • •••


22

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.

JobsA 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.


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.


• • • •••


Creating a workflow model typically includes:

“Adding Elements”

“Assigning Element Properties”

“Publishing Workflow Models”

Adding ElementsTeamSite 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 PropertiesWorkflow 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.


• • • •••


24

Publishing Workflow ModelsCompleted 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 ModelsThe 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:


• • • •••

TeamSite and Workflow Models

tfo_workflow (new job, in TeamSite FrontOffice)

tt_data (saving FormsPublisher data records)

tt_deletedcr (deleting FormsPublisher data records in ContentCenter Standard only)

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.


• • • •••


26
• • • •••

Chapter 2

Installing Workflow Modeler

This chapter contains the following sections:

System Requirements


Uninstalling Workflow Modeler

System RequirementsEnsure 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

Installing Workflow ModelerAfter ensuring that you have satisfied the system requirements, complete the following procedure to install Workflow Modeler on your system.

NOTEIf you encounter any error during the installation, see Appendix D, “Troubleshooting”.

1. Download or locate the Workflow Modeler package.

2. Extract the package contents.


• • • •••

Chapter 2: Installing Workflow Modeler

28

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


• • • •••


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.

NOTEThis screen varies based on the operating system you are using. For Windows, the following screen appears.


• • • •••


30

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 Installation Shortcut Location Options

Option Shortcut LocationIn a new 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.

In an existing Program 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.

In the Start Menu Creates shortcuts to start Workflow Modeler on the Start menu.

On the Desktop Creates shortcuts to start the Workflow Modeler on the Windows desktop.


• • • •••


The Install Complete screen appears.

Figure 7 Install Complete Screen

3. Click Done to complete the installation and exit the installer.

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.

Other 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.

Don’t create icons 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.

Table 2 Installation Shortcut Location Options (Continued)

Option Shortcut Location


• • • •••


32

Proceed to Chapter 3, “Using Workflow Modeler” for information about starting and using the Workflow Modeler.

Uninstalling Workflow ModelerWhen 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.


• • • •••

Uninstalling Workflow Modeler

Figure 9 Uninstall Complete Screen

3. Click Done to complete the uninstallation procedure.


• • • •••


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 ModelerTo 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.


• • • •••

Chapter 3: Using Workflow Modeler

36

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


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.

NOTEFor 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. The name of the TeamSite server.


• • • •••


• 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.

NOTEYou can invoke more than one instance of Workflow Modeler. However, Autonomy does not recommend or support this operation.

Workflow Modeler GUI ElementsThe 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.


• • • •••


38

Figure 11 Workflow Modeler User Interface (UI)

Links toolbarTasks toolbarTree pane

Project paneProperties paneDisplay toolbar

Standard toolbar

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 ToolbarThe 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.


• • • •••


The key operations are introduced in the following table.

Links ToolbarThe 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.

Table 3 Standard Toolbar

Icon Name DescriptionDuplicate Selection Duplicates the selected workflow elements.

Group Selection Groups the selected workflow elements and creates a subprocess. You can expand or collapse the subprocess.

Ungroup Selection Ungroups the selected subprocess.

Layout All Nodes Arranges all the connected workflow elements horizontally and disconnected workflow elements vertically.

Layout Selected Nodes Arranges the selected workflow elements horizontally if they are connected and vertically if they are disconnected.

Automatic Link Layout

Improves the presentation of links.

Hide/Show Property Sheet

Hides/displays the Properties pane.

Validate Workflow Model

Validates the workflow. If the workflow contains error(s), the Error pane appears.

Sticky Actions 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.


• • • •••


40

The links and nodes are introduced in the following table.

Table 4 Links Toolbar

Icon Name DescriptionStart 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.

End Event 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.

Default Link Defines a simple transition from one workflow element to another. Use this link type when there is no need for special logic or conditions.

Reset Link Defines a link that restarts the workflow by an event that precedes it.

Inactivate Link Defines a link that can be rendered inactive by an event that proceeds it.

Timeout Link 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.

Success Link Defines the workflow path on which to continue after an event has been successfully completed.

Failure Link Defines the workflow path on which to continue after an event has not been successfully completed.

Conditional Link 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.

AND Gateway All tasks linked to this element must be completed before activating a successor task.

OR Gateway One of the tasks linked to this element must be completed before activating a successor task.

NOT Gateway None of the tasks linked to this element must be completed before activating a successor task.

Text Annotation 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.


• • • •••


NOTEThe links and nodes listed in this table are also available from the Create > Other Elements menu.

Tasks ToolbarThe 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 Tasks Toolbar

Icon Name DescriptionUser Task Defines a task that is assigned to a user. It appears on

a user’s task list in ContentCenter interfaces.

Review Task Defines a task that specifies one or more users must review assigned work (typically files associated with the task) before the job can continue.

Group Task 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.

Email Task 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.

External Task Specifies that an external program is run using the command element.

CGI Task Enables you to run a CGI script.

Metadata Task Enables the task owner to create metadata for the files associated with the task.

Update Task Performs a TeamSite Get Latest or Copy to Area operation on files associated with the task.


• • • •••


42

NOTEThe tasks listed in this table are also available from the Create > Tasks menu.

Submit Task Performs a TeamSite Submit operation on files associated with the task.

Deploy 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.

Lock Task 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.

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 Specifies a URL to be invoked.

Dummy Task Acts as a placeholder for time delays, task resets, or gate transition tasks. A dummy task has no owner or areavpath.

Table 5 Tasks Toolbar (Continued)

Icon Name Description


• • • •••


Display ToolbarThe 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 Display Toolbar

Icon Name DescriptionMake 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* Increases the magnification of the area of the Project pane where you click.

Zoom Out* Decreases the magnification of the area of the Project pane where you click.

Zoom Box Defines a rectangular area of the Project pane to display.

Reset Zoom* Resets the magnification of the Project pane to the default setting. This option is not active when the default magnification is selected.

Fit to Contents* Displays all elements in the Project pane as large as possible without cropping out any element.

Pan 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.

Hide/Show Tree* Hides or displays the Tree pane. For information about the Tree pane, see “Tree Pane” on page 50.

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.


• • • •••


44

NOTEThe 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 MenuThe 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 The Options Menu

Option DescriptionAllow 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.


• • • •••


Configuring Application Settings

You can configure the application settings using the Preference dialog box. To display the dialog box, select Options > Preference.

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.

Grid Spacing Displays the Grid Spacing dialog box where you can specify the Project pane’s grid size (in points). The grid is displayed or hidden by selecting the Grid option in the View menu.

Validate Workflow 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.

Login to Server Displays the server Login dialog box if you are currently using the Workflow Modeler in the offline mode.

Logout from Server Logs you out of the TeamSite server if you are using the Workflow Modeler in the online mode.

Preference 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.

Table 7 The Options Menu (Continued)

Option Description


• • • •••


46

Figure 13 Preference Dialog Box

You can configure the following options using the Preference dialog box:

“General”

“Appearance”

“Shortcut Keys”

NOTEAll 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.


• • • •••


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.

NOTEIn 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.


• • • •••


48

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


• • • •••


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.

NOTEIn the offline mode, the Shortcut Keys option is disabled.

Project PaneThe 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.


• • • •••


50

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 work—authoring a Press Release for example—then 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 deployed—for 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 PaneThe 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.


• • • •••


Figure 18 Tree Pane


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.


• • • •••


52

Properties PaneThe 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.

NOTEThe 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


Some of the General properties have been assigned.

NOTEEnsure that the required properties (indicated as bold labels) have values assigned to them.

The test1 project is:

Described as an Approve/deploy workflow model.


• • • •••


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 PaneThe 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


One of the Zoom tools has been used to magnify the image in the Project pane.


• • • •••


54

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 PaneThe 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.


• • • •••


Figure 21 Errors Pane


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 contain—or are linked with links that contain—errors.

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


• • • •••


56

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 ModelTo 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.

NOTEYou 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.


• • • •••

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.

The current user’s TeamSite workarea on the //TS_Server/iwadmin/main/workflowModels/WORKAREA/iw-wa/Models branch if you logged in to TeamSite using the Workflow Modeler.

4. Click the Start Event node icon, move your cursor to the place in the Project pane 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).


• • • •••


58

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”.

NOTEID 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).


• • • •••

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 node—and a link to it—to complete the workflow model.

11. Click Save, or select File > Save to save the project.

NOTEWhen 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 ModelTo 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 user’s TeamSite workarea on the //TS_Server/iwadmin/main/workflowModels/WORKAREA/iw-wa/Models branch if you logged in to TeamSite when you started Workflow Modeler.


• • • •••


60

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 TeamSiteAfter 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.


• • • •••

Retrieving Workflow Models from TeamSite

Figure 25 Login Dialog Box

NOTEIf 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.

NOTEIf 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 TeamSiteUsing 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


• • • •••


62

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.

NOTEAfter 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.


• • • •••

Upgrading to the Latest Workflow Schema

Upgrading to the Latest Workflow SchemaWhen 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.

NOTEThe 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.


• • • •••


64
• • • •••

Chapter 4

Working with Element Attributes

Workflow elements—tasks, transition links, and nodes—all 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 VariablesThe 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)


• • • •••

Chapter 4: Working with Element Attributes

66

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.

NOTEYou 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 task’s Brief Description.


• • • •••


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).


• • • •••


68

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, including—but not limited to—a database, TeamSite, a user-defined class, or a computer’s 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.

NOTEWhile 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 task’s Brief Description.


• • • •••


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).


• • • •••


70

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.

NOTEThis 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.

NOTEIn 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 task’s Owner.


• • • •••


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:


• • • •••


72

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 workflow’s 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()

{


• • • •••


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.

NOTEExpressions 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 VariablesYou 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

Variable Name Description$IW_HOME TeamSite installation directory


• • • •••


74

$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 attribute’s value; else, it is set to the https_port attribute’s 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 attribute’s 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 Current VPath’s store$IW_SERVER TeamSite server name$IW_SESSION Current user’s session ID$IW_USER Current user’s TeamSite user name$IW_WORKAREA Current VPath’s workarea$IW_AREAOWNER Current workarea’s owner$IW_BRANCH Current VPath’s branch$IW_TIME Current time in milliseconds

Table 8 TeamSite System Variables (Continued)

Variable Name Description


• • • •••


System variables are identified by the icon.

TeamSite Macro VariablesYou 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.

NOTEMacro variables are available to EA Finish Op and EA Start Op only.

Variable ScopeWorkflow Modeler enables you to define variables with the following scopes:

Local

$IW_WFNAME Current workflow’s name

Table 9 TeamSite Macro Variables

Variable Name Description%workflow; Name of the job%workflowid; ID of the job%task; Name of the task%taskid; ID of the task%taskowner; Owner of the task%time; The current wall clock time%area; VPATH of the task's area%path; Path of the file from area root%fullpath; Full path of the file from server root%taskcomment; Task-specific comment added to the

extended attribute%filecomment; File-specific comment added to the

extended attribute

Table 8 TeamSite System Variables (Continued)

Variable Name Description


• • • •••


76

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.

NOTEDo not include the “|” symbol for a global variable’s 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 Modeler’s Properties pane.


• • • •••


Comparison of VariablesThe following table provides a comparison of the variables.

Table 10 Variable Comparison

Type Description Resolution Stage Use Case Value AssignmentConfigurable 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 variables get resolved at the time of instantiation. The job specification file contains only the values of these variables.

1. To change the presentation of the instantiation screen.

2. To add client-side validation or to introduce dynamic behavior in the instantiation screen by adding the FormAPI or JavaScript code. For more information, see Chapter 8, “Customizing the Instantiation Screen”.

1. Through UI (workflow instantiation form)

2. Through Workflow Modeler

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.


1. To change the presentation of the instantiation screen.

2. To add client-side validation or to introduce dynamic behavior in the instantiation screen by adding the FormAPI or JavaScript code. For more information, see Chapter 8, “Customizing the Instantiation Screen”.

1. Through UI (workflow instantiation form)



• • • •••


78

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.


To control the flow of a workflow. For example, you may dynamically remove task(s) from a workflow depending on the value returned by the script variable.

Through Workflow Modeler

Global 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.

The values for these variables get resolved at the time of instantiation. The job specification file contains only the values of these variables.

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)

Task Key (variable name)/value pairs that are set at the task level for use by a task.

The job specification file contains the variable element, which stores the key and the value.

To allow separate CGI tasks and external tasks to communicate with each other during the job execution.

1. Through ContentCenter interface


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.

To allow separate CGI tasks and external tasks to communicate with each other during job execution.

1. Through ContentCenter interface


Table 10 Variable Comparison (Continued)

Type Description Resolution Stage Use Case Value Assignment


• • • •••


Assigning Common Task AttributesThis 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 VPathSpecifies 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 workarea associated with the task, for example: /default/main/WORKAREA/pattismith.


• • • •••


80

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.

Brief DescriptionA 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:




DescriptionA 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.


• • • •••


Alternatively, click the Variable Type drop-down list, and select one of the following values:




NameThe 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.

OwnerUsername of the task’s 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).





• • • •••


82

LockSpecifies 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 OnlyPrevents 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 OnlyWhen 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:



• • • •••




VariablesVariables 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.


• • • •••


84

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).

NOTEVariable IDs containing the $IW value do not include the system-generated ID.

5. Click OK.

EA Finish OpDefines 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.


• • • •••


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 OpDefines 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


• • • •••


86

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


Delete



The options are:




5. Click Add.




6. Click OK.

WF Variables Finish OpDefines 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:


• • • •••


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


Delete



The options are:




5. Click Add.




6. Click OK.


• • • •••


88

WF Variables Start OpDefines 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


Delete



The options are:




5. Click Add.



• • • •••


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.

XX 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.

YY 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.

IDUnique 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.


• • • •••


90

Assigning Workflow-Specific AttributesIn 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 DescriptionDue 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.

File Comments

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).


• • • •••


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

Table 11 Workflow-specific Attributes (Continued)

Property Description


• • • •••


92

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 Developer’s 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




• • • •••


For both PreProcessor Command and PostProcessor Command properties, you can specify in-process and out-of-process commands.

PostProcessor Command

Specifies commands that are sequentially executed just before the 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 model’s task.• Remove a file attached to a workflow job.

Figure 42 PostProcessor Dialog Box

PreProcessor Command

Specifies commands that are sequentially executed just before the 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 model’s 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.




• • • •••


94

NOTEAutonomy 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 AttributesThe 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”


• • • •••


“Group Task Attributes”

“Metadata Task Attributes”

“Nested Workflow Attributes”

“Review Task Attributes”

“Submit Task Attributes”

“Update Task Attributes”

“URL Task Attributes”

CGI Task AttributesIn addition to the common attributes (described on page 79), you can assign the following task-specific attributes for CGI tasks:

Alternatively, you can set the values for all these attributes using one of the following variables:




Table 12 CGI task Attributes

Property DescriptionCGI 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.

Immediate 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).


• • • •••


96

Deploy Task AttributesIn 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

Property DescriptionDeploy 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).


• • • •••


Variables Specifies variables used by the Deploy Command attribute to invoke a deployment process using the specified values.

Figure 43 Deploy Task–Variables 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.

Table 13 Deploy Task Attributes (Continued)



• • • •••


98

• 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.




• • • •••


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.




• • • •••


10

Figure 44 OD Variables Dialog Box



0 Workflow Modeler User’s Guide

• • • •••


Email Task AttributesIn 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

Property DescriptionEmail 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.


• • • •••


10

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 Task–Variables 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.

Table 14 Email Task Attributes (Continued)



• • • •••






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.commailserver=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 User’s 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

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.

Table 14 Email Task Attributes (Continued)



• • • •••


10

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.

NOTEWhile 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.

NOTESFor 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.


• • • •••


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.


• • • •••


10

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.

NOTEThe 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">


• • • •••


<xsl:output method="html" indent="yes"/><xsl:param name="webHost" select="//WebHost"/>

<xsl:template match="/">



<header1>

<name>ReplyTo</name><value>[email protected]</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.


• • • •••


10

*/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;

}}


• • • •••


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

<?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]">


• • • •••


11

<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;


• • • •••


External Task AttributesIn addition to the common attributes (described on page 79), you can assign the following task-specific attributes for External tasks:





For an External task example, see TeamSite Workflow Developer’s Guide.

Table 15 External Task Attributes

Property DescriptionCommand 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.

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.


• • • •••


11

Group Task AttributesIn 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

Property DescriptionShared 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).


• • • •••


Metadata Task AttributesIn addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Metadata tasks:





Nested Workflow AttributesA 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 job’s completion.

Table 17 Metadata Task Attributes

Property DescriptionMD 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.

Immediate 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).


• • • •••


11

The ability for the child job to cause a transition to occur in the parent task upon the child job’s completion.

The lifetime of a nested job is dependent upon its parent task’s workflow lifetime—it 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:

Review Task AttributesIn addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Review tasks:

Table 18 Nested Workflow Task Attributes

Property DescriptionWorkflow 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.

Table 19 Review Task Attributes

Property DescriptionAvailable 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.

Available Users

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.


• • • •••


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.

Table 19 Review Task Attributes (Continued)



• • • •••


11

Alternatively, you can set the values for all these attributes (except Reviewers) using one of the following variables:




Submit Task AttributesIn addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Submit tasks:

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).

Review Type 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.Notify Reviewer

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).

Table 20 Submit Task Attributes

Property DescriptionSubmit Comment Submit comments for the associated files.

Displays a dialog box where you can enter a comment.Submit Info Submit information for the associated files.

Displays a dialog box where you can enter a comment.Override Specifies whether conflicting versions of files in the staging

area can be overwritten.The value can be True or False (the default value).

Table 19 Review Task Attributes (Continued)



• • • •••






Update Task AttributesIn addition to the common attributes (described on page 79), you can assign the following task-specific attributes for Update tasks:



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).

Skip Conflicts Specifies that files with conflicts cannot be submitted.The value can be True or False (the default value).

Skip Locked Specifies that locked files cannot be submitted.The value can be True or False (the default value).

Unlock Specifies that files be unlocked after the submit operation.The value can be True or False (the default value).

Table 21 Update Task Attributes

Property DescriptionSource Area V Path Specifies the source area from where the files are copied. This

value is required.The value can be entered directly.

Delete Specifies whether deleted files are propagated to the destination area.The value can be True (this is the default value) or False.

Overwrite Mode Specifies whether to overwrite conflicting versions of files in the destination area.The value can be True or False (this is the default value).

Table 20 Submit Task Attributes (Continued)



• • • •••


11



URL Task AttributesIn addition to the common attributes (described on page 79), you can assign the following task-specific attribute for URL tasks:

Assigning Common Link AttributesLike 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.

Table 22 URL Task Attributes

Property DescriptionURI 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:• 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.


• • • •••

Assigning Common Link Attributes

NameThe 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.

TypeThe Type property is one of the following link types:

For more information on these link types, see “Links Toolbar” on page 39.

IDThe ID property is a unique, read-only, system-generated identifier for the link. It is always the same as the link’s 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).

• Default • Success • Reset • Failure • Inactivate • Conditional • Timeout


• • • •••


12

Assigning Link-Specific AttributesThe following links have link-specific attributes that you can set in the Properties pane:

“Timeout Links”

“Conditional Links”

Timeout LinksTimeout 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.

NOTEA 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.


• • • •••

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.


• • • •••


12


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 LinksConditional 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.




True. The workflow continues over this link if the condition of the current task evaluates to True.

Working with Logical NodesWorkflow 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. 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.

NOT. None of the tasks linked to this node must be completed to activate a successor task.

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 AttributesSimilar 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


• • • •••


12

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 link’s 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).


• • • •••

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:

//TS_Server/iwadmin/main/workflowModels/STAGING/Models

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”.

NOTETo 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


• • • •••

Chapter 5: Predefined Workflow Models

12

Publish LiveSiteCS Content Workflow

Retrieval Workflow

Archival WorkflowFigure 50 illustrates the archival workflow.

Figure 50 Diagram of the Archival Workflow

1. Start archival of the Edition.

2. Email notification of the success or failure to archive the Edition to DigitalSafe is sent to users of your choice.

Start

Archive Edition

End

failuresuccess

Email notification ofthe successful archivalof the Edition.

Email notification ofthe failure to archivethe Edition.


• • • •••

Author Submit with DeployFigure 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.

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.

Review Work

Author Work

Approveiw_areaowner

reject

approve

Submitiw_areaowner

End

failure

retryDeploy Resolve Deployment

Problem


• • • •••


12

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



(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.


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

Submit

End

Approveiw_areaowner

approve

iw_areaowner


• • • •••

Author Submit with MetadataFigure 53 illustrates an author submit with metadata capture.

Figure 53 Diagram of the Author Submit with Metadata Solution Workflow



(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.


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.

Metadata

Author Work

Metadata Captureiw_user

reject

Submitiw_areaowner

End

Approveiw_areaowner

approve


• • • •••


13

Configurable Author AssignmentFigure 54 illustrates a configurable author assignment.

Figure 54 Diagram of the Configurable Author Assignment Solution Workflow

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.

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.

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).

New Job

Email to Author

Metadata Capture

reject

Submitiw_areaowner

approve

(optional)Add Files to Job

(optional)

End

failure

retry(optional) Deploy Resolve Deployment

Problemiw_areaowner

Email Notification ofDeployment Problem

(optional)

cancel job

(optional)

Author Work

Review


• • • •••

Configurable Author SubmitFigure 55 illustrates a configurable author submit.

Figure 55 Diagram of the Configurable Author Submit Solution Workflow

1. Author submits modified files, which initiates a new job and prompts the author for the following information:• Submit comment (required)• Information comment


(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.

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.


Submit

Author Work

Metadata Capturereject

Submitiw_areaowner

approve

(optional)Email to Author

iw_user

(optional)

End

failure


Problemiw_areaowner


(optional)

cancel job

Review

(optional)Add Files to Job


• • • •••


13

Configurable Default SubmitFigure 56 illustrates a configurable default submit.

Figure 56 Diagram of the Configurable Default Submit Solution Workflow

1. A user—whose work does not need review—submits 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.


Submit

Metadata Capture

Submitiw_user

iw_user

(optional)

End

failure


Problemiw_areaowner


(optional)

cancel job

Publish LiveSite Content WorkflowFor more information on the Publish LiveSite Content workflow, see the Default SitePublisher Workflows chapter in the TeamSite SitePublisher User’s Guide.


• • • •••

Publish LiveSiteCS Content WorkflowFigure 57 illustrates a Publish LiveSiteCS Content Workflow.

Figure 57 Diagram of the Publish LiveSiteCS Content 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 Production

Initiatesworkflow

Server

Deploy Deploy

End

LSCS Development

(optional)STAGING

LSCS ProductionServer

STAGING

(optional)Submit

Submit

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 Administrator’s Guide.


• • • •••


13

Retrieval WorkflowFigure 58 illustrates the retrieval workflow.

Figure 58 Diagram of the Retrieval Workflow

Configurable Workflow OverviewThe 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

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.

Start

Create/Overwrite a

success

Workarea

Edition RetrievalEmail notification ofthe failure

failure

Email notification ofthe success End

failure


• • • •••

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 FilesThis 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 OverviewEach 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.xmlAdd Files

Deployment

Email Notification

Metadata Capture

Review

configurable_default_submit_config.xmlDeployment

Email Notification

Metadata Capture

configurable_author_assignment_config.xmlAdd Files

Deployment


• • • •••


13

Metadata Capture

Review

VisualAnnotate and Configurable WorkflowsVisualAnnotate 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 Developer’s Guide.

NOTEAs VisualAnnotate is not supported on non-English servers, remove the VisualAnnotate functionality from these workflows before using them on a non-English server.


• • • •••

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 RolesThe 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 interface’s User Management tab. For more information, see the User Roles section in the User Management chapter of the unified administration interface guide.


• • • •••

Chapter 6: Managing and Configuring Workflow Models

13

WorkflowUser RoleBy 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.

NOTESThe 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 RoleAll 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.

NOTEUsers 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


• • • •••

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.


• • • •••


14

Operations Summary for Workflow RolesThe following table provides a summary of operations allowed for the WorkflowAdmin and WorkflowUser roles.

Published Workflow Models in TeamSiteWhen 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:

//TS_Server/iwadmin/main/workflowModels/STAGING/Models (shown in )

An editable version is also stored in the following Workarea:


Table 23 Operations Summary for Workflow Roles

Role Publish Workflow

Manage Workflow

Configure Workflow

Web View Workflow

Execute/Run Workflow

WorkflowAdmin Yes Yes Yes Yes YesWorkflowUser No No No Yes Yes


• • • •••


Figure 59 workflowModels Branch

WorkflowModels Branch ContentsThe 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.


• • • •••


14

Figure 60 Content Tab of WorkflowModels Branch

Config. 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.

NOTEThe 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:


• • • •••


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.

NOTEdefault_config.cfg includes a specific reference to the DTD file—http://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.


• • • •••


14

Subscribing Workflow ModelsThe 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.

NOTEConcurrent 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 FileThis 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.

model element. An example code snippet is shown below:<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.


• • • •••


active. 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. 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>


• • • •••


14

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)retrieve_job(retrieving an archived Edition from DigitalSafe)

submit (submitting files)

assign (assign button or menu item)

new_job (new job)




NOTEThe 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 element’s 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:


• • • •••


<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:


• • • •••


14

<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 regex="^/default/main/foo"/><vpath-regex regex="^\default\main\foo"/>

<vpath-regex regex="^\\default\\main\\foo"/>

<vpath-regex regex="^/default\main\\foo"/>


• • • •••


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 User’s Guide.

NOTEThe 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


• • • •••


15

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 model’s availability to one or more TeamSite branches using one of the following tabs:

Administration tab

Content tab

Managing Workflow ModelsYou 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”.


• • • •••


Figure 62 available_models.xml File

Configuring Workflow ModelsTeamSite 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 model’s 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.


• • • •••


15

Configuring Workflow Models Using the Content TabTo 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.


• • • •••


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.

For example, if you configure the samplereview workflow model for the branch //TS_Server/default/main, 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


• • • •••


15

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

NOTETinyMCE and VisualFormat are not supported in the workflow instantiation screen.

Selection Order for Custom Workflow ConfigurationWhen 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 parent’s 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.


• • • •••


NOTEThe 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”.


• • • •••


15
• • • •••

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




iwmodelc.bat command-line utilty

NOTESThe 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:


• • • •••

Chapter 7: Instantiating Workflows

15

New Job

Submit

Assign

Each of these options is described in the corresponding section that follows.

Instantiating Workflow Models With the New Job OptionThe 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.


• • • •••


Figure 67 Select a Workflow Dialog Box

NOTEThe 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:



• • • •••


16

NOTESThe 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 Developer’s Guide. TinyMCE and VisualFormat are not supported in the workflow instantiation screen.

Depending on the form’s 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 OptionThe 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.


• • • •••


Figure 70 Submit Menu Option




• • • •••


16



The workflow instantiation form appears.





Figure 73 New job Listed on the Workflow Tab


• • • •••


Instantiating Workflow Models With the Assign OptionThe 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



• • • •••


16







• • • •••

Viewing Workflow Models in ContentCenter Professional




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 InstantiationTo 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.


• • • •••


16

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).

NOTEYou 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 InstantiationAfter 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.


• • • •••


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.


• • • •••


16

Figure 81 Web View of Instantiated Workflow Model

23

1

4567

10

8 9

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.


• • • •••

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.

NOTEProperties 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.


• • • •••


17

Figure 83 Select A Workflow Screen





• • • •••

Instantiating Workflow Models from TeamSite Front Office



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.


• • • •••


17

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.


• • • •••

Instantiating Workflow Models from the Command Line

NOTEThe iwmodelc.bat command is for Windows users only. UNIX users must use the iwmodelc.sh command.


• • • •••


17
• • • •••

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.

NOTESThe following FormAPI objects are not supported in the context of workflow:

Data Capture Form• IWDatacapture.save ()


• • • •••

Chapter 8: Customizing the Instantiation Screen

17

• 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.


• • • •••

How to Customize the Instantiation Screen?

NOTEA 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.

How to Customize 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 ScreenPerform 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.

NOTEThis 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:


• • • •••


17

<ProcessModelConfiguration xmlns="http://www.interwoven.com/schema/modelConfig"/>

Customizing the Default Instantiation ScreenPerform 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.

NOTESee 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/iw-

cc/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) {...}


• • • •••


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 AvailablePerform 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/


• • • •••


18

Changing Default Property AppearanceYou 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.

NOTESThe 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.


• • • •••


Figure 87 Configurable Variable - Label (During Design in Workflow Modeler)

7. Publish the workflow.

NOTEThe 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.

NOTEEach 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>


• • • •••


18

<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>

NOTEIn 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>


• • • •••


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.

NOTESThe following widgets are supported in the custom_instantiation.cfg file:


• • • •••


18

checkbox

radio

text

textarea

selectYou 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.


• • • •••


Figure 91 Modified Appearance of the Configurable Variable (Employee)

Adding Client-Side ValidationIn 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 FieldsThe 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.

NOTEEnsure 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


• • • •••


18

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>

NOTESProvide unique IDs to each of these new fields.Start the ID with an alphabetic character.


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/>


• • • •••


<text required="t"/></item>


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); .

.

. }


10. Create a job based on this workflow.


• • • •••


18

Adding Dynamic BehaviorYou 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.

NOTESIf 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) {...}


• • • •••


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.


• • • •••


19

For example:var reviewersIdReadonlyList = "ID1194860561111";

In this code snippet, there is only one Reviewers property that is set as Readonly in the workflow.

NOTEIf 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.

NOTEIf 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.

NOTEIf 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()


• • • •••


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.


• • • •••


19

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"/>


• • • •••


</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.

NOTEIf 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.


• • • •••


19

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).


• • • •••


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(",");


• • • •••


19

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();

}


• • • •••


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

{ }

}


• • • •••


19

}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;


• • • •••


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.


• • • •••


20

NOTESWorkflow 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.


• • • •••

Chapter 9

Using Datasource Framework

IntroductionDatasource 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 DatasourcesAutonomy 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.


• • • •••

Chapter 9: Using Datasource Framework

20

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.

NOTEIf 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.

NOTEIf 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.


• • • •••

Creating a Datasource

Creating a DatasourceTo 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 InterfacesDatasource framework exposes the following interfaces, which are available for creating Datasources:

SimpleDataSource

ArrayDataSource (deprecated)

ListDataSource

MapDataSource

SortedValuesMapDataSource

NOTEThe 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.


• • • •••


20

NOTEEnsure that the datasource.jar and DataSourceFrameworkSchema.jar files are in your project’s 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.

Signaturepublic 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.

NOTEThis interface has been deprecated; use ListDataSource instead.

Signaturepublic 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:


• • • •••


sessionId. Session ID of the currently logged in user.

context. TeamSite vpath.

param. Hash map containing the additional parameters passed using the Datasource configuration file DataSourceConfig.xml or passed while calling the Datasource in the FormsPublisher DCT.

ListDataSource

You must implement this interface if you are creating a Datasource that returns a list of values. It is mostly used for populating a list.

Signaturepublic 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.

Signaturepublic 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.

Signaturepublic interface SortedValuesMapDataSource


• • • •••


20

{ 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 class. This class contains methods such as getSessionId, getServerContext, and so on.

For more information, see Javadocs of this class. The class is located under:com.interwoven.datasource.core.DataSourceContext

Registering a DatasourceEvery 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.

NOTEThe 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>

...

...


• • • •••


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.

Classname: Fully qualified name of the Datasource class.

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.

NOTESIf 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 DatasourceAfter 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: iw-home/local/config/lib/content_center/customer_src


You can now use the newly created Datasource in Workflow Modeler and DCTs.


• • • •••


20

NOTETo use the newly created Datasource in Workflow Modeler, you may have to re-login to TeamSite.

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

NOTEFor 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 DatasourcesYou 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).


• • • •••

Using Datasources in Job Instantiation Forms

Syntax<command-prefix>:<method-name>:<namespace>

where,

command-prefix. This is a constant and should always be Datasource; it is case-insensitive.

method-name .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. This is a constant and should always be Datasource; it is case-insensitive.

method-name. This is a constant and should always be executeComponent; it is case-insensitive.

component-name. This is a name of a component that you want to execute, for example, UserPicker.

param-name (optional, unless parameter value is specified). This is a name of a parameter that can retrieve a specific value.

param-value (optional). This is a value for the passed parameter.

You can call this command as follows:<inline command="Datasource:executeComponent:UserPicker: role=master:server=TeamSite"/>


• • • •••


21

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 DatasourcesIn 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 Developer’s Guide.

To support dynamic calls, the following JavaScript objects have been introduced:IWDatasource

IWMap


• • • •••


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. Name of the Datasource component to be executed, for example, UserPicker.

dsParams (optional). An IWMap object that contains a list of name-value pairs. These name-value pairs are passed to the Datasource. These values are different from the name-value pairs specified while registering the Datasource.


• • • •••


21

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 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:...


• • • •••


...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",


• • • •••


21

"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){}

}...

...


• • • •••

Chapter 10

Using Custom Code

OverviewTeamSite 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.


• • • •••

Chapter 10: Using Custom Code

21

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.

NOTEYou 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 CodeTo 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.


• • • •••

Creating Custom Code

NOTEFor 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 InterfaceTo develop custom code for an in-process command, you must implement the InProcessJavaCommand interface. For example:

public class PreProcessorURLTask implements InProcessJavaCommand{

...

...}

NOTESYour 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.


• • • •••


21

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.

NOTEYou 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)


• • • •••

Creating Custom Code

{//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 WFMTaskWFMTask[] 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.


• • • •••


22

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 CodeTo 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: iw-home/local/config/lib/content_center/customer_src


Your custom code will be called during instantiation after you add the command in Workflow Modeler for the PreProcessor Command or PostProcessor Command properties.


• • • •••

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 options—and other advanced Workflow Modeler features—are described in detail in other chapters of this book.

PrerequisitesBefore 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.


• • • •••

Appendix A: Workflow Modeler Tutorial

22

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 OverviewIn 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.

DevelopmentIn 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.


• • • •••

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 TeamSite’s 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.

DeploymentWhen 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.

NOTEWhenever 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 model’s availability to one or more TeamSite branches. For information on managing workflows, see “Subscribing Workflow Models” on page 144.


• • • •••


22

InstantiationWhen 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 WorkflowTo 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.

NOTEFor 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.


• • • •••

Creating a New Workflow

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 Tutorial–List of Workflow Elements

Element Name Element TypeStart Start EventDummy Task Dummy TaskCreate Metadata Conditional LinkNo Metadata Conditional LinkSubmit After Timeout Timeout Link


• • • •••


22

These tasks and links have been renamed using their Name attribute.

Variables OverviewIn this tutorial, you will create two new variables supported by the TeamSite workflow engine. The new variables are as follows:

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. 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.

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 a script to determine which metadata capture screen is displayed to end-users.

Submit Files Default LinkMetadata Capture Metadata TaskSubmit Submit TaskDeploy Content Conditional LinkNo Deploy Conditional LinkDeploy Task Deploy TaskGateway AND GatewayNotify Conditional LinkNotify Deploy Email TaskResolve Problems Conditional LinkResolve Default LinkResolve Deploy Problems User TaskDeploy Success Success LinkDeploy Failure Failure LinkRetry Default LinkCancel Default LinkEnd End Event

Table 24 Tutorial–List of Workflow Elements (Continued)

Element Name Element Type


• • • •••


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 AttributesIn 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 Tutorial–Workflow Attributes

Attribute Description ActionName Specifies the name that

displays in the list of available jobs in the ContentCenter interfaces

Type Sample WorkflowModel

Brief Description

Provides a brief description for the workflow model.

Type Sample Workflow.


• • • •••


22

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 AttributesIn 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.

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• ID—Type includeMetadata• Label—Type Include Metadata• Default Value—Type true• Select the Hidden and Readonly

optionsVariable 2• ID—Type includeDeploy• Label—Type Include Deploy• Default Value—Type true• Select the Hidden and Readonly

optionsVariable 3• ID—Type notifyDeployFailure• Label—Type Notify Deploy

Failure

• Default Value—Type true• Select the Hidden and Readonly

optionsThe values (true or false) set for these variable and the script used for the conditional links determine the workflow path.

Table 25 Tutorial–Workflow Attributes (Continued)

Attribute Description Action


• • • •••


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.


Table 26 Tutorial–Dummy Task Attributes

Attribute Description ActionName Specifies a name that


Type Dummy Task

Brief Description

Provides a brief description of what the task does.

Type Submit In Progress

Description Allows the job creator to enter a description of the new task

1. Click the blank field next to the Description attribute.

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.


Table 27 Tutorial–Metadata Task Attributes



Type Metadata Capture

Brief Description

Provides a brief description of what the task does.

Type Metadata Capture


• • • •••


23

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.


Description Allows the job creator to enter a description of the new job


2. In the text box of the Description dialog box, type Metadata Task.

Table 28 Tutorial–Submit Task Attributes



Type Submit

Brief Description

Provides a brief description of what the task does

Type Submit Files

Description Allows the job creator to enter a description of the new job


2. In the text box of the Description dialog box, type Submit Task.

Submit Comment

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:• ID—Type sbmtComment• Label—Type Comment• Description—Enter submit

comment

Table 27 Tutorial–Metadata Task Attributes (Continued)



• • • •••


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.


Table 29 Tutorial–Deploy Task Attributes



Type Deploy Task

Variables Enables you to set values for variables pertinent to this task

1. Click the field next to the Variables 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.

Submit Info Allows the job creator to specify submit information for the associated files.

Click the blank field next to the Submit Info attribute, and create a CONFIGURABLE variable with the following details:• ID—Type sbmtInfo• Label—Type Info• Description—Enter submit

information

Table 28 Tutorial–Submit Task Attributes (Continued)



• • • •••


23

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.


Table 30 Tutorial–Notify Deploy Task Attributes



Type Notify Deploy

Brief Description

Provides a brief description of what the task does

Type Notify Deploy Failure

Variables 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

configurableAuthorNotification.xsl, use the AuthorMailNotificationTask class.

• For reviewerNotification.xsl or configurableReviewerNotification.xsl, use the ReviewerMailNotificationTask class.

In addition, you need to do the following:


• • • •••


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 AttributesIn 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.


Table 31 Tutorial–Create Metadata Link Attributes



Type Create Metadata


• • • •••


23

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.


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;

}

Table 32 Tutorial–No Metadata Link Attributes



Type No Metadata

Table 31 Tutorial–Create Metadata Link Attributes (Continued)



• • • •••


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.


Table 33 Tutorial–Submit After Timeout Link Attributes



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.




if("$IW_CV(includeMetadata)" != "true")

{

true;}

else

{ false;

}

Table 32 Tutorial–No Metadata Link Attributes (Continued)



• • • •••


23

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.


Table 34 Tutorial–No Deploy Link Attributes



Type No Deploy.




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.


• • • •••



Table 35 Tutorial–Deploy Content Link Attributes



Type Deploy Content.




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.


Table 36 Tutorial–Notify Link Attributes



Type Notify.


• • • •••


23

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.





if("$IW_CV(notifyDeployFailure)" == "true")

{

true;}

else

{ false;

}

Table 37 Tutorial–Resolve Problems Link Attributes



Type Resolve Problems.

Table 36 Tutorial–Notify Link Attributes (Continued)



• • • •••

Saving Your Workflow Model

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 ModelIn 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.




if("$IW_CV(notifyDeployFailure)" != "true")

{

true;}

else

{ false;

}

Table 37 Tutorial–Resolve Problems Link Attributes (Continued)



• • • •••


24

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 TeamSiteWhen 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/Models. In addition, a copy of the workflow model is automatically saved to //TS_Server/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 model’s 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.


• • • •••

Testing Your Work

Testing Your WorkTest 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.

NOTEIf 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.


• • • •••


24
• • • •••

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 model’s 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.

ATTRIBUTE. Defines the attributes that are allowed for an element.

The Available_Models1.0.xsd file is available in \iwadmin\main\workflowModels\STAGING\Internal.


• • • •••

Appendix B: Workflow Schemas

24

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: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>


• • • •••

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"/>






• • • •••


24

<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="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:enumeration value="true"/>

<xs:enumeration value="false"/></xs:restriction>

</xs:simpleType>

</xs:attribute></xs:complexType>


• • • •••

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.xsdThe 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>


• • • •••


24

<xs:extension base="xs:string"><xs:attribute name="name" type="xs:string" use="required"/>

</xs:extension>

</xs:simpleContent>

</xs:complexType></xs:schema>


• • • •••

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.

NOTEFor 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 com.interwoven.datasource.ArrayDataSource;

import com.interwoven.datasource.MapDataSource;

import com.interwoven.datasource.core.DataSourceContext;import com.interwoven.log100.Logger;

import com.interwoven.log100.LoggerFactory;

import com.interwoven.cssdk.common.CSClient;import com.interwoven.cssdk.common.CSRemoteException;

import com.interwoven.cssdk.common.CSException;

import com.interwoven.cssdk.common.CSIterator;import com.interwoven.cssdk.access.*;

import com.interwoven.cssdk.factory.CSFactoryInitializationException;

import com.interwoven.cssdk.filesys.CSVPath;import com.interwoven.cssdk.filesys.CSBranch;


• • • •••

Appendix C: Datasource Example

25

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 sessionIdclient = CSClientUtil.getCSClient((String)sessionId,params);


• • • •••

} 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()) {


• • • •••


25

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


• • • •••

{ 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:


• • • •••


25

package com.interwoven.datasource.examples;

import java.util.Locale;

import java.util.Map;import java.util.Properties;

import com.interwoven.cssdk.access.CSAuthenticationException;import com.interwoven.cssdk.access.CSExpiredSessionException;

import com.interwoven.cssdk.access.CSInvalidSessionStringException;

import com.interwoven.cssdk.common.CSClient;import com.interwoven.cssdk.common.CSException;

import com.interwoven.cssdk.common.CSRemoteException;

import com.interwoven.cssdk.factory.CSFactory;import com.interwoven.cssdk.factory.CSFactoryInitializationException;

import com.interwoven.log100.Logger;

import 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


• • • •••

* @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);


• • • •••


25

}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.


• • • •••

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 Solution1 “BrowserLaunchingInitiali

zingException” message is logged in the WorkflowModeler.log file.

The which command is unable to find the browser.Ensure that: • /usr/bin is always in the PATH.• <browser executable> is present in at least one

of the locations used by the which command to find the browser.

2 In the Choose Shortcut Folder screen, after selecting a folder using the Choose button, if you click Previous, then the Cancel, Previous, and Install buttons are disabled.

Click Choose to select another location for the shortcut. This action enables the Cancel, Previous, and Install buttons.

3 Unable to find the bpmn.css file on the file system. Some of the functions may not work as expected.

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.

4 An exception occurred while creating the toolbar for tasks. Please check the log file for more information.

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.


• • • •••

Appendix D: Troubleshooting

25

5 An exception occurred while creating the toolbar for events, flows, gateways, and so on. Please 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.

6 An exception occurred while initializing the Workflow Modeler. Check the log file for more information.

The Workflow Modeler installation is incorrect or corrupt. You can find more information in the installation_directory\WorkflowModeler.log file.Reinstall the Workflow Modeler application.

7 Unable to initialize the UI appearance according to the preferences.

The Workflow Modeler application is trying to use an appearance (look and feel) that is not supported 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.swing.plaf.windows.WindowsLookAndFeel

8 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.

9 Target directory does not exist on the TeamSite server.

The workarea iwadmin/main/workflowModels/WORKAREA/iw-wa/Models is missing from the TeamSite iwadmin store.Create the missing workarea in the iwadmin store.

10 Parent directory does not exist on the TeamSite server.

The Models directory does not exist on the TeamSite server.Create the missing directory: iwadmin/main/workflowModels/WORKAREA/iw-wa/Models

11 File update failed because the target directory is read-only.

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.

Table 38 Error Messages (Continued)

No. Error/Scenario Possible Cause and Solution


• • • •••

12 Unable to save the workflow model. Please view the log file for more information.

There can be several reasons for this error. Some common reasons are:• User does not have write permission on the

directory where the workflow model needs to be stored.

• The file may be in use by some other application.You can find detailed information in the installation_directory\WorkflowModeler.log file.If the problem is one of the two listed here:• Assign appropriate permissions to save the file on

the local file system.• Close the file if it is in use by another application.

13 Unable to load the workflow model.

User does not have appropriate permissions to retrieve models from the TeamSite server.Assign appropriate permissions on the TeamSite server for the current user.

14 External workflow tasks not working in TeamSite.

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.

15 URL external tasks not working after SiteMinder integration.

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




• • • •••


26

17 Workflow Modeler cannot connect to TeamSite after SiteMinder integration.

The Workflow Modeler application uses CSSDK SOAP to connect to the TeamSite server. When a 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 agent’s 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/cmFor more information on Active Response Module and Realms, see TeamSite documentation.




• • • •••

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 server’s 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.




• • • •••


26

Debugging with WorkflowModeler.log FileLogging 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:\Interwoven\WorkflowModeler 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 such a way that the events are captured in the WorkflowModeler.log file. To do this:

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. Specifies potentially harmful situations.

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

ERROR. Specifies error events that might still allow the application to continue running.

FATAL. Specifies very severe error events that will presumably lead the application to abort.

4. Save the file.

NOTESDepending 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.


• • • •••


26
• • • •••

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 model’s 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 model’s 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.


• • • •••

:

26

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.


• • • •••

W

Index

267

• • •
orkflow Modeler User’s Guide
Symbols$IW_USER 23, 53.ipm file 56.ipm files 20.wft files 24

Aaccessing

workflow model 145active tasks 22adding

client-side validation 185dynamic behavior 188links to workflow model 58new fields 185tasks to workflow model 58

administeringworkflow model 24

alignment grid 44Allow Editing option 44AND node 40AND operator 23application setting

configuring 45application theme

configuring 47approval cycle

workflow models 24Archival Workflow 126arranging

all elements 39links 39selected elements 39

Assign optioninstantiating workflow 163

attributesdefined 23elements 23variables 23

Author Submit with Deploy 127Author Submit with Email 128Author Submit with Metadata 129author_submit_with_deploy.wft file 127author_submit_with_email.wft file 126, 128, 134author_submit_with_metadata.wft file 129available_models.xml 24

structure 144Available_Models1.0.xsd

schema 243

BBoolean operators 39branch

workflowModels 141business processes and tasks 41

CCGI task 41

attributes 95changing

application theme 47client-side validation 185color-coded links 51combining

workflow model access 145command

instantiating workflows 157workflow model access 146

Conditional link 40Config folder

workflowModels branch 142Configurable Author Assignment 130configurable author assignment workflow model 134Configurable Author Submit 131configurable author submit workflow model 134Configurable Default Submit 132configurable default submit workflow model 134

•••

26

configurable_author_assignment.wft file 130configurable_author_assignment_config.xml 135configurable_author_submit.wft file 131, 133configurable_author_submit_config.xml 135configurable_default_submit.wft file 132configurable_default_submit_config.xml 135configuration file

configurable_author_assignment_config.xml 135configurable_author_submit_config.xml 135configurable_default_submit_config.xml 135workflow 135

configuringapplication settings 45shortcut keys 48workflow 137

Content tab 152workflow validation prompt 46

convertingworkflow model 63

Create menu 41, 42creating

workflow model 224custom workflow configuration

selection order 154custom_config.xml

file 154customize

adding client-side validation 185adding dynamic behavior 188adding new fields 185Email task 103instantiation screen 178property appearance 180workflow models 24

DDatasource

interfaces 203out-of-the-box 201sample 249

defaultfile extension 56installation folder 29

instantiation screen 177JavaScript 195

functionality 188local location of workflow models 57nodes in Tree pane 50project name 49workflow model name 56, 225

Default link 40default_config.cfg

file 143Deploy task 42designing

workflow model 224Display toolbar 43displaying

Properties pane 39draft workflow model

retrieving 61Dummy task 42duplicating

elements 39

Eediting

existing workflow models 59elements

adding to workflow models 57assigning properties 23duplicating 39grouping 39Properties pane 52Tree pane 50ungrouping 39

Email task 41customizing 103

End Event node 40error messages

troubleshooting 257Error pane

illustrated 55validation results 54

executable fileWorkflow Modeler 27


• • • •••

•

extended attributesannotations 136

External task 41

FFailure link 40file

.ipm 20, 56

.wft 24available_models.xml 24configuration 20installation 27workflow configuration 20workflow templates 24WorkflowModler.exe 36

Fit to Contents tool 43

Ggrid

alignment 44show or hide 44spacing option 45

Grid Spacing option 45group

workflow model access 146Group task 41grouping

elements 39GUI elements

illustrated 38introduced 37

HHide/Show Overview option 52Hide/Show Overview tool 43Hide/Show Tree tool 43hiding

Properties pane 39hiding and showing GUI panes 43

Iicon

New 56Open 59Start Event 57

icon, workflow models 24Inactive link 40inactive tasks 22installation

file 27installing

default location 29prerequisites

Workflow Modelerinstalling 27

startup shortcut icons 30system requirements 27

Instance folderworkflowModels branch 142

instantiatingworkflow 157

instantiating workflowAssign option 163command line 172commands 157ContentCenter Professional 157ContentCenter Standard 169New Job 158Submit 160TeamSite Front Office 171

instantiation screenadding dynamic behavior 188adding new fields 185customize 178

property appearance 180default 177default JavaScript functionality 188

interfacesDatasource 203

Internal folderworkflowModels branch 143

invokinglogin screen 46


27

IWorkflow Modelerlogging into TeamSite 36

JJavaScript 195

functionality 188jobs

defined 22job instance 22job spec 25job specification 22

Llifecycle, of workflow models 19link

adding to Project pane 58links

arranging 39color-coded 51Conditional 40Default 40duplicating 39Failure 40icons illustrated 40repeating 39Success 40Timeout 40

Links toolbar 39local default location for workflow models 49Lock task 42Login dialog box 36login option 45Login to TeamSite option 45Logout from TeamSite option 45logout option 45

MMake Selection Active tool 43managing

workflow 137menus

Create 41, 42

Options 44View 44

Metadata task 41model access

combining 145command 146group 146role 146user 147

model elementattributes 144path separators 148

Model Properties node 50Models folder

workflowModels branch 143modes

Offline 36Online (logged into TeamSite) 36

modifyingapplication theme 47applications settings 45shortcut keys 48

NNested Workflow task 42New icon 56New Job

instantiating workflow 158nodes

AND 40duplicating 39End Event 40grouping 39icons illustrated 40introduced 23Model Properties 50NOT 40OR 40repeating 39Start Event 40, 57Text Annotation 40ungrouping 39Workflow Model 50


• • • •••

•

NOT node 40NOT operator 23

OOffline mode 36Online mode (logged into TeamSite) 36Open icon 59operators

Boolean 39optional elements 23Options menu

Allow Editing 44Grid Spacing 45introduced 44Login to TeamSite 45Logout from TeamSite 45Sticky Actions 45Validating Workflow 45validating workflow models 44

OR node 40OR operator 23organizing

all elements 39selected elements 39

out-of-the-box Datasource 201Overview pane

illustrated 53versus the Project pane 53

PPan tool 43, 54panes

Error 54Overview 53Project 53Properties 52Tree 49, 50

password, TeamSite 36path separators

model element 148preference

setting 45

Priority propertyProperties

Priority 53Project pane

adding link 58adding tasks 58displaying the alignment grid 44grid 45illustrated 49Options menu setting 44versus the Overview pane 53

propertiesassigning to elements 23required 58variables 23

Properties pane 52hiding 39showing 39showing or hiding 52

property appearancecustomize 180

Publish LiveSite Content Workflow 132Publish LiveSiteCS Content Workflow 133published

workflow model 140published workflow model

retrieving 61publishing

workflow model 60, 240

Rregular expressions

path separators 148repeating

elements 39required elements 23required properties 58Reset link

linksReset 40

Retrieval Workflow 134retrieving

workflow model 61


27

Review task 41role

workflow model access 146

Ssample

Datasource 249saving

workflow model 239schemas

validation against in Error pane 54selection order

custom workflow configuration 154setting

preference 45shortcut keys

setting 48shortcuts

for starting the Workflow Modeler 30starting without 36startup (illustrated) 35

showingProperties pane 39

showing and hiding GUI panes 43solutions workflows

author_submit_with_deploy.wft file 127author_submit_with_email.wft file 126, 128, 134author_submit_with_metadata.wft file 129configurable author assignment 134configurable author submit 134configurable default submit 134configurable_author_assignment.wft file 130configurable_author_submit.wft file 131, 133configurable_default_submit.wft file 132

Standard toolbar 38Start Event node 40starting the Workflow Modeler 35states of tasks 22Sticky Actions option 45Submit

instantiating workflow 160Submit task 42Subscription schema

Available_Models1.0.xsd 243Success link 40system requirements, for installing 27

Ttask

adding to Project pane 58tasks

active 22adding from the Tasks toolbar 41as business processes 41as units of work 41CGI 41defined 21Deploy 42Dummy 42duplicating 39Email 41External 41Group 41grouping 39icons illustrated 41inactive 22Lock 42Metadata 41Nested Workflow 42repeating 39Review 41states 22Submit 42ungrouping 39Update 41URL 42User 41

Tasks toolbar 41TeamSite 45

administering workflow models 24branches and workflow models 24logging into from Workflow Modeler 36new features for workflow models

24Option menu login option 45Option menu logout option 45


• • • •••

•

password 36tsadmin store 60user name 36Workflow Modeler compatibility 24workflowModels branch 60

TeamSite branches 60terminology, workflow 20testing

workflow model 241Text Annotation node 40Timeout link 40toolbars

Display 43Links 39Standard 38Tasks 41

Tree panedefault nodes 50element list 50illustrated 50

troubleshootingerror messages 257

tsadmin store 60tutorial

Workflow Modeler 221

Uungrouping

elements 39uninstalling

default program location 32icon on All Programs menu (illustrated) 35Workflow Modeler 32

Update task 41upgrading

workflow model 63URL task 42user

workflow model access 147user name

TeamSite 36User task 41

VValidate Workflow option 45Validate Workflow tool 44validating

workflow 39validating workflow models

from the Options menu 44results in Error pane 54

variable$IWUSER 53

variables$IWUSER 23introduced 23

View menu 44viewing

workflow models 165viewing workflow models

after instantiation 166before instantiation 165ContentCenter Professional 165

VisualAnnotate 136extended attributes 136introduced 136

VisualFormat 154

Wworkflow

configuration files 135configuring 137managing 137terminology 20validating 39VisualAnnotate 136

Workflow Model node 50Workflow Modeler 24

creating workflow models 22executable file 27GUI elements 37starting 35TeamSite compatibility 24uninstalling 32

workflow models 57adding link 58


27

adding tasks 58administering in TeamSite 24approval 24availability to branches 24available_models.xml 24configuring 151creating (overview) 22customizing 24defined 21differentiating from workflow templates 24editing existing 59example of (illustrated) 21icon that identifies 24instantiating 24introduced 19jobs 22lifecycle 19lifecycle (illustrated) 20managing 24, 144optional elements 23published 140publishing 24, 240required elements 23retrieving 61saving 239submitting in TeamSite 24tasks 21testing 241upgrading 63validating 54

workflow templatesdifferentiating from workflow models 24

workflowModelsbranch content 141

workflowModels branch 60Config folder 142Instance folder 142Internal folder 143Models folder 143

WorkflowModler.exe file 36

ZZoom tools 43


• • • •••

Date post:	15-Oct-2014
Category:	Documents
Upload:	dawsky
View:	236 times
Download:	1 times