11 ワークフローの開発
この章では、Oracle Identity Managerのワークフローの概念、機能およびアーキテクチャについて説明します。ワークフローのユースケース、最初のワークフローの設計、実装およびデプロイの手順を示します。また、この章ではプラグイン・ポイントを使用してリクエスト管理操作を拡張する方法と、証明およびアイデンティティ監査コンポジットをカスタマイズする方法を説明します。
この章のトピックは、次のとおりです:
11.1 ワークフローの概要
ワークフローは、承認リクエストをルーティングし、手動のプロビジョニング・タスクをITプロビジョナまたはヘルプ・デスク履行にルーティングするために使用します。
この項では、主なワークフローの概念について、次の各トピックで説明します。
11.1.1 ワークフローの概要
ユーザー・アクセスを管理し、ビジネス・プロセスを編成して、ユーザーが適切なアクセス権を取得できるようにすることが、アイデンティティ制御の主要機能となります。
ユーザーのアクセスを変更するプロセスは、ポリシーをトリガーするHRのイベントを介してユーザーが開始するか、または管理者が開始することができます。アクセスの変更がどのように開始されるかに関係なく、組織には次の要件があります。
-
開始されるビジネス・プロセスは柔軟で、組織の変化するビジネス・ルールに適合できる必要があります。
-
ビジネス・プロセスでは、即時アクセス権を付与するか、アクセス権を付与する前に手動操作のステップを導入して承認を求めるかを決定できる必要があります。
-
ビジネス・プロセスは、リクエストされた内容、リクエスト者、リクエストの対象者およびコンテキストに関する職務の分離(SoD)チェックなど、検証を実行できる必要があります。
-
手動操作が必要な場合、ビジネス・プロセスには、ユーザーまたはユーザー・グループに割り当てる機能、および応答がタイミングよく受信されなかったときにエスカレーション、再割当てまたは期限切れの処理を行う機能が必要です。
-
手動操作の場合、ビジネス・プロセスには、承認者から、コメントや添付などの情報を収集する機能が必要です。
-
アクセス権の自動付与が不可能な場合、または組織のルールによって手動によるアクセス権付与が必要な場合、ビジネス・プロセスでは、外部システム(チケット発行システムなど)と対話できる必要があります。
-
すべての決定およびアクションを監査し、報告可能な方法で利用可能にして、組織がプロセスのパフォーマンスを計測したり、監査者がコンプライアンス要件を満たすことができるようにする必要があります。
Oracle Identity Managerでは、組織がこれらの要件を満たすことができる、柔軟かつ強力なアクセス・リクエスト機能が提供されています。
11.1.2 ワークフローの概念
ワークフローに関連する基本概念は、リクエスト、承認、承認ワークフロー・ポリシー、SOAコンポジット、パートナ・リンク、BPELプロセス、ITプロビジョナ、リクエストWebサービス、リクエスト・コールバック、プロビジョニング・コールバック、リクエスト・ペイロードおよびヒューマン・タスクです。
Oracle Identity Managerのワークフローの主要概念として、次のような用語があります。
-
リクエスト
Oracle Identity Managerでは、リクエストは、あるアイデンティティまたはアカウントで操作を実行する必要がある場合に起動されるビジネス・プロセスを指します。これらの操作の例として、ユーザーの作成、アカウントのプロビジョニング、ユーザーへのロールの付与があります。リクエストには、すぐに履行可能な場合(直接的な操作)と、承認の形式で手動操作が必要な場合(リクエストベースの操作)があります。ユーザーが操作を実行しようとすると、Oracle Identity Managerは、その操作が直接的であるか、ログイン中のユーザーの認可ポリシーに基づくリクエストベースであるかを確認します。
-
承認
リクエストは1レベルの承認を通過します。これは、対応する操作のワークフロー・ポリシーで構成されます。
バルク・リクエストは1レベルの承認を通過します。これは、対応するバルク操作のワークフロー・ポリシーで構成されます。承認後に、子リクエストが生成されます。これらの子リクエストは、単純リクエストと同じ承認プロセスに従います。
-
承認ワークフロー・ポリシー
承認ワークフロー・ポリシーは、リクエスト・エンジンがSOAコンポジット選択して呼び出せるようにする、管理者が構成したルールから構成されます。承認ワークフロー・ポリシーで定義されたルールを使用して、リクエスト・エンジンは、そのリクエストを自動承認するのか、SOAコンポジットを起動する必要があるのかを決定します。
-
SOAコンポジット
SOAコンポジットは、単一のアプリケーション内に一括して設計されデプロイされた複数のサービス、サービス・コンポーネントおよび参照の集合です。このサービス、サービス・コンポーネントおよび参照間のワイヤリングによってメッセージ通信が可能となります。コンポジットにより、メッセージに記述された情報が処理されます。
-
パートナ・リンク
パートナ・リンクを使用すると、BPELプロセス・サービス・コンポーネントと対話する外部サービスを定義できます。パートナ・リンクは、SOAコンポジット・エディタまたはOracle BPELデザイナのBPELプロセス・サービス・コンポーネント内にサービスまたは参照(JCAアダプタ経由など)として定義できます。
-
BPELプロセス
BPELプロセスは、プロセスの編成と、同期または非同期プロセスの保存に使用されます。一連のビジネス・アクティビティとサービスをエンドツーエンドのプロセス・フローに統合するビジネス・プロセスを設計します。
-
ITプロビジョナ
ITプロビジョナは、履行ユーザーまたはヘルプ・デスク・ユーザーとも呼ばれ、手動のプロビジョニング・リクエストの履行を担当する人です。
-
リクエストWebサービス
リクエストWebサービスは、Oracle Identity Managerに付属するWebサービスです。顧客がリクエスト、ユーザー、ロール、組織、アカウント、権限、アプリケーション・インスタンスおよびカタログ情報を公開できるようにし、承認ワークフローによってデータ・ドリブンのルーティング決定が実行されるようにします。
-
リクエスト・コールバック
リクエスト・コールバックは、承認結果(承認/拒否)の受信時にSOAコンポジットによって起動されるWebサービスです。リクエスト・エンジンは、承認の目的でSOAコンポジットを起動すると、このコンポジットがリクエスト・コールバックを起動して承認または拒否の決定を提供するまで、リクエストを一時停止します。この決定によって、リクエスト・エンジンは、リクエストの履行(承認された場合)、リクエストの拒否(拒否された場合)に進むことができます。
-
プロビジョニング・コールバック
プロビジョニング・コールバックは、接続なしのプロビジョニングの一部として起動されるWebサービスです。ITプロビジョナまたは履行ユーザーが、接続なしのプロビジョニング・リクエストを履行し、タスクを完了とマークすると、SOAコンポジットはプロビジョニング・コールバックを起動して、プロビジョニング・ワークフローの完了を許可するプロビジョニング・ステータスを送信します。
-
リクエスト・ペイロード
リクエスト・エンジンはSOAコンポジットを起動して、それにリクエスト、リクエスタおよびターゲット・ユーザーに関するいくつかの基本情報を渡します。この情報をリクエスト・ペイロードと呼びます。
-
ヒューマン・タスク
ヒューマン・タスクにより、ユーザーまたはグループが、エンドツーエンドのビジネス・プロセス・フローの一環として実行するタスクを記述するワークフローのモデリングが提供されます。
11.1.3 ワークフローのアーキテクチャ
ワークフロー・アーキテクチャに関わるコンポーネントは、認可ポリシー、Business Process Execution Language (BPEL)プロセス、ヒューマン・タスク、およびリクエストの承認または却下です。
ワークフローは、Oracle Identity Managerで次の目的に使用されます。
-
承認のために、承認者にリクエストをルーティングする
-
履行のために、ITプロビジョナまたはヘルプ・デスクに手動のプロビジョニング・タスクをルーティングする
図11-1に、Oracle Identity Managerのワークフローの概要を示します。
ヒューマン・タスクの完了に関わるステップについては、ヒューマン・タスク・プロセス・フローを参照してください。
11.1.4 ヒューマン・タスク・プロセス・フロー
ヒューマン・タスクの完了には、様々なユーザー開始アクション、リクエスト作成、承認ワークフロー・ポリシー、SOAコンポジット、人手の介入が必要かどうか、リクエストの承認または却下が含まれています。
ヒューマン・タスクを完了するまでには、図11-1に示すように、次のアクションが発生します。
-
ユーザーは、結果としてリクエストになる操作を開始します。そのような操作の例を次に示します。
-
自己登録
-
ユーザー・プロファイルの変更(ただし、ロックの、ロック解除およびパスワードの管理操作を除く)
-
ロール付与操作
-
アプリケーション・インスタンス操作(接続なしのプロビジョニングを含む)
-
権限操作
-
バルク操作
-
-
リクエストが作成されます。適切な検証の後に、リクエスト・エンジンは承認ワークフロー・ポリシーを評価し、起動するSOAコンポジットを選択します。
-
承認ワークフロー・ポリシーが構成されていない場合は、デフォルトのSOAコンポジットが承認に対して選択されます。
-
SOAコンポジットには、Business Process Execution Language (BPEL)プロセスが含まれています。
-
BPELプロセスは、Webサービスを起動して、リクエストに関する次のような詳細を取得します。
ノート:
このステップはオプションです。これは、BPELプロセスで様々なエンティティに関連する追加情報が必要な場合にのみ、必要です。
-
カタログからの項目の詳細
-
ターゲット・ユーザー情報
-
リクエスタ情報
-
-
BPELプロセスは、優先度、承認者および通知などのプロパティを計算するために、追加のロジックを起動します。
-
承認および手動の履行中など、手動操作が必要な場合、プロセスはヒューマン・タスクを起動します。
ヒューマン・タスクには、ユーザーまたはロールに対して承認タスクの割当て、期限切れ、エスカレーションを実行するためのロジックが含まれます。ヒューマン・タスクは、ユーザーおよびロールを静的または動的に割り当てることができます。静的割当ての場合、BPELプロセスで承認者を決定し、パラメータとしてヒューマン・タスクに渡すことができます。動的割当ての場合、Oracle Business Rules (OBR)で作成されたルールを使用して、承認者が動的に決定されます。
通常、BPELプロセスには1つのヒューマン・タスクが含まれます。インスタンスによっては、BPELプロセスで複数のヒューマン・タスクのうちの1つを選択するデシジョン・ポイントが起動される場合があります。
-
ヒューマン・タスクが完了すると、(承認の)承認または拒否のレスポンス、あるいは(手動履行の)完了のレスポンスが、Oracle Identity Managerへのコールバック・サービスを介して戻され、操作が再開されます。
11.2 事前定義済SOAコンポジット
事前定義済SOAコンポジットを承認プロセスとして使用できます。
表11-1に、承認プロセスとして使用可能なOracle Identity Managerにおける事前定義済SOAコンポジットを示します。
表11-1 事前定義済ワークフロー・コンポジット
ワークフロー・コンポジット | 説明 |
---|---|
DefaultRequestApproval |
デフォルトのリクエスト・レベルの承認。デフォルトでは、リクエスト・レベルの承認の場合、SYSTEM ADMINISTRATORSロールに送信されます。 さらに、このコンポジットが証明ユースケースによって呼び出されます。タスクは次のいずれかの状態になります。
ノート: 証明ユースケースについては、Oracle Identity Governanceでのセルフ・サービス・タスクの実行のアイデンティティ証明の管理を参照してください。 |
DefaultOperationalApproval |
デフォルトの操作レベルの承認。デフォルトでは、操作レベルの承認の場合、承認タスクはSYSTEM ADMINISTRATORSロールに割り当てられます。 さらに、コンポジットが証明ユースケースによって呼び出され、タスクが自動承認されます。 |
BeneficiaryManagerApproval |
これは、受益者のマネージャの承認を必要とします。これは次のものと関連付けることができます。
リクエスト・レベルでは、リクエストに複数の受益者が存在する可能性があるため、このコンポジットは、承認の操作レベルで関連付けられる必要があります。 |
DefaultRoleApproval |
このSOAコンポジットにより、承認のためにSYSTEM ADMINISTRATORSロールに割り当てられる単一の承認タスクが作成されます。 |
RequesterManagerApproval |
このSOAコンポジットにより、承認のためにリクエスタのマネージャに割り当てられる単一の承認タスクが作成されます。 ノート: このコンポジットは、承認されていないリクエスト・モデル(ユーザーの自己登録など)に関連付けることはできません。 |
DefaultSODApproval |
このSOAコンポジットにより、システム管理者に割り当てられる承認タスクが作成され、SoDチェックが開始されて、SoDの結果が使用可能になると、SoD管理者ロールに割り当てられる別の承認タスクが作成されます。これは、SoDチェックの必要に応じて、操作レベルでリソースをプロビジョニングまたは変更するリクエスト・モデルに関連付けられる必要があります。 |
DisconnectedProvisioning |
このSOAコンポジットは、システム管理者にタスクを割り当て、接続なしのプロビジョニングを実行します。 |
ProvideInformation |
このSOAコンポジットは、アカウント/権限の詳細を要求しているリクエスタにタスクを割り当てます。 |
CertificationProcess |
これは、デフォルトの証明コンポジットです。このコンポジットは、証明タスクの証明者(ユーザー)への割当てに対応します。このコンポジットは、次の証明タスク・イベントの管理も行います。
|
CertificationOverseerProcess |
このコンポジットは、証明タスクを証明者(ユーザー)に割り当てます。さらに、コンポジットは、証明者のタスクの完了後の監督者へのタスクのルーティング処理も行います。Oracle SOA Business Rulesを使用してタスクのルーティングが処理されます。このコンポジットは、次の証明タスク・イベントに対応します。
|
11.3 新しいSOAコンポジットの作成
SOAコンポジットを作成してデプロイし、承認プロセスとして使用できます。
承認プロセスとして使用できる新規SOAコンポジットを作成するには、次のステップを実行します。
11.3.1 新しいSOAコンポジットの作成
特定の基準に準拠することで、承認プロセスとして使用できる新規SOAコンポジットを作成できます。
SOAコンポジットを承認プロセスとして使用するには、SOAコンポジットが特定の基準に準拠している必要があります。この項では、基準と、新規SOAコンポジットの作成方法について説明します。次の項目が含まれます。
11.3.1.1 SOAコンポジットを承認プロセスとして使用する基準
SOAコンポジットを承認プロセスとして使用するには、SOAコンポジットが特定の基準に準拠している必要があります。このような基準によって、リクエスト・サービスはコンポジットを適切にインスタンス化し、管理できます。基準は、次のとおりです。
-
次の属性はBPELプロセスに必須です。
-
タイプが文字列のRequestID
-
タイプが文字列のRequestModel
-
タイプが文字列のRequestTarget
-
タイプが文字列のURL
-
XML要素のRequesterDetails
-
XML要素のBeneficiaryDetails
-
XML要素のObjectDetails
-
XML要素のOtherDetails
RequestID、RequestModel、RequestTargetおよびURL属性には、常に、すべてのタイプのリクエストの有効な値が設定されます。
RequesterDetailsはXML要素です。この要素には、認証を必要とするすべてのリクエストの有効な値が入力されます。タイプが自己登録ユーザーのリクエストは、リクエスタが匿名ユーザーのため、リクエスタの詳細が空です。
BeneficiaryDetailsはXML要素です。この要素には、「リソースのプロビジョニング」、「ロールの割当て」など、受益者があるすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1人の受益者に関連している場合にのみ入力されます。リクエストが複数の受益者に関連している場合、BeneficiaryDetailsは空になります。BeneficiaryDetails要素には、常に、受益者がある単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1人の受益者にのみ関連付けられているためです。
ObjectDetailsはXML要素です。この要素には、リソース・エンティティに関連付けられているすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1つのリソースに関連している場合にのみ入力されます。リクエストが複数のリソースに関連している場合、ObjectDetailsは空になります。ObjectDetails要素には、常に、リソースに関連付けられている単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1つのリソースにのみ関連付けられているためです。
-
-
BPELプロセスに必須のすべての属性は、RequestDetails.xsdおよびApprovalProcess.xsdから参照されます。これらのファイルは、変更または削除できないテンプレートSOAコンポジットにあります。
11.3.1.2 ヘルパー・ユーティリティを使用したカスタムSOAコンポジットの作成
Oracle Identity Managerでは、カスタムSOAコンポジットを作成するヘルパー・ユーティリティが提供されます。このユーティリティでは、必要な基準のすべてに準拠したテンプレートSOAプロジェクトが作成されます。このユーティリティは、OIM_HOME/workflows/new-workflowディレクトリに配置されています。
ノート:
-
JAVA_HOME環境変数を設定してから、このユーティリティを実行する必要があります。
-
このユーティリティには、Apache Antバージョン1.7以上が必要です。
-
JDeveloperは、デフォルトではOracle Identity Managerで使用できません。SOAのサポートのためには、SOA推奨のJDeveloperをインストールします。
ヘルパー・ユーティリティを実行してカスタムSOAコンポジットを作成するには:
11.3.2 SOAコンポジットのOracle SOAサーバーへのデプロイ
新規SOAコンポジットの作成後、それを承認プロセスとして使用するにはデプロイする必要があります。
BPELへのワークフロー・コンポジットのデプロイの詳細は、Oracle SOA Suite開発者ガイドのSOAコンポジット・アプリケーションのデプロイを参照してください。
ノート:
コンポジットは新規バージョンで再デプロイされる必要があります。コンポジットがSOAで同じバージョンで再デプロイされる場合、コンポジットによって開始されたOracle Identity Managerの保留中のすべての承認が失効となり、ユーザーのTaskListから削除されます。既存のSOAコンポジットのデプロイの詳細は、Oracle SOA Suite開発者ガイドのOracle JDeveloperで既存のSOAアーカイブをデプロイする方法を参照してください。
Oracle Enterprise Managerを使用してコンポジットを再デプロイしている場合:
- すでにお薦めしたように、別のバージョンを使用して再デプロイします。そうしないと、すべての保留中のリクエストが失効します。
- 保留中のリクエストがないかリクエストが失効しても問題がないためにコンポジットを再デプロイしようとする場合でも、Enterprise Managerの再デプロイ・オプションは使用しないでください。まずコンポジットをアンデプロイしてから、デプロイしてください。
11.4 ワークフローの開発: Vision社のリクエストのチュートリアル
Vision社のリクエストのチュートリアルでは、アプリケーションを作成し、アプリケーションのワークフローを開発し、アプリケーション用に承認および履行を構成します。
この項では、最初のワークフローを設計する方法について説明します。次の項目が含まれます。
11.4.1 チュートリアルの概要
このチュートリアルのユースケースの最終結果は、アプリケーション・インスタンス、およびBPELプロセスと複数のヒューマン・タスクで構成される承認用のSOAコンポジットです。
このチュートリアルは、次のユースケースに基づいています。
-
Vision Corp社は、FinApp(メインフレームベースのアプリケーション)を使用しています。このアプリケーションは、リモートから起動可能なAPIを持ちません。したがって、アカウントはヘルプ・デスクによって手動で管理されます。
-
Vision Corp社の従業員は、アクセス・リクエスト・カタログを使用して、アプリケーションでアカウントおよび権限をリクエストします。
-
承認は、リクエストされているアクセスのリスク・レベルに基づいて行われます。リスク・レベルが「低」の場合、受益者のマネージャによる承認のみが必要です。リスク・レベルが「中」の場合、受益者のマネージャまたは監査レビュー・チームのメンバーのいずれかによる承認が必要です。リスク・レベルが「高」の場合、受益者のマネージャおよび監査レビュー・チームのメンバーによる承認が必要です。
このチュートリアルでは、アプリケーションとワークフローの作成方法、およびアプリケーションでの承認および履行の構成方法について説明します。
このチュートリアルでは、次の結果が得られます。
-
アプリケーション・インスタンス
-
次で構成される、承認用のSOAコンポジット
-
BPELプロセス
-
複数のヒューマン・タスク
-
11.4.2 前提
チュートリアルを開始するには、SOAデザインタイムとともにOracle SOAスイートおよびJDeveloperをインストールする、数個のロールと1つの組織をVisionという名前で作成するなど、特定の前提条件を満たす必要があります。
このチュートリアルでは、次を前提としています。
-
SOA管理対象サーバーを含む、構成済のOracle Identity Governance 12 c (12.2.1.4.0)ドメインがあります。
-
SOA Quick StartディストリビューションからインストールされたJDeveloper 12c (12.2.1.4)があります(『Oracle Fusion Middleware SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』のOracle SOA Suite Quick Start for Developersのインストールに関する項を参照)。
-
BPELアクティビティやパートナ・リンクなどの基本的なBPEL構成要素と、基本的なXPath関数について理解しているユーザーを対象にしています。
-
SOAコンポジット・エディタとOracle BPELデザイナ(BPELプロセスを設計およびデプロイするための環境)を熟知している必要があります。ただし、SOAコンポジットの詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のSOAコンポジット・アプリケーションの開発のスタート・ガイドを参照してください。
-
2つのロール(監査レビュー・チームおよびアセット管理チーム)が作成され、メンバーが割り当てられています。
-
Visionという名前の組織が作成されています。
11.4.3 アプリケーション・インスタンスの作成
このチュートリアルの前提条件として、アプリケーション・インスタンスを作成し、アプリケーション・インスタンス属性を定義し、フォームを作成し、アプリケーション・インスタンスを1つ以上の組織に公開し、アプリケーション・インスタンスに権限をリンクし、権限があるアプリケーション・インスタンスをカタログに公開する必要があります。
この項では、アプリケーション・インスタンスを作成および公開し、それに権限をリンクする方法について説明します。次の項目が含まれます。
11.4.3.1 FinAppアプリケーション・インスタンスの作成
FinAppアプリケーション・インスタンスを作成するには:
- Oracle Identity System Administrationにログインします。
- 「サンドボックス」をクリックして、サンドボックス管理にアクセスし、サンドボックスを作成し、それをアクティブにします。サンドボックスの詳細、サンドボックスの作成、アクティブ化および公開方法については、サンドボックスの管理を参照してください。
- 「構成」で、「アプリケーション・インスタンス」をクリックします。ツールバーで「作成」をクリックして、「アプリケーション・インスタンスの作成」ページを開きます。
- 「名前」および「表示名」に、FinAppと入力します。
- 「切断」オプションを選択して、接続なしアプリケーション・インスタンスを指定します。
- 「保存」をクリックし、「OK」をクリックして、FinAppアプリケーション・インスタンスの作成を確認します。
11.4.3.2 アプリケーション・インスタンス属性の定義とフォームの作成
アプリケーション・インスタンスの属性を定義し、フォームを作成するには:
-
「構成」で、「フォーム・デザイナ」をクリックします。
-
FinAppフォームを検索して選択します。このフォームは、接続なしアプリケーション・インスタンスを保存すると自動的に作成されます。
ノート:
フォームを作成して編集するには、アクティブなサンドボックスで作業している必要があります。
-
「フィールド」タブをクリックし、ツールバーで「編集」アイコンをクリックします。
デフォルトでは、次のフィールドが作成され、使用可能になります。
フィールド 説明 ITリソース
アカウントが作成されるITリソース・インスタンス
アカウント・ログイン
アプリケーションのログイン
パスワード
アプリケーションへのログイン中に使用されるパスワード
アカウントID
アカウントの作成時に、アプリケーションによって生成される一意の識別子
サービス・アカウント
アクセス・リクエスト中のみに使用されるフラグ
ノート:
「アカウントID」および「ITリソース」などの属性は、通常、アクセス・リクエスト・ユーザー・インタフェースには表示されません。ユースケースによっては、これらの属性と関係がない場合があります(たとえば、携帯電話リクエスト)。これらの属性を非表示にする場合は、フォームをカスタマイズできます。フォームをカスタマイズする方法の詳細は、Oracle Identity Governanceの管理のカスタム属性の構成を参照してください。
-
属性を追加します。この例では、次の属性を追加します。
Account Description: データ型はTextです。
ノート:
カスタム属性を作成する方法の詳細は、Oracle Identity Governanceの管理のカスタム属性の構成を参照してください
-
属性を追加した後、「フィールド」タブの構成が次の表と同等であることを確認します。
表示ラベル 名前 タイプ アカウントの説明
AccountDescription
テキスト
アカウントID
UD_FINAPP_ACCOUNTID
テキスト
ITResource
UD_FINAPP_IT
数値
アカウント・ログイン
UD_FINAPP_LOGIN
テキスト
パスワード
UD_FINAPP_PASSWORD
テキスト
サービス・アカウント
serviceaccount
チェック・ボックス
-
ユーザーが権限をリクエストするのを許可するには、子オブジェクトを追加し、権限としてタグ付けされる属性を追加する必要があります。そのように行うには:
-
「子オブジェクト」タブをクリックし、ツールバーで「追加」をクリックします。
-
子オブジェクト名を入力し、「OK」をクリックして子オブジェクトを作成します。
-
作成した子オブジェクトをクリックします。
-
「アクション」、「作成」の順に選択し、新規属性を作成します。ポップアップ・ウィンドウから「参照」を選択し、「OK」をクリックします。次のフィールドに値を入力します。
名前: プロファイル名
表示名: プロファイル名
-
「バルクで使用」を選択して、複数のユーザーのアクセスをリクエストするときに、リクエスタによる値の指定を許可します。
-
「参照タイプ」下の新規参照タイプの作成をクリックします。
-
次に示すように、新しいLookupを作成し、値を指定します。
コード: Lookup.FinApp.Profile
意味: Lookup.FinApp.Profile
説明: Lookup.FinApp.Profile
-
次の表に示す値を使用して、3つの参照コードを作成します。
意味 コード FinAppユーザー
FinAppUser
FinApp管理者
FinAppAdministrator
FinAppオペレータ
FinAppOperator
ノート:
スケジュール済タスクと参照APIを使用して、参照定義を移入することもできます。
-
「検索可能」、「権限」および「「検索可能」ピックリスト」オプションを選択します。
-
-
「保存して閉じる」をクリックします。
-
「親オブジェクトに戻る」をクリックします。
-
「ビューの再生成」をクリックして、新しい属性でUIフォームを再作成します。
-
すべてのタブを閉じます。
-
サンドボックスを公開します。
11.4.3.3 1つ以上の組織へのアプリケーション・インスタンスの公開
1つ以上の組織にアプリケーション・インスタンスを公開するには:
- FinAppアプリケーション・インスタンスの詳細ページを開き、「組織」タブをクリックします。
- 「割当て」をクリックします。「組織の選択」ダイアログ・ボックスで、アプリケーション・インスタンスを公開する組織を1つ以上選択します。
- アプリケーション・インスタンスをその組織と子組織に公開する場合は、「階層」オプションを選択します。
- 「OK」をクリックします。
11.4.4 カタログでのFinAppの構成
カタログでアプリケーション・インスタンスとその権限を構成するようにカタログ項目詳細を編集します。
カタログでアプリケーション・インスタンスとその権限を構成するには:
11.4.5 承認用SOAコンポジットの作成と構成
カタログでアプリケーション・インスタンスとその権限を構成した後、承認用SOAコンポジットを登録および設定できます。具体的には、承認ワークフローを作成し、リクエストとカタログのデータをBPELプロセスで使用できるようにし、ワークフローの選択を構成し、ヒューマン・タスクを構成し、ヒューマン・タスクおよびBPELマッピングを構成し、SOAコンポジットをデプロイし、ワークフロー・ルールを作成します。
この項の内容は次のとおりです。
11.4.5.3 ワークフローの選択の構成
ワークフロー選択ルールを定義するには:
-
catalogDataという変数を定義します。そのように行うには:
- 「変数」アイコンをクリックし、「変数」ダイアログ・ボックスの「作成」アイコンをクリックします。
- 「要素」として「タイプ」を選択し、フィールドの横にある「検索」アイコンをクリックします。
- ダイアログ・ボックスで、「プロジェクトのスキーマ・ファイル」、「CatalogData.xsd」の順に展開し、CatalogData要素を選択します。この変数には、InvokeCatalogDetailsステップの出力として返されるカタログ詳細が格納されます。
-
workflowtypeという変数を定義します。そのように行うには:
- 「要素」としてタイプを選択し、フィールドの横にある「検索」アイコンをクリックします。
- ダイアログ・ボックスで、「プロジェクトのスキーマ・ファイル」、「BusinessRule.xsd」の順に展開し、StageOutput要素を選択します。この変数には、呼び出されるワークフローのタイプが格納されます。
-
「SOAコンポジット」ビューに移動し、図11-12に示すようにビジネス・ルール・コンポーネントを追加します。
-
「ビジネス・ルールの作成」ダイアログ・ボックスで、ルール・ディクショナリの名前としてWorkflowSelectionを指定します。
-
プロジェクトのスキーマ・ファイル内のCatalogData.xsdから入力をCatalogDataとして指定し、プロジェクトのスキーマ・ファイル内のBusinessRule.xsdからStageOutputとして出力します。
-
BPELプロセスに切り替えます。
-
「SOAコンポーネント」を展開し、InvokeCatalogOperationとApprovalTask_1コンポーネント間でビジネス・ルール・コンポーネントを追加します。
-
そのルールを編集し、
WorkflowSelection
という名前に変更します。 -
「ルール」ダイアログ・ボックスで、「ディクショナリ」タブをクリックし、ステップ4で定義したWorkflowSelectionディレクトリを選択します。
-
「ディクショナリ」タブで「入力ファクトの割当て」サブタブをクリックし、プラス(+)アイコンをクリックします。
-
図11-13に示すように、catalogData変数をルールの入力にマップします。
-
「ディクショナリ」タブで「出力ファクトの割当て」サブタブをクリックします。
-
図11-14に示すように、workflowtype変数をルールの出力にマップします。
-
図11-15に示すように、WorkflowSelectionルールの前にAssignアクティビティを追加し、その名前をAssignRuleInputに変更します。
-
図11-16に示すように、InvokeCatalogOperationの出力をcatalogData変数にマップします。
-
「SOAコンポジット」ビューに切り替えます。
-
ビジネス・ルール・コンポーネントを右クリックし、「編集」を選択します。
-
「ルールの作成」をクリックします。
-
そのルールの名前をRule1から
Auto Approval
に変更します。 -
「低」、「中」または「高」リスクの値が設定されていない項目が自動承認としてステージングされるように、ルールを編集します。これを行うには、図11-17に示すようにします。
-
IFの下にある「<テストの挿入>」アクションをクリックして、簡易テストを選択します。次のように定義します:
CatalogDataType.itemRisk != 3
-
最初のテストを選択し、「後ろに挿入」オプションを使用して、別の簡易テストを追加します:
CatalogDataType.itemRisk != 5
-
前のテストを選択し、「後ろに挿入」オプションを再度使用して、最後の簡易テストを追加します
CatalogDataType.itemRisk != 7
これらの追加の結果、IF条件は次のようになります:
CatalogDataType.itemRisk != 3 and CatalogDataType.itemRisk != 5 and CatalogDataType.itemRisk != 7
-
THENの下にある「<insert_action>」アクションをクリックして、新規アサートを選択します。
-
「新規アサート」の隣に追加された「<ターゲット>」をクリックして、「ステージ」を選択します。
-
図11-17に示すように、「<プロパティの編集>」をクリックし、「プロパティ」ダイアログ・ボックスに値
Auto
を入力します。
-
-
同様に、図11-18に示すように、「マネージャ」、「シリアル」、および「パラレル」承認ルールを作成します。
-
BPELプロセスに切り替えます。
-
図11-19に示すように、WorkflowSelectionルールの後にswitchアクティビティを追加します。
-
そのSwitchアクティビティを選択し、図11-20に示すように2つのSwitch Caseステップを追加します。
-
図11-21に示すように、条件の名前をSerial Approval、Parallel Approval、Manager Approvalに変更します。
-
図11-22に示すように、デフォルト・ヒューマン・タスクをManager Switch Caseにドラッグします。
-
「SOAコンポジット」ビューに切り替えます。
-
図11-23に示すように、SerialApprovalとParallelApprovalの2つのヒューマン・タスクを追加します。
-
BPELプロセスに切り替えます。
-
Manager Approval Switch Caseを編集し、次の式を追加します。
bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType')='Manager'
最初に、新しく追加したタスクを構成し、次にそれらをBPELプロセスに書き込む必要があります。
ノート:
式の追加には式ビルダーの使用をお薦めします。
11.4.5.4 ヒューマン・タスクの構成
この項では、ヒューマン・タスクを構成する方法について説明します。この章の内容は次のとおりです。
11.4.5.4.1 パラレル・ヒューマン・タスクの構成
パラレル・ヒューマン・タスクを構成するには:
-
「SOAコンポジット」ビューに切り替えます。パラレル承認タスクを編集します。
-
「データ」タブをクリックし、パラレル承認タスクのプロパティにリストされている属性を追加します。
-
「データ」タブでタスク・パラメータを検証し、「一般」タブをクリックします。
-
「タスクのタイトル」を
<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approval
に設定します。そのように行うには:-
タスク・タイトルの横の「編集」をクリックし、「task:payload」、「ns2:BeneficiaryDetails」、「ns2:DisplayName」の順に選択します。
-
「式に挿入」をクリックします。図11-24に示すようにタスク・タイトルが表示されます。
<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%>
次のようにこれを編集して意味のあるタイトルを構成できます。
<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approval.
-
-
「タスク所有者」を「グループ」と「SYSTEM ADMINISTRATORS」に設定し、「名前別」オプションを「承認」とともに使用して「カテゴリ」を設定します。
-
「通知」タブをクリックし、次に「詳細」をクリックします。
-
「通知をアクション可能にする」オプションを選択します。「ワークリスト/ワークスペースURLを通知に表示」オプションの選択を解除します。
-
「割当て」タブをクリックします。
-
パラレル・ステージを追加します。これを行うには、単一参加者をワークフロー・エディタからStage1ボックスにドラッグ・アンド・ドロップします。最初の単一参加者の右側に2番目の単一参加者を追加するプロセスを繰り返します。
-
「投票結果」の詳細を構成します。これを行うには、2つのステージのすぐ下にある鉛筆アイコンを選択します。「プロパティ」ボックスで、次のようにします:
- 「投票結果」を「承認」に設定し、「結果タイプ」は「パーセンテージ別」、「値」は50のままにします。
- 「デフォルトの結果」を「拒否」に設定します。
- 「添付とコメントの共有」および「最小のパーセンテージに達するとただちに投票結果がトリガーされます」オプションを選択します。
-
Managerステージを編集します。これを行うには、Stage1.Participant1ステージを選択します。「プロパティ」ボックスで、次のようにします:
- 図11-25に示すように、「ラベル」をManagerに変更します。
- 参加者のリストを作成ドロップダウン・ボックスから、「ルールベース」を選択します。
- 「ルールセットのリスト」フィールドに
Manager
と入力し、フィールドの右にあるプラス・アイコンをクリックします。
-
マネージャ・ルール・セットの「概要」タブの「一般的なルール」ボックスで、「追加」アイコンをクリックして新規ルールを作成します。
-
図11-26に示すように、参加者リスト・ルールを作成します。
-
ReviewTeamステージを編集します。これを行うには、Stage1.Participant2ステージを選択します。「プロパティ」ボックスで、次のようにします:
- 「ラベル」をReviewTeamに変更します。
- 参加者のリストを作成ドロップダウン・ボックスから、「ルールベース」を選択します。
- 「ルールセットのリスト」フィールドに
ReviewTeam
と入力し、フィールドの右にあるプラス・アイコンをクリックします。
-
ReviewTeamルール・セットの「概要」タブの「一般的なルール」ボックスで、「追加」アイコンをクリックして新規ルールを作成します。「ルール・セット」にReviewTeamが表示されない場合は、「追加」アイコンを使用して手動で作成します。
-
図11-27に示すように、参加者リスト・ルールを作成します。
11.4.5.4.2 パラレル承認タスクのプロパティ
表11-2に、パラレル承認タスクを構成する際の「データ」タブの属性をリストします。
表11-2 パラレル・ヒューマン・タスクの「データ」タブの属性
パラメータ | データ型 |
---|---|
RequestID |
{http://www.w3.org/2001/XMLSchema}string |
RequestModel |
{http://www.w3.org/2001/XMLSchema}string |
RequestTarget |
{http://www.w3.org/2001/XMLSchema}string |
RequesterDetails |
{http://xmlns.oracle.com/request/RequestDetails}RequesterDetails |
BeneficiaryDetails |
{http://xmlns.oracle.com/request/RequestDetails}BeneficiaryDetails |
ObjectDetails |
{http://xmlns.oracle.com/request/RequestDetails}ObjectDetails |
OtherDetails |
{http://xmlns.oracle.com/request/RequestDetails}OtherDetails |
url |
{http://xmlns.oracle.com/request/RequestDetails}url |
Catalogdata |
{http://xmlns.oracle.com/RequestServiceApp/RequestDataService/CatalogData}CatalogData |
RequesterDisplayName |
{http://www.w3.org/2001/XMLSchema}string |
BeneficiaryDisplayName |
{http://www.w3.org/2001/XMLSchema}string |
Requester |
{http://www.w3.org/2001/XMLSchema}string |
11.4.5.4.4 シリアル承認タスクのプロパティ
表11-3に、シリアル承認タスクを構成する際の「データ」タブの属性をリストします。
表11-3 シリアル承認タスクの「データ」タブの属性
パラメータ | データ型 |
---|---|
RequestID |
{http://www.w3.org/2001/XMLSchema}string |
RequestModel |
{http://www.w3.org/2001/XMLSchema}string |
RequestTarget |
{http://www.w3.org/2001/XMLSchema}string |
RequesterDetails |
{http://xmlns.oracle.com/request/RequestDetails}RequesterDetails |
BeneficiaryDetails |
{http://xmlns.oracle.com/request/RequestDetails}BeneficiaryDetails |
ObjectDetails |
{http://xmlns.oracle.com/request/RequestDetails}ObjectDetails |
OtherDetails |
{http://xmlns.oracle.com/request/RequestDetails}OtherDetails |
url |
{http://xmlns.oracle.com/request/RequestDetails}url |
Catalogdata |
{http://xmlns.oracle.com/RequestServiceApp/RequestDataService/CatalogData}CatalogData |
RequesterDisplayName |
{http://www.w3.org/2001/XMLSchema}string |
BeneficiaryDisplayName |
{http://www.w3.org/2001/XMLSchema}string |
Requester |
{http://www.w3.org/2001/XMLSchema}string |
11.4.5.7 ワークフロー・ルールの作成
作成したSOAコンポジットは、単一およびバルク操作に使用できます。コンポジットが特定の操作に対して起動されるようにするには、Oracle Identity Managerでワークフロー・ルールを作成する必要があります。
Oracle Identity Managerでワークフロー・ルールを作成するには:
- Oracle Identity System Administrationにログインします。
- 左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。
- アプリケーション・インスタンスのバルク・プロビジョニング操作のワークフロー・ルールを作成し、自動承認に設定します。ワークフロー・ルールの作成と管理の詳細は、Oracle Identity Governanceの管理の承認ワークフロー・ルールの構成を参照してください。
- アプリケーション・インスタンスのプロビジョニング操作のワークフロー・ルールを作成し、デプロイするコンポジットを起動することを指定します。
ノート:
各タイプのリクエストに対して複数のSOAコンポジットを作成可能ですが、こチュートリアルで示すように単一のSOAコンポジットを使用して、複数のヒューマン・タスクを作成することをお薦めします。Oracle Business Rulesで作成したルールを使用すると、このチュートリアルで示すように、ヒューマン・タスクを選択できます。
ヒント:
SOAコンポジットBPELプロセスであるリクエストWebサービスにサポートされるエンティティ(カタログ、ユーザー、ロールまたは組織など)のカスタム属性の値にアクセスできます。カスタム属性またはUDFはCustomAttribute要素の一部です。UDFを含むカタログ・エンティティのインスタンスは次のとおりです。
<ns12:CustomAttribute Name="ApproverRolePhoneNumber"> <ns5:Value>1234</ns5:Value> </ns12:CustomAttribute> <ns12:CustomAttribute Name="ApproverRoleEmailId"> <ns5:Value>approver@example.com</ns5:Value> </ns12:CustomAttribute>
たとえば、BPELプロセスでApproverRolePhoneNumberカタログのUDF値にアクセスするには、次のように指定します。
bpws:getVariableData('catalogDetails','CatalogData','/ns22:CatalogData/ns22:CustomAttribute[@Name = string("ApproverRolePhoneNumber")]/ns24:Value')
11.5 単一およびバルク操作のデフォルト承認コンポジットの構成
リクエストレベルのコンポジットはバルク・リクエストに適用でき、操作レベルのコンポジットは単一および子リクエストに適用できます。
oim-config.xmlファイルにDefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティを設定すると、デフォルトのコンポジットを構成できます。これらのプロパティは、Oracle Enterprise ManagerのSystem MBean Browserを使用して編集できます。これらのプロパティのデフォルト値は、それぞれdefault/DefaultRequestApproval!6.0
とdefault/DefaultOperationalApproval!6.0
になります。
これらのプロパティの値は、次の形式で入力します。
NAMESPACE/COMPOSITE_NAME!VERSION
たとえば:
default/AddAccessApproval!2.0
DefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティのデフォルト値を変更する場合は、Oracle Identity Managerを再起動する必要があります。
11.6 カスタム・タスク詳細タスクフローの作成およびデプロイ
独自のタスクフローを作成し、そのカスタム・タスクフローを呼び出すようにDefaultRequestApprovalコンポジットのヒューマン・タスクを構成します。
デフォルトでは、すべてのタスクは、保留中の承認のデフォルト・タスク詳細ページを使用するように構成されています。このタスクフローはカスタマイズできません。ただし、タスク詳細ページのUIをカスタマイズしたり、その他の情報を表示することはできます。この項では、独自のタスクフローを作成し、DefaultRequestApprovalコンポジットのヒューマン・タスクを構成して、そのカスタム・タスクフローを呼び出す方法を説明します。
この項の内容は次のとおりです。
11.6.1 カスタム・タスク詳細タスクフローを開発するための前提条件
カスタム・タスク詳細タスクフローを開発するためには、Oracle Identity Manager、SOAおよびJDeveloperをインストールします。
カスタム・タスク詳細タスクフローを開発する前に、コンピュータに次のソフトウェアをインストールしておく必要があります。
-
Oracle Identity Governance 12c (12.2.1.4.0)
-
Oracle SOA 12c (12.2.1.4)
-
JDeveloper 12c (12.2.1.4)にインストールされたSOA Quick Startディストリビューション(『Oracle Fusion Middleware SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』のOracle SOA Suite Quick Start for Developersのインストールに関する項を参照)
11.6.2 カスタム・タスク詳細タスクフローの開発
DefaultRequestApprovalコンポジットのヒューマン・タスクのカスタム・タスクフローを作成します。
この項では、カスタム・タスクフローの開発方法について説明します。次の項目が含まれます。
11.6.2.1 カスタム・タスクフローの構築: おおまかなステップ
DefaultRequestApprovalコンポジットのヒューマン・タスクのカスタム・タスクフローを作成するには:
-
Jdeveloperを開き、新規汎用アプリケーションを作成します。そのように行うには:
-
アプリケーション名として
RequestApprovalTaskDetailsApp
を入力し、「次へ」をクリックします。 -
プロジェクト名として
RequestApprovalTaskDetails
を入力します。プロジェクト・テクノロジは選択しないでください。 -
「終了」をクリックします。
-
-
Oracle Identity Manager共有ライブラリを追加します。そのように行うには:
-
RequestApprovalTaskDetailsプロジェクトを右クリックして、「プロジェクト・プロパティ」→「ライブラリとクラスパス」の順に選択します。
-
「ライブラリの追加」をクリックします。
-
「ディレクトリ」をクリックします。
-
IAM_HOME/server/jdev.lib/ディレクトリに移動し、「選択」をクリックします。
ノート:
IAM_HOMEはOracle Identity Managerのホーム・ディレクトリのパスで、たとえばBEA_HOME/Oracle_IDM1/のようになります。ここでは、BEA_HOMEは、Oracle Identity Managerインストールのミドルウェア・ディレクトリのパスです。
-
OIMビュー共有ライブラリ→OIMモデル共有ライブラリを選択し、「OK」をクリックします。
-
「OK」をクリックします。
-
-
タスク詳細タスクフローを作成します。そのように行うには:
-
shiphome内の次ディレクトリに移動します。
IAM_HOME/server/workflows/composites/
-
DefaultRequestApproval.zipファイルを解凍します。
-
Jdeveloperに戻り、RequestApprovalTaskDetailsを右クリックして、「新規作成」を選択します。
-
ヒューマン・タスクに基づいて、「Web層」、「JSF」、ADFタスクフローを選択します。
-
ファイル・ブラウザで、DefaultRequestApproval.zipを解凍したディレクトリに移動します。DefaultRequestApproval/ApprovalTask.taskファイルを選択します。
-
「タスク・フローの作成」ダイアログ・ボックスで、次の値を指定します。
ファイル名: request-approval-details-tf.xml
ディレクトリ: タスクフローがWEB-INF/oracle/iam/ui/custom/ディレクトリに作成されることを確認します。WEB-INF/oracle/iam/ui/custom/ディレクトリの下のすべてのタスクフローが表示権限で保護されます。
タスク・フローID: request-approval-details-tf
-
「OK」をクリックします。
-
-
hwtaskflow.xmlを削除します。これを行うには、RequestApprovalTaskDetailsプロジェクトの下の「アプリケーション・ソース」に進み、hwtaskflow.xmlを削除します。
-
タスク詳細ページを作成します。そのように行うには:
-
request-approval-details-tf.xmlを開きます。Diagramモードに切り替えます。
-
taskdetails1_jspx viewアクティビティの名前をrequest-approval-detailsに変更します。
-
request-approval-details viewアクティビティを右クリックし、「ページの作成」を選択します。次の値を入力します。
ファイル名: request-approval-details.jspx
ディレクトリ: JSPXファイルをpublic_html/oracle/iam/ui/custom/ディレクトリに配置します。
初期ページ・レイアウトおよびコンテンツ: 空白ページ
-
「OK」をクリックします。
-
-
タスク詳細ページのマネージドBeanの追加の説明に従って、タスク詳細ページのマネージドBeanを追加します。
-
詳細ページ構造の作成の説明に従って、詳細ページ構造を作成します。
-
「リクエスト情報」タブの移入の説明に従って、「リクエスト情報」タブに移入します。
-
「タスク情報」タブの移入の説明に従って、「タスク情報」タブに移入します。
11.6.3 電子メール通知のカスタム・タスク詳細の開発(オプション)
デフォルトでは、電子メール通知の送信について、電子メール用に別のページがない場合は、開発した同じタスク詳細ページが電子メール通知で送信されます。
場合によっては、電子メール通知で送信する情報を制限する必要があります。そのような場合は、電子メール通知用に別のページを開発できます。電子メール・ページも、同じタスク詳細タスクフローの一部になります。
電子メール用カスタム・タスクフローの作成の詳細は、Oracle SOA Suite開発者ガイドの電子メール通知の作成を参照してください。
11.6.4 タスク詳細タスクフローのデプロイ
タスク詳細タスクフローをデプロイするには、タスク詳細をADFライブラリJARとしてデプロイし、adflibRequestApprovalTaskDetails.jarをカスタム共有ライブラリにパッケージ化します。
タスク詳細タスクフローをデプロイするには:
-
ADFライブラリJARとしてタスク詳細をデプロイします。そのように行うには:
-
「RequestApprovalTaskDetails」を右クリックして、「プロジェクト・プロパティ」→「デプロイメント」の順に選択します。
-
「新規」をクリックします。「デプロイメント・プロファイルの作成」ダイアログ・ボックスが表示されます。
-
次の値を指定し、「OK」をクリックします。
アーカイブ・タイプ: ADFライブラリJARファイル
名前: adflibRequestApprovalTaskDetails
-
「RequestApprovalTaskDetails」を右クリックして、「デプロイ」→「adflibRequestApprovalTaskDetails」を選択します。
-
「デプロイメント・アクション」ポップアップで、「終了」をクリックします。
-
-
カスタム共有ライブラリでadflibRequestApprovalTaskDetails.jarをパッケージ化します。そのように行うには:
-
IAM_HOME/server/apps/ディレクトリに移動します。
-
次のディレクトリ構造を作成します。
WEB-INF/lib/
-
WEB-INF/lib/ディレクトリにadflibRequestApprovalTaskDetails.jarをコピーします。
-
IAM_HOME/server/apps/ oracle.iam.ui.custom-dev-starter-pack.warを更新し、adflibRequestApprovalTaskDetails.jarを追加します。たとえば:
jar uvf oracle.iam.ui.custom-dev-starter-pack.war WEB-INF/*
-
-
Oracle Identity Manager管理対象サーバーを再起動して、カスタム共有ライブラリへの変更を反映します。
11.6.6 カスタム・タスクフローのテスト
リクエストを作成し、「保留中の承認」で「タスクの詳細」リンクを検証することで、カスタム・タスクフローをテストします。
カスタム・タスクフローをテストするには:
- エンド・ユーザーとしてOracle Identity Self Serviceにログインします。
- 「本人情報」に移動し、「電話」属性の値を変更します。リクエストが作成され、タスクがシステム管理者に割り当てられます。
- システム管理者としてOracle Identity Self Serviceにログインします。
- 「保留中の承認」に移動します。
- 対応するリクエストの「タスクの詳細」リンクをクリックします。カスタム・タスク詳細ページが表示されます。
11.7 リクエスト管理操作の拡張
リクエスト管理操作の特定の側面をカスタマイズして、柔軟性を向上させたり、追加機能のカスタマイズされたロジックを実装できます。これを行うには、リクエスト管理プラグインを使用できます。カスタマイズの実装に使用できるプラグイン・ポイントがあります。
ここでは、プラグイン・ポイントについて次の各項で説明します。
11.7.1 リクエスト・ステータス変更に基づくカスタム・コードの実行
リクエストのライフサイクルの各ステージでステータスが変更されます。リクエスト・エンジンによって、リクエスト・ステータスの変更時にカスタム・コードを実行できるプラグイン・ポイントが公開されます。このプラグイン・ポイントを拡張するカスタム・コードを含むプラグインを実装し、コードを実行するために登録できます。
プラグイン・ポイントは、public void followUpActions(String reqId)メソッドを含むoracle.iam.request.plugins.StatusChangeEventインタフェースです。このメソッドはリクエストIDパラメータで構成され、これとリクエスト管理APIを使用してリクエスト詳細を取得できます。
関連項目:
プラグインおよびプラグイン・ポイントの詳細はプラグインの開発
ステータス変更時に実行するコードは、oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するプラグイン・クラスのfollowUpActions()メソッドで実装する必要があります。plugin.xmlファイルでこのプラグインをどのリクエスト・ステータス変更時に実行するかを指定する必要があります。
たとえば、Oracle Identity Managerでリクエストが「リクエストに失敗しました」ステータスに移行した場合、管理者に通知を送信するカスタム・コードを実行できます。そのように行うには:
11.7.2 リクエスト・データの検証
RequestDataValidatorプラグインを使用して、送信後にリクエスト・データのカスタム検証を追加できます。
この項では、プラグインをデータ・バリデータおよび事前移入アダプタに関連付ける方法について説明し、シナリオをいくつか示します。次の項目が含まれます。
11.7.2.1 リクエスト・データの検証について
RequestDataValidatorプラグインを使用して、送信後にリクエスト・データのカスタム検証を追加できます。このプラグインのプラグイン・ポイントは、public void validate(RequestData requesterData)メソッドを含むoracle.iam.request.plugins.RequestDataValidatorインタフェースです。
特定のプラグインに関連付けられているデータセット・バリデータおよび事前移入アダプタを定義できます。プラグインに関連付けられるリクエスト・データセットは、プラグイン登録時に定義できます。plugin.xmlファイルは、プラグインとデータセット・バリデータまたは事前移入アダプタの間の関連付けを定義するために使用します。<plugins>要素に付加されている<metadata>ノードは、データ・バリデータと事前移入アダプタの間の関連付けを定義するために使用します。
ノート:
データセットに対して指定されているDataSetValidatorプラグインは、plugin.xml自体でバリデータ・メタデータを指定するプラグイン拡張によってオーバーライドすることはできません。たとえば、デフォルト・バリデータに付属している事前定義済データセットModifyUserDatasetは、カスタム実装クラスによってオーバーライドされません。したがって、データセットのバリデータが優先され、それをオーバーライドするオプションは現時点ではありません。
11.7.2.2 プラグインとデータ・バリデータおよび事前移入アダプタの関連付け
次の例は、プラグインをデータ・バリデータおよび事前移入アダプタに関連付ける方法を示しています。
<?xml version="1.0" encoding="UTF-8"?> <oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <plugins pluginpoint="oracle.iam.request.plugins.RequestDataValidator"> <plugin pluginclass= "oracle.iam.plugin.appinst.ApplicationInstanceDataValidator" version="1.0" name="AppInstDataValidator"> <metadata name="DataValidator"> <value>AppInstanceDataSet|ADAppDataSet|EBSDataSet</value> </metadata> </plugin> </plugins> </oimplugins>
この例の次のコード行は、プラグインがリクエスト・データ・バリデータ・データセットに関連付けられていることを示すメタデータxml要素の定義を示しています。
<metadata name="DataValidator">
このメタデータ要素のAttribute name="DataValidator"
は、リクエスト・データ・バリデータに関連付けられているプラグインを示すことに注意してください。
現在のプラグインに関連付けられているデータセットの名前の定義は、次の行で示されます。
<value>AppInstanceDataSet|ADAppDataSet|EBSDataSet</value>
ノート:
リクエスト・データセット名は、単一のパイプ文字(|)で区切る必要があります。
11.7.2.3 シナリオI: ターゲット・システムに対するユーザーのプロビジョニング
AD User APACターゲットにユーザーをプロビジョニングするように、Oracle Identity Managerが構成されているとします。RequestDataValidatorは、次に示すように、ADUserDataValidatorを対応するリクエスト・データセットに対して構成することを指定します。
<plugin pluginclass= "oracle.iam.plugin.appinst.ADUserDataValidator" version="1.0" name="ADUserDataValidator"> <metadata name="DataValidator"> <value>ADUserAPACDataSet</value> </metadata> </plugin>
後で、AD User EMEAターゲットにユーザーがプロビジョニングされるように、システム・コンフィギュレータがOracle Identity Managerを構成する場合、システム・コンフィギュレータは新しいアプリケーション・インスタンスを作成し、UIフォームをそれに関連付けようとします。リクエスト・データセットは、プロセスで自動生成されます。データ・バリデータをこのリクエスト・データセットに対して再利用する場合、次の操作を実行します。
11.7.2.4 シナリオII: 権限リクエストのプロビジョニングまたは変更
権限のプロビジョニングおよび権限の変更リクエストの一部として指定される権限データは、データセット検証プラグインを作成し、プラグイン・メタデータ(plugin.xml)で次のように指定することで検証できます。
<metadata name="DataValidator"> <value>EBSForm.UD_EBS_RESP</value> </metadata>
ここで、EBSFormは、アカウントがプロビジョニングされるアプリケーション・インスタンスに関連付けられているフォームの名前で、UD_EBS_RESPは権限に対応する子フォームの名前です。UD_EBS_RESPによって権限タイプが識別されます。
11.7.3 リクエスト作成時の属性値の事前移入
事前移入プラグインは、リクエスト・データセットの属性参照または属性に関連付けられます。これを使用すると、リクエストの作成時にカスタム・コードを実行して、属性値を事前移入できます。リクエスタは、必要に応じて事前移入する値を変更できます。
このプラグインのプラグイン・ポイントは、public Serializable prepopulate(RequestData requestData)メソッドを含むoracle.iam.request.plugins.PrePopulationAdapterインタフェースです。このプラグインは、次のリクエスト・タイプにのみ使用します。
リソースのプロビジョニング、リソースの自己リクエスト、ユーザーの作成、ユーザーの自己登録
次の行は、事前移入データを満たすためのリクエスト・データセット属性に、プラグインがマップされることを示すメタデータ要素の定義を示しています。
<metadata name="PrePopulationAdapater">
関連付けは、データセット名と属性名を次の形式で組み合せることによって定義されます。
<DATASET_NAME>::<ATTRIBUTE_NAME>
たとえば:
AppInstanceDataSet::First Name
複数の属性を同じ事前移入プラグインに関連付けることが可能ですが、その際は、各関連付けを単一のパイプ文字(|)で区切ります。たとえば:
<datasetname1>::<attribute1> | <datasetname2>::<attributename2>|<datasetname3>::<attribute3>
事前移入プラグインの例を次に示します。
<plugins pluginpoint="oracle.iam.request.plugins.PrePopulationAdapter"> <plugin pluginclass= "oracle.iam.plugin.appinst.ApplicationInstancePrePopulateAdapter" version="1.0" name="AppInstPrepopAdapter"> <metadata name="PrePopulationAdapater"> <value> AppInstanceDataSet::First Name|ADAppDataSet::Last Name </value> </metadata> </plugin> </plugins>
ノート:
カタログ・フォーム・デザイナでリクエスト・データセットを作成する他に、リクエスト・データセットをMDSに手動でアップロードすることができます。リクエスト・データセット内にDataSetValidatorまたはPrepopulationAdapter要素を定義することもできます。データセット内で構成されるこれらのデータセット・バリデータまたは事前移入アダプタは、他の構成よりも最優先されます。
たとえば、プラグインEBSUserDataValidatorは、リクエスト・データセットEBSUSerDataSetと関連付けるために登録されますが、そのデータセットは作成されていないか、アップロードされていないとします。もう1つのプラグインADUserDataValidatorが登録されていますが、どのリクエスト・データセットにも関連付けられていません。後でリクエスト・データセットEBSUSerDataSetを作成して、リクエストの作成に使用すると、そのリクエスト・データを検証するためにプラグインEBSUserDataValidatorがコールされます。そこで、手動で作成したリクエスト・データセットEBSUSerDataSetに、DataSetValidator要素を追加して、別のプラグインADUserDataValidatorを指定します。EBSUSerDataSetを使用してリクエストを作成すると、プラグインADUserDataValidatorがコールされます。これは、ADUserDataValidatorがリクエスト・データセットの一部として構成されたためです。DataSetValidatorエントリをEBSUSerDataSetから削除すると、そのリクエスト・データを検証するためにプラグインEBSUserDataValidatorが起動されます。
11.7.4 アカウント受益者によるリクエスト承認の有効化
アカウント受益者による承認は、IRoutingSlipCallbackクラスを実装するコールバック・クラスを作成することで、有効にできます。
11.8 自己登録リクエストの自動承認の有効化
リクエストを自動承認する必要があるか、SOAコンポジットを起動する必要があるかを決定する承認ワークフロー・ポリシーのルールを構成できます。
構成承認ワークフロー・ルールの詳細は、Oracle Identity Governanceの管理の承認ワークフロー・ルールの構成を参照してください。
承認ワークフロー・ポリシーで自動承認のルールを構成した後、次のステップを実行して自己登録リクエスト用に自動承認を有効化します。
-
組織を自動的に割り当てるには、ホーム組織ポリシーを構成します。ホーム組織ポリシーの構成方法の詳細は、Oracle Identity Governanceの管理のホーム組織ポリシーの管理を参照してください。
-
デフォルトでは、自己登録リクエストに設定されているロールおよびユーザー・タイプは「パートタイムの従業員」です。この値を上書きする場合は、SelfCreateUserDataset.xmlデータセットで構成されているプラグインを変更します。
-
必要な値やロジックについて新規プラグイン実装を作成し、データセットで構成されているプラグインを変更することで、新しいプラグイン実装を反映できます。新しいプラグインではoracle.iam.request.plugins.PrePopulationAdapterが実装されている必要があります。
-
プラグイン登録ユーティリティを使用して、作成したプラグインを登録します。詳細は、プラグイン登録ユーティリティを使用したプラグインの登録および登録解除を参照してください。
-
リクエスト・データセットを更新するには:
-
MDSへのメタデータ・ファイルのエクスポートの説明に従って、MDSから/metadata/iam-features-requestactions/model-data/SelfCreateUserDataset.xmlリクエスト・データセットをエクスポートします。
-
Role属性に構成されているプラグイン名を次のように更新します。
<AttributeReference name="Role" attr-ref="Role" available-in-bulk="false" type="String" length="255" widget="dropdown" lookup-code="Lookup.Users.Role" required="true"> <PrePopulationAdapter classname="oracle.iam.selfservice.uself.uselfmgmt.plugins.RolePrepopulateAdapter" name="RolePrepopulateAdapter"/> </AttributeReference>
-
MDSからのメタデータ・ファイルのインポートの説明に従って、更新されたリクエスト・データセットをMDSにインポートします。
-
ノート:
Dynamic Monitoring Service (DMS)を使用してパフォーマンス・メトリックを表示できます。次のDMSメトリックは、自己登録フローのパフォーマンスを監視するために存在します。
-
Self_Registration
: これは、完了および失敗した自己登録リクエストの数を提供します。 -
oracle.iam.selfservice.uself.uselfmgmt.api.UnauthenticatedSelfService
: これは、自己登録リクエスト数や、自己登録リクエストの送信に要した時間などの詳細を提供します。
11.9 「現在の割当てのスキップ」オプションの非表示
タスク・アクションを変更することで、「現在の割当てのスキップ」アクションがSOAコンポーザまたはJDeveloperに表示されないようにすることができます。
現在の割当てのスキップは承認者には有効なアクションではありません。承認者がこのアクションを選択すると、対応するリクエストは失敗します。したがって、次のいずれかの方法を実行して、このオプションを非表示にできます。
-
SOAコンポーザからタスク・アクションを変更します。「現在の割当てのスキップ」アクションに対して、すべてのチェックボックスの選択を解除し、保存します。
-
JDeveloperを使用してタスク・アクションを変更します。「現在の割当てのスキップ」アクションに対して、すべてのチェックボックスの選択を解除します。次に、コンポジットを保存し、再デプロイします。タスクの作成者または所有者がタスク・コンテンツに対して実行できるアクションの指定については、Oracle SOA Suite開発者ガイドのタスク操作のためのアクションの指定を参照してください。
11.10 証明の監視のカスタマイズ
証明の監視は、監視のレベルを拡張するため、または特定のタイトルに達したときに監視プロセスを停止するためにカスタマイズできます。
この項では、証明の監視のカスタマイズ方法について説明します。次の項目が含まれます。
11.10.1 証明の監視のカスタマイズの理解
証明の監視は、監視のレベルを拡張するため、または特定のタイトルに達したときに監視プロセスを停止するためにカスタマイズできます。
証明コンポジットには、カスタマイズ可能な監視ロジックが含まれています。このロジックにより、次のいずれかまたはすべてに基づいて監督者のシーケンスを選択するためのOracle Identity Managerへの問合せをサポートします。
-
プライマリ・レビューア
-
証明の現在のフェーズ
-
Oracle Identity Managerで定義された管理階層
デフォルトでは、証明タスクが1人のレビューアに割り当てられるという、単一レベルの監視のみがサポートされます。
証明の監視用コンポジットで事前定義されているように、プライマリ・レビューアまたは監督者がサインオフすると、主要なレビュー・タスクはシーケンス内の次の監督者に自動的にルーティングされます。プライマリ・レビューアまたは監視者(最終監視者を除く)が主要なレビュー・タスクでサインオフすると、そのユーザーは、完了したタスクを問い合せて、そのタスクを受信箱で表示することはできなくなります。
11.10.2 証明の監視のカスタマイズ
証明の監視をカスタマイズするには、JDeveloperで証明コンポジットを編集します。
証明の監視のカスタマイズに必要なステップは、次のとおりです。
-
コンポジットを作成します。そのように行うには:
-
DOMAIN_HOME/bin/ディレクトリでsetDomainEnv.shスクリプトを実行して、JAVA_HOME、ANT_HOMEおよびPATH環境変数を設定します。
-
OIM_HOME/server/workflows/new-workflow/ディレクトリに移動します。process-templateサブディレクトリには、コンポジット・ファイルが含まれたZIPファイルのアーカイブが格納されています。このコンポジット・ファイルは、新しいコンポジットを作成するためにベース・ファイルとして使用します。
-
次のコマンドを実行します。
ant -f new_project.xml compliance
次の選択を行うよう求められます。
1 - アイデンティティ監査コンポジット
2 - 証明コンポジット[デフォルト]
-
オプション2の証明コンポジットを選択します。
-
プロンプトが表示されたら、新しいコンポジットの名前を入力して、
[Enter]
を押します。コンポジットが作成され、コンポジットに指定した名前のパッケージ・ディレクトリがprocess-templateサブディレクトリに作成されます。
-
-
JDeveloperでコンポジットを開きます。そのように行うには:
-
process-templateディレクトリに移動します。
-
ステップ1cで指定したコンポジット名のディレクトリに移動します。
-
JDeveloperを使用して、COMPOSITE_NAME.jprを開きます。
-
-
「アプリケーション・ナビゲータ」ビューの「プロジェクト」ペインでプロジェクトを開いて、「CertificationTask.task」をダブルクリックして編集します。「割当て」タブをクリックします。「Stage1.Participant」オブジェクトをクリックして、「編集」を選択します。「参加者タイプの編集」ダイアログ・ボックスが表示されます。デフォルトでは、このコンポジットで単一の証明のレベルが定義され、証明は1人のレビューアに割り当てられます。たとえば、証明のレベルを変更するには、現在のタスクの割当て先のマネージャに移動して、次の値を設定します。
ノート:
この手順で説明するカスタマイズはサンプルです。詳細なカスタマイズは、CertificationOverseerProcessデフォルト・テンプレートや、SOAのドキュメントを参照してください。
-
タイプ: 「シリアル」。シリアル証明ロジックのみがサポートされます。
-
参加者のリストの作成で使用: 「管理チェーン」
-
属性の指定で使用: 「値ベース」
-
開始参加者: 証明を開始するユーザーを選択します。
-
最上位の参加者: 「役職別」。証明レビューの最上位の参加者になるレビューアの役職を指定します。最上位の参加者としてVPを指定し、レベル数として5を指定すると、証明はレベル3であっても、VPレベルにまで引き上げられます。その他のレベルは、スキップされます。
-
レベル数: 「番号別」。1を指定すると、証明はマネージャのレベルまでになります。2を指定すると、証明はマネージャのマネージャまでになります。
-
タスクの単一への自動割当て: 「ユーザー」
-
割当てパターン: 「最もビジーでない箇所」
-
-
「OK」をクリックします。
-
コンポジットをデプロイします。そのように行うには:
- 「ファイル」、「すべて保存」を選択して、作業を保存します。
- プロジェクトを右クリックし、「デプロイ」、「COMPOSITE_NAME」、「アプリケーション・サーバーにデプロイ」の順に選択します。または、SAR (SOAアーカイブ)にデプロイしてから、Oracle Enterprise Managerを使用してデプロイできます。
-
Oracle Identity Self Serviceにログインし、新しくデプロイしたコンポジットを「構成」ページで選択して、証明の定義を作成します。証明の定義の作成の詳細は、『Oracle Identity Governanceでのセルフ・サービス・タスクの実行』の証明の定義の作成に関する項を参照してください。
11.11 アイデンティティ監査コンポジットのカスタマイズ
アイデンティティ監査コンポジットをカスタマイズし、新規のアイデンティティ監査スキャン定義を作成できます。
アイデンティティ監査コンポジットをカスタマイズするには:
-
コンポジットを作成します。そのように行うには:
-
OIM_HOME/server/workflows/new-workflow/ディレクトリに移動します。process-templateサブディレクトリには、コンポジット・ファイルが含まれたZIPファイルのアーカイブが格納されています。このコンポジット・ファイルは、新しいコンポジットを作成するためにベース・ファイルとして使用します。
-
次のコマンドを実行します。
ant -f new_project.xml compliance
次の選択を行うよう求められます。
1 - アイデンティティ監査コンポジット
2 - 証明コンポジット[デフォルト]
-
オプション1のアイデンティティ監査コンポジットを選択します。
-
プロンプトが表示されたら、新しいコンポジットの名前を入力して、
[Enter]
を押します。コンポジットが作成され、コンポジットに指定した名前のパッケージ・ディレクトリがprocess-templateサブディレクトリに作成されます。
-
-
JDeveloperでコンポジットを開きます。そのように行うには:
-
process-templateディレクトリに移動します。
-
ステップ1dで指定したコンポジット名のディレクトリに移動します。
-
JDeveloperを使用して、COMPOSITE_NAME.jprを開きます。
-
-
IdentityAuditRemediationTask.task
を編集して、IdentityAuditTask割当てのすべてのカスタマイズを行います。 -
必要なコールバック(「タスク完了」、「エスカレーション」、「有効期限」、「ルーティング」、「再割当て」および「プロキシ」)が構成されていることを確認します。新規に作成したコンポジットまたはデフォルトのアイデンティティ監査修正コンポジットで構成されたコールバックを参照します。
-
変更を保存します。
-
コンポジットをコンパイルして、コンポジットJARファイルをSOAにデプロイします。詳細は、SOAのドキュメントを参照してください。
-
Oracle Identity Self Serviceにログインし、アイデンティティ監査構成コンポジット参照から新規に作成したコンポジットを使用して新規アイデンティティ監査スキャン定義を作成します。