Oracle Approvals Managementインプリメンテーション・ガイド リリース12 E06007-01

目次

前へ

次へ

Oracle Approvals Managementの実装

Oracle Approvals Managementの実装

概要

AMEには、組織に必要な承認プロセスをプログラム・コードを記述せずに作成する柔軟性が備わっています。AMEの機能と柔軟性を利用するには、承認プロセスが計画どおりに機能するように、実装時に細部まで十分に注意を払う必要があります。

次の図は、AMEの実装プロセスを表しています。組織の要件によっては、一部の実装ステップを省略できることがあります。一部のステップを省略すると思われる場合でも、すべての実装ステップを必ず理解するようにしてください。

組織の承認プロセスの計画

AMEのトランザクション・タイプの使用を開始する前に、トランザクション・タイプで実装する必要がある承認プロセスを文書化することをお薦めします。トランザクション・タイプの要件文書では、次のことを指定します。

• ビジネス・ケースのセット

• AMEでビジネス・ケースを表す方法。各ビジネス・ケースを表すために十分な構成変数値、項目区分使用、必須属性値、承認者グループおよびルール使用のセットを定義します。

• 各ビジネス・ケースに対する代表的なテスト・ケース。

ビジネス・ケース

トランザクション・タイプの要件文書では、次の4種類のビジネス・ケースを考慮する必要があります。

• 承認プロセスの構造が同じトランザクション

• デフォルトの承認者リストに繰返し承認者が含まれているトランザクション

• 承認者が例外的な方法で承認要求を転送するトランザクション

• 承認プロセスで類似のパラレル化を使用する必要があるトランザクション

承認ケース

最初のビジネス・ケースでは、一般的な承認要件を考慮します。このようなケースでは、組織で同じとみなされる属性値が設定されているトランザクションのセットに対して、必要な承認の種類を非形式的に指定します。たとえば、次のようなビジネス・ケースがあります。

合計額が、$1,000を超過し、かつ$5,000以下の旅費に関するすべての経費精算書は、発行者の直属の2人の管理者から承認を受ける必要があります。

承認のビジネス・ケースは通常、ルール使用、rulePriorityModes構成変数の値、および必須属性使用の組合せに直接変換されます。ビジネス・ケースで、権限チェーンではなく承認者グループからの承認が必要である場合、変換には承認者グループの定義も含まれる可能性があります。

繰返し承認者のケース

繰返し承認者のケースでは、承認ルールで、承認者が単一のトランザクションの承認者リストに複数回出現することが必要な場合のAMEの動作方法を示します（AMEでは、指定したケースでは繰返し承認者を抑制できます）。このビジネス・ケースは、repeatedApprovers構成変数に対する単一のトランザクション・タイプ固有の値に直接変換されます。

特別な転送のケース

特別な転送のケースとは、たとえば、承認者が承認者リスト内の上位の承認者、またはリストにすでに含まれていない下位の承認者に転送する場合などです。8つの特別なケースがあり、これらは、forwardingBehaviors構成変数に対する8つのトランザクション・タイプ固有の値に変換されます。

パラレル化のケース

パラレル化のケースでは、承認者リストを構成する承認者階層の同一レベルに位置する、同じ承認者サブセット内の承認者をAMEで処理する方法を示します。次の6つのレベルがあります。

• 項目区分

• 項目

• サブリスト

• 処理タイプ

• グループまたはチェーン

• 承認者

要件文書で、各レベルの同じサブセット内の承認者が、順次またはパラレルのいずれで順序付けされるかを指定する必要があります。たとえば、「他の条件がすべて同じ場合、同じ処理タイプによって生成される承認者は、パラレルで順序付けされる必要があります。」のように記述します。

AMEでのビジネス・ケースの表現

通常、承認のビジネス・ケースをトランザクション・タイプに変換する方法は複数あります。たとえば、ルール優先順位を使用することによって、より少数または単純なルールを使用できる場合があります。一般的に、承認のビジネス・ケースをトランザクション・タイプに変換するには、複数のトランザクション・タイプ固有の構成変数に対する値の設定、項目区分使用の作成、複数の必須属性に対する使用の定義、承認者グループの定義およびルールとルール使用の作成などを実行します。

構成変数

承認のビジネス・ケースの実装時に考慮する必要がある構成変数は、次のとおりです。

• adminApprover

• allowAllApproverTypes

• allowAllItemClassRules

• allowFyiNotifications

• productionFunctionality

• purgeFrequency

• repeatedApprovers

• distributedEnvironment

• currencyConversionWindow

• rulePriorityModes

• forwardingBehaviors

項目区分使用

ビジネス・ケースの実装時に、所定のトランザクション・タイプに付属の項目区分以外の項目区分を使用する必要がある場合があります。考えられる理由は2つあります。1つは、新規項目区分内の各項目に対して、個別の値を持つ属性を定義する場合です。この結果、これらの属性に対する条件を定義することになるため、ルールでは項目ごとに異なる内容を考慮できます。もう1つは、項目区分内の各項目に対する承認者リストがAMEで生成されるようにする場合です。

必須属性

承認のビジネス・ケースの実装に関連する必須属性は、次のとおりです。

• ALLOW_DELETING_RULE_GENERATED_APPROVERS

• ALLOW_REQUESTOR_APPROVAL

• AT_LEAST_ONE_RULE_MUST_APPLY

• EFFECTIVE_RULE_DATE

• EVALUATE_PRIORITIES_PER_ITEM

• REJECTION_RESPONSE

• REPEAT_SUBSTITUTIONS

• USE_RESTRICTIVE_ITEM_EVALUATION

• USE_WORKFLOW

• WORKFLOW_ITEM_KEY

• WORKFLOW_ITEM_TYPE

承認者グループ

承認者グループをトランザクション・タイプに作成するか、または組み込む必要があります。ビジネス・ケースで、AMEでサポートされている承認者階層の権限チェーンとして存在していない承認者グループの承認者が必要な場合は、その承認者を含む承認者グループを定義する必要があります。承認者グループを定義すると、AMEでは、AMEに付属のすべての処理タイプ内に、関連する承認グループ処理が自動的に作成されます。実装時に簡単に参照できるように、ビジネス・ケースに必要な承認者グループを要件文書にリストすると便利です。リストには、各グループの名称、摘要およびメンバーシップ・リストを含める必要があります。メンバーは順序付けされている必要がありますが、オーダー番号は一意である必要はありません。たとえば、グループのすべてのメンバーにオーダー番号1を割り当てた場合、そのグループは通常、パラレルで通知されます。

ルールとルール使用

組織で使用する承認ルールが多数ある場合、ルールを承認マトリックスまたは決定ツリーで表すと分かりやすくなることがあります。承認マトリックスは単なる表であり、1つのルールに1行を使用します。一番右の列には処理を1つ以上記述します。他の列には、所定の属性に対する許容値のセットを記述します。次に示す表は、経費精算書の承認マトリックスの一部です。この例では、ルールは、経費カテゴリと経費精算書の合計にのみ依存しています。

（この表が一部であるのは、重要なビジネス・ケースが考慮されていないためです。たとえば、旅費の合計額が$5,000を超える経費精算書が考慮されていません。実際の承認マトリックスでは通常、承認が必要ない場合や依頼元の承認のみを必要とする場合も含めて、ビジネス・ケースがすべて列挙される必要があります。）

決定ツリーには通常、各属性に対して1つのノード列があり、各ブランチの先には、そのノードが表す属性に対する許容値のセットを表すノードがあります。最終（リーフ）ノードは処理を表し、ルート・ノードからリーフ・ノードへのパスはルールを表します。次の決定ツリーは、前述の承認マトリックスの一部と同じです。

決定ツリーは承認マトリックスより柔軟性があります。これは、決定ツリーでは、ルート・ノードからリーフ・ノードへのすべてのパスに沿って同じ属性を同じ順序にする必要がないためです。この結果、決定ツリーは、承認ルールの条件が、同じ属性セットですべて定義されるとは限らない場合に適しています。また、決定ツリーがビジネス・ケースをすべて表しているかどうかの検証が複雑になります。決定ツリーを使用してルール・セットを表す場合は、ビジネス・ケースと、ルート・ノードからリーフ・ノードへのツリーのパスが1対1対応であることを確認してください。

ルール・セットの表現方法に関係なく、次の提案に留意してください。

• 承認を必要とするすべてのビジネス・ケースをルールで記録していることを確認すること

• 所定のビジネス・ケースに対して矛盾する結果をルールが表していないことを確認すること

• 所定のトランザクションに適用するルールの数を最小限に抑えること

• トランザクション・タイプ内のルールの合計数を最小限に抑えること

テスト・ケース

テスト・ケースはビジネス・ケースを表す必要があります。トランザクション・タイプの有効な属性（つまり、トランザクション・タイプが使用するルールで使用される処理タイプで必要であるか、またはこのようなルールで使用される条件によって参照される必須の全属性）それぞれに対する値を指定してください。テスト・ケースでは、テスト・ケースの属性値に応じてAMEで生成される必要がある承認者リストも指定する必要があります。AMEでは、トランザクション・タイプを本番に移行する前に、テスト環境内のトランザクション・タイプのテスト・ケースすべてに対して、適切な承認プロセスを作成する必要があります。

テスト・ケースは、適切な統合アプリケーションでトランザクションとして作成すると便利な場合があります。この方法では、アプリケーションで承認者リストを表示することによってアプリケーションのAME統合をテストでき、AMEのテスト・ワークベンチに承認者リストを表示することによってAMEの動作をテストできます。また、テスト・ケースの属性値をテスト・ワークベンチのテスト・トランザクション・ページで繰返し入力することによる、単調な作業やエラーの可能性が回避されます。

パラレル承認プロセス

承認プロセスのパラレル化によって、トランザクションの承認プロセス時間が短縮されます。パラレル承認プロセスによって、トランザクションの承認者リストに階層（ツリー）構造が適用され、ツリーの特定レベルの各部分で、それぞれの通知-承認サイクルを非同期で進行できるようになります。この結果、トランザクション内の各項目の承認プロセスは、トランザクション内の他の項目の承認プロセスの進行に関係なく処理を続行でき、トランザクションの承認プロセス時間が短縮されます。

パラレル化の詳細な動作は、次のとおりです。

• AMEエンジンによって、各レベルのパラレル化構成に基づいて承認者ツリーが構成されます。

• アプリケーションによって、承認者ツリーの各レベルおよび各リーフの承認者に対するオーダー番号が計画されます。

• 相互にパラレルである複数のノードの承認プロセスが同時に開始されます。

• それ以降は、各ノードの承認プロセスが他と関係なく進行します。

承認者リスト

単一のトランザクションの承認者リストは、階層（逆ツリー）構造であり、6つの下位レベルがあります。ルートから下位方向に向かって次のレベルがあります。

• 項目区分

• 項目

• サブリスト

• 処理タイプ

• グループまたはチェーン

• グループまたはチェーン・メンバー

1つ上のレベルの単一オブジェクトに対して、特定のレベルのオブジェクトが多数存在する場合があります。

次の図は、パラレル承認プロセスの例を示しています。

図の例の承認者リスト・ツリーでは、次の8つの承認が必要です。

• A

• B

• C

• D

• P

• Q

• R

• S

たとえば、図からわかるように、「ヘッダー」項目区分の下のサブツリーは、「明細項目」項目区分の下のサブツリーの承認プロセスとは関係なく独立して進行します。これは、この2つの項目区分のオーダー番号が同じであるためです。承認者A、B、CおよびDの進行は、項目区分がパラレルであるため、承認者P、Q、RおよびSの進行とは関係ありません。パラレル承認プロセスは、次のように進行します。

• AとPに通知されます。

• Aが承認します。

• Bに通知されます。

• Bが承認します。

• Cに通知されます。

• Pが承認します。

• Qに通知されます。

• QとCが承認します。

• DとRに通知されます。

• Dが承認します。

• この段階で、Dの後に承認する承認者がいないため、AMEから承認者は戻されません。

• Rが承認します。

• Sに通知されます。

• Sが承認します。

• AMEで承認プロセスが完了します。

各項目区分に対する承認プロセスと、引き続き各項目に対する承認プロセスを同時に開始することにした場合は、パラレルで実行されるサブプロセスが3つとなります。ヘッダーのプロセスはAから開始されます。明細項目1はPから、明細項目2はRから開始されます。

トランザクションの承認プロセスをさらに短縮するために、グループまたはチェーン内のすべての承認者に同時に通知できます。この結果、ヘッダーのプロセスはA、B、CおよびDへの通知で開始されます。これらの承認者がすべて承認すると、ヘッダーの承認プロセスは完了します。この方法では、トランザクションの承認プロセス全体の中で最も長いサブプロセスに必要となるのは、2つの通知-承認サイクルのみです。承認者のオーダー番号については、リストは次のようになります。

1. 1 - A

2. 1 - B

3. 1 - C

4. 1 - D

5. 1 - P

6. 2 - Q

7. 1 - R

8. 2 - S

例に戻ると、項目区分と項目レベルで承認をパラレル化するという決定は、オーダー番号1をすべての項目区分に割り当て、各項目区分のパラレル化モードをパラレルに設定することになります。同様に、トランザクションの承認者グループと権限チェーンをパラレル化するという決定は、承認者グループ1と2に対して合意投票制度を選択することになります。例での最終的な承認者リスト（前述のオーダー番号とオーダー・モードの決定と一致）は、次のようになります。

1. 1 - A

2. 1 - B

3. 1 - C

4. 1 - D

5. 1 - P

6. 2 - Q

7. 1 - R

8. 2 - S

抑制される繰返し承認者

承認者リストに繰返し承認者が含まれている場合、AMEでは、構成変数repeatedApproversに選択したオプションに基づいて、動的な方法で抑制されます。関連項目: 構成変数

繰返し承認者には、承認プロセス中の最初の出現時に通知されます。たとえば、承認がパラレルで進行する2つの項目の場合を考えてみます。項目1には、3人の承認者M、NおよびOが設定され、項目2には3人の承認者T、WおよびOが設定されています。承認者は、項目ごとに順次に通知されます。繰返し承認者機能を使用すると、項目2におけるOの出現が繰返しに設定されます。ただし、承認プロセス時に、項目2の承認の進行状況によっては、項目1におけるOの出現が繰返しになります。

承認プロセスをパラレル化する方法

この項では、承認者リスト・ツリーの各レベルおよび承認者リスト・ツリーと同じレベルで使用可能な承認プロセス・パラレル化オプションについて説明します。ツリーの特定のレベルに対してオプションを選択する方法については、対応するトピックを参照してください。

承認者リスト・ツリーの各レベルの承認プロセス・パラレル化オプションは、次のとおりです。

項目区分

項目区分のパラレル化は、項目区分オーダー番号を使用して明確に管理されます。このオーダー番号は、トランザクション・タイプによって、項目区分使用が設定されている項目区分に割り当てられます。

項目

項目区分使用のパラレル化モードによって、項目区分の項目の項目オーダー番号が決まります。モードがシリアルの場合、項目の項目オーダー番号は順次で、項目IDの昇順です。モードがパラレルの場合は、すべての項目に項目オーダー番号1が割り当てられます。

サブリスト

項目区分のサブリスト・モードによって、項目区分の項目の承認者リストにあるサブリストのサブリスト・オーダー番号が決まります。次の4つのオプションがあります。

• 「シリアル」モードでは、前承認者にサブリスト・オーダー番号1、権限承認者にサブリスト・オーダー番号2、後承認者にサブリスト・オーダー番号3が割り当てられます。

• 「パラレル」モードでは、すべての承認者にサブリスト・オーダー番号1が割り当てられます。

• 「まず前承認者、それから権限および後承認者」では、前承認者にサブリスト・オーダー番号1が割り当てられ、他の承認者にサブリスト・オーダー番号2が割り当てられます。

• 「まず前承認者および権限承認者、それから後承認者」では、前承認者と権限承認者にサブリスト・オーダー番号1が割り当てられ、後承認者にサブリスト・オーダー番号2が割り当てられます。

これらのモードはすべて、シリアル・モードを除いて、前承認者/権限承認者/後承認者という命名体系が意味する順序とある程度一致します。つまり、いずれのサブリスト・モードの場合も、前承認者が権限承認者または後承認者の後に承認することはなく、権限承認者が後承認者の後に承認することもありません。

処理タイプ

処理タイプ・パラレル化は、トランザクション・タイプによって処理タイプに割り当てられた処理タイプ・オーダー番号を使用して、明確に管理されます。

承認者リスト・ツリーと同じレベルの承認プロセス・パラレル化オプションは、次のとおりです。

承認者グループと権限チェーン

承認者グループと権限チェーンは、承認者リスト・ツリーの同じレベルに存在するため、グループまたはチェーンのオーダー番号を共有します。

• 承認者グループ

  承認者グループ・パラレル化は、トランザクション・タイプによって承認者グループに割り当てられた承認者グループ・オーダー番号を使用して、明確に管理されます。

• 権限チェーン

  トランザクション・タイプによって、権限チェーンを生成する各処理タイプに、権限チェーンのオーダー・モードが割り当てられます。シリアル・モードでは、チェーンに対して、チェーンの生成順に、昇順のグループまたはチェーンのオーダー番号が割り当てられます。パラレル・モードでは、すべてのチェーンに対して、グループまたはチェーンのオーダー番号1が割り当てられます。

承認者グループと権限チェーンのメンバー

承認者グループのメンバーと権限チェーンのメンバーは、承認者リスト・ツリーの同じレベルに存在するため、グループまたはチェーン・メンバーのオーダー番号を共有します。

• 承認者グループのメンバー

  前承認または後承認者グループとして機能する承認者グループでは、グループの投票制度を使用して、そのメンバーのグループまたはチェーン・メンバーのオーダー番号が決定されます。また、静的メンバーに割り当てられるメンバー・オーダー番号または動的メンバー用に生成されるメンバー・オーダー番号も決定される場合があります（動的メンバーには、グループのSQL問合せからメンバーが戻される順序に従って、順次のメンバー・オーダー番号が割り当てられます）。承認者グループの投票制度には4つの値のいずれかを設定できます。値によって、グループまたはチェーン・メンバーのオーダー番号のみでなく、すべてのグループ・メンバーまたはいずれかのメンバーが項目を承認する必要があるかどうかも決定されます。

  • 「シリアル」制度では、グループまたはチェーン・メンバーのオーダー番号が、メンバー・オーダー番号の昇順に割り当てられます。同じ番号の場合は適宜調整されます。

  • 「合意」制度では、グループまたはチェーン・メンバーのオーダー番号1がすべてのメンバーに割り当てられます。すべてのグループ・メンバーが承認する必要があります。

  • 「最初の応答者が獲得」制度では、グループまたはチェーン・メンバーのオーダー番号1がすべてのメンバーに割り当てられます。この場合、最初の応答者のみが承認する必要があります。他のメンバーの応答はすべて、記録されますが無視されます。

  • 「オーダー番号」制度では、各メンバーのグループまたはチェーン・メンバーのオーダー番号がメンバーのメンバー・オーダー番号に設定されます。すべてのグループ・メンバーが承認する必要があります。

• 権限チェーン・メンバー

  権限チェーンを生成する処理タイプには投票制度があります。投票制度では、処理タイプによって生成される権限チェーン内の承認者について、グループまたはチェーン・メンバーのオーダー番号が決定されます。（これは、承認者グループ権限チェーン処理タイプによって生成される権限チェーンについても当てはまります。この処理タイプでは、使用するグループの承認者グループ投票制度は無視されます。）処理タイプの投票制度には、承認者グループの投票制度に対して許容されている値（オーダー番号制度以外）を設定できます。

AMEのロールと職責

Oracle Approvals Managementでは、アクセス・レベルの定義にロールと職責が使用されます。次の2つのレベルでセキュリティが提供されています。

• データ・セキュリティ。限定されたユーザー・ロールについて、トランザクション・タイプへのアクセス権限を定義できます。

• 機能セキュリティ。ビジネス・アナリストおよび管理者について、AME機能（モジュール）へのアクセス権限を定義できます。

  機能セキュリティを実装するために、AMEで次の内容が事前定義されています。

  • 権限。オブジェクトに対するユーザーのアクセス権限を決定するために使用できるセキュリティ機能です。

  • 権限セット。権限やナビゲーション機能、権限セットのグループです。これらのセットは、権限の階層を作成するために使用されます。

  • ロール。ユーザーまたはユーザーのグループに割り当てることができる汎用機能セットです。

権限セット

独自のロールを作成する場合は、次の事前定義の権限セットを使用して、ユーザーによる各ページへのナビゲートを許可または禁止します。

注意: ユーザーが複数のページにアクセスできるようにするには、個々の権限セットを明示的に付与する必要があります。たとえば、ユーザーが更新ページにアクセスできるようにし、同時に詳細を表示できるようにするには、表示権限を明示的に付与する必要があります。

職責

Oracle Applicationsのユーザーには、AMEを使用するための2つの使用可能なAMEエンド・ユーザー職責のいずれかが必要です。1つは非技術（ビジネス）ユーザー用の職責、もう1つは技術（管理）ユーザー用の職責です。このマニュアルの残りの部分では、AMEユーザー・インタフェース機能に管理権限が必要な場合は示します。それ以外の場合、このマニュアルで説明する機能にはビジネス・ユーザー職責でアクセスできると判断してください。

AMEでは、次の職責が事前定義されています。

• 承認管理ビジネス・アナリスト。この職責を使用すると、SQLまたはPL/SQLプログラミングの専門知識、あるいはOracle Applicationsの技術的な知識を必要としないユーザー・インタフェースの領域にアクセスできます。

• 承認管理管理者。AMEのユーザー・インタフェースに対するフル・アクセス権限があります。通常、AMEの構成変数の設定などの技術タスクを実行するために、AMEで最低1人のユーザーに管理権限を付与する必要があります。

注意: 既存の利用者の場合は、これらの職責を既存ユーザーに割り当てていることを確認する必要があります。承認管理: アップグレード後処理を実行して、既存ユーザーを新規職責に移行する必要があります。関連項目: Oracle Approvals Managementの実装

ロール

次のロールが事前定義されています。

• 承認管理プロセス・オーナー: ビジネス・ダッシュボード、属性、条件、処理タイプ、承認者グループ、テスト・ワークベンチ、ルールへの表示のみのアクセス権限があります。設定レポート・ページへのアクセス権限もあります。

• 承認管理システム・ビューワ: 管理ダッシュボードおよび設定レポートへの表示のみのアクセス権限があります。

• 承認管理ビジネス・アナリスト: ビジネス・ダッシュボードの表示アクセス権限のほか、属性、条件、グループ、テスト、ルールの作成、更新、削除権限付きのアクセス権限があります。また、設定レポート・ページおよびトランザクション固有の構成値を変更する権限付きの構成変数ページへのアクセス権限があります。処理の作成、更新、削除、および処理タイプの構成値の作成、更新、削除はできますが、処理タイプの作成、更新、削除はできません。

• 承認管理システム管理者: 管理ダッシュボード・アクセス権限、設定レポート、例外ログ・アクセス権限、トランザクション・タイプ固有の値を定義する権限付きの構成変数アクセス権限があります。トランザクション・タイプを作成、更新、削除できます。

• 承認管理管理者: ビジネス・アナリストおよびシステム管理者のすべてのアクセス権限があります。処理タイプを作成、更新、削除できます。デフォルトの構成値を変更できます。

Oracle Approvals Managementの実装

AMEを実装するには、次のステップを実行する必要があります。

1. アプリケーションをインストールします。

   AMEのインストール・ルーチンおよび管理機能によって、AMEを使用できるアプリケーションが決定されます。インストールと管理は通常、技術者の仕事です。インストールは一般的に1回のみ実施されます。管理タスク（AMEの管理者ダッシュボードを使用）が必要となるのは通常、新規アプリケーションでAMEを使用可能にする場合、またはトランザクションのエラー・ログにアクセスするか、エラー・ログを消去する場合のみです。

2. 次の作業を完了してAMEのセキュリティを設定します。

   • 事前定義のロールをユーザーまたはユーザーのグループに結び付けます。

     AMEでは、ユーザーにAME機能へのアクセス権限を提供するために、ロール・ベースのアクセス・モデル（RBAC）が使用されます。このアクセス・モデルには、次の事前定義ロールがあります。

     • 承認管理管理者

     • 承認管理アナリスト

     • 承認管理システム・ビューワ

     • 承認管理システム管理者

     • 承認管理プロセス・オーナー

     5つの事前定義ロールのそれぞれに、固有の機能付与セットがあります。付与によって、ユーザーにAMEへのアクセス権限が提供されます。機能付与を使用可能にするには、「ユーザー管理」ページを使用してユーザーにロールを割り当てる必要があります。「ユーザー管理」ページにアクセスする方法の詳細は、『Oracle Applicationsシステム管理者ガイド - セキュリティ』を参照してください。

     ユーザーのアクセス権限を設定する手順は、次のとおりです。

     1. 管理者としてログインします。

     2. 「ユーザー管理」職責を選択します。

     3. 「ユーザー」ページを選択します。

     4. AMEロールを付与するユーザーを検索します。

     5. 結果の表で、「更新」をクリックします。「ユーザーの更新」ページで、ユーザーの詳細をユーザーが使用できるロールのリストとともに表示できます。

     6. 「ロールの割当」をクリックします。

     7. 結果のリストからロールを選択し、「適用」をクリックします。

     5つの事前定義ロールのいずれかをユーザーに割り当てた場合は、AME職責を間接的にユーザーに割り当てたことになります。

     注意: 要件にあわせてカスタム・ロールを作成できます（ 『Oracle Applicationsシステム管理者ガイド - セキュリティ』を参照）。ロールに対する権限セットの詳細は、「AMEのロールと職責」を参照してください。

   • データ・アクセス権限をユーザーに付与します。

     AMEでは、データ・セキュリティを使用してトランザクション・タイプへのアクセスが制限されるため、トランザクション・タイプへのアクセス権限をユーザーに付与するには、「付与」ページを使用します。ユーザーのアクセス権限を設定する手順は、次のとおりです。

     1. 管理者としてログインします。

     2. 「機能管理者」職責を選択します。

     3. 「付与」タブを選択します。

     4. 「付与の作成」をクリックします。

     5. 被付与者タイプとして「特定のユーザー」を選択します。

     6. 被付与者キーとしてユーザーを選択します。

     7. オブジェクトとしてAMEトランザクション・タイプを選択します。

        1. すべての行: すべてのAMEトランザクション・タイプに対するアクセス権限がユーザーに付与されます。

        2. インスタンス: 次のパラメータで指定した特定のAMEトランザクション・タイプに対するアクセス権限が付与されます。FND_APPLICATION_ID => トランザクション・タイプが属しているアプリケーションのアプリケーションID。TRANSACTION_TYPE_ID => アプリケーション内のAMEトランザクション・タイプの一意の識別子。

        3. インスタンス・セット: 次のパラメータで指定した1つ以上のAMEトランザクション・タイプに対するアクセス権限が付与されます。

           • 事前定義のインスタンス・セットであるAMEトランザクション・タイプ・インスタンス・セットを使用します。

           • 次のページで、「パラメータ1」にFND_APPLICATION_ID、「パラメータ2」にTRANSACTION_TYPE_IDに対するワイルドカード検索文字列を選択します。

     8. 次のページには、インスタンス・タイプに対する3つのオプションがあります。権限セットとして「AME呼出しアプリケーション」を選択します。

     9. 確認して完了します。

     詳細は、『Oracle Applicationsシステム管理者ガイド - セキュリティ』を参照してください。

   注意: 既存の利用者の場合は、既存のユーザーに承認管理ビジネス・アナリストおよび承認管理管理者の職責があることを確認する必要があります。承認管理: アップグレード後処理を実行して、既存ユーザーを新規職責に移行する必要があります。関連項目: 承認管理: アップグレード後処理の実行

3. ユーザー・プロファイル「AME: インストール済」を設定します。

   このユーザー・プロファイルはAMEで事前定義されており、AMEを使用するInternet ExpensesやiProcurementなどの統合アプリケーションで使用できます。このプロファイルはアプリケーション・レベルで設定され、そのアプリケーションによって、AMEがインストールされているかどうか、およびインストールされている場合は実行する処理を判別するために使用されます。場合によっては、この判別は、そのアプリケーションの承認プロセスにAMEを使用するかどうかの判断に使用されますが、必ず使用されるわけではありません。統合アプリケーションでこのユーザー・プロファイルを使用するかどうかについては、そのアプリケーション固有のマニュアルを参照してください。

4. トランザクション・タイプを構成します。

   アプリケーション管理者は、AMEがインストールされ、そのセキュリティが設定された後すぐに、AMEの構成変数の値を確認する必要があります。AMEには、次の種類の構成変数があります。

   • 単一の値の構成変数

     AMEの構成変数distributedEnvironmentには、すべてのアプリケーションに対する単一の値が設定されます。この変数では、AMEのコンピューティング環境の様々な側面が記述されます。この値は、AMEが正しく機能するように設定する必要があります。

   • トランザクション・タイプ固有の変数

     他のAME構成変数には、各トランザクション・タイプに対する値の他に、デフォルト値を設定できます。これらの変数は、次のとおりです。

     • adminApprover

     • allowAllApproverTypes

     • allowAllItemClassRules

     • allowFyiNotifications

     • currencyConversionWindow

     • forwardingBehaviors

     • productionFunctionality

     • purgeFrequency

     • repeatedApprovers

     • rulePriorityModes

     これらの変数は、AMEによるトランザクション・タイプの承認プロセスの生成方法に関する多くの側面を決定するもので、必須属性と同じです。異なる点は、これらの値は常に、トランザクション・タイプ内のすべてのトランザクションに対して固定であることです。AMEを使用する前に、これらの変数のデフォルト値をそのまま使用できることを確認してください。

注意: 古いトランザクション・データを削除するには、コンカレント・マネージャからパージ・ユーティリティを毎日実行する必要があります。このタスクに失敗すると、結果的にパフォーマンスが低下し、特定のAMEデータベース表のサイズが無制限に大きくなります。関連項目: トランザクション・データのパージ

トランザクション・タイプの実装

トランザクション・タイプを実装するには、必要に応じて、承認プロセスの次のコンポーネントを指定または作成する必要があります。

1. 項目区分使用を作成します（オプション）。

   トランザクション・タイプで実装する承認プロセスを文書化した後は、トランザクション・タイプの実装を開始できます。最初のステップは、トランザクション・タイプに必要なカスタムの項目区分使用を登録することです。

2. トランザクション属性を作成します（オプション）。

   AMEでは、属性は、TRANSACTION_AMOUNTなどの名前付きのビジネス変数であり、その値は、実行時にAMEによって、トランザクションの承認者リストが構成されるときにフェッチされます。アプリケーション管理者職責のあるユーザーのみが（「属性」タブを使用して）属性を作成または変更できます。これは、この作業には通常、SQL問合せの入力または変更が必要であるためです。

   AMEには、AMEを使用できる各アプリケーションのトランザクション・タイプに通常必要となる属性が含まれています。組織でアプリケーションをカスタマイズしているか、またはアプリケーションでフレックスフィールドを定義していて、これらをアプリケーションの承認プロセスで使用する場合は、AMEアプリケーション管理者職責のあるユーザーが、カスタマイズまたはフレックスフィールドを表す新規属性名を作成し、これらの値を実行時にフェッチするSQL問合せを定義する必要があります。ビジネス・ユーザーがAMEルールに対する条件を作成する際に選択できるのは、既存の属性のみです。

3. 条件を作成します（オプション）。

   AMEでは、条件によって、トランザクションへのルール適用に必要な属性値のリストまたは範囲が指定されます。次に例を示します。

   USD1000 < TRANSACTION_AMOUNT < USD5000

   条件は、「条件」タブを使用して作成および保守します。

4. 承認者グループを作成します（オプション）。

   AMEルールを作成して、1つ以上の承認者グループをトランザクションの承認者リストに含めることができます。承認者グループは、「承認者グループ」タブを使用して作成および保守します。承認者グループを承認グループ・ルールで使用する前に、その承認者グループを作成する必要があります。また、既存の承認者グループを承認グループ・ルールに追加することもできます。

5. 処理タイプを使用する準備をします。

   「処理タイプ」タブを使用して、処理タイプをトランザクション・タイプに追加します。使用可能な処理タイプは、次のとおりです。

   • 事前定義の処理および承認者タイプ

     AMEには、多数の事前定義の処理タイプとそれに対する処理が用意されています。事前定義の処理タイプでは現在、（HR管理階層内の）HR従業員、（HR職階階層内の）HR職階、およびOracle Applications（FND）ユーザーの3種類の承認者がサポートされています。事前定義の処理タイプは、様々な方法でHR階層をさかのぼります。

     処理によって、トランザクションの承認者リストに含められる承認者が決定されます。通常、処理タイプによって、トランザクションの承認者リストに階層から適切な権限チェーンが組み込まれ、特定の組織階層をさかのぼる方法が表されます。また、承認の内容によってチェーンの開始位置と終了位置が指定されます。組織で、AMEの事前定義処理タイプでさかのぼることができない組織階層からの承認を要求する場合は、カスタムの処理タイプを使用する必要があります。カスタムの処理タイプを作成する手順の詳細は、AME開発者ガイドを参照してください。

   • カスタムの処理タイプおよび承認者タイプ

     AMEでは、ワークフロー・ディレクトリ・サービスに登録された元システムからの承認者（つまり、ワークフローで承認者として機能可能なエンティティ）をサポートできます。組織で、AMEの事前定義処理タイプによって生成される権限チェーンと構成が異なる権限チェーンが必要な場合、またはAMEでまだサポートされていない元システムの承認者からの承認が必要な場合は、カスタムの処理タイプのコーディングを選択することもできます。これには膨大なプログラミング作業が必要となり（一般的な処理タイプ・ハンドラPL/SQLパッケージのコードは数百行です）、アプリケーション管理者が結果のPL/SQLパッケージをAMEに登録する必要があります。また、事前定義以外の承認者タイプをAMEに登録する必要もあります。現在、承認者タイプを登録するユーザー・インタフェースはなく、SQL*Plusのコマンド行から登録する必要があります。承認者タイプをユーザー自身で登録するよりも、組織で必要な承認者タイプをサポートするパッチのリリースをAME開発に要求することをお薦めします。

   • 既存の承認タイプへの承認の追加

     組織で、AMEの事前定義の処理タイプを使用することを計画する場合がありますが、追加処理が必要な場合があります。たとえば、管理レベルの処理タイプには、管理階層に対して最大10レベルの処理が用意されています。組織に15レベルある場合は、レベル11から15に対する管理レベルの処理を作成する必要があります。アプリケーション管理者は、「処理」タブを使用してこれらの処理タイプを追加できます。

   • 役職レベル承認タイプの使用準備

     組織で役職レベルの処理タイプの1つを使用することを計画している場合は、最初にHRMSで定義されている各役職に役職レベルを割り当てる必要があります（つまり、HRMS表per_jobsのapproval_authority列に移入する必要があります）。組織では、役職レベルを保守するためのビジネス・プロセスも設定する必要があります。

6. 承認ルールを定義します。

   項目区分使用、属性、条件、承認者グループ、処理タイプおよび処理の準備が完了すると、「ルール」タブを使用して承認ルールを作成できます。ここでも、承認マトリックスまたは決定ツリーが便利なチェックリストとして役立つ場合があります。

   AMEでは、承認ルールによって、1つ以上の条件が承認処理に関連付けられます。ルールがトランザクションに適用されるのは、ルールの条件すべてがトランザクションに該当する場合のみです。

   AMEを使用できる各アプリケーションでは、1つ以上のトランザクション・タイプが定義されます。各トランザクション・タイプには独自の承認ルール・セットがあります。複数のトランザクション・タイプで属性名を共有できますが、それぞれの属性名に対して別々の使用を定義できます。この結果、複数のトランザクション・タイプによる条件とルールの共有が可能になります。関連項目: 属性の使用

7. 承認ルールをテストします。

   トランザクション・タイプにルール・セットを設定した後は、そのルールをテストして、適切なケースに適用されること、および論理的な欠落や矛盾がないことを確認することが重要です。これらのテスト・ケースは、後で再利用するために保存できます。

   トランザクション・タイプをテストする方法は、次の3通りあります。

   • 統合アプリケーションでトランザクションを作成し、アプリケーションのユーザー・インタフェースを使用してトランザクションの承認者リストを表示する方法

   • 統合アプリケーションでトランザクションを作成し、AMEの「テスト・ワークベンチ」タブを使用してトランザクションの承認者リストを表示する方法

   • AMEの「テスト・ワークベンチ」タブを使用して、テスト・トランザクションを作成し、その承認者リストを表示する方法

8. カスタム・トランザクション・タイプを作成します。

   たとえば、カスタム・アプリケーションに対する承認エンジンとしてAMEを使用する場合には、カスタム・トランザクション・タイプを新しく作成できます。トランザクション・タイプの作成については、このマニュアルでは説明しません。組織でカスタム・トランザクション・タイプを作成する必要がある場合は、Oracleサポートに連絡して、『Oracle Approvals Management Developer Guide』を入手してください。関連項目: トランザクション・タイプの作成

9. AMEを使用するようにOracle Applicationsを構成します。

   AMEを使用するようにOracle Applicationを構成する作業は、そのアプリケーションのトランザクション・タイプに対して定義されているルール・セットをAMEで十分にテストした後で実施してください。AMEを使用するようにアプリケーションを構成する方法については、アプリケーションのユーザー・マニュアルまたは技術マニュアルを参照してください。

トランザクション・データのパージ

パージ・ユーティリティを実行して、古いトランザクション・データを削除できます。構成変数purgeFrequencyに必要な値を設定すると、トランザクション・データの保持日数を定義できます。関連項目: 構成変数

トランザクション・データをパージする手順は、次のとおりです。

「要求の発行」ウィンドウを使用します。

1. システム管理者職責を使用して、「要求の発行」ウィンドウにナビゲートします。

2. 要求名に「承認管理トランザクション・データ・パージ」と入力します。

3. 「パラメータ」ウィンドウがオープンしていない場合は、「パラメータ」フィールドをクリックします。デフォルトで「パラメータ」ウィンドウがオープンしている場合は、次のステップで指定されているパラメータ詳細を入力します。

4. パージ対象の古いデータがあるトランザクション・タイプを選択します。

5. パージするトランザクションを選択します。完了済、処理中、承認済および否認済のすべてのトランザクションをパージできます。

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

7. 「発行」をクリックして、古いトランザクション・データをパージします。

承認管理: アップグレード後処理の実行

既存の利用者の場合は、既存のユーザーに承認管理ビジネス・アナリストおよび承認管理管理者の職責があることを確認する必要があります。承認管理: アップグレード後処理を実行して、既存ユーザーをこれらの職責に移行する必要があります。

「要求の発行」ウィンドウを使用します。

承認管理: アップグレード後処理を実行する手順は、次のとおりです。

1. システム管理者職責を使用して、「要求の発行」ウィンドウにナビゲートします。

2. 要求名に「承認管理: アップグレード後処理」と入力します。

3. 「パラメータ」ウィンドウがオープンしていない場合は、「パラメータ」フィールドをクリックします。デフォルトで「パラメータ」ウィンドウがオープンしている場合は、次のステップで指定されているパラメータ詳細を入力します。

4. 移行するために、次のいずれかを行います。

   • 既存のユーザーを移行する場合は、「MIGRATE_USERS」を選択します。

   • 項目区分使用を移行する場合は、「MIGRATE_ITEM_CLASS_USAGES」を選択します。

   • ユーザーおよび項目区分使用を移行する場合は、「MIGRATE_ALL」を選択します。

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

6. 「発行」をクリックして、既存ユーザーを承認管理ビジネス・アナリストおよび承認管理管理者の職責に移行します。

Copyright © 2001, 2006, Oracle. All rights reserved.