BizTalk Server ソリューションでビジネス ルール エンジン (BRE) を実装する場合は、次の要素を考慮する必要があります。
ファクトの種類
ルール エンジンは、XML とデータベースのファクトにアクセスするのにかかる時間と比較して、.NET ファクトへのアクセスにかかる時間が短くなります。 ポリシーで .NET または XML またはデータベースファクトのいずれかを使用する場合は、パフォーマンスを向上させるために .NET ファクトを使用することを検討する必要があります。
データ テーブルとデータ接続
データ セットのサイズが小さい場合 (< 10 など)、 TypedDataTable バインドは DataConnection バインディングよりも優れたパフォーマンスを提供します。 ただし、データ セットが大きい場合 (約 10 行以上) の場合、 DataConnection バインドの方が TypedDataTable バインディングよりも優れています。 そのため、データ セットの推定サイズに基づいて 、DataConnection バインディングと TypedDataTable バインディングのどちらを使用するかを決定する必要があります。
情報収集者
ファクト取得機能は、通常、ポリシーが実行される前にルール エンジンに長期的かつ緩やかに変化するファクトを提供するために使用される標準メソッドを実装します。 エンジンはこれらのファクトをキャッシュして、複数の実行サイクルで使用します。 ルール エンジンを呼び出すたびに静的またはかなり静的なファクトを送信する代わりに、ファクトを初めて送信するファクト取得機能を作成し、必要な場合にのみメモリ内のファクトを更新する必要があります。
ルールの優先順位
ルールの優先度設定は 0 を基準にその両側で指定でき、数値が大きいほど優先度が高くなります。 アクションは、優先度が最も高い順に実行されます。 ポリシーで Assert/Update 呼び出しを使用して前方チェーン動作を実装する場合、優先順位設定を使用してチェーンを最適化できます。 たとえば、 Rule2 が Rule1 によって設定された値に依存しているとします。 Rule1 の優先度を高くすると、Rule2 は Rule1 の起動後にのみ実行され、値が更新されます。 逆に、 ルール 2 の優先度が高い場合は、1 回起動し、 Rule1 の起動後に再度起動し、 Rule2 が条件を使用しているという事実を更新できます。 これにより正しい結果が得られますが、このシナリオでは Rule1 の優先度を高くすると、パフォーマンスが向上します。
Update の呼び出し
Update 関数を使用すると、更新されたファクトを使用するすべてのルールが再評価されます。 更新関数の呼び出しは、特にファクトの更新時に大量のルールセットが再評価される場合にコストがかかる場合があります。 この動作を回避できる状況があります。 たとえば、次の規則を考えてみましょう。
Rule1:
IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)
Rule2:
IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)
ポリシーの残りの規則はすべて、 条件で StatusObj.Flag を使用します。 したがって、StatusObj オブジェクトに対して Update が呼び出されると、すべてのルールが再評価されます。 Amount フィールドの値が何であっても、Rule1 または Rule2 を除くすべてのルールは、Update 呼び出しの前と Update 呼び出しの後に 1 回、2 回評価されます。
関連するオーバーヘッドを軽減するために、ポリシーを呼び出す前に フラグ フィールドの値を false に設定し、ポリシーで Rule1 のみを使用してフラグを設定できます。 この場合、Amount フィールドの値が 5 より大きい場合にのみ Update が呼び出され、Amount の値が 5 以下の場合は Update 関数は呼び出されません。 したがって、Rule1 または Rule2 を除くすべてのルールは、Amount フィールドの値が 5 より大きい場合にのみ 2 回評価されます。
論理 OR 演算子の使用
条件で論理 OR 演算子の数が増えるにつれて、ルール エンジンの分析ネットワークを拡張する追加の順列が作成されます。 パフォーマンスの観点からは、論理 OR 演算子を含まないアトミックルールに条件を分割することをお勧めします。
キャッシュの設定
ルール エンジンは 2 つのキャッシュを使用します。 1 つ目は更新サービスによって使用され、2 つ目は各 BizTalk プロセスで使用されます。 ポリシーを初めて使用すると、BizTalk プロセスは更新サービスにポリシー情報を要求します。 更新サービスは、ルール エンジン データベースからポリシー情報を取得し、それをキャッシュして、BizTalk プロセスに情報を返します。 BizTalk プロセスは、その情報に基づいてポリシー オブジェクトを作成し、関連付けられているルール エンジン インスタンスがポリシーの実行を完了したときに、ポリシー オブジェクトをキャッシュに格納します。 同じポリシーが再度呼び出されると、BizTalk プロセスはキャッシュからポリシー オブジェクトを再利用します (使用可能な場合)。 同様に、BizTalk プロセスが更新サービスからポリシーに関する情報を要求した場合、更新サービスはキャッシュ内のポリシー情報 (使用可能な場合) を検索します。 更新サービスでは、60 秒ごとに、データベース内のポリシーに更新があったかどうかも確認されます。 更新プログラムがある場合、更新サービスは情報を取得し、更新された情報をキャッシュします。
これらのキャッシュに関連するルール エンジンには、 CacheEntries、 CacheTimeout、 PollingInterval の 3 つのチューニング パラメーターがあります。 これらのパラメーターの値は、レジストリまたは構成ファイルで指定できます。 CacheEntries パラメーターの値は、キャッシュ内のエントリの最大数であり、既定では 32 の値に設定されます。 特定のシナリオでパフォーマンスを向上させるために、 CacheEntries パラメーターの値を増やしたい場合があります。 たとえば、40 個のポリシーを繰り返し使用しているとします。 CacheEntries パラメーターの値を 40 に増やしてパフォーマンスを向上させることができます。 これにより、更新サービスは最大 40 個のポリシーのキャッシュの詳細をメモリに保持できます。
CacheTimeout の値は、エントリが更新サービス キャッシュに保持される時間 (秒単位) です。 言い換えると、 CacheTimeout 値は、ポリシーのキャッシュ エントリが参照されずにキャッシュに保持される期間を指します。 CacheTimeout パラメーターの既定値は 3,600 秒 (1 時間) です。 つまり、キャッシュ エントリが 1 時間以内に参照されていない場合、エントリは削除されます。 場合によっては、 CacheTimeout パラメーターの値を大きくしてパフォーマンスを向上させることができます。 たとえば、ポリシーが 2 時間ごとに呼び出される場合、 CacheTimeout パラメーターを 2 時間より大きい値に増やすことで、ポリシー実行のパフォーマンスが向上します。
ルール エンジンの PollingInterval パラメーターは、更新サービスがルール エンジン データベースで更新プログラムをチェックする時間を秒単位で定義します。 PollingInterval パラメーターの既定値は 60 秒です。 ポリシーがまったく更新されない、またはほとんど更新されないことがわかっている場合は、このパラメーターを高い値に変更してパフォーマンスを向上させることができます。
SideEffects プロパティ
ClassMemberBinding、DatabaseColumnBinding、および XmlDocumentFieldBinding クラスには、SideEffects という名前のプロパティがあります。 このプロパティは、バインドされたフィールド、メンバー、または列の値をキャッシュするかどうかを決定します。 DatabaseColumnBinding クラスおよび XmlDocumentFieldBinding クラスの SideEffects プロパティの既定値は false です。 ClassMemberBinding クラスの SideEffects プロパティの既定値は true です。 したがって、XML ドキュメントのフィールドまたはデータベース テーブルの列にポリシー内で 2 回目以降アクセスすると、その値がキャッシュから取得されます。 ただし、.NET オブジェクトのメンバーに 2 回目以降アクセスすると、値はキャッシュからではなく .NET オブジェクトから取得されます。 .NET ClassMemberBinding の SideEffects プロパティを false に設定すると、フィールドの値が 2 回目以降キャッシュから取得されるため、パフォーマンスが向上します。 これはプログラムでのみ実行できます。 ビジネスルール作成ツールはSideEffectsプロパティを表示しません。
インスタンスと選択性
XmlDocumentBinding、ClassBinding、および DatabaseBinding クラスには、インスタンスと選択性の 2 つのプロパティがあります。 Instances の値は、作業メモリ内のクラスのインスタンスの予想される数です。 選択度の値は、ルール条件を正常に渡すクラス インスタンスの割合です。 ルール エンジンはこれらの値を使用して条件の評価を最適化し、最初に条件の評価で使用されるインスタンスが最も少なく、次に残りのインスタンスが使用されるようにします。 オブジェクトのインスタンス数に関する知識がある場合は、 Instances プロパティをその値に設定すると、パフォーマンスが向上します。 同様に、これらのオブジェクトの割合が条件を満たしているという知識がある場合は、 選択度 プロパティをその値に設定すると、パフォーマンスが向上します。 これらのパラメーターの値はプログラムでのみ設定できます。 ビジネス ルール作成ツールでは、これらを公開しません。