Best Practices for Working with Received Deliveries
Best Practices for Uploading Received Delivery Files
Uploading a received delivery is the required first step toward importing a package ZIP file or files.
• If the ZIP files you received are large, upload speed can be improved by saving the ZIP files on the Windchill server and selecting the Attach new external storage option 
.
.• If your Windchill server is in a cluster environment, ensure that the received ZIP files are available from all cluster layers.
• It is advisable to review any manifest file or offline viewer provided by the sender. To review the offline viewer, the ZIP files should be extracted on the file system prior to import. The original ZIP file is required for upload. To review the manifest file, the ZIP file or files should be uploaded and the manifest reviewed from the received delivery.
Best Practices for Using Mapping Definitions
Mapping definitions are a useful tool for translating source system information into something that is valid on the target system. Mapping definitions can provide translation from attributes that are provided as guidance (such as context, folder, and life cycle template) as well as attributes that have significant business importance that are administered locally to a system (such as owning organization, life cycle state, and security labels).
• Use the Preview Received Delivery Import action to establish the mapping definitions prior to importing received delivery data.
• Use preview and mapping definition in parallel so that you can copy information directly from the preview window into the source system information within the mapping definition.
• Consider and address type definition, attribute definition, and versioning scheme definition mismatches prior to establishing mapping definitions.
◦ Consider whether it is more efficient to add the information from the source system directly to your configuration (for example, creating a folder with the same name) or to define a mapping.
◦ Life cycle template mapping is recommended as it represents the business process the object follows once it is imported. As it is rarely desirable to have the object follow the same business process on the target system as it is undertaking on the source system, it is a best practice to define a mapping to life cycle template that does not initiate a workflow process on the objects.
▪ Map to a basic life cycle template representation of the source system when you want to maintain a correlation to the source system life cycle template or simply use a basic life cycle for information imported from the sending system.
▪ Limit mapping to advanced life cycle templates to just those cases where a workflow should be initiated on the imported object.
▪ When using an advanced life cycle, it should be associated with a workflow process that does not introduce change to the object as any changes on the target system are overwritten if the object is imported again.
• If possible, avoid making mapping changes after importing the first received delivery from a particular source system. Changing the mapping definitions could result in data organization issues.
• Use the text available from the Source Value field in the Context Related Information section of the Preview Received Delivery Import window to populate the source system information for mapping attributes.
• The user who defines the mapping should have the appropriate authorization to the relevant objects in the system, such as the folder location, life cycle template, and so on.
• Review the mapping definitions on a regular basis to remove or change incorrect or obsolete mapping definitions.
• Save your changes on each tab to ensure that data is not lost.
• Use the Preview Received Delivery Import action and the Define Mapping action in parallel as it will allow you to copy information from the Preview Received Delivery Import window and paste it into the source system information in the appropriate mapping definition.
Best Practices for Version Mapping
The decision to implicitly map or retain the version information from the source system is a critical decision because version information represents critical business information.
• When version information should be retained from the source system, the target system must also include the definition of the same version schemes for file-based and state-based revision series. For more information, see Object Numbering and Versioning.
• It is recommended that the object versioning properties configured in the target system match the properties configured in the source system.
• Before importing a package, determine the versioning scheme available in the source system. It is not recommended to change the versioning scheme after replicating data as it may result in unpredictable outcome or conflicts during future imports.
• Verify that the configuration for version mapping is set correctly using the Import Received Delivery or Preview Received Delivery Import dialog box before starting an import.
• When the source system uses file-based or state-based series with historical definitions, it is recommended to use the version information from the source system without implicit mapping.
For more information on version mapping, see Defining Received Delivery Version Mapping.
Best Practices for Importing Received Delivery Objects
• Received delivery import performance can be controlled using several properties. The properties control how received deliver import is managed. The import can be handled sequentially or by using transactions or threads. The following properties can be set to maximize performance:
◦ wt.ixb.import.noOfParallelImportPaths: sets the number of transactions used for parallel import.
Using multiple transactions can benefit received delivery import performance because a partially successful import is possible if there are any issues during import. The objects imported as part of any successful transactions are available to authorized users. Unsuccessful transactions can be re-attempted after adjustments are made. By default, this property is set to 1. If the wt.ixb.tag.apply.TransactionTag.enableCount property is set to more than 75000, this property is set to 4.
◦ wt.ixb.tag.apply.TransactionTag.enableCount: sets the threshold for dividing into multiple transactions based upon the number of objects in the received delivery files.
If your site uses more than one transaction to import received delivery files, you must set a value for this property to determine the maximum number of objects that can be in each transaction. The value is measured in the number of objects contained in a delivery file, excluding links between objects. For example, if you set the value to 3000 and the delivery contains 5500 objects, the import will be divided into two transactions. By default, this property is set to 75000.
◦ wt.ixb.import.maxThreads: sets the number of threads used within a transaction.
Using multiple threads has the most significant impact on received delivery import performance. The threads share the same database connection, which can impact performance if the threshold is reached. The number of objects can also impact performance; the greater the number or objects, the greater the performance improvement when using multiple threads. In general, one thread will be sufficient for incremental package deliveries. An initial package delivery may benefit from multiple threads, particularly if the import time window is small. By default, this property is set to 1.
 | The value of the wt.ixb.import.maxThreads property is used in conjunction with the wt.ixb.import.noOfParallelImportPaths property, which determines the number of transactions used for import. • Single Transaction Scenario: If the wt.ixb.import.noOfParallelImportPaths property is set to 1, the value of the wt.ixb.import.maxThreads property is the total number of threads used for import. • Multiple Transaction Scenario: If the value of the wt.ixb.import.noOfParallelImportPaths is set to more than 1, the value of the wt.ixb.import.maxThreads property is the number of threads used per import transaction. |
◦ wt.ixb.import.batchSize: sets the batch size for a thread.
Batch size has lower impact on received delivery import performance. The property can be set to determine the number of objects in each import batch. By default, this property is set to 10000.
• Use the same Import Into option during import as you selected in the Preview Received Delivery Import window.
• Use the Save the latest resolutions provided by you during this import process option when importing to save the resolutions as it allows you to reuse these choices in the future when importing another received delivery from the same source system.
• Select the Use the previously saved resolutions option when importing to reuse previously saved resolutions.
• Review the import summary report after successful completion of a received delivery import.
• Received delivery import is handled using RDImportExecutorQueue. For more information, see Out-of-the-box Background Queues.
• After a received delivery import succeeds, the uploaded ZIP files associated with the delivery can be removed to improve archiving performance. The com.ptc.windchill.rd.cleanupFilesOnSuccessfulImport property can be set to True to automatically remove ZIP files when the import succeeds.
Best Practices for Reviewing Received Delivery Log Files
Log files are available from a received delivery information page with details about what was discovered during the preview and import actions. You can use these log files to investigate warnings and errors encountered during the import process, identify which objects and links were imported, and find out which objects imported with conflicts or were skipped due to conflicts. For more information, see Reviewing a Received Delivery Import Log.