たとえば、以下のポリシーについて考えてみます。これらはすべて、[ユーザの変更]管理タスクの ModifyUserEvent 用のポリシーです。
|
ポリシー |
ルール |
評価 |
|---|---|---|
|
Policy1 |
User where (User ID = Smith01) |
常時 |
|
Policy2 |
User where (Title = Manager) |
Title 属性が変更された場合 |
|
Policy3 |
User where (Salary >= 80000) |
Salary 属性が変更された場合 |
Policy1 は、管理者がユーザ Smith01 の[ユーザの変更]タスクを呼び出した場合に評価されます。どの属性が変更されたかは関係ありません。
Policy2 は、管理者が[ユーザの変更]タスクを呼び出して、任意のユーザ オブジェクトの Title 属性を変更した場合に評価されます。 Policy2 は Title 属性が Manager に変更された場合に真になります。
Policy3 は、管理者が[ユーザの変更]タスクを呼び出して、任意のユーザ オブジェクトの Salary 属性を変更した場合に評価されます。 Policy3 は Salary 属性が 80000 以上に変更された場合に真になります。
この例では、管理者が[ユーザの変更]タスクを使用してユーザ Smith01 の Title 属性を Manager に変更すると、Policy1 と Policy2 の両方が真に評価され、それぞれのワークフロー プロセスが開始されます。 この場合、標準的な優先度が適用されます。
条件付きルールの評価により、イベントの保留中に、ある作業項目の承認者が、同じイベントの他の作業項目に影響を与える属性を変更できるようになります。 これが可能なのは、評価タイプが「Always」の承認ポリシーのみです。 前述の例では、管理者がユーザ Smith01 の属性を変更すると、Policy1 が真となり、作業項目が生成されます。 承認者は、Policy1 によって生成された作業項目を承認する一方で、同じ承認画面で Smith01 の Salary 属性を変更することが可能です。 この場合、Smith01 の新しい Salary の値によって、Policy3 が同じ ModifyUserEvent のインスタンスの作業項目を生成するかどうかが決まります。 承認者が Salary 属性を 90000 に変更すると、Policy3 は新しい作業項目を生成します。この作業項目は、イベント自体が承認される前に承認されている必要があります。 標準的な優先度が適用されます。
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|