設定を変更可能な XML オブジェクト設定のチューニング

設定可能な XML オブジェクトを使用すると、広範囲のユーザーインタフェース仕様が利用でき、タスクごとにユーザーへのデータ表示方法を定義したり、複雑な業務プロセスを自動化したりできるようになります。ただしこの柔軟性は、効率、パフォーマンス、および信頼性に影響を与えることがあります。

ここでは、フォーム、ルール、およびワークフローから構成される、Identity Manager の設定可能な XML オブジェクトをチューニングする際のガイドラインをいくつか説明します。これらの情報は、次のように構成されています。

• 「フォームのチューニング」

• 「ルールのチューニング」

• 「ワークフローのチューニング」

フォームのチューニング

実行中タスクのビューや変数コンテキストと相互に作用するインタフェースを定義するには、Identity Manager のフォームを使用します。フォームには、データ要素のセットにビジネスロジックと変換ロジックに使用する実行コンテキストがあります。各種タスクを実行する非常に強力で動的なフォームを作成できるとはいえ、フォームの複雑さを抑えれば効率が上がります。

次に、カスタマイズしたフォームのパフォーマンスを向上させる方法をいくつか説明します。

• 「新しいフォームの最適化」

• 「管理者フォームの最適化」

• 「エンドユーザーフォームの最適化」

• 「フォームフィールド内の式の最適化」

新しいフォームの最適化

Identity Manager の新しいフォームを設計する際、システムインテグレーターは次の手順に従えばフォームのパフォーマンスを最適化できます。

• 「負荷が大きい」クエリーは、できる限り一度だけ実行する。このクエリーを最小限に抑えるには、次の項目を実行します。

  • <Field> <Default> 要素を使用して、クエリーを実行し結果を格納します。

  • これ以降のフィールドの値を参照するには、フィールド名を使用します。

  • カスタムタスクの場合

    • ManualAction の前にこのタスク内の値を計算してから、タスク変数にこの値を格納します。

    • このフォーム内の変数を参照するには、variables.tmpVar を使用します。

    • ManualAction の後に変数をクリアするには、<setvar name=’tempVar’/> を使用します。

• 計算には、初期表示と更新ごとに実行される <defvar> を使用します。

管理者フォームの最適化

管理者フォームのパフォーマンスを向上させるには、次の項目を実行します。

• TargetResources を指定して、特定のリソースのみを取得して編集します。(詳細は、「ワークフローのチューニング」を参照してください。)

• FormUtil.getResourceObjects または FormUtil.listResourceObjects を使用している場合は、変更頻度の低いオブジェクトに cacheList と cacheTimeout のキャッシュパラメータを使用します。

• 時間の掛かる計算とフェッチの結果は <Field> 要素に格納し、<Default> にある式で評価することで、演算が一度だけ行われるようにします。

• update.constraints を使用して、実行時に取得されるリソースを制限します (『Sun Identity Manager Deployment Reference』の「Dynamic Tabbed User Form」を参照してください)。

• バックグラウンドの承認を使用 (ManualAction の各所有者に 1 秒のタイムアウトを設定) して、ページ送信の高速化を図ります。

• 選択したパネルにかかわらず、ページの再読み込み時に Identity Manager が「タブパネルフォーム」のすべてのパネルに定義されているすべてのフィールドを必ず更新するようにしてください。

エンドユーザーフォームの最適化

エンドユーザーフォームのパフォーマンスを向上させるには、次の項目を実行します。

• TargetResources を使用して、ビューのチェックアウトを対象となるリソースアカウントのものだけに制限します。これにより、ビューのフェッチ時間が短縮され、TaskInstance と WorkItems で消費されるメモリーが少なくて済むようになります。

• Identity Manager のユーザーオブジェクトのビュープロパティーと属性だけが対象となっている場合、WSUser を返す際に Session.getObject(Type, name) の使用を検討します (複数の延期タスクのトリガーの管理に役立ちます)。

• 通常はエンドユーザーのタスクの方がプロビジョニングタスクよりも WorkItems が多いため、エンドユーザーのタスクはWorkItem サイズに特に影響を受けやすくなります。

• 「ビュー」をチェックアウトして構築し、編集したあとでビュー全体にマージし直してチェックインする際には、一時的な汎用オブジェクトを使用することを検討します。

• デフォルトの「ユーザーの作成」と「ユーザーの編集」インタフェースを使用する代わりに、スケーラブルフォームを使用するようにします。

  ユーザーを編集する際にデフォルトのユーザーフォームを使用すると、ユーザーのアカウントを編集し始めた時点で Identity Manager はそのユーザーが所有しているリソースを取得します。多数のリソースを抱えるユーザーアカウントがある配備環境では、この時間の掛かりがちな操作によってパフォーマンスが低下する危険性があります。

フォームフィールド内の式の最適化

フォームで実行される動作の中には、Identity Manager 外部のリソースを呼び出すものがあります。特にグループリストや電子メール配信リストのコンパイルなど、結果の値が長いリストになるような外部リソースへのアクセスは、Identity Manager のパフォーマンスに影響を与えることがあります。

このような呼び出し中のパフォーマンスを向上させるには、『Sun Identity Manager Deployment Reference』の「Java クラスを使用したフィールドデータの取得」のガイドラインに従ってください。

また、<Disable> 式のようなパフォーマンスに影響を受けやすい式で JavaScript^TM を使用するのは避けてください。組み込まれたトレース機能を使用する場合は、短い XPRESS 式の方がデバッグしやすいです。ワークフローアクションの複雑なロジックには JavaScript を使用します。

フォームの表示速度が低下した場合、debug/Show_Timings.jsp ページで問題を見つけ出すことができます。Formconvert.convertField() への呼び出しを探してください。これで、フィールドごとにその値の計算にどれくらい時間が掛かっているかがわかります。

ルールのチューニング

Identity Manager ルｰﾙを使用して、本製品の中でフォームやワークフローなど設定可能なコンポーネントで再利用できる定数と XPRESS ロジックをカプセル化します。

ルールを記述する際は、最適なパフォーマンスを得られるよう、必要に応じて次のガイドラインを使用してください。

• 定数値を返すには、静的な宣言を使用します。

• 増分された値や一度だけ参照される値には、defvar メソッドを使用して一時的な値でアルゴリズムを実装します。

• 複数回返すべき値がある複雑で負荷のかかる計算には、putmap、setlist、または setvar メソッドを使用します。最終的には値を <null> に設定します。

ワークフローのチューニング

さまざまな人的および電子的タッチポイントを使用した複雑な業務処理を、使いやすく自動化できるように Identity Manager のワークフローをカスタマイズします。

カスタムのワークフローのパフォーマンスを向上させるには、次の方法に従ってください。

• 処理時間を改善するため、承認サブプロセスへの呼び出しを削除して、デフォルトのワークフローを単純化します (特に、Active Sync、一括動作、調節などの一括処理動作)。

• ワークフロー内に無限ループがないことを確認します。特に、承認サブプロセス内にあるループで、ブレークフラグが更新され適切に確認されるようにします。

• 複数回同じオブジェクトのリポジトリを参照する必要がある場合は、取得したオブジェクトを後から使用できるよう変数に置きます。

  Identity Manager はすべてのオブジェクトをキャッシュしないため、変数の使用が必要です。

• WorkflowServers の checkoutView の TargetResources オプションで、アカウント情報のクエリー対象となるリソース数を制限します。

  アカウント情報のクエリー対象となるリソース数を制限する方法については、次の例をご覧ください。

  <Argument name=’TargetResources’> <list> <string>resource name[| #]</string> </list> </Argument>

  ---

  注 –

  上の例の [| #] は、特定のリソースに複数アカウントがあるときに使用できるオプションのパラメータです。たいていの場合、リソース名で十分です。

  ---

• フォームで残った不要なビュー変数を消去します。特に大きなマップとリストを消去します。たとえば、次のようにします。

  <setvar name=’myLargeList’></null></setvar>

  このビューは、TaskInstance オブジェクトで複数回コピーされるため、大きなビューでは TaskInstance とそれに対応する TaskResult のそれぞれのサイズが著しく増加します。

• 完了したタスクをすぐに廃棄するよう、TaskDefinition の resultLimit (数秒内) を使用するか、タスク実行中のこのオプションを設定します。TaskInstances の数が多いと、次に影響が出ます。

  • フッター内の taskResults.jsp と管理者インタフェース内の JSP^TM タスクの表示方法

  • JSP タスクの表示方法

  • タスク名を変更する際の TaskInstance ごとのクエリー

  • データベースのサイズ

  次のオプションを必要に応じて設定します。

  • (選択を推奨) delete — 新しいタスクの実行が開始される前に、同一名の古い方の TaskInstance を削除します。

  • wait — 古い方の TaskInstance が削除されるか resultLimit に達して期限が切れるまで、現在の TaskInstance を一時停止します。

  • rename — 命名が競合しないように、TaskInstance 名にタイムスタンプを挿入します。

  • terminate — 同一名の古い方の TaskInstance を削除します。現在実行中の同一名の TaskInstance がそれぞれ中止されます。

WorkItems (ManualActions ) のチューニング

WorkItems (ワークフロー内では ManualActions と表示されています) の数とサイズによって、メモリーとシステムパフォーマンスが著しく影響を受けることがあります。デフォルトでは、WorkItem に Identity Manager が全体ワークフローのコンテキストをコピーしてから、送信後にこのワークフローコンテキストを書き戻します。

WorkItems と ManualActions のパフォーマンスを向上させるには、次の手順に従ってください。

• WorkItems のサイズを減らします。

  デフォルトでは、ManualAction が WorkItem を作成してから、そのタスクコンテキストのそれぞれの変数を WorkItem.variables にコピーします。タスクコンテキスト変数を制限すると、並列承認から上書きされなくなります。

  • WorkItem へコピーし直される変数を制限するには、ExposedVariables を使用します。たとえば、次のようにします。

    <ExposedVariables><List><String>user ...

  • WorkItem から実行中のタスクへ解析し直される変数を制限するには、EditableVariables を使用します。たとえば、次のようにします。

    <EditableVariables><List><String>user ...

    承認フラグ、フォームボタンの値、および実際の承認者名を必ず含めてください。

• 確認ページとバックグラウンド処理を変更し、ユーザーインタフェースの応答時間を向上させます。

  • 設定プログラムなどの別ユーザーが所有している、確認の ManualAction またはバックグラウンドの ManualAction を作成します。

  • タスクが実行されて WorkItems が削除されてからユーザーがアクションを送信する場合にエラーメッセージが表示されないようにするには、timeout=’-5’ (5 秒) と ignoreTimeout=’true’ を設定します。

• 値のマップやリストなどの大きな属性値を送信時に null に設定してメモリー使用を最適化します。または、スコープからすばやく排出されるようにそれらを Activity スコープ指定変数としてインスタンス化します。

• 完了したタスクの有効期間を短くします。

  • 各 WorkItem に Timeout を指定してそのワークフローが Timeout を WorkItem ごとに予測するようにして、デッドエンドのタスクがなくなるようにします。

  • タスク完了後のスケジューラによるタスクの処理方法がわかるよう、TaskDefinition の resultLimit と resultOption オプションを使用するようにします。

    • resultLimit を使用して、タスク完了後のタスクの有効期間を秒単位で制御します。デフォルトのサイズはゼロ (0) です。つまり、タスク完了後にタスクインスタンスが即時削除されます。

    • resultOption を使用して、タスクの繰り返しインスタンスが開始されたときに行うべき動作を指定します (wait、delete、rename、または terminate など)。デフォルトは delete です。

      正常に完了したタスクを即時削除するとはいえ、デバッグできるまでエラーを含むタスクを残しておくには、条件付きで完了したタスクを削除することもできます。

      TaskDefinition の resultLimit に、問題をデバッグするのに十分な期間を設定します。WorkflowServices 呼び出し後に、実行時にエラーが何も報告さければ(WF_ACTION_ERROR が <null/> など)、resultLimit を 0 (または 小さい値) に設定できます。

• うまくスコープ指定されていない変数を評価して修正します。次のように、宣言された場所に応じて変数をスコープ指定します。

  • Global 変数は、多くの動作 (ケース所有者やビューなど) に使用され、サブプロセス内で承認フラグとして使用されるべき値です。

    <TaskDefinition> の要素として宣言されている変数があれば、その変数をグローバルにスコープ指定してください。external に宣言されている変数があれば、その値はスタックの呼び出し時に解決されます。

  • 負荷の掛かる値の Activity 変数 (リソースのフェッチを必要としたり、大きなリストやマップの値を格納する Activity 変数など) が、WorkItem で参照されることがあります。

    <Activity> 要素として宣言されている変数があれば、その変数を Activity 内の動作と遷移要素に表示されるようにします。

    ---

    注 –

    Identity Manager Version 2005Q3M1 SP1 以降は、WorkItem の作成に値がコピーされないよう、ワークフローではなくフォームに <Activity> 変数値を使用してください。

    ---

  • Activity 変数は、遷移ロジックで使用される値です。

    <Action> の要素として宣言されている変数があれば、動作の完了時にその変数がスコープを配るはずです。Action 変数は通常、アプリケーションから設定された変数名 (View -> User など) を「変更」するために WorkflowApplication の呼び出しで使用されます。

• ウィザードのワークフローの最終ページには、同期実行 (syncExec='true') を指定しないでください。

  true に設定すると、ユーザーがタスクを実行したときに、そのタスクが完了するまで実行されます。そのタスクが完了するか、別の停止点 (別の ManualAction など) に達するまでインタフェースがハングしてしまいます。

• 不要な承認チェックを削除します。

  ---

  注 –

  Active Sync には、viewOptions.Process から指定されたシステム指定のプロビジョニングタスクの代わりに、能率的なプロビジョニングタスクを使用します。

  ---

• Identity Manager に用意されているプロビジョニングタスクは変更しないでください。

  (リストされていないタスクである限り、) タスクを新規作成してから、フォームと処理マッピング構成の中でそのタスクを指定します。