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 following associations are supported for missing object functionality:
• Part — Markup
• Part — Representation
• Variance — Changeable
• Change Activity — Changeable (affected data, resulting data, hanging changes)
• Change Request — Changeable (relevant product data)
• Change Request — Variance
• Change Request — Change Notice
• Change Request — WTPartMaster (subject product)
• Variance — WTPartMaster (relevant product)
• FlexibleChangeItem — FlexibleChangeItem (flexible change links)
• Document — Document (dependency)
• Document — DocumentMaster (usage - only missing for child role)
• CAD Document — Part
• CAD Document — CAD Document Master (usage - only missing for child role)
• CAD Document — CAD Document Master (references link)
• CAD Document — CAD Document Master (variant link)
• Part — Part Master (usage - only missing for child role)
• Part — Document (describes link)
• Part — DocumentMaster (references link)
• Part Master — Part Master (alternates)
• Part Usage — Part Master (substitutes)
• Configurable links (masters, revision, references, describes)
• Part — CAD Document (note)
Missing objects handling for change activity-changeable association
For change activity (CA) and changeable (C) association, the change notice (CN) and change activity are considered for missing object processing with its associated changeable.
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 |
CN — CA1 — C | |
CN — CA2 — C | CA2 is recorded as missing for both CN and C. |
