残りのルール候補とランク付け

ルールレゾリューションアルゴリズムが継続し、3つのステップからなるサブプロセスを通して、残りのルール候補をランク付けします。まず、ルール候補のリストをソートします。その後、「Withdrawn」と表示されたルールの影響を受けるすべてのルール候補がリストから削除されます。最後に、デフォルトのルール候補が定義されます。

ルールのソート順

ルールレゾリューションアルゴリズムは、残りのルール候補を次の順番でソートします。

Class
Ruleset
Circumstance
Circumstance Date
Date/Time Range
Version

最初の2つの基準である「Class」と「Ruleset」は、ルールレゾリューションの基本となるものです。ルール候補が参照されたルールのApplies toクラスに近いほど、そのルール候補の順位は高くなります。各クラス内では、オペレーターのルールセットリストに従ってルール候補がソートされます。

注：クラス定義で「Use class-based inheritance to arrive at the correct rule to execute?」のチェックボックスが選択されていないルールは、クラスごとにランク付けされません。

次の3つの基準（Circumstance（PropertyまたはTemplate）、Circumstance Date、Date/Time Range）は、ルールレゾリューションの基本に対する修飾子として使用され、ルール候補をさらに絞り込む、または特殊化するために使用されます。

最後の基準「Version」は、残りの候補ルールを、そのルールを含むルールセットのバージョンでランク付けします。これにより、ベースルールが最近のルールセットのバージョンで更新されても、特殊化されたルールが自動的に上書きされないようになります。

次の図は、ルール候補のリストは、クラスとルールセットの順序に従ってランク付けされており、特殊化されたルールも含まれているため、ルール候補のリストから削除されるルールがないことを示しています。

可用性が「Withdrawn」に設定されているルール候補の削除

ルール候補がランク付けされた後、ルールレゾリューションアルゴリズムは、可用性が「Withdrawn」に設定されているルールの影響を受けるルール候補を削除します。

可用性が「Not Available」に設定されているルールとは異なり、可用性を「Withdrawn」に設定したルールは、下位のルールセットのバージョンのルールにも影響します。ルールのAvailabilityが「Withdrawn」に設定されている場合、下位のルールセットのバージョンでapply toクラス、ルールの目的、および撤回されたルールの修飾子に一致する他のすべてのルール候補もリストから削除されます。

この例では、Purchasing: 02-01-10ルールセットのCreateRequest FlowActionの可用性が、「Withdrawn」に設定されています。削除されたルールのapplies toクラスと目的に一致する他の2つのルール候補は、Purchasingルールセットの下位バージョンに属しているため、リストから削除されます。他のクラスやルールセットでのCreateRequestのインスタンスは、さらなる検討のために保持されます。

次の画像は、削除対象として設定されたルールを強調表示するルールレゾリューションアルゴリズムを示しています。