差分受信送信物ファイルのインポート

データ管理機能 > パッケージを使用したオフラインコラボレーション用データのインポートとエクスポート > 受信送信物のインポート > 差分受信送信物ファイルのインポート

差分受信送信物ファイルのインポート

同じソースシステムから複数のパッケージ送信 Zip ファイルを受信している場合は、送信者が前回の送信からの差分送信物を送信する場合もあります。差分受信送信物ファイルをインポートするプロセスは、完全受信送信物ファイルをインポートするプロセスと同じです。ただし、次の 2 つの点に注意してください。

• 差分送信に含まれる追加情報

• 受信送信物ファイルをインポートする順序

状況によっては、同じソースシステムから、以前に送信されたコンテンツに対する更新を含む後続の送信を受信する場合があります。以前に送信されたすべてのコンテンツを含む完全送信を受信する場合と、前回の送信以降に変更された情報だけを含む差分送信を受信する場合があります。たとえば、ほかの企業とコラボレーションしているときに、パートナーのアセンブリに対する修正内容を知る必要がある場合は、定期的な更新をリクエストして修正されたデータで情報を最新に維持します。

完全送信と異なり、差分送信はベース送信と比較されます。この比較により、差分送信では次の基準のいずれかに一致するオブジェクトに関する情報を送信できます。

• 削除済み: ベース送信が送信された後に、Windchill から除去されたオブジェクトに関する情報。ターゲットシステムから同じオブジェクトを除去できます。インポート中に、システムはこれらの同じオブジェクトの除去を試みます。除去できないオブジェクトがある場合は報告されます。

• 存在しない: ベース送信で送信されたオブジェクトのうち、パッケージから除外されたために現在の送信に含まれていないオブジェクトに関する情報。除外の理由には、パッケージの作成に使用されるコレクションオプションが変更された、オブジェクトが基準を満たさなくなった、オブジェクトがパッケージから明示的に除去されたなどがあります。業務プロセスに応じて、オブジェクトにその他の対応が必要な場合は、プレビューやこれらのオブジェクトのインポートレポートを使用します。たとえば、システムからの除去、別のコンテキストへの移動、新しいライフサイクル状態の設定などが可能です。

• 変更済み: なんらかの方法で修正されたオブジェクトが送信されます。変更には、コンテンツファイルの更新、属性の修正、別のフォルダへのオブジェクトの移動などがあります。

• 新規: Windchill に新規作成されたオブジェクト、または初めてパッケージに含まれたオブジェクトが送信されます。

差分送信には、ベース送信以降に変更されていないオブジェクトに関する情報は含まれません。変更されたオブジェクトには、ユーザーによって開始された変更と、システムレベルの変更の両方が含まれます。

差分送信では、CAD ドキュメントと WTPart の間の関連付けについての変更された情報も保持されます。関連付け情報の変更が明確に表示されていない場合は、ここで例外が発生します。

CAD ドキュメントに関連付けられており、ビルドなし (「関連付けた後に部品を構築」プリファレンスまたは「シングルレベルビルドの設定」オプションを「オフ」に設定) で Windchill にチェックインされているイメージを含む WTPart について考えてみます。これらのオブジェクトでパッケージが作成されている場合、関連付けを除去した後に (CAD ドキュメントと Windchill 部品の関連付けの編集を参照) 増分パッケージを Windchill にインポートすると、WTPart と CAD ドキュメント間の関連付けの除去は完全ではありません。

差分送信は、ソースシステムで変更を評価する基準となるベース送信を選択して作成されるため、通常は 2 つの送信間に依存が存在します。最良事例として、受信送信物の Zip ファイルは常にファイルがエクスポートされたときと同じ順序でインポートしますが、差分送信ではこの点が特に重要となります。詳細については、受信送信物の処理のベストプラクティスの「受信送信物オブジェクトのインポートのベストプラクティス」のセクションを参照してください。

差分送信の属性の管理

一部のビジネスシナリオでは、ベースライン送信と比較する際に、差分送信ロジックで特定の属性の変更を無視する必要が生じることがあります。更新された差分送信ロジックは、以前の送信以降に変更された関連オブジェクトのみを Windchill パッケージに含めてエクスポートするための効率的なメカニズムを提供します。

シナリオの例 1

ベースパッケージに Part 1 A.1 と Part 2 A.1 の 2 つの部品が含まれている次の例について考えます。Part1 A.1 で変更が加えられて Part 1 A.2 に変更され、さらにコンテナの説明 (製品/ライブラリ) が変更されています。コンテナはエクスポートされる部品メタデータに貢献するので、コンテナは埋め込みオブジェクトと見なされます。コンテナの説明の変更は変更されたオブジェクトと見なされ、これにより、コンテナに含まれているすべてのオブジェクトが変更されたオブジェクトと見なされます。つまり、この Part1 A.1 と Part1 A.2 では、ベース送信と比較する際に、エクスポートされたメタデータは変更されていないにもかかわらず、変更されたオブジェクトと見なされます。エクスポートされたメタデータにも注意を払うため、デルタ計算ロジックがさらに強化されました。このため、以下の表に示すように、Part1 A.1 でエクスポートされたメタデータは変更されないので、結果のパッケージでは 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 1 A.2	Part 1 A.2 - デルタ

シナリオの例 2

もう 1 つの例として、前の例で説明したベースパッケージに追加の 3 番目の部品 Part3 A.1 が含まれており、この部品にはユーザー User1 によって属性 LifeCycle1 (LC1) が追加されています。ある時点で 3 番目の部品の LifeCycle1 属性が別のユーザー User2 によって LifeCycle2 (LC2) に修正された場合、通常、差分送信には Part1 A.1 -> Part1 A.2 と Part3 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 1 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 を指定すると、lifecycleInfo タグ全体とその中にネストされたすべての属性が無視されるので、差分送信でのエクスポート時に Part3 A.1 の変更は無視されます。

<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 1 A.2 Part 2 A.1 Part 3 A.1 の LC1 -> LC2	Part 1 A.2

XML ファイルでエレメントを定義した後、このファイルを読み込んでプリファレンスを有効にできます。すべての Windchill パッケージや、同期差分送信などのその他の送信オプションで同様のプリファレンスを設定できます。

詳細については、「パッケージのタイプベースのプロパティ」の「タイプベースプロパティの XML ファイルの読み取りおよび読み込み」セクションを参照してください。

通常、「送信コンテンツ」 UI タブにはパッケージメンバーのみが表示されます。セカンダリオブジェクト (依存オブジェクト) は UI に表示されません。関連付けられているセカンダリオブジェクトが変更されて差分パッケージの送信 ZIP に含まれている場合にプライマリメンバーが表示されるのはこれが理由です。

たとえば、送信 ZIP に含まれている製品表現の更新では「送信コンテンツ」 UI タブに WTPart が表示されます。また、関連付けられているファミリーテーブルでは EPM ドキュメントが表示されます。同様に、製造メーカー/ベンダー/OEM 部品の AXL エントリにのみ更新がある場合、関連付けられている WTPart が「送信コンテンツ」 UI タブに表示されます。

これは役に立ちましたか?