|
| |
| Sun™ Identity Manager 8.0 ワークフロー、フォーム、およびビュー | |
第 1 章
ワークフローこの章では、Identity Manager のワークフローについて説明します。
この章の内容
関連する章
- 「XPRESS 言語」- ワークフローやフォームにロジックを含めるために XPRESS 言語で記述する式の一覧を示し、それぞれについて説明します。
ワークフローについてIdentity Manager ワークフローは、定義されている規則に従って一貫して実行される、一連のアクションとタスクを定義します。Identity Manager 統合開発環境 (IDE) のグラフィカルユーザーインタフェースを使用して、Identity Manager によって起動される各ワークフローをカスタマイズできます。
ワークフローを操作する前に、次の項目について理解してください。
ワークフローとは
一般に、ワークフローは論理的で反復可能なプロセスであり、ドキュメント、情報、またはタスクが、定義された手順の規則セットに従って、アクションの関与者から別の関与者に渡されます。関与者は人、マシン、またはその両方の場合があります。
Identity Manager では、この概念は具体的には Identity Manager のワークフローコンポーネントとして実装されています。この機能は、ユーザーアカウントの作成、更新、有効化、無効化、および削除を管理する、複数のプロセス (ワークフロー) から構成されます。
製品インタフェースのどの位置から呼び出すかに応じて、ワークフローはワークフロー、タスク、プロセス、またはタスク定義として参照されます。
ワークフローを使用する場面
実行するほとんどの Identity Manager タスクは、ワークフロープロセスのセットとして定義できます。Identity Manager にユーザーを作成するときは、たとえば、対応するワークフロープロセスが、次の処理を定義、実行します。
ワークフローはユーザーとの対話なしで自動的に実行できますが、承認の形でユーザーとの対話が必要な場合もあります。
通常、ワークフローはビューのチェックインに付随して呼び出されます。ビューのチェックインは、フォームとビューを実装するページで「保存」をクリックしたときに行われます。
リポジトリ内のワークフロー
Identity Manager のリポジトリには、通常は、タイプが WFProcess の設定オブジェクトとしてワークフローが存在します (Create User ワークフローは、このオブジェクト定義の唯一の例外で、ProvisioningTask オブジェクトとして定義される)。taskType は常に Workflow です。
注
Identity Manager は、ワークフローの実行中のリポジトリオブジェクト (つまり、ユーザー) をロックしません。これは、ワークフローが数日にわたって実行される可能性があり、その間中リポジトリオブジェクトをロック状態で維持することはできないためです。ただし、同じユーザーによる、別の更新ワークフローの呼び出しは、Identity Manager によって禁止されます。
タスク定義とタスクインスタンス
TaskDefinition の起動インスタンスは、TaskInstance オブジェクトとして表されます。どちらのオブジェクトタイプも、「デバッグ」ページから表示できます。配備の現在のタスク定義またはタスクインスタンスにアクセスするには、次の手順に従います。
ワークフロータスクが呼び出されると、ワークフローエンジンはリポジトリに TaskInstance を作成します。TaskInstance はリポジトリ内のオブジェクトの 1 つで、実行するワークフロープロセスの実行時状態を保持します。また、作成元となった TaskDefinition のコンテキスト変数と即時遷移情報を格納します。
TaskInstance は、TaskDefinition の生成 ID を使用して、説明的な TaskDefinition オブジェクトを参照します。TaskDefinition を編集すると、すでに実行中の TaskInstance は変更前の TaskDefinition オブジェクトを継続して使用しますが、新たに実行する TaskInstance は、新たに生成された ID を使用して修正後の TaskDefinition を使用します。
タスクインスタンスの削除のタイミング
TaskInstance の存続期間は、resultLimit パラメータによって決定されます。結果の有効期間の値にゼロが設定されている場合は、タスクは完了後ただちに削除されます。正の値が設定されている場合は、TaskInstance はその時間 (単位は分) だけ維持されます。
保留になっているワークフローの TaskInstance を削除するには、次の手順に従います。
タスク定義パラメータ
次の表は、標準の設定パラメータを示しています。
ワークフローエンジン
ワークフローエンジンは、実行時のワークフロープロセスの実行を可能にするソフトウェアサービスです。ワークフロープロセスをサポートするワークフローエンジンの主な機能は次のとおりです。
アクティビティーに手動アクションが含まれる場合は、Identity Manager はアクティビティーレベルで変数を受け取ります。ワークフロータスクに必要な記憶領域を最小限に抑えるために、ワークフローエンジンは完了したアクティビティーのほかのすべての変数をエクスポートの前に削除します。
ワークフロープロセスコンポーネントの概要各ワークフロープロセスは、次のコンポーネントのいずれか、またはその組み合わせによって定義されます。ここでは、これらのコンポーネントについて詳しく説明します。
- Activity - プロセスに含まれる 1 つの論理手順を表します。
- Action - アクティビティーの実行方法を定義します。アクションは、簡単な式評価の場合もあれば、複雑な Java クラスの呼び出しの場合もあります。
- Transition - アクティビティーから別のアクティビティーへの移動を定義します。
- Split - 1 つのアクティビティーから複数のアクティビティーへの移動を定義します。Split は、さらに次のように定義されます。
- Join - 複数のアクティビティーから単一アクティビティーへの移動を定義します。Join コンポーネントは、さらに次のように定義されます。
- Subprocess - プロセスに含まれる別のアクティビティーから呼び出されるアクティビティー、アクション、および遷移のセットを定義します。
図 1-1 ワークフローの一般的なプロセスとコンポーネント
ワークフローアクティビティー
アクティビティーとは、ワークフロープロセスに含まれる 1 つのステップのことです。アクティビティーには、遷移、変数、アクションなど、複数のコンポーネントを含めることができますが、起動アクティビティーと終了アクティビティーを必ず含める必要があります。
起動アクティビティーと終了アクティビティーには、関連するアクションはありません。起動アクティビティーにはプロセスを開始するアクティビティーへの遷移を 1 つ以上設定しますが、終了アクティビティーには関連するアクションを設定しないようにしてください。
ワークフローアクション
ワークフローアクションには、ワークフローアクティビティー内で実行される操作を記述します。各アクティビティーには複数のアクションを含めることができます。Identity Manager には次のタイプのアクションがあります。
- アプリケーション -- WorkflowApplication インタフェースを介してリンクされた簡単な自動アプリケーション呼び出しです。Application アクションは、引数と変数を受け取り、変数を返すことができます。Identity Manager には、アクションのプロビジョニング、リポジトリアクセス、およびその他のユーティリティーに対応する広範囲のアプリケーションが用意されています。
- 手動 -- 人との対話を必要とするアクションです。Identity Manager フォームを使用して、ユーザーに要求する変数の名前を指定したり、アクションの所有者用のリポジトリに作業項目を作成したりできます。
- 式 -- XPRESS 言語の式を使用して定義される自動アクションです。スクリプトアクションは通常、XPRESS または JavaScript のプログラムです。
- サブプロセス -- ほかのワークフロープロセスを再帰的に呼び出すことによって実行されるアクションです。サブプロセスは、ルートプロセス内でしか定義できません。
ワークフローアクション変数
アプリケーションアクションとは
アプリケーションアクションでは、スクリプトアクションより複雑な Java 呼び出しを行うことができます。
手動アクションとは
手動アクションは、手動によるやり取りを定義した、ワークフロープロセス定義の一部です。ワークフロー実行者が手動アクションを処理するときは、Identity Manager はリポジトリ内に WorkItem オブジェクトを作成します。作業項目に完了のマークが付いてからでないと、ワークフローは次に進むことができません。手動アクションには所有者を関連付ける必要があります。所有者の代わりに、所有者を決定する式でもかまいません。
ほとんどの手動アクションは、承認の要求に使用されるため、作業項目の表は管理者インタフェースの「承認」タブにあります。ワークフローに属する手動アクションはどれも、リポジトリ内の WorkItem オブジェクトで表されます。作業項目ビューには、WorkItem オブジェクト自体に関係するいくつかの属性と、ワークフロータスクからコピーされた、選択されたワークフロー変数の値が含まれます。これには、保留中の承認などの属性と、作業項目の承認に使用されるフォームが含まれます。Identity Manager では、手動アクションは標準ワークフローの一部として、組織、ロール、およびリソースを承認することができます。
手動アクションにはタイムアウトを割り当てることができます。
デフォルトのワークフロープロセスIdentity Manager IDE を使用することで、デフォルトの Identity Manager プロセスを編集し、一連のステップをカスタマイズできます。Identity Manager のワークフロー機能には、次のようなデフォルトプロセスのライブラリが含まれます。
- ユーザーワークフロー - ユーザーの作成、削除、更新、有効化、無効化、名前の変更など、Identity Manager ユーザーに関連するタスクのステップを定義します。
- Identity Manager オブジェクトワークフロー - リソース、リソースグループ、組織、組織単位など、Identity Manager のオブジェクトに関連するすべてのタスクのステップを定義します。たとえば、ロール管理やワークフロー管理などのワークフローは、単にビューの変更をリポジトリに適用するだけですが、承認や、その他のカスタマイズのきっかけを提供することもできます。
- その他のワークフロー - 調整、Remedy テンプレート、その他のカスタムタスクなど、Identity Manager の各種機能やオブジェクトのステップを定義します。
例
次のユーザー作成ワークフローは、タイムアウト時間に達した時点で、エスカレーションアクティビティーを呼び出すように変更されています。タイムアウト時間に達するまでは、APPROVED 変数の結果が評価されます。評価の結果に基づいて、承認と拒否に対応したアクティビティーのどちらに遷移するかが決定されます。
作業項目タイプ
手動アクションには、ワークフローエンジンによって手動アクションが実行された場合に生成される作業項目に、タイプを割り当てる機能があります。カスタマイズ内容に作業項目タイプを割り当てることで、表示または操作の対象となる work items のセットをフィルタリングできます。
システムは、次のタイプの作業項目を認識します。
表 1-3 作業項目タイプ
作業項目タイプ
説明
approval
承認の作業項目であることを示します。
ウィザード
ユーザーによる任意操作の作業項目であることを表します。
保留
一時的な作業項目であることを表します。ワークフローにバックグラウンドでの実行を強制するときは、このタイプを使用します。
これ以外に、カスタマイズした作業項目タイプを割り当てることもできます。たとえば、リソースの承認を表す作業項目タイプを resource に設定したり、ロールの承認を表す作業項目タイプを role に設定したりできます。
作業項目のコンテキスト
作業項目は、<ManualAction> 指令を使用して起動されます。指定されたワークフローに関連付けられたフォームでは、ベースコンテキストを variables.user に設定できます。これにより、変数名に user.variables を入れる必要がなくなります。
作業項目はネームスペースであるため、フォームの一般的な属性名は次のようになります。
カスタムタスクと管理者承認の両方に適用されます。
認証タイプ
手動アクションには、作成する作業項目の認証タイプも指定できます。認証タイプは作業項目タイプとは異なり、現在の管理者が権限を持たない項目を排除できるように、クエリーに返される作業項目をシステムが自動的にフィルタリングするタイプです。通常は、承認者としての権限を持つどの管理者にも、担当する組織のすべての作業項目を表示する権限が割り当てられます。
手動アクションに作業項目の認証タイプを指定するには、次のように authType 属性を使用します。
<ManualAction authType='RoleApproval'>
作業項目タイプの割り当て
ManualAction 定義に項目タイプを指定するには、itemType 属性を設定します。次に例を示します。
<ManualAction itemType='approval'>
WorkItem の管理表示機能の制限
通常は、承認者としての権限を持つどの管理者にも、担当する組織のすべての作業項目を表示する権限が割り当てられます。管理者が組織の作業項目のサブセットのみを表示できるようにするときは、次の手順に従います。
作業項目の委任
ワークフロー内の作業項目 (手動アクション) を委任できるようにするには、delegator と delegators を入力引数として渡し、<ManualAction> の <WorkItemDelegator> 要素と <WorkItemDelegators> 要素でそれぞれ参照する必要があります。
delegator と delegators の値を取得するには、com.waveset.provision.getDelegateObjects ワークフローサービスメソッドを呼び出します。このメソッドは次の引数を取ります。
- 次の 2 つの属性のどちらか。
- delegateWorkItemType - 委任情報を渡す作業項目タイプ (approval、roleApproval、または attestation) を指定します。有効な作業項目タイプは、WorkItemTypes 設定オブジェクトで定義されます。
- delegateWorkItemTypeObjectName - 委任情報が収集されるオブジェクトの名前を指定します。この引数が有効なのは、delegateWorkItemType が organizationApproval、resourceApproval、roleApproval、またはこれらの作業項目タイプの拡張である場合だけです。
- delegateWorkItemTypeObjectType - 委任情報が収集されるオブジェクトのタイプを指定します。この引数が有効なのは、delegateWorkItemType が organizationApproval、resourceApproval、roleApproval、またはこれらの作業項目タイプの拡張である場合だけです。
サービスから delegateObjects 引数で委任オブジェクトのリストが返されます。
delegateObject
各 delegateObject には次の属性が入ります。
遷移の作成
遷移は、アクティビティーが 1 つまたは複数の別アクティビティーに移動するための規則を定義します。遷移には条件を設定できます。つまり、特定の条件が満たされる場合にのみ、遷移が行われるように設定できます。単純なアクティビティーには、アクティビティーを構成するアクションが完了するとただちに実行される、1 つの無条件遷移のみを含めることができます。
Identity Manager が使用するプロセスの更新プロセスをカスタマイズするときは、ワークフロープロセスが想定どおりに正しく完了するように、変更内容を検証してから保存してください。保存したら、Identity Manager が使用できるように、変更したワークフローをインポートします。Identity Manager IDE デバッガを使用することもできます。Identity Manager IDE によるワークフロープロセスの編集については、「Identity Manager IDE の使用」を参照してください。
本稼動環境のワークフローの編集
本稼働環境のワークフロープロセスはカスタマイズしないでください。
元のワークフローのインスタンスの実行中にワークフローのアクティビティーやアクションを編集すると、問題が生じることがあります。具体的には、TaskInstance には TaskDefinition ワークフローへの参照が含まれ、ID によって特定される現在のアクティビティーまたはアクションが格納されています。これらの ID を変更すると、実行を再開したときに、想定されているとおりにタスクが再開されない可能性があります。
本稼働環境のワークフローの編集を回避できない場合は、次の手順に従います。これにより、古い定義を使用するタスクインスタンスによって保留されている作業項目の喪失を回避できます。
この手順に従うと、Identity Manager 内で保留状態にある既存の Create User タスクに問題が生じるのを回避できます。この場合、保留中のタスクで参照される、TaskDefinition の一意の ID は維持されます。
標準ワークフローIdentity Manager には、使用されるプロセスにマップされた、標準のワークフローが最初から用意されています。これらのデフォルトワークフローの簡単な説明については、「ワークフローのデフォルトアクティビティー」を参照してください。デフォルトワークフローを表示、編集するには、次の手順に従います。
Identity Manager の管理者インタフェースから「設定」>「フォームおよびプロセスマッピング」を選択すると、プロセスマッピングを表示できます。
デフォルトワークフローの一般的なカテゴリ
プロセスのカスタマイズ1 つまたは複数の Identity Manager のプロセスを変更することで、ステップを削除して新しいステップを設定したり、既存のステップをカスタマイズしたりできます。プロセスの各ステップは、アクティビティーによって表されます。
ワークフローの編集時または作成時に利用できる定義済みアクティビティーを提供するワークフローツールボックスは、ワークフローの変更に役立ちます。
このツールボックスを開くには、ダイアグラムビューを右クリックし、ツールボックスオプションを選択します。
ワークフローのデフォルトアクティビティー
次に、用意されているデフォルトアクティビティーをカテゴリ別に示します。
表 1-4 ワークフローのデフォルトアクティビティー
アクティビティー
説明
Add Deferred Task
延期タスクのスキャナ情報をオブジェクトに追加します。
Audit Object
監査ログレコードを作成します。
Authenticate User Credentials
Authorize Object
リポジトリ内のオブジェクトに対して、対象となる認証をテストします。
Checkin Object
オブジェクトに変更を適用します。
Checkin View
更新されたビューを適用します。
Checkout Object
リポジトリのオブジェクトをロックし、編集のために取得します。
延期タスクのスキャナ情報をオブジェクトに追加します。
Checkout View
更新可能なビューを取得します。
Create Resource Object
リソースオブジェクトを作成します。
Create View
新規ビューを初期化します。
Delete Resource Object
リソースオブジェクトを削除します。
Deprovision Primitive
リソースアカウントをプロビジョニング解除します。
Disable Primitive
リソースアカウントを無効にします。
Disable User
Identity Manager のユーザーアカウント、リソースアカウント、またはその両方を無効にします。
Email Notification
アクションを通知する電子メールを送信します。
Enable Primitive
リソースアカウントを有効にします。
Enable User
Identity Manager のユーザーアカウント、リソースアカウント、またはその両方を有効にします。
Get Object
リポジトリオブジェクトを取得します。
Get Property
プロパティーを取得します。
Get View
読み取り専用ビューを取得します。
List Resource Objects
Query Object Names
一致する属性を持つオブジェクトを検索します。
Query Objects
一致する属性を持つオブジェクトを検索します。
Query Reference
Refresh View
以前にチェックアウトされたビューを更新します。
Remove Deferred Task
延期タスクのスキャナ情報をオブジェクトから削除します。
Remove Property
オブジェクトの拡張プロパティーを削除します。
Reprovision Primitive
リソースアカウントを再プロビジョニングします。
Run Resource Actions
Set Property
拡張プロパティーをオブジェクトに追加します。
Unlock Object
以前にチェックアウトされたオブジェクトのロックを解除します。
Unlock View
以前にチェックアウトされたビューのロックを解除します。
Update Resource Object
リソースによって管理されるオブジェクトを修正します。
表 1-5 Approval ワークフローのデフォルトアクティビティー
アクティビティー
説明
Approval
基本的な単一の承認者プロセスを実行します。
Approval Evaluator
複雑な承認プロセスを実装するために、承認定義オブジェクトの評価を繰り返します。
使用するフォームとテンプレートの受け渡しは許可されますが、別の設定が指定されている場合は、そちらが優先されます。
Lighthouse Approval
割り当てられている組織、ロール、およびリソースの、デフォルトの Identity Manager 承認プロセスを実行します。Approval Evaluator プロセスを使用します。
Multi Approval
複数の承認者に承認を配布します。各承認者の Approval プロセスを使用します。
Notification Evaluator
複雑な通知プロセスを実装するために、承認定義オブジェクトの評価を繰り返します。通常は、Approval Evaluator に定義されている構造と同じ構造です。標準ワークフローでは、承認定義と通知定義は同じ構造にあります。カスタマイズされたワークフローでは、これは要件となりません。
Provisioning Notification
プロビジョニング処理が完了したあとに管理者に通知するための標準プロセス。
表 1-6 User ワークフローのデフォルトアクティビティー
アクティビティー
説明
DeProvision
既存の Identity Manager ユーザーをプロビジョニング解除するための標準ステップを実行します。リソースアカウントの削除、Identity Manager ユーザーの削除、リンク解除、および割り当て解除を詳細に制御できます。個々のリソース操作は、成功するまで再試行されます。
Provision
新しい Identity Manager ユーザーを作成し、リソースアカウントをプロビジョニングする標準ステップを実行します。個々のリソース操作は、成功するまで再試行されます。
Set Password
Identity Manager アカウントとリソースアカウントのパスワードを変更します。
Update User Object
WSUser オブジェクトをチェックアウトし、変更内容を適用してからチェックインします。
Update User View
ユーザービューをチェックアウトし、提供される一連の更新を適用してからチェックインします。
Update View
任意のビューに一連の変更を適用します。
表 1-7 End User ワークフローのデフォルトアクティビティー
アクティビティー
説明
End User Update Groups
マネージャーのいずれかのレポートに割り当てられるリソースのグループ割り当てを更新します (グループをサポートするリソースが対象)。
End User Update My Groups
ログインしているアカウントに割り当てられるリソースのグループ割り当てを更新します (グループをサポートするリソースが対象)。
End User Update Roles
マネージャーのいずれかのレポートのロール割り当てを更新します。
End User Update My Roles
ログインしているアカウントに割り当てられるロール割り当てを更新します。
End User Update Resources
マネージャーのいずれかのレポートの、リソース割り当てと、関連付けられている属性を更新します。
End User Update My Resources
ログインしているアカウントの、リソース割り当てと、関連付けられている属性を更新します。
表 1-8 Compliance ワークフローのデフォルトアクティビティー
アクティビティー
説明
Access Review Remediation
1 つのユーザーエンタイトルメントを操作する 1 人の是正者のための是正。
Attestation
各アテスターの作業項目を作成し、すべての作業項目が承認済みの状態で完了した場合は、ユーザーのエンタイトルメントレコードに APPROVED のマークを付け、いずれかの作業項目が拒否された場合は、その時点でただちに REJECTED のマークを付けます。1 つの作業項目が拒否されると、その他すべての作業項目はキャンセルされます。
Launch Access Scan
Access Review タスクから得られる設定に基づいて、Access Scan タスクを呼び出すか、またはスケジューリングします。このアクティビティーは、Access Review ワークフロー/タスクから直接呼び出されます。
Launch Entitlement Rescan
1 人のユーザーのためにアクセススキャンの再スキャンを起動します。
Launch Violation Rescan
1 人のユーザーのために監査ポリシースキャンの再スキャンを起動します。
Multi Remediation
1 つのコンプライアンス違反と複数の是正者のための是正。
Remediation
1 つのコンプライアンス違反を操作する 1 人の是正者のための是正。
Scan Notification
各アクセススキャンの最後に、保留中のアテステーション作業項目があることをアテスターに通知します。保留中の作業項目の数に関係なく、各アテスターに 1 つの通知を送信します。また、スキャンに所有者が存在する場合は、スキャンの開始と完了をその所有者にも通知します。このワークフローは、次の入力をとります。
scanName -- アクセススキャンの名前
scanOwner -- アクセススキャンの所有者の名前
recipients -- 通知先となる Identity Manager ユーザーの名前リスト
notificationType -- 通知タイプ (begin、end、attest などのタイプが有効)
userCount -- スキャン対象ユーザーの数 (begin のみ)
Standard Attestation
指定された各アテスターのアテステーションサブプロセスを作成します。
Standard Attestation
指定された各アテスターのアテステーションサブプロセスを作成します。
Test Auto Attestation
アテステーション作業項目を作成せずに新しいレビュー決定規則をテストできるようにします。このワークフローは、作業項目を作成せず、開始してすぐに終了するだけです。すべてのユーザーエンタイトルメントオブジェクトは、アクセススキャンによって作成されたときと同じ状態のままです。terminate オプションと delete オプションを使用すると、このワークフローで実行されたアクセススキャンの結果がクリーンアップされます。
Update Compliance Violation
コンプライアンス違反を受け入れます。
スキャンタスク変数
監査ポリシースキャンタスクおよびアクセススキャンタスクのタスク定義には、タスクの開始時に使用するフォームを指定します。これらのフォームには、制御する必要があるスキャンタスク変数の、全部ではないが大部分に対応するフィールドが含まれています。
表 1-9 スキャンタスク変数
変数名
デフォルト値
目的
maxThreads
5
1 つのスキャナで 1 度に作業する同時ユーザー数を指定します。この値を大きくすると、非常に低速なリソース上にアカウントを持つユーザーをスキャンするときのスループットが向上する可能性があります。
userLock
5000
スキャンするユーザーのロックを取得するために消費する時間 (ミリ秒単位) を指定します。1 度に複数のスキャンによって同じユーザーがスキャンされ、そのユーザーのリソースが低速である場合は、この値を大きくすることでロックエラーを減らすことができますが、スキャン全体の速度は低下します。
scanDelay
0
新しいスキャンスレッドを発行する間隔 (ミリ秒単位) を指定します。正の数にすると、スキャナによる CPU 負荷を減らすことができます。
ワークフロータスク
表 1-10
アクティビティー
説明
Add Result
名前を付けたデータ項目をタスク結果に追加します。
Add Result Error
タスク結果にエラーメッセージを追加します。
Add Result Message
タスク結果に情報メッセージを追加します。
Background Task
Identity Manager の管理者インタフェースから呼び出された場合に、ワークフローを強制的にバックグラウンドで実行します。
Get Resource Result
最後のプロビジョニング操作でリソースアダプタから返された結果オブジェクトを取得します。
Get Resource Result Item
最後のプロビジョニング操作でリソースアダプタから返された結果オブジェクトから、1 つの結果項目を取得します。
Rename Task
リポジトリ内のタスクインスタンスの名前を変更します。
Scripted Task Executor
渡されたスクリプトに基づいて BeanShell または JavaScript を実行します。タスクとして定期的に実行するようにスケジューリングできます。たとえば、リポジトリからデータベースにデータをエクスポートして報告や分析を行うときなどに使用できます。カスタム Java コードを作成しなくてもカスタムタスクを作成できることも利点です。カスタム Java コードはアップグレードのたびに再コンパイルし、すべてのサーバーに配備する必要がありますが、スクリプトはタスクに埋め込まれるため、再コンパイルや配備の必要はありません。
Set Result
タスクに入力される結果にエントリを追加します。これは、ワークフローの概要レポートに記載されます。
Set Result Limit
終了したタスクインスタンスをリポジトリ内で維持する時間を、秒単位で指定します。正の値は、タスクの完了後に、その秒数の間だけタスクインスタンスを維持することを表します。
負の値は、タスクインスタンスが自動的に削除されないことを表します。ただし、タスクを手動で削除することは可能です。
デフォルトの名前変更タスクの使用
カスタマイズを行わずにデフォルトの名前変更タスクを使用する場合は、ワークフローに次のアクションを指定します。
<Action process='Rename Task'>
<Argument name='name' value='新しいタスク名'/>
</Action>
ワークフローの進行状況の追跡
タスクに指定されている所有者は、ワークフロータスクの状態を常に確認できます。多くの場合、所有者はタスクを開始した人物ですが、所有者情報を定義し直すことができます。タスクはリポジトリ内のオブジェクトであるため、適切な権限を持つユーザーであれば、誰もがそれを表示できます。
通常、ワークフローの状態は executing、pending、creating、および suspended という文字列で「状態」列に表示されます。ワークフローの状態を要約した、より説明的な文字列をこの列の表示に追加できます。
この機能を実装するには、追加可能な 2 つの式のいずれかを WFProcess ファイルに追加します。
コード例 1-2
<WFProcess name='queryRoleTask' maxSteps='0'>
<Status>
<s>Customized Status</s>
</Status>
<Activity id='0' name='start'>
<Transition to='GetReferencingRoles'/>
</Activity>
<Activity name='GetReferencingRoles'>
<Action id='0'>
<expression>
<Status> には、文字列となる任意の XPRESS ステートメントを設定できます。次に例を示します。
<Status>
<s>カスタム文字列</s>
</Status>
または
<Status>
<block>
<s>表示されない</s>
<s>カスタム文字列</s>
</block>
</Status>
この例の式の結果は、条件が当てはまる結果が保留中の場合に、「状態」列に表示されます (たとえば、pending (カスタムステータス))。
ワークフロープロパティーの設定ワークフローの設定プロパティーは、System Configuration オブジェクトによって制御されます。次の表は、頻繁に使用される設定プロパティーを示しています。
表 1-11 システム設定オブジェクトのワークフロープロパティー
属性名
データ型
デフォルト値
workflow.consoleTrace
String
false
workflow.fileTrace
null
workflow.maxSteps
String
5000
workflow.resultTrace
String
false
workflow.retainHistory
String
false
workflow.traceAllObjects
String
false
workflow.traceLevel
String
1
workflow.validationLevel
String
CRITICAL
serverSetting.default.reconciler
consoleTrace
コンソールにトレースメッセージを送信するかどうかを指定します。true に設定した場合は、トレースメッセージが送信されます。デフォルトは false です。
fileTrace
名前が付けられたファイルにトレースメッセージを送信するかどうかを指定します。特定のファイルにトレースメッセージを送信するには、そのファイルの名前を入力します。
maxSteps
ワークフロープロセスまたはサブプロセスで許容される、最大ステップ数を指定します。このレベルを超過すると、その時点で Identity Manager はワークフローを終了します。この設定は、無限ループによるワークフローのスタックを検出するための安全装置として使用されます。ワークフロー自体に設定されたデフォルト値は 0 です。SystemConfiguration オブジェクトの workflow.maxSteps 属性に格納されたグローバル設定から実際の設定値が抽出されることはずであることを示しています。このグローバル設定の値は 5000 です。
resultTrace
タスクの結果オブジェクトにトレースメッセージを維持するかどうかを指定します。true に設定した場合は、タスクの結果オブジェクトにトレースメッセージが累積されます。
retainHistory
タスクの完了時に、履歴全体を返すかどうかを指定します。true に設定した場合は、Identity Manager は、ケース履歴全体を返します。これは、履歴を分析してプロセスの問題を診断する場合には便利ですが、結果全体のサイズが大きくなります。
traceAllObjects
汎用オブジェクトをワークフローのトレース処理の対象とするかどうかを指定します。
traceLevel
ワークフローのトレースに含める詳細度を指定します。値を指定しないか、または 0 を指定した場合は、もっとも詳細な情報がトレースされます。デフォルトは 1 です。
validationLevel
実行前にワークフローの検証に適用される厳密度を指定します。設定したレベル以上のエラーが検出された場合は、ワークフローの実行は開始されません。有効な値は、CRITICAL、ERROR、WARNING、または NONE です。NONE を指定した場合は、検証を完全に無効にします。
デフォルトは CRITICAL です。
serverSettings.default.reconciler 属性
次の 2 つの調停サーバー属性を使用して、アカウント単位ワークフローを調整できます。
これら 2 つの値の積が、ユーザーのアカウント単位ワークフローが成功するのに必要な時間より大きくなるようにしてください。この間隔の間に、調停サーバーの内部でロック競合の問題が解決されます。
次の例を考えてみましょう。
再試行に消費される合計時間は 15 秒 (3 x 5000 ミリ秒) です。
再試行に消費される合計時間 (15 秒) が 30 秒より小さいため、この設定は最適ではありません。この例のユーザーは、lockwaitThreshold と maxRetries の値を大きくして、その積がアカウント単位ワークフローの合計時間より大きくなるようにするべきです。
ワークフローサービスの使用Identity Manager には、ユーザーアカウントのプロビジョニングと操作を目的とするプロセスを定義するために、デフォルトワークフローが用意されています。Identity Manager をカスタマイズするときは、これらのワークフローを変更して、配備環境に固有のビジネスルールを反映することができます。ワークフローを使用することで、アカウントプロビジョニングに関する独自のビジネスルールを Identity Manager に実装できます。
ここでは、ワークフローサービスに関連する次のトピックの概要について説明します。
特定のワークフローメソッドについては、<distribution>¥REF¥javadoc (<distribution> はインストールディレクトリ) を参照してください。
メソッドのコンテキストについて
Lighthouse コンテキストは Identity Manager リポジトリにアクセスするための認証済みセッションを表現しているので、可視性およびアクションの制限を適用するための認証チェックが必要となります。ユーザーやその他の Identity Manager オブジェクトを作成、変更、および削除するには、リポジトリプロビジョニングツールへの認証済みアクセス権が必要になります。このアクセス権は、コンテキストオブジェクト (通常は LighthouseContext または WorkflowContext) によって確立されます。これらの各コンテキストオブジェクトには、呼び出し側にリポジトリへのアクセス権を与える認証済みセッションオブジェクトが含まれています。
ログインした環境 (Web ブラウザ内) のコンテキストで操作しているときのコンテキスト (セッション) はかなり単純です。しかし、Identity Manager の内部では、ワークフロープロセスはブラウザセッションから独立した別個のプロセス (実際には TaskInstance) であるので、Identity Manager リポジトリにアクセスする必要があります。これは、実行中のワークフローのアクティブコンテキストはワークフローの開始時に割り当てられ、ワークフローが中断しても保持され再開時に復元されるためです。
ユーザーが (通常は WorkItem または ManualAction で) ワークフローと対話するときは、ワークフロー独自のコンテキストは保持されます。作業項目と対話するユーザーのコンテキストは想定されていません (ユーザーには、作業項目への適切なアクセス権を与えるコンテキストが必要です)。作業項目と対話するユーザーがフォームを読み込むと、Identity Manager はワークフローのコンテキストではなく、ユーザーのコンテキストでフォームを処理します。より正確に言えば、作業項目と対話するユーザーはワークフローとはまったく対話しません。ユーザーは作業項目とだけ対話します。ユーザーが作業項目を変更したあとは、スケジューラが必要に応じてワークフローを再起動します。
ワークフローの組み込み変数
ワークフローエンジンは、いくつかの組み込み変数を使用します。これらの変数のほとんどは、ワークフロー内で宣言する必要はありません。しかし、組み込み変数はワークフローの実行状態を確認するために使用できます。また、多くの変数は、ワークフローサービスの影響を受けて設定されます。
表 1-12 ワークフローの組み込み変数
名前
説明
WF_ACTION_ERROR
この組み込み変数は、直前に実行されたアクションがエラーを含む結果を返したり例外をスローしたりした場合に true に設定されます。
WF_ACTION_RESULT
この組み込み変数には、直前のアクションから返される WavesetResult オブジェクトが設定されます。この変数は、アクションの WavesetResult を取り込み、それをグローバル TaskInstance の結果に追加せずに処理したい場合に使用します。この変数はもともと、リソースの再試行をサポートするために追加されました。再試行のたびにタスク結果にリソースのエラーメッセージを追加することは必ずしも望ましくはないためです。あまり頻繁に使用される変数ではありませんが、アクションの結果をタスク結果に追加する前に調整する場合には便利です。
WF_ACTION_SUPPRESSED
この組み込み変数は、<Condition> 式の評価が false であるためにアクションが実行されない場合に true に設定されます。
WF_ACTION_TIMEOUT
この組み込み変数は、直前に実行されたアクションがタイムアウトになった場合に true に設定されます。
WF_CASE_OWNER
この組み込み変数には、ワークフロータスクを呼び出した管理者の名前が設定されます。
WF_CASE_RESULT
この組み込み変数には、TaskInstance の WavesetResult が設定されます。これは XPRESS または JavaScript で実装されるアクションにおいて結果を取得するために使用されます。WorkflowApplication クラスとして実装されるアクションは WorkflowContext を経由して結果を取得することが可能です。WorkflowContext の全体は WF_CONTEXT 変数を使って参照できるため、この変数は絶対に必要であるとは言えませんが、便利ではあります。
WF_CONTEXT
この組み込み変数には、WorkflowContext オブジェクトが設定されます。これは XPRESS または JavaScript で実装されるアクションにおいて WorkflowContext を取得するために使用できます。WorkflowApplication クラスとして実装されているアクションに対して、コンテキストが渡されます。
一般的なセッションワークフローサービスの呼び出しの構造
ワークフローの内部には、制御の流れと変数の範囲の両方を制限する階層構造があります。ワークフローは Case または WFCase とも呼ばれ、ワークフローアクティビティーのリストが含まれています。ワークフローアクティビティーには、Action 要素のリストが含まれます。WFCase で宣言される変数は、すべての Activity 要素および Action 要素で参照できます。color という名前の変数を WFCase レベルで宣言し、同時に Action でも宣言した場合、これらは実質的に異なる 2 つの変数です。たとえば、Action 内の color 変数の値を変更しても、WFCase の color 変数の値には影響しません。
ワークフローサービスは、ワークフローアクションから呼び出されます。WorkflowServices は、op 引数の値によって選択された一連の操作を提供します。各操作の引数はそれぞれ異なるため、呼び出し側の「署名」が指定されたサービスと一致する必要があります。次のコード例は、ワークフローサービスアクションの一般的な形式を示しています。
<Action class='com.waveset.session.WorkflowServices'>
<Condition/>
<Argument name='op' value=workflowServiceOp/>
<Argument name=argname1>
<expression>value1expression</expression>
</Argument>
<Argument name=argname2>
<expression>value2expression</expression>
</Argument>
<Argument name=argnameN>
<expression>valueNexpression</expression>
</Argument>
</Action>
サポートされる各ワークフローサービスには、それぞれ異なる数の、必須および省略可能な引数があります。セッションワークフローサービスの呼び出しに渡す op 引数には、提供されているサービスのいずれかを指定する必要があります。これは、リフレクションによるメソッド呼び出しに似ています。ここでは、呼び出されるメソッドの名前が、実行されるワークフローサービスの名前に相当します。
後続のリストにない op 引数が渡された場合、ワークフローサービスは次の結果を返します。
'Unknown WorkflowServices op'
また、ワークフローコンテキスト変数 WF_ACTION_ERROR は、NULL 以外の値に設定されます。
先行のリストにない op 引数が渡された場合は、ワークフローサービスは次の結果を返します。
'Unknown WorkflowServices op'
また、ワークフローコンテキスト変数 WF_ACTION_ERROR は、NULL 以外の値に設定されます。
プロビジョンワークフローサービス
com.waveset.provision.WorkflowServices クラスにもサービスのセットがありますが、これらのサービスは com.waveset.session.WorkflowServices のメソッドほど使用頻度が高くありません。これらのサービスは、アカウント管理を実行するための低レベルの基本サービスで、主にデフォルトワークフローによって呼び出されます。カスタムワークフローでは、これらのサービスを使用することもできますが、checkoutView と checkinView によってより高レベルのビューを使用し、これらのビューから標準のワークフローを起動することもできます。
プロビジョンサービスの主な目的は、プロビジョニングツールへのアクセス権をワークフローに与えることで、リソースおよびリソースアカウントにアクセスできるようにすることです。これらのサービスは、リソースそのものに実際に読み込み/書き込み操作を実行します。
一般的なプロビジョンワークフローサービスの呼び出しの構造
ワークフローの内部には、制御の流れと変数の範囲の両方を制限する階層構造があります。ワークフローは Case または WFCase とも呼ばれ、ワークフローアクティビティーのリストが含まれています。ワークフローアクティビティーには、アクションのリストが含まれています。WFCase で宣言される変数は、すべての Activity 要素および Action 要素で参照できます。「color」という名前の変数を WFCase レベルで宣言し、同時にアクションでも宣言した場合は、実質的に 2 つの異なる変数が存在することになります。たとえば、アクション内の「color」変数の値を変更しても、WFCase の「color」変数の値には影響しません。ワークフローサービスは、ワークフローアクションから呼び出されます。WorkflowServices は、「op」引数の値によって選択された一連の「操作」を提供します。各操作の引数はそれぞれ異なる可能性があるため、呼び出し側の「署名」がサービスと一致する必要があります。次のコード例は、セッションワークフローサービスアクションの一般的な形式を示しています。
<Action class='com.waveset.provision.WorkflowServices'>
<Condition/>
<Argument name='op' value=workflowServiceOp/>
<Argument name=argname1>
<expression>value1expression</expression>
</Argument>
<Argument name=argname2>
<expression>value2expression</expression>
</Argument>
...
<Argument name=argnameN>
<expression>valueNexpression</expression>
</Argument>
</Action>
サポートされる各ワークフローサービスには、それぞれ異なる数の、必須および省略可能な引数があります。
サポートされるプロビジョンワークフローサービス
次のリストは、Identity Manager が現在サポートしているプロビジョンワークフローサービスを示しています。ワークフローサービスの呼び出しに指定する op 引数は、次のいずれかの値である必要があります。
表 1-13
プロビジョンワークフローサービス
説明
approve
ユーザーアカウントの承認を記録します。
auditNativeChangeToAccountAttributes
リソースアカウントの 1 つまたは複数の監査可能属性に加えられたネイティブ変更のレポートを生成します。
authenticateUserCredentials
パスワードを使用して、リソースに対しユーザーを認証します。
bulkReprovision
このメソッドは、クエリーのセットを実行し、指定した条件と一致するすべてのユーザーを検索します。その後、このリストを繰り返し、ユーザーを一度に再プロビジョニングします。
changeResourceAccountPassword
1 つまたは複数のリソースアカウントのパスワードを変更します。
checkDeProvision
削除前に、アカウントがプロビジョニング解除を必要とするかどうかを調べます。
cleanupResult
タスク結果から NULL の ResultError を削除します。このメソッドは、引数として op をとります。有効な値は、cleanupResult です。
createResourceObject
リソースオブジェクト (たとえば、グループ) を作成します。
deleteResourceAccount
リソースアカウントを削除します。
deleteResourceObject
リソースオブジェクト (たとえば、グループ) を削除します。
deProvision
Identity Manager アカウント、リソースアカウント、またはその両方を削除します。
deleteUser
Identity Manager ユーザーを削除します。
disable
Identity Manager アカウント、リソースアカウント、またはその両方を無効にします。
enable
Identity Manager アカウント、リソースアカウント、または両方を有効にします。
getApprovals
既存のアカウントに割り当てられたロール、組織、およびリソースの承認のリストを決定します。
getApprovers
lockOrUnlock
指定されたユーザーに関連付けられている Lighthouse アカウントポリシーがロックの有効期限の時刻を指定している場合に、そのユーザーをロックまたはロック解除します。
notify
通知を送信します。ほとんどの場合は、電子メールが使用されます。
provision
新しい Identity Manager アカウントと、(オプションとして) リソースアカウントを作成します。
questionLock
ユーザーをロックしますが、ロックの有効期限の日時は設定しません。
reject
リソースアカウントの却下を記録します。
reProvision
既存の Identity Manager アカウントを更新します。
runResourceAction
リソースの指定されたリソースアダプタに対して、リソースアクションを実行します。
updateResourceObject
unlinkResourceAccountsFromUser
validate
op 引数に上記以外の値を指定した場合、ワークフローサービスは次の結果を返します。
'Unknown WorkflowServices op'
また、ワークフローコンテキスト変数 WF_ACTION_ERROR は、NULL 以外の値に設定されます。
ビュー操作メソッドについて
ほとんどのワークフロー処理にはビューが使用されます。このため、ワークフローで使用されるビュー関連のメソッドでもっともよく使用されるのは checkoutView メソッドと checkinView メソッドになります。ビューオブジェクトをチェックアウトすると、基本となるオブジェクトがロックされ、ほかのユーザーが書き込めなくなります。これは、ワークフロー処理では特に重要です。ワークフローがユーザーをチェックアウト (ロック) し、手動アクションのために処理を中断すると、手動アクションが完了するまで (数時間後または数日間後の可能性がある) そのユーザーがロックされたままになる可能性があるためです。デフォルトでは、オブジェクトに対するロックの有効期限は 5 分であり、これがワークフローに関する 2 つ目の懸念事項です。オブジェクトをチェックインするには、オブジェクトが呼び出し側によってすでにロックされている必要があります。したがって、ワークフローがビューをチェックアウトし (暗黙的にオブジェクトがロックされる)、処理を 10 分間中断してからビューをチェックインすると、10 分間が経過して呼び出し側のロックがすでに終了しているため、ワークフローが失敗します。
次の例は、一般的なチェックアウト操作を示しています。
コード例 1-3
<Action id='-1' application='com.waveset.session.WorkflowServices'>
<Argument name='op' value='checkoutView'/>
<Argument name='type' value='User'/>
<Argument name='id' value='mfairfield'/>
<Variable name='view'/>
<Return from='view' to='user'/ >
</Action>
チェックアウトおよびチェックイン呼び出しとオプションのマップの使用
チェックアウトおよびチェックイン呼び出しのオプション引数として (UserViewConstants クラスの一部として定義される)、どのオプションを使用できるかを判断するのが難しいことがあります。Javadoc には、次の形式でオプションが記載されています。
OP_TARGETS
OP_RAW
OP_SKIP_ROLE_ATTRS
Identity Manager では、オプションを確認するときにこれらのリテラル文字列をコードにハードコードする代わりに、コード全体で使用できるように文字列を表現する定数が用意されています。これはよいコーディング手法ですが、XPRESS やワークフローでは UserViewConstants の静的フィールド (OP_TARGET_RESOURCES など) を参照できません。
正しい値を渡すことができる有効な文字列であることを調べるために、正しい文字列であることを確認するためテスト規則を作成できます。たとえば、次の規則は TargetResources を返します。
コード例 1-4
<block>
<set name='wf_srv'>
<new class='com.waveset.provision.WorkflowServices'/>
</set>
<script>
var wfSvc = env.get('wf_srv');
var constant = wfSvc.OP_TARGETS;
constant;
</script>
</block>
この規則は文字列を調べるのに便利ですが、すべての呼び出しに同じ文字列を返すため、本稼働配備には適していません。この問題を最小限に抑えるため、ビュー処理に使用される Identity Manager 定数が変更されることはありません。定数をワークフローにコーディングしたあとは、リリースが異なっても、ビューによるその定数の解釈は変わりません。
有効な文字列であることがわかったら、ビューのチェックアウト呼び出しを次のように更新できます。このコードでは、Identity Manager および Active Directory に変更が反映されるだけのビューがチェックアウトされます。
コード例 1-5
<Action id='-1' application='com.waveset.session.WorkflowServices'>
<Argument name='op' value='checkoutView'/>
<Argument name='type' value='User'/>
<Argument name='id' value='mfairfield'/>
<Argument name='options'>
<map>
<s>TargetResources</s>
<list>
<s>Lighthouse</s>
<s>AD</s>
</list>
</map>
</Argument>
<Variable name='view'/>
<Return from='view' to='user'/ >
</Action>
ベストプラクティス
パフォーマンス上の観点から、可能な場合はユーザービューのサイズを制限することをお勧めします。ビューを小さくすると、リソースから取得されてネットワークに送信されるデータが少なくなります。ビューはワークフロー内に変数として保持されるため、ワークフロータスクが中断されるたびに TaskInstance オブジェクトにビューを書き込む必要があります。システムが数千個のワークフローを同時に実行していて、各ワークフローに大きなビューがある場合は、リポジトリとの間でビューを転送するのにかかる時間 (直列化および非直列化を含む) が大きなボトルネックになります。
ビューの最適な使用方法は、ユーザーへの変更をインテリジェントに実行して承認するために必要なデータだけを保持することです。呼び出し側の目的が一連のリソース上にあるユーザーのパスワードを変更することである場合は、このプロセスを実行する上で知る必要があるものは、そのユーザーに関連付けられたアカウントのリストだけです。通常、このプロセスに特定のアカウントのデータは必要ありません。
シナリオ例 1
ある顧客が、ユーザーが特定のリソースへのアクセスを要求できるようなカスタムワークフローを実装することにしました。このワークフローは、適切な承認が得られるまでの間、変更を送信できるようにユーザービューをチェックアウトするはずです。この例では、取得する必要がある情報はビューの Identity Manager ユーザー部分だけで、waveset.resources リストおよび accountInfo オブジェクトがそれに合わせて更新されるようです。このような場合は次のようにして、ユーザービューをチェックアウトするときに TargetResources オプションを使用して、ユーザービューの Identity Manager ユーザー部分とオプションマップだけがチェックアウトされるようにします。
作業項目ビューでは、ユーザービューのサイズを小さくできます。作業項目とは、承認、委任、ユーザーが追加情報を入力するためのワークフロー内での中断などの、個人に割り当てられたタスクを表現するオブジェクトのことです。カスタムワークフローでは手動アクションによって、承認が作成され、フォームとの対話が行われます。手動アクションとは、簡単にいえば、現在の <ManualAction> 要素の範囲内にあるすべてのワークフロー変数をコピーすることです。タスクのコンテキストだけでなく、WorkItem オブジェクト内の変数オブジェクトにコピーします。承認に関して、完全なユーザービューやコンテキスト変数が必要になることはほとんどありません。このため、ManualAction を定義するときに ExposedVariables 引数を指定することにより、WorkItem のサイズを小さくすることを検討してください。
<Exposed Variables> 要素により、後続処理の作業項目に取り込む必要がある変数がワークフローに正確に伝わります。1 つのワークフローが複数の承認者をサポートする場合は、承認者ごとに 1 つ、複数の作業項目が作成されることに注意してください。ワークフローに 10 人の承認者がいれば、メモリーが 100K バイトずつ消費されてゆき、すぐに実際のメモリー量を検討することになります。
シナリオ例 2
前述のシナリオは、手動アクションが 1 つだけの比較的単純な実装を示しています。しかし、一般的な配備にはより複雑なシナリオが必要になります。たとえば、ある顧客は、ユーザーが作成されると承認を「バケット」に入れ、約 25 人の承認者のいずれかが承認を選択できるようにする必要があります。バケットを模倣するには、バケット内に承認者ごとの作業項目を作成します。承認者が行う作業は、アクションの受け入れだけです。受け入れが終わると、Identity Manager は残りの 24 個の作業項目を破棄することができ、バケット要求を受け入れた承認者の実際の承認作業項目を生成します。
エスカレーション層として機能する 3 つのバケットがあるとします。バケット 1 で承認が処理されると、Identity Manager は新しい要求をバケット 2 にエスカレーションし、再びこのプロセスが始まります。このプロセスにより、バケット 1 つあたりおよそ 26 (25 + 1) 個の作業項目が作成され、3 つのバケットで 3 倍になります。1 つのユーザー要求によって作成される作業項目は 78 個で、しかもすべて一度に作成されるとは限りません。しかし、500,000 人規模のユーザーベースを持ち、各ユーザーがこれらの要求を毎日数百個も作成する配備環境でこれが発生することを考えてください。このシナリオの実装者が ExposedVariables 引数を使用して WorkItem ビューのサイズを慎重に決定しないと、大量の不要なデータが作業項目に格納され、JDBC 接続を介して渡されることになります。
コード例 1-7
<Activity id='0' name='activity1'>
<ManualAction id='-1'>
<FormRef>
<ObjectRef type='UserForm' name='Access Review Abort Confirmation Form'/>
</FormRef>
<ExposedVariables>
<List>
<String>user.waveset.accountId</String>
<String>user.waveset.resources</String>
<String>user.accounts[Lighthouse].idmManager</String>
<String>user.accounts[Lighthouse].fullname</String>
</List>
</ExposedVariables>
<ViewVariables>
<List>
<String>user</String>
</List>
</ViewVariables>
</ManualAction>
<WorkflowEditor x='53' y='111'/>
</Activity>
シナリオ例 3
ユーザープロビジョニング要求のカスタムワークフローを作成し、ユーザーが実行できるようにする必要があります。このタイプのワークフローは、部下のプロビジョニング要求をマネージャーに送信させ、かつ組織内のすべてのマネージャーを Identity Manager 管理者にしないことを希望する顧客のときにお勧めします。
これらの要件に留意して、次のようなカスタムワークフローを作成します。
ビューも更新する必要があります。ビューを更新すると、Identity Manager は割り当てられているリソースの情報を再検査し、ネイティブリソースからその情報を再取得して、最新の情報でユーザービューを更新します (ビューがチェックアウトされてから変更されている場合)。
Identity Manager でビューが確実に更新されるようにするために、手動アクション内の ViewVariables 要素に、Identity Manager が作業項目の variables オブジェクトに含まれるどの変数をビューとして扱い、要求時に更新すべきかを指定します。変数 user を ViewVariable として指定する例については、前述の例を参照してください。
ワークフローの監査の有効化ワークフローの監査は、通常の監査と類似していますが、ワークフローの監査では、時刻を計算するための追加情報も記録されます。通常の監査では、イベントの発生をレポートしますが、イベントがいつ開始され、終了したのかは示されません。Identity Manager の監査の詳細については、『Identity Manager 管理ガイド』を参照してください。
ワークフロー監査の処理では、事前に定義されている属性の名前とその値が、監査対象イベントごとに記録されます。この機能を使用してワークフロー、プロセス、およびアクティビティーの最初と最後に auditWorkflow イベントを配置することによって、ワークフローを計測することができます。
注
ワークフローまたはプロセスを計測するときに、終了アクティビティーにイベントを配置することは許可されていません。最後の auditWorkflow イベントを実行してから終了イベントに無条件に遷移する、終了前アクティビティーを作成する必要があります。
ワークフローの監査を有効にするには、ワークフロー、または 1 つまたは複数のワークフローアクティビティーに、audit 属性を追加します。この属性を追加し、管理者インタフェースの適切なタスクテンプレートで「ワークフロー全体の監査」ボックスにチェックマークを付けることで、ワークフローの監査が有効になります。タスクテンプレートで監査を有効にする手順については、『Identity Manager 管理ガイド』の「タスクテンプレート」の章を参照してください。
また、auditWorkflow イベントのペアリングを可能にするために auditconfig.xml ファイルに定義されている次のアクションに、適切な値を渡す必要があります。追加のアクションを定義してもかまいません。
次の呼び出し例は、呼び出し側から渡す必要のある情報だけを示しています。
<Action application=苗om.waveset.session.WorkflowServices��gt;
<Argument name=賓p��value=病uditWorkflow��>
<Argument name=病ction��value=百tartWorkflow��>
</Action>
ワークフロー監査の処理では、事前に定義されている属性の名前とその値が、監査対象イベントごとに記録されます。ワークフロー内の監査を有効にするには、WFProcess 要素、あるいは 1 つまたは複数の Activity 要素に、audit 属性を値 true で追加します。WFProcess レベルで属性を設定すると、ワークフロー全体が監査対象となり、個々の Activity 要素に属性を追加した場合は、特定のアクティビティーのみが監査対象となります。監査属性を設定しない場合、監査は無効になります。また、ワークフローを呼び出すタスクテンプレート内でも監査を有効にする必要があります。
記録される情報と記録される場所
デフォルトでは、ワークフローの監査は、通常の監査イベントで記録されるほとんどの情報が収集されます。これには、次の属性が含まれます。
これらの属性は、logattr テーブルに格納され、auditableAttributesList から取得されます。
Identity Manager は、workflowAuditAttrConds 属性が定義されているかどうかについても調べます。
プロセスまたはワークフローの 1 つのインスタンスの中で、特定のアクティビティーを何度も呼び出すことができます。特定のアクティビティーインスタンスの監査イベントを一致させるために、Identity Manager は、ワークフローインスタンス内の一意の識別子を logattr テーブルに記録します。
ワークフローの logattr テーブルに追加属性を記録するには、workflowAuditAttrConds リスト (GenericObjects のリストと見なされる) を定義する必要があります。workflowAuditAttrConds リストに attrName 属性を定義すると、Identity Manager は、コード内のオブジェクトから attrName を抽出します。まず、attrName をキーとして使用し、次に、attrName の値を記録します。すべてのキーと値は、大文字の値として記録されます。
アプリケーションの追加Identity Manager IDE からアクセスできるように、独自に用意した Java メソッドを登録できます。次の手順で実行します。
- idm/config/workflowregistry.xml ファイルを編集します。
- 次の例のような形式で、アプリケーションの定義を追加します。
<WorkflowApplication name='Increment Counter'
class='com.waveset.util.RandomGen' op='nextInt'><ArgumentDefinition name='start' value='10'>
<Comments>Get the next counter</Comments>
</ArgumentDefinition>
</WorkflowApplication>- Identity Manager IDE を再起動します。
アプリケーションメニューに新しいアプリケーションが追加されます。
