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

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

  • Статья

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

Внимание

Эта возможность входит в предварительную версию, и на нее распространяются Дополнительные условия использования предварительных версий Microsoft Azure.

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

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

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

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

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

    Этот компонент принимает объект RuleSet в качестве входных данных и создает исполняемое представление набора правил. Переводчик по умолчанию создает скомпилированную сеть дискриминации из определения набора правил.

  • Перехватчик отслеживания набора правил

    Этот компонент получает выходные данные от исполнителя набора правил и пересылает их в средства отслеживания и мониторинга набора правил.

Оценка условий и выполнение действия

Подсистема правил Azure Logic Apps — это эффективный механизм вывода, который может связывать правила с объектами .NET или XML-документами. Подсистема правил использует трехэтапный алгоритм для выполнения набора правил со следующими этапами:

  • Спичка

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

  • Разрешение конфликтов

    На этапе разрешения конфликтов подсистема правил проверяет правила, которые являются кандидатами на выполнение, чтобы определить следующий набор действий правил для выполнения на основе предопределенной схемы разрешения. Подсистема правил добавляет все правила кандидатов, найденные на этапе сопоставления, в повестку дня обработчика правил.

    Схема разрешения конфликтов по умолчанию основана на приоритетах правил в наборе правил. Приоритет — это свойство правила, которое можно настроить в Microsoft Rules Composer. Чем больше число, тем выше приоритет. Если запускается несколько правил, обработчик правил сначала выполняет действия с более высоким приоритетом.

  • Действие

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

    Внимание

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

Пример

В следующем примере показано, как работает трехэтапный алгоритм сопоставления, разрешения конфликтов и действий:

Правило 1. Оценка дохода

  • Декларативное представление

    Получить кредитный рейтинг заявителя только в том случае, если отношение дохода к кредиту заявителя меньше 0,2.

  • IF — представление с помощью бизнес-объектов

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

Правило 2. Оценка кредитного рейтинга

  • Декларативное представление

    Утвердить заявителя только в том случае, если кредитный рейтинг заявителя превышает 725.

  • IF — ПРЕДСТАВЛЕНИЕ с помощью бизнес-объектов:

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

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

Факт Description Поля
Приложение 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 элемент управления возвращается на этап соответствия.

    Единственным новым объектом для сопоставления является факт 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 (значение=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 потенциально влияет на одно или несколько действий.

Свойство 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, а не из кэша.

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

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