审批策略示例

以下示例展示了应用程序、维、节点类型和层次集级别的审批策略，并演示如何使用各种策略设置处理审批。

示例 1：应用程序级别审批策略

首先，让我们看一个简单示例，以了解在基本级别上审批的工作原理。在此示例中，在应用程序级别有一个审批策略，指示至少需要 GL Govern 组中的两个人批准对会计科目表的所有更改。

表 29-1 示例 1：应用程序级别策略设置

Fusion GL 应用程序 维 节点类型 层次集
策略 A
  • 审批组：GL Govern
  • 方法：并行
  • 必需总数：2 个批准者
 帐户维 帐户节点类型 帐户层次集

GL Govern 组包括 Barry、Julie 和 Jane。Tom 是 Fusion GL 应用程序的所有者。

审批工作流：

  1. Mark 提交请求以添加帐户并更新成本中心描述。
  2. 因为审批方法为并行，请求将发送给 GL Govern 组中的所有三个成员以进行审批。
  3. Julie 批准该请求。
  4. Barry 批准该请求。
  5. 策略要求得到满足，请求被最终提交。

示例 2：死锁升级

现在，让我们再次看一下同一个示例，但这次 Barry 和 Jane 已调出 GL Govern 组。

表 29-2 示例 2：死锁升级策略设置

Fusion GL 应用程序 维 节点类型 层次集
策略 A
  • 审批组：GL Govern
  • 方法：并行
  • 必需总数：2 个批准者
 帐户维 帐户节点类型 帐户层次集

GL Govern 组仅包括 Julie。Tom 是 Fusion GL 应用程序的所有者。

审批工作流：

  1. Mark 提交请求以添加帐户并更新成本中心描述。
  2. 将向 Julie 发送审批请求。
  3. Julie 批准该请求。

    策略需要两个来自 GL Govern 组的批准者，但 Julie 是该组中的唯一人员。由于没有更多批准者来满足策略要求，这将导致死锁。结果是，请求将升级到对该应用程序具有数据管理员权限的用户。因为 Tom 是应用程序的所有者，他的所有者权限包括数据管理员权限。

  4. 该请求将升级到 Tom。
  5. Tom 批准该请求。
  6. 策略要求得到满足，请求被最终提交。

示例 3：维级别顺序审批策略

接下来，让我们看一个维级别的顺序类型策略。在此示例中，Josh 必须批准请求，然后是 Frank，最后是来自 Accounting 组的某个人员。

表 29-3 示例 3：维级别顺序策略设置

应用程序 维 节点类型 层次集
Planning 应用程序

帐户维

策略 A
  • 审批组：Josh、Frank、Accounting
  • 方法：顺序
  • 必需总数：3 组
 帐户节点类型 帐户层次集

Accounting 组包括 James 和 Heather。

审批工作流：

  1. Mark 提交请求以移动三个帐户。
  2. 将向 Josh 发送审批请求。
  3. Josh 批准该请求。
  4. 将向 Frank 发送审批请求。
  5. Frank 批准该请求。
  6. 将向 Accounting 组（James 和 Heather）发送审批请求。
  7. Heather 批准该请求。
  8. 策略要求得到满足，请求被最终提交。

示例 4：节点类型和层次集级别审批策略

应用程序和维级别的审批策略适用于所有请求操作，而节点类型和层次集级别的策略仅适用于特定请求操作。节点类型上的策略仅适用于添加或删除节点或者更新节点属性的请求。层次集上的策略仅适用于在层次集中插入、移除、移动节点或对节点重新排序的请求，或者更新节点关系属性的请求。

为说明这些准则，让我们看一个示例：有两个请求，在节点类型和层次集上设置了策略。第一个是更新节点属性的请求，所以仅节点集上的策略适用。第二个是添加帐户的请求，将影响节点类型和层次集，因此两个策略都适用。

表 29-4 示例 4：节点类型和层次集级别策略设置

应用程序 维 节点类型 层次集
Planning 应用程序

帐户维

帐户节点类型

策略 A
  • 审批组：Accounting、TaxUsers
  • 方法：并行
  • 每组一次审批：True

帐户层次集

策略 B
  • 审批组：EssAdmins
  • 方法：并行
  • 每组一次审批：False
  • 必需总数：5 次审批

关于这些请求的一些其他背景：

  • Accounting 组包括 James 和 Heather。
  • TaxUsers 组包括 Brian、Jane 和 Rachel。
  • EssAdmins 组中有七个管理员（EssAdmin1 至 EssAdmin7）。

首先，让我们看一个更新节点属性的请求。节点属性更新仅受节点类型上的策略影响。

请求 1 审批工作流：

  1. Mark 提交请求以更新三个帐户描述（节点属性更新）。
  2. 将向 Accounting 和 TaxUsers 组发送审批请求。

    注：

    因为节点属性更新不影响层次集，所以 EssAdmins 组不会收到审批请求。
  3. James 为 Accounting 组批准该请求。
  4. Rachel 为 TaxUsers 组批准该请求。
  5. 策略要求得到满足，请求被最终提交。

接下来，让我们看第二个请求，这次是添加节点。像以前一样，节点类型上的策略适用，因为该请求操作将添加节点。但是对于此请求，层次集上的策略也适用，因为添加操作将在基于层次的视点中创建插入操作。

请求 2 审批工作流：

  1. Mark 提交请求以添加三个新帐户。
  2. 将向 Accounting 和 TaxUsers 组发送审批请求。
  3. 因为基于层次的视点中的添加操作还会在层次集中创建插入操作，所以还将向 EssAdmins 组发送审批请求。
  4. James 为 Accounting 组批准该请求。

    注：

    因为 James 只对节点类型具有隐式参与者（读取）权限（而对层次集没有），所以他必须在请求检查器中批准该请求。请参阅“策略和权限”。
  5. Rachel 为 TaxUsers 组批准该请求。

    注：

    因为 Rachel 只对节点类型具有隐式参与者（读取）权限（而对层次集没有），所以她必须在请求检查器中批准该请求。请参阅“策略和权限”。
  6. 五个 Essbase 管理员批准该请求。

    注：

    因为 EssAdmins 组对层次集具有隐式参与者（读取）权限，所以还被授予了对节点类型的隐式参与者（读取）权限。他们可以打开视图并浏览层次集以批准该请求。请参阅“策略和权限”。
  7. 策略要求得到满足，请求被最终提交。

示例 5：启用了扩充的审批

如果在审批策略上启用了扩充，则对请求涉及的视图中的任何数据对象具有参与者（写入）访问权限的批准者都可以在批准之前修改请求。

在此示例中，在具有视点的维护视图中针对三个应用程序发出了请求：General Ledger、Planning 和 Consolidation。每个应用程序都有一个应用程序级别的审批策略，并且 GL 和 Planning 策略启用了扩充。

表 29-5 示例 5：启用了扩充的审批

General Ledger 应用程序 Planning 应用程序 Consolidation 应用程序
GL 审批策略
  • 审批组：Josh（General Ledger 管理员）

    注：

    Josh 对 Planning 应用程序具有参与者（写入）权限。
  • 方法：顺序
  • 必需总数：1
  • 是否启用扩充？是
 Planning 审批策略
  • 审批组：Julie（Planning 管理员）

    注：

    Julie 对 Consolidation 应用程序具有参与者（写入）权限。
  • 方法：顺序
  • 必需总数：1
  • 是否启用扩充？是
 Consolidation 审批策略
  • 审批组：Accounting
  • 方法：顺序
  • 必需总数：1
  • 是否启用扩充？否

审批工作流：

  1. Mark 提交请求，要求在 General Ledger 应用程序中添加成本中心。
  2. 系统向 GL 管理员 Josh 发送审批请求。
  3. Josh 通过向 Planning 应用程序添加成本中心来扩充请求，然后批准针对 GL 应用程序的请求。
  4. 由于 Josh 向 Planning 应用程序添加了节点，因此激活了 Planning 审批策略，并向 Planning 管理员 Julie 发送了审批请求。
  5. Julie 通过向 Consolidation 应用程序添加成本中心来进一步扩充请求，然后批准针对 Planning 应用程序的请求。
  6. 激活 Consolidation 审批策略，并向 Accounting 组发送审批请求。
  7. Accounting 组成员 Barry 批准针对 Consolidation 应用程序的请求。由于未在 Consolidation 策略中启用扩充，因此 Barry 无法进一步扩充请求。
  8. 在满足所有审批策略的策略要求后，最终提交请求并向这三个应用程序添加成本中心。