Rules engine что это
rules engine
Смотреть что такое «rules engine» в других словарях:
Business rules engine — A business rules engine is a software system that executes one or more business rules in a runtime production environment. The rules might come from legal regulation ( An employee can be fired for any reason or no reason but not for an illegal… … Wikipedia
Engine swap — Warning: in some jurisdictions with strict smog rules it may not be possible to register a late model vehicle with an engine swap, even if it can be proven that it produces less pollution than the original engine (owing to visual inspection… … Wikipedia
Engine (computer science) — An engine is a continuation based construct that provides timed preemption. Engines which can contain other engines are sometimes called nesters and engines which don t have this ability are then called flat engines. To implement timed preemption … Wikipedia
Inference engine — In computer science, and specifically the branches of knowledge engineering and artificial intelligence, an inference engine is a computer program that tries to derive answers from a knowledge base. It is the brain that expert systems use to… … Wikipedia
Business rules approach — Business rules are abstractions of the policies and practices of a business organization. The Business Rules Approach is a development methodology where rules are in a form that is used by, but does not have to be embedded in business process… … Wikipedia
Cleverpath AION Business Rules Expert — (formerly Platinum AIONDS, and before that Trinsic AIONDS, and originally Aion) is an expert system and Business rules engine owned by Computer Associates by 2005.[1] The product was created around 1986 as Aion by the Aion company. In its initial … Wikipedia
Parser Grammar Engine — The Parser Grammar Engine (originally Parrot Grammar Engine) or PGE is a compiler and runtime for a Perl 6 rules for the Parrot virtual machine. [cite web | url=http://search.cpan.org/ ltoetsch/parrot 0.2.2/compilers/pge/README | title=Parrot… … Wikipedia
NASCAR rules and regulations — The National Association for Stock Car Auto Racing (NASCAR) makes and enforces numerous rules and regulations that transcend all racing series. NASCAR issues a different rule book for each racing series; however, rule books are published… … Wikipedia
Pontiac V8 engine — From 1955 to 1981 the Pontiac Division of General Motors manufactured its own, unique V8 engines, distinct from Buick, Cadillac, Chevrolet, or Oldsmobile. Displacement began at 287 in³ and grew as large as 455 in³ (7.5 L) by 1970. Pontiac s… … Wikipedia
Что такое Rule-Engine?
Дата публикации Oct 3, 2019
Здесь я пытаюсь объяснить механизм правил очень простым способом. Давайте начнем с проблемы. Предположим, если я скажу вам, что вам нужно создать банковское приложение, в котором вы должны реализовать логику, как указано ниже.
Вы можете легко реализовать эти типы правил или логики в своем приложении. Но если вы получите некоторые дополнительные требования, такие как:
Для достижения всех этих требований в нашем приложении мы можем использоватьПравило двигатель,Но прежде чем запускать механизм правил, давайте разберемся с несколькими терминологиями и опытом.
терминологической:
Условие также известно какфакт или предшественники или шаблоны, И действие также известно какследствие,
Знание в виде правил:
Теперь давайте попробуем разобраться с движком правил.
Правило-Engine
Это программа экспертной системы, которая запускает правила для данных и, если выполняется какое-либо условие, выполняет соответствующие действия.
На приведенной выше диаграмме показано, что мы собираем знания в форме правил (форма if-then) и храним их в любом магазине. Правила могут храниться в любом хранилище, таком как файлы или базы данных. Теперь механизм вывода выбирает правила в соответствии с требованиями и запускает их на входных данных или запросах. Если какие-либо шаблоны / условия соответствуют, тогда он выполняет соответствующее действие и возвращает результат или решение.
Механизм логического вывода
Программа Inference-Engine работает в три этапа, чтобы выполнить правило для данных.
Алгоритм, который мы можем использовать для сопоставления с образцом:
Droolsявляется одной из реализаций двигателя правил и использоватьАлгоритм повторениядля сопоставления с образцом. Это один из лучших алгоритмов для сопоставления с образцом.
Выход первого этапа является конфликтным набором.Конфликтный набор означает, что для одного и того же факта или условия может быть возможно, что выполняется более одного правила. Таким образом, он возвращает набор правил конфликта.
Методы вывода:
В правилах двигателей обычно используется одно из следующихметоды выводареализовать механизм вывода.
Но прежде чем понять метод логического вывода, давайте разберемсярассуждения, Есть два типа рассуждений.
1. Направленная на цель / обратная аргументация:Это работает в обратном направлении от цели Здесь мы начнем с основной цели, а затем перейдем к подцелям. Таким образом, в целенаправленных рассуждениях, если мы хотим достичь главной цели, мы должны думать, что «чтобы достичь главной цели, какие подцели мы должны достичь ».
Пример:Если мы планируем провести вечер, и для этого мы планируем пойти в кино, на прогулку и на ужин. затемвечернаша главная цельикино, прогулка и ужинявляются подцелями основной цели,
2. Обоснование данных / пересылка:Он начинается с доступных данных и использует правила для извлечения дополнительных данных, пока не будет достигнута цель. Здесь мы смотрим на данные, и если мы нашли какой-то шаблон, то он выполняет соответствующее действие.
Пример:Предположим, мы должны выяснитьокрас питомца по кличке Фрицс заданными правилами и данными.
Здесь, используя данные правила и данные, мы можем извлечь больше данных, таких как:
Итак, теперь давайте обсудим методы вывода:
Прямая цепочка:
Обратная цепочка:
Есть еще одна категория под названиемГибридная цепочка, Слюни используют это. Это сочетание прямой и обратной цепочки.
Преимущества правила двигателя
Все приведенные выше конкретные требования в данном примере можно рассматривать как преимущества механизма правил.
Реализация правил двигателя
Есть много реализаций, доступных для движка правил. Немного похоже на:
Выступает DMN, дирижирует ZeeBe: как использовать бизнес-правила в микросервисах
Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. Так сложилось, что, единожды попробовав бизнес-процессы на Camunda, я стал адептом этой технологии и стараюсь ее применять в проектах со сложной логикой. Действительно сама идея подкупает: рисуешь процесс в удобном GUI-редакторе (моделлере), а фреймворк выполняет эти действия по порядку, соблюдая большой спектр элементов нотации BPMN.
К тому же в Camunda есть встроенная поддержка еще одной нотации — DMN (Decision Model and Notation): она позволяет в простой и понятной форме создавать таблицы принятия решений по входящим наборам данных.
Но чего-то все же не хватает. Может, добавим немного скорости?
Почему ускоряем процессы
В банковской сфере бизнес-процессы широко используются там, где довольно часто встречаются длинные, с нетривиальной логикой процессы взаимодействия как с клиентом, так и между банковскими подсистемами.
Что обычно характеризует такие процессы:
от момента создания до завершения процесса может пройти несколько дней;
участвует большое количество сотрудников;
осуществляется интеграция со множеством банковских подсистем.
Фреймворк Camunda прекрасно справляется с такими задачами, однако, заглянем под капот: там находится классическая база данных для осуществления транзакционности.
Но что если к логической сложности добавляется еще и требование к быстродействию? В таких случаях база данных рано или поздно становится «узким горлышком»: большое количество процессов начинает создавать блокировки, и это в конечном итоге приводит к замедлению.
Отличные новости: воспользуемся ZeeBe
В случаях, когда DMN все же необходим, он может быть добавлен как отдельное приложение. Именно такую архитектуру мы и рассматриваем в данной статье.
микросервис, инициирующий событие и запускающий процесс (event-handler);
микросервис обработки бизнес-правил (rules-engine);
микросервис, эмулирующий действия (action).
Данные микросервисы могут быть запущены в неограниченном количестве экземпляров для того, чтобы справиться с динамической нагрузкой.
Из оркестрации у нас:
микросервис с брокером сообщений ZeeBe (zeebe);
микросервис визуализации работающих процессов simplemonitor (zeebe-simple-monitor).
А присматривать за всеми микросервисами будет кластер k8s.
Схема взаимодействия
С точки зрения бизнес-логики в примере будет рассмотрен следующий бизнес-сценарий:
из внешней системы происходит запрос в виде rest-обращения с передачей параметров;
запускается бизнес-процесс, который «пропускает» входящие параметры через бизнес-правило;
в зависимости от полученного решения из бизнес-правил запускается микросервис действий с различными параметрами.
Теперь поговорим подробнее о каждом микросервисе.
Микросервис zeebe
Данный микросервис состоит из брокера сообщений ZeeBe и экспортера сообщений для отображения в simple-monitor. Для ZeeBe используется готовая сборка, которую можно скачать с github. Подробно о сборке контейнера можно посмотреть в исходном коде в файле build.sh
Принцип ZeeBe — минимальное число компонентов, входящих в ядро, поэтому по умолчанию ZeeBe — это брокер сообщений, работающий по схемам BPMN. Дополнительные модули подключаются отдельно: например, для отображения процессов в GUI понадобится экспортер (доступны разные экспортеры, к примеру, в ElasticSearch, в базу данных и т.п.).
В данном примере возьмем экспортер в Hazelcast. И подключим его:
добавим zeebe-hazelcast-exporter-0.10.0-jar-with-dependencies.jar в папку exporters;
добавим в файл config/application.yaml следующие настройки:
Данные активных процессов будут храниться в памяти, пока simplemonitor их не считает. Hazelcast будет доступен для подключения по порту 5701.
Микросервис zeebe-simplemonitor
Во фреймворке ZeeBe есть две версии GUI-интерфейса. Основная версия, Operate, обладает большим функционалом и удобным интерфейсом, однако, использование Operate ограничено специальной лицензией (доступна только версия для разработки, а лицензию для прода следует запрашивать у производителя).
Simplemonitor можно оформить тоже в виде микросервиса, который периодически подключается к порту hazelcast брокера ZeeBe и выгружает оттуда данные в свою базу данных.
Можно выбрать любую базу данных Spring Data JDBC, в данном примере используется файловая h2, где настройки, как и в любом Spring Boot приложении, вынесены в application.yml
Микросервис event-handler
Это первый сервис в цепочке, он принимает данные по rest и запускает процесс. При старте сервис осуществляет поиск файлов bpmn в папке ресурсов:
Микросервис имеет endpoint, и для простоты принимает вызовы по rest. В нашем примере передаются 2 параметра, сумма и лимит:
Следующий код отвечает за запуск процесса:
Сам процесс нарисован в специальной программе ZeeBe modeler (почти копия редактора Camunda modeler) и сохраняется в формате bpmn в папке workflow в ресурсах микросервиса. Графически процесс выглядит как:
У каждой задачи (обозначаем прямоугольником на схеме) есть свой тип задач, который устанавливается в свойствах задачи, например, для запуска правил:
Каждый дополнительный микросервис в данном примере будет использовать свой тип задач. Тип задач очень похож на очередь в Kafka: при возникновении задач к нему могут подключаться подписчики — worker’ы.
После старта процесс продвинется на один шаг, и появится сообщение типа DMN.
Микросервис rules-engine
Благодаря прекрасной модульной архитектуре Camunda есть возможность использовать в своем приложении (отдельно от самого фреймворка Camunda) движок правил принятия решения.
Для его интеграции с вашим приложением достаточно добавить его в зависимости maven:
Сами правила создаются в специальном графическом редакторе Camunda modeler. Одна диаграмма DMN имеет два вида отображения.
Entity Relation Diagram (вид сверху) показывает зависимости правил друг от друга и от внешних параметров:
На такой диаграмме можно представить одно или несколько бизнес-правил. В текущем примере оно одно зависит от двух параметров — сумма и лимит. Представление на этой диаграмме параметров и комментариев необязательно, но является хорошим стилем оформления.
Само же бизнес-правило содержит более детальный вид:
Как видно из примера выше, бизнес-правило представляется в виде таблицы, в которой перечислены входящие и результирующие параметры. Инструмент достаточно богатый, и можно использовать различные методы сравнения, диапазоны, множества, несколько типов политик правил (первое совпадение, множественное, последовательность по диаграмме и т.п.). Такая диаграмма сохраняется в виде файла dmn.
Посмотрим на примере, где такой файл располагается в папке dmn-models в ресурсах микросервиса. Для регистрации диаграммы при старте микросервиса происходит его однократная загрузка:
Для того, чтобы подписаться на сообщения от ZeeBe, требуется осуществить регистрацию worker’а:
В данном коде осуществляется подписка на событие DMN, вызов модели правил при получении сообщения от ZeeBe и результат выполнения правила сохранятся обратно в бизнес-процесс в виде переменной result (константа RESULT_DECISION_FIELD ).
Когда данный микросервис отчитывается ZeeBe о выполнении операции, бизнес-процесс переходит к следующему шагу, где происходит выбор пути в зависимости от выполнения условия, заданного в свойствах стрелочки:
Микросервис action
В зависимости от полученного результата будет вызван один и тот же микросервис action, но с различными параметрами. Данные параметры задаются в закладке headers:
Также передачу параметров можно сделать и через закладку Input/Output, тогда параметры придут вместе с переменными процесса, но передача через headers является более «каноничной».
Посмотрим на получение сообщения в микросервисе:
Здесь происходит логирование всех переменных бизнес-процесса:
Исходный код
Компиляция образов Docker
Для каждого микросервиса есть различный набор действий, направленных на подготовку образов docker и загрузки этих образов в открытые репозитории hub.docker.com.
Загрузка микросервисов в кластер k8s
Для развертывания в кластере необходимо сделать следующие действия:
Создать namespace в кластере kubectl create namespace zeebe-dmn-example
Создать config-map общих настроек
Yml-файлы находятся в соответствующих проектах:
Теперь осталось последовательно создать поды и сервисы. Указанные yml-файлы находятся в корне соответствующих проектов.
Смотрим, как отображаются наборы подов в кластере:
И мы готовы к тестовому запуску!
Запуск тестового процесса
Запуск процесса осуществляется открытием в браузере соответствующий URL. К примеру, сервис event-handler имеет сервис с внешним IP и портом 81 для быстрого доступа.
Зеленым цветом выделен путь, по которому прошел процесс. Серым выделены выполненные задачи, а снизу отображены переменные процесса.
Поделюсь, какими ресурсами пользовался для подготовки прототипа
Небольшое послесловие вместо итогов
Из плюсов:
архитектура разработанного прототипа получилась гибкой и расширяемой. Можно добавлять любое количество микросервисов для обработки сложной логики;
простая нотация BPMN и DMN позволяет привлекать аналитиков и бизнес к обсуждению сложной логики;
Zeebe показал себя как очень быстрый фреймворк, задержки на получение/отправку сообщений практически отсутствуют;
Zeebe изначально разрабатывался для работы в кластере, в случае необходимости можно быстро нарастить мощности;
без ZeeBe Operate можно вполне обойтись, Simple-Monitor отвечает минимальным требованиям.
Из минусов:
хотелось бы иметь возможность редактирования DMN непосредственно в ZeeBe modeler (как это реализовано в Camunda), на данный момент, приходится использовать оба моделлера;
к сожалению, только в Enterprise версии Camunda есть возможность просмотра пути, по которому принималось решение:
Это очень полезная функция при отладке правил. В Community версии приходится добавлять дополнительное поле типа output для логирования, либо разработать свое решение визуализации.
При развертывании прототипа в реальных условиях в кластере k8s необходимо добавить ограничения по ресурсам (CPU и RAM), также нужно будет подобрать лучшую систему хранения исторических данных.
Где применять такие технологии:
как оркестрация внутри одной команды или продукта в виде перекладывания сложной логики на диаграммы BPMN / DMN;
в сфере, где идет потоковая обработка данных с большим количеством интеграций. В банке это может быть проведение или проверка транзакций, обработка данных из внешних систем или просто многоэтапная трансформация данных;
как частичная альтернатива существующего стека ESB или Kafka для интеграции между командами.
Коллеги, понимаю, что есть множество разных технологий и подходов. Буду рад, если поделитесь в комментариях вашим опытом: как вы решаете подобные задачи?
Rule Engine, или как сделать систему проще
В этой статье я не буду касаться технических вопросов и не приведу примеров кода. Эта статья призвана дать понятие, что такое Rule Engine, для чего эта штука и что она умеет. Если вас заинтересует такой подход к построению систем, то вы без проблем найдете Rule Engine на ваш вкус и цвет.
Итак, зачем же эта штука нужна. Возьмем какое нибудь предприятие, которое живет в весьма быстром ритме. Например один из крупнейших аэропортов, где каждые несколько минут происходит посадка или взлет.
Вопросы и ответы
Задайте себе вопросы:
Второй вопрос проще, поэтому ответим сначала на него. Минимальная цена это несколько десятков тысяч евро, а вот максимальная несколько сотен человеческих жизней. А теперь к первому вопросу.
Итак, кто? Ответ: в большинстве случаев люди. Не без помощи компьютеров конечно, но все таки люди. Теперь вопрос: как? Есть список возможных вариантов, человек из них выбирает. Вариантов дается немного, поэтому в принципе особых мук выбора нет. И последний вопрос: на основании чего? Есть правила, их нужно придерживаться и по возможности выполнять. Например, задержка вылета более чем на полчаса весьма нежелательна. Ну и главный вопрос: а причем тут Rule Engine?
Что бы ответить на этот вопрос, нужно ответить на другой вопрос, а именно: а почему человеку предлагается всего несколько вариантов, если:
Ответ: а потому что, все что вы только что прочитали, является некоторым подобием идеальной ситуации, которую все бы хотели видеть, но которая сильно упрощается, потому что в таком случае человек просто не справился бы с потоком информации. Поэтому количество правил, на которые действительно обращают внимание уменьшают в лучшем случае до десятка, а иногда и меньше. И планируют на часок-другой вперед. Вот и появляются всякие неприятные ситуации, а некоторые из них становятся просто хроническими, как например запаздывание вылета на полчаса. В результате теряются весьма большие деньги, т.к. самолеты не летают, как должны, а стоят на полосах и ждут не известно чего. Пассажиры нервничают, репутация компании страдает, она ругается с аэропортом, т.к. платит тому весьма не маленькую сумму денег за услуги и вправе рассчитывать на соответствующее качество оных. Конечно, все уже давно привыкли и прекрасно понимают, что работа аэропорта не из легких, но ведь хочется как всегда лучшего. Как раз в этот момент на помощь приходит Rule Engine.
Что за зверь такой?
Предположим у вас есть объект А, у него есть численное value и булево priority. Есть правило: если value>5, то ставим объекту приоритет, т.е. записываем ему в priority значение true. Таким образом, если у нас есть куча объектов, то прогоняя их через это правило, мы определяем, какие из них согласно этому правилу важны. Это будет первый этап сортировки. Если на этом этапе мы не смогли однозначно определить, что объект А важнее чем объект Б, то нам требуется еще одно правило, или мы решаем, что объекты равнозначны. Именно выполнение правил Rule Engine и делает. Вы даете ей правила, объекты и спрашиваете, какие из объектов к правилам подходят, какие нет. Правило часто и густо выглядит примерно так:
Вот так вот просто. Как вы сами понимаете, правило может быть таким сложным, как вы хотите/как надо.
В чем смысл?
А смысл в том, что эти правила хранятся в отдельном файлике, или в базе данных или еще где нибудь/как нибудь. Если вам надо правило изменить, вам не надо трогать вашу программу, достаточно это самое правило изменить и сказать Rule Engine, что теперь правила изменились. Если какая то определенная Rule Engine вам вдруг разонравилась(тормозит например), вы можете ее без особых проблем заменить на другую.
В чем подвох?
Есть множество моментов, которые иногда совсем не тривиальны. Например: у нас есть два правила:
И есть объект, у которого value равно 6. Даем мы Rule Engine этот объект и эти правила, что получим? Неправильно! Почему? Потому что надо еще сказать, в каком порядке правила применяются, т.к. от порядка выполнения зависит результат. Для того что бы сказать Rule Engine в каком порядке она должна применять правила, надо поставить им приоритеты. Если у двух правил приоритеты одинаковые, значит их очередность не влияет на результат.
Или вот еще вопрос. Как обрабатывать правила? Все, пока есть хоть одно, которое выполняется? Тогда можно легко подвесить систему, т.к. одно правило будет что нибудь уменьшить а другое это же самое увеличивать. А может применять правило ровно один раз? Или проверять правило ровно один раз? Чувствуете разницу?
Хочу блэкджек и развратных женщин!
Есть такая штука. Даже много штук, вам понравится.
Правила можно тестить. Да-да, вы же не хотите обрушить вашу систему из-за того, что вы в правиле циферку не ту написали?
Правила можно дебагить. Классно, правда? Вот вам Rule Engine выдает интересный результат. Весьма интересный. Но не тот, который вы ожидаете. Что делать? Дебагить, что ж еще! Ставим точку останова в правиле и вперед.
У правил есть версии. А то как же без системы версий? А вдруг окажется, что наше новое чудное правило, которое мы успешно протестили, приносит нам одни убытки, т.к. раньше мы слали подарки бездетным женщинам, а теперь шлем их лицам интересной сексуальной ориентации? Как исправить? Идем в систему версий, достаем оттуда старое правило, смотрим, кто его изменил, увольняем его нафиг/ лишаем премии/ смотрим внимательно(а вроде мужик ведь? а?)
Проверяем правила на корректность/ не противоречивость. Например:
Угадайте, что делает это правило? Правильно, ничего! Убираем это правило, ибо лишнее.
Правила можно накликать. В смысле не как беду накликать, а мышкой накликать. Есть визуальный редактор правил. Теперь ваша секретарша Маша может сама творить интересные вещи с вашей системой. Степень вашего удивления зависит только от креативности Маши.
А вот манагеру Феде кликать правила не нравится, он ведь манагер, он хочет рулить правила писать. Можно и так. Для этого есть такая штука как DSL (Domain Specific Language). Теперь Федя может написать:
«Если клиент студент, то кредит ему не давать».
Ну хоть одну фамилию то назови!
Что, хотите узнать, как же такое чудо называется, где искать? Ну количество Rule Engine довольно большое. Все что я описал есть например у JBoss Drools. Написана на Java, бесплатная, известная. Рекомендую.
Сам то юзал?
А то. Я писал прототип системы (описана в начале статьи) для одного весьма известного аэропорта в рамках написания своей бакалаврской работы. Было интересно, узнал много нового. На защите работы бакалавра, дабы не говорить абстрактно, что я там творил( потому как низзя!), написал простую программку, которая несколько раз в секунду генерировала целое число, записывала его в список и этот список сортировала. Результат сортировки я выводил тупо в консоль. Дома я написал несколько правил, например:
И т.д. На защите я преподам эти правила показал, потом мы быстро накликали в редакторе еще одно, потом я стартовал систему и мы игрались несколько минут сортируя список с числами на всякие лады, просто изменяя приоритеты правил(естественно правила менялись на лету, без остановки системы). Было весело.
А теперь, по традиции, я озвучу вам истинную цель этой статьи. После этой статьи было небольшое движение, результаты которого я вам преподнесу в виде отдельной статьи, если эта вам понравится.