Тема номера: Oracle BAM и Oracle Rules – новые технологии Oracle

Построение гибких процессов масштаба предприятия
с использованием продуктов
ORACLE BUSINESS RULES и Oracle BPEL PROCESS MANAGER
(BUILDING FLEXIBLE ENTERPRISE PROCESSES
USING ORACLE BUSINESS RULES AND BPEL PROCESS MANAGER)

Источник: Oracle White Paper (Официальный документ Oracle), январь 2005,
http://www.oracle.com/technology/products/ias/business_rules/pdf/bpelAndRules.pdf

I. Введение

Эффективные бизнес-процессы – это одно из основных конкурентных отличий для каждой успешной компании. Эти процессы “оркестрируют” взаимодействия между системами, сервисами, людьми и партнерами для достижения стратегических и операционных целей. Определение и безошибочное исполнение бизнес-процессов позволяют организации обеспечивать качество продуктов и услуг, сокращать расходы, улучшать обслуживание клиентов и быстро реагировать на изменяющиеся рыночные условия. Типичный бизнес-процесс часто включает ряд точек принятия решений (decision points). Эти точки, как правило, влияют на течение процесса или на используемые ресурсы и в некоторых случаях в них происходит проверка входящих данных. Реализация этих точек основана на некоторых условиях и фактах, внутренних или внешних для данного процесса и на предварительно определенных политиках или правилах компании. Во многих организациях бизнес-аналитики или центральный комитет по политикам определяют эти правила, а оценка на соответствие этим правилам “врезается” в логику самого процесса. Как правило, это (“врезание”) приводит к несогласованному применению этих правил в процессах и делает затруднительным донесение изменений ко всем процессам, когда политики компании пересматриваются.

Желание обладать адаптивными бизнес-процессами, которые можно быстро “подгонять” под изменяющиеся условия бизнеса, нормативные требования правительства (government regulations) и давление конкуренции, привело к осознанию необходимости применения Business Rules Engine, “движка” бизнес-правил, как ключевого компонента системы управления бизнес-процессами (Business Process Management, BPM). Прежде чем углубиться в детали бизнес-правил, давайте определим, что такое бизнес-правила и как они должны рассматриваться.

Согласно организации Business rules group1 (www.businessrulesgroup.org) бизнес-правила можно определять одним из двух способов:

1. с точки зрения бизнес-аналитика, бизнес-правило – это “Руководство (guidance), которое определяет обязательства, связанные с поведением, действиями, практиками или процедурами в рамках той или иной области деятельности или сферы”;
2. с точки зрения информационной системы бизнес-правило – это “предложение (statement), которое определяет или налагает ограничения на некоторый аспект деятельности (бизнеса). Оно предназначено для задания структуры деятельности или для контроля/влияния “поведения” этой деятельности”.

Программный продукт класса business rules включает декларативный язык правил (declarative rule language), эффективный “движок” выводов (inference engine) и инструменты для поддержки определения и управления правилами. Бизнес-правила должны быть способны “перекинуть мост” между представлениями бизнес-аналитиков и специалистов информационных систем о правилах.

Следует рассмотреть возможность применения бизнес-правил, если ваша организация столкнулась с одной из следующих проблем:

1. Компании нужна бОльшая гибкость в своих бизнес-процессах. В идеале, вам хочется быстро отвечать на конкуренцию и изменяющиеся требования регуляторов, корректировать поведение процессов без модификации или переустановки бизнес-процесса.
2. Бизнес-процессы должны изменяться динамически или оптимизироваться на основе выводов от средств мониторинга активности деловых процессов (BAM - business activity monitoring). Однако, бизнес-процессы не имеют соответствующих интерфейсов для реализации выводов.
3. Бизнес-правила и точки принятия решений “врезаны” во множество процессов данной организации. Следовательно, неясно, какие процессы зависят от данной организационной политики или руководства.
4. Центральная группа или комитет создает политики и руководства – однако, во время внедрения эти политики часто интерпретируются по-разному владельцем каждого процесса и часто применяются несогласованно.
5. Бизнес-аналитики обладают ограниченным кругозором и неспособны модифицировать правила после того, как они включены в бизнес-процессы. IT-специалисты, как правило, внедряют правила отличные от тех, которые выражены бизнес-пользователями.
6. У компании нет центрального репозитория политик. Следовательно, нет легкого способа изменить политику и немедленно применить ее по всей организации, во всех ее департаментах.

Возрастающее количество компаний присматриваются к web-сервисам и сервис-ориентированной архитектуре (Service-Oriented Architecture - SOA) как к основе для решения интеграционных проблем, возникающих при построении соединенных приложений. BPEL и другие стандарты web-сервисов предназначены для решения типичных ситуаций этих приложений в открытом, переносимом и стандартном стиле. Если перед вашей организацией стоит одна из перечисленных выше проблем, вы должны также рассмотреть использование бизнес-правил как части вашей процессной архитектуры. Продукты Oracle BPEL Process Manager и Oracle Business Rules позволяют организациям строить гибкие SOA-решения благодаря максимальному использованию существующих ресурсов при минимизации стоимости развертывания новых приложений.

Далее в этой статье обсуждается, как движки правил (rule engines) могут быть эффективно использованы в качестве Decision Service, сервиса принятия решений, в рамках SOA. В секциях II и III дан обзор продуктов Oracle Business Rules и Oracle BPEL Process Manager. В секции IV описывается сервис принятия решений и способы его использования с бизнес-процессами. В секции V мы рассмотрим типичный случай применения бизнес-правил в контексте BPEL-процесса LoanFlow.

II. Продукт ORACLE BUSINESS RULES

Продукт Oracle Business Rules – это новый компонент Oracle Application Server 10g. Он позволяет специфицировать бизнес-правила отдельно от кода приложений. Отделение бизнес-правил от кода дает возможность бизнес-аналитикам быстро изменять бизнес-политики, используя графические инструменты.

Oracle Business Rules включает высокопроизводительный движок выводов, язык правил (rules language) и инструмент автора правил с графическим интерфейсом и SDK. На рис. 1 показана архитектура Oracle Business Rules.

Рис. 1: Архитектура Oracle Business Rules

• Компонент Rule Author позволяет бизнес-пользователям создавать и редактировать приложения правил (rules applications) с применением интуитивно понятного интерфейса на основе форм (intuitive form interface). В этом компоненте используется бизнес-диалект, а не язык разработчика-программиста. Компонент Rule Author – это приложение общего назначения, которое “опирается” на Rule SDK. Он поставляется и как приложение для тонкого клиента, и как JDeveloper plug-in.
• Язык (описания) правил Rules Language (RL) – это полнофункциональный язык программирования правил (rules programming language), спроектированный для интеграции с Java. Интерпретатор RL написан на Java и может быть встроен в Java-программы.
• На RL можно создавать, модифицировать и писать правила для Java-объектов и вызывать Java-методы. Подобно другим языкам правил RL в большей степени декларативный язык, нежели процедурный. Это позволяет намного легче разрабатывать некоторые типы приложений, а движку правил глобально оптимизировать оценку для нескольких правил (evaluation of multiple rules). RL-программы – это просто строки текста, которые могут быть сохранены где угодно.
• Продукт Rule Engine – это эффективная реализация стандартного в отрасли алгоритма Rete. Основная функциональность этого движка – это загрузка правил, загрузка/удаление (assert/retract) фактов в рабочую память, выполнение выводов и интерфейсов для показа статуса рабочей памяти. Этот движок может быть вызван как вызываемая java-библиотека (java callable library) или как отдельный сервис (standalone service) – в обоих случаях он потребляет ресурсы достаточно скромно (рабочая память занимает менее 2M байт) и использует репозиторий правил (rules repository) для хранения наборов правил и других метаданных. Этот репозиторий может быть базой данных или набором файлов.
• Продукт Rule SDK обеспечивает разработку Java-приложений с функцией редактирования, как правило, это приложения GUI (графический интерфейс пользователя) или web-браузера. Используя эти приложения, бизнес-пользователи могут редактировать и просматривать правила. SDK обеспечивает:

III. Продукт ORACLE BPEL PROCESS MANAGER

Наиболее критичным этапом жизненного цикла процесса является развертывание процесса на платформе, которая может оркестрировать течение, поток (flow) этого процесса и выполнять его разнообразные задачи. Оркестрирование набора сервисов в поток сквозного процесса (end-to-end process flow) требует выполнения множества технических требований, которые включают связывание с разнородными системами, шаблоны синхронного и асинхронного обмена сообщениями, манипулирование данными, координация течения процесса (flow coordination), поток заданий пользователей (user workflow), управление исключительными ситуациями (exception management), недетерминированные события (non-deterministic events), компенсирующие транзакции (compensating transactions), управление версиями и т.д. Назначение стандарта BPEL – обеспечение более богатого, но в то же время более простого уровня абстракции/стандарта для удовлетворения этих требований. BPEL быстро становится отраслевым стандартом defacto для оркестровки и выполнения процессов.

Продукт Oracle BPEL Process Manager предоставляет полную интеграционную платформу и является наиболее зрелой, масштабируемой и полной реализацией движка выполнения BPEL из доступных в настоящее время. Этот продукт использует Oracle OC4J как базовый J2EE-сервер. Некоторые из его ключевых функций:

• Поддержка стандартов — Этот движок реализует непосредственную поддержку стандартов BPEL и web-сервисов, таких как WSIF, XSLT и т.д. Он использует WSDL - как компонентную модель и XML - как модель данных;
• Производительность и масштабируемость – Этот высокопроизводительный BPEL-движок исполняет одновременно множество BPEL-процессов и обеспечивает возможность “отжимки” ("dehydration"), так что состояние долгоживущих процессов автоматически поддерживается в базе данных. Возможно применение кластеров для обеспечения масштабируемости и отказоустойчивости. Другие значительные функции – это параллельная (side-by-side) работа с версиями, секционирование процесса и продвинутое управление исключительными ситуациями;
• Сервисы соединений - Расширяемая схема соединения WSDL обеспечивает соединения по другим протоколам и форматам сообщений, нежели SOAP. Соединения доступны для JMS, электронной почты, JCA, HTTP и многих других протоколов для связи с сотнями внутренних систем. Доступны и адаптеры для соединения к различным тиражируемым приложениям (SAP, PeopleSoft и т.д.) и унаследованным системам.
• Сервисы управления данными – Они включают трансформации данных с применением XSLT/XQuery и трансляцию из не-XML форматов к XML форматам и наоборот.
• Сервисы пользовательских потоков заданий – Эти сервисы обеспечивают интеграцию людей и выполняемых ими “ручных” задач в потоки BPEL. Эти workflow- функции включают назначение задач и их маршрутизацию, множество workflow-шаблонов, сервисы идентичности, сервисы уведомления и полный список заданий.
• BPEL Console предоставляет web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживаются данные аудита и информация истории процесса и отчетов, и все это доступно через BPEL Console.
• Сенсорная структура на базе мониторинга деловой активности (BAM) – определенные пользователем сенсоры могут использоваться, чтобы отслеживать специфическую деятельность или переменные в процессе и предпринимать соответствующие действия.

На рис. 2 показана архитектура BPEL Process Manager и его различных компонентов.

Рис. 2: Архитектура BPEL Process Manager

IV. Бизнес-правила как сервис принятия решений

Как сказано ранее, концепция архитектуры SOA обеспечивает создание композитных (составных) приложений благодаря интеграции наборов синхронных и асинхронных сервисов и систем в поток процесса (process flow). Создание таких приложений – это двух шаговый процесс. Первый шаг – это публикация различных сервисов, которые будут использованы в приложениях, и второй шаг – это объединение или оркестровка их (сервисов) в бизнес- потоки (business flows) или потоки процессов. Публикация сервиса означает выделение некоторой функции в существующем приложении или системе и обеспечении ее доступности некоторым стандартным способом, а при оркестровке множество таких сервисов объединяется в сквозной (end-to-end) бизнес-процесс. Бизнес-правила легко “врезаются” в эту архитектуру как сервис принятия решений Decision Service.

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

1. web-сервиса, который “сворачивает” (wraps) сессию правила для базового движка правил. Этот сервис позволяет бизнес-процессам загружать и удалять факты как часть бизнес-процесса. В некоторых случаях все факты могут быть загружены в бизнес-процесс как один набор, в других же случаях бизнес-процесс может постепенно подзагружать факты и потом обращаться к движку правил для выводов. Следовательно, данный сервис должен поддерживать взаимодействия, как с состоянием, так и без него.
2. Правила, которые оцениваются сервисом принятия решения благодаря использованию движку правил. Они определяются с использованием Rule Author и загружаются в репозиторий правил.
3. Метаданные, описывающие факты, которые необходимы для оценки заданных правил. Каждое правило, представленное как сервис, будет использовать различные типы фактов. И эти факты должны быть представлены (exposed) через XSD-определения и соответствующие WSDL-операции. Например: набор правил CreditRating может ожидать SSN-идентификатор клиента, предыдущую историю его займов и т.д. - как факты, а правило PensionPayment может ожидать - как факты - срок службы работника, его зарплату, возраст и т.д.
4. Адаптеры, которые периодически загружают факты из внутренних систем, таких как базы данных или файлы. Факты могут передаваться прямо из бизнес-процессов или периодически загружаться из внутреннего репозитория, такого как база данных, файловая система или внешнее приложение. Сервисы адаптеров могут быть использованы внутренним образом как часть сервиса принятия решений для загрузки фактов. Пример: для сервиса принятия решений CreditRating такие факты, как SSN клиента или сумма займа, могут быть переданы из бизнес-процессов, но другие факты, такие как кредитная история клиента и непогашенные займы, могут быть получены с использованием адаптеров из внутреннего репозитория.

На рис. 3 сервис принятия решений показан как часть всей BPM-инфраструктуры.

Рис. 3: Сервис принятия решения (Decision Service) с BPEL Process Manager

Некоторые примеры использования сервисов принятия решений:

• Динамическая обработка (Dynamic processing) – правила могут использоваться для выполнения интеллектуальной маршрутизации (intelligent routing) в бизнес-процессе на основе соглашений об уровне обслуживания (service level agreements) или других руководств. Например: “Если клиент требует ответа в течение одного дня, пошлите прошение о займе только в агентство StarLoan. Если же клиент может ждать дольше, то перенаправьте его запрос к трем различным агентствам по предоставлению займов”;
• Вынесение “наружу”(Externalize) точек принятия решений в процессе – целый ряд условий может быть оценен как часть этого процесса. Однако, параметры этих точек могут изменяться независимо от процесса. Например: “давайте займы только тем клиентам, у которых кредитная оценка равна как минимум 650”. Это значение может изменяться динамически из-за требований новых руководств бизнес-аналитиками.
• Проверка данных и ограничений (Data validation and constraint checks) – правила могут использоваться для проверки входных документов или задействования дополнительных ограничений по запросам. Например: новый запрос клиента должен всегда сопровождаться подтверждающим письмом о занятости (employment verification letter) и деталями банковского счета.
• Пользовательский поток заданий (User workflow) – правила часто используются в контексте пользовательских задач в бизнес-процессе.
  • Назначение задач на основе политик (Policy based task assignment) используется для назначения задач заданным ролям или пользователям. Например: процесс, который используется для обработки приходящих на портал запросов, может маршрутизировать запросы на займы и страховые платежи (insurance quotes) на совсем разные наборы ролей.
  • Политики перенаправления и делегирования (Escalation and Delegation policies) – эти политики могут использоваться для направления запросов к нескольким пользователям для одобрения или передачи задач другим пользователям, если некоторый пользователь не укладывается в заданный промежуток времени. Например: если пользователь за два дня не выполнит задачу с высоким приоритетом, она может быть переназначена его (или ее) руководителю или альтернативному пользователю. Другой пример: политики страхования нового клиента всегда должны быть одобрены его агентом и контролером.
  • Балансирование загрузки задачами среди пользователей (Load balancing of tasks among users) – когда задача назначена ряду пользователей или роли, каждый пользователь в этой роли получает набор задач и работает с ними заданное время. Для новых входящих задач политики могут применяться для назначения приоритетов и размещения задач в очереди к определенных пользователям. Например: некоторому агенту по займам в любое время назначается не более 10 займов в предположении 80% использования ресурсов.
• Мониторинг деловой активности (BAM) – правила могут использоваться совместно со средствами BAM для генерации сигналов на основе некоторых политик. Выводы из измерений ключевых индикаторов эффективности (KPI) также могут использоваться, чтобы повлиять на поток бизнес-процесса. Например: если количество займов за этот месяц от клиентов с высокой степенью риска превысило 30, то послать сообщение о прекращении приема запросов от клиентов с кредитной оценкой меньше 700.

V. Сценарий процесса LOAN FLOW

Рассмотрим следующий пример процесса LoanFlow, развернутого у типичного брокера займов. Этот брокер принимает запрос от клиента, выполняет кредитную проверку с использованием внешнего сервиса и затем направляет прошение двум агентствам по предоставлению займов. После получения предложений от этих агентств выбирается лучшее из них и клиент уведомляется об этом. В этом сценарии участвуют - LoanBroker, сервисы CreditRating, StarLoanService, UnitedLoanService и клиент. Процесс LoanFlow (рис. 4) оркестрирует взаимодействия между этими сервисами. Давайте используем этот сценарий для иллюстрации использования сервиса принятия решений. Предположим, что движок правил используется в сервисах CreditRating и StarLoan.

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

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

В этом случае сервис принятия решений используется для оценки правил на основе как статических данных, таких как в прошении о займе, так и таких, как “непогашенные займы для клиентов с высоким уровнем риска” из системы мониторинга деловой активности. Аналогично, правила также используются для отправления прошений о займах на различные уровни в случае клиентов с высоким уровнем риска. Отметим, что эти условия должны быть формализованы как предложения “switch” (“переключатель”) в самом бизнес-процессе. Однако, использование бизнес-правил дает агентству по предоставлению займов гибкость при изменениях [бизнеса-процесса] в зависимости от рыночных условий без переустановки бизнес-процесса.

Рис. 4: Сервис принятия решений Decision Service как часть LoanFlow BPEL-процесса

VI. Партнеры

Корпорация Oracle установила партнерские отношения с рядом поставщиков для предоставления функциональности бизнес-правил совместно с продуктами Oracle BPEL Process Manager и Oracle Business Activity Monitoring. В число этих поставщиков входит компания ILOG, Inc. (http://www.ilog.com ) – ее продукт ILOG JRules может использоваться для создания web-сервиса, который можно применять для принятия решений в BPEL-процессах.

VII. Заключение

Движки бизнес-правил (Business Rules Engines) критичны для развертывания эффективных бизнес-процессов, которые могут быстро реагировать на изменяющиеся условия бизнеса. Продукты Oracle Business Rules и Oracle BPEL Process Manager составляют полную платформу для построения бизнес-процессов на базе бизнес-правил, что обеспечивает максимальную гибкость и прозрачность. За более подробной информацией по этим технологиям обращайтесь по адресам to http://www.oracle.com/technology/index.html

Jan 2005
Authors: Bhagat Nainani, Kathryn Gruenefeldt, Ralf Mueller
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright © 2001 Oracle Corporation
All rights reserved.