Что такое бизнес правила программирование

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

В первую очередь бизнес-правила реализуют следующие ограничения БД:

§ задание допустимого диапазона значений;

§ задание значения по умолчанию;

§ требование уникальности значения;

§ запрет пустого значения;

§ ограничения ссылочной целостности.

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

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

Главное правило программирования

Достоинство такого подхода заключается в лег­кости изменения бизнес-правил и определении правил «своего» приложения. Недостатком является снижение безопасности БД, связанное с тем, что каждое приложение может устанавливать свои правила управления БД. Ниже мы рассмотрим пример программирования бизнес-правил в приложении, связанный с каскадным удалением записей связанных таблиц.

При работе с удаленными БД в архитектуре «клиент-сервер» бизнес-правила можно реализовывать также на сервере.

Источник: studopedia.su

Бизнес-правила (службы Master Data Services)

В Master Data Services бизнес-правило — это правило, которое используется для обеспечения качества и точности основных данных. Бизнес-правило можно использовать для автоматического обновления данных, отправки электронной почты или запуска бизнес-процесса или рабочего процесса.

Создание и публикация бизнес-правил

Бизнес-правила — это операторы If/Then/Else , создаваемые в диспетчере основных данных. Если значение атрибута удовлетворяет указанному условию, выполняется определенное действие. В противном случае выполняется действие Else. Возможны такие действия, как задание значения по умолчанию или изменение значения. Эти действия могут сочетаться с отправкой уведомления по электронной почте.

Бизнес-правила могут основываться на определенных значениях атрибутов (например, предпринимать действие, если Цвет=Синий) или на изменении значения атрибута (например, предпринимать действие, если значение атрибута «Цвет» изменяется). Дополнительные сведения об отслеживании неспецифического изменения см. в разделе Отслеживание изменений (Master Data Services)).

От планов к делу. Как создать-IT продукт, который полетит? / Оскар Хартманн

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

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

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

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

Применение бизнес-правил

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

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

Другие важные замечания о применении правил.

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

Системные настройки

В диспетчер конфигурации Master Data Services есть два параметра, которые влияют на бизнес-правила. Эти параметры можно настроить в диспетчер конфигурации Master Data Services или непосредственно в таблице Параметры системы. Дополнительные сведения см. в разделе Параметры системы (Master Data Services).

Связанные задачи

Описание задачи Раздел

Создание и публикация бизнес-правила.	Создание и публикация бизнес-правила (службы Master Data Services)
Добавление нескольких условий к бизнес-правилу.	Добавление нескольких условий к бизнес-правилу (службы Master Data Services)
Создание бизнес-правила, которое требует заполнения атрибутов.	Запрос значений атрибута (службы Master Data Services)
Создание бизнес-правила, которое запускает действие при изменении значений атрибутов.	Инициирование действия на основе значения атрибута (службы Master Data Services)
Создание бизнес-правила для использования пользовательского сценария как условия	Расширение бизнес-правил (Master Data Services)
Создание бизнес-правила для использования пользовательского сценария как действия	Расширение бизнес-правил (Master Data Services)
Изменение имени существующего бизнес-правила.	Изменение имени бизнес-правила (службы Master Data Services)
Настройте диспетчер основных данных для отправки уведомлений при применении бизнес-правил.	Настройка в бизнес-правилах отправки уведомлений (службы Master Data Services)
Применение бизнес-правил к определенным элементам.	Подтверждение конкретных членов, обнаруженных при проверке на соответствие бизнес-правилам (службы Master Data Services)
Исключите бизнес-правило, чтобы оно не использовалось.	Исключение бизнес-правила (службы Master Data Services)
Удаление существующего бизнес-правила.	Удаление бизнес-правила (службы Master Data Services)

См. также

• Общие сведения о службах Master Data Services (MDS)
• Версии (Master Data Services)
• Проверка (службы Master Data Services)
• Отслеживание изменений (службы Master Data Services)

Источник: learn.microsoft.com

Внешняя логика приложения: подход бизнес-правил с Drools

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

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

Поскольку требования продолжают изменяться, для кода на этом уровне очень легко запутаться в ситуации, известной как «код спагетти», множество вложенных условий if-else и по мере добавления новых условий ухудшается читаемость. Кроме того, чтобы изменить поведение системы, необходимо выполнить перекомпиляцию и перестройку.

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

Что такое бизнес-правила?

Бизнес-правило — это просто утверждение, которое определяет или ограничивает некоторые аспекты бизнеса. Бизнес-правила всегда разрешаются в true или false. Бизнес-правило также может быть определено как абстракция политики и практики бизнес-организации.

• У клиента может быть несколько бронирований, но одновременно можно арендовать только один автомобиль. (Прокат автомобилей)
• Когда регистрация идет из страны, указанной в списке запрещенных стран, отклоните регистрацию. (Регистрация сайта PTC)

Что такое механизм правил?

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

Зачем использовать механизм правил?

• Логика и разделение данных — ваши данные находятся в объектах вашего домена, логика в правилах.
• Скорость и масштабируемость — механизм бизнес-правил использует дизайн алгоритмов для эффективного сопоставления шаблонов правил с объектами вашего домена, например, с алгоритмом повторного использования, который используется в Drools Expert. Также с точки зрения масштабируемости правила могут совместно использоваться в различных системах, что позволяет нам создавать или интегрировать подсистемы, которые используют некоторые правила, используемые другими подсистемами.
• Централизация знаний — поскольку логика выводится в виде правил, существует только один источник истины, а это ваше хранилище правил / знаний (база знаний).
• Средство объяснения — системы правил эффективно предоставляют «средство объяснения», позволяя регистрировать решения, принятые механизмом правил, а также причины их принятия.
• Понятные правила — в Drools Expert правила могут быть написаны с использованием DSL (домен-специфических языков), позволяющих нетехническим экспертам в области писать правила, близкие к естественному языку.

Типовые правила

Рисунок 1: Пример файла правил Drools

Правило сообщения Hello и правила сообщения Goodbye. Мы можем прочитать эти правила следующим образом:

• Hello Message Rule — «Когда статус объекта Message — HELLO, отобразите атрибут сообщения объекта Message и измените его сообщение и статус на« Goodbye Cruel World »и GOODBYE соответственно».
• Правило Goodbye Message — «Когда статус объекта Message -« GOODBYE », отобразите атрибут сообщения объекта Message».

Сделайте свои приложения управляемыми правилами

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

1. Факты — факты — это просто ваши доменные объекты / модели. Правила запускаются против этих фактов, чтобы сопоставить условия, объявленные в правилах, с состоянием факта, который используется в настоящее время, и это определяет правило / правила для выполнения.
2. Правило — правило — это утверждение, которое проверяет условие на факт и состоит из 3 важных разделов:

1. Имя — название правила
2. LHS (Условие) — это раздел «когда» (см. Выше). В этом разделе объявляется условие, которое будет проверять правило.
3. RHS (Последствие / Действие — это раздел «тогда» (см. Выше). В этом разделе объявляются последствия или действие, которое должно выполняться при выполнении условия, объявленного в разделе «когда».

Пример кода:

package com.ideyatech.drools; import org.drools.KnowledgeBase; import org.drools.KnowledgeBaseFactory; import org.drools.builder.KnowledgeBuilder; import org.drools.builder.KnowledgeBuilderFactory; import org.drools.builder.ResourceType; import org.drools.io.ResourceFactory; import org.drools.runtime.StatelessKnowledgeSession; import com.ideyatech.drools.bean.Message; public class Main < public static void main(String[] args) < final KnowledgeBase knowledgeBase = createKnowledgeBase(); final StatelessKnowledgeSession session = knowledgeBase.newStatelessKnowledgeSession(); try < final Message message = new Message(); message.setStatus(Message.HELLO); session.execute(message); >catch (Throwable e) < e.printStackTrace(); >> private static KnowledgeBase createKnowledgeBase() < final KnowledgeBuilder builder = createKnowledgeBuilder(); final KnowledgeBase knowledgeBase = KnowledgeBaseFactory .newKnowledgeBase(); knowledgeBase.addKnowledgePackages( builder.getKnowledgePackages()); return knowledgeBase; >private static KnowledgeBuilder createKnowledgeBuilder() < final KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder(); final String rulePath = «com/ideyatech/drools/rule/hello-world-rule.drl»; builder.add(ResourceFactory.newClassPathResource( rulePath), ResourceType.DRL); if (builder.hasErrors()) < throw new RuntimeException(builder.getErrors().toString()); >return builder; > >

• Приведенный выше код содержит два вспомогательных метода: createKnowledgeBuilder () и createKnowledgeBase ().
• Метод createKnowledgeBuilder () создает экземпляр KnowledgeBuilder, который отвечает за получение исходных файлов, таких как файлы .drl (Drools Rule), и превращение их в KnowledgePackage определений правил и процессов, которые может использовать база знаний.

• В этом методе мы добавили в KnowledgeBuilder файл правил «hello-world-rule.drl», который является ресурсом ClassPath. Обратите внимание, что правила также могут быть получены как ресурс File или URL-ресурс.

Когда мы запускаем этот код, это дает следующий результат:

Человекочитаемые правила с использованием DSL

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

Рисунок 2: Файл DSL

Рисунок 3: Файл DSLR

На рисунках выше у нас есть 2 файла; DSL и файл DSLR. Файл DSL содержит сопоставление условий и последствий, используемых в файле DSLR. Например, условие DSL «Есть клиент с firstName » сопоставляется с «$ customer: Customer (firstName == )». Это отображение / перевод просто говорит движку, как интерпретировать правило, записанное в файле DSLR.

Вывод

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

Источник: coderlessons.com