Двигатель бизнес-правил

Механизм бизнес-правил — это программная система , которая выполняет одно или несколько бизнес-правил в среде выполнения производства . Правила могут исходить из правового регулирования («Сотрудник может быть уволен по любой причине или без причины, но не по незаконной причине»), политики компании («Все клиенты, которые тратят более 100 долларов за один раз, получат скидку 10%) или других источников. Система бизнес-правил позволяет определять, тестировать, выполнять и поддерживать эти политики компании и другие операционные решения отдельно от кода приложения .

Механизмы правил обычно поддерживают правила, факты, приоритет (оценку), взаимное исключение, предварительные условия и другие функции.

Программное обеспечение для обработки правил обычно предоставляется как компонент системы управления бизнес-правилами , которая, среди прочих функций, обеспечивает возможность: регистрировать, определять, классифицировать и управлять всеми правилами, проверять согласованность определений правил («Клиенты уровня Gold имеют право на бесплатную доставку, если объем заказа > 10» и «Максимальный объем заказа для клиентов уровня Silver = 15»), определять взаимосвязи между различными правилами и связывать некоторые из этих правил с ИТ- приложениями, на которые они влияют или которым необходимо обеспечить соблюдение одного или нескольких правил.

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

Статья в Computerworld прослеживает историю движков правил с начала 1990-х годов и до таких продуктов, как Pegasystems , Fair Isaac Corp, ILOG ^[1] и eMerge ^[2] от Sapiens .

Многие усилия организаций по правилам объединяют аспекты того, что обычно считается проектированием рабочего процесса , с традиционным проектированием правил. Эта неспособность разделить два подхода может привести к проблемам с возможностью повторного использования и контроля как бизнес-правил, так и рабочих процессов. Подходы к проектированию, которые избегают этой дилеммы, разделяют роль бизнес-правил и рабочих процессов следующим образом: ^[3]

• Бизнес-правила производят знания;
• Рабочие процессы выполняют бизнес-задачи.

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

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

Для создания архитектуры, использующей механизм бизнес-правил, необходимо установить интеграцию между BPM (Business Process Management) и платформой BRM (Business Rules Management), которая основана на процессах, реагирующих на события или проверяющих бизнес-суждения, которые определяются бизнес-правилами. На рынке есть некоторые продукты, которые изначально обеспечивают такую ​​интеграцию. В других ситуациях этот тип абстракции и интеграции должен быть разработан в рамках конкретного проекта или организации.

Большинство механизмов правил на основе Java предоставляют технический интерфейс уровня вызовов, основанный на стандарте интерфейса прикладного программирования (API) JSR-94, что позволяет осуществлять интеграцию с различными приложениями, а многие механизмы правил допускают сервисно-ориентированную интеграцию посредством веб-стандартов, таких как WSDL и SOAP .

Большинство движков правил предоставляют возможность разрабатывать абстракцию данных , которая представляет бизнес-сущности и отношения, для которых должны быть написаны правила. Эта модель бизнес-сущности обычно может быть заполнена из различных источников, включая XML , POJO , плоские файлы и т. д. Не существует стандартного языка для написания самих правил. Многие движки используют синтаксис, подобный Java , в то время как некоторые позволяют определять пользовательские языки, удобные для бизнеса.

Большинство движков правил функционируют как вызываемая библиотека. Однако становится все более популярным запускать их как общий процесс, похожий на то, как ведут себя СУРБД . Большинство движков рассматривают правила как конфигурацию, которая должна быть загружена в их экземпляр процесса, хотя некоторые из них на самом деле являются генераторами кода для всего экземпляра выполнения правила, а другие позволяют пользователю выбирать.

Существует несколько различных типов движков правил. Эти типы (как правило) различаются по тому, как правила планируются к выполнению.

Большинство систем правил, используемых предприятиями, представляют собой прямую цепочку , которую можно разделить на два класса:

• Первый класс обрабатывает так называемые правила производства/ вывода . Эти типы правил используются для представления поведения типа ЕСЛИ условие ТО действие. Например, такое правило может ответить на вопрос: «Должна ли быть разрешена ипотека этому клиенту?», выполняя правила формы «ЕСЛИ некоторое-условие ТО разрешить-клиенту-ипотеку».
• Другой тип движка правил обрабатывает так называемые правила реакции/ события условия действия . Реактивные движки правил обнаруживают и реагируют на входящие события и обрабатывают шаблоны событий. Например, реактивный движок правил может использоваться для оповещения менеджера, когда определенные товары отсутствуют на складе.

Самое большое различие между этими типами заключается в том, что движки правил производства выполняются, когда пользователь или приложение вызывают их, обычно в режиме без сохранения состояния. Реактивный движок правил автоматически реагирует на события, обычно в режиме с сохранением состояния. Многие (и, конечно, большинство) популярных коммерческих движков правил имеют возможности как правил производства, так и правил реакции, хотя они могут подчеркивать один класс над другим. Например, большинство движков бизнес-правил в первую очередь являются движками правил производства, тогда как движки правил сложной обработки событий подчеркивают правила реакции.

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

Другой тип механизма правил автоматически переключается между обратной и прямой цепочкой несколько раз во время рассуждения, например, система Internet Business Logic, которую можно найти с помощью поиска в Интернете.

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

Существуют некоторые обстоятельства, когда вывод на основе нечеткой логики может быть более подходящим, когда эвристики используются в обработке правил, а не булевы правила. Примерами могут служить классификация клиентов, вывод отсутствующих данных, расчеты ценности клиентов и т. д. Язык DARL ^[4] и связанный с ним механизм вывода и редакторы являются примером такого подхода.

Одним из распространенных вариантов использования движков правил является стандартизированный контроль доступа к приложениям. OASIS определяет архитектуру движка правил и стандарт, предназначенный для контроля доступа, называемый XACML (eXtensible Access Control Markup Language). Одним из ключевых различий между движком правил XACML и движком бизнес-правил является тот факт, что движок правил XACML не имеет состояния и не может изменять состояние каких-либо данных. движок правил XACML, называемый точкой принятия решения о политике (PDP), ожидает двоичный вопрос «Да/Нет», например «Может ли Алиса просмотреть документ D?», и возвращает решение, например «Разрешить/запретить».

• Бизнес-правило
• Производственная система
• Механизм вывода
• Алгоритм Рете
• Правила рипл-даун
• Система управления бизнес-правилами
• Семантический рассуждающий
• Движок рабочего процесса
• Язык выполнения бизнес-процессов (BPEL)
• Список двигателей BPEL
• Список движков BPMN 2.0

• Тейлор, Джеймс; Раден, Нил (2007). Smart (Enough) Systems. Prentice Hall. ISBN 0-13-234796-2 . 
• Дэвид Линтикум (14.02.2007). «Движки правил и SOA». InfoWorld, 14.02.2007. Получено 23.09.2009 с сайта http://www.infoworld.com/d/architecture/rules-engines-and-soa-158.

• Рекомендации по принятию решения об использовании механизма правил?