Механизм бизнес-правил - Business rules engine

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

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

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

ИТ-использование

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

История

Статья в Computerworld прослеживает механизмы создания правил до начала 1990-х годов и продуктов таких компаний, как Pegasystems , Fair Isaac Corp и ILOG .

Стратегии дизайна

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

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

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

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

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

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

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

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

Типы систем правил

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

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

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

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

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

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

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

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

Механизмы правил для контроля доступа / авторизации

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

Смотрите также

использованная литература

Библиография

внешние ссылки