Importing Incremental Received Delivery Files

Data Management Capabilities > Using Packages to Import and Export Data for Offline Collaboration > Import Received Delivery > Importing Incremental Received Delivery Files

If you have received more than one package delivery ZIP file from a source system, it is possible that the sender chose to send you an incremental delivery from what was previously delivered. The process to import incremental received delivery files is identical to the process to import full received delivery files. There are, however, two additional aspects to consider:

• Additional information contained in an incremental delivery

• The order in which received delivery files are imported

In some situations, you may receive a subsequent delivery from the same source system with updates to content that was previously delivered. You may receive a full delivery with all content that was previously delivered, or you may receive an incremental delivery with only information that has changed since the previous delivery. For example, if your company is collaborating with another company and you need to know about any modifications to their assembly, you could request regular updates to keep up with the modified data.

Unlike a full delivery, an incremental delivery is compared against a base delivery. This comparison allows an incremental delivery the unique opportunity to send information about objects that meet one of the following criteria:

• Deleted: Information about objects that have been removed from Windchill since the base delivery is sent so the same objects can be removed from the target system. During import, the system attempts to remove these same objects. Any objects that cannot be removed are reported.

• Absent: Information about objects that were sent in the base delivery but are no longer included in the current delivery because they were not included in the package. Possible reasons for exclusion may be that the collection options used to create the package have changed, the object may no longer meet the criteria, or the object was explicitly removed from the package. The preview and import reports on these objects as you may want to take further action on the objects, depending on your business process. For example, you can remove them from your system, move them to another context, or set a new life cycle state.

• Changed: Objects that have been modified in some way are sent. A change could be an update to a content file, modification to an attribute, moving the object to a new folder, and so on.

• New: Objects that are new in Windchill or are included in the package for the first time are sent.

Incremental deliveries do not contain information about objects that are unchanged since the base delivery. Changed objects encompass both change initiated by the user and system level changes.

Incremental deliveries also carry the changed information about the association between a CAD document and a WTPart. Here is an exception when the change in association information is not shown clearly.

Consider a WTPart with image that is associated with a CAD document and is checked in to Windchill without build (Build Part After Associate preference or the Set for Single-Level Build option set to Off). If a package is made of these objects, when importing an incremental package after removing the association (See, Editing the Association of CAD Documents and Windchill Parts) to Windchill, the association removal between the WTPart and the CAD document is not clean.

As incremental deliveries are created on the source system by selecting a base delivery from which changes are assessed, there is often a dependency between the two deliveries. It is always a best practice to import the received delivery ZIP files in the same order as the files were exported, but it is more important for an incremental delivery. For more information, see the section Best Practices for Importing Received Delivery Objects in Best Practices for Working with Received Deliveries.

Managing Attributes for Incremental Delivery

In certain business scenarios, you may want the incremental delivery logic to ignore the changes in specific attributes during a comparison with the baseline delivery. The updated incremental delivery logic provides an efficient mechanism for Windchill packages to include and export only the relevant objects that have changed since the previous delivery.

Example scenario 1

Consider the following example, where the base package includes two parts Part 1 A.1 and Part 2 A.1. There is a change in Part1 A.1, and it is changed to Part 1 A.2, and additionally the container description (product/library) is changed. As the container contributes to the Part metadata that is exported, the container is considered as an embedded object. Change in description of the container as a changed object and that pulls in all the objects that are contained in the container as changed i.e., in this Part1 A.1 and Part1 A.2 even though the metadata exported is not changed when compared to the base delivery. The delta calculation logic is further hardened to pay attention as well to the metadata exported. Therefore, the resulting package will export only Part 1 A.2 as Part1 A.1 exported metadata remains unchanged as shown in the table below.

Source	Base delivery	Incremental Delivery
Part 1 A.1 Part 2 A.1	Part.1 A.1 + Part 2 A.1 Change: Part 1 A.1 –> Part 2 A.2	Part 1 A.2 — delta

Example scenario 2

Consider another example, where the base package mentioned in the previous example includes an additional part, a third part say, Part3 A.1 with the attribute LifeCycle1 (LC1) which was added by a user say, User1. At some point of time if the LifeCycle1 attribute in the third part was modified by another user say User2, to LifeCycle2 (LC2), typically, the incremental delivery will contain the changes pertaining to Part1 A.1 –>Part1 A.2 and the Part3 A.1 –>LC1 to LC2.

Source	Base delivery	Incremental Delivery
Part 1 A.1 Part 2 A.1	Part.1 A.1 + Part 2 A.1 Change: Part 1 A.1 –> Part 2 A.2 Part 3 A.1 –> LC1 to LC2	Part 1 A.2 Part 3 LC2

Although, the system generates the incremental delivery by comparing all changed contents to the base delivery, you can also influence the incremental delivery logic to ignore an attribute during export.

To control the information that is exported in an incremental delivery according to your business processes, you can set specific preferences using the customizable properties in the package type-based properties XML file.

The <elementName> tag provided OOTB (Out Of The Box) within the type-based properties sets in the WPTypeBasedPropertiesLoad.xml file, allows you to specify the attributes that should be ignored when an incremental delivery is compared to the baseline delivery.

<XMLFilterTags>

</XMLFilterTags>

Following is an example of the code to be added in WPTypeBasedPropertiesLoad.xml file:

<WPTypeProperties typeId="com.ptc.windchill.cp.rep.ReplicationPackage">
.
.
.
<XMLFilterTags>
<elementName>lifecycleInfo</elementName>
<XMLFilterTags>
</WPTypeProperties>

In the sample type-based properties file above, the lifecycleInfo attribute is excluded from the criteria that determines the comparison between the incremental and baseline deliveries.

In our example scenario 2, specifying lifecycleInfo would result in the Part3 A.1 change being ignored during the export in incremental delivery as the entire lifecycleInfo tags and all nested attributes within will be ignored.

<lifecycleInfo>
<lifecycleTemplateName>Basic</lifecycleTemplateName>
<lifecycleState>INWORK</lifecycleState>
<objectHistory><lifeobjectHistory>
<ObjectID><localId>wt.lifecycle.LifeCycleHistory:170223<localId></ObjectID>
<action>Enter_Phase</action>
<actorPrincipal><WTPrincipalReference.classType="wt.org.WTUser".fullName="Demo, User" isInternal="false" surname="Demo" .userEmail="demouser">
<ufid>uid=demo,o=narwhal145_ptms0ld,o=ptc|Ldap.ptcnet.ptc.com|Ldap.ptcnet.ptc.com</ufid>
<name>demo</name>
</WTPrincipalReference></actorPrincipal>
<lifeCycleName>Basic 1</lifeCycleName>
<phaseName>In.Work</phaseName>
<state>INWORK</state>
<teamTemplateIdentity> <teamTemplateIdentity>
<createStamp>1662546309000</createStamp>
<modifyStamp>166254309000</modifyStamp>
<lifeobjectHistory></objectHistory>
</lifecycleInfo>

The result would be as shown in the table below, where only the changes to Part 1 A.2 are exported in the incremental delivery now.

Source	Base delivery	Incremental Delivery
Part 1 A.1 Part 2 A.1	Part.1 A.1 + Part 2 A.1 Change: Part 1 A.1 –> Part 2 A.2 Part 2 A.1 Part 3 A.1 –> LC1 to LC2	Part 1 A.2

Once you have defined the elements in the XML file, you can load the file to bring the preferences to effect. You can set similar preferences for all Windchill packages and for other delivery options such as sync incremental deliveries.

For more information, see the Reading and Loading Type-Based Properties XML File section in Package Type-Based Properties.

Typically, the system only displays the package members in the Delivery Contents UI tab. The secondary or dependent objects are not displayed in UI. This is the reason the system shows primary members when associated secondary objects are changed and included in a Delivery zip in an incremental package

For example, WT Part is shown in the Delivery Contents UI tab for Representations update included in the delivery zip; or the EPM Document is displayed for the associated Family table; similarly, if there is update only in the AXL Entry for Manufacturer/Vendor/OEM part then associated WT Part is displayed in Delivery Contents UI tab.

Was this helpful?