ソリューション

既成のコンフィギュレーションとカスタマイズフックを使用して、新規矛盾を追加するロジックを実装します。

クラス DiscrepancyType は矛盾タイプを表します。このクラスにはサポート済みのマークが付き、既成の矛盾が含まれます。

これは独自の rbInfo ファイル DiscrepancyTypeRB.rbInfo を持つ標準の Windchill 列挙であり、既成の enumCustomize ツールを使用してカスタマイズできます。

選択可能のマークが付いているすべての列挙が MPMLink の BOM トランスフォーマインタフェースで表示されます。enumCustomize ツールを使用して、矛盾タイプの既存のリストを更新したり、タイプを追加または除去したりできます。

Discrepancy2 は実際の矛盾値オブジェクトを定義する基本インタフェースです。これはサポートされているものとしてマークされています。ただし、抽象サポートクラス AbstractDiscrepancy2 を拡張することをお勧めします。この抽象クラスは、インタフェースで使用されているメソッドのデフォルトの実装を提供します。

◦ Discrepancy2 または AbstractDiscrepancy2 のすべての実装が値オブジェクトであることが想定され、ビジネスロジックが含まれていてはなりません。実装は矛盾に関連するデータを格納するよう設計されています。

◦ 矛盾を検出して解決する実際のロジックは、次のポイントで説明する矛盾委任で提供されます。

◦ このモデルでは、データとビジネスロジックを明確に分離できます。要件に基づいて、1 つの矛盾と複数の委任を定義したり、複数の矛盾と 1 つの委任を定義したりできます。

Discrepancy Delegate は特定の矛盾タイプの委任を定義する基本インタフェースです。これはサポートされているものとしてマークされています。カスタマイズの要件がある場合、抽象サポートクラス AbstractDiscrepancyDelegate を拡張することをお勧めします。この抽象クラスは、インタフェースで使用されているメソッドのデフォルトの実装を提供します。

◦ 委任の主な目的は、データとロジックを分離することにあります。委任はロジックについて責任を負う必要があります。さらに、これによって、ロジックの複雑度と再利用可能性に基づいて、複数の矛盾タイプに 1 つの委任を使用できます。

◦ 委任には 2 つの要素があります。1 つ目の要素は、指定された矛盾を JSON フォーマットに変換し、JSON を使用して矛盾を返す機能です。これは、選択した矛盾について報告して解決する場合のユーザーインタフェース用に必要です。ただし、これがサーバー側のみの場合、これらの API はスキップできます。委任の 2 つ目の要素は、矛盾を検出、検証、解決するロジックを実装することです。

既成のコンフィギュレーションの例を以下に示します。

codebase\com\ptc\windchill\associativity\xconfs\associativity.service.properties.xconf
<Service context="default" name="com.ptc.windchill.associativity.reconciliation.DiscrepancyDelegate">
......<Option cardinality="singleton" selector="QUANTITY" requestor="null"
......serviceClass="com.ptc.windchill.associativity.reconciliation.part.QuantityDiscrepancyDelegate"/>
......<Option cardinality="singleton" selector="REMOVED_USAGE" requestor="null"
serviceClass="com.ptc.windchill.associativity.reconciliation.part.RemovedUsageDiscrepancyDelegate"/>

</Service>

これは調整サービスのメインの入力です。担当のクラスは ReconciliationContext です。addAdditionalParam メソッドを使用してカスタム入力を指定できます。

public void addAdditionalParam(String key, Object value);

このマップにキーまたは値を取り込んで、サービスのフロー全体および DiscrepancyDelegate でほとんどのカスタマイズフックに読み取ることができます。これにより、各種タスクをクライアントまたはサーバーの用途に応じて異なる方法で実行する場合などに、各種入力に基づいてカスタマイズを駆動できます。さらに、異なる委任間で再使用可能な高いパフォーマンスを必要とする情報をサービスまたはカスタマイズでキャッシュ可能になります。

クラス CriteriaType は、上流構造の現在の作業版数を以前の作業版数と比較する基準を表します。このクラスにはサポート済みのマークが付き、既成の基準タイプが含まれます。

これは独自の rbInfo ファイル CriteriaTypeRB.rbInfo を持つ標準の Windchill 列挙であり、既成の enumCustomize ツールを使用してカスタマイズできます。

AbstractCriteria は、矛盾を検出するために現在のアイテムと比較する以前のアイテムを検索するときに使用する基本クラスです。このサービスは、以前のアイテムを使用して、以前のパスまたは構造情報を構築して、構造の矛盾を検出します。

TimeBasedCriteria、OutOfDateCriteria、および BaselineCriteria が既成で提供されています。入力 ReconciliationContext を使用して、これらの基準をサービスに注入できます。指定しない場合、サービスはコンフィギュレーションからデフォルトの基準を読み取ります。

インタフェースをカスタマイズできます。これはアイテムのコレクションをとり、現在のアイテムと以前のアイテムを比較したマップを返します。入力ごとに 1 つのエントリが結果として返されます。したがって、以前のアイテムが検出されなかった場合、結果の値として同じアイテムが追加されます。インタフェースを以下に示します。

public abstract Map<Associative, Associative> getCurrentToOldAssociative(ReconciliationContext context, Collection<Associative> associatives) throws WTException;

ファイル codebase\com\ptc\windchill\associativity\xconfs\associativity.service.properties.xconf で指定されているデフォルトの基準でのコンフィギュレーションを以下に示します。

矛盾モデルを処理するメインサービスインタフェースは ReconciliationService です。このサービスは、入力とコンフィギュレーションに基づいて矛盾を検出または解決する API を提供します。このサービスに最低限必要な入力を以下に示します。

a. 変更コンテキスト: すべての変更または矛盾を検出しなければならないルートノード。これはすべての変更に共通する対応コンテキストであり、必ずしも構造の絶対ルートである必要はありません。これはパフォーマンスの観点で役立ちます。変更コンテキストが高い階層にあるほど、サービスのパフォーマンスへの影響が大きくなります。これは上流と見なされます。

b. 変更アイテム: 特定の変更コンテキストで変更されたアイテム。これらは上流アイテムと見なされます。

c. 変更アイテムパス: 特定の変更コンテキストでの変更アイテムのパス。パスは構造情報が提供されるユーザーインタフェースから開始します。これによってパフォーマンスへの影響が抑えられます。この入力はオプションです。

d. 上流ナビゲーション基準: 上流構造を横断するナビゲーション基準。これは省略することも可能ですが、指定することをお勧めします。これを指定しなかった場合、サービスは変更コンテキストのデフォルトのナビゲーション基準を使用します。デフォルトのナビゲーション基準が適切に設定されていない場合、これによって問題が生じることがあります。

e. 下流ナビゲーション基準: 下流構造を横断するナビゲーション基準。これは省略することも可能ですが、指定することをお勧めします。これを指定しなかった場合、サービスは下流変更コンテキストのデフォルトのナビゲーション基準を使用します。デフォルトのナビゲーション基準が適切に設定されていない場合、これによって問題が生じることがあります。

f. 下流変更コンテキスト: 矛盾を検証または解決する必要がある下流ルート。矛盾の検出のみを行う場合、これはオプションです。

上記の入力は ReconciliationContext bean オブジェクトを使用して指定できます。

これは矛盾を検出および解決した後で事前処理と事後処理を実行する委任を定義する基本インタフェースです。これには解決する矛盾の順序を指定するロジックも格納されています。委任はサポートされているものとしてマークされています。

既成のコンフィギュレーションを以下に示します。