该简单示例演示如何进行策略排序。 在该示例中,假设策略规则始终被评估。
如果某事件具有多个始终被评估的策略,那么要使得该事件本身被批准,必须批准所有策略。 然而,如果与事件(策略评估类型为“ALWAYS”)关联的策略被拒绝,那么就会拒绝事件本身。
注意:如果与事件关联的策略的评估类型为 Onchange,则与包含在该策略内的属性关联的更改被拒绝。 事件本身不会被拒绝且评估行中的下一策略。
在该示例中,Policy1 、 Policy2 和 Policy3 都有 ALWAYS 的策略评估类型。 Policy1 评估为假,则名为 Process1 的工作流流程不会执行,且不会为 User1 生成任何工作项。 事件控制立即传递给 Policy2。 Policy2 和 Policy3 都评估为真。 由于工作流 Process2 具有较高优先级,所以首先运行并为 User2 生成工作项。
如果 User2 批准该工作项,工作流 Process3 即会运行并为 User3 生成工作项,而 User3 随后必须批准该工作项,才能使得该事件本身获得批准。 这些操作如下表所示:
|
优先级 |
策略 |
结果 |
工作流 |
批准人 |
操作 |
|---|---|---|---|---|---|
|
1 |
Policy1 |
假 |
Process1 |
User1 |
— |
|
2 |
Policy2 |
真 |
Process2 |
User2 |
已批准 |
|
3 |
Policy3 |
真 |
Process3 |
User3 |
已批准 |
但是,如果 User2 拒绝工作项,事件本身将被拒绝且不会为 User3 生成任何工作项,如下表所示:
|
优先级 |
策略 |
结果 |
工作流 |
批准人 |
操作 |
|---|---|---|---|---|---|
|
1 |
Policy1 |
假 |
Process1 |
User1 |
— |
|
2 |
Policy2 |
真 |
Process2 |
User2 |
已拒绝 |
|
3 |
Policy3 |
真 |
Process3 |
User3 |
— |
下一步,Policy1,Policy2,以及 Policy3 都有 ONCHANGE 的策略评估类型。 如果 User2 拒绝工作项,仅与包含在 Policy2 内的属性关联的更改会被拒绝。 之后评估 Policy3,并且工作流 Process3 运行并为 User3 生成工作项。 如果 User3 拒绝工作项,由于对该事件的所有更改被拒绝所以也拒绝该事件。 如果 User3 批准工作项,会批准事件且包含在 Policy3 内的属性更改会持续。
|
优先级 |
策略 |
结果 |
工作流 |
批准人 |
操作 |
|---|---|---|---|---|---|
|
1 |
Policy1 |
假 |
Process1 |
User1 |
— |
|
2 |
Policy2 |
真 |
Process2 |
User2 |
已拒绝 |
|
3 |
Policy3 |
真 |
Process3 |
User3 |
已批准 |
|
版权所有 © 2013 CA。
保留所有权利。
|
|