Configuring Part and Document Relationships (Products and Libraries)
The relationships between a part and a document, two parts, or two documents vary depending upon how the two objects are linked. This section briefly describes the different types of links that form these relationships and then describes the configuration options that are available.
Part to Document Relationships (Products and Libraries)
|
|
Part to document relationships do not apply to Arbortext Content Manager or Pro/INTRALINK 10.1.
|
The association between a part and a document is created from the part information page, document information page, or Part Structure Browser. Associations can be viewed from the Related Objects tab on the part information page. These same relationships can be viewed from the Related Objects tab of the document information page.
There are two types of links that can be established:
• A Part Reference Link (WTPartReferenceLink)—Using this type of link always links the part to the master document. Regardless of the version of the document the user selects, the part will always link to the master document when this link type is used. This is true even when the system has been configured to allow the user to select the link type and the document type.
Reference links always display a document version of the master based on life cycle state rules. For example, when a user clicks the reference link for Part 100 version A.1, Windchill searches for the latest released version of Doc 100 to display. If no version of the document has been released, it displays the latest working version (in this case, Doc 100 version A.2).
How to configure the life cycle state rules is described later in this section.
• A Part Describe Link (WTPartDescribeLink)—Using this type of link links the part to the latest iteration of a document and vice versa.
For example, when the user clicks a describe link for Part 100 version A.2, Windchill searches for the latest iteration of Doc 100 to display (in this case, Doc 100 version A.2).
You can create part to document relationships in the following ways:
• From the Related Objects tab on the part information page, the user creates the link using the actions from the References Documents or Described By Documents tables.
• From the Related Objects tab on the document information page, the user creates the link using the actions from the Describes Parts or Referenced By Parts tables.
• From the Structure tab on the part information page, the user creates the link using the > or > actions from the right-click action menu for a part.
Relationship constraints can be created for the
Part Reference Link and
Part Describe Link types, to specify which document types can be related to which part types for those relationships. Once relationship constraints have been created, only documents of the types specified in the relationship constraint appear when adding an existing document or creating a new document and adding it to a part as a described by or references document. For more information, see
Relationship Constraints Tab.
| Special link types, known as configurable links, can be used to configure and display additional relationship tables on document and part information pages. For information, see Using Configurable Links. |
To allow the user to select the link type regardless of the document subtype, set the Part to Document Association Logic preference to Yes from the Preference Management utility on > or > . You might create relationship constraints in the Type and Attribute Management utility that do not carry forward to the end-user user interface until you modify this preference.
For more information on using the
Preference Management utility, see
About the Preference Management Utility.
| In addition, setting this preference allows you to associate more than one version of a described by document to a part. For reference documents, the part is associated to the document master. |
Additional configuration options are described in the following sections.
Revised or Saved Part to Related Document (Products and Libraries)
When a user revises a part using the Revise action or saves the part using the Save As action, the new version of the part carries forward the link to the document by default. While the Revise action always carries the link forward, you can choose to prevent the link from being carried forward during a Save As action by removing the Relationship copy rules related to this operation from wt.properties.
For example, assume the following properties are set in wt.properties:
wt.enterprise.copyRuleDelimiter=,
wt.enterprise.copyRulesN=wt.part.WTPart,Relationship,
wt.part.WTPartReferenceLink-references
The first property sets the delimiter for the copy rules to the comma (,).
The wt.enterprise.copyRulesN property is the Relationship copy rule for wt.part.WTPart. This rule copies the references forward when the type of link is WTPartReferenceLink.
If you remove the wt.enterprise.copyRulesN property, then reference links are not carried forward.
| As a best practice, there should be no gaps in the sequence of copy rules. If you remove a copy rule, renumber those rules that follow. For example if there are six copy rules and you remove copyRules5, then you should renumber copyRules6 so that it is copyRules5. Duplicate numbers should never be used in the copy rules sequence. |
Use the xconfmanager utility when modifying the wt.properties file. For more information on using this utility, see
About the xconfmanager Utility. For more information about the properties used for copy rules, see the description of wt.enterprise.copyRules in the properties.html file.
| PTC recommends that you do not change the value of the wt.enterprise.copyServiceRules property. The property is used by internal services. |
Document Version Used with Reference Link (Products and Libraries)
As described earlier, Part Reference Link links (WTPartReferenceLink) link to a document master, but display a document version of the master based on the life cycle state rules for the document.
The default behavior is that Windchill searches for the latest released version of the document to display. If no version of the document has been released, it displays the latest working version of the document.
To change the default behavior, change the value set for the List of comma separated life cycle states of documents used to display associated Reference documents to part. in the Preference Management utility.
| The states must be valid life cycle states. The states are defined as key value pairs in StateRb.rbinfo and can be viewed in the life cycle template associated with the object. States are always specified using uppercase characters. |
For example, to change the search to include the Released, Approved, and then Completed states of a document, set the preference value to:
RELEASED,APPROVED,COMPLETED
After this preference is set, Windchill searches for the latest Released version first. If none is found, it searches for the latest Approved version. If none is found, it searches for the latest Completed version. So, if a part is linked to Reference Document 4 which has three versions (A, B, and C), where A = Released, B = Approved, and C = In Work, based on the state settings in wt.properties, Windchill displays the latest iteration of version A which was released and ignores the rest.
Part to Part Relationships (Products and Libraries)
| Part to part relationships are available only in Windchill PDMLink, and do not apply to Arbortext Content Manager or Pro/INTRALINK 10.1. |
A user associates one part with another by using the Structure tab on a part information page. When a user makes the association, a Part Usage link (WTPartUsageLink) is created, forming a "uses part" relationship between a part and a part master.
The only configuration option for part to part relationships is described in the next section.
Revised or Saved Parent Part to Child Part (Products and Libraries)
When a user revises a parent part using the Revise action or saves the part using the Save As action, the new version of the part carries forward the usage link.
To prevent a link from being copied forward on a Revise or Save As action, you must remove copy rules from wt.properties. For example, assume the following properties are set in wt.properties:
wt.enterprise.copyRuleDelimiter=,
wt.enterprise.copyRulesN=wt.part.WTPart,Relationship,
wt.part.WTPartUsageLink-uses
The first property sets the delimiter for the copy rules to the comma (,).
The wt.enterprise.copyRulesN property is the Relationship copy rule for wt.part.WTPart. This rule copies the references forward when the type of link is WTPartUsageLink.
If you remove the wt.enterprise.copyRulesN property, then the usage links are not carried forward.
| There can be no gaps in the sequence of copy rules. If you remove a copy rule, you must renumber those rules that follow. For example, if there are six copy rules and you remove copyRules4, then you must renumber copyRules5 and copyRules6 so that copyRules5 becomes copyRules4 and copyRules6 becomes copyRules5. |
Use the xconfmanager utility when modifying the wt.properties file. For more information on using this utility, see
About the xconfmanager Utility. For more information about the properties used for copy rules, see the description of wt.enterprise.copyRules in the properties.html file.
| PTC recommends that you do not change the value of the wt.enterprise.copyServiceRules property. The property is used by internal services. |
Document to Document Relationships (Products and Libraries)
There are several different types of document to document relationships in your Windchill solution:
• A document can reference another document from the Related Objects tab on the document information page. This relationship creates a link of type WTDocumentDependencyLink.
• A document can serve as the parent to a second child document from the Structure tab on the document information page. This relationship creates a link of type Document Usage (WTDocumentUsageLink).
There are no configuration options available for document to document relationships.
Part and Document Association Behavior (Products and Libraries)
About Part to Document Association Logic preference:
The preference Part to Document Association Logic controls the logic for how documents are related to and displayed for a part or a part instance. A value of 'No' uses the PDMLink logic and a value of 'Yes' uses the Windchill PDM logic. The PDMLink logic enforces that a document of type Reference document can only be associated to a part or a part instance as a References document and all other document types can only be associated to a part or a part instance as a Described By document. The Windchill PDM logic allows References and Described By relationships to be created from part or part instance to document regardless of the document type. See the References and Described By tables on the part information page or part instance information page for a description of the behavior of References documents and Described By documents. In addition, the PDMLink logic enforces that a part or a part instance be related only to one version of a document; whereas the Windchill PDM logic allows a part or a part instance to be associated to versions of the same document.
When the preference Part To Document Association Logic is set to: | Expected Behavior |
No | For a part inside Related Tabs -> Describes by doc, it should be able to create/add docs of all types except Reference Document |
Yes | For a part inside Related Tabs -> Describes by doc, it should be able to create/add docs of all types including Reference Document |
About com.ptc.core.meta.type.mgmt.server.impl.association.useImpliedAssociationConstraintItemList property:
The base association constraints between WTPart and WTDocument are displayed because WTPartDescribeLink is listed as a type that supports “implied” constraints in the system. You can override this behavior by setting a property. By default, this property is set to include: WTPartUsageLink, WTDocumentUsageLink, WTPartDescribeLink, and WTPartReferenceLink. You can set this property in site.xconf as per your requirements. For example, to omit WTPartDescribeLink from this “implied” constraints list, you can set the property as:
<Property name="com.ptc.core.meta.type.mgmt.server.impl.association.useImpliedAssociationConstraintItemList" overridable="true" targetFile="codebase/wt.properties" value="wt.part.WTPartUsageLink,wt.doc.WTDocumentUsageLink,wt.part.WTPartReferenceLink"/>
The image provided below displays the hierarchy structure of a Part and a Document:
If the Part Describe Link has the following Relationship Constraint : partsubtype -> docsubtype | The property com.ptc.core.meta.type.mgmt.server.impl.association.useImpliedAssociationConstraintItemList in wt.properties file | Expected Behavior | Summary |
Yes | does not contains 'wt.part.WTPartDescribeLink' | For a document of type 'docsubtype', inside Related Tabs -> describes part, it should be able to create/add only parts of type 'partsubtype' and all sub types of partsubtype | Doc2(DocSubtype) —> Part2(PartSubtype) Doc2(DocSubtype) —> Part3(Subtype of PartSubtype) |
Yes | contains 'wt.part.WTPartDescribeLink' (OOTB) | For a document of type 'docsubtype', inside Related Tabs -> describes part, it should be able to create/add parts of other types as well | Doc2(DocSubtype) —> Part2(PartSubtype) Doc2(DocSubtype) —> Part3(PartSubtype) Doc2(DocSubtype) —> Part4(PartSubtype) Doc2(DocSubtype) —> Part1(Part) |
No | does not contains 'wt.part.WTPartDescribeLink' | For a document of type 'docsubtype', inside Related Tabs -> describes part, it should not be able to create/add parts of other types as well | Doc2(DocSubtype) ⅹ—> Part2(PartSubtype) Doc2(DocSubtype) x—> Part3(Subtype of PartSubtype) |
No | contains 'wt.part.WTPartDescribeLink' (OOTB) | For a document of type 'docsubtype', inside Related Tabs -> describes part, it should be able to create/add parts of other types as well | Doc2(DocSubtype) —> Part2(PartSubtype) Doc2(DocSubtype) —> Part3(PartSubtype) Doc2(DocSubtype) —> Part4(PartSubtype) Doc2(DocSubtype) —> Part1(Part) |
Yes | contains 'wt.part.WTPartDescribeLink' (OOTB) | For a part of type 'partsubtype', inside Related Tabs -> describes by doc, it should be able to create/add only docs of type 'docsubtype' and all sub types of docsubtype | Part2(PartSubtype) —> Doc2(DocSubtype) Part2(PartSubtype) —> Doc3(Subtype of DocSubtype) |
Yes | does not contains 'wt.part.WTPartDescribeLink' | For a part of type 'partsubtype', inside Related Tabs -> describes doc, it should be able to create/add only docs of type 'docsubtype' and all sub types of docsubtype | Part2(PartSubtype) —> Doc2(DocSubtype) Part2(PartSubtype) —> Doc3(Subtype of DocSubtype) |
No | contains 'wt.part.WTPartDescribeLink' (OOTB) | For a part of type 'partsubtype', inside Related Tabs -> describes by doc, it should be able to create/add document of other types as well | Part2(PartSubtype) —> Doc2(DocSubtype) Part2(PartSubtype) —> Doc3(Subtype of DocSubtype) Part2(PartSubtype) —> Doc4(Subtype of DocSubtype) Part2(PartSubtype) —> Doc1(Document) |
No | does not contains 'wt.part.WTPartDescribeLink' | For a part of type 'partsubtype', inside Related Tabs -> describes doc, it should be not able to create/add document of other types as well | Part2(PartSubtype) —> Doc2(DocSubtype) Part2(PartSubtype) x—> Doc3(Subtype of DocSubtype) Part2 (Part) x—> Doc3(subtype of doc) |
> or Organizations 
> . You might create relationship constraints in the Type and Attribute Management utility that do not carry forward to the end-user user interface until you modify this preference.
