Documente Academic
Documente Profesional
Documente Cultură
Administration Guide
Release 6.7.1
Service Pack 1
Windows
© 1999-2007 Interwoven, Inc. All rights reserved.
No part of this publication (hardcopy or electronic form) may be reproduced or transmitted, in any form
or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior
written consent of Interwoven. Information in this manual is furnished under license by Interwoven, Inc.
and may only be used in accordance with the terms of the license agreement. If this software or
documentation directs you to copy materials, you must first have permission from the copyright owner
of the materials to avoid violating the law which could result in damages or other remedies.
Interwoven, Inc.
803 11th Ave.
Sunnyvale, CA 94089
http://www.interwoven.com
Interwoven, Inc. 4
Contents
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Storing TeamSite Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
The user_databases.xml File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Synchronizing LDAP Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Configuring TeamSite and Active Directory to Work Without an
Anonymous Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
LDAP Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Impact of Using Non-OS Users in TeamSite . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Domains to Use for Group Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Logging Users and Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Configuring Submit Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
The submit.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Submit Filtering Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Sample submit.cfg file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Testing and Debugging Submit Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Chapter 7: Configuring Interwoven Search 137
Search Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Working with Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Indexing Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Searching Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Deleting Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Configuring the Index and Search Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Generic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Generic Agent Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Index Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Index Agent Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Search Manager Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Search Agent Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
Logging Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Field Mapping Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Configuring Date Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
Example of FieldMapping File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
The standardFields.xml File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Types of Files Being Indexed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Using CLTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Search Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
Example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
Files Not Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
Deleted Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Using the CustomDate Extended Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Deleted Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
Interwoven, Inc. 6
Contents
Interwoven, Inc. 8
Contents
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
Running ECM 1.1 and ECM 2.0 Toolkits Simultaneously . . . . . . . . . . . . . . . . .256
Import from MediaBin Requires Anonymous Access to the Transfer Directory 256
Using IP Address for WorkSite MP Cluster Prevents Trusted Login . . . . . . . . .257
Patch Required When Using Microsoft Internet Explorer 6.0 SP1. . . . . . . . . . .257
Appendix C: Content Transformation Services 259
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
Installation Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261
Editing the transform.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
URL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262
The convert URL Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
The converttask URL Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
Demonstrating the Workflow CGI Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263
Removing or Modifying Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
Using Content Transformation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
Appendix D: Next Generation Tagger GUI 267
Tagger GUI New Features and Differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268
Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272
Tagging a Single File (Next Generation Tagger GUI) . . . . . . . . . . . . . . . . . . . .272
Tagging Multiple Files (Original Tagger GUI). . . . . . . . . . . . . . . . . . . . . . . . . .273
Compatibility and Default Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273
Implications of Configuring the Next Generation Tagger GUI . . . . . . . . . . . . .274
Replicant Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
Reverting to the Original CGI Environment . . . . . . . . . . . . . . . . . . . . . . . . . . .277
Dynamic Addition of Select Box Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277
Configuring the Next Generation Tagger GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . .277
Integrating MetaTagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Creating a Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Creating a Mapping File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
DTDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
metadata-rules.dtd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
metadatacapture6.0.dtd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281
datacapture6.0.dtd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Appendix E: Using the Derby Database 291
Creating the Derby Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Setting User Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
Testing Derby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Managing the Derby Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Interwoven, Inc. 10
Contents
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335
Troubleshooting the SiteMinder Web Agent . . . . . . . . . . . . . . . . . . . . . . . . . . .335
Troubleshooting the Active Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336
Appendix I: TeamSite Service Monitor 339
Service Monitor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .339
TeamSiteService Monitor Components and Processes . . . . . . . . . . . . . . . . . . . . . .340
Installing TeamSite Service Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341
Configuring TeamSite Service Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342
iw.powerfail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342
iw.processfail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Starting and Stopping iwserver Under Service Monitor . . . . . . . . . . . . . . . . . . .344
Uninstalling TeamSite Service Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
Appendix J: Troubleshooting 345
Glossary 349
Index 361
Interwoven, Inc. 12
List of Figures
Figure 1 Using TeamSite for Web site development. . . . . . . . . . . . . . . . . . . . . . . . .23
Figure 2 Assign-edit-approve workflow model . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Figure 3 Example of a workflow for a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Figure 4 Connections from client computer to TeamSite server . . . . . . . . . . . . . . .28
Figure 5 TeamSite file system structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Figure 6 How the Event Subsystem Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Figure 7 Windows Task Manager, Processes dialog box . . . . . . . . . . . . . . . . . . . . .64
Figure 8 Component Services Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Figure 9 Default Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Figure 10 Registry Editor window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Figure 11 Expanding the directory tree of the TeamSite server . . . . . . . . . . . . . . . . .72
Figure 12 Viewing a shared access drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Figure 13 Viewing the size of the iw-store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Figure 14 Roles screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Figure 15 New Role screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Figure 16 Edit Role screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Figure 17 Add Users screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Figure 18 Search tab to search for users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Figure 19 LDAP Browse tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Figure 20 Add Multiple Users screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Figure 21 Add Multiple Users Individually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Figure 22 Groups screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Figure 23 New Group Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Figure 24 Group Properties screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Figure 25 Group Membership screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Figure 26 New Branch screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Figure 27 Manage Branches screen from the Actions menu . . . . . . . . . . . . . . . . . .103
Figure 28 Branch Properties screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
Figure 29 Branch Users and Roles screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Figure 30 High-level design of search system . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Figure 31 Tagger GUI screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
Figure 32 Metadata Capture components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
Figure 33 Alternate Tagger GUI form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
Figure 34 Browser access to iwwebd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Figure 35 Processing proxy requests through the iw.cfg file . . . . . . . . . . . . . . . . . .195
Figure 36 Local Area Network settings dialog box . . . . . . . . . . . . . . . . . . . . . . . . .201
Figure 37 Proxy failover remap diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Figure 38 ReportCenter System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
Figure 39 Relationship of Reporting database schemas . . . . . . . . . . . . . . . . . . . . . .227
Figure 40 WorkSite MP Properties Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
Figure 41 MediaBin Properties Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236
Figure 42 WorkSite MP Field in FormsPublisher. . . . . . . . . . . . . . . . . . . . . . . . . . .243
Figure 43 WorkSite MP Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Interwoven, Inc. 14
List of Tables
Table 1 Notation Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 2 TeamSite options configurable in the iw.cfg File . . . . . . . . . . . . . . . . . . 34
Table 3 Functions of Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 4 Autoprivate Encodings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Table 5 server_locale Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Table 6 Types of files controlled by [location] . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table 7 Role operations and permission checking . . . . . . . . . . . . . . . . . . . . . . 109
Table 8 Attributes for user_databases.xml file . . . . . . . . . . . . . . . . . . . . . . . . . 125
Table 9 Interpretation of Time and Date Patterns . . . . . . . . . . . . . . . . . . . . . . . 150
Table 10 Search CLTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Table 11 Index Manager Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Table 12 Search Manager Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Table 13 Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Table 14 Archived Server Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Table 15 Archived User Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Table 16 Archived Workflow Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Table 17 Archived FormsPublisher or Tagger GUI Events . . . . . . . . . . . . . . . . . 223
Table 18 WorkSite MP metadata elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Table 19 MediaBin metadata elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Table 20 Next generation Tagger GUI new features . . . . . . . . . . . . . . . . . . . . . . 268
Table 21 Tagger GUI differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Table 22 Tagger GUI schema support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Table 23 XML Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Table 24 Language Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Table 25 Code Pages for CLTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Table 26 Default Encodings for Text Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Table 27 Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Table 28 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Table 29 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Table 30 Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Table 31 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Table 32 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Table 33 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Table 34 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Table 35 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Table 36 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Table 37 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Table 38 Troubleshooting options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Interwoven, Inc. 16
About This Book
It is also very helpful to be familiar with regular expression syntax. If you are not
familiar with regular expressions, it is recommended that you consult a reference
manual such as Mastering Regular Expressions, by Jeffrey Friedl.
Some TeamSite configuration files make use of XML. For more information about
XML, consult a reference manual or the online specification at
http://www.xml.com/axml/testaxml.htm.
Notation Conventions
This manual uses the following notation conventions:
You can use the dir /x command to display the long and short versions of the file
names in the current directory.
Interwoven, Inc. 18
Default Paths
During installation default paths are used unless the installer specifies otherwise. The
default path for TeamSite is:
C:\Program Files\Interwoven\TeamSite
The installed paths are referred to in this document as iw-home and iwsearch-home.
Interwoven, Inc. 20
Chapter 1
TeamSite Overview
This chapter introduces three major TeamSite concepts and concludes with a description
of the TeamSite system architecture:
TeamSite Elements
User Roles
TeamSite Workflow
TeamSite Architecture
TeamSite Elements
The following sections describe some common TeamSite concepts that you should be
familiar with before beginning to configure TeamSite.
Content Stores
The Content Store is a large directory created by the TeamSite installation program that
contains TeamSite files and metadata. By default, the Content Store is located in
C:\iw-store.
TeamSite supports as many as eight Content Stores per TeamSite server (the first is
created automatically by the installation program, and the others are created as needed
by the TeamSite system administrator.
Branches
TeamSite provides branches for different paths of development for content. Branches
can be related to each other (for example, alternate language versions of the same Web
site) or they may be completely independent. Typically, each branch contains all the
content for a Web site or a major section of it (such as a department), or a collection of
related content (such as the program files for a software application or the image and
text files for a book). Branches can be indexed and searched.
A single branch contains archived copies of its content as editions, a staging area for
content integration, and individual workareas where users may develop content without
disturbing one another. Branches can also contain subbranches, so that teams may keep
alternate paths of development separate from each other. Content can be easily shared
and synchronized across branches and subbranches. Users may work on one branch or
on several, and the number of branches on a system is not limited.
Branches facilitate distributed workflow because they allow separate teams to work
independently on different projects. Because all branches are located on the same
TeamSite server, it is easy for one team to incorporate the work of another into their
project.
Workareas
Each workarea contains a virtual copy of all related content, which may be modified in
any way without affecting the work of other contributors. Users who have access to a
workarea may modify files within that workarea and view their changes within the
context of all related content before integrating their work with that of other
contributors. Users can lock files in each workarea, eliminating the possibility of
conflicting edits.
All changes made to files in a workarea are kept completely separate from other
workareas and the staging area until the user chooses to submit his changes to the
staging area. Within a workarea, users may add, edit, or delete files, or revert to older
versions of files without affecting other users.
Staging Areas
Each branch contains one staging area where contributors incorporate their changes
with the work of others. Users submit files from their workareas to the staging area to
integrate their work with other contributions, and test the integrity of the resulting
content. Because the staging area is an integrated component of the system, conflicts are
easily identified and different versions of the same file can be merged, rather than
overwritten.
Editions
Editions are read-only snapshots of a branch, taken at sequential points in its
development. Contributors with appropriate permissions can create new editions any
time they feel their work is well integrated, or any time they want to create an updated
snapshot of all content for reference or deployment to a production server. For Web site
content development, each edition is a fully functional version of the Web site, so that
users can see the development of the Web site over time and compare it with current
work.
Interwoven, Inc. 22
Chapter 1: TeamSite Overview
TeamSite branches contain private workareas, which contain complete virtual copies of
the Web site; staging areas, where contributors integrate their work; and editions, which
are read-only snapshots of the Web site at various points in its development. Each area
contains a virtual copy of the entire Web site. Content is submitted from workareas to
the staging area, and the staging area is then published as an edition. Older editions are
available for reference. The following diagram illustrates the use of TeamSite for Web
site development.
Production Server
TeamSite Branch
TeamSite Branch
Client
Submit
Get Latest
Workarea B Staging Area Edition 3
Publish Deploy
Production
Server
Workarea C Edition 2
Edition 1
User Roles
TeamSite ships with out-of-the-box user types, each with specific access permissions
and optimized user interfaces. These user types are known as roles. The roles are:
Reviewer
Author
Editor
Administrator
Master
WorkflowUser
WorkflowAdmin
These default roles are summarized in the following sections. Each installation can
create or modify roles to meet the needs of your organization. Refer to Chapter 5,
“Defining Users and Roles,” for details about the roles and for instructions on creating or
modifying roles.
Reviewer
Reviewers generally review work done by others. They may have approval authority.
They can browse workareas and review files and forms, search for content, and work
with tasks. Reviewers usually access TeamSite from the browser-based ContentCenter
Standard interface.
Author
Authors are primary content creators. All work done by Authors goes through an
explicit approval step. They can receive assignments from Editors, which are displayed
in task lists when Authors log in to TeamSite. Authors usually access TeamSite from the
browser-based ContentCenter Standard interface and do not need to be sophisticated
computer users.
In order to test their work, Authors have full access to the content in their Editors’
workareas, but do not need to concern themselves with the larger structure and
functionality of TeamSite. The Author role is appropriate for non-technical users or for
more technical contributors who do not need access to extended TeamSite functionality,
such as advanced version management features.
Editor
Editors own workareas. They create and edit content, just as Authors do, but they are
primarily responsible for managing the development taking place within their
workareas. This includes assigning files to Authors and submitting completed content to
the staging area, and it may include creating editions.
Interwoven, Inc. 24
Chapter 1: TeamSite Overview
Administrator
Administrators own branches. They have all the abilities of Editors, but they are
primarily responsible for the content and functioning of their branch. Administrators can
manage project workflow by creating new workareas for Editors and groups and by
creating subbranches of their own branch to explore separate paths of development.
They can assign TeamSite users to groups and assign users to roles on the branch.
Master
Master users own the entire TeamSite Content Server. They can create new stores and
perform all the functions of Editors and Administrators on any branch. They can create
or modify roles. The Master user is generally involved in the installation of TeamSite
and can reconfigure TeamSite on a system-wide basis.
Users with the Master role have access to the Administration tab within ContentCenter
Professional. This allows them to add operating system users to TeamSite, assign
groups, create and edit roles, and perform other TeamSite tasks. Most installations only
have a few Master users.
WorkflowUser
By default, all TeamSite users should be able to use workflow models. To achieve this,
the workflowModels branch of the iwadmin store is shared for iwEveryone with role as
WorkflowUser. This role has the minimum privileges required to instantiate a workflow.
WorkflowAdmin
The WorkflowAdmin role has privileges to design workflows using Interwoven
Workflow Modeler and upload them to TeamSite. They have privileges to manage,
configure, and debug the workflow models. Users who can perform these operations
include workflow developers or TeamSite administrators.
TeamSite Workflow
A workflow model is a general workflow configuration that can be used repeatedly. Each
workflow model describes a process that may include user tasks and a wide variety of
automated tasks. Workflow models are configured by the system administrator or by the
Interwoven Client Services organization.
For more information about configuring different workflow models, consult the
TeamSite Workflow Developer’s Guide.
Task:
Automated
deployment
Jobs
A job is a set of interdependent tasks. One example of a TeamSite job would be the set
of tasks needed to prepare a new section in a marketing Web site to support a new
product launch.
Each job is a specific instance of a workflow model. When a job is created, the job
creator must supply all the specific information for that job. For example, the workflow
model in Figure 2 might be used to create the job in Figure 3.
Task:
Automated
deployment
Interwoven, Inc. 26
Chapter 1: TeamSite Overview
Because jobs follow predefined workflow models, tasks cannot be added to or removed
from individual jobs, although not every possible task may actually take place for a
given job.
Tasks
A task is a unit of work performed by a single user or process. Each task in a job is
associated with a particular TeamSite workarea and carries a set of files with it. The user
or process owning a task can modify, add files to, or remove files from the task.
Tasks have two possible states: active and inactive. 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). Once the task has been activated, users or
external programs can work on it. For example, once a user task has been activated, the
user can work on the files contained in the task. Once an external task has been
activated, the appropriate external program can run on the files contained in the task.
Inactive tasks are tasks that have been completed or that have not been activated yet.
TeamSite Architecture
The TeamSite file system is composed of the TeamSite Content Server and device
driver, the TeamSite Content Store of files and metadata, a suite of command-line tools,
TeamSite CGI, proxy servers for access through the TeamSite browser-based user
interfaces (ContentCenter), and file system mounts for access through the file system
interface.
The TeamSite file system is the core of the TeamSite system, where detailed information
about the Web site, the Web assets, Web asset metadata, the production process and the
users is stored. The TeamSite file system collects and maintains metadata on TeamSite
files, directories, and areas, and allows TeamSite to process and present information
according to who is asking for the information, and under what conditions. By using an
object-oriented design within a file system architecture, TeamSite combines extensive
metadata tagging with open access and file system performance for Web content.
The client computer connects to the TeamSite server in several ways. Requests from the
browser interfaces or Local File Manager are routed through the TeamSite Web daemon,
which allows consistent views of TeamSite areas. The double proxy server redirects
hard-coded links within the Web site. Requests through the file system interface
(TeamSite shared drive) and command-line tools, which do not go through the web
server, are not routed through a proxy server.
TeamSite command
Content Command line
Store Line Tools
CSSDK Browser
Soap Interfaces
RPC Web
Server
Daemon
Local File
(port 80) Manager
Servlet
Engine
Content
TeamSite CSSDK Services
Server Content Applications
(iwserver) Web
Server iwproxy
(port 81)
Workarea
TeamSite
Virtualization
Shared
Drive (port 1080) Local File
Manager
Device
Driver
SMB
Network
Share
Interwoven, Inc. 28
Chapter 1: TeamSite Overview
default or
store name*
main
admin INITIAL
WORKAREA STAGING EDITION
It may also contain directories that hold subbranches. In the example above, the main
branch (main) contains one workarea (admin), a staging area, an initial edition, and a
subbranch (development). The subbranch contains three user-defined workareas (andre,
pat, and chris), a staging area, and two editions, one of which is user-generated
(ed_0001).
Although many of the files contained within this file system structure are virtual, they
can be treated as if they were real. They appear to exist even when you run link checkers
and scripts against them. However, staging areas, editions, and container directories (for
example, WORKAREA, EDITION, main, or development) are all read-only. Only workareas
can be written to.
Specifying VPaths
The path describing a workarea is its workarea VPath. The path describing a file’s
location within an area is its area relative path. Combined together, a file’s full VPath
describes its precise location in the Interwoven file system.
A vpath (“version path”) is a path within the TeamSite content repository, specified as
one of the following:
\store\branch+\EDITION\edition
\store\branch+\WORKAREA\area\directory*\file
\store\branch+\STAGING\directory*\file
where “+” indicates 1 or more; * indicates 0 or more, and a path may omit the elements
below it in order to specify just a directory, area, branch, or store.
STAGING is a special area that every branch has. Thus, an area is either a workarea,
specified as WORKAREA\area, or STAGING.
The path delimiter can be either “/” or “\” when specifying a TeamSite path, but will be
output as: “/” (Unix) or “\” (Windows).
Optionally, a vpath can include the server name by prepending //servername to it,
though doing so is generally not needed.
The maximum length of a vpath (including host name, branch, workarea, and folders) is
currently limited to about 600 bytes.The limitation is imposed by the maximum length
of a GET URL command supported by a browser. The 600-byte requirement provides
30 folder levels with average 20-byte folder names.
For multi-byte languages (Chinese, Japanese, Korean), the maximum length is reduced
by a factor of 9 to about 67 bytes. Each CJK character, when used as part of an URL,
must be encoded. The encoding for UTF-8 expands each character to a 9-byte sequence
of the form "%xx%xx%xx" where xx is the hexadecimal UTF-8 code.
Interwoven, Inc. 30
Chapter 1: TeamSite Overview
Related Documentation
For information and preliminary configuration information, consult the TeamSite
Installation Guide.
For more information about configuring different workflow models, consult the
TeamSite Workflow Developer’s Guide.
For more information on specifying a vpath, see the TeamSite Command-Line Tools
manual.
Interwoven, Inc. 32
Chapter 2
Most of the settings for the TeamSite server are configured in the main configuration
file, iw-home\etc\iw.cfg (default location).
[iwwebd]
http_port=80
Changes to most of these configuration settings take effect within a few minutes
(although for options that affect a user interface, users may need to clear their browser
cache in order to see the changes). For these settings to take immediate effect, use the
iwreset.exe command-line tool (CLT). Configuration options that require TeamSite to
be restarted in order to take effect are noted where appropriate.
NOTE
If section headings are duplicated in the iw.cfg file, some or all of the values given for
the parameters in one copy of the section will be ignored. Verify that a section heading
only appears once in your iw.cfg file.
Location of iw.cfg
If iw.cfg does not exist in the default location, TeamSite looks for it in the following
locations, in the following order:
iw-home\local\etc\iw.cfg
iw-home\etc\iw.cfg
If iw.cfg is not found in any of these places, TeamSite assumes the default values for
iw.cfg settings.
Interwoven, Inc. 34
Chapter 2: Configuration File Overview
Interwoven, Inc. 36
Chapter 2: Configuration File Overview
Interwoven, Inc. 38
Chapter 3
This chapter contains the following information on configuring the TeamSite server:
Configuring User Interface Functionality
Configuring Server Functionality
Working with the Utility Service
Enabling the Event Subsystem
Configuring Server Performance
Configuring the TeamSite Server Locale
Configuring FormsPublisher
TeamSite Embedded Failsafe
If the [iwcgi] section of iw.cfg does not contain this line, add it as follows:
[iwcgi]
domain_list=This Domain,That Domain,The Other Domain
NOTES
You can include any number of domains in this list.
If your [iwcgi] section does not contain a domain_list, domains are automatically
detected and displayed.
Domains are listed in alphabetical order, not the order listed in iw.cfg.
Do not confuse this line with the domain_list line in the [iwserver] section of
iw.cfg.
Optional entry that specifies whether or not to use a mapping file to configure
individual email addresses or aliases.
Interwoven, Inc. 40
Chapter 3: Configuring the TeamSite Server
email_mapping_file=path_to_file
Optional entry that specifies the location of the mapping file to use (a sample file is
located in iw-home\local\config\wft\email_map.cfg).
debug_output=path_to_file
An optional entry that specifies that debug output will be sent to the file location
indicated.
Use the valid_domains setting to provide a comma-separated list of valid domains for
URLs in TeamSite ContentCenter. By default, the TeamSite server host name, domain
and IP address are automatically included and do not have to be specified here.
[teamsite_servlet_ui]
valid_domains=domain,domain,domain
By default, old_mod_times is set to true, and the modification time of a file is the time
a user last changed the file's contents. Submitting a file to the staging area or updating it
into your workarea through Get Latest does not affect the modification time; the
modification time will be the same as the modification time of the source file. If
old_mod_times=false, the modification time of a file is the later of the time (1) a user
last changed its contents and (2) the time the file was updated into the workarea (with
get-latest, copy-to-area, or iwupdate operations) or submitted if it is a file in the staging
area or an edition.
This distinction is important when you are using TeamSite for SCM. A lot of build tools,
such as UNIX make, rely on timestamps to determine whether it needs to regenerate
object files. They typically compare the modification time of the source file with the
modification time of the corresponding object file and decide to rebuild the object file
only if the source file has a later modification date. If you use such a build tool out of a
TeamSite workarea with old_mod_times=true (the default), you could have problems if
your workarea is updated before a build.
For example: You run make to recompile file1.c in your workarea. This generates
object file file1.o, with the current time as its modification time. However, yesterday
another user submitted another version of file1.c, but you did not update your
workarea before running make. This newer version of file.c has a modification time
from yesterday (when it was modified before being submitted). If you now update your
workarea, you will get the new version of file1.c, but its modification time would still
be the time from yesterday. By default, with old_mod_times=yes, the modification time
of a file has no correlation to the time you update your workarea. If you run make again,
it would fail to recompile the new version of file1.c, because the modification time of
file1.o is later than the modification time of the newer file1.c. This can be fixed by
setting old_mod_times=false. The modification time of file1.c would then show in
your workarea with the time when you did the get-latest procedure, and make would
know to regenerate the object file.
The old_mod_times setting only affects the modification time displayed through the file
system interface and not through ContentCenter. The modification time of a file in a
user interface is always the time the contents changed.
You can set up TeamSite so that the content modification timestamp is updated
whenever the EAs are modified using the force_EA_mod_times option in the iw.cfg
file.
[iwserver]
force_EA_mod_times=true
To change the encoding of the iw.cfg file, add the following lines to the beginning of
the file:
[iwcfg]
encoding=encoding_type
Interwoven, Inc. 42
Chapter 3: Configuring the TeamSite Server
NOTE
This must be the first section in the iw.cfg file—no other entry can precede it.
For more settings in [iwwebd], refer to Chapter 9, “Configuring the TeamSite Web
Daemon and Proxy Server.”
A branch’s locking model is set when the branch is created. Different branches on one
TeamSite server may use different types of locking. All workareas on a branch use the
same type of locking. The type of locking a branch uses cannot be changed after the
branch has been created.
You can also set these locking models, plus the option None, when creating roles. Since
a branch and a role can have separate file locking, TeamSite uses the more restrictive of
the role locking and branch locking when determining what locking model is in place
for a particular user on that branch. TeamSite also evaluates whether a user has multiple
roles on the branch and uses the least restrictive locking specified in a role. It then
compares locking for the role with the branch locking model and applies the most
restrictive model.
Role locking is useful if you wanted to have a different locking model for users having
different roles on a given branch. For example, the author role may have mandatory
write locking, implying that users who are authors in a branch that has submit locking
should have the lock on the file and lock the file in their workarea before editing the file.
This lowers the need for authors to deal with conflict resolution and merging while other
roles enjoy a more lenient model.
Submit Locking is the least restrictive followed by Optional Write Lock and Mandatory
Write Lock.
Interwoven, Inc. 44
Chapter 3: Configuring the TeamSite Server
TeamSite enables you to specify the locking model of each branch at the time that it is
created. However, the main branch is created automatically by the TeamSite installation
program and it uses the default option of Submit locking.
Creating a new Content Store also creates a new main branch. You can specify which
locking model to use for the main branch of a new Content Store by completing the
following procedure:
1. Edit the main_lock_model line in the [iwserver] section of iw.cfg as follows:
[iwserver]
main_lock_model=locking_model
You can configure TeamSite to allow only the owner or creator of the lock to submit a
locked file to the staging area (as opposed to allowing any member of the workarea
where the file is locked). To configure this option, add the following line to the
[iwserver] section of iw.cfg:
[iwserver]
only_lock_owner_creator_submits=yes
Locking Behavior
In TeamSite 6.5 and earlier, Mandatory Write Lock implied that the file was locked in
that workarea. Since TeamSite 6.7, Mandatory Write Lock implies that the file is locked
in that workarea and that the user trying to edit is also the lock owner. To get TeamSite
6.5 Mandatory Write Lock model behavior in TeamSite 6.7, set this option to true.
[iwserver]
lockmodel_compatibility=true|false
Comparing Files
When TeamSite is comparing two versions of a file, it checks the version history chain
to determine a common ancestor for the two versions. You can specify the number of
versions to check using the compare_search_limit option in iw.cfg, as follows (the
default is 20):
[iwserver]
compare_search_limit=20
Autoprivate Feature
TeamSite’s Autoprivate feature enables you to prevent certain file types and directories
from being submitted to the staging area or copied during a Copy To operation.
Examples of these files may include temporary files, backup files and Macintosh
resource forks. File types specified in the Autoprivate configuration file automatically
get marked Private.
NOTE
Changes to Autoprivate only apply to files or directories that are created or renamed
after the changes are made. Changes do not apply to existing files.
Files and directories may also be specified Private by turning on the Do not submit
check box in the Properties screen in ContentCenter.
Each section is set off by parentheses on their own lines, and the file begins with a “ ( ”
(open parenthesis) on its own line and ends with a “ ) ” (close parenthesis) on its own
line.
Interwoven, Inc. 46
Chapter 3: Configuring the TeamSite Server
((filenamepattern)(#_characters_to_match_at_beginning)
(#_characters to match_at_end))
For example, to have Autoprivate detect any file or directory that ends with .frk, add
the following entry:
((x.frk)(0)(4))
meaning to match zero characters at the beginning of the name and the four characters
(.frk) specified at the end of the name.
To set Autoprivate to detect any filename that ends in .backup.fm, add the following
entry:
((x.backup.fm)(0)(a))
where 0 specifies not to match any characters at the beginning, and a (hexidecimal 10)
specifies to match ten characters at the end of the filename.
Entries in the second section specify exact filename matches, set off by double
parentheses. These filename matches apply across all directories in all workareas on the
TeamSite server. For example, if autoprivate.cfg includes:
((test))
then all files and directories named test that are created after this line is added, in all
directories in all workareas in TeamSite, will be marked private.
((Network\20Trash\20Folder))
Encodings are represented as \xx where xx is the hex value of the corresponding ASCII
character. The following table shows the mappings for the six special characters.
Encoding examples:
For changes to autoprivate.cfg to take effect, restart the TeamSite server or use the
iwreset command-line tool.
Interwoven, Inc. 48
Chapter 3: Configuring the TeamSite Server
All iwat triggers and workflow external tasks are executed by iwutild. However, the
programs executed by iwat triggers and workflow external tasks need not be specified
in iwutild.cfg.
The iwutild.cfg file can be edited to modify error logging, executed commands, and
file locations. The following code shows the default iwutild.cfg file.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iwutild SYSTEM "iwutild1.0.dtd">
<iwutild>
<file-list>
<file
name="iwcfg"
path="E:\TeamSite\etc\iw.cfg"/>
<file
name="iwserverlog"
path="E:\TeamSite\local\logs\iwserver.log"/>
<file
name="iwtracelog"
path="E:\TeamSite\local\logs\iwtrace.log"/>
<file
name="iweventslog"
path="E:\TeamSite\local\logs\iwevents.log"/>
<file
name="templatingcfg"
path="E:\TeamSite\local\config\templating.cfg"/>
<file
name="fileencodingcfg"
path="E:\TeamSite\local\config\file_encoding.cfg"/>
<file
name="availabletemplatescfg"
path="E:\TeamSite\local\config\wft\available_templates.cfg"/>
</file-list>
</iwutild>
The iwutild.cfg file uses the port-ssl option to set the port number to be used for the
iwutild service. The default value is 6689. This value can be changed during the
TeamSite installation.
If you change the port number in iwutild.cfg after installation, you need to update the
cssdk.cfg file and set the following option in iw.cfg so that iwserver can find the
iwutild service.
[iwserver]
utild_ext_tasks_portnum=portnumber
The iwutild.cfg file allows you to select which commands or scripts use
impersonation and which are to run as System. The iwptcompiler is one of these
commands. Disable impersonation for a command by specifying impersonate="false"
for the command.
The iwutildreset CLT can force iwutild to re-read the iwutild.cfg file. The
iwutildstat CLT provides status information for the iwutild server. Refer to the
TeamSite Command-Line Tools for information on these CLTs.
Interwoven, Inc. 50
Chapter 3: Configuring the TeamSite Server
The Event Subsystem uses a JMS (Java Message Service)-compliant model of message
delivery, which is based on three concepts:
Events – Synonymous with message. Events are the result of changes, end-user
actions, or occurrences in a Publisher program. For example, TeamSite server
events include (but are not limited to):
CreateBranch
Submit
TaskActivate
Events have names and properties, such as user, role, and timestamp, that are
represented in the Event Subsystem as attribute/value pairs.
A subscriber can be set up to perform functions after a TeamSite event occurs. For
example, an index can be updated after files are submitted.
Publishers. Applications that send events to the Event Subsystem. The Event
Subsystem then passes the events to Subscribers that have registered to receive
them.
Subscribers. Applications that register with the Event Subsystem to receive events.
Subscribers can filter events so that they receive only the ones they need.
TeamSite Search
Server Proxy Servlet
ReportCenter
Message Service
Implementation
The Event Subsystem is configured by the TeamSite installer. Refer to the TeamSite
Installation Guide for information.
If the line is not included, add it to the iw.cfg file. Save and close the file; issue the
iwreset CLT.
NOTE
The iw.cfg file may contain other commented-out settings in the [event_subsystem]
section; ignore these settings.
When you installed TeamSite, you were asked for information about your database
system. If that process was successful and no warning messages were issued, your
database system is active. If that information was not provided or if the database system
was not configured properly, perform the following steps to set up RDBMS-based event
persistence:
1. Make a copy of the following file:
iw-home\eventsubsystem\conf\jmsconfignew_rdbms.xml.example
Interwoven, Inc. 52
Chapter 3: Configuring the TeamSite Server
Change the values for the driver, url, username, and password attributes according
to your needs.
4. Copy the appropriate JDBC drivers into iw-home\eventsubsystem\lib.
Run the script that corresponds with the database you use.
Oracle create_oracle.sql
DB2 create_db2.sql
MsSQL create_sqlserver.sql
MySQL create_mysql.sql
Derby create_derby.sql
You can execute the SQL script using a client utility supplied by the database
vendor. For example, if you are using an Oracle database, use SQL*Plus. If you are
using Microsoft SQL Server, use Query Analyzer.
If you are running this script for the first time, the Event Subsystem tables may not
be present and you will receive an error message. Ignore the error message and
continue executing the script.
6. Configure Event Subsystem logging by editing the log4j.xml file in
iw-home\eventsubsystem\conf. Only the location and name of the configuration
file need to be specified. The Event Subsystem uses log4j for logging. More infor-
mation about this can be found at www.apache.org/log4j/docs/.
7. Start the Event Subsystem by selecting Control Panel > Services.
8. Restart the Interwoven servlet engine to ensure that the Event Subsystem servlet is
started; this can be done by issuing an iwreset -ui command.
This has to be done manually and is required if MsSQL 2000 or 2005 is being used as
the event subsystem database.
Script for the workaround for MsSQL transactional deadlocks under load:
exec sp_rename @objname='messages',
@newname='messages_table', @objtype = 'OBJECT'
exec sp_rename @objname='message_handles',
@newname='message_handles_table', @objtype='OBJECT'
Configuring Microsoft SQL Server 2005 for Use with the Event Subsystem
NOTE
To use the Microsoft SQL Server 2005 with TeamSite Reporting, see “Configuring
Microsoft SQL Server 2005 for Use with TeamSite Report Center” on page 230.
To use the Microsoft SQL Server 2005 with the TeamSite Event Subsystem, install and
configure MSSQL Server 2005 manually as follows:
1. Stop the Interwoven Event Subsystem Service. Use the Services control panel.
2. Uninstall the Event Subsystem Service:
iw-home\iw-perl\bin\iwperl.exe iw-home\install\install_eventsubd.ipl -u
3. Obtain the MSSQLServer 2005 JDBC driver jar file sqljdbc.jar.
4. Copy the file into the iw-home\eventsubsystem\lib directory.
5. Back up the iw-home\eventsubsystem\conf\jmsconfignew.xml file.
6. Copy the iw-home\eventsubsystem\conf\jmsconfignew_rdbms.xml.example file
to iw-home\eventsubsystem\conf\jmsconfignew.xml.
Interwoven, Inc. 54
Chapter 3: Configuring the TeamSite Server
The Event Subsystem clears all messages from the database once they reach a certain
age, regardless of their delivery status. This helps control the database size. The JMS
persistence can cause the database to grow significantly if subscribers such as Search or
Reporting are down. As the proxy servlet web application publishing to JMS server, the
expiry time is added in the iw_bridge_cfg.xml config file (refer to the TeamSite
Installation Guide for information on iw_bridge_cfg.xml):
iw-home\httpd\webapps\eventsubsystem\WEB-INF\iw_bridge_cfg.xml
For example:
<iwovJMS
classpath="C:/Interwoven/TeamSite/eventsubsystem/lib/openjms-client-0.7.6
.1.jar"
initialContextFactory="org.exolab.jms.jndi.InitialContextFactory"
url="tcp://localhost:3035/"
factoryName="JmsTopicConnectionFactory"
topic="Interwoven"
waitTime="300000"
expiryTimeInDays = "2">
</iwovJMS>
The expiryTimeInDays property in the iwovJMS tag can be used for setting up the expiry
time in days; specify whole positive numbers only. The default is 4 days. Specifying 0
or -ve value means the messages do not expire.
If you are using DataDeploy, enable DAS by performing the following steps:
1. Stop the TeamSite services.
2. Make the following changes to the
iw-home\httpd\webapps\eventsubsystem\WEB-INF\iw_bridge_cfg.xml file.
Add dasTopic="TeamSite_User" property to the iwovJMS tag.
For example:
<iwovJMS
classpath="_IW_HOME_/eventsubsystem/lib/openjms-client-0.7.6.1.jar"
initialContextFactory="org.exolab.jms.jndi.InitialContextFactory"
url="tcp://localhost:3035/"
factoryName="JmsTopicConnectionFactory"
topic="Interwoven"
dasTopic="TeamSite_User"
expiryTimeInDays="4"
waitTime="300000">
</iwovJMS>
Interwoven, Inc. 56
Chapter 3: Configuring the TeamSite Server
baseLogName="_IW_LOG_DIR_/iwui/iwevents/TeamSiteClientEvents"
stateFileName="_IW_HOME_/servletd/logs/iwclientDASproxy.properties"
waitTime="30000"
isDAS="true" />
<logFile name="TeamSiteDASLog"
baseLogName="_IW_LOG_DIR_/iwevents/TeamsiteEvents"
stateFileName="_IW_HOME_/servletd/logs/iwDASproxy.properties"
waitTime="30000"
isDAS="true" />
3. Restart the TeamSite services.
4. The DAS enabling can be verified by looking into the messages_handles database
table for the messages published for the DAS.
example: Pseudo Query:
Select * from message_handles where destinationId in
(Select destinationId from destinations where name ='TeamSite_User')
Cache Size
To set the TeamSite cache size, edit the cachesize line in the [iwserver] section of
iw.cfg. If a comment symbol (#) begins the line, remove it. If this line does not appear
in your iw.cfg file, add it as shown below. The initial cache size setting should be
approximately three times the number of files and directories on the largest branch.
For example, if the largest branch contains 15,000 files and directories, you should set
cache size to 45000 as follows:
[iwserver]
cachesize=45000
Minimum cache size is 1000; maximum is 400,000 entries. Each cache line takes a
maximum of 1KB of physical memory. Recommended physical memory is cache size
times 1KB plus an additional 25% as a safety margin. In the example shown below,
physical memory would be (45,000 * 1KB) + 11MB = 56MB. If you encounter a great
deal of memory swapping, you should either reduce the cache size or install more
memory.
NOTE
The value of cachesize is not the amount of memory that is used, but the number of
objects kept in the cache.
You must restart the TeamSite server for this change to take effect.
External tasks run as the task owner and are restricted to the permissions associated with
the task owner. If the impersonate_without_password option in the iw.cfg file is set to
false, the behavior from earlier TeamSite versions in which the iwauth cookie carries
the password is in effect. This applies only to iwptcompile and CGIs and has no effect
if impersonation is turned off for a given command in the iwutild.cfg file.
[authentication]
impersonate_without_password=true|false
Throughput Monitors
Throughput monitors can be used in conjunction with the iwstat CLT to monitor
system status and performance. By default, the throughput monitoring is set to off. To
turn on throughput monitoring edit the thruputmonitoring line in the [iwserver]
section of iw.cfg as follows:
[iwserver]
thruputmonitoring=on
After turning monitoring on, the five default throughput monitors are activated. They
return system statistics over the previous minute, 15 minutes, hour, eight hours, 24
hours, and for the entire time that the system has been running.
You can deactivate any of the default monitors by adding a comment mark (#) to the
beginning of the line. The last two throughput monitors can be configured with custom
time intervals.
[iwserver]
thruputmonitoring=on
thruputmonitor1=1 # 1 minute
thruputmonitor2=15 # 15 minutes
thruputmonitor3=60 # 1 hour
thruputmonitor4=480 # 8 hours
Interwoven, Inc. 58
Chapter 3: Configuring the TeamSite Server
thruputmonitor5=1440 # 24 hours
thruputmonitor6=-1 # forever
thruputmonitor7
thruputmonitor8
The disklow lines in the [iwserver] section of iw.cfg control the behavior of disk low
detection. They are shown here with their default settings:
[iwserver]
disklow_mbytes=50
disklowpercent=10
disklow_mbytes—Defines the freeze threshold in MB for the TeamSite server. The
TeamSite server does not allow any write operations if the disk space falls below
this setting.
disklowpercent—Defines the percentage of free disk space that is considered low.
NOTE
If the server detects a low-disk state based on the threshold set in iw.cfg, it does not
allow you to manually unfreeze the Content Store with the iwfreeze command.The
TeamSite server does not allow disklowpercent to go below 2 percent. To change these
settings, edit the setting on any of these lines.
This setting is automatically created in the iw.cfg file when iwserver is started. The
system locale is determined by reading the System Locale setting in the Regional
Settings control panel. Once the server_locale setting exists in the iw.cfg file, it is
used to determine the TeamSite server’s system locale at every invocation of iwserver.
If this setting is not present, iwserver determines its locale from the System Locale
setting in the Regional Settings control panel.
NOTE
While this setting can be user-modified, it is designed to serve as reference as to the
locale in which iwserver is currently running. If you have a situation where you want to
force iwserver to run in a particular locale (independent of the System Locale setting)
you can stop the TeamSite server, manually edit the server_locale line, then restart the
TeamSite server.
The locale in which the server operates (as defined by the server_locale entry),
effectively determines the locale of the TeamSite IFS. For example, if iwserver runs
under the Japanese_Japan.Shift_JIS@Binary locale, all file and directory names are
encoded in Shift_JIS encoding.
The server_locale setting in the iw.cfg file can contain any of the locales listed in the
following table (note that these settings are Interwoven naming conventions—the
operating system locales to which they map are also contained in the table):
Configuring FormsPublisher
The following sections describe how to configure FormsPublisher to provide an
example templating environment. After the initial setup is complete, you can:
Use the example templating environment to become familiar with the
FormsPublisher end-user features.
Customize the example environment to create your site-specific configuration.
Interwoven, Inc. 60
Chapter 3: Configuring the TeamSite Server
workarea to a permanent branch. You can then submit the workarea to the staging
area and use Get Latest to propagate the setup to other workareas on the branch.
2. Read the iw-home\examples\Templating\README file (and README files in the each
subdirectory) for details about directory contents and last-minute information that
might not be documented elsewhere.
3. Copy the contents of iw-home\examples\Templating\templatedata (including the
templatedata directory itself) to the workarea determined in step 1.
Ensure all users have read and write permission for each file.
Do not change any directory or file names.
The end result should be workarea_name/templatedata/...
4. Edit the templating.cfg file to specify the branches where FormsPublisher is used.
5. Optionally, edit the available_templates.cfg file as described in the Workflow
Developer’s Guide.
To change the directory in your workareas where templating content will reside, modify
the /etc/iw.cfg file. The default directory is templatedata.
[teamsite_templating]
data_root=directory
A manifest file is created at the top of the user’s workarea when a preview is performed.
Included in the manifest file is a list of files created during a preview. When a new
preview is requested, the manifest file is checked and the temporary files listed in it are
deleted. The manifest file is also deleted. The preview is then generated and a new
manifest file is created.
The preview_system_directory parameter in the iw.cfg file puts preview system files,
such as manifest files, in a directory other than data_root (templatedata).
[teamsite_templating]
preview_system_directory=directory
Data records are normally written so that all content appears on a single line. You have
the option to print so that each new XML element in a data record starts on a new line,
indented. To enable this type of printing, include the following line in the /etc/iw.cfg
file.
[teamsite_templating]
pretty_print_dcrs=true
Interwoven, Inc. 62
Chapter 4
This chapter describes configuration settings and procedures that can be used to manage
and enhance your server performance. While there are many variables that contribute to
your TeamSite server performance, the information contained in this section should
prove useful to most TeamSite administrators. The following topics are discussed:
Verifying Server Operation
Starting and Stopping the TeamSite Server
Checking Request Handling
Verifying the Server Mount
Locating the Installation Directory
Reviewing TeamSite Log Files
Monitoring the Server Load
Reconfiguring iwwebd to Recognize a New IP Address
Managing Disk Space
Monitoring Disk Space Usage
Interwoven, Inc. 64
Chapter 4: Managing the TeamSite Server
5. Select Interwoven TeamSite from the list of services, and click Stop.
6. Select Interwoven Proxy from the list of services, and click Stop.
7. If you are using OpenDeploy, select Interwoven OpenDeploy from the list of ser-
vices, and click Stop.
8. To restart TeamSite, you must reboot the server host machine.
Do not attempt to restart the Interwoven TeamSite service from the Services control
panel. By default, TeamSite is configured to start automatically on reboot.
NOTE
If you stop the TeamSite server while there are open handles (for example, someone has
a file from the Content Store open, or is exploring it, or it is remotely mounted), either
of the following entries may be written to iwtrace.log:
If the TeamSite server is responding, you will see a response similar to this:
iwserver: 6.7.0 Build 61235 Interwoven 20060328
If the server does not respond or stops, then the server is not handling requests correctly.
Restart the server as described on page 65.
If you did not use the default installation location, check the iwmount line in the
[locations] section of iw-home\etc\iw.cfg to find out what drive letter was used.
Use Windows Explorer to verify that the drive is mounted as an IFS volume. If it is not,
reboot the server.
NOTE
If you are using IIS, the Microsoft Management Console may show an error flag next to
the IFS volume when you reboot the Windows server. This does not necessarily indicate
an error. Because IIS starts before TeamSite, it cannot find the IFS volume when it first
starts, and it does not remove the error even after TeamSite starts and the IFS volume
appears. Once the TeamSite server does start, you can navigate to the IFS volume and
see your content files in your backing store.
Interwoven, Inc. 66
Chapter 4: Managing the TeamSite Server
For detailed information about iwgethome and all TeamSite CLTs, refer to the TeamSite
Command-Line Tools manual for your platform.
NOTE
The default locations of files is iw-home\local\logs.
Configuration Log
The configuration log records the ports assigned to TeamSite during the installation
procedure, the host IP address, and whether auto-configuration of IIS is enabled. The
file is called config_summary.log and, by default, is located in iw-home\install\.
Server Log
The server log records the state of TeamSite over time—including, but not limited
to—when the TeamSite server is started, stopped, and mounted. The file is called
iwserver.log and, by default, is located in iw-home\local\logs. If the file is not in the
default location, you can locate it using the CLT iwgetelog.
Master users can also view the server log from the Administration tab by selecting
TeamSite Admin > Logs > Server Log.
Trace Log
The trace log records any irregularities on the TeamSite server. It is primarily used by
Interwoven Consulting Services to diagnose system performance issues. The file is
called iwtrace.log and, by default, is located in iw-home\local\logs. If the file is not
in the default location, you can locate it using the CLT iwgettrace.exe.
Master users can also view the trace log from the Administration tab by selecting
TeamSite Admin > Logs > Trace Log.
Events Log
The iwevents.log records TeamSite activities—including, but not limited to—file
submits, edition, branch and workarea creation, and DiskLow, Freeze, ShutDown,
StartUp and Thaw events. It is used with certain TeamSite triggering scripts. By default,
the file is located in iw-home\local\logs. If the file is not in the default location, you
can locate it using the CLT iwgetelog.exe. The entries in your iwevents.log file will
be similar to these:
event-specific information
(the example line wrapped)
The last sample line states that on Friday August 24, 2007, the user tom, who is logged
in with the role of editor, took ownership of task 0x3ffd8 (or 262104). The task is
labeled Editor Review in job 0x3ffcf (or 262095) and is part of a workflow named CPE
Workflow. The user tom assigned ownership to the task to tom (himself).
Master users can also view the event log from the Administration tab by selecting
TeamSite Admin > Logs > Event Log.
Interwoven, Inc. 68
Chapter 4: Managing the TeamSite Server
Workflow Log
The workflow log records the output from workflow runtime diagnostics. The file is
called iwjoberrors.log and, by default, is located in iw-home\local\logs. The log file
contains entries when the following events occur:
When the TeamSite server encounters an error compiling a workflow, including:
a task’s named owner has insufficient privileges to its areavpath
an areavpath does not exist
This does not include every workflow specification that has errors—some errors
occur on the client.
When externaltasks have trouble forking.
When the workflow engine has problems while running tasks in a job, including:
attempting to create a task variable that already exists.
attempting to add a file to a task that is already in its file list.
Configuration is controlled by the [iwserver] section in the iw.cfg file. See the
Windows Event Viewer documentation provided by its manufacturer for usage details.
See TeamSite Command-Line Tools for details about iwstat.exe usage and output.
Interwoven, Inc. 70
Chapter 4: Managing the TeamSite Server
File Locations
The [locations] section of iw.cfg must be updated if you change the locations of
certain TeamSite files and directories from their default locations. To change the
location of one of the following files, remove the comment (#) marks from its line and
edit the line to point to the new location (ensure that the [locations] line is not also
commented out). After restarting, TeamSite looks for the specified file or directory in
the new location.
[locations]
iwbin=C:\Program Files\Interwoven\TeamSite\bin
iwmount=Y:
iwcgimount=Y:
iwroles=C:\Program Files\Interwoven\TeamSite\local\config\roles
iwstore=C:\iw-store
iwsubmitconfig=C:\Program Files\Interwoven\TeamSite\local\config\submit.cfg
iwautoprivate=C:\Program
Files\Interwoven\TeamSite\local\config\autoprivate.cfg
iwlogs=C:\Program Files\Interwoven\TeamSite\local\logs
iwconfigs=C:\Program Files\Interwoven\TeamSite\local\config
iweventlog=C:\Program Files\Interwoven\TeamSite\local\logs\iwevents.log
iwtracelog=C:\Program Files\Interwoven\TeamSite\local\logs\iwtrace.log
iwdeploylog=C:\Program Files\Interwoven\TeamSite\local\logs\iwdeploy.log
where:
NOTES
The TeamSite shared drive location can be configured to any drive letter (for
example, to change the shared drive to X:, edit the [locations] section to contain
the line iwmount=X:). If you change the shared drive location, you must update the
webserver alias (iw-mount) accordingly. After changing shared drive locations, you
must reboot the server for the changes to take effect.
If you change the location of one of the logs and no file with the specified name is
present in the new location, a new file is created.
To change the location of the TeamSite Content Store, you must edit the Registry.
Figure 10Registry Editor window
Interwoven, Inc. 72
Chapter 4: Managing the TeamSite Server
When you browse the contents using the new mounted drive, you will notice
improved performance. Users accessing the TeamSite file system interface remotely
(over a network) are not affected.
NOTE
You can determine their locations by issuing the iwstore or iwmount CLTs.
The amount of disk usage for your selection is shown in the bottom of the window:
Size of C:\iw-store
Deleting Editions
To reclaim some disk space, you can delete old editions, which also deletes all files
contained in that edition and all intermediate submissions between publication of
editions. You should be aware that if a file is contained in more than one edition and not
all of these editions are deleted, the file is not deleted; only the pointer to the file in the
deleted edition is deleted. Therefore, you may not save as much space as you anticipate.
NOTE
You can also delete editions using the iwrmed CLT as described in the TeamSite
Command-Line Tools.
Metadata Forking
Metadata forking conserves disk space by reducing the number of files whose content is
duplicated throughout the TeamSite Content Store. That is, if you have an old version of
a file in one branch, and an identical version on another branch, the same data may
appear twice in the Content Store. Metadata forking is accomplished by running the
iwfsshrink CLT and results in no user-visible changes to the TeamSite virtual file
system (for example, file histories are not changed).
Interwoven, Inc. 74
Chapter 4: Managing the TeamSite Server
The iwfsshrink utility must be run while the TeamSite server is running; however,
TeamSite may experience some performance degradation while it is running. Also,
iwfsshrink may not remove all duplicates (for example, it does not remove any
duplicates created by TeamSite users while the utility is running). The iwfsshrink
utility should be run every few months.
1. Start the iwfsshrink utility from the command line:
>iwfsshrink run storename
3. Optionally, you can pause the operation with the pause option, then restart it with
the run option.
For more details about the iwfsshrink utility, see the TeamSite Command-Line Tools.
Alternatively, if you have unused branches in TeamSite, you can delete these branches
to recover disk space. Over time, individual branches take up an increasing amount disk
space, as the number of versions and files on the branch grows. If you do not need any
of your old version history, you can create a new (empty) branch, create a workarea,
copy all the old content into the workarea, then delete the old branch. Exercise extreme
caution when doing this, as all version and metadata information will be irrevocably
lost.
Interwoven, Inc. 76
Chapter 5
TeamSite provides configurable roles that allow companies to define their own user
roles that map more closely to their corporate structure or to modify the out-of-the-box
roles. Additionally, permissions to manage branches can be delegated to users in
specific roles. This allows users other than TeamSite administrators to manage other
users working on a branch. Information discussed in this chapter includes:
User Roles
Configuring Roles
Managing TeamSite Users
Working with TeamSite Groups
Working with Branches
Scenario
The following scenario demonstrates how roles might be allocated among users and
some of the functionality available to each role:
He creates new TeamSite groups using the Manage Groups section of the
Administration tab. He also assigns users to groups and specifies the manager or
managers of the group. The group manager may or may not be a member of the group
they are managing.
Andre creates new TeamSite roles or modifies existing roles using the Manage Roles
section of the Administration tab. When Andre determines that a new role is needed, he
analyzes the operations to be performed by that role. He then creates a new role by
building from an existing role and adding or removing operations as appropriate. If
necessary, he can also modify existing roles to more accurately reflect the business
needs at Ajuba.
Andre can also stop the server to perform maintenance, and can restart the TeamSite
server. Andre maintains the server’s configuration files and works with the server
through command-line tools, a variety of APIs, or the Administration tab in
ContentCenter Professional.
Chris, a manager in Ajuba’s Partner Marketing Group, is responsible for the partner
portal. Andre creates a branch called Research_Reports and assigns Chris the
Administrator role because Chris is responsible for managing the users and groups and
their roles on the branch and for creating editions when content is ready to be published.
He is automatically assigned the Administrator role if he is made owner of the branch.
The Research_Reports branch is where content for the Financial Research section of
the portal is developed. The initial workarea was created by Andre and the group for
sharing was assigned to a TeamSite group that consists of Research Analysts in the
Marketing Department. Chris has also been made the manager of the TeamSite group by
Andre. He can then add other members in his marketing team to the group and to the
branch (provided the users have already been added to the system as TeamSite users by
Andre).
Chris uses ContentCenter frequently throughout the week to monitor the progress of
jobs and check the readiness of content in the staging areas of the branches he owns.
Pat uses ContentCenter daily to assign tasks to Authors, review content-in-progress, and
submit files to the staging area. Pat assigns Eric, a Financial Analyst who covers the
wireless sector of the technology industry, a task to update a report.
Eric is an expert with the tools he uses for analyzing a business, but does not need to
know the details of the content management system he uses. As an Author, Eric uses
ContentCenter to manage his tasks and access his content-in-progress. Typically, Eric
responds to automated email messages that notify him of new tasks and requests for
revision.
Interwoven, Inc. 78
Chapter 5: Defining Users and Roles
User Roles
TeamSite provides the following out-of-the-box user roles, each with varying levels of
access to TeamSite:
Author
Reviewer
Editor
Administrator
Master
WorkflowUser
WorkflowAdmin
To determine which role a user should have, consult the following lists of tasks and find
the role that best fits the user’s work. If these roles do not meet your needs, you can
configure your own roles as described in “Configuring Roles” on page 82.
Reviewer
A TeamSite user with the Reviewer role performs the following tasks:
Search for content.
Compare files.
Preview files.
Preview form output.
Create new jobs, transition tasks, attach and remove files from tasks, view task
details and properties.
Author
A TeamSite user with the Author role performs the following tasks:
Create, edit, import, move, rename, copy, and delete folders and files.
Merge, lock, tag, revert, submit, and preview, and compare files.
Mark files private, search for content, and submit content.
Edit file properties.
Create forms, preview, and generate form output.
Update workarea.
View files in context of all content in staging area.
Create new jobs, and work with tasks assigned to them.
Editor
A TeamSite user with the Editor role performs all the tasks that an Author can perform
and also does the following tasks:
Download files, perform a copy to area operation.
View all jobs and assign tasks.
View and modify job properties and file permissions.
Approve and reject content.
Administrator
A TeamSite user with the Administrator role performs all the tasks that an Editor can
perform and also does the following tasks:
Create and delete branches and edit their properties.
Create and delete workareas and edit their properties.
Create and delete editions and edit their properties.
Add users to the branch and specify their role.
Add, remove, or modify TeamSite users and groups.
Delegate administration of the branch or subbranches.
Change job and task attributes.
Master
A TeamSite user with the Master role performs all the tasks that any other user can
perform and also does the following tasks:
Add, delete content stores and edit their properties.
Freeze and thaw the Content Stores.
Add TeamSite users.
Create/modify roles.
Create/delete TeamSite groups.
Delegate administrative authority.
A Master user can work anywhere in TeamSite. This role is not configurable.
NOTE
Most installations only need to assign a few Master users, who will then delegate
administrative authority to other users.
Interwoven, Inc. 80
Chapter 5: Defining Users and Roles
WorkflowUser
By default, all TeamSite users should be able to use workflow models. To achieve this,
the workflowModels branch of the iwadmin store is shared for iwEveryone with role as
WorkflowUser.
This role has the minimum privileges required to instantiate a workflow. Users with the
WorkflowUser role can perform the following tasks in TeamSite:
NOTE
The iwEveryone group is automatically added to the workflowModels branch with the
WorkflowUser role. You do not have to add it manually.
WorkflowAdmin
Not all TeamSite users are allowed to create, subscribe, and configure workflow models.
Normally, users who can perform these operations include workflow developers or
TeamSite administrators.
Users with the WorkflowAdmin role can perform the following tasks in TeamSite:
Crete, copy, move, and delete files and folders.
Download and import files.
Preview and edit files.
Lock and unlock files.
View file history.
Modify file extended attributes.
Submit files and update workarea.
Manage workflow models.
Configure workflow models.
Publish workflow models.
Webview workflow model.
NOTE
Add users to this role manually. This role should not normally be given to the
iwEveryone group.
Users with the WorkflowAdmin role can perform four new operations in TeamSite, in
addition to the existing operations mentioned in this section. Refer to the Workflow
Modeler User’s Guide for more information on these operations.
The four new operations have been included under the Workflow category (select
Administration > Roles and Permissions > Manage Roles > Edit). They 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.
Publish Workflow Model. Users can use Interwoven Workflow Modeler to publish
workflows to TeamSite. Without this permission, users can only save the workflow
in the draft state to the iw-wa workarea. They cannot publish it (that is, submit it to
the staging area).
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.
Configuring Roles
TeamSite provides the out-of-the-box roles described in “User Roles” on page 79.
TeamSite provides a method for Master users to modify these out-of-the-box roles as
well as create new roles.
TeamSite defines all the operations that can be performed by users in the out-of-the-box
roles. These operations display on the Edit Roles screen. If your site has created
additional operations, these are described in the custom_userops.xml file and will also
display on the Edit Roles screen; refer to the TeamSite User Interface Customization
Guide for information on this file.
The roles.xml file contains the descriptions of each role. This file is modified by
changes made through the Manage Roles option on the Administration tab.
NOTE
The iwroleadm CLT can also be used to manage roles.
Interwoven, Inc. 82
Chapter 5: Defining Users and Roles
Recommendations:
When creating a new role, start with an existing role that is similar to the role you
want to create. Make changes as appropriate.
When creating roles, define all the business user roles (non-administrative roles)
first and then create the administrative roles later (administrative roles are not
limited to the Administrator role but refer to the general category of roles that can
administer TeamSite functions). The non-administrative roles need to exist so that
you can add them as delegable roles in your administrative roles. (For example, if
you create new roles such as Contributor and Approver first, these new roles are
available to select as delegable roles when you create or edit your branch
administrator role.) New customer-defined roles are not automatically added as
delegable roles, so defining the non-administrative roles first saves you from going
back to the Administrative role to add new roles as delegable roles.
Avoid using spaces in role names.
Managing Roles
The Roles screen shows the names and description of each TeamSite role. TeamSite
ships with four out-of-the box roles (see “User Roles” on page 79) that can be configured
plus the Master role that cannot be configured (so it is not listed on this screen).
The New Role link lets you create new roles. It is recommended that new roles be
created from existing roles with changes to meet your specific configuration.
Click Next to move to the Edit Role screen where you can specify the attributes of your
new role.
Interwoven, Inc. 84
Chapter 5: Defining Users and Roles
Editing Roles
The Edit Role screen is used to make changes to the operations performed by users in
this role. This screen displays when you click Next from the Add Role screen or Edit
next to a role.
The Display Name and Description fields show the name of the role and the
description. If you are creating a new role, these are the values that you entered in the
Add Role screen. These fields can be modified. However, the role name was set to the
name specified in the New Roles screen and will not change even though the display
name may change. A role name may need to be specified in the iw.cfg file or when
designing workflows.
The Roles that role can delegate field is used to specify role delegation
permissions.When a user is granted permission to delegate, that user can assign roles to
other users on that store or branch. For example, if a user has a role such as
Administrator that allows delegation of Editors, the Administrator can assign users the
Editor role on that branch. To allow delegation, move the role from the Available to the
Selected field by highlighting the role and clicking the arrow. If you have delegation on
a branch, you normally also have it on any subbranches.
The Locking model field lets you select the type of locking that occurs when users in
this role work on files. The choices are:
Submit Lock
Optional Write Lock
Mandatory Write Lock
None
The categories area of the form shows the More Detail and Less Detail links. More
Detail opens all the categories and shows all the check boxes that can be selected. Less
Detail closes all categories.
Each category includes a title, a brief summary and the links More Detail and Less
Detail. These links show or close the available check boxes for that category only.
When a category shows details, the Select All and Clear All links control whether all or
none of the check boxes are selected.
You can change the attributes for a role in the following categories:
Branch Administration. Lets you give users authorization to create, delete, and
rename branches, modify branch properties, delete and rename editions, and
delegate roles.
ContentCenter Professional Operations. Enables the Reporting tab in
ContentCenter Professional. Refer to Appendix A, “Configuring TeamSite
ReportCenter,” for information on the ReportCenter.
Content Management. Controls whether users can compare files, publish an
edition, submit content, and update workareas (that is, do Get Latest and Copy to
Area operations).
Custom User Operations. Lists items that have been specifically set up for your
organization. This functionality is contained in the custom_userops.xml file; refer
to the TeamSite User Interface Customization Guide.
External Triggers. Controls whether the users in this role can modify the iwat CLT
triggers. Refer to the TeamSite Command-Line Tools.
Files, Forms, and Folders. Controls the actions that users may perform with files
and forms. These include editing, previewing downloading, and merging files;
copying deleting, moving, and renaming files and folders; previewing and
generating forms; searching for file content; locking and unlocking files; reverting
Interwoven, Inc. 86
Chapter 5: Defining Users and Roles
to an earlier version of a file; undoing changes; marking files private; changing file
extended attributes and permissions; and viewing the file history.
New and Imported Content. Controls whether users can create files, folders, and
forms and import content.
Store Administration. Indicates whether users in this role can freeze and thaw the
content store.
User Administration. Controls whether users can create and delete TeamSite users
and create TeamSite groups.
Workarea Administration. Indicates whether users can create, rename, and delete
workareas, and modify workarea properties.
Workflow. Controls all aspects of jobs and tasks. These operations include:
Tasks. Attach a file, add a comment, assign a task, detach a file from a task, and
read or modify task properties.
Jobs. Create and end a job, and read and modify job properties.
Ownership. Take or return ownership of a group task, retry a task, and take a
task back.
View. View all jobs and tasks, the user’s jobs and task, and job details.
Manage Workflow Model. Add or remove workflows allowed for a branch or
vpath. Specify the users who can instantiate these workflows using the Manage
Workflows link.
Publish Workflow Model. Use Interwoven Workflow Modeler to publish
workflows to TeamSite. Without this permission, users can only save the
workflow in the draft state to the iw-wa workarea. They cannot publish it (that
is, submit it to the staging area).
Configure Workflow Model. Configure or customize the workflows for
different branches. Provide default values or make certain fields hidden or
visible during instantiation.
Webview Workflow Model. View the workflow in a browser. Check the values
of the properties for each task and track the workflow after instantiation.
At the bottom of the Edit Role screen is the Permission Overrides section. These
options lets users in this specific role:
Modify tasks and jobs that they do not own.
View and modify files in workareas where they are not a member of the group for
sharing.
Providing these permissions in a role allows users with that role to perform actions such
as cleaning up files or deleting jobs even though they may not own the job or have
permission to work on the files.
NOTE
Users with permission overrides can perform operations through ContentCenter.
However, if these users access files through the file system (Y: drive), traditional file
system permissions govern file access. Permission overrides should be used carefully.
Deleting Roles
Clicking the Delete link opposite a role name in the Roles screen displays a message
asking you to verify deletion of the role. If you click Delete, the role will no longer be
available in TeamSite. TeamSite users in the deleted role can view public branches and
workareas and file contents but cannot perform TeamSite operations unless they have
access through another role.
TeamSite users may have operating system access (referred to as OS users) or they may
be users who do not have operating system (OS) access (referred to as non-OS users).
Non-OS users can be assigned roles so they have the same TeamSite access as any other
TeamSite user. Non-OS users can only be added to non-OS groups. TeamSite Master
users can add non-OS users to TeamSite without waiting for the IT department to add
these users to the operating system.
TeamSite can configured to use LDAP or Active Directory for user authorization. You
can maintain multiple LDAP databases. These must be identified to TeamSite in the
user_databases.xml file (refer to “Storing TeamSite Users” on page 123). An LDAP
database may contain either OS users or non-OS users, but OS and non-OS users cannot
be mixed in an LDAP database.
NOTE
Depending on how your LDAP database is identified in the user_databases.xml file,
the users may be synchronized with TeamSite users automatically. This process is
described in “Synchronizing LDAP Users” on page 127.
Interwoven, Inc. 88
Chapter 5: Defining Users and Roles
The iwuseradm CLT can also be used to maintain the information in the tsusers.xml
file; refer to the TeamSite Command-Line Tools for information.
In the Preferred ContentCenter field, select one of these options to specify the
ContentCenter interface for each user:
Professional. ContentCenter Professional displays when the user logs in. A link at
the top of the screen allows them to move between ContentCenter Professional and
ContentCenter Standard. When logging in later, the user returns to the interface they
were using when they logged out.
Professional only. ContentCenter Professional displays. The user cannot switch to
ContentCenter Standard.
Standard. ContentCenter Standard displays when the user logs in. A link at the top
of the screen allows them to move between ContentCenter Standard and
ContentCenter Professional. When logging in later, the user returns to the interface
they were using when they logged out.
Standard only. ContentCenter Standard displays. The user cannot switch to
ContentCenter Professional.
You can specify that this user has the Master role by selecting the This user is a
TeamSite Master check box.
After a TeamSite user is added, you may, optionally, create a workarea for the user on
the subbranch where he or she will be working (see the ContentCenter Professional
online help).
When creating a workarea, you must include the user’s domain name in the Name field
of the New Workarea window (for example, MYDOMAIN\andre); use the Find option to
select this information. However, for a non-OS user, just enter the user id.
When you click the Search/Browse button on the Add Users screen, the form that
displays allows you to search for users or browse LDAP databases.
In the Search tab, select the database you want to search. Enter a name or partial name
in the Name field. Click Search. Users satisfying the search criteria display. Highlight
the users you wish to add (hold down the Ctrl key while clicking on the user names to
select multiple users). Click Select User.
The users you selected display in the Selected Users area of the screen. You can do
multiple searches by changing the database and the name. The users you select from the
new search are added to the Selected Users area. You can select and remove individual
users and all users from this list with the Remove and Remove All buttons.
When you complete your search, click OK to add the selected users to TeamSite.
Interwoven, Inc. 90
Chapter 5: Defining Users and Roles
In the LDAP Browse tab, you can browse through the list of LDAP databases. Highlight
the users you wish to add (hold down the Ctrl key while clicking on the user names to
select multiple users). Click Add Selected Users.
The users you selected display in the Selected Users area of the screen. You can add
users from different databases. The users you select from the new database are added to
the Selected Users area. You can select and remove individual users and all users from
this list with the Remove and Remove All buttons.
When you complete browsing the databases, click OK to add the selected users to
TeamSite.
When you select multiple users to add to TeamSite as a result of the search or browse
processes, the Add Multiple Users screen displays.
When you add all the selected users at the same time by clicking Add, the users display
in the list of users. If you wish to individually review each other, when you click Add
the Add Multiple Users Individually screen displays.
Interwoven, Inc. 92
Chapter 5: Defining Users and Roles
When you select multiple users and indicate that you want to add the individually, the
Add Multiple Users Individually screen displays.
Each user is listed separately. The user name, database where the user information is
stored, and email address display. You can change the ContentCenter interface and
specify whether the user is to be a TeamSite Master.
After you have specified the information for each user, click Add.
The User Details screen provides information about the user and lets you modify
existing user information.
The user ID, name, and email address display as specified when the user was added to
TeamSite. The groups of which this user is a member are shown. The workareas and the
role the user has in each of those workareas is also shown.
You can change the value in the Preferred ContentCenter field and change whether the
user is a TeamSite Master. If the user is an OS user, you can also modify the email
address.
Recommendation: Remove the user from any groups, workareas, or branches that refer
to that user before deleting the user.
If your installation uses the LDAP synchronization process to obtain user information,
delete the user from the LDAP database or delete all LDAP roles for the LDAP user
entry. The next time the iwldapsync CLT is run, the user will be removed from
TeamSite. If the user needs to be removed immediately, you can manually run the
iwldapsync CLT.
Use the following CLT to remove the user from the TeamSite entity database:
>iwuser -d DOMAIN\username
If you do not perform this step, you will not be able to create another user with the same
name.
To remove the user’s Windows account from the TeamSite server, use the Windows
Computer Manager or, if Microsoft Active Directory is installed, use the Active
Directory Users and Computers administrative tool:
1. Remove the user from any groups the user belongs to.
2. Remove the user account itself.
Interwoven, Inc. 94
Chapter 5: Defining Users and Roles
When using TeamSite groups, one OS group is used for file system representation; the
default iwglobal group is created when TeamSite is installed. This is the name of the
OS group that displays in the file system interface for assets that are shared by non-OS
users. The name of the default group is configurable using iwglobal_group in the
iw.cfg file. You must restart TeamSite for this change to take effect.
[iwserver]
iwglobal_group=group_name
Managing Groups
When you select Manage Groups, the Groups screen shows a list of TeamSite groups.
The listing can be modified by clicking All to show all the groups or by clicking
Managed by: to show the groups managed by the logged-in user.
NOTE
TeamSite ships with the out-of-the-box TeamSite group iwEveryone. This is a group of
all TeamSite users; it cannot be deleted.
Click New Group to display the New Group screen. In this screen, you can enter the
name of the new TeamSite group and a description of the group.The group name must
contain at least one non-numeric ASCII character.
For each group, you can click on links to obtain more information about that group:
Members. Displays the Group Membership screen to show a list of all the members
in that group.
Managers. Displays the Group Managers screen to show a list of the managers of
that group. A manager does not need to be a member of the group.
Properties. Displays the Group Properties screen to allow you to modify the
properties.
Delete. Deletes the group after requesting verification that you do want to delete the
group.
Interwoven, Inc. 96
Chapter 5: Defining Users and Roles
Click on Members to go the Group Membership screen to modify the members of the
group.
Group Membership
The Group Members screen shows all the members of the group. You can control the
display using the following links:
Collapsed. The collapsed view shows the names of group members and the names
of the subgroups within the group.
Expanded. The expanded view shows the names of group members and expands the
subgroups so all members of the subgroups are listed.
Interwoven, Inc. 98
Chapter 5: Defining Users and Roles
Deleting Groups
Clicking the Delete link opposite a group name in the Group screen displays a message
asking for you to verify deletion of the group. If you click Delete, the group will no
longer be available in TeamSite.
TeamSite users in the deleted group may still have access to TeamSite branches if they
are members of other groups that have a role on a branch or if they directly have a role
on a branch. Minimally, without being in any group or having any role, users can still
navigate into public branches and public workareas and see folders for which they have
read permissions.
Recommendation: Care should be taken to ensure that no assets are held by the group to
be deleted. You may want to just empty users from the group but leave the group. A
TeamSite administrator can later use the iwidmap CLT and reassign assets to another
group.
NOTE
Be careful not to add an OS group that has a name that is the same as an existing
TeamSite group name; doing so may prevent TeamSite access.
Content can be shared among branches. See “Integrating Content From Different
Branches” on page 102.
A locking model is one of the properties set when a branch is created. Locking models
specify locking behavior for all workareas on the branch and determine whether users
can edit files in different workareas at the same time. The role the user has on a branch
also sets locking behavior. The locking behavior for both the branch and the role are
combined to determine the locking behavior for a user in a branch. See “Setting Locking
Models” on page 44.
All users can view public branches and their properties, but only users with a role on the
branch can view private branches. Only users in roles who have authorization can
reassign a branch to a new owner and update the branch properties. Only some
properties are editable after the branch is created.
Deleting branches removes them and their contents, including the version history, from
the system. Use caution when deleting branches.
To access branches:
1. Select the Content tab.
2. Navigate to the store that contains the branches you want.
3. Open the main branch. If subbranches exist, navigate through them to the branch
you want.
To change this setting on an existing main branch, you must use the Windows File
Properties to take ownership, or the command-line tool iwchgrp to change the group of
the root directory of the main branch. However, if you edit the main_owner and
main_group lines and then create a new Content Store, the new settings take effect on
the new Content Store. For information about creating a new Content Store, see the
TeamSite Installation Guide.
You can specify the role that the owner of a branch has in the iw.cfg file. This role will
be added for the person who is the branch owner. This will be in effect whenever a new
branch is created. If nothing is specified, the Administrator role is used.
[iwserver]
branch_owner_role=role_name
You can specify the role or roles that can administer branches (have access to the
Actions > Manage Branches menu item) with the following iw.cfg option:
[iwserver]
admin_roles=role_name, role_name
If a user has one of the roles specified in the admin_roles setting in the branch being
viewed, the Manage Branches menu item is enabled. This setting controls whether the
user sees the menu item; it does not give users in the roles any additional privileges,
such as adding users to a role on a branch. For that, you still need to modify the role to
have Delegate permission.
You can specify a secondary master user other the local administrator with the following
iw.cfg option:
[iwserver]
secondary_admin_account=domain\user
Creating Branches
Users with appropriate permissions can create subbranches within branches.
To create a branch:
1. Select the Content tab.
2. Navigate to the branch under which you want to create the new branch.
3. Click New Branch in the view pane title bar.
4. Enter a name for the branch.
5. Enter a general description of the branch (for example, if content for a product cata-
log is to be developed on the branch, you might enter “Branch established for the
development of product catalog content.”).
6. Your user name is displayed in the Owner field by default. Enter a different user
name if you want to assign the branch to another person. By default, this user will
have the Administrator role on the branch (unless a different role has been config-
ured using the branch_owner_role option in the iw.cfg file).
7. Select a locking option. See “Setting Locking Models” on page 44 for information
about those options.
8. Enter the name of the edition you want to use as a starting point. The edition must
be from the parent branch.
9. Specify whether you want to you want the branch to inherit access from the parent
branch.Turn on Inherit from Parent to indicate that the users and their roles should
initially be identical to those on the parent branch. You can add additional users
later. This is the recommended setting. If this setting is not turned on, you select the
users and groups for this branch separate from the parent branch. It is recommended
that individual users be added to a TeamSite group rather than being added individ-
ually to a branch.
10. Select Restrict Access to set up this branch so it only displays for users or the
groups that have permission to work in the branch. By default, a restricted branch is
shown in general listings of all branches, but users without a role on that branch
cannot go into that branch. (The branch_security option in iw.cfg controls
whether the name of restricted branches can be seen.)
11. Click OK.
The branch is created and contains no workareas, one edition named INITIAL, and
a staging area. The staging area and INITIAL edition contain a copy of the content
from the edition you chose as a starting point.
After a branch is created you can create workareas and base them on the branch’s
INITIAL edition, or any other editions you create on the branch.
The staging area and INTIAL edition in newly created branches contain a copy of the
content in the parent branch’s edition on which they are based. Newly created workareas
contain a copy of the content in the branch’s edition on which they are based. Therefore,
if you want to create subbranches with workareas that contain content similar to that in
the parent branch, create an edition for the parent branch that contains the content you
want, and base your subbranches on that edition. You can then base the workareas on the
INITIAL edition in each subbranch.
5. Select a workarea.
6. Select an overwrite option.
7. Click OK.
The content is copied to the selected workarea.
After the content is copied to the workarea on the target branch, you can submit the
content and create new editions to meet your needs.
Managing Branches
If your role allows you to manage branches, you can use the Actions > Manage
Branches menu item from the Content tab to display the Manage Branches screen. This
screen lists the branches you can manage, along with your role or roles in each branch.
From this screen, you can delete or rename the branch. Each branch also has a
Properties link so you can modify the branch properties. Click on the name of the
branch to find the users and their roles.
If you make changes to the branch properties, click Save to save and close the Branch
Properties screen.
You can click Users and Groups to see the list of users and groups with access to this
branch and the role they have for this branch.
Users and groups may be specifically assigned for that branch, as shown in the top
section of the screen, or they may be inherited from the parent branch, as shown in the
bottom part of the screen.
After you set or change the role for that user, click Save to save the change and return to
the Branch Users and Roles screen.
Searching by Name
From the Branch Users and Roles screen, click Search Users and Groups. In the Search
Users and Groups screen, enter a user name and click Get Roles. If you enter a partial
user name, all user names containing that string are included in the results.
The results lists all users satisfying the search criteria and the roles they have in the
branch. Both the user id and the user name are searched.
This chapter discusses various procedures for managing access to TeamSite, including
assigning user roles, user authentication, and filtering user submissions, as follows:
Access Considerations
Working with Permissions
Sharing TeamSite Assets using Windows Groups
Enabling the User/Group/Role Disk Cache
Operating System Group Membership
Authentication
Configuring Submit Filtering
Access Considerations
Access to TeamSite is governed by the following two factors:
Windows-related authentication permissions
TeamSite role-based access
Windows file permissions control who has access to individual files and directories.
Windows password authentication is used when logging in to TeamSite. However,
TeamSite access privileges govern the role a user has in various branches and
workareas. For example, to edit a file in a workarea, a user must both be able to access
that workarea (through TeamSite access privileges), and have permissions for that file
and its parent directory (through Windows permissions).
When adding a new user, you need to consider the following factors:
Whether the user will have access to the server.
The role the user will play in your TeamSite operations.
The content the user will be editing.
To decide what groups new users need to belong to and which workareas they need to
access, consider your existing groups and the content and workareas they can access.
Add new users to the groups that work on the same content that they need to edit, and
they will automatically have access to their workareas and to their content files. If the
new users need their own workarea, create a private or shared workarea, but make sure
that they own or have access to the files that they will be editing. To change ownership
or access to files, see page 122.
Set permissions on your files according to the latter consideration. Remember that
permissions cannot be set differently for different workareas. If the permissions for
corresponding files are set differently in different workareas, you will encounter
conflicts when you submit files to the staging area.
NOTE
The TeamSite log-in screen accepts passwords of virtually any length. If you are using
multi-byte characters, the maximum length is 64 characters.
Not all of these factors apply to every action. TeamSite checks only the factors that
apply to the action being attempted. Generally, it checks as follows:
All the roles a user has on the branch are calculated. If any of these roles allow the
operation, permission is granted; otherwise the operation is not allowed for the user
on that object.
If the user has a role on the branch that has permission overrides set, these restrictions
may not apply.
Table 7 lists all of the operations that can be specified when roles are being created or
edited. It also shows the scope of each of the operations and the permissions that are
checked before a user can perform the function.
NOTE
TeamSite workflow tasks may require users to perform actions such as editing a file,
submitting it to the staging area, or taking ownership of a group task. To perform the
task, the user must have the ability to perform the action as specified in the table. For
example, if you assign a task that requires an Author to edit a file, the Author must have
workarea permissions, parent directory permissions, and file permissions for that file in
addition to the Edit operation in the role.
Workarea Access
By default, the workarea root file system permissions restrict any subdirectory access.
For example, the permissions on a subdirectory or a file specify that a user can modify
the subdirectory or file. However, permissions on the root directory do not grant write
permissions to the user. Therefore, TeamSite does not allow the user to modify the file
or subdirectory. To disable this check, set this option to no.
[iwserver]
mask_workarea_access=no
When set to no, permissions on the workarea root directory affect only this directory
rather than the entire tree.
You can configure TeamSite to not display the names of branches and workareas in the
ContentCenter if the user does not have read permissions by editing the
branch_security and workarea_security lines in the section of iw.cfg as follows:
[iwserver]
branch_security=on
workarea_security=on
Default Permissions
You can control branch permissions on Windows by adding the branch_default_perm
parameter to the [iwserver] section of the iw.cfg file as follows:
[iwserver]
branch_default_perm=0
The default behavior creates all branches with read access for the group Everyone. If
you add branch_default_perm=0 as shown, the group Everyone is not added to the
ACL for new branches created after this configuration setting is added.
NOTE
Permissions can only be changed in ContentCenter or with the iwaccess CLT and not
through a browser window. Use add-windows-permission option of the iwaccess CLT
to set permissions recursively for a folder and the files or folders below that folder.
Edit. Click Edit opposite a user to display the Edit Permissions screen. The Name
and User display. Select a Permission option and save the change.
Delete. Click Delete to remove the user from the permissions. You are prompted to
verify the deletion.
Remove Inherited Permissions. When you click Remove Inherited Permissions,
you are asked if you want to make a local copy of the inherited permissions.
NOTE
TeamSite groups are an alternative to Windows groups. The advantage of TeamSite
groups is that they are managed entirely within TeamSite whereas Windows groups
require management through the Windows operating system. The advantage of
Windows groups is that they interoperate with Windows and AD.
The following sections explain how Windows groups are typically used in each of these
environments, and describe in what circumstances the new Active Directory System
Interface (ADSI) and disk-caching code can be used to improve performance.
Microsoft provides two kinds of groups in an NTLM or Mixed Mode Active Directory
environment: local groups and global groups. In a typical TeamSite installation in this
environment, global groups are used to group users, and local groups are used to share
TeamSite resources. The global groups contain lists of users, and these global groups are
in turn members of the local groups used for sharing.
No special steps are required to configure TeamSite for this environment. The
parameters use_adsi and domain_local_groups found in the [iwserver] section of
iw.cfg are not used. They should either be commented out or set to false.
Local groups are defined on the machine on which TeamSite runs, so they have some
disadvantages. If the TeamSite server is to be moved to a new machine, even if the new
machine is a member of the same domain, the local groups need to be re-created on the
new machine. For this reason, where practical, Interwoven recommends the use of
domain local groups and domain users rather than local users and groups. However,
machine local groups and users are sometimes the best choice for TeamSite servers that
are used for demonstration or test purposes.
The advantage of domain local groups is that they are known to all machines in the
domain in which they are defined. If domain local groups are used to share TeamSite
resources, the TeamSite server may run on any machine in the domain, and moving the
TeamSite server software to a different machine in the domain does not require any
changes to the group structure. In a Mixed Mode environment, where the groups for
sharing are tied to a particular machine rather than to the domain, it is more difficult to
swap out failed hardware or to move the TeamSite server to a different machine.
In this environment, use domain local groups for sharing rather than traditional local
groups. To enable the use of domain local groups as groups for sharing, use the
following setting in iw.cfg:
[iwserver]
domain_local_groups=yes
For larger installations, TeamSite may be configured to use cached user and group
information to significantly reduce the server's startup time. This feature may be used
with or without enabling the ADSI code. See “Enabling the User/Group/Role Disk
Cache” on page 120.
In this environment, where users are grouped in universal groups, and resources are
shared using domain local groups, the new ADSI code must be enabled in iw.cfg:
[iwserver]
use_adsi=yes
domain_local_groups=yes
When TeamSite users are in tsusers.xml, the TeamSite server may take several
minutes to start up as it collects user and group information. This startup time can be
significantly reduced when the server is configured to use cached user and group
information at startup time (this is on by default). See “Enabling the User/Group/Role
Disk Cache” and information later in this section.
In networks that are spread over large geographic areas and where TeamSite users are
spread among different domains, network response times may encounter unusual delays
when the TeamSite service is first started. The TeamSite service is usually configured to
start automatically after a Windows reboot. At startup, TeamSite reads a variety of user
and group information from the Active Directory. This process may take several
minutes. In extreme cases, the time required to start the server may result in a system
timeout, which occurs when the server requires more than 10 minutes to start. These are
possible solutions for this problem:
Increase the timeout period from the default value of 600, which denotes 600
seconds (10 minutes), to a larger value. The timeout period may be set to a different
value by changing a parameter in the Windows Registry. The key to be changed is
found in the Registry at HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\iwserver\Parameters\Start Timeout. Its value is
the number of seconds that Windows should wait for the server to start.
If the server startup time is unacceptably long, consider limiting the number of
inquiries that TeamSite must make to remote AD controllers. This is done by
limiting the number of domains that TeamSite is required to search using the
domain_list parameter in the iwserver section of iw.cfg. If it is not practical to
limit the number of domains, the need to query remote AD controllers for group
membership information can be reduced or eliminated completely by careful choice
of Windows group type for various uses. These possible changes may improve
performance:
Use universal groups exclusively to group users. This is recommended practice
from Microsoft (although other group types may be used). To instruct TeamSite
to restrict its user search to universal groups, set the following parameter in
iw.cfg:
[iwserver]
windows_groups_for_users=UNIVERSAL
If the groups used to share TeamSite resources are domain local groups only,
limit the TeamSite search for nested groups to groups nested in domain local
groups. This is done with the following iw.cfg setting:
[iwserver]
windows_groups_for_sharing=LOCAL
Use universal groups exclusively to share TeamSite resources. Recommended
practice is usually to share resources using domain local groups, but in larger
systems, significant performance gains may be made if universal groups are
used instead. If universal groups only are used to share TeamSite resources, then
the TeamSite server can use the Active Directory Global Catalog for all its
inquiries about groups for sharing. To configure the server to restrict its groups
for sharing to universal groups, include the following settings in the iw.cfg file:
[iwserver]
windows_groups_for_sharing=UNIVERSAL
While some of these factors may be outside your control, response times can usually be
improved by trying some of the following:
Where practical, limit the number and size of groups used for sharing TeamSite
assets. Create dedicated groups, composed solely of TeamSite users, instead of
using large existing groups. This is especially helpful if the existing operating
system groups contain many members that are not TeamSite users.
Limit the number of domains that contain TeamSite users and Windows groups used
for sharing. The domain_list parameter in the [iwserver] section of iw.cfg
should be set to include only domains that contain TeamSite users and groups; see
“Domains to Use for Group Authentication” on page 131. A short list of domains can
be searched faster than a long one.
If possible, use universal groups exclusively to group TeamSite users. Set
windows_groups_for_users=UNIVERSAL in iw.cfg. This is recommended for most
TeamSite installations.
Consider using universal groups instead of domain local or global groups to share
TeamSite resources. Set windows_groups_for_sharing=UNIVERSAL in iw.cfg. This
restriction is not necessary for most TeamSite installations.
Where TeamSite users are in tsusers.xml and there are a lot of users, groups or
domains, leave the user/group/role disk cache enabled (the default setting). This is a
good practice for most large TeamSite installations.
In installations that do not include nested groups in the groups used for sharing
TeamSite assets, disable the nested group handling functions (see “Disabling Group
Nesting” on page 121). This option is not frequently used, but is sometimes chosen
to improve response times where there are very large numbers of TeamSite users.
The disk cache is enabled by default. To disable this feature in iw.cfg, set:
[iwserver]
enable_user_group_disk_cache=false
This flag is disabled by default. To enable the group debugging flag in iw.cfg, set:
[iwserver]
debug_adsi=true
TeamSite only checks the primary group owner of a workarea and does not rely on
ACLs to determine workarea ownership.
You can also change ownership of workareas through ContentCenter Professional in the
Workarea Properties screen.
This sets a group of users, all of whom have full file system access. If this line does not
exist, the group Everyone is used.
Authentication
Authentication involves determining whether users can access TeamSite resources. The
tsusers.xml file maintains information on TeamSite users. Operating system users are
usually identified as TeamSite users and added to this file through the Manage Users
option in the ContentCenter Professional Administration tab that is available to Master
users (refer to “Managing TeamSite Users” on page 88).
NOTE
LDAP files that contain users that are to be added through synchronization include the
attr_sync attribute described in “Synchronizing LDAP Users” on page 127.
The following code is an example of the user_databases.xml file that defines two
LDAP databases and two external databases. Databases set up using these formats are
used to add TeamSite users through the iwuseradm CLT or the Administration tab.
<iwuser_databases>
<iwldap id="ldap_1" display_name="my ldap_1" os="t">
<server value="ishuffle-sol.amer.interwoven.com" />
<port value="389" />
<search_key value="uid" />
<ssl_port value="0" />
<CAFile value="" />
<dnBase value="marketing.interwoven.com" />
<account value="admin" />
<password value="52616e646f6d4956c82bafa0f007
0585907d439c34792e66c55ade1fd1e21fc4" />
<attr_email value="mail" />
<attr_display_name value="cn" />
</iwldap>
The CLT outputs YES if the encrypted password matches the original password.
When you use the ContentCenter Professional Administration tab to manage users, you
can search for users in these databases (“Managing TeamSite Users” on page 88).
When attr_sync is defined, TeamSite users from the LDAP file can only be created by
the synchronization process; TeamSite users from this LDAP file cannot be added or
deleted through the Administration tab or using the iwuseradm CLT.
NOTE
If attr_sync attribute is not defined, LDAP users are added to TeamSite through the
ContentCenter Professional Administration tab or the iwuseradm CLT.
If you do not have an existing attribute in your LDAP schema where you can store
TeamSite user interface information, add a new attribute to your LDAP schema as
described in this section. If you already have an attribute where you can store TeamSite
interface information, start the procedure with step 3.
1. Add an auxiliary class to an existing object in the schema.
2. Add a new attribute to that object that will contain the TeamSite information. This
attribute is the name specified for attr_sync.
3. Your LDAP administrator can now assign TeamSite interface information to users
configured in your LDAP server using the server’s administration tools. The infor-
mation for this attribute indicates whether the user is a TeamSite user or a TeamSite
Master user and the ContentCenter interface the user can access.
The following are the valid values (they are case-sensitive):
master. This user is a TeamSite Master user.
tsuser. This user is a TeamSite user. In releases prior to TeamSite 6.7, the
values of admin, editor, and author could be specified for this attribute. Those
values are now converted to tsuser.
ccpro. ContentCenter Professional displays when the user logs in. A link at the
top of the screen allows them to move between ContentCenter Professional and
ContentCenter Standard. When logging in later, the user returns to the interface
they were using when they logged out.
ccpro-only. ContentCenter Professional displays. The user cannot switch to
ContentCenter Standard.
ccstd. ContentCenter Standard displays when the user logs in. A link at the top
of the screen allows them to move between ContentCenter Standard and
ContentCenter Professional. When logging in later, the user returns to the
interface they were using when they logged out.
ccstd-only.ContentCenter Standard displays. The user cannot switch to
ContentCenter Professional.
The password specifies the encrypted password of the Active Directory user account
that matches account.
This information is included in the user_databases.xml file using the account and
password attributes.
LDAP Synchronization
Synchronization is done with the iwldapsync CLT (refer to the TeamSite
Command-Line Tools for options on this CLT). This CLT is normally launched when
TeamSite starts up and is run periodically as defined by ldapcache_thread_delay in
the iw.cfg file. The default is every 24 hours. The CLT can also be run manually.
You can enable logging of the LDAP synchronization process using the log_ldap_sync
option in the iw.cfg file; logging is on by default. The ldap_sync_retry_count is used
to specify the number of retries to connect to the TeamSite server when the LDAP
synchronization process runs. By default, the retry count is 12, which means that
TeamSite waits about 60 seconds to start responding to client requests.
TeamSite automatically synchronizes TeamSite users up to the search limit set by the
LDAP server for each LDAP configuration. If the LDAP server is configured to limit
the number of records returned by a search query to a number that is less than the
number of TeamSite users in the LDAP database, no LDAP users will be found during
the synchronization. Try the following options to address the issue when using LDAP
synchronization:
Divide the users under different LDAP subtrees (under different base DNs) and
define multiple LDAP databases in TeamSite such that the number of TeamSite
users under each LDAP database configuration is no more than the LDAP search
limit.
Increase you LDAP search limit to the number of TeamSite users configured in
LDAP.
The other option is to add LDAP users to TeamSite using either the Administration tab
or the iwuseradm CLT instead of using the LDAP synchronization procedure.
Every LDAP directory has a schema that describes the objects and attributes that are
found in the directory. For example, you could have an object called user and an
attribute postaladdress. To configure TeamSite to perform user authentication, you can
either modify an existing attribute to represent TeamSite users or create a new one; this
procedure is described in “Modifying LDAP Schemas to Store TeamSite User Interface
Information” on page 128.
By default, TeamSite authenticates against all domains. To limit the number of domains
used for group authentication, add the following line to the [iwserver] section of
iw.cfg:
[iwserver]
domain_list=domain1,domain2,domain3
You can explicitly specify the domain controller that should be used for a particular
domain. This option should not be used if the use_adsi parameter is enabled.
[iwserver]
domain_list=domain1, domain2:domain_controllerA, domain3
In this example, the primary domain controller would be used for first and third
domains, while domain_controllerA would be used for the second domain.
NOTE
Do not confuse this line with the domain_list line in the [iwcgi] section.
Once this feature is activated, each time TeamSite is restarted, it logs all users in the
roles files and their associated groups in iw-home\local\logs\iwtrace.log. Log files
use the following format:
NOTE
If this feature is left on for too long, your log files will grow extremely large.
NOTE
This file is not present by default; you need to create the file in the location specified.
where:
The case-sensitive statement specifies whether or not the rules matching should
ignore the case of the path names. If case-sensitive is not specified, the value is
assumed to be no.
workarea#_pattern is used to match a workarea to the set of file rules to apply
when a submit is done from that workarea. Each pattern can only be specified once,
and the first match is used. The syntax of the pattern is regex(5) (extended syntax).
and where ACL (Access Control List) contains one or more Access Control
Entries (ACE), as follows:
name:perms (a single ACE, to specify a single user or group)
{ name:perms, name:perms, ... } (multiple ACEs, to specify multiple users or
groups)
where perms specifies the permissions granted to the specified user or group and
is either any sequence made of the characters:
R (read)
W (write)
X (execute)
D (delete)
P (change permissions)
O (take ownership)
or one of the preset combinations:
ALL (RWXDPO)
NONE (none)
READ (RX)
WRITE (W)
CHANGE (RWXD)
For example:
setaccess={ andre:ALL, marketing\pat:RX }
would remove the existing ACL and grant andre full access and pat (in the
marketing domain) read and execute access to the specified files.
would remove any existing ACEs for the user chris and the group everyone,
and grant chris change access and the group everyone read access to the
specified files. Any other existing ACEs would remain unchanged.
5. The server submits the transformed files and directories to the staging area.
RULES
{
. # any workarea
{
/a/b/.*\.html$ # files ending in .html under /a/b
{
owner=DOMAIN\andre
group="DOMAIN\\web editors"
setaccess = {everyone:Read, domain\andre:ALL}
}
[^/]$ # all other files
{
group="DOMAIN\\web editors"
setaccess = {users:rx, "domain\\webeditors:change"}
}
/$ # all directories
{
group="DOMAIN\\web editors"
setaccess = {everyone:rwx/rx, "domain\\webeditors:change"}
}
}
}
NOTES
Only the first match is applied. That is, the first match is used if multiple rules
match the file or directory. The submit.cfg file should be ordered so that the most
specific workarea patterns are closer to the top and the most specific file patterns are
earlier in each section. You may need to duplicate some actions for them to apply to
multiple rules.
For purposes of matching, the path name of a directory must end in a slash (/).
Single or double quotes around patterns are optional, but they must be used around
workarea and file patterns that contain spaces or the following special characters:
#, {, }, =, or ,.
Backslashes (\) are special characters when used within patterns surrounded by
quotes; a backslash followed by any character is replaced by the single character.
For example, to embed a single quote, double quote, or backslash in a pattern,
precede the character with a backslash (\', \", or \\). Backslashes are not special
characters in patterns that are not quoted.
For example, the following three specifications are equivalent:
owner = DOMAIN\andre
owner = 'DOMAIN\\andre'
owner = "DOMAIN\\andre"
You can use backslashes (\) or forward slashes (/) as the path delimiter in regular
expressions, but using forward slashes is more readable. This is because the
backslash is treated as a special character in regex(5) syntax, and it is also treated
as a special character by the configuration file parser when the expression is
enclosed in quotes or double quotes. Therefore, when an expression using
backslashes is contained in quotes or double quotes, the backslashes must be
escaped twice, for a total of four backslashes.
For example, the following are equivalent expressions for matching any file whose
name ends in .html in the \a\b directory:
^/a/b/.*\.html$
'^/a/b/.*\\.html$'
"^/a/b/.*\\.html$"
^\\a\\b\\.*\.html$
'^\\\\a\\\\b\\\\.*\\.html$'
"^\\\\a\\\\b\\\\.*\\.html$"
Do not specify duplicate workarea patterns multiple times, duplicate file patterns
multiple times within a workarea section, or the same action multiple times within a
file rule.
Changes to submit.cfg do not take effect until the server is restarted or until you
use iwreset.
File permissions could be overwritten with submit.cfg options. If submit.cfg and
file permissions are not designed properly, the end user could be confused.
would return:
Matched area pattern "^/default/main/WORKAREA/.*$"
Matched file pattern ".*\.sh$"
Actions to do are:
owner = andre
Matched area pattern and Matched file pattern are the case-insensitive regular
expressions found in submit.cfg that match the workarea and file. Actions to do are
the actions (specified in submit.cfg) that will be applied to the file.
Refer to the TeamSite Command-Line Tools manual for more information about this
CLT.
You can also get debugging information on the submit handling configuration printed to
iwtrace.log by adding the following line to the [iwserver] section of iw.cfg:
[iwserver]
debug_event_handler=yes
Configuring Interwoven
Search
The Interwoven Search function allows users to search common document types and
data records from TeamSite. Users can search for text within a file or for values
specified by metadata. Users enter search criteria using the search user interface from
ContentCenter. ContentCenter users may also save their search queries so the queries
can be reused or modified; refer to the online help for details. CLTs are also available for
system administrators to perform queries and to set up index and search functionality;
refer to the TeamSite Command-Line Tools.
Search Overview
The primary uses for Interwoven search are to:
Find files for viewing, editing, copying, and tagging.
Find outdated files for removal.
Find files for reuse.
Find files for reporting purposes (regulation and auditing compliance).
Find files for recovery purposes (restore older versions of deleted files).
The Interwoven Search function is made up of two parts—the index manager and the
search manager. The index manager controls the indexing of content. The search
manager performs queries on indices and returns the results to the user. Both the index
manager and the search manager use agents, which are processes that access the search
engine for either indexing or querying documents. The index manager also uses a
document cracker that cracks a file or a data record and provides metadata and
full-search content on the document. TeamSite CLTs are used to issue commands to
either the index manager or the search manager. The ContentCenter interfaces
communicate with the search manager to request searches and to view the search results.
NOTE
Within configuration or log files associated with the Interwoven Search function, the
term index server is sometimes used to refer to the index manager and the terms search
service or search server may be used to refer to the search manager.
TeamSite
Search Index
Manager Manager
Indexing Branches
When a new TeamSite branch is to be indexed, the branch can be indexed in two ways.
The branch may be specified in the iwsearch-home\etc\branches.cfg file and
then the index manager may be started. The index manager picks up the branch
name during startup time and indexes the branch. If non-English characters are used
in this file, save the file in UTF-8 encoding.
The branch can be specified in the iwndxaddbr CLT that tells the index manager the
relevant branch that is to be indexed.
Whenever a branch that is specified to the index manager to be indexed has been
successfully indexed, the index manager creates a collection of data and indices about
the documents in the branch that is optimized for subsequent searching.
In addition to indexing an entire branch, the index manager also has a listener that
listens to any submit event on a previously indexed branch. When a user submits a set of
files through TeamSite, the index manager recognizes that a submission has occurred
and instructs the indexing to occur on that set of files. Indexing can be tuned based on a
set of parameters in the iwsearch-home\etc\search.properties file.
When an index manager is shut down, relevant information about all the branches that it
has indexed is stored in a file. When the index manager subsequently comes back up, it
sets the appropriate context by reading the information from this file.
Searching Branches
A ContentCenter user issues a search query. This query is sent to the search server.
Results are returned to the ContentCenter screen, arranged in relevancy order
determined by the search engine.
A CLT can also be used to issue a query. Queries are written in XML format and may be
saved in a file. The name of the file is provided with a CLT flag. Refer to the TeamSite
Command-Line Tools for details on using CLTs for queries.
Using the ContentServices API, you can search across multiple branches. Search across
multiple branches is not supported through ContentCenter or CLTs.
Deleting Branches
When a TeamSite branch has to be deleted, you need to issue the appropriate index
server CLTs so that the collections maintained by the index server for that branch are
handled correctly.
To purge the branch’s collection from the index manager and from the disk, issue the
iwndxpurgebr CLT for that branch. Otherwise, issue the iwndxrmbr CLT to remove the
collection from the index manager. Refer to the TeamSite Command-Line Tools for an
explanation of the differences between the two CLTs.
After issuing one of these CLTs, you can delete the branch from TeamSite. Refer to
page 167 for troubleshooting information if collections or branches are not deleted
correctly.
This section shows the configuration parameters in each area and describes the
information that can be modified.
NOTE
The iwsearch-home\etc\search.private.properties file contains settings you do
not normally need to adjust. Do not modify this file unless specifically instructed to do
so by an Interwoven representative.
Generic Configuration
This section identifies the TeamSite server. It is normally set by the installation
program. However, if your TeamSite server changes, you need to modify this section.
You also need to specify the locale of the index manager and search manager. This value
should typically refer to the same language or country as specified for the locale of the
TeamSite server.
######################################################################
# Generic configuration items (common for index server and search)
######################################################################
# TeamSite host
iw.teamsite.server.host=_IW_TS_HOST_NAME_
When an agent fails to respond to a command from its server, the server automatically
restarts it. However, if the agent has a persistent problem, it can go through rapid
restarts, which can slow the system down. To limit this behavior, you can specify the
number of times the server is allowed to restart its agent within a specific time period. If
the restart limit is exceeded, the server takes the agent out of operation, which is called
taking the agent offline. Once an agent has been taken offline, the only way to start it is
to restart the server.
iw.agent.windows.systemroot=_SYSTEM_ROOT_
Change the value for iw.index.server.port to reflect your actual TCP port. This is the
TCP port that the index manager monitors for API requests, such as requests from CLTs
and the user interface. Also specify the value for the java.naming.provider.url.
The iw.index.maxbifsize parameter controls how many files are optimally submitted
to be indexed at a time. Once the value is exceeded, an index job starts. BIF refers to
Bulk Insert File; BIFs are generated per branch so this refers to the optimal number of
changes per branch to be processed at one time.
The session pooling parameters control the number of connections open to TeamSite.
The iw.index.scipool.max parameter specifies the maximum number of connections
that can be opened. The iw.index.scipool.warm parameter specifies the number of
connections that are always open, whether or not they are used.
You can control the number of times the index manager attempts to listen to the
TeamSite Event Subsystem before giving up using the
iw.index.events.listen.attempts parameter; this value must be a positive number.
You can also specify the number of seconds the index manager waits between attempts
to listen to the TeamSite Event Subsystem using the iw.index.events.listen.wait
parameter.
You can control the number of times the index manager attempts to connect to the
TeamSite server before giving up by using the iw.index.iwserver.connect.attempts
parameter. You can also specify the number of seconds the index manager waits
between attempts to connect to the TeamSite server using the
iw.index.iwserver.connect.wait parameter.
# Server configuration
iw.index.server.port=_IW_INDEX_PORT_
# Optimal wait time before received events are processed (in minutes)
iw.index.optimalWaitMins=1
iw.index.wamodifications.frequency=2
# Control after how much time (in hours) the collections of workarea
# modifications for a branch are considered too old and hence deleted
# and then re-indexed. Checked during index server startup only.
iw.index.wamodifications.deleteindexes=72
The iw.index.agent.mainport parameter specifies the TCP port number on which the
index manager listens to its agent. This connection is used by the index manager to
dispatch commands to its agents. The iw.index.agent.callbackport parameter
specifies the TCP port on which the index manager listens to its agents for a callback
connection. The callback connection is used by the agents to send their log messages to
the server.
The iw.index.agent.idxdir parameter sets the directory on the index manager server
that holds the indexes for all branches. For example:
iw.index.agent.idxdir=C:/Interwoven/Index
NOTE
If workarea indexing is turned on, the directory on the index manager server that holds
the indexes for all workarea-modified files will be a subdirectory named WORKAREAINDX
under the path you specified. In a scenario where the index server is on machine 1 and
the search server is on machine 2, the collection directories that both the index and
search server point to have to be same. If the index collection is on C:\collection on
machine 1 and pointed to by iw.index.agent.idxdir, it has to be mapped using a
network drive such that it is accessible by the search server from machine 2. So
iw.search.agent.idxdir could be x:\coll-dir on machine 2 although both of them
finally point to the same set of bytes.
######################################################################
# Index agent configuration
######################################################################
# Port number on which index server listens for connections from its
agents
iw.index.agent.mainport=_IW_INDEX_AGENT_MAIN_PORT_
# Port number on which index server listens for callbacks from its agents
iw.index.agent.callbackport=_IW_INDEX_AGENT_CALLBACK_PORT_
Change the value for iw.search.server.port to reflect your actual TCP port. This is
the TCP port that the search manager monitors for API requests, such as requests from
CLTs and the user interface.
The search manager uses a pool of worker threads for servicing client requests. Each
client connection, whether from a CLT or the user interface, is served by its own worker
thread. When the search manager starts, it creates threads specified by the value of the
iw.search.server.threadpool.warmthreads parameter. If a new client connection is
made and none of these threads is available to service the connection, a new thread is
created, thus growing the thread pool.
When a thread has been idle for longer than the millisecond time out specified by the
value of the iw.search.server.threadpool.keepalivetime parameter, it is
terminated by the server to conserve resources. If
iw.search.server.threadpool.keepalivetime is set to a value of -1, the threads are
never reclaimed.
Change the value for the iw.index.server.host parameter if the index manager is on a
different host computer than the search manager.
You can modify the cache configuration. The raw cache contains the results of a query
as they are retrieved. Post-processing filters the results from the raw cache and writes
the results to the processed cache until enough results are found to return the first page
of results. The values for iw.search.cache.raw.entries.capacity and
iw.search.cache.raw.entries.grace are used to control the total number of queries
kept in the system and the extra capacity that can be used when managing the number of
queries. For example, the default settings indicate 100 queries are kept in the system,
but that number can go to 110 (10 grace queries) and then 10 queries would be deleted at
one time to return to the 100-query capacity. This is more efficient than deleting one
extra query at a time. The iw.search.cache.processed.size parameter specifies the
size of the processed cache.
The session pooling parameters control the number of connections open to TeamSite.
The iw.search.scipool.max parameter specifies the maximum number of connections
that can be opened. The iw.search.scipool.warm parameter specifies the number of
connections that are open, whether they are used or not. The value for
iw.search.scipool.max should be less than half the value of
iw.search.server.threadpool.maxthreads, but should not generally exceed 25 for the best
performance.
######################################################################
# Search server configuration
######################################################################
iw.search.server.port=_IW_SEARCH_PORT_
iw.search.server.threadpool.maxthreads=50
iw.search.server.threadpool.warmthreads=10
iw.search.server.threadpool.keepalivetime=60000
iw.search.query.maxOpenQueriesPerUser=2
iw.search.query.defaultQueryLocale=en
#Cache configuration
#Raw cache
iw.search.cache.raw.entries.capacity=100
iw.search.cache.raw.entries.grace=10
iw.search.cache.raw.validity.mins=240
#Processed cache
iw.search.cache.processed.size=100
The iw.search.agent.mainport parameter specifies the TCP port on which the search
manager listens to its agents. This connection is used by the search manager to dispatch
commands to its agents. The iw.search.agent.callbackport parameter specifies the
TCP port on which the search manager listens to its agents for a callback connection.
The callback connection is used by the agents to send their log messages to the server.
The iw.search.agent.idxdir parameter sets the directory on the search manager that
holds the indexes for all branches.
NOTE
If workarea indexing is turned on, the directory on the search manager server that holds
the indexes for all workarea-modified files will be a subdirectory named WORKAREAINDX
under the path you specified.
######################################################################
# Search Agent configuration
######################################################################
# Port number on which search server listens for connections from its
# agents
iw.search.agent.mainport=_IW_SEARCH_AGENT_MAIN_PORT_
# Port number on which search server listens for callbacks from its agents
iw.search.agent.callbackport=_IW_SEARCH_AGENT_CALLBACK_PORT_
Logging Configuration
The logging configuration refers to both the index manager and the search manager. The
first part of the value for the log4j.logger.com.interwoven parameter specifies the
log level for the server. The set of possible log levels are in increasing order of verbosity
are FATAL, ERROR, WARN, INFO, and DEBUG. Normally, the server should be run with the
log level of INFO. You can control the maximum log file size using
log4j.appender.mainLogger.MaxFileSize and specify the number of archived or
backup log files using log4j.appender.mainLogger.MaxBackupIndex.
#######################################################
# Logging configuration
#######################################################
log4j.logger.com.interwoven=INFO, mainLogger
log4j.appender.mainLogger.MaxFileSize=5000KB
log4j.appender.mainLogger.MaxBackupIndex=3
If you make changes such as adding another attribute to the FieldMapping.xml file, you
need to force the index manager to re-index all the files. Use the iwndxpurgebr CLT to
remove the collection; then add the branch to the index again.
In addition to these extended and templating attributes that are defined in the field
mapping configuration file, there are a set of attributes and file properties that will
always be indexed. These are defined in an internal standard field mapping
configuration file. The StandardFields schema (as described on page 155) defines these
fields and they cannot be changed.
The templates element contains a template element for each FormsPublisher template
used. The template element includes a templateType element that identifies the
FormsPublisher template (or form). The fields within the form that will be indexed are
identified in the templatingFields element, which contains one or more
templatingField elements. Each templatingField element contains a xpath element
and a fieldSpecification element. The templatingField element defines a mapping
from the xpath of a templating entry to the field definition that is used to store it.
NOTE
The fieldName and fieldStorage elements defined in globalFields must be unique.
The fieldName and fieldStorage elements defined for a single template type may be
reused in other template types. This means two different templates could have fields that
share names or storage; however, these cannot conflict with a global field.
The value for a zone name must be a valid XML name; it cannot have spaces. Names are
character insensitive. They can consist of all alphabetic characters (upper and lower
case), numeric characters, the dash (-), the underscore character (_), or the number
sign (#).
y year
M Month (in numeric form)
d Day in month
a|p AM or PM marker
h Hour
m Minute
The following examples show how Index Manager interprets the date and time patterns.
<templates>
<!-- Examples of configuring 'iwov' style templates -->
The templates section <template>
begins by defining
intranet/weather. <templateType>intranet/weather</templateType>
<templatingFields>
<templatingField>
<xpath>/Announcement</xpath>
<fieldSpecification>
<fieldName>Announcement</fieldName>
<fieldType>string</fieldType>
<fieldStorage>zone:WeatherAnnouncement</fieldStorage>
</fieldSpecification>
</templatingField>
</templatingFields>
</template>
<template>
This section defines <templateType>internet/yacht</templateType>
internet/yacht.
<templatingFields>
<!-- An Example of configuring int fields -->
<templatingField>
<xpath>/General Info/Length</xpath>
<fieldSpecification>
<fieldName>YachtLength</fieldName>
<fieldType>int</fieldType>
<fieldStorage>CustomInt1</fieldStorage>
</fieldSpecification>
</templatingField>
</templatingFields>
</template>
<template>
Another template
category and type. <templateType>internet/auction</templateType>
It defines <templatingFields>
internet/auction.
<!-- An Example of configuring float fields -->
<templatingField>
<xpath>/Minimum Bid Amount</xpath>
<fieldSpecification>
<fieldName>MinBidAmount</fieldName>
<fieldType>float</fieldType>
<fieldStorage>CustomFloat1</fieldStorage>
</fieldSpecification>
</templatingField>
</templatingFields>
</template>
<template>
This element defines <!-- An example of configuring all instances of replicants -->
internet/careers.
<templateType>internet/careers</templateType>
<templatingFields>
<templatingField>
<xpath>/Responsibilities List</xpath>
<fieldSpecification>
<fieldName>Responsibilities</fieldName>
<fieldType>string</fieldType>
<fieldStorage>zone:Responsibilities</fieldStorage>
</fieldSpecification>
</templatingField>
</templatingFields>
</template>
<template>
This section defines <!-- An example of configuring a particular replicant instance -->
internet/pr. <templateType>internet/pr</templateType>
<templatingFields>
<templatingField>
<xpath>/Story[1]/Section Paragraphs[1]/Paragraphs</xpath>
<fieldSpecification>
<fieldName>FirstStoryParagraph</fieldName>
<fieldType>string</fieldType>
<fieldStorage>zone:FirstStoryParagraph</fieldStorage>
</fieldSpecification>
</templatingField>
</templatingFields>
</template>
<field>
<fieldName>BranchId</fieldName>
<fieldType>long</fieldType>
<fieldStorage>BranchId</fieldStorage>
</field>
<field>
<fieldName>OwningAreaId</fieldName>
<fieldType>long</fieldType>
<fieldStorage>OwningAreaId</fieldStorage>
</field>
<field>
<fieldName>LastModifier</fieldName>
<fieldType>string</fieldType>
<fieldStorage>zone:LastModifier</fieldStorage>
</field>
<field>
<fieldName>LastModifiedDate</fieldName>
<fieldType>date</fieldType>
<fieldStorage>LastModifiedDate</fieldStorage>
</field>
<field>
<fieldName>Indexed</fieldName>
<fieldType>int</fieldType>
<fieldStorage>Indexed</fieldStorage>
</field>
<field>
<fieldName>IndexedDate</fieldName>
<fieldType>date</fieldType>
<fieldStorage>IndexedDate</fieldStorage>
</field>
<field>
<fieldName>Size</fieldName>
<fieldType>int</fieldType>
<fieldStorage>FileSize</fieldStorage>
</field>
<!-- Fields returned by Verity -->
<field>
<fieldName>Title</fieldName>
<fieldType>string</fieldType>
<fieldStorage>zone:DocMetadataTitle</fieldStorage>
</field>
<field>
<fieldName>Author</fieldName>
<fieldType>string</fieldType>
<fieldStorage>zone:DocMetadataAuthor</fieldStorage>
</field>
<field>
<fieldName>Keywords</fieldName>
Only TeamSite EAs (if there are any) and file properties are extracted from most other
types of documents, such as:
Raster image documents
Vector graphic documents
Executable files
Encapsulation formats
Sound file formats
Planning/outline formats
Scheduling/planning formats
Movie files
Animation files
You can specify other types of files for which content is not extracted using the
iw.index.binaryextensions parameter in the search.properties file (see page 142).
Using CLTs
CLTs have been created to manage the index and search servers. Refer to the
Command-Line Tools Reference for details on usage.
Search Examples
This section contains examples of searches based on a set of input constraints. Each
search example contains:
a brief description,
the code for using Interwoven Query Schema to define the query (required when
issuing the query with iwsrchquery),
a code fragment showing how to issue the query using the ContentServices API.
NOTE
The searches described in this chapter will work only after TeamSite Search is installed
and configured.
Example 1
Find all content in English that has either:
An attribute called LaunchDate that is equal to Oct 14, 2005, or
An attribute called TeamSite/Metadata/Description that contains the phrase This
file discusses the weather pattern.
<predicate xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TeamSiteSearch.xsd">
<queryLocale>en</queryLocale>
<or>
<attributeComparison><name>LaunchDate</name><operator>EQ</operator>
<value><![CDATA[14 Oct 2005]]></value></attributeComparison>
<fulltext-attribute>
<name>TeamSite/Metadata/Description</name>
<fulltext-phrase>
<term>This file discusses the weather pattern</term>
</fulltext-phrase>
</fulltext-attribute>
</or>
</predicate>
Example 2
Find all content in English that has either:
A file size greater than 20KB, or
File names that start with b and end with txt.
<attributeComparison><name>Size</name><operator>GT</operator><value><![
CDATA[20000]]></value></attributeComparison>
<areaRelativePath>
<wildcard>
b*.txt
</wildcard>
</areaRelativePath>
</or>
</predicate>
Example 3
Find all FormsPublisher (Templating) content in English that:
Belongs to the template category/type of internet/yacht, and
Has both:
A templating attribute called GeneralInfoLength (this maps to the xpath
/General Info/Length as specified in FieldMapping.xml) whose value is
greater than 200, and
A templating attribute called Details (this maps to the xpath /Details as
specified in FieldMapping.xml) that contains the full-text phrase example of a
boat that I would like.
<attributeComparison><name>GeneralInfoLength</name><operator>GT
</operator><value><![CDATA[200]]></value></attributeComparison>
</templatingAttribute>
<templatingAttribute>
<templateType>internet/yacht</templateType>
<fulltext-attribute>
<name>Details</name>
<fulltext-phrase>
<term>example of a boat that I would like</term>
</fulltext-phrase>
</fulltext-attribute>
</templatingAttribute>
</and>
</predicate>
Example 4
Find all content in English that has either:
Both the full-text terms hello and world, or
At least one full-text term beginning with environ.
<predicate xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TeamSiteSearch.xsd">
<queryLocale>en</queryLocale>
<or>
<fulltext-all>
<term>hello</term>
<term>world</term>
</fulltext-all>
<fulltext-wildcard>
<term>environ*</term>
</fulltext-wildcard>
</or>
</predicate>
Example 5
Find all content in English that has either:
An attribute called Description that contains both the terms weather and
patterns, or
<predicate xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TeamSiteSearch.xsd">
<queryLocale>en</queryLocale>
<or>
<fulltext-attribute>
<name>Description</name>
<fulltext-all>
<term>weather</term>
<term>patterns</term>
</fulltext-all>
</fulltext-attribute>
<fulltext-near>
<ordered>true</ordered>
<proximity>1</proximity>
<term>Scotland</term>
<term>Yard</term>
</fulltext-near>
</or>
</predicate>
Example 6
<predicate xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TeamSiteSearch.xsd">
<queryLocale>ja</queryLocale>
<or>
<fulltext-all>
<term> </term>
</fulltext-all>
</or>
</predicate>
NOTE
In this example, the Japanese strings are obtained from the file japanese.txt, where
they are stored in UTF-8 format.
Troubleshooting
The following topics provide additional information you may need regarding index and
search functionality.
Content in text (.txt) documents (including files with .cpp, .c, or .html
extensions) must be saved in UTF-8 encoding to be properly indexed and
searchable.
Searching on standard Author, Keyword, and Title metadata is possible only for
Microsoft Word documents.
When a non-Microsoft Office file (such as a .txt or .pdf file) that has “Document
Summary Info” is copied to a workarea, either through the Local File Manager or
through the file system, the “Document Summary Info” is not preserved so that
information is not indexed and cannot be searched.
If there is a comment in a file (<!-- and -->), then the last word in the file fails to
be indexed. Add a blank space after the last word to remedy this situation.
Comments (between <!-- and -->) in a .xml file are not indexed.
Search stemming is not supported.
Deleted Edition
If you delete the initial edition of a branch or the last indexed edition of a branch,
indexing of further assets on the branch cannot be done. You may obtain the last
indexed edition of a branch by using one of the Index Manager CLTs that provides the
detailed branch status.
If you delete the last edition of a branch before the index server has started indexing it,
you need to create a new edition; doing so ensures that the indexing of assets on the
branch work when the index server starts indexing it.
Deleted Branches
If a TeamSite branch was deleted without issuing the iwndxpurgebr CLT or the
iwndxrmbr CLT on that branch (see page 139), perform the following steps to clean the
state of the index server and search server for that branch:
1. Issue the iwndxstatus -a CLT to list information about all the branches the index
server knows about, including the deleted branch. From this list find the vpath of the
deleted branch exactly as it appears.
2. To purge the collection for the deleted branch from disk, issue the iwndxpurgebr
CLT and provide the branch vpath exactly as it appeared in the iwndxstatus output.
Alternately, issue the iwndxrmbr CLT and provide the branch vpath exactly as it
appeared in the iwndxstatus output.
These CLTs may issue an error message indicating that the specified branch does
not exist in TeamSite, but they will clean the state of the index server.
Configuration Issues
A incorrect entry in the FieldMapping.xml file may result in the index server not
coming up. Typically, an appropriate error message displays in the log. However,
sometimes based on the type of incorrect entry specified in the FieldMapping.xml
file, the index server may not come up and an appropriate error message may not be
entered in the log. In these cases, please double check your FieldMapping.xml file
for syntactic and semantic correctness.
Using CLTs
When configuring and administrating Search, do not run any Search administration
CLTs while the index server is starting up, until the event subsystem is available. If
you see an error message similar to: ERROR - DFsyEOFException: Unexpected end
of stream, wait several minutes and then run the CLT again.
The iwndxpurgebr CLT results in a 10002 error because indexed collection writers
(indexer, workarea indexer, purge branch) need to coordinate access to avoid
collection corruption. In this purge command, the index manager tries to remove the
collection directory. It could not remove everything because the collection is opened
in the search agent. Since it removed some of the unlocked files, the collection was
corrupted.
Use the iwndxrmbr CLT instead. This simply removes the branch from the index
manager but does not purge the collection. It is a safe operation.
Before using the iwndxpurgebr CLT, stop the search server so all current
connections to the collection are closed. Make sure that the indexing for the
branch (including workarea indexing) is not active. The branch must be frozen
first and indexer should be allowed time to finish the current jobs for this
branch. One can look into indexer logs for any active indexing jobs being
carried out for that branch.
Error Messages
This section provides index manager and server manager error codes and messages.
TeamSite metadata capture enables TeamSite users to add metadata information to files.
Metadata is a structured way to describe data in your files allowing you to organize and
manage it.
End users can access a field description by clicking on the question mark next to the
field name.
In addition to the convenience of having a default metadata capture form, the form is
easy to modify to reflect the categorization of metadata in your organization.
The following diagram shows how these components work together. Sections following
the diagram explain each diagram step and component in detail.
metadata-rules.cfg datacapture.cfg
2 2
5 5
iw-store
Diagram Key
1. The metadata CGI receives a list containing the names of the files that can have
metadata added to them. The list can come from an instantiated job (if metadata
capture is initiated from a job) or from the browser (if initiated from a TeamSite user
interface).
2. The metadata CGI reads both configuration files (metadata-rules.cfg and
datacapture.cfg) to determine what information it should display in the Tagger
GUI. It makes this determination on a per-file basis, so that the entry form can con-
tain different prompts and actions for different files.
3. The metadata CGI displays the Tagger GUI on the client system.
4. An end-user enters and submits the data using the metadata entry form and the meta-
data CGI.
5. The metadata CGI consults the rules in both configuration files to verify the validity
of the data entered by the user. If the data does not meet all necessary criteria, noti-
fication is sent to the user so that data can be re-entered.
6. If the data meets all necessary criteria, the metadata CGI adds the new metadata (in
the form of TeamSite extended attributes) to the specified files. The metadata CGI
interfaces directly with the Content Store to update the files with the new metadata.
7. If metadata capture was initiated from a job, the metadata CGI notifies the workflow
subsystem, which starts successor task 0 (zero) as defined in the job specification
file.
You can deploy these extended attributes to a database using Interwoven DataDeploy.
The deployment can be manual, or automatic using Database Auto-Synchronization
(DAS). See the Database Deployment for OpenDeploy Administration Guide for more
information.
<metadata-rules>
<cond vpath-regex="."> Vpath Identifier
<rule name="Default Rule" /> Rule Identifier
</cond>
Notes:
International Encoding—UTF-8 is an encoding of Unicode, a standard for encoding
the character sets of international languages. All of your content should specify their
encoding as UTF-8. For details about encoding, see Appendix G,
“Internationalization.”
Vpath Identifier—Names the vpath (in this case, all directories) to which the rules
named in the following subelements are applied.
Rule Identifier—Names the rule that applies to the preceding vpath. The rule itself
is defined in the <ruleset> element in iw-home\local\config\datacapture.cfg.
In this example, the Default Rule rule defined in datacapture.cfg always applies
to all directories.
<metadata-rules>
<cond vpath-regex="^/default/main/syndication"> Vpath Identifier 1
</cond>
<cond vpath-regex="\.doc$"> Vpath Identifier 5
</cond>
</cond>
</cond>
<cond vpath-regex="/corp/"> Vpath Identifier 13
</cond>
</cond>
</cond>
</metadata-rules>
Notes:
Vpath Identifier . Files on the\syndication branch always receive the rules named
1
following subelements.
Rule Identifier . The Default and Web Content rules defined in datacapture.cfg
8
Vpath Identifier . Files ending in .html on the \main\www branch receive rules in
9
Vpath Identifier . Files ending in .html in the corp directory on the \main\www
13
branch receive rules in addition to those defined by Default and Web Content.
Rule Identifiers . The Corporate rule defined in datacapture.cfg applies to files
14
Rules contain items, where each item is a single set of data that is to be captured from
the end-user. An item consists of one or more instances. Each instance encapsulates how
to capture the data for the item, and each instance defines an ACL that determines which
(if any) instance a particular user is allowed to use to enter the data.
The metadata capture form is a data capture template (DCT) that is configured
specifically for metadata capture. The data capture subsystem that generates the
metadata capture form is similar to the subsystem that generates data capture templates
for FormsPublisher. A major difference between the two implementations is the location
of the datacapture.cfg file. FormsPublisher relies on multiple datacapture.cfg files
(one for each data type), while metadata capture relies on a single datacapture.cfg file
(in iw-home\local\config).
The datacapture.cfg file uses the following DTD (it is also installed by the TeamSite
installation program in iw-home\local\config\). The datacapture.cfg files must
have been created using metadatacapture6.0.dtd.
<!-- metadatacapture6.0.dtd Version 1.1 2/12/04 -->
<!-- Start with some basic parameter entities. -->
<!ENTITY % data-capture-requirements-contentspec "(ruleset+)*">
<!ENTITY % items "container|view-container|view|item">
<!ENTITY % chooser-options "option|inline">
<!ELEMENT data-capture-requirements
(%data-capture-requirements-contentspec;)>
<!ATTLIST data-capture-requirements
name CDATA #IMPLIED
type (metadata) #REQUIRED
dtd-system-identifier CDATA #IMPLIED
>
<!-- The ’dtd-system-identifier’ attribute is a URI indicating the
DTD from whence a particular data-capture-requirements was
derived, if any.
-->
<!--The form of this element is exactly the same as that for the callout
element in datacapture.4.0.dtd. -->
<!ELEMENT cgi-callout EMPTY>
<!ATTLIST cgi-callout
label CDATA #REQUIRED
url CDATA #REQUIRED
window-features CDATA #IMPLIED
>
<select>
<inline command="command name" />
</select>
runs the "blah" callout program, and that program returns this text:
<substitution>
<option label="ABC" />
<option label="123" />
<option label="Jackson 5" />
</substitution>
then the DCT snippet will, after callout execution and inline
substitution, look like:
<select>
<option label="ABC" />
<option label="123" />
<option label="Jackson 5" />
</select>
-->
<!ELEMENT inline EMPTY>
<!ATTLIST inline
command CDATA #REQUIRED
>
International Encoding
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE data-capture-requirements SYSTEM "metadatacapture6.0.dtd">
Rules contain "items"; one item is a single (set of) data that is
to be captured from the end user. An item consists of one or more
"instances". Each instance encapsulates how to capture the data
for the item, and each instance defines an ACL that determines which
(if any) instance a particular user is allowed to use to enter the
data. Instances are text, textarea, radio, checkbox, select, and
replicant.
<item name="Keywords">
<description>
Keywords can include terms that are not in the asset itself.
</description>
<database data-type="VARCHAR(100)" />
<text required="f" size="32" maxlength="60" />
</item>
<item name="Description">
<description> Description Elemen
A brief summary of 250 characters or less.
</description>
<database data-type="VARCHAR(100)" />
<textarea required="f" rows="5" cols="72" wrap="virtual"
maxlength="250" />
</item>
</view>
Notes:
International Encoding—UTF-8 is an encoding of Unicode, a standard for encoding
the character sets of international languages. All web assets should specify their
encoding as UTF-8. For details about encoding, see Appendix G,
“Internationalization.”
Metadata Identifier. When configuring datacapture.cfg for metadata capture, you
must specify "type=metadata" in the <data-capture-requirements> element as
shown here.
Rule Identifier. The <ruleset> element contains all of the items that make up the
rule set defining the appearance and behavior of the data capture form. A
datacapture.cfg file that is configured for metadata capture can contain any
number of <ruleset> elements (as opposed to FormsPublisher datacapture.cfg
files, which can contain just one <ruleset> element). This example file happens to
contain just one <ruleset> element; it could contain more if necessary. The rule
defined here is named Default Rule and is referenced by the metadata-rules.cfg
file shown on page 176. The name attribute is required and its value appears in the
TeamSite user interfaces as the name of the data capture form. Optional subelements
Table 13 Datatypes
Datatype Description and Example
DATE If data-type is DATE, the data-format must be a format string that is
valid for the Java simple date format class. Formats do not have to be
year-month-day, any valid format will work.
<database data-type="DATE" data- format="yyyy-mm-dd" />
<text maxlength="10"
validation-regex="^[0-9][0-9][0-9][0-9]-[0-1] [0-9]-[0-3]
[0-9]$" />
INT Allows any integer up to 7 digits. This example assumes that you want
to store data as integers, not dollars and cents.
<database data-type="INT" />
<text maxlength="7"
validation-regex="^[0-9]\{0,\}$" />
REAL Allows any decimal up to 8 digits (including decimal). The regex
allows 0 or more digits, followed by a decimal point, followed by zero
or more digits.
<database data-type="REAL" />
<text required="t" maxlength="8"
validation-regex="^[0-9]\{0,\}\.[0-9]\{0,\}$" />
If users encounter an error with the Tagger GUI, an error message tells them to contact
their system administrator. The system administrator should check the servletd log file
for more information on the configuration problem.
Troubleshooting
The following issues with metadata capture have resulted in the changes to the metadata
capture feature:
Standard name-value pairs from a datacapture.cfg file for metadata capture are
not posted to the resulting callout CGI.
Callouts from MetaTagger CGI do not support showing file names.
The area_path variable does not show the full path with the file name.
The path of a file being tagged is passed as form data in MetaTagger callouts.
Previously, this information was passed as path_indexnumber.
In the MetaTagger UI for single files, the path_0 value is posted with the file system
path to the file being tagged. For example, the form data would contain something
similar to:
y:/default/main/br1/WORKAREA/wa1/file.txt now
In the MetaTagger UI for multiple files, path_0, path_1, path_2... path_n values are
posted to provide all the files that are being tagged. A new form variable called
iw_callback_path contains the path_X string indicating which file a callout
corresponds to. For example:
Form data
---------
Callout prop30247927
Callout prop1682317
Callout prop6972548
iw_callback_path path_0 <====== this tells you that it's for the file
"atestfile.txt"
path_0 Y:/default/main/StressTestA/WORKAREA/test_wa1/atestfile.txt
path_1 Y:/default/main/StressTestA/WORKAREA/test_wa1/atag.txt
path_2 Y:/default/main/StressTestA/WORKAREA/test_wa1/11223344.txt
prop1682317 callout for path_0
prop30247927 callout for path_1
prop6972548 callout for path_2
Field access and validation is now done from the cgi called by the callout. However, the
field names have changed from being the actual field name (such as Title and Author)
to propXXXXXXXX. This format supports multi-file tagging where the UI layout shows
only one specific field corresponding to all the files. With this format, you see all the
Title fields for file 1, 2, 3, etc. on one page. You do not see any of the other fields in
conjunction.
In the MetaTagger UI for a single file, to determine what propXXXXXXXX means in terms
of actual field names, a mapping from the actual field name to the propXXXXXXXX names
is now posted. For example:
Form data
---------
Callout prop33462681
Description prop32955489
Keywords prop4078723
Title prop24746526
path_0 Y:/default/main/StressTestA/WORKAREA/test_wa1/atag.txt
prop24746526 search project
prop32955489 project for search
prop33462681
prop4078723 search verity
Here you can see that if you need to access the value of the Title field, you have one
extra step to get to the value:
Title > prop24746526 >search project
In the MetaTagger UI for a multiple files, callouts were not designed for this case so
their usefulness is somewhat limited. For example, the form data would appear as
follows:
Form data
---------
Callout prop30247927
Callout prop1682317
Callout prop6972548
iw_callback_path path_0
path_0 Y:/default/main/StressTestA/WORKAREA/test_wa1/atestfile.txt
path_1 Y:/default/main/StressTestA/WORKAREA/test_wa1/atag.txt
path_2 Y:/default/main/StressTestA/WORKAREA/test_wa1/11223344.txt
prop1682317 callout for path_0
prop30247927 callout for path_1
prop6972548 callout for path_2
The mapping from actual field name to the propXXXXXXXX field names is again present,
but it is only for one field per page. In this case it is for the Callout fields corresponding
to all the files being tagged. The array of Callout values is ordered the same as the file
indices, hence it is easy to determine which Callout field goes with which file. It is not
recommended that callouts be used in the multi-file case for traditional cross field
validation as it cannot be done. To mimic cross-field validation in this scenario, run an
external script to access the file determined by the iw_callback_path variable and read
the extended attributes outside of the MetaTagger UI context.
You could also modify the item names or view names to modify these forms for your
use.
For more extensive form design, refer to the TeamSite FormsPublisher Developer’s
Guide for guidance.
The following sections describe the configuration settings for the TeamSite web daemon
and the TeamSite proxy server. They begin with an overview of each of these features,
and then are followed by sections on specific configuration settings.
About the TeamSite Web Daemon
About the Proxy Server
Configuring TeamSite Web Daemon and Proxy Server Operation
Resolving Fully Qualified URLs
Redirecting Fully Qualified URLs
Redirecting TeamSite Views to Different Areas
Configuring TeamSite to Use Different Web Servers
Configuring External Remappings
Host Header Remappings
Enabling iwproxy Access Control
Configuring SSI Remapping
Configuring Proxy Failover
Debugging Your Proxy Server Configuration
Browser iwwebd
iwproxy servletd
Customer TeamSite
Web server File System
Remote contributors can use TeamSite securely without having to establish a Virtual
Private Network (VPN). The iwwebd web daemon also serves the non-servlet-based
parts of TeamSite ContentCenter. For an illustration of how requests are processed, see
Figure 4 on page 28.
Each time a request is made through the TeamSite proxy server, the following sections
of iw.cfg are processed as shown in the following graphic. More than one rule may be
applied to a request. When a rule matches a URL—depending on the section in which
the rule was specified—either an HTTP redirect is sent back to the browser to indicate
the new location or the URL is rewritten and passed to the new section. The first rule
that matches in any section prevails; no other rules in that section are applied.
No
Can the rewritten path iwproxy_failover_remap
be found?
See Configuring Proxy Failover.
Yes Sends the rewritten path to be
reprocessed.
NOTE
iwreset -a does not apply changes to the [iwproxy_remap] or
[iwproxy_plugin_remap] sections of iw.cfg if you are using Web server plug-ins. If
you make changes to these sections and you are using Web server plug-ins, you must
restart the Apache Web server (not the Apache Tomcat, IBM WebSphere, or BEA
WebLogic web application server) to apply the changes.
[iwproxy]
customer_webserver_host=hostname or IP_address
iwproxy_host=proxy_hostname
iwproxy_port=1080
customer_webserver_port=81
where:
customer_webserver_host is the host name of the content Web server. The value
must be set to the host name of the Web server that serves the content of your Web
sites.
iwproxy_host specifies the host where the TeamSite proxy daemon runs. Usually
this is the TeamSite server.
iwproxy_port is the port on which the TeamSite proxy server operates. It should be
set to an open port value. This port need only be open to the TeamSite proxy server.
It may be blocked from end-user clients for added security.
customer_webserver_port is the port through which the TeamSite proxy server
communicates with the Web server. It must be set to the value of the port used by the
Web server.
The settings in the [iwproxy] section are set during the TeamSite installation. They can
be manually edited if necessary.
For example, the file whose directory path (rooted in a TeamSite area) is
/main/index.html might contain a link to the file /images/banner.gif. This link can
be specified as either a relative or an absolute path as follows:
As a relative path:
../images/banner.gif
As an absolute path:
/images/banner.gif
NOTE
The proxy server does not allow you to remap the document root directory for Content
Store branches other than the default Content Store.
Links in HTML documents are often specified with relative or absolute path names. For
example, in a link to an image, the file name might appear as:
/images/miles.gif
On a typical Web server, this link reference would be mapped by the Web server to its
document root, for example:
/images/miles.gif D:\inetpub\wwwroot\images\miles.gif
All users that attempt to access the file using the absolute path name are mapped to the
same file location on the Web server.
However, TeamSite supports a system of private workareas, giving each user access to
the Web site’s files from within their own personal, virtual version of the Web site.
TeamSite uses a proxy server to manage mapping of files to workareas with relative and
absolute path references. Using the previous example, the TeamSite proxy server
enables all users attempting to access /images/miles.gif from within TeamSite to be
mapped to the copy of miles.gif in their own workareas. The redirected mapping
would look like:
/images/pic.gif Y:\default\main\branchpath\WORKAREA\workareaname\im
ages\miles.gif
Document Roots
TeamSite maps the initial Web server directory structure (the document root) of
workareas to the top level of the workarea directory by default. You may, however, want
to move the document root, or group types of files together for improved clarity,
convenience, or efficiency. On a branch-by-branch basis, the TeamSite proxy server
allows you to remap the document root anywhere within the workarea directory. It also
allows you to define mappings directly to subdirectories within workareas.
NOTE
The proxy server does not allow you to remap the document root directory for Content
Store branches other than the default Content Store.
Document roots are defined in the [iwproxy_remap] section of iw.cfg. The default
setting is as follows:
[iwproxy_remap]
global_default_map=/
NOTE
The iw.cfg file also contains a section called [global_default_map]. There must be a
corresponding section for each parameter defined in the [iwproxy_remap] section.
where configSectionName is the name of the section of the configuration file that
defines the branch remappings, and vpath is the vpath to the branch you are
configuring.
2. For each line that you added to [iwproxy_remap] section, create a section in iw.cfg
named [configSectionName].
3. Add a line to this new section that defines the document root:
_docroot=dirpath
The first line tells TeamSite to use the section [branchrewrite_1] to set the document
root configuration for the /main branch. The second line tells TeamSite to use the
[branchrewrite_2] section to set the document root configuration for the
/main/training branch.
You would then create two new sections in iw.cfg corresponding to the lines in
[iwproxy_remap]:
[branchrewrite_1]
_docroot=/htdocs
/pictures/=/pictures/
/html/=/html/
[branchrewrite_2]
_docroot=/htdocs
/images/=/images/
Note that the first line of both the new sections contains _docroot=/htdocs. This
defines a special directive that sets the mapping of the document root. Any requests
from workareas on the main branch or the main/training branch to the root level
directory (/) now start at:
.../workareaname/htdocs/
Thus, the request for file /miles.gif will now be mapped to:
.../workareaname/htdocs/miles.gif
The two docroot configuration sections also contain lines similar to the following:
/pictures/=/pictures/
This line maps file requests directly to the listed directory /pictures/, bypassing the
document root defined in the first line. Thus, a request for the file
/pictures/mingus.gif gets mapped to:
.../workareaname/pictures/mingus.gif
not:
.../workareaname/htdocs/pictures/mingus.gif
The TeamSite proxy server operates using literal string matches and substitutions in
path names. To avoid inadvertently rewriting names, always use trailing slashes in your
remap definitions.
NOTE
Do not use trailing slashes in your remap definitions for _docroot directories.
If such a link appears in an HTML file in a TeamSite workarea, and you follow that link
while performing in-context QA, you will be taken out of the workarea and to the actual
referenced Web site.
Therefore, if you use fully qualified URLs to reference pages within your own Web site,
clicking on these links will take you out of the in-context view of the current workarea,
staging area, or edition and into your own currently deployed Web site. To solve this
problem, TeamSite enables you to configure your proxy server to redirect fully qualified
links within your Web site, then pass them to the regular proxy server to ensure the
integrity of the in-context view in a workarea, staging area, or edition.
NOTE
Only configure this setting if your Web site uses fully qualified URLs that you need to
view in-context. This setting requires you to manually configure your browser, so that
you cannot view the actual Web site without reconfiguring your browser. This also
slows the TeamSite server by sending every request through iwwebd and iwproxy.
enables the feature and redirects links that specify http://www.example.com in the
URL and sends them to the corresponding location in the current TeamSite area.
NOTE
If your iw.cfg file’s [iwwebd] section defines the host as host=hostname.domain, and
your browser's proxy server is set to hostname.domain:port, when you start TeamSite,
you must enter http://hostname.domain/iw/ in your browser rather than
http://hostname/iw/.
Continue the configuration by completing the procedures described in the next sections.
The TeamSite web daemon can be used as a proxy server to connect to any outside
address and access content. You can create a regex in the
[iwproxy_fullproxy_redirect] section of iw.cfg to disable this functionality. Refer
to the [iwproxy_fullproxy_redirect] section of iw.cfg.example for details.
Using iwproxy_preconnect_remap
To configure TeamSite to redirect workarea views and retain your original area as the
current working area (as described in the first bullet), edit the
[iwproxy_preconnect_remap] section of iw.cfg as follows:
[iwproxy_preconnect_remap]
_regex=source_regex=dest_ex
workarea, staging area, or edition. You can add any number of _regex lines to this
section.
For example:
_regex=(.*)/branch1/WORKAREA/[^/]+/products/(.*)=$1/branch2/
STAGING/products/$2
tells the proxy server to remap the products directory of any workarea on any branch
named branch1 to the products directory of the staging area on its sister branch,
branch2.
In the source regular expression, (.*) is used to specify an arbitrary path, and $1 in the
destination expression means that it must follow the same path (and therefore branch1
can be anywhere in the branch structure, but branch2 is a sister branch of branch1).
Also in the source regular expression, [^/]+ is used to specify a single directory level,
of any name (which in this case would be the workarea name, and therefore all
workareas on branch1 are specified). Finally, the source regular expression uses (.*) to
specify another arbitrary path, and $2 in the destination expression tells it to follow the
same path.
You can also specify the exact location of the areas you want to remap:
_regex=^/
iw-mount/default/main/branch1/WORKAREA/[^/]+/products/(.*)=/
iw-mount/default/main/branch2/STAGING/products/$1
The TeamSite proxy server applies the first match it finds, so you can exclude a
particular area from a more general rule by creating a separate rule for that area and
placing it before the more general rule. For example:
_regex=(.*)/branch1/WORKAREA/chris/products/(.*)=$1/branch1/
STAGING/products/$2
_regex=(.*)/branch1/WORKAREA/[^/]+/products/(.*)=$1/branch2/
STAGING/products/$2
remaps the products directory in all workareas on branch1 except for Chris’s to the
staging area of branch2.
See “Configuring Proxy Failover” on page 207 for more details about configuration rule
precedence.
Using iwproxy_preconnect_redirect
To configure TeamSite to redirect workarea views and cause the area you redirect into to
become the current working area (as described in the second bullet on page 202), edit
the [iwproxy_preconnect_redirect] section of iw.cfg:
[iwproxy_preconnect_redirect]
_regex=source_regex=dest_ex
For this to work properly, the other Web server must have the appropriate TeamSite
directory mounts and privileges. The Web server alias used by httpd on port 1234 of
test1.example.com must be configured with the TeamSite alias as well (/iw-mount/).
The following example would allow Andre to test all CGIs in his workarea on
test1.example.com, as previously described:
[iwproxy_preconnect_remap]
_regex=^/iw-mount/default/main/branch1/WORKAREA/andre/(.*)\.cgi
(\?.*)?$=http://test1.example.com:1234/iw-mount/default/main/branch1/
WORKAREA/andre/$1.cgi$2
Using iwproxy_preconnect_remap
To configure TeamSite to redirect workarea views to external Web servers, edit the
[iwproxy_preconnect_remap] section of iw.cfg as follows:
[iwproxy_preconnect_remap]
_regex=source_regex=dest_ex
sends all requests for files in the /logos directory in all workareas on branch1 to
another server, corporateidserver.example.com.
Using iwproxy_external_remap
You can also use [iwproxy_external_remap] rules for external remappings, although
[iwproxy_preconnect_remap] is the preferred methodology.
For example, if all your corporate logo files reside on a separate server, you can use
[iwproxy_external_remap] to create a mapping to the directory where they reside:
[iwproxy_external_remap]
/logos/=http://corporateidserver.example.com/logos/
This remapping sends all requests for /logos/ to a directory on another server,
corporateidserver.example.com/logos/. You can also create associations using
case-insensitive regular expression mapping.
create a mapping for /logos/ in one of the [branchrewrite] sections, all requests on
that branch for files in the /logos/ directory will use that mapping instead of the
external mapping. Requests on other branches will still be sent to the
corporateidserver.
_regex=^/iw-mount/default/main/branch1/WORKAREA/.*=example.com:1234
will change the Host: header that the source server gets from the TeamSite proxy server
to read:
Host: example.com:1234
All users should be able to read any document on the internet site.
For all other branches, iwproxy should check to ensure the current user has read
access.
[iwproxy_access_control_enabled]
_default=yes
_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/)]+)|ST
AGING)/hr/=yes
_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/]+)|STA
GING)/=no
_regex=^/iw-mount/dc/main/www%20external/(((WORKAREA|EDITION)/[^/]
+)|STAGING)/=no
If you want to debug regular expressions, set the value for _debug in the
[iwproxy_plugin_remap] section to true. On NES, debugging information is stored in
the Web server error log file. On IIS, this information is stored in
C:\temp\iw_isapi.log. This log file can grow extremely large over time.
No
iwproxy_preconnect_remap
iwproxy_hostheader_remap
iwproxy_smartcontextedit_allowed
Yes
To specify the number of times to try to remap a URL, edit the _maxfail line of the
[iwproxy_failover_remap] section of iw.cfg. The default value of this line is
_maxfail=0, which turns off proxy failover. Note that proxy failover is seldom needed
because files are almost always in locations that can be specified using static,
case-insensitive regular expressions during configuration. If you need to enable proxy
failover, it is recommended that you do not set _maxfail to more than 1 or 2 due to the
impact on system performance.
iwproxy [-d|-x]
iwproxy returns debug output which you can redirect to a file. Note that the iwproxy
debug mode is single-threaded; it therefore slows the TeamSite server down
significantly. Use the debug mode for diagnostic purposes only.
One common source of proxy configuration problems is the inclusion of any character
or blank space past the end of a branch name in any line in any [iwproxy*] section in
iw.cfg. For example, the following line in the [iwproxy_remap] section is illegal
because it contains blank spaces and characters after the branch name:
[iwproxy_remap]
tag_engspecs=/main/engspecs #This is the engineering spec site
NOTE
iwproxy.exe needs to run as local Administrator or a user with the following access
privileges: Act as Part of Operating System, Log on Locally, Increase Quotas, and
Replace a Process Level Token.
Backing Up TeamSite
Your TeamSite Content Stores represent a tremendous investment in resources and are a
valuable corporate asset. As such, they should be backed up daily, or even more
frequently, to minimize the possibility of damaged or lost data. Any third-party backup
solution that can guarantee exact time and state directory content recovery can be used.
If the available backup method is efficient and inexpensive (compared to the value of
the data being protected), the TeamSite workareas can also be backed up to allow users
to recover individual files or directories from their workareas, rather than having to
recover the entire Content Store. This is a very convenient feature for users, but can
come at a relatively high price in terms of extra time and space needed for these
redundant backups. Although the virtual files which comprise much of theTeamSite file
system mount (Y:) take up no extra space on the TeamSite server, if the actual TeamSite
workareas are backed up, the virtual files in the workareas will be treated as actual files
and will take up space in the backup media.
NOTE
Workarea backup must be done through the Y: drive.
You must freeze the TeamSite Content Store (with the iwfreeze command) while you
are backing up your Content Store or workareas. Failure to freeze the Content Store
while you are backing up can result in possible data loss and corruption. For details
about the iwfreeze CLT, refer to TeamSite Command-Line Tools for your platform.
NOTE
If you are using multiple Content Stores, you can back up each store independently. The
iw-store directory should be backed up if you have in-progress workflows or batch
jobs that you do not want to lose. Because workflows can span all stores, a full frozen
backup of all stores and the workflow store is needed. You can freeze and unfreeze the
workflow store just like any other store, but you cannot move it outside of iw-store.
Backing up workareas alone is not a substitute for backing up the TeamSite Content
Store. If you only back up the files that appear in the TeamSite file system mount, you
will lose important metadata such as version histories and file status. Always back up
the actual TeamSite Content Store whether or not you back up individual workareas.
To determine your optimal backup strategy, you must analyze the trade-offs of
convenience and speed in backing up versus simplicity and speed of restoration, and
decide what best suits your needs. A strategy using a single full backup and an indefinite
string of incrementals is optimized for backup speed, but the amount of time required to
perform a full recover of the Content Store grows with each passing day as a new
incremental is added to the list. Every backup must be preserved to be able to recover
the Content Store. One benefit of this method is that a complete daily record of the
Content Store will be preserved.
The opposite extreme is to perform a full backup every day. Each backup will take the
maximum amount of time to perform, but only one recover needs to be done to
completely recreate the Content Store. If you only preserve the previous day’s backup,
no history of the Content Store will be retained, but the amount of storage space used by
the backups is minimized.
Configuring TeamSite
ReportCenter
The TeamSite ReportCenter integrates with Crystal Enterprise to allow you to run
standard reports and to create additional reports. When TeamSite ReportCenter is
installed, authorized users of ContentCenter Professional have a Reporting tab that
provides access to available reports and displays the results of requested reports.
NOTES
If Crystal Reports conflicts with TeamSite on Port 81, create the Crystal Reports
web site on a different port.
ReportCenter Overview
TeamSite ReportCenter obtains information from the Event Subsystem (page 51).
Information is stored in a relational database and can be read by Crystal Enterprise
software to obtain reporting information.
Event
TeamSite subsystem
Report
Module
TSReport
RDBMS
Reporting
Messaging UI RDBMS
library
Event Crystal
Proxy Enterprise
The new messaging library provides TeamSite with a reliable method of publishing
events. This library exports a write/read interface, which can be used by event
publishers and subscribers. The TeamSite server uses the message library to write events
and the new proxy service reads such events and propagates them to the Interwoven
Event Subsystem.
The TeamSite report server subscribes to events published by the TeamSite core server
engine, the workflow engine, and the templating engine. On receiving events from the
Interwoven Event Subsystem, the report server archives these events into the reporting
database. In some cases, the report server will query the engine that generated the event
for additional information. Some examples of this are:
Query the core server for all files submitted as part of a submit event.
Query the workflow engine for all files associated with a task.
To query on workflow events, modify the iw.cfg file so jobs are not deleted from the
content store when they complete, as follows:
[workflow]
delete_jobs_on_completion=false
The TeamSite report server archives the event-related information into a relational
database provided by the customer. The report server adheres to the JDBC standard
while accessing and modifying a database. The reporting service supports the following
databases: Oracle 8i, Oracle 9i, MS SQL Server 2000 and IBM DB2 8.1. The database
schema should be created prior to starting the TeamSite report server. The necessary
DDL scripts will be provided with the reporting server package.
This section shows the complete file and then describes the configuration parameters in
each area and specifies the information to be modified. Most of the information in this
file is entered during the installation. You should generally make changes to this file
using the iwconfigtsreport CLT.
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<License key="_LICENSE_KEY_"/>
<!-- ********************** Logging ******************************** -->
<Logging>
<!-- See org.apache.log4j.xml.DOMConfigurator for more details -->
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="tsreport" class="org.apache.log4j.FileAppender">
<param name="File" value="_IWLOGDIR_/tsreport.log" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%d{HH:mm:ss.SSS} %-5p [%t] - %m\n"/>
</layout>
</appender>
<root>
<priority value="ERROR"/>
<appender-ref ref="tsreport"/>
</root>
<category name="com.interwoven">
<priority value="INFO"/>
<appender-ref ref="tsreport"/>
</category>
</log4j:configuration>
</Logging>
<Product>
<param name="type" value="teamsite" />
<param name="name" value="Product : TeamSite" />
<param name="ref-id" value="1" />
<param name="database-id" value="42" />
</Product>
<Listener class="com.interwoven.tsreport.server.TeamsiteListener"
topic="Interwoven" product-ref="1">
<param name="Reportable Extended Attributes">
<value name="key"/>
<value name="key1"/>
<value name="key2"/>
</param>
<JobVariables>
<variable name="" />
<variable name="" />
<variable name="" />
</JobVariables>
</Listener>
</EventServer>
</Receiver>
</configuration>
License key
The license key is added to this file during installation. If you do not have the license
key when you install TeamSite, rerun the reporting installation module.
Logging
The <param> element describes where the log file is written; the directory where the file
is located may be changed during installation.
The <priority> element within the <category> element can be changed to reflect the
level of debugging. The levels of debugging are ERROR, WARN, INFO, and DEBUG. Refer to
http://logging.apache.org/log4j/docs/ for details.
Database
The installation software enters this information into this file.
The <poolsize> element describes the number of threads to connect to the database;
leave this at one.
The <driver> element refers to the database driver required.
The <URL> element is the URL connect string.
The <user> element refers to the database user. During installation, you are also
asked for this user’s password; it is stored in a different file.
NOTE
For DB2, the pagesize of the user tablespace should be 16K for the database where
the Report Center schema will be created.
CSSDK
If the report server is being run under an account other than SYSTEM, you must also
add the user and role. The user account under which the reporting server is running must
be a TeamSite user in a role with sufficient privileges.
The <poolsize> element describes the number of threads to connect to the database;
leave this at one.
The <server> element identifies the server where TeamSite is running.
The <configfile> element provides the location of the configuration file.
The <locale> element identifies the language of the server.
Product
This section is currently a placeholder for future release; you do not need to make
changes.
Receiver
This section should be manually edited.
You need to specify values for the <param> element named Reportable Extended
Attributes at the end of the file. Replace key, key1, and key2 with the names of
extended attributes to be reported on. Add additional value elements as needed. If the
EAs in metadata.cfg are to be reported on, the full name should be specified, such as
TeamSite/Metadata/EAName.
The jobvariables section captures workflow and task variables. Job variables are
captured on WorkflowActivate events, and task variables are captured on
TaskInactivate events.
You must restart the report server after making these changes in order for them to take
effect.
Archived Events
The following server events are archived in the reporting database.
The following user events are archived in the reporting database. The events SetEA
through DestroyFSE are only available when turned on by iwat scripts as described in
TeamSite Command-Line Tools.
Database Schema
The iw-home\tsreport\conf\ddl\tables.xml schema lists the available tables in
Reporting.
<?xml version="1.0"?>
<!--A reference xml file listing all tables involved in the reporting
module -->
<database>
<schema name="teamsite_report_schema">
<table name="EventsSummary"/>
<table name="WFEventsSummary"/>
<table name="Files"/>
<table name="FileVersions"/>
<table name="WFTaskEventComments"/>
<table name="ExtendedAttributes"/>
<table name="VersionedFileEAs"/>
<table name="DataCaptureTemplates"/>
<table name="report5_view"/>
<table name="report6_view"/>
</schema>
</database>
Every table has a schema that describes the columns. Most of the columns are
self-explanatory and use basic data types as described in the schema. All tables in the
reporting database schema have an ID column. This column is used to uniquely identify
a row in each table. This ID is globally unique across the entire schema. The ID column
is also the primary key in each case.
For example, the following code from a schema describes the FileVersions table. Each
row in this table represents a particular version of a file or directory in TeamSite. Each
time a submit event is generated, each file associated with the submit is entered as one
row in this table.
- <table name="FileVersions">
<attribute name="ID" type="char(40)" not_null="true" />
<attribute name="EventID" type="char(40)" not_null="true" />
<attribute name="SubmitType" type="varchar(32)" not_null="true" />
<attribute name="FileID" type="char(40)" not_null="true" />
<attribute name="FileType" type="varchar(32)" not_null="true" />
<attribute name="LastModifier" type="varchar(32)" not_null="true" />
<attribute name="ContentModificationTime" type="datetime"
not_null="true" />
<attribute name="AttributeModificationTime" type="datetime"
not_null="true" />
<attribute name="Comments" type="blob" not_null="false" />
<attribute name="Version" type="varchar(255)" not_null="true" />
<attribute name="DctId" type="char(40)" not_null="false" />
<attribute name="DcrId" type="char(40)" not_null="false" />
</table>
This table has four columns that serve as foreign keys indexing into the other reporting
tables (as illustrated in Figure 39):
1. EventID: This column maps to the ID columns in WFEventsSummary table and
EventsSummary table. Since the ID column is a globally unique identifier, it is safe
to use one column to map to two separate tables. This column identifies the event
associated with this file version.
d. FileID: This column maps to the ID column in the Files table. This provides the
file name and path information for this particular file version.
e. DctID: This column maps to the ID column in the DataCaptureTemplates table
and provides the category and type information of the data capture template
used to create this data record. If a particular file version is not a data record,
then this column has a null value.
f. DcrID: This column maps to the ID column in the FileVersions table itself. This
column identifies the particular version of the data record used to generate the
applicable output file.
Each database type has its own schema. The schemas are located in the
iw-home\tsreport\conf\ddl directory and are named: db2_schema.xml,
mssql_schema.xml, mysql_schema.xml, and oracle_schema.xml. Except for the
attributes and values for the <jdbc> element and the datatypes of the columns, the files
are identical.
The other reports defined in the tables.xml schema are described here and the mapping
relationships are illustrated in Figure 39:
EventsSummary. Every TeamSite event, with the exception of workflow-related
events, is archived in this table. Each event is persisted as a separate row in this
table.
WFEventsSummary. All events generated by the TeamSite workflow engine are
archived in this table.
Files. This table contains all files in the TeamSite repository that are either
versioned or were at any time part of a workflow task. The entries in this table are
vpaths and do not by themselves provide any version information.
ExtendedAttributes. This table contains a list of all extended attribute key/value
pairs. Each row in the table is a unique extended attribute name and value.
DataCaptureTemplates. This table contains all the category and type information
for all the templates defined in TeamSite. Each row in the table uniquely represents
a particular category and type.
WFTaskEventComments. This table contains all comments associated with a
particular task or job event. Any job or task transition to a particular state generates
an event, which could potentially have comments associated with it. All these
comments are archived in this table. The table has a column EventID that serves as a
foreign key and maps to the ID column in the WFEventsSummary table.
VersionedFileEAs. This table establishes a many-to-many relationship between the
FileVersions table and the ExtendedAttributes table. In TeamSite, one file can have
many extended attributes and a single key/value pair can be an extended attribute on
multiple files. The two main columns in this table are:
a. VersionedFileID: This foreign key maps to the ID column in the FileVersions
table and represents a particular file version.
b. EAID: This columns maps to the ID column in the ExtendedAttributes table
and represents one particular extended attribute.
Database Drivers
The Crystal Enterprise server must have the appropriate database client drivers installed
and configured. Because Crystal Enterprise accesses the TeamSite Events database
when rendering the TeamSite reports, the Crystal Enterprise server must be configured
appropriately to have access to this database. For example, it may be required to have an
ODBC System DSN entry referring to the TeamSite events database on a Crystal
Enterprise server. In the case of Oracle, it may be required to install an Oracle client
with the appropriate TNS setup on the Crystal Enterprise server. Please refer to the
Crystal Enterprise Administrative Guide and the appropriate database manuals for
details.
Reports on Crystal Enterprise have Crystal-proprietary ACLs associated with them. For
a user to view a TeamSite report, the users should have “View on Demand” rights
granted to them on the reports (or the folder that contains these reports).
Clicking the ContentCenter Logout link will also log the user out of Crystal Enterprise
if the user has logged into reporting during the TeamSite session. Only the session
created within ContentCenter is logged out. Crystal Enterprise sessions in other
windows, including those pointed to the Crystal Enterprise user interface, are not
affected.
Troubleshooting
This section contains troubleshooting issues related to Reporting.
If you have a large number of files submitted, such that a report may return more than
20,000 files, you need to change the Crystal Enterprise configuration to allow the larger
number of files. Otherwise, ContentCenter users will see an error message. Refer to the
Crystal Enterprise online knowledge base.
Configuring Microsoft SQL Server 2005 for Use with TeamSite Report Center
NOTE
To configure the SQL Server 2005 for use with the Event Subsystem, refer to
“Configuring Microsoft SQL Server 2005 for Use with the Event Subsystem” on page 54.
To use the Microsoft SQL Server 2005 with the TeamSite Report Center, install and
configure MSSQL Server 2005 manually as follows:
1. Stop the Interwoven TeamSite Report Service. Use the Services control panel.
2. Uninstall the Interwoven TeamSite Report Service:
iw-home\tsreport\bin\tsreport.exe -uninstall iwtsreport
url="jdbc:microsoft:sqlserver://_SERVERNAME_:_PORT_;databaseName=_DATA
BASE_;selectMethod=cursor;"/>
So that it appears as follows:
<jdbc driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
url="jdbc:sqlserver://_SERVERNAME_:_PORT_;databaseName=_DATABASE_"/>
NOTE
Do not substitute the tags with "_" (underbar) with the actual values.
-start com.interwoven.tsreport.server.ReportServer
-params -startServer -config "iw-home\tsreport\conf\tsreport.xml"
-stop com.interwoven.tsreport.server.ReportServer
-params -stopServer -config "iw-home\tsreport\conf\tsreport.xml"
-out "<logs directory>\tsreport_out.log"
-err "<logs directory>\tsreport_err.log"
-current "iw-home\tsreport\bin"
-path "iw-home\tools\java\jre\bin"
-displayname "Interwoven TeamSite Report Service"
-startupmode automatic
9. Use the Services control panel to start the TeamSite Report Service.
ECM Connector
This appendix describes the configuration and usage of the ECM Connector feature.
ECM Connector provides Web content developers seamless access to the business and
creative content managed in WorkSite MP and MediaBin repositories when using
TeamSite for performing Web content management tasks.
Connector Configuration
Configuration of ECM Connector involves establishing connectors between the
TeamSite server and the WorkSite MP or MediaBin servers. Connectors can be
established using one of the following methods:
Trusted login. Connection is attempted using the TeamSite user’s personal
TeamSite login information. For trusted login to work correctly with WorkSite MP,
an account with the same user name as the TeamSite user must exist on the on the
WorkSite MP server. MediaBin trusted login is accomplished using LDAP
authentication. An entry matching the TeamSite user name must be present in the
LDAP.
Trusted login is not supported for root (UNIX) or Administrator (Windows)
accounts. It is intended only for end users.
See “WorkSite MP Configuration” on page 254 and “MediaBin Configuration” on
page 255 for more information.
Guest login. Connection is attempted using a “Guest” account established on the
WorkSite MP or MediaBin server for use with TeamSite. This account information
must be configured in TeamSite prior to the connection being attempted. This single
account applies to all TeamSite users. This method is also known as “proxy login.”
When TeamSite connects to MediaBin or WorkSite MP, it does not use the identity
of the current TeamSite user. Instead, it impersonates a MediaBin or WorkSite MP
user. The credentials of these “proxy users” are stored in the TeamSite system and
are used by all TeamSite users. It is recommended that you not use the credentials of
a real person, but instead create dedicated user accounts in MediaBin and WorkSite
MP for use as TeamSite proxy users. The proxy users should be given read access to
those assets that are to be made available to TeamSite; they do not need any write
privileges.
Fail through. The initial connection is made using the TeamSite user’s personal
information. If that attempt fails, then the connection is reattempted using the Guest
account information.
Each server connector exists independently of the other. For example, you can configure
a trusted login connector between your TeamSite and the WorkSite MP servers, and a
guest login connector between your TeamSite and MediaBin servers.
WorkSite MP
Select the WorkSite MP link to display the WorkSite MP Properties screen (Figure 40).
Complete the following attributes in each of the following sections to configure your
WorkSite MP connector:
Cluster:
Enter the cluster address of the WorkSite MP server. It is recommended that you
use a resolvable host name rather than an IP address.
Check the associated box to enable a connection to the WorkSite MP server you
specified.
Enter the process manager (PM) password (if one has been set) in the PM
Password field.
NOTE
In some cases, changing the cluster address or PM password values will require
resetting the TeamSite user interface. To reset the TeamSite user interface, run the
following command:
iw-home/bin/iwreset -ui
Authorization:
Select one of the following authorization options when connecting to WorkSite MP:
Login as the TeamSite user. Login to the WorkSite MP server will be done
using the same user name that was used to login to the TeamSite server.
Login with a WorkSite MP guest account. Login with the guest user account
you set up on the WorkSite MP server for use with your TeamSite server.
Try to login as the TeamSite user, but use the WorkSite MP guest account if
unsuccessful. This option uses your TeamSite user login information first, but if
it is not successful, then it will try the WorkSite MP guest account
automatically.
TeamSite User:
Complete the following attribute if either the Login as the TeamSite user or Try to
login as the TeamSite user, but use the WorkSite MP guest account if
unsuccessful option was selected as your Authorization option:
Enter the WorkSite MP domain of the TeamSite user in the Domain field under
TeamSite User. When logging in with the TeamSite user ID, all users must be in
the same WorkSite MP domain. For example, if the WorkSite MP domain is set
to mycompany.com and a user logs into TeamSite as one of the following:
Windows. MYCOMPANY\jdoe
The information used to log into WorkSite MP would be userid=jdoe and
domain=mycompany.com.
Guest User:
Complete the following attributes if either the Login with a WorkSite MP guest
account or Try to login as the TeamSite user, but use the WorkSite MP guest
account if unsuccessful option was selected as your Authorization option:
Enter the WorkSite MP user name of the account in the Name field.
Enter the WorkSite MP domain (if necessary) in the Domain field.
Enter the password associated with the user name in the Password field.
Destination:
Enter the default directory within your TeamSite workarea under which any
files imported from the WorkSite MP server when using FormsPublisher are
written. Note that when you are importing WorkSite MP files using the Import
command, files are stored in your current working directory.
Click OK when you have completed the necessary attribute values. Your WorkSite MP
connector is now configured.
MediaBin
Select the MediaBin link to display the MediaBin Properties screen (Figure 41).
Complete the following attributes in each of the following sections to configure your
MediaBin connector:
Server:
Enter the name of the MediaBin server hosting the Web services.
Check the associated box to enable a connection to the MediaBin server you
specified.
Enter the appropriate URL to point to the MediaBin web services in the WSDL
URL field. In most cases you can simply change the host name in the default
value.
Authorization:
Select one of the following authorization options:
Login as the TeamSite user. Login to the MediaBin server will be done using
the same user name that was used to login to the TeamSite server. An entry for
this TeamSite user must be present in the LDAP used by MediaBin.
Login with a MediaBin guest account. Login with the guest user account you
set up on the MediaBin server for use with your TeamSite server.
Try to login as the TeamSite user, but use the MediaBin guest account if
unsuccessful. This option uses your TeamSite user login information first, but if
it is not successful, then it will try the MediaBin guest account automatically.
Trusted Client:
Complete the following attribute if either the Login as the TeamSite user or Try to
login as the TeamSite user, but use the MediaBin guest account if unsuccessful
option was selected as your Authorization option.
Enter the hint required for trusted client access in the Hint field. This is the
same value as is used in the MediaBin web.config file’s TrustedClientHint
value.
Guest User:
Complete the following attributes if either the Login with a MediaBin guest
account or Try to login as the TeamSite user, but use the MediaBin guest account
if unsuccessful option was selected as your Authorization option:
Enter the MediaBin user name of the account in the Name field.
Enter the MediaBin domain (if necessary) in the Domain field.
Enter the password associated with the user name in the Password field.
Destination:
Enter the directory within your TeamSite workarea in which any files imported
from the MediaBin server when using FormsPublisher are written. Note that
when you are importing MediaBin assets using the Import command, files are
stored in your current working directory.
Web Client:
Enter the appropriate URL to point to the MediaBin server on which you can
edit assets selected within TeamSite. In most cases you can simply change the
host name in the default value.
Click OK when you have completed the necessary attribute values. Your MediaBin
connector is now configured.
Refer to the README file residing at the following location for descriptions of each of
these samples:
iw-home/examples/Templating/templatedata
datacapture.cfg
You can incorporate WorkSite MP or MediaBin functionality in your FormsPublisher
form by including a dialog for either or both remote servers in your associated
datacapture.cfg file. In the datacapture.cfg file, dialogs are configured using the
dialog element. Each dialog has a set of named parameters that are used to connect the
FormsPublisher form fields to the dialog’s inputs and outputs.
Each parameter can have an input, an output, or both. An input parameter can have an
actual value, or it can reference an item whose value will be obtained when the dialog is
activated. An output parameter can only reference an item whose value will be set by the
dialog. Input and output parameters vary between WorkSite MP and MediaBin. Some
parameters are shared by both remote servers, while others are unique to one or the
other. The set of output parameters can also be different depending on whether the form
is configured to import files from the remote server immediately upon selection, or
whether to wait until the Web page is actually generated.
Dialog parameters reference items by name, not by path. When a dialog references an
item, it first looks for an item with that name in the same container as the dialog itself. If
it is not found, then it looks in the enclosing (parent) container, and so on up the
hierarchy.
You can configure the dialog element anywhere that an item element can appear. The
dialog element has the following attributes:
type. Specify one of the following values to indicate what type of remote server is
being represented:
worksite
mediabin
The following configuration inserts a WorkSite MP field into the form, and gives the
associated button the label “WorkSite”:
<dialog type="worksite" label="WorkSite">
...
</dialog>
The dialog element can also include the optional rowcontinue and window-features
attributes, which are used elsewhere in the datacapture.cfg file. Refer to the
FormsPublisher documentation for more information.
Each parameter associated with the dialog is configured within the dialog element as a
separate dialog-param element. The type of parameter is specified by the
dialog-param element’s name attribute. For example:
<dialog type="worksite" label="WorkSite">
<dialog-param name="path">
...
</dialog-param>
...
</dialog>
Inputs and outputs are configured within each dialog-param element using the
dialog-input and dialog-output elements, respectively. Both these types of elements
include the field-ref sub-element, which associates the item reference to the input or
output.
In the following example, the parameter “path” includes both an input and an output,
while the parameter “label” includes only an output.
<dialog type="worksite" label="WorkSite">
<dialog-param name="path">
<dialog-input><field-ref name="path"/></dialog-input>
<dialog-output><field-ref name="path"/></dialog-output>
</dialog-param>
<dialog-param name="label">
<dialog-output><field-ref name="label"/></dialog-output>
</dialog-param>
format. The desired format for the asset rendition. Use of the following values:
• GIF
• JPG
• JPEG
Refer to your sample presentation templates that were installed with ECM Connector to
get additional usage information.
These tags require the IW_AUTH environment variable to be set to a valid value. This
variable will be set when the presentation template is invoked from the user interface or
a workflow external task. If you want to test the presentation template from the
command line, you must set this variable before calling the iwpt_compile CLT.
When these tags are used in a presentation template, the template may not function if it
is applied from the command line (for example, using iwgen or iwregen) or in a
nonstandard execution environment. These tags require access to a valid TeamSite
session string. The session string is provided by ContentCenter when the Preview or
Generate commands are performed and is provided by the workflow engine if the
template is applied in an external task.This IW_AUTH environment variable can be set to a
valid session string if one is not already available
You can also run the perldoc program to get more information on these tags. To run this
program, navigate to the following location:
iw-home/iw-perl/bin
where tagname is one of the ECM Connector tags listed at the beginning of this section,
for example:
perdoc.bat TeamSite::PT::iwov_import_mediabin
FormsPublisher
This section assumes that you are familiar with the use of FormsPublisher, including
generating and previewing Web pages. Refer to your TeamSite FormsPublisher
Developer’s Guide documentation for general information on FormsPublisher. This
section describes how to use ECM Connector in the FormsPublisher context.
Names for items in the FormsPublisher user interface, such as for fields and buttons, are
user-defined. Terms that appear in the following sections are only examples.
When ECM Connector is installed and configured, additional controls are present in the
FormsPublisher user interface where you can browse and search the associated
WorkSite MP or MediaBin server for the items you want to include.
WorkSite MP
You can insert links to WorkSite MP documents into FormsPublisher. Depending on
your presentation template, this link is subsequently represented as a hyperlink in the
generated Web page.
Click the WorkSite button to display the WorkSite MP Browser screen appears
(Figure 43), which shows files that reside on the WorkSite MP server.
You can navigate through the different workspaces on the server until you find the
document file you want. You can also click Find to search the current directory for files
based on their file names, or specify files by type. This feature searches the working
repository or container, such as a workspace, directory, or category, as well as any
sub-repositories contained within the working one.
Select the document file you want and click OK. In this example, we have navigated to
the following WorkSite MP location:
Employee Personal Workspaces/Analyst Day - internal/
ANALYST DAY MATERIALS
and have selected the file Anaylist Day Feedback.doc (Figure 44):
When the WorkSite MP browser displays files, it provides the option of viewing
additional information on any given file. Click Properties to display the Document
Properties screen, which lists a variety of properties associated with the file (Figure 45).
You can open the file through the WorkSite MP user interface by clicking Open in
WorkSite. Otherwise, click Close to return to the WorkSite MP Browser.
You can modify the Link Label value to another term if you want. The text contained in
the Link Label field value will be the hyperlink text in the outputted Web page
(Figure 47).
MediaBin
Figure 48 shows an example of the MediaBin field in FormsPublisher.
To insert a digital asset that resides on the MediaBin server into your Web page, click
the MediaBin button. The MediaBin browser appears (Figure 49), which represents the
file system on the MediaBin server.
Directories appear as folder icons in the MediaBin browser, while files appear in
thumbnail form.
You can navigate through the different folders on the server until you find the digital
asset file you want. You can also click Find to search the current directory for files
based on their file names.
Select the document file you want and click OK. In this example, we have navigated to
the following MediaBin directory:
Photography/Stock/Corel_PSDs/AutoRacing
Click Properties to display the Asset Properties screen, which lists a variety of
properties associated with the file (Figure 45).
You can view an enlarged version of the selected file by clicking on its thumbnail image.
You can open the file through the MediaBin user interface by clicking Open in
MediaBin. Otherwise, click Close to return to the MediaBin Browser.
From the MediaBin browser, when you select an item, you can also click Find Similar
to locate all assets that are similar to the selected image. The results are ordered by how
closely they resemble the original. This does not apply to non-image assets. You can
also add metadata criteria to similar image searches to refine your results even further.
Refer to your MediaBin documentation for more information on this feature.
Click OK when you are finished. The FormsPublisher screen returns, with the path to
the file contained in the File field, and by default, the file name contained in the Label
field (Figure 46).
You can modify the Link Label value to another term if you want. The text contained in
the Label field value will be the Alt text (the text label that appears when you place the
cursor over the object) that accompanies your digital asset in the outputted Web page
(Figure 53).
TeamSite Workarea
This section assumes that you are familiar with the use of the Import feature in the
TeamSite. Refer to the ContentCenter Professional User’s Guide for general information
on the Import feature. This section describes how to use ECM Connector in the context
of importing files to your TeamSite workarea.
When ECM Connector is installed and configured, the existing TeamSite Import feature
is enhanced to allow you to import document and digital asset files from the connected
WorkSite MP and MediaBin servers to your workarea.
Selecting the File > Import command displays the Import to: screen (Figure 54), where
you can select from where you want to import content.
When you select the document or digital asset file you want to import and click OK, the
file you selected is imported into your working directory within your TeamSite
workarea. After the file is successfully imported, you can perform the same functions on
that file that you can any other imported file.
You can access the originating WorkSite MP or MediaBin server by clicking the Open
in WorkSite or Open in MediaBin button that appears in the same window. After
logging in to the appropriate server, you can make the desired modifications, save the
file, and then re-import it into TeamSite.
If it is necessary to open the imported file in TeamSite, you can click the Edit in
TeamSite button, and proceed with your editing. However, note that if a file is imported
to TeamSite and then edited within TeamSite, it is not given any special protection. If
that same image is re-imported to the same location in TeamSite, the file will be
replaced (within the workarea) and the edits may be lost.
The format of the metadata XML record is the same for both WorkSite MP and
MediaBin imported assets. The basic structure is a document-level metadata element
that contains namespace attributes, and zero or more attribute metadata child elements
and Dublin Core metadata elements. The following is an example of a partial metadata
XML record for a MediaBin file.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<dc:type>JPEG</dc:type>
<attribute>
<name>Asset Type</name>
<value type="xs:string">JPEG</value>
</attribute>
<attribute>
<name>Dimensions (pixels)</name>
<value type="xs:int">300</value>
<value type="xs:int">300</value>
</attribute>
<dc:date.created>2004-10-19T09:50:00</dc:date.created>
...
</metadata>
MediaBin metadata comprises both system metadata, such as insertion time, modified
time, and dimensions, and file format specific metadata for formats such as JPEG,
PhotoShop, and MS Office. All this metadata is represented for a single asset. For an
imported MediaBin asset, the metadata concerns the asset in MediaBin, not the
rendition. For example, if a TIFF file is retrieved as a GIF, the attributes regarding the
format, size and dimensions of the asset will be appropriate for the TIFF file.
WorkSite MP metadata is available for the base asset and for versions of that asset, so
differentiation of the metadata’s origin is required.
For WorkSite MP assets, both the base and version metadata is downloaded. For
WorkSite MP metadata XML records only, the attribute element contains a scope
attribute with a value of either document or version. The scope attribute indicates
whether the metadata is for the base asset (document) or for a version of that asset
(version). This example is for WorkSite MP version metadata with a single value.
<attribute scope="version">
<name>BASE::VERSION_NUMBER</name>
<value type="xs:int">2</value>
</attribute>
This example is for WorkSite MP document metadata that has multiple values.
<attribute scope="document">
<name>APP::LABEL_RSID</name>
<value type="xs:string">business</value>
<value type="xs:string">document processing</value>
<value type="xs:string">Interwoven, Inc.</value>
</attribute>
float
int
long
string
The Dublin Core standard permits omitted or repeated metadata elements. The Dublin
Core element set comprises the following elements:
Title
Creator
Subject
Description
Publisher
Contributor
Content
Date
Type
Format
Identifier
Source
Language
Relation
Coverage
Rights
For the Dublin Core Date metadata element there are two qualifiers applied:
Created
Modified
This example shows the two elements representing MediaBin’s “Asset Type” metadata:
a Dublin Core dc:type element and an attribute element.
<dc:type>JPEG</dc:type>
<attribute>
<name>Asset Type</name>
<value type="xs:string">JPEG</value>
</attribute>
The following table lists WorkSite MP metadata elements that correspond to Dublin
Core metadata elements:
The following table lists MediaBin metadata elements that correspond to Dublin Core
metadata elements:
Custom Metadata
Both WorkSite MP and MediaBin support the generation of custom metadata.
WorkSite MP custom metadata allows the generation of multi-level metadata. Currently,
only the first level of metadata is captured. MediaBin custom metadata associated with
an asset is captured along with the system and file format specific metadata.
WorkSite MP Configuration
This section contains instructions for configuring your WorkSite MP server for use with
ECM Connector 2.0. The instructions contained here are supplemental to the WorkSite
MP product documentation.
The ability to allow external authentication for enterprise users must be enabled for the
authentication library. From the Configuration Manager, navigate to the Edit
Cluster:CMS Settings window, select the authentication library, and check the Allow
external authentication for enterprise users option. Save and close the window.
Follow the instructions for enabling authenticated login in section 2.1.1 of the WorkSite
MP HFB7 release notes.
The ability to allow invocation of an authenticated login for an enterprise session must
be enabled. From the Library Manager, navigate to the appropriate cluster and library,
and select the Systems Configurations command. Set the value of the Allows the
invocation of a authenticated logon for an enterprise row to True.
MediaBin Configuration
This section contains instructions for configuring your MediaBin server for use with
ECM Connector 2.0. The instructions here are supplemental to the MediaBin product
documentation.
Troubleshooting
This information may provide information on issues related to ECM Connector.
If you want to run both the ECM Connector 1.1 and 2.0 toolkits in the same
ContentCenter instance, follow these steps:
1. Back up the following files:
k3.jar
MediaBinServer.jar
You can obtain this patch from the following Microsoft Web site:
http://www.microsoft.com/downloads/details.aspx?amp;amp;amp;amp;displayla
ng=en&familyid=8C6560FC-297C-4982-8BA5-DE7949043B17&displaylang=en
NOTE
This link could change at any time.
Content Transformation
Services
Overview
This section provides a Content Transformation Services overview. Refer to Figure 56
for an illustration.
With Content Transformation Services, Microsoft Word content is transformed into PDF
or HTML through an intermediate step that saves the content in reusable, sequentially
formatted ppXML. This format exposes the internal structure of the source document,
and can in turn be transformed into a customer-defined schema prior to style sheet
application. The rules for ppXML transformation are built by administrators or
developers using the Developer Workbench GUI.
From the TeamSite end-user perspective, all transformations are initiated through the
ContentCenter user interfaces. The typical end user of the system, using a browser,
communicates exclusively with the TeamSite server. When a document is to be
converted, the TeamSite server fetches the source document from the content store and
sends it, using an HTTP request, to the content transformation engine (the XDoc server
from CambridgeDocs). The content transformation engine writes the file into a
temporary upload directory, writes the converted versions into that directory, and then
responds to the request. The response includes a .zip file with all of output files. When
TeamSite receives the response, it unzips the response into its own temporary directory,
reads the results from that directory, and writes the appropriate files to the content store.
For security reasons, the content transformation engine does not have direct access to
the TeamSite content store. If a restricted, confidential document is maintained in
TeamSite and converted by this system, it may be exposed to others in the temporary
directories on the two systems. Normally, the document only exists there for a short time
and is deleted after it has been converted. However, it may remain if an error occurs or
the system is being debugged.
Because all document conversions are initiated by a user action, the content store is
accessed through the ContentServices API using the credentials of the current user. The
user needs read access to the source document and write access to the workarea that
contains it. The user who initiated the conversion owns any files that are created.
If a source document is modified by a user after it has been converted into PDF or
HTML format, the system does not automatically regenerate the output. It does not
report that output is obsolete. The user must regenerate output.
To customize the way the output is shown (such as adding headers or footers or mapping
styles), the templates and configuration on the content transformation engine must be
modified. Refer to the content transformation engine documentation to do this.
Installation
This section describes the recommended installation of Content Transformation
Services for TeamSite on two servers (Figure 56). One server (Server A) hosts
Interwoven TeamSite, and the other server (Server B) hosts the content transformation
engine.
User’s
Browser
ContentCenter Request
Content
TeamSite Transformation
Response Engine
Server A Server B
Temporary Upload
Directory Directory
Installation Procedure
1. Install TeamSite on Server A. Refer to the TeamSite Installation Guide for
instructions.
2. Install the content transformation engine on Server B. Refer to the documentation
provided with the content transformation engine.
3. Set the TeamSite configuration:
a. Create a directory on Server A and give full control to the owner of the
Interwoven Servlet Engine process. This is usually SYSTEM.
b. Edit the iw-home/local/config/transform.cfg file (see “Editing the
transform.cfg File” on page 262):
• Set the value of <transfer-dir-local> to the path of the directory created
in step 3a.
• Set the value of <url> so that it points to the installation of content
transformation engine.
• Set <conversion> to active="true".
• In the <debugging> section, specify the roles that have the debugging option
in ContentCenter Professional. By default, this option is set to the
Administrator and Master roles. Setting this option places a Show
debugging information checkbox on the Conversion Selection screen. If
the user turns on this feature, the Conversion Results screen contains a link
to a log file. These temporary log files are not removed from the temporary
directory when the debugging feature is activated.
c. Restart the Interwoven Servlet Engine (using iwreset -ui). Restart the Servlet
Engine anytime the configuration file is modified so that the system picks up the
changes.
<conversion active="false">
<source-files>
<source extension="doc">
<output-format extension="xml"
implied="true" />
<output-format extension="html"
default-selection="false"
required="false" />
<output-format extension="pdf"
default-selection="false"
required="false" />
</source>
</source-files>
<!-- Roles that will be shown the debugging option -->
<debugging>
<role>master</role>
<role>admin</role>
</debugging>
<service>
<!-- The URL used to invoke the transformation engine.
Replace "localhost" with the name of the server on which
the transformation engine has been installed.
If the instance of Tomcat on that server is not listening to port
8080 (the default), then replace "8080" with the correct port
number.
-->
<url>http://localhost:8080/MultiFormat/MultiFormatServlet</url>
<!-- The path to a temporary directory on the local (TeamSite)
server -->
<transfer-dir-local>C:\WINNT\temp\transform</transfer-dir-local>
</service>
</conversion>
URL Commands
Two URL commands are available for use in connection with Content Transformation
Services. The /iw-cc/convert URL Command initiates the Convert functionality. The
/iw-cc/converttask URL is used as a CGI task within a workflow. These URL tasks
are discussed briefly in this chapter. For additional information on URL Commands,
refer to the TeamSite User Interface Customization Guide.
As with most URL Commands, this URL Command invokes the appropriate
ContentCenter screen that provides this operation.
When the Convert task is initiated, it shows the user all of the Word documents that are
attached to the task. The user can select the desired output formats (HTML, PDF, or
both) for each document. ContentCenter then displays the results of the conversion and
includes links to the generated HTML or PDF files if the conversion is successful. The
generated files are automatically attached to the task, and the user can then transition to
the next task.
This workflow can be modified to use the Convert CGI task by performing the
following steps:
1. Make of copy of the WFT with a different name.
2. Edit the new file.
a. Change the $cgi_command to /iw-cc/converttask (line 31).
b. Change the readonly flag on the CGI task from "t" to "f" (line 117).
c. Optionally, change the description of the CGI task to something like Convert
Attached Documents (line 114).
Alternatively, this task can be added into an existing workflow by simply adding a CGI
task with the command /iw-cc/converttask and readonly="f". For example:
<cgitask name="Convert"
description="Convert Attached Documents"
owner="__TAG__('iw_user');"
immediate="t"
readonly="f">
<areavpath v="__TAG__('iw_workarea');"/>
<successors>
<successorset description="NEXT TASK">
<succ v="Done"/>
</successorset>
</successors>
<command v='/iw-cc/converttask'/>
</cgitask>
NOTES
While users can edit the HTML or PDF output using an appropriate editor, the edits
will be lost if the Word document is converted again. Change the Word document to
get the needed output.
If a source document is modified after it has been converted into PDF or HTML
format, the system does not automatically regenerate the output or report that the
output is obsolete. The user must regenerate the output.
This TeamSite release supports the next generation Tagger GUI for tagging files (that is,
adding metadata to them). The original Tagger GUI used in TeamSite 6.7.1 and earlier
releases is also supported. Which Tagger GUI is invoked depends on what type of
tagging activity is initiated by an user:
The next generation Tagger GUI is invoked whenever a user selects a single file to
tag through ContentCenter Standard or Professional. To ensure backward
compatibility, the next generation Tagger GUI is capable of displaying rulesets
based on the schemas used by both the original and next generation Tagger GUIs.
The default behavior for this TeamSite release is for the next generation Tagger GUI
to implement rulesets based on the original-style schema.
The original Tagger GUI is invoked whenever a user selects more than one file to tag
through ContentCenter Standard or Professional.
The next generation Tagger GUI differs from the original Tagger GUI in several key
areas (see “Tagger GUI New Features and Differences” on page 268 for details). The
original Tagger GUI still performs as described in the Chapter 8, “Configuring Metadata
Capture.”
NOTES
While the next generation Tagger GUI supports the original Tagger GUI schema, the
opposite is not true. That is, the original Tagger GUI does not support the next
generation Tagger GUI schema.
In future TeamSite releases, the next generation Tagger GUI will support tagging
more than one file at a time. When that ability is supported, the next generation
Tagger GUI will be the default Tagger GUI for all tagging activities initiated in
ContentCenter Standard and Professional.
NOTE
For this release, the next generation Tagger GUI only supports tagging a single file at a
time. Therefore, the features shown in Table 20 are available only for single-file tagging
at this time.
The differences between the original and next generation Tagger GUIs are as follows.
NOTES
The original Tagger GUI does not support the next generation Tagger GUI schema.
For the original Tagger GUI, the overall Tagger GUI configuration file
iw-home\local\config\datacapture.cfg must conform to the DTD defined in
iw-home\local\config\metadatacapture6.0.dtd.This behavior is documented in
Chapter 8, “Configuring Metadata Capture.”
For the next generation Tagger GUI, the overall Tagger GUI configuration file does
not need to be named datacapture.cfg, and the schema that it must conform to is
defined in iw-home\local\config\datacapture6.0.dtd. The only naming
requirement for the overall next generation Tagger GUI configuration file is that it
end in .cfg (anyfilename.cfg). This convention is possible because each next
generation Tagger GUI overall configuration file may contain just one <ruleset>
element. This change was made to improve performance. Thus, to enable the next
generation Tagger GUI to support multiple rulesets, you must create multiple
configuration files in iw-home\local\config\tagui\rulesets60, each with a unique
file name and a uniquely named ruleset defined in the <ruleset> element. See
“DTDs” on page 280 for DTD details.
Because the next generation Tagger GUI overall configuration file can have any file
name ending in .cfg, it is possible for it to be named datacapture.cfg.This is the
same file name used by the original Tagger GUI configuration file. When both files
are named datacapture.cfg, the location of datacapture.cfg determines which
XML tags are used by the next generation Tagger GUI. If datacapture.cfg is in
iw-home\local\config, the next generation Tagger GUI uses the tags defined by
metadatacapture6.0.dtd. If datacapture.cfg is in
iw-home\local\config\tagui\rulesets60, the next generation Tagger GUI uses the
tags defined by datacapture6.0.dtd (and only then can take advantage of all next
generation Tagger GUI features).
Sequence of Events
The following sections describe what happens when a user invokes the Tagger GUI
through ContentCenter Standard or Professional.
5. When the ruleset is found, the rules defining Tagger GUI appearance and behavior
are executed, the Tagger GUI is displayed, and the user can complete the process of
tagging the file originally selected.
4. When the ruleset is found, the rules defining Tagger GUI appearance and behavior
are executed, the Tagger GUI is displayed, and the user can complete the process of
tagging the files originally selected.
The original Tagger GUI shipped with this release is configured to use one or more
rulesets located in the iw-home\local\config\datacapture.cfg configuration file.
(These rulesets are named in iw-home\local\config\metadata-rules.cfg as the
rulesets to search for when the Tagger GUI is invoked, but are defined in
iw-home\local\config\datacapture.cfg). As shown in the preceding table, the
original Tagger GUI only supports the original Tagger GUI schema for rulesets.
Therefore, the datacapture.cfg file in iw-home\local\config\must conform to
metadatacapture6.0.dtd.
The next generation Tagger GUI supports both the original (for backward compatibility)
and next generation Tagger GUI schemas. To ensure backward compatibility in this
release, the next generation Tagger GUI implements the original Tagger GUI ruleset and
configuration file (iw-home\local\config\datacapture.cfg). This occurs because no
configuration files containing next-generation rulesets are included in the
iw-home\local\config\tagui\rulesets60 directory for this release (see “Configuring
the Next Generation Tagger GUI” for information about adding such rulesets).
Therefore, when the Tagger GUI performs step 3a on page 272, it does not find a
next-generation ruleset having the name specified in metadata-rules.cfg. It then
performs step 3b, at which time it finds an original ruleset having the name specified in
metadata-rules.cfg.
NOTE
Future TeamSite releases will contain examples of next generation rulesets in the
iw-home\local\config\tagui\rulesets60 directory so that all of the features supported
by the next generation Tagger GUI will be available by default. For the current release,
if you choose to customize the Tagger GUI you should edit
iw-home\local\config\datacapture.cfg so that your changes are implemented no
matter which Tagger GUI (original or next generation) is invoked.
Replicant Processing
Unlike the original Tagger GUI schema, the next generation Tagger GUI schema does
not support the <replicant> element. Instead, it provides equivalent support through
the <container> element. The New Tagger GUI <container> element supports the
same max, min, and default semantics of the <replicant> element. The <replicant>
element is still supported for backward compatibility in rulesets conforming to the old
schema, but the old schema does not provide support for new features such as FormAPI
script.
The original Tagger GUI schema distinguished between replicants and containers, and
whether an item used the <replicant> or <container> tag had an impact on the format
for the item when it was saved in the Content Store. This format may be important for
your downstream systems. In the next generation Tagger GUI’s new schema, the
replicant save format is preserved for backward compatibility for containers that can be
instantiated (those where neither min and max are not 1). To properly support containers
or replicants that implicitly or explicitly have both min and max equal to 1, a new
To implement a next generation UI using the next generation schema that mimics the
replicant element in UI behavior and backend save format, or if you have existing data
records that you would like to manually port into the next generation schema (to add
FormAPI script, for example), you need to add <container> elements in place of
<replicant> elements when using the next generation Tagger GUI schema. Since
<replicant> and <container> elements support the same attributes in the new schema,
you should be able to keep all attributes the same, unless the replicant explicitly or
implicitly uses min and max of 1.
Since <replicant> elements were always saved in the Content Store using instance
numbers using the original Tagger GUI, you can specify
eaSaveFormat=”withInstanceNums” to mimic the save format of a replicant tag. Also,
since <container> elements were always saved in the Content Store without instance
numbers in the original Tagger GUI, you can specify
eaSaveFormat=”withoutInstanceNums” to get this behavior in the next generation
Tagger GUI (note: “withoutInstanceNums” only applies when min and max are both
equal to 1, since having an instantiable container would result in a save format that
includes instance numbers in the old Tagger GUI). Finally, the default for the
eaSaveForrmat in the next generation tagger GUI is “withInstanceNums”, so unless
otherwise specified, containers in the next generation Tag UI configurations would save
using instance numbers (to support the min and max elements allowed by next generation
<container> elements).
Example
And similarly, the following datacapture.cfg entry (also using the original Tagger
GUI schema):
Because the next generation Tagger GUI must be compatible with the original Tagger
GUI, it also must support saving and loading the data shown above. When min==max==1,
the eaSaveForm attribute lets you specify whether the /#/ format should be included
when saving (or attempting to load) the data form.
NOTES
When min and max are not both 1, this is automatically a replicant type and instance
numbers must be used in the Content Store. If they are not, replicant instances 2
through N would overwrite the first instance in the Content Store. FormsPublisher
recognizes this case automatically, which is why withoutInstanceNums only
applies when min==max==1.
Even though the eaSaveFormat attribute only exists in the next generation Tagger
GUI schema, the original Tagger GUI schema files are transformed dynamically at
runtime into next generation schema files when the next generation Tagger GUI
renders them. Therefore, the dynamic migration code automatically adds
eaSaveFormat=withoutInstanceNums whenever migrating an original format
container into a next generation format container so that the next generation Tagger
GUI will automatically work with the original schema and be backwards compatible
with any pre-existing data.
To revert to the original CGI environment for Tagger GUI, set the following in
application_custom.xml:
iw.tagui.CGIEnv="old"
iw.tagui.CGIEnv="new"
Because multi=t values are saved in a single string (for example, "value1, value2,
value3"), on changing a multi-valued list into a single-valued list, the next generation
Tagger GUI renders "value1, value2, value3" as a legal option in the select list. The
original Tagger GUI would have arbitrarily chosen one of the values.
If you anticipate this case (in which the meaning of a saved value could change), it is
recommended that you migrate the extended attribute data to the new format to achieve
whatever result your organization desires.
You can configure the next-generation Tagger GUI to use next generation rulesets
(rather than the default original Tagger GUI ruleset in datacapture.cfg). The general
steps are as follows.
1. Create one or more configuration files in the
iw-home\local\config\tagui\rulesets60 directory. Configuration file names must
end in .cfg, and the files must conform to the schema defined in
iw-home\local\config\datacapture6.0.dtd. Each configuration file can contain
only one ruleset.
2. In iw-home\local\config\metadata-rules.cfg, change the ruleset name specified
for use to the name of the new ruleset you created in the
iw-home\local\config\tagui\rulesets60 directory.
Integrating MetaTagger
If MetaTagger is installed on your system, you can configure the next generation Tagger
GUI to use Metatagger whenever the next generation Tagger GUI is invoked.
Configuration involves two main activities:
Creating a ruleset for the data form from which Metatagger will be invoked.
Creating a file that maps Metatagger projects to data form items defined in the
ruleset.
Creating a Ruleset
Use the example ruleset shown in this section as the basis for creating your own ruleset
for a data form that will invoke Metatagger. The file defining the ruleset must:
Reside in the iw-home\local\config\tagui\rulesets60 directory.
Have a file name ending in .cfg.
Contain the tagEngineConfig attribute, which points to the Metatagger mapping
file that you will create as described in the next section.
Conform to the next generation Tagger GUI schema defined in
datacapture6.0.dtd.
<data-capture-requirements>
<ruleset name="Default Rule">
<root-container name="Asset_metadata" location="Asset_metadata">
<item name="CustomMT" pathid="CustomMT" tagEngineConfig="met
atagger://MT_Rulefile">
<label>CustomMT</label>
<description>Keywords can include terms that are not
in the asset itself.</description>
<database data-type="VARCHAR(100)"/>
<text required="f" size="32" maxlength="60"/>
</item>
<item name="Keywords" pathid="Keywords" tagEngineConfig="met
atagger://MT_Rulefile">
<label>Keywords</label>
<description>Keywords can include terms that are not
in the asset itself.</description>
<database data-type="VARCHAR(100)"/>
<text required="f" size="32" maxlength="60"/>
</item>
</root-container>
</ruleset>
</data-capture-requirements>
NOTE
Be sure that the maxlength attribute is set to a value that is high enough to display all
results for metadata suggestions returned by MetaTagger. If maxlength is too low, the
display field will truncate the returned result, and you will not be able to highlight
and/or edit the result.
<?xml version="1.0"?>
<tagUIConfig>
<item name="/Asset_metadata/CustomMT">
<parameter name="metataggerProjectName" value="summidx_en"/>
</item>
<item name="/Asset_metadata/Keywords">
<parameter name="metataggerProjectName" value="test_taxonomy"/>
<parameter name="metataggerBrowseInitialDir" value=""/>
</item>
<item name="/Asset_metadata/test_taxonomy">
<parameter name="metataggerProjectName" value="test_taxonomy"/>
<parameter name="metataggerBrowseInitialDir" value=""/>
</item>
</tagUIConfig>
NOTE
All item references are rooted in the node specified in the <root-container> element in
defaultRule.cfg. The syntax for item references is the same as the base FormAPI path
syntax. You do not need to specify indices in an item reference if the item/container is a
replicant.
The data entry areas of the “Asset_metadata” form are mapped to Metatagger
projects as follows:
CustomMT (mapped to the summidx_en Metatagger project)
Keywords (mapped to the test_taxonomy Metatagger project)
DTDs
The following sections show the DTDs used to define the original and next generation
Tagger GUI ruleset schemas.
metadata-rules.dtd
This DTD defines the schema used by the iw-home\local\config\metadata-rules.cfg
file, which is used by the original and next-generation Tagger GUIs.
NOTE
This DTD is documented in greater detail in Chapter 8, “Configuring Metadata Capture.”
metadatacapture6.0.dtd
This DTD defines the schema used by the iw-home\local\config\datacapture.cfg
file, which is used by default by the original Tagger GUI. It is also supported by the
next-generation Tagger GUI for backward compatibility.
NOTE
This DTD is documented in greater detail in Chapter 8, “Configuring Metadata Capture.”
<!--The form of this element is exactly the same as that for the callout
element in datacapture.4.0.dtd. -->
<!ELEMENT cgi-callout EMPTY>
<!ATTLIST cgi-callout
label CDATA #REQUIRED
url CDATA #REQUIRED
window-featuresCDATA #IMPLIED
>
<select>
runs the "blah" callout program, and that program returns this text:
<substitution>
<option label="ABC" />
<option label="123" />
<option label="Jackson 5" />
</substitution>
then the DCT snippet will, after callout execution and inline
substitution, look like:
<select>
<option label="ABC" />
<option label="123" />
<option label="Jackson 5" />
</select>
-->
<!ELEMENT inline EMPTY>
<!ATTLIST inline
command CDATA #REQUIRED
>
datacapture6.0.dtd
This DTD defines the schema used by the configuration files (anyfilename.cfg)
located in the iw-home\local\config\tagui\rulesets60 directory, which are used by
the next-generation Tagger GUI.
<select>
<inline command="command name" />
</select>
runs the "blah" callout program, and that program returns this text:
<substitution>
<option label="ABC" />
<option label="123" />
<option label="Jackson 5" />
</substitution>
then the DCT snippet will, after callout execution and inline
substitution, look like:
<select>
<option label="ABC" />
<option label="123" />
<option label="Jackson 5" />
</select>
-->
<!ELEMENT inline EMPTY>
<!ATTLIST inline
command CDATA #REQUIRED
>
<!-- window-features is ignored if dialog type is button. function and
function-param can only be used if
dialog type is a button. Function name should not contain braces and
arguments. -->
>
The Apache Derby database ships with TeamSite and can be used for the Event
Subsystem if you are not using another database system. The Derby database was
installed with TeamSite. You need to configure it if you wish to use it.
NOTE
The Derby database is not supported as the Report Center database.
ij> exit;
<BookTitle> 291
Appendix E: Using the Derby Database
NOTE
To start this service automatically when you reboot, set the service type to
automatic.
5. Stop the Event Subsystem. Copy the Derby JDBC jar (derbyclient.jar) from the
iw-home\derby\lib directory to the iw-home\eventsubsystem\lib directory.
6. Edit the registry key to include the path of the new JDBC driver jar file. The older
JDBC jars if any should be removed.
\\HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\
Services\iweventsubd\Parameters\JVM Option Number 0
7. Delete the events.lock file if it is located in the iw-home\eventsubsystem
directory.
8. Point to the new database in the <DatabaseConfiguration> section of the
iw-home\eventsubsystem\conf\jmsconfignew.xml file:
<DatabaseConfiguration>
<RdbmsDatabaseConfiguration
driver="org.apache.derby.jdbc.ClientDriver"
url="jdbc:derby://localhost:1527/testdb" user="usr"
maxActive="10" maxIdle="5" minIdleTime="1800"
evictionInterval="3600" />
</DatabaseConfiguration>
9. Start the Event Subsystem by selecting Control Panel > Services.
10. Verify from the eventsubd.log that the Event Subsystem has started properly.
To remove the user mary by setting the password to null, issue the following command:
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.mary', null)
To add Derby users and not users in LDAP or an external file, issue the following
command:
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
('derby.authentication.provider','BUILTIN');
To add the property required for authentication, issue the following command:
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
('derby.connection.requireAuthentication','true');
Testing Derby
You can test whether a valid user and password have been created. The first command
shows testing a user with an invalid password and receiving an error message, while the
second command shows using a valid password.
ij> connect 'jdbc:derby:testdb;create=false;user=usr;password=test';
ERROR 08004: Connection refused : Invalid authentication.
ij> connect 'jdbc:derby:testdb;create=false;user=usr;password=hgaur';
A Derby table or index (called a conglomerate) can contain unused space after large
amounts of data have been deleted or updated. This happens because, by default, Derby
does not return unused space to the operating system. After a page has been allocated to
a table or index, Derby does not automatically return the page to the operating system
until the table or index is dropped, even if the space is no longer needed. However,
Derby provides the following commands to reclaim unused space in tables and
associated indexes.
ij> call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('USR', 'MESSAGES', 1);
0 rows inserted/updated/deleted
ij> call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('USR', 'MESSAGE_HANDLES', 1);
0 rows inserted/updated/deleted
NOTE
See Derby documentation at http://db.apacheorg/derby/ for details on running and
managing a Derby database.
<BookTitle> 293
Appendix E: Using the Derby Database
For TeamSite to correctly interpret a text document, it is necessary to know the character
encoding in which its contents are represented. Unlike an HTML document that can
declare the encoding of its contents using an <HTTP META="Content-Type"
CONTENT="text/html; charset=charsetname"> tag, a plain text file has no mechanism
for storing this information. The encoding is required for certain TeamSite functionality
including VisualPreview and the Source Differencing and Interwoven Merge tools.
In previous releases, VisualPreview relied on the Content-Type header from the content
Web server to specify the encoding of plain text files. This required you to configure the
encoding at your content Web server which may limit flexibility and scalability. By
default, the Source Differencing and Interwoven Merge tools assumed that text files are
encoded in ISO-8859-1, which is not suitable for content in eastern Asian languages.
The following sections describe the regex_map language, and how it is used to specify
the character encodings of text files used by TeamSite:
regex_map Defined
The regex_map Format
Strategies for Effective regex_maps
Internationalization and regex_maps
VisualPreview and file_encoding.cfg
Source Differencing and Merging and file_encoding.cfg
regex_map Defined
A regex_map is a filter that transforms a set of input variable values into a set of output
variable values through a set of rules written in XML using the following form:
Input Variables
var1 = "original value1"
var2 = "original value2"
regex_map
<regex_map>
<match .../>
<subst .../>
<subst .../>
<match .../>
</regex_map>
Output Variables
Input Variable
vpath = path of a TeamSite file
regex_map
<regex_map>
<match reg_vpath= "/web/techsupport/jp/" val_encoding= "Shift_JIS"/>
<match reg_vpath= "\.txt$" val_encoding= "8859_1"/>
<match reg_vpath= ".*" val_encoding= "UTF8"/>
</regex_map>
Output Variable
encoding = character encoding
for the given vpath
All files in the /web/techsupport/jp branch are encoded in Shift-JIS, because their
vpath begins with "/web/techsupport/jp/".
If the input vpath variable does not contain "/web/techsupport/jp/", the output
encoding variable is set to "UTF8" because ".*" matches any string.
Each rule within <regex_map> is evaluated in order, the first <match> tag with a regular
expression that matches the input variable vpath is used, and subsequent rules are
ignored. Therefore, it is important for the <match reg_vpath= ".*" val_encoding=
"UTF8"/> rule to appear last.
Rule Syntax
Every <subst> or <match> rule expresses the following logical operation:
If all the regular expressions within this rule match, then perform all of this rule’s
variable assignments; otherwise, ignore this rule and consult the next rule.
Execution terminates when the first <match> rule has been applied, or when there are no
more rules. A <subst> rule that has been satisfied does not terminate execution (unless
it is the last rule).
The encoding of all files named index_zh_TW.html anywhere in the /web branch is
Big5. There are no exceptions to this rule, so stop processing if it applies.
<match reg_vpath=
"^/web/(STAGING|WORKAREA|EDITION).*/index_zh_TW.html"
val_encoding= "Big5"/>
Note that the “or” capability of regular expressions, expressed by the pipe character
( | ), enables this single rule handle three cases at once (STAGING or WORKAREA or
EDITION).
When there are no reg_ conditions, the assignment always executes if the rule is
encountered. Any rules that occur after this statement are unused.
For example, because filenames and URLs are case-insensitive on Microsoft Windows,
the following declaration would be recommended when writing a regex_map for a
TeamSite server on Microsoft Windows:
<regex_map opt_case_insensitive="vpath url">
<subst reg_vpath="..." .../>
<match reg_url="..." .../>
</regex_map>
Variables
Variables store strings to be passed in the following ways:
As input to a regex_map from an application.
From rule to rule within a regex_map.
As results from a regex_map to the application.
Variable names are case-sensitive and must begin with a letter and may contain any
sequence of alphanumeric characters and the underscore character ( “ _ ” ). References to
any variable whose value is not set by the application or by rules in the regex_map
evaluates to an empty string.
Application Variables
Any application that uses a regex_map gives it a set of inputs before execution and
inspects a set of output variables when the regex_map processing completes. These
input and output variables are known as application variables.
Intermediate Variables
You may find it helpful to assign intermediate results to your variables in regex_map
rules before arriving at final output values. These intermediate variables can help make
a complex set of rules more manageable by factoring out several separate conditions
into one condensed case. You can then write one rule to act on the condensed case,
instead of repetitively writing the same actions for the individual initial conditions.
“Strategies for Effective regex_maps” on page 303 contains an example of factoring.
Intermediate variables should have names that begin with x_ to avoid conflicts with
application variables that Interwoven may create in the future.
Input Variables
good = "Bon"
my = "mon"
friend = "ami"
regex_map
<regex_map>
<subst val_french="${good}jour"/>
<match val_friend="copain"
val_french="$french, $my $friend!"/>
</regex_map>
Output Variables
good = "Bon"
my = "mon"
friend = "copain"
french = "Bonjour, mon ami"
In the <match> rule, there is no need to disambiguate the three variables because the
variable names french, my, and friend are followed by a comma, a space, and an
exclamation point, none of which can be confused as being part of a variable name.
In the second rule, the values of friend and french are taken from the time at which
the rule was encountered. All assignments in a rule appear to occur simultaneously
and do not affect each other.
NOTE
Pairs of parentheses are numbered according to the order in which their left parenthesis
occurs within the regular expression. Parentheses of the form (?:some_expression) are
used solely for grouping characters in the regular expression, not for capturing text
during matching, and are excluded from the count.
The shorthand version of a captured subexpression variables is $n. Note that the
shorthand notation can only be used when the variable being modified is the same as the
variable from which the subexpression was captured.
For example, the pair of rules in the following regex_map makes the assignment
message="regex_maps are awesome maps!" in an inefficient way:
Input Variables
text = "My, how large your eyes are!"
message = "regards some maps with awe"
regex_map
<regex_map>
<subst reg_text="This regular expression match fails"
reg_message="some (m[aeiou]ps)"
val_text="so this assignment never occurs..."
val_message="... and the $1 capture is wasted."/>
<subst reg_text="(?:(bloop)|([a-z]+)(!))"
reg_message="(...)ards ((.{4}) (.{4})) with (.*)"
val_message="$1ex_${4} ${text:2} ${message:5}$2${text:3}"/>
</regex_map>
Output Variables
text = "My, how large your eyes are"
message = "regex_maps are awesome maps!"
The second rule does apply, since both of the reg_text and reg_message matches
succeed. The parentheses also capture the text in the strings, resulting in the
following temporary bindings:
${text:1} = empty string
${text:2} = are
${text:3} = !
${message:1} = reg
${message:2} = some maps
${message:3} = some
${message:4} = maps
${message:5} = awe
Finally, variable interpolation occurs for the val_message assignment. Since the $1,
${4}, and $2 occur in a val_message context, they are treated as shorthand for
${message:1}, ${message:4}, and ${message:2}, respectively. The curly braces
for ${4} are optional in this case, and could be used in other situations to clarify
where the variable name ends and literal text begins.
Quoting
Inside a val_ attribute, dollar signs ($) have special meaning—they mark the start of
captured subexpression names. To force a dollar sign to lose this special meaning (and
be treated as a literal dollar sign), it must be escaped by preceding it with a backslash.
Similarly, a backslash is treated as a special quoting character unless it is escaped by a
preceding backslash.
Input Variable
hello = "Hi"
regex_map
<regex_map>
<subst reg_hello="(.*)"
val_hello="$1! Parking costs \$1\\hr."
</regex_map>
Output Variable
hello = "Hi Parking costs $1\hr."
In the preceding example, hello is assigned the value "Hi! Parking costs $1\hr."
(with the deliberately “wrong” backslash used instead of a forward slash for
demonstration purposes).
Also, because regex_map is written in XML, characters with special meaning in XML
need to be represented using XML entities. These special characters are described in the
following table.
Apostrophe ’ '
For example,
<subst val_statement="Programmers think "1 & 1 is 1.quot;"/>
By taking advantage of these features, you can write configuration files that are compact
and manageable.
The following example demonstrates how factoring and intermediate variables can
make a regex_map configuration scale to handle complex situations. Suppose that a
system-wide reorganization forced you to rename all files named README to README.TXT
and relocate all files under the /a/b branch to the /c/d branch. You could list all of the
possibilities as follows:
<regex_map>
<!- Handle both branch move and file extension addition ->
<match reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)README$"
val_vpath= "/c/d/$1README.TXT"/>
But this strategy could become extremely complicated if there were more combinations.
A factored set of rules can handle each change independently:
<regex_map>
<!- Handle a possible branch move ->
<subst reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)"
val_vpath= "/c/d/$1"/>
A complicated set of rules could be clarified with intermediate variables, for example:
<regex_map>
<!-- Decompose vpath into branch, area, directory, filename -->
<!-- Decomposition could be done in just one rule, -->
<!-- but we choose to break it up with the help of x_rest. -->
<subst reg_vpath="^(.*?)/((?:WORKAREA|EDITION|STAGING).*)"
val_x_branch="${vpath:1}"
val_x_rest="${vpath:2}"/>
<subst reg_x_rest="((?:WORKAREA|EDITION)/[^/]+|STAGING)(.*)"
val_x_area="${x_rest:1}"
val_x_rest="${x_rest:2}/>
<subst reg_x_rest="(.*)(/.*)"
val_x_dir="${x_rest:1}"
val_x_file="${x_rest:2}"/>
<!-- End decomposition -->
<subst reg_x_file="^/README$"
val_x_file="/README.TXT"/>
<!-- End transformations -->
In the preceding example, factoring out the vpath decomposition logic simplifies the
actual transformation rules. In a complex situation with many transformation rules,
adding a few standardized rules at the beginning and end of the regex_map is
worthwhile.
If you need to specify non-ASCII literal characters in your regex_maps, ensure the text
editor you are using can edit and save the file_encoding.cfg in UTF-8 encoding.
Refer to page 314 for details about text editor encodings.
The following list of encodings are the IANA preferred charset names
(http://www.iana.org/assignments/character-sets) and are valid entries for the
file_encoding.cfg file:
English, German:
ISO-8859-1
ISO-8859-15
windows-1252
Japanese:
Shift_JIS
EUC-JP
Korean:
EUC-KR
Simplified Chinese:
EUC-CN
GB2312
Unicode:
UTF-8
NOTE
file_encoding.cfg has no effect on the file encoding seen in visual differencing. This
is so that what is seen in the visual differencing tool most closely approximates what
will be seen in the production environment.
Sample file_encoding.cfg
<?xml version="1.0" encoding="UTF-8"?>
<!-- Otherwise, the directory name at the top of the area is the
result. -->
<subst reg_vpath="(?:(?:WORKAREA|EDITION)/[^/]+|STAGING)/([^/]+)/"
val_encoding="${vpath:1}"/>
Internationalization
Overview
TeamSite is engineered with your global enterprise in mind. This includes
internationalizing the TeamSite server to support multibyte languages and locales at the
operating system, and localizing the ContentCenter user interface and documentation.
Internationalized TeamSite supports the following needs:
International user data. Enables users to enter data, content, and field values in
English, Korean, Traditional Chinese, Simplified Chinese, French, German, and
Japanese.
Localized operating system. The TeamSite server runs on any one of the following
localized operating systems: English, French, German, Korean, Simplified Chinese,
Traditional Chinese, and Japanese (one locale per instance of iwserver).
Localized user interfaces. The ContentCenter Professional and ContentCenter
Standard interfaces have been localized into French, German, Japanese, Korean,
Traditional Chinese, and Simplified Chinese.
Localized file names. You are no longer restricted to having file and directory
names in ASCII character encoding. For example, file, directory, branch, workarea,
and edition names can have Japanese names on Japanese servers, German names on
German servers, Simplified Chinese names on Simplified Chinese servers, and so
forth.
Continued support for processing of non-English metadata and FormsPublisher
content.
NOTE
Information on localized servers contained in this chapter is only valid with localized
TeamSite versions. Check the Release Notes to determine whether localized servers are
supported in your TeamSite version.
Supported Content
TeamSite supports non-ASCII characters in branch, area, directory, vpath, and file
names in addition to the contents of a file.
b. You install and run your TeamSite server on this file server.
c. You use the file system interface to migrate your existing hierarchy of files and
directories into the TeamSite File System.
d. The TeamSite server must run in the ja locale for these file and directory names
to be processed correctly. If you change the locale to ja_JP.PCK (Japanese
Shift-JIS) before TeamSite server is started, the TeamSite server would
incorrectly interpret the imported file and directory names as ja_JP.PCK
encoded. This is not a supported scenario.
Mixed-locale file systems are not supported. For example, a scenario where a parent
directory has directory names encoded in ja_JP.PCK (Japanese Shift-JIS, and child
directories have file names encoded in ja is not supported.
If TeamSite server is running on a German operating system using a German Latin1
locale, it is possible to create a branch or workarea on the TeamSite File System
with Japanese names using ContentCenter. However, when viewed with the file
system interface, these Japanese names would appear as illegible characters because
the server is running in a Latin1 locale and does not include the Japanese character
set. This is not a supported scenario.
This scenario is supported for Metadata because Metadata entered using the
ContentCenter does not interact with server operating system. Any data that is
interchanged with the server operating system (including VPATHs) are only
meaningful if they are within the server locale’s encoding.
If the TeamSite File System is functioning as a networked file server, it is expected
that all other networked file system clients (for example, NFS clients) are operating
in the same locale as the TeamSite File System file server.
Currently, NFS does not enforce this restriction and therefore enables NFS clients to
be in a different locale than the NFS server. However, NFS protocol does not do
encoding conversion. Therefore, file and directory attributes (including names) are
passed through in binary format. This would not work for TeamSite File System
functioning as a file server because it does encoding conversion from and into
UTF-8 based on the server file system’s locale.
About UTF-8
UTF-8 is the 8-bit encoding format for Unicode. Unicode is a system for exchanging,
processing, and displaying diverse written languages. Unicode supports the principal
written languages of the world as well as many classical languages.
/archive/main/WORKAREA/area/ .html
would be:
/iw/iw-cc/edit?vpath=/archive/main/WORKAREA/area/%e5%ba%9c.html
since the Japanese character is Unicode character U+30D5, which is encoded as the
bytes 0xe5 0xba 0x9c in the UTF-8 format.
To achieve this, TeamSite system calls to the operating system are converted from
UTF-8 encoded textual data (for example, VPATH information) into the locale of
iwserver (as defined by the server_locale setting in iw.cfg). In most cases, this is the
same as the operating system’s native locale. The conversion is also required when
operating system information is returned to TeamSite.
NOTE
If the TeamSite server is run in a different locale than the host operating system’s locale,
the TeamSite virtual file system would use a different encoding locale compared to the
rest of host server’s file systems. By default, the TeamSite server locale uses the native
locale of the host operating system.
To avoid this issue, complete the following procedure before running any CLT on SBCS
systems.
1. Open the DOS command window.
2. Right-click on the command window’s title bar and choose Properties from the
menu.
The Properties dialog box displays.
3. Click the Font tab.
4. Select Lucida Console font from the Font list, and click OK.
The Apply Properties dialog box displays.
5. Select Save properties for future windows with same title, and click OK.
6. At the DOS prompt, type chcp and press Enter.
The system returns the active code page number: 437 for English systems, or 850
for German systems. Record the code page number so you can revert to the default
code page for commands that require it.
7. Type chcp 1252 and press Enter to change the code page to 1252.
The system confirms the active code page is set to 1252. All command window
input and output will use this code page.
For HTML documents, VisualPreview honors the encoding specified by the charset
parameter in either a Content-Type HTTP header or in an HTML META tag. For example:
Content-Type: text/plain; charset=UTF-8
<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=UTF-8">
NOTE
To solve the issue of text files that do not specify their encoding, use the
file_encoding.cfg configuration file. Refer to Appendix F, “Specifying Content
Encoding,” for detailed information about creating configuring settings in
file_encoding.cfg.
Scenario 1
1. A Japanese user goes to a Japanese site which does not specify its encoding.
Netscape defaults to Japanese (Auto-Detect).
2. The Japanese user logs into TeamSite (UTF-8 pages). Netscape switches to UTF-8.
3. The Japanese user opens a new window and returns to the Japanese site which does
not specify its encoding. Now Netscape defaults to UTF-8.
This would not happen if the site specified the encoding of its web pages.
Scenario 2
1. A Japanese user logs into TeamSite (UTF-8 pages). Netscape switches to UTF-8.
2. The Japanese user’s content in TeamSite does not include the ‘Content-type’ META
tag.
3. Upon entering SmartContext QA, Netscape tries to render the content as UTF-8,
which is probably wrong. The solution to this problem is to always specify the
encoding for all HTML content.
If this procedure does not deliver the expected results (that is, certain characters are not
displayed properly), try the following procedure:
1. Select View > Character Set > Set Default Character Set.
2. Select View > Character Set > Unicode (UTF-8).
Usage Scenarios
The following examples illustrate some of the advantages of using TeamSite in a global
enterprise. Note that a branch scenario could also apply to a workarea, directory, or file
operation (for example, New Branch, New Workarea, and Import File). Scenarios can
also be applied to other locales.
Scenario 1
1. The TeamSite server is running in the Windows Japanese 2000 locale.
2. You create a branch with a Japanese name using ContentCenter running on Japanese
Windows 2000. This branch is created in the TeamSite File System with Windows
Japanese encoding.
3. You can navigate this branch with the Japanese name using ContentCenter.
4. You can also log on to the server machine and access this branch with Japanese
name using the file system interface (Windows Explorer).
Scenario 2
1. The TeamSite server is running in the Windows Japanese 2000 locale.
2. Your TeamSite Administrator copies a directory from the Windows Explorer file
system into the TeamSite File System. This directory contains file and directory
names with Japanese encoded names.
3. Your TeamSite Administrator creates a file in the TeamSite File System with a
Japanese encoded name.
4. ContentCenter users (on any client platform) can view and access this directory (and
corresponding files) with a Japanese name.
Scenario 3
1. Type an iwsubmit command in a shell window running on a Japanese 2000 system.
2. Create submit comments in Japanese.
3. Execute the iwsubmit command. In ContentCenter, the Japanese submit comments
are displayed correctly with the corresponding entity submitted.
Single Sign-On
This chapter describes the procedure for configuring TeamSite to integrate with single
sign-on (SSO) authentication products. These products include SiteMinder from
Computer Associates as well as authentication software from other vendors. The
integration enables:
The TeamSite server to act as another web server in a portal environment controlled
by the SSO product.
A single sign-on where TeamSite users log in once against the SSO authentication
engine and are authorized to access all of its resources (TeamSite and the other web
servers in the portal) without having to log in to TeamSite explicitly.
Overview
TeamSite provides a framework providing integration with SiteMinder. You can also use
this framework to integrate SSO products from other vendors. See theTeamSite Release
Notes for details about which SSO products are currently supported.
After completing the integration described in this chapter, the SSO product controls
access to TeamSite by authenticating the user against its user database and placing an
Interwoven authentication cookie in the browser. Three different integration scenarios
are described in detail:
Integrating CA SiteMinder with TeamSite together with the Interwoven Active
Response module. This is the same integration that was supported in previous
versions of TeamSite and is the recommended configuration. No SiteMinder Policy
Server configuration changes are necessary when an existing system is upgraded to
TeamSite 6.7.1 or later from TeamSite 6.5 or 6.7. However, if you are using an older
Web Agent that does not support Apache 2, you will need to upgrade to a version
that supports Apache 2. See “Installing and Configuring the SiteMinder Web Agent
on the TeamSite System” on page 322 for more information.
Integrating CA SiteMinder with TeamSite without employing the Interwoven Active
Response module. This integration is recommended when it is not practical to install
an Active Response module for TeamSite in the SiteMinder Policy Server.
Integrating an SSO product other than SiteMinder with TeamSite without
employing an active response.
Prerequisites
The following conditions must already be met before you start this procedure:
TeamSite 6.7.1 or above is installed on one computer.
SiteMinder Policy Server 5.5 or 6.0 is installed on another computer.
You have an SSL certificate for the TeamSite system.
You have a SOAP license for the TeamSite system.
TeamSite and SiteMinder share the same user database.
Overview
With this configuration, two credential verifications are performed when a user signs on
through the SiteMinder system. First, SiteMinder authenticates the user and sets an
SMSESSION authentication cookie. Upon successful authentication by SiteMinder, the
SiteMinder Policy Server opens an encrypted channel to the TeamSite authentication
service, and the user is authenticated by TeamSite. Following successful authentication
by TeamSite, a TeamSite IWAUTH authentication cookie is set, and the user is able to
access TeamSite.
The typical sequence of data and operation flow following integration is depicted in the
following figure and described in the legend that follows.
4
iw-webd with SiteMinder web agent
3
Browser
8 6
9 9
TeamSite servletd
(Content Services)
10 10
5. The Interwoven Active Response module makes an SSL connection to the TeamSite
Access Service and sends the user’s login credentials in a SOAP message using
HTTP.
6. The TeamSite Access Service authenticates the user and returns a session string that
the Active Response module uses to create an IWAUTH cookie.
7. The Active Response module then writes the IWAUTH persistent cookie to the web
agent.
8. The web agent passes the cookie to the user’s browser.
9. The cookie is checked each time the user visits a page served by TeamSite.
10. Upon verification, the page is served from TeamSite and displayed in the user’s
browser.
Integration Procedure
Performing this integration involves the following main steps:
Installing and Configuring the SiteMinder Web Agent on the TeamSite System.
Setting Realms, Rules, and Responses on the SiteMinder Policy Server.
Setting Environment Variables on the SiteMinder Policy Server.
Copying the Active Response Module to the SiteMinder Policy Server.
Installing and Configuring the SiteMinder Web Agent on the TeamSite System
1. Ensure that the host and agent configuration objects that you plan to use are created
prior to running the SiteMinder Web Agent installation script. This is necessary
because the SiteMinder Web Agent installation script prompts you for the IP address
of the SiteMinder Policy Server, the name of the agent configuration object, and the
name of the host configuration object.
2. Run the SiteMinder Web Agent installation script supplied by CA. Refer to the
documentation provided with that product for more installation details. On
Windows systems, SiteMinder Web Agent V5QMR8 is supported. On UNIX
systems, SiteMinder Web Agent V5QMR7 is supported.
3. On UNIX systems, the SiteMinder Web Agent software is usually installed in a
different location from the web server it services. To find the various libraries and
executables it needs, the Web Agent uses the following environment variables:
$LD_LIBRARY_PATH
$NETE_WA_ROOT
$NETE_WA_PATH.
SiteMinder provides a script called nete_wa_env.sh with the Web Agent software
that sets these environment variables.
The “.” followed by a space at the beginning of the command is required. It tells the
shell to execute the script in the current shell environment without forking another
shell.
4. On Windows systems, copy the WebAgent.conf and LocalConfig.conf files from
$NETE_WA_ROOT\BIN\IIS to $IW_HOME\iw-webd\conf. This step is necessary
because the Windows Web installation script for Web Agents does not recognize the
iwwebd Apache server. This step is not necessary on UNIX systems.
Table 27 Realms
Realm Name Realm Type Resource Filter
protected_iw Protected /iw
unprotected_iw Unprotected /iw/services/cm/2.0/accessservice
Table 28 Rules
Rule Name Description
Authenticate_iw - iw* Configured for authenticating event actions.
Protected_iw - iw* Configured for GET, PUT, POST actions.
The other Realm does not require any rules.
4. Create a SiteMinder Response with the name IWResponse and the following details:
Table 29 Response
Field Entry
Attribute of the Response WebAgent-OnAccept-Redirect
NOTE
Leave the Parameters field empty.
The Interwoven Active Response module uses two environment variables. One of these
specifies the host computer and port that is used to talk to the TeamSite Access Service.
The other specifies the location of a text file that is used to seed the pseudo-random
number generated used by the SSL encryption libraries. This may be any file, preferably
one that changes randomly.
Perform the following procedure on the system where the SiteMinder Policy Server is
running.
On a Windows system:
1. Right-click on the My Computer icon on your desktop and select Properties from
the menu. The System Properties window displays.
2. Click the Advanced tab.
3. Click Environment Variables. The Environment Variables dialog box displays.
4. In the System variables section, click New. The New System Variable dialog box
displays.
5. Enter INTERWOVEN_AUTH_HOST in the Variable Name field.
6. Enter the name of the server and optional port in the Variable Value field, for
example: server.interwoven.com:443.
This environment variable provides the name of the TeamSite server and optional
port. If no port number is specified, the default port number 443 is used.
7. Click OK to close the New System Variable dialog box.
8. Again, select New from the System variables section to display the New System
Variable dialog box.
9. Enter INTERWOVEN_RAND_FILE in the Variable Name field.
10. In the Variable Value field, enter the complete path of a file containing random text,
for example: c:\iw\random.txt.
11. If you are using an LDAP system and the Windows account name is not part of the
Distinguished Name (DN) of the system’s users, you must tell the Interwoven
Active Response module where to find a user’s Windows account name. To do this,
set an additional environment variable called INTERWOVEN_USER_ATTR as follows.
(The Windows account name is typically already part of the DN. If that is the case
with your system, skip to step 12.)
a. Select New from the System variables section to display the New System
Variable dialog box.
b. Enter INTERWOVEN_USER_ATTR in the Variable Name field.
c. In the Variable Value field, enter the name of the LDAP attribute that contains
your system’s users’ Windows account name. This name is typically “uid” or
“SAMAccountName.”
12. Click OK to close the New System Variable, Environment Variables, and System
Properties windows.
13. Reboot your system.
The installation program automatically places the Active Response module needed to
integrate TeamSite and SiteMinder in the iw-home/lib directory on your TeamSite
server. The module is in a file is called iwtssmar.so (on UNIX systems) or
iwtssmar.dll (on Windows systems) and must be copied to your SiteMinder Policy
Server.
1. Stop all SiteMinder Policy Server daemons (UNIX) or services (Windows). Refer to
the SiteMinder Operations Guide for detailed instructions.
2. Copy the iwtssmar.so (UNIX) or iwtssmar.dll (Windows) file from iw-home/lib
to where the policyserver_home/bin/smservauth executable can find it.
For example (UNIX):
%cp iw-home/lib/iwtssmar.so /var/siteminder/bin/
Prerequisites
The following conditions must already be met before you start this procedure:
TeamSite release 6.7.1 or above is installed on one computer.
Overview
This configuration does not require the installation of any proprietary Interwoven
software on the SiteMinder Policy Server, and requires no connection between the
Policy Server and the TeamSite authentication service. With this approach, users are
authenticated solely by SiteMinder, and there is no additional TeamSite authentication
step. SiteMinder verifies the user’s password, sets an SMSESSION authentication cookie,
and passes the user’s identity to TeamSite through a session cookie or HTML header
parameter. TeamSite prepares an IWAUTH access cookie based on the user’s identity, and
does not perform any further credential check.
The advantages of this approach are that there is no requirement to install an Interwoven
authentication plug-in in the SiteMinder Policy Server, and there is no need to open a
communication channel between the Policy Server and the TeamSite authentication
service.
The typical sequence of data and operation flow following integration is depicted in the
following figure and described in the legend that follows.
4
1
iw-webd with SiteMinder web agent
3
Browser
6
7 7
TeamSite servletd
(Content Services)
8 8
2. The web agent intercepts the request and prompts for a user name and password.
3. A user enters a user name and password.
4. The SiteMinder web agent passes the login information to the SiteMinder Policy
Server, which authenticates the user.
5. TeamSite sees the SMSESSION cookie that SiteMinder has set, looks up the user
name, and sets an IWAUTH cookie that TeamSite will use for access control.
6. The web agent passes the cookie to the user’s browser.
7. The cookie is checked each time the user visits a page served by TeamSite.
8. Upon verification, the page is served from TeamSite and displayed in the user’s
browser.
Integration Procedure
Performing this integration involves the following main steps:
Installing and Configuring the SiteMinder Web Agent.
Configuring the SiteMinder Policy Server.
Configuring TeamSite.
$NETE_WA_PATH.
SiteMinder provides a script called nete_wa_env.sh with the Web Agent software
that sets these environment variables.
In a typical TeamSite installation, TeamSite is configured to start automatically
whenever its host computer is booted. For the SiteMinder Web Agent to start, values
The “.” followed by a space at the beginning of the command is required. It tells the
shell to execute the script in the current shell environment without forking another
shell.
4. On Windows systems, copy the WebAgent.conf and LocalConfig.conf files from
$NETE_WA_ROOT\BIN\IIS to $IW_HOME\iw-webd\conf. This step is necessary
because the Windows Web installation script for Web Agents does not recognize the
iwwebd Apache server. This step is not necessary on UNIX systems.
Table 30 Realm
Realm Name Realm Type Resource Filter
protected_iw Protected /iw
Table 31 Rules
Rule Name Description Action
iwCookieRule Sets a session cookie upon Authentication event
successful authentication. onAuthAccept.
If you are using an HTTP header parameter instead of a session cookie, use the
following rule:
Table 32 Rules
Rule Name Description Action
iwHeaderVarRule Sets a header parameter Authentication event
upon successful onAuthAccept.
authentication.
Table 33 Response
Field Entry
Name iwCookieResponse
Table 34 Response
Field Entry
Name iwHeaderVarResponse
Table 35 Response
Field Entry
Name iwDomainResponse
If you are using an HTML header parameter for the domain name:
Table 36 Response
Field Entry
Name iwDomainResponse
6. If the protected_iw realm does not already have a policy, create one with the
following settings:.
Table 37 Policy
Policy Name Enabled
iw-policy Yes
If you configured the system to pass user information in the session cookie, in the
Rules tab select Add/Remove Rules. Select iwCookieVarRule that you created
earlier and add it to the policy. After you add the rule, select Select Response to tie
iwCookieVarResponse to the rule.
If you configured the system to pass user information in an HTML header parameter
(rather than in the session cookie), in the Rules tab select Add/Remove Rules. Select
iwHeaderVarRule that you created earlier and add it to the policy. After you add the
rule, select Select Response to tie iwHeaderVarResponse to the rule.
If TeamSite is running on a Windows computer, and you have chosen to pass the
user’s domain name separately from his account name, create another rule under the
protected_iw domain called iwDomainRule, and add it to iw-policy. After you
add the rule, select select Response to tie iwDomainResponse to the rule.
Configuring TeamSite
The TeamSite configuration described here is performed through the UI toolkit. All of
these Java parameters are customized by entering their values as default-param
subelements in the applications element of the application_custom.xml file. See the
TeamSite User Interface Customization Guide for details about setting parameters in
application_custom.xml.
NOTE
You can perform this configuration before or after you install and configure the
SiteMinder Policy Server.
The default value for this parameter is false; to enable SSO, it must be set to true.
2. Verify that the name of the SSO cookie set by the SSO package is already set to
SiteMinder’s default of SMSESSION. The setting should appear as shown here. If it
does not, reset it accordingly:
iw.common.authentication.ssoCookieName=SMSESSION
If you choose to set a cookie, set ssoUserCookie to the variable name that you
specified in step 5 in the preceding section:
iw.common.authentication.ssoUserCookie=session_cookie_name
4. On Windows systems, if your user directory does not contain an attribute for each
TeamSite user in the form domain\user, domain/user, or user@domain.com, you
may need to send the domain information separately in a different session cookie or
HTTP header parameter.
If you choose to set a header parameter, set it as follows:
iw_common.authentication.ssoDomainParam=header_parameter_name
Prerequisites
The following conditions must already be met before you start this procedure:
TeamSite release 6.7.1 or above is installed on one computer.
An SSO product is installed on another computer.
You have an SSL certificate for the TeamSite system.
You have a SOAP license for the TeamSite system.
TeamSite and the SSO product share the same user database.
Overview
This configuration does not require the installation of any proprietary Interwoven
software in the SSO system. Authentication is delegated completely to the SSO system,
without TeamSite playing a role. This approach accommodates a variety of different
SSO products from different vendors. To use an SSO system with TeamSite, it must be
able to pass the authenticated user’s account name to TeamSite upon completion of
authentication. This may be done using an HTTL header parameter or a browser session
cookie.
The typical sequence of data and operation flow following integration is depicted in the
following figure and described in the legend that follows.
SSO Server
5
4
1
3
Browser
6
7 7
TeamSite servletd
(Content Services)
8 8
Integration Procedure
Performing this integration involves three main steps:
Installing and Configuring the SSO Web Agent
Configuring the SSO Server
Configuring TeamSite
The web agent must be compatible with Apache 2 web servers. See the SSO vendor’s
documentation for the recommended version and installation instructions.
The SSO server needs to generate either a session cookie or an HTML header parameter
that contains a TeamSite user account name. For Windows account names, the domain
may be sent in the same cookie or parameter, or it may be sent in a different cookie or
parameter. When the domain and user name are sent together, any of the following
forms is acceptable:
domain\user
domain/user
user@domain.com
Configuring TeamSite
TeamSite configuration is performed through the UI toolkit. All of the parameters are
located in the application_custom.xml file. See the TeamSite User Interface
Customization Guide for details about setting parameters in application_custom.xml.
NOTE
You can perform this configuration before or after you install and configure the SSO
Server.
The default value for this parameter is false; to enable SSO, it must be set to true.
2. Verify that the name of the SSO cookie set by the SSO package is already set to
SiteMinder’s default of SMSESSION. The setting should appear as shown here. If it
does not, reset it accordingly:
iw.common.authentication.ssoCookieName=SMSESSION
4. On Windows systems, if your user directory does not contain an attribute for each
TeamSite user in the form domain\user, domain/user, or user@domain.com, you
may need to send the domain information separately in a different session cookie or
HTTP header parameter.
If you choose to set a header parameter, set it as follows:
iw_common.authentication.ssoDomainParam=header_parameter_name
Troubleshooting
“Failed to start the LLAWP process. Execlp failed: No such file or directory.”
These and similar messages may result if the NETE_WA_* environment variables are not
correctly set. See SiteMinder Knowledge Base article 222207 for additional details.
If the ServerPath parameter is missing from the Web Agent configuration, you may get
messages of the form child pid 1234 exit signal Abort (6). The solution is to add
a value for ServerPath to the WebAgent.conf configuration file.
If the SiteMinder LLAWP process does not shut down correctly when iwweb is stopped,
it may be because the SiteMinder ServerPath parameter was specified in the Agent
Configuration Object instead of in WebAgent.conf. The solution is to move ServerPath
to the WebAgent.conf file, and to remove any associated semaphores. You can do this
using the OS commands ipcs and ipcrm, or by rebooting the system. See SiteMinder
Knowledge Base article 222318 and Tech Note 1027 for additional details.
If the problem persists after applying the ServerPath fix, a workaround is to issue the
following command before running any script or command that stops and restarts the
TeamSite iwweb web server:
LLAPW /pathToConfigDirectory/webagent.conf -APACHE20 -shutdown
If the SiteMinder dialog appears correctly, then after entering the user name and
password for a valid TeamSite user, you should see the TeamSite page you requested. If,
instead, you see a TeamSite login page, then TeamSite did not detect an Interwoven
IWAUTH session cookie, either because one was not created, or because it was created in
the wrong domain.
If the IWAUTH cookie is not present, it may be because the user is present in the
SiteMinder user database, but he is not a valid TeamSite user. Make sure that the user is
present in the tsusers.xml file.
Netscape and Mozilla Firefox web browsers provide a “cookie manager” option that
displays the value of all cookies, including session cookies. If an IWAUTH cookie is
present, but its domain does not match the path you typed for the TeamSite web page,
you may need to make changes to your Web Agent configuration file, or to your
system’s DNS settings to correct this. If the IWAUTH cookie is absent completely, and the
user is a valid TeamSite user, then the problem is probably due to a SiteMinder Policy
Server configuration error. If you are using a session cookie to pass the user name to
TeamSite, make sure that the cookie is set as expected, and that its name matches the
name you have selected in the TeamSite application.xml configuration file.
This message is written to the log file if the SiteMinder computer is unable to open a
TCP/IP socket connection to the TeamSite server. A possible reason for this might
be that the TeamSite server is unreachable or that the INTERWOVEN_AUTH_HOST
environment variable contains an incorrect host name or port number. This message
will also be seen if the Interwoven Access Service on the TeamSite server is not
configured with a valid SOAP license key.
Interwoven: SSL Connection error.
This message is written to the log file if SiteMinder is able to open a socket
connection to the TeamSite server but is unable to establish an SSL session over the
channel. Possible reasons include a misconfigured TeamSite server whose X.509
certificate is missing or corrupt.
Interwoven: Failed to send query to server.
This message is written to the log file if the SSL channel to the TeamSite server
fails.
Interwoven: Failed to get session string from server.
This message appears if the supplied user name and password are valid, but no
TeamSite role is associated with the user. This message does not necessarily denote
an error if there are some SiteMinder users that are intentionally not given access to
TeamSite.
The TeamSite Service Monitor is a “watchdog” service that monitors the TeamSite
server (iwserver). You must purchase TeamSite Service Monitor in addition to the base
version of TeamSite to use the features described in this appendix.This appendix
describes the TeamSite Service Monitor:
Service Monitor Overview
TeamSiteService Monitor Components and Processes
Installing TeamSite Service Monitor
Configuring TeamSite Service Monitor
NOTE
The Service Monitor only monitors iwserver; it does not monitor any other Interwoven
services. Additionally, it does not monitor TeamSite in a cluster environment.
You can configure the Service Monitor in several ways. For example, you can instruct it
to:
Shut down the TeamSite server and notify a specified system user that a power or
process failure was detected.
Stop the TeamSite server after detecting a failure even if all post-failure system
checks are normal.
Perform a different action depending on whether a power failure or a process failure
was detected.
Perform any other Perl script-defined action automatically upon failure detection.
For any failure, you must execute a file system check (use the iwfsck CLT described in
the TeamSite Command-Line Tools) to ensure that data inconsistencies have not been
introduced.
You can also turn off the Service Monitor completely, in which case the base version of
TeamSite continues to run.
Start
iwtock
Yes Yes
Start iwserver
Yes (Solaris)
Continue
monitoring
iwserver
The main TeamSite Service Monitor component is the iwtock watchdog service, which
starts the iwserver process and tracks iwserver execution for as long as the TeamSite
server is running. When iwtock first starts, it determines whether the previous TeamSite
shutdown was abnormal or normal. If it detects an abnormal shutdown, iwtock runs the
iw-home\ha\conf\iw.powerfail script, which can be configured either to stop iwtock
or to perform a variety of system checks or other actions as described in “Configuring
TeamSite Service Monitor” on page 342. If the system meets the passing criteria defined
in iw.powerfail, iwtock starts iwserver. If the system does not meet the passing
criteria, iwtock stops and iwserver is not started. All output from iw.powerfail is
logged in iwserver.log.
If iwtock determines that the previous TeamSite shutdown was normal, it starts
iwserver. From this point on, iwtock continues to monitor iwserver. If at any time
iwtock detects that iwserver is not running and there is no evidence of an explicit
shutdown, it assumes that an unexpected shutdown or system interruption has occurred.
In this situation, iwtock runs the iw-home\ha\conf\iw.processfail script, which can
be configured either to stop iwtock or to perform a variety of system checks or other
actions as described in “Configuring TeamSite Service Monitor” on page 342. If the
system meets the passing criteria defined in iw.processfail, iwtock exits (it cannot
start iwserver due to Windows architecture characteristics). If the system does not meet
one or more passing criteria, iwtock stops and iwserver is not restarted.
NOTE
If iwserver attempts to spawn more than once within 30 seconds of initial startup or a
restart, iwtock will exit.
On any list of active system processes, iwtock appears as iwperl (you will not see a list
entry called iwtock).
iw.powerfail
The default iw.powerfail script shown here is shipped with TeamSite. In its current
form, it only logs its own name (iw.powerfail) when executed. It also contains a
commented example of how you could configure the script to run the iwsi program to
send email to a system administrator when the script executes. You can configure this
script to perform any action upon execution; the only requirement is that you use Perl
syntax compatible with Perl Release 5.00503. All results returned by iw.powerfail are
logged in iwserver.log.
NOTE
Review the current best practices related to recovering from a failure that posted at
https://support.interwoven.com. For any failure, you must execute a file system
check (use the iwfsck CLT described in the TeamSite Command-Line Tools) to ensure
that data inconsistencies have not been introduced.To force iwtock to exit rather than
start the TeamSite server after iw.powerfail executes, specify an iw.powerfail exit
value of 127. This feature is included for scenarios in which TeamSite should not restart
automatically following a power failure.
use File::Basename;
print( basename( $0 ) . "\n" );
#
# Use this script to execute processes that can clean up after a powerfail
# crash.
#
# This script is executed when the Watchdog daemon determines that the
# system was not taken down cleanly, and the daemon is itself beginning
# execution.
# Some of the things that might be tried:
# Run the iwfsck CLT
#
# You may also want to mail your system administrator at this point:
#
#use Mail::Send;
#$msg = new Mail::Send Subject=>'TeamSite problem', To=>'admin,root';
#$mfh = $msg->open;
#print $mfh "Please address TeamSite issues at your earliest convenience";
#$mfh->close;
#
# If you do not wish to continue bringing up the system, then exit this
# script with a 127.
# 127 indicates to the daemon that it is not to continue with the bringup.
#
#exit 127
iw.processfail
The default iw.processfail script shown here is shipped with TeamSite. In its current
form, it only logs its own name (iw.processfail) when executed. It also contains a
commented example of how you could configure the script to run the iwsi program to
send email to a system administrator when the script executes. You can configure this
script to perform any action upon execution; the only requirement is that you use Perl
syntax compatible with Perl Release 5.00503. All results returned by iw.processfail
are logged in iwserver.log.
NOTE
Because of the way in which TeamSite and Windows interact, it is not possible for
iw.processfail to restart the TeamSite server. Instead, the iwtock service exits
whenever iw.processfail finishes executing. At that point, you must reboot the system
to restart the TeamSite server.
use File::Basename;
print( basename( $0 ) . "\n" );
#
# Use this script to execute processes that can clean up after a TeamSite
# crash after the system has begun processing data.
#
# This script is executed when the Service Monitor daemon determines that
# the system was not taken down cleanly, and the daemon has already begun
# observing the execution of TeamSite. Some of the things that might be
# tried:
#
#
# You may also want to mail your system administrator at this point:
#
#use Mail::Send;
#$msg = new Mail::Send Subject=>'TeamSite problem', To=>'admin,root';
#$mfh = $msg->open;
#print $mfh "Please address TeamSite issues at your earliest convenience";
#$mfh->close;
#
# If you do not wish to restart the system, then exit this script
#exit 127
Related Documentation
See the iwsi documentation in TeamSite Command-Line Tools for more information
about the TeamSite Service Monitor.
Troubleshooting
NOTE
Several features have troubleshooting sections in the chapters describing those features.
Administrator
An out-of-the box role configured for the owner of a branch, responsible for the
project being developed on it. An Administrator can perform all the functions that
an Author or an Editor can, and can also create and delete new subbranches and
workareas on his branch. Administrators exercise control over workflow by giving
workareas to editors and subbranches to other administrators.
approve
When an Editor approves a file returned by an Author, the file is submitted to the
staging area. Approving a file automatically unlocks it and removes it from the
Author’s Task list.
assign
To lock a file for the use of a specific Author and attach comments. A list of
assigned files displays in the Author’s Task list. Editors can also view a list of files
that they have assigned.
attribute search
A basic parametric search that involves single-level value-pairs AND/OR search
criteria. The supported operators for parametric search are: equal (=), less than (<),
less than or equal (<=), greater than (>), greater than or equal (>=), not equal (<>).
Author
An out-of-the box role configured for a primary web content contributor with
limited access to the TeamSite system, usually using ContentCenter Standard.
Authors can access, create, and modify web content through their Editors’
workareas. An Editor can assign specific files to an Author, which will appear in the
Author’s Task list.
Autoprivate
The Autoprivate feature helps minimize clutter on the development server.
Autoprivate automatically identifies file types that should not be submitted to the
staging area and marks them as Private. These files typically include Microsoft
branch
A path of development for a body of content developed and maintained by a team.
Each branch contains one or more workareas, a staging area, and a published edition
and may contain subbranches and previous editions.
casual contributor
A person who modifies or creates content using TeamSite, usually on an infrequent
or sporadic basis. “Contributor” is a generic term that does not designate a specific
TeamSite role.
category
In FormsPublisher, a category is a grouping of types of templates. Category
directories are the first division of the templatedata directory. Each category has its
own directory, which contains subdirectories for each type within it. An example of
a category would be beverages, which may contain tea, coffee, milk, and soda types.
When editing roles, categories are groupings of operations that users can perform
within a role.
collection
The metadata for a set of documents with optimized architecture for searching.
command trigger
A type of command-line tool that can trigger scripts when specific TeamSite events
occur. An example is the use the iwatsub command trigger to trigger an event when
files are submitted.
comment
A note attached to a file, directory, workarea, branch, edition, job, or task.
Comments can be attached to workareas, branches and editions when they are
created. Comments can be attached to files and directories when they are assigned,
returned, rejected, locked or submitted. Global comments can be set when these
functions involve multiple files.
Compare
A function that displays a list of the differences between any two TeamSite objects.
Objects that can be compared include workareas, staging areas, or editions.
conflict
Occurs when multiple users make changes to the same file in multiple locations, for
example, when a file has been changed in two different workareas.
conflicting edits
Occur when multiple users make changes to the same parts of the same file,
producing two versions of the file that cannot be automatically merged. Conflicting
edits require users to specify which individual changes will go into the merged
version.
content
A set of information contained within a text document, vocabulary, file, or database
record. See also data record.
ContentCenter Professional
A user interface for experienced TeamSite users, technical users, or users who have
some familiarity with content management systems. It is intended for “power
users,” and users who must administer content development projects. It includes
integrated administrative functions for easy, contextual TeamSite administration and
fully customizable menus, tabs, and more.
ContentCenter Standard
A user interface for business users—that is, non-technical subject matter experts and
infrequent users of a content management system. It includes an initial customizable
“home page” containing module UI components displaying areas for a user's tasks,
favorites, work in progress, and forms, wizards for common functions, and
out-of-box email messages for workflow task notification.
contributor
A person who modifies or creates content using TeamSite. “Contributor” is a
generic term that does not designate a specific TeamSite role.
convert
The process of changing a Microsoft Word file to PDF or HTML format.
data record
An XML file containing formatting information interspersed with data captured
from a contributor or through other means. A data record is named when a content
contributor saves the record. Content contributors can edit a data record by
reopening it in the form that created it. Several different data records can also be
matched to a single presentation template to create one or many output files. Data
records can also be deployed to a database by Interwoven DataDeploy.
delegated administration
Users in specific roles may be allowed to delegate administrative activities to users
in other roles. This is set up in the Edit Roles screen. This allows administrative
activities to be performed by users who are most involved with that content.
edition
A frozen, read-only snapshot of a branch of development. An edition contains a
copy of all the files in the staging area at the time it was published. New editions can
be released to production servers as complete, functional Web sites. Editions also
serve as rollback points for projects in development, and they provide permanent
archives of the Web site for Site Rollback.
Editor
An out-of-the box role configured for the owner of a workarea or workareas. Editors
assign files to Authors, manage files, and edit and create files, submit content to the
staging area, and may create editions. Editors may have access to workareas that
they do not own, but they cannot assign files in these workareas.
form
The form generated by a data capture template. A contributor fills out a form to
create a data record. A form displays in the FormsPublisher window so that a user
can enter and format data, select options, and access menu items.
form entry
The information a user enters in a blank form. Form entry files are stored in
locations selected within the templatedata/form_category/form_type/data
folder in the user’s workarea, and are available to recall and use as necessary.
form item
An element in a data capture template that defines a form field, such as a text field,
text area, check box, combo box, or option button.
Full-text search
Ability to search by entering one or more keywords from any document and
applying AND/OR operators on the keywords.
Get Latest
A command that brings staging area content that is different from the workarea
content into the workarea.
groups
TeamSite groups are a collection of users who can access branches and share
workareas. TeamSite groups complement the operating system groups that may
exist.
history
A complete record of all changes that have been made to a file through time. A user
can see the complete history of a file by selecting it and selecting History from the
View menu.
initial edition
The first edition on a newly created branch. The initial edition serves as the original
source of content for all workareas on a new branch. This edition may be empty, or
it may be a copy of an edition from another branch.
job
A set of interdependent tasks assigned to one or more people. All jobs are based on
predefined workflows, and each job is a specific instance of a workflow model.
When a user starts a job based on a workflow, the user specifies who should perform
each task, and then initiates the job. The person who is to perform each task is
notified through the Tasks section of the ContentCenter interface (and optionally
through email) that there is a task to perform. After a task is completed, the job
proceeds to the next task in its sequence that was defined by the workflow. When all
of the tasks in a job are done, the job is complete.
locking
Restricting file access within a branch. Locking a file reduces the possibility of
conflicting edits but also reduces the team’s ability to work on files simultaneously.
Every time a file is locked, the version in the workarea is compared with the version
in the staging area and the latest is taken (although this behavior can be overridden).
TeamSite supports three types of locking, or locking models: Submit Locking,
Optional Write Locking, and Mandatory Write locking. The locking model is
main branch
The first branch created when TeamSite is installed. The Main Branch is owned by
the Master user. All branches in the TeamSite system are subordinate to the main
branch.
Master
An out-of-the box role configured for the owner of the main branch. The Master
user is responsible for the entire Web site. The Master organizes the structure of the
TeamSite system and coordinates the activities of all users, creates roles, assigns
operating system users, and can also perform all functions on all branches. Master
users have access to the ContentCenter Professional Administration tab.
merge
The process of reconciling conflicts between versions of a file that have been edited
by two people. The two versions can be merged in the staging area to produce a new
version of the file, incorporating changes made by both users. Merging can be
automated with TeamSite’s Advanced File Merging.
metadata
There are four types of metadata: file properties, user-specified metadata,
system-provided metadata (such as FormsPublisher extended attributes), and
derived metadata from Metatagger operations.
Navigation Window
The left-hand side of the TeamSite window, which allows you to navigate through
TeamSite by clicking on the underlined names of branches, workareas, staging
areas, editions, or directories.
output file
A file that a user generates by combining form entries with a presentation template.
The output file is typically in HTML format for use as a Web page, although it can
presentation template
A template that defines how form entries will appear when displayed. For example,
a presentation template could specify the size, color, and layout of a Web page.
A presentation template is populated with data from one or more of the following
sources:
Data record
Queries to databases
FormsPublisher can be configured to populate any presentation template with any
data record plus additional information as required from a relational database.
A contributor can match a single data record with several presentation templates to
create multiple output files containing the same or similar information, each suitable
for a different Web site, each with a different look and feel.
Presentation templates can be used with component templates. A component
template is a presentation template nested within another presentation template.
Multiple data records of the same type can use a single presentation template to
create multiple output files in the same format.
preview
Viewing content prior to submitting, deploying, or generating an output file from it.
Previewing typically pertains to Web sites that being working on. For example,
before beginning work on a Web site, a user may preview it to assess its current look
and feel. Previewing is also useful after you have finished working on a Web site to
ensure that your changes appear as you intended prior to making the Web site
publicly available. Previewing within FormsPublisher is limited to displaying the
output of the form being worked on using a specific presentation template.
private
Within a workarea, a user can mark a file as Private, which prevents the file from
being submitted to the staging area if the file is a part of a workarea or directory that
is submitted. It also prevents the file from being copied to another workarea during
a Copy To operation.
public
The opposite of Private, the Public function removes the private marking on a file.
All files are public by default.
publish
The publishing of finished content to environments beyond the one where it was
created. For example, a user could create a press release from within ContentCenter,
submit the final version for approval and inclusion in the staging area, and then
publisher
An application that sends events to the Event subsystem.
Reviewer
An out-of-the box role configured for users who are responsible for reviewing
content prepared by other users.
role
A collection of operations that are assigned to users. These are stored in the
roles.xml file. Master users configure roles to meet the needs of their installation.
Search index
Search is enabled by building an index of searchable content and metadata.
Search results
The returned set of assets that adhere to the specified criteria.
Site Rollback
The process of deploying a previous edition in place of the current Web site.
Because TeamSite editions are complete copies of the entire Web site at the time of
publication, they can be referenced to revert to prior versions of files, directories, or
the entire Web site.
staging area
The area where users integrate the contents of their workareas. Users submit
read-only copies of files from their workareas to the staging area to integrate with
other contributions, and test the integrity of the resulting Web site.
subbranch
A branch subordinate to a major branch. To separate development efforts among
teams or team members, an Administrator can create subbranches. The subbranch
receives its own unique staging area and workareas and generates its own editions.
Editions published on a subbranch can be integrated back into work on the higher
branch, or released as stand-alone Web sites.
Submit Locking
A type of locking in which users can choose to lock a file to insure that their
changes are submitted to the staging area. While a file is locked, other users can edit
their own version of the locked file within their workarea, but they cannot submit to
the staging area. Once the lock holder has released the file lock, other users can
merge their modifications with the new file version.
subscriber
An application that registers with the Event Subsystem to receive events.
tag
When users tag a file, they specify additional descriptive information that remains
with the file indefinitely (this information is also called metadata). For example, a
user could tag a press release file by adding a title such as “Press Release,” key
words such as “July” and “Acquisition,” a region such as “California,” and so on.
These tags do not appear in the text of the file, so they are not displayed when the
file is viewed through a browser or editing application. Instead, they appear when
you view the file’s tags, use search functionality, or use a product such as
Interwoven MetaTagger.
task
A unit of work performed by a single user or process that is part of a job. Each task
in a job is associated with a particular TeamSite workarea and carries a set of files
with it. There are two types of tasks: individual and group.
Individual tasks are assigned to a specific person. When an individual task is
assigned to a user, it appears under Tasks > My Tasks view in the Workflow
tab. From there the user can take whatever action is necessary to complete the
task.
Group tasks are assigned to a group of people, any one of whom can perform the
task. (Groups are defined and maintained by ContentCenter administrators and
other maintainers of your ContentCenter system.) If a group task is assigned to
your group, it appears under the Workflow tab > Tasks > Unassigned Group
Tasks view. From there a user can take ownership of the task and complete it.
After you perform a task, the job proceeds to the next task in its predefined
sequence. When all of the tasks in a job are done, the job is complete.
task transition
Selecting a task transition moves the job along the workflow process by activating
successor task(s).
template
A file that specifies attributes of another file, such as look and feel. When you create
a file, you can choose to base that file on a template.
templating.cfg
type
A division within a category in FormsPublisher. Each type has a corresponding data
capture template so that users can enter information for that type. Examples of types
could be tea, coffee, milk, and soda, which are part of the beverages category.
unlock
To remove a lock from a file. If an Editor has locked a file, the branch Administrator
or Master user can also remove the lock. The Master user can remove any lock from
any file.
user
A person who has been set up to be a TeamSite user and is assigned specific roles in
various TeamSite branches. A Master user has additional responsibilities for
maintaining TeamSite and adding users, creating roles, and so forth.
version
A numbered iteration of a content file. Whenever users submit a file and it is
approved, ContentCenter saves the new version of the file containing the changes
and retains the original, pre-edited version. Because previous versions are not
deleted, users can view all previous versions of the file, see when and by whom each
version was modified, and if necessary revert the current file back to an earlier
version. Note that versioning only occurs when a file is submitted to the staging
area. If a user just edits a file and saves the changes, a new version is not created
until the file enters the staging area.
VisualPreview
A tab that displays on an output page that allows you to perform various TeamSite
functions.
workarea
A virtual copy of a Web site, which may be worked on independently without
affecting the actual site or the work of other contributors. A workarea can be owned
by a single user or a number of users together. Editors and Administrators can own
workareas, but Authors cannot.
workflow
A sequence of tasks that can be assigned to one or more people. For example, a
workflow could define three tasks: to edit some text, to add an image, and to review
the work. Whenever users start a job, it must be based on a predefined workflow.
Workflows are defined by ContentCenter administrators and other maintainers of
the ContentCenter system. See also “workflow model,” “job,” and “task.”
workflow model
A general workflow configuration that can be used repeatedly. Each workflow
model describes a process which may include user tasks and a wide variety of
automated tasks.
default domains
code pages 314 configuring, in the login screen 40
drive (Y:) 66 for group authentication 131
file permissions 115 DTD
default_protocol 43 datacapture6.0.dtd 273
iwov_webdesk_url tag 43 metadatacapture6.0.dtd 179, 273
iwsend_servlet_mail.ipl script 43 metadata-rules.cfg 176
delegate role 86
delegated administration E
defined 352
delete_jobs_on_completion 217 ECM Connector 233
deleting 94 configuration 233
branches 75 configuring WorkSite MP 254
editions 74 modifying FormsPublisher 238
expired messages 56 modifying presentation templates 241
indexed edition 166 troubleshooting 256
TeamSite groups 99 Edit Role screen 85
users 94 Edit Users and Roles screen 106
Derby database 291 editions
creating 291 creating 24
managing 293 defined 22, 352
schema 291 deleting 74
setting user information 292 deleting indexed 166
testing 293 initial, defined 353
directories see also publishing editions
permissions 108 Submit logs 74
directory structure Editors
copying 61 defined 24, 352
disable_ext_task_impersonation 58 tasks 80
disabling email
VisualPreview 39 corrupted 346
disk cache domains 40
users/group/role 120 incorrect display 346
disk space mapping files 40
checking usage 73 servers 40
compression 74 settings, for workflow 40
conserving 74 tasks 40
file system mount 28 email_mapping_file 41
low 59 Embedded Failsafe 62
managing 73 enable_user_group_disk_cache 120
moving the Content Store 75 enabling
recovery 74 VisualPreview 39
removing old versions 75 encoding 42
removing unused branches 75 charset parameter 315
disklow_mbytes 59 file_encoding.cfg 306, 315
disklowpercent 59 html files 295
document root IANA preferred names 305
configuring 198 Merge tool 305
defined 197 META tag 315
mapping 197 setting in iw.cfg 42
domain local groups 119 Single Byte Character Sets 314
domain_list 40, 131 Source Differencing tool 305
domain_local_groups 117 specifying 315
text editors 304, 315
locking main_lock_model 45
branch 99 main_owner 100
branches 44 Manage Branches screen 103
configuring submits 45 manage groups 95
defined 353 mandatory write locking 44
in workareas 45 defined 354
on the main branch 45 mask_workarea_access 114
role and branch 44 Master
setting in role 86 defined 25, 354
types of 44 secondary 101
lockmodel_compatibility 45 specifying 90
log files tasks 80
config_summary.log 67 mdc_dd.cfg 186
configuration 67 MediaBin
event 68 anonymous access 255
iwevents.log 68 connecting to 233
iwjoberrors.log 69 ECM Connector properties 236
iwserver.log 67 link to assets 245
iwtrace 131 search 249
iwtrace.log 68 members of group 97
reviewing 67 Merge tool 295, 305
server 67 merging files
submit 46, 74 defined 354
trace 68 META tag 315
update 46 metadata
workflow 69 attribute 250
log size 46 custom 253
log_ldap_sync 129 data types 251
log4j.appender.mainLogger.MaxBackupIndex defined 354
parameter 148 Dublin Core 252
log4j.appender.mainLogger.MaxFileSize ECM Connector 249
parameter 148 metadata capture
log4j.logger.com.interwoven parameter 148 about 171, 172
logging components 173
in configuration files 173
authentication 107 configuring
out appearance 173
Crystal Enterprise 229 names 173
users and groups 131 rules 175
login DTD 176, 178
screen, configuring domain lists 40 extended attributes 175
low disk space 59 form 178
initiating from within a job 192
M required input 173
results of 175
maildomain 40 rule sets 178
mailserver 40 schematic 174
main branch
validating input 173
defined 354
workflow 191
locking model 45 metadata search
ownership 100 about 171
main_group 100 metadatacapture6.0.dtd 273
metadata-rules.cfg 274 O
about 173 old_mod_times 41
configuring 176 only_lock_owner_creator_submits 45
DTD 176 operating system groups 122
examples 176 optional write locking 44
location of 173 defined 354
rule identifier 176 oracle_schema.xml 225
sample file 176 OS groups 122
UTF-8 encoding 176 output file
vpath identifier 176 defined 354
Microsoft Management Console, mount errors 66 override permissions 108
Mixed Mode Active Directory 116 ownership
group information 117 branch 100
modification time 41 workareas, changing 122
monitoring
iwserver 339
system status 58 P
mount errors, Microsoft Management Console 66 passwords 107
mounting the TeamSite server 66 encrypting 126
MS SQL Server 2005 length 108
ReportCenter 230 paths
MsSQL server absolute 196
configuring 54 default 19
MsSQL server 2005 naming conventions 18
configuring 54 relative 196
mssql.xml 225 resolving see also proxy server
multibyte characters vpath 30
browser behavior when interpreting encoding PDF output 264
315 performance
multiple users 92, 93 monitoring 58
MultiStore using groups 119
backing up 212 permissions
mysql_schema.xml 225 checking 109
default 115
N directory 108
file 107, 108, 115
Native Mode Active Directory 117
Navigation Window override 87, 108, 347
defined 354 required for actions 108
nested groups role-based 107
disabling 121 types of 108
Netegrity 319 workarea 108
New Branch screen 101 port number
New Group screen proxy server 196
groups servletiw.cfg
creating 96 servlet_port 43
New Role screen 84 web server 196
new users presentation templates
adding 107 for ECM Connector 241
non-ASCII characters 310 pretty_print_dcrs 62
non-OS users 123 preview
adding to TeamSite 88 defined 355
impact 130 maintaining files 61
notation conventions 17 specifying directory for 62
Notepad, saving documents as UTF-8 315
preview_history_limit 61 regex_map
preview_system_directory 62 element 295, 297
private illustrated 296
branches 100 internationalization 304
defined 355 introduced 295
files 46 regular expression syntax 298
properties strategies 303
branch 104 UTF-8 304
group 97 variables 298
proxy server Regional Settings control panel 59
about 194 regular expressions
configuring about 17, 133
applying changes 195, 196 case-sensitivity 298
basic operation 196 expression engine 298
overview 193 file encoding 295
to use different webservers 204
in regex_maps 298
debugging 209
in Submit filters 133
document roots 199
relative paths 196
external remappings 205 see also proxy server
failover 207 remote contributors 194
fully qualified paths removing
Internet Explorer 201
resolving 199 users 94
server configuration 200 replicant
host header remappings 206 eliminating 274
ReportCenter
host name 196
configuring 217
port number 196
database 219
redirecting TeamSite views 202, 204
enabling 86
relative and absolute paths 196
remapping document roots error messages 230
rules of precedence 194 extended attributes 220
SSI remapping 207 files 224
public license key 219
defined 355 log file 219
public URL protection 41 modules 216
publisher overview 216
defined 356 user information 220
publishing Reporting tab
defined 355 ContentCenter 228
publishing editions 24 reports
importing 229
request handling 66
R resolving path names see proxy server
RDBMS restart server 345
configuring 52 restrict access 102
reconfiguring IP address 70 reverse proxy
recovering disk space 74 SiteMinder 323, 328
redirecting TeamSite views see proxy server Reviewers
defined 24, 356
tasks 79
W workflow models
and jobs 27
watchdog 339
assign-edit-approve 26
web browsers, interpreting encoding 315
defined 25, 359
web content, specifying encoding 315 WorkflowAdmin
web daemon
defined 25
about 194
tasks 81
configuring 193, 196 WorkflowUser
setting defaults 43 defined 25
web servers
tasks 81
configuring 204 WorkSite MP
group 123 cluster address 257
host name 196 configuring for ECM Connector 254
plugins 195 connecting to 233
port number 196 ECM Connector properties 234
starting and stopping 195 external authentication 254
Web site
link to documents 243
defined 359
process manager password 255
development 23
trusted login 254
webserver_group 123 Write locking
Windows see also Optional Write locking, Mandatory
Event Viewer 69 Write locking
permissions and TeamSite 108
Task Manager 64
Windows groups 116 X
Windows network 118 XML
windows_groups_for_sharing 119 about 17
windows_groups_for_users 119 datacapture.cfg 179
Wordpad, saving documents as UTF-8 315 metadata-rules.cfg 176
workarea_security 114 regex_map language 295
workareas special characters 302
changing group ownership 122
creating 108 Y
defined 22, 359
locking files in 45 Y: drive (default TeamSite drive) 66
ownership changes 122
permissions 108
permissions on directory 114
read access 114
security 114
workflow
defined 359
jobs
defined 26
metadata capture 191
query events 217
tasks
defined 27
specifying files in 191
workflow CGI program 263
workflow events
ReportCenter 223
workflow log
locating 69