Azure Logic Apps ルールエンジンの実行の最適化 (プレビュー)

[アーティクル]
06/18/2024

適用対象: Azure Logic Apps (Standard)

重要

この機能はプレビュー段階にあり、「Microsoft Azure プレビューの追加使用条件」が適用されます。

Azure Logic Apps ルールエンジンは、Microsoft Rules Composer で作成できるルールセットの実行コンテキストを提供します。このガイドでは、ルールエンジンの動作に関する主要な概念について説明し、操作と実行の最適化に関する推奨事項を示します。

コアコンポーネント

ルールセット実行子

このコンポーネントは、ルール条件の評価とアクションの実行を担当するアルゴリズムを実装します。既定のルールセット実行子は、メモリ内作業工程を最適化するように設計されたネットワークベースの順行連鎖推論エンジンです。
ルールセットトランスレーター

このコンポーネントは、RuleSet オブジェクトを入力として受け取り、ルールセットの実行可能な表現を生成します。既定のメモリ内トランスレーターは、ルールセットの定義からコンパイルされた識別ネットワークを作成します。
ルールセット追跡インターセプター

このコンポーネントは、ルールセットエグゼキューターから出力を受信し、その出力をルールセットの追跡および監視ツールに転送します。

条件の評価とアクションの実行

Azure Logic Apps ルールエンジンは、.NET オブジェクトまたは XML ドキュメントにルールをリンクできる、非常に効率的な推論エンジンです。ルールエンジンは次のステージで、ルールセットの実行に 3 段階のアルゴリズムを使用します。

照合

照合ステージでは、ルールエンジンはルール条件で定義されている述語を使用して、ファクト型を使用する述語 (ルールエンジンのワーキングメモリで保持されるオブジェクト参照) とファクトを照合します。効率を高める目的で、ルールセット内のすべてのルールでパターンマッチングが行われ、ルール間で共有される条件は 1 回だけ照合されます。ルールエンジンは、後続のパターンマッチング操作を高速化するために、部分的な条件の一致をワーキングメモリに格納する場合があります。パターンマッチングフェーズからの出力には、ルールエンジンの議題の更新が含まれています。
競合の解決

競合解決ステージでは、ルールエンジンが実行の候補となるルールを確認し、あらかじめ指定した解決スキームに基づいて、次に実行するルールアクションのセットを決定します。ルールエンジンは、照合ステージ中に見つかったすべての候補ルールをルールエンジンの議題に追加します。

既定の競合解決スキームでは、ルールセット内のルールの優先度が基盤となります。 Microsoft Rules Composer で構成できるルールプロパティが優先順位となります。数値が大きいほど、優先度は高くなります。複数のルールがトリガーされた場合、ルールエンジンは優先順位の高いアクションを最初に実行します。
操作

アクションステージでは、ルールエンジンは解決されたルールでアクションを実行します。ルールアクションは、ルールエンジンに新しいファクトをアサートすることで、サイクルを続行できます。これはフォワードチェーンとも呼ばれます。

重要

このアルゴリズムは、現在実行中のルールに割り込むことはありません。ルールエンジンは、照合フェーズが繰り返される前に、現在実行中のルール内のすべてのアクションを実行します。ただし、ルールエンジンの議題に関する他のルールは、照合フェーズが再び開始される前には実行されません。照合フェーズでは、ルールエンジンの実行前にこれらのルールが議題から削除される可能性があります。

例

次の例は、照合 - 競合解決 - アクションの 3 ステージの仕組みを示します。

ルール 1: 収入を評価する

宣言型表明および保証

申請者のクレジット評価を、申請者の収入とローンの比率が 0.2 未満の場合にのみ取得します。

ビジネスオブジェクトを使用した IF-THEN 表明および保証

IF Application.Income / Property.Price < 0.2
THEN Assert new CreditRating( Application)

ルール 2: 信用格付けを評価する

宣言型表明および保証

申請者のクレジット評価が 725 を超える場合にのみ、申請者を承認します。

ビジネスオブジェクトを使用した IF-THEN 表明および保証

IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725
THEN SendApprovalLetter(Application)

次の表は、ファクトをまとめたものです。

ファクト	説明	フィールド
Application	住宅融資申込みを表す XML ドキュメント。	- Income: $65,000 - SSN: XXX-XX-XXXX
プロパティ	購入する物件を表す XML ドキュメント。	- Price: $225,000
CreditRating	ローン申請者のクレジット評価を含む XML ドキュメント。	- Value: 0-800 - SSN: XXX-XX-XXXX

ワーキングメモリと議題の更新

ルールエンジンのワーキングメモリと議題は、最初は空です。アプリケーションがアプリケーション ファクトとプロパティ ファクトを追加すると、ルールエンジンのワーキングメモリと議題が次のように更新されます。

ワーキングメモリ	アジェンダ
- アプリケーション - プロパティ	ルール 1

条件 Application.Income / Property.Price < 0.2 は、照合フェーズで true と評価されるため、ルールエンジンは議題にルール 1 を追加します。
CreditRating ファクトはワーキングメモリに存在しないため、ルール 2 の条件は評価されません。
ルール 1 は議題内の唯一のルールであるため、ルールが実行されたら、議題から削除されます。
ルール 1 では、ワーキングメモリに追加される申請者の CreditRating ドキュメントである新しいファクトを生成する、1 つのアクションを定義します。
ルール 1 の実行が完了すると、コントロールは照合フェーズに戻ります。

照合対象となる新しいオブジェクトは CreditRating ファクトしかないため、照合フェーズの結果は次のようになります。

ワーキングメモリアジェンダ

- アプリケーション
- プロパティ
- CreditRating ルール 2
ルール 2 が実行され、承認通知を申請者に送信する関数が呼び出されます。
ルール 2 が完了すると、コントロールは照合フェーズに戻ります。ただし、照合する新しいファクトはこれ以上なく、議題は空であるため、前方チェーンが終了し、ルールセットの実行が完了します。

ワーキングメモリ	アジェンダ
- アプリケーション - プロパティ - CreditRating	ルール 2

議題と優先度

Azure Logic Apps ルールエンジンがルールを評価してアクションを実行する仕組みを理解するには、議題と優先順位の概念についても知る必要があります。

アジェンダ

ルールエンジンの議題は、実行のルールをキューに登録するスケジュールです。エンジンインスタンスに議題が配置されており、一連のルールセットではなく、1 つのルールセットに対して機能します。ファクトがワーキングメモリにアサートされ、ルールの条件が満たされると、エンジンはルールを議題に配置し、優先順位に基づいてそのルールを実行します。エンジンは、優先度が上から下の順にルールのアクションを実行し、議題の次のルールのアクションを実行します。

ルールエンジンはルール内のアクションをブロックとして扱うので、エンジンが次のルールに移動する前にすべてのアクションが実行されます。ルールブロック内のアクションはすべて、ブロック内の他のアクションとは無関係に実行されます。アサーションの詳細については、「コントロール関数を使用してルールエンジンを最適化する」を参照してください。

次の例は、議題のしくみを示しています。

規則 1

IF
Fact1 == 1
THEN
Action1
Action2

規則 2

IF
Fact1 > 0
THEN
Action3
Action4

値が 1 の Fact1 ファクトがエンジンにアサートされると、ルール 1 とルール 2 の両方の条件が満たされます。そのため、エンジンは両方のルールを議題に移動してアクションを実行します。

ワーキングメモリ	アジェンダ
ファクト 1 (値 = 1)	ルール 1： - Action1 - Action2 ルール 2： - Action3 - Action4

優先度

既定では、すべてのルールの実行優先度は 0 に設定されます。ただし、個々のルールでこの優先度を変更できます。優先度の範囲には 0 に対する正と負のどちらも指定できます。数値が大きいほど高い優先度となります。エンジンは、優先度が最も高いものから最も低いものの順にアクションを実行します。

次の例は、優先度がルールの実行順序にどのように影響するかを示しています。

ルール 1 (優先度 = 0)

IF
Fact1 == 1
THEN
Discount = 10%

ルール 2 (優先度 = 10)

IF
Fact1 > 0
THEN
Discount = 15%

両方のルールの条件が満たされていますが、ルール 2 の優先順位が高いため、最初に実行されます。次の表に示すように、ルール 1 に対して実行されたアクションの結果により、最終的な割引は 10% となります。

ワーキングメモリ	アジェンダ
Fact1 (値 = 1)	ルール 2：割引: 15% ルール 1：割引: 10%

アクションの副作用

アクションの実行がオブジェクトの状態または条件で使用される用語に影響を与える場合、このアクションでは、そのオブジェクトまたは用語に "副作用" があるといえます。この語句は、アクションに副作用ということではなく、オブジェクトまたは用語が 1 つ以上のアクションの影響を受ける可能性があるという意味です。

たとえば、次のようなルールがあるとします。

規則 1

IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"

規則 2

IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")

この例では、OrderForm.UpdateStatus は OrderForm.Status に"副作用" を与えます。つまり、OrderForm.Status は 1 つ以上のアクションの影響を受ける可能性があります。

.NET クラスメンバーの SideEffects プロパティの既定値は true に設定されているため、ルールエンジンは副作用のあるメンバーをキャッシュできません。この例では、ルールエンジンは OrderForm.Status をワーキングメモリにキャッシュしません。代わりに、エンジンがルール 1 を評価するたびに、エンジンは OrderForm.Status の最新の値を取得します。 SideEffects プロパティ値が false の場合、ルールエンジンは、エンジンが初めて OrderForm.Status を評価するときに値をキャッシュします。ただし、前方チェーンシナリオでの後の評価では、エンジンはキャッシュされた値を使用します。

現在、Microsoft Rules Composer では、ユーザーが SideEffects プロパティ値を変更する方法がありません。ただし、Microsoft .NET 準拠クラスライブラリである Business Rules フレームワークを通じて、SideEffects をプログラムで設定することができます。ルールの条件およびアクションで使用されるオブジェクトのメソッド、プロパティ、およびフィールドを ClassMemberBinding クラスで指定して、バインド時にこの値を設定します。 ClassMemberBinding クラスには、SideEffects という名前のプロパティがあります。このプロパティには、メンバーにアクセスするとその値が変更されるかどうかを示すブール値が含まれています。

パフォーマンスに関する考慮事項

このセクションでは、Azure Logic Apps ルールエンジンがさまざまなシナリオや、構成およびチューニングパラメーターのさまざまな値でどのように動作するかを説明します。

ファクトの種類

ルールエンジンは、XML ファクトにアクセスするよりも短い時間で、.NET ファクトにアクセスします。ルールセットで .NET ファクトまたは XML ファクトのどちらを使用するか選べる場合は、パフォーマンスを向上させるために .NET ファクトを使用することを検討してください。

ルールの優先順位

ルールの優先度設定の範囲は 0 に対して正と負のどちらでも可能で、数値が大きいほど優先度は高くなります。アクションは、優先度が最も高いものから優先度が最も低いものの順に実行されます。ルールセットで Assert 呼び出しまたは Update 呼び出しを使用して前方チェーン動作を実装する場合は、Priority プロパティを使用するとチェーンを最適化できます。

たとえば、ルール 1 によって設定される値に ルール 2 が依存しているとします。 ルール 1 の優先度がより高い場合、ルール 2 はルール 1 が起動して値を更新した後にのみ実行されます。逆に、ルール 2 の優先度が高い場合は、そのルールは 1 回起動してから、ルール 1 の起動後に再度起動し、ルール 2 の条件のファクトを更新します。このシナリオでは、正しい結果が生成される場合と生成されない場合がありますが、明らかに、2 回発生すると、1 回のみの場合よりもパフォーマンスに影響が出ます。

詳細については、「Microsoft Rules Composer を使用してルールを作成する」を参照してください。

論理和演算子

ルールエンジンは、論理 AND 演算子を実行するように最適化されており、論理 OR 演算子が最上位レベルでのみ使用されるように、エンジンが解析したルールを結合正規形式に再構築します。

条件でより多くの論理 OR 演算子を使用すると、順列が増え、ルールエンジンの分析ネットワークが拡張されます。その結果、ルールエンジンがルールを正規化するのに長い時間がかかる場合があります。

次の一覧に、この問題の考えられる回避策を示します。

OR 演算子が最上位でのみ使用されるよう、ルールを選言標準形式に変更します。

Microsoft Rules Composer の選言標準形式ではルールを作成しにくい場合があるため、プログラムでルールを作成することを検討してください。
OR 演算子を実行し、ブール値を返すヘルパーコンポーネントを開発し、ルールでそのコンポーネントを使用します。
ルールを複数のルールに分割し、そのルールを使用して以前実行したルールで設定されたフラグをチェックしたり、以前実行したルールでアサートされたオブジェクトを使用したりします。次に例を示します。
- ルール 1: IF (a == 1 OR a == 3) THEN b = true
  
  ルール 2: IF (b == true) THEN …
- ルール 1: IF (a == 1 OR a == 3) THEN Assert(new c())
  
  ルール 2: IF (c.flag == true) THEN …

Update の呼び出し

Update 関数は、ルールエンジンのワーキングメモリにあるファクトを更新します。これにより、条件内で更新されたファクトを使用するすべてのルールが再評価されます。つまりこの動作では、更新されたファクトが原因で多くのルールで再評価が必要な場合は特に、Update 関数の呼び出しにコストがかかる可能性があります。状況によっては、ルールを再評価する必要をなくすことができます。

たとえば、次のルールがあるとします。

規則 1

IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)

規則 2

IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)

ルールセット内の残りのルールはすべて、条件で StatusObj.Flag を使用します。 StatusObj オブジェクトで Update 関数を呼び出すと、すべてのルールが再評価されます。 Amountフィールドの値には関係なく、ルール 1 とルール 2を除くすべてのルールがUpdateの呼び出しの前後に 1 回ずつ (計 2 回) 評価されます。

代わりに、ルールセットを呼び出す前に [Flag] 値を false に設定し、ルールセットのルール 1 のみを使用してフラグを設定します。この場合、Update 関数は [Amount] 値が 5 より大きい場合にのみ呼び出されます。量が 5 以下の場合、Update 関数は呼び出されません。こうすると、ルール 1 とルール 2 を除くすべてのルールは、[Amount] 値が 5 より大きい場合のみ 2 回評価されます。

SideEffects プロパティのビヘイビアー

XmlDocumentFieldBinding クラスと ClassMemberBinding クラスの SideEffects プロパティは、バインドされたフィールド、メンバー、または列の値をキャッシュするかどうかを決定します。

XmlDocumentFieldBinding クラスでは、SideEffects プロパティの既定値は false です。ただし、ClassMemberBinding クラスでは、SideEffects プロパティの既定値は true です。

つまり、エンジンがルールセット内でXML ドキュメント内のフィールドに 2 回目以降のアクセスを行う際、エンジンはキャッシュからフィールドの値を取得します。ただし、エンジンがルールセット内で .NET オブジェクトのメンバーに 2 回目以降のアクセスを行う場合、エンジンはキャッシュからではなく .NET オブジェクトから値を取得します。

この動作では、.NET ClassMemberBinding の SideEffects プロパティを false に設定すると、エンジンが 2 回目以降にキャッシュからメンバーの値を取得するため、パフォーマンスを向上させることができます。ただし、Microsoft Rules Composer では SideEffects プロパティが公開されないため、プログラムでのみプロパティ値を設定できます。

インスタンスと選択性

XmlDocumentBinding クラスと ClassBinding クラスにはそれぞれ次のプロパティがあります。ルールエンジンがプロパティの値を使用して条件の評価を最適化します。これらのプロパティ値により、エンジンは最初に条件評価で可能な限り少ないインスタンスを使用し、次に残りのインスタンスを使用するようになります。

インスタンス: ワーキングメモリ内の、予想されるクラスインスタンスの数。

あらかじめオブジェクトインスタンスの数がわかっている場合は、Instances プロパティをこの数に設定するとパフォーマンスを向上できます。
選択性 (Selectivity): ルール条件に正常に合格したクラスインスタンスの割合。

条件を渡すオブジェクトインスタンスの割合がわかっている場合は、Selectivity プロパティをこの割合に設定するとパフォーマンスを向上できます。

これらのプロパティ値は、Microsoft Rules Composer によって公開されないため、プログラムでのみ設定できます。

クラス継承のサポート

継承は、オブジェクト指向プログラミング (OOP) 言語の主要な機能であり、元のクラスを書き換えることなく、既存のクラスのすべての機能を使用し、それらの機能を拡張する機能です。

Azure Logic Apps ルールエンジンでは、次の種類のクラス継承がサポートされています。

実装の継承: 他のコーディングなしで基底クラスのプロパティとメソッドを使用する機能。
インターフェイスの継承: プロパティ名とメソッド名のみを使用する機能ですが、子クラスで実装を提供する必要があります。

ルールエンジンを使用すると、共通の基底クラスの観点からルールを記述できますが、ルールエンジンにアサートされるオブジェクトは派生クラスから取得されます。

次の例には Employee という名前の基底クラスがあり、派生クラスの名前は RegularEmployee と ContractEmployee です。

class Employee
{
    public string Status()
    {
        // member definition
    }
    public string TimeInMonths()
    {
        // member definition
    }
}

class ContractEmployee : Employee
{
   // class definition
}
class RegularEmployee : Employee
{
   // class definition
}

この例では、次の規則があるとします。

ルール 1

IF Employee.TimeInMonths < 12
THEN Employee.Status = "New"


At run time, if you assert two objects, a **ContractEmployee** instance and a **RegularEmployee** instance, the engine evaluates both objects against the Rule 1.

You can also assert derived class objects in actions by using an **Assert** function. This function causes the engine to reevaluate rules that contain the derived object and the base type in their conditions as shown in the following example, which demonstrates implementation inheritance:

**Rule 2**

```text
IF Employee.Status = "Contract"
THEN Employee.Bonus = false
Assert(new ContractEmployee())

アサーションの後、エンジンは、Employee 型または ContractEmployee 型を条件に含むすべてのルールを再評価します。派生クラスのみがアサートされている場合でも、派生クラスではなく基本クラスのメソッドを使用してルールを記述した場合、基本クラスもアサートされます。

次の方法で共有

Azure Logic Apps ルールエンジンの実行の最適化 (プレビュー)

コアコンポーネント

条件の評価とアクションの実行

例

ワーキングメモリと議題の更新

議題と優先度

アジェンダ

優先度

アクションの副作用

パフォーマンスに関する考慮事項

ファクトの種類

ルールの優先順位

論理和演算子

Update の呼び出し

SideEffects プロパティのビヘイビアー

インスタンスと選択性

クラス継承のサポート

フィードバック

フィードバック

その他のリソース

次の方法で共有

Azure Logic Apps ルール エンジンの実行の最適化 (プレビュー)

コア コンポーネント

条件の評価とアクションの実行

例

ワーキング メモリと議題の更新

議題と優先度

アジェンダ

優先度

アクションの副作用

パフォーマンスに関する考慮事項

ファクトの種類

ルールの優先順位

論理和演算子

Update の呼び出し

SideEffects プロパティのビヘイビアー

インスタンスと選択性

クラス継承のサポート

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

Azure Logic Apps ルールエンジンの実行の最適化 (プレビュー)

コアコンポーネント

ワーキングメモリと議題の更新