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

適用対象: Azure Logic Apps (Standard)

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.Income / Property.Price < 0.2 は、照合フェーズで true と評価されるため、ルール エンジンは議題にルール 1 を追加します。

• CreditRating ファクトはワーキング メモリに存在しないため、ルール 2 の条件は評価されません。

• ルール 1 は議題内の唯一のルールであるため、ルールが実行されたら、議題から削除されます。

• ルール 1 では、ワーキング メモリに追加される申請者の CreditRating ドキュメントである新しいファクトを生成する、1 つのアクションを 定義します。

• ルール 1 の実行が完了すると、コントロールは照合フェーズに戻ります。

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

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

• ルール 2 が実行され、承認通知を申請者に送信する関数が呼び出されます。

• ルール 2 が完了すると、コントロールは照合フェーズに戻ります。 ただし、照合する新しいファクトはこれ以上なく、議題は空であるため、前方チェーンが終了し、ルール セットの実行が完了します。

議題と優先度

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

アジェンダ

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

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

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

規則 1

IF
Fact1 == 1
THEN
Action1
Action2

規則 2

IF
Fact1 > 0
THEN
Action3
Action4

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

優先度

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

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

ルール 1 (優先度 = 0)

IF
Fact1 == 1
THEN
Discount = 10%

ルール 2 (優先度 = 10)

IF
Fact1 > 0
THEN
Discount = 15%

両方のルールの条件が満たされていますが、ルール 2 の優先順位が高いため、最初に実行されます。 次の表に示すように、ルール 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 ルール エンジンとは？
• Microsoft Rules Composer を使用してルールを作成する
• Azure Logic Apps Rules Engine プロジェクトの作成