Windchill Replication — Out Of Context Collection & Missing Objects
While using Windchill context replication, problems arise with highly structured data where object-to-object relationships could cross out from the context being replicated to objects in other contexts that are not being replicated. In such a case, the default behavior is to truncate the relationships at the context boundary so that only objects within the context are included in the package for replication.
The behavior of the context replication can be changed to trace cross-context relationships and include the additionally collected objects in the replication package by using the following properties:
|
Name
|
Description
|
Default Value
|
|---|---|---|
|
com.ptc.windchill.wp.rep.enableOutOfContextCollection
|
Controls the collection of linked objects outside of the replicated context.
|
false
|
|
com.ptc.windchill.wp.enableMissingObjectTrackingSource
|
Controls the tracking of missing objects on the source system.
|
false
|
|
com.ptc.windchill.wp.enableMissingObjectTrackingTarget
|
Controls the tracking of missing objects on the target system.
|
false
|
Property enableOutOfContextCollection — Logic
When the com.ptc.windchill.wp.rep.enableOutOfContextCollection property is enabled for an object, and a part or CAD document in the context has links outside of the context, the following collection logic is used:
For each part version in the replication context, a collection gathers the following:
• All child (uses) part dependents using configuration specification LATEST.
• All documents related to the seed object or its dependents.
• All change objects related to the seed object or its dependents.
• All replacement parts related to the seed object or its dependents.
For each CAD Document version in the replication context, a collection gathers the following:
• All child (uses) CAD Document dependents using configuration specification LATEST.
• All change objects related to the seed object or its dependents.
• All Drawings, Family Tables, Generics and Published Content.
 |
Nothing is collected for replication package members, which are not parts or CAD documents.
|
For collected dependents, the latest iteration of each released revision and the latest iteration of any un-released revisions are included in the collection. For example, assume a part has the following versions:
• A.1 (Released)
• B.1 (In Work)
• C.1 (Released)
• D.1 (In Work)
• D.2 (In Work)
• E.1 (In Work)
• E.2 (In Work)
The following versions are collected:
• A.1 (Released)
• B.1 (In Work)
• C.1 (Released)
• D.2 (In Work)
• E.2 (In Work)
|
|
• The additional related objects (non-child objects) are collected only from those objects which are selected via the initial configuration specification (LATEST). They are not collected from subsequently gathered versions.
For example, if Part B revision 2 of a child part is selected by the configuration specification LATEST, then the collector gathers change objects, documents that are related to Part B revision 2. If Part A revision 2 of the part is RELEASED then it is included in the package but it’s related objects (change objects, documents etc.) are not included in the package.
• Standard access control is applied during collection so only objects accessible to the person performing the refresh are collected.
|
Collection Logic Examples
Example 1:
REL — Released, IW — In Work
The result of collection is as follows:
Object | Collected version | Missing Object | Comments |
|---|---|---|---|
Part 1 | A | Seed object | |
Part 2 | C | Included via LATEST configuration specification | |
Part 2 | B | Prior released version is included but not collected | |
Part 2 | A | Prior released version is included but not collected | |
Part 3 | None | Y | Not collected from Part 2 rev A |
Part 4 | None | Y | Not collected from Part 2 rev B |
Part 5 | A | Included via LATEST configuration specification | |
Part 6 | A | Included via LATEST configuration specification | |
Part 7 | None | Not collected because parent is not included | |
Part 8 | None | Not collected because parent is not included | |
Part 9 | None | Not collected because parent is not included | |
Part 10 | None | Not collected because parent is not included |
If configuration specification of LATEST is used, Part 2 revision C is collected along with Part 5 and Part 6. Prior released revisions of Part 2 are also included (but not collected from). Part 3 is marked as missing under Part 2 revision A, and Part 4 is marked missing under Part 2 revision B.
If configuration specification of LATEST RELEASED is used, Part 2 revision B, Part 4 revision A and Part 9 are collected. Their later unreleased revisions are also included (but not collected from). Part 3 is marked as missing under Part 2 revision A, Part 5 and Part 6 are marked as missing under Part 2 revision C, and Part 10 is marked as missing under Part 4 revision A.
In either of the above scenarios, Part 7 and Part 8 are second level associations which are never encountered (either included or marked as missing).
Example 2:
The result of collection is as follows:
Object | Included | Missing Object | Comments |
|---|---|---|---|
Part 1 | Y | Included in replicated context | |
Part 2 | Y | Included via configuration specification | |
Part 3 | Y | Included via configuration specification | |
Part 4 | Y | Included via configuration specification | |
Document 1 | Y | Related to part 2 | |
Document 2 | N | Y | Document-document relationship not traced |
Document 3 | Y | Related to Part 3 | |
Document 4 | N | Y | Only Part & CAD relationships traced across contexts |
Change Request 1 | Y | Related to Part 1 | |
Change Request 2 | N | Y | Document-Change relationships not traced |
Change Request 3 | Y | Included in replicated context |
Example 3:
The result of collection is as follows:
Object | Included | Missing Object | Comments |
|---|---|---|---|
Part 1 | Y | ||
Part 2 | Y | ||
Part 3 | Y | ||
Part 4 | N | Y | |
Part 5 | Y | ||
Document 0 | N | N | |
Document 1 | N | Y | |
Document 2 | Y | ||
Document 3 | Y | ||
Document 4 | N | N | |
Change Request 1 | Y | Y | |
Change Request 2 | N | Y |
Property enableMissingObjectTrackingSource — Details
When the property com.ptc.windchill.wp.enableMissingObjectTrackingSource is enabled, missing objects for a replication package delivery are computed, included in the delivery zip and stored for retrieval later.
Points to remember:
• Missing object information is included in the zip for replicable objects which are exported and included in the zip.
• In case of incremental deliveries, no missing object information is included for objects which are not being exported. Objects are not included if they have been already replicated earlier or if they are not accessible to replicate.
• Missing object information is for replicable objects which are not getting replicated and are linked to objects which are getting replicated and included in the zip.
• The Missing Object Link Name and Missing Object Role Name columns in the Missing Objects table provides information about the relationship between the missing objects and the source objects included in the package.
The following associations are supported for missing object functionality:
Link Name | Role A (Parent) | Role B (Child) |
|---|---|---|
FormalizedBy | Deprecated in Fox | Deprecated |
AddressedBy2 | ||
TheMarkUpTheViewable | ||
Representation | ||
WTDocumentDependencyLink | Describes | Described By |
WTDocumentUsageLink | Used By | Uses |
EPMBuildRule | Build Source | Build Target |
WTPartUsageLink | Used By | Uses |
WTPartReferenceLink | Referenced By | References |
WTPartDescribeLink | Describes | Described By |
ReportedAgainst | Change Issue | Changeable2 |
AffectedActivityData | Change Activity2 | Changeable2 |
RelevantRequestData2 | Change Request2 | Changeable2 |
ChangeRecord2 | Change Activity2 | Changeable2 |
SubjectProduct | WTPart Master | Change Request2 |
ProblemProduct | WTPart Master | Change Issue |
WTPartAlternateLink | WTPart Master | WTPart Master |
SubstituteLinkDependencyProcessor | WTPart Master | WTPart Usage Link |
HangingChangeLink | Change Activity | Changeable |
FlexibleChangeLinkDependencyProcessor | ||
EPMMemberLink | ||
EPMReferenceLink | ||
NoteHolderNoteLink | ||
ConfigurableDescribeLink | Described By | Describes |
ConfigurableMastersLink | Traced By | Traces |
ConfigurableReferenceLink | Referenced By | References |
ConfigurableRevisionLinkCustomProcessor | Linked From | Linked To |
Missing Objects Handling for Change Activity-Changeable Association
For change activity (CA), change request (CR) and changeable (C) association, the change notice (CN) and change activity are considered for missing object processing with its associated changeable.
Usecase 1
One Change Activity missing for Change Notice and Changeable (Part)
• Create Part1 and Part2.
• Create Change Request for this Part1
• Create Change Notice for the Change Request.
• Change Task >> Add Part2 as Affected Object.
• Change Notice >> Implementation Plan >> Add Change Task2 and add Part2 as Affected Object.
• Set Change Task2 lifecycle state to “Under Review”.
• Create missingchangeuser and absolute deny read permission for Change Task and state as “Under Review”.
• Create replication package using missingchangeuser
Result:
Source Object | Missing Object |
|---|---|
Change Notice | Change Task2 |
Part | Change Task2 |
When there are multiple changeable associations linking same changeable to same change notice the changeable/change notice are not recorded as missing objects for the second change activity. Only the change activity is recorded as missing object.
Scenario | Result |
|---|---|
CR — C (Part1) CR — CN — CA1 — C (Part2) | |
CR — CN — CA2 — C (Part2) | CA2 is recorded as missing for both CN and C. |
Usecase 2
Change Notice and Change Task missing for Changeable (Part)
• Create Part.
• Create Change Request for that Part.
• Create Change Notice for the Change Request.
• Go to the Change Task and add part as Affected Object
• Move Change Notice to other context. Change Task will also move to other context.
• Create a replication package
Source Object | Missing Object |
|---|---|
Part | Change Notice |
Part | Change Task |
When a Change Task and Change Notice is created for a Changeable (part) and if the Change Notice is moved to other context, the Change Task also moves to the other context. Here, the Change Notice and Change Task is recorded as the missing object for the part.
Scenario | Result |
|---|---|
CR — CN — CA – C | |
CR — CN — CA – C | Both CA and CN are recorded as missing for C |
Usecase 3
Change Task missing for Changeable (Part) and Change Notice
• Create Part.
• Create Change Request for that Part.
• Create Change Notice for the Change Request.
• Go to the Change Task and add part as Affected Object.
• Create missingchangeuser and absolute deny read permission for Change Task.
• Create replication package using missingchangeuser
Source Object | Missing Object |
|---|---|
Change Notice | Change Task |
Part | Change Task |
When a Change Task is linked to a Changeable (part) and Change Notice, but the permission to read are denied for the Change Task, then over replication the Change Task is recorded as the missing object for the Part as well as the Change Notice.
Scenario | Result |
|---|---|
CR — CN — CA – C | |
CR — CN — CA – C | CA is recorded as missing for C and CN |
Usecase 4
Change Task and Changeable(Part) missing for Change Notice
• Create Part1 and Part2.
• Create Change Request for this Part1
• Create Change Notice for the Change request.
• Go to the Change Task and add Part2 as Affected Object
• Move part2 to another context
• Create replication package
Source Object | Missing Object |
|---|---|
Change Notice | Part |
Change Notice | Change Task |
When there are multiple Changeable (Part) associations linked to same Change Notice and Change Request, the Changeable and Change Request are recorded as missing objects for the Change Notice.
Scenario | Result |
|---|---|
CR — C (Part1) | |
CR — CN — CA — C (Part2) | CA and C (Part2) is recorded as missing for CN. |
Usecase 5
Changeable(Part) missing for Change Notice and Change Task
• Create Part1 and Part2.
• Create Change Request for that Part1.
• Create Change Notice for the Change Request.
• Go to the Change Task and add Part2 as Affected Object
• Move part2 to another context.
• Create replication package
Source Object | Missing Object |
|---|---|
Change Notice | Part2 |
Change Task | Part2 |
When there are multiple Changeable (Part) associations linked to same Change Notice and Change Request, the Changeable (Part2) is recorded as missing objects for the Change Activity and Change Request.
Scenario | Result |
|---|---|
CR — C (Part1) | |
CR — CN — CA — C (Part2) | C (Part 2) is recorded as missing for both CN and CA. |
Usecase 6
Change Notice missing for Change Task and Changeable(Part)
• Create Part1 and Part2.
• Create Change Request for this Part1.
• Create Change Notice for the Change request.
• Go to the Change Task and add Part2 as Affected Object
• Create missingchangeuser and absolute deny read permission for Change Notice.
• Create replication package using missingchangeuser
Source Object | Missing Object |
|---|---|
Part2 | Change Notice |
Change Task | Change Notice |
When there are multiple Changeable (Part) associations linked to same Change Notice and Change Request, the Change Notice is recorded as missing object for the Change activity and Changeable (Part 2).
Scenario | Result |
|---|---|
CR — C (Part 1) | |
CR — CN — CA — C (Part 2) | CN is recorded as missing for both CN and C (Part 2). |
| | To execute usecase 1 and 3, enable DisableAccessControlOnLinkExport of replication package in WPTypeBasedPropertyLoader. |
Missing Objects Handling for Substitutes Link
Usecase 1
• Create a Part1 in Context A.
• Create two parts Part2 and Part3 in Context B.
• From Context A, add Part2 as the child of Part1 and create Part3 as the substitute of the Part2.
• Check-in Part as required.
• Create replication package of Context A.
• Missing object tab of Context A will show relation between Part1 <-> Part2. (This relation is due to WTPartUsageLink).
• Create replication package of Context B.
• Missing object of Context B will not show any missing object.
Usecase 2
• Create two parts — Part1 and Part2 in Context A.
• Create a Part3 in Context B.
• From Context A, add Part2 as the child of Part1 and create Part3 as the substitute of the Part2.
• Check-in part as required.
• Create replication package of Context A.
• Missing object tab of Context A will show relation between Part2 <-> Part3. (This relation is due to WTPartSubstituteLink).
• Create replication package of Context B.
• Missing object of Context B will not show any missing object.
| | Following links are child only links and therefore missing object will be reported only if child of these links are in another context and the replication package is created on the parent context. • WTPartUsageLink • WTDocumentUsageLink • EPMMemberLink |
| | When a substitute part, that has a usage relationship with a parent part, is missing on the source server, the Missing Object table shows the role name of the missing object in the following format: • Source server: Substitutes -> Identity of parent part • Target server: Substitutes -> Identity of child part The identity of a part includes the part number, part name, organization, version, and view. Consider the following example: Parent A.1  Child A.1  Substitute A.1The Missing Object Role Name column in the Missing Objects table shows the following details: • Source server: Substitutes > 000002, Parent, Demo Organization, A.1 (Design) • Target server: Substitutes > 000005, Child, Demo Organization, A.1 (Design) |
Missing Object Handling for Alternate Link
Usecase 1
• Create a Part1 in Context A.
• Create two parts — Part2 and Part3 in Context B.
• From Context A, add Part2 as the child of Part1 and create Part3 as the alternate of the Part2.
• Check-in part as required.
• Create replication package of Context A.
• Missing object tab of Context A will show relation between Part1 <-> Part2. (This relation is due to WTPartUsageLink).
• Create replication package of Context B.
• Missing object of Context B will not show any missing object.
Usecase 2
• Create two parts — Part1 and Part2 in Context A.
• Create a part3 in Context B.
• From Context A, add Part2 as the child of Part1 and create Part3 as alternate of the PartB.
• Check-in part as required.
• Create replication package of Context A.
• Missing object tab of Context Awill show relation between Part2 <-> Part3. (This relation is due to WTPartAlternateLink).
• Create replication package of Context B.
• Missing object tab of Context Awill show relation between Part3 <-> Part2. (This relation is due to WTPartAlternateLink).