承認ポリシーの例

例1: アプリケーション・レベルの承認ポリシー

まず、承認が基本的なレベルでどのように機能するかを示す単純な例を見てみましょう。この例では、GL Governグループの少なくとも2人が勘定体系へのすべての変更を承認する必要があることを示すアプリケーション・レベルの承認ポリシーがあります。

GL GovernグループはBarry、JulieおよびJaneで構成されます。Tomは、Fusion GLアプリケーションの所有者です。

承認ワークフロー:

1. 勘定科目を追加し、コスト・センターの説明を更新する要求の送信をマークします。
2. 承認方法は並列であるため、要求はGL Governグループのメンバー3人すべてに承認のために送信されます。
3. Julieは要求を承認します。
4. Barryは要求を承認します。
5. ポリシー要件が満たされ、要求がコミットされます。

例2: デッドロック・エスカレーション

もう一度同じ例を見てみましょう。ただし今回は、BarryとJaneはGL Governグループから移動されています。

GL GovernグループはJulieでのみ構成されています。Tomは、Fusion GLアプリケーションの所有者です。

承認ワークフロー:

1. 勘定科目を追加し、コスト・センターの説明を更新する要求の送信をマークします。
2. 承認要求はJulieに送信されます。
3. Julieは要求を承認します。

   ポリシーではGL Governグループの承認者が2人必要ですが、そのグループに含まれるのはJulieのみです。ポリシー要件を満たすために必要な承認者が他にいない場合、この結果はデッドロックとなります。結果として、要求は、アプリケーションに対するデータ・マネージャ権限を持つユーザーにエスカレーションされます。Tomはアプリケーションの所有者であるため、この所有者権限にはデータ・マネージャ権限が含まれます。

4. 要求はTomにエスカレーションされます。
5. Tomは要求を承認します。
6. ポリシー要件が満たされ、要求がコミットされます。

例3: ディメンション・レベルのシリアル承認ポリシー

次に、ディメンション・レベルのシリアルタイプ・ポリシーを見てみましょう。この例では、Joshは要求を承認し、次にFrank、最後にAccountingグループの誰かが承認します。

AccountingグループはJamesおよびHeatherで構成されます。

承認ワークフロー:

1. 3つの勘定科目を移動する要求の送信をマークします。
2. 承認要求はJoshに送信されます。
3. Joshは要求を承認します。
4. 承認要求はFrankに送信されます。
5. Frankは要求を承認します。
6. 承認要求はAccountingグループ(JamesおよびHeather)に送信されます。
7. Heatherは要求を承認します。
8. ポリシー要件が満たされ、要求がコミットされます。

例4: ノード・タイプおよび階層セット・レベルの承認ポリシー

アプリケーションおよびディメンション・レベルの承認ポリシーはすべての要求アクションに適用されますが、ノード・タイプおよび階層セット・レベルのポリシーは特定の要求アクションにのみ適用されます。ノード・タイプのポリシーは、ノードを追加または削除する要求、またはノード・プロパティを更新する要求にのみ適用されます。階層セットのポリシーは、階層セットにおけるノードの挿入、除去、移動または並替えの要求、またはノード関係プロパティの更新の要求にのみ適用されます。

これらの原則を表すために、ノード・タイプと階層セットの両方に対するポリシーのある例の2つの要求を見てみましょう。最初の要求はノード・プロパティを更新するため、ノード・セット上のポリシーのみが適用されます。2番目の要求は勘定科目を追加しますが、これはノード・タイプと階層セットの両方に影響するため、両方のポリシーが適用されます。

これらの要求のその他の背景:

• AccountingグループはJamesおよびHeatherで構成されます。
• TaxUsersグループは、Brian、JaneおよびRachelで構成されます。
• EssAdminsグループには、7人の管理者がいます(EssAdmin1からEssAdmin7)。

まず、ノード・プロパティを更新する要求を見てみましょう。ノード・プロパティの更新は、ノード・タイプのポリシーによってのみ影響されます。

要求1承認ワークフロー:

1. 3つの勘定科目の説明を更新する要求(ノード・プロパティ更新)の送信をマークします。
2. 承認要求はAccountingおよびTaxUsersグループに送信されます。

   注:

   ノード・プロパティの更新は階層セットに影響を及ぼさないため、EssAdminsグループは承認要求を受信しません。
3. JamesはAccountingグループの要求を承認します。
4. RachelはTaxUsersグループの要求を承認します。
5. ポリシー要件が満たされ、要求がコミットされます。

次に、2番目の要求(今回はノードの追加)を見てみましょう。前回と同じように、ノード・タイプのポリシーが適用されますが、これは要求アクションによりノードが追加されるためです。ただし、この要求では、追加アクションにより階層ベースのビューポイントにアクションが挿入されるため、階層セットのポリシーも適用されます。

要求2承認ワークフロー:

1. 3つの新規勘定科目を追加する要求の送信をマークします。
2. 承認要求はAccountingおよびTaxUsersグループに送信されます。
3. 階層ベースのビューポイントでの追加アクションにより、階層セットでの挿入アクションが作成されるため、承認要求はEssAdminsグループへも送信されます。
4. JamesはAccountingグループの要求を承認します。

   注:

   Jamesはノード・タイプに対する暗黙的な参加者(読取り)権限を持っていますが、階層セットに対しては持っていないため、要求インスペクタで要求を承認する必要があります。ポリシーおよび権限を参照してください。
5. RachelはTaxUsersグループの要求を承認します。

   注:

   Rachelはノード・タイプに対する暗黙的な参加者(読取り)権限を持っていますが、階層セットに対しては持っていないため、要求インスペクタで要求を承認する必要があります。ポリシーおよび権限を参照してください。
6. 5人のEssbase管理者が要求を承認します。

   注:

   EssAdminsグループは階層セットに対する暗黙的な参加者(読取り)権限を持っているため、ノード・タイプに対する暗黙的な参加者(読取り)権限も付与されます。ビューを開き階層セットを参照して、要求を承認できます。ポリシーおよび権限を参照してください。
7. ポリシー要件が満たされ、要求がコミットされます。

例5: エンリッチメントが有効な承認

承認ポリシーでエンリッチメントが有効になっている場合、要求のビュー内の任意のデータ・オブジェクトに対して参加者(書込み)アクセス権を持つ承認者は、承認する前に要求を変更できます。

この例では、一般会計、Planningおよび連結の3つのアプリケーションのビューポイントがあるメンテナンス・ビューで要求が実行されます。各アプリケーションには、アプリケーション・レベルの承認ポリシーがあり、GLおよびPlanningのポリシーのエンリッチメントが有効になっています。

承認ワークフロー:

1. Markは、一般会計アプリケーションにコスト・センターを追加する要求を送信します。
2. 承認要求は、GL管理者のJoshに送信されます。
3. Joshは、Planningアプリケーションにコスト・センターを追加して要求をエンリッチした後、GLアプリケーションの要求を承認します。
4. JoshがPlanningアプリケーションにノードを追加したことで、Planning承認ポリシーがアクティブ化され、承認要求がPlanning管理者のJulieに送信されます。
5. Julieは、連結アプリケーションにコスト・センターを追加して要求をさらにエンリッチした後、Planningアプリケーションの要求を承認します。
6. 連結承認ポリシーがアクティブ化され、承認要求が会計グループに送信されます。
7. 会計グループのメンバーであるBarryは、連結アプリケーションに対する要求を承認します。連結ポリシーではエンリッチメントが有効になっていないため、Barryは要求をさらにエンリッチすることはできません。
8. すべての承認ポリシーのポリシー要件が満たされると、要求がコミットされ、3つのアプリケーションすべてにコスト・センターが追加されます。