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

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

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

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

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

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

История

Статья в Computerworld отслеживает движки правил до начала 1990-х годов и продуктов, подобных Pegasystems, Прекрасный Исаак Corp и ILOG.[1]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ «Вы знаете, где находятся все бизнес-правила вашей компании?». Computerworld. IDG Enterprise. 39 (21): 25. 2005-05-23. ISSN  0010-4841. Получено 2014-02-02. Механизмы правил существуют с начала 1990-х годов, когда их продали такие компании, как Pegasystems Inc. в Кембридже, Массачусетс, Fair Isaac Corp. в Миннеаполисе и ILOG в Маунтин-Вью, Калифорния. Обычно они использовались в отраслях с жесткими правилами, таких как финансы и страхование. Однако за последние несколько лет на рынок вышли многие поставщики, и все больше компаний рассматривают механизмы правил как способ повышения гибкости бизнес-операций.
  2. ^ Ваша система правил основана на событиях? Извлекаются из http://www.sapiens-tech.com/iDuneDownload.dll?GetFile?AppId=225&FileID=216581&Anchor=&ext=.pdf В архиве 2018-09-30 в Wayback Machine.
  3. ^ «Двигатель бизнес-правил» (PDF).
  4. ^ https://darl.ai/home/darl

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

  • Тейлор, Джеймс; Раден, Нил (2007). Умные (достаточно) системы. Прентис Холл. ISBN  0-13-234796-2.
  • Дэвид Линтикум (14 февраля 2007 г.). «Движки правил и SOA». InfoWorld, 14 февраля 2007 г. Получено 23 сентября 2009 г. http://www.infoworld.com/d/architecture/rules-engines-and-soa-158.

внешняя ссылка