1. Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ
  2. ワークフロー
  3. ワークフローの開発

13 ワークフローの開発

ワークフローについて理解し、リクエスト管理機能と証明およびアイデンティティ監査コンポジットをカスタマイズするためのワークフローを開発してデプロイします。

この章では、Oracle Identity Managerのワークフローの概念、機能およびアーキテクチャについて説明します。ワークフローのユースケース、最初のワークフローの設計、実装およびデプロイの手順を示します。また、この章ではプラグイン・ポイントを使用してリクエスト管理操作を拡張する方法と、証明およびアイデンティティ監査コンポジットをカスタマイズする方法を説明します。

この章のトピックは、次のとおりです:

13.1 ワークフローの概要

ワークフローは、承認リクエストをルーティングし、手動のプロビジョニング・タスクをITプロビジョナまたはヘルプ・デスク履行にルーティングするために使用します。

この項では、主なワークフローの概念について、次の各トピックで説明します。

13.1.1 ワークフローの概要

ユーザー・アクセスを管理し、ビジネス・プロセスを編成して、ユーザーが適切なアクセス権を取得できるようにすることが、アイデンティティ制御の主要機能となります。

ユーザーのアクセスを変更するプロセスは、ポリシーをトリガーするHRのイベントを介してユーザーが開始するか、または管理者が開始することができます。アクセスの変更がどのように開始されるかに関係なく、組織には次の要件があります。

  • 開始されるビジネス・プロセスは柔軟で、組織の変化するビジネス・ルールに適合できる必要があります。

  • ビジネス・プロセスでは、即時アクセス権を付与するか、アクセス権を付与する前に手動操作のステップを導入して承認を求めるかを決定できる必要があります。

  • ビジネス・プロセスは、リクエストされた内容、リクエスト者、リクエストの対象者およびコンテキストに関する職務の分離(SoD)チェックなど、検証を実行できる必要があります。

  • 手動操作が必要な場合、ビジネス・プロセスには、ユーザーまたはユーザー・グループに割り当てる機能、および応答がタイミングよく受信されなかったときにエスカレーション、再割当てまたは期限切れの処理を行う機能が必要です。

  • 手動操作の場合、ビジネス・プロセスには、承認者から、コメントや添付などの情報を収集する機能が必要です。

  • アクセス権の自動付与が不可能な場合、または組織のルールによって手動によるアクセス権付与が必要な場合、ビジネス・プロセスでは、外部システム(チケット発行システムなど)と対話できる必要があります。

  • すべての決定およびアクションを監査し、報告可能な方法で利用可能にして、組織がプロセスのパフォーマンスを計測したり、監査者がコンプライアンス要件を満たすことができるようにする必要があります。

Oracle Identity Managerでは、組織がこれらの要件を満たすことができる、柔軟かつ強力なアクセス・リクエスト機能が提供されています。

13.1.2 ワークフローの概念

ワークフローに関連する基本概念は、リクエスト、承認、承認ワークフロー・ポリシー、SOAコンポジット、パートナ・リンク、BPELプロセス、ITプロビジョナ、リクエストWebサービス、リクエスト・コールバック、プロビジョニング・コールバック、リクエスト・ペイロードおよびヒューマン・タスクです。

Oracle Identity Managerのワークフローの主要概念として、次のような用語があります。

  • リクエスト

    Oracle Identity Managerでは、リクエストは、あるアイデンティティまたはアカウントで操作を実行する必要がある場合に起動されるビジネス・プロセスを指します。これらの操作の例として、ユーザーの作成、アカウントのプロビジョニング、ユーザーへのロールの付与があります。リクエストには、すぐに履行可能な場合(直接的な操作)と、承認の形式で手動操作が必要な場合(リクエストベースの操作)があります。ユーザーが操作を実行しようとすると、Oracle Identity Managerは、その操作が直接的であるか、ログイン中のユーザーの認可ポリシーに基づくリクエストベースであるかを確認します。

  • 承認

    リクエストは1レベルの承認を通過します。これは、対応する操作のワークフロー・ポリシーで構成されます。

    バルク・リクエストは1レベルの承認を通過します。これは、対応するバルク操作のワークフロー・ポリシーで構成されます。承認後に、子リクエストが生成されます。これらの子リクエストは、単純リクエストと同じ承認プロセスに従います。

  • 承認ワークフロー・ポリシー

    承認ワークフロー・ポリシーは、リクエスト・エンジンがSOAコンポジット選択して呼び出せるようにする、管理者が構成したルールから構成されます。承認ワークフロー・ポリシーで定義されたルールを使用して、リクエスト・エンジンは、そのリクエストを自動承認するのか、SOAコンポジットを起動する必要があるのかを決定します。

  • SOAコンポジット

    SOAコンポジットは、単一のアプリケーション内に一括して設計されデプロイされた複数のサービス、サービス・コンポーネントおよび参照の集合です。このサービス、サービス・コンポーネントおよび参照間のワイヤリングによってメッセージ通信が可能となります。コンポジットにより、メッセージに記述された情報が処理されます。

  • パートナ・リンク

    パートナ・リンクを使用すると、BPELプロセス・サービス・コンポーネントと対話する外部サービスを定義できます。パートナ・リンクは、SOAコンポジット・エディタまたはOracle BPELデザイナのBPELプロセス・サービス・コンポーネント内にサービスまたは参照(JCAアダプタ経由など)として定義できます。

  • BPELプロセス

    BPELプロセスは、プロセスの編成と、同期または非同期プロセスの保存に使用されます。一連のビジネス・アクティビティとサービスをエンドツーエンドのプロセス・フローに統合するビジネス・プロセスを設計します。

  • ITプロビジョナ

    ITプロビジョナは、履行ユーザーまたはヘルプ・デスク・ユーザーとも呼ばれ、手動のプロビジョニング・リクエストの履行を担当する人です。

  • リクエストWebサービス

    リクエストWebサービスは、Oracle Identity Managerに付属するWebサービスです。顧客がリクエスト、ユーザー、ロール、組織、アカウント、権限、アプリケーション・インスタンスおよびカタログ情報を公開できるようにし、承認ワークフローによってデータ・ドリブンのルーティング決定が実行されるようにします。

  • リクエスト・コールバック

    リクエスト・コールバックは、承認結果(承認/拒否)の受信時にSOAコンポジットによって起動されるWebサービスです。リクエスト・エンジンは、承認の目的でSOAコンポジットを起動すると、このコンポジットがリクエスト・コールバックを起動して承認または拒否の決定を提供するまで、リクエストを一時停止します。この決定によって、リクエスト・エンジンは、リクエストの履行(承認された場合)、リクエストの拒否(拒否された場合)に進むことができます。

  • プロビジョニング・コールバック

    プロビジョニング・コールバックは、接続なしのプロビジョニングの一部として起動されるWebサービスです。ITプロビジョナまたは履行ユーザーが、接続なしのプロビジョニング・リクエストを履行し、タスクを完了とマークすると、SOAコンポジットはプロビジョニング・コールバックを起動して、プロビジョニング・ワークフローの完了を許可するプロビジョニング・ステータスを送信します。

  • リクエスト・ペイロード

    リクエスト・エンジンはSOAコンポジットを起動して、それにリクエスト、リクエスタおよびターゲット・ユーザーに関するいくつかの基本情報を渡します。この情報をリクエスト・ペイロードと呼びます。

  • ヒューマン・タスク

    ヒューマン・タスクにより、ユーザーまたはグループが、エンドツーエンドのビジネス・プロセス・フローの一環として実行するタスクを記述するワークフローのモデリングが提供されます。

13.1.3 ワークフローのアーキテクチャ

ワークフロー・アーキテクチャに関わるコンポーネントは、認可ポリシー、Business Process Execution Language (BPEL)プロセス、ヒューマン・タスク、およびリクエストの承認または却下です。

ワークフローは、Oracle Identity Managerで次の目的に使用されます。

  • 承認のために、承認者にリクエストをルーティングする

  • 履行のために、ITプロビジョナまたはヘルプ・デスクに手動のプロビジョニング・タスクをルーティングする

図13-1に、Oracle Identity Managerのワークフローの概要を示します。

図13-1 ワークフローのアーキテクチャ

図13-1の説明が続きます
「図13-1 ワークフローのアーキテクチャ」の説明

ヒューマン・タスクの完了に関わるステップについては、ヒューマン・タスク・プロセス・フローを参照してください。

13.1.4 ヒューマン・タスク・プロセス・フロー

ヒューマン・タスクの完了には、様々なユーザー開始アクション、リクエスト作成、承認ワークフロー・ポリシー、SOAコンポジット、人手の介入が必要かどうか、リクエストの承認または却下が含まれています。

ヒューマン・タスクを完了するまでには、図13-1に示すように、次のアクションが発生します。

  1. ユーザーは、結果としてリクエストになる操作を開始します。そのような操作の例を次に示します。

    • 自己登録

    • ユーザー・プロファイルの変更(ただし、ロックの、ロック解除およびパスワードの管理操作を除く)

    • ロール付与操作

    • アプリケーション・インスタンス操作(接続なしのプロビジョニングを含む)

    • 権限操作

    • バルク操作

  2. リクエストが作成されます。適切な検証の後に、リクエスト・エンジンは承認ワークフロー・ポリシーを評価し、起動するSOAコンポジットを選択します。

  3. 承認ワークフロー・ポリシーが構成されていない場合は、デフォルトのSOAコンポジットが承認に対して選択されます。

  4. SOAコンポジットには、Business Process Execution Language (BPEL)プロセスが含まれています。

  5. BPELプロセスは、Webサービスを起動して、リクエストに関する次のような詳細を取得します。

    ノート:

    このステップはオプションです。これは、BPELプロセスで様々なエンティティに関連する追加情報が必要な場合にのみ、必要です。

    • カタログからの項目の詳細

    • ターゲット・ユーザー情報

    • リクエスタ情報

  6. BPELプロセスは、優先度、承認者および通知などのプロパティを計算するために、追加のロジックを起動します。

  7. 承認および手動の履行中など、手動操作が必要な場合、プロセスはヒューマン・タスクを起動します。

    ヒューマン・タスクには、ユーザーまたはロールに対して承認タスクの割当て、期限切れ、エスカレーションを実行するためのロジックが含まれます。ヒューマン・タスクは、ユーザーおよびロールを静的または動的に割り当てることができます。静的割当ての場合、BPELプロセスで承認者を決定し、パラメータとしてヒューマン・タスクに渡すことができます。動的割当ての場合、Oracle Business Rules (OBR)で作成されたルールを使用して、承認者が動的に決定されます。

    通常、BPELプロセスには1つのヒューマン・タスクが含まれます。インスタンスによっては、BPELプロセスで複数のヒューマン・タスクのうちの1つを選択するデシジョン・ポイントが起動される場合があります。

  8. ヒューマン・タスクが完了すると、(承認の)承認または拒否のレスポンス、あるいは(手動履行の)完了のレスポンスが、Oracle Identity Managerへのコールバック・サービスを介して戻され、操作が再開されます。

13.2 事前定義済SOAコンポジット

事前定義済SOAコンポジットを承認プロセスとして使用できます。

表13-1に、承認プロセスとして使用可能なOracle Identity Managerにおける事前定義済SOAコンポジットを示します。

表13-1 事前定義済ワークフロー・コンポジット

ワークフロー・コンポジット 説明

DefaultRequestApproval

デフォルトのリクエスト・レベルの承認。デフォルトでは、リクエスト・レベルの承認の場合、SYSTEM ADMINISTRATORSロールに送信されます。

さらに、このコンポジットが証明ユースケースによって呼び出されます。タスクは次のいずれかの状態になります。

  • 受益者に割当て済。その後、タスクは受益者の決定に基づいて受益者のマネージャに割り当てることができます。

  • 証明リクエスタが受益者のマネージャの場合、自動承認済。

ノート: 証明ユースケースについては、Oracle Identity Governanceでのセルフ・サービス・タスクの実行のアイデンティティ証明の管理を参照してください。

DefaultOperationalApproval

デフォルトの操作レベルの承認。デフォルトでは、操作レベルの承認の場合、承認タスクはSYSTEM ADMINISTRATORSロールに割り当てられます。

さらに、コンポジットが証明ユースケースによって呼び出され、タスクが自動承認されます。

BeneficiaryManagerApproval

これは、受益者のマネージャの承認を必要とします。これは次のものと関連付けることができます。

  • 受益者を含むリクエスト・モデル。そのようなリクエスト・モデルの例は、アプリケーション・インスタンスのプロビジョニングおよびロールの割当てです。

  • ユーザーの作成およびユーザーの自己登録を除くすべてのユーザー・モデル。

リクエスト・レベルでは、リクエストに複数の受益者が存在する可能性があるため、このコンポジットは、承認の操作レベルで関連付けられる必要があります。

DefaultRoleApproval

このSOAコンポジットにより、承認のためにSYSTEM ADMINISTRATORSロールに割り当てられる単一の承認タスクが作成されます。

RequesterManagerApproval

このSOAコンポジットにより、承認のためにリクエスタのマネージャに割り当てられる単一の承認タスクが作成されます。

ノート: このコンポジットは、承認されていないリクエスト・モデル(ユーザーの自己登録など)に関連付けることはできません。

DefaultSODApproval

このSOAコンポジットにより、システム管理者に割り当てられる承認タスクが作成され、SoDチェックが開始されて、SoDの結果が使用可能になると、SoD管理者ロールに割り当てられる別の承認タスクが作成されます。これは、SoDチェックの必要に応じて、操作レベルでリソースをプロビジョニングまたは変更するリクエスト・モデルに関連付けられる必要があります。

DisconnectedProvisioning

このSOAコンポジットは、システム管理者にタスクを割り当て、接続なしのプロビジョニングを実行します。

ProvideInformation

このSOAコンポジットは、アカウント/権限の詳細を要求しているリクエスタにタスクを割り当てます。

CertificationProcess

これは、デフォルトの証明コンポジットです。このコンポジットは、証明タスクの証明者(ユーザー)への割当てに対応します。このコンポジットは、次の証明タスク・イベントの管理も行います。

  • 有効期限

  • プロキシ

  • エスカレーション

  • 再割当て

CertificationOverseerProcess

このコンポジットは、証明タスクを証明者(ユーザー)に割り当てます。さらに、コンポジットは、証明者のタスクの完了後の監督者へのタスクのルーティング処理も行います。Oracle SOA Business Rulesを使用してタスクのルーティングが処理されます。このコンポジットは、次の証明タスク・イベントに対応します。

  • 有効期限

  • プロキシ

  • ルーティング(監督者)

  • エスカレーション

  • 再割当て

13.3 新しいSOAコンポジットの作成

SOAコンポジットを作成してデプロイし、承認プロセスとして使用できます。

承認プロセスとして使用できる新規SOAコンポジットを作成するには、次のステップを実行します。

13.3.1 新しいSOAコンポジットの作成

特定の基準に準拠することで、承認プロセスとして使用できる新規SOAコンポジットを作成できます。

SOAコンポジットを承認プロセスとして使用するには、SOAコンポジットが特定の基準に準拠している必要があります。この項では、基準と、新規SOAコンポジットの作成方法について説明します。次の項目が含まれます。

13.3.1.1 SOAコンポジットを承認プロセスとして使用する基準

SOAコンポジットを承認プロセスとして使用するには、SOAコンポジットが特定の基準に準拠している必要があります。このような基準によって、リクエスト・サービスはコンポジットを適切にインスタンス化し、管理できます。基準は、次のとおりです。

  • 次の属性はBPELプロセスに必須です。

    • タイプが文字列のRequestID

    • タイプが文字列のRequestModel

    • タイプが文字列のRequestTarget

    • タイプが文字列のURL

    • XML要素のRequesterDetails

    • XML要素のBeneficiaryDetails

    • XML要素のObjectDetails

    • XML要素のOtherDetails

    RequestID、RequestModel、RequestTargetおよびURL属性には、常に、すべてのタイプのリクエストの有効な値が設定されます。

    RequesterDetailsはXML要素です。この要素には、認証を必要とするすべてのリクエストの有効な値が入力されます。タイプが自己登録ユーザーのリクエストは、リクエスタが匿名ユーザーのため、リクエスタの詳細が空です。

    BeneficiaryDetailsはXML要素です。この要素には、「リソースのプロビジョニング」、「ロールの割当て」など、受益者があるすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1人の受益者に関連している場合にのみ入力されます。リクエストが複数の受益者に関連している場合、BeneficiaryDetailsは空になります。BeneficiaryDetails要素には、常に、受益者がある単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1人の受益者にのみ関連付けられているためです。

    ObjectDetailsはXML要素です。この要素には、リソース・エンティティに関連付けられているすべてのリクエストの有効な値が入力されます。この要素には、リクエストが1つのリソースに関連している場合にのみ入力されます。リクエストが複数のリソースに関連している場合、ObjectDetailsは空になります。ObjectDetails要素には、常に、リソースに関連付けられている単純リクエストおよび子リクエストの有効な値が設定されます。このため、承認の操作レベルで承認プロセスとして使用されるSOAコンポジットでこのXML要素を使用することをお薦めします。これは、承認の操作レベルでは、リクエストが1つのリソースにのみ関連付けられているためです。

  • BPELプロセスに必須のすべての属性は、RequestDetails.xsdおよびApprovalProcess.xsdから参照されます。これらのファイルは、変更または削除できないテンプレートSOAコンポジットにあります。

13.3.1.2 ヘルパー・ユーティリティを使用したカスタムSOAコンポジットの作成

Oracle Identity Managerでは、カスタムSOAコンポジットを作成するヘルパー・ユーティリティが提供されます。このユーティリティでは、必要な基準のすべてに準拠したテンプレートSOAプロジェクトが作成されます。このユーティリティは、OIM_HOME/workflows/new-workflowディレクトリに配置されています。

ノート:

  • JAVA_HOME環境変数を設定してから、このユーティリティを実行する必要があります。

  • このユーティリティには、Apache Antバージョン1.9.8以上が必要です。

  • JDeveloperは、デフォルトではOracle Identity Managerで使用できません。SOAのサポートのためには、SOA推奨のJDeveloperをインストールします。

ヘルパー・ユーティリティを実行してカスタムSOAコンポジットを作成するには:

  1. 次のコマンドを実行します。
    cd OIM_HOME/workflows/new-workflow
ant -f new_project.xml
  2. 次のプロンプトが表示されたら、JDeveloperアプリケーション名を入力します。

    Please enter application name

  3. 次のプロンプトが表示されたら、JDeveloperプロジェクト名を入力します。

    Please enter project name

  4. 次のプロンプトが表示されたら、コンポジットの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コンポジットで構成する必要があります。

    テンプレートSOAコンポジットのヒューマン・タスクは、SYSTEM ADMINISTRATORSロールに割り当てられるよう構成されています。

13.3.2 SOAコンポジットのOracle SOAサーバーへのデプロイ

新規SOAコンポジットの作成後、それを承認プロセスとして使用するにはデプロイする必要があります。

BPELへのワークフロー・コンポジットのデプロイの詳細は、Oracle SOA Suite開発者ガイドのSOAコンポジット・アプリケーションのデプロイを参照してください。

ノート:

コンポジットは新規バージョンで再デプロイされる必要があります。コンポジットがSOAで同じバージョンで再デプロイされる場合、コンポジットによって開始されたOracle Identity Managerの保留中のすべての承認が失効となり、ユーザーのTaskListから削除されます。既存のSOAコンポジットのデプロイの詳細は、Oracle SOA Suite開発者ガイドのOracle JDeveloperで既存のSOAアーカイブをデプロイする方法を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlを使用したカスタムSOAコンポジットのデプロイの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAコンポジット・アプリケーションをデプロイするには:を参照してください。

13.3.3 SSLモードでのOracle Identity Governanceとの通信のための前提条件の設定

SSL通信の前提条件は、TRUSTSTORE_LOCATION環境変数を設定し、t3sプロトコルを使用することです。

Oracle Identity Managerとの通信でSSLモードを使用している場合は、次を実行する必要があります。

ノート:

非SSL接続の場合は、この項をスキップしてください。

  1. TRUSTSTORE_LOCATION環境変数を設定します(TRUSTSTORE_LOCATIONは信頼できるキー・ストア・ファイルの場所です)。
  2. t3プロトコルではなくt3sプロトコルを使用します。たとえば、Oracle Identity ManagerのURLは次のようになります。

    t3s://HOST_NAME:PORT

13.4 ワークフローの開発: Vision社のリクエストのチュートリアル

Vision社のリクエストのチュートリアルでは、アプリケーションを作成し、アプリケーションのワークフローを開発し、アプリケーション用に承認および履行を構成します。

この項では、最初のワークフローを設計する方法について説明します。次の項目が含まれます。

13.4.1 チュートリアルの概要

このチュートリアルのユースケースの最終結果は、アプリケーション・インスタンス、BPELプロセスおよび複数のヒューマン・タスクで構成される承認用のSOAコンポジット、および事前定義済の接続なしSOAコンポジットへの変更です。

このチュートリアルは、次のユースケースに基づいています。

  • Vision Corp社は、FinApp(メインフレームベースのアプリケーション)を使用しています。このアプリケーションは、リモートから起動可能なAPIを持ちません。したがって、アカウントはヘルプ・デスクによって手動で管理されます。

  • Vision Corp社の従業員は、アクセス・リクエスト・カタログを使用して、アプリケーションでアカウントおよび権限をリクエストします。

  • 承認は、リクエストされているアクセスのリスク・レベルに基づいて行われます。リスク・レベルが「低」の場合、受益者のマネージャによる承認のみが必要です。リスク・レベルが「中」の場合、受益者のマネージャまたは監査レビュー・チームのメンバーのいずれかによる承認が必要です。リスク・レベルが「高」の場合、受益者のマネージャおよび監査レビュー・チームのメンバーによる承認が必要です。

このチュートリアルでは、アプリケーションとワークフローの作成方法、およびアプリケーションでの承認および履行の構成方法について説明します。

このチュートリアルでは、次の結果が得られます。

  • アプリケーション・インスタンス

  • 次で構成される、承認用のSOAコンポジット

    • BPELプロセス

    • 複数のヒューマン・タスク

13.4.2 前提

チュートリアルを開始するには、SOAデザインタイムとともにOracle SOAスイートおよびJDeveloperをインストールする、数個のロールと1つの組織をVisionという名前で作成するなど、特定の前提条件を満たす必要があります。

このチュートリアルでは、次を前提としています。

  • Oracle SOA Suiteは、SOAインフラストラクチャが構成されているホストにインストールされています。

  • JDeveloper 12.2.1.3は、SOAコンポジット・エディタ12.2.1.3およびBPELデザイナ12.2.1.3.0で使用できます。

  • SOA Jdeveloper拡張の必須パッチがある場合はそれが適用されています。必須パッチの詳細は、Oracle Fusion Middlewareリリース・ノートの「Oracle Identity Managerのインストールに必要な必須パッチ」を参照してください。

  • BPELアクティビティやパートナ・リンクなどの基本的なBPEL構成要素と、基本的なXPath関数について理解しているユーザーを対象にしています。

  • SOAコンポジット・エディタとOracle BPELデザイナ(BPELプロセスを設計およびデプロイするための環境)を熟知している必要があります。ただし、SOAコンポジットの詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のSOAコンポジット・アプリケーションの開発のスタート・ガイドを参照してください。

  • 2つのロール(監査レビュー・チームおよびアセット管理チーム)が作成され、メンバーが割り当てられています。

  • Visionという名前の組織が作成されています。

13.4.3 アプリケーション・インスタンスの作成

このチュートリアルの前提条件として、アプリケーション・インスタンスを作成し、アプリケーション・インスタンス属性を定義し、フォームを作成し、アプリケーション・インスタンスを1つ以上の組織に公開し、アプリケーション・インスタンスに権限をリンクし、権限があるアプリケーション・インスタンスをカタログに公開する必要があります。

この項では、アプリケーション・インスタンスを作成および公開し、それに権限をリンクする方法について説明します。次の項目が含まれます。

13.4.3.1 FinAppアプリケーション・インスタンスの作成

FinAppアプリケーション・インスタンスを作成するには:

  1. Oracle Identity System Administrationにログインします。
  2. 「サンドボックス」をクリックして、サンドボックス管理にアクセスし、サンドボックスを作成し、それをアクティブにします。サンドボックスの詳細、サンドボックスの作成、アクティブ化および公開方法については、サンドボックスの管理を参照してください。
  3. 「構成」で、「アプリケーション・インスタンス」をクリックします。ツールバーで「作成」をクリックして、「アプリケーション・インスタンスの作成」ページを開きます。
  4. 「名前」および「表示名」に、FinAppと入力します。
  5. 「切断」オプションを選択して、接続なしアプリケーション・インスタンスを指定します。
  6. 「保存」をクリックし、「OK」をクリックして、FinAppアプリケーション・インスタンスの作成を確認します。
13.4.3.2 アプリケーション・インスタンス属性の定義とフォームの作成

アプリケーション・インスタンスの属性を定義し、フォームを作成するには:

  1. 「構成」で、「フォーム・デザイナ」をクリックします。

  2. FinAppフォームを検索して選択します。このフォームは、接続なしアプリケーション・インスタンスを保存すると自動的に作成されます。

    ノート:

    フォームを作成して編集するには、アクティブなサンドボックスで作業している必要があります。

  3. 「フィールド」タブをクリックし、ツールバーで「編集」アイコンをクリックします。

    デフォルトでは、次のフィールドが作成され、使用可能になります。

    フィールド 説明

    ITリソース

    アカウントが作成されるITリソース・インスタンス

    アカウント・ログイン

    アプリケーションのログイン

    パスワード

    アプリケーションへのログイン中に使用されるパスワード

    アカウントID

    アカウントの作成時に、アプリケーションによって生成される一意の識別子

    サービス・アカウント

    アクセス・リクエスト中のみに使用されるフラグ

    ノート:

    「アカウントID」および「ITリソース」などの属性は、通常、アクセス・リクエスト・ユーザー・インタフェースには表示されません。ユースケースによっては、これらの属性と関係がない場合があります(たとえば、携帯電話リクエスト)。これらの属性を非表示にする場合は、フォームをカスタマイズできます。フォームをカスタマイズする方法の詳細は、Oracle Identity Governanceの管理のカスタム属性の構成を参照してください。

  4. 属性を追加します。この例では、次の属性を追加します。

    Account Description: データ型はTextです。

    ノート:

    カスタム属性を作成する方法の詳細は、Oracle Identity Governanceの管理のカスタム属性の構成を参照してください

  5. 属性を追加した後、「フィールド」タブの構成が次の表と同等であることを確認します。

    表示ラベル 名前 タイプ

    アカウントの説明

    AccountDescription

    テキスト

    アカウントID

    UD_FINAPP_ACCOUNTID

    テキスト

    ITResource

    UD_FINAPP_IT

    数値

    アカウント・ログイン

    UD_FINAPP_LOGIN

    テキスト

    パスワード

    UD_FINAPP_PASSWORD

    テキスト

    サービス・アカウント

    serviceaccount

    チェック・ボックス

  6. ユーザーが権限をリクエストするのを許可するには、子オブジェクトを追加し、権限としてタグ付けされる属性を追加する必要があります。そのように行うには:

    1. 「子オブジェクト」タブをクリックし、ツールバーで「追加」をクリックします。

    2. 子オブジェクト名を入力し、「OK」をクリックして子オブジェクトを作成します。

    3. 作成した子オブジェクトをクリックします。

    4. 「アクション」、「作成」の順に選択し、新規属性を作成します。ポップアップ・ウィンドウから「参照」を選択し、「OK」をクリックします。次のフィールドに値を入力します。

      名前: プロファイル名

      表示名: プロファイル名

    5. 「バルクで使用」を選択して、複数のユーザーのアクセスをリクエストするときに、リクエスタによる値の指定を許可します。

    6. 「参照タイプ」下の新規参照タイプの作成をクリックします。

    7. 次に示すように、新しいLookupを作成し、値を指定します。

      コード: Lookup.FinApp.Profile

      意味: Lookup.FinApp.Profile

      説明: Lookup.FinApp.Profile

    8. 次の表に示す値を使用して、3つの参照コードを作成します。

      意味 コード

      FinAppユーザー

      FinAppUser

      FinApp管理者

      FinAppAdministrator

      FinAppオペレータ

      FinAppOperator

      ノート:

      スケジュール済タスクと参照APIを使用して、参照定義を移入することもできます。

    9. 「検索可能」、「権限」および「「検索可能」ピックリスト」オプションを選択します。

  7. 「保存して閉じる」をクリックします。

  8. 「親オブジェクトに戻る」をクリックします。

  9. 「ビューの再生成」をクリックして、新しい属性でUIフォームを再作成します。

  10. すべてのタブを閉じます。

  11. サンドボックスを公開します。

13.4.3.3 1つ以上の組織へのアプリケーション・インスタンスの公開

1つ以上の組織にアプリケーション・インスタンスを公開するには:

  1. FinAppアプリケーション・インスタンスの詳細ページを開き、「組織」タブをクリックします。
  2. 「割当て」をクリックします。「組織の選択」ダイアログ・ボックスで、アプリケーション・インスタンスを公開する組織を1つ以上選択します。
  3. アプリケーション・インスタンスをその組織と子組織に公開する場合は、「階層」オプションを選択します。
  4. 「OK」をクリックします。
13.4.3.4 アプリケーション・インスタンスへの権限のリンク

権限をアプリケーション・インスタンスにリンクするには:

  1. 「システム管理」で「スケジューラ」をクリックします。
  2. 権限リスト・スケジュール済ジョブを検索し、「即時実行」をクリックします。
  3. 「構成」で「アプリケーション・インスタンス」をクリックし、FinAppアプリケーション・インスタンスに移動します。
  4. 図13-2に示すように、「権限」タブをクリックして、権限が表示されることを確認します。

    図13-2 権限のリスト

    図13-2の説明が続きます
    「図13-2 権限のリスト」の説明
  5. 図13-3に示すように、権限を選択し、それがアプリケーション・インスタンスと同じ組織に公開されていることを確認します。

    図13-3 組織への権限の可用性

    図13-3の説明が続きます
    「図13-3 組織への権限の可用性」の説明
  6. 1つ以上の権限を編集し、ビジネス・フレンドリな説明を入力します。必要に応じて、表示名も同様に変更します。
13.4.3.5 カタログへのアプリケーション・インスタンスおよび権限の公開

カタログにアプリケーション・インスタンスとその権限を公開するには:

  1. 「システム管理」で「スケジューラ」をクリックします。
  2. カタログの同期化スケジュール済ジョブを検索し、「即時実行」をクリックします。

13.4.4 カタログでのFinAppの構成

カタログでアプリケーション・インスタンスとその権限を構成するようにカタログ項目詳細を編集します。

カタログでアプリケーション・インスタンスとその権限を構成するには:

  1. Oracle Identity Self Serviceにカタログ管理者としてログインします。
  2. 「リクエスト」で「カタログ」をクリックします。
  3. 「カタログ」ページで、アプリケーション・インスタンスを検索します。
  4. アプリケーション・インスタンスを選択し、カタログ項目の詳細を編集します。
  5. デフォルト属性の値を提供します。このチュートリアルでは、リスク・レベルと手動の履行に基づいてワークフロー・ルーティングが行われるため、「リスク・レベル」と「履行ロール」属性の値を指定する必要があります。ただし、その他の属性の値も指定することをお薦めします(特に「ユーザー定義タグ」)。

    図13-4は、カタログ項目の属性を示しています。

    図13-4 カタログ項目の属性

    図13-4の説明が続きます
    「図13-4 カタログ項目の属性」の説明

13.4.5 承認用SOAコンポジットの作成と構成

カタログでアプリケーション・インスタンスとその権限を構成した後、承認用SOAコンポジットを登録および設定できます。具体的には、承認ワークフローを作成し、リクエストとカタログのデータをBPELプロセスで使用できるようにし、ワークフローの選択を構成し、ヒューマン・タスクを構成し、ヒューマン・タスクおよびBPELマッピングを構成し、SOAコンポジットをデプロイし、ワークフロー・ルールを作成します。

この項の内容は次のとおりです。

13.4.5.1 承認ワークフローの作成

新しい承認ワークフローを作成するには:

  1. DOMAIN_HOME/bin/ディレクトリでsetDomainEnv.shスクリプトを実行して、JAVA_HOME、ANT_HOMEおよびPATH環境変数を設定します。
  2. OIM_ORACLE_HOME/server/workflows/new_workflowに移動します。
  3. 次のコマンドを実行します。
    ant -f new_project.xml
  4. アプリケーション名としてAddAccessApprovalApplicationを指定します。
  5. プロジェクト名としてAddAccessApprovalを指定します。
  6. サービス名としてAddAccessを指定します。
  7. ユーティリティによってコンポジットを含む新しいJDeveloperワークスペースが生成されるまで待ちます。ワークスペースは、/server/workflows/new-workflow/process-template内に生成されます。
  8. そのディレクトリをJDeveloperからアクセス可能な場所にコピーします。
13.4.5.2 BPELプロセスに対するリクエストおよびカタログ・データの使用可能化

BPELプロセスに対してリクエストおよびカタログ・データを使用可能にするには:

  1. BPELプロセスの「設計」ビューに切り替えます。
  2. コンポーネント・パレットからinvokeアクティビティをドラッグして、AssignRequestWSURLアクティビティの後にドロップします。名前をInvokeRequestDetailsOperationに変更します。
  3. 「InvokeRequestDetailsOperation」を右クリックし、「編集」を選択します。
  4. 図13-5に示すように、「パートナ・リンク・チューザ」からパートナ・リンクとしてRequestWSPartnerLinkを、操作としてgetRequestDetailsを選択します。

    図13-5 パートナ・リンクと操作

    図13-5の説明が続きます
    「図13-5 パートナ・リンクと操作」の説明
  5. 「変数」セクションの「入力」および「出力」フィールドでプラス(+)アイコンをクリックして、入力変数および出力変数を作成します。入力変数にrequestDetails_InputVariable、出力変数にrequestDetails_OutputVariableという名前を付けます。「適用」をクリックし、「OK」をクリックします。
  6. assignアクティビティをドラッグ・アンド・ドロップし、名前をAssignRequestInputに変更し、図13-6に示すようにInvokeRequestDetailsOperation invokeアクティビティの前に配置します。

    図13-6 AssignRequestInput

    図13-6の説明が続きます
    「図13-6 AssignRequestInput」の説明
  7. 「AssignRequestInput」を右クリックして、「編集」を選択して、図13-7に示すようにInvokeRequestDetailsOperationの入力をマップします。

    図13-7 入力マッピング

    図13-7の説明が続きます
    「図13-7 入力マッピング」の説明
  8. 図13-8に示すように、InvokeアクティビティをInvokeRequestDetailsOperationの後に追加します。そのアクティビティにInvokeCatalogOperationという名前を付けます。

    図13-8 InvokeCatalogOperation

    図13-8の説明が続きます
    「図13-8 InvokeCatalogOperation」の説明
  9. InvokeCatalogOperationを編集し、図13-9に示すように構成します。

    図13-9 InvokeCatalogOperationの構成

    図13-9の説明が続きます
    「図13-9 InvokeCatalogOperationの構成」の説明
  10. 図13-10に示すように、AssignアクティビティをInvokeCatalogOperationの後に追加します。そのアクティビティにAssignCatalogInputという名前を付けます。

    図13-10 AssignCatalogInput

    図13-10の説明が続きます
    「図13-10 AssignCatalogInput」の説明

    ノート:

    次の属性は、リクエストWebサービスのcatalog detailメソッドから、カスタム属性として返されます。

    • APPROVER_USER_FIRSTNAME

    • APPROVER_USER_LASTNAME

    • APPROVER_USER_DISPLAYNAME

    • APPROVER_USER_EMAIL

    • CERTIFIER_USER_FIRSTNAME

    • CERTIFIER_USER_LASTNAME

    • CERTIFIER_USER_DISPLAYNAME

    • CERTIFIER_USER_EMAIL

    • FULFILLMENT_USER_FIRSTNAME

    • FULFILLMENT_USER_LASTNAME

    • FULFILLMENT_USER_DISPLAYNAME

    • FULFILLMENT_USER_EMAIL

  11. assignアクティビティを右クリックして編集し、図13-11に示すように入力をInvokeCatalogOperationにマップします。

    図13-11 InvokeCatalogOperationの入力マッピング

    図13-11の説明が続きます
    「図13-11 InvokeCatalogOperationの入力マッピング」の説明
13.4.5.3 ワークフローの選択の構成

ワークフロー選択ルールを定義するには:

  1. catalogDataという変数を定義します。そのように行うには:

    1. 「変数」アイコンをクリックし、「変数」ダイアログ・ボックスの「作成」アイコンをクリックします。
    2. 「要素」として「タイプ」を選択し、フィールドの横にある「検索」アイコンをクリックします。
    3. ダイアログ・ボックスで、「プロジェクトのスキーマ・ファイル」、「CatalogData.xsd」の順に展開し、CatalogData要素を選択します。この変数には、InvokeCatalogDetailsステップの出力として返されるカタログ詳細が格納されます。

  2. workflowtypeという変数を定義します。そのように行うには:

    1. 「要素」としてタイプを選択し、フィールドの横にある「検索」アイコンをクリックします。
    2. ダイアログ・ボックスで、「プロジェクトのスキーマ・ファイル」、「BusinessRule.xsd」の順に展開し、StageOutput要素を選択します。この変数には、呼び出されるワークフローのタイプが格納されます。

  3. 「SOAコンポジット」ビューに移動し、図13-12に示すようにビジネス・ルール・コンポーネントを追加します。

    図13-12 ビジネス・ルール・コンポーネントの追加

    図13-12の説明が続きます
    「図13-12 ビジネス・ルール・コンポーネントの追加」の説明

  4. 「ビジネス・ルールの作成」ダイアログ・ボックスで、ルール・ディクショナリの名前としてWorkflowSelectionを指定します。

  5. プロジェクトのスキーマ・ファイル内のCatalogData.xsdから入力をCatalogDataとして指定し、プロジェクトのスキーマ・ファイル内のBusinessRule.xsdからStageOutputとして出力します。

  6. BPELプロセスに切り替えます。

  7. 「SOAコンポーネント」を展開し、InvokeCatalogOperationとApprovalTask_1コンポーネント間でビジネス・ルール・コンポーネントを追加します。

  8. そのルールを編集し、WorkflowSelectionという名前に変更します。

  9. 「ルール」ダイアログ・ボックスで、「ディクショナリ」タブをクリックし、ステップ4で定義したWorkflowSelectionディレクトリを選択します。

  10. 「ディクショナリ」タブで「入力ファクトの割当て」サブタブをクリックし、プラス(+)アイコンをクリックします。

  11. 図13-13に示すように、catalogData変数をルールの入力にマップします。

    図13-13 catalogData変数の入力マッピング

    図13-13の説明が続きます
    「図13-13 catalogData変数の入力マッピング」の説明

  12. 「ディクショナリ」タブで「出力ファクトの割当て」サブタブをクリックします。

  13. 図13-14に示すように、workflowtype変数をルールの出力にマップします。

    図13-14 workflowtype変数の出力マッピング

    図13-14の説明が続きます
    「図13-14 workflowtype変数の出力マッピング」の説明

  14. 図13-15に示すように、WorkflowSelectionルールの前にAssignアクティビティを追加し、その名前をAssignRuleInputに変更します。

    図13-15 AssignRuleInput

    図13-15の説明が続きます
    「図13-15 AssignRuleInput」の説明

  15. 図13-16に示すように、InvokeCatalogOperationの出力をcatalogData変数にマップします。

    図13-16 catalogData変数の出力マッピング

    図13-16の説明が続きます
    「図13-16 catalogData変数の出力マッピング」の説明

  16. 「SOAコンポジット」ビューに切り替えます。

  17. ビジネス・ルール・コンポーネントを右クリックし、「編集」を選択します。

  18. 「ルールの作成」をクリックします。

  19. そのルールの名前をRule1からAuto Approvalに変更します。

  20. 図13-17に示すように、「低」、「中」または「高」リスクの値が設定されていない項目が自動承認としてステージングされるように、ルールを編集します。これを行うには:

    1. IFの下にある「<テストの挿入>」アクションをクリックして、簡易テストを選択します。次のように定義します: 

      CatalogDataType.itemRisk != 3

    2. 最初のテストを選択し、「後ろに挿入」オプションを使用して、別の簡易テストを追加します:

      CatalogDataType.itemRisk != 5

    3. 前のテストを選択し、「後ろに挿入」オプションを再度使用して、最後の簡易テストを追加します:

      CatalogDataType.itemRisk != 7

      これらの追加の結果、IF条件は次のようになります:

      CatalogDataType.itemRisk != 3 and
    CatalogDataType.itemRisk != 5 and
    CatalogDataType.itemRisk != 7

    4. THENの下にある「<insert_action>」アクションをクリックして、新規アサートを選択します。

    5. 「新規アサート」の隣に追加された「<ターゲット>」をクリックして、「ステージ」を選択します。

    6. 図13-17に示すように、「<プロパティの編集>」をクリックし、「プロパティ」ダイアログ・ボックスに値Autoを入力します。

    図13-17 stageTypeプロパティ

    図13-17の説明が続きます
    「図13-17 stageTypeプロパティ」の説明

  21. 同様に、図13-18に示すように、「マネージャ」、「シリアル」、および「パラレル」承認ルールを作成します。

    図13-18 承認ルール

    図13-18の説明が続きます
    「図13-18 承認ルール」の説明

  22. BPELプロセスに切り替えます。

  23. 図13-19に示すように、WorkflowSelectionルールの後にswitchアクティビティを追加します。

    図13-19 switchアクティビティ

    図13-19の説明が続きます
    「図13-19 switchアクティビティ」の説明

  24. そのSwitchアクティビティを選択し、図13-20に示すように2つのSwitch Caseステップを追加します。

    図13-20 Switch Caseステップ

    図13-20の説明が続きます
    「図13-20 Switch Caseステップ」の説明

  25. 図13-21に示すように、条件の名前をSerial Approval、Parallel Approval、Manager Approvalに変更します。

    図13-21 名前変更済条件

    図13-21の説明が続きます
    「図13-21 名前変更済条件」の説明

  26. 図13-22に示すように、デフォルト・ヒューマン・タスクをManager Switch Caseにドラッグします。

    図13-22 デフォルト・ヒューマン・タスクのドラッグ

    図13-22の説明が続きます
    「図13-22 デフォルト・ヒューマン・タスクのドラッグ」の説明

  27. 「SOAコンポジット」ビューに切り替えます。

  28. 図13-23に示すように、SerialApprovalとParallelApprovalの2つのヒューマン・タスクを追加します。

    図13-23 ヒューマン・タスクの追加

    図13-23の説明が続きます
    「図13-23 ヒューマン・タスクの追加」の説明

  29. BPELプロセスに切り替えます。

  30. Manager Approval Switch Caseを編集し、次の式を追加します。

    bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType')='Manager'

    最初に、新しく追加したタスクを構成し、次にそれらをBPELプロセスに書き込む必要があります。

    ノート:

    式の追加には式ビルダーの使用をお薦めします。

13.4.5.4 ヒューマン・タスクの構成

この項では、ヒューマン・タスクを構成する方法について説明します。この章の内容は次のとおりです。

13.4.5.4.1 パラレル・ヒューマン・タスクの構成

パラレル・ヒューマン・タスクを構成するには:

  1. 「SOAコンポジット」ビューに切り替えます。パラレル承認タスクを編集します。

  2. 「データ」タブをクリックし、パラレル承認タスクのプロパティにリストされている属性を追加します。

  3. 「データ」タブでタスク・パラメータを検証し、「一般」タブをクリックします。

  4. 「タスクのタイトル」を<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approvalに設定します。そのように行うには:

    1. タスク・タイトルの横の「編集」をクリックし、「task:payload」、「ns2:BeneficiaryDetails」、「ns2:DisplayName」の順に選択します。

    2. 「式に挿入」をクリックします。図13-24に示すようにタスク・タイトルが表示されます。

      図13-24 タスク・タイトル

      図13-24の説明が続きます
      「図13-24 タスク・タイトル」の説明
      <%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%>

      次のようにこれを編集して意味のあるタイトルを構成できます。

      <%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approval.

  5. 「タスク所有者」を「グループ」と「SYSTEM ADMINISTRATORS」に設定し、「名前別」オプションを「承認」とともに使用して「カテゴリ」を設定します。

  6. 「通知」タブをクリックし、次に「詳細」をクリックします。

  7. 「通知をアクション可能にする」オプションを選択します。「ワークリスト/ワークスペースURLを通知に表示」オプションの選択を解除します。

  8. 「割当て」タブをクリックします。

  9. パラレル・ステージを追加します。これを行うには、単一参加者をワークフロー・エディタからStage1ボックスにドラッグ・アンド・ドロップします。最初の単一参加者の右側に2番目の単一参加者を追加するプロセスを繰り返します。

  10. 「投票結果」の詳細を構成します。これを行うには、2つのステージのすぐ下にある鉛筆アイコンを選択します。「プロパティ」ボックスで、次のようにします:

    1. 「投票結果」を「承認」に設定し、「結果タイプ」は「パーセンテージ別」、「値」は50のままにします。

    2. 「デフォルトの結果」を「拒否」に設定します。

    3. 「添付とコメントの共有」および「最小のパーセンテージに達するとただちに投票結果がトリガーされます」オプションを選択します。

  11. Managerステージを編集します。これを行うには、Stage1.Participant1ステージを選択します。「プロパティ」ボックスで、次のようにします:

    1. 図13-25に示すように、「ラベル」をManagerに変更します。

      図13-25 ManagerおよびReview Teamステージ

      図13-25の説明が続きます
      「図13-25 ManagerおよびReview Teamステージ」の説明

    2. 参加者のリストを作成ドロップダウン・ボックスから、「ルールベース」を選択します。

    3. 「ルールセットのリスト」フィールドにManagerと入力し、フィールドの右にあるプラス・アイコンをクリックします。

  12. マネージャ・ルール・セットの「概要」タブの「一般的なルール」ボックスで、「追加」アイコンをクリックして新規ルールを作成します。

  13. 図13-26に示すように、参加者リスト・ルールを作成します。

    図13-26 Manager参加者ルール

    図13-26の説明が続きます
    「図13-26 Manager参加者ルール」の説明

  14. ReviewTeamステージを編集します。これを行うには、Stage1.Participant2ステージを選択します。「プロパティ」ボックスで、次のようにします:

    1. 「ラベル」をReviewTeamに変更します。

    2. 参加者のリストを作成ドロップダウン・ボックスから、「ルールベース」を選択します。

    3. 「ルールセットのリスト」フィールドにReviewTeamと入力し、フィールドの右にあるプラス・アイコンをクリックします。

  15. ReviewTeamルール・セットの「概要」タブの「一般的なルール」ボックスで、「追加」アイコンをクリックして新規ルールを作成します。「ルール・セット」にReviewTeamが表示されない場合は、「追加」アイコンを使用して手動で作成します。

  16. 図13-27に示すように、参加者リスト・ルールを作成します。

    図13-27 Review Team参加者ルール

    図13-27の説明が続きます
    「図13-27 Review Team参加者ルール」の説明
13.4.5.4.2 パラレル承認タスクのプロパティ

表13-2に、パラレル承認タスクを構成する際の「データ」タブの属性をリストします。

表13-2 パラレル・ヒューマン・タスクの「データ」タブの属性

パラメータ データ型

RequestID

{http://www.w3.org/2001/XMLSchema}string

RequestModel

{http://www.w3.org/2001/XMLSchema}string

RequestTarget

{http://www.w3.org/2001/XMLSchema}string

RequesterDetails

{http://xmlns.oracle.com/request/RequestDetails}RequesterDetails

BeneficiaryDetails

{http://xmlns.oracle.com/request/RequestDetails}BeneficiaryDetails

ObjectDetails

{http://xmlns.oracle.com/request/RequestDetails}ObjectDetails

OtherDetails

{http://xmlns.oracle.com/request/RequestDetails}OtherDetails

url

{http://xmlns.oracle.com/request/RequestDetails}url

Catalogdata

{http://xmlns.oracle.com/RequestServiceApp/RequestDataService/CatalogData}CatalogData

RequesterDisplayName

{http://www.w3.org/2001/XMLSchema}string

BeneficiaryDisplayName

{http://www.w3.org/2001/XMLSchema}string

Requester

{http://www.w3.org/2001/XMLSchema}string
13.4.5.4.3 シリアル承認タスクの構成

シリアル承認タスクを構成するには:

  1. 「SOAコンポジット」ビューに切り替えます。シリアル承認タスクを編集します。
  2. 「データ」タブをクリックします。
  3. シリアル承認タスクのプロパティにリストされているパラメータを追加します。
  4. 「データ」タブでタスク・パラメータを検証し、「一般」タブをクリックします。
  5. 「タスクのタイトル」を<%/task:task/task:payload/ns2:BeneficiaryDetails/ns2:DisplayName%> has submitted a request for approvalに設定します。
  6. 「タスク所有者」を「グループ」と「SYSTEM ADMINISTRATORS」に設定し、「名前別」オプションを「承認」とともに使用して「カテゴリ」を設定します。
  7. 「通知」タブをクリックし、次に「詳細」をクリックします。
  8. 「通知をアクション可能にする」オプションを選択します。「ワークリスト/ワークスペースURLを通知に表示」オプションの選択を解除します。
  9. 「割当て」タブをクリックします。
  10. 順次ステージを追加し、図13-28に示すように、ステージの名前をManagerおよびReview Teamに変更します。

    図13-28 シリアル・ステージ

    図13-28の説明が続きます
    「図13-28 シリアル・ステージ」の説明
  11. Managerステージを編集します。これを行うには、Stage1.Participant1ステージを選択します。「プロパティ」ボックスで、次のようにします:

    1. ラベルをManagerに変更します。

    2. 「参加者のリストのビルド」ドロップダウンから、「ルールベース」を選択します。

    3. 「ルールセットのリスト」フィールドにManagerと入力し、フィールドの右にあるプラス・アイコンをクリックします。

  12. マネージャ・ルール・セットの「概要」タブの「一般的なルール」ボックスで、「追加」アイコンをクリックして新規ルールを作成します。
  13. 図13-29に示すように、参加者リスト・ルールを作成します。

    図13-29 Managerステージのルール

    図13-29の説明が続きます
    「図13-29 Managerステージのルール」の説明
  14. ReviewTeamステージを編集します。これを行うには、Stage1.Participant2ステージを選択します。「プロパティ」ボックスで、次のようにします:

    1. ラベルをReviewTeamに変更します。

    2. 「参加者のリストのビルド」ドロップダウンから、「ルールベース」を選択します。

    3. 「ルールセットのリスト」フィールドにReviewTeamと入力し、フィールドの右にあるプラス・アイコンをクリックします。

  15. ReviewTeamルール・セットの「概要」タブの「一般的なルール」ボックスで、「追加」アイコンをクリックして新規ルールを作成します。
  16. 図13-30に示すように、参加者リスト・ルールを作成します。

    図13-30 Review Teamステージのルール

    図13-30の説明が続きます
    「図13-30 Review Teamステージのルール」の説明
13.4.5.4.4 シリアル承認タスクのプロパティ

表13-3に、シリアル承認タスクを構成する際の「データ」タブの属性をリストします。

表13-3 シリアル承認タスクの「データ」タブの属性

パラメータ データ型

RequestID

{http://www.w3.org/2001/XMLSchema}string

RequestModel

{http://www.w3.org/2001/XMLSchema}string

RequestTarget

{http://www.w3.org/2001/XMLSchema}string

RequesterDetails

{http://xmlns.oracle.com/request/RequestDetails}RequesterDetails

BeneficiaryDetails

{http://xmlns.oracle.com/request/RequestDetails}BeneficiaryDetails

ObjectDetails

{http://xmlns.oracle.com/request/RequestDetails}ObjectDetails

OtherDetails

{http://xmlns.oracle.com/request/RequestDetails}OtherDetails

url

{http://xmlns.oracle.com/request/RequestDetails}url

Catalogdata

{http://xmlns.oracle.com/RequestServiceApp/RequestDataService/CatalogData}CatalogData

RequesterDisplayName

{http://www.w3.org/2001/XMLSchema}string

BeneficiaryDisplayName

{http://www.w3.org/2001/XMLSchema}string

Requester

{http://www.w3.org/2001/XMLSchema}string
13.4.5.4.5 デフォルト承認タスクの構成

デフォルト承認タスクを構成するには:

  1. 「SOAコンポジット」ビューに切り替えます。承認タスクを編集します。
  2. 「一般」タブをクリックします。
  3. 図13-31に示すように、タスクのタイトルを設定します。

    図13-31 デフォルト承認タスク

    図13-31の説明が続きます
    「図13-31 デフォルト承認タスク」の説明
  4. 「割当て」をクリックします。
  5. Managerステージを編集します。これを行うには、approvalApp.approvalTask.assigneeステージを選択します。「プロパティ」ボックスで、次のようにします:

    1. 「ラベル」を「マネージャ」に変更します。

    2. 「参加者のリストのビルド」ドロップダウンから、「ルールベース」を選択します。

    3. 「ルールセットのリスト」フィールドにManagerと入力し、フィールドの右にあるプラス・アイコンをクリックします。

  6. マネージャ・ルール・セットの「概要」タブの「一般的なルール」ボックスで、「追加」アイコンをクリックして新規ルールを作成します。
  7. 図13-32に示すように、参加者リスト・ルールを作成します。

    図13-32 参加者リスト・ルール

    図13-32の説明が続きます
    「図13-32 参加者リスト・ルール」の説明
13.4.5.5 ヒューマン・タスクとBPELのマッピングの構成

ヒューマン・タスクとBPELのマッピングを構成する手順は次のとおりです。

13.4.5.5.1 シリアル承認ヒューマン・タスクの構成

シリアル承認ヒューマン・タスクを構成するには:

  1. 「BPEL」プロセスに切り替えます。次の条件を、Serial Approvalスイッチに追加します。
    bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType') = 'Serial'
  2. 図13-33に示すように、Human TaskアクティビティをSOAコンポーネントからSerial Approvalスイッチにドラッグ・アンド・ドロップします。

    図13-33 Human Taskアクティビティ

    図13-33の説明が続きます
    「図13-33 Human Taskアクティビティ」の説明
  3. ヒューマン・タスクを編集し、「ヒューマン・タスク」ダイアログ・ボックスで、シリアル承認ヒューマン・タスク定義を選択します。
  4. 「起案者」を「リクエスタ・ログイン」にマップし、図13-34に示すように、「BPEL変数」にタスク・パラメータをマップします。

    図13-34 タスク・パラメータとBPEL変数のマッピング

    図13-34の説明が続きます
    「図13-34 タスク・パラメータとBPEL変数のマッピング」の説明
  5. 「詳細」タブをクリックします。図13-35に示すように、識別キーをリクエストIDにマップします。

    図13-35 識別キーとリクエスタIDのマッピング

    図13-35の説明が続きます
    「図13-35 識別キーとリクエスタIDのマッピング」の説明
  6. イニシエータをリクエスタ・ログインにマップし、「適用」および「OK」をクリックします。
  7. タスク結果はREJECTのSwitch caseを選択します。
  8. 既存の条件スクリプトを次のように置き換えます。
    bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:outcome') = 'REJECT'
  9. 「タスク結果はREJECT」の下のAssignアクティビティを選択および編集します。
  10. 1つを除くすべてのコピー・ルールを削除します。残すコピー・ルールは「ソース」ビューで置換できるため、どれでもかまいません。
  11. 保存して「ソース」タブをクリックします。次に、copyアクティビティを選択します。
  12. そのアクティビティを、次のものに置き換えます。
    <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>
  13. タスク結果はAPPROVEに対してこのステップを繰り返します。Switch Caseを選択し、「条件」フィールドに次のものをコピーします。
    bpws:getVariableData('SerialApproval1_globalVariable','payload','/task:task/task:systemAttributes/task:outcome') = 'APPROVE'
  14. 承認結果の下の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>
  15. 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>
13.4.5.5.2 パラレル・ヒューマン・タスクの構成

パラレル・ヒューマン・タスクを構成するには:

  1. 次の条件を、Parallel Approvalスイッチ・アクティビティに追加します。
    bpws:getVariableData('workflowtype','/ns18:StageOutput/ns18:stageType') = 'Parallel'
  2. Human TaskアクティビティをSOAコンポーネントからParallel Approvalスイッチにドラッグ・アンド・ドロップします。
  3. パラレル承認ヒューマン・タスクを選択します。
  4. シリアル・ヒューマン・タスクと同様の方法で、ヒューマン・タスク・パラメータをマップします。
  5. シリアル・ヒューマン・タスクの同等物と同じ方法で、APPROVE結果のAssignアクティビティをマップします。
  6. シリアル・ヒューマン・タスクの同等物と同じ方法で、REJECT結果のAssignアクティビティをマップします。
  7. シリアル・ヒューマン・タスクの同等物と同じ方法で、Otherwise結果のAssignアクティビティをマップします。

    ノート:

    copyアクティビティで適切なグローバル変数(ParallelApproval1_globalVariable)を指定する必要があります。

13.4.5.5.3 自動承認の構成

自動承認を構成するには:

  1. Otherwise switch caseで、Assignアクティビティをドラッグ・アンド・ドロップします。
  2. assignアクティビティを選択し、「ソース」ビューに切り替えます。
  3. 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>
13.4.5.6 SOAコンポジットのデプロイ

SOAコンポジットをデプロイするには:

  1. 「ファイル」、「すべて保存」を選択して、作業を保存します。
  2. プロジェクトを右クリックし、「デプロイ」、「COMPOSITE_NAME」、「アプリケーション・サーバーにデプロイ」の順に選択します。または、SAR (SOAアーカイブ)にデプロイしてから、Oracle Enterprise Managerを使用してデプロイできます。

    ノート:

    • デフォルトのバージョンは1.0です。既存のコンポジット・インスタンスが実行されている場合は、バージョンを変更することもできます。

    • コンポジットを再デプロイする場合に1つ以上のヒューマン・タスクを追加または削除した場合は、異なるバージョンでデプロイすることをお薦めします。

13.4.5.7 ワークフロー・ルールの作成

作成したSOAコンポジットは、単一およびバルク操作に使用できます。コンポジットが特定の操作に対して起動されるようにするには、Oracle Identity Managerでワークフロー・ルールを作成する必要があります。

Oracle Identity Managerでワークフロー・ルールを作成するには:

  1. Oracle Identity System Administrationにログインします。
  2. 左側のナビゲーション・ペインの「ワークフロー」で、「承認」をクリックします。
  3. アプリケーション・インスタンスのバルク・プロビジョニング操作のワークフロー・ルールを作成し、自動承認に設定します。ワークフロー・ルールの作成と管理の詳細は、Oracle Identity Governanceの管理の承認ワークフロー・ルールの構成を参照してください。
  4. アプリケーション・インスタンスのプロビジョニング操作のワークフロー・ルールを作成し、デプロイするコンポジットを起動することを指定します。

ノート:

各タイプのリクエストに対して複数のSOAコンポジットを作成可能ですが、こチュートリアルで示すように単一のSOAコンポジットを使用して、複数のヒューマン・タスクを作成することをお薦めします。Oracle Business Rulesで作成したルールを使用すると、このチュートリアルで示すように、ヒューマン・タスクを選択できます。

ヒント:

SOAコンポジットBPELプロセスであるリクエストWebサービスにサポートされるエンティティ(カタログ、ユーザー、ロールまたは組織など)のカスタム属性の値にアクセスできます。カスタム属性またはUDFはCustomAttribute要素の一部です。UDFを含むカタログ・エンティティのインスタンスは次のとおりです。

<ns12:CustomAttribute Name="ApproverRolePhoneNumber">
    <ns5:Value>1234</ns5:Value>
</ns12:CustomAttribute>
<ns12:CustomAttribute Name="ApproverRoleEmailId">
   <ns5:Value>approver@example.com</ns5:Value>
</ns12:CustomAttribute>

たとえば、BPELプロセスでApproverRolePhoneNumberカタログのUDF値にアクセスするには、次のように指定します。

bpws:getVariableData('catalogDetails','CatalogData','/ns22:CatalogData/ns22:CustomAttribute[@Name = string("ApproverRolePhoneNumber")]/ns24:Value')

13.5 単一およびバルク操作のデフォルト承認コンポジットの構成

リクエストレベルのコンポジットはバルク・リクエストに適用でき、操作レベルのコンポジットは単一および子リクエストに適用できます。

oim-config.xmlファイルにDefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティを設定すると、デフォルトのコンポジットを構成できます。これらのプロパティは、Oracle Enterprise ManagerのSystem MBean Browserを使用して編集できます。これらのプロパティのデフォルト値は、それぞれdefault/DefaultRequestApproval!6.0とdefault/DefaultOperationalApproval!6.0になります。

これらのプロパティの値は、次の形式で入力します。

NAMESPACE/COMPOSITE_NAME!VERSION

たとえば:

default/AddAccessApproval!2.0

DefaultRequestLevelCompositeプロパティおよびDefaultOperationLevelCompositeプロパティのデフォルト値を変更する場合は、Oracle Identity Managerを再起動する必要があります。

13.6 カスタム・タスク詳細タスクフローの作成およびデプロイ

独自のタスクフローを作成し、そのカスタム・タスクフローを呼び出すようにDefaultRequestApprovalコンポジットのヒューマン・タスクを構成します。

デフォルトでは、すべてのタスクは、保留中の承認のデフォルト・タスク詳細ページを使用するように構成されています。このタスクフローはカスタマイズできません。ただし、タスク詳細ページのUIをカスタマイズしたり、その他の情報を表示することはできます。この項では、独自のタスクフローを作成し、DefaultRequestApprovalコンポジットのヒューマン・タスクを構成して、そのカスタム・タスクフローを呼び出す方法を説明します。

この項の内容は次のとおりです。

13.6.1 カスタム・タスク詳細タスクフローを開発するための前提条件

カスタム・タスク詳細タスクフローを開発するためには、Oracle Identity Manager、SOAおよびJDeveloperをインストールします。

カスタム・タスク詳細タスクフローを開発する前に、コンピュータに次のソフトウェアをインストールしておく必要があります。

  • Oracle Identity Governance 12c (12.2.1.3.0)

  • Oracle SOA 12c (12.2.1.3)

  • SOA Quick StartディストリビューションからインストールされたJDeveloper 12c (12.2.1.3) (『Oracle Fusion Middleware SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』のOracle SOA Suite Quick Start for Developersのインストールに関する項を参照)

13.6.2 カスタム・タスク詳細タスクフローの開発

DefaultRequestApprovalコンポジットのヒューマン・タスクのカスタム・タスクフローを作成します。

この項では、カスタム・タスクフローの開発方法について説明します。次の項目が含まれます。

13.6.2.1 カスタム・タスクフローの構築: おおまかなステップ

DefaultRequestApprovalコンポジットのヒューマン・タスクのカスタム・タスクフローを作成するには:

  1. Jdeveloperを開き、新規汎用アプリケーションを作成します。そのように行うには:

    1. アプリケーション名としてRequestApprovalTaskDetailsAppを入力し、「次へ」をクリックします。

    2. プロジェクト名としてRequestApprovalTaskDetailsを入力します。プロジェクト・テクノロジは選択しないでください。

    3. 「終了」をクリックします。

  2. Oracle Identity Manager共有ライブラリを追加します。そのように行うには:

    1. RequestApprovalTaskDetailsプロジェクトを右クリックして、「プロジェクト・プロパティ」→「ライブラリとクラスパス」の順に選択します。

    2. 「ライブラリの追加」をクリックします。

    3. 「ディレクトリ」をクリックします。

    4. IAM_HOME/server/jdev.lib/ディレクトリに移動し、「選択」をクリックします。

      ノート:

      IAM_HOMEはOracle Identity Managerのホーム・ディレクトリのパスで、たとえばBEA_HOME/Oracle_IDM1/のようになります。ここでは、BEA_HOMEは、Oracle Identity Managerインストールのミドルウェア・ディレクトリのパスです。

    5. OIMビュー共有ライブラリ→OIMモデル共有ライブラリを選択し、「OK」をクリックします。

    6. 「OK」をクリックします。

  3. タスク詳細タスクフローを作成します。そのように行うには:

    1. shiphome内の次ディレクトリに移動します。

      IAM_HOME/server/workflows/composites/

    2. DefaultRequestApproval.zipファイルを解凍します。

    3. Jdeveloperに戻り、RequestApprovalTaskDetailsを右クリックして、「新規作成」を選択します。

    4. ヒューマン・タスクに基づいて、「Web層」、「JSF」、ADFタスクフローを選択します。

    5. ファイル・ブラウザで、DefaultRequestApproval.zipを解凍したディレクトリに移動します。DefaultRequestApproval/ApprovalTask.taskファイルを選択します。

    6. 「タスク・フローの作成」ダイアログ・ボックスで、次の値を指定します。

      ファイル名: request-approval-details-tf.xml

      ディレクトリ: タスクフローがWEB-INF/oracle/iam/ui/custom/ディレクトリに作成されることを確認します。WEB-INF/oracle/iam/ui/custom/ディレクトリの下のすべてのタスクフローが表示権限で保護されます。

      タスク・フローID: request-approval-details-tf

    7. 「OK」をクリックします。

  4. hwtaskflow.xmlを削除します。これを行うには、RequestApprovalTaskDetailsプロジェクトの下の「アプリケーション・ソース」に進み、hwtaskflow.xmlを削除します。

  5. タスク詳細ページを作成します。そのように行うには:

    1. request-approval-details-tf.xmlを開きます。Diagramモードに切り替えます。

    2. taskdetails1_jspx viewアクティビティの名前をrequest-approval-detailsに変更します。

    3. request-approval-details viewアクティビティを右クリックし、「ページの作成」を選択します。次の値を入力します。

      ファイル名: request-approval-details.jspx

      ディレクトリ: JSPXファイルをpublic_html/oracle/iam/ui/custom/ディレクトリに配置します。

      初期ページ・レイアウトおよびコンテンツ: 空白ページ

    4. 「OK」をクリックします。

  6. タスク詳細ページのマネージドBeanの追加の説明に従って、タスク詳細ページのマネージドBeanを追加します。

  7. 詳細ページ構造の作成の説明に従って、詳細ページ構造を作成します。

  8. 「リクエスト情報」タブの移入の説明に従って、「リクエスト情報」タブに移入します。

  9. 「タスク情報」タブの移入の説明に従って、「タスク情報」タブに移入します。

13.6.2.2 タスク詳細ページのマネージドBeanの追加

タスクの詳細ページのマネージドBeanを追加するには:

  1. RequestApprovalTaskDetailsプロジェクトを右クリックして、「新規作成」→「Javaクラス」を選択します。次の値を入力します。

    名前: RequestApprovalDetailsStateBean

    パッケージ: oracle.iam.ui.custom.view.backing

  2. 「OK」をクリックします。
  3. 次のコードをマネージド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);
    }
    
    
}
  4. 「概要」モードでrequest-approval-details-tf.xmlを開きます。「マネージドBean」セクションを選択し、次の詳細でマネージドBeanを登録します。

    名前: requestApprovalDetailsStateBean

    クラス: oracle.iam.ui.custom.view.backing.RequestApprovalDetailsStateBean

    スコープ: pageFlow

13.6.2.3 詳細ページ構造の作成

タスク詳細ページ構造を作成するには:

  1. request-approval-details.jspxを開きます。
  2. コンポーネント・パレットからpanelStretchLayoutをページに追加します。プロパティ・インスペクタで、panelStretchLayoutに対してTopHeght==autoを設定します。
  3. 「アプリケーション・ナビゲータ」で、「データ・コントロール」に移動します。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「Return」を開きます。図13-36に示すように「データ・コントロール」からpanelStretchLayoutのトップ・ファセットに「タスク」をドラッグ・アンド・ドロップします。コンテキスト・メニューから、「ヒューマン・タスク」→「タスク・アクション」を選択します。ヒューマン・タスク・アクションが、トップ・ファセットに追加されます。

    図13-36 トップ・ファセットへのタスクのドラッグ

    図13-36の説明が続きます
    「図13-36 トップ・ファセットへのタスクのドラッグ」の説明
  4. コンポーネント・パレットから、panelTabbedレイアウトをpanelStretchLayoutの中央ファセットに追加します。
  5. コンポーネント・パレットから、2つのshowdetailItemコンポーネントをpanelTabbedレイアウトに追加します。プロパティ・インスペクタから、これらのコンポーネントのテキスト名としてRequest InformationとTask Informationを設定します。
  6. 「リクエスト情報」タブをクリックします。プロパティ・インスペクタで属性stretchChildren=firstを設定します。
  7. 「リクエスト情報」タブで、もう1つのpanelStretchLayoutを追加します。このpanelStretchLayoutに対して属性topHeight=autoを設定します。図13-37は、「リクエスト情報」および「タスク情報」タブを示しています。

    図13-37 panelTabbedレイアウト

    図13-37の説明が続きます
    「図13-37 panelTabbedレイアウト」の説明
13.6.2.4 「リクエスト情報」タブの移入

「リクエスト情報」タブに移入するには:

  1. 「ナビゲータの表示オプション」に移動し、図13-38に示す「ライブラリの表示」を選択します。これにより、「アプリケーション・ナビゲータ」にOIMビュー共有ライブラリが表示されます。

    図13-38 OIMビュー共有ライブラリ

    図13-38の説明が続きます
    「図13-38 OIMビュー共有ライブラリ」の説明
  2. 「アプリケーション・ナビゲータ」で、OIMビュー共有ライブラリ→WEB-INF/oracle/iam/ui/catalog/tfsを開きます。request-summary-information-tf.xmlを、ステップ7gで追加したPanelStretchLayoutのトップ・ファセットにドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。「リージョン」を選択します。「タスク・フロー・バインディングの編集」ダイアログ・ボックスが表示されます。タスクフローのパラメータは後から指定できます。したがって「OK」をクリックします。
  3. 同様に、catalog-tf.xmlを、ステップ7gで追加したPanelStretchLayoutの中央ファセットにドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。「リージョン」を選択します。「タスク・フロー・バインディングの編集」ダイアログ・ボックスが表示されます。「OK」をクリックします。
  4. ページの下部にある「バインディング」タブをクリックし、バンディングを表示します。プラス(+)記号をクリックして、次のようにバインディングを追加します。

    i) 次のように入力して、「OK」をクリックします。

    カテゴリ: 一般バインディング

    作成するアイテム: attributeValues

    ii) 「データソースの追加」をクリックします。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」を選択します。「OK」をクリックします。

    iii) 属性としてRequestIDを指定し、「OK」をクリックします。

  5. 「実行可能ファイル」の下でtaskflow-requestsummaryinformationtf1を選択します。「プロパティ・インスペクタ」で、プラス(+)記号をクリックしてタスクフロー・パラメータを追加します。この値フィールドを編集し、次に示すように#{bindings.RequestID.inputValue}で更新します。

    ID=requestID、Value= #{bindings.RequestID.inputValue}

  6. プラス記号(+)をクリックして、もう1つのバインディングを追加します。このバインディングは、RequestApprovalDetailsStateBeanで参照されます。

    i) 次のように入力して、「OK」をクリックします。

    カテゴリ: 一般バインディング

    作成するアイテム: attributeValues

    ii) 「データソースの追加」をクリックします。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」→「BeneficiaryDetails」を選択します。「OK」をクリックします。

    iii) 属性としてDisplayNameを指定し、「OK」をクリックします。

  7. プラス記号(+)をクリックして、もう1つのバインディングを追加します。このバインディングは、RequestApprovalDetailsStateBeanで参照されます。

    i) 次のように入力して、「OK」をクリックします。

    カテゴリ: 一般バインディング

    作成するアイテム: attributeValues

    ii) リストから、データソース「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「戻る」→「タスク」→「ペイロード」を選択します。

    iii) 属性としてRequestTargetを指定し、「OK」をクリックします。

  8. 「実行可能ファイル」で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}

13.6.2.5 「タスク情報」タブの移入

「タスク情報」タブに移入するには:

  1. 設計モードに切り替えます。「タスク情報」タブをクリックします。
  2. アプリケーション・ナビゲータで、「データ・コントロール」に移動します。「RequestApprovalTaskDetails_ApprovalTask」→「getTaskDetails」→「Return」を開きます。「タスク情報」タブで「タスク」をドラッグ・アンド・ドロップします。コンテキスト・メニューの作成が表示されます。図13-39に示すように、「ヒューマン・タスク」→「ペイロードのない完了済タスク」を選択します。

    図13-39 タスク詳細DataControl

    図13-39の説明が続きます
    「図13-39 タスク詳細DataControl」の説明
  3. panelGroupLayout内にラップされているpanelHeaderが、「タスク情報」タブに追加されます。panelHeaderに移動し、panelHeaderのツールバー・ファセットを削除します。タスク・アクションは、すでにステップ7cにあります。さらに、タスク詳細、タスク履歴、コメント、および添付も、「タスク情報」タブに追加されています。
  4. 作業内容を保存します。

13.6.3 電子メール通知のカスタム・タスク詳細の開発(オプション)

デフォルトでは、電子メール通知の送信について、電子メール用に別のページがない場合は、開発した同じタスク詳細ページが電子メール通知で送信されます。

場合によっては、電子メール通知で送信する情報を制限する必要があります。そのような場合は、電子メール通知用に別のページを開発できます。電子メール・ページも、同じタスク詳細タスクフローの一部になります。

電子メール用カスタム・タスクフローの作成の詳細は、Oracle SOA Suite開発者ガイドの電子メール通知の作成を参照してください。

13.6.4 タスク詳細タスクフローのデプロイ

タスク詳細タスクフローをデプロイするには、タスク詳細をADFライブラリJARとしてデプロイし、adflibRequestApprovalTaskDetails.jarをカスタム共有ライブラリにパッケージ化します。

タスク詳細タスクフローをデプロイするには:

  1. ADFライブラリJARとしてタスク詳細をデプロイします。そのように行うには:

    1. 「RequestApprovalTaskDetails」を右クリックして、「プロジェクト・プロパティ」→「デプロイメント」の順に選択します。

    2. 「新規」をクリックします。「デプロイメント・プロファイルの作成」ダイアログ・ボックスが表示されます。

    3. 次の値を指定し、「OK」をクリックします。

      アーカイブ・タイプ: ADFライブラリJARファイル

      名前: adflibRequestApprovalTaskDetails

    4. 「RequestApprovalTaskDetails」を右クリックして、「デプロイ」→「adflibRequestApprovalTaskDetails」を選択します。

    5. 「デプロイメント・アクション」ポップアップで、「終了」をクリックします。

  2. カスタム共有ライブラリでadflibRequestApprovalTaskDetails.jarをパッケージ化します。そのように行うには:

    1. IAM_HOME/server/apps/ディレクトリに移動します。

    2. 次のディレクトリ構造を作成します。

      WEB-INF/lib/

    3. WEB-INF/lib/ディレクトリにadflibRequestApprovalTaskDetails.jarをコピーします。

    4. 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/*

  3. Oracle Identity Manager管理対象サーバーを再起動して、カスタム共有ライブラリへの変更を反映します。

13.6.5 ヒューマン・タスクとタスクフロー権限の構成

タスク詳細タスクフローをデプロイした後、ヒューマン・タスクとタスクフロー権限を構成できます。

ヒューマン・タスクとタスクフロー権限を構成するには、次の手順を実行します。

13.6.5.1 カスタム・タスクフローのビュー権限の追加

認可ポリシー・マネージャ(APM)を使用してカスタム・タスクフローの表示権限を追加するには:

  1. WebLogicユーザーとしてAPMアプリケーションにログインします。
  2. 「アプリケーション」→「OracleIdentityManager」→「リソース・タイプ」に移動します。「開く」をクリックします。
  3. 「新規作成」をクリックして、新しいリソース・タイプを作成します。次の詳細を入力して、「保存」をクリックします。

    • 表示名: ADFタスク・フロー

    • 名前: ADFTaskFlows

    • アクション: パーソナライズ、カスタマイズ、付与、表示。各アクションを追加するには、「新規」をクリックします。

    • リソース階層のサポート: いいえ

    • リソース・デリミタ: スラッシュ(/)

    • 評価ロジック: 権限クラス

    • 権限クラス: oracle.adf.controller.security.TaskFlowPermission

    • アクション名デリミタ: カンマ(,)

  4. 「アプリケーション」→「OracleIdentityManager」→デフォルト・ポリシー・ドメイン→リソース・カタログ→「リソース」に移動します。「開く」をクリックします。
  5. 「新規」をクリックして、新規リソースを作成します。次の値を入力して、「保存」をクリックします。

    • リソース・タイプ: ステップ3で作成したリソース・タイプを選択します。

    • 表示名: カスタム・タスクフローの表示名を入力します。

    • 名前: カスタム・タスクフローの名前を次の形式で入力します。 

      TASKFLOW_DOCUMENT#TASKFLOW_ID

      たとえば:

      /WEB-INF/request-approval-details-tf.xml#request-approval-details-tf

    • 説明: カスタム・タスクフローの説明を入力します。

    ノート:

    ステップ1(f)で説明したように、カスタム・タスクフローには、それぞれリソースを作成する必要があります。すべてのカスタム・タスクフローに対して、ステップ1(c)で作成したリソース・タイプと同じものを使用できます。

  6. 「アプリケーション」→「Oracle Identity Manager」→デフォルト・ポリシー・ドメイン→「認可ポリシー」に移動します。「開く」をクリックします。
  7. 「プリンシパルによる検索」を選択し、「検索」をクリックします。表示されている既存のポリシーを追加する場合は、それを選択し「開く」をクリックします。それ以外の場合は、「新規」をクリックしてポリシーを作成します。
  8. 新しいポリシーの名前およびプリンシパルを追加します。
  9. 「ターゲットの追加」(+)記号をクリックします。ターゲットの検索ダイアログ・ボックスが表示されます。
  10. 「リソース」タブをクリックします。ステップ5で定義したリソース・タイプを指定して、「検索」をクリックします。
  11. ステップ5で作成したリソースを選択します。「選択した項目の追加」をクリックします。
  12. ターゲットの追加をクリックします。リソースが「ターゲット」表に追加されます。
  13. 表に追加したリソースを展開します。タスクフローに適用する権限を選択します。完了したら、「適用」をクリックします。
13.6.5.2 カスタム・タスクフローを使用するためのヒューマン・タスクの構成

カスタム・タスクフローを使用するようにヒューマン・タスクを構成するには:

  1. WebLogicユーザーとしてOracle Enterprise Managerにログインします。
  2. 「Farm_IAM_DOMAIN」→「SOA」→「soa_infra (SOA_SERVER)」→「デフォルト」→「DefaultRequestApproval [4.0]」に移動します。
  3. 「コンポーネント・メトリック」→「承認タスク」をクリックします。
  4. 「管理」タブをクリックします。
  5. 次に示すように、既存のエントリの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/oracle/iam/ui/custom/request-approval-details-tf.xml

    ノート:

    URIの形式は次のとおりです:
    /identity/faces/adf.task-flow?_id=TASKFLOW_ID&_document=TASKFLOW_DOCUMENT

13.6.6 カスタム・タスクフローのテスト

リクエストを作成し、「保留中の承認」で「タスクの詳細」リンクを検証することで、カスタム・タスクフローをテストします。

カスタム・タスクフローをテストするには:

  1. エンド・ユーザーとしてOracle Identity Self Serviceにログインします。
  2. 「本人情報」に移動し、「電話」属性の値を変更します。リクエストが作成され、タスクがシステム管理者に割り当てられます。
  3. システム管理者としてOracle Identity Self Serviceにログインします。
  4. 「保留中の承認」に移動します。
  5. 対応するリクエストの「タスクの詳細」リンクをクリックします。カスタム・タスク詳細ページが表示されます。

13.7 リクエスト管理操作の拡張

リクエスト管理操作の特定の側面をカスタマイズして、柔軟性を向上させたり、追加機能のカスタマイズされたロジックを実装できます。これを行うには、リクエスト管理プラグインを使用できます。カスタマイズの実装に使用できるプラグイン・ポイントがあります。

ここでは、プラグイン・ポイントについて次の各項で説明します。

13.7.1 リクエスト・ステータス変更に基づくカスタム・コードの実行

リクエストのライフサイクルの各ステージでステータスが変更されます。リクエスト・エンジンによって、リクエスト・ステータスの変更時にカスタム・コードを実行できるプラグイン・ポイントが公開されます。このプラグイン・ポイントを拡張するカスタム・コードを含むプラグインを実装し、コードを実行するために登録できます。

プラグイン・ポイントは、public void followUpActions(String reqId)メソッドを含むoracle.iam.request.plugins.StatusChangeEventインタフェースです。このメソッドはリクエストIDパラメータで構成され、これとリクエスト管理APIを使用してリクエスト詳細を取得できます。

関連項目:

プラグインおよびプラグイン・ポイントの詳細はプラグインの開発

ステータス変更時に実行するコードは、oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するプラグイン・クラスのfollowUpActions()メソッドで実装する必要があります。plugin.xmlファイルでこのプラグインをどのリクエスト・ステータス変更時に実行するかを指定する必要があります。

たとえば、Oracle Identity Managerでリクエストが「リクエストに失敗しました」ステータスに移行した場合、管理者に通知を送信するカスタム・コードを実行できます。そのように行うには:

  1. oracle.iam.request.plugins.StatusChangeEventインタフェースを実装するRequestFailedChangeEventという名前の新しいプラグイン・クラスを作成します。このクラスには、followUpActions(String reqId)メソッドで管理者に通知を送信するロジックが必要です。
  2. プラグイン・フレームワークで指定されている次の標準形式で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プラグインが実行されることを意味します。

  3. プラグインをOracle Identity Managerに登録します。Oracle Identity Managerにプラグインを登録する方法の詳細は、プラグインの登録を参照してください。

13.7.2 リクエスト・データの検証

RequestDataValidatorプラグインを使用して、送信後にリクエスト・データのカスタム検証を追加できます。

この項では、プラグインをデータ・バリデータおよび事前移入アダプタに関連付ける方法について説明し、シナリオをいくつか示します。次の項目が含まれます。

13.7.2.1 リクエスト・データの検証について

RequestDataValidatorプラグインを使用して、送信後にリクエスト・データのカスタム検証を追加できます。このプラグインのプラグイン・ポイントは、public void validate(RequestData requesterData)メソッドを含むoracle.iam.request.plugins.RequestDataValidatorインタフェースです。

特定のプラグインに関連付けられているデータセット・バリデータおよび事前移入アダプタを定義できます。プラグインに関連付けられるリクエスト・データセットは、プラグイン登録時に定義できます。plugin.xmlファイルは、プラグインとデータセット・バリデータまたは事前移入アダプタの間の関連付けを定義するために使用します。<plugins>要素に付加されている<metadata>ノードは、データ・バリデータと事前移入アダプタの間の関連付けを定義するために使用します。

ノート:

データセットに対して指定されているDataSetValidatorプラグインは、plugin.xml自体でバリデータ・メタデータを指定するプラグイン拡張によってオーバーライドすることはできません。たとえば、デフォルト・バリデータに付属している事前定義済データセットModifyUserDatasetは、カスタム実装クラスによってオーバーライドされません。したがって、データセットのバリデータが優先され、それをオーバーライドするオプションは現時点ではありません。

13.7.2.2 プラグインとデータ・バリデータおよび事前移入アダプタの関連付け

次の例は、プラグインをデータ・バリデータおよび事前移入アダプタに関連付ける方法を示しています。

<?xml version="1.0" encoding="UTF-8"?>
<oimplugins xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <plugins pluginpoint="oracle.iam.request.plugins.RequestDataValidator">
     <plugin pluginclass= "oracle.iam.plugin.appinst.ApplicationInstanceDataValidator" version="1.0" name="AppInstDataValidator">
     <metadata name="DataValidator">
      <value>AppInstanceDataSet|ADAppDataSet|EBSDataSet</value>
   </metadata>
      </plugin>
  </plugins>
</oimplugins>

この例の次のコード行は、プラグインがリクエスト・データ・バリデータ・データセットに関連付けられていることを示すメタデータxml要素の定義を示しています。

<metadata name="DataValidator">

このメタデータ要素のAttribute name="DataValidator"は、リクエスト・データ・バリデータに関連付けられているプラグインを示すことに注意してください。

現在のプラグインに関連付けられているデータセットの名前の定義は、次の行で示されます。

<value>AppInstanceDataSet|ADAppDataSet|EBSDataSet</value>

ノート:

リクエスト・データセット名は、単一のパイプ文字(|)で区切る必要があります。

13.7.2.3 シナリオI: ターゲット・システムに対するユーザーのプロビジョニング

AD User APACターゲットにユーザーをプロビジョニングするように、Oracle Identity Managerが構成されているとします。RequestDataValidatorは、次に示すように、ADUserDataValidatorを対応するリクエスト・データセットに対して構成することを指定します。

<plugin pluginclass= "oracle.iam.plugin.appinst.ADUserDataValidator" version="1.0" name="ADUserDataValidator">
<metadata name="DataValidator">
<value>ADUserAPACDataSet</value>
</metadata>
</plugin>

後で、AD User EMEAターゲットにユーザーがプロビジョニングされるように、システム・コンフィギュレータがOracle Identity Managerを構成する場合、システム・コンフィギュレータは新しいアプリケーション・インスタンスを作成し、UIフォームをそれに関連付けようとします。リクエスト・データセットは、プロセスで自動生成されます。データ・バリデータをこのリクエスト・データセットに対して再利用する場合、次の操作を実行します。

  1. ADUserDataValidatorのplugin.xmlを編集します。
  2. <metadata> <value>サブタグに、新しいリクエスト・データセットの名前をデリミタで区切って追加します。たとえば:
    <value>ADUserAPACDataSet|ADUserEMEADataSet</value>
  3. データ・バリデータ・プラグインを再登録します。
13.7.2.4 シナリオII: 権限リクエストのプロビジョニングまたは変更

権限のプロビジョニングおよび権限の変更リクエストの一部として指定される権限データは、データセット検証プラグインを作成し、プラグイン・メタデータ(plugin.xml)で次のように指定することで検証できます。

<metadata name="DataValidator">
      <value>EBSForm.UD_EBS_RESP</value>
</metadata>

ここで、EBSFormは、アカウントがプロビジョニングされるアプリケーション・インスタンスに関連付けられているフォームの名前で、UD_EBS_RESPは権限に対応する子フォームの名前です。UD_EBS_RESPによって権限タイプが識別されます。

13.7.3 リクエスト作成時の属性値の事前移入

事前移入プラグインは、リクエスト・データセットの属性参照または属性に関連付けられます。これを使用すると、リクエストの作成時にカスタム・コードを実行して、属性値を事前移入できます。リクエスタは、必要に応じて事前移入する値を変更できます。

このプラグインのプラグイン・ポイントは、public Serializable prepopulate(RequestData requestData)メソッドを含むoracle.iam.request.plugins.PrePopulationAdapterインタフェースです。このプラグインは、次のリクエスト・タイプにのみ使用します。

リソースのプロビジョニング、リソースの自己リクエスト、ユーザーの作成、ユーザーの自己登録

次の行は、事前移入データを満たすためのリクエスト・データセット属性に、プラグインがマップされることを示すメタデータ要素の定義を示しています。

<metadata name="PrePopulationAdapater">

関連付けは、データセット名と属性名を次の形式で組み合せることによって定義されます。

<DATASET_NAME>::<ATTRIBUTE_NAME>

たとえば:

AppInstanceDataSet::First Name

複数の属性を同じ事前移入プラグインに関連付けることが可能ですが、その際は、各関連付けを単一のパイプ文字(|)で区切ります。たとえば:

<datasetname1>::<attribute1> | <datasetname2>::<attributename2>|<datasetname3>::<attribute3>

事前移入プラグインの例を次に示します。

<plugins pluginpoint="oracle.iam.request.plugins.PrePopulationAdapter">
  <plugin pluginclass= "oracle.iam.plugin.appinst.ApplicationInstancePrePopulateAdapter" version="1.0" name="AppInstPrepopAdapter">
     <metadata name="PrePopulationAdapater">
   <value>
AppInstanceDataSet::First Name|ADAppDataSet::Last Name
  </value>
   </metadata>
   </plugin>
  </plugins>

ノート:

カタログ・フォーム・デザイナでリクエスト・データセットを作成する他に、リクエスト・データセットをMDSに手動でアップロードすることができます。リクエスト・データセット内にDataSetValidatorまたはPrepopulationAdapter要素を定義することもできます。データセット内で構成されるこれらのデータセット・バリデータまたは事前移入アダプタは、他の構成よりも最優先されます。

たとえば、プラグインEBSUserDataValidatorは、リクエスト・データセットEBSUSerDataSetと関連付けるために登録されますが、そのデータセットは作成されていないか、アップロードされていないとします。もう1つのプラグインADUserDataValidatorが登録されていますが、どのリクエスト・データセットにも関連付けられていません。後でリクエスト・データセットEBSUSerDataSetを作成して、リクエストの作成に使用すると、そのリクエスト・データを検証するためにプラグインEBSUserDataValidatorがコールされます。そこで、手動で作成したリクエスト・データセットEBSUSerDataSetに、DataSetValidator要素を追加して、別のプラグインADUserDataValidatorを指定します。EBSUSerDataSetを使用してリクエストを作成すると、プラグインADUserDataValidatorがコールされます。これは、ADUserDataValidatorがリクエスト・データセットの一部として構成されたためです。DataSetValidatorエントリをEBSUSerDataSetから削除すると、そのリクエスト・データを検証するためにプラグインEBSUserDataValidatorが起動されます。

13.7.4 アカウント受益者によるリクエスト承認の有効化

アカウント受益者による承認は、IRoutingSlipCallbackクラスを実装するコールバック・クラスを作成することで、有効にできます。

デフォルトでは、アカウント受益者は承認者グループのメンバーかどうかに関係なくリクエストを承認することはできません。一方、アカウント受益者によるリクエスト承認を有効にすることはできます。たとえば、ユーザーは受益者のアカウントをリクエストし、その受益者はアプリケーションの承認者グループに所属します。受益者は、Oracle Identity Managerにログインし、アカウントを承認します。
アカウント受益者を有効にしてそのアカウントを承認するには:
  1. oracle.bpel.services.workflow.task.IRoutingSlipCallback.onTaskAssignedを実装するコールバック・クラスを作成します。
  2. その実装で、タスクの現在の割当て先がTest.Beneficiaryである場合には、ID管理者または他のユーザー(要件に応じる)にタスクを再割当てします。
  3. コールバック・クラスがサーバーのクラスパスに含まれるようにします。
  4. JDeveloperで、承認タスクを開いて、タスク・ステータスにコールバック・クラスを指定します。
  5. 「イベント」タブをクリックします。
  6. 「OnAssigned」状態の場合、「Javaクラス」列で、空のフィールドをクリックして値を入力します。この値は、oracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装するJavaコールバック・クラスの完全クラス名です。
  7. 「OK」をクリックし、作業を保存します。

    ノート:

    コールバック・クラスの使用は、次のURLで「タスク割当てに対する制限の指定」の項を参照してください。

    http://docs.oracle.com/cd/E29597_01/dev.1111/e10224/bp_hwfconf_shared.htm#BABBBJAE

13.8 自己登録リクエストの自動承認の有効化

リクエストを自動承認する必要があるか、SOAコンポジットを起動する必要があるかを決定する承認ワークフロー・ポリシーのルールを構成できます。

構成承認ワークフロー・ルールの詳細は、Oracle Identity Governanceの管理の承認ワークフロー・ルールの構成を参照してください。

承認ワークフロー・ポリシーで自動承認のルールを構成した後、次のステップを実行して自己登録リクエスト用に自動承認を有効化します。

  1. 組織を自動的に割り当てるには、ホーム組織ポリシーを構成します。ホーム組織ポリシーの構成方法の詳細は、Oracle Identity Governanceの管理のホーム組織ポリシーの管理を参照してください。

  2. デフォルトでは、自己登録リクエストに設定されているロールおよびユーザー・タイプは「パートタイムの従業員」です。この値を上書きする場合は、SelfCreateUserDataset.xmlデータセットで構成されているプラグインを変更します。

  3. 必要な値やロジックについて新規プラグイン実装を作成し、データセットで構成されているプラグインを変更することで、新しいプラグイン実装を反映できます。新しいプラグインではoracle.iam.request.plugins.PrePopulationAdapterが実装されている必要があります。

  4. プラグイン登録ユーティリティを使用して、作成したプラグインを登録します。詳細は、プラグイン登録ユーティリティを使用したプラグインの登録および登録解除を参照してください。

  5. リクエスト・データセットを更新するには:

    1. MDSへのメタデータ・ファイルのエクスポートの説明に従って、MDSから/metadata/iam-features-requestactions/model-data/SelfCreateUserDataset.xmlリクエスト・データセットをエクスポートします。

    2. 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>

    3. MDSからのメタデータ・ファイルのインポートの説明に従って、更新されたリクエスト・データセットをMDSにインポートします。

ノート:

Dynamic Monitoring Service (DMS)を使用してパフォーマンス・メトリックを表示できます。次のDMSメトリックは、自己登録フローのパフォーマンスを監視するために存在します。

  • Self_Registration: これは、完了および失敗した自己登録リクエストの数を提供します。

  • oracle.iam.selfservice.uself.uselfmgmt.api.UnauthenticatedSelfService: これは、自己登録リクエスト数や、自己登録リクエストの送信に要した時間などの詳細を提供します。

13.9 「現在の割当てのスキップ」オプションの非表示

タスク・アクションを変更することで、「現在の割当てのスキップ」アクションがSOAコンポーザまたはJDeveloperに表示されないようにすることができます。

現在の割当てのスキップは承認者には有効なアクションではありません。承認者がこのアクションを選択すると、対応するリクエストは失敗します。したがって、次のいずれかの方法を実行して、このオプションを非表示にできます。

  • SOAコンポーザからタスク・アクションを変更します。「現在の割当てのスキップ」アクションに対して、すべてのチェックボックスの選択を解除し、保存します。

  • JDeveloperを使用してタスク・アクションを変更します。「現在の割当てのスキップ」アクションに対して、すべてのチェックボックスの選択を解除します。次に、コンポジットを保存し、再デプロイします。タスクの作成者または所有者がタスク・コンテンツに対して実行できるアクションの指定については、Oracle SOA Suite開発者ガイドのタスク操作のためのアクションの指定を参照してください。

13.10 証明の監視のカスタマイズ

証明の監視は、監視のレベルを拡張するため、または特定のタイトルに達したときに監視プロセスを停止するためにカスタマイズできます。

この項では、証明の監視のカスタマイズ方法について説明します。次の項目が含まれます。

13.10.1 証明の監視のカスタマイズの理解

証明の監視は、監視のレベルを拡張するため、または特定のタイトルに達したときに監視プロセスを停止するためにカスタマイズできます。

証明コンポジットには、カスタマイズ可能な監視ロジックが含まれています。このロジックにより、次のいずれかまたはすべてに基づいて監督者のシーケンスを選択するためのOracle Identity Managerへの問合せをサポートします。

  • プライマリ・レビューア

  • 証明の現在のフェーズ

  • Oracle Identity Managerで定義された管理階層

デフォルトでは、証明タスクが1人のレビューアに割り当てられるという、単一レベルの監視のみがサポートされます。

証明の監視用コンポジットで事前定義されているように、プライマリ・レビューアまたは監督者がサインオフすると、主要なレビュー・タスクはシーケンス内の次の監督者に自動的にルーティングされます。プライマリ・レビューアまたは監視者(最終監視者を除く)が主要なレビュー・タスクでサインオフすると、そのユーザーは、完了したタスクを問い合せて、そのタスクを受信箱で表示することはできなくなります。

13.10.2 証明の監視のカスタマイズ

証明の監視をカスタマイズするには、JDeveloperで証明コンポジットを編集します。

証明の監視のカスタマイズに必要なステップは、次のとおりです。

  1. コンポジットを作成します。そのように行うには:

    1. DOMAIN_HOME/bin/ディレクトリでsetDomainEnv.shスクリプトを実行して、JAVA_HOME、ANT_HOMEおよびPATH環境変数を設定します。

    2. OIM_HOME/server/workflows/new-workflow/ディレクトリに移動します。process-templateサブディレクトリには、コンポジット・ファイルが含まれたZIPファイルのアーカイブが格納されています。このコンポジット・ファイルは、新しいコンポジットを作成するためにベース・ファイルとして使用します。

    3. 次のコマンドを実行します。

      ant -f new_project.xml compliance

      次の選択を行うよう求められます。

      1 - アイデンティティ監査コンポジット

      2 - 証明コンポジット[デフォルト]

    4. オプション2の証明コンポジットを選択します。

    5. プロンプトが表示されたら、新しいコンポジットの名前を入力して、[Enter]を押します。コンポジットが作成され、コンポジットに指定した名前のパッケージ・ディレクトリがprocess-templateサブディレクトリに作成されます。

  2. JDeveloperでコンポジットを開きます。そのように行うには:

    1. process-templateディレクトリに移動します。

    2. ステップ1cで指定したコンポジット名のディレクトリに移動します。

    3. JDeveloperを使用して、COMPOSITE_NAME.jprを開きます。

  3. 「アプリケーション・ナビゲータ」ビューの「プロジェクト」ペインでプロジェクトを開いて、「CertificationTask.task」をダブルクリックして編集します。「割当て」タブをクリックします。「Stage1.Participant」オブジェクトをクリックして、「編集」を選択します。「参加者タイプの編集」ダイアログ・ボックスが表示されます。デフォルトでは、このコンポジットで単一の証明のレベルが定義され、証明は1人のレビューアに割り当てられます。たとえば、証明のレベルを変更するには、現在のタスクの割当て先のマネージャに移動して、次の値を設定します。

    ノート:

    この手順で説明するカスタマイズはサンプルです。詳細なカスタマイズは、CertificationOverseerProcessデフォルト・テンプレートや、SOAのドキュメントを参照してください。

    • タイプ: 「シリアル」。シリアル証明ロジックのみがサポートされます。

    • 参加者のリストの作成で使用: 「管理チェーン」

    • 属性の指定で使用: 「値ベース」

    • 開始参加者: 証明を開始するユーザーを選択します。

    • 最上位の参加者: 「役職別」。証明レビューの最上位の参加者になるレビューアの役職を指定します。最上位の参加者としてVPを指定し、レベル数として5を指定すると、証明はレベル3であっても、VPレベルにまで引き上げられます。その他のレベルは、スキップされます。

    • レベル数: 「番号別」。1を指定すると、証明はマネージャのレベルまでになります。2を指定すると、証明はマネージャのマネージャまでになります。

    • タスクの単一への自動割当て: 「ユーザー」

    • 割当てパターン: 「最もビジーでない箇所」

  4. 「OK」をクリックします。

  5. コンポジットをデプロイします。そのように行うには:

    1. 「ファイル」、「すべて保存」を選択して、作業を保存します。
    2. プロジェクトを右クリックし、「デプロイ」、「COMPOSITE_NAME」、「アプリケーション・サーバーにデプロイ」の順に選択します。または、SAR (SOAアーカイブ)にデプロイしてから、Oracle Enterprise Managerを使用してデプロイできます。

  6. Oracle Identity Self Serviceにログインし、新しくデプロイしたコンポジットを「構成」ページで選択して、証明の定義を作成します。証明の定義の作成の詳細は、『Oracle Identity Governanceでのセルフ・サービス・タスクの実行』の証明の定義の作成に関する項を参照してください。

13.11 アイデンティティ監査コンポジットのカスタマイズ

アイデンティティ監査コンポジットをカスタマイズし、新規のアイデンティティ監査スキャン定義を作成できます。

アイデンティティ監査コンポジットをカスタマイズするには:

  1. コンポジットを作成します。そのように行うには:

    1. OIM_HOME/server/workflows/new-workflow/ディレクトリに移動します。process-templateサブディレクトリには、コンポジット・ファイルが含まれたZIPファイルのアーカイブが格納されています。このコンポジット・ファイルは、新しいコンポジットを作成するためにベース・ファイルとして使用します。

    2. 次のコマンドを実行します。

      ant -f new_project.xml compliance

      次の選択を行うよう求められます。

      1 - アイデンティティ監査コンポジット

      2 - 証明コンポジット[デフォルト]

    3. オプション1のアイデンティティ監査コンポジットを選択します。

    4. プロンプトが表示されたら、新しいコンポジットの名前を入力して、[Enter]を押します。コンポジットが作成され、コンポジットに指定した名前のパッケージ・ディレクトリがprocess-templateサブディレクトリに作成されます。

  2. JDeveloperでコンポジットを開きます。そのように行うには:

    1. process-templateディレクトリに移動します。

    2. ステップ1dで指定したコンポジット名のディレクトリに移動します。

    3. JDeveloperを使用して、COMPOSITE_NAME.jprを開きます。

  3. IdentityAuditRemediationTask.taskを編集して、IdentityAuditTask割当てのすべてのカスタマイズを行います。

  4. 必要なコールバック(「タスク完了」、「エスカレーション」、「有効期限」、「ルーティング」、「再割当て」および「プロキシ」)が構成されていることを確認します。新規に作成したコンポジットまたはデフォルトのアイデンティティ監査修正コンポジットで構成されたコールバックを参照します。

  5. 変更を保存します。

  6. コンポジットをコンパイルして、コンポジットJARファイルをSOAにデプロイします。詳細は、SOAのドキュメントを参照してください。

  7. Oracle Identity Self Serviceにログインし、アイデンティティ監査構成コンポジット参照から新規に作成したコンポジットを使用して新規アイデンティティ監査スキャン定義を作成します。