高度なカスタマイズ > ビジネスロジックのカスタマイズ > 変更管理のカスタマイズ > 変更ワークフローの終了 > 制限事項
  
制限事項
古いワークフロープロセスと新しいワークフロープロセス
新しいワークフロープロセスと連動するように古いワークフロープロセスを設定できる場合があります。たとえば、承認後にワークフロープロセスを完了する問題レポートまたは一時許可に新しい変更リクエストワークフローを使用することはできますが、その変更リクエストワークフロープロセスは親関連付けに対して強制終了を呼び出す必要があります。新しいワークフロープロセスを使用する問題レポートまたは一時許可も関連付けられている場合、これらは handlesClosuretrue に設定されているときには強制終了されません。Windchill Release 11.0 に付属の変更リクエストワークフロープロセステンプレートは、以前のリリースと新しいリリースの両方の問題レポートおよび一時許可ワークフロープロセスをサポートするように設定されています。
同期終了がすでに設定されている既存の関連変更管理オブジェクトプロセスに対して強制終了 API を使用すると、予期しない結果が生じる可能性があります。たとえば、変更リクエストワークフロープロセスで、変更通知が解決されたときのためにすでに同期終了が設定されているとします。親関連付けを強制終了するように変更通知ワークフロープロセスを更新すると、アノテーションのロックなどの変更リクエストプロセス内の追加のシーケンスは発生しません。
必要な変更リクエストワークフロープロセスの更新
フレキシブル変更プロセス関連付けを使用できるように変更リクエストワークフロープロセスを更新する必要があります。ChangeService2Event.CN_STATE_CHANGED は、フレキシブル変更プロセス関連付けではサポートされていません。このイベントは、廃止された wt.change2.AddressedBy2 関連付けでは使用できます。
複数の関連付けがある場合の終了
フレキシブル変更プロセス関連付けの親 (役割 A) および子 (役割 B) として定義する変更管理オブジェクトタイプを決定するとき、終了の方向を考慮する必要があります。オーナー役割は、親役割または子役割とは切り離して定義できます。たとえば、以下の関係があるとします。
問題レポートから変更リクエストへの関連付け
変更リクエストから変更通知への関連付け
関連付け規則を定義するときに、終了の方向を使用することをお勧めします。終了の方向に関連付け規則を定義することにより、変更リクエストはすべての関連変更通知が終了をするのを待ち、問題レポートはすべての関連変更リクエストが終了するのを待つことが保証されます。変更リクエストが両方の関連付けのオーナー役割であると見なされる場合は、次のように役割が終了の方向に定義されている変更プロセス関連付け規則を定義することを検討してください。
役割 A (親)
役割 B (子)
オーナー役割
問題レポート
変更リクエスト
役割 B
変更リクエスト
変更通知
役割 A
規則が終了の方向に定義されていない場合は、さらなる考慮が必要です。規則の定義を次のように変更することを検討してください。
役割 A (親)
役割 B (子)
オーナー役割
変更リクエスト
問題レポート
役割 A
変更リクエスト
変更通知
役割 A
一般的な isRelatedChildrenInStates API が特定の変更管理オブジェクトタイプを指定することなく変更リクエストワークフロープロセスで使用されている場合、変更リクエストは問題レポートが終了するのを待ちます。問題レポートワークフロープロセスも変更リクエストが終了するのを待つため、終了のデッドロックが発生します。終了のデッドロックを防止するには、isRelatedChildrenInStates API を使用するときに、特定の変更管理オブジェクトタイプが指定されている必要があります。変更リクエストワークフロープロセスで変更通知タイプが指定されている必要があります。これにより、関連問題レポートが無視されます。