| Oracle® Fusion Middlewareパフォーマンスのチューニング・ガイド 12c (12.2.1.2) E82648-01 |
|
 前へ |
 次へ |
Oracle Human Workflowをチューニングし、人間の様々な操作をビジネス・プロセスで取り扱う際のパフォーマンスを最適化できます。
親トピック: SOA Suiteのコンポーネント
Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャ内で稼働するサービス・エンジンです。これを使用すると、対話型の人的プロセスを実行できます。
ヒューマン・ワークフローは、プロセスの内部または外部で行われる承認処理、却下処理、再割当て処理といった人間のやり取りに対応しています。Human Workflowサービスは、ビジネス・プロセスと人間とのやり取りの様々な側面を処理する多くのサービスからなります。
詳細は、Oracle Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発で、ヒューマン・ワークフロー・サービス・コンポーネントの使用に関する項を参照してください。
Oracle Human WorkflowのWebサイト(http://www.oracle.com/technology/products/soa/hw/index.html)も参照してください。
Oracle Human Workflowをチューニングし、人間の様々な操作をビジネス・プロセスで取り扱う際のパフォーマンスを最適化できます。
ここに記載されている提案はすべてAPI使用に適用できます。
表17-1 重要なヒューマン・ワークフロー・チューニング戦略
| 名前 | 説明 | 推奨事項 |
|---|---|---|
クライアント側のレスポンス時間の最小化 |
ワークフロー・クライアント・アプリケーションが対話型の場合、クライアント側の最適なレスポンス時間を維持することが重要です。 レスポンス時間に影響を与える要素としては、サービス・コールのパフォーマンスの影響、リクエストに該当するタスク・セットを特定するための問合せ時間、該当タスクごとに取得される追加情報の量などがあります。 |
パフォーマンス・メトリックを確認してレスポンス時間を改善する方法を決定してください。 |
適切なワークフロー・サービス・クライアントの選択 |
リモート・クライアントは、ほとんどの場合、パフォーマンスの点で最善の選択肢です。クライアントがワークフロー・サービスと同じJVMで稼働している場合(soa-infraアプリケーション)、APIコールはリモート・メソッド呼出し(RMI)の必要がないように最適化されます。クライアントが別のJVMに存在する場合は、RMIが使用されます。このとき、APIメソッド間でデータのシリアライズおよびデシリアライズが行われるため、パフォーマンスに影響が出ることがあります。 SOAPクライアントは、標準化(Webサービスに基づく)について優先されます。リモート・クライアントで使用されるリモート・メソッド呼出し(RMI)と比べると、追加のパフォーマンスに関する考慮事項があります。Webサービス・テクノロジによって追加の処理が行われるため、XML間でAPIメソッド引数の整列化および非整列化が発生します。 |
クライアント・アプリケーションがJava EEテクノロジをベースとしている場合は、ユースケース・シナリオを基に、使用するクライアントを検討してください。 クライアント・アプリケーションが.Netテクノロジをベースとしている場合は、SOAPワークフロー・サービス以外は使用できないことに注意してください。 |
厳密なフィルタを使用した該当タスクの絞込み |
タスク・リストを取得する際に、データベース・レベルで最大限のフィルタ処理を行えるよう、問合せをできるだけ厳密なものにする必要があります。 |
レスポンス時間を改善するために正しいフィルタを使用してください。 |
該当タスクのサブセットの取得(ページング) |
問合せAPIには、ユーザーに返される該当行の数および開始行を制御するページング・パラメータが用意されています。 |
返されるレコードの数を制限できる値への |
該当タスクに必要な情報のみのフェッチ |
通常は、タスク・リストを表示するためにペイロード・フィールドの一部が必要になるだけです。 |
まれに、ペイロード全体が必要になることもありますが、その場合はペイロード情報をリクエストできます。 |
返される問合せ列の数の削減 |
|
索引付けされた列である可能性が高いため、一般的な列を使用するよう努めてください。これによって、SQLの実行が早くなります。 |
集計APIを使用したタスク統計のチャート化 |
タスク情報を要約したチャートや統計を表示することが必要になる場合があります。 |
問合せAPIを使用してすべてのタスクをフェッチし、クライアント・レイヤーで統計を計算するのではなく、新しい集計APIを使用してデータベース・レベルで統計を計算することを検討してください。 |
カウントAPIメソッドを使用したタスク数のカウント |
特定の条件に一致するタスクの数をカウントするだけでよい場合があります。 |
|
フレックスフィールドの索引のオンデマンド作成 |
ワークフロー・スキーマ表WFTASKには、フレックスフィールド属性列がいくつか含まれています。これらを使用すると、ワークフロー・スキーマにタスク・ペイロード値を格納できます。列の数が多く、列の使用はオプションであるため、インストール済のスキーマにはこれらの列の索引は含まれていません。 |
特定のマップ済フレックスフィールド列が問合せの述語で頻繁に使用される場合は、これらの列に索引を作成してください。 |
|
特定の問合せ条件に一致するタスクが存在するかどうかを確認することが必要になる場合があります。 |
デフォルトの
|
次の戦略を使用すると、さらにパフォーマンス向上を図ることができます。
負荷の高い状況でのシステムのスケーラビリティは、サーバーのパフォーマンスによって事実上決まります。ヒューマン・ワークフローのチューニングのクライアント・タスクのレスポンス時間を最小化する戦略では、適切な量の情報をフェッチすること、および問合せに伴うパフォーマンスへの影響を軽減することによってクライアント側のレスポンス時間を最小化する手法をいくつか取り上げています。これらの手法には、データベースおよびサービス・ロジックがサーバー側のパフォーマンスに与える影響を軽減し、サーバーのパフォーマンスを改善する効果もあります。その他、次のような構成変更を行うとサーバーのパフォーマンスが向上します。
表17-2 重要なサーバー・パフォーマンス・チューニング戦略
| 名前 | 説明 | 推奨事項 |
|---|---|---|
完了したインスタンスの定期的なアーカイブ |
システムのデータベース・スケーラビリティは、システム内のデータ量によって大きく変わります。ビジネス・プロセスおよびワークフローは本来一時的なものであるため、処理が終われば、頻繁に問い合せられることはありません。 |
アーカイブ手法を使用して、完了したインスタンスを別のシステムへ定期的に移動し、そこで履歴データの問合せに役立てることを検討してください。アーカイブを行う際には、孤立したタスク・インスタンスが発生しないよう注意する必要があります。 |
適切なワークフロー・コールバック機能の選択 |
ワークフロー・コールバック機能を使用すると、割当てやタスク完了といった重要なワークフロー・イベントの後、外部システムに対して問合せや更新を行うことができます。 |
各ワークフロー・イベントの後ではなく、タスクの完了後に外部システムを更新するための十分なリソースがあることを確認してください。 コールバックが避けられない場合は、BPELコールバックではなくJavaコールバックを使用することを検討してください。Javaコールバックでは、コールバック・メソッドが同じスレッド内で実行されるため、BPELコールバックで発生するようなパフォーマンスへの影響は生じません。 |
通知がパフォーマンスに与える影響の最小化 |
通知は、実行すべきタスクがあることをユーザーに知らせるのに便利です。ほとんどの承認が電子メール経由で行われる環境では、アクション可能な通知が特に有効です。この場合、ワークリストの使用状況の点ではそれほど負荷がかかっていないとも言えます。 |
ワークフロー・イベントごとに通知を送信するかわりに、通知を最小限に抑えて、タスクが割り当てられたときのみユーザーに知らせるようにしてください。 また、通知のセキュリティを確保し、タスクの内容そのものではなく、タスクへのリンクのみを通知に含めて送信することを検討してください。 |
クラスタ・ノードのデプロイ |
ワークフロー・インスタンスおよび状態情報はすべて、デハイドレーション・データベースに格納されます。ワークフロー・サービスはステートレスです。つまり、ノードのクラスタ上で複数のワークフロー・サービスを同時に使用できます。 |
パフォーマンスの重要性が高く、スケーラビリティに優れたシステムが必要な場合は、クラスタ環境を使用してワークフローをサポートすることが可能です。 |
ワークフローの完了に要する時間は、ワークフローに指定されたルーティング・タイプによって異なります。ワークフロー機能には、ワークフローの完了に要する時間を短縮するための手段が用意されています。
表17-3 重要なワークフロー完了チューニング戦略
| 名前 | 説明 | 推奨事項 |
|---|---|---|
ワークフロー・レポートを使用した進捗状況のモニター |
モニタリングおよび予防的な問題解決を容易にするワークフロー・レポート(および対応するビュー)がいくつか用意されています。 |
不参加タスク・レポートを確認して、長期間キューに入っているタスクを特定のユーザーに割り当てることができます。 サイクル・タイム、その他の統計をモニタリングして、負担の大きいグループやタスクの完了まで時間がかかるグループのスタッフを増員することができます。 |
エスカレーション・ルールの指定 |
タスクが特定のユーザーの下で止まってしまうことのないよう、エスカレーション・ルールを指定できます。たとえば、タスクが処理されずに一定の時間が経過した場合は、そのタスクをマネージャへ進めることができます。別のルーティング・ロジックに基づいて他のユーザーへタスクをエスカレートする必要がある場合は、カスタム・エスカレーション・ルールを組み込むことも可能です。 |
適切なエスカレーション・ルールを指定することで、ワークフローの完了に要する時間を短縮できます。 |
ユーザー・ルールおよびグループ・ルールを指定した自動割当て |
ルールを使用することでワークフローの待ち時間が大幅に短縮され、ワークフロー完了の迅速化につながります。 |
タスクを他のユーザーやグループの他のメンバーに手動で再割当てするかわりに、ユーザー・ルールおよびグループ・ルールを使用して自動再割当てを実行できます。こうすると、ワークフローにタイミングよくユーザーの注意を向けることができます。 |
タスク・ビューを使用した作業の優先順位付け |
ユーザーの受信ボックスには、様々な期日が設定された様々なタイプのタスクが格納されます。ユーザーは、手動でタスクを選別したり並べ替えたりして、次に処理するタスクを決める必要があります。 |
タスクが期日や優先度に基づいてフィルタ処理されるようなタスク・ビューを作成すれば、作業の優先順位付けが自動的に行われるため、処理するタスクを決めるのに無駄な時間を費やさずに済み、タスクの完了に専念できるようになります。 |
ワークフロー・サービスでは、SQL問合せを構成する際、アイデンティティ・プロバイダの情報を使用して、ユーザーのロールやグループのメンバーシップを基にそのユーザーに該当するタスクを特定します。アイデンティティ・プロバイダに対しては、ロール情報を調べてユーザーがタスク詳細をフェッチする際の権限を特定したり、ユーザーがタスクに対して実行できるアクションを特定する目的でも、問合せが行われます。アイデンティティ・プロバイダへのリクエストを迅速化するには、いくつかの方法があります。
アイデンティティ構成ファイル内の検索ベースをできるだけ細かくノードに設定します。理想的なのは、ワークフロー関連のグループを単一ノードに集めて、検索および参照のためのトラバースを最小限に抑えることです。これは常に可能であるとはかぎりません。たとえば、既存のグループを使用して、他のノードのグループにメンバーシップを付与する必要が生じる場合もあります。フィルタを指定して検索対象のノードを絞り込むことが可能であれば、アイデンティティ構成ファイルにフィルタを指定してください。
アイデンティティ・プロバイダの重要な属性(dnやcnなど)のすべてに索引を作成します。そうすることで、検索や参照の際に、ツリー全体ではなくノードのサブセットのみがトラバースされるようになります。
キャッシュをサポートするアイデンティティ・プロバイダを使用します。LDAPプロバイダの中にはキャッシュをサポートしないものもありますが、Oracle Internet Directoryはキャッシュをサポートしているため、参照および検索の問合せが高速化されます。
Oracle Internet Directoryをアイデンティティ・プロバイダとして使用する場合、データ形状が変更された後のデータベース上の最新の統計を収集するためにoidstats.sqlを実行するようにしてください。
Human Workflowスキーマでは、最も重要な列にいくつかの索引があらかじめ定義されています。ユーザーのタスク・リストをフェッチするため、リクエストのタイプに応じて異なるSQL問合せが生成されます。データベース・オプティマイザは、様々な計画(全表スキャン、索引による表アクセスなど)のコストを評価して、よりコストの低い計画を決定します。オプティマイザが正しく機能するよう、索引統計を常に最新の状態に維持してください。データベースの使用方法を問わず、最大限のパフォーマンスを得るには、データベース統計を定期的に更新し、その他のチューニング可能なパラメータ(メモリー、表領域、パーティションなど)を効果的に使用することが重要です。
データベースのチューニングの詳細は、データベース・パラメータのチューニングを参照してください。
