Azure Logic Apps 規則引擎執行的優化 （預覽）
適用於：Azure Logic Apps (標準)
重要
此功能處於預覽狀態，且受限於 Microsoft Azure 預覽版的補充使用規定。
Azure Logic Apps 規則引擎會提供規則集的執行內容，您可以使用Microsoft規則編輯器建立規則集。 本指南說明規則引擎運作方式的核心概念，並提供作業和執行的優化建議。
核心元件
Ruleset 執行程式
此元件會實作負責規則條件評估和動作執行的演算法。 默認規則集執行程式是辨識網路型的正向鏈結推斷引擎，其設計目的是要優化記憶體內部作業。
規則集翻譯工具
此元件會 採用 RuleSet 對象作為輸入，並產生規則集的可執行表示法。 默認記憶體內部翻譯工具會從規則集定義建立編譯的辨識網路。
規則集追蹤攔截器
此元件會接收來自規則集執行程序的輸出，並將該輸出轉送至規則集追蹤和監視工具。
條件評估和動作執行
Azure Logic Apps 規則引擎是高效推斷引擎，可將規則連結至 .NET 物件或 XML 檔。 規則引擎會使用三階段演算法來執行規則集，並具有下列階段：
火柴
在比對階段中，規則引擎會使用規則引擎的工作記憶體中所定義的述詞，比對使用事實類型的述詞，這些述詞是規則引擎工作記憶體中維護的對象參考。 為了提高效率，模式比對會在規則集中的所有規則中發生，而且跨規則共用的條件只會比對一次。 規則引擎可能會將部分條件比對儲存在工作記憶體中，以加速後續模式比對作業。 模式比對階段的輸出包含規則引擎議程的更新。
衝突解決
在衝突解決階段，規則引擎會根據預先決定的解決方案配置，檢查要執行的規則，以判斷下一組要執行的規則動作。 規則引擎會將比對階段中找到的所有候選規則新增至規則引擎的議程。
默認衝突解決配置是以規則集內的規則優先順序為基礎。 優先順序是在Microsoft Rules Composer 中設定的規則屬性。 數位越大，優先順序越高。 如果觸發多個規則，規則引擎會先執行較高優先順序的動作。
動作
在動作階段中，規則引擎會在已解析的規則中執行動作。 規則動作可以將新的事實判斷為規則引擎，這會導致循環繼續，也稱為向前鏈結。
重要
演算法絕不會先佔目前執行中的規則。 規則引擎會在比對階段重複之前，執行目前執行中規則中的所有動作。 不過，規則引擎議程上的其他規則不會在比賽階段再次開始之前執行。 比對階段可能會導致規則引擎在執行之前，將這些規則從議程中移除。
範例
下列範例示範比對、衝突解決和動作的三階段演算法如何運作：
規則 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)
下表摘要說明事實：
| 事實 | 描述 | 欄位 |
|---|---|---|
| 應用程式 | 表示房屋貸款申請的 XML 檔。 | - 收入：65,000美元 - SSN：XXX-XX-XXXX |
| 屬性 | XML 檔，表示要購買的屬性。 | - 價格： $225,000 |
| CreditRating | 包含貸款申請人信用評級的 XML 檔。 | - 值：0-800 - SSN：XXX-XX-XXXX |
工作記憶體和議程的更新
一開始，規則引擎的工作記憶體和議程是空的。 在您的應用程式新增 Application 和 Property 事實之後，規則引擎會更新其工作記憶體和議程，如下所示：
| 工作記憶體 | 議程 |
|---|---|
| -應用 -財產 |
規則 1 |
規則引擎會將規則 1 新增至其議程， 因為條件 Application.Income / Property.Price < 0.2 會在比對階段評估為 true 。
工作記憶體中沒有 CreditRating 事實，因此不會評估規則 2 的條件。
規則 1 是議程中唯一的規則，因此規則會執行，然後從議程中消失。
規則 1 定義單一動作，導致新的事實，這是申請人的 CreditRating 檔，新增至工作記憶。
在規則 1 完成執行之後，控件會返回比對階段。
唯一要比對的新物件是 CreditRating 事實，因此比對階段的結果如下：
工作記憶體 議程 -應用
-財產
- CreditRating規則 2 規則 2 現在會執行，該函式會呼叫將核准信件傳送給申請人的函式。
在規則 2 完成之後，控件會返回比對階段。 不過，沒有更多新的事實可供比對，而且議程是空的，因此向前鏈結會終止，而且規則集執行已完成。
議程和優先事項
若要瞭解 Azure Logic Apps 規則引擎如何評估規則和執行動作，您也必須瞭解議程和優先順序的概念。
議程
規則引擎的議程是排入執行規則的排程。 引擎實例的議程存在，並針對單一規則集運作，而不是一系列規則集。 當事實判斷為工作記憶體，並符合規則的條件時，引擎會將規則放在議程上，並根據優先順序執行該規則。 引擎會從上到下執行規則的動作，然後在議程上執行下一個規則的動作。
規則引擎會將規則中的動作視為區塊，因此所有動作都會在引擎移至下一個規則之前執行。 不論區塊中的其他動作為何，規則區塊中的所有動作都會執行。 如需判斷提示的詳細資訊，請參閱 使用控制函式 優化規則引擎。
下列範例顯示議程的運作方式：
規則 1
IF
Fact1 == 1
THEN
Action1
Action2
規則 2
IF
Fact1 > 0
THEN
Action3
Action4
當 Fact1 事實具有 1 值時，會判斷提示至引擎中，規則 1 和規則 2 都符合其條件。 因此，引擎會將這兩個規則移至議程，以執行其動作。
| 工作記憶體 | 議程 |
|---|---|
| 事實 1 （value=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 會先執行，因為優先順序較高。 最終折扣是 10%，因為針對規則 1 執行的動作結果，如下表所示：
| 工作記憶體 | 議程 |
|---|---|
| Fact1 （value=1） | 規則 2： 折扣：15% 規則 1： 折扣：10% |
動作副作用
如果動作的執行會影響物件的狀態或條件中使用的字詞，則此動作據說會對該物件或字詞產生「副作用」。 此片語並不表示動作具有副作用，而是物件或字詞可能會受到一或多個動作的影響。
例如，假設您有下列規則：
規則 1
IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"
規則 2
IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")
在此範例中， OrderForm.UpdateStatus 對 OrderForm.Status 有「副作用」，這表示 OrderForm.Status 可能會受到一或多個動作的影響。
.NET 類別成員的 SideEffects 屬性會設定為 true 作為預設值，這可防止規則引擎快取具有副作用的成員。 在此範例中，規則引擎不會在工作記憶體中快取 OrderForm.Status 。 相反地，每次引擎評估規則 1 時，引擎就會取得 OrderForm.Status 的最新值。 如果 SideEffects 屬性值為 false，當引擎第一次評估 OrderForm.Status 時，規則引擎會快取值。 不過，針對後續在向前鏈結案例中的評估，引擎會使用快取的值。
Microsoft Rules Composer 目前不提供修改 SideEffects 屬性值的方法。 不過，您可以透過商務規則架構，以程式設計方式設定 SideEffects 屬性值，這是Microsoft 。符合 NET 規範的類別庫。 您可以使用 ClassMemberBinding 類別在系結中設定此值，以指定規則條件和動作中使用的物件方法、屬性和字位。 ClassMemberBinding 類別具有名為 SideEffects 的屬性，其中包含布爾值，指出存取成員是否變更其值。
效能考量
本節討論 Azure Logic Apps 規則引擎如何在各種案例中執行，以及設定和微調參數的不同值。
事實類型
規則引擎存取 .NET 事實所需的時間比存取 XML 事實要少。 如果您在規則集中使用 .NET 事實或 XML 事實之間有選擇，請考慮使用 .NET 事實來提升效能。
規則優先順序
規則的優先順序設定可以範圍設定為 0 的任一端，且具有較高優先順序的數位。 動作會依優先順序從最高優先順序到最低優先順序開始執行。 當規則集使用 Assert 或 Update 呼叫實作轉送鏈結行為時，您可以使用 Priority 屬性優化鏈結。
例如，假設規則 2 相依於規則 1 所設定的值。 如果規則 1 具有較高的優先順序，則規則 2 只會在規則 1 引發並更新值之後執行。 相反地，如果規則 2 具有較高的優先順序，則規則可以引發一次，然後在規則 1 引發之後再次引發，並更新規則 2 條件中的事實。 此案例可能會或可能不會產生正確的結果，但很明顯，引發兩次會對效能造成影響，而只會引發一次。
如需詳細資訊，請參閱 使用Microsoft規則撰寫器建立規則。
邏輯 OR 運算子
規則引擎已優化以執行邏輯 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 函式呼叫可能很昂貴，特別是因為更新的事實而需要重新評估許多規則時。 在某些情況下，您可以避免重新評估規則。
例如，請考慮下列規則：
規則 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 函式時，會重新評估所有規則。 無論值在 [數量] 欄位中，規則 1 和規則 2 以外的所有規則都會評估兩次：在更新呼叫之前和更新呼叫之後一次。
相反地，您可以在叫用規則集之前， 將 Flag 值設定為 false ，然後在規則集中只 使用規則集中的規則 1 來設定旗標。 在此情況下，只有在Amount值大於5時，才會呼叫Update函式。 如果數量小於或等於 5，則不會呼叫 Update 函式。 如此一來，只有在Amount值大於5時，規則1和規則2以外的所有規則都會評估兩次。
SideEffects 屬性行為
在 XmlDocumentFieldBinding 和 ClassMemberBinding 類別中，SideEffects 屬性會決定要快取系結字段、成員或數據行的值。
在 XmlDocumentFieldBinding 類別中， SideEffects 屬性的預設值為 false。 不過，在 ClassMemberBinding 類別中，SideEffects 屬性的預設值為 true。
因此，如果引擎第二次或更新版本在規則集中存取 XML 檔中的欄位，引擎就會從快取取得欄位的值。 不過，如果引擎第二次或更新版本在規則集中存取 .NET 對象的成員，引擎會從 .NET 物件取得值，而不是從快取取得。
此行為表示，如果您在 .NET ClassMemberBinding 中將 SideEffects 屬性設定為 false，您可以改善效能，因為引擎會從第二次和之後開始從快取取得成員的值。 不過，您只能以程式設計方式設定屬性值，因為Microsoft Rules Composer 不會公開 SideEffects 屬性。
實例和選擇性
XmlDocumentBinding 和 ClassBinding 類別各有下列屬性，規則引擎會使用其值來優化條件評估。 這些屬性值可讓引擎先在條件評估中使用最少的實例，然後使用其餘實例。
實例：工作記憶體中預期的類別實例數目。
如果您事先知道物件實例的數目，您可以將 Instances 屬性設定為這個數位，以改善效能。
選擇性：成功通過規則條件的類別實例百分比。
如果您事先知道傳遞條件的物件實例百分比，您可以將 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 類型的所有規則。 即使只判斷提示衍生類別，如果規則是使用基類中的方法撰寫，而不是在衍生類別中撰寫規則，也會判斷提示基類。