请考虑以下策略,所有策略都适用于“修改用户”管理任务中的 ModifyUserEvent:
|
策略 |
规则 |
评估 |
|---|---|---|
|
Policy1 |
用户,其中(用户 ID = Smith01) |
始终 |
|
Policy2 |
用户,其中(职位 = 经理) |
当“职位”属性更改时 |
|
Policy3 |
用户,其中(工资 >= 80000) |
当“工资”属性更改时 |
管理员每次为用户 Smith01 调用“修改用户”任务时即会评估 Policy1,无论更改哪个属性都会如此。
当管理员为任意用户对象调用“修改用户”任务以更改“职位”属性时即会评估 Policy2。 如果“职位”更改为“经理”,Policy2 为真。
当管理员为任意用户对象调用“修改用户”任务以更改“工资”属性时即会评估 Policy3。 如果工资更改为 80000 或更多,Policy3 为真。
在该示例中,如果管理员使用“修改用户”任务为用户 Smith01 将“职位”属性更改为“经理”,那么 Policy1 和 Policy2 都会评估为真,而其相应的工作流流程也会启动。 在这种情况下,即会应用标准排序优先级。
通过条件规则评估,某工作项的批准人可以更改对同一事件的其他工作项产生影响的属性(此时该事件仍处于未决状态)。 这对于评估类型为“Always”的批准策略是可能的。 在上面的示例中,如果管理员为用户 Smith01 更改属性,Policy1 则为真并生成工作项。 当批准 Policy1 生成的工作项时,该批准人可能会在同一批准屏幕上为 Smith01 更改“工资”属性。 在这种情况下,Smith01 的新“工资”值将确定 Policy3 是否会为相同的 ModifyUserEvent 实例生成工作项。 如果批准人将工资更改为 90000,Policy3 即会生成新的工作项,该工作项必须获得批准后事件本身才会获得批准。 此时即应用标准排序优先级。
|
版权所有 © 2013 CA。
保留所有权利。
|
|