高度なカスタマイズ > サービスおよびインフラストラクチャのカスタマイズ > サーバーロジックの開発 > Windchill マルチオブジェクト操作
  
Windchill マルチオブジェクト操作
Windchill のマルチオブジェクト API インフラストラクチャのサポートによって、変更の永続化、ほかの API の呼び出し、またはイベントの発行時にいずれのループも経由しないで、オブジェクトのコレクションに対して操作を実行できるようになります。これによって、データベースとのやりとりの回数およびメソッド呼び出しの回数が削減されます。たとえば、100 のオブジェクトを永続化する操作で、バッチオペレーションを使用してデータベースを 1 回呼び出し、操作に関連するイベントを 1 回発行すれば済みます。同様に、イベントリスナーは、重複する永続性 (CRUD2) 操作と、データベース呼び出しを n 回ではなくわずか 1 回行うマルチオブジェクト操作を置換して、コレクション全体に対して操作できます。関連付けなどをコピーするイベントリスナーにはマルチオブジェクト API が有効なので、コレクションにエレメントが 1 つしかない場合でも、マルチオブジェクト API はループよりも非常に優れています。マルチオブジェクト API に対する Windchill のサポートは以下の項目で構成されています。
Windchill 固有のコレクション
マルチオブジェクトイベントの発行と通知
マルチオブジェクト委任
マルチオブジェクト例外
マルチオブジェクト「CRUD」の永続性管理マネージャ API
バッチ (「UPDATE WHERE」および「DELETE FROM」) ステートメント機能
トランザクションコンテキストとリスナー
オブジェクト削除時の参照整合性の関連検証
Windchill 固有のコレクションでは、Java Collections フレームワークを使用して、Windchill 永続性オブジェクトに対して最適化されたセット、リスト、およびマップを提供します。これらのコレクションでは、QueryKey、WTReference、および完全にインフレートされた永続可能オブジェクトとして表される永続可能オブジェクトをシームレスに処理します。また、クラスに基づいたサブコレクションの再表示、インフレート、および取得、メンバーシップのテストなどを実行するための多数の API も提供します。詳細については、Javadoc の wt.fc.collections パッケージを参照してください。
マルチオブジェクトイベントの発行および通知では、イベント (PRE_STORE など) をシングルオブジェクトまたはマルチオブジェクトとして発行および通知することができます。イベントメカニズムは、発行子および通知子 (つまり、リスナー) が矛盾する場合、マルチオブジェクトイベントをシングルオブジェクトイベントに変換してリスナーをループするか、または逆に、シングルオブジェクトイベントをマルチオブジェクトイベントに変換して、マルチオブジェクトリスナーに通知することによって、自動的に処理します。マルチオブジェクトイベントには、コレクションベースのイベントターゲットが含まれます。
マルチオブジェクト委任によって、オブジェクトのコレクションの委任をリクエストできます。次に、マルチオブジェクト代理 API によって、適切な代理が使用先のコレクションのサブコレクションにマッピングされます。これによって、サブコレクションが代理のマルチオブジェクト API に渡されると、その代理でマルチオブジェクト API を実行できます。たとえば、部品とドキュメントのコレクションに「x.y.Z」代理をリクエストし、delegate1 が部品に相当し、delegate2 がドキュメントに相当する場合、delegate1 のマルチオブジェクト API が呼び出されて部品のサブコレクションを渡します。詳細については、wt.services.ac.DefaultServices に関する Javadoc エントリを参照してください。
マルチオブジェクト例外は、マルチオブジェクト API およびリスナーによって発生します。このような例外によって、渡されたコレクションの一部のオブジェクトに関連する問題の内容に関する拡張情報を入手できます。たとえば、3 つのオブジェクトが一意でないアイデンティティに割り当てられているために、10 のオブジェクトに対する変更アイデンティティが失敗した場合、発生した例外は 3 つの個々のエラーを示します。このためには、「additionalMessages」を wt.util.WTException に追加する必要があります。
マルチオブジェクト CRUD 永続性管理マネージャ API は、バッチ操作を使用してデータベースと対話します。これによって、CRUD 操作のデータベース対話の回数がわずか 1 回に削減されます (実際には、テーブルごとに 1 回になります)。100 個の部品のコレクションを渡す保存操作では、100 回の挿入操作を行うのではなく、データベースに対して 1 回の一括挿入を行うことができます。詳細については、wt.fc Javadoc エントリを参照してください。
バッチ (「UPDATE WHERE」および「DELETE FROM」) ステートメント機能では、データベースで UPDATE WHERE ステートメントおよび DELETE FROM ステートメントに変換される Windchill ステートメントが生成されます。これによって、たとえば、1 回のデータベース呼び出しでオブジェクトのコレクションのすべての関連付けを削除できます。リンクをあらかじめ照会する必要がありません (実際には、これらの操作はイベントを対象としているので、OID が返される場合もあります。また、リスナーが完全な永続可能オブジェクトを要求する場合はインフレートされます)。詳細については、wt.fc.batch を参照してください。
トランザクションコンテキストとリスナーでは、ネステッドされたトランザクションとグローバルトランザクションに MethodContext と似た方法で情報を追加し、トランザクションによるコミット開始直前、コミット完了時、またはロールバック時に通知するための詳細なメカニズムが提供されます。wt.pom パッケージの Transaction、TransactionListener、および TransactionCommitListener に関する Javadoc エントリを参照してください。
オブジェクト削除時の参照整合性の関連検証では、削除時の関連付けによる動作を指定するための宣言型メカニズムを使用します。各役割によって、役割オブジェクトが削除される際に、関連付けを削除すべきか、または削除を拒否すべきかが示されます。