导入收到的增量交付文件

数据管理功能 > 使用包针对离线协作导入和导出数据 > 导入收到的交付 > 导入收到的增量交付文件

导入收到的增量交付文件

如果您已从源系统收到多个包交付 ZIP 文件，则可能是发件人选取从先前交付的内容向您发送增量交付。收到的增量交付文件与收到的完整交付文件的导入进程相同。但是，有两个方面需要额外考虑：

• 增量交付中包含的其他信息

• 收到的交付文件的导入顺序

在某些情况下，您可能从同一源系统收到后续交付，其中包含先前交付内容的更新。您可能收到含有先前交付的所有内容的完整交付，或者收到只含自上次交付后已发生更改的信息的增量交付。例如，如果贵公司与另一公司合作，并且您需要了解对其装配的所有修改，则可请求定期更新以便与修改后的数据保持同步。

与完整交付不同，增量交付会与基本交付进行比较。此比较使增量交付有独一无二的机会来发送满足下列条件之一的对象的相关信息：

• 已删除：自发送基本交付以来从 Windchill 中移除的对象的相关信息，以便能够从目标系统中移除相同对象。在导入期间，系统尝试移除这些相同的对象。无法移除的所有对象都会被报告出来。

• 不存在：在基本交付中发送、但因不包括在包中而不再包含在当前交付中的对象的相关信息。可能的排除原因是，用于创建包的收集选项已发生更改、对象可能不再满足条件，或者已经从包中明确移除对象。您可能希望对其执行进一步操作的对象的预览和导入报告取决于业务流程。例如，您可以从系统中移除这些对象、将其移至另一上下文，或者设置新的生命周期状态。

• 已更改：会发送以某种方式修改的对象。更新内容文件、修改属性、将对象移至新文件夹等都可以算作变更。

• 新建：会发送在 Windchill 中新建或包首次包含的对象。

增量交付不包含在基本交付后未发生更改的对象的相关信息。变更的对象包括用户级别变更和系统级别变更。

增量交付还包含 CAD 文档与 WTPart 之间的关联的已更改信息。以下是关联信息中的变更未明确显示的例外情况。

请考虑一个 WTPart，其图像与 CAD 文档关联并在没有构建的情况下 (“关联后构建部件”首选项或“设置为单级构建”选项设为“关闭”) 被检入 Windchill。如果包是由这些对象组成的，则在移除与 Windchill 的关联 (请参阅编辑 CAD 文档与 Windchill 部件之间的关联) 后导入增量包时，WTPart 与 CAD 文档之间的关联不再有效。

由于增量交付是通过选择从中评估更改的基本交付而在源系统上创建的，因此这两种交付通常相关。按照与文件导出相同的顺序导入收到的交付 ZIP 文件始终均为最佳做法，但这对增量交付而言更重要。有关详细信息，请参阅处理收到的交付的最佳做法主题中的“导入收到的交付对象的最佳做法”部分。

管理增量交付的属性

在某些业务情景中，您可能希望增量交付逻辑能够在与基线交付进行比较的过程中忽略特定属性的变更。更新的增量交付逻辑为 Windchill 包提供了高效机制，以便仅包括和导出自上一次交付以来发生变更的相关对象。

示例情景 1

请看以下示例：其中基础包包含两个部件 Part 1 A.1 和 Part 2 A.1。Part 1 A.1 发生变更，即变更为 Part 1 A.2；此外，容器说明 (产品/存储库) 也有所变更。当容器构成导出的部件元数据时，容器被视为嵌入对象。将容器说明的变更视为已变更的对象，并将容器中包含的所有对象都视为已变更的对象引入，也就是说，在此 Part 1 A.1 和 Part 1 A.2 中，即使在与基本交付进行比较时导出的元数据不发生变更，情况也是如此。此外，还会进一步强化增量计算逻辑，以关注导出的元数据。因此，产生的包将仅导出 Part 1 A.2，因为 Part 1 A.1 导出的元数据没有变更 (如下表所示)。

源	基本交付	增量交付
Part 1 A.1 Part 2 A.1	Part 1 A.1 + Part 2 A.1 变更: Part 1 A.1 –> Part 2 A.2	Part 1 A.2 - 增量

示例情景 2

请看另一个示例：其中上一示例中所述的基础包包含其他部件，即第三个部件 Part 3 A.1，其属性 LifeCycle1 (LC1) 是由用户 User1 添加的。在某一时间点，如果第三个部件中的 LifeCycle1 属性已由另一用户 User2 修改为 LifeCycle2 (LC2)，则增量交付将包含与 Part 1 A.1 –> Part 1 A.2 和 Part 3 A.1 –> LC1 至 LC2 相关的变更。

源	基本交付	增量交付
Part 1 A.1 Part 2 A.1	Part 1 A.1 + Part 2 A.1 变更: Part 1 A.1 –> Part 2 A.2 Part 3 A.1 –> LC1 至 LC2	Part 1 A.2 Part 3 LC2

尽管系统会通过比较所有变更内容与基本交付来生成增量交付，但您也可以在导出期间通过影响增量交付逻辑来忽略属性。

要根据业务流程控制增量交付中导出的信息，您可以使用基于包类型的特性 XML 文件中的可自定义特性来设置特定首选项。

WPTypeBasedPropertiesLoad.xml 文件中基于类型的特性集内预设提供的 <elementName> 标记可用于指定在将增量交付与基线交付进行比较时应忽略的属性。

<XMLFilterTags>

</XMLFilterTags>

以下是要在 WPTypeBasedPropertiesLoad.xml 文件中添加的代码的示例：

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

在上述基于示例类型的特性文件中，从用于决定增量交付与基线交付之间的比较的条件中排除 lifecycleInfo 属性。

在示例情景 2 中，如果指定 lifecycleInfo，则会导致在增量交付的导出过程中 Part 3 A.1 的变更被忽略，因为整个 lifecycleInfo 标记及其内部的所有嵌套属性都会被忽略。

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

结果如下表所示，现在只有 Part 1 A.2 的变更在增量交付中导出。

源	基本交付	增量交付
Part 1 A.1 Part 2 A.1	Part 1 A.1 + Part 2 A.1 变更: Part 1 A.1 –> Part 2 A.2 Part 2 A.1 Part 3 A.1 –> LC1 至 LC2	Part 1 A.2

在 XML 文件中定义元素后，即可加载该文件以使相关的首选项生效。您可以为所有 Windchill 包和其他交付选项 (例如同步增量交付) 设置类似的首选项。

有关详细信息，请参阅基于包类型的特性主题中的“读取和加载基于类型的特性 XML 文件”部分。

通常，系统仅在“交付内容”UI 选项卡中显示包成员。次要或依存对象不会显示在 UI 中。因此，当关联的次要对象发生变更并包含在增量包的交付 zip 文件中时，系统会显示主要成员。

例如，在交付 zip 文件所含“表示”更新的“交付内容”UI 选项卡中显示 WT 部件；或为关联的族表显示 EPM 文档；同样，如果仅在制造商/厂商/OEM 部件的 AXL 条目中进行更新，则关联的 WT 部件会显示在“交付内容”UI 选项卡中。

这对您有帮助吗?