| Oracle® Fusion Middleware Oracle Identity Manager開発者ガイド 11g リリース2 (11.1.2.2.0) B69536-07 |
|
 前 |
 次 |
この章では、Oracle Identity Managerのワークフローの概念、機能およびアーキテクチャについて説明します。ワークフローのユースケース、最初のワークフローの設計、実装およびデプロイの手順を示します。また、この章では、プラグイン・ポイントを使用してリクエスト管理操作を拡張する方法についても説明します。
この章の内容は次のとおりです。
この項では、主なワークフローの概念について、次の各項で説明します。
ユーザー・アクセスを管理し、ビジネス・プロセスを編成して、ユーザーが適切なアクセス権を取得できるようにすることが、アイデンティティ制御の主要機能となります。ユーザーのアクセスを変更するプロセスは、ポリシーをトリガーするHRのイベントを介してユーザーが開始するか、または管理者が開始することができます。アクセスの変更がどのように開始されるかに関係なく、組織には次の要件があります。
開始されるビジネス・プロセスは柔軟で、組織の変化するビジネス・ルールに適合できる必要があります。
ビジネス・プロセスでは、即時アクセス権を付与するか、アクセス権を付与する前に手動操作の手順を導入して承認を求めるかを決定できる必要があります。
ビジネス・プロセスは、リクエストされた内容、リクエスト者、リクエストの対象者およびコンテキストに関する職務の分離(SoD)チェックなど、検証を実行できる必要があります。
手動操作が必要な場合、ビジネス・プロセスには、ユーザーまたはユーザー・グループに割り当てる機能、および応答がタイミングよく受信されなかったときにエスカレーション、再割当てまたは期限切れの処理を行う機能が必要です。
手動操作の場合、ビジネス・プロセスには、承認者から、コメントや添付ファイルなどの情報を収集する機能が必要です。
アクセス権の自動付与が不可能な場合、または組織のルールによって手動によるアクセス権付与が必要な場合、ビジネス・プロセスでは、外部システム(チケット発行システムなど)と対話できる必要があります。
すべての決定およびアクションを監査し、報告可能な方法で利用可能にして、組織がプロセスのパフォーマンスを計測したり、監査者がコンプライアンス要件を満たすことができるようにする必要があります。
Oracle Identity Managerでは、組織がこれらの要件を満たすことができる、柔軟かつ強力なアクセス・リクエスト機能が提供されています。
Oracle Identity Managerのワークフローの主要概念として、次のような用語があります。
リクエスト
Oracle Identity Managerでは、リクエストは、あるアイデンティティまたはアカウントで操作を実行する必要がある場合に起動されるビジネス・プロセスを指します。これらの操作の例として、ユーザーの作成、アカウントのプロビジョニング、ユーザーへのロールの付与があります。リクエストには、すぐに履行可能な場合(直接的な操作)と、承認の形式で手動操作が必要な場合(リクエストベースの操作)があります。ユーザーが操作を実行しようとすると、Oracle Identity Managerは、その操作が直接的であるか、ログイン中のユーザーの認可ポリシーに基づくリクエストベースであるかを確認します。
リクエスト・レベルの承認
リクエストは、履行に進む前に、2つの独立した承認プロセスを通過する必要があります。リクエスト・レベル承認および操作レベル承認です。リクエスト・レベル承認は最初に起動され、操作レベル承認が後に続きます。リクエスト・レベル承認は主にバルク・リクエストに使用されますが、バルク・リクエストには複数のターゲット・ユーザー、複数のリクエストされたエンティティ、またはその両方の任意の組合せが関係します。
バルク承認の場合は、リクエスト・レベル承認が受信されると、リクエスト・エンジンによって、リクエストが個々のターゲット・ユーザーおよびリクエストされた操作またはエンティティの組合せに分割され、組合せごとに操作の承認が起動されます。
操作レベルの承認
操作レベル承認は、2番目の承認プロセスであり、リクエスト承認の一環として起動されます。操作の承認は、常に単一のターゲット・ユーザーおよび単一の操作またはリクエストされたエンティティに対して行われます。
承認ポリシー
承認ポリシーは、リクエスト・エンジンが、起動する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コンポジットを起動して、それにリクエスト、リクエスタおよびターゲット・ユーザーに関するいくつかの基本情報を渡します。この情報をリクエスト・ペイロードと呼びます。
ヒューマン・タスク
ヒューマン・タスクにより、ユーザーまたはグループが、エンドツーエンドのビジネス・プロセス・フローの一環として実行するタスクを記述するワークフローのモデリングが提供されます。
ワークフローは、Oracle Identity Managerで次の目的に使用されます。
承認のために、承認者にリクエストをルーティングする
履行のために、ITプロビジョナまたはヘルプ・デスクに手動のプロビジョニング・タスクをルーティングする
図21-1に、Oracle Identity Managerのワークフローの概要を示します。
図21-1では、次のアクションが発生しています。
ユーザーは、結果としてリクエストになる操作を開始します。そのような操作の例を次に示します。
自己登録
ユーザー・プロファイルの変更(ただし、ロックの、ロック解除およびパスワードの管理操作を除く)
ロール付与操作
アプリケーション・インスタンス操作(接続なしのプロビジョニングを含む)
権限操作
バルク操作
リクエストが作成されます。適切な検証の後に、リクエスト・エンジンは承認ポリシーを評価し、起動するSOAコンポジットを選択します。
承認ポリシーが構成されていない場合、リクエスト・レベル承認に対してはデフォルトのリクエスト・レベルSOAコンポジットが選択され、操作レベル承認に対してはデフォルトの操作レベルSOAコンポジットが選択されます。
SOAコンポジットには、Business Process Execution Language (BPEL)プロセスが含まれています。
BPELプロセスは、Webサービスを起動して、リクエストに関する次のような詳細を取得します。
|
注意: このステップはオプションです。これは、BPELプロセスで様々なエンティティに関連する追加情報が必要な場合にのみ、必要です。 |
カタログからの項目の詳細
ターゲット・ユーザー情報
リクエスタ情報
BPELプロセスは、優先度、承認者および通知などのプロパティを計算するために、追加のロジックを起動します。
承認および手動の履行中など、手動操作が必要な場合、プロセスはヒューマン・タスクを起動します。
ヒューマン・タスクには、ユーザーまたはロールに対して承認タスクの割当て、期限切れ、エスカレーションを実行するためのロジックが含まれます。ヒューマン・タスクは、ユーザーおよびロールを静的または動的に割り当てることができます。静的割当ての場合、BPELプロセスで承認者を決定し、パラメータとしてヒューマン・タスクに渡すことができます。動的割当ての場合、Oracle Business Rules (OBR)で作成されたルールを使用して、承認者が動的に決定されます。
通常、BPELプロセスには1つのヒューマン・タスクが含まれます。インスタンスによっては、BPELプロセスで複数のヒューマン・タスクのうちの1つを選択するデシジョン・ポイントが起動される場合があります。
ヒューマン・タスクが完了すると、(承認の)承認または拒否のレスポンス、あるいは(手動履行の)完了のレスポンスが、Oracle Identity Managerへのコールバック・サービスを介して戻され、操作が再開されます。
表21-1に、承認プロセスとして使用可能なOracle Identity Managerにおける事前定義済SOAコンポジットを示します。
表21-1 事前定義済ワークフロー・コンポジット
| ワークフロー・コンポジット | 説明 |
|---|---|
|
DefaultRequestApproval |
デフォルトのリクエスト・レベルの承認。デフォルトでは、リクエスト・レベルの承認の場合、SYSTEM ADMINISTRATORSロールに送信されます。 さらに、このコンポジットが証明ユースケースによって呼び出されます。タスクは次のいずれかの状態になります。
注意: 証明ユースケースの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のアイデンティティ証明の管理に関する項を参照してください。 |
|
DefaultOperationalApproval |
デフォルトの操作レベルの承認。デフォルトでは、操作レベルの承認の場合、承認タスクはSYSTEM ADMINISTRATORSロールに割り当てられます。 さらに、コンポジットが証明ユースケースによって呼び出され、タスクが自動承認されます。 |
|
BeneficiaryManagerApproval |
これは、受益者のマネージャの承認を必要とします。これは次のものと関連付けることができます。
リクエスト・レベルでは、リクエストに複数の受益者が存在する可能性があるため、このコンポジットは、承認の操作レベルで関連付けられる必要があります。 |
|
DefaultRoleApproval |
このSOAコンポジットにより、承認のためにSYSTEM ADMINISTRATORSロールに割り当てられる単一の承認タスクが作成されます。 |
|
RequesterManagerApproval |
このSOAコンポジットにより、承認のためにリクエスタのマネージャに割り当てられる単一の承認タスクが作成されます。 注意: このコンポジットは、承認されていないリクエスト・モデル(ユーザーの自己登録など)に関連付けることはできません。 |
|
DefaultSODApproval |
このSOAコンポジットにより、システム管理者に割り当てられる承認タスクが作成され、SoDチェックが開始されて、SoDの結果が使用可能になると、SoD管理者ロールに割り当てられる別の承認タスクが作成されます。これは、SoDチェックの必要に応じて、操作レベルでリソースをプロビジョニングまたは変更するリクエスト・モデルに関連付けられる必要があります。 |
|
DisconnectedProvisioning |
このSOAコンポジットは、システム管理者にタスクを割り当て、接続なしのプロビジョニングを実行します。 |
|
ProvideInformation |
このSOAコンポジットは、アカウント/権限の詳細を要求しているリクエスタにタスクを割り当てます。詳細は、『Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド』のリクエスト内の権限およびアカウントの依存性に関する項を参照してください。 |
|
CertificationProcess |
これは、デフォルトの証明コンポジットです。このコンポジットは、証明タスクの証明者(ユーザー)への割当てに対応します。このコンポジットは、次の証明タスク・イベントの管理も行います。
|
|
CertificationOverseerProcess |
このコンポジットは、証明タスクを証明者(ユーザー)に割り当てます。さらに、コンポジットは、証明者のタスクの完了後の監督者へのタスクのルーティング処理も行います。Oracle SOA Business Rulesを使用してタスクのルーティングが処理されます。このコンポジットは、次の証明タスク・イベントに対応します。
|
承認プロセスとして使用できる新規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コンポジットにあります。
Oracle Identity Managerでは、カスタムSOAコンポジットを作成するヘルパー・ユーティリティが提供されます。このユーティリティでは、必要な基準のすべてに準拠したテンプレートSOAプロジェクトが作成されます。このユーティリティは、OIM_HOME/workflows/new-workflowディレクトリに配置されています。
|
注意:
|
ヘルパー・ユーティリティを実行してカスタムSOAコンポジットを作成するには、次の手順を実行します。
次のコマンドを実行します。
cd OIM_HOME/workflows/new-workflow
ant -f new_project.xml
次のプロンプトが表示されたら、JDeveloperアプリケーション名を入力します。
Please enter application name
次のプロンプトが表示されたら、JDeveloperプロジェクト名を入力します。
Please enter project name
次のプロンプトが表示されたら、コンポジットのADFバインディング・サービスの名前を入力します。
Please enter the service name for the composite. This needs to be unique across applications
OIM_HOME/workflows/new-workflow/process-template/ディレクトリに新規アプリケーションが作成されます。新規アプリケーションは、JDeveloperで開いて変更できます。
テンプレートSOAコンポジットのヒューマン・タスクは、ヒューマン・タスクの割当て先に通知を送信するよう構成されています。作成されたカスタム・コンポジットでは、要件に応じて通知メッセージを変更できます。承認者に送信されるすべての通知は、SOAコンポジットで構成する必要があります。通知を送信するようにOracle SOAサーバーを構成する方法は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle User Messaging Serviceの構成に関する説明を参照してください。
テンプレートSOAコンポジットのヒューマン・タスクは、SYSTEM ADMINISTRATORSロールに割り当てられるよう構成されています。
BPELへのワークフロー・コンポジットのデプロイの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
|
注意: コンポジットがSOAで再デプロイされる場合、コンポジットによって開始されたOracle Identity Managerの保留中のすべての承認が失効となり、ユーザーのTaskListから削除されます。既存のSOAコンポジットのデプロイの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のOracle JDeveloperでの既存のSOAアーカイブのデプロイに関する説明を参照してください。 |
Oracle Identity Managerとの通信でSSLモードを使用している場合は、次を実行する必要があります。
|
注意: 非SSL接続の場合は、この項をスキップしてください。 |
TRUSTSTORE_LOCATION環境変数を設定します(TRUSTSTORE_LOCATIONは信頼できるキー・ストア・ファイルの場所です)。
t3プロトコルではなくt3sプロトコルを使用します。たとえば、Oracle Identity ManagerのURLは次のようになります。
t3s://HOST_NAME:PORT
この項では、最初のワークフローを設計する方法について、次の各項で説明します。
このチュートリアルは、次のユースケースに基づいています。
Vision Corp社は、FinApp(メインフレームベースのアプリケーション)を使用しています。このアプリケーションは、リモートから起動可能なAPIを持ちません。したがって、アカウントはヘルプ・デスクによって手動で管理されます。
Vision Corp社の従業員は、アクセス・リクエスト・カタログを使用して、アプリケーションでアカウントおよび権限をリクエストします。
承認は、リクエストされているアクセスのリスク・レベルに基づいて行われます。リスク・レベルが低い場合、必要なのは受益者のマネージャの承認のみです。リスク・レベルが中の場合、受益者のマネージャまたは認証者の承認が必要です。リスク・レベルが高の場合、受益者のマネージャおよび監査レビュー・チームの承認が必要です。
承認の後、リクエストはアセット管理チームのメンバーによって履行される必要があります。
このチュートリアルでは、アプリケーションとワークフローの作成方法、およびアプリケーションでの承認および履行の構成方法について説明します。
このチュートリアルでは、次の結果が得られます。
アプリケーション・インスタンス
次で構成される、承認用のSOAコンポジット
1つのBPELプロセス
複数のヒューマン・タスク
事前定義された接続なしのプロビジョニングSOAコンポジットの変更
このチュートリアルでは、次を前提としています。
Oracle SOA Suiteは、SOAインフラストラクチャが構成されているホストにインストールされています。
JDeveloper 11.1.1.7と、SOA Design Time 11.1.1.7が使用可能です。
SOA Jdeveloper拡張の必須パッチがある場合はそれが適用されています。必須パッチの詳細は、Oracle Fusion Middlewareリリース・ノートのOracle Identity Managerのインストールに必要な必須パッチに関する項を参照してください。
BPELアクティビティやパートナ・リンクなどの基本的なBPEL構成要素と、基本的なXPath関数について理解しているユーザーを対象にしています。
SOAコンポジット・エディタとOracle BPELデザイナ(BPELプロセスを設計およびデプロイするための環境)を熟知している必要があります。ただし、SOAコンポジットの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
2つのロール(監査レビュー・チームおよびアセット管理チーム)が作成され、メンバーが割り当てられています。
Visionという名前の組織が作成されています。
この項には次のトピックが含まれます:
FinAppアプリケーション・インスタンスを作成するには、次の手順を実行します。
Oracle Identity System Administrationにログインします。
「サンドボックス」をクリックして、サンドボックス管理にアクセスし、サンドボックスを作成し、それをアクティブにします。サンドボックスの詳細、サンドボックスの作成、アクティブ化および公開方法については、「サンドボックスの管理」を参照してください。
「構成」で、「アプリケーション・インスタンス」をクリックします。ツールバーで「作成」をクリックして、「アプリケーション・インスタンスの作成」ページを開きます。
「名前」および「表示名」に、FinAppと入力します。
「切断」オプションを選択して、接続なしアプリケーション・インスタンスを指定します。
「保存」をクリックし、「OK」をクリックして、FinAppアプリケーション・インスタンスの作成を確認します。
アプリケーション・インスタンスの属性を定義し、フォームを作成するには、次の手順を実行します。
「構成」で、「フォーム・デザイナ」をクリックします。
FinAppフォームを検索して選択します。このフォームは、接続なしアプリケーション・インスタンスを保存すると自動的に作成されます。
|
注意: フォームを作成して編集するには、アクティブなサンドボックスで作業している必要があります。 |
「フィールド」タブをクリックし、ツールバーで「編集」アイコンをクリックします。
デフォルトでは、次のフィールドが作成され、使用可能になります。
| フィールド | 説明 |
|---|---|
| ITリソース | アカウントが作成されるITリソース・インスタンス |
| アカウント・ログイン | アプリケーションのログイン |
| パスワード | アプリケーションへのログイン中に使用されるパスワード |
| アカウントID | アカウントの作成時に、アプリケーションによって生成される一意の識別子 |
| サービス・アカウント | アクセス・リクエスト中のみに使用されるフラグ |
|
注意: 「アカウントID」および「ITリソース」などの属性は、通常、アクセス・リクエスト・ユーザー・インタフェースには表示されません。ユースケースによっては、これらの属性と関係がない場合があります(たとえば、携帯電話リクエスト)。これらの属性を非表示にする場合は、フォームをカスタマイズできます。フォームをカスタマイズする方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のカスタム属性の構成に関する説明を参照してください。 |
属性を追加します。この例では、次の属性を追加します。
Account Description: データ型はTextです。
|
注意: カスタム属性の作成の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のカスタム属性の構成に関する項を参照してください。 |
属性を追加した後、「フィールド」タブの構成が次の表と同等であることを確認します。
| ラベルの表示 | 名前 | タイプ |
|---|---|---|
| アカウントの説明 | AccountDescription | テキスト |
| アカウントID | UD_FINAPP_ACCOUNTID | テキスト |
| ITResource | UD_FINAPP_IT | 数値 |
| アカウント・ログイン | UD_FINAPP_LOGIN | テキスト |
| パスワード | UD_FINAPP_PASSWORD | テキスト |
| サービス・アカウント | serviceaccount | チェックボックス |
ユーザーが権限をリクエストするのを許可するには、子オブジェクトを追加し、権限としてタグ付けされる属性を追加する必要があります。これを行うには、次の手順を実行します。
「子オブジェクト」タブをクリックし、ツールバーで「追加」をクリックします。
子オブジェクト名を入力し、「OK」をクリックして子オブジェクトを作成します。
作成した子オブジェクトをクリックします。
「アクション」、「作成」の順に選択し、新規属性を作成します。ポップアップ・ウィンドウから「参照」を選択し、「OK」をクリックします。次のフィールドの値を入力します。
名前: プロファイル名
表示名: プロファイル名
「バルクで使用」を選択して、複数のユーザーのアクセスをリクエストするときに、リクエスタによる値の指定を許可します。
「参照タイプ」下の新規参照タイプの作成をクリックします。
次に示すように、新しいLookupを作成し、値を指定します。
コード: Lookup.FinApp.Profile
Meaning: Lookup.FinApp.Profile
Description: Lookup.FinApp.Profile
次の表に示す値を使用して、3つの参照コードを作成します。
| 意味 | コード |
|---|---|
| FinAppユーザー | FinAppUser |
| FinApp管理者 | FinAppAdministrator |
| FinAppオペレータ | FinAppOperator |
|
注意: スケジュール済タスクと参照APIを使用して、参照定義を移入することもできます。 |
「検索可能」、「権限」および「「検索可能」ピックリスト」オプションを選択します。
「保存して閉じる」をクリックします。
「親オブジェクトに戻る」をクリックします。
「ビューの再生成」をクリックして、新しい属性でUIフォームを再作成します。
すべてのタブを閉じます。
サンドボックスを公開します。
1つ以上の組織にアプリケーション・インスタンスを公開するには、次の手順を実行します。
FinAppアプリケーション・インスタンスの詳細ページを開き、「組織」タブをクリックします。
「割当て」をクリックします。「組織の選択」ダイアログ・ボックスで、アプリケーション・インスタンスを公開する組織を1つ以上選択します。
アプリケーション・インスタンスをその組織と子組織に公開する場合は、「階層」オプションを選択します。
「OK」をクリックします。
権限をアプリケーション・インスタンスにリンクするには、次の手順を実行します。
カタログにアプリケーション・インスタンスとその権限を公開するには、次の手順を実行します。
「システム管理」で「スケジューラ」をクリックします。
カタログの同期化スケジュール済ジョブを検索し、「即時実行」をクリックします。
カタログでアプリケーション・インスタンスとその権限を構成するには、次の手順を実行します。
Oracle Identity Self Serviceにカタログ管理者としてログインします。
「リクエスト」で「カタログ」をクリックします。
「カタログ」ページで、アプリケーション・インスタンスを検索します。
アプリケーション・インスタンスを選択し、カタログ項目の詳細を編集します。
デフォルト属性の値を提供します。このチュートリアルでは、リスク・レベルと手動の履行に基づいてワークフロー・ルーティングが行われるため、「リスク・レベル」と「履行ロール」属性の値を指定する必要があります。ただし、その他の属性の値も指定することをお薦めします(特に「ユーザー定義タグ」)。
図21-4は、カタログ項目の属性を示しています。
この項には次のトピックが含まれます:
新しい承認ワークフローを作成するには、次の手順を実行します。
WebLogic Serverのインストール・ディレクトリの/server/bin/サブディレクトリにあるsetWLSEnv.shスクリプトを実行して、JAVA_HOME環境変数を設定します。
ANT_HOME環境変数をMIDDLEWARE_HOME/modules/org.apache.ant_1.7.1に設定します。
PATH環境変数を$JAVA_HOME/bin:$ANT_HOME/bin:$PATHに設定します。
OIM_HOME/server/workflows/new_workflowに移動します。
次のコマンドを実行します。
ant-f new_project.xml
アプリケーション名としてAddAccessApprovalApplicationを指定します。
プロジェクト名としてAddAccessApprovalを指定します。
サービス名としてAddAccessを指定します。
ユーティリティによってコンポジットを含む新しいJDeveloperワークスペースが生成されるまで待ちます。ワークスペースは、/server/workflows/new-workflow/process-template内に生成されます。
そのディレクトリをJDeveloperからアクセス可能な場所にコピーします。
BPELプロセスに対してリクエストおよびカタログ・データを使用可能にするには、次の手順を実行します。
BPELプロセスの「設計」ビューに切り替えます。
コンポーネント・パレットからinvokeアクティビティをドラッグして、AssignRequestWSURLアクティビティの後にドロップします。名前をInvokeRequestDetailsOperationに変更します。
「InvokeRequestDetailsOperation」を右クリックし、「編集」を選択します。
図21-5に示すように、「パートナ・リンク・チューザ」からパートナ・リンクとしてRequestWSPartnerLinkを、操作としてgetRequestDetailsを選択します。
「変数」セクションの「入力」および「出力」フィールドでプラス(+)アイコンをクリックして、入力変数および出力変数を作成します。入力変数にrequestDetails_InputVariable、出力変数にrequestDetails_OutputVariableという名前を付けます。「適用」をクリックし、「OK」をクリックします。
assignアクティビティをドラッグ・アンド・ドロップし、名前をAssignRequestInputに変更し、図21-6に示すようにInvokeRequestDetailsOperation invokeアクティビティの前に配置します。
「AssignRequestInput」を右クリックして、「編集」を選択して、図21-7に示すようにInvokeRequestDetailsOperationの入力をマップします。
図21-8に示すように、InvokeアクティビティをInvokeRequestDetailsOperationの後に追加します。そのアクティビティにInvokeCatalogOperationという名前を付けます。
InvokeCatalogOperationを編集し、図21-9に示すように構成します。
図21-10に示すように、AssignアクティビティをInvokeCatalogOperationの後に追加します。そのアクティビティにAssignCatalogInputという名前を付けます。
|
注意: 次の属性は、リクエストWebサービスのcatalog detailメソッドから、カスタム属性として返されます。
|
assignアクティビティを右クリックして編集し、図21-11に示すように入力をInvokeCatalogOperationにマップします。
ワークフロー選択ルールを定義するには、次の手順を実行します。
catalogDataという変数を「タイプ-要素CatalogData」として定義します。これを行うには、「変数」アイコンをクリックし、「変数」ダイアログ・ボックスの「作成」アイコンをクリックします。
この変数には、InvokeCatalogDetailsステップの出力として返されるカタログ詳細が格納されます。
workflowtypeという変数を「タイプ-要素StageOutput」として定義します。この変数には、呼び出されるワークフローのタイプが格納されます。
「SOAコンポジット」ビューに移動し、図21-12に示すようにビジネス・ルール・コンポーネントを追加します。
「ビジネス・ルールの作成」ダイアログ・ボックスで、ルール・ディクショナリの名前としてWorkflowSelectionを指定します。
入力としてcatalogDataを、出力としてworkflowstageを指定します。
BPELプロセスに切り替えます。
SOAコンポーネントを開き、ビジネス・ルール・コンポーネントを追加します。
そのルールを編集し、WorkflowSelectionという名前に変更します。
「ルール」ダイアログ・ボックスで、「ディクショナリ」タブをクリックし、手順4で定義したWorkflowSelectionディレクトリを選択します。
図21-13に示すように、catalogData変数をルールの入力にマップします。「ディクショナリ」タブで「入力ファクトの割当て」サブタブを選択して、プラス(+)アイコンをクリックします。
図21-13に示すように、catalogData変数をルールの入力にマップします。
図21-14に示すように、workflowtype変数をルールの出力にマップします。「ディクショナリ」タブで「出力ファクトの割当て」サブタブを選択します。
図21-14に示すように、workflowtype変数をルールの出力にマップします。
図21-15に示すように、WorkflowSelectionルールの前にAssignアクティビティを追加し、その名前をAssignRuleInputに変更します。
図21-16に示すように、InvokeCatalogOperationの出力をcatalogData変数にマップします。
「SOAコンポジット」ビューに切り替えます。
ビジネス・ルール・コンポーネントを右クリックし、「編集」を選択します。
「ルールの作成」をクリックします。
そのルールの名前をRule1からAuto Approvalに変更します。
ルールを編集し、図21-17に示すように、「プロパティ」ダイアログ・ボックスでstageTypeプロパティを指定します。
stageTypeプロパティを指定するには、次の手順を実行します。
「THEN」の下の「「挿入」」アクションをクリックします。
「新規アサート」を選択します。
「新規アサート」の隣に追加された「<ターゲット>」をクリックして、「ステージ」を選択します。
<プロパティの編集>をクリックします。図21-17に示すように、「プロパティ」ダイアログ・ボックスが表示されます。
同様に、図21-18に示すように、「マネージャ」、「シリアル」、および「パラレル」承認ルールを作成します。
BPELプロセスに切り替えます。
図21-19に示すように、WorkflowSelectionルールの後にswitchアクティビティを追加します。
そのSwitchアクティビティを選択し、図21-20に示すように2つのSwitch Caseステップを追加します。
図21-21に示すように、条件の名前をSerial Approval、Parallel Approval、Manager Approvalに変更します。
図21-22に示すように、デフォルト・ヒューマン・タスクをManager Switch Caseにドラッグします。
「SOAコンポジット」ビューに切り替えます。
図21-23に示すように、SerialApprovalとParallelApprovalの2つのヒューマン・タスクを追加します。
BPELプロセスに切り替えます。
Manager Approval Switch Caseを編集し、次の式を追加します。
bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType')='Manager'
最初に、新しく追加したタスクを構成し、次にそれらをBPELプロセスに書き込む必要があります。
|
注意: 式の追加には式ビルダーの使用をお薦めします。 |
ヒューマン・タスクを構成する手順は次のとおりです。
パラレル・ヒューマン・タスクを構成するには、次の手順を実行します。
「SOAコンポジット」ビューに切り替えます。
パラレル承認タスクを編集します。
「データ」タブをクリックし、次の表に示す属性を追加します。
| パラメータ | データ型 |
|---|---|
| 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 |
「データ」タブでタスク・パラメータを確認します。
「一般」タブをクリックします。
「タスクのタイトル」を<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approvalに設定します。これを行うには、次の手順を実行します。
タスク・タイトルの横の「編集」をクリックし、「task:payload」、「ns2:BeneficiaryDetails」、「ns2:DisplayName」の順に選択します。
「式に挿入」をクリックします。図21-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に設定します。
「通知」タブをクリックし、次に「詳細」をクリックします。
「通知をアクション可能にする」オプションを選択します。
「割当て」タブをクリックします。
パラレル・ステージを追加します。これを行うには、フロー・チャートで「ステージ1」を選択し、プラス(+)アイコンをクリックし、「パラレル・ステージ」を選択します。
ステージを選択し、「編集」をクリックします。名前としてManagerを指定します。
図21-25に示すように、もう一方のステージを選択し、名前としてReview Teamを指定します。
2つのステージの後の鉛筆アイコンをクリックします。
「投票結果」ダイアログ・ボックスで、投票結果をAPPROVEに設定します。デフォルト結果をREJECTに設定します。これは、両方の承認者がタスクを拒否した場合、リクエストが、デフォルト結果に基づいて完了状態に移動するためです。
「添付ファイルとコメントの共有」オプションを選択します。
「投票結果」ダイアログ・ボックスで、「OK」をクリックします。
「最小のパーセントに達するとただちに投票結果がトリガーされます」オプションが選択されていることを確認します。
Managerステージで<参加者の編集>を選択し、「編集」をクリックします。
「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定します。「参加者のリストの作成で使用」リストから、 「ルールベース」を選択し、ルールを使用して参加者リストを作成します。
「ルールセットのリスト」フィールドにManagerと入力します。また、ラベルをManagerに編集します。
「参加者の追加」ダイアログ・ボックスで、「OK」をクリックします。「ParallelApprovalRules.rules」タブが表示されます。
図21-26に示すように、ルールを作成します。
|
注意: 「ルールの作成」ページで、「IF」句の「<パターンの挿入>」は、デフォルトでは表示されません。「<パターンの挿入>」を表示するには、「ルール1」ラベルの前の2つの下矢印をクリックして「ルール1」を展開し、図21-26に示すように「拡張モード」オプションを選択します。 |
同様に、「参加者タイプの追加」ダイアログ・ボックスに次の値を指定して、Review Teamステージを構成します。
タイプ: 単一。
ラベル: Review Team。
参加者のリストの作成で使用: ルールベース。
ルールセットのリスト: ReviewTeam。
「参加者が手動でタスクを申告」を選択します。
図21-27に示すように、参加者ルールを作成します。
シリアル承認タスクを構成するには、次の手順を実行します。
「SOAコンポジット」ビューに切り替えます。
シリアル承認タスクを編集します。
「データ」タブをクリックします。
次の表に示すパラメータを追加します。
| パラメータ | データ型 |
|---|---|
| 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 |
「データ」タブでタスク・パラメータを確認します。
「一般」タブをクリックします。
「タスクのタイトル」を<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approvalに設定します。
「タスク所有者」を「グループ」およびSYSTEM ADMINISTRATORSに設定します。
「通知」タブをクリックし、次に「詳細」をクリックします。
「通知をアクション可能にする」オプションを選択します。
「割当て」タブをクリックします。
順次ステージを追加し、図21-28に示すように、ステージの名前をManagerおよびReview Teamに変更します。
Managerステージを編集します。
「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定し、ルールを使用して参加者リストを作成します。
図21-29に示すように、参加者リスト・ルールを作成します。
同様に、Review Teamステージを構成します。
図21-30に示すように、参加者リスト・ルールを作成します。
デフォルト承認タスクを構成するには、次の手順を実行します。
「SOAコンポジット」ビューに切り替えます。
承認タスクを編集します。
「一般」タブをクリックします。
図21-31に示すように、タスクのタイトルを設定します。
「割当て」をクリックします。
Stage1.Participant1を選択し、「編集」をクリックします。
「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定します。「参加者のリストの作成で使用」リストから、 「ルールベース」を選択し、ルールを使用して参加者リストを作成します。
「ラベル」および「ルールセット」にManagerと入力し、「OK」をクリックすると、ルールが開きます。
図21-32に示すように、参加者リスト・ルールを作成します。
ヒューマン・タスクとBPELのマッピングを構成する手順は次のとおりです。
シリアル承認ヒューマン・タスクを構成するには、次の手順を実行します。
「BPEL」プロセスに切り替えます。
次の条件を、Serial Approvalスイッチに追加します。
bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType') = 'Serial'
図21-33に示すように、Human TaskアクティビティをSOAコンポーネントからSerial Approvalスイッチにドラッグ・アンド・ドロップします。
ヒューマン・タスクを編集し、「ヒューマン・タスク」ダイアログ・ボックスで、シリアル承認ヒューマン・タスク定義を選択します。
「起案者」を「リクエスタ・ログイン」にマップし、図21-34に示すように、「BPEL変数」にタスク・パラメータをマップします。
「詳細」タブをクリックします。
図21-35に示すように、識別キーをリクエストIDにマップします。
イニシエータをリクエスタ・ログインにマップし、「適用」および「OK」をクリックします。
タスク結果はREJECTのSwitch caseを選択します。
既存の条件スクリプトを次のように置き換えます。
bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:outcome') = 'REJECT'
「タスク結果はREJECT」の下のAssignアクティビティを選択および編集します。
1つを除くすべてのコピー・ルールを削除します。残すコピー・ルールは「ソース」ビューで置換できるため、どれでもかまいません。
保存して「ソース」タブをクリックします。
copyアクティビティを選択します。
そのアクティビティを、次のものに置き換えます。
<sequence>
<assign>
<copy>
<from expression="string('rejected')"/>
<to variable="outputVariable"
part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="string('rejected')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>
タスク結果はAPPROVEに対してこの手順を繰り返します。Switch Caseを選択し、「条件」フィールドに次のものをコピーします。
bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:outcome') = 'APPROVE'
承認結果の下のAssignアクティビティを選択し、そのコピー・ルールを次のものに置き換えます。
<sequence>
<assign>
<copy>
<from expression="string('approved')"/>
<to variable="outputVariable"
part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="string('approved')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>
Otherwise結果の下のAssignアクティビティを選択し、そのコピー・ルールを次のものに置き換えます。
<sequence>
<assign>
<copy>
<from expression="bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:state')"/>
<to variable="outputVariable" part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:state')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>
パラレル・ヒューマン・タスクを構成するには、次の手順を実行します。
次の条件を、Parallel Approvalスイッチ・アクティビティに追加します。
bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType') = 'Parallel'
Human TaskアクティビティをSOAコンポーネントからParallel Approvalスイッチにドラッグ・アンド・ドロップします。
パラレル承認ヒューマン・タスクを選択します。
シリアル・ヒューマン・タスクと同様の方法で、ヒューマン・タスク・パラメータをマップします。
シリアル・ヒューマン・タスクの同等物と同じ方法で、APPROVE結果のAssignアクティビティをマップします。
シリアル・ヒューマン・タスクの同等物と同じ方法で、REJECT結果のAssignアクティビティをマップします。
シリアル・ヒューマン・タスクの同等物と同じ方法で、Otherwise結果のAssignアクティビティをマップします。
|
注意: copyアクティビティで適切なグローバル変数(ParallelApproval1_globalVariable)を指定する必要があります。 |
自動承認を構成するには、次の手順を実行します。
Otherwise switch caseで、Assignアクティビティをドラッグ・アンド・ドロップします。
assignアクティビティを選択し、「ソース」ビューに切り替えます。
Assignアクティビティで、次を置き換えます。
<assign name="Assign1"/>
これを次のテキストに置き換えます。
<sequence>
<assign>
<copy>
<from expression="string('approved')"/>
<to variable="outputVariable"
part="payload"
query="/ns3:processResponse/ns3:result"/>
</copy>
<copy>
<from expression="ora:getConversationId()"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg0"/>
</copy>
<copy>
<from expression="string('approved')"/>
<to variable="Invoke_1_callback_InputVariable_1"
part="parameters"
query="/ns1:callback/arg1"/>
</copy>
</assign>
</sequence>
SOAコンポジットをデプロイするには、次の手順を実行します。
「ファイル」、「すべて保存」を選択して、作業を保存します。
プロジェクトを右クリックし、「デプロイ」、「COMPOSITE_NAME」、「アプリケーション・サーバーにデプロイ」の順に選択します。または、SAR (SOAアーカイブ)にデプロイしてから、Oracle Enterprise Managerを使用してデプロイできます。
|
注意:
|
作成したSOAコンポジットは、自己登録、作成、変更、無効化、有効化、削除など、ユーザー操作意外のすべてのリクエストに使用できます。ユーザー操作以外のすべてのリクエストでこのコンポジットが起動されるようにするには、Oracle Identity Managerで承認ポリシーを作成する必要があります。Oracle Identity Managerで承認ポリシーを作成するには、次の手順を実行します。
Oracle Identity System Administrationにログインします。
「ポリシー」で「承認ポリシー」を選択します。
Provision Application Instanceのリクエスト・レベル承認ポリシーを作成し、それを自動承認に設定します。
Provision Application Instanceの操作レベル承認ポリシーを作成し、「承認プロセス」をクリックします。
デプロイしたSOAコンポジットを選択します。
スコープ・タイプに「すべて」を指定します。
次のように、デフォルトの承認ルールを作成します。
Request.Request Type = Provision Application Instance
この承認ポリシーを保存します。
次のリクエスト・タイプに対して手順5から8を繰り返し、すべての非ユーザー操作リクエストによってSOAコンポジットが起動されるようにします。
アカウントの変更 - 権限のプロビジョニング
アカウントの有効化 - 権限の失効
アカウントの無効化 - ロール付与
アカウントの失効 - ロールの失効
|
注意: 各タイプのリクエストに対して複数の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@mydomain.com</ns5:Value>
</ns12:CustomAttribute>
たとえば、BPELプロセスでApproverRolePhoneNumberカタログのUDF値にアクセスするには、次のように指定します。
bpws:getVariableData('catalogDetails','CatalogData','/ns22:CatalogData/ns22:CustomAttribute[@Name = string("ApproverRolePhoneNumber")]/ns24:Value')
|
oim-config.xmlファイルにDefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティを設定すると、デフォルトのリクエスト・レベルおよび操作レベルのコンポジットを作成できます。これらのプロパティは、Oracle Enterprise ManagerのSystem MBean Browserを使用して編集できます。これらのプロパティのデフォルト値は、それぞれdefault/DefaultRequestApproval!3.0とdefault/DefaultOperationalApproval!3.0になります。
これらのプロパティの値は、次の形式で入力します。
NAMESPACE/COMPOSITE_NAME!VERSION
例:
default/AddAccessApproval!2.0
DefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティのデフォルト値を変更する場合は、Oracle Identity Managerを再起動する必要があります。
|
注意: デフォルトのリクエスト・レベルとして構成されたコンポジットとオペレーション・レベルのコンポジットは、すべてのリクエスト・タイプに適用できます。そのため、これらのコンポジットはすべてのリクエスト・タイプに対応するように設計する必要があります。 |
デフォルトでは、すべてのタスクは、保留中の承認のデフォルト・タスク詳細ページを使用するように構成されています。このタスクフローはカスタマイズできません。ただし、タスク詳細ページのUIをカスタマイズしたり、その他の情報を表示することはできます。この項では、独自のタスクフローを作成し、DefaultRequestApprovalコンポジットのヒューマン・タスクを構成して、そのカスタム・タスクフローを呼び出す方法を説明します。
この項には次のトピックが含まれます:
カスタム・タスク詳細タスクフローを開発する前に、コンピュータに次のソフトウェアをインストールしておく必要があります。
Oracle Identity Manager 11gリリース2 (11.1.2.2.0)
Oracle SOA 11g (11.1.1.7.0)
Oracle SOAコンポジット・エディタ拡張機能を備えたJDeveloper 11g (11.1.1.7.0)
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
タスク・フロー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
初期ページ・レイアウトおよびコンテンツ: 空白ページ
「OK」をクリックします。
このページのマネージドBeanを追加します。これを行うには、次の手順を実行します。
RequestApprovalTaskDetailsプロジェクトを右クリックして、「新規作成」→「Javaクラス」を選択します。次の値を入力します。
名前: RequestApprovalDetailsStateBean
パッケージ: oracle.iam.ui.custom.view.backing
「OK」をクリックします。
次のコードをマネージドBeanに追加します。
package oracle.iam.ui.custom.view.backing;
import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.ValueExpression;
import javax.faces.application.Application;
import javax.faces.context.FacesContext;
import oracle.iam.ui.platform.model.config.ConstantsDefinition;
public class RequestApprovalDetailsStateBean implements java.io.Serializable{
public RequestApprovalDetailsStateBean() {
super();
}
private String requestAction = ConstantsDefinition.REQUEST_ACTION_APPROVAL_UPDATE;
private String requestType = ConstantsDefinition.REQUEST_TYPE_VIEW_DETAIL;
public void setRequestAction(String requestAction) {
this.requestAction = requestAction;
}
public String getRequestAction() {
return requestAction;
}
public void setRequestType(String requestType) {
this.requestType = requestType;
}
public String getRequestType() {
return requestType;
}
public String getUserIds() {
Object benefDisplayName = getValueFromELExpression("#{bindings.DisplayName.inputValue}");
//benefDisplayName would be "None" if beneficiary does not exist
if (benefDisplayName != null && !ConstantsDefinition.NONE_BENEF_DISPLAY_NAME.equalsIgnoreCase(benefDisplayName.toString()))
return benefDisplayName.toString();
Object requestTarget = getValueFromELExpression("#{bindings.RequestTarget.inputValue}");
if (requestTarget != null)
return requestTarget.toString();
return "";
}
private Object getValueFromELExpression(String expression) {
FacesContext facesContext = FacesContext.getCurrentInstance();
Application app = facesContext.getApplication();
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext elContext = facesContext.getELContext();
ValueExpression valueExp =
elFactory.createValueExpression(elContext, expression,
Object.class);
return valueExp.getValue(elContext);
}
}
「概要」モードでrequest-approval-details-tf.xmlを開きます。「マネージドBean」セクションを選択し、次の詳細でマネージドBeanを登録します。
名前: requestApprovalDetailsStateBean
クラス: oracle.iam.ui.custom.view.backing.RequestApprovalDetailsStateBean
スコープ: pageFlow
詳細ページ構造を作成します。これを行うには、次の手順を実行します。
request-approval-details.jspxを開きます。
コンポーネント・パレットからpanelStretchLayoutをページに追加します。プロパティ・インスペクタで、panelStretchLayoutに対してTopHeght==autoを設定します。
「アプリケーション・ナビゲータ」で、「データ・コントロール」に移動します。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「Return」を開きます。図21-36に示すように「データ・コントロール」からpanelStretchLayoutのトップ・ファセットに「タスク」をドラッグ・アンド・ドロップします。コンテキスト・メニューから、「ヒューマン・タスク」→「タスク・アクション」を選択します。ヒューマン・タスク・アクションが、トップ・ファセットに追加されます。
コンポーネント・パレットから、panelTabbedレイアウトをpanelStretchLayoutの中央ファセットに追加します。
コンポーネント・パレットから、2つのshowdetailItemコンポーネントをpanelTabbedレイアウトに追加します。プロパティ・インスペクタから、これらのコンポーネントのテキスト名としてRequest InformationとTask Informationを設定します。
「リクエスト情報」タブをクリックします。プロパティ・インスペクタで属性stretchChildren=firstを設定します。
「リクエスト情報」タブで、もう1つのpanelStretchLayoutを追加します。このpanelStretchLayoutに対して属性topHeight=autoを設定します。図21-37は、「リクエスト情報」および「タスク情報」タブを示しています。
「リクエスト情報」タブに移入します。これを行うには、次の手順を実行します。
「ナビゲータの表示オプション」に移動し、図21-38に示す「ライブラリの表示」を選択します。これにより、「アプリケーション・ナビゲータ」にOIMビュー共有ライブラリが表示されます。
「アプリケーション・ナビゲータ」で、OIMビュー共有ライブラリ→WEB-INF/oracle/iam/ui/catalog/tfsを開きます。request-summary-information-tf.xmlを、手順7gで追加したPanelStretchLayoutのトップ・ファセットにドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。「リージョン」を選択します。「タスク・フロー・バインディングの編集」ダイアログ・ボックスが表示されます。タスクフローのパラメータは後から指定できます。したがって「OK」をクリックします。
同様に、catalog-tf.xmlを、手順7gで追加したPanelStretchLayoutの中央ファセットにドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。「リージョン」を選択します。「タスク・フロー・バインディングの編集」ダイアログ・ボックスが表示されます。「OK」をクリックします。
ページの下部にある「バインディング」タブをクリックし、バンディングを表示します。プラス(+)記号をクリックして、次のようにバインディングを追加します。
i) 次のように入力して、「OK」をクリックします。
カテゴリ: 一般バインディング
作成するアイテム: attributeValues
ii) 「データソースの追加」をクリックします。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」を選択します。「OK」をクリックします。
iii) 属性としてRequestIDを指定し、「OK」をクリックします。
「実行可能ファイル」の下でtaskflow-requestsummaryinformationtf1を選択します。「プロパティ・インスペクタ」で、プラス(+)記号をクリックしてタスクフロー・パラメータを追加します。この値フィールドを編集し、次に示すように#{bindings.RequestID.inputValue}で更新します。
ID=requestID、Value= #{bindings.RequestID.inputValue}
プラス記号(+)をクリックして、もう1つのバインディングを追加します。このバインディングは、RequestApprovalDetailsStateBeanで参照されます。
i) 次のように入力して、「OK」をクリックします。
カテゴリ: 一般バインディング
作成するアイテム: attributeValues
ii) 「データソースの追加」をクリックします。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」→「BeneficiaryDetails」を選択します。「OK」をクリックします。
iii) 属性としてDisplayNameを指定し、「OK」をクリックします。
プラス記号(+)をクリックして、もう1つのバインディングを追加します。このバインディングは、RequestApprovalDetailsStateBeanで参照されます。
i) 次のように入力して、「OK」をクリックします。
カテゴリ: 一般バインディング
作成するアイテム: attributeValues
ii) リストから、データソース「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」を選択します。
iii) 属性としてRequestTargetを指定し、「OK」をクリックします。
「実行可能ファイル」でtaskflow-catalogtf1を選択して、「実行可能ファイル」の右上隅の「編集」をクリックして「タスク・フロー・バインディングの編集」ダイアログ・ボックスで次の値を編集します。
Id=requestId, Value= #{bindings.RequestID.inputValue}
Id=requestType, Value=#{pageFlowScope.requestApprovalDetailsStateBean.requestType}
Id=requestAction, Value=#{pageFlowScope.requestApprovalDetailsStateBean.requestAction}
Id=userIds, Value=#{pageFlowScope.requestApprovalDetailsStateBean.userIds}
「タスク情報」タブに移入します。これを行うには、次の手順を実行します。
設計モードに切り替えます。「タスク情報」タブをクリックします。
アプリケーション・ナビゲータで、「データ・コントロール」に移動します。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「Return」を開きます。「タスク情報」タブで「タスク」をドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。図21-39に示すように、「ヒューマン・タスク」→「ペイロードのない完了済タスク」を選択します。
panelGroupLayout内にラップされているpanelHeaderが、「タスク情報」タブに追加されます。panelHeaderに移動し、panelHeaderのツールバー・ファセットを削除します。タスク・アクションは、すでに手順7cにあります。さらに、タスク詳細、タスク履歴、コメント、および添付ファイルも、「タスク情報」タブに追加されています。
作業内容を保存します。
デフォルトでは、電子メール通知の送信について、電子メール用に別のページがない場合は、「電子メール通知のカスタム・タスク詳細の開発(オプション)」で開発した同じ詳細ページが電子メール通知で送信されます。
場合によっては、電子メール通知で送信する情報を制限する必要があります。そのような場合は、電子メール通知用に別のページを開発できます。電子メール・ページも、同じタスク詳細タスクフローの一部になります。
電子メール用カスタム・タスクフローの作成の詳細は、Oracle Fusion Middleware Oracle SOA Suite開発者ガイドの電子メール通知の作成に関する項を参照してください。
タスク詳細タスクフローをデプロイするには、次の手順を実行します。
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管理対象サーバーを再起動して、カスタム共有ライブラリへの変更を反映します。
ヒューマン・タスクとタスクフロー権限を構成するには、次の手順を実行します。
認可ポリシー・マネージャ(APM)を使用して、カスタム・タスクフローの表示権限を追加します。これを行うには、次の手順を実行します。
WebLogicユーザーとしてAPMアプリケーションにログインします。
「アプリケーション」→「OracleIdentityManager」→「リソース・タイプ」に移動します。「開く」をクリックします。
「新規作成」をクリックして、新しいリソース・タイプを作成します。次の情報を指定します。
表示名: ADFタスク・フロー
名前: ADFTaskFlows
アクション: パーソナライズ、カスタマイズ、付与、表示。各アクションを追加するには、「新規」をクリックします。
リソース階層のサポート: いいえ
リソース・デリミタ: スラッシュ(/)
評価ロジック: 権限クラス
権限クラス: oracle.adf.controller.security.TaskFlowPermission
アクション名デリミタ: カンマ(,)
「保存」をクリックします。
「アプリケーション」→「OracleIdentityManager」→デフォルト・ポリシー・ドメイン→リソース・カタログ→「リソース」に移動します。「開く」をクリックします。
「新規」をクリックして、新規リソースを作成します。次の値を入力して、「保存」をクリックします。
リソース・タイプ: 手順1(c)で作成したリソース・タイプを選択します。
表示名: カスタム・タスクフローの表示名を入力します。
名前: カスタム・タスクフローの名前を次の形式で入力します。
TASKFLOW_DOCUMENT#TASKFLOW_ID
例:
/WEB-INF/request-approval-details-tf.xml#request-approval-details-tf
説明: カスタム・タスクフローの説明を入力します。
|
注意: 手順1(f)で説明したように、カスタム・タスクフローには、それぞれリソースを作成する必要があります。すべてのカスタム・タスクフローに対して、手順1(c)で作成したリソース・タイプと同じものを使用できます。 |
「アプリケーション」→「Oracle Identity Manager」→デフォルト・ポリシー・ドメイン→「認可ポリシー」に移動します。「開く」をクリックします。
「プリンシパルによる検索」を選択し、「検索」をクリックします。表示されている既存のポリシーを追加する場合は、それを選択し「開く」をクリックします。それ以外の場合は、「新規」をクリックしてポリシーを作成します。
新しいポリシーの名前およびプリンシパルを追加します。
「ターゲットの追加」(+)記号をクリックします。ターゲットの検索ダイアログ・ボックスが表示されます。
「リソース」タブをクリックします。手順1(f)で定義したリソース・タイプを指定して、「検索」をクリックします。
手順1(f)で作成したリソースを選択します。「選択した項目の追加」をクリックします。
「ターゲットの追加」をクリックします。リソースが「ターゲット」表に追加されます。
表に追加したリソースを展開します。タスクフローに適用する権限を選択します。
「適用」をクリックします。
カスタム・タスクフローを使用するようにヒューマン・タスクを構成します。これを行うには、次の手順を実行します。
WebLogicユーザーとしてOracle Enterprise Managerにログインします。
「Farm_IAM_DOMAIN」→「SOA」→「soa_infra (SOA_SERVER」)→「デフォルト」→「DefaultRequestApproval [4.0]」に移動します。
「コンポーネント・メトリック」→「承認タスク」をクリックします。
「管理」タブをクリックします。
次に示すように、既存のエントリのURIを、カスタム・タスクフローを指すように変更します。
アプリケーション名: ANY_NAME
ホスト名: OIM_SERVER_HOSTNAME
HTTPポート: OIM_HTTP_PORT
HTTPSポート: OIM_HTTPS_PORT(オプション)
URI: /identity/faces/adf.task-flow?_id=request-approval-details-tf&_document=WEB-INF/request-approval-details-tf.xml
カスタム・タスクフローをテストするには、次の手順を実行します。
エンド・ユーザーとしてOracle Identity Self Serviceにログインします。
「本人情報」に移動し、「電話」属性の値を変更します。リクエストが作成され、タスクがシステム管理者に割り当てられます。
システム管理者としてOracle Identity Self Serviceにログインします。
「保留中の承認」に移動します。
対応するリクエストの「タスクの詳細」リンクをクリックします。カスタム・タスク詳細ページが表示されます。
リクエスト・データセットは、特定のタイプのリクエストと関連付けることができるデータを格納するXMLファイルです。
|
注意: この項の情報は参照用です。リクエスト・データセットの変更、エクスポート、およびインポートは行わないことをお薦めします。ユーザーおよびアプリケーション・インスタンス定義を拡張するには、Oracle Identity System Administrationのフォーム・デザイナを使用します。フォーム・デザイナの詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のフォームの管理に関する項を参照してください。 |
表21-2に、リクエスト・タイプおよび関連付けられるOracle Identity Managerに付属のデフォルトのリクエスト・データセット・ファイル名を示します。
表21-2 Oracle Identity Managerに付属のデフォルトのリクエスト・データセット
| リクエスト・タイプ | デフォルトのデータセット・ファイル名 | エンティティ |
|---|---|---|
|
ユーザーの作成 |
CreateUserDataSet.xml |
ユーザー |
|
ユーザーの削除 |
DeleteUserDataset.xml |
ユーザー |
|
ユーザーの有効化 |
EnableUserDataset.xml |
ユーザー |
|
ユーザーの無効化 |
DisableUserDataset.xml |
ユーザー |
|
ユーザー・プロファイルの変更 |
ModifyUserDataset.xml |
ユーザー |
|
セルフ・プロファイルの変更 |
ModifyUserDataset.xml |
ユーザー |
|
ロールの作成 |
CreateRoleDataSet.xml |
ロール |
|
ロールの変更 |
ModifyRoleDataSet.xml |
ロール |
|
ロールの削除 |
DeleteRoleDataSet.xml |
ロール |
|
ロールの割当て |
AssignRolesDataset.xml |
ロール |
|
ロールからの削除 |
RemoveRolesDataset.xml |
ロール |
リクエスト管理操作の特定の側面をカスタマイズして、柔軟性を向上させたり、追加機能のカスタマイズされたロジックを実装できます。これを行うには、リクエスト管理プラグインを使用できます。カスタマイズの実装に使用できるプラグイン・ポイントがあります。
ここでは、プラグイン・ポイントについて次の各項で説明します。
Oracle Identity Managerでは、リクエストのライフサイクルの各ステージでステータスが変更されます。リクエスト・エンジンによって、リクエスト・ステータスの変更時にカスタム・コードを実行できるプラグイン・ポイントが公開されます。このプラグイン・ポイントを拡張するカスタム・コードを含むプラグインを実装し、コードを実行するために登録できます。プラグイン・ポイントは、public void followUpActions(String reqId)メソッドを含むoracle.iam.request.plugins.StatusChangeEventインタフェースです。このメソッドはリクエストIDパラメータで構成され、これとリクエスト管理APIを使用してリクエスト詳細を取得できます。
ステータス変更時に実行するコードは、oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するプラグイン・クラスのfollowUpActions()メソッドで実装する必要があります。plugin.xmlファイルでこのプラグインをどのリクエスト・ステータス変更時に実行するかを指定する必要があります。
たとえば、Oracle Identity Managerでリクエストが「リクエストに失敗しました」ステータスに移行した場合、管理者に通知を送信するカスタム・コードを実行できます。これを行うには、次の手順を実行します。
oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するRequestFailedChangeEventという名前の新しいプラグイン・クラスを作成します。このクラスには、followUpActions(String reqId)メソッドで管理者に通知を送信するロジックが必要です。
プラグイン・フレームワークで指定されている次の標準形式でplugin.xmlを定義します。
<oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<plugins pluginpoint="oracle.iam.request.plugins.StatusChangeEvent">
<plugin pluginclass="com.mycompany.RequestFailedChangeEvent" version="1.0" name="RequestFailedChangeEvent">
<metadata name="status">
<value>Request Failed</value>
</metadata>
</plugin>
</oimplugins>
このXML定義では、プラグインを実行する必要があるステージをメタデータ部分で指定しています。メタデータ値をRequest Failedとして指定し、これはリクエストが「リクエストに失敗しました」ステータスに移行したときにcom.mycompany.RequestFailedChangeEventプラグインが実行されることを意味します。
プラグインをOracle Identity Managerに登録します。Oracle Identity Managerにプラグインを登録する方法の詳細は、プラグインの登録に関する説明を参照してください。
RequestDataValidatorプラグインを使用して、送信後にリクエスト・データのカスタム検証を追加できます。このプラグインのプラグイン・ポイントは、public void validate(RequestData requesterData)メソッドを含むoracle.iam.request.plugins.RequestDataValidatorインタフェースです。
特定のプラグインに関連付けられているデータセット・バリデータおよび事前移入アダプタを定義できます。プラグインに関連付けられるリクエスト・データセットは、プラグイン登録時に定義できます。plugin.xmlファイルは、プラグインとデータセット・バリデータまたは事前移入アダプタの間の関連付けを定義するために使用します。<plugins>要素に付加されている<metadata>ノードは、データ・バリデータと事前移入アダプタの間の関連付けを定義するために使用します。
|
注意: データセットに対して指定されているDataSetValidatorプラグインは、plugin.xml自体でバリデータ・メタデータを指定するプラグイン拡張によってオーバーライドすることはできません。たとえば、デフォルト・バリデータに付属している事前定義済データセットModifyUserDatasetは、カスタム実装クラスによってオーバーライドされません。したがって、データセットのバリデータが優先され、それをオーバーライドするオプションは現時点ではありません。 |
例21-1は、プラグインをデータ・バリデータおよび事前移入アダプタに関連付けできる方法を示しています。
例21-1 プラグインとデータ・バリデータおよび事前移入アダプタの関連付け
<?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>
|
注意: リクエスト・データセット名は、単一のパイプ文字(|)で区切る必要があります。 |
次のシナリオを参考にしてください。
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フォームをそれに関連付けようとします。リクエスト・データセットは、プロセスで自動生成されます。データ・バリデータをこのリクエスト・データセットに対して再利用する場合、次の操作を実行します。
ADUserDataValidatorのplugin.xmlを編集します。
<metadata> <value>サブタグに、新しいリクエスト・データセットの名前をデリミタで区切って追加します。例:
<value>ADUserAPACDataSet|ADUserEMEADataSet</value>
データ・バリデータ・プラグインを再登録します。
権限のプロビジョニングおよび権限の変更リクエストの一部として指定される権限データは、データセット検証プラグインを作成し、プラグイン・メタデータ(plugin.xml)で次のように指定することで検証できます。
<metadata name="DataValidator">
<value>EBSForm.UD_EBS_RESP</value>
</metadata>
ここで、EBSFormは、アカウントがプロビジョニングされるアプリケーション・インスタンスに関連付けられているフォームの名前で、UD_EBS_RESPは権限に対応する子フォームの名前です。UD_EBS_RESPによって権限タイプが識別されます。
事前移入プラグインは、リクエスト・データセットの属性参照または属性に関連付けられます。これを使用すると、リクエストの作成時にカスタム・コードを実行して、属性値を事前移入できます。リクエスタは、必要に応じて事前移入する値を変更できます。
このプラグインのプラグイン・ポイントは、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が起動されます。 |
承認ポリシーは、リクエスト・レベルまたは操作レベルで構成できます。これらでは、リクエスト・レベルおよび操作レベルで使用可能なすべてのデータを使用してルールを構築できます。このルールを使用して、そのリクエストを自動承認するのか、SOAコンポジットを起動する必要があるのかを決定します。リクエスト・レベルおよび操作レベルの自動承認の有効化の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』の承認ポリシーの作成に関する項を参照してください。
承認ポリシーの更新後は、次の手順を実行して自己登録リクエスト用に自動承認を有効化します。
組織を自動的に割り当てるには、オーケストレーションで組織の値を設定する前処理ハンドラを追加します。承認関連のハンドラより前に実行されるように順序を設定する必要があります。CreateUserPreProcessHandlerのすぐ後に実行されるように設定してください。オーケストレーションおよびイベント・ハンドラの詳細は、第28章「イベント・ハンドラの開発」を参照してください。
デフォルトでは、自己登録リクエストに設定されているロールおよびユーザー・タイプは「パートタイムの従業員」です。この値を上書きする場合は、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にインポートします。
