IBM FileNet P8, バージョン 5.2.1            

Process API の使用の最適化

パフォーマンスを向上するようにプロセス・アプリケーションを設計すると、アプリケーションの効率を大幅に改善し、ユーザーの操作性を強化できます。次のガイドラインは、プロセス・アプリケーションのパフォーマンスを最適化するための一般的な推奨事項を示します。

ロスターの使用の最適化

すべてのワーク・アイテムはロスター経由で追跡され、複数のワークフロー定義がロスターに格納されます。ロスター照会からは、VWRosterElementsVWWorkObjects のみが取得されます。

ロスターの使用を最適化するには:

  • 頻繁に更新されないフィールドのみを開示します。ロスター上の開示データ・フィールドの更新には、より手間がかかります。
  • ロスター関連の照会に対して最適なバッファー・サイズを設定します。例えば、バッファー・サイズを増やして (デフォルトは 50、最大は 200)、Content Platform Engine サーバーに対するラウンド・トリップを最小化することを検討します。
  • ロスター経由でワーク・オブジェクトを照会しないようにします。ロスター経由で照会すると、アプリケーションがデータベースに 1 回でなく 2 回アクセスします。

キューの使用の最適化

特定のステップのすべてのワークは、キューに常駐します (キューには、実際のワーク・オブジェクト・データが格納されます)。キューには、異なるタイプのワーク・オブジェクトを格納できます。キューを照会すると、VWWorkObjectsVWStepElements、および VWQueueElements が取得されます。

キューの使用を最適化するには:

  • QUERY_LOCK_OBJECTS フラグを使用します。そうすることで、オブジェクトのロック状況を確認 (またはオブジェクトをロック) するために、別の RPC を行う必要がなくなります。フラグを使用すると、ロックの競合も削減されます。
  • 照会に対して最適なバッファー・サイズを設定します。例えば、バッファー・サイズを増やして (デフォルトは 50、最大は 200)、Content Platform Engine サーバーに対するラウンド・トリップを最小化することを検討します。
  • できれば、パーティション化して複数のキューを使用するようにします。

ログの使用の最適化

ログの使用を最適化するには:

  • パーティション化して、異なるワークフローに異なるログを使用するようにします。
  • 不要なログ・オプションを無効にします。そうすることで、パフォーマンスが向上する可能性がありますが、トラッカーにも影響を与えます。この手法はトラッカーでは使用しないでください。
  • ログ・レコードを管理します。ログを保守するには、vwlog ツールを使用します。未使用のログ・レコードを定期的に削除するには、オペレーティング・システムのスケジューリング・ツールを使用します。
  • ログ情報をテキスト・ファイルに保存します。

照会の最適化

照会の使用を最適化するには:

  • 適切な照会フラグを設定して、ロスター、キュー、およびログの各照会からユーザー・フィールドのみを返すようにします。例えば、VWQueue.createQuery() の queryFlags パラメーターの照会フラグ QUERY_GET_NO_SYSTEM_FIELDS や QUERY_GET_NO_TRANSLATED_SYSTEM_FIELDS を設定して、返されるワーク・アイテムのシステム・フィールドとヘルパー・データを取得しないようにします。エレメントに関するヘルパー・メソッドは、変換済みのシステム・フィールドなしでは機能しません。
  • 索引を作成し、索引の数を制限して、転送データ量の少ないより効率的な照会が実施されるようにします。索引は固有にします。
  • フィルターを使用して一定範囲のエレメントを取得し、転送データ量の少ないより効率的な照会を実現します。フィルターは以下の目的で使用してください。
    • 取得したエレメントを指定された範囲内に制限するため。
    • Content Platform Engine サーバーからのそれぞれの取り出しで取得されるオブジェクトの最大数 (デフォルトでは 50 項目) を設定するため。
    .

LDAP データ・セキュリティーでユーザー名とグループ名のパターン・マッチ・リストを生成するためのガイドライン

LDAP データ・セキュリティーを使用してシステム内のユーザー名とグループ名のリストを最適化するには、次のガイドラインに従います。

VWSession メソッドの findGroups() および findUsers() から返される結果リストは、検索パターン、検索タイプ、ソート・タイプ、バッファー・サイズの 4 つの入力引数によって決まります。これらのメソッドは、カスタム・アプリケーションから直接呼び出すことも、FileNet® の「参加者の選択」ダイアログを使用して間接的に呼び出すこともできます。このダイアログには、以下のアプリケーションからアクセスできます。
  • プロセス構成コンソール
  • プロセス・トラッカー
  • Process Administrator
  • Process Designer
  • サンプルの Java™ ステップ・プロセッサー・クライアント・ユーティリティー
これらのメソッドの 1 つの呼び出しが直接であろうと間接的であろうと、通常は出力リストに以下のような特性があります。
  • 検索タイプのルールに従って、検索パターンに一致する名前を格納します。
  • ソート・タイプで指定されたソート順序に従って並べられます。
  • バッファー・サイズ引数で指定されたレコード数を含む塊で Content Platform Engine から内部的に転送されます。

VWSession.findGroups() または VWSession.findUsers() によって生成される名前リストには、次のように入力引数の特定の組み合わせに応じて制限があります。

  • 検索タイプが NONE の場合、次の特別な考慮事項が他の入力値に適用されます。
    • 検索パターンは無視され、NULL の検索パターンが許可されます。
    • ソート・タイプは無視され、昇順にソートされたリストが常に返されます。
  • Sun Java System Directory Server の場合、Content Platform Engine 管理者のユーザー・アカウント・サイズ制限を -1 (制限なし) に設定します。こうすることで、セキュリティー・サーバーのバッファー・サイズ制限の潜在的な副次作用を排除できます。
  • 検索タイプが NONE 以外の入力オプションである場合、特別な考慮事項が他の入力値オプションと結果の名前リストに適用されます。この場合の特別な考慮事項は、ソート・タイプが NONE であるか、その他の考えられるいずれかのオプション (ASCENDING や DESCENDING など) であるかに応じて異なります。
    • ソート・タイプが NONE の場合:
      • バッファー・サイズ設定が、メソッド呼び出しで返すことができるレコードの最大数となります。
      • 返される実際のレコード数は、入力バッファー・サイズとディレクトリー・サーバー・サイズ制限のいずれか小さい方の数となります。
    • ソート・タイプが NONE 以外のオプションの場合:
      • バッファー・サイズ設定が、メソッド呼び出しで返すことができるレコードの最大数となります。
      • 検索タイプが NONE である場合を除き、Null 以外の検索タイプが求められます。NONE 検索タイプは検索パターンを無視するため、例外となります。
      • セキュリティー・データベースには、ソート用の索引が含まれている必要があります。適切なセキュリティー・データベース索引が存在しない場合、Content Platform Engine は、「VWServer 例外: 重要な拡張機能が使用できません。LDAP err = 0x0000000c」のようなエラー・メッセージをログに記録し、表示します。


最終更新日: 2015 年 10 月
optimize_process_api.htm

© Copyright IBM Corp. 2015.