| Oracle Access Manager IDおよび共通管理ガイド 10g（10.1.4.3） B55478-01 |
|
 戻る |
 次へ |
この章の内容は次のとおりです。
アイデンティティ・システム・ワークフローにより、マスター・アイデンティティ管理者と委任アイデンティティ管理者は、アイデンティティ・システム機能にビジネス・ロジックを適用できます。ワークフローにより、新規従業員用の福利厚生アカウントおよび電子メール・アカウントの作成や、ディレクトリ内のユーザー・プロファイル属性の変更といった複雑な作業手順の整理統合と自動化が実現します。
各ワークフローは、順序付けられたアクションのチェーンで構成されます。たとえば、管理者が新規ユーザー・アイデンティティをユーザー・マネージャに追加する場合、新規情報の送信後、承認などの追加情報の様々な部門に新規情報がルーティングされます。ワークフロー内のすべてのタスク処理を1人の担当者に任せるのではなく、特定の作業を処理するのに最も適した専門担当者に各ステップを割り当てることが可能です。1つのステップが完了すると、ワークフロー・エンジンにより、順序内の次のステップの担当者にワークフロー・チケットが送信されます。
ワークフロー機能の要約は、次のとおりです。
ディレクトリでオブジェクトの作成、オブジェクトの削除、および属性の変更を行うプロセスを自動化および標準化できます。
オブジェクトの作成、オブジェクトの削除、および属性の変更を行う場合に、データ整合性とルールに関するチェックを適用できます。
バックエンド・アプリケーションをプロビジョニングするためのデータ入力システムとしてアイデンティティ・システムを構成できます。
ユーザー、グループおよび管理情報と同様に、Oracle Access Managerはワークフロー定義に関する情報をディレクトリに格納します。これには、ワークフロー内のステップを承認できる人々の情報が含まれます。ワークフロー定義は、ユーザーまたはグループ・ブランチとは対照的に、ディレクトリの構成ブランチにあります。
ワークフローは、ユーザーにより開始できます。たとえば、新しい従業員は、自己登録ワークフローを開始できます。
ワークフローは、プログラム的な方法でも開始できます。たとえば、IdentityXMLのworkflowSaveCreateProfile関数を起動して、ユーザーの作成ワークフローを開始できます。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
ワークフローのURLリンクをコピーして別のアプリケーションのページに埋め込み、Portal Insertsとしてアクセスすることもできます。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ワークフローは、通常、ユーザー・アクションまたは自動データ取得の任意の組合せを伴う繰返し頻度の高い複数ステップのタスクに適しています。各ワークフローは、アイデンティティ・システム・アプリケーションの1つと関連付けられます。次に、いくつかの一般的なワークフローをリストします。
ユーザー・マネージャ: ワークフローを定義して、ユーザーに自分の部門番号および電話番号の変更を許可できます（マネージャに承認されるまでは保留）。新規ユーザーが作成された場合、そのユーザーに関する情報を適切な人々が外部システムからプログラム的に取得できます。
別のワークフローでは、新規ユーザーを企業の電子メール・アプリケーションに追加できます。オブジェクト・テンプレート・スキーマを定義している場合、ワークフローを使用してデータをアイデンティティ・システム・アプリケーションからプロビジョニング用としてバックエンド・アプリケーションに送信できます。オブジェクト・テンプレートの詳細は、「外部アプリケーションへの非LDAPデータの送信」を参照してください。
組織マネージャ: 部品エントリの作成をサプライヤに許可し、サプライヤが追加した各エントリをマネージャが承認するまで保留できます。また、最初にユーザーが新規部品エントリを追加し、次にデータ追加のリクエストを承認担当の適切な人物にルーティングして、最後にその担当者が新規データのディレクトリへのコミットを承認するワークフローを作成できます。
アイデンティティ・システム・ワークフローでは、次の拡張機能がサポートされます。
サブフローを使用すると、複数のワークフロー・アクティビティをパラレルに実行できます。
たとえば、新規ユーザーを作成するリクエストで2つの異なる部門からの承認が必要とされる場合、2つの部門で同時に承認リクエストを受信できます。詳細は、「サブフローの定義」を参照してください。
特定のワークフロー・ステップを異なる動的参加者にルーティングできます。動的参加者は、実行時に評価される属性値またはビジネス・ロジックに基づいて選択されます。
詳細は、「動的参加者の指定」を参照してください。
タスクを割り当てられている正式な参加者が外出やその他の理由により着信チケットを処理できない場合、そのステップの職責をかわりに引き受けるサロゲート（代理人）を指定できます。
詳細は、「サロゲートの指定」を参照してください。
時間ベース・エスカレーションを構成すると、元の参加者が割り当てられたステップを特定の期間内に完了しない場合、ワークフロー・チケットを異なる参加者にルーティングできます。
詳細は、「時間ベース・エスカレーションの有効化」を参照してください。
IdentityXMLを使用すると、Portal Insertsまたはアプリケーションとして任意のWebページからワークフローを起動できます。
詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
ワークフロー監査を使用すると、ワークフローの状態をモニターし、プロセス内の各ステップで特定のアクションを実行したユーザーを正確に特定できます。
詳細は、「ワークフローのモニタリング」を参照してください。
ユーザー操作を必要としないアクションを実現するため、ワークフロー・ステップを構成して外部ソースからアイデンティティ・システムに必要なデータを自動的に取得できます。
詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
ワークフローには様々なタイプがあります。たとえば、ワークフローのあるタイプでは、既存オブジェクトの1つ以上の属性を変更できます。別のタイプのワークフローでは、新規オブジェクトを作成できます。図5-1は、ユーザーの作成ワークフローを示しています。
|
注意: ユーザー・アイデンティティの作成手順は、ユーザーの作成ワークフローが管理者によってどのように定義されたかにより異なります。ユーザーの作成ワークフローが定義されていない場合は、管理者が「ユーザー・アイデンティティの作成」タブを選択しても、十分なアクセス権限がないことを示すメッセージが表示されます。 |
次に、ワークフローを作成する場合の手順の概要についてまとめます。実際の手順は、属性の変更ワークフローとユーザーの作成ワークフロー（またはグループの作成あるいはオブジェクトの作成ワークフロー）では多少異なります。
関連するアイデンティティ・システム・アプリケーションのタブにオブジェクトを追加します。
オブジェクトの属性を構成します。
LDAP属性に対する読取り権限と書込み権限を構成します。
ワークフローの参加者は、ワークフローの処理中に参照および変更されるLDAP属性に対する適切な読取り権限と書込み権限を保持している必要があります。詳細は、「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
属性をアプリケーション・パネルに追加します。
この操作は、LDAP属性とテンプレート属性の両方に適用されます。属性の変更ワークフローの場合、ユーザーは、パネルを含むプロファイル・ページでテンプレート・オブジェクトの属性を参照できません。ただし、テンプレート属性を追加しないと、ワークフローは適切に動作しません。
ワークフローを構成します。
属性の変更ワークフローのステップで属性を追加する場合、リストの一番上の属性がプロファイル・ページで構成されている必要があります（詳細は、「ステップ属性の定義」を参照してください）。一番上の属性が正しく構成されていれば、リスト内の後続の属性は自動的にページに追加されます。
ワークフロー定義により、ワークフローが作成されたアイデンティティ・システム・アプリケーションの関連プロファイル・ページの外観が変化します。たとえば、属性の変更ワークフローが正しく構成されると、ターゲット・オブジェクトの「プロファイルの変更」ページに含まれる属性の横に「変更」ボタンが表示されます。ユーザーの作成ワークフローが正しく構成されると、ユーザー・マネージャの「ユーザー・アイデンティティの作成」を選択したときに適切な属性が表示されます。
ワークフロー定義が作成されると、使用されるワークフロー・タイプに応じて、いずれか1つの方法でワークフローのインスタンスを開始できます。
図5-1 ワークフローの開始方法
| ワークフロー・タイプ | ユーザーがこのワークフローを開始する方法 . . |
|---|---|
|
ユーザーの「プロファイルの変更」ページの「変更をリクエスト」ボタン |
|
|
ユーザー・マネージャの「ユーザー・アイデンティティの作成」リンクからアクセスできる「ユーザー・アイデンティティの作成」ページ。 |
|
|
ユーザーの「プロファイルの表示」ページの「ユーザーの非アクティブ化を開始」ボタン。 |
|
|
ユーザーの再アクティブ化ワークフローの作成時に「プロファイルの表示」ページに表示される「ユーザーの再アクティブ化の開始」ボタン。最初にユーザー・マネージャの「非アクティブなユーザー・アイデンティティ」ページでユーザーを検索する必要があります。 ユーザーの再アクティブ化操作を実行できるのは、ディレクトリ管理者または再アクティブ化権限を保持するユーザーです。 |
|
|
このタイプのワークフローを作成すると、ワークフローを開始するURLが生成されます。URLを保存し、自己登録ワークフローを開始する場合にはそのURLを使用します。 |
|
|
グループ・マネージャの「グループの作成」リンクからアクセスできる「グループの作成」ページ。 |
|
|
グループの「プロファイルの表示」ページ。 |
|
|
組織マネージャの「作成」ページ。 |
|
|
オブジェクトの「プロファイルの表示」ページ。 |
プログラムの実行がワークフローの特定のステップに到達すると、ワークフロー・エンジンによってそのステップ・インスタンスのチケットが作成されます。たとえば、ユーザーの作成ワークフローの場合、ユーザーがユーザー・マネージャで「ユーザーの作成」機能を選択すると、通常はすぐにIT部門の特定の参加者にチケットが送信されます。
各ワークフロー・チケットは、最初はリンクの形式で表示されます。参加者がこのリンクをクリックすると、ワークフロー内のそのステップに関連するアクションを実行するよう求められます。たとえば、IT部門のユーザーがユーザーの作成ワークフローのチケットを処理する場合、通常は新規ユーザーのログインIDとパスワードを指定するよう求められます。
ワークフローでの各ステップの完了時に、ワークフロー・ログが作成されます。
詳細は、「ワークフローの使用」を参照してください。
たとえば、「ユーザー・アイデンティティの作成」ページの内容は、ユーザーの作成ワークフローで構成された属性に基づくことがあります。
新規ユーザーに関する情報がこのページに保存されると、ワークフローの開始ステップは完了します。次のスクリーン・ショットは、ワークフロー定義によってこのワークフロー・インスタンスのチケットが生成されたことを示しています。
このワークフローの参加者は、ワークフロー・ステップに対して生成されたチケットを参照し、新規ユーザーの追加を承認できます。チケット情報は、承認ラベルの横のチケット番号をクリックすることで表示できます。
|
注意: 表示される結果は、ワークフローに関係するステップの数によって異なります。 |
チケット情報が表示されるのは、現在のステップの完了後に実行する必要があるステップ（タスク）がワークフローに含まれる場合のみです。ただし、「有効化」ステップはどの参加者でも完了できるタスクではありません。そのため、「有効化」ステップのチケットは生成されません。ワークフローのステップの数は、確認ページに表示される結果に影響します。次に2つの例を示します。
単一ステップのワークフロー: 参加者が必要な1つのステップ（「開始」）のみを含むワークフローがあるとします（「有効化」ステップには参加者は不要です）。この場合、「開始」ステップの実行後にチケットは生成されません。これは、次に実行される「有効化」ステップが最後のステップであり、このステップには参加者が必要ないためです。確認画面には次のメッセージのみが表示されます。
Initiate - Completed Enable - Completed
複数ステップのワークフロー: 3つのステップ（「開始」、「承認」、「有効化」）を含むユーザーの作成ワークフローがあるとします。参加者が「開始」ステップを実行すると、「承認」ステップが実行可能であることを参加者に通知するチケットが生成されます。この場合、「承認」ステップ用のチケットが生成され、次のようなメッセージが表示されます。
Confirmation Initiate--Completed Ticket generated for next step < step action > < link >."
チケット情報が表示されるのは、ワークフローの次のステップを参加者が実行する必要がある場合のみです（「有効化」は除外されます）。
ワークフローのステップおよびアクションの詳細は、「ワークフローのタイプ、ステップおよびアクション」を参照してください。
アイデンティティ・システムにユーザーを追加するワークフローを作成するとします。この場合、次の手順を実行するユーザーの作成ワークフローを定義できます。パスワードにマルチバイト文字が含まれるユーザーを作成する場合は、注意してください。英語以外のキーボードを使用すると、ユーザーの作成に失敗します。詳細は、「パスワードにマルチバイト文字が含まれる場合、ユーザー作成に失敗する」を参照してください。
ユーザー・マネージャ・アプリケーションで、新規ワークフロー定義を作成します。
この例では、ワークフロー定義に3つのステップが存在し、ユーザー・マネージャにログインしているIT部門の任意のユーザーがそれらのステップを通じて新規ユーザーを作成できます。このワークフローは次のとおりです。
ステップ1（開始）: このステップでは、ユーザー・マネージャにログインしているユーザーが、新規ユーザーのデータを入力します。
ステップ2 （情報と承認の提供）: このステップでは、ユーザーのマネージャが、入力されたユーザーのデータを承認します。
ステップ3（アクティブ化）: このステップでは、新規ユーザーをアクティブ化します。
ユーザーがユーザー・マネージャにログインします。
ユーザーは、「ユーザーの作成」ボタンを選択します。
ワークフロー・インスタンスにより、新規ユーザーの名前、ユーザーID、パスワードと、新規ユーザーのマネージャのユーザーIDと電子メールを指定するよう求められます。
ワークフロー・インスタンスにより、新規ユーザーの作成リクエストが、新規ユーザーの情報とともにそのユーザーのマネージャにルーティングされます。
マネージャは、ユーザー・マネージャ・アプリケーションの「リクエスト」機能をクリックし、ジョブ・チケットのリンクの形式でリクエストを表示します。
マネージャは、チケットのリンクをクリックしてリクエストを表示します。
マネージャは、リクエストを承認するために「プロセス」ボタンをクリックします。
マネージャは、「プロセス」ページの「承認」ボタンをクリックします。
リクエストが処理され、新規ユーザーがアイデンティティ・システムで有効化されます。
新規ユーザーは、各自のディレクトリ・プロファイルと、マスター管理者によってそのプロファイルの属性に割り当てられている権限に応じて、ログイン後に適切な機能を使用できます。詳細は、「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
ワークフローを定義する場合、ほとんどのワークフロー・ステップで次の2つのタイプのオブジェクトおよび属性を使用できます。
LDAPオブジェクトおよび属性: ワークフローを使用して、アプリケーション・プロファイル・ページに構成されているオブジェクトおよび属性を変更できます。ワークフローに参加するユーザーは、これらのオブジェクトおよび属性を表示または変更するための適切な権限を保持している必要があります。
テンプレート属性: ワークフローを使用してバックエンド・アプリケーションをプロビジョニングする場合、テンプレート・スキーマに基づいて情報を追加するワークフロー・ステップを構成します。ワークフロー内でテンプレート属性の値がコミットされたときに、アイデンティティ・イベントAPIプラグインを使用してこのデータを捕捉し、プロビジョニング用としてバックエンド・アプリケーションに送信します。詳細は、「外部アプリケーションへの非LDAPデータの送信」および『Oracle Access Manager開発者ガイド』を参照してください。
リリース7.0の時点で、プロビジョニングではアイデンティティ・システムからバックエンド・システムに向かう一方向のデータ・フローのみを使用できます。そのため、必要に応じてLDAPディレクトリとバックエンド・システムの両方にデータを記述するためのプロビジョニング・ワークフローを構成することになります。これにより、ユーザーは、ワークフロー・ターゲットに構成されているデータを参照できます。ただし、バックエンド・アプリケーションに含まれるターゲットの現在の状態を参照するには、アプリケーションまたはそのログにアクセスする必要があります。
プロビジョニング・ワークフローでは、ワークフローを記述するスキーマごとに、「コミット」、「アクティブ化」、「有効化」、「削除」、「無効化」および「非アクティブ化」の個別ステップを用意する必要があります。
ワークフロー・タイプにより、ワークフローの目的（ユーザーの作成など）が決定されます。ワークフロー・ステップは、ワークフローの個々のセグメントです。複数のステップが一連の順序で実行されます。ワークフロー・アクションは、ステップで実行されるアクティビティ（情報を要求するリクエストの発行など）です。
たとえば、ユーザーの作成ワークフロー・タイプでは、ユーザーのディレクトリ・エントリを作成できます。このタイプのワークフローには、ユーザー情報のリクエスト、情報の収集、リクエストの承認などに関するアクションが含まれます。
次の表に、様々なワークフロー・タイプと各アイデンティティ・システム・アプリケーションの関係を示します。
| アプリケーション | ワークフロー・タイプと説明 |
|---|---|
|
|
|
|
|
各ワークフローでは、最低2つのステップ（ワークフロー・インスタンスを開始するステップとそれを終了するステップ）を定義する必要があります。1つのステップは、次の要素で構成されます。
番号: このステップの一意の識別子。
ワークフローのすべてのステップには番号があります。
アクション: アクションは、アイデンティティ・システムまたは外部システムで実行されるアクティビティです。
ワークフローのすべてのステップはアクションを実行します。たとえば、ワークフローの開始、情報の提供、承認のリクエストなどのアクションがあります。詳細は、「ステップ・アクションの概要」を参照してください。
属性: 属性値は、ステップの一部として追加または変更できます。
たとえば、ユーザーの電話番号属性の値を変更するステップを定義できます。ステップ属性は、必須属性、オプション属性、または別のワークフロー・ステップの完了時に設定される属性のいずれかです。
アイデンティティ・システム内でローカルに使用する値の場合、ワークフローの一部としてLDAP属性を構成します。バックエンド・アプリケーションにプロビジョニングする場合、ワークフロー・ステップでLDAP属性とテンプレート属性の両方を構成します。
|
注意: ロケーションIDに「DN接頭辞」セマンティク型が含まれる場合、Active DirectoryおよびADAMでは、複数値のRDNが許可されないことに注意する必要があります（iPlanet/SunOneでは使用可能）。Active DirectoryおよびADAMでは、メタ属性構成で「属性値」の選択が「単一」になっていることを確認してください。 |
たとえば、ユーザーの作成ワークフローの場合、「開始」ステップを作成し、ユーザー・マネージャにログインしているユーザーが誰でも新規ユーザーの作成プロセスを開始できるようそのステップを構成できます。または、変更リクエストの承認を担当するワークフロー内の特定の参加者を定義できます。参加者は、ロール、名前、グループ・メンバーシップ、またはその他の特性に基づいて割り当てることが可能です。
LDAP属性の場合、DNに基づいて参加者を選択するLDAPフィルタを定義することもできます。
ワークフローのすべてのステップで参加者を必要としているわけではありません。たとえば、デフォルトのユーザーの作成ワークフローの「有効化」ステップでは参加者を必要としません。「承認」などの前のステップが終了すると、システムによりアクション（有効化）が自動的に実行されます。「コミット」および「外部アクション」ステップも参加者を使用しません。
ターゲット: 作成や削除などの対象となる個人、グループ、またはその他のLDAPオブジェクト。
ワークフロー定義のターゲットは、テンプレート・オブジェクトではなくLDAPオブジェクトです。
エントリ条件: 現在のステップの前に完了する必要のあるステップまたはサブフロー。
たとえば、ワークフローの最初のステップが「開始」ステップであるとします。このワークフローの2番目のステップには、「開始」ステップの正常な完了をエントリ条件に指定できます。一般的に、エントリ条件は、前のステップの正常な完了です。
通知: ステップ実行の前後に電子メール通知を受信するユーザー。
他の参加者は、電子メール通知が構成されているかどうかにかかわらず、着信リクエスト・キューの保留中のチケットを参照できます。詳細は、「ステップ・アクションの説明」を参照してください。
前処理と後処理: ワークフローの一環として実行される外部機能。
たとえば、ユーザーの作成ワークフローで、一意のログインIDを割り当てる開始ステップの後にJavaプログラムをコールできます。
図5-2は、ワークフロー・プロセスを示しています。
ワークフローのステップごとに1つのアクションを割り当てます。アクションは、ユーザーが実行するか、自動化された方法で実行します。
たとえば、ユーザーを作成するワークフローに必要なアクションは、次のとおりです。
リクエストの開始
ユーザーの有効化またはアクティブ化
使用可能なアクションは、ワークフロー・タイプと、前のステップに定義されているアクションに応じて異なります。たとえば、「開始」アクションは、ワークフローの最初のステップでのみ使用できます。
表5-3に、ユーザー・マネージャ・ワークフローのステップに関連付けることのできるアクションをリストします。
表5-3 ユーザー・マネージャ・ワークフローで使用可能なアクション
| ワークフロー・タイプ | アクション |
|---|---|
|
リクエスト（必須） 情報の提供 承認 情報と承認の提供 サブフロー承認 コミット（必須） 外部アクション エラー・レポート |
|
|
「開始」または「自己登録」（いずれかは必須） 情報の提供 情報と承認の提供 承認 サブフロー承認 コミット 「有効化」または「アクティブ化」（いずれかは必須） グループの選択 削除 エラー・レポート 外部アクション |
|
|
開始（必須） 情報の変更 「無効化」または「非アクティブ化」（いずれかは必須） 承認 サブフロー承認 承認の変更 コミット 削除 エラー・レポート 外部アクション |
|
|
開始 情報の変更 承認 情報と承認の変更 コミット 外部アクション エラー・レポート 非アクティブ化 無効化 削除 |
|
|
開始 情報の提供 承認 情報と承認の提供 サブフロー承認 コミット 外部アクション エラー・レポート アクティブ化 有効化 |
表5-4に、グループ・マネージャ・ワークフローで使用可能なアクションをリストします。
表5-4 グループ・マネージャ・ワークフローで使用可能なアクション
| ワークフロー・タイプ | アクション |
|---|---|
|
リクエスト（必須） 情報の提供 承認 情報と承認の提供 サブフロー承認 外部アクション コミット（必須） エラー・レポート |
|
|
開始（必須） 情報の提供 情報と承認の提供 承認 コミット（必須） サブフロー承認 削除 外部アクション エラー・レポート |
|
|
開始（必須） 情報の変更 承認の変更 サブフロー承認 承認 コミット（必須） 削除 エラー・レポート 外部アクション |
表5-5に、組織マネージャ・ワークフローのアクションをリストします。
表5-6に、ワークフローで使用可能なアクションを示します。
表5-6 ワークフロー・ステップのアクション
| アクション | 説明 |
|---|---|
|
アクティブ化 |
ユーザー・マネージャ専用。アイデンティティ・システムで新規ユーザーをアクティブ化します。アクティブなユーザーは、有効化されると、ログインして管理者に許可された操作を実行できます。ユーザー・エントリのobuseraccountcontrol属性により、アクティブ化と非アクティブ化のステータスが制御されます。「アクティブ化」アクションでは、マネージャなどの参加者がユーザーをアクティブ化する必要があります。 |
|
承認 |
このアクションは、必須属性で構成できます。必須属性の値は、実行時に承認担当の参加者に提供されます。このアクションで変更される情報はありません。 |
|
情報と承認の変更 |
「情報と承認の提供」アクションと同じ機能を実行しますが、ユーザーを非アクティブ化する場合にのみ使用します。 |
|
情報の変更 |
「情報の提供」アクションと同じ機能を実行しますが、ユーザーを非アクティブ化する場合にのみ使用します。 |
|
コミット |
前のステップで収集された情報をディレクトリに書き込みます。コミット操作により、ディレクトリ内のオブジェクトの場所に情報が書き込まれます。たとえば、作成操作では、「コミット」アクションによってディレクトリに新規エントリが追加されます。ワークフローに追加の「コミット」アクションが含まれる場合、その情報は新しく作成されたオブジェクトを含むディレクトリ内の場所に書き込まれます。「コミット」アクションは、ワークフロー内で2回以上使用できます。ユーザー・アクションは必要ありません。 |
|
非アクティブ化 |
ユーザー・マネージャ専用。非アクティブ化の効果は、ユーザーの現行セッションが終了した後に反映されます。非アクティブなユーザーは、ログインできません。他のユーザーは、非アクティブなユーザーを検索対象とする場合を除き、アイデンティティ・システムで非アクティブなユーザーを検索できません。非アクティブ化では、ディレクトリのユーザーは削除されません。ユーザー・エントリのobuseraccountcontrol属性により、アクティブ化と非アクティブ化のステータスが制御されます。ワークフローの非アクティブ化ステップには、参加者が必要です。 注意: 削除ユーザーを含む.ldifを作成する場合、「削除」のかわりに「非アクティブ化」または「無効化」ワークフロー・ステップを使用してください。「非アクティブなユーザー・アイデンティティ」ページに移動し、「アーカイブ」オプションを使用します。これにより、ディレクトリからユーザーが削除され、次の場所にdeactivateduser.ldifが作成されます。 IdentityServer_install_dir\oblix\data\common directory |
|
削除 |
ユーザーの作成、グループの作成またはオブジェクトの作成ワークフローで「削除」アクションを使用すると、ターゲット・エントリがディレクトリから永久に削除されます。ターゲット・エントリの作成後に、作成ワークフローが中断される場合があります。「削除」ステップによりディレクトリを消去することで、同じユーザーを作成する新しい操作を試行できます。 |
|
無効化 |
ユーザー・マネージャ専用。ユーザーを非アクティブ化します。これにより、ユーザーの現行セッションが終了すると、そのユーザーはアイデンティティ・システムから認識されなくなります。非アクティブ化の効果は、ユーザーによる次回のログイン試行時に適用されます。非アクティブ化では、オブジェクトはディレクトリから削除されません。このアクションには、参加者は必要ありません。 |
|
有効化 |
ユーザー・マネージャ専用。「有効化」アクションは、「コミット」および「アクティブ化」アクションの組合せです。新規ユーザーを自動的にアクティブ化します。アクティブなユーザーは、前のステップの完了後にアイデンティティ・システムで認識されます。このアクションには、ユーザーをアクティブ化する参加者は必要ありません。 |
|
エラー・レポート |
バックグラウンド・プロセスで処理エラーが発生した場合に、特定のユーザーにエラーを送信するようエラー・レポートを構成できます。ステップが否認される場合（承認プロセスの実行時など）にもエラー・レポートを構成できます。 |
|
外部アクション |
Oracle Access Managerの外部で実行されるアクション。 |
|
開始 |
作成および非アクティブ化ワークフローを開始します。このアクションは、ワークフロー内で1回のみ使用できます。このアクションは、最初のアクションである必要があります。自己登録アクションも、ワークフローの開始アクションに指定できます。特定のワークフローの参加者として定義されているかどうかにかかわらず、すべてのユーザーのページに「プロファイルの作成」ボタンまたは「ユーザーの非アクティブ化の開始」オプションが表示されます。ワークフローの参加者として定義されていないユーザーがワークフローのボタンまたはリンクをクリックすると、エラー・メッセージが表示されます。 |
|
情報と承認の提供 |
「情報の提供」アクションと「承認」アクションを1つのアクションにまとめたものです。 |
|
情報の提供 |
ユーザーから情報を収集します。このアクションは、「開始」と似ていますが、ワークフローの最初のアクションには指定できません。 |
|
リクエスト |
属性の変更、追加または削除を求めるユーザーのリクエスト。このアクションの参加者には、「プロファイルの変更」ページに「変更をリクエスト」または「削除をリクエスト」ボタンが表示されます。 |
|
自己登録 |
ユーザーは、登録フォームを完成して送信できます。他の参加者は、リクエストを承認してユーザーをアクティブ化します。このアクションは、ワークフロー内の最初のステップである必要があります。自己登録アクションでは、必ずしも他の参加者が新規ユーザーを承認およびアクティブ化する必要はありません。 |
|
グループの選択 |
ワークフローの参加者は、ユーザーの作成ワークフローの実行中に、1つ以上のグループにターゲット・ユーザーをサブスクライブできます。新規ユーザーは、サブスクリプション・ポリシーを満たしている必要があります。「有効化」または「アクティブ化」ステップの後にのみ使用できます。 |
|
サブフロー承認 |
メイン・ワークフロー・ステップから起動されたサブフローの現在のステータスをレポートします。他のサブフローから起動されたサブフローには適用されません。 |
自己登録では、ターゲットがまだ作成されていないため、これらの値はglobalparams.xmlを通じて提供されます。この場合、globalparmams.xmlでこれらのパラメータを見つけ、現在の環境に応じてその値を変更する必要があります。たとえば、次のようになります。
IdentityServer_install_dir/apps/common/bin/globalparams.xml
<SimpleList> <NameValPair ParamName="sendMailFromName" Value="SelfRegistration"> </NameValPair> </SimpleList> <SimpleList> <NameValPair ParamName="sendMailFromEmail" Value="SelfRegistration@Oracle.com"> </NameValPair> </SimpleList>
ターゲット・ユーザーが作成されている場合は、電子メールが特定の参加者に送信されます。この電子メールでは、送信者の名前および電子メールがログイン・ユーザーのプロファイル（名前属性と電子メール属性）から特定されます。これらの属性が空の場合は、パラメータsendMailFromNameおよびsendMailFromEmailを使用して、送信者の名前および電子メールがそれぞれ特定されます。
アイデンティティ・サーバーのglobalparams.xmlに含まれるUseDefaultOptionsForAllMailsパラメータを使用して、すべての電子メール通知の送信に使用する電子メールIDを構成します。次に例を示します。
ParamName="UseDefaultOptionsForAllMails" Value="true"
この場合、アイデンティティ・サーバーから送信されたすべての電子メールで次の処理が行われます。
送信者名フィールドの値は、globalparams.xmlファイルで定義されているsendMailFromNameパラメータから取得されます。
送信者の電子メールフィールドの値は、globalparams.xmlファイルで定義されているsendMailFromEmailパラメータから取得されます。
存在し、trueの場合: UseDefaultOptionsForAllMailsが存在し、trueに設定されているがglobalparams.xmlファイルで値が定義されていない場合は、次の条件が適用されます。
sendMailFromNameが定義されていない場合: 送信者名フィールドにsendMailFromEmailパラメータの値を使用して、電子メールが送信されます。
sendMailFromEmailが定義されていない場合: UseDefaultOptionsForAllMailsがtrueでsendMailFromEmailが定義されていない場合、電子メールは送信されません。かわりに、適切なメッセージがユーザーに送信され、通知用電子メールを送信できなかったことを示すエラーが記録されます。
存在せず、falseの場合: UseDefaultOptionsForAllMailsパラメータが存在しない場合、または存在するが次のように値がfalseに設定されている場合は、以前の動作が実行されます。『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ParamName="UseDefaultOptionsForAllMails" Value="false"
UseDefaultOptionsForAllMailsパラメータを追加する手順
アイデンティティ・サーバーのglobalparams.xmlファイルを探します。次に例を示します。
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
10g（10.1.4.3）の動作を使用する場合: UseDefaultOptionsForAllMailsパラメータに値trueを指定して、sendMailNotificationEnabledパラメータの上に追加します（すでにある場合を除く）。次に例を示します。
<SimpleList> <NameValPair ParamName="UseDefaultOptionsForAllMails" Value="true" /> </SimpleList>
以前の動作をリストアする場合: UseDefaultOptionsForAllMailsパラメータの値をfalseに設定します。次に例を示します。
<SimpleList> <NameValPair ParamName="UseDefaultOptionsForAllMails" Value="false" /> </SimpleList>
デプロイ内のアイデンティティ・サーバーごとに、手順を繰り返します。
単純なワークフローの場合、すべてのステップは順番に実行されます。1つのステップが保留中の状態になると、ワークフローは次のステップに進めません。ワークフローには様々な参加者が関与するのが一般的であるため、ワークフローの完了が遅れる可能性があります。ワークフローの処理を迅速化するには、パラレルに発生するサブフローを定義します。サブフローにより、ワークフローは複数の作業部分に分割されます。サブフローでは、独自のサブフローを起動できます。1つのワークフローから複数のサブフローを起動できます。
|
注意: サブフローは、常に属性の変更ワークフローです。 |
採用担当マネージャがユーザーの作成ワークフローを開始します。
従業員番号とバッジ番号を求めるリクエストがファシリティ部門に送信されます。
ログインIDとパスワードを求めるリクエストがIT部門に送信されます。
最終承認とユーザーのアクティブ化を求めるリクエストが採用担当マネージャに送信されます。
サブフローの使用により、一部のリクエストをパラレルに実行できます。図5-3は、サブフローが完了するまで承認を待機するワークフローを示しています。
ワークフローは、サブフローが完了するまで次のステップに進みません。
|
注意: サブフローを起動する場合、ターゲット・オブジェクトまたは属性は、「ワークフロー・ドメイン」フィルタの指定によるフィルタ基準を満たしている必要があります。 |
マスター管理者は、クイックスタート・ツールを使用してデフォルト設定に基づく単純なワークフローを迅速に作成できます。
クイックスタートを使用してワークフロー定義を作成したら、ワークフロー・ツールを使用してそのワークフロー定義を変更できます。たとえば、動的参加者やサロゲートを指定できます。クイックスタート・ツールでは、次のワークフローを定義できます。
表5-7 クイックスタート・ツールで作成できるワークフロー
| ワークフロー名 . . | 含まれるステップ . . |
|---|---|
|
ユーザー、グループまたはオブジェクトの作成（基本） |
「自己登録」または「開始」 コミット エラー・レポート 注意: 単純なユーザーの作成ワークフローの場合、必須属性はほとんどのディレクトリ・サーバーで姓と名です（Active Directoryの場合はログインID）。 |
|
ユーザー、グループまたはオブジェクトの作成（拡張: 承認あり） |
開始 承認 コミット エラー・レポート |
|
ユーザーまたはオブジェクトの自己登録（拡張: 承認あり） |
自己登録 承認 コミット エラー・レポート |
|
属性の変更（基本） |
リクエスト コミット エラー・レポート |
|
属性の変更（拡張: 承認あり） |
リクエスト 承認 コミット エラー・レポート |
クイックスタート・ツールでは、アイデンティティ・システムにログインしているすべてのユーザーが、ほとんどのステップに参加者として割り当てられます。ユーザー・マネージャでは、属性の変更ワークフローの参加者は、「マネージャ」ロールが割り当てられている任意のユーザーです。グループ・マネージャでは、属性の変更ワークフローの「承認」ステップの参加者は、「グループの所有者」ロールが割り当てられている任意のユーザーです。
クイックスタート・ツールを使用してワークフローを作成すると、ワークフローのステップ、参加者、関連属性などを参照および変更できます。ワークフロー定義の参照方法の詳細は、「ワークフロー・サマリーの表示とエクスポート」を参照してください。ワークフローの変更方法の詳細は、「ワークフローの変更」を参照してください。
|
注意: ワークフローを定義できるかどうかは、保持している管理権限に応じて変化します。 |
クイックスタート・ツールを使用してワークフローを定義する手順
アイデンティティ・システム・コンソールで、「ユーザー・マネージャ」、「グループ・マネージャ」または「組織マネージャ」を選択します。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
デフォルトでは、構成情報を参照できる権限を保持するのは、マスター管理者、マスター・アイデンティティ管理者および委任アイデンティティ管理者のみです。
「ここをクリック」というリンクをクリックします。
これにより、クイックスタート・ツールが起動します。
作成するワークフロー・タイプを選択します。
|
注意: 同じクイックスタート・ページで作成ワークフローと属性の変更ワークフローを定義できます。「属性の変更」フィールドとオプションを表示するには、ページの一番下までスクロールします。 |
ワークフローの名前も指定できます。デフォルト名が提供されますが、クイックスタート・ツールを使用してこのタイプのワークフローを複数作成する場合、その名前は変化しません。
作成ワークフロー・タイプを選択する場合、ワークフローにより作成されるオブジェクトに対して1つのターゲット・ロケーションを指定できます。
デフォルトのターゲット・ロケーションは、アイデンティティ・システムの検索ベースです。
オプションで、追加属性を選択できます。
ユーザーの作成、グループの作成またはオブジェクトの作成ワークフローの場合、これらの属性は開始ステップまたは自己登録ステップの実行時に入力されます。
属性の変更ワークフローの場合、これらの属性はワークフローの実行時に変更されます。選択した属性ごとに個別のワークフローが作成されます。たとえば、5つの属性を選択すると、クイックスタート・ツールによって5つの属性の変更ワークフローが生成されます。
「生成」をクリックします。
クイックスタート・ツールにより生成されるサマリー・レポートを確認します。
ワークフローをテストするには、サマリー・レポートのいずれかのワークフロー・リンクをクリックします。
これにより、ワークフロー・インスタンスが開始されます。ワークフローを使用するプロセスの詳細は、「アイデンティティ・システム・アプリケーションでユーザーがワークフローにアクセスする方法」を参照してください。
|
注意: ワークフローをPortal Insertsとして使用するには、出力されたURLをブラウザからコピーします。Portal Insertsの作成方法の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。 |
「完了」をクリックします。
Webポータルにユーザー登録ページを提供する場合、自己登録ワークフローを定義し、そのワークフローに対して出力されたURLを取得できます。このURLは、Portal Insertsとして使用できます。
クイックスタート・ツールを使用して自己登録ワークフローを定義する手順
自己登録ワークフローを作成します（「クイックスタート・ツールを使用してワークフローを定義する手順」を参照してください）。
「生成」ボタンをクリックし、次に新しく作成されたワークフローのリンクをクリックします。
新規ワークフローが表示されたら、そのURLをコピーします。
このURLは、Webポータルにユーザー登録ページを設定する際に使用できます。このURLは、ワークフローの最初のページへのリンクです。自己登録ワークフローを定義するその他の方法は、「自己登録ワークフローの作成」を参照してください。
クイックスタート・ツールを使用する以外に、複数のオプションとサブフローを指定できる構成ページを使用してワークフローを定義できます。
この場合、ワークフローを定義する権限を保持している必要があります。詳細は、「管理の委任について」を参照してください。
通常、ワークフローには、最低2つのステップ（ワークフローを開始するステップと変更をコミットするステップ）が含まれます。
タスクの概要: ワークフロー・アプレットを使用したワークフローの定義
「ワークフロー定義」アプレットを起動します。
詳細は、「「ワークフロー定義」アプレットへのアクセス」を参照してください。
「新規」を選択して新規ワークフロー定義の作成を開始します。
詳細は、「新規ワークフロー定義の開始」を参照してください。
作成ワークフロー・タイプを選択した場合、ワークフロー・ターゲットを指定します。
ターゲットは、オブジェクトの作成先となるディレクトリ・ツリー内の場所です。詳細は、「オブジェクトの作成ワークフローのLDAPターゲットの定義」を参照してください。
ワークフロー・ステップとアクションを定義します。
各ワークフロー・ステップには、アクションが含まれます。アクションは、ユーザーが実行するか、自動化された方法で実行します。ワークフローのステップごとに1つのアクションを割り当てます。各ステップには、参加者も割り当てます。詳細は、「ワークフローの最初のステップの定義」を参照してください。
属性をステップに関連付けます。
ステップ・アクションは、1つ以上の属性値を対象に実行されます。これらの属性は、ディレクトリから取得されるか、オブジェクト・テンプレートから取得されます。詳細は、「ステップ属性の定義」を参照してください。
後続のステップのエントリ条件を定義します。
詳細は、「後続のステップの定義」を参照してください。
後続のステップを定義します。
1つ以上のサブフローを定義します。
サブフローは、特定のステップまたはワークフローを完了するために満たす必要のある条件です。メイン・ワークフロー・ステップと同様に、サブフローにはアクション、参加者および属性が関連付けられます。詳細は、「サブフローの定義」を参照してください。
ワークフローを終了する1つ以上のコミット・ステップを定義します。
複数のスキーマ（たとえば、LDAPスキーマとテンプレート・スキーマ）を使用してワークフローを構成する場合、スキーマ・タイプごとに個別のコミット・ステップを構成する必要があります。
アイデンティティ・システム・コンソールで、「ユーザー・マネージャ」、「グループ・マネージャ」または「組織マネージャ」を選択します。
組織マネージャに複数のタブがある場合は、適切なタブを選択してください。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
一部のブラウザでは、アプリケーションの証明書を信頼するかどうかを尋ねるプロンプトが表示されることがあります。このプロンプトが表示された場合は、「常に信頼」オプションを選択してください。
ユーザー・マネージャおよび組織マネージャの場合、「ワークフロー定義」ページが表示されます。
グループ・マネージャを使用している場合、必要に応じて適切なグループ・タイプを指定します。使用可能なグループ・タイプは、実際の構成に応じて異なります（「「グループ・マネージャ」タブへの補助オブジェクト・クラスおよびテンプレート・オブジェクト・クラスの追加」を参照してください）。
グループ・マネージャを使用している場合、「ワークフロー定義」ページで必要に応じて適切なグループ・タイプを選択し、「次へ」をクリックします。
グループ・タイプを選択しない場合、このワークフローでは「Basic」グループ・タイプが使用されます。
ワークフロー定義は、ユーザー・セットごとに作成できます。たとえば、エンジニアリング部門と営業部門で異なるユーザーの作成ワークフローを定義できます。
単純なユーザーの作成ワークフローの場合、必須属性はほとんどのディレクトリ・サーバーで姓と名です（Active Directoryの場合はログインID）。
|
注意: デフォルトでは、ディレクトリ内のすべてのオブジェクトおよび属性はアイデンティティ・システムで表示されません。Identity_install_dir/apps/common/bin/globalparams.xmlにあるこのパラメータexcludeOCsForTreeInAppletを使用すると、アイデンティティ・システム・アプリケーションのオブジェクト・クラスを表示できます。使用しない場合は、表示されません。
詳細は、『Oracle Access Managerカスタマイズ・ガイド』の「パラメータ・リファレンス」の章を参照してください。 |
「ワークフロー・アプレットの使用方法」の手順に従ってワークフロー定義ツールを起動します。
「新規」をクリックし、「新規」ボタン以外のすべてのボタンが非アクティブ化されるまで待機します。
「ワークフロー名」フィールドにワークフローの名前を入力します。
「ワークフロー・タイプ」リストで、作成するワークフローのタイプを選択します。
ワークフロー・タイプの詳細は、「ワークフローのタイプ、ステップおよびアクション」を参照してください。
サブフローを作成する場合は、「サブフローの定義」を参照してください。
「説明」フィールドに、オプションでこのワークフローの説明を入力できます。
「ワークフロー・ドメイン」フィールドで、このワークフローを使用可能にするディレクトリ・ツリー内の開始ポイントを選択します。
ワークフロー・ドメインを、ワークフローを開始したログイン・ユーザーのディレクトリ・エントリと一致させる場合は、置換構文を使用します。たとえば、ワークフロー・ドメインのouを、ワークフローを生成したユーザーのouと常に一致させる場合、次のように入力します。
(ou=$ou$)
使用例は、「置換構文: ログイン・ユーザーのDNに一致するターゲットを戻す方法」を参照してください。
|
注意: ワークフロー作成時にワークフロー・ドメイン（またはターゲット・ドメイン）のフィルタを指定する場合、完全なLDAP URLは使用しないでください。LDAPフィルタのみを使用できます。 |
ワークフローを使用可能にする特定のドメインを選択することも可能です。たとえば、ディレクトリ・ツリー内にEngineeringとSalesという異なるブランチがあり、このワークフローをEngineeringにのみ適用する場合、ディレクトリ・ツリーのEngineeringブランチの最上位ノードを選択します。ディレクトリ・ツリーが特にフラットな形状の場合、またはツリーに特に大量のブランチが存在する場合、LDAPフィルタを入力してワークフロー・ドメインを絞り込むことができます。「ルールとフィルタの使用方法」を参照してください。たとえば、ディレクトリ・ツリーの開始ポイントがou=peopleで、管理者のみを対象とするワークフローを作成する場合、(title=admin)を含むフィルタを作成できます。
|
注意: フィルタを使用する場合は、必ずパフォーマンス・テストを実行してください。フィルタは実行時に評価されるため、パフォーマンスに影響する可能性があります。 |
ユーザー・マネージャまたは組織マネージャを使用している場合、「次へ」をクリックします。
ワークフロー・タイプによっては、ターゲットを選択するよう求められるか（「オブジェクトの作成ワークフローのLDAPターゲットの定義」を参照）、ワークフローの最初のステップを定義するよう求められます（「ワークフローの最初のステップの定義」を参照）。
グループ・マネージャを使用しており、拡張グループを操作している場合、必要に応じてサブスクリプション・タイプを指定します。
たとえば、グループを選択するステップや、ユーザーがグループに自分自身を追加するステップを定義する場合にこの操作が発生する可能性があります。oblixAdvancedGroupオブジェクト・クラスでobGroupSubscriptionType属性が構成されている場合、参加者は「サブスクリプション・タイプ」オプションを使用できます。
使用可能なサブスクリプション・タイプは、次のとおりです。
表5-8 ワークフローのサブスクリプション・タイプ
| オプション | 説明 |
|---|---|
|
タイプが選択されていません |
サブスクリプション・タイプが定義されていません。機能的には「オープン」ポリシーと同等です。 |
|
オープン |
登録は、サブスクライブするすべてのユーザーに許可されます。 |
|
フィルタでオープン |
登録は、グループの動的フィルタ（LDAPルール）を満たすすべてのユーザーに許可されます。 |
|
ワークフロー経由で制御 |
サブスクライブまたはサブスクライブ解除するには、ユーザーがワークフローの「グループの選択」ステップのターゲットである必要があります。 |
|
クローズ済 |
メンバー・リストはクローズされています。変更は許可されません。default_subscriptionポリシー・パラメータのデフォルト設定は、SubscriptionPolicyClosedです。このパラメータは次の場所にあります。 IdentityServer_install_dir/identity/oblix/data/common/groupdbparams.xml ここで、IdentityServer_install_dirは、アイデンティティ・システムがインストールされているディレクトリです。 |
「追加」をクリックし、「次へ」をクリックします。
ワークフロー・タイプによっては、ターゲットを選択するよう求められるか（「オブジェクトの作成ワークフローのLDAPターゲットの定義」を参照）、最初のステップを定義するよう求められます（「ワークフローの最初のステップの定義」を参照）。
定義するワークフロー・タイプとして「作成」を選択する場合（「ユーザーの作成」など）、1つ以上のターゲットを定義する必要があります。ターゲットは、オブジェクトの作成先となるディレクトリ・ツリー内の場所です。たとえば、ou=bestmotors,o=company,c=usというターゲットでは、ou=bestmotorsコンテナの下にオブジェクトが作成されます。ワークフローでこのターゲットを使用してユーザーを作成すると、そのディレクトリ・エントリは、cn=John Smith,ou=bestmotors,o=company,c=usのようになります。
ワークフロー・ターゲットを定義する場合、置換構文も使用できます。これにより、ユーザーの作成ワークフローの新規ユーザーのouエントリを、ワークフローを開始したログイン・ユーザーのouエントリと常に一致させることができます。使用例は、「置換構文: ログイン・ユーザーのDNに一致するターゲットを戻す方法」を参照してください。置換構文を使用する場合、必要に応じてglobalparams.xmlのResourceFilterSearchScopeパラメータの値を変更する必要があります。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
ログイン・ユーザーのouエントリに複数の値が含まれており、それらのいずれかのouの下に新規ユーザーを作成する場合、globalparams.xmlのResourceFilterSearchScopeパラメータの値を2に変更する必要があります。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。この場合、ワークフローの実行時に使用可能なすべてのターゲットのリストが表示されます。ユーザーは、新規ターゲット・ユーザーを作成する正確なouの場所を選択できます。リスト内のターゲットは、ログイン・ユーザーのou属性の複数の値から取得されます。このリストは、(ou=$ou$)とともに(objectclass=organizationalUnit)などの他のフィルタ・コンポーネントを使用して制限することが可能です。
複数のターゲットを定義すると、参加者にはワークフローの実行時に選択リストが表示されます。ワークフロー・ターゲットは、常にLDAPディレクトリ・ツリーに基づきます。テンプレート・スキーマに基づくターゲットは使用できません。
別のタイプのワークフローを定義している場合、最初のワークフロー定義ページで「次へ」をクリックし、「ワークフローの最初のステップの定義」に記載されているステップ定義ページに移動します。
まだ開始していない場合、「新規ワークフロー定義を開始する手順」に従って新規ワークフロー定義を開始します。
最初の「ワークフロー定義」ページで「次へ」をクリックします。
ターゲットの特性を選択するためのフィールドを含むターゲット・ページが表示されます。
新規ターゲットを定義するため、「ターゲット名」フィールドに名前を入力します。
たとえば、販売代理店のターゲットを作成する場合、ターゲット名は「代理店名」などとします。
「ターゲット・ドメイン」フィールドで、オブジェクトを作成するディレクトリ・ツリー内の場所を選択し、「追加」をクリックしてターゲット・ドメインを「ターゲット」フィールドに追加します。
ワークフロー・ドメインを定義すると、ワークフローが適用されるディレクトリ・ツリーのブランチが選択されます。ターゲット・ドメインは、メイン・ワークフロー・ドメインのサブセットです。フィルタを使用すると、より厳密にターゲットの場所（ツリー内で選択したノードの下に含まれる任意のユーザー・オブジェクト）を指定できます。
|
注意: ワークフロー作成時にターゲット・ドメイン（またはワークフロー・ドメイン）を指定する場合、完全なLDAP URLは使用しないでください。LDAPフィルタのみを使用できます。たとえば、ldap:///ou=Partners,o=Company,c=US??sub?(cn=Shutterbug Canavan)ではなく、cn=Shutterbug Canavanとするのが適切です。 |
詳細は、「ルールとフィルタの使用方法」を参照してください。
|
注意: ワークフロー・ドメインにフィルタを追加した場合、ターゲットのフィルタを指定することはできません。 |
「追加」をクリックします。
追加ターゲットにワークフローを適用するには、次の操作を実行します。
「新規」をクリックします。
別の名前とドメインを指定します。
「追加」をクリックします。
ターゲット・ドメインの指定が完了したら、「次へ」をクリックします。
ワークフローの名前を指定し、必要に応じてターゲットを定義した後、最初のワークフロー・ステップを作成するよう求められます。次のようなページが表示されます。
|
注意: ステップ定義ページで、すべてのタブが使用できるわけではありません。これは、特定の場合に適用されないタブがあるためです。たとえば、デフォルトのユーザーの作成ワークフローでは、「外出中」タブは、「外出中」通知が不要の場合は「開始」ステップ中は使用できません。また自動的に実行されて参加者を伴わない「有効化」ステップ中にも使用できません。UseDefaultOptionsForAllMailsの詳細は、「ステップ・アクションの説明」を参照してください。 |
まだ開始していない場合、「新規ワークフロー定義を開始する手順」に従って新規ワークフロー定義を開始します。
（作成ワークフロー・タイプで）まだ定義していない場合、「ワークフロー・ターゲットを定義する手順」に従ってターゲットを定義します。
「実行するアクションの選択*」リストで、アクションを選択します。
ユーザー・マネージャまたは組織マネージャのオブジェクトの作成ワークフローでは、「開始」および「自己登録」アクションを選択できます。
グループ・マネージャのオブジェクトの作成ワークフローでは、「開始」アクションを選択できます。
「参加者」をクリックします。
ほとんどのステップで、アクションを実行する参加者が必要です。この例外は、「コミット」や「有効化」などの自動的に発生するアクションを含むステップと、「外部アクション」および「自己登録」アクションを含むステップです。
参加者を必要としないなステップでは、「外出中」タブは使用できません。
次のいずれかの方法を使用して参加者を指定します。
ロール: 「すべてのユーザー」というロールは、アイデンティティ・システムにログインしているすべてのユーザーを示します。
ロールは、ワークフロー・パラメータ・ファイルのgsc_wf_param.xml、usc_wf_param.xmlおよびosc_wf_param.xmlで定義します。詳細は、「ワークフローのデータおよびアクションのカスタマイズ」を参照してください。
|
注意: 「参加者の選択*」フィールドで「事前通知する参加者の選択」を選択した場合、ロールとして「次のステップの参加者」を選択しないでください。また、グループ・マネージャ・ワークフローのコミット・ステップでは、事後通知する所有者やメンバーを選択しないでください。選択しても、所有者やメンバーに電子メール通知は実行されません。UseDefaultOptionsForAllMailsの詳細は、「ステップ・アクションの説明」を参照してください。 |
参加者ロール（ステップを処理できるユーザーのロール）は、コミット、有効化またはアクティブ化ステップが完了した後にのみ機能します。コミット、有効化またはアクティブ化ステップにより、通知情報の決定に使用されるオブジェクトのDNが作成されます。
人の選択: セレクタの使用方法の詳細は、「検索機能」を参照してください。セレクタの構成方法の詳細は、「「オブジェクト・セレクタ」表示タイプの検索フィルタ」を参照してください。
グループの選択: セレクタの使用方法の詳細は、「検索機能」を参照してください。セレクタの構成方法の詳細は、「「オブジェクト・セレクタ」表示タイプの検索フィルタ」を参照してください。
フィルタの作成: LDAPフィルタの作成方法の詳細は、「クエリー・ビルダーを使用したLDAPフィルタの記述」を参照してください。
「ステップの保存」または「ワークフローの保存」をクリックするか、次の項の手順に従ってステップ属性を選択します。
ステップ・アクションは、1つ以上の属性値を対象に実行されます。ステップ・アクションを構成する場合、特定の属性値を必要とするかどうかと、他の構成オプションを指定します。たとえば、「情報の提供」アクションでは、電子メール属性を指定して、ステップ参加者に電子メール・アドレスの入力を促すことができます。
ステップ属性の定義には、次の手順が含まれます。
ワークフローの特定のステップで使用可能にする属性の選択。
属性プロパティの構成。
オブジェクト・テンプレート（.tplファイル）に基づく属性では、アイデンティティ・システム・コンソールで属性を構成するときに、属性の含まれるスキーマのタイプが表示されると役立つ可能性があります。たとえば、新規ユーザーの電子メール・アカウントを設定するアプリケーションに情報を送信するワークフローの場合、属性ラベルの前にアプリケーション名を配置できます。これは、ユーザーがこの属性を参照する場合に役立ちます。プロビジョニング属性では、データ・フローが一方向であるため、ユーザーによる値の送信後はアイデンティティ・システムのプロファイル・ページに属性値が表示されません。ユーザーからこれに関する質問があったときに、属性ラベルがあるとその現象が通常どおりの動作であるかどうかを決定するのに役立ちます。詳細は、「属性の構成」を参照してください。
まだ開始していない場合、「新規ワークフロー定義を開始する手順」に従って新規ワークフロー定義を開始します。
（作成ワークフロー・タイプで）まだ定義していない場合、「ワークフロー・ターゲットを定義する手順」に従ってターゲットを定義します。
「ワークフローの最初のステップを定義する手順」に従ってワークフロー・ステップの定義を開始します。
ワークフロー・ステップの参加者を選択してから、「属性」をクリックします。
「使用可能な属性」パネルで、ワークフロー・ステップに関連付ける1つ以上の属性を選択します。
属性の変更ワークフローの場合、選択した一番上の属性がプロファイル・ページのパネルに追加されていることを確認します。これにより、適切なプロファイル・ページに「変更をリクエスト」ボタンが表示され、ユーザーはこのワークフローのインスタンスを実行できます。
複数を選択する場合の詳細は、「複数の属性を選択するためのキー」を参照してください。
右矢印ボタン（>>）をクリックし、選択した属性を「選択された属性」パネルに追加します。
オブジェクトの作成ワークフローのデフォルトでは、相対識別名（RDN）を定義する属性が「選択された属性」パネルに表示されます。
属性の変更ワークフローのデフォルトでは、ワークフローの基礎として選択した属性が「選択された属性」パネルに表示されます。
ステップを保存するか、必要に応じて次の項の手順に従って属性プロパティを構成します。
|
注意: ワークフローのすべての必須属性（オブジェクト・クラス・スキーマの定義に基づく）が構成されるまで、ワークフローは保存できません。 |
「選択された属性」パネルで、構成する1つ以上の属性を選択します。
複数を選択する場合の詳細は、「複数の属性を選択するためのキー」を参照してください。
「プロパティ」をクリックします。
次のような「属性プロパティ」ダイアログが表示されます。
属性の1つ以上のプロパティを選択します。
必須: ワークフロー参加者は、この属性の値を指定する必要があります。
|
注意: 必須属性は、非表示または読取り専用にすることはできません。 |
オプション: ワークフロー参加者は、この属性の値を指定できます。
読取り専用: ワークフロー参加者は、この属性を参照できますが変更できません。
非表示: ワークフロー参加者は、この属性の値を参照できません。属性は、アイデンティティ・イベント・プラグインAPIとIdentityXMLで使用可能です。
デフォルト値: テキスト文字列を表示します。このテキスト文字列には、参加者にとって役立つ情報を指定します。たとえば、電話番号を入力する際の正しい書式を示す文字列をphoneNumber属性のデフォルト値に指定できます。値は、テキスト表示タイプに制限されます。
「OK」をクリックします。
「ステップの保存」または「ワークフローの保存」をクリックします。
この時点で、メール通知参加者を定義するか、このワークフローの追加ステップを定義することが可能です。
|
注意: メール通知参加者を定義する際に、「参加者の選択*」フィールドで「事前通知する参加者の選択」を選択した場合、ロールとして「次のステップの参加者」を選択しないでください。また、グループ・マネージャ・ワークフローのコミット・ステップでは、事後通知する所有者やメンバーを選択しないでください。選択しても、所有者やメンバーに電子メール通知は実行されません。UseDefaultOptionsForAllMailsの詳細は、「ステップ・アクションの説明」を参照してください。 |
事前通知または事後通知が機能するには、選択されたロールを対象にコミット、有効化またはアクティブ化ステップが完了している必要があります。コミット、有効化またはアクティブ化ステップの完了前には、オブジェクトはディレクトリ・ツリーのワークフロー・インスタンス情報内にのみ存在します。コミット、有効化またはアクティブ化ステップにより、通知情報の決定に使用されるオブジェクトのDNが作成されます。
|
注意: 電子メール通知のカスタマイズの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。UseDefaultOptionsForAllMailsの詳細は、「ステップ・アクションの説明」を参照してください。 |
ワークフローには、少なくとも開始ステップと完了ステップが含まれますが、状況により追加のステップとサブフローも含まれます。ワークフロー内に2番目の（または3番目の、あるいはそれ以上の）ステップを作成する手順では、そのステップのエントリ条件を定義します。エントリ条件は、次の要素で構成されます。
このステップに先行するステップの識別。
前のステップの必須出力結果の識別。
「ワークフローの最初のステップを定義する手順」に従ってワークフローの最初のステップを完成したら、「定義済ステップ」領域で「新規」をクリックします。
このページに、ワークフローの後続のステップを構成するための新規フィールドが表示されます。
「前のステップ」リストで、このアクションに先行するステップを選択します。
「戻り値」リストで、前のステップでtrueまたはfalseのどちらの値が戻されたときにこのアクションを実行するかを指定します。
前のステップが正常に完了した場合、trueの値が戻されます。「False」を選択すると、前のステップがfalseの値を戻したときにエラー・レポートが生成されます。falseの値が戻される場合は、次のとおりです。
参加者がワークフロー・チケットを否認した場合
コミット・ステップに失敗した場合
アイデンティティ・イベント・プラグインAPIまたはIdentityXMLにより、強制的にfalseの値が戻される場合
戻り値にかかわらず、前のステップのすべてのサブフローが完了するまでこのアクションの実行を遅延する場合、「サブフローを待機」を選択します。
このチェック・ボックスを選択すると、戻り値のエントリ条件に:trueが追加されます。このチェック・ボックスを選択しない場合、戻り値のエントリ条件に:falseが追加されます。詳細は、「サブフローの定義」を参照してください。
「追加」をクリックしてワークフロー定義のエントリ条件を追加します。
エントリ条件が「選択した値」フィールドに表示されます。
このフィールドの最初のエントリは、現行のステップに先行するステップの番号に対応した番号です。
このフィールドの2番目のエントリは、TrueまたはFalseの値です。このエントリは、前のステップが正常に終了した場合、現行のステップを実行する（True）かどうかを表します。
このフィールドの最後のエントリも、TrueまたはFalseの値です。このエントリは、このステップの実行前に、サブフローが終了するまで待機するかどうかを表します。Trueの場合、サブフローが終了するまで待機します。
「アクション」リストでアクションを選択します。有効化、アクティブ化、およびその他のアクションを選択できます。
使用可能なアクションは、前のステップのアクションに応じて異なります。たとえば、次のようになります。
「情報の提供」は、「開始」に先行することはできません。
通常、エラー・レポート・アクションは、ステップが失敗した理由を提供します。たとえば、属性値の否認やユーザー・アクティブ化リクエストの拒否などです。
通常、falseの状態は、エラー・レポート・ステップのエントリ条件です。たとえば、エラー・レポート・ステップの前のステップの参加者がアクティブ化操作を否認した場合に、ワークフローをエラー・レポート・ステップに進めることができます。
|
注意: プロビジョニングに使用するワークフローの場合、ワークフローごとに最低2つのコミット・アクションを定義する必要があります。1つのアクションでLDAPのデータをコミット（または有効化あるいはアクティブ化）し、もう1つのアクションでプロビジョニング・データを書き込みます。 |
必要に応じて、「ワークフローの最初のステップの定義」の手順に従って参加者の追加と属性の構成を行います。
ステップまたはワークフローを保存します。
注意: ユーザーの作成ワークフローは、「有効化」ステップで終了する必要があります。そうしない場合、ワークフローで追加されたユーザーを検索できません。
ワークフローの最後のステップでは、特定のスキーマ・ドメインにデータをコミットします。デフォルトでは、スキーマ・ドメインは、アイデンティティ・システムがやり取りするLDAPディレクトリです。ただし、ワークフローでテンプレート属性を構成した場合、テンプレート属性のスキーマ・ドメインにデータをコミットするための個別ステップを構成する必要があります。
テンプレート・スキーマ・ドメインの属性のコミット・ステップは、アイデンティティ・イベントAPIで処理してプロビジョニング用にバックエンド・システムに渡すことができます。
作成後のワークフローは、デフォルトで無効化されています。アイデンティティ・システムまたは外部アプリケーションで他の参加者を受け入れる準備ができたら、ワークフローを有効化します。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャにアクセスします。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
ワークフロー・メニューでワークフローを選択します。
「有効化」をクリックします。
注意: 属性が存在しないというメッセージが表示された場合は、各ワークフロー・ステップを調査してください。ステップごとに参加者と属性を構成する必要があります。
ワークフローは、テストの前に有効化する必要があります。詳細は、「ワークフローの有効化」を参照してください。また、ワークフローをテストする場合はそのワークフローの参加者である必要があります。
アイデンティティ・システム・コンソールで、ワークフローを実行するアプリケーションを選択します。
たとえば、ユーザーの作成ワークフローの場合、ユーザー・マネージャを起動します。
ワークフローを開始します。
たとえば、ユーザーの作成ワークフローを定義した場合、テストするワークフローは「ユーザーの作成」ページのリストに表示されます。ワークフローを開始するには、そのワークフローをリストから選択します。
ユーザーの変更ワークフローの場合、ユーザー・マネージャで「変更をリクエスト」機能を選択します。
各ワークフロー・ステップで指示される機能を実行します。
ワークフローは、期待どおりに動作する必要があります。たとえば、ユーザーの作成ワークフローの完了後には、ユーザーの作成操作で追加されたユーザーを検索できる必要があります。
アイデンティティ・システム・コンソールで、「グループ・マネージャ」を選択します。
ワークフロー定義のグループ・タイプに対応するグループ・タイプ・パネルを選択します。
たとえば、Group構造化オブジェクト・クラスとoblixAdvancedGroupオブジェクト・クラスでは、グループ・タイプ・パネルが異なる可能性があります。詳細は、「「ユーザー・マネージャ」または「組織マネージャ」タブへの補助オブジェクト・クラスおよびテンプレート・オブジェクト・クラスの追加」を参照してください。
次に、ユーザーの作成ワークフローを定義する場合の例を示します。この例では、アイデンティティ・システムにログインしているすべてのユーザーが任意のユーザーを作成できるワークフローを定義します。このワークフローにより、ユーザーに割り当てる名前および電子メール・アドレスを要求するチケットが生成されます。処理が完了すると、アイデンティティ・システムで新規ユーザーが有効化されます。
ユーザー・マネージャで、「構成」をクリックし、次に「ワークフロー定義」をクリックして「ワークフロー定義」ページに移動します。
「新規」をクリックします。
このワークフローに「テスト用の新規ユーザー作成ワークフロー」という名前を付けます。
「ワークフロー・タイプ」フィールドで、「ユーザーの作成」を選択します。
ターゲット定義ページで、「ターゲット名」フィールドに名前を入力し、「追加」をクリックしてデフォルト・ドメインを受け入れます。
「次へ」をクリックして「ターゲット・ドメイン」ページから「ワークフロー定義」ページに移動します。
ワークフローの「開始」ステップを作成します。
「参加者」タブをクリックし、参加者を「すべてのユーザー」ロールとして定義します。
「属性」タブをクリックし、ワークフロー参加者に入力してほしい「姓」や「名」などの属性を選択します。
「新規」をクリックし、「有効化」アクション・タイプで新規ステップを作成します。
「追加」をクリックし、「有効化」ステップのエントリ条件として「開始」ステップを追加します。
「参加者」をクリックし、参加者として「すべてのユーザー」を選択します。
「属性」をクリックし、このステップで提供される属性を追加します。
ワークフローを保存して有効化します。
ユーザー・マネージャで新規ユーザーの作成を試み、ワークフローをテストします。
サブフローに指定できるのは、属性の変更ワークフロー・タイプのみです。これらのワークフローは、ワークフロー定義ページでサブフローとして明示的に構成する必要があります。また、すべてのサブフローには承認ステップ・アクションが含まれる必要もあります。
|
注意: ワークフローをサブフローとして使用可能にするには、ワークフロー定義の最初のページにある「サブフローとして使用」を選択する必要があります。 |
アイデンティティ・システム・コンソールで、「ユーザー・マネージャ」、「グループ・マネージャ」または「組織マネージャ」アプリケーション・タブをクリックします。
「構成」をクリックします。
「ワークフロー定義」をクリックします。
「新規」をクリックします。
「ワークフロー名」フィールドにワークフローの名前を入力します。
「サブフローとして使用」チェック・ボックスを選択します。
「ワークフロー・タイプ」リストで、「属性の変更」を選択します。
「次へ」をクリックします。
ワークフローの最初のステップで、ワークフローにより変更する属性を指定します。
他のワークフローと同様に、ワークフローの残り部分を完成します。
|
注意: すべてのサブフロー定義には承認ステップ・アクションが含まれる必要があります。 |
サブフローは、メイン・ワークフローの特定のワークフロー・ステップに関連付ける必要があります。ワークフローの実行時、特定のステップに構成されているサブフローは、そのステップ・アクションの実行後に起動されます。
「「ワークフロー定義」アプレットへのアクセス」に従ってワークフロー・アプリケーションを起動します。
サブフローを割り当てるワークフローを選択します。
「変更」をクリックします。
ページがリフレッシュされ、ステップ定義ページが表示されます。
「サブフロー」タブをクリックします。
ページの「定義済ステップ」領域で、サブフローを挿入するワークフロー順序内の場所を選択します。
「サブフロー」タブの「サブフローの選択」領域で、このワークフローの一部とするサブフローを選択します。
このステップに割り当てる1つ以上のサブフローを選択し、右矢印ボタン（>>）をクリックします。
|
注意: ここでサブフローが表示されない場合は、そのフローがサブフローとしてマークされており、有効化されていることを確認してください。また、サブフローのターゲットである属性は、サブフローの割当て先のワークフローでは使用できません。 |
ステップを保存します。
オプションで、後続の1つ以上のステップでサブフローの完了を待機するかどうかを指定できます。
サブフローが完了するまで遅延させるステップを選択し、「変更」をクリックします。
「サブフローを待機」チェック・ボックスを選択します。
通常は、ワークフロー・ステップの作成時に指定した静的参加者が、そのステップの完了を担当するユーザーになります。処理上のボトルネックを避けるため、または各チケットをその処理に最も適した参加者に送信するため、次の3つの拡張チケット・ルーティング機能を使用して特定の状況下にある静的参加者を入れ替えることができます。
ワークフロー作成時に静的参加者を指定するかわりに、ワークフロー・プラグインまたはアプリケーションを使用して実行時の状況に応じた動的参加者を選択できます。
静的または動的参加者が外出中などの理由によりワークフロー・チケットを処理できない場合、その参加者は自分のユーザー・プロファイルに「外出中」フラグを設定できます。このフラグがアクティブであるかぎり、すべての着信チケットはサロゲート参加者に転送されます。
所定のワークフロー・チケットを受信した参加者が一定の期間内にチケットを処理しない場合、そのチケットをエスカレーション参加者（チケット処理の責任を全面的に引き継ぐ参加者）に送信できます。
すべてのワークフロー・ステップを拡張チケット・ルーティング用に構成できるわけではありません。たとえば、ワークフローの最初のステップは、再ルーティングできません。ただし、最初のステップを再ルーティングする必要はありません。ワークフローを開始するユーザーは最初のステップの参加者でもあり、最初のステップは常にワークフローの開始操作であるためです。
ユーザー・アクションを伴わないステップは、定義上ユーザー参加者を含むことがないため、再ルーティングできません。たとえば、外部データベースからプロビジョニング・データを自動的に取得するステップは、ユーザー参加者を含まないため、参加者を入れ替えても意味がありません。
次の表に、ワークフロー・ステップに関連付けることのできるユーザー・アクションをリストします。
表5-9 拡張チケット・ルーティングで使用できるユーザー・アクション
| ユーザー・アクション | 可用性 |
|---|---|
|
承認 |
デフォルトでは、動的参加者、サロゲートおよび時間ベース・エスカレーションで使用可能です。 |
|
情報の提供（承認あり） |
|
|
開始 |
デフォルトでは、動的参加者とサロゲートで使用可能です。適切なワークフロー・パラメータ・ファイルを変更することで、時間ベース・エスカレーションでも有効化できます。詳細は、「ワークフロー・パラメータ・ファイルを変更する手順」を参照してください。 |
|
自己登録 |
|
|
情報の提供 |
|
|
サブフロー承認 |
|
|
アクティブ化 |
|
|
非アクティブ化 |
|
|
エラー・レポート |
|
|
グループの選択 |
|
|
リクエスト |
|
|
情報の変更 |
|
|
情報の変更（承認あり） |
ワークフロー・アプレットの「メール通知」タブを使用すると、ワークフロー・チケットの再ルーティング時にタスクを完了するよう割り当てられた参加者に電子メール通知を構成できます。チケットの再ルーティングを適用するステップごとにメール通知を構成できます。
拡張チケットの再ルーティングを伴うステップにメール通知を構成するには、次の手順を実行します。
拡張ワークフロー・チケットの再ルーティング用に電子メール通知を構成する手順
変更するワークフローに応じてユーザー・マネージャ、グループ・マネージャまたは組織マネージャに移動し、「構成」→「ワークフロー定義」をクリックします。
変更するワークフローを選択し、「変更」をクリックします。
属性の変更ワークフローを変更する場合、「次へ」を1回クリックします。それ以外のタイプのワークフローの場合、「次へ」を2回クリックします。
メール通知を設定するステップを選択し、「変更」をクリックします。
「メール通知」タブをクリックします。
静的、動的およびサロゲート参加者に対する通知を有効化するため、「事前通知する参加者の選択」または「事後通知する参加者の選択」を選択します。
ワークフローの最初のステップでは、「事前通知する参加者の選択」は選択できません。
個人、グループ、ロールまたはルールに基づいて、通知するユーザーを指定します。
通知するユーザーを指定する場合、セレクタやフィルタ・ビルダーなどの機能を使用できます。
エスカレーション参加者への通知: 「エスカレーション通知先の選択」をクリックして手順7を繰り返します。
「ステップの保存」をクリックしてステップ固有の変更をコミットします。
「ワークフローの保存」をクリックしてワークフロー全体を保存します。
動的参加者機能は、実行時の状況に基づいてワークフロー・チケットを代替参加者に自動ルーティングできる拡張ワークフロー・オプションの1つです。
アイデンティティ・システムでは、次の2つのタイプのワークフロー参加者がサポートされます。
静的参加者: このタイプの参加者は、通常、ワークフロー・ステップの定義時にワークフロー・アプレットを通じて指定します。たとえば、新規従業員のネットワーク・アカウントを設定するワークフローを作成する際に、すべての着信チケットをネットワーク・セキュリティ・マネージャにルーティングする承認ステップを含めることができます。後でワークフロー・プラグインまたはアプリケーションを追加しないかぎり、この事前指定された静的参加者が、ワークフロー・ステップで生成されるすべてのチケットの主要な受信者として機能します。
動的参加者: このタイプの参加者は、ワークフロー・アプレットではなく、ワークフロー・プラグインまたはアプリケーションで指定する必要があります。これらの状況依存型の参加者は、実行時の属性値または外部ビジネス・ロジックに基づいて選択されます。たとえば、プラグインを使用して、2,500ドルを超えるすべての購買リクエストを経理担当マネージャに、50ドル未満のすべてのリクエストを会計事務員に、他のすべてのリクエストを作業可能な経理担当者にルーティングするよう指定できます。
次の図に示すとおり、ワークフローが実行され、動的参加者が有効化されているステップにプログラム実行が到達すると、ワークフロー・プラグインまたはアプリケーションにより、動的参加者のセットが選択されてそれらのユーザーにワークフロー・チケットが送信されます。プラグインまたはアプリケーションで動的参加者が選択されない場合、コール側のアプリケーションにより、ワークフロー・プラグインまたはアプリケーションによる介入がない場合と同じように元の静的参加者にチケットが送信されます。
動的参加者は、静的参加者を指定する場合と同じ基準を使用して指定します。これには、個人、グループ、ロールおよびルールに基づく指定が含まれます。詳細は、「次のいずれかの方法を使用して参加者を指定します。」の手順を参照してください。
動的参加者は、ワークフローのすべてのステップで定義できます（ただし、静的参加者が開始する必要のある最初のステップは除きます）。
ステップ・インスタンスが実行時に割り当てられると、静的参加者が通常取得するのと同じチケット処理権限が動的参加者により継承されます。これらの権限は、特に動的参加者に割り当てられるチケットにのみ拡張されます。つまり、動的参加者は、「代替権限」機能を使用して委任が作成される場合のように元の参加者に割り当てられたすべての権限を取得することはありません。「代替管理者の追加」を参照してください。
動的参加者のアイデンティティは、関連するワークフロー・ステップが実行されるまで不明のため、特定のワークフロー・サービス（前のワークフロー・ステップにより生成される事後アクション電子メールなど）では使用できません。ただし、動的参加者を選択するワークフロー・ステップにより生成される事前アクション電子メールを使用して、動的参加者に通知を行うことは可能です。「動的参加者に対応するワークフロー・ステップを準備する手順」の手順を参照してください。
通常の状況下のワークフロー・ステップでは、ワークフロー・アプレットを通じて指定された静的参加者が使用されます。
特定のステップに対してoblixpppcatalogカタログ・ファイルでプラグインまたはアプリケーションを指定している場合、プラグインまたはアプリケーションにより、実行時の値の評価に応じて先に動的参加者が選択されます。プラグインまたはアプリケーションが動的参加者のセットを指定できない場合にのみ、静的参加者が主要なステップ参加者として指定されているメイン・アプリケーションに制御が戻されます。
特定のステップではワークフロー・プラグインまたはアプリケーションにより常に動的参加者が選択されると事前に判明している場合、そのステップに静的参加者を定義する必要はありません。ただし、静的参加者を指定しない場合、デフォルトの「静的参加者が使用可能」ボタンを「静的参加者が使用不可」に切り替える必要があります。次の図に示すとおり、これらのラジオ・ボタンは、ワークフロー・アプレットの「参加者」タブに表示されます。このアプレットには、構成中のワークフローに適したユーザー・マネージャ、グループ・マネージャまたは組織マネージャを通じてアクセスできます。
動的参加者機能は、デフォルトでは有効化されません。この機能をアクティブ化するには、次のタスクの概要に記載されている手順を完了する必要があります。
タスクの概要: ワークフロー・ステップへの動的参加者の割当て
クイックスタート・ツールまたはワークフロー・アプレットを使用して、動的参加者を利用するステップを含むワークフローを作成します。
詳細は、「クイックスタート・ツールの使用方法」および「ワークフロー・アプレットの使用方法」を参照してください。
特定のステップで静的参加者を使用する可能性がある場合は、そのステップの静的参加者を定義する必要があります（「次のいずれかの方法を使用して参加者を指定します。」の手順を参照してください）。
ただし、特定のステップで常に動的参加者が使用されると事前にわかっている場合は、そのステップに静的参加者を定義する必要はありません。詳細は、「「静的参加者が使用不可」ボタンの概要」を参照してください。
必要に応じて、動的参加者の電子メール通知を設定します。
詳細は、「動的参加者に対応するワークフロー・ステップを準備する手順」を参照してください。
動的参加者を選択するための適切なプラグインまたはアプリケーションが実行時にコールされるように、oblixpppcatalogカタログ・ファイルにポインタを追加します。
詳細は、「oblixpppcatalog.lstを変更する手順」を参照してください。
実行時に動的参加者を選択するための事前アクション・プラグインまたはアプリケーションを作成します。
一般的なプラグインまたはアプリケーションには、次の処理を実行するコード・セクションが含まれます。
動的参加者の3つ以上のセットを指定します。最後のセットには、常にNULL値のみが含まれます。
実行時に評価する属性またはビジネス・ロジックを指定します。
評価に基づいて動的参加者を選択します。
選択された参加者が実際にアイデンティティ・システム・ディレクトリに存在することを確認します。存在しない場合、動的参加者の選択プロセスは失敗しますが、ワークフロー・エンジンからエラー・メッセージは戻されません。
動的参加者のリストをコール側のアイデンティティ・システム・アプリケーションに渡します。
詳細は、「タスクの概要: 動的参加者を選択するプラグインまたはアプリケーションの作成」を参照してください。
|
警告: 動的参加者を有効化するプラグインおよびアプリケーションは、事前アクション・タイプである必要があります。事後アクション・タイプは使用できません。 |
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャで、「構成」に移動し、「ワークフロー定義」をクリックします。
「ワークフロー」リストで、動的参加者に対応するよう準備するステップを含むワークフローを選択し、「変更」をクリックします。
現在のワークフロー・ステップで最終的に静的参加者を使用する可能性がある場合は、ロール、ルール、個人またはグループに基づいて静的参加者を定義します（「次のいずれかの方法を使用して参加者を指定します。」の手順を参照してください）。
前述の条件が適用されない場合、またはこのステップに対してすでに静的参加者を定義している場合、直接手順4に進んでください。
現在のワークフロー・ステップでプラグインまたはアプリケーションを使用して動的参加者を指定し、かつ現在のステップで静的参加者が最終的にワークフロー・チケットを受信するような状況が発生しない場合、「静的参加者が使用不可」ボタンを選択します（「「静的参加者が使用不可」ボタンの概要」を参照してください）。それ以外の場合、直接手順5に進んでください。
必要に応じて電子メール通知を設定します。これを行うには、「メール通知」タブをクリックし、「事前通知する参加者の選択」ボタンを選択します。次に、「ロールの選択」ボックスで「現在のステップの参加者」を選択します。動的参加者が最終的に選択されると、それらの参加者は、ワークフロー・チケットが割り当てられたという内容の電子メールを受信します。
|
注意: 「静的参加者が使用可能」スイッチがアクティブであると、「事前通知する参加者の選択」ボタンにより静的参加者に対する電子メール通知が有効化されます。これに対し、「静的参加者が使用不可」スイッチがアクティブであると、動的参加者に通知が送信されます。UseDefaultOptionsForAllMailsの詳細は、「ステップ・アクションの説明」を参照してください。 |
「ステップの保存」をクリックしてステップ固有の情報をコミットし、「OK」をクリックして操作の確認を求めるプロンプトを閉じます。
「ワークフローの保存」をクリックしてワークフロー全体に関連する情報をコミットし、「OK」をクリックして操作の確認を求めるプロンプトを閉じます。ワークフローを有効化するかどうかを尋ねる追加のプロンプトが表示されたら、「はい」をクリックします。
次の手順を実行して、動的参加者を設定するステップを含むワークフローのワークフローIDを特定します。
変更するワークフローに応じて、ユーザー・マネージャ、グループ・マネージャまたは組織マネージャを起動します。
「構成」タブをクリックし、次に「ワークフロー定義」をクリックします。
変更するワークフローを選択し、「表示」をクリックします。
obworkflowidの「ワークフロー定義ビュー」にレポートされる値を書き留めます。この値は、次のような文字列で示されます。
Workflow DN : obworkflowid=5985de47196a4a728a629a429b6a5194
任意のプレーン・テキスト・エディタを使用して、次のディレクトリにあるoblixpppcatalog.lstファイルを開きます。
IdentityServer_install_dir\identity\oblix\apps\common\bin
ここで、IdentityServer_install_dirは、ワークフローを実行するアイデンティティ・サーバーのルート・インストール・フォルダです。
次のいずれかの文字列をoblixpppcatalog.lstに追加します。
obworkflowid_workflowstep_preaction;lib;;Component_install_dir\identity\oblix\path\pluginName.dll;functionName; Orobworkflowid_workflowstep_preaction;exec;;Component_install_dir\identity\oblix\path\applicationName.exe;functionName;
この場合:
obworkflowidは、この説明の手順1dで書き留めたワークフローのアイデンティティ番号です。
workflowstepは、動的参加者を定義するステップです。
pathは、Component_install_directory\identity\oblix\からpluginName.dllまたはapplicationName.exe（実行時に動的参加者を選択するコード・オブジェクト）までのパスです。
functionName: プラグインを指定する場合、動的参加者の基準を設定するダイナミック・リンク・ライブラリ・プラグイン内の関数を示すfunctionNameも指定する必要があります。
プラグインを使用して動的参加者を指定する場合、前述の最初のコード行を挿入します。プラグインではなく実行可能プログラムを使用する場合、2番目の行を挿入します。
どちらの場合でも、挿入行はセミコロンで終了する必要があります。これらの行は、既存の行を分断しないかぎり、oblixpppcatalog.lstファイルのどこにでも配置できます。
挿入する行は、次のようになります。
wfqs20040901T17251953156_2_preaction;lib;;
Component_install_dir\identity\oblix
\unsupported\ppp\ppp_dll\ppp_dll.dll;
WorkflowPreActionSetDynamicParticipantsTest;
oblixpppcatalog.lstを元の場所に保存します。
oblixpppcatalog.lstファイルの詳細は、『Oracle Access Manager開発者ガイド』も参照してください。
タスクの概要: 動的参加者を選択するプラグインまたはアプリケーションの作成
C++を使用して、「oblixpppcatalog.lstを変更する手順」で指定したワークフロー・ステップにプログラム実行が到達したときに動的参加者を選択するプラグインまたはアプリケーションを作成します。
LDAP属性または独自仕様のビジネス・ロジックを様々に組み合せて、実行時に他の参加者に優先して動的参加者の1つのグループを選択する条件を指定します。
プラグインまたはアプリケーションに次のヘッダー・ファイルをインクルードします。これらのファイルにより、動的参加者の選択に必要な事前アクション処理が有効化されます。
obppp.h obpppwf.h obpppdata.h
アプリケーションまたはプラグイン内で、ロール、ルール、個人またはグループの任意の組合せを使用して動的参加者の3つ以上のセットを定義します。各配列の最後の項目は、常にNULLである必要があります。たとえば、次のようになります。
個人を指定する場合、次のような行を挿入します。
PPPSetVals[0] = "cn=Van Oman, ou=Sales, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[1] = "cn=Fabien Esser, ou=Sales, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[2] = NULL;
data->Set("DynamicParticipant.Persons", PPPSetVals);
グループを指定する場合、次のような行を挿入します。
PPPSetVals[0] = "cn=Basic group1k1, ou=Groups, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[1] = "cn=Basic group1k2, ou=Groups, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[2] = NULL;
data->Set("DynamicParticipant.Groups", PPPSetVals);
ロールを指定する場合、次のような行を挿入します。
PPPSetVals[0] = "ob_self";
PPPSetVals[1] = "manager";
PPPSetVals[2] = NULL;
data->Set("DynamicParticipant.Roles", PPPSetVals);
Remember, of course, that only certain roles are valid for particular workflow types. See page 200.
ルールを指定する場合、次のような行を挿入します。
PPPSetVals[0] = "(cn=rohit*)";PPPSetVals[1] = "(cn=beth*)";PPPSetVals[2] = NULL;
data->Set("DynamicParticipant.Rules", PPPSetVals);
静的または動的参加者が特定のワークフロー・ステップに割り当てられたアクションを実行できないときに、その参加者が自分のユーザー・プロファイルに「外出中」フラグを設定して、着信ワークフロー・チケットを1人以上の指定されたサロゲート参加者に転送できるようアイデンティティ・システム・アプリケーションを構成できます。再ルーティングされるチケットを処理するために元の参加者が保持していたすべての権限は、サロゲートに付与されます。
「外出中」フラグのアクティブ化後に作成されたチケットのみがサロゲートに再ルーティングされます。「外出中」フラグのアクティブ化前に作成されたすべてのチケットの処理を担当するのは、引き続き元の参加者です。
「外出中」フラグを有効化すると、その効果は参加者が静的参加者または潜在的な動的参加者として指定されているすべてのワークフローのすべてのステップに適用されます。
「外出中」フラグをオフにリセットすると、新しく作成されたチケットは再び元の参加者にルーティングされます。サロゲートは、「外出中」フラグがアクティブなときに自分に対してルーティングされたすべてのチケットの処理を担当しますが、元の参加者が再度「外出中」フラグをアクティブ化しないかぎり、新規チケットはサロゲートにルーティングされません。
元の参加者にチケット割当てを送信する場合と同じワークフロー・アプレット設定により、サロゲートとその他のユーザーに「外出中」フラグのためワークフロー・チケットが再ルーティングされたという内容の通知も行われます。
アイデンティティ・システム・コンソールの「共通構成」タブで、任意の属性を「外出中」セマンティク型に関連付けます。
この操作は1回のみ行います。詳細は、「外出中属性を「外出中」セマンティク型に関連付ける手順」を参照してください。
ワークフロー・アプレットの「外出中」タブで、1人以上のサロゲートを指定します。
詳細は、「次のいずれかの方法を使用して参加者を指定します。」を参照してください。
個々のユーザーが、ユーザー・プロファイルの「外出中」フラグをアクティブ化します。
詳細は、「「外出中」フラグを使用する手順」を参照してください。
「外出中」セマンティク型に関連付けるLDAPディレクトリの属性を選択します。
これは、ユーザーが外出中であるかどうかを示すブール値を保持する属性である必要があります。簡便化のため、製品にはobOutofOfficeIndicator属性が付属していますが、ディレクトリ内の適切な属性を任意に使用できます。
アイデンティティ・システム・コンソールに移動し、「共通構成」→「オブジェクト・クラス」→Personオブジェクト・クラス（gensiteorgpersonなど）→「属性の変更」を選択します。
属性リストで、関連付ける属性を選択します。
「セマンティク型」フィールドで、「外出中 - インジケータ」を選択します。
このインジケータを保持できるのは、一部の属性のみです。たとえば、gensiteOrgPersonのgenuserid属性は、このインジケータを保持できます。
「表示タイプ」ボックスで「ブール」を選択し、「完了」をクリックして変更をコミットします。
|
注意: この手順は、1回のみ実行する必要があります。 |
1人以上のサロゲートを指定するステップを含む特定のワークフローに応じてユーザー・マネージャ、グループ・マネージャまたは組織マネージャにログインし、「構成」に移動して「ワークフロー定義」を選択します。
サロゲートを指定するステップを含むワークフローを選択し、「変更」をクリックします。
属性の変更ワークフローを変更する場合、「次へ」を1回クリックします。
それ以外のタイプのワークフローを変更する場合、「次へ」を2回クリックします。
サロゲートを指定するステップを選択し、「変更」をクリックします。
ページがこのステップの情報でリフレッシュされます。ページがリフレッシュされない場合、ステップが選択されていることを確認してください。選択されていない場合、ステップを再度クリックし、次に「変更」をクリックします。
ユーザー・アクションに関連付けられた任意のワークフロー・ステップのサロゲートを指定できます。
「外出中」タブをクリックします。
個人、グループ、ロールおよびルールを指定するツールを組み合せて、1人以上のサロゲートを指定します。
詳細は、「次のいずれかの方法を使用して参加者を指定します。」を参照してください。
「間接ロールの選択」ボックスには、ディレクトリに現在定義されている任意のロールを選択するためのチェック・ボックスが含まれます。これらのロールは、ワークフロー・ターゲットではなく現在の参加者に適用されるため、間接的であるとみなされます。
「ステップの保存」をクリックしてステップの変更をコミットします。
属性を構成するよう求める警告が表示された場合、このステップに対して属性を選択していることを確認してください。
サロゲートを指定するワークフロー・ステップごとに前述の手順を繰り返します。
「ワークフローの保存」をクリックしてワークフロー全体を保存します。
静的または動的参加者となる可能性のあるユーザーに対し、この手順に記載されている操作を実行するのに十分な権限（検索、読取りおよび書込み）が付与されていることを確認してください。
属性に「外出中」フラグが構成されていることを確認します。
ユーザー・マネージャに移動し、「プロファイル」を選択して「変更」をクリックします。
「個人情報」セクションで、「外出中インジケータ」を「True」に切り替えます。（デフォルトでは、この属性は「False」です。）
「保存」をクリックして変更をコミットし、「OK」をクリックして操作の確認を求めるポップアップを閉じます。
ワークフロー・チケットの処理を割り当てられた1人以上の参加者が一定の期間内にチケットを処理しない場合、チケットを別の参加者に自動的に再ルーティングすることでそのチケットをエスカレーションできます。元の参加者は、エスカレーションされたチケットを処理できません。この場合、エスカレーション参加者がチケットを処理する必要があります。エスカレーション参加者は、チケット処理のために元の参加者に付与されていたすべての権限を継承します。
割り当てられた時間内にエスカレーション参加者がチケットを処理しない場合、チケットは再度エスカレーションされ、最終的にはエスカレーション・チケットの処理を担当できる最後の参加者であるアイデンティティ・システム管理者までエスカレーションされます。
デフォルトでは、任意のワークフロー・ステップで時間ベース・エスカレーションを有効化できますが、次の2つの条件を満たしている必要があります。
エスカレーションされるステップは、ワークフローの開始ステップではないこと。
ステップに関連付けられたアクションがエスカレーションに対応していること。デフォルトでは、「承認」および「情報と承認の提供」のみがエスカレーションに対応していますが、適切なワークフロー・パラメータ・ファイルに行を追加することで他のアクションでも対応できます。詳細は、「ワークフロー・パラメータ・ファイルを変更する手順」を参照してください。
時間ベース・エスカレーションを設定する特定のワークフローに応じてユーザー・マネージャ、グループ・マネージャまたは組織マネージャにログインし、「構成」に移動して「ワークフロー定義」をクリックします。
エスカレーションを設定するワークフローを選択し、「変更」をクリックします。
保留中のチケットがワークフローに存在する間に変更できるのは一部の設定のみであると警告するポップアップが表示されたら、「OK」をクリックしてポップアップを閉じます。属性の変更ワークフローを変更する場合、「次へ」を1回クリックします。それ以外のタイプのワークフローを変更する場合、「次へ」を2回クリックします。
エスカレーションを有効化するステップを選択し、「変更」をクリックします。
ページがこのステップの情報でリフレッシュされます。ページがリフレッシュされない場合、ステップが選択されていることを確認してください。選択されていない場合、ステップを再度クリックし、次に「変更」をクリックします。
選択するステップは、エスカレーションに対応するアクションに関連付けられている必要があります。デフォルトでは、「承認」および「情報と承認の提供」が対応しています。時間ベース・エスカレーションをサポートする追加アクションを有効化する方法の詳細は、「ワークフロー・パラメータ・ファイルを変更する手順」を参照してください。
「エスカレーション」タブをクリックします。
チケットをエスカレーションするまでに待機する期間を指定します。期間は、日、分、時間単位で設定できます。この期間は、すべてのエスカレーション・レベルに適用されます。
チケットのエスカレーション先となる1人以上の参加者を指定します。ロールは、ワークフロー・ターゲットに対してではなく、最新のエスカレーションを起動せずに済む期間内にチケットを処理できなかった参加者に対して評価されるため、間接ロールとなります。たとえば、「間接ロールの選択」ボックスで「マネージャ」を選択した場合、最初にチケットを受信した経理担当者がチケットを迅速に処理しないと、そのチケットは（ワークフロー・ターゲットのマネージャではなく）経理担当者のマネージャにエスカレーションされます。
チケットをエスカレーションする回数（レベル数）を指定します。この数には、最終エスカレーション・レベル（常にチケットがルーティングされるアイデンティティ・システム管理者）は含まれません。
エスカレーション参加者の1つのセットのみ指定できます。この1つのセットは、すべてのエスカレーション・レベルに適用されます。たとえば、ただ1人のユーザーを指定すると、エスカレーションが起動されるたびにそのユーザーにチケットがエスカレーションされます。そのエスカレーション参加者がいずれかのレベルにおいてチケットを処理しない場合、チケットは最終的にアイデンティティ・システム管理者にエスカレーションされます。
一方、各レベルの異なるユーザーにより保持されているロールを指定すると、チケットは各レベルの異なるユーザーにエスカレーションされます。たとえば、「マネージャ」を指定すると、チケットは最初にそのチケットが発行されたユーザーのマネージャにエスカレーションされます。その後、そのマネージャのマネージャに、さらにそのマネージャのマネージャにという形でエスカレーションが続きます。
「ステップの保存」をクリックして「エスカレーション」タブで入力した設定をコミットします。
「メール通知」タブをクリックし、エスカレーションを通知するユーザーを指定します。
「エスカレーション通知先の選択」を選択します。
個人、グループ、ロールまたはルールに基づいて、通知するユーザーを選択します。使用可能なロールは、次のとおりです。
前のステップの所有者: 前のステップを完了した参加者です。
現在のステップの参加者: エスカレーションされたチケットを処理するよう現在割り当てられているユーザーです。
次のステップの参加者: 次のステップを処理するよう割り当てられているユーザーです。この場合、次のステップに定義されている静的参加者にのみ通知が行われます。これは、実行フローが次のステップに到達し、動的参加者のアイデンティティが決定される前に電子メール通知が送信されるためです。
開始者: ワークフローを開始したユーザーです。
「承認」または「情報と承認の提供」以外のユーザー・アクションで時間ベース・エスカレーションを有効化する場合にのみこの手順を実行します。時間ベース・エスカレーションに対応可能なユーザー・アクションのリストは、表5-9を参照してください。
任意のプレーン・テキスト・エディタを使用して、時間ベース・エスカレーションを有効化するアクションを含むワークフローに適したワークフロー・パラメータ・ファイルを開きます。
表5-10に、様々なアイデンティティ・システム・アプリケーションに関連付けられたワークフローに適用されるワークフロー・パラメータ・ファイルをリストします。
表5-10 ワークフロー・パラメータ・ファイルの名前とパス
| アプリケーション | ワークフロー・パラメータ・ファイルの名前とパス |
|---|---|
|
ユーザー・マネージャ |
|
|
グループ・マネージャ |
|
|
組織マネージャ |
|
時間ベース・エスカレーションをサポートするアクションの複合リストの場所を見つけます。例5-1に、この複合リストの前半部分の内容を示します。
例5-1 ワークフロー・パラメータの複合リスト（一部）
<CompoundList ListName="actionName">
<SimpleList >
<NameValPair ParamName="occurrence" Value="n"/>
<NameValPair ParamName="useraction" Value="true"/>
<NameValPair ParamName="initialStep" Value="false"/>
<NameValPair ParamName="time_based_escalation" Value="true"/>
</SimpleList>
. . .
</CompoundList>
ここで、actionNameは、時間ベース・エスカレーションを有効化するアクションの名前です。時間ベース・エスカレーションに対応可能なアクションのリストは、表5-9を参照してください。
次の文字列を、前述のリストで指定された位置に追加します。
<NameValPair ParamName="time_based_escalation" Value="true"/>
時間ベース・エスカレーションをサポートするすべてのユーザー・アクションに対してここまでの手順を繰り返します。
ファイルを保存して閉じます。
非同期ワークフローは、保留中のサブフローの完了を待機せずにステップからステップへと進みます。非同期操作は、アイデンティティ・イベントの一部である前処理および後処理コードです（『Oracle Access Manager開発者ガイド』を参照してください）。保留中の非同期アクションを再開できるユーザーは、asynch_userパラメータにより決定します。デフォルトはAnyoneです。
次の場所にあるasynchparams.xmlファイルを開きます。
IdentityServer_install_dir/oblix/apps/asynch/bin/asynchparams.xml
ここで、IdentityServer_install_dirは、アイデンティティ・サーバーがインストールされているディレクトリです。
async_userパラメータに次のいずれかの値を設定します。
Anyone: すべてのユーザーが非同期操作を実行できます（デフォルト）。
DN: 特定の1人のユーザーが非同期操作を実行できます。ユーザーのDNを指定します。
パラメータに指定できるのは、1つのDNのみです。
asynchparams.xmlファイルを閉じます。
ユーザー・マネージャ、グループ・マネージャおよび組織マネージャは、非同期ワークフローが再開したときに自動的にロードされません。アプリケーションがロードされない状態で非同期ワークフローを再開するリクエストがアイデンティティ・サーバーに送信されると、ワークフロー・エンジンではエラー状態を登録できない可能性があります。
例として、User Mangerでユーザーの非アクティブ化ワークフローを作成する場合を検討します。このワークフローには、「開始」ステップと「無効化」ステップのみが含まれます。ここで、STATUS_PPP_WF_ASYNCコードを戻すワークフローのイベント・プラグインを作成するとします（この場合、「開始」ステップ中にワークフロー・インスタンスは非同期状態となり、ワークフローを再開して「無効化」ステップを実行するコマンドが待機されます）。アイデンティティ・システムの再起動時にこのワークフローを再開するIdentityXMLリクエストが発生すると、ワークフロー・エンジンにより間違って成功のステータスが戻されます。この場合、実際にはユーザーが無効化されていない状態で、「無効化」ステップから完了のステータスが戻されます。
|
注意: アイデンティティ・サーバーの再起動時に、ユーザー・マネージャ、グループ・マネージャおよび組織マネージャが事前ロードされていることを確認してください。 |
ユーザー・マネージャ、グループ・マネージャおよび組織マネージャを事前ロードする手順
次の場所にあるアイデンティティ・システムのパラメータ・ファイルを開きます。
Identity_install_dir/identity/oblix/engine/obengineparams.xml
このファイルで、アイデンティティ・システム・アプリケーションの次の構成情報を見つけます。
<ValNameList ListName="groupservcenter">
<ValNameList ListName="userservcenter">
<ValNameList ListName="objservcenter">
Dll_Loadパラメータを0から1に変更します。グループ・マネージャの例は、次のとおりです。
<ValNameList ListName="groupservcenter" > <NameValPair ParamName="Dll_Name" Value="groupservcenter"/> <NameValPair ParamName="Dll_Dir" Value="oblix/apps/groupservcenter/bin"/> <NameValPair ParamName="Dll_Load" Value="1"/> <NameValPair ParamName="Work_Dir" Value="oblix/apps/groupservcenter/bin"/>
ワークフローの定義が完了すると、ユーザーは、ユーザー・マネージャ、グループ・マネージャまたは組織マネージャの関連機能からワークフローを起動できます。ワークフローの「開始」以外のステップの参加者は、チケットを検索して処理できます。ユーザーは、ワークフロー・リクエストの削除、リクエストのアーカイブ、およびワークフローの進行状況のモニターを行うことが可能です。
ワークフロー定義で指定されたアクションを実行するには、ワークフローの参加者に、ワークフローに関連する属性を参照および変更できる権限が付与されている必要があります。「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
定義されたワークフローは、ユーザー・マネージャ、グループ・マネージャまたは組織マネージャの埋込み機能の一部となります。ワークフローは、そのワークフローの「開始」ステップの参加者として定義されているユーザーであれば、誰でも起動できます。たとえば、ユーザーの作成ワークフローを定義するとします。ワークフローに指定されたドメインのユーザーは、ユーザー・マネージャの「ユーザーの作成」機能からこのワークフローを起動できます。作成操作のために複数のワークフローが定義されている場合、そのオブジェクトの作成ページにリストが表示されます。
ユーザーは、属性の変更ワークフローも開始できます。属性の変更ワークフローは、ユーザーがアクセスを許可されているプロファイル・ページで使用できます。たとえば、プロファイル・ページに表示されるマネージャ属性に対してワークフローが定義されているとします。ユーザーは、所属部門を変更したときに、状況に応じて自分のマネージャの名前を変更するリクエストを発行する必要があります。このリクエストは、属性の変更ワークフローによって処理されます。
ユーザー・マネージャで、「アイデンティティ」をクリックし、次に「変更」をクリックします。
変更できるすべての属性の編集可能フィールドを含む「ユーザー・プロファイル」ページが表示されます。
「削除をリクエスト」または「変更をリクエスト」ボタンのあるプロファイル・ページの属性について、その属性値を削除または変更するリクエストを発行できます。
これらのボタンは、「削除をリクエスト」または「変更をリクエスト」アクションを伴う属性の変更ワークフローまたはサブフローが作成されている場合に表示されます。
リクエストは、チケットの形式で送信されます。このチケットを処理するユーザーは、リクエストを承認または否認できます。詳細は、「チケットの検索と処理」を参照してください。
ワークフローが開始されると、チケットの処理により後続のステップが生成されます。保留中のワークフロー・チケットは、ユーザー・マネージャ、グループ・マネージャおよび組織マネージャで検索できます。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャで、「リクエスト」をクリックします。
「リクエスト」ページで、「着信リクエスト」、「送信リクエスト」または「リクエストのモニター」をクリックします。
送信リクエストは、すでに処理済のチケットです。
「検索」リストで、リクエストを表示するアプリケーションを選択します。
テキスト・フィールドに日数を指定します。すべてのリクエストを表示する場合は、このフィールドを空白のままにします。
「実行」をクリックします。
ワークフロー・チケットのリストが表示されます。このリストは、検索基準に一致します。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャで、「リクエスト」をクリックします。
「リクエスト」ページで、「着信リクエスト」をクリックします。
「検索」リストで、リクエストを表示するアプリケーションを選択します。
テキスト・フィールドに日数を指定します。すべてのリクエストを表示する場合は、このフィールドを空白のままにします。
「実行」をクリックします。
ワークフロー・チケットのリストが表示されます。このリストは、検索基準に一致します。
着信リクエストのリンクをクリックします。
リクエストの詳細ページで、「プロセス」ボタンをクリックします。
このワークフローの参加者の場合、ワークフローの現在のステップに構成されている属性を含むページが表示されます。
このワークフローの必須属性を入力します。
たとえば、「ユーザーの作成」ステップの場合、状況により新規ユーザーの電子メール・アドレスを入力するよう求められます。このページで入力する必要のある情報は、ワークフローの現在のステップがどのように構成されているかにより決定されます。
ワークフローの現在のステップを完了するのに適切なボタンをクリックします。
たとえば、「ユーザーの作成」リクエストの場合、通常はこのチケットの詳細ページに「承認」ボタンと「否認」ボタンが含まれます。
アイデンティティ・システムで有効化されたユーザーは、非アクティブ化および再アクティブ化することが可能です。非アクティブ化されたユーザーは、アイデンティティ・システムにログインできなくなり、アイデンティティ・システムに表示されなくなります。非アクティブ化の効果は、ユーザーが現行セッションからログアウトした後に反映されます。「リクエストのモニター」権限を保持する管理者は、非アクティブなユーザーを参照し、それらのユーザーを永久に削除するか、再アクティブ化することが可能です。
|
注意: 非アクティブなユーザーと削除されたユーザー（およびユーザーが所属するグループ）に対する参照を削除するため、構成済のすべてのディレクトリが検索されます。ユーザー・データと構成データを別々に格納している場合、両方のディレクトリが同時に検索されます。 |
ユーザーを非アクティブ化するワークフローを定義する手順は、「ワークフロー・アプレットの使用方法」を参照してください。ワークフローが定義されると、十分な権限を保持するユーザーは、各ユーザーのプロファイル・ページで「ユーザーの非アクティブ化を開始」ボタンを参照できます。
ユーザーを非アクティブ化する手順は、ユーザーの非アクティブ化ワークフローで指定されているアクションに準拠します。
状況に応じて、非アクティブなユーザーを再アクティブ化できます。たとえば、休職中の従業員を非アクティブ化し、職場への復帰後にその従業員を再アクティブ化できます。
この目的に使用するユーザーの再アクティブ化ワークフローを定義します。
再アクティブ化ワークフローで許可されるアクションの概要は、「ワークフローのタイプ、ステップおよびアクション」を参照してください。ワークフローが定義されると、十分な権限を保持するユーザーは、非アクティブなユーザーのプロファイル・ページで「ユーザーの再アクティブ化の開始」ボタンを参照できます。
ユーザー・マネージャで、「非アクティブなユーザー・アイデンティティ」サブタブをクリックし、「非アクティブなユーザーの検索」ページを表示します。
検索を実行し、再アクティブ化するアイデンティティに対応する非アクティブなユーザー名を選択します。
「プロファイルの表示」ページが表示されます。
「プロファイルの表示」ページの「ユーザーの再アクティブ化の開始」ボタンをクリックします。
ユーザーが再アクティブ化されます。
|
注意: ユーザーを再アクティブ化する場合、そのユーザーを以前所属していたグループに手動で追加し、そのユーザーの属性ポリシーと検索ベースを再設定する必要があります。 |
ワークフローをモニターする権限を保持するユーザーは、他のユーザーが所有するリクエスト・チケットの状態など、ワークフローの進行状況を参照できます。
管理ドメイン内のリクエストのみがリストされます。詳細は、「管理の委任」を参照してください。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャで、「リクエスト」をクリックします。
「リクエストのモニター」をクリックします。
|
注意: サブフローでは、最初のステップが処理されていない場合、「処理日」フィールドは空白です。 |
「検索」フィールドで、検索基準を選択して「実行」をクリックします。
検索フィールドの下に結果が表示されます。
必要に応じて「次へ」または「前へ」をクリックし、他の結果を参照します。
チケットのリクエスト番号をクリックし、そのチケットの「リクエスト」ページを表示します。
このページには、ワークフローの現在のステップ番号がリストされます。
応答していない不完全なワークフローを削除するには、「リクエストのモニター」機能を使用してワークフローを特定し、「終了」ボタンをクリックします。完了したワークフローを終了するには、「ワークフローのモニター」機能の「削除」ボタンを使用します。
ワークフローをアーカイブすると、参加者と時間を記録に残せますが、ディレクトリから大量のデータが削除されます。ワークフローを周期的にアーカイブすると、Oblixツリーの肥大化を防げます。完了済のワークフローのみアーカイブできます。複数のアーカイブ操作により、このファイルに情報が追加されます。
アーカイブされたワークフローは、LDIF形式で保存されます。アーカイブ・データを格納するデフォルトの場所は、次のとおりです。
IdentityServer_install_dir/oblix/data/common/wfinstance.ldif
デフォルトの場所を変更して、アーカイブされたデータがアップグレード中に上書きされるのを防いでください。次のファイルでアーカイブ・ファイルの場所を制御します。
| ファイル名 | アプリケーション | |
|---|---|---|
usc_wf_params.xml |
ユーザー・マネージャ | |
gsc_wf_params.xml |
グループ・マネージャ | |
osc_wf_params.xml |
組織マネージャ |
一度にアーカイブするインスタンスは、最大で数百のみにすることをお薦めします。大量のインスタンスを選択すると数秒を要するため、アーカイブ操作中にサーバー・リソースが消費されます。
「ワークフローのモニタリング」の手順に従ってワークフロー・リクエストを表示します。
「すべて選択」列でリクエストを選択します。
「アーカイブ」をクリックします。
アーカイブの確認ページが表示されたら、「戻る」をクリックして前のページに戻ります。
|
注意: パラメータ・ファイルの変更後、アイデンティティ・サーバーを再起動する必要があります。 |
ワークフロー・リクエストは削除できます。
「ワークフローのモニタリング」の手順に従ってリクエストを表示します。
「すべて選択」列でリクエストを選択し、「削除」をクリックします。
削除の確認ページが表示されたら、「戻る」をクリックして前のページに戻ります。
実行時に、複数のユーザーがワークフロー・チケットを受信できます。たとえば、ITグループが「ワークフローの作成」リクエストのチケットを受信するとします。このリクエストを処理する管理者は、チケットをロックできます。これにより、他のユーザーは、ロックされたチケットの情報を参照できますが、チケットの操作はできなくなります。チケットのロックを解除できるのは、チケットをロックしたユーザー（マスター・アイデンティティ管理者）と、リクエストをモニターする権限を付与されているユーザーのみです。
「チケットを処理する手順」に従ってチケットをオープンします。
ワークフロー・チケットの処理時に、ワークフロー・ページに「チケットのロック」および「ロック解除」ボタンが表示されます。
必要に応じて「チケットのロック」または「ロック解除」を選択します。
ワークフローの定義後、それらのワークフローを表示、コピー、変更、削除およびエクスポートできます。
ステップや参加者などを含むワークフローのサマリーを表示して、そのレポートをカンマ区切り値（CSV）のファイルにエクスポートできます。
|
注意: 次の手順は、Microsoft Internet Explorerを使用しており、アイデンティティ・システム・インタフェース（Webパス）をWebGateで保護している場合に適用されます。「CSVにエクスポート」機能を有効化するには、次の2つのWebGateパラメータを構成する必要があります。CachePragmaHeader: 空白のままにします。 CacheControlHeader: 「プライベート」を指定するか、空白のままにします。 詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャにアクセスします。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
ワークフロー・メニューで、表示するワークフローを選択します。
「表示」を選択します。
「ワークフロー定義ビュー」ページが表示されます。
「ワークフロー定義ビュー」ページを拡大するか、右にスクロールしてワークフローのすべての内容を確認します。
「.csvファイルへのエクスポート」をクリックし、ワークフローのカンマ区切り値のファイルを保存します。
「閉じる」をクリックしてページを閉じます。
サンプルのCSVファイルをスプレッドシートで開くと、次のように表示されます。
ワークフローのコピーは、新規ワークフローの基盤として使用できます。また、保留中のチケットが多すぎて変更機能を適用できないワークフローを変更する場合にも、ワークフローのコピーを使用できます。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャにアクセスします。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
「ワークフロー」メニューで、コピーするワークフローを選択します。
「コピー」をクリックします。
ワークフローのコピーがリストに表示されます。
このワークフローは、コピー元の名前に「のコピー」が付いた名前になります。必要がない場合でも、コピーしたワークフローの名前は変更することをお薦めします。
必要に応じて情報を変更し、新規ワークフローを作成します。
かわりに変更するワークフローとしてワークフローをコピーする手順
前の手順に従ってワークフローをコピーします。
ワークフローに外部アクションが含まれる場合、新規ワークフローを参照するようoblixpppcatalogカタログ・ファイルを更新します。
詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
コピーを変更します。
ワークフローをアイデンティティ・システムからのみ起動する場合、これで作業は完了です。
ワークフローがPortal Insertsとして別のアプリケーションのWebページに埋め込まれている場合、新規ワークフローIDを参照するようワークフローのリンクを更新します。
ワークフローの作成後に、そのパラメータを変更できます。選択したワークフローに保留中のインスタンスが含まれる場合は、ターゲットのリスト、任意のステップの参加者、または任意のステップの事前通知と事後通知の受信者のみを変更できます。
|
注意: 保留中のチケットがある場合に変更できるのはワークフローの一部分のみであるため、非常にアクティブなシステムでは、ワークフローをコピーしてそのコピーを変更する必要があります。詳細は、「ワークフローのコピー」を参照してください。 |
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャにアクセスします。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
「ワークフロー」メニューで、変更するワークフローを選択します。
「変更」をクリックします。
選択したワークフローの情報が表示されます。「変更」をクリックすると、変更中に使用されないようにこのワークフローは無効化されます。
必要に応じてワークフロー設定を変更します。
「ワークフローの保存」をクリックして変更を保存します。
ワークフローの有効化を求めるプロンプトが表示されたら、「はい」をクリックします。
ワークフローに保留中のリクエストが含まれなければ、ワークフローを削除できます。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャにアクセスします。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
「ワークフロー」メニューで、削除するワークフローを選択します。
「削除」をクリックします。
確認メッセージが表示されたら、「OK」をクリックします。
すべてのワークフローをカンマ区切り値（CSV）のファイルにエクスポートできます。これは、印刷可能なテキスト・ファイルです。
|
注意: 次の手順は、Microsoft Internet Explorerを使用しており、アイデンティティ・システム・インタフェース（Webパス）をWebGateで保護している場合に適用されます。「CSVにエクスポート」機能を有効化するには、次の2つのWebGateパラメータを構成する必要があります。CachePragmaHeader: 空白のままにします。 CacheControlHeader: 「プライベート」を指定するか、空白のままにします。 詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャにアクセスします。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
ワークフロー・メニューで、エクスポートするワークフローを選択します。
「すべてをエクスポート」をクリックし、すべてのワークフローを含むカンマ区切り値のファイルを保存します。
「ユーザー・マネージャ、グループ・マネージャおよび組織マネージャの概要」で説明したとおり、ユーザー・マネージャ、グループ・マネージャおよび組織マネージャ・アプリケーションに表示される要素は構成可能です。ユーザー・マネージャおよびグループ・マネージャ・アプリケーションは1つのタブで構成され、組織マネージャは1つ以上のタブで構成されます。タブは、複数のプロファイル・ページの集合であり、プロファイル・ページ自体は複数のパネルの集合です。パネルは、属性と値のグループです。
これらのアプリケーションのプロファイル・ページに表示されるワークフロー・パネルは、参照および変更できます。
アイデンティティ・システム・コンソールで、「共通構成」をクリックします。
「共通構成」ページが表示されます。
「ワークフロー・パネル」をクリックします。
「ワークフロー・パネル」ページに構成済のワークフロー・パネルが表示されます。
次の表に、各パネルの説明を示します。
| パネル | 説明 |
|---|---|
| ワークフロー・モニター表 | ユーザーが「リクエストのモニター」ページでワークフロー検索を実行したときに、結果ページに含まれる列。 |
| ワークフロー・プロファイル・パネル | 「リクエストのモニター」ページでワークフロー・インスタンスに関して表示される情報。 |
| ワークフロー・ステップ・プロファイル・パネル | 「リクエストのモニター」ページでワークフロー・インスタンスのステップに関して表示される情報。 |
| チケット情報パネル | 「着信リクエスト」または「送信リクエスト」ページの「チケット情報」ページで表示される情報。 |
| チケット検索テーブル | ユーザーが「着信リクエスト」または「送信リクエスト」ページでワークフロー検索を実行したときに、結果ページに表示される情報。 |
表示するパネルをクリックします。
パネルに表示される項目が、「パネルの表示」ページに表示されます。
| パネル・フィールド | 説明 |
|---|---|
| パネル・ラベル | アイデンティティ・システムに表示されるパネルの名前。
このフィールドはローカライズできます。 |
| 説明 | このパネルの機能の説明。
このフィールドはローカライズできます。 |
| 属性 | パネルの列とその表示名に使用される属性。
このフィールドはローカライズできます。 |
ワークフロー・パネルは削除できませんが、変更することはできます。
アイデンティティ・システム・コンソールで、「共通構成」をクリックします。
「共通構成」ページが表示されます。
「ワークフロー・パネルの構成」をクリックします。
「ワークフロー・パネルの構成」ページに構成済のワークフロー・パネルが表示されます。
表示するパネルをクリックします。
「変更」をクリックします。
「パネルの変更」ページが表示されます。
「パネル・ラベル」フィールドに、アプリケーションに表示するこのパネルの新規名を入力します。
「説明」フィールドに説明を入力します。
「属性」フィールドで、アプリケーションに表示する順序で属性を選択します。
「保存」をクリックします。
パネル情報を複数の言語で表示する場合、ワークフロー・パネルをローカライズできます。これを行うには、次の操作を実行する必要があります。
適切な言語パックをインストールします。
管理コンソールで、インストールした言語ごとにパネルの表示情報を手動で入力します。
属性をローカライズする方法の詳細は、「アイデンティティ・システムでのスキーマ・データの使用」および「ユーザー・マネージャ、グループ・マネージャおよび組織マネージャの構成」を参照してください。
アイデンティティ・システム・コンソールで、「共通構成」をクリックします。
「共通構成」ページが表示されます。
「ワークフロー・パネルの構成」をクリックします。
「ワークフロー・パネルの構成」ページに構成済のワークフロー・パネルが表示されます。
表示するパネルをクリックします。
パネル名、説明、属性などのワークフロー・パネルの詳細がページに表示されます。
「翻訳」をクリックします。
|
注意: 「翻訳」ボタンは、2つ以上の言語パックがインストールされている場合にのみ表示されます。 |
「パネル表示名のサマリー」ページが表示されます。パネル・フィールドおよび属性の言語固有の表示名が表示されます。特定の言語でまだ翻訳されていないフィールドは、「未構成」としてマークされます。
「パネル表示名のサマリー」ページで、「変更」をクリックします。
「パネル表示名の構成」ページが表示されます。このページには、パネル情報と、インストール済言語のリンクが含まれます。
ワークフロー・パネルを構成する言語をクリックします。
選択した言語の「パネル表示名の構成」ページが表示されます。
次の情報を入力します。
パネル・ラベル: パネルの言語固有の表示名を入力します。
説明: パネルの簡単な説明を入力します。これはオプション設定です。
属性: 属性の各表示名に対して言語固有のテキストを入力します。
「保存」をクリックして変更を保存します。変更を保存せずにページを終了する場合は、「取消」をクリックします。
oblix/data/common/workflowdbparams.xmlファイルのWfInstanceNotRequiredフラグをtrueに設定すると、ディレクトリ・サーバーへのアクセスを削減できます。このフラグにより、必要な場合を除きディレクトリ・サーバーにワークフロー・インスタンスが書き込まれなくなります。デフォルト設定のfalseでは、ワークフロー・インスタンスはディレクトリ・サーバーに書き込まれます。
ワークフロー・パフォーマンスの詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
「アイデンティティ・システム管理者の指定」で説明したとおり、ユーザー・マネージャ、グループ・マネージャおよび組織マネージャを管理できるのは、アイデンティティ管理者のみです。
デフォルトでは、アイデンティティ管理者の属性アクセス制御は省略されます。その結果、属性の変更ワークフローを定義する場合に、そのワークフローの属性アクセス制御はアイデンティティ管理者に対してチェックされません。これらの管理者は自動的に変更権限を付与されますが、その他のユーザーは属性の変更をリクエストする権限のみを保持します。
この機能を制御するパラメータは、IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xmlに含まれるBypassAccessControlForDirAdminです。ディレクトリ管理者に自動的に変更権限を付与しない場合、このフラグをfalseに設定してアイデンティティ・サーバーを再起動します。
アイデンティティ管理者に対して、属性の変更ワークフローで属性を変更する権限と、属性の変更をリクエストする権限を付与できます。IdentityServer_install_dir/identity/oblix/apps/userservcenter/bin/userservcenter.xmlなどの各アプリケーション・パラメータ・ファイルで、checkChangeAttributeEvenAllowModifyパラメータをtrueに設定できます。この設定により、管理者は、属性の変更を許可されている場合でも入力ボタンとワークフロー・ボタンの両方を参照できます。このパラメータは、ワークフローの変更権限と開始権限を両方とも保持する管理者に適用されます。ただし、この機能により、パフォーマンス・オーバーヘッドが発生する可能性があります。
次の拡張オプションを使用できます。
ワークフロー・アクションへのカスタム・コードの追加
ワークフロー・アクションの動作の構成
アイデンティティ・イベント・プラグインAPIを使用して、カスタム・コードをワークフロー・アクションに追加できます。ワークフローでアイデンティティ・イベント・プラグインAPIを使用する一般的な例は、次のとおりです。
外部システムによる値（一意のIDなど）の自動生成
ワークフロー・ステップのデータの検証
外部システムのデータの更新
カスタム・コードを記述したら、そのコードをワークフロー・アクションの前（事前アクション）か、ワークフロー・アクションの後（事後アクション）に実行するようoblixpppcatalogファイルでアイデンティティ・システムに指示する必要があります。
詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
外部アクションは事前アクションおよび事後アクションと同じ目的で使用しますが、アイデンティティ・イベント・プラグインAPIのアクションとは次の2つの点で異なります。
外部アクションは、既存のアクションに追加しません。
ルーティング・パスは、外部アクションの終了状態に基づいて完全に構成可能です。
外部アクション・コードは、oblixpppcatalogファイルにフックとして実装します。詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
ユーザー・マネージャ、グループ・マネージャおよび組織マネージャには、それぞれ参加者に表示するデータと選択可能なアクションを制御するためのワークフロー・パラメータ・ファイルがあります。
各パラメータ・ファイルには、次の3つのセクションが含まれます。
オブジェクトの作成
オブジェクトの削除
属性の変更
ファイルは次の場所にあります。
IdentityServer_install_dir/identity/oblix/apps/applicationname/bin/
ここで、IdentityServer_install_dirはアイデンティティ・サーバーのインストール・ディレクトリであり、applicationnameは次のいずれかです。
usc_wf_params.xml: ユーザー・マネージャ
gsc_wf_params.xml: グループ・マネージャ
osc_wf_params.xml: Org Manager
次の表に、各パラメータの説明を示します。
| パラメータ | 説明 | 設定例 |
|---|---|---|
| occurrence | このアクションをワークフロー内で使用できる回数を示します。 | [1] [n]
1: アクションは1回のみ使用できます。 n: アクションは複数回使用できます。 |
| useraction | ステップが対話型であるかどうかを示します。 | [true] [false]
true: アクションにはユーザー操作が必要です。 false: これはバックグラウンド・ステップであり、ユーザー操作は必要ありません。 |
| forceCommit | このアクションがコミットではない場合でも、このステップに暗黙的コミットを発行するかどうかを示します。暗黙的コミットにより、収集されたすべてのデータが特定のターゲット・エントリに書き込まれます。 | [true] [false]
true: 暗黙的コミットを発行します。 false: 暗黙的コミットを発行しません。 |
| pre_action | 前のステップのアクションがこのリストに含まれる場合、現在のアクションを指定できることを示します。 | [アクションのリスト] |
| exit_condition | 特定のアクションに使用可能な結果を示します。 | [終了状態のリスト]
たとえば、次のようになります。 true: 1 false: 0 |
| relevant_data | このステップに構成可能な関連データのタイプを示します。バックグラウンド・ステップには、関連データは含まれません。 | [関連データのリスト]
Required、ProvisionedまたはOptionalの任意の組合せを使用できます。 |
| initialStep | 開始、自己登録または承認ステップに適用できるパラメータ。 | 値はtrueとfalseです。 |
デフォルトでは、ワークフロー定義アプレットで使用できるのは、「すべてのユーザー」ロールのみです。ディレクトリに定義されているロールをワークフロー定義アプレットに追加するには、ユーザー・マネージャ、グループ・マネージャおよび組織マネージャのワークフロー・パラメータ・ファイルを変更します。
次の手順では、すべてのDNロールをワークフロー・アプレットに表示する方法について説明します。
「属性の構成」の手順に従って「属性の変更」アプレットを表示します。
Personオブジェクト・クラス、またはPersonオブジェクト・クラスに関連付けられた補助オブジェクト・クラスについて、DNデータ型の属性を選択します。
たとえば、「マネージャ」属性を選択します。
「表示タイプ」リストで、選択した属性に対して「オブジェクト・セレクタ」表示タイプを選択します。
「ターゲット・オブジェクト・クラス」リストで、gensiteOrgPersonなどのPersonオブジェクト・クラスを選択します。
すべてのロールが次の手順に従って有効化されているかぎり、ワークフロー・アプレットに属性がロールとして表示されます。
「保存」をクリックします。
次のワークフロー・パラメータ・ファイルを編集します。
ユーザー・マネージャ: usc_wf_params.xmlを開きます。
グループ・マネージャ: gsc_wf_params.xmlを開きます。
組織マネージャ: osc_wf_params.xmlを開きます。
<CompoundList ListName="Roles">セクションに移動します。
適切なワークフロー・タイプを見つけます。
たとえば、オブジェクトの作成ワークフローを変更するには、<CompoundList ListName="CREATE_OBJECT">を見つける必要があります。
このファイルのParticipant（参加者）またはNotifee（通知先）セクションを見つけます。
たとえば、<ValNameList ListName="Participant">セクションを編集します。
次の行を追加します。
<NameValPair ParamName="dns" Value="dns"/>
自己登録により、ユーザーは、自分自身または所属する組織をWebページから直接アイデンティティ・システムに追加できます。アイデンティティ・システムには、自己登録用のユーザー・インタフェースはありません。登録フォームを表示するURLを構成する必要があります。
自己登録を行うユーザーは、初回のログイン試行後にパスワードを再設定するよう求められる場合があります。この動作は、「リセット時に変更」フィールドの設定に応じて変化します（「パスワード・ポリシーの構成」を参照してください）。複数のユーザーが同じブラウザ・セッションを使用して自己登録を行う場合に、「リセット時に変更」オプションが選択されていると、最初のユーザー以降のすべてのユーザーは、初回のログイン後にパスワードを変更するよう求められます。
自己登録後にユーザーをアイデンティティ・システムに自動的にログインさせる場合は、basedbparams.xmlファイルのSelfRegGeneratesSSOCookieをtrueに設定する必要があります。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
自己登録ページのカスタマイズ方法の詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
次の手順では、Basic認証の自己登録ワークフローについて説明します。
アイデンティティ・システム・コンソールで、「ユーザー・マネージャ」、「グループ・マネージャ」または「組織マネージャ」を選択します。
組織マネージャに複数のタブがある場合は、適切なタブを選択してください。
「構成」をクリックし、次に「ワークフロー定義」をクリックします。
最初のステップに「自己登録」を使用して、ユーザーの作成または組織の作成ワークフローを定義します。
このワークフローにアクセスし、ワークフローの識別名とターゲット・ドメインを記録します。
この情報を自己登録URLに追加します。
次のように自己登録URLをHTMLドキュメントに追加します。
https://domain_name:port/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi?program=workflowSelfRegistration&ObWorkflowName=workflow_DN&ObDomainName=target_domain
変数は次のとおりです。
domain_name:port: ホスト・システムのドメイン名とポート番号。
workflow_DN: ワークフローのDN。
target_domain: 名前を除くターゲット・パス。
ObDomainName target_domainの値は、自己登録ワークフローに定義されているターゲット・ドメインです。詳細は、「オブジェクトの作成ワークフローのLDAPターゲットの定義」を参照してください。
組織の自己登録では、次の形式を使用します。
https://domain_name:portnumber/identity/oblix/apps/objservcenter/ bin/objservcenter.cgi?program=workflowSelfRegistration&tab_id=tab_ name&ObWorkflowName=workflow_DN&ObDomainName=target_domain
変数は次のとおりです。
domain_name:portnumber: ホスト・システム
tab_name: タブの名前
workflow DN: ワークフローのDN
target_domain: 名前を除くターゲット・パス
自己登録用のURLは、認証を必要としないページを参照している必要があります。自己登録URLは、通常の/identity/oblix/apps/userservcenter/bin/userservcenter.cgiではありません。一般的に、ユーザーがアイデンティティ・システムにアクセスすると、アクセス・システムにより認証を求められます。ただし、自己登録ページおよびロスト・パスワード・ページにアクセスするユーザーについては、認証を要求しないようWebGateを設定する必要があります。
予約文字をURL準拠のテキスト代替文字で置き換えます。
DNパスを動的拡張URLで指定する場合、URLの予約文字（英数字以外）を、%とそれに続く文字のASCII 16進表現でエンコードする必要があります。たとえば、次のようになります。
%3D: 等号（=）
%2C: カンマ
%20: 空白
たとえば、次のようになります。
cn=Engineering Team, ou=Engineering, o=Company, c=US
置換後の文字列:
cn%3DEngineering%20Team%2C%20ou%3DEngineering%2C%20o%3DCompany%2C%20c%3DUS
HTMLファイルを保存します。
次に、自己登録URLの例を示します。
http://silicon/identity/oblix/apps/userservcenter/bin/userservcenter.cgi?program=w orkflowSelfRegistration&obdomainname=o%3DCompany%2Cc%3DUS&obworkflowname=obworkflo wid%3D20020605T1132216476%2CobcontainerId%3Dworkflowdefinitions%2co%3Doblix%2Co%3Dconfigdata
組織マネージャでは、ビジネス・ロケーションを管理し、特定のユーザーにそのロケーションの管理を許可するワークフローを作成できます。個々のユーザーまたは特定のロール（ファシリティ・マネージャなど）を保持するユーザーを選択するか、IT事業部などの特定のグループを選択することが可能です。
ユーザーが組織のロケーションを参照できるようにするには、ロケーション・マップの.gifイメージをワークフローに追加します。ユーザーがロケーションをクリックすると、建物が位置する領域のマップがロケーション・プロファイルに表示されます。
新規ロケーション・ワークフローを作成したら、その新規ワークフローを使用してロケーション・オブジェクトを作成できます。これを行うには、組織マネージャの「組織プロファイルの作成」機能を使用します。または、ロケーション・オブジェクトを先に作成し、そのオブジェクトを既存のワークフローにリンクできます。ロケーション・オブジェクトを作成したら、マップ上の特定の場所にユーザーなどの他のオブジェクトを割り当てることができます。
|
注意: ロケーションIDに「DN接頭辞」セマンティク型が含まれる場合、Active DirectoryおよびADAMでは、複数値のRDNが許可されないことに注意する必要があります（iPlanet/SunOneでは使用可能）。Active DirectoryおよびADAMでは、メタ属性構成で「属性値」の選択が「単一」になっていることを確認してください。 |
ロケーション・オブジェクトの作成後、ロケーション機能を使用可能にして、ユーザーまたはオブジェクトのロケーションを表示する適切な権限を備えたユーザーを有効化する必要があります。
組織マネージャの「ロケーション」タブを変更し、ロケーション属性をユーザー・マネージャと組織マネージャのプロファイル・ページに追加します。
詳細は、「組織マネージャでの「ロケーション」タブの有効化」および「タブのプロファイル・ページおよびパネルの構成」を参照してください。
ロケーション属性に対する読取り権限を構成します。
詳細は、「ユーザーによるLDAPデータの表示および変更の許可」を参照してください。
「タスクの概要: ロケーションの作成ワークフローの定義」の説明に従って、ロケーションの作成ワークフローを定義します。
新規ロケーションを作成し、必要に応じて他のロケーションに関連付けられたロケーション階層を確立します。
詳細は、「オブジェクト・クラスの追加」を参照してください。
ユーザーまたはオブジェクト・プロファイルのロケーション属性の値を割り当てます。
詳細は、「ワークフロー・アプレットの使用方法」を参照してください。
|
注意: 属性値は、ワークフローを使用する以外に、オブジェクト・プロファイル・ページでも追加および変更できます。 |
ワークフロー定義を開始します（「新規ワークフロー定義の開始」を参照してください）。
必要に応じて1つ以上のサブフローを作成します（「サブフローの概要」を参照してください）。
|
注意: メイン・ワークフローを開始する前にサブフローを作成する必要があります。これにより、サブフローをメイン・ワークフローにリンクできます。 |
ワークフローに関連付ける属性を選択します（「ステップ属性の定義」を参照してください）。
使用可能なデフォルトのロケーション属性は、「ロケーションID」、「ロケーション名」、「ロケーション・タイトル」および「マップ・イメージ」です。「ロケーションID」と「ロケーション名」は、必須属性です。
参加者を指定します（「ワークフローの最初のステップの定義」を参照してください）。
ワークフロー・プロセスを定義します（「ステップ・アクションの概要」を参照してください）。
ワークフローを保存します。
ワークフローを有効化します（「ワークフローの有効化」を参照してください）。
ワークフローをテストしてその妥当性を検証します（「ワークフローのテスト」を参照してください）。
