Windchill 7.0 Business Administrators Guide

Windchill Business Administrators Guide
Windchill 7.0 December 2003
Copyright 2003 Parametric Technology Corporation. All Rights Reserved. User and training documentation from Parametric Technology Corporation (PTC) is subject to the copyright laws of the United States and other countries and is provided under a license agreement that restricts copying, disclosure, and use of such documentation. PTC hereby grants to the licensed user the right to make copies in printed form of this documentation if provided on software media, but only for internal/personal use and in accordance with the license agreement under which the applicable software is licensed. Any copy made shall include the PTC copyright notice and any other proprietary notice provided by PTC. This documentation may not be disclosed, transferred, modified, or reduced to any form, including electronic media, or transmitted or made publicly available by any means without the prior written consent of PTC and no authorization is granted to make copies for such purposes. Information described herein is furnished for general information only, is subject to change without notice, and should not be construed as a warranty or commitment by PTC. PTC assumes no responsibility or liability for any errors or inaccuracies that may appear in this document. The software described in this document is provided under written license agreement, contains valuable trade secrets and proprietary information, and is protected by the copyright laws of the United States and other countries. It may not be copied or distributed in any form or medium, disclosed to third parties, or used in any manner not provided for in the software licenses agreement except with written prior approval from PTC. UNAUTHORIZED USE OF SOFTWARE OR ITS DOCUMENTATION CAN RESULT IN CIVIL DAMAGES AND CRIMINAL PROSECUTION. Registered Trademarks of Parametric Technology Corporation or a Subsidiary Advanced Surface Design, Behavioral Modeling, CADDS, Computervision, EPD, EPD.Connect, Expert Machinist, Flexible Engineering, HARNESSDESIGN, Info*Engine, InPart, MECHANICA, Optegra, Parametric Technology, Parametric Technology Corporation, PHOTORENDER, Pro/DESKTOP, Pro/E, Pro/ENGINEER, Pro/HELP, Pro/INTRALINK, Pro/MECHANICA, Pro/TOOLKIT, PTC, PT/Products, Shaping Innovation, and Windchill. Trademarks of Parametric Technology Corporation or a Subsidiary 3DPAINT, Associative Topology Bus, AutobuildZ, CDRS, CounterPart, Create Collaborate Control, CV, CVact, CVaec, CVdesign, CV-DORS, CVMAC, CVNC, CVToolmaker, DataDoctor, DesignSuite, DIMENSION III, DIVISION, e/ENGINEER, eNC Explorer, Expert MoldBase, Expert Toolmaker, GRANITE, ISSM, KDiP, Knowledge Discipline in Practice, Knowledge System Driver, ModelCHECK, MoldShop, NC Builder, PartSpeak, Pro/ANIMATE, Pro/ASSEMBLY, Pro/CABLING, Pro/CASTING, Pro/CDT, Pro/CMM, Pro/COLLABORATE, Pro/COMPOSITE, Pro/CONCEPT, Pro/CONVERT, Pro/DATA for PDGS, Pro/DESIGNER, Pro/DETAIL, Pro/DIAGRAM, Pro/DIEFACE, Pro/DRAW, Pro/ECAD, Pro/ENGINE, Pro/FEATURE, Pro/FEM-POST, Pro/FICIENCY, Pro/FLY-THROUGH, Pro/HARNESS, Pro/INTERFACE, Pro/LANGUAGE, Pro/LEGACY, Pro/LIBRARYACCESS, Pro/MESH, Pro/Model.View, Pro/MOLDESIGN, Pro/NC-ADVANCED, Pro/NC-CHECK, Pro/NC-MILL, Pro/NCPOST, Pro/NC-SHEETMETAL, Pro/NC-TURN, Pro/NC-WEDM, Pro/NC-Wire EDM, Pro/NETWORK ANIMATOR, Pro/NOTEBOOK, Pro/PDM, Pro/PHOTORENDER, Pro/PIPING, Pro/PLASTIC ADVISOR, Pro/PLOT, Pro/POWER DESIGN, Pro/PROCESS, Pro/REPORT, Pro/REVIEW, Pro/SCAN-TOOLS, Pro/SHEETMETAL, Pro/SURFACE, Pro/VERIFY, Pro/Web.Link, Pro/Web.Publish, Pro/WELDING, Product Development Means Business, Product First, ProductView, PTC Precision, Shrinkwrap, Simple Powerful Connected, The Product Development Company, The Way to Product First, Wildfire, Windchill DynamicDesignLink, Windchill PartsLink, Windchill PDMLink, Windchill ProjectLink, and Windchill SupplyLink. Third-Party Trademarks Adobe is a registered trademark of Adobe Systems. Advanced ClusterProven, ClusterProven, and the ClusterProven design are trademarks or registered trademarks of International Business Machines Corporation in the United States and other countries and are used under license. IBM Corporation does not warrant and is not responsible for the operation of this software product. AIX is a registered trademark of IBM Corporation. Allegro, Cadence, and Concept are registered trademarks of Cadence Design Systems, Inc. AutoCAD and
AutoDesk Inventor are registered trademarks of Autodesk, Inc. Baan is a registered trademark of Baan Company. CADAM and CATIA are registered trademarks of Dassault Systemes. COACH is a trademark of CADTRAIN, Inc. DOORS is a registered trademark of Telelogic AB. FLEXlm is a registered trademark of GLOBEtrotter Software, Inc. Geomagic is a registered trademark of Raindrop Geomagic, Inc. EVERSYNC, GROOVE, GROOVEFEST, GROOVE.NET, GROOVE NETWORKS, iGROOVE, PEERWARE, and the interlocking circles logo are trademarks of Groove Networks, Inc. Helix is a trademark of Microcadam, Inc. HOOPS is a trademark of Tech Soft America, Inc. HP-UX is a registered trademark and Tru64 is a trademark of the Hewlett-Packard Company. I-DEAS, Metaphase, Parasolid, SHERPA, Solid Edge, and Unigraphics are trademarks or registered trademarks of Electronic Data Systems Corporation (EDS). InstallShield is a registered trademark and service mark of InstallShield Software Corporation in the United States and/or other countries. Intel is a registered trademark of Intel Corporation. IRIX is a registered trademark of Silicon Graphics, Inc. MatrixOne is a trademark of MatrixOne, Inc. Mentor Graphics and Board Station are registered trademarks and 3D Design, AMPLE, and Design Manager are trademarks of Mentor Graphics Corporation. MEDUSA and STHENO are trademarks of CAD Schroer GmbH. Microsoft, Microsoft Project, Windows, the Windows logo, Windows NT, Visual Basic, and the Visual Basic logo are registered trademarks of Microsoft Corporation in the United States and/or other countries. Netscape and the Netscape N and Ship's Wheel logos are registered trademarks of Netscape Communications Corporation in the U.S. and other countries. Oracle is a registered trademark of Oracle Corporation. OrbixWeb is a registered trademark of IONA Technologies PLC. PDGS is a registered trademark of Ford Motor Company. RAND is a trademark of RAND Worldwide. Rational Rose is a registered trademark of Rational Software Corporation. RetrievalWare is a registered trademark of Convera Corporation. RosettaNet is a trademark and Partner Interface Process and PIP are registered trademarks of "RosettaNet," a nonprofit organization. SAP and R/3 are registered trademarks of SAP AG Germany. SolidWorks is a registered trademark of SolidWorks Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and in other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. Sun, Sun Microsystems, the Sun logo, Solaris, UltraSPARC, Java and all Java based marks, and "The Network is the Computer" are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. VisTools is a trademark of Visual Kinematics, Inc. (VKI). VisualCaf is a trademark of WebGain, Inc. WebEx is a trademark of WebEx Communications, Inc. Licensed Third-Party Technology Information Certain PTC software products contain licensed third-party technology: Rational Rose 2000E is copyrighted software of Rational Software Corporation. RetrievalWare is copyrighted software of Convera Corporation. VisualCaf is copyrighted software of WebGain, Inc. VisTools library is copyrighted software of Visual Kinematics, Inc. (VKI) containing confidential trade secret information belonging to VKI. HOOPS graphics system is a proprietary software product of, and is copyrighted by, Tech Soft America, Inc. G-POST is copyrighted software and a registered trademark of Intercim. VERICUT is copyrighted software and a registered trademark of CGTech. Pro/PLASTIC ADVISOR is powered by Moldflow technology. Moldflow is a registered trademark of Moldflow Corporation. The JPEG image output in the Pro/Web.Publish module is based in part on the work of the independent JPEG Group. DFORMD.DLL is copyrighted software from Compaq Computer Corporation and may not be distributed. METIS, developed by George Karypis and Vipin Kumar at the University of Minnesota, can be researched at http://www.cs.umn.edu/~karypis/metis. METIS is 1997 Regents of the University of Minnesota. LightWork Libraries are copyrighted by LightWork Design 1990-2001. Visual Basic for Applications and Internet Explorer is copyrighted software of Microsoft Corporation. Adobe Acrobat Reader is copyrighted software of Adobe Systems. Parasolid Electronic Data Systems (EDS). Windchill Info*Engine Server contains IBM XML Parser for Java Edition and the IBM Lotus XSL Edition. Pop-up calendar components Copyright 1998 Netscape Communications Corporation. All Rights Reserved. TECHNOMATIX is copyrighted software and contains proprietary information of Technomatix Technologies Ltd. Apache Server, Tomcat, Xalan, and Xerces are technologies developed by, and are copyrighted software of, the Apache Software Foundation (http://www.apache.org/) - their use is subject to the terms and limitations at: http://www.apache.org/LICENSE.txt. UnZip ( 1990-2001 Info-ZIP, All Rights Reserved) is provided "AS IS" and WITHOUT WARRANTY OF ANY KIND. For the complete Info-ZIP license see
ftp://ftp.info-zip.org/pub/infozip/license.html. Gecko and Mozilla components are subject to the Mozilla Public License Version 1.1 at http://www.mozilla.org/MPL/. Software distributed under the MPL is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the MPL for the specific language governing rights and limitations. Technology "Powered by Groove" is provided by Groove Networks, Inc. Technology "Powered by WebEx" is provided by WebEx Communications, Inc. Acrobat Reader is Copyright 1998 Adobe Systems Inc. Oracle 8i run-time, Copyright 2000 Oracle Corporation. The Java Telnet Applet (StatusPeer.java, TelnetIO.java, TelnetWrapper.java, TimedOutException.java), Copyright 1996, 97 Mattias L. Jugel, Marcus Meiner, is redistributed under the GNU General Public License. This license is from the original copyright holder and the Applet is provided WITHOUT WARRANTY OF ANY KIND. You may obtain a copy of the source code for the Applet at http://www.mud.de/se/jta (for a charge of no more than the cost of physically performing the source distribution), by sending e-mail to [email protected] or [email protected] are allowed to choose either distribution method. The source code is likewise provided under the GNU General Public License. GTK+The GIMP Toolkit are licensed under the GNU LPGL. You may obtain a copy of the source code at http://www.gtk.org/, which is likewise provided under the GNU LPGL. zlib software Copyright 1995-2002 Jean-loup Gailly and Mark Adler. UNITED STATES GOVERNMENT RESTRICTED RIGHTS LEGEND This document and the software described herein are Commercial Computer Documentation and Software, pursuant to FAR 12.212(a)-(b) (OCT'95) or DFARS 227.7202-1(a) and 227.7202-3(a) (JUN'95), is provided to the US Government under a limited commercial license only. For procurements predating the above clauses, use, duplication, or disclosure by the Government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 (OCT'88) or Commercial Computer Software-Restricted Rights at FAR 52.227-19(c)(1)-(2) (JUN'87), as applicable. 040103 Parametric Technology Corporation, 140 Kendrick Street, Needham, MA 02494 USA
Contents
Change Record .................................................................................................... xv About This Guide................................................................................................ xix

Intended Audience...................................................................................................................... xix Overview..................................................................................................................................... xix Chapter Contents ........................................................................................................................ xx Related Documentation .............................................................................................................. xxi Technical Support....................................................................................................................... xxi Documentation for PTC Products...............................................................................................xxii Comments ..................................................................................................................................xxii Documentation Conventions .....................................................................................................xxiii
Getting Started.................................................................................................... 1-1

Introduction.................................................................................................................................1-2 Logging On as the Administrator ................................................................................................1-2 Windchill PDM Home Page ................................................................................................. 1-3 Windchill PDMLink Home Page ........................................................................................... 1-4 Windchill ProjectLink Home Page........................................................................................ 1-5 Creating the Default Organization Container..............................................................................1-6 Establishing Administrators ......................................................................................................1-10 Windchill PDM Administrators ........................................................................................... 1-10 Windchill PDMLink Administrators ..................................................................................... 1-11 Windchill ProjectLink Administrators.................................................................................. 1-12 Creating Users to Select as Administrators ....................................................................... 1-13 The Next Steps.........................................................................................................................1-13
Administration Overview ................................................................................... 2-1

Your Installed Windchill Runtime Architecture............................................................................2-2 Managing Your Windchill System...............................................................................................2-3 Your Installed Windchill Environment .........................................................................................2-3
Managing User Access to Data ................................................................................................. 2-6 Windchill PDMLink Container Hierarchy ............................................................................. 2-7 Windchill ProjectLink Container Hierarchy .......................................................................... 2-7 Container Hierarchy for Co-installed Windchill Solutions .................................................... 2-8 Managing Access to Data through Access Control Rules................................................... 2-8 Managing Access to Data through Team Memberships ................................................... 2-14 Managing Users ....................................................................................................................... 2-14 Managing Data......................................................................................................................... 2-16 Data Types ........................................................................................................................ 2-17 Soft Types ......................................................................................................................... 2-17 Visualization Data.............................................................................................................. 2-18 CAD Data .......................................................................................................................... 2-18 Document Data ................................................................................................................. 2-18 Part Data ........................................................................................................................... 2-18 Audit Reports..................................................................................................................... 2-19 Managing Windchill Processes ................................................................................................ 2-19 Managing User Collaboration .................................................................................................. 2-19 Additional Administrative Groups ............................................................................................. 2-20 Post-Installation Activities ........................................................................................................ 2-21 About the windchill Command ................................................................................................. 2-22 About the windchill shell........................................................................................................... 2-24 About the xconfmanager Utility ................................................................................................ 2-25 Formatting Property Value Guidelines .............................................................................. 2-26
Administering Containers .................................................................................. 3-1

Distributed and Hierarchical Administration ............................................................................... 3-2 Container Administrative Items .................................................................................................. 3-4 Container Configuration ...................................................................................................... 3-4 Container Structure ............................................................................................................. 3-6 Container Participation ........................................................................................................ 3-8 Container Policies ............................................................................................................. 3-10 Container Data Types and Attributes ................................................................................ 3-13 Container Templates ......................................................................................................... 3-14 Container Object Initialization Rules ................................................................................. 3-18 Creating Containers ................................................................................................................. 3-19 Using Out-of-the-box Translated Context Templates........................................................ 3-20 Creating Context Templates.............................................................................................. 3-22
vi
Administering Domains and Policies ........................................................................................3-24 Container and Domain Hierarchy Overview ...................................................................... 3-24 Domains in the Site Container ........................................................................................... 3-26 Creating Domains .............................................................................................................. 3-27 Defining Domain-based Policies ........................................................................................ 3-28 Using the Policy Administrator ........................................................................................... 3-28 Specifying Policy Rules in a Context Template ................................................................. 3-31 Administering Object Initialization Rules ..................................................................................3-32 Loading Object Initialization Rules..................................................................................... 3-32 Adding Object Initialization Rules ...................................................................................... 3-32 Accessing the Object Initialization Rules Administrator ..................................................... 3-33 How Object Initialization Rules Work ................................................................................. 3-33 Determining the Composite Rule ....................................................................................... 3-34 Specifying Rules in the Object Initialization Rules Administrator....................................... 3-35 Content of Object Initialization Rules XML Documents ..................................................... 3-36 Example XML Document ................................................................................................... 3-38 Specifying Object Initialization Rules in a Context Template............................................. 3-38 Searching for Principals............................................................................................................3-39
Administering the Site ....................................................................................... 4-1

Overview.....................................................................................................................................4-2 Typical Duties of Site Administrators..........................................................................................4-2 Creating and Managing Organizations ................................................................................ 4-3 Adding and Updating Members ........................................................................................... 4-4 Creating and Managing Site Folders and Documents ......................................................... 4-4 Managing Site-level Types and Type-specific Attributes ..................................................... 4-5 Managing Site-level Templates ........................................................................................... 4-5 Auditing System Information ................................................................................................ 4-5 Creating and Managing Access Control Policies ................................................................. 4-6 Configuring External Vaults or Replication Sites to Optimize Performance......................... 4-6 Configuring Numbering and Versioning Schemes and Units of Measure............................ 4-7 Configuring and Managing CAD Publishing Utilities ............................................................ 4-7 Creating, Updating, and Managing Custom Reports ........................................................... 4-7 Importing and Exporting Information Among Systems ........................................................ 4-7 Managing Overall System Configuration and Preferences .................................................. 4-7 Monitoring Enterprise Systems Transactions Log ............................................................... 4-8 Out-of-the-Box Site Container Configuration..............................................................................4-8 About the Site Tab......................................................................................................................4-8 Best Practices for Windchill PDMLink and Windchill ProjectLink ...............................................4-9 Setting Default Preferences in Windchill ProjectLink to Collapse Tables ............................ 4-9
Contents
vii
Administering Organizations............................................................................. 5-1

Overview .................................................................................................................................... 5-2 Typical Duties of Organization Administrators ........................................................................... 5-3 Managing Organization Members, Groups, and Roles ....................................................... 5-3 Creating, Updating, and Managing Organization Folders and Documents ......................... 5-4 Managing Organization-level Types and Type-specific Attributes ...................................... 5-4 Managing Organization Templates and Object Creation Rules .......................................... 5-5 Auditing Activities Within the Organization.......................................................................... 5-5 Creating and Managing Access Control Policies ................................................................ 5-5 Configuring Numbering and Versioning Schemes .............................................................. 5-6 Monitoring and Managing Viewable Publishing................................................................... 5-6 Viewing Project Reports ...................................................................................................... 5-6 Importing and Exporting Information ................................................................................... 5-6 Out-of-the-Box Organization Templates .................................................................................... 5-7 Container Structure ............................................................................................................. 5-7 Container Participation ........................................................................................................ 5-8 Container Access Control Policies ...................................................................................... 5-8 Container Data .................................................................................................................. 5-12 Creating an Organization ......................................................................................................... 5-13 Using the Organization Utilities Page ...................................................................................... 5-15 Best Practices for Windchill PDMLink and Windchill ProjectLink............................................. 5-15 E-mail Addresses .............................................................................................................. 5-15 Creating Only One Organization Container for Windchill PDMLink .................................. 5-16 Setting Default Preferences in Windchill ProjectLink to Collapse Tables.......................... 5-16
Administering Products and Libraries.............................................................. 6-1

Overview .................................................................................................................................... 6-2 Typical Duties of Product and Library Administrators ................................................................ 6-2 Managing Team Members and Roles ................................................................................. 6-3 Managing Folders................................................................................................................ 6-3 Managing Templates........................................................................................................... 6-3 Managing Object Initialization Rules ................................................................................... 6-4 Managing Access Policies................................................................................................... 6-4 Configuring Numbering and Versioning Schemes .............................................................. 6-4 Managing Viewable Publishing ........................................................................................... 6-5 Managing Custom Reports.................................................................................................. 6-5 Importing and Exporting Information ................................................................................... 6-5 Configuring External Vaults or Replication Sites to Optimize Performance ........................ 6-5
viii
Out-of-the-box Product and Library Context Templates.............................................................6-6 Out-of-the-box Container Participation ................................................................................ 6-7 Out-of-the-box Container Access Control Policies .............................................................. 6-8 Creating a Product....................................................................................................................6-15 Creating a Library .....................................................................................................................6-17 Administering Teams................................................................................................................6-18 Using the Product and Library Utilities Page ............................................................................6-19
Administering Windchill PDM Library .............................................................. 7-1

Overview.....................................................................................................................................7-2 Typical Duties of Windchill PDM Administrators.........................................................................7-2 Managing Groups and Roles ............................................................................................... 7-3 Managing Templates ........................................................................................................... 7-3 Managing Object Initialization Rules.................................................................................... 7-3 Managing Access Policies ................................................................................................... 7-3 Configuring Numbering and Versioning Schemes ............................................................... 7-3 Managing Viewable Publishing ............................................................................................ 7-4 Managing Custom Reports .................................................................................................. 7-4 Importing and Exporting Information.................................................................................... 7-4 Configuring External Vaults or Replication Sites to Optimize Performance......................... 7-4 Out-of-the-box Windchill PDM Library Contents.........................................................................7-5 Creating Groups for Use in Site Domain Policies.......................................................................7-6 Improving Performance on Searches from Windchill Explorer ...................................................7-6
Administering Projects ...................................................................................... 8-1

Overview.....................................................................................................................................8-2 Typical Duties of Project Managers............................................................................................8-2 Creating and Updating Project Space ................................................................................. 8-2 Managing Project Team Members and Roles ..................................................................... 8-3 Creating, Updating, and Managing Documents and Folders ............................................... 8-3 Creating, Updating, and Managing Activities, Deliverables, Resources, and Action Items . 8-3 Managing Project Templates ............................................................................................... 8-4 Importing and Exporting Information.................................................................................... 8-4 Optional Utilities (Optional Access Through Project Utilities Link)....................................... 8-4 Out-of-the-box Project Templates ..............................................................................................8-6 Creating a Project.......................................................................................................................8-8
Contents
ix
Administering Principals....................................................................................9-1
Overview .................................................................................................................................... 9-2 Windchill Users.................................................................................................................... 9-2 Windchill Groups ................................................................................................................. 9-3 Windchill Organizations....................................................................................................... 9-3 Using the Principal Administrator ............................................................................................... 9-4 Best Practices for Windchill PDMLink and Windchill ProjectLink ........................................ 9-6 Best Practices When Maintaining a Directory Service Outside of Windchill ....................... 9-6 Understanding Principals ........................................................................................................... 9-7 Best Practices for Assigning Domains to Principals .................................................................. 9-7 Managing Users ......................................................................................................................... 9-8 Naming a User's Personal Cabinet ..................................................................................... 9-9 Deleting Users................................................................................................................... 9-10 Managing Groups .................................................................................................................... 9-12 Deleting Groups ................................................................................................................ 9-13 Managing Organizations .......................................................................................................... 9-14 Deleting Organizations ...................................................................................................... 9-15 Receiving Administrative Notifications ..................................................................................... 9-16 Managing the Principal Cache ................................................................................................. 9-17 Automatically Purging Entries from the Principal Cache ................................................... 9-17 Manually Purging Entries from the Principal Cache .......................................................... 9-18 Maintaining the Connections between Principal Objects and their Directory Service Entries . 9-18
Administering Access Control ........................................................................ 10-1

Overview .................................................................................................................................. 10-2 About Access Control Rules .................................................................................................... 10-2 Creating and Managing Access Control Rules ........................................................................ 10-3 Setting Permissions ................................................................................................................. 10-5 About Access Control Lists ...................................................................................................... 10-6 Deriving ACLs from Access Control Policies..................................................................... 10-7 How ACLs Work ................................................................................................................ 10-8 Distributed Administration of Policy Rules....................................................................... 10-11 About Predefined Access Control Policy Rules ..................................................................... 10-12
Managing Access to Enterprise Information...........................................................................10-13 Domain Administered Information ................................................................................... 10-14 Policy and Ad Hoc Access Controlled Information .......................................................... 10-14 Content Holder Information.............................................................................................. 10-14 Foldered Information........................................................................................................ 10-15 Life-Cycle Managed Information ...................................................................................... 10-19 Example Permissions Needed for Moving a Document .................................................. 10-20 Windchill PDM Example Permissions Needed for Creating a Part in a Shared Cabinet . 10-21 Access Control Strategies for Cabinets in Windchill PDM......................................................10-22 Access to Cabinets .......................................................................................................... 10-22 Access Control Strategies for Life-Cycle Managed Objects...................................................10-24 Combining Access Control Strategies for Cabinets and Life-Cycle Managed Objects ..........10-24
Using Types and the Type Manager ............................................................... 11-1

Overview of Types and the Runtime Typing Capability............................................................11-2 Effects of Deploying a New Type....................................................................................... 11-3 Using Typing in Conjunction with Classification ................................................................ 11-3 When to Use Typing and When to Use Modeling .............................................................. 11-5 Localization of New Type Definitions ................................................................................. 11-5 Migration of Existing Type Instances to a New Type Definition ......................................... 11-6 Defining Additional Attributes............................................................................................. 11-7 The Type Manager .................................................................................................................11-10 Starting the Type Manager .............................................................................................. 11-10 Using the Type Manager ................................................................................................. 11-11 Setting Constraints .......................................................................................................... 11-19 Best Practices for Windchill PDMLink and Windchill ProjectLink..................................... 11-22
Administering Indexing................................................................................... 12-1

Overview...................................................................................................................................12-2 About Indexing Rules ...............................................................................................................12-2 Creating and Managing Indexing Rules ...................................................................................12-3 About Indexing Policy ...............................................................................................................12-3 Considerations for Establishing Indexing Rules ................................................................ 12-4 About Indexing Lists .................................................................................................................12-4 Defining a Collection.................................................................................................................12-5
Administering Notifications............................................................................. 13-1

Overview...................................................................................................................................13-2 About Notification Rules ...........................................................................................................13-2 Creating and Managing Notification Rules ...............................................................................13-3 Notification Lists .......................................................................................................................13-4
Contents
xi
About Notification ..................................................................................................................... 13-5
Administering Life Cycles................................................................................ 14-1

Overview .................................................................................................................................. 14-2 The Windchill Life Cycle Model ................................................................................................ 14-2 Life Cycle Iteration ................................................................................................................... 14-3 Testing an Updated Life Cycle .......................................................................................... 14-4 Viewing Iteration History .......................................................................................................... 14-4 Creating a Life Cycle Template................................................................................................ 14-5 Life Cycle Properties ................................................................................................................ 14-6 Defining Life Cycle Phases ...................................................................................................... 14-8 Selecting Life Cycle Roles............................................................................................... 14-10 Defining Life Cycle Access Control Rules ....................................................................... 14-13 Associating a Workflow Process with Phases and Gates ............................................... 14-15 Defining Promotion Criteria ............................................................................................. 14-17 Predefined Life Cycle States.................................................................................................. 14-19 Import and Export .................................................................................................................. 14-19 Preparing to Import or Export Life Cycles ....................................................................... 14-19 Importing and Exporting Life Cycles................................................................................ 14-20 Access to Life Cycle Administration ....................................................................................... 14-21 Best Practices for Windchill PDMLink and Windchill ProjectLink........................................... 14-21
Administering Teams and Roles ..................................................................... 15-1

Overview .................................................................................................................................. 15-2 Out-of-the-Box Team Templates ............................................................................................. 15-3 Windchill PDMLink Out-of-the-Box Team Templates........................................................ 15-3 Windchill PDM Out-of-the-Box Team Templates .............................................................. 15-5 Team Templates and Object Types .................................................................................. 15-6 Team Roles Resolution............................................................................................................ 15-9 Initial Team Creation ......................................................................................................... 15-9 Role Resolution Rules....................................................................................................... 15-9 Role Resolution Example ................................................................................................ 15-12 Defining Team Properties and Roles ..................................................................................... 15-16 Predefined Roles ................................................................................................................... 15-18 Assigning Participants to Team Roles ................................................................................... 15-19 Best Practices for Windchill PDMLink and Windchill ProjectLink........................................... 15-20
Administering Workflow Processes................................................................ 16-1

Overview .................................................................................................................................. 16-2 Workflow Iteration .................................................................................................................... 16-3 Testing an Updated Workflow Process Template ............................................................. 16-3
xii
Using the Workflow Process Editor ..........................................................................................16-3 Working with Workflow Templates..................................................................................... 16-4 Navigating a Process Diagram .......................................................................................... 16-8 Placing Process Nodes...................................................................................................... 16-8 Declaring Variables.......................................................................................................... 16-11 Defining an Assigned Activity .......................................................................................... 16-13 Defining a Subprocess..................................................................................................... 16-22 Defining Connectors ........................................................................................................ 16-23 Defining Links .................................................................................................................. 16-24 Import and Export ...................................................................................................................16-26 Preparing to Import or Export Workflow Templates ......................................................... 16-26 Importing and Exporting Workflow Templates ................................................................. 16-28 Process Manager Toolbar Access Control .............................................................................16-29 Viewing Workflow History .......................................................................................................16-29 Selecting Events .............................................................................................................. 16-30 Using the Workflow History Viewer.................................................................................. 16-31 Configuring Worklist Fields.....................................................................................................16-35 Workflow Instance States .......................................................................................................16-37 Domain-based Workflows.......................................................................................................16-38 Default Workflow Templates...................................................................................................16-40 Windchill PDMLink Default Workflows ............................................................................. 16-40 Electronic Signatures..............................................................................................................16-42 Best Practices for Windchill PDMLink and Windchill ProjectLink ...........................................16-44
Administering Views and View Associations ............................................... 17-1

Overview...................................................................................................................................17-2 Views and View Associations ...................................................................................................17-2 Managing Views and View Associations ..................................................................................17-3 Examining a View Structure............................................................................................... 17-3 Creating a View ................................................................................................................. 17-3 Renaming a View............................................................................................................... 17-4 Creating a View Association .............................................................................................. 17-4 Inserting a View ................................................................................................................. 17-4
Administering Visualization Services............................................................. 18-1

Overview...................................................................................................................................18-2 File Types .......................................................................................................................... 18-2 Architecture ..............................................................................................................................18-3
Contents
xiii
Troubleshooting ....................................................................................................................... 18-6 Windchill Visualization Service Loader.............................................................................. 18-6 CAD Agent ........................................................................................................................ 18-9 Publishing CAD Documents ............................................................................................ 18-16 Visualization Collaboration .............................................................................................. 18-21 Exporting Watermarks for ProductView ................................................................................. 18-21 Windchill Visualization Service Properties ............................................................................. 18-22
Administering Audit Reports ........................................................................... 19-1

Overview .................................................................................................................................. 19-2 Enabling Auditing ..................................................................................................................... 19-2 Accessing Audit Reports .......................................................................................................... 19-2 Example Audit Report .............................................................................................................. 19-3
Index
xiv
Change Record
Table 1 Changes for Windchill 7.0

Change Description
Chapter 1, Getting Started
This new chapter provides a road map for getting your Windchill solution set up to be usable as a test system and provides some basic information about your Windchill environment. This new chapter provides a general overview of your installed Windchill runtime architecture and Windchill environment. It also introduces you to the main Windchill administration areas and gives some basic information about how to manage your Windchill solution. This new chapter provides the overall details relating to working with containers. This chapter includes information that previously existed in Understanding Domains and Policies (chapter 1 in the previous Windchill Business Administrators Guide). This new chapter provides an overview for administering sites and describes the typical duties that a site administrator performs. The new chapter provides an overview for administering organizations and describes the typical duties that an organization administrator performs.
Chapter 2, Administration Overview
Chapter 3, Administering Containers
Chapter 4, Administering the Site
Chapter 5, Administering Organizations
xv
Change
Description
Chapter 6, Administering Products and Libraries
This new chapter provides an overview for administering products and libraries in Windchill PDMLink and describes the typical duties that an adminisrator performs in the product and library contexts. This new chapter provides an overview for administering product and libraries in Windchill PDM and describes the typical duties that an administrator performs. It also provides additional information about some of the main administrative tasks for the Windchill PDM library container. This new chapter provides an overview for administering projects in Windchill ProjectLink and describes the typical duties that an administrator performs in the project context. This chapter includes information that previously existed in Administering Users and Groups (chapter 2 in the previous Windchill Business Administrators Guide). The chapter documents the new user interface for the Principal Administrator and has been updated to incorporate organization as a new principal type.
Chapter 7, Administering Windchill PDM Library
Chapter 8, Administering Projects
Chapter 9, Administering Principals
xvi
Change
Description
Chapter 10, Administering Access Control
This chapter includes information that previously existed in Administering Access Control (chapter 5 in the previous Windchill Business Administrators Guide). The chapter has been updated to include the following: use of the Secured information feature new Change Permissions permission use of out-of-the-box policy rules reorganization and update to Windchill 7.0.
Chapter 11, Using Types and the Type Manager
This chapter includes information that previously existed in Using Types and the Type Manager (chapter 3 in the previous Windchill Business Administrators Guide). The chapter has been updated to reflect Windchill 7.0. This chapter includes information that previously existed in Administering Indexing (chapter 6 in the previous Windchill Business Administrators Guide). The chapter has been updated to incorporate organization as a new principal type. This chapter includes information that previously existed in Administering Notifications (chapter 4 in the previous Windchill Business Administrators Guide). The chapter has been updated to incorporate organization as a principal type.
Chapter 12, Administering Indexing
Chapter 13, Administering Notifications
Change Record
xvii
Change
Description
Chapter 14, Administering Life Cycles
This chapter includes information that previously existed in Administering Life Cycles (chapter 8 in the previous Windchill Business Administrators Guide). The chapter has been updated to reflect Windchill 7.0. This chapter includes information that previously existed in Administering Teams and Roles (chapter 7 in the previous Windchill Business Administrators Guide). The chapter has been updated to reflect Windchill 7.0. This chapter includes information that previously existed in Administering Workflow Processes (chapter 9 in the previous Windchill Business Administrators Guide). The chapter has been updated to reflect Windchill 7.0 This chapter was previously chapter 10 in the Windchill Business Administrators Guide. This chapter includes information that previously existed in Administering Visualization Services (chapter 11 in the previous Windchill Business Administrators Guide). The chapter has been updated to reflect Windchill 7.0 and includes information how to export watermarks to ProductView. This new chapter provides information on how to enable and use the audit reporting feature.
Chapter 15, Administering Teams and Roles
Chapter 16, Administering Workflow Processes
Chapter 17, Administering Views and View Associations Chapter 18, Administering Visualization Services
Chapter 19, Administering Audit Reports
xviii
About This Guide
Intended Audience
The Windchill Business Administrators Guide serves as a reference guide for Windchill business and application administrators. The following table illustrates the responsibilities and skills of each type of administrator:
Business Administrator Applications Administrator
Responsibilities
Use Windchill to achieve specific business goals, such as setting up workflows and entering users, user groups, ACLs, and so on. Understand the Windchill client and the business needs of enterprise users.
Use Windchill applications to achieve goals appropriate for the application.
Skills
Understand the needs of particular application-user communities.
System administrators, who are responsible for keeping the system running, should refer to the Windchill System Administrators Guide.
Overview
The Windchill Business Administrators Guide describes responsibilities and roles of Windchill business and application administrators, providing conceptual and background information to help them understand the nature of administrative tasks.
xix
Chapter Contents
The Windchill Business Administrators Guide is composed of the following chapters and appendixes: Chapter 1, Getting Started, provides a road map for getting your Windchill solution set up to be usable as a test system and provides some basic information about your Windchill environment. Chapter 2, Administration Overview, provides a general overview of your installed Windchill runtime architecture and Windchill environment. Chapter 3, Administering Containers, provides the overall details relating to working with containers. Chapter 4, Administering the Site, provides an overview for administering sites and describes the typical duties that a site administrator performs. Chapter 5, Administering Organizations, provides an overview for administering organizations and describes the typical duties that an organization administrator performs. Chapter 6, Administering Containers, provides the overall details relating to working with containers. Chapter 7, Administering Windchill PDM LIbrary, provides an overview for administering product and libraries in Windchill PDM and describes the typical duties that an administrator performs. Chapter 8, Administering Projects, provides an overview for administering projects in Windchill ProjectLink and describes the typical duties that an administrator performs in the project context. Chapter 9, Administering Principals, describes the principals (user, group, and organization objects) that are used in your Windchill solution. It also provides details about managing the principals. Chapter 10, Administering Access Control, describes access control policies, consisting of rules that govern access to objects. It includes the Windchill model for storage of enterprise information and strategies for creating access rules that best serve your site's security needs. Chapter 11, Using Types and the Type Manager, describes the definition of subtypes, attributes, and constraints. Chapter 12, Administering Indexing, describes indexing policies and specifies the indexes into which an object is to be entered when a specified event occurs, and it describes how to define and bulk-load index collections when setting up a new site or upgrading to a new release. Chapter 13, Administering Notifications, describes notification policies, which determine users and groups to be notified when specific events are applied to an object.
xx
Chapter 14, Administering Life Cycles, describes life cycles, which define how an object matures and provides models for product commercialization. Chapter 15, Administering Teams and Roles, describes the definition of teams and the mapping of team roles to principals. Chapter 16, Administering Workflow Processes, describes workflow processes, which enable an organization to automate procedures in which information, tasks, and documents are passed among participants. Chapter 17, Administering Views and View Associations, describes view setups and view associations for your Windchill system. Chapter 18, Administering Visualization Services, describes the configuration and troubleshooting of the visualization service. Chapter 19, Administering Audit Reports, provides information on how to enable and use the audit reporting feature.
Related Documentation
The following documentation may also be helpful: Windchill System Administrators Guide Windchill Installation and Configuration Guide Windchill User's Guide Windchill Application Developer's Guide Windchill Customizer's Guide Windchill Object Adapter Reference Manual Windchill Performance Tuning Guide properties.html file
If books are not installed on your system, see your system administrator for the Windchill Documentation CD.
Technical Support
Contact PTC Technical Support via the PTC Web site, phone, fax, or e-mail if you encounter problems using Windchill. For complete details, refer to Contacting Technical Support in the PTC Customer Service Guide enclosed with your shipment. This guide can also be found under the Support Bulletins section of the PTC Web site at: http://www.ptc.com/support/index.htm
About This Guide
xxi
The PTC Web site also provides a search facility that allows you to locate Technical Support technical documentation of particular interest. To access this page, use the following link: http://www.ptc.com/support/support.htm You must have a Service Contract Number (SCN) before you can receive technical support. If you do not have an SCN, contact PTC License Management using the instructions found in your PTC Customer Service Guide under Contacting License Management.
Documentation for PTC Products

PTC provides documentation in the following forms: Help topics HTML books PDF books
All books are available in HTML and PDF formats, or both, on product CDs. To view HTML books, use your Internet browser. To view and print PDF books, you must have the Adobe Acrobat Reader installed. All Windchill documentation is included on the CD for the application. In addition, books updated after release (for example, to support a hardware platform certification) are available from the Reference Documents section of the PTC Web site, at the following URL: http://www.ptc.com/cs/doc/reference
Comments
PTC welcomes your suggestions and comments on its documentation. You can send comments to the following address: [email protected] Please include the name of the application and its release number with your comments. For online books, provide the book title.
xxii
Documentation Conventions
Windchill documentation uses the following conventions:
Convention Item Example
Bold
Names of elements in the user interface, such as buttons, and menu paths. Required elements and keywords or characters in syntax formats.
Click OK. Select File > Save. create_<tablename>.sql create_<tablename>.sql
Italic
Variable and user-defined elements in syntax formats. Angle brackets (< and >) enclose individual elements. Examples Messages The CAUTION symbol indicates potentially unsafe situations which may result in minor injury, machine damage or downtime, or corruption or loss of software or data.
Monospace
JavaGen "wt.doc.*" F true Processing completed.
When you add a value to an enumerated type (for example, by adding a role in the RolesRB.java resource file), removing that value can result in a serious runtime error. Do not remove a role unless you are certain there is no reference to it within the system.
About This Guide
xxiii
xxiv
1
Getting Started
This chapter provides a road map for getting your Windchill solution set up so that it is usable as a test system. The chapter also provides some basic information about Windchill administrators and your Windchill environment. Topic Page
Introduction .........................................................................................................1-2 Logging On as the Administrator........................................................................1-2 Creating the Default Organization Container......................................................1-6 Establishing Administrators ..............................................................................1-10 The Next Steps ..................................................................................................1-13
1-1
Introduction
This guide provides business administration information for the following Windchill solutions: Windchill PDM Windchill PDMLink Windchill ProjectLink After a Windchill solution installation is complete, the following basic activities have been accomplished: A Web server and servlet engine are installed and configured The Oracle database is installed and configured Any enterprise directory services that are going to be used are configured The Windchill solution is installed and has been started
If you want more information about these activities, see the Windchill Installation and Configuration Guide. Before you can get started with administrative activities in your Windchill solution, you must log on as the Administrator (defined during the installation). Additionally for Windchill PDMLink and Windchill ProjectLink, you must create a container for the installed default organization and establish additional administrators. The next sections in this chapter describe how to log on, create an organization container, and establish administrators. The last section provides a guide to which additional chapters you may want to read next, based on the types of administrators.
Logging On as the Administrator

You can access your Windchill solution using a URL from a Web browser. Note: The server manager and method server must be running (as well as the Web server and servlet engine) before Windchill can be accessed. The URL string is formatted as follows:
http://<hostname>:<port>/<webapp>
The required parameters were defined when Windchill Info*Engine was installed. You only need to include the port number when Windchill is using a port number other than 80 (default). If Windchill is using the default port, then you can enter http://<hostname>/<webapp> in your Web browser Address (or Location) text box. For example, if you specified Windchill for the <webapp> parameter, then
1-2
the following URL entered in the Web browser Address text box will open the Windchill home page:
http://<hostname>/Windchill
Tip: If you are logging on using the same system where your solution is installed, you can use localhost as <hostname>. Use the administrative user defined during the installation to log on. This user is a member of the Administrators group and has out-of-the box privileges that give you full control over all Windchill objects. The home page that appears is unique to your Windchill solution. The following sections describe each home page.
Windchill PDM Home Page

The Windchill PDM home page that appears is similar to the following:
The first time you access the Windchill home page, you can select one of the links listed under Available Homes to make that page your personal home page. Common home pages for the administrator are the Business Administration and System Administration home pages. The next time you access Windchill, it will open to that page. If, at any time, you want to change your personal home page, click Options or Site Map, and then click the link to the page you want as your new personal home page.
Getting Started
1-3
Windchill PDMLink Home Page

The Windchill PDMLink home page that appears is similar to the following:
The tabs at the top of the window identify the major areas provided in Windchill PDMLink: From the Home tab, users manage their daily work. From the Product tab, users have access to all products to which they are a member. For each product, team members manage all of the information that is relevant to the design, manufacture, and support of a product. When only base data is installed, there are no out-of-the-box products. From the Library tab, users have access to all libraries to which they are a member. In a library, team members can store and provide access to business information (such as a document library) or can store and provide access to objects that are not related to a single product (such as a common parts library). There are no out-of-the-box libraries.
1-4
From the Site tab, site administrators configure and manage the Windchill system as a whole. This tab is only visible to site administrators and is the tab from which the initial administration activities, such as creating the organization container, are done.
Note: An Organization tab appears after you create an organization container. Creating this container is described in the next section, Creating the Default Organization Container.
Windchill ProjectLink Home Page

The Windchill ProjectLink home page that appears is similar to the following:
The tabs at the top of the window identify the major areas provided in Windchill ProjectLink: From the Home tab, users manage their daily work. From the Project tab, users have access to all projects to which they are a member. For each project, team members have access to the project
Getting Started
1-5
information, the project schedule, resources, and plan details. There are no out-of-the-box projects. From the Site tab, site administrators configure and manage the Windchill system as a whole. This tab is only visible to site administrators and is the tab from which the initial administration activities, such as creating the organization container, are done.
Note: An Organization tab appears after you create an organization container (as described in the next section).
Creating the Default Organization Container

Your Windchill environment consists of a set of containers that hold all of the administrative areas (known as domains), rules, and data that make up the context from which Windchill users work. The containers are set up in a hierarchy so that the rules and data created in one container can be available to child containers and the domains in one container can have child domains in a child container. The child domains inherit information from ancestor domains. Initially, every Windchill solution has an installed top-level Site container. In Windchill PDMLink and Windchill ProjectLink, Site container activities are performed from the Site tab. In Windchill PDM, Site container activities are performed from the System Administration page. Additionally for Windchill PDM, the installation creates an organization container which is named during the installation process. Note: In Windchill PDMLink and Windchill ProjectLink, the base data installation does not create an organization container; you create the organization container as described later in this section.
1-6
The organization container is a child of the Site container. For Windchill PDM, the container name is the organization name that was entered during the installation. For Windchill PDMLink and Windchill ProjectLink, you enter the organization name when you create the container. For example, assume that the organization name is Org1, then the following container hierarchy is established:
Site
Org1
In this example, the Org1 organization container inherits rules and data from the Site container. In Windchill PDMLink and Windchill ProjectLink, you must create a default organization container and set up other administrators before other users can perform activities in the Windchill solution. Note: With Windchill PDMLink, the installer can install the golf cart demo data. As part of the golf cart installation, the Demo organization container is created and the Demo user is created as the organization administrator. As is the case for all organization containers, the Demo organization container inherits rules and data from the Site container. To create the default organization container, complete the following steps: 1. Log on as the site administrator as described in Logging On as the Administrator. 2. Navigate to the Site tab and click Create Organization .
Getting Started
1-7
The following Create Organization window opens:
For detailed information on these fields, see the help available from the window. 3. For the Organization Name, click Search. The search results contains the name of the default organization created during the installation. 4. Select the name of the default organization and click OK. 5. Enter information in the Description, Postal Address, and Web Site fields.
1-8
6. Select a template from the Template drop-down list as follows: For Windchill PDMLink, select General (PDMLink). For Windchill ProjectLink, select General unless you are creating an enterprise, supplier, or customer organization container.
7. Select the check boxes that correspond to the organization options you want as follows: By default, the Subscriber check box is selected. This means the organization can host products and libraries (for Windchill PDMLink standalone), projects (for Windchill ProjectLink standalone), or all three for Windchill PDMLink and Windchill ProjectLink sites. For Windchill ProjectLink, the Automatically add new members to project creators group check box shows on the window (not shown in this figure) and is selected by default. Keep this selection for Windchill ProjectLink. By default, you are restricted to seeing only users and groups that belong to the organization. Select Allow entire user and group directory selection to provide the ability to search for all users. Windchill PDMLink recommends you select this check box.
8. For Meeting Center access, set the conferencing ID and URL in the corresponding fields. Additional set up is required after the container is created and is described in the Windchill System Administrators Guide. 9. Click OK to create the default organization container. The Windchill solution updates to include the Organization tab. Note: Next, you must set the organization administrator for the container. How to do this is described in the next section: For Windchill PDMLink, see Windchill PDMLink Administrators. For Windchill ProjectLink, see Windchill ProjectLink Administrators.
For additional information about organization containers, see Administering Organizations.
Getting Started
1-9
Establishing Administrators
Before you attempt to use your Windchill solution, you should establish a minimum set of administrators for the solution. The types of administrators that are available are determined by the Windchill solutions that are installed. Every installed Windchill solution defines the Administrators group of which, by default, the administrative user entered during the installation (for example, wcadmin) is initially the only member. Out of the box, the members of the Administrators group have full control over all Windchill objects and are commonly called the system or site administrators. The Windchill PDMLink and Windchill ProjectLink solutions provide additional types of administrators: An organization administrator manages a specific organization. A product manager manages a specific product (Windchill PDMLink only). A library manager manages a specific library (Windchill PDMLink only). A project manager manages a specific project (Windchill ProjectLink only).
The following sections provide additional information about the administrators in each Windchill solution and describe how to set the administrators.
Windchill PDM Administrators

In Windchill PDM, the site administrator (as defined by the Administrators group) is the main administrator. This group of users can access all of the links that are on the Business Administration and System Administration pages. The site administrator is also known as the system administrator. The site administrator is the only administrator initially needed for administering Windchill PDM. If you want other users to be able to administer specific areas in Windchill PDM, you add those users to the administrative groups that are created. For additional information, see Additional Administrative Groups in the Administration Overview chapter.
1-10
Windchill PDMLink Administrators

In Windchill PDMLink, the site administrator (as defined by the Administrators group) can use the links that are on the Site and Organization tabs. The site administrator is also known as the system administrator. Clicking the Administrators link on the Site tab displays the Site Administrators table. From this table, you can add users to the Administrators group. Additional Windchill PDMLink administrators include the following: An organization administrator for managing a specific organization. Initially, there is no organization administrator defined for an organization container. After you create the default organization container, click the Administrators link on the Organization tab to add one or more users as organization administrators to the default organization. For additional information, see Creating Users to Select as Administrators. A product manager for managing a specific product. Initially, the product manager is the user who creates the product. Additional users can be added to the Product Manager role from the Team page of the product. A library manager for managing a specific library. Initially, the library manager is the user who creates the library. Additional users can be added to the Library Manager role from the Team page of the library.
Creating a Product or Library

To create a product or library, a user must be one of the following: The site administrator, but only if the administrator is a member of the organization. The site administrator can become a member of the organization by setting in the organization attribute ("o", by default) for Administrator user in the directory service user entry. The organization administrator. A member of the product creators group or the library creators group. These groups are maintained through the Creators link on the Organization tab. From the Organization tab, click the Creators link and then chose the type of creator from the Current View drop-down list on the Creators table.
Getting Started
1-11
Windchill ProjectLink Administrators

In Windchill ProjectLink, the site administrator (as defined by the Administrators group) can use the links that are on the Site and Organization tabs.The site administrator is also known as the system administrator. Clicking the Administrators link on the Site tab displays the Site Administrators table. From this table, you can add users to the Administrators group. Additional Windchill ProjectLink administrators include the following: An organization administrator for managing a specific organization. Initially, there is no organization administrator defined for an organization container. After you create an organization, click the Administrators link from the Organization tab to add one or more users as organization administrators to the current organization. For additional information, see Creating Users to Select as Administrators. A project manager for managing a specific project. Initially, the project manager is the user who creates the project. Additional users can be added to the Project Manager role from the Team page of the project.
Creating a Project
To create a project, a user must be one of the following: The site administrator, but only if the administrator is a member of the organization. The site administrator can become a member of the organization by setting in the organization attribute ("o", by default) for Administrator user in the directory service user entry. The organization administrator. A member of the project creators group. Depending on the setup options selected when an organization is created, all members of the organization who have logged in may be automatically added to the project creators group. Additionally, both the system administrator and the organization administrator of the current organization can add users to the project creators group. From the Organization tab, click the Creators link. From the Project Creators table that appears, you can add users.
1-12
Creating Users to Select as Administrators

Note: Only members of an organization can be organization administrators, product creators, library creators, or project creators. In a production environment, users are usually defined in an enterprise directory that is set up during installation. If you are setting up a test system and do not have a set of users from which to select administrators, you can create a set of test users in the default directory service using the Principal Administrator. In Windchill PDMLink and Windchill ProjectLink, the Principal Administrator is available from the Site tab. Click the Utilities link and then click the Principal Administrator link to open the Principal Administrator. In Windchill PDM, the link is on the Business Administration home page. The Administrator user that is created during the installation (for example, wcadmin) is not associated to a specific organization; this user does not have the organization attribute (usually "o") set. Therefore, this user cannot be added as an organization administrator unless Administrator is updated to include the organization attribute. You can use the Principal Administrator to update the Administrator user. At a minimum, you need to either update the Administrator user so the user is a member of the default organization or create another user who can be the organization administrator. This user can then administer the organization and create products, libraries, and projects.
The Next Steps

After your administrators are established, individual administrators can log on and perform their administrative duties. For example, they can create products, libraries and projects. To understand what those duties might entail, refer to the following table:
Type of Administrator Recommended Chapters to Read
Site administrator for Windchill PDMLink and Windchill ProjectLink
Administration Overview - for general information Administering Containers - for major container concepts Administering the Site - for details using on the Windchill PDMLink and Windchill ProjectLink Site tab Administration Overview - for general information Administering Containers - for major container concepts Administering Windchill PDM Library - for the duties surrounding administering Windchill PDM
Site administrator for Windchill PDM
Getting Started
1-13
Type of Administrator
Recommended Chapters to Read
Organization administrator
Administration Overview - for general information Administering Containers - for major container concepts Administering Organizations - for details on using the Windchill PDMLink and Windchill ProjectLink Organization tab and creating organization containers
Product manager Library manager Project manager
Administering Products and Libraries - for details on administering Windchill PDMLink products Administering Products and Libraries - for details on administering Windchill PDMLink libraries Administering Projects - for details on administering Windchill ProjectLink projects
1-14
2
Administration Overview
This chapter provides a general overview of your installed Windchill runtime architecture and Windchill environment. It also introduces you to the main Windchill administration areas and gives some basic information about how to manage your Windchill solution. Topic Page
Your Installed Windchill Runtime Architecture .................................................2-2 Managing Your Windchill System......................................................................2-3 Your Installed Windchill Environment ...............................................................2-3 Managing User Access to Data ...........................................................................2-6 Managing Users.................................................................................................2-14 Managing Data ..................................................................................................2-16 Managing Windchill Processes .........................................................................2-19 Managing User Collaboration ...........................................................................2-19 Additional Administrative Groups ....................................................................2-20 Post-Installation Activities ................................................................................2-21 About the windchill Command .........................................................................2-22 About the windchill shell ..................................................................................2-24 About the xconfmanager Utility........................................................................2-25
2-1
Your Installed Windchill Runtime Architecture

After a base Windchill solution is installed, the Windchill runtime architecture consists of the following: Client applications that allow users access to Windchill. The clients can include the Windchill client pages, the visualization clients, and the Pro/ENGINEER Wildfire client. A Web sever that includes a servlet engine, Windchill Info*Engine Web services, and security modules. The Windchill server that includes the Windchill solutions and common business services. Data storage that includes the Aphelion LDAP directory service and an Oracle database. Possibly, connections to other enterprise systems such as an enterprise directory service, ERP, CRM, SCM, or other PDM systems.
For details about what is installed, see the Windchill Installation and Configuration Guide.
2-2
Managing Your Windchill System

The Windchill System Administrators Guide describes how to perform system operations that change and improve the out-of-the-box system that is installed. The following topics are covered in the Windchill System Administrators Guide: Runtime Services, including starting and stopping Windchill, defining user preferences, using the xconfmanager utility, setting up Meeting Center, setting up internal organizations. The Bootstrap Client External File Vaults Content Replication Windchill Import and Export Background Queues Pro/ENGINEER Wildfire Customizing Online Help
Your Installed Windchill Environment

Your installed Windchill environment consists of a set of containers that hold all of the administrative areas (known as domains), rules, and data that make up the context from which Windchill users work. The containers are set up in a hierarchy so that the rules and data created in one container can be available to child containers and the domains in one container can have child domains in a child container. The child domains inherit information from ancestor domains. Every Windchill solution has an installed top-level Site container. Additionally for Windchill PDM, the installation creates an organization container which is named during the installation process. This container is a child of the Site container. The container name is the organization name that was entered during the installation. For example, assume that the organization name entered during the installation is Org1, then the following containers are created in Windchill PDM:
Site
Org1
2-3
In this example, the Org1 organization container inherits rules and data from the Site container. Note: In Windchill PDMLink and Windchill ProjectLink, the base data installation does not create an organization; you create the organization container after the installation is complete, as described in Creating the Default Organization Container. Regardless of how organization containers are created, all organization containers are children of the Site container, and they inherit rules and data from the Site container. With Windchill PDMLink, the installer can install the golf cart demo data. As part of the golf cart installation, the Demo organization container is created. As is the case for all organization containers, the Demo organization container inherits rules and data from the Site container. Within the installed containers, a set of domains are loaded during the installation process. For example, the Windchill PDM Site and Org1 containers have the domains shown in following diagram:
Site / User Default System SessionIterationDomain
Unaffiliated Org1 Org1 Private
Default
System
Project
PDM
In the diagram, the dashed line shows the container boundaries and the domain inheritance is shown by the lines connecting the domains. The top-level domain is labeled / (root) and is in the Site container. The shaded domains are the domains associated with Windchill principals (users, groups, and organizations). The Windchill PDM installation also creates a third container, called the Windchill PDM library container, which is the one and only application container
2-4
in Windchill PDM and is a child of the organization container. For example, the following diagram shows the Site, Org1, and Windchill PDM containers:
Site Org1
Windchill PDM
The only additional domain loaded during the Windchill PDM installation, is the ChangeItems domain. It inherits from the / (root) domain in the Site container. In Windchill PDM, the administrator cannot create additional containers. After containers are created and users become team members, the framework established is called the context from which the users work. In many instances, the context includes the contents of a specific container and the domains, rules and data available from ancestor containers. For example, if a user entering Windchill ProjectLink navigates to a folder within the Bike Design project and creates a new document, that document is managed in the context of the Bike Design project. Persons with access to the Bike Design project may automatically have the right to see and modify the new document. Depending on how container rules are set up, users may also be able to share data across containers. When this is the case, the user context can include data from multiple containers. You can think of the context as providing the framework from which user actions are executed. This framework is defined by a container, but can include data from multiple containers. For example, parts defined in one container can be used in an assembly structure that is saved in a different container. Each context provides the following: The context structure, which includes the default domains and folders, forum topics, reference notebook folders, and user notebook folders (if used). Context participation for Windchill PDMLink and Windchill ProjectLink, which includes the available roles, teams, and groups. Default access policies. Data types and object initialization rules. Default life cycle, workflow, context, team, and report templates.
The base data that is loaded during the installation process creates the out-of-thebox templates for containers, workflows, life cycles, teams, and reports, and
2-5
associates them with the System domain that is in the Site container. These templates are then available to descendent containers where appropriate. The Administrator user and the Administrators group are created during the base installation and are also associated with the System domain. Out of the box, these administrators have full access control over all Windchill objects. One important type of data that is loaded is the context template data. Context template data files are XML files that define what is initially in a container when it is created. The file contains the types of items that are similar to the type of data, rules, and domains that are loaded during the Windchill solution installation. When creating additional containers, the administrator selects the context template data file to use to establish the context. For more information on context templates see, Creating Containers in the Administering Containers chapter.
Managing User Access to Data

All Windchill installations establish a default host organization. The Windchill PDM installation creates an organization container has the same name as the host organization. For Windchill PDMLink and Windchill ProjectLink, the site administrator creates the organization container for the default host organization as a post installation step (as described in Creating the Default Organization Container). To belong to the default organization, each user must have an entry in the user directory service that was established as part of the installation process and the organization attribute of the entry (usually "o") must be set to the organization name. By being a member of the host organization, users usually have access to the data stored in the organization container or its child containers (depending on the access control rules that are in place). Users who are not members of the host organization usually do not have access to the data stored in the host organization container or its child containers (unless they are invited to participate by someone in the organization). Again, this is dependent on the access control rules that are in place. After analyzing the users who need access to data, the system administrator determines whether additional organization containers are needed in Windchill PDMLink or Windchill ProjectLink. The organization container can limit data access to members of an organization. For example, if your Windchill solution will be used by multiple companies where each company has a different set of data and rules that will be used from within the solution, then setting up an organization container for each company would be the best approach. However, if only one company will actively use the solution and other companies will just provide data that is managed by the host organization, then one organization container is sufficient. Additionally, Windchill PDMLink administrators can create product and library application containers under an organization, and Windchill ProjectLink users can create project application containers under an organization. Using application
2-6
containers further separates the access of data. In each container, unique policy rules are set. For example: The permissions for parts stored in a product container are usually set so only members of the product have write access to the parts. The permissions for documents stored in a library container are usually set so only members of the library have write access to the documents. The permissions for all objects stored in a project container are usually set so only members of the project have write access to the objects.
Windchill PDMLink Container Hierarchy

The following diagram shows the container hierarchy of a Windchill PDMLink solution where administrators have created one library container and two product containers under the Org1 container:
Site Org1
ComLibrary
Product1
Product2
Windchill ProjectLink Container Hierarchy

The following diagram shows the container hierarchy of a Windchill ProjectLink solution where there are two organizations (Org1 and Org2) and administrators have created two project containers under each organization:
Site Org2
Org1
Project1
Project2
Project3
Project4
2-7
Container Hierarchy for Co-installed Windchill Solutions

The following solutions can be installed in the same codebase: Windchill PDMLink and Windchill ProjectLink Windchill PDM and Windchill ProjectLink
The following diagram shows the co-installed Windchill PDMLink and Windchill ProjectLink container hierarchy where there are two organizations (Org1 and Org2) and administrators have created a product and project container under each organization:
Site Org2
Org1
Product6
Project7
Product5
Project6
The following diagram shows the co-installed Windchill PDM and Windchill ProjectLink container hierarchy where there are two organizations (Org1 and Org2) and Windchill ProjectLink administrators have created two project containers, one under each organization:
Site Org2
Org1
Windchill PDM
Project8
Project6
Managing Access to Data through Access Control Rules

In each container, a set of access control rules can be set when the container is created. These rules can be defined programatically as well as defined in the template that is used to create the container. Additionally, an administrator can define access control rules for the data that is in the container and in its child containers, thereby further controlling the access to data. Generally, each access control policy rule does the following: Identifies a type of data stored in a specific administrative area (domain) to which access permissions are applied.
2-8
Identifies the specific state (or all states) of an object to which access permissions are applied. Identifies users (either as individual users, groups of users, or entire organizations) for whom access is either granted or denied. Specifies the specific access permissions (such as read, write, and modify) given to the users for the data type in the specific domain.
Access control policy rules have a hierarchy based on the domain hierarchy. Dependant domains inherit rules from ancestor domains and cannot override those rules. The following sections introduce the domains and container structure that are available in each Windchill solution.
Windchill PDM Library Container

The Windchill PDM library container is loaded as part of the installation. It inherits from the organization and Site containers that are also loaded. The initial set of domains setup with an organization named Org1 are shown in the following diagram:
Unaffiliated Org1 Org1 Private Project Product1 PDM Windchill
Default
System
PDM
ChangeItems
Note: If you load demo data, there will be additional domains created.
2-9
Use the Principal Administrator to manage users, groups, and organizations. For details on managing users, groups, and organizations, see Administering Principals. Use the Policy Administrator to create domains and corresponding policy rules. For details on domain inheritance and setting policy rules, see Administering Domains and Policies in the Administering Containers chapter.
Windchill PDMLink Application Containers

Each Windchill PDMLink application container that is created usually includes a Default domain that inherits from a PDM domain in the organization context and a System domain that inherits from / (root), as shown in the following diagram. (Depending on the template you use, other domains can also be created in the product or library container.) The diagram shows the Site, Org1, and Product1 containers and domains:
Default PDM
System
Project Product1 System
Default
2-10
However, private application containers can also be created that do not inherit from the Default domain in the organization container. The resulting hierarchy for a Windchill PDMLink private Product2 container is as follows:
Default Project
System PDM
Product2 Product1 System Default
The Team link from the Product or Library tab in Windchill PDMLink allows you to set up the role and role memberships that can be used as the groups against which the access control rules are set as described in Managing Access to Data through Team Memberships. Use the Principal Administrator to update users that have changed in your user directory service or create and update groups at the organization level that can be used as team members. For additional information about managing users, groups, and organizations, see Administering Principals. Use the Policy Administrator to create policy rules. For details on domain inheritance and setting policy rules, see Administering Domains and Policies in the Administering Containers chapter.
2-11
Windchill ProjectLink Project Containers

Each Windchill ProjectLink project container that is created usually includes a default Domain that inherits from a Project domain in the organization context and a System domain that inherits from / (root), as shown in the following diagram. (Depending on the template you use, other domains can also be created in the organization and project containers.) The diagram shows the Site, Org1, and Project1 containers and domains:
Default Project
System
PDM Project1 Product1 System
Default
2-12
However, private project containers can also be created that do not inherit from domains in the organization container. The resulting hierarchy for a Windchill ProjectLink private Project2 container is as follows:
Default
System
PDM Project2 Product1 System Default
Project
The Team link from the Project tab in Windchill ProjectLink allows you to set up the role and role memberships that can be used as the groups against which the access control rules are set, as described in Managing Access to Data through Team Memberships. Use the Principal Administrator to update users that have changed in your user directory service or create and update groups at the organization level that can be used as team members. For additional information about managing users, groups, and organizations, see Administering Principals. Use the Policy Administrator to create policy rules. For details on domain inheritance and setting policy rules, see Administering Domains and Policies in the Administering Containers chapter.
2-13
Managing Access to Data through Team Memberships

In Windchill PDMLink and Windchill ProjectLink, another aspect of managing user access to data can be found in managing who becomes a member of an application container. The context team associated with a product, library or project establishes which users are members of a specific application container. The team members are added to the team according to their role in the product, library, or project. The initial roles that are available in a specific application container are determined when the container is created; however, additional roles can be added. For each role used in a context team there is a corresponding internal group created that administrators can use to create access control rules for the members assigned to the role. The Team link from the Product, Library, or Project tab in your Windchill solution provides access to the interface for managing teams. Use the Policy Administrator to create access control rules. Your Windchill solution also uses roles and corresponding users defined in life cycle templates and team templates (if they are defined for an object). For additional information about teams, see Administering Teams and Roles. For additional information about access control rules, see Administering Domains and Policies in the Administering Containers chapter.
Managing Users
As mentioned in earlier sections, the default domains associated with users are the User domain in the Site container or one of its child domains. For example, assume that the Org1 organization container has been created and users from both the Org1 and Org2 organizations and users that have no organization affiliation (the organization attribute is not set for the user) have accessed your Windchill solution, then the following domains are automatically created:
Site / User Org2
Unaffiliated Org1 Org1
2-14
In this example the user and domain associations are as follows: Users from the Org1 organization (their organization attribute is set to Org1) are by default associated with the Org1 domain. This domain is in the Org1 container. Users from the Org2 organization (their organization attribute is set to Org2) are by default associated with the Org2 domain. This domain is in the Site container. Users who have no organization affiliation are by default associated with the Unaffiliated domain. This domain is in the Site container.
In the previous example, assume that the Org2 organization container is now created using either Windchill PDMLink or Windchill ProjectLink. Then the Org2 domain moves from the Site container to the Org2 container, as show in the following diagram:
Site / User
Unaffiliated
Org1 Org1 Org2
Org2
By using the default domains for users, users are automatically grouped by organization and access policy rules for each organization are initially set using the organization context template used to create the organization. Rules for users not affiliated with any organization can be set using the Unaffiliated domain. When your Windchill solution creates user objects, a personal cabinet is also created for each user. By default, the personal cabinet for a user is put in the same domain as the user. Using this approach allows the access control rules for personal cabinets to be in the same domain as the access control rules for the users. In the previous examples, the organization have short names. If the organization names you are using are longer than 193 characters, then the names are truncated when creating corresponding domain names. For more information, see Creating Domains in the next chapter.
2-15
Managing Data
The Windchill installation establishes a set of business object types that are available in the Site container and then can be inherited by organization containers and then by application containers. The out-of-the-box business object types are described in the following table:
Object Type Description
wt.doc.WTDocument wt.change2.WTAnalysisActivity wt.change2.WTChangeActivity2 wt.change2.WTChangeInvestigation
General documents such as text files or Microsoft Word documents Change data that assigns an analysis task to a user Change data that assigns product development work to a user Change data that collects information about the root cause of a product problem Change data that reports a potential product problem Change data that collects all tasks required to implement a product change Change data that proposes a solution to a product problem Change data that collects all change impact data required for a decision CAD documents A database object that represents a component of assembly in a product structure A snapshot of a product structure that captures the bill of materials to which a product is assembled A serialized copy of a product built according to a specific configuration A collection of specific part and document iterations
wt.change2.WTChangeIssue wt.change2.WTChangeOrder2
wt.change2.WTChangeProposal wt.change2.WTChangeRequest2 wt.epm.EPMDocument wt.part.WTPart
wt.part.WTProductConfiguration
wt.part.WTProductInstance2 wt.vc.baseline.ManagedBaseline
2-16
Note: Not all Windchill solutions use all business object types and many additional object types are used by your Windchill solution to help manage administrative processes, such as updating user preferences, life cycles, and workflows. Additional information about the use of specific object types can be found throughout this guide.
Data Types
All data stored in a Windchill solution are stored as objects of specific types. The type is identified when the object is created or imported. By typing data, you establish patterns for handling the data within the Windchill solution. For example, you can decide if part data is numbered automatically or manually and decide who has access to part data. Separate decisions can be made for each type of data by setting object initialization rules. A set of these rules is established when each container is created through the context template that is used. Additional object initialization rules can be set using the Object Initialization Rules administrator as follows: In Windchill PDMLink and Windchill ProjectLink, you access the Object Initialization Rules administrator from the Utilities page of the context where you want the rule stored. In Windchill PDM, the administrator is on the Business Administration page.
Soft Types
In addition to the modeled object types that are provided out of the box, documents can have subtypes (known as soft types). Windchill ProjectLink provides some document soft types as part of its installation. If your site needs additional types, you can create specific soft types in Windchill PDMLink and Windchill ProjectLink from within the Site or an organization context using the Types link. In Windchill PDM, the Type Manager is available from the Business Administration page.
2-17
Visualization Data
Windchill Visualization Service integrates Windchill with PTC's ProductView, a data visualization tool that allows you to view, annotate, analyze, measure, and animate CAD documents and parts. You may also view, mark up, and print the content of documents in ProductView. All information viewed or annotated in ProductView is saved and stored back into the Windchill database. ProductView supports watermarking of 3D, drawings, images, and documents. Watermarks are defined in INI files created and edited using the ProductView watermark editor. The administrator that manages watermarks manually transfers the INI files from the watermarks directory into the Windchill server. For more information about administering visualization data, see Administering Visualization Services.
CAD Data
CAD data from design authoring applications are contained and managed in Windchill as the content of CAD documents. CAD documents stored in the Windchill database have the wt.epm.EPMDocument object type and are always associated with CAD data content files. Typically, a CAD model forms the primary content for the CAD document. Other CAD data files, for example, drawings or layouts, can also be associated with the CAD document as secondary content. Administrators can create and update CAD document templates. These templates can be used to create CAD documents.
Document Data
Documents stored in the Windchill database have the wt.doc.WTDocument object type and are possibly associated with a soft type of wt.doc.WTDocument. Using soft types helps categorize the types of documents. Administrators can create and update document templates. These templates can be used to create documents.
Part Data
Parts stored in the Windchill database have the wt.part.WTPart object type. Parts created in Windchill PDM and Windchill PDMLink are always associated with a view. A view identifies what the part is used for. The Windchill installation provides two out-of-the-box views: design and manufacturing. Before allowing users to create parts, you can rename these views and add other views that make sense at your site by using the LoadViews command line utility. For more information, see Administering Views and View Associations.
2-18
Audit Reports
Auditing reports are designed to record and report user and system events for auditing and traceability purposes.
Managing Windchill Processes

Windchill provides you with the following types of Windchill data processes that can be used with the business objects stored in Windchill: A life cycle process defines a set of phases and gates that manage the life of an object as it progresses from conception to obsolescence. A workflow process defines rules which allow workflow participants to view and pass along information, tasks, and documents. A change process establishes how to get changes made to parts and many other data types including documents, document soft types, and product instances.
These three processes work together to help you manage data. Workflows are often used to drive the life cycle. That is, the workflow process is used to transition from one life cycle state to another. In most cases, a workflow process is initiated from a life cycle. In any case, life cycle-managed objects obtain a life cycle when they are created. In obtaining a life cycle, an object can have a workflow process instance created as well. Change objects are life cycle-managed objects. Each change object starts a change process when it obtains its life cycle. Use the Life Cycle Administrator to manage the life cycle templates that can be used. For details on managing life cycle templates, see Administering Life Cycles. Use the Workflow Administrator to manage the workflow templates that can be used. For details on managing workflow templates, see Administering Workflow Processes.
Managing User Collaboration

User collaboration can be done using a specific Windchill solution and other PTC or third party products or using multiple co-installed Windchill solutions. Windchill provides the following tools for collaboration: Windchill projects that are created using Windchill ProjectLink provide participants with a place in which they can share information. This information can include data that resides in either a Windchill PDM or Windchill PDMLink solution. Pro/ENGINEER Wildfire provides users with the ability to share CAD drawings and other design-related information. For administration information, see the Administering Pro/ENGINEER Wildfire chapter in the Windchill System Administrators Guide.
2-19
Additional Administrative Groups

The following additional administrative groups are automatically created for all Windchill solutions to help define users for specific administrative activities in your solution: Attribute Administrators LifeCycleAdministrators Type Administrators WorkflowAdministrators For example, those users in the Attribute Administrators group can manage the metadata for attributes. Those users in the LifeCycleAdministrators group become participants in the Default life cycle template, when that template is used. Additionally, the Windchill PDM installation creates the following administration groups: Classification Administrators Navigation Administrators And the Windchill PDMLink installation creates the following administration group: Business Entity Authors By using the Principal Administrator, you can add users to any of the administrative groups. The Windchill PDMLink and Windchill ProjectLink solutions provide additional types of administrators: An organization administrator manages a specific organization. A product manager manages a specific product. A library manager manages a specific library. A project manager manages a specific project.
For additional information about administrators, see Establishing Administrators.
2-20
Post-Installation Activities
Before allowing users to access the Windchill solution, be sure to do the following activities: Complete the activities described in the Getting Started chapter. For Windchill PDMLink and Windchill ProjectLink, determine if there are additional organization containers that you want to create and create them. See Administering Organizations. Determine if additional organization principals are needed and whether or not to allow these organizations to own parts and documents. By default, all parts and documents are owned by the organization from which they are created. For information on how to set up the ability to choose which organization own a part or document, see Administering Organizations in the Windchill System Administrators Guide. Determine whether you want audit reports enabled. See Administering Audit Reports.
2-21
About the windchill Command

PTC has provided a command, windchill, to invoke Windchill actions. For example, the command can be used to stop and start Windchill, check the status of the Windchill server, and create a new shell and set the environment variables. It can also be used as a Java wrapper. In that regard, it can accept a Class file as an argument, just like Java, and execute it without a predefined environment (Windchill classes in CLASSPATH, Java in PATH, and so on). The windchill command should be used to execute any server-side Windchill Java code. This will insure that the environment that the command is executed in is properly setup. The environment that actions are executed within, including the windchill shell action, is defined by the wt.env properties in the wt.properties file. For example, the wt.env.CLASSPATH property will set the CLASSPATH environment variable for the action that is being invoked. The windchill command is a Perl script that has also been compiled into a Windows binary executable. For UNIX systems, Perl 5.0 or greater must be installed. The windchill script assumes that Perl is installed in the standard install location of /usr/bin/perl. If Perl is not installed at this location, you can either create a symbolic link (recommended method) to the Perl install location or edit the windchill script to reference the Perl install location. To modify the windchill script, edit the <Windchill>/bin/windchill file. Locate the #! entry (for example, #!/usr/bin/perl -w) and change the Perl directory to the location where Perl is installed. The windchill command is located in the <Windchill>\ bin directory. If you receive a command not found message when you execute the windchill command, add the <Windchill>\bin directory to your PATH environment variable. The syntax of the windchill command is:
windchill [args] action
You can display the help for the windchill command by executing windchill with the -h argument or with no argument. The following tables list some of the arguments and actions applicable to the windchill command. To see a complete list of the arguments, use the report generated from the help (argument). windchill Arguments:
Arguments (optional) - h, --help -v, --[no]verbose Description Displays help and exits. Explains what is being done when a command is executed. Default is noverbose.
2-22
Arguments (optional) -w, --wthome=DIR
Description Sets the Windchill home directory. Default is the parent directory containing the windchill script. The Java executable. Default is the wt.java.cmd variable value specified in the $WT_HOME/codebase/wt.properties file. Java classpath. Default is the wt.java.classpath variable value specified in the $WT_HOME/codebase/wt.properties file. Java command line arguments.
--java=JAVA_EXE
-cp, --classpath=PATH
--javaargs=JAVAARGS
windchill Actions
Action shell start stop status version Description Sets up a Windchill environment in a new instance of the currently running shell. Starts the Windchill server. Stops the Windchill server. Retrieves the status of the Windchill server. Displays the Windchill install version.
2-23
Action properties <resource>[,...][?key[&key2]...]
Description Displays the properties as seen by Windchill for the given resource with substitution, etc. executed. It can be limited to a given set of keys. For example: windchill properties wt.properties lists all wt.properties windchill properties wt.properties?wt.server.codebase lists server codebase windchill properties wt.properties?wt.env.* lists all the environment variables use by windchill shell windchill properties with no arguments generates the help report
CLASS [CLASS_ARGS]
Run a Windchill class with optional class arguments. For example: windchill wt.load.Developer -UAOps
About the windchill shell

The windchill shell brings up a new command shell, from the parent shell that is setup for the Windchill environment. This includes setting all environment variables defined in wt.env property in the wt.properties file. To execute the windchill shell, at the command prompt enter the following command:
windchill shell
When you are finished using the windchill shell, you can exit the shell and return to the parent shell. PTC recommends running all server-side Windchill applications, tools, and utilities from the windchill shell. Also, you can use the windchill shell to set up your development environment to use javac or Java directly.
2-24
About the xconfmanager Utility

The xconfmanager is a command-line utility that is used to add, remove, and modify the properties in the Windchill property files. In addition to the xconfmanager functioning as an editing tool, xconfmanager also manages the property files. Consequently, do not manually edit the Windchill property files. Additionally, the following registry files are managed by Windchill Information Modeler and they also should not be edited manually or using the xconfmanager: associationRegistry.properties classRegistry.properties descendentRegistry.properties modelRegistry.properties
The xconfmanager utility saves your changes in the site.xconf file and provides an option to generate updated property files using those changes. The site.xconf file contains changes made to Windchill property files, starting with installation and continuing with each use of the xconfmanager utility or the System Configurator. The xconfmanager utility is located in the <Windchill>/bin directory. This chapter describes only the information and instructions necessary to modify specific Windchill properties. A full description of the xconfmanager utility and management of the Windchill property files is documented in the Windchill System Administrators Guide in the Administering Runtime Services chapter. Anyone with write access to the XCONF files and the property files under the Windchill installation directory can successfully run the xconfmanager utility. The xconfigmanger is executed from the command line from within a windchill shell. See the About the windchill Command for more information about the windchill shell. The syntax of xconfmanager command is as follows:
xconfmanager {-FhuwvV} {-r <product_root>} {-s <property_pair> {-t <property_file>}} {--reset <property_names>} {--undefine <property_names>} {-d <property_names>} {-p}
For the purposes of modifying Windchill properties, you will primarily use the set (-s), targeFile (-t), and propagate (-p) parameters. The set (-s) parameter is used to identify the relevant property and specify the new property value. See the Formatting Property Value Guidelines section (below) for information about formatting the <property_pair) value. The targetFile (-t) property is used to specify the directory location of the property file. If the file name or path contains spaces, you must enclose the <property_file> value in double quotes (" "). It is recommended to use a fully qualified file name to ensure an accurate reference to the file is made.
2-25
The propagate (-p) property is used to propagate the changes made to the XCONF files into the property file being modified in order to keep the XCONF and the property files in synch with one another. help is used to view the help for xconfmanager.
Some examples of using the xconfmanager utility are as follows: xconfmanager is run from the windchill shell. To open a windchill shell, execute the following command at a command prompt:
windchill shell
To display xconfmanager help, execute the following command from the windchill shell:
xconfmanager -h
To display the current settings for a property, execute the following command from the windchill shell:
xconfmanager -d <property_names>
To change a property value, execute the following command from the windchill shell:
xconfmanager -s <property_pair>=<property_value> -t <property_file> -p
Tip: Use the fully qualified name of the property file to ensure an accurate reference.
Formatting Property Value Guidelines

The property values you set must conform to the specification for java.util.Properties. The following guidelines will help ensure that you set properties correctly: Use forward slashes (/) in file paths so that the platform designation is not an issue. To specify a property whose value contains characters that might be interpreted by your shell (such as spaces and special characters), escape them using the appropriate technique for the shell you are using. For example, on a Windows system you can include spaces in a value by enclosing the argument with doubles quotes. For example, use the following:
-s "wt.inf.container.SiteOrganization.name=ACME Corporation"
On a UNIX system, you can use doubles quotes or you can escape the space character with a backslash. For example, use the following:
-s wt.inf.container.SiteOrganization.name=ACME\ Corporation"
2-26
On UNIX, dollar signs are usually interpreted by shells as variable prefixes. To set a property value that has a dollar symbol in it, use single quotes around the argument so that the shell does not interpreted it or use backslash to escape the dollar symbols. For example, use either of the following:
-s 'wt.homepage.jsp=$(wt.server.codebase)/wtcore/jsp/wt/portal/ index.jsp'
or
-s wt.homepage.jsp= \$(wt.server.codebase)/wtcore/jsp/wt/portal/index.jsp
Other than escaping arguments so that the command-line shell does not misinterpret them, you should not need to escape other values to be compatible with XML or property file syntaxes. The xconfmanager escapes property names and values automatically if necessary.
2-27
2-28
3
Administering Containers
This chapter provides the overall details relating to working with containers. Later chapters assume that you have read the information in this chapter. Topic Page
Distributed and Hierarchical Administration ......................................................3-2 Container Administrative Items ..........................................................................3-4 Creating Containers...........................................................................................3-19 Administering Domains and Policies ................................................................3-24 Administering Object Initialization Rules.........................................................3-32 Searching for Principals ....................................................................................3-39
3-1
Distributed and Hierarchical Administration

Windchill containers provide the framework for collecting and finding related information. The set of containers in your Windchill solution have a hierarchical relationship. The following depicts the basic container hierarchy:
Site container
Organization containers
Application containers
The Site container can have one or more child organization containers. An organization container can have one or more child application containers. Application containers include: Projects (provided by Windchill ProjectLink) Products (provided by Windchill PDMLink) Libraries (provided by Windchill PDMLink - formerly known as repositories) The Windchill PDM library (provided by Windchill PDM)
Data, such as template files, can be distributed among the containers. For example, you can define general document templates, such as those used for presentations or memos, at the top level of the hierarchy (in the Site container). The document templates are available to all containers. Then you can define progressively more specific templates at each layer in the hierarchy, such as in an organization container or a library container. In a child container, you can also define templates with the same name as those templates in an ancestor container so that the templates in the child container can override and be used in place of templates in an ancestor container. With distributed administration, container administrators are responsible for their own administrative tasks. So for example, each project, product, and library can have its own administrators (called project, product, and library managers). To support distributed administration, the administrative clients are container-aware. For example, opening the Policy Administrator in the context of a library initially displays the domains that are in the library context and the domains that are ancestors of the library context domains. Making clients container aware allows for the delegation of administrative duties to users who are recognized as container administrators.
3-2
With hierarchical administration, containers inherit administrative items from parent containers (or, in the case of policies, from ancestor domains). Administration performed at the level of an ancestor container is applicable to all of its descendent containers. Except for policies, child containers can choose to override the administrative items of its parent containers. For policies, rules from all ancestor domains are merged with the rules in a current domain to form the policy for the current domain. In general, always think of performing administration duties in the context of a container, as follows: Site administrators can create, modify, delete, and view administrative items in the Site container. Organization administrators can create, modify, delete, and view administrative items in the given organization container. They can view and override administrative items defined in the Site container. Application container administrators can create, modify, delete, and view administrative items in the given application container. They can view and override administrative items defined in the parent organization container and the Site container. Site and organization administrators can administer child containers; however, they do so by going into the context of the child container and performing their administrative duties there.
Note: Windchill users always perform their activities in the context of a container. Most often, these activities occur in application containers rather than in an organization or Site container. Non-administrative Windchill users generally do not create, modify, or delete administrative items; however, they have visibility to, and are affected by, the following administrative items: The administrative items that are defined in a given application container. The administrative items that are defined in the parent organization and Site containers, but not overridden in the application container.
3-3
Container Administrative Items

Each container can be populated with the following types of administrative items: Container configuration Container structure Container participation Container policies Container data types and attributes Container templates, including process templates and data templates Container object initialization rules
After you have created a container, you can update many of the administrative items that are associated with the container. The containers you can update include the Site container, as well as organization and application containers. To update the administrative items in a container, you must be an administrator of the container. For the details on Windchill administrators, see Additional Administrative Groups in the Administration Overview chapter. Each type of container has a slightly different set of administrative items that can be updated. For example, you can update the set of life cycle and workflow templates provided in organization, product, and library containers. Also, you can only update the set of product, library, and project templates that are provided in an organization or the Site container. This is because product, library, and project templates are not included in application containers. The following sections provide descriptions of administrative items, information on what is installed in the Site container for each item, and how to update the items.
Container Configuration
Configuration items identify the type of container and other miscellaneous information about the container. There are three general types of containers: Site -- The Site container is the top-level container. There can be only one Site container. Organization -- Organization containers are always children of the Site container. There is always at least one organization container required to have an operational Windchill solution. Note: Although Windchill PDM has an organization container (created as part of the installation), the container is not a main part of the solution architecture. It is provided for compatibility with the other solutions.
3-4
Application -- Application containers are always children of an organization container. There are three types of application containers: Product (provided by Windchill PDMLink) Library (provided by Windchill PDM and Windchill PDMLink) Project (provided by Windchill ProjectLink)
The container configuration can include the following additional items: For Windchill PDMLink and Windchill ProjectLink application containers, you decide whether the container is public or private. Private containers inherit access control rules from the Private domain of the organization. Public containers inherit access control rules from a solution-dependent public domain within the organization container. For Windchill ProjectLink, the public domain is the /Default/Project domain. For Windchill PDMLink, the public domain is the Default/PDM domain. This configuration allows an administrator to: Create policies in the organization container's Default domain that apply to all public child containers. Create policies in the Default/Project and Default/PDM domains that apply to solution-specific child containers. Create policies in the Private domain that apply to all child containers.
For project containers, you decide whether or not data can be shared to other containers. For organization containers in Windchill ProjectLink, you decide whether the creators group is auto-populated with members of the organization. The creators group in Windchill ProjectLink determines who can create projects.
The configuration of the container is set when the container is created based on the options chosen through the user interface or through data loading, and are not set in a template.
Updating the Container Configuration

For Windchill PDMLink and Windchill ProjectLink, the configuration of an organization or application container is set when the container is created based on the options chosen through the user interface. Only a few of the options can be updated: For an organization container, update the container using the Update Organization icon or the Update action on the organization details page. Site administrators, can navigate to the Organizations page from the Site tab and select the Update action for the organization they want to update. For details on how to update and what can be updated, click the help available from the Organization tab.
3-5
For an application container, update the container using the Update icon or the Update action from the container details page. First, navigate to the container by selecting the container tab and then selecting the product, library, or project you want to update. For details on how to update and what can be updated, click the help available from the container tab.
Note: In Windchill PDM, you cannot update the container configuration.
Container Structure
Structure items identify the domains, cabinets, folders, notebook folders, forum topics, and reference folders for notebooks that are in the container and the domain inheritance scheme that is in place. Containers define a structure in which information related to a context is organized. This structure can be represented by a folder hierarchy, product structure hierarchy, collection of discussion topics, or pre-defined milestones in a schedule. The structure defined by the container enforces consistency and improves efficiency. The use of the container structure is very apparent when you look at how domains can help organize rules for users. For example, the Administrators group and Administrator users are associated with the System domain and, therefore, are segregated from other users. The other users are associated with child domains of the User domain. Both the System and User domains are in the Site container, and the child domains of the User domain can be in the Site container or in an organization container.
Installed Site Container Structure

The Site container has the top-level / (root) domain, the System, Default, User, and SessionIterationDomain domains that are children of the root domain, and the Unaffiliated domain that is a child of the User domain. (For an explanation of these domains, see Administering Domains and Policies.)
Windchill PDMLink and Windchill ProjectLink
For the Windchill PDMLink and Windchill ProjectLink solutions, the following folders are installed in the Site container: System System/Workflow Default User For Windchill ProjectLink, the following folders, which are associated with Default domain in the Site container, are installed: Change Log General Policies
3-6
For Windchill ProjectLink, the following user notebook folders are installed in the Site container: My Hot Links My General Links
Windchill PDM
For Windchill PDM, the following folders are installed in the Site container: System/Default System/System For Windchill PDM, the following cabinets are installed in the Site container: Default System User
Updating Container Structure

The container structure is set either by the load files used (in the case of the Site container and the Windchill PDM organization and library containers) or by the template selected when the container is created. The template (and its underlying code) sets the domains, cabinets, folders, notebook folders, forum topics, and reference folders that are in the container and the domain inheritance scheme, which identifies parent and child domain relationships. Although you can modify the set of domains in a container using the Policy Administrator, Windchill PDMLink and Windchill ProjectLink administrators should refrain from doing so as a general rule. Instead, work within the domains provided. Windchill PDMLink and Windchill ProjectLink solutions do not expose the creation of cabinets through their user interface. Use the default cabinets defined. For Windchill PDMLink and Windchill ProjectLink, administrators can update the set of folders available in a container by navigating to the specific product, library, project, or organization and then clicking the Folders link. Similarly, forum topics can be created in a product, library, or project by clicking the Forum link that is available from the product, library, or project. Windchill PDM administrators can use the Windchill Explorer to work with cabinets and folders.
3-7
Container Participation
Participation items establish the following: Roles that are automatically available in a container. Groups automatically created in a container.
For Windchill PDMLink and Windchill ProjectLink, product, library and project containers are associated with teams of users and groups. Any user can display all products, libraries, or projects in which the user is identified as a team member. The users and groups in a team are associated with roles that identify the responsibilities and rights of the team members. For example, the Product Manager role (in Windchill PDMLink) establishes who is in charge of the product and the Project Manager role (in Windchill ProjectLink) establishes who is in charge of a project. The set of roles and groups that are automatically available in a context consist of the roles and groups established in ancestor containers, as well as those defined specifically for the container.
Installed Site Container Participation

Through the Site container, roles and groups that are useful throughout your Windchill solution are made available to the site.
Roles
The roles that are available to the entire site are defined in the <Windchill>\src\ wt\project\RoleRB.rbinfo resource bundle, which is translated to all supported languages and made available through the application clients. For Windchill PDMLink and Windchill ProjectLink, all of these role names are available to all child organizations and then to the product, library, and project containers created. To see the roles, you can click the Roles link from the Organization tab. For products, libraries, and projects, click the Team link from the corresponding tab. For Windchill PDM, you can view the roles from the Life Cycle Administrator. Update a life cycle and then click the Roles tab to view the roles.
3-8
Groups
The following group is defined in the Site container System domain: Administrators (known as the system or site administrators) Note: This group defines the administrators for your entire site as described in Distributed and Hierarchical Administration. The following groups are defined in the Site container User/Unaffiliated domain: Attribute Administrators Business Entity Authors (only Windchill PDMLink) Classification Administrators (only Windchill PDM) LifeCycleAdministrators Navigation Administrators (only Windchill PDM) Type Administrators Unrestricted Organizations WorkflowAdministrators These groups are used during the normal operation of your Windchill solution and should not be removed. Domain-based access control rules are automatically loaded in the Site container System domain granting permissions to members of these groups, except the Unrestricted Organizations group. The rules for the members of the Unrestricted Organizations group are loaded in the Site container User domain.
Updating Container Participation

For Windchill PDMLink and Windchill ProjectLink, container participation is set by the template selected when the container is created. The roles and groups defined in the template can be modified in the organization context as well as in an application container context. Those roles and groups defined in the organization are inherited by the children of the organization. From within an organization, use the Groups link to add or update groups and use the Roles link to add or remove roles from the organization. From within a product, library, or project, use the Team link to add or remove roles. From the Team table, you also add and remove members from the roles. For additional information, see Administering Teams and Roles. Note: In Windchill PDM, you cannot update the container participation except by changing life cycle roles in a life cycle template or team template, or by setting access control rules against users, groups, and organizations.
3-9
Container Policies
Container policy items can include the following: Domain-based access control rules that establish the access control against specific principal, object type, life cycle state, and domain combinations. For example, there can be an access control rule for objects with the wt.doc.WTDocument data type in the Default domain that gives read permission to the Engineers group. Indexing rules that define which collections an object is included in when the object of a specified object type and domain combination moves to a specific life cycle state. Collections are used to create indexing lists which help improve performance when searching for objects. Notification rules that define which principals get notified when a specified event occurs for an object type and domain combination.
Containers provide a natural context for controlling access to the contained information. In application containers, access is controlled through container team membership, policy rules and, for Windchill ProjectLink, ad hoc rules applied to folders and roles. Container contents can be restricted so that access is limited to the members of a container team or the container information can be made more broadly available to the enterprise through policies that grant specified groups in an organization access to specific object types. The policies that are in effect in a context are determined by the policies set in the domains that are in the current context, as well as those set in the ancestor domains. For details, see Administering Domains and Policies.
Installed Site Container Policies

The Site container policies that are set consist of the domain-based access control rules and one indexing rule. No notification rules are set in the Site container domains, and no policy rules are set in the Site container SessionIterationDomain. Note: Your solution may vary from the following description, as the name of the Administrators group, and the names of the some initial domains are configurable from the wt.properties.xconf file prior to the installation. The following sections describe the rules that are set in the Site container.
3-10
Access Control Rules for / (Root) Domain
The following domain-based access control rules are programmatically set when the data is loaded during the installation. The rules are in the Site container / (root) domain for all life cycle states. Note: These rules ensure that users can operate within the Windchill solution and should not be changed without fully understanding the reason for the change.
Object Type Principal Permissions Comment
AccessPolicyRule
ALL
Read
Allows organization and application container administrators to see inherited access rules. Allows all users to complete a variety of general actions. Allows all users to set and configure personal configuration specification settings. Allows all users to complete a variety of general actions. Allows all users to create and read object subscriptions. Allows all users to set and configure personal configuration specification settings. Allows all users to create and read markups. Allows the owner of a markup the ability to modify and delete it. Grants full control to all site administrators. Allows all users to set and configure personal configuration specification settings.
AdministrativeDomain EPMDocConfigSpec
ALL ALL
Read Full Control (All) Read Read and Create Full Control (All) Read and Create Modify and Delete Full Control (All) Full Control (All)
ExchangeContainer ObjectSubscription WTDocumentConfigSpec
ALL ALL ALL
WTMarkup WTMarkup WTObject WTPartConfigSpec
ALL OWNER Administrators ALL
3-11
Access Control Rules for User Domain
The following domain-based access control rules are set in the Site container User domain for all life cycle states.
DBPrefEntry WTGroup WTObject WTPartConfigSpec
All Unrestricted Organizations OWNER Authors
Read Read Full Control (All) Read Modify Create Read
Allows users to read preferences. Allows read access to groups for the organizations that are in this group. Grants full control to the owner of an object. Allows read, modify and create permission to users in the Authors group for part configuration specifications. Allows read access to users for the organizations that are in this group.
WTUser
Unrestricted Organizations
Access Control Rule for User/Unaffiliated Domain
The following domain-based access control rule is set in the Site container Unaffiliated domain (which is a child of the User domain) for all life cycle states.
WTPrincipal
All
Read
Allows read access to principals for all users.
Access Control Rule for Default Domain
The following domain-based access control rule is set in the Site container Default domain for all life cycle states.
Meeting
All
Read
Allows read access to meetings for all users.
Access Control Rules for System Domain
The domain-based access control rules set in the Site container System domain are used to control access to administrative objects. For normal operations, you should not modify these rules. To view the rules, use the Policy Administrator from the Site context. For information about accessing the Policy Administrator, see Using the Policy Administrator.
3-12
Indexing Rule for / (Root) Domain
The following indexing rule is set in the Site container / (root) domain for all life cycle states..
Object Type State Collections Comment
WTObject
All
Windchill_Business_Collection
Indexes all object in all states and puts the indexes into the Windchill_Business_Collection collection.
Updating Container Policies

Use the Policy Administrator to update container policies. For information about using the Policy Administrator, see Administering Domains and Policies.
Container Data Types and Attributes

Data type and attribute items identify data types (defined as soft types) and attributes that are in addition to the Windchill modeled classes. The data types available in a context are determined by the data types defined in the organization context, as well as those defined in the Site context. For example, if your organization context has defined Plan and Report document soft types, then these soft types are available in any project, product, or library context created from your organization context.
Installed Site Container Data Types and Attributes

All data types that are modeled in your Windchill solution are available for administrator use from the Site container. If Windchill ProjectLink is installed, then the following document soft types are also available from the Site container: Agenda General Minutes Plan Presentation
3-13
Updating Container Data Types and Attributes

For Windchill PDMLink and Windchill ProjectLink, you can use the Types link from the Site and Organization tabs to view and update data types: To create and update site-wide types, navigate to the Site tab and click the Types link. For organization-specific types, access an organization and click the Types link.
To associate attributes with a type, attributes must already be defined at the site level. Use the Type Manager to update add attributes to data types. Only the site administrator can create and update attributes by using and the Attribute Manager. Note: The internet domain defined on an organization principal is important when creating new soft types. The internet domain is used to distinguish which organization owns the type. The default organization principal created during the installation process owns the Site container; any types owned by this organization principal are available to all organizations. Soft types created from an organization container that has its own internet domain set on its associated organization principal are only available to the owning organization. For additional information about updating data types and attributes, see Using Types and the Type Manager.
Container Templates
Template items identify the templates that provide users with the required information used when creating and processing Windchill objects. Windchill provides the following types of templates (not all types of templates are available from all Windchill solutions): Context templates provide the required and optional administrative items that are used to create containers. There are four types of context templates: Product templates define default values and other information, such as team roles and access policies, which are used when an administrator creates a product using Windchill PDMLink. Library templates define default values and other information, such as team roles and access policies, which are used when an administrator creates a library using Windchill PDMLink. Project templates define default values and other information, such as folder structure and team roles, which are used when an administrator creates a project using Windchill ProjectLink. Organization templates define default values and other information, such as folder structure and groups, which are used when an administrator creates an organization context from either Windchill PDMLink or
3-14
Windchill ProjectLink. Each solution provides a unique set of organization templates. Document templates provide content files and default values, which are used when users create different types of documents. For example, content might include skeleton documents for memos or reports. CAD document templates define the content and default values, which are used when users create CAD documents from either Windchill PDM or Windchill PDMLink. Life cycle templates define the phases and gates associated with various business objects when the objects are initialized. Report templates define default values, which are used when users run reports for change management. Team templates define default roles, which are used when users populate teams associated with life cycles. Workflow templates define default values, which are used when users initiate a workflow.
Installed Site Container Templates

The templates loaded in the Site container are associated with the System domain. The following sections describe the templates that are loaded.
Organization Context Templates
Note: Windchill PDM does not load or use organization context templates. When Windchill PDMLink is installed, the following organization context template is loaded in the Site container: General (PDMLink) When Windchill ProjectLink is installed, the following organization context templates are loaded in the Site container: General Enterprise Supplier Customer For additional information about organization context templates, see Out-of-theBox Organization Templates in the Administering Organizations chapter.
3-15
Life Cycle Templates
The following life cycle templates are loaded in the Site container for all Windchill solutions: Default ReplicationPublish ReplicationReceive ReplicationSender ReplicationBaseline For Windchill PDMLink and Windchill PDM when CMII is installed, the following life cycle templates are loaded in the Site container: CMII Problem Report CMII Change Request CMII Change Notice CMII Change Activity CMII Change Proposal For Windchill ProjectLink, the following life cycle templates are loaded in the Site container: Approval Approval Routing Basic Notify Notify Routing Release Release Routing Review Review Routing
Workflow Templates
The following workflow templates are loaded in the Site container for all Windchill solutions: Submit Review ReplicationPublish ReplicationReceive ReplicationSender For Windchill PDMLink and Windchill PDM when CMII is installed, the following workflow templates are loaded in the Site container: CMII PR Workflow CMII ECR Workflow CMII ECN Workflow CMII CA Workflow
3-16
For Windchill ProjectLink, the following workflow templates are loaded in the Site container: Approval Process Notify Process Release Process Review Process
Team Templates
Team templates are used with life cycle templates. For all Windchill solutions, the following team template is loaded in the Site container: Default For Windchill PDMLink and for Windchill PDM with CMII installed, the following team templates are loaded in the Site container: CA Team ECN Team ECR Team Problem Report Team
Document Templates
For Windchill ProjectLink, the following document templates are loaded in the Site container: Agenda Template Memo Template Minutes Template MS Project Plan Template Presentation Template Requirements Template No document templates are loaded for Windchill PDM and Windchill PDMLink.
3-17
Updating Container Templates

For Windchill PDMLink and Windchill ProjectLink, templates are available from the Templates link in each context. To update templates, navigate to the Templates table by clicking the Templates link within a specific context and then select the type of template from the Current View drop-down list. The list of templates that are available from the context appears in the table. Each type of template has its own method of updating the templates. Generally, updating can be initiated either by clicking an icon at the top of the Templates table or selecting an action from a row in the table. For details on templates and how to update them, click the help icon available on the Templates table. For Windchill PDM, you update each template using the administrator utility that is associated with the template. The following links, located under Business Administration, give you access to the utilities: Process Administrator (for life cycle, team, and workflow templates) Document Template Administrator (for document templates)
Container Object Initialization Rules

Container object initialization rule items identify rules that establish specific default attribute values that are used when instances of objects of a specific type are created. Windchill solutions provide algorithms for setting default values for the following object attributes: Folder paths Life cycle attributes Team template attributes Default numbering scheme Default versioning scheme Strings Enumerated types
Note: To set default values for other attributes, your site would need to create the algorithms that can be used in setting them. For additional information about object initialization rules, see Administering Object Initialization Rules.
3-18
Installed Site Container Object Initialization Rules

For all Windchill solutions, the out-of-the-box numbering and versioning schemes are used for WTPart, WTDocument, and EPMDocument in the Site container. These schemes are simple Oracle sequences that have been loaded into the Windchill database. Each starts at 1 and increments by 1. For change objects (WTChangeActivity2, WTChangeIssue, WTChangeOrder2, WTChangeProposal, and WTChangeRequest2), the out-of-the-box numbering scheme is also set. For additional information about the out-of-the-box numbering and versioning schemes, see the help accessible from the Object Initialization Rules Administrator. Additionally, the value Default is set as the default life cycle template and Default is set as the default team template for the following object types: ManagedBaseline WTProductInstance2 WTProductConfiguration Note: In Windchill PDM, the application clients set values for folder paths, life cycle templates, and team templates. Default values are never used in these cases.
Updating Container Object Initialization Rules

Use the Object Initialization Rules Administrator to update object initialization rules. For information about using the Object Initialization Rules Administrator, see Administering Object Initialization Rules.
Creating Containers
Note: Only Windchill PDMLink and Windchill ProjectLink provide the capabilities for creating organization and application containers. You cannot create containers in Windchill PDM. There is only one Site container, which is created when your Windchill solution is installed. No other Site containers can be created. Note: In Windchill PDMLink and Windchill ProjectLink, the base data installation does not create an organization; after the installation is complete, the site administrator creates the organization container from the Site tab. Application container administrators can create application containers. You become an application container administrator for products, libraries, or projects by being in the creators group for products, libraries, or projects. The creators groups are maintained from the Creators link on the Organization tab. When
3-19
you create an organization from Windchill ProjectLink, you can choose to automatically add those organization members who log on to the project creators group. In Windchill PDMLink, you manually add users to the product and library creators groups. As part of the process of creating a container, you select a context template. Context templates provide the administrative items (as described in Container Administrative Items) that you want set in the container, thus establishing the initial context framework for users. For information about creating organization containers, see Creating an Organization in the Administering Organizations chapter. For information about creating product and library containers, see Administering Products and Libraries. For information about creating project containers, see Administering Projects.
Using Out-of-the-box Translated Context Templates

Your Windchill solution provides a set of out-of-the-box context templates that you can use when creating containers. The text in the templates has been translated and translated files are provided in the loadFiles directory where your Windchill solution is installed. The installer determines which language set of templates to load as part of the installation process. The command you use for loading additional templates and the templates that are available are unique for Windchill PDMLink and Windchill ProjectLink. The following sections describe the command syntax and templates for each solution.
Windchill PDMLink Translated Templates

For Windchill PDMLink, you can load additional translated template sets into the Site container using the following command:
windchill wt.load.LoadFromFile -d /<install_dir>/loadFiles/<template_set_XML> -CONT_PATH /
Where <install_dir> is the directory where your Windchill solution is installed and <template_set_XML> is an XML file that contains a list of the files to load for a specific language. Setting CONT_PATH to "/" adds the templates to the Site container. For Windchill PDMLink, use one of the following for <template_set_XML>:
Language Windchill PDMLink File to Load
English French German
pdmlinkContainerTemplates.xml pdmlinkContainerTemplates_fr.xml pdmlinkContainerTemplates_de.xml
3-20
Language
Windchill PDMLink File to Load
Italian Japanese Korean Simplified Chinese Spanish Traditional Chinese
pdmlinkContainerTemplates_it.xml pdmlinkContainerTemplates_ja.xml pdmlinkContainerTemplates_ko.xml pdmlinkContainerTemplates_zh_CN.xml pdmlinkContainerTemplates_es.xml pdmlinkContainerTemplates_zh_TW.xml
Windchill ProjectLink Translated Templates

For Windchill ProjectLink, you can load additional translated template sets into the Site container using the following command:
windchill wt.load.LoadFromFile -d /<install_dir>/loadFiles/projectlink/<template_set_XML> -CONT_PATH /
Where <install_dir> is the directory where your Windchill solution is installed and <template_set_XML> is an XML file that contains a list of the files to load for a specific language. Setting CONT_PATH to "/" adds the templates to the Site container. For Windchill ProjectLink, use one of the following for <template_set_XML>:
Language Windchill ProjectLink File to Load
English French German Italian Japanese Korean Simplified Chinese Spanish Traditional Chinese
ProjectLinkContainerTemplates.xml ProjectLinkContainerTemplates_fr.xml ProjectLinkContainerTemplates_de.xml ProjectLinkContainerTemplates_it.xml ProjectLinkContainerTemplates_ja.xml ProjectLinkContainerTemplates_ko.xml ProjectLinkContainerTemplates_zh_CN.xml ProjectLinkContainerTemplates_es.xml ProjectLinkContainerTemplates_zh_TW.xml
3-21
Removing Templates
To remove templates that have been loaded, click the Site tab and then click the Templates link to display templates. Select the type of template from the Current View drop-down list to display the templates in the table. Use the delete row action to remove individual templates. For additional help on removing templates, click the help icon on the Templates table to display the templates help.
Using Out-of-the-box Templates

Use one of the out-of-the-box organization templates when creating organization containers. For application containers, you can use one of the out-of-the-box product, library, or project templates, or you can create additional application container templates as described in the next section. The details of what is in each out-of-the-box context template can be found in the following chapters: Organization templates are described in Administering Organizations. Product and library templates are described in Administering Products and Libraries. Project templates are described in Administering Projects.
Note: The role names used in Windchill solution context templates are included as references to the <Windchill>\src\wt\project\RoleRB.rbinfo resource bundle so that when they are used, they appear in the language specified by the browser language. This means that the translated templates do not contain translated role names.
Creating Context Templates

You can create additional context templates in the following ways: By saving the contents of an existing container as a new context template. This option is available for products, libraries, and projects. By exporting an existing application container as a template, updating the template contents (if needed), and then importing the new template. This option is available for products, libraries, and projects.
Windchill PDMLink Context Templates

When using either of the options for creating templates, you can include the following administrative items in a new Windchill PDMLink template: Folder Structure (not including the folder contents) Team Roles Team Members
3-22
Document Templates Object Initialization Rules Access Policy Rules
Windchill ProjectLink Context Templates

When using either of the options for creating templates, you can include the following administrative items in a new Windchill ProjectLink template: Folder Structure (not including the folder contents) Folder Links and Structure Project Plan Deliverables Team Roles Team Members Documents Document Templates Forum Spec Forum Template Object Initialization Rules
Additionally in Windchill ProjectLink, you can save an existing project as a new project. Using this option creates a duplicate of a project under a new name.
Access to Creating Additional Context Templates

In both Windchill PDMLink and Windchill ProjectLink, you can save a product, library, or project container as a new template from the details page of the container, or you can export an existing product, library, or project container from the details page of the container. The actions available from the details page include the following: The Save As <context> Template action provides a way to create a new template from the current context. In the action, <context> is either Product, Library, or Project, depending on the context you are viewing. A newly created product, library, or project template is saved in the application container's organization context and appears in the Templates table of that context when the Current View is <context> Templates. The Export As Template action allows you to export the current product, library, or project context as a template, creating a ZIP file on your system.
3-23
You can then import the exported template into Windchill PDMLink or Windchill ProjectLink by navigating to the organization under which you want the template imported and clicking the Templates link. From the Templates table that appears, select the type of template from the Current View and click Import Template. This creates a template with the same name as the exported template. If you want to specify a different name for the template, choose Create Template instead of Import Template to import the exported template.
Administering Domains and Policies

This section describes how domains and policies are defined. A domain is an administrative area that defines a set of administrative policies, such as access control, indexing, and notification. Objects associated with a domain are subject to its policies. A policy is a collection of rules designed for various types of objects associated with a domain. For example, an indexing policy consists of rules that determine the types of objects for which metadata should be entered into specified collections, when the objects belong to the domain. Before creating a container in Windchill PDMLink and Windchill ProjectLink, you should determine which domains are needed and use a template that creates the domains and the policies for those domains when you create the container. For details on what domains and policies are included in the out-of-the-box templates, see the following chapters: Organization templates are describe in Administering Organizations. Product and library templates are describe in Administering Products and Libraries. Project templates are describe in Administering Projects.
After a container is created, you can use the Policy Administrator to administer the domains in the container. The following sections provide information about installed domains and how to use the Policy Administrator to administer the domains.
Container and Domain Hierarchy Overview

Container types have the following established hierarchy:
3-24
When each container is created, a set of domains is also created for use within the container context. Generally, the domain hierarchy is established using the container hierarchy. A parent domain is either in the same container as its child domain or in the parent container of its child domain's container (Windchill PDM being the exception to this rule). In the following diagram, the site, organization, and library containers are shown with one domain defined in each container. The domain hierarchy shows domain3 (in the library container) as a child of domain2 (in the organization context) and domain2 as a child of domain1 (in the site container):
To illustrate this rule, consider the following examples: Assume that the Windchill PDMLink installation creates the Site container and has a child organization container that is named Bike Company, and that an administrator (using an out-of-the-box library template) creates a library container named Sales that is a child of the Bike Company container. Then the domain hierarchy for the Windchill PDMLink Sales library is as follows:
/ (Site) |-Default (Organization Bike Company) |-PDM (Organization Bike Company) |-Default (Library Sales) |-Private (Organization Bike Company) |-System (Library Sales)
Assume that the Windchill ProjectLink installation creates the Site container and has a child organization container that is named Bike Company, and that an administrator (using an out-of-the-box project template) creates a project container named Super Bike that is a child of the Bike Company container. Then the domain hierarchy for the Windchill ProjectLink Super Bike project is as follows:
/ (Site) |-Default (Organization Bike Company) |-Project (Organization Bike Company) |-Sales (Organization Bike Company) |-Default (Project Super Bike) |-Private (Organization Bike Company) |-System (Project Super Bike)
3-25
Assume that the Windchill PDM installation loads the Windchill PDM library container as a child of Bike Company organization container and the organization container is a child of the Site (root) container. When only the out-of-the-box load files are used, the domain hierarchy for the Windchill PDM library does not include domains from the organization container. Instead, the ChangeItems domain in the Windchill PDM library container inherits directly from root (/) as follows:
/ (Site) |-ChangeItems (Library Windchill PDM)
Domains in the Site Container

When a Windchill solution is installed, the following domains are initially defined in the Site container:
Domain Names Description
/ (root ) System
Sets rules that govern the entire enterprise. Serves as the default domain for most system administration objects, including queues and life cycle definitions. System is the default domain of the Administrators group. The System domain is not intended for general user business objects.
User
Serves as the default domain for organization objects and as the parent domain for the Unaffiliated domain and for organization container domains that hold the users (and their personal cabinets) for that organization. Serves as the default domain for other business information objects. This domain is primarily for use at system startup. Serves as the default domain for internal session processes. Do not modify the policies set for this domain.
Default
SessionIterationDomain
3-26
Domain Names
Description
Unaffiliated
Serves as the default domain for users who are not associated with any organization. These users do not have the organization attribute set in their directory service entry. The Unaffiliated domain is a child domain of the User domain.
The root, System, User, and Default domains cannot be moved or deleted. Also the domain names of these domains and of the Unaffiliated domain are configured through the wt.properties file. The System, User, Default, and SessionIterationDomain domains belong to the / (root) domain. Additional domains can be defined and associated with the root domain, or domains can be nested by defining them as children of another domain. This allows you to define a hierarchy of domains and then define policies at each level in the hierarchy.
Creating Domains
Windchill automatically creates domains as follows: During installation, as described earlier in this chapter. When you create containers. Each container template defines a set of domains that are created. Each time Windchill identifies a user that is affiliated with an organization that does not have an associated domain, Windchill creates the corresponding domain for the organization as a child domain of the User domain.
In addition, administrators can manually create domains. The name of a domain can be a maximum of 200 characters. When Windchill automatically creates the domains associated with organizations, the domain name is usually the same as the organization name. However, organization names can be up to 2000 characters. Therefore to name the domain, Windchill truncates the organization name to 193 characters. This allows Windchill to add a maximum of seven more characters to the domain name to identify a unique name when two or more organizations have the same beginning 193 characters in their names. When the truncated domain name is not unique, Windchill appends [1] to the truncated name. If appending [1] to the name does not make it unique, then Windchill appends [2] instead of [1]. If appending [2] does not make the name unique, then [3] is appended and so on until a unique name is found or until the maximum number of attempts to find a unique name is achieved. The maximum number of attempts is defined in the following property in the wt.properties file: wt.inf.container.WTContainerServerHelper.maxDomainCreationAttempts
3-27
The default value for this property is 25. Note: After Windchill creates a domain that is associated with an organization, an administrator can change the domain name to something more meaningful; Windchill does not rely on the organization domain name matching the organization name.
Defining Domain-based Policies

The load files and templates used to create containers include sets of domainbased policies that govern how users, groups, and organizations interact with the data in each domain. Additionally, you can create additional domains and define or change the rules set for each domain. For example, you can define the following: An access control policy, which determines user, group, and organization permissions to access objects associated with the domain. An indexing policy, which determines the collections into which metadata for an object is entered when the object is in a specific life cycle state. A notification policy, which determines who is informed when an event of interest occurs to an object in the domain.
Note: Policy rules apply to object types. Access to an instance of an object type can be governed by ad hoc access control rules in addition to policy rules. For more information, see Administering Access Control. Also, not all objects exist within a domain. For objects to be subject to policies, they must reside in a domain. The policies that apply to an object are those policies defined for the domain to which the object belongs, as well as ancestor domains.
Using the Policy Administrator

The Policy Administrator operates within the confines of the context from which it is started. How you access the Policy Administrator is determined by your Windchill solution: From Windchill PDM, you can access the Policy Administrator by clicking the Policy Administrator link that is on the Business Administration home page. From Windchill PDMLink and Windchill ProjectLink, you can access the Policy Administrator from the Utilities pages that are under the Site, Organization, Product, Library, and Project tabs.
3-28
You begin policy administration on the Policy Administrator window. From this window, you have access to the following domains: The domains that are in the current context. The ancestor domains of the domains in the current context.
For example in Windchill PDM, the initial window is similar to the following:
3-29
When accessing Policy Administrator from the Site Utilities page in either Windchill PDMLink or Windchill ProjectLink, the initial window is similar to the following:
The domains display in a tree view which is open to the domains at the top of the domain hierarchy within the current context. The current context appears selected in the Context drop-down list. The format of each domain in the list includes the domain name followed by the following information in parentheses: The type of context (for organization and application contexts) The name of the context where the domain resides
For example, if a domain in the list is shown as Default (Library Common Parts), then the domain name is Default and the domain resides in the library context named Common Parts. If the Default domain is in the Site context, then you will see Default (Site). In this case, the context type is not displayed.
3-30
You can select any of the domains listed in the tree, or you can expand the tree to show descendent domains within the current context and then select a domain. You can also change the contents of the domain tree by using the Context dropdown list as follows: Selecting an ancestor context from the Context drop-down list updates the domain tree so that the domains in the selected context and direct ancestor domains are available. The contexts listed in the Context drop-down list are formatted as the context type followed by the context name. Selecting All Contexts from the Context drop-down list updates the domain tree so that all domains from all contexts are available.
Note: The buttons that are enabled when you select a domain are determined by the Policy Administrator. For example, if you select a domain that cannot be deleted (such as the Default (Site) domain, the Delete button is disabled.
Specifying Policy Rules in a Context Template

For Windchill PDMLink, the recommended method for including a specific set of policy rules in a context template is to set the rules in an existing container (along with any other administrative items you want in the template) using the Policy Administrator and then either save the current context as a template or export the context to a ZIP file on your system. Be sure to select the Access Policy Rules option when you save or export the existing template. For Windchill ProjectLink, you cannot save the policy rules set in a current context when creating a template from the current context or when exporting the context. For information on creating context templates, see Creating Context Templates.
3-31
Administering Object Initialization Rules

The Object Initialization Rules administrator provides a way to specify default values for the attributes of a specific object type. The default values are then used when the Windchill solution creates objects of that type. These specifications are called rules. Each rule can contain default values for one object type. The rules that are set only apply when the Windchill solution that is used to create an object does not set a corresponding value. Note: In Windchill PDM, the application clients set values for folder paths, life cycle templates, and team templates. Default values are never used in these cases. The following sections provide information on rules that are loaded during installation, how to add rules, and how rules work.
Loading Object Initialization Rules

A set of rules is loaded during installation and additional sets are included in the context templates that are loaded (if either Windchill PDMLink or Windchill ProjectLink is installed). The following rules are set: For all Windchill solutions, a rules load file sets the initial numbering and versioning rules for WTDocument and WTPart. For Windchill PDM, a rules load file sets the rules for the change objects that include setting values for the folder, life cycle, and numbering scheme. For Windchill PDM and CMII, a rules load file sets the rules for the change objects. These rules include the setting of the team template and the setting of different life cycle values. For Windchill PDMLink, a rules load file sets the rules for WTDocument and WTPart attributes in addition to the numbering and versioning rules set for all solutions, as well as numbering rules for the change objects. For Windchill ProjectLink, a rules load file sets the rules for document soft types that are defined for WTDocument.
The rules that are loaded are named according to the object type to which the rule applies and appear with a site context. For additional information, see Installed Site Container Object Initialization Rules.
Adding Object Initialization Rules

You can add rules for the creation of an object, as follows: By using the Object Initialization Rules administrator. By creating additional context templates from within Windchill PDMLink or Windchill ProjectLink or updating existing templates. For information about context templates, see Container Templates.
3-32
Accessing the Object Initialization Rules Administrator

You can access the Object Initialization Rules administrator as follows: In Windchill PDM, it is available from the Business Administration page. In Windchill ProjectLink, it is available from the project, organization and Site Utilities pages. In Windchill PDMLink, it is available from the product, library, organization, and Site Utilities pages.
Clicking the Object Initialization Rules administrator link displays the Object Initialization Rules table where all rules that have been added in the current context or ancestor contexts are listed.
How Object Initialization Rules Work

Where a rule is created determines which objects are affected by the rule: Rules set during installation affect all objects of the types specified in the load file. Rules set from the Business Administration page affect all objects of the types specified that are initialized in the Windchill PDM context after the rule is set. Rules set from the site Utilities page affect all objects of the types specified that are initialized in the site context after the rule is set. Rules set from the organization Utilities page affect only those objects of the types specified that are initialized by a user from the organization under which the rule was set. Similar restrictions are in place for those rules set for project, products, and libraries, where the rules only apply to the project, product, or library under which the rules are set.
Rules for an object type that are set at one context do not replace other rules that are set at a higher context, but all rules are merged to create a composite rule. For example, a rule for WTpart numbering and versioning can be set at the Site context and a rule for WTPart folders can be set at the product or organization context. Then the composite rule for WTpart objects created under the product or organization includes both the setting for numbering and versioning, and the setting for folders. If the product rule had included setting the numbering scheme, then this rule setting would take precedence over the setting made at the site context.
3-33
If a default value is not set for an object attribute in the composite rule that is in place and the user creating the object does not specify a value for the attribute, then one of the following occurs: If the underlying code provides a default, then it is used. For example, if the rule does not set the default life cycle state, then the Life Cycle service would use its property value to set a default state. If there is no underlying code that provides a default, then the attribute value is set to NULL.
Determining the Composite Rule

To determine what object initialization rule is in effect for an object type in a specific context, you can generate the composite rule for the object type. Use the following steps to generate and display the composite rule: 1. Access the Object Initialization Rules Administrator from the context in which you want the composite rule generated, as described in Accessing the Object Initialization Rules Administrator. 2. Click Download Composite .
The Download Composite Object Initialization Rule window opens. 3. Enter a valid object type. Valid object types are of any of the object types listed in the Object Type column of the Object Initialization Rules table. 4. Click OK to initiate the download process. or Click Cancel to cancel the process. How the download occurs depends on how your system is configured. Your system may be set up to display the XML in an XML editor or a browser. From the display, you can save the XML; otherwise, you may be prompted to save the XML in a file. The following XML shows a sample composite rule for the wt.doc.WTDocument object type (formatted to fit on this page):
- <AttributeValues objType="wt.doc.WTDocument"> -  - <AttrValue id="folder.id" algorithm="com.ptc.core.foundation.folder.server.impl. FolderPathAttributeAlgorithm"> <Arg>/Default</Arg> </AttrValue> -  - <AttrValue id="lifeCycle.id" algorithm="com.ptc.core.foundation.lifecycle.server.impl. LifeCycleTemplateAttributeAlgorithm"> <Arg>Basic</Arg> </AttrValue>
3-34
-  - <AttrValue id="teamTemplate.id" algorithm="com.ptc.core.foundation.team.server.impl. TeamTemplateAttributeAlgorithm"> <Arg>Default</Arg> </AttrValue> -  - <AttrValue id="number" algorithm="com.ptc.windchill.enterprise.revisionControlled.server.impl. NumberGenerator"> <Arg>{GEN:wt.enterprise.SequenceGenerator:WTDOCUMENTID_seq:10:0}</Arg> </AttrValue> -  - <AttrValue id="MBA|versionInfo" algorithm="com.ptc.core.foundation.vc.server.impl.VersionInfoGenerator"> <Arg>wt.series.HarvardSeries</Arg> </AttrValue> </AttributeValues>
In this rule, the following wt.doc.WTDocument attribute default values are set: The folder.id default value is set to Default. The lifecycle.id default value is set to Basic. The teamTemplate.id default value is set to Default. The number default value (which sets the numbering scheme) is set to {GEN:wt.enterprise.SequenceGenerator:WTDOCUMENTID_seq:10:0}. The MBA|versionInfo default value (which sets the versioning scheme) is set to wt.series.HarvardSeries.
For an explanation of what the numbering scheme and versioning scheme default values mean, refer to the Object Initialization Rules help. To access the help, click the help icon on the Object Initialization Rules table.
Specifying Rules in the Object Initialization Rules Administrator

An object initialization rule is specified in an XML document that is formatted according to the object initialization rules DTD. You can download this DTD from the Object Initialization Rules table as follows: 1. Access the Object Initialization Rules administrator from the context in which you want to create the rule, as described in Accessing the Object Initialization Rules Administrator. 2. From the Object Initialization Rules table, click Download DTD .
Your system may be set up to display the DTD in an XML editor or a browser. From the display, you can save the DTD; otherwise, you may be prompted to save the DTD in a file.
3-35
3. Create the XML document for the rule you want to create, validating it against the DTD you downloaded in Step 1. The content of the XML document is described in the next section. 4. Click Create Rule .
The Create Object Initialization Rule window opens. 5. Enter values in the fields provided. For help on what to enter in the fields, click the help icon; browse to the XML document you created in Step 3 for the value to specify in XML File field. 6. Click OK to create the rule.
Content of Object Initialization Rules XML Documents

Each object initialization rules XML document must contain the following: The type of object for which the default attribute values are being set. For example, use the following XML for documents, where the object type is wt.doc.WTDocument:
<AttributeValues objType="wt.doc.WTDocument"> </AttributeValues>
The attributes for which default values are being set. The attributes can include any modeled or soft attributes that have been defined for the object type. An attribute must be named by its logical ID. For information on attribute logical IDs, see Using Types and the Type Manager. For example, use the following XML to identify the document folder path:
<AttrValue id="folder.id"> .</AttrValue>
3-36
The algorithms that are used to set the default values; you specify an algorithm for each attribute. Out of the box, Windchill provides the following algorithms (names are shown on multiple lines in the table; enter the name of the algorithm on one line):
Description
Algorithm
com.ptc.core.foundation.folder.server.impl. FolderPathAttributeAlgorithm com.ptc.core.foundation.lifecycle.server.impl. LifeCycleTemplateAttributeAlgorithm com.ptc.core.foundation.team.server.impl. TeamTemplateAttributeAlgorithm com.ptc.windchill.enterprise.revisionControlled. server.impl.NumberGenerator com.ptc.core.foundation.vc.server.impl. VersionInfoGenerator wt.rule.algorithm.StringConstant wt.rule.algorithm.EnumTypeConstant
Converts folder path into a type instance identifier of the specified folder. Converts the specified life cycle name into a type instance identifier of the life cycle. Converts the specified team template name into a type instance identifier of the team template. Implements the numbering scheme identified in the generator function that is specified in the argument. Implements the versioning scheme that is specified in the argument. Converts the specified value into a string. Converts the specified value into an enumerated value.
For example, use the following XML to specify the document folder path algorithm:
algorithm="com.ptc.core.foundation.folder.server.impl.FolderPathAttributeAlgorithm"
Any additional arguments that are needed to set the default values. Each outof-the-box algorithm requires one argument that is used to identify the default value. For example, use the following XML to specify the default document folder path as Default:
<Arg>/Default</Arg>
The number attribute requires that you specify a generator function as the argument. The function is used to generate the numbers. For details on numbering, see Object Initialization Rules help by clicking the help icon on the Object Initialization Rules table.
3-37
Example XML Document

The complete example XML document for a default document folder path for a document is as follows:
<AttributeValues objType="wt.doc.WTDocument"> <AttrValue id="folder.id"> algorithm="com.ptc.core.foundation.folder.server.impl.FolderPathAttributeAlgorithm" <Arg>/Default</Arg> </AttrValue> </AttributeValues>
Note: To set default values for object attributes that are not folder paths, life cycle attributes, team template attributes, the default numbering scheme, the default versioning schemes, strings, or enumerated types, you must implement a new algorithm and then specify the algorithm and its arguments in the XML document.
Specifying Object Initialization Rules in a Context Template

The recommended method for including a specific set of object initialization rules in a context template is to set the rules in an existing container (along with any other administrative items you want in the template) using the Object Initialization Administrator and then either save the current context as a template or export the context to a ZIP file on your system. Be sure to select the Object Initialization Rules option when you save or export the existing template. For information on creating context templates, see Creating Context Templates.
3-38
Searching for Principals

The following administrative clients use a common interface when searching for principals (users, groups, and organizations): Policy Administrator -- When working with policy rules, you select principals against which the rules are applied. Life Cycle Administrator -- When defining a life cycle template, you can select principals as participants for any of the roles defined for that life cycle template. Team Template Administrator -- When defining teams, you can select principals as participants for roles. Workflow Administrator -- When defining activities, you can select principals to complete each assigned activity.
In these administrative clients, the ability to locate users and organizations is determined by the administrators access permissions. A search returns all users and organizations for which the administrator has Read permission. In the administrative clients, the search scope used to locate groups is determined by the type of administrator as follows: Site administrators: Search the bundled Aphelion directory service at the site containers base node, limiting the search to the current directory hierarchy level. In other services, search with the default search scope.
Organization administrators: Only search the bundled Aphelion directory service as follows: Search the public node, limiting the search to the current directory hierarchy level. The public node is where the groups created under the organization context are located. Search the Site containers base node, limiting the search to the current directory hierarchy level.
3-39
Windchill PDM administrators: Search the bundled Aphelion directory service as follows: Search the Windchill PDM Library containers base node, limiting the search to the current directory hierarchy level. Search the parent organizations public node, limiting the search to the current directory hierarchy level. Search the site containers base node, limiting the search to the current directory hierarchy level.
Search all other services with their default search scope.
Windchill PDMLink product and library administrators: Only search the bundled Aphelion directory service as follows: Search the applications containers node for internal groups with subtree scope. This scope starts the search at the current level and searches all levels of the complete LDAP hierarchy below the current level. Search the parent organizations public node, limiting the search to the current directory hierarchy level. Search the site containers base node, limiting the search to the current directory hierarchy level.
The bundled Aphelion directory service is set up during installation and uses the bundled JNDI adapter. For additional information about setting up directory services and JNDI adapters, see the Configure Windchill to Use an Enterprise Directory chapter in the Windchill Installation and Configuration Guide.
3-40
4
Administering the Site
This chapter provides an overview for administering the site and describes the typical duties that a site administrator performs. It also provides additional information about some of the main administrative tasks for sites. Topic Page
Overview .............................................................................................................4-2 Typical Duties of Site Administrators.................................................................4-2 Out-of-the-Box Site Container Configuration.....................................................4-8 About the Site Tab...............................................................................................4-8 Best Practices for Windchill PDMLink and Windchill ProjectLink...................4-9
4-1
Overview
The site administrator manages the organizations within the site and is responsible for the common information and rules inherited by all containers in the site. The site administrator (for example, wcadmin) created at installation time may be a temporary administrator specified only to get the system up and running for the customer. If that is true, create a user who is associated with the hosting organization and add that person to the Administrators group. That person will then take over as the site administrator once the quick start program is completed. For general information about container contents and how to create containers, see Administering Containers. Note: The general information in this chapter pertains to all Windchill systems, but is more specific to Windchill PDMLink and Windchill ProjectLink. The site administrator for Windchill PDMLink and Windchill ProjectLink performs these actions from the Site tab of the user interface.
Typical Duties of Site Administrators

Site administrators are responsible for the configuration and management of the Windchill system as a whole. They create organizations representing business units of a hosting company and organizations representing partners and suppliers. In an exchange environment, organizations represent those companies willing to pay to use the service. By making an organization a subscriber, members of that organization have the ability to create libraries, products, and projects. Site administrators also control how authorized users are added to the system. They also define the information that is common across all organizations and their products, libraries, and projects. Responsibilities of the site administrator include the following: Create and update organizations participating in the site. Manage overall exchange access (control users that have access to the exchange service). Manage a group of users with site administration privileges. Manage site-level folders, documents, and links. Manage site-level access policies and rules. Manage site-level types and type-specific attributes that are inherited by all contexts in the site. Manage the rules governing object creation. Manage site-level templates that are inherited by child contexts. Perform security audits to track access to specific products, projects, documents, and parts.
4-2
Manage site configuration (such as vaulting, replication, calendar, and preferences). Manage processes (such as workflow, CAD viewable publishing, and replication). Export and import site-level information. Define and manage reports.
Creating and Managing Organizations

The Windchill PDM installation creates an organization object and associates the object to an organization container. In Windchill PDM, you cannot create additional organization containers. The Windchill PDMLink and Windchill ProjectLink installations create an organization object that is associated with the site container, but do not create the organization container. Before users access the solution, create an organization container. You can associate it with the organization object that was created during the installation, or you can create a new object. Users who have an organization attribute (the "o" attribute, by default) that matches the organization name automatically become members of the organization. Note: You can create organization containers from either the Site tab or the Organization tab. There is no difference in the type of organization created; it is a convenience to be able to create an organization from the Organization tab. When you create an organization, you can grant privileges so the organization can create its own projects, products, or libraries, or you can restrict participation to only products, projects, and libraries created by a parent company that is hosting the organization. When you create an organization, you can grant its members full access to a corporate directory with which the system is configured. The purpose is to allow employees of a company that is hosting the Windchill system the ability to search their entire directory for users and groups. You can review the list of organizations in the site and navigate to update each of the organizations. A company will probably choose to administer the organizations representing their partners or customers. In this way, you become the organization administrator on behalf of any number of organizations defined in the site.
4-3
When a Windchill solution is installed and an organization container is created, then this organization automatically owns the parts and documents that are created under the organization context. In all Windchill solutions, you can create additional organization objects (using the Principal Administrator) and allow users to select the organization that owns parts and documents. To change the outof-the-box functionality so that a user who creates a part or document can specify which organization owns the part or document by specifying the organization ID, see Administering Runtime Services in the Windchill System Administrators Guide.
Adding and Updating Members

You control how members are added to the site to enable them to log on and view and author information in the site. You can use several options. One option is for you to add each member to the site using the Principal Administrator utility. Another option is to establish a workflow process for requesting and approving members. You can also define the users who have site administration privileges so that several individuals in the company can play this role. For Windchill ProjectLink sites, you can allow users to register to the site through a registration interface and then automatically add the users as members when they complete the registration. For more information about using the Principal Administrator utility, see Using the Principal Administrator in Administering Principals later in this manual.
Creating and Managing Site Folders and Documents

You can define documents, folders, and links within the site context. The site folders are designed to hold any documents that are important for the administering the site. Types of documents that administrators might define at the site include the following: System configuration documentation System change log that captures a record of changes made to the system Operation rules and procedures (such as shutdown, backup and restart procedures) System administrator responsibilities document Key contact list for system administrators Deployment schedule and plans (this might also be defined in a project but referenced by providing a link in the site folder) Documents describing site-level document, life cycle, and workflow templates
4-4
Managing Site-level Types and Type-specific Attributes

You can define object types and type-specific attributes to make available to all organizations in the system. For example, a company might define a change impact report document type with specific attributes for each of several categories, including replacement cost, production tooling cost, and so forth. You can associate document types with life cycles that identify the various states of maturity of the document.
Managing Site-level Templates

A company may choose to define a number of document, life cycle, and workflow templates that they want all their business units and partners to use. For example, the site may want to define a document template and associated life cycle and workflow process for capturing enhancement requests for the Windchill system. Or a company may want to make a corporate presentation template available to all its business units collaborating in the exchange. The site can define project, product, library, and organization templates. Organization templates are required to create organizations. You can configure how objects of various types are created and their attributes initialized using a rules administration utility. This utility defines how the initial values for the object are established and can determine basic relationships, such as life cycle association, when an object is created. The rules established by the parent site are inherited by each organization by default, but they can be overridden by an organization. The rules are defined in an XML format, which the site administrator can view and edit.
Auditing System Information

For security or other reasons, you may need to examine the audit logs for specific members, or to determine who has accessed or modified a particular document, part, project, or product. If there is concern that a user obtained access to projects or products to which that user should not have been invited or granted access to, an audit history record for the user can be reviewed to determine which projects, products, and documents the user viewed or updated. You must enable auditing to ensure the audit events of interest are recorded by the system. See Enabling Auditing in the Administering Audit Reports chapter later in this manual for more information. Administrators should audit only the events that are necessary because the audit record consumes a significant amount of database table space.
4-5
Creating and Managing Access Control Policies

You can define polices that control the level of access to information to the system. For example, as site administrator, you may want to provide read access to all documents of type Engineering Specification to an engineering group. You need to first define an Engineering Group and populate it with the appropriate members, then define a document type of Engineering Specification at the site level, and then use the Policy Administrator at the site level to define the access policy based on the document type, the group or groups provided access and the access level. You should create only those site-level policies that provide broad access for types of information defined at the site level for all organizations in the system. For more information about access control, see Administering Access Control later in this manual.
Configuring External Vaults or Replication Sites to Optimize Performance

You can configure external file vaults so that document and part content is stored on a file system rather than in the database. This type of configuration can provide significant upload performance improvements and is appropriate when the site is frequently used to exchange large files (such as CAD model files). By default, external storage rules are based on individual domains in each container. You can launch the External Storage Administrator client from the Utilities page in the context of a product, a library, an organization, or the site. The client allows you to create vaulting rules for the domains - System and Default - associated with the container in which the client is launched. Note: The rules needed for setting up an external file vault for a product or library cannot be inherited from the organization or site. If the increased number of vaults and file vault rules becomes unmanageable, you can force vaulting to be accomplished through a single vault by setting the wt.fv.forceContentToVault property to true. For how to set external file vault rules or set up a single vault, see Administering External File Vaults in the Windchill System Administrators Guide. You can also configure replication sites so the document and part content files are replicated at a remote site where local users have only very low bandwidth connections to the Windchill server. You would typically define only the replica site and the replication schedule. The product, library, or project managers would configure the replication rules for a particular site. For how to set replication rules, see Administering Content Replication in the Windchill System Administrators Guide.
4-6
Configuring Numbering and Versioning Schemes and Units of Measure

You can configure the number and version scheme used to uniquely identify parts, documents, and other objects in the system. The set-level schemes and units of measure are inherited by the organizations, but each organization can optionally define its own schemes. In general, when a company is hosting Windchill for its internal use, the numbering, versioning, and units of measure should all be defined at the site level and should not be overridden by organizational units. This approach ensures consistence of basic identification and units across the company. For additional information, see Administering Object Initialization Rules.
Configuring and Managing CAD Publishing Utilities

You can configure CAD workers that publish viewables for CAD models that can be accessed by participants that do not have native CAD authoring tools. The site includes utilities to configure the CAD workers and monitor and manage the publishing schedules and queues. For additional information, see Administering Visualization Services
Creating, Updating, and Managing Custom Reports

You can create and update custom reports against the objects and attributes in the system as a whole.
Importing and Exporting Information Among Systems

You can exchange information between a staging server and production server, between servers, or between a server and a file system using the Windchill import/export utilities. These utilities read and write system information in an XML format. For general import and export information, see Windchill Import and Export in the Windchill System Administrators Guide. The workflow and life cycle administration utilities accessible to the site and organization administrator integrate the import and export functions with administering workflows and life cycles. For life cycle import and export information, see Import and Export in the Administering Life Cycles chapter. For workflow import and export information, see Import and Export in the Administering Workflows chapter.
Managing Overall System Configuration and Preferences

There are many system configuration settings you can view, set, and update remotely using the system preferences and system configuration utilities. Use these utilities to view and set system properties, view and manage queues, and view server status and logs. For more information, see the Windchill System Administrators Guide.
4-7
Monitoring Enterprise Systems Transactions Log

If you configured Windchill to exchange information with an Enterprise Resource Planning (ERP) system, you can monitor the transactions with the ERP system through the Enterprise Systems Transactions Log. For more information, see the Windchill Enterprise Systems Integration Administrators Guide.
Out-of-the-Box Site Container Configuration

When Windchill PDMLink or Windchill ProjectLink is installed, the following are defined for the site: Container structure; for more information, see Installed Site Container Structure. Container participation; for more information, see Installed Site Container Participation. Container policies; for more information, see Installed Site Container Policies. Container data; for more information, see Installed Site Container Data Types and Attributes. Container templates; for more information, see Installed Site Container Templates. Container rules; for more information, see Installed Site Container Object Initialization Rules.
About the Site Tab

For Windchill PDMLink and Windchill ProjectLink, the Site tab provides access to the following pages:
Page Description
Organizations Folders
Allows you to create, view, update, or subscribe to organizations. Allows you to view information about and add information to folders. This is where the site administrator can store information needed for administering the site. Allows you to view, add, or remove users from the site administrators group. Allows you to create and update document types. This page also provides access to the Life Cycle Administrator, Attribute Manager, and Type Manager.
Administrators Types
4-8
Page
Description
Templates Audit Reports Utilities
Allows you to view, create, or update templates. Allows you to create and update custom reports against the objects and attributes in the system. Allows access to utilities available to your site
Best Practices for Windchill PDMLink and Windchill ProjectLink

Setting Default Preferences in Windchill ProjectLink to Collapse Tables
In order to cut down the time it takes to load tables, you can create a site preference to collapse tables for document and part iteration history pages. The following can be set to collapse tables by default. For a document iteration history table:
name: "history$doc_list$::ccomp" and value: "1"
For a part iteration history table:

name: "history$part_list$::ccomp" name: "forum$discussTable$::ccomp" name: "notebook$reference$::ccomp" and value: "1" and value: "1" and value: "1"
You can use the xconfmanager utility to add the following wt.property to make all components collapsed:
com.ptc.netmarkets.defaultTablesCollapsed=true
For more information about using the xconfmanager, see Administration Overview.
4-9
4-10
5
Administering Organizations
This chapter provides an overview for administering organizations and describes the typical duties that an organization administrator performs. It also provides additional information about some of the main administrative tasks for organizations. Topic Page
Overview .............................................................................................................5-2 Typical Duties of Organization Administrators ..................................................5-3 Out-of-the-Box Organization Templates.............................................................5-7 Creating an Organization...................................................................................5-13 Using the Organization Utilities Page ...............................................................5-15 Best Practices for Windchill PDMLink and Windchill ProjectLink.................5-15
5-1
Overview
Organization administrators are responsible for the configuration and management of an organization within the Windchill system. The organization may represent a business unit of the parent company hosting the Windchill system or it may represent a supplier or partner to the parent company. In an exchange environment, an organization represents those companies paying for the ability to create projects. Windchill solutions use organization principals (WTOrganization type) and organization containers when administering organization information. The development of products and the subsequent management of product information throughout their entire life cycle is truly a collaborative process involving a number of organizations, including suppliers, contract manufacturers, and design partners. The Windchill solutions use organization containers as follows: To define your digital product value-chain. To define data ownership responsibilities. To define the level of engagement that organizations have within your system and business processes.
All Windchill solutions, when configured, contain a host organization. This organization represents your enterprise and is associated with an organization container. The users in the host organization either author product information or in some way are consumers of this information. Windchill PDM has only one organization container (and corresponding organization principal) that is created during installation. Additional organization principals can be created using the Principal Administrator, but no additional organization containers can be created. In Windchill PDMLink and Windchill ProjectLink, organization containers (and corresponding organization principals) can be created for each of the business organizations and or business units that are collaborating together through the Windchill solutions. Each organization inherits templates (document, workflow, and life cycle templates) and groups defined in the parent site container and then defines its own organization-specific templates, groups, types and roles. A separate group of administrators is associated with each organization to manage the organization templates, groups, and policies. The organization administrator can control who is allowed to create application containers (products, libraries, and projects) within their organization. Windchill PDMLink and Windchill ProjectLink provide client user interfaces for doing most activities that are related to administering organizations. Organization administrators define the information that is common across all products, libraries, and projects hosted within the context of their organization.
5-2
This chapter contains information that an organization administrator needs to know, as well as information that a site administrator needs in order to get the organization functional.
Typical Duties of Organization Administrators

Responsibilities of the organization administrator include the following: Managing organization, groups, and roles Creating, updating, and managing organization folders and documents Managing organization-level types and type-specific attributes Managing organization templates and object creation rules Auditing activities within the organization Creating and managing access control policies Configuring numbering and versioning schemes Monitoring and managing viewable publishing Viewing project reports Importing and exporting information
Managing Organization Members, Groups, and Roles

You control the users that can administer the organization (organization administrators) and those that can create and administer products, libraries, and projects. If Windchill ProjectLink is installed, the organization has a project creators group. If Windchill PDMLink is installed, the organization has product and library creators groups. Only members of the organization can be added to the project, product, or library creators groups. Organization administrators and site administrators who are members of the organization can create projects, products, and libraries; otherwise, you must be a member of the project creators group to create projects, a member of the product creators group to create products, or a member of the library creators group to create libraries in the organization. In Windchill ProjectLink, all members of the organization, by default, are allowed to create projects and administer the projects they create. However, if the organization is set up so that members are not automatically added to the project creators group and empowered to create projects, you must manually add members to the project creators group. Projects are considered the least formal of the application contexts (product, project, and library), so it is generally appropriate to allow all users to create and administer a project.
5-3
You can create groups at the organization level that can be available when members create product, library, and project teams or when access policies are defined. For example, an organization may want to define groups for each of the functional teams with membership in the organization. An organization might define a sales and marketing group, an engineering group, a publications group, and a quality control group. These groups can then be invited to a product or project team without adding each member individually. Furthermore, when groups are updated, the updates can be refreshed to update all the teams referencing the groups without the need for each project or project manager to update their team membership. An organization inherits the roles defined at the site (as defined in the system roles resource bundle). If an organization has no roles defined, then the roles available to choose from when adding roles to a team are those defined in the RoleRB.rbinfo file. Once an organization has roles defined, the only roles available to choose from when adding roles to a team are those defined at the organization level.
Creating, Updating, and Managing Organization Folders and Documents

You can define documents, folders, and links within your organization. The organization folders are designed to hold any documents that are important for administering the organization. The following are examples of the types of documents that administrators may define at the organization level: Organization configuration documentation Organization environment change log that captures a record of changes to the organization Organization administration rules and procedures Internal training information for organization administrators Key contact list for organization administrators Documents describing organization-level types, document templates, life cycle templates, and workflow process templates.
Managing Organization-level Types and Type-specific Attributes

Organization administrators can create types; however, they cannot create attributes. You can use existing attributes created by the site administrator and link them to types for your organization. For more information about types and attributes, see Using Types and the Type Manager.
5-4
Managing Organization Templates and Object Creation Rules

An organization can define a number of document, life cycle, and workflow process templates for all its members to use. To ensure consistency and maximize efficiency, an organization may want to define templates for specifications, presentations, reports, proposals, meeting minutes, and so forth. Life cycle and workflow process templates may be associated with each of the defined templates. Each organization inherits the templates defined in the site and can either use these site-defined templates or override them by defining organization-specific templates with the same name. The organization can inherit the project, product, and library templates defined at the site, or you can override these templates by defining templates for your organization. If Windchill ProjectLink is installed, you can create project templates. If Windchill PDMLink is installed, you can create product and library templates. You can define a set of default values to configure how objects of various types are created and their attributes initialized using the Object Initialization Rules Administrator utility. With this utility, you can define how the initial values for the object are established and determine basic relationships, such as life cycle association, when an object is created in the organization. The rules established by the parent site are inherited by each organization by default, but they can be overridden by the organization. The rules are defined in XML format; you can view and update them. For more information, see Container Object Initialization Rules.
Auditing Activities Within the Organization

You may need to examine the audit logs for specific users or determine who has accessed or modified a particular document, part, project, or product. If there is concern that a user obtained access to projects or products to which that user should not have been invited, you can review the audit history record for the user to determine which projects, products, and documents the user visited and viewed or updated. In order to create the audit record, the auditing capability must be enabled at the site level. For more information, see Administering Audit Reports.
Creating and Managing Access Control Policies

You can define policies that control the level of access to information by its members. For example, you may want to provide read access to all documents of type Engineering Specification to an engineering group in your organization. In this case, you need to first define an Engineering group and populate it with the appropriate members, then define a document type of Engineering Specification in your organization, and then use the Policy Administrator to define the access policy based on the document type, the group or groups provided access, and the access level.
5-5
You can create organization-level policies that apply to the entire organization, from the Utilities page of the Organization tab. To establish site-level policies, create those policies that apply to all organizations in the system from the Utilities page of the Site tab. For more information about access control, see Administering Access Control.
Configuring Numbering and Versioning Schemes

You can configure the number and versioning schemes used to uniquely identify parts, documents, and other objects in the organization. The organization inherits site-level schemes, but can optionally define its own schemes. In general, when a company is hosting Windchill for its internal users, the numbering and versioning schemes should be defined at the site level; you should not override the site-level schemes by defining schemes at the organization level. For more information about numbering and versioning schemes, see Administering Containers.
Monitoring and Managing Viewable Publishing

You can monitor and manage the publishing of viewable files that are optionally generated when CAD models are checked into products, libraries, and projects. You can also configure and update the watermarks used by the Windchill ProductView visualization tool when viewing document and part content. For more information, see Administering Visualization Services.
Viewing Project Reports

You can access several predefined reports for project information. One of these reports lists projects deleted by members in the organization. You can restore projects that were inadvertently deleted by a user or empty projects to free up database space.
Importing and Exporting Information

You can exchange information with another server, or between servers, or between a server and a file system using the Windchill import/export utilities. These utilities read and write system information in an XML format. The workflow and life cycle administration utilities accessible to you integrate the import/export functions. See Import and Export in the Administering Life Cycles chapter and Import and Export in the Administering Workflow Processes chapter.
5-6
Out-of-the-Box Organization Templates

At installation, the following organization templates are loaded:
Template Name Description
General (PDMLink) General Enterprise Supplier Customer
A sample template that can be used to create an organization for Windchill PDMLink. A sample template that can be used to create a general organization for Windchill ProjectLink. A sample template that can be used to create an enterprise organization. A sample template that can be used to create a supplier organization. A sample template that can be used to create a customer organization.
The organization templates can define the same basic information that is discussed in the Container Administrative Items section of the Administering Containers chapter. The out-of-the-box organization templates define the following: Container structure Container participation Container access control policies Container data
The following sections describe the items that are defined in the templates.
Container Structure
The organization templates define the following folder structure: Change Log, General, and Policies. Some organization templates define groups that are automatically included in the organization. You can add users to the groups.
5-7
Container Participation
The following groups are automatically created when an organization is created: Organization administrators Product creators (Windchill PDMLink) Library creators (Windchill PDMLink) Project creators (Windchill ProjectLink)
Container Access Control Policies

Users who are members of the site Administrators group are granted Full Control to all object types at the site root domain. Users who are members of the organization Administrators group are granted Full Control to all object types at the root domains of the Organization (Default, System, Private, and User with the same name as the organization). During the creation of an Organization container, additional domain-based access control rules are automatically created as follows: In the organizations System domain, the organizations All Participating Members group is granted read access to templates (such as document templates, life cycle templates, and workflow templates), objects, and initialization rules. For the complete list, see System Domain Rules. In the organizations User domain, the organizations All Participating Members group is granted read access to the organization container and organization.
Additional domain-based access control rules can be defined within an organization template. The following is a list of the access control rules defined in the out-of-the-box organization templates: In the General (PDMLink) organization template, organization members (all users) are granted read access to all Released objects in the organizations /Default/PDM domain. Only product and library containers are affected by this rule. In the Enterprise organization template, project type groups are granted read access to projects contained in the project type domains. For example, a project of type Engineering has a corresponding group and organization domain. An access control rule is defined granting read access to the Engineering group in the Engineering domain. When a project of type Engineering is created, the project is put in the Engineering domain. A user who is added to the Engineering group is able to see all projects of type Engineering.
5-8
PTC recommends that you do not modify or delete the default set of access control rules automatically created during the creation of an organization, product, library, or project containers. It is acceptable to modify access control rules created from a template. To adjust access control rules, use the Policy Administrator. To launch the Policy Administrator in the context of the organization, navigate to the Utilities page under the Organization tab, and click Policy Administrator. By launching the Policy Administrator from the Organization tab, the context is set to the organization context. In this context, only the domains and subdomains of the organization plus any ancestor domains from the site are visible. Members of the organizations Administrators group can create and modify rules within the organizations domains. Below is a list of some of the automatically created organization domains with some basic rules: /Default Rules created at this level are inherited by the default domains of all public products, libraries, and projects contained within the organization. Typically, only business objects belong to this domain. /Default/PDM Rules created at this level are inherited by the default domains of all public products and libraries contained within the organization. Typically, only business objects belong to this domain. /Default/Project Rules created at this level are inherited by the default domains of all public projects contained within the organization. Typically, only business objects belong to this domain. /Private Rules created at this level are inherited by the system domains of products, libraries, and projects contained within the organization. The default domain of private products, libraries, and projects also inherit these rules. PTC recommends that no additional access control rules be created within this domain. /System Typically, only administrative objects (such as document templates, team templates, and life cycle templates) are in this domain; define policies for those types.
To update the access control rules for an organization domain within the Policy Administrator, select a domain and click Update. From the Administrator Domain window, click the Access Control tab. This provides the list of existing access control rules for this domain. From this tab, you can modify or delete existing rules and create new rules. When creating or updating rules, the list of groups available from the Groups tab include groups defined at the site and organization levels. For more information, see Searching for Principals in the Administering Containers chapter.
Access Control Rules

Out-of-the-box access control rules are described in the following sections.
5-9
Default Domain Rules
No permissions are created by default in this domain.

System Domain Rules
The following table lists the combination of object type, life cycle state, and granted permissions that the Default domain out-of-the-box rules define for the organization.
Object Type State Permissions Principal
WTObject DefaultWTContainerTemplate DefaultWTContainerTemplate DefaultWTContainerTemplate WTDocument WTPart Rule FilteredDynamicEnumSet Notebook Template DefaultWTContainerTemplate Cabinet SubFolder TeamTemplate WfTemplateObject LifeCycleTemplate DefaultWTContainerTemplate
All All All All All All All All All All All All All All All All
Full Control (All) Read Read Read Read Read Read Read Read Read Read Read Read Read Read Read
ORG ADMIN LIBRARY CREATOR (for Windchill PDMLink only) PRODUCT CREATOR (for Windchill PDMLink only) PROJECT CREATOR (for Windchill ProjectLink only) All Participating Members All Participating Members All Participating Members All Participating Members All Participating Members All Participating Members All Participating Members All Participating Members All Participating Members All Participating Members All Participating Members organization principal (for Windchill PDMLink and Windchill ProjectLink only) organization principal
Notebook Template
All
Read
5-10
Note: The rules for all object types are defined programmatically when an organization container is created; they are not defined through the template that is used.
Organization User Domain (same name as the organization) Rules
The following table lists the combination of object type, life cycle state, and granted permissions that the organization user domain out-of-the-box rules define for the organization.
WTObject OrgContainer WTObject OrgContainer WTOrganization OrgContainer WTGroup WTUser
All All All All All All All All
Full Control (All) Read Full Control (All) Read Read Read Read Read
All (for Windchill PDM) All (for Windchill PDM) ORG ADMIN All Participating Members All Participating Members organization principal organization principal organization principal
Note: The rules for all object types are defined programmatically when an organization container is created; they are not defined through the template that is used.
/Default/PDM Domain Rules for General (PDMLink) Template
The following table lists the combination of object type, life cycle state, and granted permissions that the out-of-the-box rules define for the General (PDMLink) organization template:.
WTObject
Released
Read
organization principal
Note: The rules for the WTObject object type is defined through the template.
5-11
Default/PDM Domain Rules
The following table lists the combination of object type, life cycle state, and granted permissions that the Default/PDM domain out-of-the-box rules define for the organization:.
WTLibrary PDMLinkProduct
All All
Create Create
LIBRARY CREATOR PRODUCT CREATOR
Note: The rules are set programmatically when an organization container is created.
Default/Project Domain Rules
The following table lists the combination of object type, life cycle state, and granted permissions that the Default/Project domain out-of-the-box rules define for the organization:
Project2
All
Create
PROJECT CREATOR
Note: The rules are set programmatically when an organization container is created.
Container Data
For organizations created using the General or Enterprise organization templates, document types are inherited from the site. For organizations created using the Customer or Supplier organization templates, document types include those defined in the template as well as the ones inherited from the site. The Customer and Supplier organization templates define the following document types: Analysis, Contract, Design, Drawing, Issues, Memo, Proposal, Report, Requirements, Schedule, Specification, and Statement of Work. For all organizations, document attributes, part attributes, and project types are inherited from the site.
5-12
Creating an Organization
Note: This section is for Windchill PDMLink and Windchill ProjectLink. There are two types of organizations, an organization principal (WTOrganization type) and an organization container (also known as context). The organization principal represents a group of users. Each organization principal can be associated with and manage an organization container that allows creation of products, libraries, and projects within that organization. For Windchill PDMLink, members of the organization principal that is associated with the organization container, and are product or library creators, can create products or libraries within the organization. For Windchill ProjectLink, all members of the organization, by default, can create projects if the organization is a subscriber. Members of other organization principals can participate as team members in these products, libraries, and projects. Not every organization principal should have a corresponding organization container. The overhead of managing multiple organization containers for a single company can be difficult and is discouraged. Only create an organization container if the organization principal has a need to manage its own products, libraries, and projects. Note: Only site administrators have the permissions to create organization containers. Site administrators can create organization containers (contexts) from two locations: From the Site tab, on the Organizations page, click Create Organization at the top of the Organizations table.
5-13
From the Organization tab, the icon is located in the white bar below the tabs. The Organization tab is available only if an organization has been selected from the Organization table under the Site tab.
To associate an existing organization principal to the organization container, click Search, next to the Organization Name field, to search for existing organization principals. You can also type in a new organization name (one that does not match an existing organization principal); however, a new organization principal is created along with the organization container. Note: The internet domain defined on the organization principal is important when creating new soft types. The internet domain is used to distinguish which organization owns the type. During the installation process, a default organization principal is created that contains an internet domain. The default organization principal (site administrator) is associated with the site container; any types defined at the site context are available to all organizations. In a non-exchange environment, create the first organization container and associate it with the default organization principal.
5-14
By default, the Subscriber check box is selected. This means the organization can host products and libraries (for Windchill PDMLink) and projects (for Windchill ProjectLink). For Windchill ProjectLink, the Automatically add new members to project creators group check box shows on the window (not shown in this figure) and is selected by default. By default, you are restricted to seeing only users and groups that belong to the organization. Select the Allow entire user and group directory selection check box to provide the ability to search for all users. Windchill PDMLink recommends you select this check box. For additional information, see the help available from the Create Organization window. For a description of the contents of the templates, see Out-of-the-Box Organization Templates.
Using the Organization Utilities Page

Note: This section is for Windchill PDMLink and Windchill ProjectLink. The utilities listed on the Utilities page, which is accessible by clicking the Utilities link from the Organization tab, allow you to perform administrative actions at an organization level. Some of these utilities appear on other tabs. The difference is the context from which the utility is launched. The utilities are grouped according to whether they are system administration utilities or business administration utilities. Many of links provided on the page give you access to the utilities that you need to use to perform the duties described in Typical Duties of Organization Administrators. To explore the use of each utility, click the corresponding link on the page and then click the help icon in the window that opens.

E-mail Addresses
Ensure that users have an e-mail address; many features in Windchill PDMLink and Windchill ProjectLink require that users have an e-mail address. If users do not have the e-mail attribute set in their user directory service entry, they cannot participate in the features that require an e-mail address.
5-15
Creating Only One Organization Container for Windchill PDMLink

For Windchill PDMLink, PTC recommends creating only one organization container. The default organization principal created during installation should be associated with the organization container. When creating the container, use Search to locate the installed organization principal. To provide the ability to search for all members in the system, select the Allow entire user and group directory selection check box.
Setting Default Preferences in Windchill ProjectLink to Collapse Tables

In order to cut down the time it takes to load tables, you can create a preference to collapse tables for document and part iteration history pages. The following can be set, using the Preference Manager on the Utilities page of the Organization tab, to collapse tables by default. For a document iteration history table:
name: "history$doc_list$::ccomp" and value: "1"
For a part iteration history table:

name: "history$part_list$::ccomp" name: "forum$discussTable$::ccomp" name: "notebook$reference$::ccomp" and value: "1" and value: "1" and value: "1"
You can use the xconfmanager utility to add the following wt.property to make all components collapsed:
com.ptc.netmarkets.defaultTablesCollapsed=true
For more information about using the xconfmanager, see Administration Overview.
5-16
6
Administering Products and Libraries
This chapter provides an overview for administering product and libraries in Windchill PDMLink and describes the typical duties that an administrator does. It also provides additional information about some of the main administrative tasks for products and libraries. Topic Page
Overview .............................................................................................................6-2 Typical Duties of Product and Library Administrators.......................................6-2 Out-of-the-box Product and Library Context Templates ....................................6-6 Creating a Product .............................................................................................6-15 Creating a Library .............................................................................................6-17 Administering Teams ........................................................................................6-18 Using the Product and Library Utilities Page....................................................6-19
6-1
Overview
Product and library administrators (also known as product and library managers) are responsible for managing product and library containers in Windchill PDMLink. The capabilities of product and library administrators are nearly identical. Product and library administrators control the product and library configuration, and the membership in their product and library teams within the confines of a specific product or library application container. They control access to product and library information, and they define the specific life cycles, templates and processes, and monitor and manage the product and library activities. Product application containers are used to define new product models or instances and collect all the information associated with the product. Product containers are defined by product creators who are authorized by the organization parent under which a product is created. Products inherit templates, roles, groups, and policies from their parent organization container. In addition, the administrator can define product-specific templates, roles, and policies. Library application containers are used to manage standard parts and documents that are used across products and projects in an organization. Library containers are defined and managed by authorized library creators in the parent organization parent under which a library is created. Libraries inherit templates, roles, groups, and policies from their parent organization container. In addition, the administrator can define library-specific templates, groups, roles, and policies. For general information about container contents and how to create containers, see Administering Containers.
Typical Duties of Product and Library Administrators

Product and library administrators are responsible for managing the content of products and libraries. The capabilities of product and library administrators are nearly identical. Product and library administrators are responsible for administrating the system and business aspects of products and libraries. The system administration aspects include the following: Importing and exporting data Managing external storage Managing preferences Managing replication
The business administration aspects include managing the following: Document and CAD document templates
6-2
Life cycle templates Workflow templates Team templates Report templates Object initialization rules (including numbering and versioning) Policy access rules ProductView and visualization
The following sections describe some of the duties in more detail.
Managing Team Members and Roles

You define the team members and roles for the products and libraries that you manage. Each product team has a product managers group and each library team has a library managers group. Any individual that is a member of one of these managers groups has the rights to administer the product or library after it has been created. The creator of a library or product is automatically defined as a member of the product or library managers group, and is identified as the product or library owner, by default. A product or library inherits the roles defined by its parent organization and the site. Additionally, roles can be defined in the context template used to create the product or library. You can then use these roles in the product or library, or you can add product or library-specific roles to product and library teams. For additional information, see Administering Teams.
Managing Folders
You can define folders and links within products and libraries. By default, only product or library managers can define folders and subfolders in the product or library. This is typically a good policy because it prevents members from adopting a multitude of folder organization models, thereby creating folder chaos.
Managing Templates
You can define the document, CAD document, life cycle, team, report, and workflow templates that you want used in the context of a product or library. Each product or library inherits the templates defined by its parent organization and the site. Additionally, you can create new product or library-specific templates. If the name you specify is the name of an inherited template, then the new template overrides the inherited template that has the same name. For additional information about templates, see Container Templates.
6-3
Managing Object Initialization Rules

Object initialization rules establish specific default attribute values that are used when instances of objects of a specific type are created. In Windchill PDMLink, you can set default values for the following out-of-thebox object attributes: Folder paths Life cycle attributes Team template attributes Default numbering scheme Default versioning scheme
By default, the object initialization rules established by the site are inherited by each organization and then inherited by a product or library. However, they can be overridden by an organization or overridden in a product or library. The rules are defined in an XML format and can be viewed an edited by a product or library manager. For additional information about object initialization rules, see Administering Object Initialization Rules.
Managing Access Policies

You can define policies that control the level of access to information in a product or library. When defining a policy, the object types and groups defined in the parent organization may be used as well as the groups representing the team roles in a product or library. For example, you could create a policy that provides read access to all documents of type Quality Assessment to the product team role/group called Testers. You can also choose to extend read access to this document type to an organizational group with the name Quality Assurance (if such a policy is not already granted at the parent organization level). For general information about domains and policies, see Administering Domains and Policies. For additional information about creating or updating access control rule policies, see Administering Access Control.

You can configure the number and versioning scheme used to uniquely identify parts, documents and other objects in the product or library. The numbering and versioning schemes defined at the site and organization level are inherited by products and libraries by default, but each product or library can optionally define its own schemes. Use the Object Initialization Rules Administrator to configure the number and versioning schemes.
6-4
In general, when a company is hosting Windchill for its internal use, the numbering and versioning schemes should all be defined at the Site container and should not be overridden by an organization or in a product or library. For additional information, see Administering Object Initialization Rules.
Managing Viewable Publishing

You can monitor and manage the publishing of viewable files that are optionally generated when CAD models are checked into products and libraries. You can also configure and update the watermarks used by the ProductView visualization tool when viewing document and part content from the product or library. For additional information, see Administering Visualization Services.
Managing Custom Reports

You can create and update custom reports against the objects and attributes defined within the product or library. These reports are created using a report generation utility. The reporting utility is designed for use by those with a working knowledge of the Windchill data object model. For additional information, see Administering Audit Reports.

You can import information into a product or library, and export information to a local file system. The import/export facilities support information exchange with another Windchill server or non-Windchill system. These utilities read and write system information in an XML format. For general import and export information, see the Windchill Import and Export chapter in the Windchill System Administrators Guide. The workflow and life cycle administration utilities accessible to the site and organization administrator integrate the import and export functions with administering workflows and life cycles. For life cycle import and export information, see Import and Export in the Administering Life Cycles chapter. For workflow import and export information, see Import and Export in the Administering Workflows chapter.

You can configure the vaulting and replication rules for the external file and replica sites established by the site administrator. When external vaults are configured, document and part content is stored on a file system rather than in the database. This configuration can provide significant
6-5
upload performance improvements and is appropriate when the site is frequently used to exchange large files (such as CAD model files). By default, external storage rules are based on individual domains in each container. You can launch the External Storage Administrator client from the Utilities page in the context of a product, a library, an organization, or the site. The client allows you to create vaulting rules for the domains - System and Default - associated with the container in which the client is launched. Note: The rules needed for setting up an external file vault for a product or library are not inherited from the organization or site. If the increased number of vaults and file vault rules becomes unmanageable, the site administrator can force vaulting to be accomplished through a single vault by setting the wt.fv.forceContentToVault property to true. For how to set external file vault rules or set up a single vault, see the Administering External File Vaults chapter in the Windchill System Administrators Guide. Replication sites can also be configured so that document and part content files are replicated at a remote site where local users have only very low bandwidth connections to the Windchill server. Site administrators typically define the replica site and the replication schedule, and the product or library managers configure the replication rules for a particular product or library. For how to set replication rules, see the Administering Content Replication chapter in the Windchill System Administrators Guide.
Out-of-the-box Product and Library Context Templates

When Windchill PDMLink is installed, the following product and library templates are loaded: General Product and General Library -- These templates provide examples of how to setup basic access control for a general product or library container. As described in detail later in this section, the default set of roles defined are Members, Change Admin I, Change Admin II, and Change Admin III. Also, the Guests and Product/Library Manager roles are created automatically. Some basic information about these roles is a follows: The Members role is used as a basic role to grant container team membership. A set of access rules are defined for confirmed members of the container team. Any user added to a role on the team, except the Guests role, will be added to the CONFIRMED group. The general theme for the CONFIRMED access rules is to grant Create, Modify and Delete permission in the initial state (In Work) and to grant Read permission for all states (In Work, Released, and Canceled). These rules are generated for all business objects. Access policies defined for Change Objects have been setup to work in conjunction with the CMII process.
6-6
Members of the Guest role are granted Read access to all objects.
Part Library -- This template provides an example of how you can define a parts library. The default set of roles defined are Members, Change Admin I, Change Admin II, and Change Admin III. The same theme for CONFIRMED access rules defined in the general templates are used here except rules are only defined for WTParts, CAD Documents and change objects. This restricts the use of this library for the management of parts only. Members of the Guest role are granted Read access to all objects. Document Library -- This template provides an example of how you can define a document library. The default set of roles defined are Members, Change Admin I, Change Admin II, and Change Admin III. The same theme for CONFIRMED access rules defined in the general templates are used here except only rules are only defined for WTDocuments and change objects. This would restrict the use of this library for the management of documents only. Members of the Guest role are granted Read access to all objects.
The product and library templates can define the same basic information that is discussed in the Container Administrative Items section of the Administering Containers chapter. However, the out-of-the-box templates define only the following: Container participation Container access control policies
The following sections describe the items that are defined in the General Product and General Library templates.
Out-of-the-box Container Participation

The General Product and General Library templates define roles that are automatically included in product and library teams. These roles are the roles that automatically appear on the Teams table. Additionally, roles available through the organization context can be added to the team. The following roles are automatically included in the team: Product Manager (for products) and Library Manager (for libraries) Guests, which is the role to use for users who you do not want as a member of the team, but you do want them to have limited access to the product or library. Users who are guests will not see the product or library on their Product List or Library List. They would need to search for the product or library to locate it. Out of the box, guests have only read access to product or library data.
The out-of-the-box product and library templates add following roles to the team: Members, which is a role that can be used for team members who do not belong in other roles on the team.
6-7
Change Admin I, which is the change administrator I change management role Change Admin II, which is the change administrator II change management role Change Admin III, which is the change administrator III change management role
Additionally, the following groups are created: The CONFIRMED group contains all users and groups who are added as a member of a role in the team except those added to the Guests role. The INVITED group is created, but not used for products or libraries.
Out-of-the-box Container Access Control Policies

When you create a product or library container using the out-of-the-box templates, domain-based access control rules are defined in the System and Default domains of a product or library container. The rules that are created reference the groups that correspond to the out-of-the-box roles established for the team. The following section lists the roles and their corresponding groups. Additional sections provide the out-of-the-box rules generated that reference the groups listed in the next section. Some rules are generated as a result of program code that is executed when the container is created. While other rules are generated as a result of administrative policy items that are in the out-of-the-box templates. Each of the tables in the following sections includes the Generation Method column that indicates how the rule is generated. When the method of generation is a result of executing program code, then the column contains the word "program". When the method of generation is a result of administrative policy items that are in the outof-the-box templates, then the column contains the word "template". Caution: PTC recommends that you do not modify the access control rules that are programmatically set when containers are created. Doing so can cause problems with access to data and administrative functionality. Note: There are no out-of-the-box rules set for the Members or Change Admin III roles.
Team Roles and Groups

The following table lists the out-of-the-box product or library team roles and groups, and identifies which group that is associated with each role:
Team Role Corresponding Group
Change Admin I
CHANGE ADMINISTRATOR I
6-8
Team Role
Corresponding Group
Change Admin II Change Admin III Guests Members Product Manager (products only) Library Manager (libraries only)
CHANGE ADMINISTRATOR II CHANGE ADMINISTRATOR III GUEST MEMBERS PRODUCT MANAGER LIBRARY MANAGER CONFIRMED INVITED
Note: The CONFIRMED group is not associated with a specific role. All users and groups added to any role, except the Guests role, are automatically added to the CONFIRMED group. Note: Although the INVITED group is created for all application containers, this group is not used for products and libraries.
Rules for the CONFIRMED Group

Out-of-the-box access control rules that are defined in the Default and System domains for the CONFIRMED group are described in the following sections.
Default Domain Rules for CONFIRMED Group
The following table lists the combination of object type, life cycle state, and granted permissions that the Default domain out-of-the-box rules define for the CONFIRMED group:
Object Type State Permissions Generation Method
Cabinet EPMDocument EPMDocument EPMDocument ManagedBaseline ManagedBaseline StructuredAnnotationSet
All All In Work Released All In Work All
Read Modify Read Modify Create Delete Revise Read Modify Create Delete Read
program template template template template template template
6-9
Object Type
State
Permissions
Generation Method
StructuredAnnotationSet SubFolder WTChangeActivity2 WTChangeActivity2 WTChangeActivity2 WTChangeIssue WTChangeIssue WTChangeOrder2 WTChangeOrder2 WTChangeOrder2 WTChangeProposal WTChangeRequest2 WTChangeRequest2 WTDocument WTDocument WTDocument WTPart WTPart WTPart WTPartAlternateLink WTPartSubstituteLink WTProductConfiguration WTProductConfiguration WTProductInstance2 WTProductInstance2
In Work All All Implementation Open All Open All Implementation Open Open All Open All In Work Released All In Work Released All All All In Work All In Work
Modify Create Delete Read Modify Read Modify Modify Read Modify Create Read Modify Modify Modify Create Read Modify Create Read Modify Create Delete Revise Read Modify Create Delete Revise New View Version Read Modify Create Read Modify Create Read Modify Create Delete Read Modify Create Delete
template program template template template template template template template template template template template template template template template template template template template template template template template
6-10
Object Type
State
Permissions
Generation Method
WTProductInstance2
Released
Revise New View Version
template
Note: As shown in the Generation Method column, the rules for Cabinet and SubFolder object types are defined programmatically when a product or library container is created; they are not defined through the template that is used. All other rules are defined through the template.
System Domain Rules for CONFIRMED Group
The following table lists the combination of object type, life cycle state, and granted permissions that the System domain out-of-the-box rules define for the CONFIRMED group:
WTExecutionObject WTObject
All All
Modify Create Read Read
program program
Note: As shown in the Generation Method column, these rules are defined programmatically when a product or library container is created; they are not defined through the template that is used.
Rules for the GUEST Group

Out-of-the-box access control rules for the GUEST group (Guests role) are described in the following sections.
Default Domain Rules for the GUEST Group
The following table lists the combination of object type, life cycle state, and granted permissions that the Default domain out-of-the-box rules define for guests of a product or library:
Cabinet SubFolder WTObject
All All All
Read Read Read
program program template
Note: As shown in the Generation Method column, the rules for Cabinet and SubFolder object types are set programmatically when a product or library
6-11
container is created; they are not defined through the template that is used. The rule for the WTObject object type is defined through the template.
System Domain Rules for the GUEST Group
The following table lists the combination of object type, life cycle state, and granted permissions that the System domain out-of-the-box rules define for the guests of a product or library:
WTObject
All
Read
program
Note: As shown in the Generation Method column, this rule is defined programmatically when a product or library container is created; it not defined through the template that is used.
Rules for PRODUCT MANAGER and LIBRARY MANAGER Groups

Out-of-the-box access control rules for the PRODUCT MANAGER group (Product Manager role) and LIBRARY MANAGER group (Library Manager role) are described in the following sections.
Default Domain Rule for PRODUCT MANAGER and LIBRARY MANAGER Groups
The following table lists the combination of object type, life cycle state, and granted permissions that the Default domain out-of-the-box rules define for the Product Manager or Library Manager:
WTObject
All
Full control (All)
program
System Domain Rule for PRODUCT MANAGER and LIBRARY MANAGER Groups
The following table lists the combination of object type, life cycle state, and granted permissions that the System domain out-of-the-box rules define for the Product Manager or Library Manager:
WTObject
All
Full control (All)
program
6-12
Rules in Default Domain for CHANGE ADMINISTRATOR I Group

Out-of-the-box access control rules for the CHANGE ADMINISTRATOR I group (Change Admin I role) are defined through the template and are described in the following table. The table lists the combination of object type, life cycle state, and granted permissions that are defined in the Default domain out-of-thebox rules:
WTChangeActivity2 WTChangeIssue WTChangeOrder2 WTChangeProposal WTChangeRequest2
All All All All All
Full Control (All) Full Control (All) Full Control (All) Full Control (All) Full Control (All)
template template template template template
Note: No rules are defined in the System domain for the CHANGE ADMINISTRATOR I group.
Rules in Default Domain for CHANGE ADMINISTRATOR II Group

Out-of-the-box access control rules for the CHANGE ADMINISTRATOR II group (Change Admin II role) are defined through the template and are described in the following table. The table lists the combination of object type, life cycle state, and granted permissions that are defined in the Default domain out-of-thebox rules:
WTChangeActivity2 WTChangeOrder2
All All
Full Control (All) Full Control (All)
template template
Note: No rules are defined in the System domain for the CHANGE ADMINISTRATOR II group.
Updating Access Control Rules

Caution: PTC recommends that you do not modify the access control rules that are programmatically set when containers are created. Doing so can cause problems with access to data and administrative functionality. To adjust the access control rules that are defined, you can use the Policy Administrator. Navigate to the product or library and click the Policy Administrator link from the Utilities page. Select the Default domain and click Update. From the Administrative Domain window, click the Access Control
6-13
tab to view the access control rules for the domain. From this tab, you can create new rules and update or delete existing rules. When creating or updating rules, the Groups tab shows the groups available from in the current context.These groups include the groups that map to the roles being used in the product or library team. For additional information about creating or updating access control rules, see Administering Access Control.
6-14
Creating a Product
A Windchill PDMLink product container provides the context under which a team of people can create and manage all of the information that is relevant to the design, manufacture, and support of a customer product. This information includes the following: A defined data storage area for the business objects associated with a customer product. A set of rules that control the access to the product and optionally set the numbering scheme, versioning scheme, life cycles, and workflows that are used with the objects that are associated with a product. The team of users who have access to the product.
From within a product context, the product team produces an end item. The end item is the top-level assembly in the Bill of Materials for the product that is delivered to the customer. Also, if your companys product is made up of modular assemblies which can be sold separately, additional end items can be created within an existing product context. These additional end items can be children of the top-level end item. Note: Product containers are created under an organization by members of the product creators group that is defined in the organization or by the organization administrator. Additionally, if the site administrator is a member of the organization (has the organization set in the organization attribute for Administrator user directory service entry), then the site administrator can also create products. The organization administrator can add users who are members of the organization to the product creators group by accessing the Creators link from the Organization tab. The following procedure summaries the steps needed to create a product (for detailed instructions, see the help available from the Create Product window): 1. Navigate to the Product tab and click Create Product .
Note: The icon appears only if you can create a product container. 2. Select the context template and fill in the other fields in the Create Product window. For a description of the contents of the templates, see Out-of-the-box Product and Library Context Templates.
6-15
3. Determine whether you want the product to be accessible through the normal domain-based access control rules or accessible only to the product team members. This selection is made through the Private Access check box. If the check box is selected, then the product domain structure inherits from the Private organization domain rather than the normal PDM domain. This means that access is restricted to use only the access control policies that are defined within the product context being created; access control policies are not inherited from the parent PDM context. For additional information on the domain structure, see Managing Access to Data through Access Control Rules. 4. Click OK to create the product and close the window.
6-16
Creating a Library
A Windchill PDMLink library container provides the context under which you can store and provide access to business information. For example, all documents owned by a department can be stored in a department library. Libraries can also hold objects that are not related to a single product. For example, parts that are related to more than one product could be stored in a common parts library (such as a Commodity Parts or Engineered Parts library), from which you allow multiple product teams access to those parts. In previous releases, a library was known as a repository. Note: Library containers are created under an organization by members of the library creators group or by the organization administrator. Additionally, if the site administrator is a member of the organization (has the organization set in the organization attribute for Administrator user directory service entry), then the site administrator can also create libraries. The organization administrator can add users who are members of the organization to the library creators group by accessing the Creators link that is on the Organization tab. The following procedure summaries the steps needed to create a library (for detailed instructions, see the help available from the Create Library window): 1. Navigate to the Library tab and click Create Library .
Note: The icon appears only if you are a member of the library creators group for your organization. 2. Select the context template and fill in the other fields in the Create Library window. For a description of the contents of the templates, see Out-of-the-box Product and Library Context Templates. 3. Determine whether you want the library to be accessible through the normal domain-based access control rules or accessible only to the library team members. This selection is made through the Private Access check box. If the check box is selected, then the library domain structure inherits from the Private organization domain rather than the normal PDM domain. This means that access is restricted to use only the access control policies that are defined within the library context being created; access control policies are not inherited from the parent PDM context. For additional information on the domain structure, see Managing Access to Data through Access Control Rules. 4. Click OK to create the library and close the window.
6-17
Administering Teams
One of the main activities that a product or library manager has is to administer the team associated with the product or library. When a product or library is first created, a base set of roles for the team is established from the context template that is used in the creation. For information about these roles and the access control rules that are set for the roles that are in the out-of-the-box templates, see Out-of-the-box Container Access Control Policies. To administer a product or library team, perform the following activities: Establish the roles that you want used in the team. You can add, remove, or create new roles. The base set of roles that are established through the out-of-the-box templates is the minimal set of roles that you should have for a team. (See Out-of-thebox Container Participation.) Before removing any of these roles, consider the consequences of the removal. For example in a product team, you should not remove the Product Manager role because this role defines who can administer the product. The roles you can add are roles inherited from your organization. For additional information about these roles, see Installed Site Container Participation. You can also create roles specifically for your product or library team. In addition to creating a new role through the Team page, you must define the access control rules for the role by using the Policy Administrator. As part of this activity, create the rules against the group that is created for the team role. This group has the same name as the role that you create. Note: Any new roles that you create are not available for life cycle, workflow, or team templates. Add users to the team by adding the users in the specific roles. You can add users by selecting individual users or by selecting groups that are available. For example, if the organization administrator has created groups for the organization, you can select one or more of these groups to be a member of a role. Note: When the organization container is created, the Site administrator has the option of restricting user access. By default, users are restricted so that they see only users and groups that belong to the organization. Selecting the Allow entire user and group directory selection check box when the organization container is created provides the ability to search for all users. If this check box was not selected when the container was created, the Site or organization administrator can update the organization container to select it.
6-18
From the Product or Library tab, click the Team link to access the Team table. From this table, you can administer a product or library team. For additional information about teams, see the Administering Teams and Roles.
Using the Product and Library Utilities Page

The utilities listed on the Utilities page that is accessible by clicking the Utilities link from the Product and Library tabs allow you to perform administrative actions at a product and library level. The same set of utilities appears on both the Product and Library tabs. The difference is the context from which each utility is launched: Clicking a link from a product Utilities page launches the utility within the context of the current product. Clicking a link from a library Utilities page launches the utility within the context of the current library.
The utilities are grouped according to whether they are system administration utilities or business administration utilities. Many of links provided on the page give you access to the utilities that you need to use to perform the duties described in Typical Duties of Product and Library Administrators. To explore the use of each utility, click the corresponding link on the page and then click the help icon in the window that opens.
6-19
6-20
7
Administering Windchill PDM Library
This chapter provides the an overview for administering products in Windchill PDM and describes the typical duties that an administrator does. It also provides additional information about some of the main administrative tasks for the Windchill PDM library container. Topic Page
Overview .............................................................................................................7-2 Typical Duties of Windchill PDM Administrators .............................................7-2 Out-of-the-box Windchill PDM Library Contents..............................................7-5 Creating Groups for Use in Site Domain Policies...............................................7-6 Improving Performance on Searches from Windchill Explorer..........................7-6
7-1
Overview
The Windchill PDM library container is created during the installation process and the initial Windchill PDM administrator (also know as the site or system administrator) is defined. How this container works with the other installed containers and how to set additional administrators is described in the Getting Started chapter. The Windchill PDM administrators are responsible for administering business and system functions in Windchill PDM. They define the specific life cycles, templates and processes, and monitor and manage the product activities. The Windchill PDM library container is used to define new product models or instances and to collect all the information associated with the product. For general information about containers and container contents, see Administration Overview and Administering Containers. For information about the creating products and navigating throughout the solution, see the Windchill Foundation & PDM User's Guide.
Typical Duties of Windchill PDM Administrators

Windchill PDM administrators are responsible for administrating the system and business aspects of products. The system administration aspects include the following: Importing and exporting data Managing external storage Managing preferences Managing replication
The business administration aspects include managing the following: Document and CAD document templates Life cycle templates Workflow templates Team templates Report templates Object initialization rules (including numbering and versioning) Policy access rules ProductView and visualization
7-2
Managing Groups and Roles

You define groups and roles for use in the products being created. For additional information on groups, see Administering Principals. For additional information on roles, see Administering Teams and Roles.
Managing Templates
You can define a number of document, CAD document, life cycle, team, report, and workflow templates that you want used in Windchill PDM library. The library inherits the templates defined by the site. You can add to or just use these templates, or you can override the templates by defining specific templates with the same name as the site templates you want to override. For additional information about templates, see Container Templates.
Managing Object Initialization Rules

You can configure how objects of various types are created and their attributes initialized by using the Object Initialization Rules Administrator. With this utility, you can define how the initial values for the object are established and can determine basic relationships such as life cycle association when an object is created in the product. The rules established by the site are inherited by the Windchill PDM library. The rules are defined in an XML format that you can view and edit. For additional information about object initialization rules, see Administering Object Initialization Rules.
Managing Access Policies

You can define policies that control the level of access to information in a product. When defining a policy, the object types defined by the site can be used as well as object types defined in Windchill PDM library. For example, you could create a policy that provides read access to all documents of type Quality Assessment to the product team role/group called Testers. For general information about domains and policies, see Administering Domains and Policies. For additional information about creating or updating access control rule policies, see Administering Access Control.

You can configure the number and versioning scheme used to uniquely identify parts, documents and other objects in Windchill PDM library. The numbering and versioning schemes define at the site level is inherited by Windchill PDM library
7-3
by default. Use the Object Initialization Rules Administrator to configure the number and versioning schemes. For additional information, see Administering Object Initialization Rules.
Managing Viewable Publishing

You can monitor and manage the publishing of viewable files that are optionally generated when CAD models are checked into products. You can also configure and update the watermarks used by the Windchill ProductView visualization tool when viewing document and part content from the product. For additional information, see Administering Visualization Services.
Managing Custom Reports

You can create and update custom reports against the objects and attributes defined within the product or library. These reports are created using a report generation utility. The reporting utility is designed for use by those with a working knowledge of the Windchill data object model. For additional information, see Administering Audit Reports.

You can import information into a product, and can export information to a local file system. The import/export facilities support information exchange with another Windchill server or non-Windchill system. These utilities read and write system information in an XML format. For general import and export information, see the Windchill Import and Export chapter in the Windchill System Administrators Guide. The workflow and life cycle administration utilities accessible to the site administrator integrate the import and export functions with administering workflows and life cycles. For life cycle import and export information, see Import and Export in the Administering Life Cycles chapter. For workflow import and export information, see Import and Export in the Administering Workflows chapter.

You can configure the vaulting and replication rules for the external file and replica sites established by the site administrator. When external vaults are configured, document and part content is stored on a file system rather than in the database. This configuration can provide significant upload performance improvements and is appropriate when the site is frequently used to exchange large files (such as CAD model files).
7-4
For how to set external file vault rules, see the Administering External File Vaults chapter in the Windchill System Administrators Guide. Replication sites can also be configured so that document and part content files are replicated at a remote site where local users have only very low bandwidth connections to the Windchill server. Site administrators typically define the replica site and the replication schedule. For how to set replication rules, see the Administering Content Replication chapter in the Windchill System Administrators Guide.
Out-of-the-box Windchill PDM Library Contents

When Windchill PDM is installed the following Change Management administrative items are loaded into the Windchill PDM library container: The ChangeItems administrative domain The ChangeItems cabinet The following life cycle templates: Change Activity Analysis Activity Change Investigation Change Issue Change Order Change Proposal Change Request The following team templates: Change Control Board Change Team The following workflow templates: Change Activity Process Change Analysis Process Change Investigation Process Change Issue Process Change Order Process Change Proposal Process Change Request Process 1 Change Request Process 2 Note: Windchill PDM library container inherits administrative items from the Site container as described in Distributed and Hierarchical Administration and other sections of the Administering Containers chapter.
7-5
Creating Groups for Use in Site Domain Policies

If you want to create policy rules for domains that are in the Site context and use groups (rather than individual users) as the principals to which the rules apply, then there is a multi-step process that you must complete to create the groups in the Site context. This is because groups created from the Principal Administrator that is opened from the Site Map only creates groups in the Windchill PDM library context. To create a group in the Site context use the following steps: 1. From Site Map, open Policy Administrator. 2. Select the Site context and then select a domain in the Site context and click View. 3. From Administrative Domain Window of that domain, click the Principal Administrator in the Site context. to open
4. From the Principal Administrator, create the group in the Site context. You can then use the group created when setting policy rules for domains in the Site context.
Improving Performance on Searches from Windchill Explorer

If users conduct a search that contain a large result set, the additional attributes requested on Windchill objects can cause some loss in performance. If a user is experiencing a long wait for each results, they should stop the search, and enter in more specific search criteria to limit the result set being returned. If poor search performance is a persistent issue at a site, you can customize the searches by removing attributes from the default Windchill Explorer interface. This is done by modifying wt.clients.query.QueryPanelOptions.java. For example, the out-of-the-box set up for a WTDocument is shown below (see the JavaDoc for wt.clients.beans.query.WTSchema for explanation of the different tags):
{"All Document Types", "C:wt.doc.WTDocument; K:61; A:number; " + "A:name; A:docType; A:versionIdentifier; A:lifeCycleState; " + "A:teamTemplateId; K:62; A:cabinet; A:modifyTimestamp; D:organizationReference; " + "D:formatName; A:format; D:organizationUniqueIdentifier;"},
To remove the organizationReference and organizationUniqueIdentifier attributes from the search (as these attributes were found to give the largest performance gains), the modified string is as follows:
{"All Document Types", "C:wt.doc.WTDocument; K:61; A:number; " + "A:name; A:docType; A:versionIdentifier; A:lifeCycleState; " + "A:teamTemplateId; K:62; A:cabinet; A:modifyTimestamp; D:formatName; A:format;"},
7-6
8
Administering Projects
This chapter provides an overview for administering projects in Windchill ProjectLink and describes the typical duties that a project manager performs. It also provides additional information about some of the main administrative tasks for projects. Topic Page
Overview .............................................................................................................8-2 Typical Duties of Project Managers....................................................................8-2 Out-of-the-box Project Templates.......................................................................8-6 Creating a Project ................................................................................................8-8
8-1
Overview
Project managers (also known as project administrators) are responsible for creating and managing projects hosted by a parent organization in the system. Project managers create and configure the project and control the membership of the project teams within the confines of a project application container. They control access to the project information, and they define the project schedule, resources, and plan details. Project application containers are used to define new projects and to collect all the information associated with the project. Project containers are defined by project creators who are authorized by the parent organization. Projects inherit templates, roles, groups, and policies from their parent organization container. In addition, the project manager can define project-specific templates, groups, roles, and policies. For general information about container contents and how to create containers, see Administering Containers.
Typical Duties of Project Managers

Project managers are responsible for creating and managing projects. Your typical duties include the following: Creating and updating project space Managing project team members and roles Creating, updating, and managing documents and folders Creating, updating, and managing activities, deliverables, resources, and action items Managing document templates Importing and exporting information
Creating and Updating Project Space

You create the project instance in the context of a parent organization. You can choose the project template on which the project is based, define the key project attributes, define the project properties and select the configuration options. You can also update the project attributes as the project progresses. These attributes include the project description, scope, status description, risk value and description, project number, and so forth. Only members of the project creators group and the organization administrator in an organization are allowed to create projects. By default, organizations allow all members to create projects, but the organization or site administrator may update an organization restricting project creation privileges to identified creators.
8-2
For more information about creating a project, see Beginning a Project in the Windchill ProjectLink Users Guide.
Managing Project Team Members and Roles

You have exclusive control over your project team. Only Project managers can add team members and roles. Each project team contains two fixed roles that cannot be removed: Project Manager and Guests. The Guests role is designed to include groups and users that are not active project team members and need only read access to project information. Guest members do not receive project invitations; projects in which a user is a guest do not show up on project lists for the user. You can select project team roles from the list of roles inherited from the parent organization, or you can create new roles. The creator of the project is automatically established as both a project manager and as the project owner. The project manager can change the owner and can add members to the project managers group. All members of the project managers group have the same privileges. You can invite groups to the project roles from the groups defined in the parent organization under which you create the project.
Creating, Updating, and Managing Documents and Folders

You can create documents for the project, and you can define a folder structure. By default, any member of the project can define folders and subfolders in a project. You have full control over all documents created in the project; no member can prevent you from reading, updating, or deleting any object. You can also modify the access rules on any folder or any document. You can delete discussion forum topics and postings. Non-project managers can only post to discussion forum topics; they cannot delete posting or topics, even if they created them.
Creating, Updating, and Managing Activities, Deliverables, Resources, and Action Items
You alone can create activities, milestones, deliverables, and resources in the project. The owner of an activity, milestone, or deliverable can update and complete the item, but only project managers can create plan items.
8-3
Managing Project Templates

You control the document templates available to a project. You can add to the list of document templates inherited from the parent organization or site, can override the inherited template with a project-specific template of the same name or can disable a document template that was created within the context of the project. Disabled templates do not show up in the list of available templates when using the Create (Document) from Template action in the project folders page.

You can export information from one project and import it into another project on the same system or a different Windchill system. Generally, you can only import into a system at the same or higher release version as the system from which the data was exported. You can export project information as a template. A site or organization administrator can then create a template from that information that can be reused by the organization. You can also save an existing project as a new project as a means of quickly starting a similar project. You can also import a Microsoft Project plan into the system and export project information from Windchill into the Microsoft Project format. You must install a Microsoft Project plug-in utility to take advantage of this capability.
Optional Utilities (Optional Access Through Project Utilities Link)

A site or organization administrator has access to a number of utilities through the Utilities link under the Project tab. The site or organization administrator can set a preference to grant all project managers access to the project utilities functions. By default, only site and organization administrators can access the project utilities and must act on behalf of the project manager. Access is restricted by default because these utilities are complex and require a level of training that is not expected for typical project managers. The preference that must be set to expose the Utilities link to project managers is:
\ProjectLink\AllowPMUtilitiesAccess
The following utilities are available through the Utilities link: Numbering Schemes Administration Object Initialization Rules Administrator ProductView Configuration Administrator Publish Monitor Publish Scheduler Administrator Replication Administrator
8-4
Numbering Schemes Administration

You can update the numbering scheme applied to establish uniqueness for documents and parts in a project.
Object Initialization Rules Administrator

You can configure how objects of various types are created and their attributes are created and initialized in the project. The Object Initialization Rules Administrator can define how the initial values for the object are established and can determine basic relationships such as life cycle association when an object is created in the organization. The rules established by the parent organization are inherited by each project by default, but they can be overridden by a project. The rules are defined in an XML format; you can view and edit them if a site or organization administrator has given you access to them.
ProductView Configuration Administrator

If given access to this utility, you can manage the ProductView configurations to set up watermark files that users see when they view document and part content from the project.
Publish Monitor
You can access the Publish Monitor utility to monitor the publishing of viewable files generated when CAD models are checked into the project.
Publish Scheduler Administrator

You can manage the scheduling of publishing CAD files that are checked into the project.
Replication Administrator
You can establish project content replication rules. Replication is useful when sharing large files with remote sites where the remote users have low bandwidth connections to the Windchill server. Replication sites are configured so that document and part content files are replicated at a remote site and made available locally to the remote users through a higher bandwidth connection. Replication can decrease the time required to upload and download files at the remote site. Site administrators must define the replica site and the replication schedule; project managers configure the replication rules for a particular replication site established for the system. Define replication only for those projects in which remote sites are participating. Replication imposes a substantial performance burden on the Windchill server.
8-5
Out-of-the-box Project Templates

When Windchill ProjectLink is installed, the following project templates are loaded:
Template Name Description
General Design Manufacturing Custom
A sample template that can be used to create a general project. A sample template that can be used to create a design project. A sample template that can be used to create a manufacturing project. A sample template that can be used to create a custom project.
The project templates can define the same basic information that is discussed in the Container Administrative Items section of the Administering Containers chapter. However, the out-of-the-box templates define only the following: Container structure Container environment Container participation
The following sections describe the items that are defined in the templates.
Container Structure General Design Manufacturing Custom
Folder structure
General
Analysis Contracts General Designs Plans Prototypes Specifications Standards
Analysis Contracts Designs General Plans Specifications
Changes Contracts Designs General Installation Plans Prototypes Specifications
8-6
Container Environment General Design Manufacturing Custom
Forum topics
General
Analysis Design General Manufacturing Specifications
Design General Manufacturing Quality Specifications
Changes Contracts Design General Manufacturing Quality Specifications Documents General Links Parts
Reference folders
Documents General Links Parts
Container Participation General Design Manufacturing Custom
Project team roles
Guests Members Project Manager
Consultant Designer Guests Manufacturer Members Project Manager
Engineer Guests Manufacturer Members Production Planner Project Manager Purchasing Agent Quality Engineer Supplier
Customer Engineer Guests Members Project Manager Quality Engineer Supplier
8-7
Template Plan Objects General Milestones Project Start Project Finish Design Project Start Contract Signed Specifications Approved Design Approved Prototype Approved Design Released Project Finish Scope Contract Specification Draft Design Prototype Final Design Post Mortem Manufacturing Project Start Contract Signed Specifications Approved Design Approved Testing Complete Prototype Approved Production Part Approved Production Initiated Project Finish Scope Contract Specification Draft Design Test Report Prototype Production Part Production Initiated Post Mortem Custom Project Start Contract Signed Specifications Approved Design Approved Testing Complete Prototype Approved Production Part Approved Production Initiated Project Finish Scope Contract Specification Draft Design Test Report Prototype Production Part Production Plan Post Mortem
Deliverables
Scope Post Mortem
Creating a Project
Note: Members of the project creators group of an organization create containers under that organization. By default, organizations allow all members to create projects, but the organization or site administrator may update the organization restricting project creation privileges to identified creators. For information about creating projects, see Beginning a Project in the Windchill ProjectLink Users Guide or the help available from the Create Project window. For information about project plans, see Managing Project Plans in the Windchill ProjectLink Users Guide.
8-8
9
Administering Principals
This chapter describes the principals (user, group, and organization objects) that are used in your Windchill solution. It also provides details about managing the principals. Topic Page
Overview .............................................................................................................9-2 Using the Principal Administrator.......................................................................9-4 Understanding Principals ....................................................................................9-7 Best Practices for Assigning Domains to Principals ...........................................9-7 Managing Users...................................................................................................9-8 Managing Groups ..............................................................................................9-12 Managing Organizations ...................................................................................9-14 Receiving Administrative Notifications............................................................9-16 Managing the Principal Cache ..........................................................................9-17 Maintaining the Connections between Principal Objects and their Directory Service Entries...................................................................................................9-18
9-1
Overview
Windchill uses the term principal to mean a user, group, or organization. It uses principals to mean any combination of users, groups, or organizations. As the Windchill system administrator for any Windchill solution, you can create and update Windchill user, group, and organization objects through the Principal Administrator. As an Organization Administrator in Windchill PDMLink and Windchill ProjectLink, you can update the Windchill user, group, and organization objects that are in the organization context that you are administering. Note: When a Windchill solution is installed, the system administrative user (Administrator), the system administrative group (Administrators), and the host organization object are always created. By default, the user Administrator (for example, wcadmin) belongs to the Administrators group. This user does not have an organization affiliation (as defined by the organization attribute, which is "o" by default). Members of the Administrators group are granted all the permissions required to accomplish the administration tasks described in this guide. Windchill uses both the Windchill database and a directory service when creating principals. For each principal, there is an entry in a directory service and a Windchill object stored in the database: The directory service entry contains attributes specific to the type of principal. For example, user entries have attributes for the users full name, e-mail address, and organization. The Aphelion Directory Service is set up when your Windchill solution is installed. Other directory services can be established by setting up JNDI adapter entries through the Info*Engine Property Administrator and adding the adapter entries to the wt.federation.org.directoryServices property value. For additional information, see the Windchill Installation and Configuration Guide. The Windchill object contains information that is relevant to Windchill (such as the associated domain) and the Unique Federation Identifier (UFID) associated with principal. The UFID contains the distinguished name of the principal and identifies the directory service where the principal entry resides. The following sections provide additional details about Windchill principals.
Windchill Users
A Windchill user object identifies a user and is used when establishing group membership and policy rules for that user. It is stored in the Windchill database and holds user information for those users who have access to Windchill. This information includes the user name, the UFID associated with the user, the
9-2
Windchill domain of the user, and administrative flags that are set if the object needs to be repaired or is disabled. A Windchill user object is automatically created and persisted in the Windchill database the first time the user is selected from a search or the first time the user logs on to Windchill. In both of these cases, the corresponding directory service entry for the user already exists and is then referenced in the object that is created. As an administrator, you can also create, update, and delete users through the Principal Administrator. Windchill does not rely on the user object to authenticate users. Rather, users are authenticated when they log on to the Web server. The user's Web server ID is then mapped directly to the user object that has a matching user name. Windchill users are usually affiliated with an organization that is set through the directory service organization attribute (by default, "o"). If the organization attribute is not set, then the user is an unaffiliated user and cannot create products, libraries, or projects from Windchill PDMLink and Windchill ProjectLink. However, that user can be invited to a team by e-mail and can do the same things within the product, library, or project as any other member.
Windchill Groups
Organizing users into Windchill groups provides you with a more efficient way to apply policies for access control, indexing, and event notification. Each group object identifies selected users, organizations, and possibly other groups, under one name. You can create groups so that you can efficiently apply administrative policies (such as those for access control, indexing, and notification policies) to sets of users, rather than to each user individually. Groups are associated with the context in which they are created. From the Principal Administrator, you only have access to the groups created through the Principal Administrator in the current context or in ancestor contexts. Some Windchill solutions also create and manage internal groups that are used to manage team role membership. These groups are not accessible from the Principal Administrator. A Windchill group object holds the group name, the UFID associated with the group, the Windchill domain of the group, and administrative flags that are set if the object needs to be repaired or is disabled. The UFID contains the distinguished name of the group and identifies the directory service where group entry resides.
Windchill Organizations
Categorizing users by organization provides an additional way in which you can identify a set of principals by name. The Windchill PDM solution does not make extensive use of organization objects; however, it does provide an organization ownership feature that can be turned on to identify which organization owns specific Windchill objects (see Administering Organizations in the Windchill System Administrators Guide). Other Windchill solutions make use of
9-3
organization objects within organization contexts to manage Windchill objects within each organization context. An organization can be a company, company division, university, or some other list of people. Organization membership is defined by user directory entries that include the organization name defined for the organization object. For example, if the organization name is DIV1, then all users in the configured directory services who have their organization attribute (o, by default) set to DIV1 are members of the DIV1 organization. Organizations are associated with the context in which they are created. From the Principal Administrator, you only have access to the organizations created in the current context or in ancestor contexts. Each Windchill organization object holds the organization name, the UFID associated with the organization, the Windchill domain of the organization, and administrative flags that are set if the object needs to be repaired or is disabled. The UFID also contains the distinguished name of the organization and identifies the directory service where the organization entry resides.
Using the Principal Administrator

How you access the Principal Administrator is determined by your Windchill solution: From Windchill PDM, you can access the Principal Administrator by clicking the Principal Administrator link that is on the Business Administration home page. This link launches the Principal Administrator in the Windchill PDM context and provides you with access to principals that are in the current context or in ancestor contexts. From Windchill PDMLink and Windchill ProjectLink, you can access the Principal Administrator from the Utilities pages that are under the Site and Organization tabs: The Principal Administrator link from the Site tab provides you (as the system administrator) with access to users and to the groups and organizations created in the Site context. The link from the Organization tab provides access to only those principals that are available through the organization context that is active when you launch the Principal Administrator and through the Site context (which is its ancestor context). If the organization was set up so that it allows entire user and group directory selection, then you can see all users and groups (except for the internal groups maintained by your solution). However, access control rules may be set to prohibit you from seeing some users and groups.
From the Policy Administrator Administrative Domain window, you can access the Principal Administrator by clicking . Using this icon allows
9-4
you to open the Principal Administrator from the current context of the Policy Administrator. To get to the Administrative Domain window, launch Policy Administrator as described in Using the Policy Administrator. Then select a domain and click Update or View. The Principal Administrator allows administrators to manage Windchill principal objects using the following links on the Principal Administrator main page:
The following table describes the links:

Link Description
Home
Re-displays the designated home page of the Windchill solution from which you opened the Principal Administrator.
Displays the Users table from which you can manage users. Click Add Existing Users to Table to add existing users to the table. Click Create New User to create a new user. For additional information, see Managing Users.
Users
Groups
Displays the Groups table from which you can manage groups that are created in either the current context or ancestor contexts. Click Add Existing Groups to Table to add existing groups to the table. Click to create a new group.
Create New Group
For additional information, see Managing Groups.
9-5
Link
Description
Organizations
Displays the Organizations table from which you can manage organizations. Click Add Existing Organizations to Table to add existing organizations to the table. Click Create New Organization to create a new organization object. For additional information, see Managing Organizations.
Maintenance
Displays the Disconnected Principals table, which contains principals for which the distinguished name currently associated with the principal is not valid. From this table, you can search for additional principals that have nonexisting distinguished names, update disconnected principals, delete disconnected principals, or purge all principals from cache. For additional information, see Maintaining the Connections between Principal Objects and their Directory Service Entries.

The Principal Administrator creates only organization objects and not organization contexts. To create both the organization object and its context, use Create Organization from either the Site or Organization tab. Ensure that users have an e-mail address as many features in Windchill PDMLink and Windchill ProjectLink require users to have an e-mail address. If users do not have the e-mail attribute set in their user directory service entry, they cannot participate in the features that require an e-mail address.
Best Practices When Maintaining a Directory Service Outside of Windchill

Because your user directory service can be maintained outside of your Windchill solution, you may not be creating users through the Principal Administrator; instead, users are automatically created in the Windchill database when the users become active in the solution. As users are removed or changed in the user directory service through an external tool, you will need to manage the Windchill user objects by doing the following: Deleting Windchill user objects that no longer have valid user directory service entries (see Maintaining the Connections between Principal Objects and their Directory Service Entries). Cleaning up after deleted users (see Deleting Users).
9-6
Managing the principal cache so that changes in a user directory service are available in Windchill (see Managing the Principal Cache).
Understanding Principals
Principals are identified across Windchill systems through the use of the principal Unique Federation Identifiers (UFIDs). The syntax for principal UFIDs is as follows: <distinguished_name>:<guid>@<domain> where: <distinguished_name> is the distinguished name of the principal. <guid> is the globally unique identifier of the repository in which the principal was first created or discovered. <domain> is the Internet-style domain name of the repository in which the principal currently resides. Together, <guid>@<domain> identifies the directory service in which the principal resides.
Best Practices for Assigning Domains to Principals

When principal objects are created, they are associated with default domains as follows: Users who are affiliated with an organization (the organization attribute on their directory service entries is set) are associated with the domain that was created for the organization when the organization object was created. This domain usually has the same name as the organization (or a shortened version of the organization name) and the domain is a child of the Site container User domain. If the organization is associated with an organization container, then the domain is in the organization container; otherwise, the domain is in the Site container. Users who are not affiliated with an organization (the organization attribute on their directory service entries is not set) are associated with the Site container Unaffiliated domain. This domain is a child of the User domain. One exception to this rule is the Administrator user, which is associated with Site container System domain. User personal cabinets are associated with the same domain as the user.The one exception to this rule is that the personal cabinet for the Administrator user is associated with the User domain. in the Site context. Groups created in the Site context are associated with the Site container Unaffiliated domain. This domain is a child of the User domain.
9-7
Groups created in an organization context are associated with the domain that was created for the organization when the organization object was created. This domain usually has the same name as the organization (or a shortened version of the organization name) and the domain is a child of the Site container User domain. The domain is in the organization context. Organizations are associated with the domain that was created for the organization when the organization object was created. This domain usually has the same name as the organization (or a shortened version of the organization name) and the domain is a child of the Site container User domain. If the organization is associated with an organization container, then the domain is in the organization container; otherwise, the domain is in the Site container.
Note: The default domain associations described in the previous list only apply if you have not set up JNDI adapters that configure principal domain assignments as described in previous releases. The domain assignments in a JDNI adapter take precedence over the system defaults. User objects and personal cabinets are created automatically when users are selected in a search or when users log in. These user objects and person cabinets are always associated with the default domains described earlier. When you create a user through the Principal Administrator, you can select the domains. But in most cases, you should use the defaults (which are used when you do not select a domain). When creating group objects through the Principal Administrator, using the default domain is usually a good choice. However, you may want to choose a different domain if you want policy rules from a domain other than the default to apply to the group object. When creating organization objects through the Principal Administrator, using the default domain is usually a good choice. However, you may want to choose a different domain if you want policy rules from a domain other than the default to apply to the organization object. This may be the case if you want to allow users to select the owning organization when they create parts and documents. For the details on how to turn on the organization ownership feature, see Administering Organizations in the Windchill System Administrators Guide.
Managing Users
Clicking the Users link on the Principal Administrator main page displays the Users table from which you can manage users. Clicking Add Existing Users to Table allows you to locate existing users and add them to the Users table. Clicking Create New User allows you to create a new user. After a user is added to the table, you can manage the user. In previous releases, users were identified by a user ID. The user ID is now known as the user name. Managing users includes performing the following activities:
9-8
Creating users, either from scratch or by starting with a similar user To create a similar user, access the information page of a current user and select the Create Similar User link.
Searching for users Updating and deleting users When deleting users, you can delete them from just the Windchill database or delete them from both the database and the user directory service.
Viewing information about users Defining electronic signatures for users Managing personal cabinet names From Windchill PDM, you can administer personal cabinets from the Windchill Explorer. From Windchill PDMLink and Windchill ProjectLink, you can administer personal cabinets from the Personal Cabinets Administration link on the Site Utilities page.
Purging users from the principal cache
For specific instructions on how to perform these activities, click Help from within the Principal Administrator. Note: Although Windchill PDM and the Principal Administrator do not require that users have an e-mail address, many features in Windchill PDMLink and Windchill ProjectLink require that users have an e-mail address. The following sections provide information about personal cabinets and deleting users.
Naming a User's Personal Cabinet

Since a Windchill user name does not need to be unique and all personal cabinet names must be unique, Windchill uses the wt.folder.personalCabinetNamingAttribute property in the wt.properties file to determine what the initial personal cabinet name should be for a given user. The wt.folder.personalCabinetNamingAttribute property contains the following default ordered list of attributes: name -- The cabinet name used is the user's name. eMail --The cabinet name used is the user's e-mail address. fullName --The cabinet name used is the user's full name. For the cabinet name, Windchill uses the value of the first attribute in the list that produces a unique name. In most cases, the name of the personal cabinet is the user's name. If there is already a personal cabinet with that name, the user's e-mail address is used for the personal cabinet name. If the e-mail address is already
9-9
being used as a cabinet name, then the full name is used. If the full name is already being used, the object identifier for the user (OID) is used as the cabinet name. The oid is a unique string that identifies each object in Windchill. If the oid is already in use, Windchill appends an underscore and an integer, starting with 1, to the object identifier (<oid>_1, <oid>_2, and so on) until a unique cabinet name is discovered. You can change the attributes used in creating the personal cabinet name or the order of these attributes by modifying the list of attributes in the wt.folder.personalCabinetNamingAttribute property using the xconfmanager utility. Valid values are those attributes used in user directory service entries. For example, to use the full name before using an e-mail address, you could specify the following xconfmanager command from a windchill shell:
xconfmanager -s wt.folder.personalCabinetNamingAttribute=name,fullName,eMail,oid -t <Windchill>/codebase/wt.properties -p
Where <Windchill> is the location where your Windchill solution is installed. To use a user's telephone number instead of the e-mail address, you could specify the following property and value pair: wt.folder.personalCabinetNamingAttribute=name,fullName, telephoneNumber,oid If the attribute list for wt.folder.personalCabinetNamingAttribute has been modified and no personal cabinet name is discovered using the modified list, then Windchill derives the cabinet name from the user's name with the OID appended (as discussed earlier in this section). For additional information about using the xconfmanager utility, see About the xconfmanager Utility.
Deleting Users
Caution: Do not delete a user unless you understand how it affects the system, as described in this section. There are two actions that result in deleting a user. They are: Delete - Only Windchill Delete - Completely
The first action has the affect of deleting the user from the Windchill database. The second action deletes the user from both the Windchill database and the user directory service. To use the second action, you must have the required permissions to be able to delete users from the directory service as well as the database. Note: You cannot delete the Administrator or the Administrator group. Nor can you delete yourself.
9-10
The results of deleting a user from the Windchill database are as follows: The user is removed from all groups. All access control rules that identify the user are removed from the access control policy for a domain. The user is removed from all notification lists within notification policy rules and, if deleting the user from the list results in an empty list, then the rule is also deleted.
The following rules govern work items associated with a workflow process when a user is deleted from the Windchill database: If a user is deleted after a workflow process has been initiated, but prior to assignment of a work item, the user is removed from the list of participants and no work item is assigned. If the user is deleted after a workflow process has been initiated, and a work item has been assigned, that work item must be manually removed. (For more information, see Administering Workflow Processes.) A deleted user continues to appear in iteration history, object properties pages, and so on, but the name is not displayed as an e-mail link. When a user is deleted, the user is automatically removed from the list of participants in any workflow process template. The user is also removed from any role mappings created as part of a life cycle or team definition. If a user is identified as a participant in a workflow template definition and that user is deleted from the system after the workflow has been initiated, any work item that would have been assigned to the user is reassigned to the workflow administrator who created the template. If both the template creator and a user identified in a workflow process template are deleted after the workflow process is initiated, the workflow process stops until the work items assigned to the deleted user are manually reassigned. Another user can be created with the same user name, but if the original user's personal cabinet was not deleted, the new personal cabinet will not have same name. For more information, see Naming a User's Personal Cabinet. If a deleted user is specified as the user of a collection defined in the index properties, a stack trace prints in the Method Server log when an attempt is made to index an object.
The results of deleting a user from both the Windchill database and the directory service include all results described earlier for deleting a user from the Windchill database and additionally include the following: A user is not authenticated when attempting to log into Windchill. The user's name is not included in search results.
9-11
If a user is not removed from the user directory service, a new user object is created in Windchill database when the user tries to log on or when the user is selected from a search. This new user object is not the same object that was deleted, and all of the results of the earlier deletion are still true. For example, the user is no longer a member of the groups to which the user had been a member. After deleting a user from the Windchill database, you must perform the following clean-up steps: Reassign any items in the user's worklist. Unlock any objects the user has checked out of the Windchill database. Remove the user's personal cabinet and any folders or objects within it. From Windchill PDM, select the cabinet from the Windchill Explorer and delete it. From Windchill PDMLink, use the Personal Cabinets Administration link from the Site Utilities page.
Managing Groups
Clicking the Groups link on the Principal Administrator main page displays the Groups table from which you can manage groups. Clicking Add Existing Groups to Table allows you to locate existing groups and add them to the allows you to create a new
Groups table. Clicking Create New Group group.
Managing groups includes performing the following activities: Creating groups, either from scratch or by starting with a similar group To create a similar group, access the information page of a current group and select the Create Similar Group link. Searching for groups Updating and deleting groups When deleting groups, you can delete them from just the Windchill database or delete them from both the database and the directory service. Viewing information about groups Purging groups from the principal cache
Note: The groups that can be managed from the Principal Administrator do not include internal groups that are created as a result of administrator interaction with Windchill PDMLink and Windchill ProjectLink. For example, the internal groups created for the context team roles can only be managed from the Teams link; they are not visible through the Principal Administrator.
9-12
For specific instructions on how to perform these activities, click Help from within the Principal Administrator. The following section provides additional information about deleting groups.
Deleting Groups
Caution: Do not delete a group unless you understand how it affects the system, as described in this section. There are two actions that result in deleting a group. They are: Delete - Only Windchill Delete - Completely
The first action has the affect of deleting the group from the Windchill database. The second action deletes the group from both the Windchill database and the directory service. To use the second action, you must have the required permissions to be able to delete groups from the directory service as well as the database. The results of deleting a group from the Windchill database are as follows: Users who were members of the group no longer belong to the group. All access control rules that identify this group are removed from the access control policy for a domain. If any users had access permissions derived solely from membership in the deleted group, it may be necessary to create new rules to restore the lost permissions. The group is removed from all notification lists within notification policy rules and, if deleting the group from the list results in an empty list, then the rule is also deleted.
The following rules govern work items associated with a workflow process when a group is deleted from the Windchill database: If a group is deleted after a workflow process has been initiated, but prior to assignment of a work item, the group is removed from the list of participants. If removing the group leaves no participants for a role, then the role resolution is determined by the settings in the wt.properties file: If the wt.workflow.engine.ignoreUnresolvedRole property is set to true and if the ignoreUnresolvedRole event configuration is set for this activity; then there will be no work item created and the WfAssignment object completes so the workflow does not hang. If the wt.workflow.engine.ignoreUnresolvedRole property is set to false, one work item is created that goes to the Responsible Role defined in the activity template. The default for the Responsible Role is the process
9-13
creator. When the workflow process is started through a life cycle, the process creator is the creator of the business object. For more information, see Administering Workflow Processes. If the group is deleted after a workflow process has been initiated and work items are assigned, deleting the group has no affect on the process because the group itself is no longer being referenced. Work items are assigned to the individual users that were in the group. When a group is deleted, it is automatically removed from the list of participants in any workflow process template. The group is also removed from any role mappings created as part of a life cycle or team definition. If a group is identified as a participant in a workflow template definition, and that group is deleted from the system after the workflow has been initiated, any work item that would have been assigned to the group is reassigned to the workflow administrator who created the template.
The results of deleting a group from both the Windchill database and the directory service include all results described earlier for deleting a group from the Windchill database and additionally include the following: The group is not included in search results.
If a group is not removed from the directory service, a new group object is created in Windchill database when the group is selected from a search. This new group object is not the same object that was deleted and all of the results of the earlier deletion are still true. For example, the users who had been members of the group are no longer members.
Managing Organizations
Clicking the Organizations link on the Principal Administrator main page displays the Organizations table from which you can manage organizations. Clicking Add Existing Organizations to Table allows you to search for existing organization objects and add them to the Organizations table. Clicking Create New Organization allows you to create a new organization object.
Note: To use an organization object (created using the Principal Administrator) as a Windchill PDMLink or Windchill ProjectLink organization context, you must create an organization container for the organization object. You can create an organization container from the Organization tab in either of these solutions. When creating an organization container, you can either use an existing organization object that is not associated with a container or create a new organization object. Organization objects created using the Principal Administrator are considered restricted organizations. This means that no access control rules are automatically added to allow users in one organization to see users and groups from other
9-14
organizations. When you create an organization container, you can select a check box that allows users in the organization to see all users and groups. This adds the organization to the Unrestricted Organizations group, which has the access control rules set to allow users to see other users and groups. Organization objects can be used to identify an organization as the owner of specific parts and documents. By default, Windchill solutions are not set up to allow organization ownership selection. The organization under which the parts and documents are created automatically own them. There are multiple steps involved in enabling organization ownership selection, one of which is creating the organization objects. For details on how to enable organization ownership selection, see Administering Organizations in the Windchill System Administrators Guide. Managing organizations includes performing the following activities: Creating organizations, either from scratch or by starting with a similar organization To create a similar organization, access the information page of a current organization and select the Create Similar Organization link. Searching for organizations Updating and deleting organizations When deleting organizations, you can delete them from just the Windchill database or delete them from both the database and the directory service. Viewing information about organizations Purging organizations from the principal cache
For specific instructions on how to perform these activities, click Help from within the Principal Administrator. Note: When specifying the internet domain name of an organization, the name you enter can contain only alphanumeric characters and the hyphen (-) character. Do not enter any other types of characters in the name. The following section provides additional information about deleting organizations.
Deleting Organizations
Caution: Do not delete an organization object unless you understand how it affects the system, as described in this section. Note: You cannot delete an organization object that is associated with an organization container. There are two actions that result in deleting an organization. They are:
9-15
Delete - Only Windchill Delete - Completely
The first action has the affect of deleting the organization from the Windchill database. The second action deletes the organization from both the Windchill database and the directory service. To use the second action, you must have the required permissions to be able to delete organizations from the directory service as well as the database. The results of deleting an organization from the Windchill database are as follows: The organization is removed from all notification lists. All access control rules that identify this organization are removed from the access control policy for a domain. If any users had access permissions derived solely from membership in the deleted organization, it may be necessary to create new rules to restore the lost permissions.
The results of deleting an organization from both the Windchill database and the directory service include all results described earlier for deleting an organization from the Windchill database and additionally include the following: The organization is no longer included in search results.
If an organization is not removed from the directory service, a new organization object is created in Windchill database when the organization is selected from a search. This new organization object is not the same object that was deleted and all of the results of the earlier deletion still hold.
Receiving Administrative Notifications

When a user is deleted using the Principal Administrator, the administrator receives a notification by e-mail (or possibly through Windchill workflow). The administrator is notified that the principal has been disabled and that any additional manual actions should be taken, such as removing a users personal cabinet. Similarly, when Windchill detects that a user, group, or organization needs to be repaired because the object in the Windchill database no longer references an existing directory service entry, possibly because the entry has been removed from or relocated in the directory service, the administrator is notified that repair is needed. These notifications are initiated by calling the Info*Engine tasks named NotifyPrincipalDisabled.xml and NotifyPrincipalRepair.xml in the <Windchill>/tasks/wt/federation directory (where <Windchill> is the Windchill installation directory). You can customize these tasks to tailor the way in which notification is done.
9-16
Also, you can change the e-mail address used for the notifications by setting the wt.org.principalAdministratorEmail property in the wt.properties file. The default e-mail address used is the e-mail address of the Administrator user (if one is set) or the postmaster@<server_hostname> e-mail address, where <server_hostname> is the value of the java.rmi.server.hostname property in the wt.properties file.
Managing the Principal Cache

To improve the access time required for users, groups, and organizations, Windchill maintains an internal principal cache of user, group, and organization information that has been obtained from the Windchill database and directory services. Note: If user, group, or organization attributes are changed using an administration tool other than the Principal Administrator (for example, using a directory administration tool), then the cache containing those attributes must be purged in order for Windchill to display the changed attributes. You can manage the principal cache in two ways: By setting the maximum time that the information about a principal can remain available in the cache. Then cache entries are automatically purged when users try to access the old entries. By selecting actions that purge information from the cache from within the Principal Administrator.
Automatically Purging Entries from the Principal Cache

You can add the following properties to the wt.properties file to automatically purge principal cache entries: The wt.principal.cache.timeToLive property defines the amount of time that any given principal cache entry is available from the cache. Specify the property value in seconds. If the property value is not set or is set to zero or less than zero, then cache entries are not automatically removed from the cache. Out of the box, this property is not set. The wt.principal.cache.timeToLiveRandomizer property adds a random amount of time to the time stamp of each cache entry so that a large number of entries do not expire at the same time. Specify the property value in seconds. If the property is not set, the value defaults to 600 seconds (10 minutes). If the property is set to zero or set to less than zero, then no random value is added to the time stamp of each cache entry. Out of the box, this property is not set. When a valid value is specified, the random amount added to the time stamp varies between 1 second and the property value. For example, if the property value is 600 seconds (10 minutes), a value between 1 second and 600 seconds
9-17
is added to the time stamp of a cache entry when the entry is added to the cache. Use the xconfmanager utility to add the properties. For example to add the wt.principal.cache.timeToLive property, specify the following xconfmanager command from a windchill shell:
xconfmanager -s wt.principal.cache.timeToLive=600 -t <Windchill>/codebase/wt.properties -p
Where <Windchill> is the location where Windchill is installed. For information about using the xconfmanager utility, see About the xconfmanager Utility.
Manually Purging Entries from the Principal Cache

From within the Principal Administrator, you can purge either the entire cache or individual entries from the cache. For specific instructions on how to perform these activities, click Help from within the Principal Administrator.
Maintaining the Connections between Principal Objects and their Directory Service Entries
Sometimes the definitions of principals in the directory service are changed using a directory administration tool other than the Principal Administrator. For example, another tool is sometimes used to move users, groups, or organizations from one directory location to another. When this happens, the distinguished names for the principals that are moved change. During normal operation, Windchill keeps track of the objects it encounters that do not have valid distinguished names. Clicking the Maintenance link on the Principal Administrator main page displays the Disconnected Principals table, which contains principals for which the distinguished name currently associated with the principal is not valid. From the Disconnected Principals table, you can do the following activities: Search for additional principals that have nonexisting distinguished names Update disconnected principals Delete disconnected principals Purge all principals from the cache
For specific instructions on how to perform these activities, click Help from within the Principal Administrator.
9-18
10
Administering Access Control
Topic Page Overview ...........................................................................................................10-2 About Access Control Rules .............................................................................10-2 Creating and Managing Access Control Rules..................................................10-3 Setting Permissions ...........................................................................................10-5 About Access Control Lists...............................................................................10-6 About Predefined Access Control Policy Rules..............................................10-12 Managing Access to Enterprise Information...................................................10-13 Access Control Strategies for Cabinets in Windchill PDM ............................10-22 Access Control Strategies for Life-Cycle Managed Objects...........................10-24 Combining Access Control Strategies for Cabinets and Life-Cycle Managed Objects.............................................................................................................10-24
10-1
Overview
As a Windchill administrator, you must ensure that only the appropriate principals have access to objects. These decisions are expressed as access control rules governing domains. Defining these rules determines the types of interactions principals can have with objects of a specific object type and a specific life cycle state. For example, you can create a rule that gives the Publication group permission to modify objects of type WTDocument when they are in the Under Review state of their life cycle. Together, such rules form an access control policy for the domain. Subsequently, access control lists (ACLs) are derived from the policy for a domain and the policies of all its ancestor domains to enforce your access decisions. When users are viewing the attributes of an object where some of the attributes reference access controlled objects, such as principals, then whether the user sees the value of the attributes is determined by the whether the user has Read permission for the referenced objects. Typically, when a user does not have Read permission for a referenced object, the field shows (Secured information) instead of the attribute value. For example, assume that a user displays information about a product. On the page displayed, one of the product attribute fields is Created By and the value is the name of the user who created the product. If the user displaying the product information does not have Read permission for the user who created the product, then the name of the user will not appear. Instead of the name, the user sees (Secured information). This chapter discusses Windchill access control concepts, explains the relationship between domain and instance-based access control rules, and presents strategies for developing useful rules.
About Access Control Rules

One common administration task is specifying policy rules for controlling access to objects governed by a domain. When you create these rules, you customize the domain's access control policy. From this policy, ACLs are generated and associated with an object type. The ACL is the basic mechanism for enforcing access control decisions when a user attempts to interact with an object. ACLs are created upon demand and are cached to maximize system performance. There are two types of ACLs: policy ACLs, which apply to an object type ad hoc ACLs, which apply to a specific instance of an object type.
For more information on ad hoc ACLs, see Rules Governing Domain-based ACLs and Ad Hoc ACLs in this chapter. An access control rule for a domain is a mapping between an object type and life cycle state, and sets of principals and their associated permissions. For an object
10-2
type and a specific state, an access control rule specifies rights of principals concerning access to objects of that type, in that state. For example, an access control rule might state that everyone in the Publications group has permission to read all objects of type WTDocument in the Engineering domain when they are in the Under Review state. An object type specifies a category of objects that share the same attributes and functions. For example, WTDocument is an object type, and instances of that type may be found in some of the domains you have created. Since Windchill domains are hierarchical, access control rules defined for a domain are inherited by descendent domains. For example, access control rules defined for the WTDocument object type in all states within the Design domain apply to instances of the type within that domain or any descendent domains. Because Windchill types are also hierarchical, an object inherits rules defined for its ancestor types. Therefore, more than one rule may apply to a given object. For example, a rule that applies to the type WTPart also applies to the type WTSerialNumberedPart. Additionally, there can be access control rules specific to WTSerialNumberedPart. Note: Not all business objects are subject to access control, nor must all object types exist in a domain. A principal is either an individual user, a group, or an organization. Most often, you define access control rules for groups or organizations. Dealing with groups or organizations helps reduce administrative overhead by enabling you to apply rules to more than one user at a time. Sometimes, however, you need to create rules for a specific user. For example, an access control rule can explicitly deny one group member a permission that is granted to the entire group by another rule. Permissions represent operations that apply to an object. Permissions are described in more detail in the next section.
Creating and Managing Access Control Rules

You can create and manage access control rules by opening the Policy Administrator as described in Using the Policy Administrator. Select a domain and click Update. The Administrative Domain window opens. On the Administrative Domain window, click the Access Control tab to bring it to the front of the window. To create an access control rule, click Create. To
10-3
update a rule, select a row and click Update. Click Help to display detailed instructions.
10-4
Setting Permissions
Through access control rules, you can establish whether a specific user, group, or organization is granted or denied permissions to the objects of a specified object type in a specified life cycle state. You can grant or deny the following types of permissions on the Access Control Rule window:
Permission Description
Read Modify
Determines the right to know the existence of the object and view it. Determines the right to change the attributes of an object, as well as other characteristics that are part of the object definition. (For example, you have the right to modify the description attribute for a group, as well as remove a user from that group.) Determines the right to create an object. Determines the right to revise an object. Revising creates a new version of the object at the same level as the original in the version tree. For example, you can create Revision B from Revision A. Determines the right to create a version for a specific view. Determines the right to delete an object. Determines the right to change the ad hoc permissions that others have. Users, groups, or organizations granted the Change Permissions permission are allowed to change the ad hoc permissions of others to the permissions they themselves have or to a subset of the permissions they have.
Create Revise
New View Version Delete Change Permissions
Administrative
Determines the right to perform certain administrative tasks. (For example, this gives you the right to break a lock or change an object's owner.) Determines full control. A user, group, or organization with the Full Control (All) permission has all rights currently defined and any defined in the future. Therefore, when new permission types are defined, you do not have to write rules that specifically grant them to principals with full control.
Full Control (All)
10-5
Selecting certain permissions on the Access Control Rule window automatically selects other permissions when granting access to an object type. For example, if a group is given permission to create an object, the group typically should also be able to read and modify the object; however, these automatic selections can be deselected. The following table illustrates which permissions are selected automatically for each permission granted.
Permission Selects
Read Modify Create Revise New View Version Delete Change Permissions Administrative
None Read Modify and Read Modify and Read Modify and Read Modify and Read None None
For example, if you select Grant for Modify, the Grant for Read button is automatically selected, as illustrated in the following part of the Access Control Rule window:
If you do not want to permit Read access, simply click the None button for Read to clear it. Selecting None means that the rule neither grants nor denies the permission.
About Access Control Lists

The Windchill access control list (ACL) mechanism, and the rules for evaluating ACLs, follow those in the java.security.acl package. This section provides a brief
10-6
description of the way in which ACLs are derived from the access control policies for domains, and describes how they work to enforce access control. When you create an access control rule, you specify the rule antecedent and the rule consequent: The rule antecedent comprises three parts: The domain. The object type, determines which rules within an access policy apply to a specific object. The life cycle state, which identifies the life cycle phase that an object must be in for the permissions to apply. If the object type is not a life cycle managed type, then the state is not applicable. Only rules with life cycle state set to ALL apply.
The rule consequent comprises three parts: A principal, which is a user, a group, or an organization. A user can be a member of more than one group. Associated permissions. Whether permissions are granted or denied.
For access control policy rules, the principal can be the pseudo-user OWNER or the pseudo-group ALL: A rule defined for OWNER specifies permissions that apply to the owner of an ownable object. A rule defined for ALL specifies permissions that apply to all principals.
You can create access control rules for some or all of the object types within a domain. Together, these rules constitute the access control policy for the domain. An ACL is created on demand for each rule antecedent. An ACL is derived from the policy for a domain and its ancestor domains, and is composed of multiple ACL entries. Each ACL entry contains a set of permissions associated with a principal. Each ACL entry is either positive (+) or negative (). If the entry is positive, the permissions are granted to the associated principal. If negative, the permissions are denied. To improve performance, when ACLs are calculated, they are cached so they can be quickly retrieved the next time a user requests access to a particular object.
Deriving ACLs from Access Control Policies

ACLs are the mechanism used to enforce access control. This section describes how ACLs are derived from the access control policy for a domain. The next section describes how ACLs work.
10-7
An ACL is generated for each object type, state, and domain. A given object is associated with the ACL whose domain, type, and state match that of the object. For example, all WTDocument objects of a given life cycle state, within a given domain, are associated with the same ACL. In addition, this ACL is different from the ACL associated with WTPart objects that belong to the same domain. An ACL for an object is obtained by combining all rules that apply to the objects type, state, and domain. To make this definition precise, it is necessary to describe how rules are combined, and when a rule applies to a type. A rule is applicable to a given type when the object type referred to in the access control rule is the type itself or one of its ancestor types. For example, a rule that applies to the WTDocument type also applies to incident reports if IncidentReport is a soft type of WTDocument. Rules that apply to a type are combined by merging rules that have the same sign (+ or ) and principal. The merge is performed by calculating the union of all permissions within the consequents. For example, consider the combination of the following rules:
Domain Type State Principal Permission
Rule 1: Rule 2: Rule 3:
/ (Site) /Parts (Windchill PDM) /Parts (Windchill PDM)
WTObject WTObject IncidentReport
InWork InWork InWork
Analysts Engineers Analysts
+ + +
Read Read Modify
The combination of these rules produces the following ACL entries for incident reports in the InWork state in the /Parts domain in the Windchill PDM container:
Type State Principal Permission(s)
/Parts (Windchill PDM) /Parts (Windchill PDM)
IncidentReport IncidentReport
InWork InWork
Analysts Engineers
+ +
Read, Modify Read
How ACLs Work

Permissions for a principal defined in one access control rule may conflict with other permissions defined in other rules. For example, you could define an access control rule that gives everyone in the Team 1 group delete permission for all incident reports belonging to the /Acme domain when they are in the Under Review state. However, in another access control rule, you could explicitly deny user Audrey.Carmen that permission, despite her membership in Team 1. In such cases, the ACL mechanism calculates the net permissions for a principal.
10-8
As defined in the java.security.acl package, the net permissions for a principal are calculated based on the following rules: Each principal (user, group, or organization) can have at most one positive ACL entry and one negative ACL entry. Multiple positive and negative ACL entries for a principal are not allowed. If there is no ACL entry for a particular user, group, or organization, that principal has the null permission set. In effect, having a null permission set denies the principal access to the object. If there is a positive entry that gives a principal a permission and a negative entry that denies the principal the same permission, the permission is not granted. Permissions that are explicitly granted (+) to the pseudo-user OWNER override any permissions denied () to the user that is the owner of the ownable object through a negative entry for the individual user or for a group or organization to which the user belongs. Permissions that are explicitly granted (+) to the user that is the owner of an ownable object or to a group or organization to which the user belongs override any permissions denied () to the pseudo-user OWNER. Permissions that are explicitly granted (+) or denied () an individual user always override that user's group or organization permissions. For example, user ReneN is a member of Group 1. According to an access control rule for the Acme domain, all members of Group 1 have modify permission to incident reports in the Under Review life cycle state. However, if another access rule explicitly denies ReneN permission to modify incident reports, then, ReneN is denied the modify permission, despite membership in Group 1. For a given user, the net group positive permission set is the union of all the positive permissions of each group and organization to which the user belongs. This includes permissions granted for the pseudo-group ALL. For example, if user ReneN belongs to Group 1, Group 2, and Group 3, ReneNs positive group permission set includes all of the permissions granted to those groups. For a given user, the net group negative permission set is the union of all the negative permissions of each group and organization to which the user belongs. This includes permissions denied for the pseudo-group ALL. Similarly, the permissions denied to Group 1, Group 2, and Group 3, are also denied to user ReneN, a member.
When the permissions are calculated for the ACL, the difference between the positive and negative group permission sets for user ReneN is used to determine access rights. For example, as a member of Group 1, ReneN is granted read permission to all incident reports in the Under Review life cycle state in the /Acme domain. However, ReneN is also a member of Group 2, which is denied
10-9
read access to incident reports in that domain. When calculated, ReneN's permission to read incident reports is set to null for the /Acme domain. The following table provides some further examples of permission calculation. Assume you, the administrator, are creating an access control policy for several domains. One of the users you have identified, Ann, belongs to two groups, G1 and G2. If you assign permissions as shown in the table, Ann's resulting permissions are identified in the last column.
G1 Permissions G2 Permissions Union of G1 and G2 Individual Permissions Resulting Permissions
+ + + + -
Modify (M) Null set (M) -(D) (M) -(D) (M) Null set
Create (C) Null set (C) -(M) (D) -(C) (C) Null set
(C)+(M) Null set (C) -(D) (M) -(C) (M)+(C) Null set
Delete (D) Null set (D) Null set (C) -(M) (D) -(M)
(C)+(M)+(D)
(C), (D)
(C)
(C)+(D)
When you have defined the access control rules for domains, all of the instances of the object type of a particular state, and belonging to the same domain for which you have created rules, share an ACL. This association between the ACL and the object type, state and domain is preserved thereafter. When a principal attempts to access an object (for example, to view it or modify it), the associated ACL is retrieved, and the policy is enforced. Once an ACL is calculated, it is cached so it can be retrieved quickly for the next access request. For example, assume that within the /Acme domain, user Audrey.Carmen is a member of a group that has read, delete permission for all objects of the type WTObject that are in the Closed state. She is also a member of a group that has modify permission for all incident reports within the /Acme/Support domain in the Closed state, where IncidentReport is a soft type of WTObject. However, there is another access control rule within the /Acme domain for Audrey.Carmen as an individual user, that explicitly denies her delete permission for incident reports in the Closed state. The following shows the ACL entry for Audrey.Carmen that is associated with incident reports in the Closed state within the /Acme/Support domain: +Audrey.Carmen read, modify When this ACL entry was derived from the access control policies for the /, /Acme, and /Acme/Support domains, Audrey.Carmen was given read and modify permissions. Because IncidentReport is a soft type of WTObject, Audrey's read
10-10
and delete permissions for objects of type WTObject also apply to incident reports. However, because there is another access control rule that explicitly denies her delete permission for incident reports in the Closed state, she is not able to delete objects of that type/state combination belonging to the /Acme/Support domain.
Rules Governing Domain-based ACLs and Ad Hoc ACLs

An access control rule for the domain applies to an object type. An ad hoc ACL applies to a specific instance of that object type. The ad hoc ACL, however, specifies only positive (+) permissions; it cannot be used to deny access to an object. If the ad hoc ACL grants a permission that is denied in the policy ACL, the ad hoc rule supersedes the policy rule, and the access right is granted.
Distributed Administration of Policy Rules

Distributed administration is the administering of a Windchill solution by different groups of individuals. Each group has responsibility for a particular area of the solution, with enough privileges to fulfill their administrative responsibilities. Domains demark administrative areas in Windchill. Windchill supports distributed administration of access control, indexing, and notification policy rules. General information about setting up administrators can be found in Establishing Administrators. Access control, indexing, and notification rules are members of the domain to which the rule applies. For example, if you define an access control rule granting Read access to documents belonging to the Publications domain, then the rule itself belongs to the Publications domain. This allows policy rules to be administered by different groups of administrators. To give a group of administrators the rights they need to manage policy rules for an area of the system, you need to define access control rules granting permissions to the group for the AccessPolicyRule, IndexPolicyRule, and NotificationRule object types, and the domain associated with their area of responsibility. A predefined access control rule for the / (Root) domain in the Site container, grants all permissions to the Administrators group for all objects, so members of this group can manage policy rules for all domains. For example, consider the following rules:
Domain Type State Principal Permission
/ (Site) / (Site) / (Site)
AccessPolicyRule IndexPolicyRule NotificationRule
All All All
MarketingAdministrators MarketingAdministrators MarketingAdministrators
+Read +Read +Read
10-11
Domain
Type
State
Principal
Permission
Rule 4:
Marketing (Windchill PDM) Marketing (Windchill PDM) Marketing (Windchill PDM)
AccessPolicyRule
All
MarketingAdministrators
+Full Control (All) +Full Control (All) +Full Control (All)
Rule 5:
IndexPolicyRule
All
Rule 6:
NotificationRule
All
These rules grant all permissions to the MarketingAdministrators group for the policy rule object types in the Marketing domain of the Windchill PDM library container. They allow members of the MarketingAdministrators group to view, create, update, and delete rules in the Marketing domain or any of its descendent domains, but not to manage rules in any ancestor domains. The rules granting read permissions to the MarketingAdministrators group for the policy rule object types in the Root domain allows members of the MarketingAdministrators group to see the rules inherited from ancestor domains.
About Predefined Access Control Policy Rules

When a Windchill solution is installed, the set of access control policy rules that are described in the Installed Site Container Policies section of the Administering Containers chapter is created for the initial domains in the Site container. Similarly, additional access control rules are created when an organization container or an application container is created. For the details on the organization rules, see **add links to Org chapters/section**. For the details on the product and library rules, see the Out-of-the-box Container Access Control Policies section in the Administering Products and Libraries chapter. For the details on the project rules, see **add link**. Caution: The access control rules set for the domains in the Site container should not be modified without considering the full consequences of the modification. For example, changing the rule that grants Administrators Full Control (All) on the WTObject object type in All states should not be modified. If this rule is removed by mistake, you cannot administer your Windchill solution. Caution: Creating rules that deny permissions for the pseudo-group ALL is also discouraged. Denying access to ALL includes denying access to users in the
10-12
Administrators group unless there is a rule granting access to an individual user that is in that group. To repair the removal of the Administrators rule described above or to remove rules such as a rule that denies access to all principals, complete the following steps: 1. Using the xconfmanager from within the windchill shell, set the wt.access.enforce property in the wt.properties file to false:
xconfmanager -s wt.access.enforce=false -t <Windchill>/codebase/wt.properties -p
Note: Setting this property to false turns off access control. This means that none of the access control rules are enforced. 2. Restart Windchill so that the new property value is used. 3. Recreate the rule that was deleted using the Policy Administrator. 4. Set the wt.access.enforce property back to true and restart Windchill. For additional information about using the xconfmanager utility, see About the xconfmanager Utility in the Administration Overview chapter.
Managing Access to Enterprise Information

This section describes access control issues and strategies related to managing access to your enterprise information. The following characteristics of objects impact what access control rules need to be defined to manage access to your enterprise information and to define strategies for managing the information: Domain administered information -- includes any object that belongs to a domain. Policy and ad hoc access controlled information -- includes any object to which domain-based access control rules or ad hoc access control rules can be applied. Content holder information -- includes any object to which files and URLs can be attached. Foldered information -- includes any object that is contained within a folder. Foldered objects are manifested in the interface as cabinets and subfolders. Life-cycle managed information -- includes any object that is life-cycle managed. Each life-cycle managed object has associated life cycle state. CAD document information -- includes the objects that are used when creating and working with CAD documents. For additional information, see the workgroup manager guide that describes how to administer CAD documents in your Windchill solution.
10-13
Note: A specific object type can have one or more of the characteristics and thus needs to have access control rules set in multiple ways. The rules and strategies you set up must take all characteristics into account. The following sections describe each characteristic and identify the access control requirements necessary for operating on an object that has the characteristic.
Domain Administered Information

Access control decisions for an object that is a member of a domain are based on the following criteria: Object Type Determines which rules within an access policy apply to an object. Domain The domain determines which access control policies apply to an object. An object's domain and type determine which policy ACLs are associated with the object. The policy ACL, in turn, specifies which principals have permissions for objects that share the same domain and type. The set of permission is described in Setting Permissions.
Required Rules for Domain Administered Information

The following rule governs the movement of objects among domains: Moving an object from one domain to another requires Delete permission for the object type in the source domain and Create permission in the destination domain.
For example, to change the domain of a cabinet in Windchill PDM, the user must have the rights to delete cabinets in its current domain and create cabinets in the target domain.
Policy and Ad Hoc Access Controlled Information

Objects that are policy or ad hoc controlled are subject to access control. The permissions that can be set on these objects are described in Setting Permissions. For example, to create an object of a specific type in a domain, a user must have Create permission for the object type in that domain.
Content Holder Information

A number of Windchill objects, including all document types and change objects (change requests, change orders, and change activities), are modeled as content holders. A content holder is an object to which files and URLs can be attached. For example, after a document is created and saved to the Windchill database, the user who created it can add a number of files and URLs to it, which are then uploaded to the database. When the document is later checked out, the user has the
10-14
option to download one or more of the content files, which can be replaced with new or updated content when the document is checked in. Users can also request that read-only copies of one or more content objects be downloaded to the local file system. That is, users can access content files without checking the content holder out of the database. The following are several access control implications for content holders: If a content holder object is not workable (that is, it is not eligible for check in and check out), Modify permission is required to update the object. If a content holder is workable (that is, it is eligible to be checked in and out), content can be added only to the working copy of the object, which is located in the user's Checked Out folder by default. You do not need to create separate access control rules for content associated with a content holder. Rules applied to the object govern access to its content as well. Through current Windchill solutions, the content of a document or change object is only visible when a user has access to the document or change object. Therefore, if you are able to check-out the object, you are able to modify content. Access control rules for the content holder are explicitly checked before any content is uploaded or downloaded. If you have Modify permission for the content holder, you can upload content, and if you have Read permission for the content holder, you can download content. Workable objects (those objects that must be checked out and checked in) need Modify permission to check in an object.
Foldered Information
The Windchill conceptual model for information storage is based on the organization provided by an operating system. The components of this model include the following: Cabinets -- a type of folder that is the top-level organizing mechanism in the Windchill solution. A cabinet is analogous to a disk drive in the Windows operating system. Cabinets are exposed in Windchill PDM, but not exposed in the Windchill PDMLink and Windchill ProjectLink user interface. However, Windchill PDMLink and Windchill ProjectLink do use cabinets internally. Subfolders -- a type of folder that holds objects and resides in cabinets or other subfolders. The top-level foldered object exposed through the Windchill PDMLink and Windchill ProjectLink user interface is called a Folder and has the subfolder object type. Within a solution container, all subfolders are members of either the Default or System container cabinet.
10-15
Folder members (also called foldered objects) -- objects that must be stored in a folder.
The following sections provide more information about cabinets, subfolders and access control rules related to foldered information.
Cabinets
In addition to being a folder object, a cabinet is a domain administered object. When a cabinet it is created, it is associated with a domain, which determines its policy rules and administrative policies. In Windchill PDM, if no domain is selected when a cabinet is created through the Windchill Explorer, / (root) domain in the Site context is associated with the cabinet. A cabinet can contain folder members, which include subfolders and shortcuts to other folder members. Cabinets cannot contain other cabinets. In Windchill PDM, the wt.admin.displayDomains preference determines the visibility of the domain a cabinet or subfolder belongs to on properties pages, and on dialogs for creating and updating cabinets and subfolders within Windchill Explorer. If the value is true, the cabinet or subfolders domain is displayed. For subfolders, inheritance of the domain from a parent cabinet or subfolder is also displayed. If the value is false, the domain information is not displayed. A cabinet may have a primary owner. By default, the owner of a cabinet is also the owner of all information stored in that cabinet. In general, cabinets provide an organizational root for information. To facilitate organization and control of information, the system provides the following two types of cabinets: personal: A personal cabinet is associated with a single user, who is considered its owner. In other words, you are the owner of your personal cabinet and all of the information it contains. In Windchill PDM, access to personal cabinets is through the Windchill Explorer and the personal cabinet icon. In Windchill PDMLink and Windchill ProjectLink, access to personal cabinets is through a users work list items; there is no direct access to personal cabinets. shared: A shared cabinet is not associated with a single user and does not have an owner. Like a common filing cabinet, a shared cabinet contains information intended to be shared among users and groups. A shared cabinet has no owner, and the information stored in that cabinet also has no owner. The administrative rules determine who has access to the shared cabinet and its objects. The shared cabinets within the system can also be thought of as a vault for storing information. However, the access control rules applied to the domain associated with the cabinet determine the level of security the cabinet provides.
10-16
Subfolders
Similar to that of an operating system, in which a root directory contains both subdirectories and files a subfolder is used to hold Foldered objects. Subfolders reside in cabinets or other subfolders.
Foldered Objects
A folder member (or foldered object) must always reside in a folder, whether a cabinet or a subfolder. A folder member can be located in only one folder at a time, and its identity must be unique within that folder. However, you can use a shortcut to make a foldered object that resides in one folder also appear to be in another folder. By default, the owner of a folder member is the owner of the folder in which it is located.
Domain Inheritance for Foldered Objects in Windchill PDM

The domain association for a foldered object (other than a cabinet) is inherited from its parent, unless a domain has been explicitly associated with the foldered object. For example, assume that the following structure exists: A cabinet named Publications belongs to the Pubs domain. A subfolder named Technical Documents (located in the Publications cabinet), belongs to the TechDocs domain. A subfolder named Installation Guides (located in the Technical Documents subfolder), inherits its domain from its parent subfolder.
In this example, both subfolders are governed by the policies defined in the TechDocs domain. The following rules govern the movement of subfolders: If the subfolder inherits its domain, the subfolder and all its folder members that also inherit their domain are governed by the administrative policies in the domain associated with the subfolders new parent, when it is moved. For example, if the Installation Guides subfolder was moved to another cabinet or subfolder, this subfolder and the folder members of the subfolder that inherit their domain from the subfolder would then be associated with the domain of the new parent. If the subfolder belongs explicitly to a domain, it continues to belong to that domain, when it is moved. For example, if the Technical Documents subfolder is moved to another cabinet or subfolder, its domain remains unchanged and both the Technical Documents and Installation Guides subfolders and the folder members of the subfolders that inherit their domain from the subfolders are still governed by the administrative policies of the TechDocs domain.
10-17
When you change a subfolder to inherit its domain, the domain of the subfolder, and all its folder members that inherit their domain, are changed accordingly. For example, if you change the Technical Documents subfolder to inherit its domain, then both the Technical Documents and Installation Guides subfolders are associated with the Pubs domain.
If you want to ensure that a subfolder retains the same domain association as its current parent, even if it is moved, you must explicitly associate the subfolder with the domain of its current folder. To change the domain of a subfolder, the user must have the right to delete subfolders in their source domain and to create subfolders in the target domain.
Required Permissions for Foldered Object Activities

The following rules govern foldered objects: To change the contents of a folder (for example, to create or delete foldered objects or to move objects from one folder to another), the user must have Modify rights for the folders involved in the change. To navigate to an object that is to be deleted or moved, the user must also have the Read rights to the subfolders in the path to the object. Because foldered objects are domain administered, the rules listed under Required Rules for Domain Administered Information also apply.
If the rules above are met, a foldered object in Windchill PDM can be moved as follows: From one shared cabinet to another From one personal cabinet to another From a personal cabinet to a shared cabinet
An object cannot be moved from a shared cabinet to a personal cabinet. Note: In Windchill PDM, parts must be created in the user's personal cabinet. They can then be moved to a shared cabinet, so others can access them.
Default Access Control Rules for Foldered Objects

By default, the Administrators group has Full Control (All) rights to a cabinet and all of its folder members. This is the case because of the predefined access control rule created for the Root domain granting Full Control (All) permissions to members of this group for objects of type WTObject and all of its soft types. Whenever you create a new Windchill user object, a personal cabinet is created for the user. Since a Windchill user name does not need to be unique and all personal cabinet names must be unique, Windchill uses the wt.folder.personalCabinetNamingAttribute property in the wt.properties file to determine what the initial personal cabinet name should be for a given user. In most cases, the name of the personal cabinet is the user's name. For additional
10-18
information about naming personal cabinets, see Naming a User's Personal Cabinet. By default, the personal cabinet is associated with a child domain of the User domain. The name of the child domain is usually the name of the users organization unless the user is not affiliated with a domain (see Managing Users for details). The user is the owner of the personal cabinet and any objects he or she creates within this personal cabinet or any of its subfolders. Therefore, the user has all rights to those objects. This is the case because of the predefined access control rule created for the User domain that is in the Site container. The rule grants Full Control (All) permissions to the OWNER of objects of type WTObject and all of its soft types. However, the domain with which the user cabinet is associated can be changed, and appropriate rules granting owner rights would need to be defined for any other domains associated with personal cabinets.
Life-Cycle Managed Information

A very important characteristic of an object is whether it is life cyclemanaged. Objects that are life cycle managed are also domain administered. Therefore, the criteria for the objects includes the domain-administered criteria. Access control decisions for life cyclemanaged information are based on the following criteria: Team Users can participate in a role for an object. The team stores the current team membership by role. The team is resolved using the team template, life cycle template and, for Windchill PDMLink and Windchill ProjectLink, the context team. For additional information on teams, see Administering Teams and Roles. Life Cycle Determines an object's initial life cycle state by associating the object with a life cycle template. Life cycle state influences both policy and ad hoc ACLs. The ad hoc ACL is computed by binding life cycle and team roles to principals. The ad hoc ACL is stored within the object. Life Cycle State Indicates the phase of the life cycle, which was used to compute the ad hoc ACL. It is used during execution to determine the policy ACL that is appropriate for an object. An object's domain, type, and life cycle state determine which policy ACL is associated with the object. The policy ACL, in turn, specifies which principals have which permissions on objects that share the same domain, type and life cycle state. When an object is associated with a life cycle or workflow activity, access to that specific instance of the object type can be governed by an ad hoc ACL, in addition
10-19
to the policy ACL associated with the object based on its domain, type, and state. The life cycle or workflow activity can include permissions for roles associated with each life cycle phase or workflow activity. For example, principals who fulfill a life cycle or workflow role by submitting, reviewing, or promoting the object to the next life cycle phase are given access rights. Ad hoc ACLs for a life cycle phase or workflow activity are in effect for the duration of that phase or activity.
Required Permissions for Life-Cycle Managed Object Activities

Modify rights for an object is required to set its life cycle state. However, if the activity is done through the Windchill Explorer in Windchill PDM, the user must also have Administrative rights to the object. Read rights to a life cycle template and team template is required in order to select them when creating a life-cycle managed object.
Example of Using Life Cycle Roles

When an object is created, the user is asked to select a life cycle and a team for it. Therefore, life cycle roles can be resolved by mapping them to team roles, which are then mapped to actual users. For example, assume the following: For the Under Review phase of the Development life cycle, the life cycle role Promoter is mapped to the team role Team Leader. In the Prototype team, Team Leader is mapped to Amanda Smith.
Then, user Pat Johnson chooses the Development life cycle and selects Prototype as the team when he creates a design document in his personal cabinet. Subsequently, Pat moves his design document to a shared cabinet. Later, when the design document is promoted to the Under Review phase in its life cycle, Amanda Smith becomes the Promoter. Although the policy ACL does not grant Amanda modify rights to design documents, she does have that access permission for Pat's document as long as the document is in Under Review phase (that is, until she submits it for promotion to its next life cycle phase).
Example Permissions Needed for Moving a Document

The following example illustrates the permissions that are needed for the move operation as a result of the characteristics of a document. Although the permissions can be granted by either policy or ad hoc access control rules, this example describes the use of policy rules. Moving a document from one folder to another requires the permissions described in the list below. For example, consider moving an object of type WTDocument (which is a foldered object) from one folder (which is either the SubFolder or Cabinet object type) to another.
10-20
Requires Read permission for the container that the document resides in because the document is contained. Requires Read permission for the document in the domain it belongs to (that is, the domain of the source folder) in order to select it for moving, because the document is access controlled. Requires Read permission for the document in the domain it belongs to after the move (that is, the domain of the destination folder) in order to view it once it has been moved, because the document is access controlled. Requires Modify permission on the source and destination folders because the document is foldered and the folder content is being changed (removing the document from the source folder and adding it to the destination folder). If the source and destination folders are in different domains, then the domain of the document will change when it is moved, since it is domain administered and inherits its domain from the folder it resides in. Changing the domain requires Delete permission for the document in the domain of the source folder and Create permission for the document in the domain of the destination folder.
Windchill PDM Example Permissions Needed for Creating a Part in a Shared Cabinet
The following Windchill PDM example illustrates the permissions that are needed to create a part in a shared cabinet or folder. The part can be created in the user's personal cabinet, and then can be checked in or moved to a shared cabinet. The permissions can be granted by either policy or ad hoc access control rules. Creating a part in the user's personal cabinet requires the following permissions. Requires Read permission for the container that the part is being created in, because the part is contained. Requires Create permission for the part in the domain it is being created in (that is, the domain of the personal cabinet), because the part is access controlled. Requires Modify permission on the personal cabinet, because the part is foldered and the folder content is being changed (adding the part to the personal cabinet).
In addition to these permissions, the user may also need permissions to other objects related to the part creation. For example, to select a view, a life cycle, or a team for the part, the user must have Read permission for the view, life cycle template, or team to be selected. Moving the part from the user's personal cabinet to a shared cabinet requires the same permissions as moving a document from one folder to another. The permissions are as follows.
10-21
Requires Read permission for the container that the part resides in because the part is contained. Requires Read permission for the part in the domain it belongs to (that is, the domain of the personal cabinet) in order to select it for moving, because the part is access controlled. Requires Read permission for the part in the domain it belongs to after the move (that is, the domain of the shared cabinet) in order to view it, because the part is access controlled. Requires Modify permission on the source and destination folders (personal and shared cabinets) because the part is foldered and the folder content is being changed (removing the part from the source folder and adding it to the destination folder). If the source and destination folders are in different domains, then the domain of the part will change when it is moved, since it is domain administered and inherits its domain from the folder it resides in. Changing the domain requires Delete permission for the part in the domain of the source folder (personal cabinet) and Create permission for the part in the domain of the destination folder (shared cabinet). Typically personal cabinets will be in a different domain than shared cabinets.
If the part is checked in to the shared cabinet, Modify permission on the part in the personal cabinet is also needed. This is because attributes on the part are changed as a result of a checkin.
Access Control Strategies for Cabinets in Windchill PDM

This section describes some strategies for developing access control policies for cabinets in Windchill PDM.
Access to Cabinets
Access control rules that apply to the cabinet (based on the domain it belongs to) do not extend to the objects located within that cabinet and its folders. For example, assume that user Bill Smith has Read permission for Cabinet type in domain X. However, having Read permission to cabinets does not give Bill Smith read access to documents in a cabinet. There must be an additional access control rule defined for documents that provides the Read permission. Also, consider the following example: User Bill Smith does not have Read permission for the Cabinet type in domain X. He does have Read permission for the Requirements type, a soft type of WTDocument, in domain X. Consequently, Bill Smith can search for and find Requirements documents that reside in domain X. However, because he does not have read access to the
10-22
cabinet itself, he cannot see the cabinet or any of its contents through the Windchill Explorer. As illustrated by this example, it is important that you create logical rules that provide users with the access they need. The following sections describe several strategies for creating rules to effectively manage both cabinets and the objects within them. These strategies assume that foldered objects inherit their domain from the parent folder, rather than explicitly assigning a domain.
Restrictive Rules for Cabinets

One way to manage access control for Windchill objects is to define rules granting limited access to the cabinet (applied to its ancestor type WTObject), and then to add more rules that grant some principals additional permissions for specific foldered object types. In general, this strategy uses the potential of shared cabinets for use as an information storage vault. For example, you may decide that all users within the system should be allowed to see the shared Development cabinet and its contents when they are navigating in Windchill Explorer. Also assume that only the Engineering and Design groups should be allowed to check out and modify Specification (which is a soft type of WTDocument) documents stored within that cabinet. The following rules (defined for the domain to which the shared Development cabinet belongs or for an ancestor of that domain), support this strategy: Rule 1: WTObject Rule 2: Specification + Engineering, Design Modify + ALL Read
All folder members must reside within a cabinet or a subfolder. In addition to permissions such as those above, the required rules described in Foldered Information apply.
Open Rules for Cabinets

Another strategy for applying access control to objects is to define relatively open rules for access to the cabinet (applied to its ancestor type WTObject), and then to add more rules that deny access to certain object types. For example, you may decide to grant all principals read, modify, create, and delete permissions to objects that belong to the domain associated with the shared Development cabinet. However, you may want to deny the Publications group the right to create, modify, or delete Specification documents, and deny the Marketing group the right to create, modify, or delete Requirements documents.
10-23
The following rules (defined for the domain to which the shared Development cabinet belongs or for an ancestor of that domain), would support this strategy: Rule 1: WTObject + ALL: read, modify, create, delete Rule 2: Specification Publications: create, modify, delete Rule 3: Requirements Marketing: create, modify, delete
Access Control Strategies for Life-Cycle Managed Objects

Consider starting with more restrictive access control rules and then using activity- or life cyclebased rules to open up access. Also consider placing rules that grant wide access to information or access to information in its final state in a policy ACL, as access can easily be extended or restricted. A policy rule can change access to many objects, while changing access control permissions in ad hoc ACLs requires action on each individual object instance. As described earlier, you can establish complementary access control rules for domains and the objects that are associated with them. Similarly, you can implement an access control strategy by balancing the use of policy and ad hoc ACLs. Conversely, you can create a domain policy that provides for more open access to cabinets and their contents. In this case, you would define few (if any), access control rules within the life cycle.
Combining Access Control Strategies for Cabinets and Life-Cycle Managed Objects
In some cases, you may decide to create restrictive domain policies, which provide only the minimum access to most users. Specifically, you can grant users read permission to one or more shared cabinets, so they can view the cabinet while withholding additional permissions for objects residing in the cabinet and its folders. Then, based on the life cycle and team associations for the objects within each cabinet, you can use ad hoc ACLs to grant certain principals the access permissions they need to fulfill their roles for a life cycle phase or workflow activity. Life cycle roles can be mapped to team template roles when a life cycle is created. For example, the life cycle role Promoter can be mapped to the team role Team Leader. When a team is defined, roles are mapped directly to specific principals or to actor roles (of which there is only the Creator actor role currently defined). In addition for Windchill PDMLink and Windchill ProjectLink, the context team roles and members are used. For additional information about teams, see Administering Teams and Roles. Additionally, life cycles can contain access control rules for specific phases and roles. For example, assume that the Development life cycle includes an Under
10-24
Review phase. The access control rules for this phase specify that for the duration of the phase, the Promoter role has modify permission for the object.
10-25
10-26
11
Using Types and the Type Manager
This chapter discusses the basic concepts of types and the runtime typing capability. It describes the Type Manager utility and how to use it to define new subtypes, attributes, and constraints. Topic Page
Overview of Types and the Runtime Typing Capability ..................................11-2 The Type Manager ..........................................................................................11-10
11-1
Overview of Types and the Runtime Typing Capability

The runtime typing capability allows you to augment Windchill out-of-the-box business objects without changing the object model and writing code. Typing allows you to fine-tune the system and address changing needs without recompiling, rebooting, or stopping operations. Instead of using Rational Rose to create a new class that extends an existing Windchill business class, you can create a new type of object. To do this, you must create a new type in the Windchill Type Manager. You can use runtime typing to: Augment a Windchill part or document by adding additional attributes, or adding new types with different attribute sets (implementation). Quickly show your end users how Windchill could be used to solve their business problem (prototyping environment). Distribute Windchill to multiple divisions, when each division wants to modify slightly the site-specific modeled classes to enhance the part and document definitions for their own division (deployment.)
The Type Manager user interface, described later in this chapter, allows you to perform the following actions: Create new types of the existing Windchill out-of-the-box part, document, and change objects, and any modeled extensions to these objects created at your site. Create new attributes for any existing type. Define constraints for any existing attribute. Update types, attributes, and constraints. Delete types and attributes. Duplicate types (by copying and pasting) and move types (by cutting and pasting).
Each Windchill out-of-the-box modeled class appears as a root node in the Type Manager. You can add subclasses to Windchill business objects using the Type Manager user interface. The Type Manager supports inheritance, providing the newly created subtype with both the modeled and non-modeled attributes of the parent type. Any modeled classes added at your site that extend the basic Windchill business objects will appear as subtypes for the Type Manager root node. For example, assume that your organization creates a subclass in Rational Rose named SiteDocument, which extends the Windchill base class WTDocument. The SiteDocument would appear as a subtype of WTDocument in the Type Manager, where you can add additional attributes, further refine constraints, or create new subtypes of SiteDocument with its corresponding attributes and constraints.
11-2
When defining a subtype, you can specify the description, display name, associated icon, attributes, and attribute constraints. The system supports providing the display values for types, attributes, and valid value lists in multiple locales. To add attributes to your type, select attributes from the global attribute set. The attributes you add can be optional or required, and constraints can be supplied for any of the new attributes. Constraints specify characteristics, such as range restrictions or a valid value set. You can also adjust or provide constraints on inherited attributes. For more information on creating attributes in the global attribute set with the Attribute Definition Manager, see Windchill Sourcing FACTOR! Installation and Administration Guide.
Effects of Deploying a New Type

When you deploy a new type definition, the type is recognized and used by the following Windchill functionalities: Access control policies Indexing policies Notification policies Life cycle template definitions Base loader Reporting Windchill adapter
You cannot define external file vault policies or replication policies specifically for a new type. However, the type inherits the rules that apply to the modeled class on which the type definition is based.
Using Typing in Conjunction with Classification

Windchills classification capabilities complement Windchills typing capabilities. Typing allows you to define the business process characteristics of an object that can be used for processing the object through its product life cycle. Classification allows you to define the attributes that describe the objects form, fit, and function, used to classify and organize a product master database to promote consolidation of suppliers and reuse of design components.
11-3
Overview of Classification
Windchills classification capabilities enable Windchill to become a searchable repository for part and supplier data. This allows your organization to consolidate suppliers, standardize parts, manage multiple part number schemes, and promote the reuse of design and component knowledge across the manufacturing organization. Sourcing administrators and design engineers can search the Windchill repository by navigating a textual hierarchy or image matrix, or by initiating parametric searches against attributes that describe the form, fit, and function of the business object. Advanced searching capability is available to help find second sources and functional equivalents for a selected part. If classification is implemented at your site, you can develop navigation structures to help end users in their searches. A navigation structure is a hierarchical set of navigation nodes, each with a textual representation and a graphical representation. Navigation structures present product data in a way that will help different users uniquely. For example, a design engineer may want to view a detailed mechanical hierarchy of parts with a large set of attributes, while a dealer is interested only in locating the springs used on a particular tractor model. While the user navigates a Windows-like folder structure, in the background, the system "navigates" an object type, such as parts or suppliers. Queries from this navigation structure are executed against objects of that specific type. Classification structures are a special case of navigation hierarchy, where a child in the hierarchy is always a type of its parent. Windchill classification structures provide templates for Classified Windchill objects, for example, parts and suppliers. Each node of a classification structure has an associated set of attributes that describe the parts form, fit, and function, as well as attribute value constraints and a representative graphical image. Classification node attributes and constraints are used as a template for assigning form, fit, and function attributes and constraints to newly classified parts and suppliers. The template is not strictly enforced, and the end user may optionally change the template definition depending on the form, fit, and function data available for any instance of the object being classified. A single instance of a part or supplier can be classified multiple times to reflect different views of the same business object.
Comparison of Classification and Typing

Windchills typing capability allows you to extend the Windchill data model without using the modeling and system generation capabilities of Windchills Information Modeler. The typing capability allows you to add attributes and further refine constraints for existing Windchill business objects. Typing also allows you to create subtypes of existing Windchill business objects and add attributes and constraints to those subtypes.
11-4
The attributes assigned through either modeling or typing are directly related to the product and process information necessary to manage the business object over its complete product life cycle. Product and process information is used to support business processes such as: the development of a Bill of Materials (BOM), support of where-used queries, and the development of a complete and accurate change history. Many of the attributes assigned to the definition of an object are inherited from fundamental Windchill base classes to support the management of the product through its life cycle. Other attributes are inherited through your organization's addition of new attributes using either modeling or the Type Manager. Classification allows the end user to omit defined attributes from a particular instance of a business object; however, modeling and typing strictly enforce their definitions of the attributes expected for each instance. Business objects can have multiple classifications, but only one type.
When to Use Typing and When to Use Modeling

The typing capability complements Windchills model-driven customization approach of modeling with Rational Rose, system generation, and Java coding. The modeling and Java coding-based approach should be used to provide fundamental new types of information in the system. For example, a plant object would be a new type of information, where new functional capabilities are required and new behavior must be added, through new methods or implementation of plug-and-play interfaces. You should use modeling in the following situations: You need to add behavior to an extension of a Windchill business class with new methods or plug-and-play interfaces. The modeled class could subsequently be augmented with additional attributes, added through typing, to reflect changing business needs at some time in the future. You want to develop granular policy rules for administrative policies that recognize typing. For example, if you want to develop a replication rule that would replicate only a particular type of part, you would need to create the part type by extending the part through modeling. This is because replication policies are based on classes. You want to make your tailored business objects visible to the end user and the rest of the Windchill system; however, the customization effort is less than the effort required to make the object visible through typing.
Localization of New Type Definitions

Types and their attributes can be localized in the same files and in the same manner as modeled classes and attributes; however, entries in these files are not generated automatically.
11-5
Soft Types can be localized just like hard types. For example, if one wanted to localize a soft-subtype of WTPart, the partModelRB.rbInfo would be appended with entries like:
# # # # # # # # # # # # Entry Format (values equal to default value are not included) <key>.value= <key>.category= <key>.comment= <key>.argComment<n>= <key>.constant= <key>.customizable= <key>.deprecated= <key>.abbreviatedDisplay= <key>.fullDisplay= <key>.shortDescription= <key>.longDescription=
where <key> is the external form for the soft type "WCTYPE|wt.part.WTPart| com.myco.MySoftPart" Attributes can be handled in a similar way, but the corresponding file is com/ptc/core/meta/common/DefinitionResource.rbInfo:
# # # # # # # # Entry Format (values equal to default value are not included) <key>.value= <key>.display= <key>.abbreviatedDisplay= <key>.fullDisplay= <key>.shortDescription= <key>.longDescription= <key>.dataType=
where <key> is the external form for the instance based attribute "IBA| mySoftAttribute"
Migration of Existing Type Instances to a New Type Definition

When a type definition is changed, existing type instances are updated, using a strategy called lazy migration. This means the affected instances do not need to be changed immediately (that is, as soon as the new definition is deployed), but only when an individual instance is updated. For example, if you add an attribute to a type, all new instances of the type will contain the default value for the newly created attribute; however, existing instances do not contain the additional attribute until an end user updates the instance. It is possible to force migration to the new type definition by populating the database entries programmatically.
11-6
Defining Additional Attributes

In Windchill PDM and Windchill PDMLink, you can define soft attributes in order to augment the attributes of out-of-the-box business objects. Soft attributes are non-modeled; they are created at runtime and do not require recompiling or interrupting operations. You can define attributes for the following object types: Documents and document subtypes Products Parts Serial numbered parts Problem reports Enterprise Change Requests (ECRs) Enterprise Change Notices (ECNs)
Caution: See Best Practices for Windchill PDMLink and Windchill ProjectLink for information about restrictions on creating soft types and soft attributes in Windchill PDMLink and Windchill ProjectLink.
Adding Attributes
To create or add an attribute in Windchill PDM, click Attribute Administrator on the Business Administrator page. From the Attribute Administrator window, click Attribute Definition Manager. To add attributes in Windchill PDMLink or Windchill ProjectLink, click Attribute Definition Manager from the Utilities page of the Site tab. Only site administrators can access the Attribute Definition Manager. Using the Attribute Manager, you can name and set the type of a new attribute. After the attribute has been created, you can update it to specify a description and display name. For more information about creating attributes, see the online help available for the Attribute Manager. To add an existing attribute to one of the supported object types, click Type Manager on the Administration tab. The left pane of the resulting Type Manager window shows object types. You can add an attribute to any of the supported types listed earlier in this section.
11-7
Note: The names shown for change object in the Type Manager window differ from those shown in Windchill. The following table explains how the change object names correspond:
Type Manager (Windchill PDM) Change Object Windchill PDMLink Change Object or Field
WTAnalysisActivity WTChangeActivity2 WTChangeInvestigation WTChangeIssue WTChangeOrder2 WTChangeProposal WTChangeRequest2
N/A Enterprise Change Notice (ECN) Implementation Task N/A Problem Report (PR) Enterprise Change Notice (ECN) Enterprise Change Request (ECR) Proposed Solution Enterprise Change Request (ECR)
Products and serial numbered parts are subtypes of WTPart. For more information about adding attributes, refer to the Attribute Manager online help, to Using the Type Manager, and the online help available from the Type Manager.
Client Changes
When you add attributes to objects, Windchill clients are affected in the following ways: On create and update HTML pages, additional attributes appear following the standard fields. Certain types of attributes cannot be set. See Types Not Supported in the HTML and Desktop Integration Clients. In PIM, to modify additional attributes in the create part and update part windows, click Edit Attributes. A dialog box opens to allow you to modify all additional attributes that have been added through the Type Manager. PIM supports all available attributes, including the attributes not supported by the HTML client. The default attribute values, defined in the Type Manager, are added to the part automatically if the user does not open this dialog during the creation of a part.
11-8
On details pages, additional attributes (referred to as properties in the user interface) are displayed in one of the following ways: Below the standard, out-of-the-box attributes. Generally, this is done when there is a small number of additional attributes. In a separate table. For products, parts, and serial numbered parts, the table is accessible from the View Additional Properties link below the attributes already displayed, or the Additional Properties navigation link displayed on the left side of the page. For change objects, the table follows the standard attributes. Generally, this is done when there is a large number of additional attributes.
The method used to display additional attributes is determined by a property set in the wt.properties file that establishes a threshold number of soft attributes. If the number of soft attributes on an object is less than or equal to the threshold, the soft attributes are displayed along with the standard attributes. They are displayed in a separate table only if the number of soft attributes is greater than the threshold. See Additional Attribute Properties. Note: If a discrete constraint has been defined for a String or Long attribute, the set of valid values for that attribute is presented in a drop-down list in HTML windows.
Additional Attribute Properties
The default for the number of additional attributes to be displayed on the Details page is six. If there are more than six additional attributes, a separate table is created. The administrator can change the number of additional attributes to be displayed on the Details page. The wt.properties to change are:
part.attributeNumber=6 document.attributeNumber=6 change.attributeNumber=6
Types Not Supported in the HTML and Desktop Integration Clients
There are types listed in the Attribute Manager that are not supported in the HTML and Desktop Integration clients. They are the following: Floating Point Number With Units Reference Hyperlink
Multiple values for attributes are not supported in the client. Only one value per attribute is accepted.
11-9
The Type Manager

Starting the Type Manager
To start the Type Manager, first ensure the method server is running. For more information, see System Configurator documentation in the Windchill System Administrators Guide. How you access the Type Manager is determined by your Windchill application: From Windchill PDM, you can access the Type Manager by clicking the Type Manager link that is on the Business Administration home page. From Windchill PDMLink and Windchill ProjectLink, you can access the Type Manager from the Utilities pages that are under the Site and Organization tabs. The Type Manager link from the Site tab provides you (as the system administrator) with unrestricted access to all types. The link from the Organization tab provides access to only those types that are in the organization context that is active when you launch the Type Manager.
A window similar to the following appears:
The left pane displays the type hierarchy in an expandable and collapsible tree structure. The right pane is used for viewing, creating, and updating types, attributes, their values, and their constraints.
11-10
Using the Type Manager

The following section displays two major examples: creating a new part and updating that part. The examples are based on a multinational company that has deployed a customized version of Windchill to a division. This division wants to further tailor one of the customized types. The customized version of Windchill contains a new modeled type named xyzPart, which is extended from WTPart. This division wants to create a new type, based on xyzPart, which will be named bizUnit1Part1. The new part will contain the following new attributes: cageCode, an integer value identifying the vendor. procurementLeadtime, a range of dates specified using timestamp values. system, a string type identifying whether the part is in the electrical, hydraulic, or pneumatic system.
After the new part is deployed, it will be updated to add an attribute named spare, which will be a Boolean value.
Creating a Type Definition

The following procedure creates the type and attributes described above. 1. Start the Type Manager, as described earlier in this chapter, and expand the desired node.
11-11
2. Select the type xyzPart, as shown in the following figure:
3. Click the Create icon. The Create Type window appears. 4. Fill in the appropriate fields for the new type, bizUnit1Part1, as shown in the following figure:
11-12
5. Click OK. The new part type appears in the type hierarchy, as shown in the following figure. The new part is checked out and unavailable for use in the system. The Type Manager remains in update mode.
6. At this point, you can add the new attributes: cageCode, procurementLeadtime, and system. To be accessible from the Type Manager, the attributes must be available from the global attribute set. a. To add attributes to the global attribute set from Windchill PDM, go to the Business Administration window and click Attribute Administrator. Note: You can create new attributes in the Attribute Administrator at any time, even before you start the Type Manager session. But, if you are already using the Type Manager, neither it nor the method server need be restarted for the new attributes to be available for use. b. From the Attribute Administrator window, click Attribute Definition Manager. To add attributes to the global attribute set from Windchill PDMLink or Windchill ProjectLink, click Attribute Definition Manager from the Utilities page of the Site tab. Only site administrators can access the Attribute Definition Manager. c. In the resulting window, select TestOrganizer and click the create attribute icon. Enter the name cageCode in the Name field, and select
11-13
Integer Number from the Data Type drop-down list. Click OK to create the new attribute. cageCode now appears as an available attribute, as shown in the following figure:
d. Add the remaining attributes using the same procedure, then return to the Type Manager. 7. Click the Template tab, which displays the types attributes and their default values. Initially, no attributes appear. (Although they do not appear on this tab, all modeled attributes of the parent type are inherited by the new type.) 8. Click Root, and click Add Attribute. This opens the Select Attribute window. Note: All actions for the buttons at the bottom of the Template page are also available through a right-click pop-up menu.
11-14
9. Expand the attributes available under TestOrganizer and select the kind of attribute desired, in this case, cageCode.
10. Click Select. This window closes, and you are returned to the Type Manager window, which now lists the new attribute cageCode. 11. Click in the Value field corresponding to the new attribute and enter a default value, in this case, 0. Note: A default value is required for each attribute you add. This value is the initial value that is given to the new instance of the type. The value is required to ensure there is at least one value for the attribute that is capable of satisfying the constraints you may define. (You are not allowed to check in any changes to types that violate their own constraints.) 12. Add the remaining attributes in the same manner. 13. To put constraints on any of these attributes, click on the desired attribute and click Show Constraint. The Constraint Editor window opens.
11-15
14. Click Add. The Base Selector window opens, as shown in the following figure.
15. Select the desired constraint. See Setting Constraints for more information. For example, to set a range for the procurementLeadtime attribute, select the RangeConstraint constraint, and click Select. The Base Selector window closes and you are returned to the Constraint Editor, which now shows the attributes constraint. 16. In the case of a range constraint, you are prompted to enter two values for the range, as shown in the following figure.
11-16
When you are ready, click OK to close the Constraint Editor window and return to the Type Manager window. 17. To specify allowable values for the attribute named system, a string type, select that attribute and return to the Constraint Editors Base Selector window (that is, select the system attribute, click Show Constraint, click anywhere in the Constraint Editor window, and select Add). In the Base Selector window, select the DiscreteSetConstraint and click Select. When you return to the Constraint Editor window, enter the possible values for system (electrical, hydraulic, and pneumatic) in the Data field of the constraint, separating each value by a vertical bar (|) and ending the list with the bar. Click OK to close the window and return to the Type Manager window. 18. At this point, the new attributes are created, and have associated constraints and default values.
Click OK to save the attributes and return to view-only mode. 19. Check in the new type by selecting it and clicking the Check in icon. The type is now available for use in the system.
11-17
Updating a Type Definition

The following procedure updates the type created in the preceding example and adds a boolean attribute named spare. Before an attribute can be added using the Type Manager, it must exist in the Global Attribute Set. You can add it using the same procedure given in the earlier example, or you can do it before or during your Type Manager session. The following example assumes it has already been created: 1. In the Type Manager window, select the type xyzPart and click the Update icon. The part is now checked out automatically and no longer available for use in the system. 2. Follow a procedure below to add an attribute and set a default value: a. Click the Template tab. b. Click the Root field and click Add Attribute. c. In the Select Attribute window, expand the TestOrganizer node and select the type of attribute you want. In this case, choose a boolean type and click Select. d. Enter the default value for the new attribute in the Value field. Even though the value True appears in the Value field, you must explicitly select it from the drop-down True/False list. 3. Click OK to save the new attribute.
11-18
4. Click the Check in icon to check in the updated type and make it available for use in the system.
New instances of the xyzPart type now have the spare attribute. Existing instances can wait until the first time they are accessed to be updated. At this time, the spare attribute, and its default value, are added to the instance. This is known as lazy migration and prevents excessive activity in the database when a new attribute is added or deleted.
Setting Constraints
The following table provides information about constraint types.
11-19
Type of Constraint
Applies to Attributes of Data Type
Can Apply to Container
Description The attribute value must be the same as one of the specified constraint values.
Example of Constraint Value String data type: constraint value set: abc|cde|efg Legal strings can be abc, cde, or efg Integer data type: constraint value set: 1|2|3 Legal integer value can be 1, 2, or 3 Note: | is the delimiter for the string values. Currently, | is the reserved character.
Discrete Set Constraint
All
No
Immutable Constraint
All
Yes
The user cannot change, add, or delete the value of the attribute. Notes: To add this constraint, the user has to same the attribute value first. After this constraint is imposed to the container, the container is frozen. It cannot be modified any further.
No constraint value.
Range Constraint
Can be applied to All data types, but will not be effective on boolean data type All
No
The actual value of the attribute must be greater than or equal to the maximum values specified (the range is inclusive) Note: "From:" specifies the minimum value. "To:" specifies the maximum value.
From: A To: Z. Legal strings can be Abc, BCDE, ...
Single Valued Constraint
Yes
No more than one value is allowed for a specific attribute. When applied to Container, no attribute can have more than one value.
11-20
Type of Constraint
Description Provide a set of basic masking to regulate the format of a string. The constraint value is a set of strings defining positional formats for the string content. C, L, and D in constraint value are reserved characters and should not be used as delimiters; all the other characters are considered delimiters. C means one letter or one digit. L means one letter. D means one digit. The definitions of letter and digit can be found in Java.lang.Character Class.
Example of Constraint Value 1. SSN Formatting value: DDD-DD-DDDD. Legal strings can be 12345-6789, 452-98-4444, ... 2. Telephone number Formatting value: (DDD)DDD-DDDD | DDD-DDD-DDDD | DDDD-DDD-DDDD. Legal string can be (555)454-6789, 555-1983247, 1-800-436-7869, 1800-CAN-HELP,... 3. Air flight seat number Formatting value: DL|D-L. Legal strings can be 1A, 3E, ... From: 3 To: 200. 3 <= length of legal string <= 200.
String Format Constraint
Can be applied to All data type, but only effective on String data type.
No
String Length Constraint
Can be applied to All data type, but only effective on String data type. All
No
The length of the string value must be greater than or equal to the minimum, and less than or equal to the maximum values specified (the range is inclusive). Note: "From:" specifies the minimum length. "To:" specifies the maximum length.
Suggested Values Constraint
No
Provide a set of suggested values to the Constrainable.
String data type: constraint value set: abc|cde|efg. Legal strings can be abc, cde, or efg. Integer data type: constraint value set: 1|2|3. Legal integer value can be 1, 2, or 3. Note: | is the delimiter for the string values. Currently, | is the reserved character.
11-21
Type of Constraint
Description The String values are converted to Uppercase when saved.
Example of Constraint Value No constraint value.
UpperCase Constraint
Can be applied to Add data type, but only effective on String data type. All
No
Value Required Constraint Wildcard Constraint
Yes
The attribute must have at least one value. When applied to Container, each attribute must have at least one value. The String attribute value must match the Wildcard pattern of constraint value specified. Contains: Contains the value specified. Begins With: Begins with the value specified. Ends With: Ends with the value specified. Exact: Exactly the same as the value specified.
Can be applied to All data type, but only effect on String data.
No
Contains abc. Legal strings can be Ababc, abcZ, AabcZ,... Ends With er. Legal strings can be Aer, Developer, ...

Note: The internet domain defined on the organization principal is important when creating new soft types. The internet domain is used to distinguish which organization owns the type. During the installation process, a default organization principal is created that contains an internet domain. The default organization principal owns the site container; any types owned by this organization principal is available to all organizations. In a non-exchange environment, create the first organization using the default organization principal. You should restrict soft type/soft attribute definitions. If not, client customizations are necessary to expose the new soft types and soft attributes. Site administrators can define the following: soft attributes for wt.part.WTPart soft attributes for wt.change2.ChangeIssue
11-22
soft attributes for wt.change2.ChangeRequest soft attributes for wt.change2.ChangeOrder soft attributes for wt.doc.WTDocument soft types for wt.doc.WTDocument soft attributes for sub-types for wt.doc.WTDocument
Organization administrators can define the following soft types for wt.doc.WTDocument soft attributes for sub-types for wt.doc.WTDocument
In a Windchill ProjectLink exchange environment, individual organization administrators will define WTDocument sub-types for the project contexts the organization is hosting. In a Windchill PDMLink environment (standalone or combined with Windchill ProjectLink), type management activities should occur only in the site context. In a Windchill PDM environment (standalone or combined with Windchill ProjectLink), type management activities should occur globally or only in the site context. Implications for Windchill users are as follows: Business objects created in the site context must be instances of modeled classes or instances of soft types defined in the site context. Business objects created in an organization context must be instances of modeled classes or instances of soft types defined in the site or given organization context. Business objects created in an application context must be instances of modeled classes or instances of soft types defined in the site or parent organization context.
11-23
11-24
12
Administering Indexing
Topic Page Overview ...........................................................................................................12-2 About Indexing Rules........................................................................................12-2 Creating and Managing Indexing Rules............................................................12-3 About Indexing Policy.......................................................................................12-3 About Indexing Lists .........................................................................................12-4 Defining a Collection ........................................................................................12-5
12-1
Overview
Indexing is the process of extracting text strings of attribute names and attribute values from Windchill objects and sending them to a search engine that builds indices optimized for searching. This enables users to efficiently search for data stored in a Windchill database, without having to know anything about the internal object model. Windchill solutions provide the option of installing RetrievalWare to help with indexing. For additional information about RetrievalWare and its indexing capabilities, see the Administering RetrievalWare Libraries chapter in the Windchill System Administrators Guide.
About Indexing Rules

Creating an indexing rule from within the Policy Administrator requires you to specify the rule antecedent and the rule consequent. The rule antecedent comprises the following parts: The domain. The object type-- determines which rules within an indexing policy apply to a specific object. The life cycle state, identifies the life cycle phase that an object must be in for a rule to apply. The collections into which objects are to be entered, when the objects belong to the domain, are of the type, and are in the life cycle state specified by the rule.
For example, you can define a rule specifying that a general document object is to be placed in a Released collection when the objects state becomes Released. Together, the domain indexing rules form the indexing policy for a domain. The rule consequent is a list of one or more collections. A collection represents a group of related objects that can be searched. It includes indices optimized for searching, as well as references to the actual object locations. Every indexable object carries a list of collections into which it is indexed. The first such list is assigned when the object is created. When the object is deleted, it must be withdrawn from every collection in which it is indexed. Between creation and deletion, the collections in which the object is indexed can change, based on the objects life cycle state and which domain it belongs to. When you create indexing rules, you customize the indexing policy for a domain by specifying which collections an object should move into (or be removed from) when the object moves into a specified life cycle state. From this policy, indexing lists are generated and associated with an object type. To improve performance, indexing lists are cached after they are created. An indexing rule identifies a life cycle state for a particular object type and the collections into which the object should be entered, based on the state that it is in.
12-2
There can be only one state and one object type specified within a single rule. However, each rule can identify multiple collections. An object type specifies a category of objects that share the same attributes and functions. For example, WTDocument is an object type, and instances of that type may be found in some of the domains you have created. Since Windchill domains are hierarchical, indexing rules defined for a domain are inherited by descendent domains. For example, indexing rules defined for the WTDocument object type in all states within the Design domain apply to instances of the type within that domain or any descendent domains. Because Windchill types are also hierarchical, an object inherits rules defined for its ancestor types. Therefore, more than one rule may apply to a given object. For example, a rule that applies to the type WTPart also applies to the type WTSerialNumberedPart. Additionally, there can be indexing rules specific to WTSerialNumberedPart.
Creating and Managing Indexing Rules

Use the Policy Administrator to create and manage indexing rules. Indexing rules are created and managed for a domain that is within a specific context as described in the Administering Domains and Policies section of the Administering Containers chapter. Open the Policy Administrator from the context of the domain where you want the indexing rules to apply. Select the domain and click Update. On the WAdministrative Domain window, click the Indexing tab to bring it forward.
Click the help icon located in the upper left hand corner of the window for specific instructions on retrieving, creating, updating, deleting, and reporting on indexing rules.
About Indexing Policy

This section describes the Windchill implementation of indexing policies.
12-3
Considerations for Establishing Indexing Rules

As you create an indexing policy, you may find it helpful to answer the following questions: Which life cycle states are associated with the most changes in business objects? You could decide to create rules that affect objects in the In Work state. Or, you might decide to index objects in the Under Review or the Released state. Do certain domains contain objects that are more dynamic than others or objects that users are more likely to search for? How do different types of objects undergo change in the system? How might rules differ for object types that are versioned (for example, document types) and object types that are not versioned (for example, change objects)?
About Indexing Lists

Indexing lists are generated for each object type, state, and domain. Objects are associated with the indexing list of the domain, type, and state to which they belong. For example, all WTPart objects in a given state and domain are associated with the same indexing list. The indexing list for WTPart objects is different from the list associated with other types of objects (for example, WTDocument objects) that are in the same state and belong to the same domain. An indexing list for an object is obtained by combining all rules that apply to that object based on its type, state, and the domain to which it belongs. A rule is applicable to a given type when the object type referred to in the indexing rule is the type itself or one of its ancestor types. For example, if IncidentReport is a soft type of the type WTObject, then a rule that applies to WTObject also applies to IncidentReport. In addition, rules are inherited from ancestor domains. As described above, this type and domain hierarchy means that more than one collection may have to be updated when a specific event occurs. Consider the following example:
Domain Context Type State Collections
/ /Publications /Publications
Site Windchill PDM Windchill PDM
IncidentReport WTObject IncidentReport
ALL ALL ALL
Current, Assignments Assignments CustomerX
12-4
The combination of these rules produces the following index list entry for IncidentReport in /Publications:
Domain Context Type State Collection(s)
/Publications
Windchill PDM
IncidentReport
ALL
Current, Assignments, CustomerX
As this list entry specifies, the Current, Assignments, and CustomerX collections must be updated whenever an incident report is created or modified that is associated with /Publications domain, which is in the Windchill PDM context, regardless of the life cycle state it enters. When you have defined the indexing rules for your domains, all of the objects with the same domain, type, and state combination for which you have created a rule share an indexing list. This association between the indexing list and the object is preserved.
Defining a Collection
Indexing is the process of extracting text strings of attribute names and attribute values from Windchill objects and sending them to a search engine that builds index collections optimized for searching. This enables users to efficiently search for data stored in a Windchill database without having to know anything about the internal object model. Windchill collections are defined in the wt.properties file. Each collection has properties that define the collection. For more information, see the Administering RetrievalWare Libraries chapter in the Windchill System Administrators Guide.
12-5
12-6
13
Administering Notifications
Topic Page Overview ...........................................................................................................13-2 About Notification Rules...................................................................................13-2 Creating and Managing Notification Rules.......................................................13-3 Notification Lists...............................................................................................13-4 About Notification.............................................................................................13-5
Overview
A notification policy determines who is notified when events of interest happen in the system. Note: Notifications are also generated as part of workflow processing. Workflow notifications can be more task specific. For more information, see the chapter entitled Administering Workflow Processes.
About Notification Rules

When you create notification rules from within the Policy Administrator, you specify who is to be informed when a given system event occurs within the context of a specific object. You can construct a rule for a domain, an object type, and an event posted by a manager type (ownership, locking, versioning, life cycle, and so on). The set of notification rules for a domain constitutes the notification policy for that domain. Actual notification is accomplished by sending an e-mail message to the users on the notification list. This message identifies the event and the object. Note: A user must have Read permission to an object to receive notification of an event applied to that object. Creating a notification rule requires you to specify the rule antecedent and the rule consequent. The rule antecedent comprises the following parts: The domain The object type, which determines which rules within a notification policy apply to a specific object The system event type (for example, Checkout).
The rule consequent is a list of one or more principals. A notification rule for a domain identifies a system event of interest for a particular object type and determines which users, groups, and organizations should be notified when one of those events occurs, for example, checkout. There can be only one event type and one object type specified within a single rule. However, each rule can identify multiple principals. An object type specifies a category of objects that share the same attributes and functions. For example, WTDocument is an object type, and instances of that type may be found in some of the domains you have created. Since Windchill domains are hierarchical, notification rules defined for a domain are inherited by descendent domains. For example, notification rules defined for the WTDocument object type in all states within the Design domain apply to instances of the type within that domain or any descendent domains. Because Windchill types are also hierarchical, an object inherits rules defined for its ancestor types. Therefore, more than one rule may apply to a given object. For
example, a rule that applies to the type WTPart also applies to the type WTSerialNumberedPart. Additionally, there can be notification rules specific to WTSerialNumberedPart. A principal is either an individual user, a group, or an organization. Typically, you should define notification rules for groups. Dealing with groups helps reduce administrative overhead by making it possible to apply rules to multiple users at the same time, enabling mass mailings for notification. Sometimes, however, you need to create rules specific to an individual user or to an entire organization.
Creating and Managing Notification Rules

Use the Policy Administrator to create and manage notification rules. Notification rules are created and managed for a domain within a specific context as described in the Administering Domains and Policies section of the Administering Containers chapter. Open the Policy Administrator from the context of the domain where you want the notification rules to apply. Select the domain and click Update. In the Administrative Domain window, click the Notification tab to bring it forward.
Click the help icon located in the upper right hand corner of the window for specific instructions on retrieving, creating, updating, deleting, and reporting on notification rules.
Notification Lists
Notification lists are generated from the notification rules for a domain and its ancestor domains. These lists are the basic mechanism for initiating user notification when an event occurs within the context of a specific object within the domain. For performance reasons, once lists are constructed, they are kept in a cache. Notification lists are generated for every combination of type, event, and domain. A notification list for an object that is the target of an event is obtained by combining all rules that apply to the event, the domain to which the object belongs, and the type of object. For example, the same notification list applies to the Create event for all WTDocument objects within a given domain. In addition, this notification list can be different from the list associated with WTPart objects, even if the objects belong to the same domain. To make this definition precise, it is necessary to describe how rules are combined and when a rule applies to a type. A rule is applicable to a given type when the object type referred to in the notification rule is the type itself or one of its ancestor types. For example, a rule that applies to the WTObject type also applies to the IncidentReport type if IncidentReport is a soft type of WTObject. This type of hierarchy, in addition to the domain hierarchy, means that more than one set of principals may need to be notified when a specific event is applied to an object. For example, consider the combination of the following rules:
Domain Context Type Event Principal(s)
/ /Publications /Publications
Site Windchill PDM Windchill PDM
WTObject WTObject IncidentReport
Create ALL Create
Marketing, Engineers Amanda.Smith Support
The combination of these rules produces the following notification list entry for IncidentReports created in the /Publications domain:
Domain Context Type Event Principal(s)
/Publications
Windchill PDM
IncidentReport
Create
Marketing, Engineers, Support, Amanda.Smith
As this list entry specifies, all members of the Marketing, Engineers, and Support groups, and also user Amanda Smith, must be notified whenever an incident
report is created in the /Publications domain. This result is based on the following application of the notification rules: 1. Members of the Support group are to be notified when an incident report is created in the /Publications domain. 2. Members of the Marketing and Engineers groups are to be notified when an object of type WTObject is created in the Root domain. IncidentReport is a soft type of WTObject, and the Root domain is an ancestor of /Publications, so this rule also applies to the incident report created in the /Publications domain. 3. User Amanda.Smith is to be notified of all events that occur to an object of type WTObject in the /Publications domain, which includes any event that occurs to an object of the soft type IncidentReport in the /Publications domain. When you have defined the notification rules for your domains, a single notification list is shared by all events with the same event type, target object type, and target object domain. When an event occurs to an object, the notification list associated with the object is retrieved, and the appropriate principals are notified of the event.
About Notification
Before the notification process can begin, the Notification Policy Manager subscribes to all system events that are specified in the notify.properties file. The following figure represents an overview of the notification process:
1. Event happens to object.
Object
2. Notification Policy Manager listens to events that may cause notification action. 3a. Event does not cause notification.
3b. Request for notification is queued.
4a. Notification message formatted and given to mail service. Fifo Queue 4b. Mail service sends message.
An event happens to an object (step 1). If it is an event for which the Notification Policy Manager is listening, the event and the object are posted to the manager (step 2).
The Notification Policy Manager checks to determine whether the event triggers a notification action. In many cases it does not, and can be ignored (step 3a). (For example, if the object does not belong to a type subject to notification rules, or there is no list for the domain/type/event.) In some cases, there is a notification list for the domain/type/event. When a list exists, the manager does not try to send the notification immediately. Rather, it queues the notification request for deferred processing in a FIFO queue (step 3b).
Later, the queued requests are asynchronously executed. These requests translate into calls, so that the notification message is formatted and then mailed using the mail service (steps 4a and 4b).
For more information about background processing queues and their maintenance, see the chapter titled Configuring and Administering Background Queues in the Windchill System Administrators Guide.
14
Administering Life Cycles
This chapter provides information about life cycles and the Life Cycle Administrator. Topic Page
Overview ...........................................................................................................14-2 The Windchill Life Cycle Model ......................................................................14-2 Life Cycle Iteration ...........................................................................................14-3 Creating a Life Cycle Template ........................................................................14-5 Life Cycle Properties.........................................................................................14-6 Defining Life Cycle Phases...............................................................................14-8 Predefined Life Cycle States ...........................................................................14-19 Import and Export ...........................................................................................14-19 Access to Life Cycle Administration ..............................................................14-21 Best Practices for Windchill PDMLink and Windchill ProjectLink...............14-21
14-1
Overview
Business information and business objects generally become more mature and reliable over time. Life cycles define the way in which these business objects mature, providing a model for a product's commercialization process. How you access the Life Cycle Administrator is determined by your Windchill solution: From Windchill PDM, you can access the Life Cycle Administrator by clicking the Process Administrator link that is on the Business Administration home page. Then click Life Cycle Administrator. From Windchill PDMLink, you can access the Life Cycle Administrator by clicking the Life Cycle Administrator link on the Utilities pages that are under the Site, Organization, Product, and Library tabs. The Life Cycle Administrator link from the Site tab provides you (as the site administrator) with unrestricted access to all life cycles. The link from the Organization tab provides access to only those types that are in the organization context that is active when you launch the Life Cycle Administrator. The link from the Product and Library tabs provides access to only those types that are in the context that is active when you launch the Life Cycle Administrator. From the Product and Library tabs, the Life Cycle Administrator shows all life cycle templates from that context, the organization context, and the site context. From the Organization tab, you see life cycle templates from the organization context and the site context. From the Site tab, you see only sitelevel life cycle templates. From Windchill ProjectLink, you can access the Life Cycle Administrator from the Utilities pages that are under the Site and Organization tabs.
This chapter describes how to define a life cycle using the Life Cycle Administrator.
The Windchill Life Cycle Model

A Windchill life cycle is an automated, graphical model, employing phases and gates, used to manage business objects as they progress from conceptualization through obsolescence. While an object is in a specific life cycle phase, certain business rules apply, such as access control rules defined for that phase. When created, an object modeled to be life cycle-managed enters a life cycle phase, where it is assigned an initial state, and is then associated with the initial phase of its life cycle.
14-2
The Windchill life cycle implementation also provides interface points for specification of workflow processes at each phase and gate. As a result of the automatic initiation of workflow processes, workflow tasks are assigned to participating users and are listed in the worklist of those users. A default workflow process sends a notification message to the Submitter role player, and is associated with entry into each life cycle phase. Another default workflow initiates Review and Promote activities when an object enters a life cycle gate. When an object enters a life cycle gate, it is awaiting promotion. When an object is considered ready for promotion to its next life cycle phase, it reaches a decision point (gate) for the phase. If the object is found ready to progress, the Promoter role player moves it to a new phase through an explicit promote action, executed on the task for promoting the object in the worklist/assignment table or it can be automatically done by a set state robot. Promote assigns a new state to the object and associates it with its next phase, where new business rules may apply. The state of an object is a measure of its maturity at any given time. State is an enterprise object, and its meaning is applied regardless of the life cycle by which a given object was processed. For example, if an access control rule applies to a Requirements object in the Under Review state, the rule is applicable to all Requirements objects in that state, even if they arrived at the state through different life cycles. However, each phase of a life cycle must be associated with a life cycle state chosen from among all states defined in the system. As a life cycle administrator, you can create a variety of life cycles. These life cycles, which are stored in the System cabinet (for Windchill PDM) or System folder (for Windchill PDMLink and Windchill ProjectLink), define the phases and gates associated with various business objects. For the life cycle of each object, you can define the transitions through which the object must move, and the behavior associated with the object while it is in a specific state. Windchill provides a Default life cycle, with many predefined states, such as In Work, Under Review, and Released. Before you begin creating life cycles, you should understand life cycle iteration and life cycle roles, as described in this guide.
Life Cycle Iteration

Working with life cycles is an iterative process. Like version-controlled objects, iterated objects are checked in to and out of shared locations; however, unlike version-controlled objects, they cannot be revised. Instead, any change to an object creates a new and separate iteration when it is checked in. Earlier iterations, which may still be in use, are unchanged and unaffected by the new iteration. Only the latest iteration is available for new uses.
14-3
To make changes to a life cycle template, you must check out a copy. (Click Update on the Life Cycle Administrator page to check out a copy of the selected life cycle.) While it is checked out, no one else can check out a copy, but the original can be viewed or selected to manage an object. When you have completed changes to the checked-out copy, you must save it and check it in, so it is available to others. It then becomes the latest iteration. Objects that are being managed by an earlier iteration continue to be managed by that iteration. They are not affected by the newer iteration.
Testing an Updated Life Cycle

Under normal circumstances, when you select a life cycle to manage an object, the latest iteration in the shared location is used. However, if you have the life cycle checked out and stored in your personal cabinet, the checked-out copy is used. This makes it possible to test a life cycle before checking it in. To update and test a life cycle, follow this procedure: 1. Check out a copy of the life cycle. 2. Update the copy, and save it to your personal cabinet. 3. Create a life cycle-managed object that uses that life cycle. The updated copy of the life cycle in your personal cabinet is used, rather than the current, checked-out iteration in the shared location. Before you can check in the updated life cycle or undo the check out, you must delete the life cycled-managed object. If you attempt to check in the updated life cycle, or undo the checkout while the object is still managed by the updated life cycle, an error message, similar to the following, is displayed:
The iteration of the <life cycle name> is used in <number> places. The following uses must be removed before completing the checkin...
Viewing Iteration History

To view the iteration history, select the object, then Iteration History on the Life Cycle Administrator navigation panel. A list of all the life cycle iterations appear with the date and time of last modification, and the name of the modifier. Select any iteration, and click View to view the life cycle.
14-4
Creating a Life Cycle Template

The Life Cycle Administrator page displays a list of existing life cycle templates and their locations. Using the buttons on this page you can create, update, view, and delete life cycles. You can import and export life cycles among other functions. To create a life cycle, click Create to open the Create Life Cycle window. To update a life cycle, click Update to open the Update Life Cycle window. Update uses essentially the same procedures as create, but you change information, rather than creating it. When you update a life cycle, it is automatically checked out. You must have the necessary access permissions to create or update a life cycle. If you do not have the required permissions, the Create and Update buttons are enabled, but you get an error message if you try the operation. Click Help on the Life Cycle Administrator page for a description of the buttons and their functions. When you create a life cycle, you define the following: The properties of the life cycle, including name, location, the object types to which the life cycle applies, and whether the life cycle is enabled. (See Life Cycle Properties.) Phases and gates defining the life cycle. (See Defining Life Cycle Phases.) Roles, such as Submitter or Promoter, for each life cycle phase. These roles are mapped to users, groups, organizations, actors, or other roles. (See Selecting Life Cycle Roles.) Access permissions for the roles associated with each life cycle phase. (See Defining Life Cycle Access Control Rules.) Workflow processes to be associated with each phase and gate. (See Associating a Workflow Process with Phases and Gates.) Promotion criteria to help determine whether or not an object is ready to move to the next phase in its life cycle. (See Defining Promotion Criteria.)
Use the toolbar buttons to create a graphical representation of the life cycle you are defining. For information on the buttons, see the online help.
14-5
Life Cycle Properties

In the Create (or Update) Life Cycle window, the Properties panel (the lower part of the window) displays the properties of the life cycle itself. When you select a phase icon, this panel reflects the properties of that phase. A life cycle has the following properties:
Life Cycle Property Description
Name
Specifies the name of the life cycle. Life cycle names must be unique. If you enter a name already in use, an error message appears. When you update a life cycle, you cannot change its name. This is a required property. Specifies the cabinet and folder in which this life cycle is stored. The System cabinet is the default location. This is a required property for Windchill PDM. Note: Only Windchill PDM allows the user to select the location. Windchill PDMLink and Windchill ProjectLink automatically check in the template to the System folder for the context in which it was created.
Location
Description Class Enabled
Specifies optional text describing this life cycle. Specifies the object type to which this life cycle applies. This is a required property. Indicates whether the life cycle-managed object is enabled or disabled. Select the check box to enable a life cycle-managed object when the life cycle is created. Typically, you clear the Enabled check box only when you plan to delete the life cycle in the future, when it is no longer being used by a life cyclemanaged object. Used only by Windchill ProjectLink, this property specifies the life cycle templates can be used for routings. Note: Only life cycle templates that have one workflow associated to the first phase of the life cycle support routing.
Routing
14-6
The following figure displays the Update Life Cycle window, with the Default life cycle and its properties displayed.
The Class display in the panel above provides a tree view of all object types subject to life cycle management. You must choose the type to which this life cycle will apply. Because Windchill types are hierarchical, the life cycle is applicable to the selected type and all of its subtypes. A type can inherit more than one life cycle; you can directly associate a life cycle with a given subtype. For example, you could associate a life cycle with the type WTObject, and all its subtypes would also be associated with that life cycle. You could also associate those subtypes (for example, WTChangeRequest) with other life cycles. When users create objects subject to a life cycle, they must choose an appropriate life cycle as part of the creation process. All of the life cycles in the current context, or inherited by ancestor contexts to which you have read access, that are associated with the type of the object appear in the drop-down list. If you want to use a life cycle defined for another object type, click Search to list all life cycles, irrespective of object type.
14-7
Defining Life Cycle Phases

The figure that follows displays the Create Life Cycle window. When you first create a life cycle, select the phase icon to see a single undefined phase, along with the window where you can define the phase properties. Here you can also use the tabs to define the characteristics of the life cycle phases and gates.
Note: To view the properties of the life cycle itself, click anywhere on the life cycle diagram background to open the PropertiesLife Cycle panel. The PropertiesLife Cycle panel also opens when you delete a phase.
14-8
The following table provides a brief description of the phase properties.

Phase Property Description
State
When you add a phase icon to the life cycle diagram, you must choose the state it represents from the dropdown list, which is populated with all available states. Windchill provides predefined states (for example, In Work and Under Review). You can define additional states by adding them to the StateRB resource file. When you select a state, its name appears on the phase icon. The other phase properties you add define the behavior associated with an object while it is in this state.
Roles
For each life cycle phase, you can select roles (for example, Reviewer or Workflow Assignee). Submitter is a required role for each phase. Promoter is a required role for all but the final phase of the life cycle. These roles are mapped to role players. A role player can be specified as a user, a user group, an organization, an actor, or another role.
Access Control
You can also define access control rules that will be in effect for this phase. These rules, which specify permissions for each role, will be added to those already in effect for the object, based on the domain's access policy. You can choose a workflow process to be associated with this life cycle phase and with the gate representing promotion to the next phase. You must define the criteria for promotion of an object from this phase to the next phase in the life cycle.
Workflow
Promotion Criteria
An object must be approved and explicitly promoted in order to move forward in its life cycle. To illustrate this, promotion gate icons divide the phases in the life cycle diagram.
14-9
Selecting Life Cycle Roles

Click the Roles tab of the PropertiesPhase panel to select the roles to be associated with this life cycle phase. When an object is promoted to this phase in its life cycle, these roles are resolved to principals (users, groups, or organizations) who perform one of the roles in the Available Roles list. The Submitter is responsible for submitting the object for promotion to the next phase in its life cycle. Submitter is a required role for a final life cycle phase only if another role (for example, Reviewer or Observer) has been added to that phase. The figure that follows shows the Default life cycle on the Update Life Cycle window, with the Roles tab panel forward:
To add a role to the phase, select the role and click Add to move it to the Selected Roles list. You can also click Add All to move all the displayed roles to the Selected Roles list. Click Remove or Remove All to delete roles from the list.
14-10
Note: The Available Roles list is populated with predefined roles. You can define additional roles by adding them to the RoleRB.rbinfo resource file. Defined roles are added to this list when you recompile RoleRB.info and deploy the class file to your production environment. For additional information, see Enumerated Types in the Windchill Customizer's Guide.
Role Mappings
A role mapping is resolved in one of several ways: You can directly map life cycle roles to users, groups, organizations, or other roles. However, since organizations generally want to define only a small number of life cycles, it is not often practical to map life cycle roles directly to principals. Using life cycles and teams together allows role participants to be identified at runtime, rather than making this mapping an explicit part of the life cycle definition. You can map life cycle roles to team roles. At runtime, the role is resolved according to the team role mapping. (For example, the life cycle role Promoter could be mapped to the team role Team Leader, and the life cycle role Promoter would be resolved at runtime according to the Team Leader role, as mapped in the team.) You can map a life cycle role to an actor. That is, you can map a role to someone who performs a specific action within the context of the business object. At runtime, this role is then resolved to the principal who created the object with which the life cycle is associated. For example, you could assign the Creator actor to the Submitter role for a given life cycle phase. For that phase, the user who created the object would be assigned the Submitter role at runtime. If the Submitter role is defined in the team, it resolves to the teams Submitter role.
14-11
Selecting Participants for Roles

To add participants to a specific life cycle role, select a role in the Selected Roles window. Then click Participants on the Roles tab, to choose participants for the selected role. The Participants for window opens (as shown in the following figure), allowing you to choose users, groups, organizations, an actor, or other roles to be mapped to this role.
Click the Groups tab to choose from the list of groups defined in the contextspecific list of groups filtered by service (source) and access control. Select All or a specific directory service, from the Source drop-down list. If you want to associate users, select All from the Source drop-down list to search the entire system, or select the group from the Group drop-down menu. To find a user, you can also enter the user ID or full name of a user, and click Find. Select a directory service from the Source drop-down list, or a group from the Group drop-down list to narrow your search. Click the Organizations tab to choose from the list of organizations. Select All or a specific directory service, from the Source drop-down list. Click the Actors tab and choose an actor to base your selection on a particular user action. Creator is the only actor defined. The Creator is resolved at run time to the user who created the selected object. Click the Roles tab and choose a role to resolve the life cycle role.
To add a principal to a role, select it and click Add to move it to the Participants list. You can also click Add All to move all the displayed users, groups, or organizations to the Participants list. Click Remove or Remove All to delete participants from the list. Click Help to view detailed instructions for selecting participants.
14-12
Defining Life Cycle Access Control Rules

Access to a specific object (for example, a document or a part) is controlled by the access policy for the domain in which the object is located. In many contexts, policy access control lists (ACLs) are sufficient for controlling access to objects; however, when an object is part of a life cycle, there are often many different principals who must participate in moving an object through its phases. Depending on your security needs, you may not want to create domain policy rules that provide all of the necessary permissions. If this is the case, access to an object can be controlled by an ad hoc ACL that is part of its life cycle. In general, policy ACLs apply to an object type within a domain, and ad hoc ACLs apply to an instance of the type while that object remains in a specific life cycle phase. Rules in an ad hoc ACL are added to the rules in the policy ACL for a given object. The ad hoc rules exist for the duration of a specific life cycle phase. These rules grant roles additional access to an object during the life cycle phase. This access is then revoked when the object moves to a new phase and the participant no longer needs the ad hoc permissions. Ad hoc ACLs can only grant permissions. They cannot be used to deny access to an object. To create ad hoc rules, you must select a life cycle phase on the Create/Update Life Cycle window. Click the Access Control tab, select a role, and choose the appropriate access permissions.
14-13
The following figure is an example of the Access Control tab panel:
14-14
All roles are automatically given Read permission, so the associated principals can access their tasks and view the object. By default, submitters are automatically given Modify permission so they can submit the object for promotion as part of updating it; however, you can change this at your site. For each role, you can also select one or more of the permissions described in the Administering Access Control earlier in this guide. You can also learn more about domain access control and the relationship between policy and ad hoc ACLs.
Associating a Workflow Process with Phases and Gates

By default, all life cycles have predefined workflow processes associated with the phases and gates. To change the workflow process that is associated with a phase or a gate, modify the following properties in the wt.properties file: wt.lifecycle.defaultPhaseProcess wt.lifecycle.defaultGateProcess
As shown in the figure that follows, the Submit process is automatically associated with the In Work phase. The Review process is associated with the gate by which an object moves from In Work to its next phase.
14-15
Note: Use Latest Iteration is selected, so the most recent iteration of the workflow process template is used at instantiation. If this check box is cleared, the specific iteration selected is used, even if it is not the most recent.
14-16
As a result, the Review workflow, which is shown in the following Workflow Process Manager figure, defines the process and activities that are part of moving an object forward from the In Work phase.
This workflow process has three defined activities: Review, Observe, and Promote. You can view the properties of each link and activity within the process on the Workflow Process Manager. For example, for the Review workflow, the participant to be assigned the Review task is the Reviewer role. Therefore, when an object is submitted for promotion from the In Work phase and the Review workflow process is started, the Reviewer role is mapped to an actual user based on role mappings in either the life cycle or a team. In Windchill PDM, the Review task is added to the Windchill worklist for that user. In Windchill PDMLink and Windchill ProjectLink, the Review task is added to the Assignments table for the user. The Submit and Review workflow processes are predefined and available for your use when Windchill is installed; however, your organization may have a number of additional workflow processes in place. To associate a specific workflow process with a phase or gate, click Browse to locate and select a process from the shared location.
Defining Promotion Criteria

Life Cycle Management does not enforce the satisfaction of promotion criteria. For example, reviewers' votes are not tabulated, and any reviewer is allowed to check off one or more promotion criteria. The promoter can choose to promote the object to its next life cycle phase, regardless of whether all reviewers have voted or all promotion criteria have been satisfied.
14-17
However, the following specifies promotion criteria guidelines you can use to help reviewers and promoters make appropriate decisions, based on your site's processes: Click the Promotion Criteria tab to view the existing criteria set. Click Create or Update to create or modify the criteria. Click Delete to remove a criterion.
The online help contains detailed instructions to help you perform these actions. The following example displays the Promotion Criteria tab panel:
14-18
When you click Create or Update, the Create Criteria window opens. Type a criterion statement in the field provided. For example, you could enter the following statement for a given phase of a life cycle:
All reviewers have voted for promotion.
This statement would then serve as a criterion for promoting an object from the current life cycle phase to the next.
Predefined Life Cycle States

Windchill includes many predefined life cycle states and roles. You can define additional states and roles by adding them to the StateRB.rbInfo and RoleRB.rbInfo resource files. Defined states and roles are added to this list when you recompile the resource files and deploy the class files to your production environment. For additional information, see Appendix A, Enumerated Types, in the Windchill Customizers Guide. Caution: Removing a value you previously added to an enumerated type (for example, removing a state in the StateRB.rbInfo resource file), could result in serious runtime error. Do not remove a state unless you are certain there is no reference to it within the system.
Import and Export

Preparing to Import or Export Life Cycles
Before you begin, you should be familiar with the following information regarding importing and exporting: Upgrade to the latest maintenance only release (MOR) as it becomes available, to ensure you have the latest enhancements to the import and export functionality. You can import a life cycle into a later version of Windchill, but not to an earlier version. That is, importing and exporting are not backwardly compatible. Importing or exporting life cycles creates objects in a JAR or ZIP file format. (This is the same format that the load.Installer functionality uses.) Importing a JAR or ZIP file with one or more XML files creates one or more life cycle templates (depending on how many templates were defined in the XML files). There is no limit to the number of life cycles that you can export. You can export multiple life cycles into a single JAR or ZIP file. Select them (on the Life Cycle Administrator page) and click Export. All the selected life cycles are exported to the same JAR or ZIP file.
14-19
Errors can occur, especially, when importing life cycles. Some errors result in messages displayed; others cause a loss of data. Check the method server log for error information. When you export a life cycle, only the life cycle itself is exported. This includes references to underlying objects, such as principals, roles, and actor roles. However, the underlying objects themselves are not exported. If the export file is used to import the life cycle into another system, the underlying objects must first exist in the system, or the import fails and errors appear in the method server log. This can occur, especially when importing the object into a different system. Be certain that all underlying objects referenced in the XML representation of the life cycle exist. If a life cycle is imported and a life cycle with the same name already exists in the Import directory, the results depend on the Iteration On Import setting in the wt.properties file. If it is set to true, the imported life cycle is appended to the existing life cycle as a new iteration. If it is set to false, the imported file causes a method server exception, stating that there is a duplicate name, and the life cycle is not imported.
Importing and Exporting Life Cycles

To import or export life cycles, use the Import and Export buttons in the Life Cycle Administrator window. To import one or more life cycles from a JAR or ZIP file in the life cycles export directory, select a file from the Import dialog box, and click Import. To export one or more life cycles into an XML representation of the life cycles in the life cycles export directory, use the following procedure: 1. Select a template from the Life Cycle Administrator window, and click Export. (The Export button is disabled if you do not have a life cycle selected.) 2. A grant permission window may appear asking for permission to access the local file system and to write a file on that system. If you select the remember selection check box, permission need only be granted once. Once permission is granted, a Browse for file picker opens, defaulting to the system temp folder. 3. You can pick a file that exists or type in a new name. If the file name exists, you are asked to confirm to overwrite the file. You must click Yes to continue the export. If the file name does not exist, a new file is created. There is no confirmation that the export is completed. When the progress bar and the hourglass on the life cycle administrator applet disappear, the export is complete.
14-20
If you want to use a template in another context (such as between two organizations, two solution contexts, or a solution and organization context), export the template from the source context and import it into the target context. You can update a template to make it specific to an organization or solution context by copying them (using Save As) from parent contexts.
Access to Life Cycle Administration

As described in the chapters entitled Administering Life Cycles and Administering Teams and Roles, administrators create life cycles and teams. The access control rules listed in the following table provide life cycle administrators with permissions needed to manage life cycles and teams, and to move them after they have been created. These rules need to be defined for the domains (or ancestor domains) associated with folders in which life cycle templates and teams will reside.
Object Type Permissions Required
AdministrativeDomain LifeCycleTemplate Team Cabinet SubFolder WTContainer
Read Read, Modify, Create, Delete Read, Modify, Create, Delete Read, Modify Read, Modify Read

Site, organization, and solution administrators manage life cycle templates. Site administrators create, modify, delete, and view life cycle templates in the site context. Organization administrators create, modify, delete, and view life cycle templates in the given organization context. Organization administrators can view life cycle templates from the site text. Solution administrator create, modify, delete, and view life cycle templates in the given solution context. They can view life cycle templates from the parent organization context and the site context. This includes administrators of Windchill PDM library contexts.
Note: The Life Cycle Administrator is not available to administrators of project contexts.
14-21
The Life Cycle Administrator client displays a table that lists all life cycle templates belonging to the given context, plus those belonging to its parent contexts. A column in the table identifies the context owning each life cycle template. When you create a life cycle template, the system saves the new life cycle template in the System cabinet or folder of the context in which it is created. Consequently, the Create dialog for life cycle templates disables the location field since it is the system, not the user, that decides where the new life cycle template is to be located. Note: When assigning a workflow template to a life cycle template, you see a list of valid workflows. The list of valid workflow templates includes the ones defined in the given solution context, plus those defined in the parent organization and the site contexts. Workflow templates defined in a sub-context override and filter out the workflow templates defined in parent contexts having the same name. The search scope used to locate groups is determined by the type of administrator doing the search. For more information about the search scope, see Searching for Principals in the Administering Containers chapter.
14-22
15
Administering Teams and Roles
This chapter provides information about teams, team templates, and roles. Topic Page
Overview ...........................................................................................................15-2 Out-of-the-Box Team Templates ......................................................................15-3 Defining Team Properties and Roles...............................................................15-16 Predefined Roles..............................................................................................15-18 Assigning Participants to Team Roles.............................................................15-19 Best Practices for Windchill PDMLink and Windchill ProjectLink ...............15-20
15-1
Overview
Teams and team templates are used throughout Windchill. A team template is an object managed by Windchill PDM and Windchill PDMLink administrative users. This object can map participants and actor roles to roles. The team template can be assigned to a life cycle or workflow-managed business object, when it is created, to use as a template for roles resolution for the team. A team is an object, created automatically when creating a business object, that contains all the roles consolidated from the team, life cycle, and workflow templates. Roles get mapped to end users; ad hoc access permissions are defined for the participants in the life cycle and workflow templates. Note: Windchill ProjectLink does not use team templates. To understand this section, you should be familiar with the following terms: A principal is an individual user, group, or organization. A role is a function that can be fulfilled by some principal. A role is mapped to participants. A list of predefined roles is available when you define a team. An actor represents a user who performs a specific action within the context of a specific business object. Currently, Creator is the only actor defined. A participant is a principal or an actor, which has been mapped to a specific role in a team.
This chapter describes the following: Team Roles Resolution Defining Team Properties and Roles Assigning Participants to Team Roles
Teams and team templates make it possible to define a smaller number of life cycles, since the life cycle roles can be mapped to team roles, rather than to specific users and groups. For more information about life cycles, see Administering Life Cycles. The differences and relationships between teams and team templates are summarized in the following list: Team templates are used only in the creation of teams. When a business object that requires a team is created, the necessary team is automatically created. Updates to team templates do not affect existing teams that were created from the template. Team template changes are reflected in new teams only. Each team created for a specific business object is distinct from other teams created for objects of the same type.
15-2
For example, two problem reports in the same library may have associated teams that initially appear to be identical, consisting of the same roles and participants; however, changes made to one of the problem report teams do not affect the other problem report team. Teams cannot be manually created from team templates. Team creation is automatic, based on associations to business objects and workflow requirements.
Note: For more information about how teams are automatically created based on team templates and object associations, see Team Templates and Object Types later in this section.
Out-of-the-Box Team Templates

Windchill PDM and Windchill PDMLink provide out-of the box team templates. The following sections summarize the team templates that are provided.
Windchill PDMLink Out-of-the-Box Team Templates

This section summarizes the team templates that are provided with Windchill PDMLink. These team templates are designed to work with the Windchill Change Management functions. In order for the Windchill Change Management functions to operate properly, each of the Change Management objects listed in this section must have an associated team template, and each of the associated team templates must contain certain roles. The following table indicates which team template roles administrators must define, and which are designed to remain empty. (A "Yes" entry in the Modify? column means an administrator should define the role.)
Team Name Problem Report Team Role Name Change Admin I Modify? Yes Notes Assign this role to the user serving as Change Administrator I for problem reports. This user is the initial reviewer of problem reports. This role is used for workflow notifications, and is automatically set to the creator of the problem report. It should be left blank in the team template.
Problem Report Author
No
Change Activity Team
Assignee Reviewer
No No
This role is set through the user interface. It should be left blank in the team template. This role is set through the user interface. It should be left blank in the team template.
15-3
Team Name
Role Name
Modify?
Notes
ECR Team
Change Admin I
Yes
Assign this role to the user serving as Change Administrator I for enterprise change requests (ECRs). This user is the initial reviewer of ECRs. Assign this role to the user serving as Change Administrator II. This user is responsible for creating enterprise change notices (ECNs). Assign this role to the users who are responsible for approving full-track ECRs. This role is used for workflow notifications, and is automatically set to the creator of the ECR. It should be left blank in the team template. This role is used for workflow notifications, and is automatically set. It should be left blank in the team template.
Change Admin II
Yes
Change Review Board ECR Author
Yes No
No
ECN Team
Change Admin III
Yes
Assign this role to the user serving as Change Administrator III. This user is responsible for auditing an ECN after it has been completed and before the product data is released. This role is used for workflow notifications, and is automatically set. It should be left blank in the team template. This role is used for workflow notifications, and is automatically set. It should be left blank in the team template. This role is used for workflow notifications, and is automatically set. It should be left blank in the team template. This role is used for workflow notifications, and is automatically set. It should be left blank in the team template. This role is used for workflow notifications, and is automatically set. It should be left blank in the team template.
Change Admin II
No
Change Admin I
No
ECR Author
No
No
Change Implementation Board
No
15-4
To associate a team template with a particular object type, use the Object Initialization Rules Administrator.
Windchill PDM Out-of-the-Box Team Templates

The out-of-the-box life cycle, team, and workflow templates that are provided with Windchill PDM are intended as examples of what a site might set up. The three templates include: Change Team Change Control Board Default
Change Team
The Change Team example team template is a companion to the following out-ofthe-box example workflow processes: Change Activity Process Change Order Process Change Request Process 1 Change Request Process 2 Change Analysis Process Change Investigation Process Change Issue Process Change Proposal Process
These workflow processes contain workflow task assignments and notification robots that refer to the roles defined in the Change Team template. The workflow templates are provided as an example and are not intended to be used without modification to suit your particular purpose. To learn from this example team template, study the workflow processes listed above. Look at each workflow task and observe the role assign to that task. Each task has a description and instructions to help you understand the purpose of the task. You will note that sometimes a single role is assigned multiple tasks, sometimes a role is assigned only a singe task, and sometimes the role exists only to send someone a notification.
Role Participant Principal or Actor Assigned
Product Manager Engineer
Administrators Administrators
15-5
Role Participant
Principal or Actor Assigned
Purchasing Agent Manufacturing Engineer Change Manager Change Owner Submitter ESI Administrator Quality Engineer Production Planner Design Engineer Change Admin III
Administrators Administrators Administrators Administrators Creator Administrators Administrators Administrators Administrators Administrators
Change Control Board

The Change Control Board is only an example team template. There are no corresponding out-of-the-box workflow process templates that use the specific set of roles on the team.
Role Participant Principal or Actor Assigned
Product Manager Change Manager Manufacturing Manager Change Owner Production Planner
Administrators Administrators Administrators Administrators Administrators
Default
The Default team template is empty and has no roles defined. It exists as a default team template that the system automatically chooses if no other team template is designated.
Team Templates and Object Types

This section describes how team templates are associated with Windchill object types. Object associations determine how teams are automatically created from team templates.
15-6
Out-of-the-Box Associations for Windchill PDMLink

The Windchill PDMLink out-of-the-box team templates are associated with the following object types:
Team Template Object Types
CA (Change Activity) Team ECN (Enterprise Change Notice) Team ECR (Enterprise Change Request) Team
wt.change2.ChangeActivity2 wt.change2.ChangeOrder2 wt.change2.ChangeRequest2 wt.change2.WTChangeProposal
Problem Report Team Default Team
wt.change2.ChangeIssue All other objects
With the exception of the Default team, the out-of-the-box team templates are stored in the PDMLink cabinet. The Default team is stored in the System cabinet. Note: The Default team template, which is stored in the System cabinet, does not contain any roles. If your site uses workflows to manage objects (such as documents and parts) other than change objects, you must add roles to the Default team template and any other team templates you create for use with non-change objects. The change objects listed in the preceding table are the object names used in Windchill. The following table illustrates how Windchill objects correspond to Windchill objects. ("NA" indicates that the object is not applicable.)
Type Manager (Windchill) Change Object Windchill Change Object or Field
WTAnalysisActivity WTChangeActivity2 WTChangeInvestigation WTChangeIssue WTChangeOrder2 WTChangeProposal WTChangeRequest2
NA Enterprise Change Notice (ECN) Implementation Task NA Problem Report (PR) Enterprise Change Notice (ECN) Enterprise Change Request (ECR) Proposed Solution Enterprise Change Request (ECR)
15-7
Team Association
To associate a team template with a particular object type, use the Object Initialization Rules Administrator. For additional information, see Administering Object Initialization Rules in the Administering Containers chapter. In the Site container, the value Default is set as the default team template for the following object types: ManagedBaseline WTProductInstance2 WTProductConfiguration You can also create organization-, product-, and library-specific team associations by creating a team template in the corresponding context.
Team Association Rules

When a workflow activity begins, an appropriate team is automatically created, according to the following rules: 1. If you have established a default team template in the product or library context, that team template is used as the basis for any new team. 2. If no corresponding team template exists in the product or library context, the default team template defined in the organization context is used as the basis for the new team. 3. If no corresponding team template exists in the organization context, the team template in the site context is used as the basis for the new team. 4. The team is given the same name as the object for which it is created. Note: The System cabinet/domain is used to store document templates. For each product and library, a context domain is automatically created for storing document templates. For more information about domains, see Administering Domains and Policies in the Administering Containers chapter. After a team has been created, users with the necessary permissions can update the team members by clicking the team name. On the Team page, click Update Team to make changes. For example, the out-of-the-box team template association for problem report objects is the Problem Report Team. If you were to create a problem report titled My Problem Report in the library called My Library, the team would be created according to the following rules: 1. If a team template called Problem Report Team exists in the My Library context, that team template is used as the basis for the new team. 2. If no Problem Report Team exists in the My Library context, the Problem Report Team in the organization context is used as the basis for the new team.
15-8
3. If no Problem Report Team exists in the organization context, the Problem Report Team in the site context is used as the basis for the new team. 4. The team will be named My Problem Report. Users with the necessary permissions can then modify the My Problem Report team by accessing the My Problem Report details page and clicking the team name. On the Team page, click Update Team to make changes.
Team Roles Resolution

The primary task in defining a team is selecting roles and mapping them to participants. To understand the concept and purpose of teams you should understand the relationship between teams and life cycles. (For additional information about life cycles, see Administering Life Cycles in this guide.) Business objects are associated with life cycles and teams, and roles are selected within these. The primary purpose of a team is to determine who is assigned the roles that are selected in a life cycle, that is, how life cycle roles are resolved to principals at runtime. Life cycles are more complex than teams, and they require more resources to create and maintain. Therefore, it is generally more efficient to create a relatively small number of life cycles with abstract roles and a larger number of teams that map roles to specific principals, which may change over time. Your site should have a policy regarding your use of teams with life cycles. As team administrator, you should be familiar with existing life cycles that might be associated with the team you are about to create. You should then select a role for the team for every role that exists in the relevant life cycles.
Initial Team Creation Windchill ProjectLink

If the object is assigned to a life cycle containing a phase workflow in the initial phase, the object uses the context team as the template. The role-participants of the context team are copied into the team. If the object is assigned to a life cycle that does not contain a workflow process in the phase of the initial state, it is assigned to a default team where the role-participants are meaningless. The team used for workflow and life cycle is created when the object is routed.
Windchill PDMLink
If the object is assigned to a team template, the team template is resolved into the team. Roles-principals are added and roles-actor roles are resolved to the users playing the role for the object and added to the team.
Role Resolution Rules

There is a property that is used to determine how roles are resolved. It is wt.team.re-resolveRoles. The default behavior is false.
15-9
Default Behavior
For the default, the following list illustrates the order in which Windchill tries to resolve each role in a life cycle: 1. If the life cycle role exists in the team, the life cycle role is resolved to principals (or the actor for the role), as defined in the team. All life cycle mapping for that role is overridden by the team values. 2. If the life cycle role does not exist in the team (that is, rule 1 does not apply), but the life cycle role is mapped to an existing team role, then the life cycle role is added to the team and resolved to principals, as defined in the team role. 3. If the life cycle role does not exist in the team and is not mapped to a role that exists in the team (that is, rules 1 and 2 do not apply), then the life cycle role is added to the team and resolved to principals, as defined in the life cycle. 4. If the objects context team contains the role, any participants who play the role in the context team that are not already members of the role in the team are added to the team. Note: Windchill PDM does not use context teams. 5. All roles that are not defined in the team, but are used in a related workflow process, are added to the team when the workflow process starts. If all life cycle roles also exist in the team, they are resolved directly, as defined in the team, without regard to life cycle mapping. This makes it convenient to define relatively few life cycles with abstract roles, which will be resolved to principals that are defined in teams. The following flow chart illustrates the Windchill business rules for resolving life cycle roles: Note: Although it is possible to define a team that does not map roles to principals, or even to define a team with no role mapping, with typical usage, such a team would be useless.
15-10
Life Cycle Role
Is the role selected in the team? No
Yes
Ignore all life cycle mapping.
Stop
Is the life cycle role mapped to a team role? No
Yes
- Add LC Role to team. - Resolve life cycle role to team role.
Stop
Is the life cycle role mapped to principals or the actor? No
Yes
- Add LC Role to team. - Resolve life cycle role as mapped in life cycle.
Stop
The role remains unresolved. Has a related workflow process started? No
Yes
- Add LC Role to team.
Stop
Stop
Any roles that exist in the team, but do not exist in the life cycle, are added to the life cycle and resolved to the team mapping.
Property Set to True

If the property wt.team.re-resolveRoles=true, the following list illustrates the order of role resolution: 1. If the life cycle role is mapped to an existing role in the team template, the role is resolved to the members in the team template. 2. If the life cycle role is not mapped to an existing role in the team template, the life cycle roles participants are resolved and added to the team in the role. Example 1: The life cycle contains Role A and is assigned to Role B. The team contains Role B with member user x. The team template does not contain Role A. Role A is added to the team with user x as the participant.
15-11
Example 2: The life cycle contains Role A and is assigned to Role B. The team contains Role B with member user x. The team template contains Role A with user y. Role A is added to the team with user y as the participant. 3. If the objects context team contains the role, any participants who play the role in the context team that are not already members of the role in the team are added to the team. Note: Windchill PDM does not use context teams. 4. All roles that are not defined in the team, but are used in a related workflow process, are added to the team when the workflow process starts.
Role Resolution Example

This section contains an example of how roles might be resolved for an document object that is associated with a team and a life cycle. The life cycle template contains the following roles:
1st Phase 2nd Phase 3rd Phase 4th Phase
Submitter Promoter Reviewer
creator
Design Engineer
Project Manager Prod Marketing
QA Engineer Pubs
Jane Design Engineer Project Manager QA Engineer
Observer
Not in this phase
Team Leader
Not in this phase
Not in this phase
The team template contains the following roles/participants: Design Engineer--Kristin Project Manager--Dave, John QA Engineer--Sean, Sachin Team Leader--Tom, Beth
The context team contains the following roles/participants: Design Engineer--Kristin, Flavio, Bill, Galen Project Manager--Dave, John Prod Marketing--Chris QA Engineer--Sean, Sachin, Iyrena
15-12
Pubs--April, Diane, Muriel Team Leader--Tom, Beth
First Phase
An object is created by Jeff and assigned to the life cycle template and team template above. The context team is list above. The team resolves to the following participants for the first phase:
Default (property set to false) Property set to true
Design Engineer Project Manager QA Engineer Team Leader Reviewer Submitter Promoter Observations:
Kristin, Flavio, Bill, Galen Dave, John Sean, Sachin, Iyrena Tom, Beth Kristin Jeff
Kristin, Flavio, Bill, Galen Dave, John Sean, Sachin, Iyrena Tom, Beth Kristin Jeff
Participants are added during the team template/life cycle role resolution. Participants (Flavio, Bill, and Galen) were added to the design engineer role from the container team. Roles from the container team that do not exist in the team are not added (in this case, Prod Marketing and Pubs). The life cycle Reviewer role is mapped to Design Engineer, but since the container team roles are not added until after the team template/life cycle role resolution is completed, the people in the Design Engineer role are not members of the Reviewer role.
Second Phase
The object is promoted to the second phase.
Design Engineer
Kristin, Flavio, Bill, Galen
Kristin, Flavio, Bill, Galen
15-13
Default (property set to false)
Property set to true
Project Manager QA Engineer Team Leader Reviewer Submitter Promoter Observer
Dave, John Sean, Sachin, Iyrena Tom, Beth Kristin Jeff
Dave, John Sean, Sachin, Iyrena Tom, Beth Dave, John
Tom, Beth
Tom, Beth
Observations are the same as for the first phase.
Third Phase
The team templates and container teams are modified. The team template contains the following roles/participants: Design Engineer--Kristin, Flavio Project Manager--Dave, John QA Engineer--Sean, Sachin, Dan Integration--Mark
The context team contains the following roles/participants: Design Engineer--Kristin, Flavio, Jeff, Michelle Project Manager--Dave, John Product Marketing--Chris QA Engineer--Sean, Sachin, Iyrena Pubs--April, Diane, Muriel Team Leader--Tom, Beth Observer--Jane, Lynn
15-14
.
Design Engineer Project Manager QA Engineer Reviewer Submitter Promoter Observer Team Leader
Kristin, Flavio, Bill, Galen, Jeff, Michelle Dave, John Sean, Sachin, Iyrena Kristin Jeff
Kristin, Flavio, Bill, Galen, Jeff, Michelle Dave, John Sean, Sachin, Iyrena Sean, Sachin, Dan
Tom, Beth Tom, Beth
Tom, Beth Tom, Beth
Fourth Phase
A set state sets the object to the fourth phase.
default (property set to false)
property set to true
Design Engineer Project Manager QA Engineer Reviewer
Kristin, Flavio, Bill, Galen, Jeff, Michelle Dave, John Sean, Sachin, Iyrena Kristin
Kristin, Flavio, Bill, Galen, Jeff, Michelle Dave, John Sean, Sachin, Iyrena Jane, Kristin, Flavio, Bill, Galen, Jeff, Michelle, Dave, John, Sean, Sachin, Iyrena
Submitter Promoter Observer Team Leader
Jeff
Tom, Beth Tom, Beth
Tom, Beth Tom, Beth
15-15
Observations: The Design Engineer and Observer do not exist in the life cycle template for the fourth phase, but they do exist in the team and container team. New members in the container team are added, but existing members are never removed.
Defining Team Properties and Roles

Note: The Team Administrator is not accessible from Windchill ProjectLink. To begin working with team templates in Windchill PDM, from the Business Administrator page, click Process Administrator > Team Administrator. For Windchill PDMLink, you can access the Team Administrator page in one of the following ways: From the Product, Library, Organization, and Site tabs, click Utilities. Click Team Administrator to access the Team Administrator. From the Product and Library tabs, click Templates. On the Templates table, select Team Templates from the Current View drop-down list. Click Administer Team Templates.
The Team Administrator page displays a list of existing teams. The Team Administrator refers to team templates as teams. Use the buttons on this page to create, update, view, delete, rename, and save as a new team. Click Help on the Team Administrator page for a description of the buttons and their functions. Click Create or Update to access the Create/Update Team window.
15-16
The following figure shows the Create Team window for Windchill PDMLink, with properties entered:
The following figure shows the Create Team window for Windchill PDM:
15-17
Notice there is a Location field that was not in the Create Team dialog box for Windchill PDMLink. Teams can be stored in or moved to any cabinet or folder for which you have the required access permissions. Team names must be unique within the context associated with the cabinet or folder in which the team is stored. The fundamental task in defining a team is selecting the roles that compose the team. The Available Roles list is populated with the names of all roles available in the system. To add a role to a team, select it and click Add to move it to the Selected Roles list. You can also click Add All to move all the available roles to the Selected Roles list. Click Remove or Remove All to delete roles from the team. Leave the Enabled check box selected to make the team selectable. Typically, a team is disabled only when you want to remove it. A disabled team remains in effect for all current usages, but cannot be selected for new objects.
Predefined Roles
Windchill includes many predefined life cycle states and roles. You can define additional states and roles by adding them to the StateRB.rbinfo and RoleRB.rbinfo resource files. Defined states and roles are added to this list when you recompile the resource files and deploy the class files to your production environment. For additional information, see Appendix A, Enumerated Types, in the Windchill Customizer's Guide. Caution: When you add a value to an enumerated type (for example, by adding a role in the RoleRB.info resource file), removing that value can result in a serious runtime error. Do not remove a role unless you are certain there is no reference to it.
15-18
Assigning Participants to Team Roles

To associate principals (users, groups, organizations) or actors with a team role, select a role from the Selected Roles list in the Update Team window, and click Participants. This opens the Participants selection window, shown in the following figure, where you can map users, groups, organization, or actors to the selected role:
To view the online help, which has detailed instructions for selecting participants, click Help. To search for groups, click the Groups tab. Select All or a directory service from the Source drop-down list, to narrow your search. To search for users, click the Users tab. Select All or a directory service from the Source drop-down list to search the entire system. To search for a specific user, enter information in the User Name or User ID fields, and click Find. Select a group from the Group drop-down list to narrow your search. To search for organizations, click the Organizations tab. Select All or a directory service from the Source drop-down list to search the entire system. To search for actors, click the Actors tab. To assign a role, select an actor. Currently, Creator is the only actor defined. The Creator is resolved at runtime to the user who created the selected object.
15-19
To map a participant to a role, select it and click Add to move it to the Participants list. You can also click Add All to move all the displayed users, groups, organizations, or actors to the Participants list. Click Remove or Remove All to delete participants from the list.

Site, organization, and product and library administrators manage team templates. Site administrators create, modify, delete, and view team templates in the site context. Organization administrators create, modify, delete, and view team templates in the given organization context. Organization administrators can view team templates from the site context. Product and library managers create, modify, delete, and view team templates in the given application context. They can view team templates from the parent organization context and the site context. This includes administrators of Windchill PDM library contexts.
Note: The Team Administrator is not available to administrators of project contexts. The Team Administrator client displays a table that lists all team templates belonging to the given context plus those belonging to its ancestor contexts. A column in the table identifies the context owning each team template. When you create a team template in the context of a non-Windchill PDM library container, the system saves the new team template in the System cabinet of the given container. Consequently, the Create window hides the location field because it is the system, not the user, that decides where the new team template is to be located. When you create a team template in the context of a Windchill PDM library context, the Create window allows the user to specify the cabinet or folder where the new team is to be located. The valid set of cabinets and folders include the ones contained by the Windchill PDM library. The search scope used to locate groups is determined by the type of administrator doing the search. For more information about the search scope, see Searching for Principals in the Administering Containers chapter. Note: Although you are allowed to create team templates using users, it is best to create them with groups.
15-20
16
Administering Workflow Processes
This chapter provides information about workflow processes and the Workflow Administrator. Topic Page
Overview ...........................................................................................................16-2 Workflow Iteration ............................................................................................16-3 Using the Workflow Process Editor..................................................................16-3 Import and Export ...........................................................................................16-26 Process Manager Toolbar Access Control ......................................................16-29 Viewing Workflow History.............................................................................16-29 Configuring Worklist Fields............................................................................16-35 Workflow Instance States................................................................................16-37 Domain-based Workflows...............................................................................16-38 Default Workflow Templates..........................................................................16-40 Electronic Signatures.......................................................................................16-42 Best Practices for Windchill PDMLink and Windchill ProjectLink...............16-44
16-1
Overview
A workflow system gives you the ability to automate procedures in which information, tasks, and documents are passed among participants. This procedure is based on a process composed of well-defined rules, designed to efficiently accomplish your business goals. This chapter provides information on creating and updating workflow templates, importing and exporting templates, and viewing workflow history. See the end of this chapter for detailed information concerning configuring worklist fields and object subscription code. See the step-by-step examples in the Workflow Tutorial for setting up and maintaining a workflow process. You can reach the tutorial by clicking (the library icon) from the Windchill PDM home page. From Windchill PDMLink or Windchill ProjectLink, you can click Publications in the global.header. You can also access it directly at:
http://<server name>/<install name/web server alias>/wt/helpfiles/help_en/online/workflowtutorial/WorkflowTut orial.pdf.
The Windchill workflow system, implemented by the Windchill Workflow application, consists of four components: The Workflow Process Editor, which allows you to define a workflow process and save your definition as a process template. This graphical editor and its use are the focus of this chapter. The workflow runtime system, which executes a defined workflow process within the context of a specific business object (for example, a part or a document). Process execution includes delivering work items to users participating in the process, opening applications (for example, automatically interacting with the Windchill Explorer to check a business object out of the database), initiating subprocesses, and so on. The way in which the end user interacts with a running workflow process is described in detail in the Windchill User's Guide. The Workflow Process Manager, a graphical tool for monitoring and reporting on workflow processes. (For access control information, see Process Manager Toolbar Access Control, in this chapter.) The Workflow History Viewer, which provides a simple ASCII interface used to access recorded workflow events, such as state changes, data transfers, or process start. The information in Viewing Workflow History can assist you in optimizing or streamlining a workflow process.
16-2
Workflow Iteration
Administering workflow templates is an iterative process. Like version-controlled objects, iterated objects are checked in and out of shared locations. However, unlike version-controlled objects, they cannot be revised. Instead, any change to an object creates a new and separate iteration when it is checked in. Earlier iterations, which may still be in use, are unchanged and unaffected by the new iteration. Only the latest iteration is available for new uses. To make changes to a workflow template, you must check out a copy. (Clicking Update on the Workflow Administrator page automatically checks out a copy of the selected template.) While it is checked out, no one else can check out a copy, but processes can still be initiated based on the current template. When you have completed changes to the checked-out copy, you must save it and check it in to make it available to others. It then becomes the latest iteration. Running processes that use an earlier iteration continue to run, unaffected by the newer iteration.
Testing an Updated Workflow Process Template

Under normal circumstances, when you initiate a process template, the latest iteration in the shared location is used; however, if you have the template checked out and stored in your personal cabinet, the working copy is used. This makes it possible to test a workflow process template before checking it in. To update and test a workflow process template, follow this procedure: 1. Check out a copy of a workflow template. 2. Update the copy, and save it to your personal cabinet. 3. Initiate a workflow process, based on that template. The updated copy of the template in your personal cabinet is then used, rather than the current, checked-out iteration in the System cabinet. You must either complete the running process, or stop and delete it before you can check in the updated workflow process template or undo the check out. If you attempt to check in the updated process template or undo the checkout while the process instance is running, the following error message is displayed:
Can't modify or delete template, <template name>; there are open instances.
Using the Workflow Process Editor

The Workflow Process Editor is a graphical interface for defining workflow processes that range from the simple to the highly complex. It features a large set of predefined activity nodes that you can place and connect. The Process Editor supports nested processes, branching, merging, loops for iterative activities, and defining assigned activities.
16-3
How you access the Workflow Administrator is determined by your Windchill solution: From Windchill PDM, you can access the Workflow Administrator by clicking Process Administrator on the Business Administration home page, then click Workflow Administrator. From Windchill PDMLink, you can access the Workflow Administrator by clicking the Workflow Administrator link on the Utilities pages that are under the Site, Organization, Product, and Library tabs. The Workflow Administrator link from the Site tab provides you (as the system administrator) with unrestricted access to all workflow templates from the site context. The link from the Organization tab provides access to the organization-level and site-level templates. The link from the Product and Library tabs provides access to those templates that are in the context that is active, plus access to the organization-level and site-level workflow templates. From Windchill ProjectLink, you can access the Workflow Administrator from the Utilities pages that are under the Site and Organization tabs.
Working with Workflow Templates

The Workflow Administrator page opens, displaying a list of existing workflow templates, with their locations enabled status, and context. Using the buttons on this page, you can create, update, view, and delete templates, as well other activities, including importing and exporting workflows. Click Create or Update to access the Workflow Process Editor. When you update a workflow process, it is automatically checked out if it is in a vault. For detailed help on using the Workflow Administrator, click Help.
16-4
The following figure shows the Workflow Process Editor displaying a Review process, (one of the default workflow templates included in an out-of-the-box system):
If you click Create, the Workflow Process Editor displays only the Start node.
16-5
You can display the workflow process with straight lines at any angle or with square lines horizontal and vertical lines and right angles. Click Straight Lines to use straight lines at any angle, as in the following figure:
16-6
Click Square Lines to use horizontal and vertical lines at right angles, as in the following figure:
To verify that your process definition is correct, select Validate All from the Process menu. The Validate window either confirms the process definition or identifies dangling activities or malformed processes. A Java compiler is integrated with the Process Editor to support expressions of arbitrary complexity. Workflow routing functionality includes links and event triggers. Events that cause a link to fire are displayed on the link itself, so anyone viewing the process definition can easily understand and verify the process behavior. For example, the Approve and Revise events in the previous straight line and square line examples are events that cause a link to fire. When you have completed your process definition, it is saved in your personal folder. To change a process definition that has been saved in a vault, it must be first checked out, and then checked in. Updating workflow processes is an iterative process. A new iteration is created when an update is checked in. You can view iterations on the Workflow Administrator page. The following sections describe the tools and components available to help you define a workflow process in Windchill.
16-7
Navigating a Process Diagram

The Workflow Process Editor is designed for easy navigation of processes and their subprocesses, using common Web navigation techniques. For example, you can edit a subprocess diagram, by clicking a subprocess hyperlink. To navigate between a parent process and a subprocess, use either the Back and Forward buttons, or the drop-down list in the Location field. The title bar of the Workflow Process Editor displays the name of the process or subprocess you are currently editing. Hyperlinks display the properties of each activity type and link, for example: Click an activity node hyperlink to open the properties dialog box for that activity. You can then create, update, or view the properties that define the node's behavior. Click the Properties hyperlink (at the right of the Location drop-down menu) to view and edit the properties of the process itself. Double-click the link that connects a node to open a dialog box to map events that are broadcast (or emitted) from the preceding activity to actions in the succeeding activity. By default, the completion event for a given task triggers the start of all successor tasks.
Placing Process Nodes

You can build a process definition by adding, selecting, and linking nodes that are represented by icons at the left of the workflow process editor. To add nodes to the process definition, select the appropriate icon and then click on open space within the process diagram. To select a node and display its properties, click the node hyperlink. To link two nodes, click the Action icon (a right arrow). Click and drag from the first node to the second node and release the mouse button. (A line with an arrow appears linking the nodes. The first node does not move to the second.)
The following list describes the process nodes that can be added to your process definition. The list is displayed in order of each icons appearance on the Process Editor. The Assigned Activity is an activity assigned to one or more users or user groups or an actor to perform. The Ad Hoc Activity is assigned to a user to define a group of activities at runtime. The group of activities is similar to a simple block. The Block represents a group of activities, connectors, or robots. You can reduce the complexity of a process by creating blocks of activities that can be expanded when needed.
16-8
The Proxy Process is a subprocess embedded within the main parent process, which can be nested to reduce complexity and provide reuse. The And Connector fires when all the predecessor links have fired, but not before. The Or Connector fires when any one of the predecessor links has fired. Preceding activities are terminated if Terminate Open Predecessor Activities when Fired has been selected. The Conditional Router allows you to branch a process based on a conditional expression. The Threshold Connector fires when a user-defined number of predecessor links have fired. Preceding activities are terminated if Terminate Open Predecessor Activities when Fired has been selected. The End stops the process. All process activities should eventually be connected to an end. The Ground stops a parallel branch of activities within the process, but it does not stop the process. The Notification Robot notifies the appropriate user with a user-defined email. You can use braces to delimit variables created for the process or node, for example, {varname}. Use back slashes to escape the delimiter, for example, \{{varname}}\. The Method Robot represents one of several single actions performed when adding the robot to the process. No other configuration is required. The following table lists the robot actions:
Robot Description
Checkin Checkout
Checks in the primary business object to the Windchill database. Checks out a business object to the specified user. For example, you can use the Checkout robot to automatically check a part out to the engineer assigned the task of applying changes after a design review cycle is complete. Causes the primary business object to transition to a predecessor phase, with an associated state change, and the application of new business rules (such as those for access control). Removes the primary business object from the gate and returns it to the submitter.
Demote
Deny
16-9
Robot
Description
Drop
Causes an object to be removed from its current life cycle and sets its state to dropped. For example, you could have a process branch in which two vendors submit bids for review. These bids could be entered into the database as Windchill documents, which would move through a review and approval process by application of a process definition. In this case, your process may require that, when one bid is approved, its document object is automatically promoted to its next life cycle phase, while the document containing the rejected bid is dropped from its life cycle and goes no further. Causes the primary business object to transition to a successor phase, with an associated state change and the application of new business rules, such as those for access control. For example, you could define a process in which an object is automatically promoted to the next phase in its life cycle, if a specific user approves the object. In this case, you could add the Promote robot to your process definition to execute all of the actions associated with an object's promotion. Sets a Life Cyclemanaged object to an ordinal state or a specific state. The ordinal state is entered as any nonzero integer. The specific state is selected from those defined in the wt.lifecycle.StateRB enumerated type. Moves the business object associated with this process to the gate for its current life cycle phase. After a submit, an object awaits promotion to the next life cycle phase. For example, you could add the Submit robot to a process definition to indicate that, when a user creates a change request, it is automatically submitted for promotion to the Open state.
Promote
Set State
Submit
The Timer Robot delays the start of an activity by a specified amount of time, based on the time it is fired or the time the parent process is begun. The Launch Application Robot executes system commands on the server. These commands are executed using the Java runtime.exe command. The execution can be either synchronous or asynchronous. The Execute Expression Robot enters a synchronous Java expression to be executed in a workflow. By default, the expression returns true. A return of false indicates a problem during execution, and an exception is thrown on the server.
16-10
The Synchronization Robot synchronizes the start of an activity or process with events that are not time related. You can set the robot to start an activity when certain generic external or Windchill-keyed events occur. The URL Robot executes a URL to communicate with another server, for such purposes as initiating various Info*Engine tasks or providing information necessary to complete workflow tasks. It can initiate an operation or retrieve status information to be collected in a string variable. HTML links to binary objects, such as graphics, can be retrieved, although the objects, themselves, cannot. You can specify the results of a failure by the robot to execute the URL. The following list of error codes may be helpful. For instructions see the help file. 400 Bad Request: Request has not been recognized by the server, because of incorrect syntax. The client should not repeat the request. 401 Unauthorized: Request requires user authentication. Under normal usage, the URL robot does not support authentication. Request should not be repeated. 403 Forbidden: Request has been recognized but the server has refused to honor it. Authentication was not the reason. The request should not be repeated. 404 Not Found: Server has found no match for the Request-URI. May be temporary or permanent. Repeat of request may be appropriate. 500 Server Error: Server has encountered an unexpected condition, which prevents it from fulfilling the request. Repeat of request may be appropriate. 501 Not Implemented/Internal Error: Server does not support the functionality required to fulfill the request. Request should not be repeated. 503 Service Unavailable: Server is temporarily unable to handle the request. Repeat of request may be appropriate. 504 Gateway Timeout: Server has not received a timely response from the upstream server specified by the URI. Repeat of request may be appropriate.
For more information on error messages, see the Internet standards at W3C HTTP RFC (http://www.w3.org).
Declaring Variables
When you define a process, variables can be used within transition condition or automatic routing expressions. Variables can be either global (applicable to the process itself) or local (applicable to an assigned activity or a subprocess).
16-11
Variables can be declared as any Java type or as any Windchill class. The only restriction is that the variable must be Serializable. If the variable is typed as a Windchill business object, attributes of that object can be referenced through standard getter APIs. Variables can be declared as follows: Visible or invisible Required or optional Read only or read/write Resettable or Static
Variable values can be initialized from parent process variables when an activity or subprocess is started and can also be copied into parent process variables when the activity or subprocess is complete. The following figure shows the Variables tab panel on the properties dialog box for an assigned activity named Activity 1.
16-12
To define additional activity variables, click Create. The Create Variables dialog box opens:
The online help file for this dialog box provides detailed instructions for variable declaration
Defining an Assigned Activity

An assigned activity is assigned to a specific user or group of users when an instance of this process definition is running. When you define an assigned activity, you specify a task that the selected user is to perform as part of a workflow process. In Windchill PDM, this task is added to the user's worklist. When the assigned activity is executed. See the Windchill PDM User's Guide for information about worklists. In Windchill PDMLink and Windchill ProjectLink, the task is added to the users Assignments table. See the appropriate users guide for more information about Assignments tables.
16-13
The following figure shows the properties dialog box for an assigned activity, with the General tab panel forward:
The assigned activity properties are described in the sections that follow.
General
On the General tab panel, shown above, you can specify a name, a category, a responsible role, and a description for the assigned activity. Name is the only required property. From the Category drop-down list you can categorize the activity. For example, you can have activity categories that reflect a team or product type. Windchill provides several predefined categories. Categories are an enumerated type, and you can define additional categories in the wt.workflow.definer.WfTemplateCategory file. For more information about enumerated types, see the Windchill Customizers Guide.
Activity
On the Activity tab panel, shown below, you can specify a task for a user or group to perform. Select a task from the drop-down list and, if desired, provide instructions in the Instructions text area. You can use braces to delimit variables, for example, {varname}. Use back slashes to escape the delimiter, as shown in the following example:
\{{varname}}\
16-14
If you want users to be notified by e-mail of the task assignment, check Send Notification. E-mail notification is optional, as tasks are always added to the appropriate user's worklist (for Windchill PDM) or Assignment table (for Windchill PDMLink or Windchill ProjectLink). If the Signing Required check box is displayed in the Activity tab, select the check box if you want an electronic signature required for the activity to be complete.
16-15
Participants
From the Participants panel, shown below, you can assign users, user groups, roles, actors, teams, or variables, to complete the assigned activity:
Although you have the option to assign an activity task to actual users or user groups as part of the process definition, you may find it more useful to select actors, roles, or teams as participants, which are then mapped to users or groups when an instance of the process definition is instantiated. Assigning participants in this way provides more flexibility and promotes reuse of a process definition in a variety of contexts. If you choose a role, such as Submitter, as the participant to whom the task will be assigned, the role is resolved at runtime by mapping it to a participant specified in a life cycle or a team (usually a team). For example, if the workflow process is applied to a specific document, the Submitter role in the relevant phase of the document's life cycle can be mapped to a Team Leader role in the team to which the document is assigned. The actual user to whom Team Leader is mapped then receives the task in his or her worklist (for Windchill PDM) or Assignment table (for Windchill PDMLink or Windchill ProjectLink) when this activity is fired. For more information on role mapping, with an extensive example, see Administering Teams and Roles. The selected assignees are displayed on a table, which specifies the participant types. You can designate whether a specific participant is required to complete the task or what conditions must be met to meet a requirement. (That is, any participant, all participants, or a specified number, must complete the activity.)
16-16
The Required drop-down list is not displayed for users or actors or if the assignee is not required to complete the activity. If a task is assigned to a group, the task appears in the worklists (or Assignment table) of all group members. (However, one group member can choose to accept the task on behalf of the group.) By default, the person creating the assigned activity is defined as the user who is assigned the task. To find a specific user, you can search the entire system, or narrow your search to your local system or a specific federated services or user group. If you want to map a role to a team other than the one associated with the process, you can select the team from the drop-down list at the bottom of the panel. This exception applies only to this specific activity. You can also map a task role to an actor, that is, someone who performs a specific action within the context of the business object. Currently, Creator is the only actor defined. Note: Click Help on the Participants tab panel for a help file, which documents specific procedures for assigning participants.
Deadline
On the Deadline tab panel, shown below, you can set the time that the activity is due. You can set the deadline in relation to the start of the activity or the start of the parent process. If you define them both, the earliest deadline applies. You can also designate the consequences and be notified if the deadline is overdue.
16-17
To designate the consequences of a missed deadline, select one of the following check boxes: Skip Mark complete Reassign to the responsible role
To designate who is notified and when, select any number of the following check boxes: To notify the user assigned to a specific role (in addition to the responsible role) when the activity is overdue, select the check box labeled Notify the selected roles. Then select any number of roles. To notify the responsible role before the activity deadline, select the upper check box labeled Notify the responsible role and fill in the amount of days, hours, and/or minutes before the deadline that you want notification sent. To notify the responsible role after the activity deadline, select the lower check box labeled Notify the responsible role and fill in the amount of days, hours, and/or minutes after the deadline that you want notification sent.
If you do not designate the time, notification is sent to the responsible role when the deadline is reached, even if you do not select a check box. If you select both responsible role notification check boxes and fill in times, notification is sent both before and after the deadline.
16-18
Variables
On the Variables tab panel, shown below, you can declare additional variables, or you can update or delete existing variables. The variables defined for this assigned activity are listed in the Variables text area.
There are two default variables for assigned activities: self and primaryBusinessObject. The variable self refers to the assigned activity object at runtime. The variable PrimaryBusinessObject holds the business object associated with the workflow process at runtime. See Declaring Variables for information about adding other variables in this tab panel.
Routing
On the Routing tab panel, you can specify custom routing events. These events are used to control the process flow by mapping one of the events you define to an action that will be performed in a successor activity, via a link. Routing events are defined in the Routing Events text area, where you enter the name of the events (one event per line). Click Check Syntax to verify that the Java code you have entered is correct.
16-19
You can select any of the following routing types from the drop-down list: None for no routing. The Routing Events and Routing Expression text areas are not available. Conditional to automatically trigger the specified event. Manual to allow a user to select one or more of the routing events specified on this tab. Manual exclusive to allow a user to select one and only one of the routing events specified on this tab.
Conditional events require a firing expression to automatically fire the event. As shown in the following example, this expression is a fragment of Java code that sets a variable result to one of the custom routing events. The result variable is required and must return a string matching one of the event names. The expression can reference any variable defined in the Variables tab panel.
If this information on the example were entered in the Routing Events panel, the >1000 event would be emitted if the result variable for the cost of the object associated with the process (for example, a change order) has a value greater than $1000. Likewise, the <1000 event would be emitted if the result variable has a value less than or equal to $1000. One link coming from the activity can be configured to start another activity that would be assigned to a user who would review costs when the >1000 event was emitted (that is, when a change order required an expenditure greater than $1000). Another link can be configured to simply continue with the process when the <1000 event is emitted. If you do not specify an automatic event firing expression, the user who is assigned the task chooses a custom routing events. The activity emits the event that the user chooses.
16-20
Note: The online help file, accessed from the Routing tab panel, contains an extensive set of tally examples and a link to an HTML file that contains additional code samples.
Transitions
On the Transitions tab panel, shown below, you can define the conditions necessary for moving from one internal state to another within a workflow process. Each assigned activity defines transitions. For example, initiation of a particular assigned activity represents a transition. A state transition can result from a routing decision made by the workflow process while it is running. Each transition can have an associated condition. If this condition is TRUE, the transition succeeds. Otherwise, it does not. These conditions are defined in the Transitions tab panel. To add a condition to a transition, select it from the Transition list, and type an expression in the condition text area. The condition is a standard Java expression that sets the result variable to TRUE if the transition should proceed, or to FALSE if it should not. Click Check Syntax to verify that the Java code you have entered is correct. For example, you might want the process to start an assigned activity only if a variable (i) is set to a certain value. Therefore, you would select Start from the Transition list and enter the expression shown as the condition:
16-21
Errors
On the Errors tab, which follows, you can specify the consequences of an error, including who is notified.
Defining a Subprocess
A subprocess, or proxy process, can be included as a node of another process, the parent process. To add a proxy process to the process definition, drag the Proxy Process icon ( ) onto the process diagram. The properties dialog box opens. You can designate a category, enter a description, and browse to select an existing process, which then becomes the proxy process. To ensure that the proxy process is updated when the original process is changed, select Use Latest Iteration. The name of the process appears as a link as the Referenced Process.
16-22
If you do not select a process, you cannot return to the process diagram. Instead, you must click Cancel; the proxy process node disappears from the process diagram.
To set a deadline for the proxy process, click the Deadline tab. To map variables, click the Variable Mapping tab. See Variables for more information. Note: Ad hoc activities and blocks are similar to proxy process, in that they are composed of a group of activities. A block is a way of simplifying the graphical representation of the process, by combining a number of activities under one icon. An ad hoc activity is a group of activities defined at runtime.
Defining Connectors
The Workflow Process Editor supports the following connector types:
Connector Type Description
Start
The Start connector represents the starting point in a process. Each process has only one Start connector, which cannot be removed or duplicated. An And connector does not fire until all predecessor links have fired. That is, it waits for all preceding activities to complete before allowing the process to continue. For example, a Promote activity can be connected to multiple review activities by an And connector.
And
16-23
Connector Type
Description
Or
An Or connector fires if any of its predecessor links fire. That is, it allows the process to continue if any of the preceding activities have completed. For example, a Revise activity can be linked to multiple review activities by an Or connector. A Threshold connector fires if a user-defined number of predecessor links fire. That is, it allows the process to continue only when the user-defined number of preceding activities have completed. To set the number of activities that must complete before a Threshold connector fires, enter a number in the Firing Threshold text box, on the Threshold Properties dialog box. To set a dynamic threshold, in which the firing threshold is set to 0 at runtime and is reset to the number of started predecessor activities, select Add One from the drop-down list in the Action list on the preceding Link Properties dialog box.
Threshold
Conditional Router
A Conditional Router fires user-defined events based on an automatic event firing expression. Because you can define user events and fire them with an expression for all connectors, the Conditional Router is essentially an Or connector identified by a special icon.
You specify custom routing events, which can be used to control process flow, on the Routing tab panel on the Connector Properties dialog box. See Routing for more information. Note: Because the Or connector and the Threshold connector do not require all activities to be completed before allowing the process to continue, unnecessary activities can remain open. To terminate these activities, click Terminate Open Predecessor Activities When Fired on the Or Properties dialog box, or the Threshold Properties dialog box.
Defining Links
Links define the flow of control among nodes within a process definition. They also determine which actions are performed in an activity when a predecessor activity broadcasts (or emits) events. For example, when a user completes a review task (indicating completion by clicking a button on that task page), you can specify that the completion event will cause a link to the next activity to fire.
16-24
Click the hyperlink associated with a link representation, or double-click the rule between nodes in your diagram, to access the Link Properties dialog box, which allows you to map events to actions. On the Link Properties dialog box, you can map events to actions. To map an event (in the left column), select a successor action from the dropdown list in the right column. You can specify more than one event to cause the same action to occur. To indicate that an event will be ignored, leave the field in the Action column blank. If an event is ignored, no action is performed when that event is emitted. To reset all connectors in an events path when it is fired, select the Loop Link check box. The connectors that have already fired are reset, and they can be fired again. Loop links appear in red. You can define custom routing events for most activities and processes. When you do so, these events are also displayed in the Link Properties dialog box, and you can map them to actions in a successor activity. For example, you could include in a process definition the following assigned activities: Approve Revise Promote
See the following figure:
The Approve activity defines two custom routing events, yes and no. This activity has two links: one link connects to the Revise activity, and another connects to a Promote robot. The link to the Revise activity can be configured to perform the Start action in Revise when the no event is emitted from the Approve activity. The other link can be configured to perform the Start action in the Promote robot when the yes event is emitted from Approve. In this way, the flow of control to the Revise or Promote activity is controlled by the event emitted from the Approve activity.
16-25
See the figure that follows for possible results:
Import and Export

Preparing to Import or Export Workflow Templates
Before you begin, you should be familiar with the following information regarding importing and exporting: Be sure to upgrade to the latest maintenance only release (MOR), as they become available, to ensure you have the latest enhancements to the import and export functionality. You can import templates into a later version of Windchill; importing to an earlier version may not work. The data you are importing must comply with the database integrity and structure of the older version. You also must convert the CSV to XML format. Importing or exporting workflow templates creates objects in a JAR or ZIP file format. (This is the same format that the load.Installer functionality uses.)
16-26
You can import any number of templates at a time. You can have many XML files, each representing one workflow template, in one JAR or ZIP file, or you can have one XML file representing many workflow templates. The order of the templates is important. For example, if template A has a subprocess template B, then B must be placed before A in the XML. There is no limit to the number of workflow templates you can export. To export multiple templates into a single JAR or ZIP file, hold down the CTRL key, select the templates you want to export, and click Export. All the selected templates are exported to the same JAR or ZIP file.
Iterations of a workflow template are not imported or exported. When you export a workflow that contains a fixed reference to a specific iteration that is not the latest iteration, the import fails. PTC recommends that you change all fixed references to floating references (that is, references to the latest iteration) before you export the workflow template. PTC recommends that you not export data from one version of Windchill and import it into a different version. Instead, migrate the data in your database and then export the templates. Errors may occur, especially when importing workflow templates. Some errors result in messages displayed; others may be fatal. Check the method server log for error information. When you export a workflow template, only the template itself is exported. This includes references to underlying objects, such as principals, roles, and actor roles. The underlying objects themselves are not exported. If the export file is used to import the template into another database, the underlying objects must exist in the database, or the import fails and errors appear in the method server log. This can occur especially when importing the object into a different system. Be certain that all underlying objects referenced in the XML representation of the template exist. If a workflow template is imported and a template with the same name already exist in the Import directory, the results depend on the Iteration On Import setting in the wt.properties file. If wt.workflow.iterateOnImport=true, the imported workflow template is appended to the existing template as a new iteration. If it is set to FALSE, the imported file causes a method server exception, stating that there is a duplicate name, and the template is not imported. If you want to reuse an existing template that resides in another context, export the template from source context to your local client file system, then import to your target context.
16-27
Importing and Exporting Workflow Templates

Use the Import and Export buttons on the Workflow Administrator page to import or export workflow templates. To import one or more templates from a JAR or ZIP file, select the file from the local file system in the Import window, and click Import. To export a workflow template into an XML representation of the template, use the following procedure: 1. Select a template from the Workflow Administrator page, and click Export. (The Export button is disabled if you do not have a template selected.) 2. A grant permission window may appear asking for permission to access the local file system and to write a file on that system. If you select the remember selection check box, permission need only be granted once. Once permission is granted, a Browse for file picker opens, defaulting to the system temp folder. 3. You can pick a file that exists or type in a new name. If the file name exists, you are asked to confirm to overwrite the file. You must click Yes to continue the export. If the file name does not exist, a new file is created. There is no confirmation that the export is completed. When the progress bar and the hourglass on the workflow administrator applet disappear, the export is complete.
16-28
Process Manager Toolbar Access Control

Process Manager toolbar buttons give authorized users the ability to change workflow processes. An authorized user can make vital changes to an activity or a process, such as terminating or completing it. Access to Process Manager buttons is defined in the following file:
<install directory>/codebase/wt/clients/workflow/manager/process-manager.properties
As shipped, full access is given only to the system administrator and the workflow administrator, as defined in the following properties:
activityrestartAccessControl=Administrators activitysuspendAccessControl=Administrators activityresumeAccessControl=Administrators activityterminateAccessControl=Administrators activitycompleteAccessControl=Administrators processsuspendAccessControl=Administrators processresumeAccessControl=Administrators processterminateAccessControl=Administrators processcompleteAccessControl=Administrators activityrestartAccessControl=WorkflowAdministrators activitysuspendAccessControl=WorkflowAdministrators activityresumeAccessControl=WorkflowAdministrators activityterminateAccessControl=WorkflowAdministrators activitycompleteAccessControl=WorkflowAdministrators processsuspendAccessControl=WorkflowAdministrators processresumeAccessControl=WorkflowAdministrators processterminateAccessControl=WorkflowAdministrators processcompleteAccessControl=WorkflowAdministrators
To add other groups, add additional AccessControl lines to the file, in the format:
<action>AccessControl=<group name>
When you have updated the properties file the, you must recreate the JAR file.
Viewing Workflow History

To optimize and streamline your workflow process definitions, you should capture and record events, such as state transitions and variable updates that occur during process execution. The ordered sequence of these events is called a workflow history, and allows you to capture significant events. In addition, you can specify that a keyed event be emitted, which allows synchronization of other Windchill managers and servers with process events. As described in this section, you can specify the following: Which events are to be ignored Which are to be recorded Which are to be emitted as keyed events Which are to be both recorded and emitted
16-29
Selecting Events
The following events can be generated during execution of a workflow process: Process creation, which occurs when a Start command is issued for an existing, enabled process definition. Change of state, which occurs when an execution object (a process or an activity) changes states (for example, from running to completed). Change of data value, which occurs when values are read into a process activity or written to process variables. Change of assignee, which occurs when assignment of a workflow task changes from one user to another. Error event, which occurs when an exception is thrown during process execution.
You can identify the events to be recorded in the workflow history or emitted as keyed events by setting the default event configuration in the wt.properties file. Please note that workflows created before changes to the wt.properties entries are applied are not affected. When one or more of the following properties is set to true, the corresponding event is recorded or emitted: wt.workflow.engine.recordProcessStateChange wt.workflow.engine.recordProcessDataChange wt.workflow.engine.recordActivityStateChange wt.workflow.engine.recordActivityDataChange wt.workflow.engine.recordProcessCreation wt.workflow.engine.recordAssigneeChange wt.workflow.engine.recordException wt.workflow.engine.emitProcessStateChange wt.workflow.engine.emitProcessDataChange wt.workflow.engine.emitActivityStateChange wt.workflow.engine.emitActivityDataChange wt.workflow.engine.emitProcessCreation wt.workflow.engine.emitAssigneeChange wt.workflow.engine.emitException All running workflow processes record and emit events based on this default configuration. As described in the next section, however, you can use the
16-30
Workflow History Viewer to change the events recorded or emitted by a given process.
Using the Workflow History Viewer

You can view workflow-generated events on the Workflow History Viewer, a simple ASCII utility. Issue the following command to start the Workflow History Viewer: java wt.workflow.engine.WfMonitor The following is the main menu of the Workflow History Viewer: Workflow Monitor - Main Menu Existing Workflow Processes -- -- -- -- -- -- -- -- -- -- -- -- -- >> 1. Simplest, key = 3347 (Running) Audit events -- -- -- -- -- -No event retrieved 1. Select process. 2. Show selected process. 3. Delete selected process. 4. Refresh processes. 5. Change event configuration for selected process. 6. Show selected events for selected process. 7. Show all events for selected process. 8. Show selected events for all processes. 9. Show all events for all processes. 10. Select event. 11. Show event. 12. Show event source. 13. Refresh events. 14. Delete events for selected process. 15. Delete events for all processes. 16. Exit >>> Choose an option: This menu includes a list of all existing processes and a list of all retrieved events. The list of retrieved events is initially empty.
16-31
In addition to these lists, the main menu provides 16 options. A description of each follows: Select Process Select this option to select a process, so associated events can be queried. The selected process is preceded by the characters >>. Show Selected Process Select this option to display the following information about the selected process, as well as all of its activities and subprocesses that have been started: The process status (for example, running). The process creator. The team with which the process is associated. An indication of whether or not the process or activity is overdue (that is, whether it has exceeded its specified duration). The time at which the process or activity started. The time at which the process or activity ended (not shown if the process or activity has not been closed). The deadline for the process or activity, if one exists. The event configuration for the process. Suspend and alert times, in milliseconds. The following shows a sample process display:
Simplest - Running Creator: Administrator Team: Default Times: is overdue = false start time = 1998-11-20 14:08:53.0 suspend time = 0, alert time = 0 Event configuration: Process (RECORD/EMIT): Creation: R, State change: RE Activity (RECORD/EMIT): Data change: E Exception (RECORD/EMIT): Exception: R Activities: *** act_simplest (wt.workflow.engine.WfTestActivity) Running Times: is overdue = false start time = 1998-11-20 14:08:56.0 suspend time = 0, alert time = 0
Delete Selected Process Select this option to delete the selected process.
16-32
Refresh Processes Select this option to refresh all processes. The Workflow History Viewer does not automatically update the status of a displayed process. You must explicitly refresh it in order to see new processes and changes of state since the last refresh. Change Event Configuration Select this option to open an event configuration editor. With the editor you can select the events that should be emitted, recorded, or ignored, for the selected process. Edit event configuration Current configuration Process (RECORD/EMIT): Creation: R, State change: RE Activity (RECORD/EMIT): Data change: E Exception (RECORD/EMIT): Exception: R 1. Create process - record: true 2. Create process - emit: false 3. Change process state - record: true 4. Change process state - emit: true 5. Change process data - record: false 6. Change process data - emit: false 7. Change activity state - record: false 8. Change activity state - emit: false 9. Change activity data - record: false 10. Change activity data - emit: true 11. Change assignment - record: false 12. Change assignment - emit: false 13. Execution error - record: true 14. Execution error - emit: false 15. Save configuration 16. Save configuration and return 17. Return (looses changes since last save) >>> Choose an option:
16-33
As previously described, all processes are governed by the event configuration specified in the wt.properties file, unless this submenu is used to change that configuration for the selected process. Selecting an option on this submenu toggles the current setting. For example, if you select option 1, you will change the setting of Create process from true to false. Consequently, process creation would no longer be a recorded event. Show Selected Events for Selected Process Select this option to open the submenu shown in the following figure. You can select an option from this submenu to specify the type of event in which you are interested. (In the example, option 8 is selected, indicating that the user is interested in all events associated with the selected process.)
Types of events to show 1. Process creation 2. Process state change 3. Process data change 4. Activity state change 5. Activity data change 6. Assignment change 7. Execution error 8. All 9. None (return) >>> Choose an option: 8
When you have select an option from this submenu, the requested events are retrieved, and the list of events is refreshed. For each event, the list identifies the event type and the execution object associated with it:
Audit events >> 1. PROCESS_STATE_CHANGED, process = Simplest
Show All Events for Selected Process Select this option to represent a shortcut to selecting All, (option 8) from the submenu of event types described in the preceding section. If this main menu option is selected, all events associated with the selected process are shown. Show Selected Events for All Processes Select this option to display all events of the selected type for all processes. Show All Events for All Processes Select this option to display all stored events for all processes. This list can be very large. Select Event Select this option to select another event. When events are retrieved, the first event in the list is automatically selected.
16-34
Show Event Select this option to display detailed event information for a selected event, as shown in the following figure:
event type = PROCESS_STATE_CHANGED timestamp = 1998-11-20 14:08:53.0 activity key = 0 activity name = null process key = 3347 process name = Simplest process template name = simplest old state = Not started new state = Running
Show Event Source Select this option to display the execution object (process or activity) that is the source of the selected event. Refresh Events Select this option to refresh all events corresponding to the selected process and event type. This is necessary to view events generated since the last refresh. Delete Events for Selected Process Select this option to delete all the events of the last selected type associated with the selected process. Delete Events for All Processes Select this option to delete all events of the last selected type associated with all processes. Exit Select this option to terminate the Workflow History Viewer session.
Configuring Worklist Fields

In Windchill PDM, users can create and save layouts for their worklist on the Manage Layouts page (this option is not available for Windchill PDMLink and Windchill ProjectLink). Users can determine the attributes displayed by selecting attributes from drop-down lists under each column. The drop-down lists for the columns are identical. The attributes displayed in these lists are determined in the wt.properties file. Note: This option is not available for Windchill PDMLink or Windchill ProjectLink.
16-35
The following is an example of the section of wt.properties that determines what appears in these lists: # -- Workflow Worklist fields # -- Note: The SelectWorkItemCheckbox is essential for the Reassign, Accept & Update DueDate functions wt.workflow.worklist.column.1=wt.workflow.worklist.SelectWorkItemCheckbox wt.workflow.worklist.column.2=wt.workflow.worklist.Task wt.workflow.worklist.column.3=wt.workflow.worklist.Priority wt.workflow.worklist.column.4=wt.workflow.worklist.Role wt.workflow.worklist.column.5=wt.workflow.worklist.PrimaryBusinessObject wt.workflow.worklist.column.6=wt.workflow.worklist.ActivityDeadline wt.workflow.worklist.column.7=wt.workflow.worklist.WorkflowProcessName wt.workflow.worklist.column.8=wt.workflow.worklist.Team wt.workflow.worklist.column.9=wt.workflow.worklist.Owner wt.workflow.worklist.column.10=wt.workflow.worklist.AssignmentState #wt.workflow.worklist.column.11=wt.workflow.worklist.ActivityStart #wt.workflow.worklist.column.12=wt.workflow.worklist.WorkflowProcessDeadl ine #wt.workflow.worklist.column.13=wt.workflow.worklist.ActivityDescription #wt.workflow.worklist.column.14=wt.workflow.worklist.WorkflowProcessStart #wt.workflow.worklist.column.15=wt.workflow.worklist.WorkflowProcessDescr iption #wt.workflow.worklist.column.16=wt.workflow.worklist.Required The attributes are defined by the key: wt.workflow.worklist.column.#. The entry to the right of the key is a class displaying a work item attribute. The order of columns displayed in the worklist table is determined by the numbers in the fifth level (1n). In the example above, the drop-down list would display the first ten attributes (WorkItemCheckbox through AssignmentState) in the order they appear. To change the order in which the attributes are displayed, edit the numbers in the fifth level. To remove an attribute from the list, insert # at the beginning of the line to comment out the line. Note: The columns must be numbered consecutively, beginning with 1. Therefore, if you comment out a line or edit the order, you may have to renumber the remaining entries. In the example above, if you commented out line 4 (Role), you would have to renumber 5 (PrimaryBusinessObject) through the line 10 (AssignmentState), 4 through 9.
16-36
Workflow Instance States

The following diagram shows the states that an execution object (activity or process) can be in, and the transitions from state to state.
Rounded boxes represent states; arrows represent transitions. The actual states are always the innermost ones. The others are super-states, indicating a collection of substates. For example, a query for closed processes returns the processes that have completed successfully and also the processes that have terminated or were aborted. The initial state for all execution objects is the not started state. The following is the normal sequence of states for an execution object is: 1. Not Started 2. Running 3. Executed The final state can be reached with the following two transitions: Start Complete
Some transitions apply to more than one state. This is indicated by an arrow that begins in a super-state. For example, terminate transitions from any open state to the terminated state. An additional transition, reset, is not shown in the diagram. The reset transition brings any object back to the not started state.
16-37
Both Open.NotRunning.Suspended.Disabled and Open.NotRunning.Suspended.Intermited are labeled suspended in the GUI; however, the Open.NotRunning.Suspended.Disabled state is currently not used, so there is no chance of confusion. The following is the model for connectors: Enabled Disabled
Domain-based Workflows
Workflow process instances (wt.workflow.engine.WfProcess objects) are created at runtime and run in a set of subfolders parented by the Workflows folder, rooted in the /System cabinet. During initialization, loading administration data into the Windchill database creates an access control policy rule that grants all users read, modify, and create permissions for objects of type wt.workflow.engine.WfExecution Object in the /System domain. The WfProcess class extends the WfExecutionObject class, so this rule applies to workflow process instances. All Windchill users can view process information by using Windchill Explorer or Local Search. This is the default out-of-the-box behavior. In order to provide better control over access to workflow process instances, you can set a property to enable domain-based workflows. WfProcesses are still created and run in the same set of subfolders parented by the Workflows folder; however, you can have multiple Workflows folders containing WfProcesses. The workflow processes are created and run within a subfolder of the Workflows folder parented by the cabinet or folder containing the primary business objects associated with the processes. The Workflows folders are created automatically, as needed. You can specify access control policies for the domains associated with the Workflows folders, granting different rights to WfProcess objects for each of the domains. If you manually initiate a WfProcess, its Workflows folder resides in the same cabinet or folder as the Workflow Template from which it was created. When you use the Workflow Administrator to check in a workflow template, the default location is the /System cabinet. You must select a different location if the /System cabinet is not appropriate. The property in the wt.properties file that toggles domain-based functionality is wt.workflow.engine.domainBasedWorkflowFolders. The default setting is FALSE. If this property is set to true, the domain-based functionality takes effect following method server restart. WfProcesses do not immediately change to their new folder location or domain; however, upon the next workflow state change (for example, from not started to running), the WfProcess changes folders and possibly domains, as appropriate.
16-38
Users authorized to access the Workflow Administrator applet can see only those workflow process templates for which they have read access. They may be able to save new templates and/or modify templates, but only if they have create and/or modify rights. They can save templates to their personal cabinet or folder and run an instance of the template from that location. In Windchill PDM, the user can use Windchill Explorer to view workflow processes in domains for which they have read access to WFProcess objects. The user can use Local Search to find workflow processes in domains for which they have read access to WfProcess objects. If access control policy rules do not grant a user access to the primary business object, the user can be granted ad hoc access to the object. These rights are explicit to the primary business objects and are not applied to the parent folder. The user is not able to view contents of the cabinet or folder in which this primary business object is held, unless there is a specific policy or ad hoc rule granting access to the content. Note: Windchill Explorer is not an option for Windchill PDMLink or Windchill ProjectLink. There is a property in the wt.properties file called wt.workflow.definer.checkAdminAccess. The default is false. That means you can access the workflow clients through the URL alias. If you want to restrict access to the Workflow Administrator, perform the following steps: 1. Set wt.workflow.definer.checkAdminAccess to true. 2. Update the httpd.conf file to require authentication when accessing Web pages under /windchill/wt/clients/workflow (see below). 3. Restart the method server. Any user attempting to access the Workflow Administrator page is then required to authenticate as a member of the Workflow Administrators group. If the authentication fails, an error page indicates that they are not authorized to access that page.
16-39
An example of setting the web server (Apache) to authenticate access to workflow clients is as follows. This change is made to the apache/conf/httpd.conf file.
# Admin level authentication <Location /windchill/wt/clients/workflow/> AuthName Windchill AuthType Basic <IfModule auth_ldap.c> AuthLDAPAuthoritative off AuthLDAPURL ldap://ldap.company.com:389/ou=People,ou=wc62,l=city,o=company </IfModule> AuthUserFile "C:/Program Files/Apache Group/Apache/conf/wtpasswd" require valid-user </Location>
Italicized items are installation-dependent.
Default Workflow Templates

The out-of-the-box workflow templates in Windchill allow you to automate procedures in which tasks and documents are passed among participants. For general information about workflows, refer to the Workflow Administrator online help. PTC Global Services consultants can help you determine how the out-of-the-box workflows correspond to your business processes. Although you can modify workflows if necessary, you will get better results if you map the existing workflows to your processes, rather than create new workflows based on your processes. Caution: Changes you make to workflows may not be compatible with future Windchill release and service packs, and may require additional support from PTC Global Services consultants.
Windchill PDMLink Default Workflows

This section summarizes the steps in each Windchill PDMLink out-of-the-box workflow template.
Change Activity Workflow

1. Complete Enterprise Change Notice (ECN) task Review the assigned ECN task, specify updates to the affected data, and submit the completed task. 2. Review ECN task Review the data modifications resulting from the preceding step and approve or reject the modifications. 3. Rework ECN task
16-40
According to the reviewers instructions from the preceding step, perform the required modifications and resubmit them to Change Administrator III for audit.
Enterprise Change Request (ECR) Workflow

1. Submit ECR Submit the ECR for review by Change Administrator I. 2. Analyze ECR Validate the ECR, coordinate the technical analysis and generation of a recommended solution, associate relevant analysis information, and determine the disposition of the ECR. 3. Clarify ECR The ECR is sent back to the author for the addition of further information. 4. For Fast Track ECRs: Create ECN
For Full Track ECRs: a. Schedule and facilitate (Change Review Board) CRB review and record CRB decision. b. Create ECN
ECN Workflow
1. Submit ECN for review by change impact board (CIB). a. Schedule and facilitate CRB review and record CRB decision. b. If necessary, amend ECN plan based on CIBs review and resubmit to CIB. 2. Audit ECN Review the ECN data modifications and approve or reject the ECN implementation. 3. Rework ECN task Rework task and resubmit to Change Administrator III for audit. 4. Audit ECN Review the ECN data modifications and approve or reject the ECN implementation.
16-41
Problem Report Workflow

1. Submit problem report Submit the problem report for review by Change Administrator I. 2. Analyze problem report Analyze the problem report, associate the relevant analysis information, and determine the disposition of the problem report.
Electronic Signatures
Windchill PDM and Windchill PDMLink allow you to require electronic signatures on workflow activities to authenticate the activity. The wt.property wt.org.electronicIdentification=RecordIdentification is the default out-of-the-box setting. You must set wt.org.electronicIdentification.class=wt.org.electronicIdentity.engines.LDAPPass wordSignatureEngine. To require electronic signatures, perform the following steps: 1. Use Workflow Administrator to make an electronic signature required for a particular activity. When you create or update a process template, the process window appears.
16-42
2. If you double-click the activity or right-click the activity and select Properties, a properties window appears. In this window, select the Activity tab.
16-43
3. Select the Signing Required check box to require an electronic signature at this point in the process.
Note: For ad hoc activities, if you select Signing Required, you are prompted for an authentication password in order to start the ad hoc activity.

Site, organization, and solution administrators manage workflow templates. Site administrators create, modify, delete, and view workflow templates in the site context. Organization administrators create, modify, delete, and view workflow templates in the given organization context. Organization administrators can view workflow templates from the site text. Product and library administrators create, modify, delete, and view workflow templates in their respective context. They can view organization templates from the parent organization context and the site context. This includes administrators of Windchill PDM library contexts.
Note: The Workflow Administrator is not available to administrators of project contexts.
16-44
The Workflow Administrator client displays a table that lists all workflow templates belonging to the given context, plus those belonging to its parent contexts. A column in the table identifies the context owning each workflow template. When you create a workflow process in Windchill PDMLink, the system saves the new workflow process in the System cabinet of the context in which it is created. Consequently, the Create window for workflow processes disables the location field since it is the system, not the user, that decides where the new life cycle template is to be located. Note: When you assign a workflow template to a life cycle template, you see a list of valid workflows. The list of valid workflow templates includes the ones defined in the given solution context, plus those defined in the ancestor organization and the site contexts. Workflow templates defined in a sub-context override and filter out the workflow templates defined in parent contexts having the same name. The search scope used to locate groups is determined by the type of administrator doing the search. For more information about the search scope, see Searching for Principals in the Administering Containers chapter.
16-45
16-46
17
Administering Views and View Associations
Topic
Page
Overview ...........................................................................................................17-2 Views and View Associations...........................................................................17-2 Managing Views and View Associations..........................................................17-3
17-1
Overview
Within Windchill, a part is assigned to a view when it is created. A new view can be created with the Object > New View Version menu selection of the Windchill Explorer or the Product Information Explorer. A part may be a view-dependent object, if several versions of the part may be required to address the needs of the various organizations working on it. For example, the Engineering and Manufacturing departments may want to work on different versions of a part, with each version representing a view specific to that department's needs.
Views and View Associations

Before a part can be assigned to a view, you must set up views and view associations for your Windchill system. Each view you configure must have a unique name. A view can have many successor views, but only one predecessor view. Only the first view in the structure has no predecessor view. You can define only one such root view for your site. The following diagram provides an example of a typical view setup:
View-dependent versions of a part can be derived from predecessor views. As shown in the diagram above, a Manufacturing version of the part can be built from the Engineering version of the part. Facility 1, Facility 2, and Facility 3 views can be derived from Manufacturing. When a user creates a view-dependent version of a part, the new version is assigned an initial revision letter, which is prefixed with the revision letter of the part version from the predecessor view. For example, if the Engineering version of a part is Revision B, the Manufacturing version of the part is labeled Revision B.A. Each view-dependent version of a part goes through its own life cycle process.
17-2
As described in the next section, Windchill provides a command-line utility to assist you in defining and managing views and their associations.
Managing Views and View Associations

You can use the wt.vc.views.LoadViews command-line utility to create and manage views and view associations. To invoke this utility, enter the following command: windchill wt.vc.views.LoadViews When launched, this application displays the following selections:
[V]iew structure [C}reate view [R]ename view [A]ssociate views [I]nsert view [Q]uit Your choice:
Type one of the bracketed characters at the Your choice prompt to select a command. For example, to create a view, enter C. Note: Enter the uppercase character representing your selection. Lowercase values are not recognized.
Examining a View Structure

To examine the existing view structure, enter V. The structure is indented to illustrate predecessor/successor relationships. For example, the view structure for the preceding diagram would be as follows: Engineering Manufacturing Facility 1 Facility 2 Facility 3
Creating a View
To create a view, enter C. You are prompted to enter a name for the new view. The name you specify must be a unique view name.
Administering Views and View Associations
17-3
Renaming a View
To rename an existing view, enter R. You are prompted for the current view name, which you intend to change. After you have specified the existing name, you are prompted to enter a new name for the view. Again, the name you specify must be unique.
Creating a View Association

To associate two views, enter A. You are prompted for the name of the view that will assume the parent role in the new association. After you have specified a parent view, you are prompted for the name of the view that will play the child role. For example, as shown in the example (in the Examining View Structure section) you could create an association between the Engineering view and the Manufacturing view, in which the Engineering view is parent to the Manufacturing view.
Inserting a View
To insert a view into the view structure, enter I. You are prompted to enter the name of the parent view. Specify the name of a view below which the new view will be inserted. Next, you are prompted to enter the name of a view that is currently a child of this parent. You can either enter a view name, or click Return. Finally, you are prompted for the name of the view to be inserted. If you provide values for both the parent name and the child name, the inserted view will be a child of both. For example, you could specify Engineering as the parent view and Manufacturing as its child, and then insert a Facility 1 view. The Facility 1 view would be a child of both Engineering and Manufacturing, appearing below both in the view structure (as illustrated earlier in this chapter). If you do not enter a child view when prompted, the inserted view will appear between the parent view you specified and its current children, in the view structure. If you enter Engineering as the parent view but do not enter Manufacturing when prompted for the name of a child view, the Facility 1 view you insert will be a child of the Engineering view and a parent of the Manufacturing view.
17-4
18
Administering Visualization Services
Topic
Page
Overview ...........................................................................................................18-2 Architecture .......................................................................................................18-3 Troubleshooting.................................................................................................18-6 Exporting Watermarks for ProductView.........................................................18-21 Windchill Visualization Service Properties ....................................................18-22
18-1
Overview
To enable the Windchill Visualization Service (WVS), you must install Windchill and follow the configuration steps. This section is an overview of WVS functionality and architecture, providing a context for the troubleshooting guidelines in the remainder of this chapter.
File Types
ProductView can display many file types. However, it is important that you are familiar with the following four file types: OL files An OL file is a binary file, which is created by publishing a CAD part. It contains the 3D and 2D CAD information. A single CAD part may create many OL files. PLT files The PLT file contains 2D-vector information, and is created when drawing output is requested during publication of a CAD part. A CAD part can product many PLT files. ED files An ED file is an ASCII file that contains product structure and file relationship information. Within the context of a single CAD part, an ED file is used to associate OL and PLT files. A part-level ED file can also contain attribute information from the CAD part. When an assembly is converted or a product structure is traversed, the resulting ED file contains the component nodes, as well as their relationship (to form the hierarchy) and attributes. Orientation and units are held as attributes of the components. The OL and PLT files are also associated with the components. Files may be associated as a URL or as a file system reference. Note: The conversion of a CAD part can result in an ED file that contains substructure information, in addition to OL and PLT file references. Consequently, when a product structure is traversed during publishing, any component node that has an ED file associated must have the substructure merged into the resulting file to give the complete product structure definition, down to the subpart level. EDZ files The EDZ file is a ZIP file containing an ED file, and all associated OL and PLT files. The EDZ acts as a snapshot of a product structure. As it is a single file, it provides a faster way to access a large amount of information, as only one download allows you to view a complete product. The EDZ also provides a single file that can be easily exchanged (for example, through e-mail).
18-2
Architecture
The following figure is a graphical representation of the Windchill Visualization Structure architecture.
WVS allows Windchill users to generate viewable files, store those files in the Windchill database, and view data in ProductView. ProductView displays many document formats directly from the file, requiring no preparation. However, CAD data must be published before it can be viewed in ProductView. The loader is responsible for preparing data for storage in Windchill before it is converted. The loader can be used in two ways: As a Windchill service, which looks for ticket files in a directory. A ticket file is a text file that defines the location of the preconverted data and specifies the way in which it will be catalogued when stored in Windchill. See the CAD Agent section in this chapter for guidelines on how to analyze and correct problems in this process. As an operation called directly by the publisher. Calls from the publisher are performed programmatically. The data is handled in the same way as if it were loaded through a ticket. The loader can optionally call the thumbnail generator to create a JPG image and 3D thumbnail file of the 3D geometry. If required, the thumbnail generator can be configured by its recipe file to only create a JPG image.The thumbnail generation must be installed from the Visualization - Windchill Support CD.
18-3
Data stored in Windchill by the loader is stored on a Representation, which is associated with a Representable (currently a WTPart, WTDocument, or EPMDocument). In most cases the Representable is a WTPart. The loader can also create an EDZ file, which is stored as role PRODUCT_VIEW_EDZ on the Representation. All the data files are loaded as secondary content on the Representation. The ED (product structure) file is processed, so the references to the viewable files point to Windchill content through URLs. The ED file is then stored as role PRODUCT_VIEW_ED on the Representation. If a thumbnail image or 3D thumbnail file has been created, it is stored on the Representation as content role THUMBNAIL/THUMBNAIL3D. If this is the default Representation, the WTPart also receives a copy of the thumbnail content. The actual content in the database is not duplicated, if it is shared with the Representation. From either the WVS portal page or any visualization link, you can view the data stored on a Representation in Windchill within ProductView. ProductView can author Windchill information in the form of annotations and groups saved as a markup in the database. Markups are associated to a particular Representation. The following figure shows the conceptual Windchill visualization data model:
18-4
If no WTParts are created in Windchill through EPM operations, the Representation is associated to the EPMDocument. Where the CAD data has been stored in Windchill by an EPM client, (for example, the Workgroup Manager for Pro/ENGINEER) or is referenced by an EPM gateway (for example, the Pro/INTRALINK Gateway), WVS can publish and store the data. The publishing of data can be accomplished upon the following: User request from the WVS portal. Checkin of data from the EPM client or gateway. Change of life cycle, life cycle state, team, or folder within Windchill. Execution of a scheduled job.
A publish job is always created and passed to a Windchill processing queue. The publish job is self-logging; that is, all end-user messages are contained within the job itself, and they can be viewed through the WVS publish monitor. When the publisher receives a publish job, it traverses structures within Windchill and extracts necessary CAD files. The traversal and file selection is based on the type of data being processed. The publisher uses the CAD agent to schedule the conversion of the CAD data. The CAD agent has CAD workers configured to it. A CAD worker is a program written using the API of a particular CAD system, and it produces files that ProductView can read from native CAD files and assemblies. The CAD agent manages the CAD worker resource. The following are characteristics of the CAD agent: Aware of which CAD workers are configured. Can start and stop CAD workers as necessary. Manages the passing of data to and from the CAD worker.
The CAD worker typically runs on a remote system. When the CAD agent receives the published data, it returns it to the publisher. The publisher then stores the resulting data in Windchill, by programmatically invoking the loader.
18-5
Troubleshooting
This section provides information you can use to analyze and resolve issues that may arise with the WVS components.
Windchill Visualization Service Loader

The method server starts the WVS loader service. The relevant entry in the wt.properties file is in the following form:
wt.services.service.nn=com.ptc.wvs.server.loader.GraphicsServer LoaderService/com.ptc.wvs.server.loader.StandardGraphicsServerL oaderService
The service first reads the wvs.properties file to ensure that the wvs.enabled property is set to true. If this property is not set to true, the service is not started. The loader may output additional debugging information to the method server start window and log if the edrload.verbose property is set to true. Every 5 seconds, the loader polls the directory defined by the following property: edrload.directory=$(wt.temp)\\wcinput If this directory does not already exist, the loader creates it. When polling the directory, the loader looks only for INI files. All other files are ignored. If the contents of an INI file (located in the directory) are terminated with <! >, it is renamed with a .txt extension. (For example, ticket.ini would be renamed ticket.txt.) If content is not terminated with <!>, the loader waits 5 more seconds to make sure the file is not currently being written to. If, after 5 seconds, the file content still does not terminate with <!>, the file is deleted. The loader requires write access to the file so that it can rename or delete it. In order to start processing them, the loader next parses the file and validates the contents. The file should contain entries of the form Keyword=value (for example, Partnumber=123456). The following table lists valid keywords:
Keyword Value or Description
Directory Documentnumber Documentversion
Specifies the fully qualified directory location of the converted data. Specifies the number of an existing WTDocument to which you associate the representation. Specifies the version of the WTDocument to which you associate the representation.
18-6
Keyword
Value or Description
Encoding
Specifies the character set encoding of the ED file (if the ED file has no J tag present). The default is to use the J tag-specified encoding or the encoding of the Windchill server. Specifies if an EDZ file is to be created. Can be set to true or false. The default is false.
Edzcreate
Ignoreonmerge
Adds a flag to children of the ED files root node to indicate that those children should be ignored when using this representation in a WTPart structure. For example, if the root WTPart includes a representation of the complete assembly, but you want to view the data from the individual WTParts when viewing a structure, use ignoreonmerge. Specifies if markups in the input data should be stored with the representation in Windchill. Can be set to true or false. The default is true.
Includemarkups
Iteratepart
Specifies if an existing part is to be iterated. Can be set to true or false. The default is false.
Partfolder Partlifecycle Partcontainer
Specifies the folder in which the part is created. Specifies the life cycle associated with the new part. Specifies the context (for example, Project, Product, or Library) that in which a new part is created. The folder and life cycle values are determined by the context and need not be specified. You can specify the context as a name or parentname/name. For example, if an organization PTC contains a project proj1, you can specify partcontainer as proj1 or PTC/proj1 (to distinguish it from other projects called proj1 in other organizations).
Partname Partnumber
Specifies the part name. Specifies the part number of an existing part (the part number is created if it does not exist).
18-7
Keyword
Value or Description
Partoid Partteam Partrevision Repdefault
Specifies the Windchill ID of an existing part. Specifies the team associated with the new part. Specifies the part revision. Specifies whether the representation is to be the default. Can be set to true or false. The default is false.
Repdesc Repname Representableoid Thumbnailcreate
Describes the representation to be created. Specifies the name of the representation to be created. Specifies the Windchill ID of an existing representable. Specifies whether a thumbnail is to be created. Can be set to true or false. The default is false.
Ticketencoding
Specifies the character set encoding of the ticket file. If specified, this must be the first line in the ticket file. If not specified, the encoding of the Windchill server is assumed.
Note: The file must end in <!>. Keywords are case-insensitive, as are true and false values. The initial checks of the file ensure that the directory specified by the Directory keyword exists and that the loader can write to it. Additional checks include the following actions, some of which depend on keyword values: If a Partoid is specified in the file, it is checked to ensure that it references a valid WTPart. If a Partoid is not specified, the Partfolder, Partlifecycle, and Partteam values are checked to ensure that they exist. If the Partnumber/Partname does not exist, a WTPart is created. If it does exist, and Iteratepart is set to true, the part is iterated. The result is a WTPart in the database to which a new representation will be added, with the specified Repname and Repdescription. The specified directory is scanned to locate the ED file. Only one ED file is allowed. All other files are uploaded to Windchill, associated as secondary content of the representation.
18-8
If a Representableoid is specified in the file, it checked to ensure that it references a valid representable. If the Thumbnailcreate keyword is set to true, a thumbnail image is created and uploaded as content of the representation, provided the thumbnail generator has been installed. If it is the default representation, the thumbnail is copied (shared) to the WTPart. If the Edzcreate keyword is set to true, an EDZ file containing all the files in the directory is saved as content of role PRODUCT_VIEW_EDZ on the representation, provided edrload.edzenabled=true is also set in wvs.properties. The ED file is modified to reference the secondary content in Windchill, rather than the local files, before being stored as the role PRODUCT_VIEW_ED on the Representation. The loader removes the ticket.txt file from the directory it is polling. This occurs whether the loading task succeeds or fails. If an error occurs, it is reported only in the method server log. Data referenced by the ticket is not removed. The removal of the ticket.txt file signifies that the loader has completed its task.
Note: For a large assembly, the loader task can be time-consuming, especially if thumbnail generation is performed. For more information about generating thumbnails, see the Windchill Installation and Configuration Guide.
CAD Agent
Configuring the CAD workers to the CAD agent can be difficult. The files must be configured correctly, and when CAD workers are on a remote system, the network connectivity between machines must be correct. The CAD Agent usually runs as a service, and is defined in the wt.properties file as follows:
wt.services.service.nn=com.ptc.wvs.server.cadagent.CadAgentServ ice/com.ptc.wvs.server.cadagent.StandardCadAgentService
It can also run as a standalone executable. The CAD agent reads configuration settings from a file. The name of the file is defined by the following entry in wvs.properties:
cadagent.inifile=$(wt.home)\\codebase\\agent.ini
Settings in this file should only be altered using the CAD Agent Configuration Wizard. To access the wizard, click the Configure button on the CAD Agent Monitor. You must have administrative permissions in order to use the wizard.
18-9
The CAD agent listens on a port for requests. The port number is defined in the agent.ini file. By default, this value is set to 5600. If another process on the system uses this port, the CAD agent fails to initialize. If that happens, you must manually edit the agent.ini file to change the port. See Manually Starting CAD Workers for more information. If a Windchill cluster environment is used, the CADAgent is executing in the background method server only, and for the CadAgent administration UI to operate, the host name where the background method server is located must be manually added to the agent section of the agent.ini file by adding the following line:
host=<hostname>
Running the CAD Agent in Debugging Mode

If you have problems configuring the CAD agent and getting a CAD worker to connect, start the CAD agent in debugging mode. Use the following procedure: 1. 2. Stop the method server if it is running. To start the CAD agent, execute the following command from a window configured to run Windchill:
java com.ptc.wvs.server.cadagent.CadAgent d
The CAD Agent window opens.
18-10
The number of panes displayed depends upon the numbers and types of configured workers. The Status Messages pane displays the requests being processed by the CAD agent on the listening port (5600). For each type of CAD worker (Pro/ENGINEER, CADDS, CATIA, Unigraphics, and so on), a pane displays the state of the queue. Each worker has its own pane that logs its transactions. In this case, there is a single Pro/ENGINEER worker configured, which is local to the server on which the CAD agent is executing.
Manually Starting CAD Workers

To manually start a CAD worker, you must be logged into the system on which the worker is configured. From there, execute the BAT file or shell script that has been configured as the command to start the worker. If you are successful, messages are displayed in the Status Messages pane, and the checkbox for the worker, in the Adapters drop-down menu, is selected.
18-11
To stop the worker, select the appropriate Adapters entry by clicking its check box. This sends a message to stop a running worker.
If the CAD worker fails to connect to the CAD agent, no activity is displayed in the CAD Agent windows. The CAD worker may continue running or exit after a period of time. An incorrect setting in the CAD worker configuration file typically causes this. If the CAD worker and the CAD agent are not running on the same host, the CAD worker host must be able to communicate with the CAD agent host, as the name specified in the CAD worker configuration file. For remote UNIX workers, the network routing, IP addresses, and DNS (name resolution) must be configured to resolve machine hostnames and permit traffic from the server to the remote machine via ftp or telnet. The remote machine should correctly service ping, ftp, and telnet requests to its hostname. (The telnet command is not required for remote Windows NT systems.) If the following message appears in the Status Messages pane when you are attempting to manually start a worker, it is because a request is being made from a worker that is not recognized as being configured in the agent.ini file. The host name that is specified in the message must be the host name that is specified in the agent.ini file.
Processing message WORKER <hostname> <CADTYPE> Failed to add worker. Will terminate it.
18-12
In the example window that follows, the CAD agent is looking for a host name of aprilia, but the hostname is set to April in the agent.ini file. In this case, the CAD agent sends a message back, telling the worker to stop.
Starting CAD Workers from the CAD Agent

After you have successfully started a CAD worker manually, stop it and try to start it again from the CAD agent. To start it, select the entry for the worker in the Adapters drop-down menu. The entry stays selected until the start-up timeout is reached, or a connection is successful. If this procedure fails, check to determine whether the execute command is correct. A worker on a remote Windows NT client uses the worker daemon, because a telnet server is not available. Ensure that the worker daemon service is running and is configured to listen on the port specified for the worker entry in the agent.ini file. By default this is 601. For remote UNIX workers, execute nohup and put the task in the background. For example, you would use a command such as the following for a remote CADDS5 worker:
nohup cassaoa/cadds2pv &
Use the telnet command to connect to the remote worker.
18-13
To test a connection, use the telnet command from the CAD agent host to connect to the worker host. Specify the host name, user name, and password defined in the agent.ini file when the worker was configured. If the connection is successful, ensure that the system prompt does not change. Manually executing the specified worker command from this environment should create a connection to the CAD agent. If not, there is probably a difference in the environment used by telnet and the default user login. Adjust the environment to ensure that the command causes a connection through telnet. Confirm that the environment settings are correct, particularly DISPLAY, path, and the shell. The CAD agent should then be able to start the worker.
Starting CAD Workers from the CAD Agent Monitor

If the CAD agent is running in debugging mode, and the workers are disconnected, you can go to the CAD Agent Monitor to view the workers status.
18-14
Click the "go" Action icon ( ) for a specific worker to send a message to the CAD agent to start that worker. Messages displayed in the Status Messages pane indicate that the agent has received the request and has attempted to start the worker. Additionally, the check box for the appropriate worker is selected in the Adapters menu list.
The status of the worker in the CAD Agent Monitor is then updated to show that the worker is available, and the Action icon changes to "stop" ( that clicking it stops the worker. ), to indicate
18-15
The worker will become available if the timeout period specified is too small, however, the UI stops waiting at the end of the time period, and wont be updated. If the CAD Agent Monitor indicates that the worker has connected, but its status is Off, select the Automatic refresh check box to update the UI. Click the Configure button to open the CAD Agent Configuration Wizard and change the setting. For detailed help, click Show Help on the CAD Configuration Wizard. It is important that the worker starts within the specified timeout period. When the system is running, the worker should be started automatically. If the timeout value is too small, the CAD agent makes three attempts to start the worker before marking it as unable to start.
Publishing CAD Documents

This section provides troubleshooting information for publishing operations.
Manual Publishing
When the desired CAD worker is successfully connected to the CAD agent, the next step is to publish data. PTC recommends that you run the first test of this capability from the Visualization portal page. To publish a CAD document, use the following procedure: 1. Locate a CAD document in the database. 2. From the Actions listing, click the publish icon ( ).
The following window opens.
18-16
The first time the window is called, two new processing queues, named PublisherQueue and PublisherQueue1, are created in Windchill. You can use the Windchill Queue Manager to confirm that both queues exist and are active. 3. To view the status of the job, click the Publish Monitor link.
Click the status link in the State column to display the job details. If no entries appear in this panel, or if they appear and then disappear when they are completed, check to confirm that the following properties are set in the wt.properties file:
#Visualization Publishing Queue # Specify if the WVS PublisherQueue entries are to be deleted # Delete the main queue entries once complete. wt.queue.removeCompleted.PublisherQueue=true # For each PublisherQueue keep the entries so that the log may be seen in the publisher wt.queue.removeCompleted.PublisherQueue1=false # As extra queues get created, entries must be added here also wt.queue.removeCompleted.PublisherQueue2=false
Initially all publish jobs are submitted to the processing queue PublisherQueue. Only one job is executing in the queue. Other entries are set to Ready. The executing job in PublisherQueue looks for an available queue with a name of the form PublisherQueue<n>, where <n> is an integer. When a queue is available, the publish job is submitted to that queue, which immediately executes it. The following property ensures that completed jobs are removed from PublisherQueue:
wt.queue.removeCompleted.PublisherQueue=true
18-17
Completed jobs in the other queue should be kept, because they contain the actual publish job, which includes the logging information. Additional queues can be added to ensure scalability of the publishing capability. For each additional queue, the appropriate entry must be added to the wt.properties file:
wt.queue.removeCompleted.PublisherQueuen=false
Note: The publishing queue is displayed to all users, but job details are available only to the job owner. When the publish monitor is displayed in the context of a project or product, the publish jobs displayed are those associated to that context. When the job completes, the details indicate success or failure. Errors that caused failures are identified in a message.
Timeouts
When the CAD agent sends a request to the CAD worker, it has no way of determining the status of the job. Therefore, the CAD agent waits for a specified period of time. In the wvs.properties file, the following properties define timeout values for publishing:
publish.cadtimeout.component=600 publish.cadtimeout.assembly=3600 publish.cadtimeout.drawing=600
These properties specify the number of seconds that the CAD agent waits when the publisher is processing a single component, assembly, or drawing, respectively. These values should be adjusted to the needs of your site, so that they will process the largest data sets. If the values are too small, errors are displayed, and no viewable CAD data is created. Alternatively, many of the CAD workers can be configured with long and short timeout values that are sent back to the CADAgent. If these have been configured, the last timeout value sent to the CADAgent is used. See the CAD worker documentation for details of setting CAD worker timeouts. You should also tune the CAD agent settings for Auto Idle Stop and Auto Busy Stop to help control system resources. (These values are specified when you use the CAD Agent Wizard to configure a CAD worker.) For example, for CADDS5, when processing of drawings is enabled, Auto Idle Stop should be set to about 900 seconds. For Pro/ENGINEER, setting Auto Busy Stop ensures that system memory is released on a regular basis. When you set values that automate the stopping of CAD workers, you should enable Auto Start and correctly configure it so that the worker can be restarted.
18-18
Automating Publishing
There are several ways in which the publishing of viewable CAD data can be automated. An event is emitted when a CAD document is checked in from a Workgroup Manager, the Pro/INTRALINK Gateway, or the Optegra Gateway. If the following property is set to true in the wvs.properties file, this event results in submission of a publish job:
publish.service.readytopublish.enabled=true
This job is processed exactly as if the user (who checked the file in) had made a publish request from the Visualization portal or properties page.
Publish Scheduler
With the Publish Scheduler, requests can be submitted to the Windchill Schedule queue for processing. Examples are provided below, but typically you will set automated publishing schedules specific to your site, to automate the publishing of certain types of data on a regular basis. In Windchill PDM, you can access the Publish Scheduler from the Administrator page of the Visualization portal. In Windchill PDMLink or Windchill ProjectLink, you can access it from the Utilities page of the Site tab. The first time that a scheduled job is submitted, a new Windchill schedule queue called WVSScheduleQueue is created. You can use the Windchill Queue Manager to confirm that this queue exists and is active. The schedule queue executes a publish request at the date and time specified, with the specified frequency. Settings in the wvs.properties file define the jobs that are available for selection from the Schedule Publish Job page. There are a number of example jobs already configured. There are two parts to the process of creating a Schedule Publish Jobs: configuring the wvs.properties file writing the java code to select the objects to be published
The following property defines the list of available entries (where <n> is an increasing integer, starting with 1).
Schedulejobs<n>=<schedulename>
The schedulename is then used to find additional properties of the following forms:
<schedulename>.description=pull-down description <schedulename>.class=<ClassContainingMethod> <schedulename>.method=<nameOfMethod> <schedulename>.enableOnContainers=<true/false>
18-19
The <schedulename>.description property defines the text that appears in the drop-down menu on the Schedule Publish Job page. The class and method are used to identify the specific method that will be invoked by the schedule job. The value of enableOnContainers determines if this schedule job is displayed in the list of jobs when the scheduler UI is invoked in a specific context.This indicates that the schedule job contains code to filter the objects to be published based on the context. The following are the signatures of the publish job method:
public static QuerySpec <nameOfMethod>()
or
public static QueryResult <nameOfMethod>()
If a QuerySpec is returned, then PersistenceServerHelper.manager.query() is used to make the query and return a QueryResult. This QueryResult or the one returned directly from the schedule jobs method contains the EPMDocuments/WTParts/WTDocuments/Representation that are sent for publishing. A default configuration spec is used. If the QueryResult contains a Representation, then that is sent for republishing. If the QueryResult contains a WTDocument, all publishable files, that is, those with wither XXX=mapping defined in wvs.properties) are sent for publishing. To obtain the current container context for the schedule job, use the following method call in the jobs method:
WTContainerRef cr = com.ptc.wvs.server.schedule.ScheduleJobs.getCurrentContainer();
The following example schedule job method will publish all EPMDocuments in the current context:
public static QuerySpec allEPMDocuments() { QuerySpec qs = null; try { qs = new QuerySpec(EPMDocument.class); WTContainerRef cr = com.ptc.wvs.server.schedule.ScheduleJobs.getCurrentContainer(); if( cr != null ) { ContainerSpec cs = new ContainerSpec(); cs.addSearchContainer(cr); qs.setAdvancedQueryEnabled(true); qs.appendWhere(WTContainerHelper.getWhereContainerIn(cs, EPMDocument.class),new int[]{0}); } } catch (Exception e ) { e.printStackTrace(); } return qs; }
18-20
To obtain debug information for a schedule job, set the following property to true in the wvs.properties file:
publish.publishqueuehelper.verbose=true
Visualization Collaboration
To enable the collaboration interface, specify the following entry in the wvs.properties file:
collaboration.enabled=true
When this property is set to true, a Collaboration entry is included on the menu bar of the Visualization portal page. Install the collaboration agent from the Visualization - Windchill Support CD, adding the required entry into wvs.properties (via site.xcopnf) to specify the command to execute the collaboration agent. If required (for example, to change the assigned port numbers), you can change the value of the collaboration server property. The options for the collaboration server define the minimum (-p) and maximum (m) port numbers that are used by that server. Each collaboration session has its own running collaboration server, so this range should be large enough to accommodate the expected number of concurrent collaboration sessions. The default is 40. If the ProductView clients are operating through a firewall to the Windchill server, these ports must be open. The idle timeout can also be specified, in seconds, by the i option. The default is to shut down a collaboration server if no one is connected for 10 minutes. Only the user who starts a collaboration session can stop it or can host data into the session. All other users can only join the session. If the user who starts a session logs out and logs back in, he or she must go to the collaboration listing and make the session hosted into his or her current Windchill session before being able to load data into it.
Exporting Watermarks for ProductView

ProductView supports watermarking of 3D, drawings, images, and documents. Watermarks are defined in INI files created and edited using the ProductView watermark editor. The administrator that manages watermarks manually transfers the INI files from the watermarks directory into the Windchill server.
18-21
To export the watermark configuration, go to the location that ProductView Standard Edition is installed. Run the wcexport executable file, found in the productview installation directory. The Export Watermark Configuration window appears:
Specify the file name you want to export and click Browse to locate the directory. The wcexport tool creates a ZIP file including the main config.ini file, any watermark INI files referenced by the registry definitions, and any images referenced by any watermark file. To add the ZIP file to the ProductView configuration for Windchill PDM, click Administration on the Visualization navigation bar; then click Server Controlled Configuration of ProductView. To add the ZIP file for Windchill PDMLink or Windchill ProjectLink, click ProductView Configuration Administration on the Utilities pages of the appropriate tabs. Note: For Windchill PDMLink or Windchill ProjectLink, the context of the Utilities page defines where the watermark configuration is stored. For example, if you are accessing ProductView Configuration from the Organization tab, you are defining the watermark configuration for the organization. For more information on ProductView configuration, see the online help for the ProductView Configurations table.
Windchill Visualization Service Properties

Windchill uses standard Java property files to dynamically configure many optional or site-dependent settings. The primary property file, wt.properties, is located in the Windchill codebase directory, where it is available for downloading into clients. It contains properties that affect both client and server Java classes. You can edit these files by using the System Configurator application, which allows you to add properties and values, delete properties, and save your changes to the properties files, for implementation when you restart the Windchill system.
18-22
Windchill Visualization Service (WVS) uses the properties described in the following table. They are set in the wvs.properties file.
Windchill Visualization Service property cadagent.inifile Description Default Value: $(wt.home)\\codebase\\agent.ini Synopsis: Configuration file for CADAgent. Description: Specifies the configuration file used by the CADAgent. This file configures the CAD Workers that are available for use by the WVS Publisher. Default Value: $(wt.logs.dir)\\cadagent Synopsis: Directory for CADAgent log files. Description: Specifies the directory where CADAgent log files are written. Default Value: OL ED PLT DXF HPGL PGL TXT AST CCZ CC GIF JPG PDF PVT GRP EMK ETB PVA CGM TGA Synopsis: File types that the CadAgent will retrieve. Description: Adds to this space-delimited list, any file extensions that the CAD workers may create which need to be stored in Windchill. This list is case insensitive. Default Value: True Synopsis: Enables the Collaboration option from the WVS portal. Description: Enables the Collaboration option from the WVS portal. This allows ProductView collaboration to be used in a Windchill context. The property is set when the collaboration agent is installed from the Visualization - Windchill Support CD. Default Value: $(wt.home)\\bin\\pview_collaboration.exe -p 5620 -m 5660 -i 600 Synopsis: Collaboration server start command. Description: Specifies the command for starting the collaboration server. Typical options are; -p start_port_number, -m max_port_number, -i idle_timeout_in_seconds. The collaboration server executable refered to here should be placed in the correct location. The property is set when the collaboration agent is installed from the Visualization - Windchill Support CD. For more information on collaboration see ProductView documentation. Default Value: $(wt.temp)\\collaboration Synopsis: Directory used for Temporary files for collaboration. Description: Specifies the directory used for Temporary files for collaboration. Default Value: False Synopsis: Set to true to enable the configuration of a Distributed CadAgent. Description: Specifies if the CAD Agent Monitor wizard will present options and screens allowing a Distributed CadAgent to be configured. This only may be relevant when working with data populated via the Pro/INTRALINK gateway.
cadagent.logs
cadagent.pvfiletypes
collaboration.enabled
collaboration.server
collaboration.tempdir
distributedcadagent.enabled
18-23
Windchill Visualization Service property edrload.copymarkupsfromprevious iteration
Description Default Value: annotation,markup,group,pair_group,sequence Synopsis: Copy markups from previous iteration when a new representation is created. Description: If previous iteration is in the same version, specifies to copy markups from previous iteration when a new representation is created Default Value: annotation,markup,group,pair_group,sequence Synopsis: Copy markups from previous iteration when a new representation is created. Description: If previous iteration is in a different version, specifies to copy markups from previous iteration when a new representation is created. Default Value: False Synopsis: Setting this property to true matches the default status in preference to name. Description: When copying markups from previous iteration, the representation to copy from is first matched on the name and then on the default status. Setting this property to true matches the default status in preference to name. Default Value: False Synopsis: Copy content from referenced and describing documents to the representation. Description: Specifies whether to copy content from referenced and describing documents to the representation or reference the content from the document. Default Value: True Synopsis: Copy transform information from EPM./CAD System to Part structure. Description: Copies transform information from EPM./CAD System to Part structure. For CAD systems whose structure is file driven, this will cause publish.matchcadnames to be treated as true. Default Value: $(wt.temp)\\wcinput Synopsis: Directory for ticket files. Description: Specifies the directory polled by loader for ticket files that are used to load preconverted visualization data into Windchill. Default Value: WindchillDocument Synopsis: ProductView property group for WTDocument properties. Description: Specifies the ProductView property group for WTDocument properties. A change to this value will require the corresponding change in the ProductView installation.
edrload.copymarkupsfromprevious version
edrload.copymarkupsmatchdefault first
edrload.copyreferencedand describingtorep
edrload.copytransform
edrload.directory
edrload.docpropertygroup
18-24
Windchill Visualization Service property edrload.edzenabled
Description Default Value: False Synopsis: Enables creation of an EDZ file when visualization data is stored. Description: Enables the creation of an EDZ file when visualization data is stored. This includes data stored by the WVS publisher. Based on a user preference, a user will view an EDZ (if available) or an ED file. An EDZ file will download to the client all file data from a Representation initially, while with an ED file, individual files are downloaded on demand. Default Value: WindchillEPM Synopsis: ProductView property group for EPMDocument properties. Description: Specifies the ProductView property group for EPMDocument properties. A change to this value will require the corresponding change in the ProductView installation. Default Value: False Synopsis: Includes Describing WTDocuments in ed file. Description: Includes Describing WTDocuments in ed file for WTPart structure traversal. Significantly increases the structure traversal time. Default Value: False Synopsis: Flag to specify if EPMDocument properties/property page link is to be included in part structure viewing/representations. Description: Flag to specify if EPMDocument properties/property page link is to be included in part structure viewing/representations. Default Value: True Synopsis: Specifies whether to include part masters in the part structure. Description: Flag to specify if part masters are to be included in the part structure. Default Value: True Synopsis: Includes Windchill properties in ed file. Description: Includes Windchill properties in ed file. Default Value: True Synopsis: Link to properties pages is to be added. Description: Flag specifies if link to properties pages is to be added. Default Value: False Synopsis: Includes Referenced WTDocuments in ed file. Description: Includes Referenced WTDocuments in ed file for WTPart structure traversal. Will significantly increase the structure traversal time.
edrload.epmpropertygroup
edrload.includedescribing
edrload.includeepmpropertiesinpart structure
edrload.includepartmastersdefault
edrload.includeproperties
edrload.includepropertypagelength
edrload.includereferenced
18-25
Windchill Visualization Service property edrload.new.encoding
Description Default Value: Synopsis: Character set to use for new ED files. Description: Specifies the character set to use for new ED files (for example, a representation of a part structure). If not specified (default), the system default encoding is used. Default Value: True Synopsis: Overwrites transform information on Part structure. Description: Overwrites transform information on Part structure, when copying data from EPM/CAD System. Default Value: WindchillPart Synopsis: ProductView property group for WTPart properties. Description: Specifies the ProductView property group for WTPart properties. A change to this value will require the corresponding change in the ProductView installation. Default Value: $(wvs.edfileencoding) Synopsis: Default character set to use for reading ED or ETB files. Description: Specifies the default character set to use for reading ED or ETB files. The default is to use the default characterset of the server. You can also specify the charset in ticket file to override this value. If the ED file specifies a value, that value is always used. Default Value: False Synopsis: Enables debug mode for loader. Description: Enables debug mode for loader. Default Value: Synopsis: Character set to use for storing ED files in database. Description: Specifies the character set to use for storing ED files in database. If not specified (default), the existing encoding or the system default is used. Default Value: $(wt.temp) Synopsis: Temporary directory used when creating markups. Description: Specifies the temporary directory used when creating markups. Default Value: False Synopsis: Enables debug information when creating markups. Description: Enables debug information when creating markups. Default Value: batchprint='true' Synopsis: Options to send to ProductView at startup when batch printing. Description: Options to send to ProductView at startup when batch printing.
edrload.overwritetransform
edrload.partpropertygroup
edrload.read.encoding
edrload.verbose
edrload.write.encoding
markup.tempdir
markup.verbose
productview.batchprintoptions
18-26
Windchill Visualization Service property productview.collectionconfigbased onfirstobject
Description Default Value: False Synopsis: When viewing objects from the visualization collection, the ProductView configuration selected is based on the container of the first object. Description: When viewing objects from the visualization collection, the ProductView configuration selected is based on the container of the first object. Default Value: False Synopsis: When viewing objects from the visualization collection, the ProductView configuration selected is based on the organization of the user. Description: When viewing objects from the visualization collection, the ProductView configuration selected is based on the organization of the user. Default Value: False Synopsis: Get ProductView configuration information from server. Description: Get ProductView configuration information from server (for example, this retrieves watermark information from the WVSConfigurationTemplate for the container of the object being viewed). Default Value: Synopsis: The type for the WVXConfigurationTemplate to be used when a user has modify access to the object being viewed. Description: When ProductView receives configuration files from the server, users who have modify access to the representable can use a different WVSConfigurationTemplate object. The type is specified when the WVSConfigurationTemplate is created and that string should match the value of this property. If no value is specified, all users, irrespective of access rights, use the same configuration, based on the container. Default Value: Synopsis: Options to send to ProductView at startup. Description: Options to send to ProductView at startup. Default Value: redirecturl='unload.jsp' Synopsis: Web page that ProductView will redirect to upon exit. Description: Specifies the Web page that ProductView will redirect to upon exit. The default page simply closes the small web browser window that hosts the ProductView plugin.
productview.collectionconfig basedonorganization
productview.configfromserver
productview.modifyconfigtype
productview.options
productview.redirectoptions
18-27
Windchill Visualization Service property publish.alwaysusespecifiedobject
Description Default Value: True Synopsis: Publish specified object event if the specified config spec does not select it. Description: When the object specified to be published would not be selected with the specified config spec, the specified object or the one selected by the config spec can be used for the publish job. For example, publishing an old iteration of an EPMDocument when using a Latest config spec. Default Value: N/A Synopsis: Application Type to Java class lookup. Description: Specifies a required entry that relates the Application Type to a Java class that will handle the CAD system specific publishing for any CAD system supported by the WVS Publisher. Default Value: 3600 Synopsis: Timeout for conversion of CAD assemblies. Description: Specifies the timeout for CADAgent conversion of CAD assemblies in seconds. Default Value: 600 Synopsis: Timeout for conversion of CAD components. Description: Specifies a timeout for CADAgent conversion of CAD components in seconds. Default Value: 600 Synopsis: Timeout for conversion of CAD drawings. Description: Specifies the timeout for CADAgent conversion of CAD drawings in seconds. Default Value: True Synopsis: Use as stored config spec when publishing EPMDocuments Description: When publishing an EPMDocument structure and no config spec has been specified, or the Create Representation wizard specifies default (which is the default option), the config spec used depends on the EPMDocument. Setting this option to true causes the as stored config spec to be use when default is specified. Default Value: True Synopsis: All representations can be copied forward when a new representable iteration is created in a different container (for example, in an integral checkout). Description: Indicates if all representations should be copied forward when a new representable iteration is created in a different container (for example, in an integral checkout). Default Value: True Synopsis: When a representable is copied, copy forward all the representations or only those that would normally be copied forward. Description: When a representable is copied, copy forward all the representations or only those that would normally be copied forward.
publish.cadconvert."xxx"
publish.cadtimeout.assembly
publish.cadtimeout.component
publish.cadtimeout.drawings
publish.configspec.default.useas storedifavailable
publish.copyforwardall representationsoncontainerchange
publish.copyforwardall representationsoncopy
18-28
Windchill Visualization Service property publish.copymarkupsforward
Description Default Value: True Synopsis: Allows the copy forward of Annotation and Groups when enabled. Description: Applies in the case where a Representation is copied forward when a Part iterates. If this is enabled, the associated Annotation and Groups will also be copied. Default Value: False Synopsis: Allow the copy markups to be restricted to copying from a representation to a representation and a viewable to a viewable only. Description: When copying markups, allows the copy to be restricted to copying from a representation to a representation and a viewable to a viewable only. Default Value: True Synopsis: When enabled, allows Representations to be copied forward (to the next iteration) when Parts iterate. Description: Specifies if the copy forward of Representations takes place. This will take place if set to true and the copy does not compromise the validity of data published from EPM. Default Value: True Synopsis: Restrict representation copy forward mode. Description: Restricted representation copy forward mode does not copy a published representation forward when a WTPart iterates and old and new iteration point to the same EPMDocument. Default Value: PROE CADDS5 CATIA PRODESKTOP UG SOLIDWORKS CATIAV5 OTHER Synopsis: List of CAD types that can be loaded or converted from the Create Representation window. Description: Lists CAD types that can be loaded or converted from the Create Representation window on a WTPart without an EPMDocument. This is a space-separated list of keys from EPMAuthoringAppTypeRB.rbinfo. If the type OTHER is included, the file to be processed is treated as if it is on a document: the document worker mapping determines the conversion that occurs. Default Value: True Synopsis: Set copy forward of representations for WTDocuments. Description: Sets copy forward of representations for WTDocuments. All representations of WTDocuments are candidates for copy forward, even if they are published from the document content files. Publishing occurs only when document files are uploaded. If markups on the WTDocuments representations are copied forward, the representations are not replaced by publishing.
publish.copymarkupsrestricttosame type
publish.copyrepresentationsforward
publish.copyrepresentationsforward. restrict
publish.createrepresentationcadtypes
publish.deletepreconvertededz
18-29
Windchill Visualization Service property publish.documents.copymarkups forward
Description Default Value: True Synopsis: Set copy forward of markups for WTDocuments. Description: Sets copy forward of markups for WTDocuments. Individual markups are copied forward only if that markup has its copy forward flag set. Default Value: True Synopsis: Delete temporary EDZ file. Description: When publishing an EPMDocument that has an EDZ file of preconverted data (client side-generated viewables), deletes the EDZ file when the EPMDocument is published. Default Value: False Synopsis: Enables forcing of republishing existing Representations. Description: Forces the republishing of existing Representations that are already valid, (for example, when CAD Worker settings have been changed and it is required to reconvert data.) Default Value: False Synopsis: Restrict marking out of date to only direct uses EPMDocuments. Description: Restricts marking out of date to only direct uses EPMDocuments. Default Value: Synopsis: Method to filter which representations are marked out of date. Description: Be default, representations that are derived with a Latest Config Spec are candidates for being marked out of date. You can use a custom method to provide different criteria, for example, life cycle state. The method is defined by the following property in the form classname/methodname. The method should have the following signature: public static Boolean methodname(EPMDocument epmdoc, Representation rep). A return of Boolean TRUE indicates that the passed in representation of the passed in EPMDocument is a candidate for being marked out of date. A return of Boolean FALSE indicates that is should not be a candidate.
publish.documents.copy representationsforward
publish.forcerepublish
publish.markonlydirectuses representationsoutofdate
publish.markoutofdatefiltermethod
18-30
Windchill Visualization Service property publish.markoutofdaterepublish method
Description Default Value: Synopsis: Method to filter which representations that are marked out of date should be sent for republishing. Description: When a representation is marked out of date for the first time, it can be republished. This causes many extra publishing jobs. You can define a method to use to filter which EPMDocuments should have the representation automatically republished, for only released data could be selected. The method is defined by the following property in the form classname/methodname. The method should have the following signature: public static Boolean methodname(EPMDocument epmdoc, Representation rep). A return of Boolean TRUE indicates that the passed in representation of the passed in EPMDocument is sent for republishing; a return of Boolean FALSE indicates that it should not. For example, the markRepublishAll method sends all representations for republishing. publish.markoutofdaterepublishmethod=com.ptc.wvs.server.publish. PublishHelper/markRepublishAll When representation are not sent for republishing, the schedule job republishOutOfDate, or a customer schedule job, can be used to republish representations marked as out of data at a time best suited to system resource usage.
publish.markreferences representationsoutofdate
Default Value: True Synopsis: Provide a warning to the user when viewing representations marked as out of date. Description: Representations can be marked as out of date which provides a warning to the user when viewing that representation. When an EPMDocument is published, it can find referencing EPMDocuments and mark their representations that are older than the EPMDocument being published and use a Latest Config Spec as being potentially out of date. Default Value: True Synopsis: Provide a warning to the user when viewing representations marked as out of date. Description: Provides a warning to the user when viewing representations marked as out of date. When an EPMDocument is published, it can find using EPMDocuments and mark their representations (that are older that the EPMDocument being published and use a Latest Config Spec) as being potentially out of date. If required, the marking of uses of representations be limited to representation that directly use the object being published.
publish.markusesrepresentationsout ofdate
18-31
Windchill Visualization Service property publish.matchcadnames
Description Default Value: True Synopsis: Allows matching of data from CAD system with Windchill when enabled. Description: Enables matching of data from CAD system with Windchill for "file based" systems. Allows Windchill property pages to be referenced from ProductView and population of Windchill properties in ProductView. Also implied when transform information is being populated from EPM/CAD System to Part structure. Default Value: 250 Synopsis: Display limit for number of jobs in the publish monitor. Description: Specifies the display limit for jobs in the publish monitor. The value of the limit is the number of ready and the number of executing/completed jobs (for example, a limit of 250 displays up to 250 ready jobs and 250 executing/completed jobs. Default Value: False Synopsis: Enables debug information for publisher queues. Description: Enables debug information for publisher queues and schedule queue jobs. Default Value: 5 Synopsis: Polling interval for PublisherQueue to look for free queues. Description: Specifies the polling interval (in seconds) for PublisherQueue to look for free queues. Default Value: False Synopsis: Republish or update representation when metadata on an EPMDocument is changed and the EPMDocument does not iterate. Description: When the metadata on an EPMDocument is changed and the EPMDocument does not iterate (for example, a life cycle state is changed) the associated representations are updated. In certain cases (for example, when the CAD file on the EPMDocument has an association to that metadata), it may be desirable to republish the representation rather than just updating it. Default Value: True Synopsis: Retrieve all dependent files. Description: If true, retrieves all files; if false, retrieves only those files whose links are marked as required. Default Value: True Synopsis: Send WTDocuments for publishing on checkin. Description: Specifies if WTDocuments are to be sent for publishing on checkin. Only publishable files (those with an associated worker) are considered. All publishable files on the checked in document are sent for publishing.In addition, any files uploaded to a non-checkout document are published (for example, a new document or one in the users personal cabinet). This option is mutually exclusive with publish.service.document.upload.enabled.
publish.monitor.displaylimit
publish.publishqueuehelper.verbose
publish.publishqueuepollinterval
publish.republishoneepmdocument change
publish.retrieveallfiles
publish.service.documents.checkin. enabled
18-32
Windchill Visualization Service property publish.service.documents. options
Description Default Value: Synopsis: Pass options to document publishing. Description: Pass options for document publishing. Commaseparated list of name=value pairs. For example: encodefilename={true, false} - encode non-ascii filename before sending to worker encoding= - specify the character encoding for the ed file, for example, SJIS or UTF-8 Default Value: False Synopsis: Send WTDocuments for publishing on each file upload. Description: Specifies if WTDocuments are to be sent for publishing on each file upload. Only publishable files (those with an associated worker) are considered. This option is mutually exclusive with publish.service.document.checkin.enabled. Default Value: True Synopsis: Mark document representation, published from a file on the document, as out of date when a new version of the file is uploaded. Description: Marks document representation, published from a file on the document, as out of date when a new version of the file is uploaded. The file is not sent for publishing (for example, for an update when publishing on checkin or if publish on checkin and upload are disabled). Default Value: False Synopsis: Provides listener for publishing CAD data on checkin when enabled. Description: Enables WVS listener that listens for EPM CheckIn complete events. Checked in objects will be sent for publishing. Note: This property is not used in Windchill 7.0 and should be left with the default setting of false. See publish.service.readytopublish.enabled.
publish.service.documents. upload.enabled
publish.service.documents.upload. markoutofdate
publish.service.enabled
publish.service.filterdocument publishmethod
Default Value: Synopsis: Supply method to provide custom filtering of the WTDocument content to be published. Description: Specifies a method to provide custom filtering of the WTDocument content to be published as a result of file upload or checkin (provided the content has a worker associated with it). If not method is supplied, all WTDocument content that meets the above criteria is sent for publishing. The property value is specified in the form classname/methodname, with the following signature: publish static Boolean methodname(WTDocument doc, ContentItem ci) A return of Boolean TRUE indicates the WTDocument should be published, Boolean FALSE indicates that it should not be published.
18-33
Windchill Visualization Service property publish.service.filterepmdocument publishmethod
Description Default Value: Synopsis: Custom filtering of EPMDocuments published as a result of CheckIn Complete or Ready To Publish events. Description: You can supply a method to provide custom filtering of the EPMDocuments that are published as a result of a CheckIn Complete or Ready To Publish event. If no method is supplied, all EPMDocuments in the event are sent for publishing. The property value is specified in the form classname/methodname, with the following signature: public static Boolean methodname(EPMDocument epmdoc) a return of Boolean TRUE indicates the EPMDocument is published, Boolean FALSE, the EPMDocument is not published. Default Value: Synopsis: Supply a method to provide custom filtering of objects that can be published. Description: Allows you to supply a method to provide custom filtering of objects that can be published. This method checks all publishing, even from preconverted. If the publish is to convert data stored in Windchill, the flag publishFromDB is true; if the publish is for local data or data from the clipboard, publishFromDB is false. The property value is specified in the form classname/methodname, with the following signature: public static Boolean methodname(Persistable p, Boolean publishFromDB). A return of Boolean true indicates the object can be published; Boolean false indicates it cannot. Default Value: False Synopsis: Restrict EPMDocument publishing from CheckIn Complete or Ready To Publish events. Description: Restricts EPMDocument publishing from CheckIn Complete or Ready To Publish events to cases where the client initiating the event, for example the work group manager, has specified options for the creation of the representation. If this option is set, default CheckIn Complete or Ready To Publish events are ignored. Default Value: False Synopsis: Restrict EPMDocument publishing to EDZ files. Description: When using EDZ client side viewables, restricts publishing of EPMDocuments to those that have EDZ files. This limits all publishing to be only from a temporary EDZ file (for example, client side viewables). Default Value: False Synopsis: Restrict EPMDocument publishing to EDZ files, for the check in listener only. Description: When using EDZ client side viewables, restricts publishing of EPMDocuments to those that have EDZ files. This limits publishing initiated by an event only).
publish.service.filterpublishmethod
publish.service.ignoreddefaultepm events
publish.service.onlypublish preconvertededz
publish.service.onlypublish preconvertededzfromevents
18-34
Windchill Visualization Service property publish.service.readytopublish. enabled
Description Default Value: True Synopsis: Listen for Ready To Publish event to initiate publishing of EPMDocuments. Description: Listens for Ready To Publish event to initiate publishing of EPMDocuments. Work group managers should emit this event for EPMDocuments that require visualization. Default Value: False Synopsis: Enables debug mode for publish listener. Description: Enables debug mode for publish listener. Default Value: $(wt.temp)\\pubtemp Synopsis: Temporary directory for WVS publisher. Description: Stores WVS publishers temporary files in a directory. Default Value: $(publish.tempdir) Synopsis: Temporary directory for uploaded files. Description: Creates a temporary directory for uploading files when creating representations from local files.For a cluster environment, this directory must be a shared, common directory, accessible to all involved method servers. Default Value: True Synopsis: Allow markups associated directly to a viewable (for example, WTPart or WTDocument) to be copied forward when the viewable iterates. Description: Allows markups associated directly to a viewable (for example, WTPart or WTDocument) to be copied forward when the viewable iterates. An individual markup is copied only if its copy forward flag is set. Default Value: N/A Synopsis: Internal name for a schedule job definition. Description: Specifies the internal name for a schedule job definition. All other entries for this job definition will use this name as the prefix on the property name. Default Value: N/A Synopsis: Display name for the schedule job definition. Description: Specifies the display name for the schedule job definition. Default Value: N/A Synopsis: Java class for the schedule job definition. Description: Specifies the Java class for the schedule job definition. Default Value: N/A Synopsis: Java method for the schedule job definition. Description: Specifies the Java method for the schedule job definition.
publish.service.verbose
publish.tempdir
publish.tempuploaddir
publish.viewable.copymarkups forward
schedulejobsN
"schedulejobname".description
"schedulejobname".class
"schedulejobname".method
18-35
Windchill Visualization Service property scheduler.user
Description Default Value: Synopsis: User name used by scheduler. Description: Specifies the user name used by scheduler. If no user name is specified, schedule queue jobs will be executed as the user who submitted them. Default Value: 3600 Synopsis: Timeout in seconds. Description: Sets the timeout in seconds for thumbnail generation when using the cadagent and a remote thumbnail worker. Default Value: True Synopsis: Flags to enable thumbnail image generation. Description: Enables the generation of thumbnail images that are displayed on listings and property pages. The default thumbnail generation method uses Java3D, hence this must be installed on the Windchill Server machine. Default Value: 800 Synopsis: Maximum number of files for thumbnail generation. Description: Sets a limit on the size of an assembly (by the number of referenced files) that will have a thumbnail image generated. This can be used to control server resources. Default Value: 183,183,183 Synopsis: Sets the image background color for thumbnail generator. Description: Specifies the image background color to be created by the thumbnail generator. The three numbers represent red, green and blue in the range 0 to 255. Default Value: com.ptc.wvs.server.thumbnail.j3d.GeneratorJ3D Synopsis: Java class used for thumbnail generation. This is not used if the native thumbnail generator is installed. Description: Specifies the Java class used for thumbnail generation. This can be changed to implement alternative thumbnail generation technologies. Default Value: False Synopsis: Enables debugging for thumbnail generator. This is not used if the native thumbnail generator is installed. Description: Sets the debug mode for thumbnail generation. Messages will be logged in the method server log file. Default Value: True Synopsis: Enables extents generation for thumbnail generator. Description: Specifies that the thumbnail generator should compute the bounding box for each ol file that is processed. The bounding box is stored in the ed file, and is used by ProductView for proximity search and file loading optimization.
thumbnail.cadagenttimeout
thumbnail.enabled
thumbnail.filelimit
thumbnail.generator.backcolor
thumbnail.generator.class
thumbnail.generator.debugmode
thumbnail.generator.extents
18-36
Windchill Visualization Service property thumbnail.generator.height
Description Default Value: 128 Synopsis: Sets the image height for thumbnail generator. Description: Specifies the image height to be created by the thumbnail generator. Default Value: $(wt.jdk)\\bin\\java -Xms32m -Xmx512m com.ptc.wvs.server.thumbnail.Generator Synopsis: Executes the Java thumbnail generator. This is not used if the native thumbnail generator is installed. Description: Specifies the Java command and options used to generate thumbnail images. Images are executed in a separate Java virtual machine as they are relatively memory intensive. The -Xmx option is important as this controls the maximum amount of memory that the Java virtual machine can allocate. Default Value: set by Visualization - Windchill Support CD installer Synopsis: Executes the native thumbnail generator. Description: Specifies the command to execute the native thumbnail generator, which creates 2D thumbnail images and 3D thumbnail files. The value of this property is set by the Visualization - Windchill Support CD installer. Default Value: -60 Synopsis: Sets image X axis rotation for thumbnail generator. Description: Specifies the image X axis rotation in degrees. Default Value: -25 Synopsis: Sets image Y axis rotation for thumbnail generator. Description: Specifies the image Y axis rotation in degrees. Default Value: -10 Synopsis: Sets image Z axis rotation for thumbnail generator. Description: Specifies the image Z axis rotation in degrees. Default Value: False Synopsis: Enables logging of statistics for thumbnail generator. Description: Logs timing and memory usages statistics for thumbnail generator. Messages will be logged in the method server log file. Default Value: 192 Synopsis: Sets the image width for thumbnail generator. Description: Specifies the image width to be created by the thumbnail generator. Default Value: 1.2 Synopsis: Sets image zoom factor for Java thumbnail generator. This is not used if the native thumbnail generator is installed. Description: Specifies the image zoom factor, allowing the object to be made larger or smaller in the thumbnail image.
thumbnail.generator.javacmd
thumbnail.generator.nativecmd
thumbnail.generator.rx
thumbnail.generator.ry
thumbnail.generator.rz
thumbnail.generator.stats
thumbnail.generator.width
thumbnail.generator.zoomfactor
18-37
Windchill Visualization Service property thumbnail.usecadagent
Description Default Value: False Synopsis: Set to true if thumbnail generation is performed on a remote system. Description: Executes thumbnail generation via the CadAgent by configuring a worker type THUMBNAIL and using the GenericWorker. In most cases this is not required, but if the Windchill server is not capable of running the thumbnail generator, this does allow a remote machine to be used to execute the actual thumbnail generation process. This will be less efficient than executing directly.
viewer.<DataFormatName>
Default Value: N/A Synopsis: Maps Windchill file type to ProductView viewer type. Description: Maps Windchill file type to ProductView viewer type. Windchill file type (the DataFormat name) specified here should have any spaces removed. Additional entries of this form can be added for any file types (for example, viewer.GIFImage=image). Default Value: N/A Synopsis: Maps file extension to ProductView viewer type. Description: Maps file extension to ProductView viewer type. Note that the file extension includes the dot, and should be specified in upper case. There is an alternative technique for associating a file with a specific file viewer, using the DataFormat name. Additional entries of this form can be added for other file extensions (for example, viewer..HPGL=drawing). Default Value: True Synopsis: Allows representation deletion. Description: Provides the ability for a user to delete a representation from the user interface. If true, all users can delete representations from the user interface; if false, no users can delete representations from the user interface. If admin, only administrators (system, project, or product administrators) can delete representations from the user interface. Default Value: True Synopsis: Allows default representation selection. Description: Provides the ability for a user to change the default representation from the user interface. If true, all users can change the default representation from the user interface; if false, no users can change the default representation from the user interface. If admin, only administrators (system, project, or product administrators) can change the default representation from the user interface.
viewer..<FileExtension>
webpage.allowdeleterepresentation
webpage.allowmakedefault representation
18-38
Windchill Visualization Service property webpage.allowpublish.epm document webpage.allowpublish.wtpart webpage.allowpublish.wtdocument
Description Default Value: True Synopsis: Allows publishing from the user interface. Description: Provides the ability for a user to publish from the user interface, on a type basis. If true, all users can publish the specified type from the user interface; if false, no users can publish the type from the user interface. If admin, only administrators (system, project, or product administrators) can publish from the user interface. Default Value: single Synopsis: Enables autoloading of files in ProductView. Description: Allows ProductView to autoload files. If value is "true" all files will be autoloaded. If value is "single", ed files with a single associated file will be autoloaded. If value is "false" no files will be autoloaded. Default Value: 21 Synopsis: Sets the default query type for WVS portal, used only in Windchill PDM. Description: Specifies default query type for the WVS portal page. The types supported are; 21 = WTParts, 22 = WTDocuments, 49 = EPMDocuments, 55=ProductInstances, 111=ProductConfigurations. Default Value: True Synopsis: Displays thumbnail for ProductInstance and ProductConfiguration. Description: For the view link for ProductInstance and ProductConfiguration, displays the thumbnail image. This gives only an approximate rendition. Default Value: True Synopsis: Displays thumbnail viewer for 2D thumbnails. Description: On the Representations listing page, displays the thumbnail viewer popup icon when there is only a 2D thumbnail (that is, no 3D thumbnail); otherwise, there must be a 3D thumbnail and the thumbnail view must be installed on the server. Default Value: True Synopsis: Displays warning when viewing an out of date representation. Description: Displays warning when viewing a representation that has be marked as out of date. Default Value: False Synopsis: Set the long listing default for WVS portal. Description: Specifies default for the Long List setting on the WVS portal.
webpage.autoload
webpage.defaultquerytype
webpage.displayproductthumbnail
webpage.displayviewthumbnailfor 2d
webpage.flagoutofdate
webpage.longlistingdefault
18-39
Windchill Visualization Service property webpage.markupenabled
Description Default Value: True Synopsis: Enables the creation and storing of markups from ProductView. Description: Enables the creation and storing of markups from ProductView. Default Value: True Synopsis: Enables display of the part structure view option. Description: Allows part structures to be viewed from the WVS portal and the Product Structure web page, without the publishing of CAD data and the creation of a representation. Default Value: True Synopsis: Adds (with add from collection) Annotations and Groups with a Representation. Description: Allows any associated Annotation and Groups to also be added, when a Representation is added from the collection. Default Value: False Synopsis: Sets the delete display for WVS portal. Description: Specifies the display of a delete option on the WVS portal. Default Value: True Synopsis: Enables the add to collection and add from collection facilities to allow Representations and/or Markups to be copied. Description: Enables additional add to collection and add from collection facilities on the Representations, Annotation and Groups, and Visualization Collection pages. Default Value: True Synopsis: Display publish link for documents with publishable files. Description: For a document with publishable files (that is, worker mapping defined with a "worker.xxx=yyy" property) displays the publish link when there is no default representation. The default publish link publishes the first publishable file on the document. Default Value: False Synopsis: Display link to representation or markup page for documents. Description: For a document with no representations and no markups and no displayed publish link, displays the link to either a markups page or a representations page. Default Value: True Synopsis: Displays representation link for a part. Description: When a part displays the part structure link and has no markups, displays the link to the representation listing. If false, displays the link to the markups listing.
webpage.partstructureview
webpage.pastemarkupswith representation
webpage.showedrdelete
webpage.showextendedclipboard
webpage.showpublishfordoc
webpage.showrepfordoc
webpage.showrepforpart
18-40
Windchill Visualization Service property webpage.showsavezip
Description Default Value: True Synopsis: Displays the save representation action. Description: Displays the save representation action in the representation listing. This allows you to save the representation as a local ZIP or JAR file or a link to view the representation to be saved (to include in an e-mail, for example). Default Value: True Synopsis: Displays view default structure link for a part. Description: When a part has no default representation and no associated EPMDocument, displays the view default structure link. Default Value: True Synopsis: Sets the thumbnail display default for WVS portal. Description: Specifies default for the display of thumbnails on the WVS portal. Individual users can set their preference for thumbnail display from preference settings. Default Value: False Synopsis: Provides user interface debug information. Description: Provides user interface debug information. Default Value: N/A Synopsis: Maps Windchill file type to a worker type. Description: Maps Windchill file type to a worker type. A worker of this type should have been configured in the agent.ini file (for example, worker.VRML=VRML). Default Value: N/A Synopsis: Maps file extension to a worker type. Description: Maps file extension to a worker type. Note that the file extension includes the dot, and should be specified in upper case. There is an alternative technique for associating a file with a specific file viewer, using the DataFormat name. A worker of this type should have been configured in the agent.ini file (for example, worker..IGES=IGES). Default Value: $(wt.home)\\loadFiles\\wvs\\ Synopsis: Directory where WVS demo data is located. Description: Specifies the location of the WVS demo data. This is referenced only in the WVS demo data ini files. A file delimiter is required at the end of the entry. Default Value: Synopsis: Character encoding for communication to server. Description: Specifies the character encoding used by the servlet engine.
webpage.showstructureforpart
webpage.showthumbnail
webpage.verbose
worker.<DataFormatName>
worker..<FileExtension>
wvs.demo.data
wvs.edencoding
18-41
Windchill Visualization Service property wvs.edfileencoding
Description Default Value: Synopsis: Character encoding for reading ed files. Description: Specifies the default encoding to use for reading ED files. If none specified, then the system uses the default character encoding of the server. See also edrload.encoding. Default Value: True Synopsis: Enables Windchill Visualization Service. Description: Enables Windchill Visualization Service. When set to false, users will not see thumbnails or be able to launch ProductView. Before visualization can be fully used, other parts of the system, such as CAD Workers, need to be installed and configured.
wvs.enabled
18-42
19
Administering Audit Reports
Topic Page Overview ...........................................................................................................19-2 Enabling Auditing .............................................................................................19-2 Accessing Audit Reports ...................................................................................19-2 Example Audit Report.......................................................................................19-3
19-1
Overview
By default, the auditing features provided by Windchill are disabled. This documentation provides the instructions to enable the auditing features and use audit reporting.
Enabling Auditing
To enable the auditing features, use the following procedure: 1. Shut down servers/servlet engines. 2. Edit the wt.properties file to add the wt.audit.eventConfigFile property using the xconfmanager. From a windchill shell, execute the following command:
-s wt.audit.eventConfigFile=$(wt.home)$(dir.sep)codebase $(dir.sep)registry$(dir.sep)auditing$(dir.sep)configAudit.xml -t <Windchill>/codebase/wt.properties -p
3. Repropagate the xconf file. 4. Set the EventConfiguration enabled property to true on the codebase/registry/auditing/configAudit.xml file:
EventConfiguration enabled="true"
5. Analyze your auditing rules. The characteristics of what gets audited is described in the $(wt.codebase.location)/registry/auditing/configAudit.xml file. This file is delivered with some predefined auditing rules. If you choose to add or change these rules, PTC recommends that the original file remain intact. You can create a backup of the original and apply your changes to a new file. If you decide to select a new name for this file, then you must edit the wt.audit.eventConfigFile property to reference the new name. 6. Restart servers and servlet engines.
Accessing Audit Reports

How you access Audit Reports is determined by your Windchill application: From Windchill PDM, you can access Audit Reports by clicking the Audit Reports link that is on the Business Administration home page. From Windchill PDMLink and Windchill ProjectLink, you can access Audit Reports from the Audit Reports link directly below the Site and Organization tabs. The link from the Site tab provides the site administrator with unrestricted access to all reports. The link from the Organization tab provides access to only those reports that are in the organization context that is active.
19-2
For Windchill PDMLink and Windchill ProjectLink, there are 10 reports available. They include: Context Access Context Change Context-Access Change Object Access Object Change Object-Access Change Organization Access Team Change User Access User-Context Access
In Windchill PDM, there are seven reports available. They include: Context Access Context Change Object Access Object Change Object-Access Change Team Change User Access
For information on how to use the Audit Report utility, see the online help.
Example Audit Report

Assume you want to find out the accesses a user has made in the last month. 1. Click User Access on the Audit Reports page. 2. On the User Access page, click Find User to select a user. 3. Select a time period from the Time Period drop-down list. You can also select a custom time period by using the start and end calendar pickers. 4. Click Generate Report.
19-3
For Windchill PDMLink or Windchill ProjectLink, your browser should look something like this:
19-4
For Windchill PDM, your browser would look something like this:
If you want to save this audit report to a file, click Save to File. The Save to File window appears, allowing you to specify the name of the file:
19-5
A Save As window appears in which you can choose a location in your file system or /network to store the ZIP file.
19-6
Index
A
Access control cabinets, 10-1810-19 content holder objects, 10-15 deleted groups, 9-13 deleted organizations, 9-16 deleted users, 9-11 domains, 10-2 life cycles and, 14-13, 14-21 overview, 10-2 Process Manager, 16-29 Access control lists, 10-2, 10-610-11 ad hoc, 10-2, 10-11, 10-19, 14-13, 14-21 defining, 10-2 derived from access control policies, 10-710-8 object types, 10-2 permissions in, 10-810-10 policy, 10-2, 10-19, 14-13, 14-21 types of, 10-2 Access control policies defined, 10-7 defining, 4-6 deriving access control lists from, 10-710-8 organizations, 5-5 Access control rules about, 10-7 creating, 10-3 Default domain, 3-12 default, for cabinets, 10-18 defined, 10-2 domains, 10-10 example, 10-2 examples, 10-1010-11 introduction, 2-8 permissions in, 10-810-10 predefined, 10-12 root domain, 3-11 System domain, 3-12 User domain, 3-12 User/Unaffiliated domain, 3-12 Windchill PDMLink, 6-8 window, 10-6 Access Control Rules window, 10-5
ACL. See Access control list Action items, 8-3 Activities, 8-3 creating, 8-3 managing, 8-3 updating, 8-3 Actors, 15-2 Ad hoc ACLs. See Access control lists, ad hoc Administrative Domain window, 10-3, 12-3 Administrative notifications, 9-16 Administrative permission, 10-5 Administrator user, 1-13, 2-6 Administrators access to objects, 2-6 selecting users, 1-13 Windchill PDMLink, 1-11 Windchill ProjectLink, 1-12 Administrators group, 2-6 All permission, 10-5 ALL pseudo-group, 10-7 Application containers, 3-2, 3-5 Assigned activities. See Workflow activities Attributes. See Soft attributes Audience, xix Audit reports, 19-2 Auditing organization, 5-5 system information, 4-5
B
Background queues, 2-3 baseline.ManagedBaseline, 2-16 Bootstrap client, 2-3
C
Cabinets access control, 10-15 default access control rules for, 10-18 owners of, 10-16 personal, 10-18 defined, 10-16 deleted users, 9-11
Index-1
shared, 10-23 defined, 10-16 Cabinets access control, 10-19 Caching of access control lists, 10-7, 10-10 of notification lists, 13-4 CAD agent, 18-5 configuring, 18-9 debugging mode, 18-10 timeouts, 18-18 CAD document templates, 3-15 CAD documents object type, 2-16 templates, 2-18 visualization, 2-18 CAD documents, publishing automating, 18-19 manual, 18-16 CAD workers, 18-5, 18-9 configuring, 4-7 starting from the CAD agent, 18-13 from the CAD agent monitor, 18-14 starting, manually, 18-11 stopping, 18-12 Change Activity team roles, 15-3 Change Admin roles, 6-8, 6-13 Change Management objects, 15-3 Change objects, 10-14 Change Permissions permission, 10-5 Code examples, object subscription, 16-35 Co-installed Windchill solutions, 2-8 Collapse tables, 4-9, 5-16 Collections defined, 12-2 deleted users, 9-11 Composite object initialization rules, 3-34 Configuring worklist fields, 16-35 CONFIRMED group, 6-6, 6-8, 6-9 Container hierarchy, 3-2 libraries, 6-17 products, 6-15 Container configuration description, 3-4 updating, 3-5 Container data description, 3-13 installation, 3-13 organizations, 5-7
site, 4-8 updating, 3-14 Container environment projects, 8-6 Container hierarchy Windchill PDMLink, 2-7 Container object initialization rules accessing, 3-33 description, 3-18 installation, 3-19 loading, 3-32 site, 4-8 specifying, 3-35 updating, 3-32 XML, 3-36 Container participation description, 3-8 installation, 3-8 organization, 5-7 projects, 8-6 site, 4-8 updating, 3-9 Container policies description, 3-10 installation, 3-10 organization, 5-7 site, 4-8 updating, 3-13 Container structure description, 3-6 installation, 3-6 organizations, 5-7 projects, 8-6 site, 4-8 updating, 3-7 Container templates description, 3-14 installation, 3-15 site, 4-8 updating, 3-18 Containers creating, 3-19 libraries, 6-2 organization, 3-4, 4-3 overview, 2-3 products, 6-2 Site, 3-2, 3-4 Windchill PDM, 2-5 Content holder objects, 10-1410-15 access control, 10-15 Content replication products and libraries, 6-6
Index-2
projects, 8-5 system, 2-3 Windchill PDM, 7-5 Context definition, 2-5 domains, 3-30 teams, 2-14 templates, 2-6 use, 3-3 Context templates, 3-14 Create permission, 10-5 Create Project window, 8-8 Create Team window Windchill PDMLink, 15-17 Creating access control rules, 10-3 action items, 8-3 activities, 8-3 containers, 3-19 context templates, 3-22 deliverables, 8-3 documents and folders, 8-3 groups, 9-12 indexing rules, 12-312-4 life cycle templates, 14-5 notification rules, 13-2 organization folders and documents, 5-4 organizations, 1-7, 4-3, 5-13, 9-15 project space, 8-2 projects, 8-8 resources, 8-3 roles, 15-16 site folders and documents, 4-4 users, 9-9 views and view associations, 17-2 workflow activities, 16-13 process links, 16-24 subprocesses, 16-22 Creator actor, 15-2 product and library, 1-11, 5-3, 5-8 project, 1-12, 5-8
organizations, 9-15 users, 9-9, 9-10 Deliverables, 8-3 Disconnected principals, 9-18 Document templates, 3-15, 3-17 Documents content holder, 10-14 organization, 5-4 Domains access control rules, 10-10, 10-14, 10-16 administering, 3-24 creating, 3-27 definition, 3-24 display of, 10-16 indexing rules and, 12-3, 13-3 installed, 3-24 introduction, 1-6 naming, 3-27 overview, 2-3, 3-28 Root, 3-26, 3-27 Site container, 3-26 subfolders, 10-17 System, 3-26
E
ECN team roles, 15-4 ED files, 18-2 EDZ files, 18-2, 18-4 Electronic signatures, 9-9, 16-42 E-mail notifications. See Notifications Enabling audit reports, 19-2 Enumerated types, 15-18 EPMDocument, 2-16, 18-4 ERP system, working with, 4-8 Example audit report, 19-3 Exporting life cycles, 14-19 watermarks, 18-21 workflow process templates, 16-26 External file vaults, 2-3
F
File vaults, 2-3 Folder members, 10-15, 10-16, 10-23 Folder paths, 3-18 Foldered objects. See Folder members Folders, 8-3, 10-16 organization, 5-4
D
Data types, 2-17 Default domain, 3-12, 3-26 Defining, 15-16 Delete permission, 10-5 Deleting groups, 9-12, 9-13
Index-3
G
Gates. See Life cycle gates Generating thumbnails, 18-9 Groups deleting, 9-13 managing, 9-12 organization, 5-3 setting permissions, 10-5 Guests role, 6-6, 6-7, 6-11
H
Home page Windchill PDM, 1-3 Windchill PDMLink, 1-4 Windchill ProjectLink, 1-5 Home tab, 1-4, 1-5
I
Import and export, 4-7, 5-6 between projects, 8-4 Importing life cycles, 14-19 Microsoft Project plan, 8-4 workflow process templates, 16-26 Indexing rules combinations of, 12-5 creating, 12-312-4 object types and, 12-4 root domain, 3-13 See also Collections INVITED group, 6-8 Iterated objects, 14-3
J
JAR files, 14-19, 14-20 java.security.acl package, 10-6, 10-9
L
Libraries, 3-2 creating in Windchill PDMLink, 6-17 templates, 6-6 Windchill PDM, 7-1 Windchill PDMLink, 6-1 Library creators, 1-11, 5-3, 5-8 Library domains access control, 6-8 teams and, 15-8 Library manager, 1-11, 6-7, 6-12
Library tab, 1-4 Library templates, 3-14 Life cycle access control rules defining, 14-13 overview, 10-19 Life Cycle Administrator page, 14-4, 14-5, 14-19 Life cycle gates associating workflow processes with, 14-15 overview, 14-3 Life cycle phases, 14-6 access control and, 14-9 associating workflow processes with, 14-15 defining, 14-8 properties of, 14-9 Life cycle promotion defining criteria for, 14-17 Life cycle roles, 10-20, 14-9, 15-10, 16-16 assigning permission to, 14-15 mappings, 14-11 predefined, 14-11 selecting, when defining phases, 14-10 Life cycle states defined, 14-3 indexing and, 12-2 predefined, 14-19 Life Cycle templates installation, 3-16 Life cycle templates checking out, 14-4 container, 3-15 creating, 14-5 Life cycle-managed information, 10-19, 14-4 Life cycles, 14-1, 14-2 access control, 10-19, 14-21 Default, 14-3, 14-7 defined, 14-2 importing and exporting, 14-19 iterations of, 14-3 properties of, 14-6, 14-8 team roles and, 15-9 team templates and, 15-2 updating, 14-4 Logging On, 1-2
M
Maintenance only release, 14-19, 16-26 Manage Layouts page, 16-35 Managing action items, 8-3 activities, 8-3 deliverables, 8-3
Index-4
documents and folders, 8-3 libraries, 6-1 organization folders and documents, 5-4 organizations, 4-3 products, 6-1 project roles, 8-3 project team members, 8-3 project templates, 8-4 resources, 8-3 site folders and documents, 4-4 Members adding to a site, 4-4 organization, 2-14 Members role, 6-7 Modify permission, 10-5
N
New View Version permission, 10-5 Nodes. See Workflow processes, node types Notification lists, 13-2, 13-413-5 Notification Policy Manager, 13-5, 13-6 Notification rules combinations of, 13-4 creating, 13-2 defined, 13-2 object types and, 13-413-5 Notifications, 13-113-6 administrative, 9-16 defined, 13-2 deleted groups, 9-13 deleted oragnizations, 9-16 policies, defined, 13-2 process, 13-513-6 queue, 13-6 See also Workflow notifications notify.properties file, 13-5 NotifyPrincipalDisabled.xml, 9-16 NotifyPrincipalRepair.xml, 9-16 Null permission, 10-9 Numbering schemes administration, 8-5 configuring, 5-6 loading, 3-32 object initialization rules, 3-18 updating for projects, 8-5
O
o attribute, 1-11, 1-13, 2-6, 4-3 Object classes life cycles and, 14-7
Object initialization rules accessing, 3-33 description, 3-18 installation, 3-19 loading, 3-32 specifying, 3-35 updating, 3-32 XML, 3-36 Object subscription code examples, 16-35 Object types access control, 10-8, 10-11, 10-23 business data, 2-16 comparison of Windchill and Windchill PDMLink, 11-8, 15-7 defined, 10-3, 12-3, 13-2 indexing rules and, 12-4 life-cycle managed, 10-19 team templates, 15-6 OL files, 18-2 Online help, 2-3 Optegra Gateway, 18-19 Organization administrator, 1-11, 1-12 administrators, 3-3, 5-2, 5-8 affiliation, 2-14 attribute, 1-11, 1-12, 2-6 attributes, 4-3 containers, 1-6, 2-3, 3-4, 4-3 folders and documents, 5-4 groups, 5-3 members, 5-3 principals, 5-2 roles, 5-3 tab, 1-5, 1-6 templates, 1-9, 3-14, 3-15, 5-7 organization ID, 4-4 Organization Utilities page, 5-15 Organizations deleting, 9-15 managing, 9-14 viewing, 9-14 Out-of-the-box business object types, 2-16 container participation, 6-7 translated context templates, 3-20 Windchill PDMLink library templates, 6-6 Windchill PDMLink product templates, 6-6 Out-of-the-box templates organization, 5-7 project, 8-6 using, 3-22
Index-5
OWNER pseudo-user, 10-7
P
Participants assigning to life cycle roles, 14-12 to team roles, 15-19 to workflow activities, 16-16 defined, 15-2 searching for, 3-39 Participants window, 14-12 PDM domain, 2-10 PDMLink. See Windchill PDMLink Permissions access control lists, 10-810-10 ad hoc access control lists and, 14-13 calculating, 10-11 defined, 10-3 examples, 10-1010-11 setting, 10-510-6 types of, 10-5 See also Access control, Access control rules personal cabinet names, 9-9 PLT files, 18-2 Policies definition, 3-24 overview, 3-28 Policy ACLs. See Access control lists, policy Policy Administrator, 3-24, 3-28 Policy rules, 3-28, 3-31 Principal Administrator, 4-4, 9-4 Principal cache, 9-9, 9-12, 9-15, 9-17 Principals administering, 9-1 defined, 10-3, 13-3, 15-2 net permissions for, 10-910-10 repair, 9-18 searching, 3-39 Pro/ENGINEER Wildfire, 2-3 Pro/INTRALINK Gateway, 18-19 Process Manager toolbar, 16-29 Processes notification, 13-513-6 Product creators, 1-11, 5-3, 5-8 Product domains access control, 6-8 teams and, 15-8 Product manager, 1-11, 6-7, 6-12 Product tab, 1-4 Products container, 3-2
templates, 3-14, 6-6 Windchill PDM, 7-1 Windchill PDMLink, 6-15 Windchill PDMLlink, 6-1 ProductView, 2-18, 18-2, 18-3 ProductView Configuration Administrator for projects, 8-5 Project containers, domains for, 2-12 Project creators, 1-12, 5-3, 5-8 Project manager, 1-12 Project managers, 8-2 Project roles resolution of, 15-9 Project space creating and updating, 8-2 Project tab, 1-5 Project team members, 8-3 Project templates, 3-14, 8-4 out-of-the-box, 8-6 Project Utilities page, 8-4 ProjectLink. See Windchill ProjectLink Projects, 3-2, 8-2 Promotion. See Life cycle promotion Proxy processes. See Workflow subprocesses PTC documentation, xxii Publish Monitor for projects, 8-5 Publish Scheduler, 18-19 Publish Scheduler Administrator for projects, 8-5 Purging groups, 9-12 organizations, 9-15 users, 9-9
Q
Queues notification, 13-6 visualization publish jobs, 18-5, 18-17 Windchill Schedule, 18-19 See also Windchill Queue Manager
R
Read permission, 10-5 Related documentation, xix Repair principals, 9-18 Replication Administrator for projects, 8-5 Replication sites configuring, 4-6
Index-6
Report templates, 3-15 Resources, 8-3 Revise permission, 10-5 Robots. See Workflow processes, robot types RoleRB.rbinfo resource file, 14-11, 14-19, 15-18 Roles, 15-1 project, 8-3 Root domain, 3-11, 3-26, 3-27, 10-18 Root view, 17-2 Routing events, 16-19 Rule antecedents for access control lists, 10-7 for indexing, 12-2 for notifications, 13-2 Rule consequents for access control lists, 10-7 for indexing, 12-2 for notifications, 13-2 Rules. See Access control rules, Notification rules Runtime Services, 2-3
States. See Life cycle states Stopping CAD workers, 18-12 Subfolders defined, 10-17 domains, 10-17 moving, 10-17 Subprocesses. See Workflow subprocesses System cabinet, 14-3 System domain, 3-12, 3-26 System information, auditing, 4-5
T
Tables setting preferences to collapse, 4-9 Team association, 15-8 rules, 15-8 Team roles creating, 15-16 defined, 15-2 See also Life cycle roles, Participants Team templates, 15-2 Change Activity Team, 15-3 Change Control Board, 15-5 Change Team, 15-5 comparison of teams and, 15-2 container, 3-15 Default, 15-5, 15-7 ECN Team, 15-4 ECR Team, 15-4 installation, 3-17 object initialization rules, 3-18 out-of-the-box, 15-3 Windchill PDM, 15-5 Windchill PDMLink, 15-3 Problem Report Team, 15-3 Teams, 15-1, 15-2 context, 2-14 creating, 15-16 roles resolution, 15-9 Windchill PDMLink, 6-18 See also Team templates Technical support, xxi Templates creating, 3-22 organization, 1-9, 5-7 removing, 3-22 site-level, 4-5 translated, 3-20 Thumbnail generator, 18-3 Thumbnail images, 18-4
S
Schedule Publish Job, 18-19 Searching deleted oragnizations, 9-16 deleted users, 9-11, 9-14 groups, 9-12 indexes, 12-2 organizations, 9-15 users, 9-9 SessionIterationDomain domain, 3-26 Setting default preferences, 4-9, 5-16 permissions, 10-510-6 Site administrators, 1-11, 1-12, 3-3, 4-2 container, 2-3, 3-4, 3-19 container domains, 3-26 document templates, 3-17 life cycle templates, 3-16 tab, 1-5, 1-6 team templates, 3-17 workflow templates, 3-16 Soft attributes, 11-7 Soft Types, 11-6 Soft types, 2-17 Starting CAD agent, 18-10 CAD workers, 18-11 Type Manager, 11-10 StateRB.rbinfo resource file, 14-19, 15-18
Index-7
Transitions, for workflow activities, 16-21 Translated context templates, 3-20 Troubleshooting Visualization services, 18-9 Type Manager examples, 11-11 initial window, 11-10 use case, 11-11 using, 11-11 Types, 4-5, 5-4 enumerated, 15-18 Type Manager, 11-7 use case, 11-11
U
UFID, 9-2, 9-7 Unaffiliated domain, 2-15, 3-12, 3-27 Unique Federation Identifier, 9-2 Update Life Cycle window, 14-7, 14-10 Updating action items, 8-3 activities, 8-3 deliverables, 8-3 documents and folders, 8-3 groups, 9-12 life cycles, 14-4 members, 4-4 organization folders and documents, 5-4 organizations, 9-15 project space, 8-2 resources, 8-3 users, 9-9 workflow process templates, 16-3 User objects, 9-2 User domain, 2-14, 3-12, 3-26, 10-19 user ID, 9-8 Users creating, 10-18 deleting, 9-10 managing, 2-6, 2-14, 9-8 notifying. See Notifications organization affiliation, 2-14 setting permissions for, 10-510-6
Viewable publishing, 5-6 View-dependent objects defined, 17-2 Viewing groups, 9-12 organizations, 9-14, 9-15 users, 9-9 workflow history, 16-29 Views and view associations, 17-1 command-line utility for, 17-3 creating, 17-2 Visualization collaboration interface, 18-21 Visualization data model, 18-4 Visualization service See also Thumbnail generator, Thumbnail images Visualization services, 18-1 architecture, 18-3 file types, 18-2 loader, 18-3, 18-6 properties, 18-22 Publish Scheduler, 18-19 troubleshooting, 18-6
W
Watermarks, 18-21 Windchill environment, 2-3 Windchill PDM containers, 2-5 getting started, 1-2 home page, 1-3 library, 3-2 library container, 2-9, 7-2 organization, 2-6 Windchill PDMLink application containers, 2-10 container hierarchy, 2-7 demo data, 2-4 getting started, 1-2 home page, 1-4 templates, 3-22 translated templates, 3-20 Windchill ProjectLink administrators, 1-12 container hierarchy, 2-7 getting started, 1-2 home page, 1-5 project containers, 2-12 templates, 3-23 translated templates, 3-21 Windchill Queue Manager, 18-19 Windchill Runtime Architecture, 2-2
V
Versioning schemes configuring, 5-6 loading, 3-32 object initialization rules, 3-18
Index-8
Windchill URL, 1-2 Windchill Visualization Service, 2-18 Windows Administrative Domain, 10-3, 12-3 Create Project, 8-8 Create Team, 15-17 Participants, 14-12 Update Life Cycle, 14-7, 14-10 Work items deleted groups, 9-13 Workflow activities access control, 10-19 assigning participants to, 16-16 creating, 16-13 deadlines for, 16-17 declaring variables for, 16-19 defining, 16-13 defining transitions for, 16-21 error consequences, 16-22 routing, 16-19 Workflow Administrator page, 16-4, 16-28 Workflow history, 16-29 events, 16-30 Workflow History Viewer, 16-2, 16-31 Workflow notifications, 13-2 Workflow Process Editor, 16-2, 16-3 connector types, 16-23 navigating diagrams, 16-8 Workflow Process Manager, 14-17, 16-2 Workflow process templates checking out, 16-3 deleted groups, 9-14 deleted users, 9-11 importing and exporting, 16-26 iterations of, 16-3 updating, 16-3, 16-7 Workflow processes, 16-2 associating, with life cycle phases and gates, 14-15 declaring variables in, 16-11 defining connectors in, 16-23 defining links in, 16-24 deleted groups, 9-13 life cycles and, 14-3 node types, 16-8 robot types, 16-9 Workflow routing. See Workflow activities, Routing events Workflow runtime system, 16-2 Workflow states, 16-37 Workflow subprocesses creating, 16-22 Workflow system
components of, 16-2 defined, 16-2 Workflow templates container, 3-15 installation, 3-16 Workflow Tutorial, 16-2 Worklist fields configuring, 16-35 wt.principal.cache.timeToLive property, 9-17 wt.principal.cache.timeToLiveRandomizer property, 9-17 wt.properties file, 12-5, 16-36 domain names in, 3-27 wt.vc.views.LoadViews command-line utility, 17-3 WTAnalysisActivity, 2-16 WTChangeActivity2, 2-16 WTChangeInvestigation, 2-16 WTChangeIssue, 2-16 WTChangeOrder2, 2-16 WTChangeProposal, 2-16 WTChangeRequest2, 2-16 WTDocument, 2-16, 10-2, 10-8 WTObject, 10-10, 10-23, 13-4 access control rules for, 10-18, 10-19 WTPart, 2-16, 18-4, 18-5 WTProductConfiguration, 2-16 WTProductInstance2, 2-16 wvs.properties file, 18-6, 18-21
X
xconfmanager, 2-25
Z
ZIP files, 14-19, 14-20
Index-9

Windchill 7.0 Business Administrators Guide

Uploaded by

Copyright:

Available Formats

Windchill 7.0 Business Administrators Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windchill 7.0 Business Administrators Guide

Uploaded by

Copyright:

Available Formats

What are the main topics covered in the documentation?

What are the main topics covered in the documentation?

What are some of the key components of the Windchill product?

What are some of the key components of the Windchill product?

Windchill Business Administrators Guide

Windchill 7.0 December 2003

Change Record .................................................................................................... xv About This Guide................................................................................................ xix

Getting Started.................................................................................................... 1-1

Administration Overview ................................................................................... 2-1

Administering Containers .................................................................................. 3-1

Windchill Business Administrators Guide

Administering the Site ....................................................................................... 4-1

Administering Organizations............................................................................. 5-1

Administering Products and Libraries.............................................................. 6-1

Windchill Business Administrators Guide

Administering Windchill PDM Library .............................................................. 7-1

Administering Projects ...................................................................................... 8-1

Administering Access Control ........................................................................ 10-1

Windchill Business Administrators Guide

Using Types and the Type Manager ............................................................... 11-1

Administering Indexing................................................................................... 12-1

Administering Notifications............................................................................. 13-1

About Notification ..................................................................................................................... 13-5

Administering Life Cycles................................................................................ 14-1

Administering Teams and Roles ..................................................................... 15-1

Administering Workflow Processes................................................................ 16-1

Windchill Business Administrators Guide

Administering Views and View Associations ............................................... 17-1

Administering Visualization Services............................................................. 18-1

Administering Audit Reports ........................................................................... 19-1

Windchill Business Administrators Guide

Table 1 Changes for Windchill 7.0

Chapter 1, Getting Started

Chapter 2, Administration Overview

Chapter 3, Administering Containers

Chapter 4, Administering the Site

Chapter 5, Administering Organizations

Chapter 6, Administering Products and Libraries

Chapter 7, Administering Windchill PDM Library

Chapter 8, Administering Projects

Chapter 9, Administering Principals

Windchill Business Administrators Guide

Chapter 10, Administering Access Control

Chapter 11, Using Types and the Type Manager

Chapter 12, Administering Indexing

Chapter 13, Administering Notifications

Chapter 14, Administering Life Cycles

Chapter 15, Administering Teams and Roles

Chapter 16, Administering Workflow Processes

Chapter 19, Administering Audit Reports

Windchill Business Administrators Guide

About This Guide

Use Windchill applications to achieve goals appropriate for the application.

Understand the needs of particular application-user communities.

Windchill Business Administrators Guide

About This Guide

Documentation for PTC Products

Windchill Business Administrators Guide

Click OK. Select File > Save. create_<tablename>.sql create_<tablename>.sql

JavaGen "wt.doc.*" F true Processing completed.