Overview
Windchill manages and controls product data on a cross-organizational basis by providing enterprise-class capabilities without enterprise complexity. Windchill PDMLink provides you with:
- A packaged product life cycle management solution designed for quick implementation, based on PTC’s Windchill technology.
- A collaborative Web-native platform that supports critical product development elements, such as:
- Collaborative design
- Configuration management
- Life cycle and workflow management
- Change management
- Design outsourcing
- Variant design and generation
Checkout PLM Coach’s Windchill Training Offer
Windchill PDMLink
- Windchill is a new generation of PDM that solves the problems that have prevented manufacturers from effectively managing and controlling product data on a cross-organizational basis by providing enterprise-class capabilities without enterprise complexity.
- Windchill’s collaborative design environment enables the design team to develop products by using their preferred tools and still share critical product-related intellectual property with the other players in the process.
- Robust configuration management capabilities provide the technology for documenting and managing the configuration of the product in forms that all users can understand.
- Windchill’s built-in lifecycle and workflow management tools control process tasks, including reviews and approval, by enabling the delivery of the right information to the users who need it at the right time.
- Windchill change management solution uses a proven process for controlling the activities required to document and implement changes. PDMLink ensures that everyone has what they need to accurately assess the impact of a change and effectively plan and manage its implementation, reducing the likelihood of costly mistakes.
- Windchill provides the capability to perform design outsourcing functions by enabling the use of user profiles to configure the system interface by role and by providing a work package mechanism to group objects and data to be assigned to customers or suppliers as part of any business process.
- Windchill makes it simple for executives, managers, marketing, manufacturing, sales, and support people, as well as product developers, to easily access and use the organization’s product-related intellectual property.
Windchill Architecture
-
Server:
- Windchill server tier consists of a Windchill server and a Web server.
- It is important that a Business Administrator have an understanding of the basic architectural components of a Windchill system. From a high-level perspective, there are four mandatory system elements as well as several optional supporting elements.
- The Java-based Windchill Server is the application tier of the Windchill system and provides system logic for behavior and data element relationships. The Web Server enables Web connectivity and serves Web pages as part of the client tier, giving Windchill its Web-centric behavior. These two elements make up the technology core of the Windchill solution.
-
Client:
- The Windchill clients only require the latest browsers and network connectivity to access data and execute basic tasks.
- Client machines, which are the towers and laptops used by your user community, only require the latest browsers and network connectivity to access data and execute basic tasks. Because
- Windchill is a Web-based application, accessing information is as simple and familiar as “surfing the Web.” The client machine and the Web server together compose the client tier of Windchill.
-
Database:
- A database server, such as Oracle or SQL Server, is used to store Windchill objects.
- A database server is used as the database repository for Windchill metadata and creates a persistence tier for the Windchill system. Content files may also be stored in the database, but they are often referenced and stored elsewhere on the network.
- In addition, the Windchill Directory Server comes with Windchill. This is an LDAP (Lightweight Directory Access Protocol) server which is used to store some Windchill connection information.
- This directory server is also frequently used to store administrator login information.
- The database server, Windchill server, and client machines connected to the Web server establish a three-tier architecture, which is scalable and easier to manage than traditional client server environments.
-
Optional Services:
- Several optional servers provide Windchill with additional functionality.
- Additional servers can provide Windchill with additional functionality. Most of these servers are optional – if you do not use the feature, you do not need the server. A few examples are:
- The indexing server uses Solr to enable full-text search capabilities in the Windchill environment, searching not only object metadata, but the object content as well.
- One or more enterprise directory servers, such as Microsoft Active Directory may be used to authenticate Windchill users. This way, users maintain a single login name and password across all enterprise applications. In the absence of an enterprise directory server, you may store Windchill users in the Windchill Directory Server, or administrative directory.
- Visualization workers scan Windchill content files and create lightweight viewable representations.
- These representations may be read by ProductView, enabling users to view, review, discuss, and mark up the content even if they do not have access to the original authoring application. For example, you can use ProductView to mark up Creo Elements/PRO models or Arbortext documents even if you do not have a license.
- Windchill is designed to accommodate all SMTP compliant E-mail servers, which are used to send notification of system events to the user community. Typically, Windchill connects to an already existing enterprise mail server.
Checkout PLM Coach’s Windchill Training Offer
Windchill Terminology
- A Windchill organization represents your enterprise and contains products, libraries, and other data. Common Windchill terminology:
- Organization
- A Windchill organization represents your enterprise and contains products, libraries, and other data.
- Organization administrators define the information that is common across all products and libraries hosted within the context of their organization.
- Products
- Products provide an organizational context for product definition. Product contexts contain end items composed of structured assemblies of parts with associated CAD documents and documents, as well as other end items.
- Libraries
- Libraries provide an organizational context for similar, yet non-product specific data storage.
- Library contexts enable the association of administrative policies, such as access control, indexing, event notification, and external file vaulting rules to the objects in the library.
- Organization
Windchill Data Model
Primary business objects represent a class of objects that typically store information 
Image: Windchill Data Model
Primary Objects
- Primary Business Objects represent a class of objects that typically store information from the business domain.
- End items and parts are used to represent product structure and to conduct engineering configuration management.
- CAD documents store model and drawing information from specific applications that Windchill recognizes and integrates with, such as Creo Elements/PRO or CATIA.
- Documents are versatile objects that store content files from any authoring application.
- Viewables are lightweight representations of documents or parts that may be viewed and marked up in ProductView.
- Change items are used to track and control formal engineering change to the product structure, models, drawings, and product documentation.
- The figure above provides a basic illustration of the primary business object model for Windchill.
Policies, Processes, and Participants
- Windchill enables administrators to set up policies and configure processes for various participants.
- Domain Policies — Are composed of administrative rules for managing access control, indexing, and event notification. Domain policies may be Site specific, Organization specific, or associated with specific products and libraries.
- Life cycles — Are composed of sequential states that represent the maturation stages of objects.
- Workflows — Provide the automation of business processes during which tasks and/or information are passed from one participant to another for action, according to a set of procedural rules. Workflows are usually associated with one or more states in a life cycle.
- Principals — Represent business entities, such as users, groups, and organizations. Domain policies, workflow tasks, and other data and process management aspects of Windchill reference designated principals when defining system behavior.
- Roles — Are used to identify performers of a certain task (or tasks) within the system. For example, the reviewing activities may be assigned to a Reviewer role. Principals required to fulfill the role of Reviewer should be mapped to that role.
- Teams — Map a set of principals to roles, generally within the context of a specific product. Teams may also be used as an association mechanism for a set of business objects.
Checkout PLM Coach’s Windchill Training Offer
Business Administration
- The Business Administrator role exists to manage the Windchill environment and to apply business rules to the data controlled by the system.
- For the Business Administrator, Windchill provides the tools necessary to:
- Manage product data behavior.
- Manage users, groups, and organizations (principals).
- Manage product data access.
- Automate business processes.
- Configure role-based user interfaces.
- Monitor user and system event
The Business Administrator role exists to manage the Windchill environment and to apply business rules to the data controlled by the system. This includes, but is not limited to, managing users, groups, and organizations; administering products, libraries, projects and teams; defining access control, indexing, and notification policies; automating processes by using workflows and lifecycles to map to your companies business rules; generating system templates for administrative reuse; administering numbering and versioning schemes, perhaps with the assistance of a system administrator or application developer; and performing general system configuration changes to meet business needs.
Planning a Windchill Implementation
The statement, “Who can access what data, when, where, and how,” encompasses the elements of one of the largest tasks Business Administrator’s must perform: access control. Each who, what, when, and where element represents a specific piece of administration. Once those pieces are defined, the elements are used to identify the access control policies that build the how element.
Who
“Who” represents the user community that accesses the Windchill system. In Windchill terminology, who refers to principals, which may be users, groups, or organizations. Groups and organizations make it possible to selectively apply specific access control policies.
What
“What” refers to the data that is managed in the system, more specifically what type of data: parts, documents, or change items. While Windchill has been targeted to manage product development data, it is not limited to such.
When
“When” refers to the stages of data development, such as In Work, Under Review, Released, or Obsolete. This collection of stages, or states, is generally referred to as a product’s life cycle. Different users should be granted differing access permissions, based on the life cycle state of the data.
Where
“Where” refers to the way data is grouped or structured within the system. For example, data may be grouped by project, department, or type. Implementing logical products and libraries for grouping data facilitates the application of access control policies specific to those contexts.
How
“How” refers to the ways that principals may interact with data. Windchill provides standard options for Create, Read, Modify, and Delete, and other permissions, including Administrative. 
Image: Windchill Implementation Plan Checkout PLM Coach’s Windchill Training Offer
Identifying the Data to be Managed
The “what” element in business administration encompasses the data that is managed in the Windchill system. First, you must identify product information that is maintained with strict revision control versus project information which is stored more informally. Next, identify data that is stored in the system for reference or in support of other managed product data. Once your corporate information has been identified, look at the data objects available in Windchill and determine which objects best meet the data storage needs for your product information. Identifying the departments or business units that use the information helps you later determine the way access control policies are developed and implemented
Identifying Windchill Users
Every user must have a user account before accessing the Windchill system. User accounts enable you, as a Business Administrator, to grant or deny individual access to the data within Windchill, to maintain a historical record of user interaction, and to send E-mail notifications of system events. You categorize your user accounts into organizations and groups. Groups help simplify administration when implementing system policies.
Checkout PLM Coach’s Windchill Training Offer
Windchill Contexts
As a Business Administrator, you must understand Windchill’s concept of contexts, or containers. Contexts identify administrative levels within Windchill. The Site context represents the entire Windchill installation. Administration conducted at the Site context affects the entire Windchill system and all of the data in the system. Within the Site context, there is an organization context. An organization context typically represents a major business unit or division at your company. Later, you learn about smaller contexts within the organization, such as products and libraries. It is a PTC recommended best practice that initial implementations begin with the use of a single organization context; therefore, this course generally focuses on management of a single organization context. 
Image: Windchill Contexts
Users and Groups
It is essential for you to determine the specific individuals who require a user account for the Windchill system. Is it all employees or a subset of employees, such as those in a specific department or involved on a specific project? Everyone who needs to access information or participate in a Windchill automated process requires a user account. Once the original set of users has been established, a process should be put in place to add user accounts and make changes to user accounts as the organization evolves. 
Image: Windchill Users and Groups Checkout PLM Coach’s Windchill Training Offer
User and Group Structure
A Windchill site implementation must contain at least one organization, which in turn should contain most of the user community accounts. While an organization context acts as an administrative domain, the associated organization object acts like a super group whose membership includes all users associated to that organization. The Organization object is available from several administrative interfaces, which enable you to conveniently apply rules or policies to the entire organization. The systems’ user accounts may be associated as members of groups and groups may be composed of user accounts and other groups. 
Image: Windchill Users and Groups Structure
Understanding Contexts
A context within Windchill is a storage location for a set of related information and business objects. These storage locations are analogous to file cabinets in the physical world and are implemented in the system using a cabinet object. Like a file cabinet, each context may contain folders, documents, CAD documents, and other Windchill objects. Each business object in the system is contained in only one context enabling a type of conceptual ownership between a business object and its context. Each Windchill context is governed by a set of administrative domain policies that apply to all of the data stored inside it. A context is related to other contexts through a specific hierarchy. Because this hierarchy exists, administrators can use it to navigate to business objects in a specific context or to apply administrative domain policies at higher levels that apply to all contexts below it. Checkout PLM Coach’s Windchill Training Offer
Relationships Between Contexts
The context hierarchy is a conceptual structure that implies a parent/child relationship between contexts at different levels. Windchill has three context hierarchy levels: the site level, the organization level, and the sub-organization level.
Site
The site level is the root or top-level parent of the hierarchy. It is composed of a single Site context which is a cabinet that hosts all of the data and policies contained in the system. The Site context acts as a host to one or more Organization context objects. Policies applied at the site level are inherited by all of the Organization contexts below it.
Organization
The organization level is the second tier of the context hierarchy. It is composed of one or more Organization contexts. Each Organization context is a cabinet that hosts all of the data and policies contained in that specific organization. The Organization context may contain zero or more sub-organization level context objects. Policies applied at the Organization context are inherited by all of the contexts below it. The final level is the sub-organization level. There are several types of contexts which may be stored in an organization:
- A Product context stores information related to a single, deliverable product.
- A Library context stores information related to reference parts and documents not specifically associated to any single product.
Each of these contexts is a cabinet that hosts all of the data and policies for that specific container. Some of these policies are inherited from the Organization parent context and the Site context. The context hierarchy enables the creation of common policies, templates, and profiles at higher levels simplifying the administration of the system. These rules become the default policies for all business objects and data at lower levels, unless a specific rule is written at a lower level which overrides the default policy. Rules applied at the organization level override those that are applied at the site level. Rules at the product/library level override those that are applied at the organization and site level. While all contexts have the capability of storing business objects and data, only the lowest level is typically used for storing business objects such as CAD documents and documents. The Site and Organization contexts are typically accessed only by administrators, and store only objects related to the administration of the Windchill system. Because the site and organization levels are used for creating default administrative rules, normal users do not see a Site or Organization tab. Business objects that contain data for users are typically put into individual sub-organization level contexts.
Windchill Objects Review
Windchill stores, manages, and controls many different types of data which are represented by various business objects in the system. This table is provided as a refresher to remind you of the commonly managed Windchill objects and their corresponding class names. As a Business Administrator, you should understand that it is important to know both the display name given to the various data being stored in the system and the object class name. While the object display name is presented to your users, the Windchill object type or class names are typically used by the various administrative tools within the system. You can use this table as a reference throughout this module to relate the administrative functions performed on object types to the business behavior displayed in the system associated with the corresponding object name.
| Object Type (Display) | Object Class (Java) |
|---|---|
| All (parent of all objects) | wt.fc.WTObject |
| Parts and End Items | wt.part.WTPart with end item attribute |
| CAD Documents | wt.epm.EPMDocument |
| Dynamic Documents | Subtype of EPMDocument |
| Problem Reports | wt.change2.WTChangeIssue |
| Change Requests | wt.change2.WTChangeRequest2 |
| Change Notices | wt.change2.WTChangeOrder2 |
| Change Notice Tasks | wt.change2.WTChangeActivity2 |
| Managed Baselines | wt.vc.baseline.ManagedBaseline |
Windchill Object Typing Capability
Windchill’s runtime typing capability enables you to augment out-of-the-box business objects by adding additional attributes, or by adding new object types with different attribute sets without changing the object model or writing code. Runtime typing capability can extend a type to add attributes to it, or create a subtype that has different administration and access controls. Both extended and subtypes are non-modeled and do not require recompiling or interrupting operations. Although non-modeled types are limited in possible logic or functions, they do give you the capability of customizing the information that you capture in the system, enable you to set type-specific policies, and enable you to configure rules that govern the business behavior of each object type. In contrast, modeled types take a longer time to implement and require extensive Java experience, but may provide advanced functionality such as specialized application integration, statistical analysis, or any other function that can be coded in Java. Additionally, modeling requires the additional purchase of Windchill Information Modeler for Windchill.
Extending and Subtyping Objects
Windchill enables you to extend object types by adding additional attributes and creating custom user interface layouts. Extending an object alters that object and Windchill makes a clear distinction between an extended WTDocument and an unextended WTDocument; however, both types share the same administrative rules. Subtyping an object enables you to not only create new attributes and interfaces, but distinguishes between it and the original object by enabling unique administration. For example, a subtype of WTDocument may have different access control rules, profiles, and attribute sets than the original WTDocument. If you do not override an administrative element, the subtype inherits it from the parent. For example, if you do not create new user interface layouts for your subtype of WTDocument, it uses WTDocument’s layouts. Checkout PLM Coach’s Windchill Training Offer
The Type and Attribute Manager
The Type Manager enables you to extend and subtype objects. The Type Manager:
- Is structured in a hierarchical format.
- Enables you to create types for many object classes.
- Enables you to add attributes to types.
- Enables you to add layouts to types.
- Enables you to set constraints on attributes.
- Subtypes inherit the attributes of their parent type.
Types
The Type Manager displays object classes in a structured hierarchical format. Within the Managed Types area, all of the modeled classes that can be typed are exposed to the Type Manager. The Type Manager enables you to create subtypes from the modeled classes, add attributes to the modeled classes or newly created types, and set constraints on attributes. Subtypes are created and displayed as children to the modeled classes in the structural hierarchy, such as the Agenda and General documents in the figure. When subtypes are created, they inherit all the attributes of their parent type.
Enumerations
The Type and Attribute Manager also manages global enumerations. A global enumeration is useful if you have a set of valid string values for an attribute that may be used in more than one type. For example, both a document and a part may have a commodity code attribute, and you want to be certain that the valid values for commodity code are the same across both types. However, there are also cases when you do not want to use a global enumeration. For example, a case part and a garment part may both have an attribute for material. However, the case part may have valid values such as plastic and aluminum, while the garment part has valid values such as cotton and nylon. The Internal Name of an enumeration must be unique in the organization, but is not generally shown in Windchill user interfaces. The Display Name is shown in user interfaces. Checkout PLM Coach’s Windchill Training Offer
Adding Attributes to Types
To add a new attribute to a type, it must first be in Edit mode. Newly created types are in Edit mode by default, but existing types are not. If you need to enter edit mode, select the object type from the Manage Types panel and click Actions → Edit. You can only edit modeled and site-level types if you are a site administrator. An Organization administrator can create and edit types at the Organization level, but there are no out-of-the-box Organization-level objects.
Managing Attribute Constraints
When an attribute is assigned to a type, attribute constraints can be applied. Constraints can limit or dictate the attribute values required from users. Windchill provides a wide variety of possible constraints. A few of the most common are:
- The Legal Value List constraint limits the attribute value to a predetermined set of values. In the example, the Description attribute for the Document type has a Legal Value List constraint.
- An Enumerated Value List constraint also limits the attribute value, but instead of entering the set of legal values in the constraint, it refers to a global enumeration to get the set of legal values.
- A Suggested Value List provides a set of values, but the user may enter a different value if needed.
- A Valid Range may provided with numeric attributes. This could, for example, keep an attribute from being a negative number.
- The Required constraint prevents the type from being instantiated unless the attribute has a value.
- The Single Valued constraint prevents you from associating more than one of the attribute to the type.
It is important to remember that the constraint is associated with the combination of the type and the attribute, not just to the attribute. This enables the same attribute to have different constraints, depending upon the type. For example, a string attribute “Location” may be restricted to a set of company facilities in one type, and unconstrained in another type. The example shows constraints for the Department attribute of a Document type.
Managing Attribute Visibility
The Visibility tab of an attribute associated with a type controls which attributes appear on which screens, and how. Visibility for global attributes can be further controlled using Profiles. A profile can control the visibility of a global attribute regardless of which type it is used in. If the visibility of a global attribute is restricted using a profile and the type manager, the most restrictive visibility of the two is used. Each attribute has a visibility control for each screen. The visibility may be set to:
- Read/Write – Enables the user to view and edit the attribute.
- Read Only – Enables the user to view, but not edit the attribute.
- Value Hidden – Enables the user to see the attribute exists, but not its value.
- Hidden – The user does not see that the attribute exists.
The Visibility tab controls what attributes are seen and how. But, the Layouts tab controls where the attributes are seen. Layouts may be used to arrange attributes on a screen in different locations. However, editing Layouts has some drawbacks:
- Out of the box layouts are not intuitive. It takes some effort to understand what attributes appear on what screens, and where.
- When you add a layout to a subtype, you break the inheritance of all layouts from the parent type. Thus, if you want to create a new layout for a subtype, you must rewrite all of the layouts.
- Windchill 10 is the first release of Windchill with layouts. As such, as of the time of this writing, layouts have not been heavily tested in the field and best practices for their have not yet been defined.
You do not need to create a layout to have an attribute appear on the screen. Windchill user interfaces for most types automatically adjust for new attributes if the visibility is set correctly. Checkout PLM Coach’s Windchill Training Offer
Creating Subtypes
You can access the New Subtype Wizard using either of the following methods:
- The right-click context menu of the parent type in the right panel of the type manager.
- The Actions menu of the type information page. The New Subtype has several attributes:
- The Internal Name must uniquely identify the type, but is not used in Windchill user interfaces.
- The Display Name is the name of the type displayed in Windchill user interfaces, but does not need to be unique and may contain spaces.
- The Icon is the full path to an image. This image represents the type on the Folder page and other user interfaces. The image path is relative to the [Windchill Home]/codebase directory on the server, so in the example you can see the file is somewhere in [Windchill Home]/codebase/netmarkets.
Most Business Administrators do not have the ability to upload files to the Windchill codebase directory or its subdirectories. As a result, there are generally three ways to configure an icon:
- Inherit the icon from the parent type.
- Know where an existing icon is and use it (you are likely unable to browse the codebase).
- Ask your system administrator to upload an icon for you and tell you the path.
Localizing Types and Attributes
If your Windchill instance has a language pack installed, you can localize many type and attribute properties. To do so, you must edit the type or attribute and click the Localize icon next to the field you want to translate. A Localize Wizard appears enabling you to translate the field into each language for which a Windchill language pack is installed. Checkout PLM Coach’s Windchill Training Offer
Object Initialization Rules
A business administrator configures object initialization rules in order to control the behavior and associations of an object upon its creation (instantiation). The rules are written in XML, assigned to a specific object class, and can be defined at all of the context levels. You can set up object initialization rules to affect any of the following object attributes: object numbering, object versioning, folder path, life cycle association, and team template association. Object initialization rules control the behavior and associations of an object upon its creation. Object initialization rules:
- Provide the capability to assign specific associations and behaviors to object types upon their creation.
- Are written in XML.
- Can be defined at all contexts.
- Are object class specific.
Object initialization rules affect the following attributes:
- Object numbering
- Object versioning
- Folder path
- Life cycle association
- Team template association
Object Initialization Rule Management
When an object is created, it uses a merged object initialization rule to determine its settings. Object initialization rules can be defined at all contexts.
- Rules set during installation affect all objects of the types specified in the load file.
- Rules at the Site context affect objects generated within the Windchill installation.
- Rules at the Organization context affect objects generated within that Organization.
- Rules for a sub-organization level context affect objects generated within that context.
- Object initialization rule merging:
- The rules used at object creation are merged from all of the object initialization rules for that class of object at all contexts in the object’s hierarchy.
- Merging enables setting some attributes at a higher context, while leaving others to be defined at the Product or Library level.
- If two rules conflict during the merge, the rule at the lower context takes precedence.
Checkout PLM Coach’s Windchill Training Offer
Object Initialization Rule Example
The graphic in this slide shows an example of an object initialization rule. The rule consists of an XML document that must be formatted according to the object initialization rules Document Type Definition (DTD). The XML document contains various XML tags that identify information that the system uses during object creation. The first tag identifies the type of object for which the default attribute values are being set. The individual rules are separated by comments that identify the various attribute settings. Each rule consists of an XML tag identifying the algorithm used to determine the attribute value followed by the XML tags used to determine the algorithm’s default values. 
Image: Windchill Object Initialization Rules Sample XML File
Life Cycle Association Rules
The life cycle association rule consists of an XML tag identifying the LifeCycleTemplateAttributeAlgorithm. Life cycle associations may be defined as part of the object initialization rule set.
- Determined by the LifeCycleTemplateAttributeAlgorithm.
- The out-of-the-box algorithm requires one argument that is used to identify the default value: <Arg>Basic</Arg>
- Replace the value in the <Arg></Arg> tags to change the life cycle used.
Team Template Association Rules
The team template association rule consists of an XML tag identifying the TeamTemplateAttributeAlgorithm. Team Template associations may be defined as part of the object initialization rule set.
- Defined by the TeamTemplateAttributeAlgorithm.
- The out-of-the-box algorithm requires one argument that is used to identify the default value: <Arg>Default</Arg>
- Replace the value in the <Arg></Arg> tags with the name of a Team Template as displayed in the Team Template Administrator.
Checkout PLM Coach’s Windchill Training Offer
Object Numbering Scheme Rules
You can write an object numbering scheme rule to identify the numbering scheme used for end items, parts, documents, CAD documents and all of the change objects. The numbering scheme rule consists of an XML tag identifying the NumberGenerator algorithm. Following the XML tag for the algorithm are any XML argument tags that identify settings used by the algorithm. Out-of-the-box, initial numbering rules are set for documents, CAD documents, parts, and end items to use sequential numbering with a 10 digit default number length, and for change objects to use sequential numbering with a five digit default number length. If you remove the numbering scheme rules in all contexts, the system uses built-in defaults to determine object numbering behavior. If the object is created in a sub-organization level context, then manual numbering occurs. If the object is created at the Site or Organization context, then single digit autonumbering occurs.
Folder Path Rules
The folder path rule consists of an XML tag identifying the PathAttributeAlgorithm. Folder paths may be defined as part of the object initialization rule set.
- Determined by the FolderPathAttributeAlgorithm
- The out-of-the-box algorithm requires one argument used to identify the default value: <Arg>/Default</Arg>
- Replace the value in the <Arg></Arg> tags to change folder storage.
- /Default must start the path, indicating the root folder of the context.
- For example, storing parts in a Parts folder: <Arg>/Default/Parts</Arg>
Versioning Scheme Rules
The versioning scheme rule consists of an XML tag identifying the VersionInfoGenerator algorithm. Versioned objects:
- End Items
- Parts
- Documents
- CAD Documents
Versioning scheme may be defined as part of the object initialization rule set.
- Determined by the VersionInfoGenerator algorithm.
- The out-of-the-box algorithm requires one argument used to identify the default value: <Arg>wt.series.HarvardSeries</Arg>
- Replace the series identified between the <Arg> and </Arg> tags to change the versioning scheme used.
Checkout PLM Coach’s Windchill Training Offer
Understanding Windchill Life Cycle Types
There are Basic and Advanced types of Windchill life cycles. Basic:
- Use pre-defined transitions for life cycle movement.
- Provides improved performance during the creation and revision of objects.
- Recommended to manage most Windchill objects.
Advanced:
- Use workflows for life cycle movement.
- Used for the out-of-the-box Promotion transition processes.
- Use this type for managing objects that require:
- Development through company-specific business processes.
- Special access control.
- Additional flexibility in managing the objects.
Defining Windchill Domain Policies
A domain’s primary purpose is to manage policies. Domain policies define a set of rules that govern:
- Access control
- Determines who can create, read, modify, and delete specific data objects (documents, parts) within designated Products, Libraries, Projects, and Programs.
- Notifications
- Determines who receives an E-mail notification triggered by a specific Windchill object event.
- Indexing
- Determines what data objects are stored in a searchable Collection (data library) and can be located by users performing searches.
Security Labeled Objects
A security label may be placed on an object to deny access to non-authorized participants. Security labels may deny access to objects to non-authorized participants, even if the user would otherwise be granted access by using domain or ad-hoc access.
- Internal Personnel only
- Export-controlled
- Company proprietary
- Highly trusted employee
An authorized participant may be a user, group, or organization. Agreements may provide exceptions to a security label. Agreements are lifecycle controlled objects in Windchill. Agreements may be site, organization, or sub-context level, but labels are defined site-wide. Implementing security labels requires manually editing text files and is typically done by a system administrator or application Checkout PLM Coach’s Windchill Training Offer
Understanding Access Control
When a user accesses an object, the system checks the policy rules for that object. First, if the object is security-labeled, the system checks the security label. If the user is authorized: The System Checks Policy Rules
- Group Grant which is overridden by
- Group Deny which is overridden by
- User Grant, which is overridden by
- User Deny, which is overridden by
- Group or user Absolute Deny
How the Policy Rules are Evaluated
- If a user is denied access by an Absolute Deny, the user is denied access without referring to ad-hoc access.
- If a user is granted access by policy, the user is permitted access without referring to ad-hoc access.
How Ad-Hoc Rules are Evaluated
- Ad-Hoc Access can only grant.
- Ad-Hoc Access overrides a deny rule that is set by domain policy, but not an absolute deny rule.
Checkout PLM Coach’s Windchill Training Offer
Planning Access Control Strategies
Restrictive access control rules are the recommended method. The two general access rule philosophies include:
- Open rules
- Restrictive rules
The places where access rules can be applied in Windchill include:
- Security Labels (Object level)
- Labels, such as internal-only may be applied to an object.
- Denies any type of access to unauthorized users, regardless of policy or ad-hoc rules.
- Exceptions to the label may be made by using security agreements.
- Domain (Policy)
- Access rules applied to a storage context.
- Rules apply to all objects of the same class within the context.
- Life Cycle and Manage Security (Ad-Hoc)
- Life cycle rules are applied as part of a business process.
- Manage Security rules are applied manually through an administrative interface.
- Grant permissions only, not deny.
- Supersedes domain policy access control rules.
Conclusion
This guide assists newbies on getting started with Windchill administration. If you want to gain structured in-depth knowledge on Windchill checkout our Windchill training offerings. Checkout our Other Resources PLM Coach – All Courses Teamcenter PLM Training Teamcenter PLM Customization Teamcenter PLM Architecture Learn CATIA CAA RADE Teamcenter Functional Guide 3DEXPERIENCE Enterprise Knowledge Language 3DEXPERIENCE Web Services Guide 3DEXPERIENCE Platform Openness Teamcenter Interview Questions with Answers 3DEXPERIENCE CAA RADE Terminology 3DEXPERIENCE EKL Guide ————————————————– 🌍 For PLM / CAD Training Visit ► https://plmcoach.com
Follow PLM Coach on Social Media: YouTube | LinkedIn | Facebook | Twitter | Pinterest
📧 Contact PLM Coach:
Follow the link to Training Inquiry Form to provide your details PLM Coach Training Inquiry Form
Follow the link to Text PLM Coach on WhatsApp ► https://wa.me/917989703878
☏ Mobile Number ► +91-7989703878
💌 Email ► info@plmcoach.com
————————————————–
Wonderful extract of entire windchill PLM not only for people new to PLM but for experienced people.