Best Practices for Working with Packages
Best Practices for Collecting Objects into a Package
Windchill packages that are used for external collaboration gather package contents based upon how the objects are related. These packages start with one or more initially selected objects, apply the collections rules to it, and collect the related objects together to form the package contents.
• Use the collector to gather objects rather than including all objects in the initially selected objects table.
• If multiple versions of the same initially selected object are used for collection, then use multiple managed collections to establish the collection options on each version of that object.
• Set the collection rules to collect all dependent objects to ensure that no essential objects are left out of the package.
• Use a managed collection as an initially selected object for complex collection scenarios. There may be a situation where different collection rules should be applied for different initially selected objects or collection rules would result in multiple versions of the same object being collected into the package. Each managed collection can have its own collection rules.
Best Practices for Working with Large Packages
Windchill packages are not limited to a specific size. However, as the number of objects in the package contents increases there are some recommendations strictly related to working with packages that include over 2,000 objects.
• If your package will collect over 60,000 objects, your system administrator should set the
com.ptc.core.collectionsrv.engine.limitDependencyTracing property to an appropriate value. For more information, see
Workspace Page Functionality.
• For sites working with packages containing a large number of objects, view the package or managed collection contents as a list rather than as a tree. While the tree view provides better navigation into managed collections contained in a package, the tree view does not readily support large numbers of objects. Using a list provides the ability to page through the package or managed collection members. You can use a separate window from the list view to view the contents of a nested managed collection. To enable packages and managed collections to be viewed as a list, set the ShowPackageContentsTableAsTree property to true. By default, the Content table for a package displays members in a tree view.
• For replication packages with a large number of objects, your site administrator can set the following properties to improve export performance:
◦ wt.ixb.export.maxThreads: Sets the maximum number of threads used for export. If there are fewer objects, the number of threads decreases accordingly. The recommended number of threads is two.
◦ wt.ixb.export.objPerThreadGuidance: Sets the number of objects included in each thread.
Best Practices for Filtering Objects in a Package
When applying filters, consider the data you have collected. Make sure you are not filtering out objects that are required to accurately display the information on the source system. This is particularly applicable to structures, baselines, and change objects. Be aware of special CAD document relationships. For example, multiple members of a family table may be necessary to provide the desired design context on the target system.
Best Practices for Filtering Files to be Included in the Package ZIP File
Windchill packages provide several options for filtering the files that should be included in the ZIP file. The most common filter is by file extension. Site configurations can provide additional ways to filter the files.
When providing an Export Only formatted delivery, it is important that related files required by files in the package are included in the package as well. For example, if required files for a CAD document are not included, the recipient may not be able to load the CAD document in the appropriate authoring application.
When providing a PTC Windchill formatted delivery, system integrity of the imported object is an additional consideration. In many cases, there are no system integrity considerations (such as not sending all the attachments). Windchill integrity is not often impacted by whether or not attachments exist. In some cases, there are system integrity considerations in removing content files. For example, CAD files or representations cannot exist without their associated content. When excluding the contents for a particular object that would be included in a PTC Windchill formatted delivery, the default recommendation is to exclude the object itself in the event all content files would be excluded.
Best Practices for Creating a Package Delivery
The delivery is integral to the Windchill package process. There are two attributes on a delivery that have a significant impact on the ZIP file that is created: recipient and delivery medium. The recipient directly relates to the security options that are provided when the ZIP is created. The delivery medium drives the number of ZIP files created based upon the medium’s size limitation.
• If you want to apply the recipient’s
Windchill authorization to the delivery, make sure to select the participant using the find participant icon
rather than by manually entering the name of the user. Consider, however, if the user has the appropriate authorization to view all of the objects included in the package. If they do not, you may not want to apply their security authorization to the delivery. If you do not apply their security authorization, the user may be given access to objects that they may not otherwise have been granted access.
• If your site has security labels enabled and you are sending to a participant who is not a Windchill participant, be sure to apply the security labels to the delivery appropriate for distribution to the recipient. If the package includes objects without the security labels specified by the ZIP file creator, they are excluded from the ZIP file.
• Select the delivery medium you intend to use to distribute the ZIP file or files. Make sure that the ZIP file size is set appropriately for your desired delivery mechanism using the > preference.
| In the event the Delivery Medium File Size preference does not exist for the selected delivery medium, the > preference is used. |
Best Practices for Locking a Package
If you are creating multiple deliveries from the same package, make sure your package content is appropriate for every delivery prior to locking the package. After the first delivery is sent, the package cannot be unlocked without creating a new iteration or revision.
Best Practices for Package File Synchronization
When you use authoring applications other than Creo Parametric, NX, SOLIDWORKS, CATIA V5, or Autodesk Inventor, consider either disabling CAD file synchronization or not distributing those files using packages. By setting the > preference to No, all CAD document objects will be included in the package delivery, regardless of where they were authored and without synchronization.
Best Practices for Creating an Importable ZIP file
The ability to create a PTC Windchill formatted ZIP file introduces additional considerations that do not apply to the export only format.
• Selecting the
Windchill importable format option when zipping the package delivery includes only supported objects in the ZIP file. Objects that are not supported for import into the
Windchill release level specified are not included in the final ZIP file. For a list of supported object types for each
Windchill release, see
Supported Objects for Windchill Importable Packages.
• Verify the target system Windchill version supports receiving Windchill importable packages.
• To ensure proper delivery of package information, work with the recipient to ensure that the two Windchill systems can exchange information. Considerations should be given to the following topics:
◦ Optional Products: When a package contains objects associated with a Windchill product, such as Windchill Supplier Management, the recipient’s system should also have this product installed.
◦ Type and Attribute Definitions: When a package contains subtypes and attributes that you created on your system, the recipient’s system should also contain these subtypes and attributes to import the package ZIP file.
◦ Mapping Definitions: Most objects contain information from the source system that can be mapped to translate between the source system values and those of the target system. These are intended to be used to facilitate exchange without changing the business intent of this information.
◦ Versioning Schemes: When a package contains objects using a versioning scheme created on your system, the recipient’s system should contain the same versioning scheme.
Best Practices for Creating a Package ZIP File in a Customized System
Windchill packages use the standard import and export capability of Windchill. When modeled customizations have been made and objects impacted by this modeled customization are included in a package, your customization also needs to account for the import and export customization. When using a PTC Windchill formatted ZIP file containing these objects, it also means the recipient’s system should support this customization.
For more information, see
Packages Customization.
Best Practices for Working with Full and Incremental Deliveries for Importable Packages
Full deliveries contain all objects present in the package, with the possible exception of objects excluded due to security considerations. Incremental deliveries are different from full deliveries. Incremental deliveries only include objects that have been added to the package or have changed since a selected base delivery. In addition, an incremental delivery provides information about objects that have been deleted or moved since the selected base delivery. If the incremental delivery is imported into another Windchill system and it contains information about deleted objects, a delete action is requested on the target system.
The ability to delete the object on the target system may be constrained due to the configuration of the target system. For example, a product structure is exported in a base delivery, and later one of the parts used in the structure is removed from the structure and then deleted. A subsequent full delivery of the package would contain the latest version of the structure, but the deleted part would still remain on the target system. But, an incremental delivery from the same base delivery would include information specifying that the part was deleted on the source system and request that the part be deleted on the target system during the import process.
In external collaboration, full deliveries are common and it may not be important to have any objects deleted on the source system also be removed on the target system. In internal collaboration scenarios using replication packages, keeping the target system synchronized with the source system, including deleting objects, is more important. Incremental deliveries delete the objects on the target that were deleted on the source since the base delivery. If a full delivery is sent for a subsequent version of the package, it is recommended to follow immediately with an incremental delivery that is based upon the previous incremental or base delivery to ensure object deletions are also communicated to the target system.
For example, a replication package A.1 is sent to another internal Windchill system. Multiple incremental deliveries are also delivered with each previous incremental delivery specified as the base delivery (incremental A.2 is based on A.1, incremental A.3 is based on A.2, and so on through A.7). If a full delivery is required, such as B.1, then it would be followed with another incremental delivery with the last incremental delivery specified as the base delivery (B.2 based on A.7). This pattern ensures that objects deleted between the replication package versions A.7 and B.1 are communicated to the target system.