Поделиться через

Оптимизация выполнения для обработчика правил Azure Logic Apps

Область применения: Azure Logic Apps (стандартная версия)

В этом руководстве описываются основные понятия, объясняющие, как работает обработчик правил Azure Logic Apps при оценке условий, выполнении действий и разрешении конфликтов между правилами. Модуль правил Azure Logic Apps предоставляет контекст выполнения для набора правил, который создается с помощью Microsoft Rules Composer.

Вы узнаете о трехэтапном алгоритме выполнения подсистемы, о том, как повестка дня и система приоритетов определяют порядок выполнения правил и как побочные эффекты влияют на поведение кэширования. Это руководство также предоставляет стратегии оптимизации производительности, включая советы по управлению типами фактов, логическими операторами, вызовами обновлений и поддержкой наследования классов, чтобы можно было эффективно создавать наборы правил, которые выполняются эффективно.

Основные компоненты

  • Исполнитель набора правил

    Этот компонент реализует алгоритм, отвечающий за оценку условия правила и выполнение действия. Исполнитель набора правил по умолчанию — это дискриминационная сеть и движок вывода по прямой цепочке, предназначенный для оптимизации операций в памяти.

  • Переводчик наборов правил

    Этот компонент принимает объект 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 Application.SSN = CreditRating.SSN AND CreditRating.Value > 725
THEN SendApprovalLetter(Application)

В следующей таблице приведены сведения о фактах.

Факт Описание Поля
Приложение XML-документ, представляющий приложение на кредит на жилье. - Доход: $65000
— SSN: XXX-XX-XXXX
Свойство XML-документ, представляющий имущество для покупки. - Цена: $225,000
CreditRating XML-документ, содержащий кредитный рейтинг претендента на кредит. - Значение: 0-800
— SSN: XXX-XX-XXXX

Обновления рабочей памяти и повестки дня

Изначально рабочая память и повестка дня подсистемы правил пуста. После добавления фактов приложения и свойств обработчик правил обновляет свою рабочую память и повестку дня, как показано ниже.

Рабочая память Повестка дня
-Приложение
- Свойство		 Правило 1

  • Подсистема правил добавляет Правило 1 в свой план, так как условие Application.Income / Property.Price < 0.2 принимает значение true во время фазы сопоставления.

  • В рабочей памяти нет фактов CreditRating , поэтому условие правила 2 не оценивается.

  • Правило 1 является единственным правилом в повестке дня, поэтому правило выполняется, а затем исчезает из повестки дня.

  • Правило 1 описывает действие, результатом которого является создание нового факта, в виде документа CreditRating заявителя, который добавляется в рабочую память.

  • После завершения выполнения правила 1 управление возвращается на этап соответствия.

    Единственным новым объектом для сопоставления является факт Кредитного Рейтинга, поэтому результаты этапа соответствия перечислены ниже.

    Рабочая память Повестка дня
    -Приложение
    - Свойство
    - Кредитный рейтинг    		 Правило 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 (значение=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 (значение=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 потенциально влияет на одно или несколько действий.

Свойство SideEffects для членов класса .NET имеет значение true в качестве значения по умолчанию, что предотвращает кэширование элемента с побочными эффектами обработчика правил. В этом примере обработчик правил не кэширует OrderForm.Status в рабочей памяти. Вместо этого модуль получает последнее значение OrderForm.Status при каждом вычислении правила 1. Если значение свойства SideEffects равно false, обработчик правил кэширует значение при первом вычислении OrderForm.Status. Однако для последующих вычислений в сценариях перенаправления подсистема использует кэшированное значение.

Microsoft Rules Composer в настоящее время не предоставляет способ изменения значения свойства SideEffects . Однако можно программно задать значение свойства SideEffects с помощью фреймворка бизнес-правил, который является библиотекой классов, совместимой с .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 Rules Composer".

Логические операторы 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 …

Обновление вызовов

Функция обновления обновляет факт, который существует в рабочей памяти обработчика правил, что приводит к повторной оценки всех правил, использующих обновленный факт в условиях. Это означает, что вызовы функций обновления могут быть дорогостоящими, особенно если для многих правил требуется повторное вычисление из-за обновленных фактов. В некоторых ситуациях можно избежать повторной оценки правил.

Например, рассмотрим следующие правила:

Правило 1

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

Правило 2

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

Все остальные правила в наборе правил используют StatusObj.Flag в их условиях. При вызове функции Update в объекте StatusObj все правила будут переоценены. Независимо от значения в поле "Сумма", все правила, кроме правила 1 и правила 2, оцениваются дважды: один раз перед вызовом Update и один раз после вызова обновления.

Вместо этого можно задать значение Flag в false перед вызовом набора правил, а затем использовать только правило 1 для задания флага в наборе правил. В этом случае функция update вызывается только в том случае, если значение "Сумма" больше 5. Функция update не вызывается, если сумма меньше или равна 5. Таким образом, все правила, кроме правила 1 и правила 2 , оцениваются дважды, только если значение суммы больше 5.

Поведение свойств 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 в их условиях. Несмотря на то, что утверждается только производный класс, базовый класс также получает утверждение, если правила записываются с помощью методов в базовом классе, а не в производном классе.

Связанный контент

  • Last updated on