適用於:Azure Logic Apps (標準)
Azure Logic Apps 規則引擎會提供規則集的執行內容,您可以使用Microsoft 規則編輯器建立該規則集。 本指南說明規則引擎運作方式的核心概念,並提供作業和執行的最佳化建議。
核心元件
規則集執行程式
此元件會實作負責規則條件評估和動作執行的演算法。 預設規則集執行程式是辨識網路型的正向鏈結推斷引擎,其設計目的是最佳化記憶體內部作業。
規則集翻譯工具
此元件會採用 RuleSet 物件作為輸入,並產生規則集的可執行表示法。 預設記憶體內部翻譯工具會從規則集定義建立編譯的辨識網路。
規則集追蹤攔截器
此元件會接收來自規則集執行程式的輸出,並將該輸出轉送至規則集追蹤和監視工具。
條件評估和動作執行
Azure Logic Apps 規則引擎是高效推斷引擎,可將規則連結至 .NET 物件或 XML 文件。 規則引擎會使用三階段演算法進行規則集執行,並具有下列階段:
比對
在比對階段中,規則引擎會使用規則條件中所定義的述詞,比對使用事實類型的述詞,而這些述詞是規則引擎工作記憶體中維護的物件參考。 為了提高效率,模式比對會在規則集中的所有規則中發生,而且跨規則共用的條件只會比對一次。 規則引擎可能會將部分條件比對儲存在工作記憶體中,以加速後續模式比對作業。 來自模式比對階段的輸出包含規則引擎議程的更新。
衝突解決
在衝突解決階段中,規則引擎會檢查候選執行的規則,以根據預先決定的解決配置來決定下一組要執行的規則動作。 規則引擎會將比對階段期間找到的所有候選規則新增至規則引擎的議程。
預設的衝突解決配置是根據規則集中的規則優先順序。 優先順序是您可以在 Microsoft 規則編輯器中設定的規則屬性。 數字越大,優先順序越高。 如果觸發多個規則,規則引擎會先執行較高優先順序的動作。
動作
在動作階段中,規則引擎會在已解決的規則中執行動作。 規則動作可以將新的事實判斷為規則引擎,這會導致循環繼續進行,也稱為正向鏈結。
重要事項
演算法永遠不會取代目前執行中的規則。 規則引擎會在比對階段重複之前,執行目前執行中規則中的所有動作。 不過,規則引擎議程上的其他規則不會在比對階段再次開始之前執行。 比對階段可能會導致規則引擎在這些規則執行之前,將其從議程中移除。
範例
下列範例顯示比對、衝突解決和動作的三階段演算法如何運作:
規則 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 事實,因此比對階段的結果如下:
工作記憶體 議程 - 應用程式
- 屬性
信用評等規則 2 規則 2 現在會執行,這會呼叫一個函式,將核准信函傳送給申請者。
在規則 2 完成之後,控制項會返回比對階段。 不過,沒有更多新的事實可供比對,而且議程是空的,因此正向鏈結會終止,而且規則集執行已完成。
議程和優先順序
若要了解 Azure Logic Apps 規則引擎如何評估規則和執行動作,您也必須了解議程和優先順序的概念。
議程
規則引擎的議程是將執行規則加入佇列的排程。 引擎執行個體的議程存在,並針對單一規則集採取動作,而不是一系列規則集。 當事實判斷提示至工作記憶體,並滿足規則的條件時,引擎會將規則放在議程上,並根據優先順序執行該規則。 引擎會依從上到下的優先順序執行規則的動作,然後執行議程上下一個規則的動作。
規則引擎會將規則中的動作視為區塊,因此所有動作都會在引擎移至下一個規則之前執行。 不論區塊中的其他動作為何,規則區塊中的所有動作都會執行。 如需斷言的詳細資訊,請參閱 使用控制函式優化規則引擎。
下列範例顯示議程的運作方式:
規則 1
IF
Fact1 == 1
THEN
Action1
Action2
規則 2
IF
Fact1 > 0
THEN
Action3
Action4
當值為 1 的 Fact1 事實判斷提示至引擎時,規則 1 和規則 2 的條件均已滿足。 因此,引擎會將這兩個規則移至議程,以執行其動作。
| 工作記憶體 | 議程 |
|---|---|
| 事實 1 (value=1) | 規則 1: - Action1 - 行動2 規則 2: - 動作3 - 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 規則編輯器目前不提供修改 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 規則編輯器中以析取範例建置規則可能很棘手。
開發執行 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 函式時,會重新評估所有規則。 無論 [數量] 欄位中的值是什麼,規則 1 和規則 2 以外的所有規則都會評估兩次:在 Update 呼叫之前一次和 Update 呼叫之後一次。
相反地,您可以在叫用規則集之前,將 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 規則編輯器不會公開 SideEffects 屬性。
執行個體和選擇性
XmlDocumentBinding 和 ClassBinding 類別各有下列屬性,規則引擎會使用其值來最佳化條件評估。 這些屬性值可讓引擎先在條件評估中使用盡可能少的執行個體,然後再使用剩餘的執行個體。
執行個體:工作記憶體中預期的類別執行個體數目。
如果您事先知道物件執行個體的數目,您可以將 Instances 屬性設定為這個數字以改善效能。
選擇性:成功通過規則條件的類別執行個體百分比。
如果您事先知道通過條件的物件執行個體百分比,您可以將 Selectivity 屬性設定為這個百分比以改善效能。
您只能以程式設計方式設定這些屬性值,因為 Microsoft 規則編輯器不會公開它們。
支援類別繼承
繼承能夠使用現有類別中的所有功能,並擴充這些功能而無需重寫原始類別,這是物件導向程式設計 (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 類型的所有規則。 即使只判斷提示衍生類別,如果規則是使用基底類別中的方法撰寫,而不是衍生類別中的方法,則也會判斷提示基底類別。