Best Practices for Working with Received Deliveries

• 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.

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.

• 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.

• 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:

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.

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.

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 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.

• 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.

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.