| Oracle® Fusion Middleware Oracle Identity Managerのためのアプリケーションの開発とカスタマイズ 11gリリース2 (11.1.2.3.0) E61958-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managerのためのアプリケーションの開発とカスタマイズ 11gリリース2 (11.1.2.3.0) E61958-10 |
|
前 |
次 |
この章では、Oracle Identity Managerのワークフローの概念、機能およびアーキテクチャについて説明します。ワークフローのユースケース、最初のワークフローの設計、実装およびデプロイの手順を示します。また、この章ではプラグイン・ポイントを使用してリクエスト管理操作を拡張する方法と、証明およびアイデンティティ監査コンポジットをカスタマイズする方法を説明します。
この章の内容は次のとおりです。
この項では、主なワークフローの概念について、次の各項で説明します。
ユーザー・アクセスを管理し、ビジネス・プロセスを編成して、ユーザーが適切なアクセス権を取得できるようにすることが、アイデンティティ制御の主要機能となります。ユーザーのアクセスを変更するプロセスは、ポリシーをトリガーするHRのイベントを介してユーザーが開始するか、または管理者が開始することができます。アクセスの変更がどのように開始されるかに関係なく、組織には次の要件があります。
開始されるビジネス・プロセスは柔軟で、組織の変化するビジネス・ルールに適合できる必要があります。
ビジネス・プロセスでは、即時アクセス権を付与するか、アクセス権を付与する前に手動操作の手順を導入して承認を求めるかを決定できる必要があります。
ビジネス・プロセスは、リクエストされた内容、リクエスト者、リクエストの対象者およびコンテキストに関する職務の分離(SoD)チェックなど、検証を実行できる必要があります。
手動操作が必要な場合、ビジネス・プロセスには、ユーザーまたはユーザー・グループに割り当てる機能、および応答がタイミングよく受信されなかったときにエスカレーション、再割当てまたは期限切れの処理を行う機能が必要です。
手動操作の場合、ビジネス・プロセスには、承認者から、コメントや添付ファイルなどの情報を収集する機能が必要です。
アクセス権の自動付与が不可能な場合、または組織のルールによって手動によるアクセス権付与が必要な場合、ビジネス・プロセスでは、外部システム(チケット発行システムなど)と対話できる必要があります。
すべての決定およびアクションを監査し、報告可能な方法で利用可能にして、組織がプロセスのパフォーマンスを計測したり、監査者がコンプライアンス要件を満たすことができるようにする必要があります。
Oracle Identity Managerでは、組織がこれらの要件を満たすことができる、柔軟かつ強力なアクセス・リクエスト機能が提供されています。
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コンポジットを起動して、それにリクエスト、リクエスタおよびターゲット・ユーザーに関するいくつかの基本情報を渡します。この情報をリクエスト・ペイロードと呼びます。
ヒューマン・タスク
ヒューマン・タスクにより、ユーザーまたはグループが、エンドツーエンドのビジネス・プロセス・フローの一環として実行するタスクを記述するワークフローのモデリングが提供されます。
ワークフローは、Oracle Identity Managerで次の目的に使用されます。
承認のために、承認者にリクエストをルーティングする
履行のために、ITプロビジョナまたはヘルプ・デスクに手動のプロビジョニング・タスクをルーティングする
図13-1に、Oracle Identity Managerのワークフローの概要を示します。
図13-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へのコールバック・サービスを介して戻され、操作が再開されます。
表13-1に、承認プロセスとして使用可能なOracle Identity Managerにおける事前定義済SOAコンポジットを示します。
表13-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コンポジットは、アカウント/権限の詳細を要求しているリクエスタにタスクを割り当てます。 |
|
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.9と、SOA Design Time 11.1.1.9が使用可能です。
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にカタログ管理者としてログインします。
「リクエスト」で「カタログ」をクリックします。
「カタログ」ページで、アプリケーション・インスタンスを検索します。
アプリケーション・インスタンスを選択し、カタログ項目の詳細を編集します。
デフォルト属性の値を提供します。このチュートリアルでは、リスク・レベルと手動の履行に基づいてワークフロー・ルーティングが行われるため、「リスク・レベル」と「履行ロール」属性の値を指定する必要があります。ただし、その他の属性の値も指定することをお薦めします(特に「ユーザー定義タグ」)。
図13-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」を右クリックし、「編集」を選択します。
図13-5に示すように、「パートナ・リンク・チューザ」からパートナ・リンクとしてRequestWSPartnerLinkを、操作としてgetRequestDetailsを選択します。
「変数」セクションの「入力」および「出力」フィールドでプラス(+)アイコンをクリックして、入力変数および出力変数を作成します。入力変数にrequestDetails_InputVariable、出力変数にrequestDetails_OutputVariableという名前を付けます。「適用」をクリックし、「OK」をクリックします。
assignアクティビティをドラッグ・アンド・ドロップし、名前をAssignRequestInputに変更し、図13-6に示すようにInvokeRequestDetailsOperation invokeアクティビティの前に配置します。
「AssignRequestInput」を右クリックして、「編集」を選択して、図13-7に示すようにInvokeRequestDetailsOperationの入力をマップします。
図13-8に示すように、InvokeアクティビティをInvokeRequestDetailsOperationの後に追加します。そのアクティビティにInvokeCatalogOperationという名前を付けます。
InvokeCatalogOperationを編集し、図13-9に示すように構成します。
図13-10に示すように、AssignアクティビティをInvokeCatalogOperationの後に追加します。そのアクティビティにAssignCatalogInputという名前を付けます。
|
注意: 次の属性は、リクエストWebサービスのcatalog detailメソッドから、カスタム属性として返されます。
|
assignアクティビティを右クリックして編集し、図13-11に示すように入力をInvokeCatalogOperationにマップします。
ワークフロー選択ルールを定義するには、次の手順を実行します。
catalogDataという変数を「タイプ-要素CatalogData」として定義します。これを行うには、「変数」アイコンをクリックし、「変数」ダイアログ・ボックスの「作成」アイコンをクリックします。
この変数には、InvokeCatalogDetailsステップの出力として返されるカタログ詳細が格納されます。
workflowtypeという変数を「タイプ-要素StageOutput」として定義します。この変数には、呼び出されるワークフローのタイプが格納されます。
「SOAコンポジット」ビューに移動し、図13-12に示すようにビジネス・ルール・コンポーネントを追加します。
「ビジネス・ルールの作成」ダイアログ・ボックスで、ルール・ディクショナリの名前としてWorkflowSelectionを指定します。
入力としてcatalogDataを、出力としてworkflowstageを指定します。
BPELプロセスに切り替えます。
SOAコンポーネントを開き、ビジネス・ルール・コンポーネントを追加します。
そのルールを編集し、WorkflowSelectionという名前に変更します。
「ルール」ダイアログ・ボックスで、「ディクショナリ」タブをクリックし、手順4で定義したWorkflowSelectionディレクトリを選択します。
図13-13に示すように、catalogData変数をルールの入力にマップします。「ディクショナリ」タブで「入力ファクトの割当て」サブタブを選択して、プラス(+)アイコンをクリックします。
図13-13に示すように、catalogData変数をルールの入力にマップします。
図13-14に示すように、workflowtype変数をルールの出力にマップします。「ディクショナリ」タブで「出力ファクトの割当て」サブタブを選択します。
図13-14に示すように、workflowtype変数をルールの出力にマップします。
図13-15に示すように、WorkflowSelectionルールの前にAssignアクティビティを追加し、その名前をAssignRuleInputに変更します。
図13-16に示すように、InvokeCatalogOperationの出力をcatalogData変数にマップします。
「SOAコンポジット」ビューに切り替えます。
ビジネス・ルール・コンポーネントを右クリックし、「編集」を選択します。
「ルールの作成」をクリックします。
そのルールの名前をRule1からAuto Approvalに変更します。
ルールを編集し、図13-17に示すように、「プロパティ」ダイアログ・ボックスでstageTypeプロパティを指定します。
stageTypeプロパティを指定するには、次の手順を実行します。
「THEN」の下の「「挿入」」アクションをクリックします。
「新規アサート」を選択します。
「新規アサート」の隣に追加された「<ターゲット>」をクリックして、「ステージ」を選択します。
<プロパティの編集>をクリックします。図13-17に示すように、「プロパティ」ダイアログ・ボックスが表示されます。
同様に、図13-18に示すように、「マネージャ」、「シリアル」、および「パラレル」承認ルールを作成します。
BPELプロセスに切り替えます。
図13-19に示すように、WorkflowSelectionルールの後にswitchアクティビティを追加します。
そのSwitchアクティビティを選択し、図13-20に示すように2つのSwitch Caseステップを追加します。
図13-21に示すように、条件の名前をSerial Approval、Parallel Approval、Manager Approvalに変更します。
図13-22に示すように、デフォルト・ヒューマン・タスクをManager Switch Caseにドラッグします。
「SOAコンポジット」ビューに切り替えます。
図13-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」の順に選択します。
「式に挿入」をクリックします。図13-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を指定します。
図13-25に示すように、もう一方のステージを選択し、名前としてReview Teamを指定します。
2つのステージの後の鉛筆アイコンをクリックします。
「投票結果」ダイアログ・ボックスで、投票結果をAPPROVEに設定します。デフォルト結果をREJECTに設定します。これは、両方の承認者がタスクを拒否した場合、リクエストが、デフォルト結果に基づいて完了状態に移動するためです。
「添付ファイルとコメントの共有」オプションを選択します。
「投票結果」ダイアログ・ボックスで、「OK」をクリックします。
「最小のパーセントに達するとただちに投票結果がトリガーされます」オプションが選択されていることを確認します。
Managerステージで<参加者の編集>を選択し、「編集」をクリックします。
「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定します。「参加者のリストの作成で使用」リストから、 「ルールベース」を選択し、ルールを使用して参加者リストを作成します。
「ルールセットのリスト」フィールドにManagerと入力します。また、ラベルをManagerに編集します。
「参加者の追加」ダイアログ・ボックスで、「OK」をクリックします。「ParallelApprovalRules.rules」タブが表示されます。
図13-26に示すように、ルールを作成します。
|
注意: 「ルールの作成」ページで、「IF」句の「<パターンの挿入>」は、デフォルトでは表示されません。「<パターンの挿入>」を表示するには、「ルール1」ラベルの前の2つの下矢印をクリックして「ルール1」を展開し、図13-26に示すように「拡張モード」オプションを選択します。 |
同様に、「参加者タイプの追加」ダイアログ・ボックスに次の値を指定して、Review Teamステージを構成します。
タイプ: 単一。
ラベル: Review Team。
参加者のリストの作成で使用: ルールベース。
ルールセットのリスト: ReviewTeam。
「参加者が手動でタスクを申告」を選択します。
図13-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に設定します。
「通知」タブをクリックし、次に「詳細」をクリックします。
「通知をアクション可能にする」オプションを選択します。
「割当て」タブをクリックします。
順次ステージを追加し、図13-28に示すように、ステージの名前をManagerおよびReview Teamに変更します。
Managerステージを編集します。
「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定し、ルールを使用して参加者リストを作成します。
図13-29に示すように、参加者リスト・ルールを作成します。
同様に、Review Teamステージを構成します。
図13-30に示すように、参加者リスト・ルールを作成します。
デフォルト承認タスクを構成するには、次の手順を実行します。
「SOAコンポジット」ビューに切り替えます。
承認タスクを編集します。
「一般」タブをクリックします。
図13-31に示すように、タスクのタイトルを設定します。
「割当て」をクリックします。
Stage1.Participant1を選択し、「編集」をクリックします。
「参加者タイプの追加」ダイアログ・ボックスで、「参加者」タイプを「単一」に設定します。「参加者のリストの作成で使用」リストから、 「ルールベース」を選択し、ルールを使用して参加者リストを作成します。
「ラベル」および「ルールセット」にManagerと入力し、「OK」をクリックすると、ルールが開きます。
図13-32に示すように、参加者リスト・ルールを作成します。
ヒューマン・タスクとBPELのマッピングを構成する手順は次のとおりです。
シリアル承認ヒューマン・タスクを構成するには、次の手順を実行します。
「BPEL」プロセスに切り替えます。
次の条件を、Serial Approvalスイッチに追加します。
bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType') = 'Serial'
図13-33に示すように、Human TaskアクティビティをSOAコンポーネントからSerial Approvalスイッチにドラッグ・アンド・ドロップします。
ヒューマン・タスクを編集し、「ヒューマン・タスク」ダイアログ・ボックスで、シリアル承認ヒューマン・タスク定義を選択します。
「起案者」を「リクエスタ・ログイン」にマップし、図13-34に示すように、「BPEL変数」にタスク・パラメータをマップします。
「詳細」タブをクリックします。
図13-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にログインします。
左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。
アプリケーション・インスタンスのバルク・プロビジョニング操作のワークフロー・ルールを作成し、自動承認に設定します。ワークフロー・ルールの作成と管理の詳細は、『Oracle Identity Managerの管理』の承認ワークフロー・ルールの構成に関する項を参照してください。
アプリケーション・インスタンスのプロビジョニング操作のワークフロー・ルールを作成し、デプロイするコンポジットを起動することを指定します。
|
注意: 各タイプのリクエストに対して複数の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.3.0)
Oracle SOA 11g (11.1.1.9.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」を開きます。図13-36に示すように「データ・コントロール」からpanelStretchLayoutのトップ・ファセットに「タスク」をドラッグ・アンド・ドロップします。コンテキスト・メニューから、「ヒューマン・タスク」→「タスク・アクション」を選択します。ヒューマン・タスク・アクションが、トップ・ファセットに追加されます。
コンポーネント・パレットから、panelTabbedレイアウトをpanelStretchLayoutの中央ファセットに追加します。
コンポーネント・パレットから、2つのshowdetailItemコンポーネントをpanelTabbedレイアウトに追加します。プロパティ・インスペクタから、これらのコンポーネントのテキスト名としてRequest InformationとTask Informationを設定します。
「リクエスト情報」タブをクリックします。プロパティ・インスペクタで属性stretchChildren=firstを設定します。
「リクエスト情報」タブで、もう1つのpanelStretchLayoutを追加します。このpanelStretchLayoutに対して属性topHeight=autoを設定します。図13-37は、「リクエスト情報」および「タスク情報」タブを示しています。
「リクエスト情報」タブに移入します。これを行うには、次の手順を実行します。
「ナビゲータの表示オプション」に移動し、図13-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」を開きます。「タスク情報」タブで「タスク」をドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。図13-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にログインします。
「保留中の承認」に移動します。
対応するリクエストの「タスクの詳細」リンクをクリックします。カスタム・タスク詳細ページが表示されます。
リクエスト管理操作の特定の側面をカスタマイズして、柔軟性を向上させたり、追加機能のカスタマイズされたロジックを実装できます。これを行うには、リクエスト管理プラグインを使用できます。カスタマイズの実装に使用できるプラグイン・ポイントがあります。
ここでは、プラグイン・ポイントについて次の各項で説明します。
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は、カスタム実装クラスによってオーバーライドされません。したがって、データセットのバリデータが優先され、それをオーバーライドするオプションは現時点ではありません。 |
例13-1は、プラグインをデータ・バリデータおよび事前移入アダプタに関連付けできる方法を示しています。
例13-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 Identity Managerの管理』の承認ワークフローの管理に関する項を参照してください。
承認ワークフロー・ポリシーで自動承認のルールを構成した後、次の手順を実行して自己登録リクエスト用に自動承認を有効化します。
組織を自動的に割り当てるには、ホーム組織ポリシーを構成します。ホーム組織ポリシーの構成方法の詳細は、『Oracle Identity Managerの管理』のホーム組織ポリシーの管理に関する項を参照してください。
デフォルトでは、自己登録リクエストに設定されているロールおよびユーザー・タイプは「パートタイムの従業員」です。この値を上書きする場合は、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メトリックは、自己登録フローのパフォーマンスを監視するために存在します。
|
現在の割当てのスキップは承認者には有効なアクションではありません。承認者がこのアクションを選択すると、対応するリクエストは失敗します。したがって、次のいずれかの方法を実行して、このオプションを非表示にできます。
SOAコンポーザからタスク・アクションを変更します。「現在の割当てのスキップ」アクションに対して、すべてのチェックボックスの選択を解除し、保存します。
JDeveloperを使用してタスク・アクションを変更します。「現在の割当てのスキップ」アクションに対して、すべてのチェックボックスの選択を解除します。次に、コンポジットを保存し、再デプロイします。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のタスク操作のためのアクションの指定に関する項を参照してください。
証明の監視は、監視のレベルを拡張するため、または特定のタイトルに達したときに監視プロセスを停止するためにカスタマイズできます。証明コンポジットには、カスタマイズ可能な監視ロジックが含まれています。このロジックにより、次のいずれかまたはすべてに基づいて監督者のシーケンスを選択するためのOracle Identity Managerへの問合せをサポートします。
プライマリ・レビューア
証明の現在のフェーズ
Oracle Identity Managerで定義された管理階層
デフォルトでは、証明タスクが1人のレビューアに割り当てられるという、単一レベルの監視のみがサポートされます。
証明の監視用コンポジットで事前定義されているように、プライマリ・レビューアまたは監督者がサインオフすると、主要なレビュー・タスクはシーケンス内の次の監督者に自動的にルーティングされます。プライマリ・レビューアまたは監視者(最終監視者を除く)が主要なレビュー・タスクでサインオフすると、そのユーザーは、完了したタスクを問い合せて、そのタスクを受信箱で表示することはできなくなります。
証明の監視のカスタマイズに必要な手順は、次のとおりです。
コンポジットを作成します。これを行うには、次の手順を実行します。
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」をクリックします。
コンポジットをコンパイルして、コンポジットJARファイルをSOAにデプロイします。詳細は、SOAのドキュメントを参照してください。
Oracle Identity System Administrationにログインし、新しくデプロイしたコンポジットを「構成」ページで選択して、証明の定義を作成します。
アイデンティティ監査コンポジットをカスタマイズするには、次の手順を実行します。
コンポジットを作成します。これを行うには、次の手順を実行します。
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にログインし、アイデンティティ監査構成コンポジット参照から新規に作成したコンポジットを使用して新規アイデンティティ監査スキャン定義を作成します。
