Жизненный цикл бизнес-процессов по требованию, Часть 1: Создание основы для вашего бизнес-процесса по требованию

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

Доктор Джерман Голдсзмидт, старший технический сотрудник, IBM 

Доктор Джерман Голдсзмидт (Dr. German Goldszmidt) - старший технический сотрудник, работает в Программной Группе IBM, занимается архитектурой интегрированной платформы для поставки, настройки и развертывания решений по требованию. До этого был исследователем в Исследовательском центре IBM Уотсона и руководил проектированием и реализацией нескольких технологий, включая Oceano, первого прототипа автономных вычислений eUtility и Сетевого Диспетчера, компонента стабилизатора загрузки WebSphere.



Джоши Джозеф, инженер-программист, IBM 

Джоши Джозеф (Joshy Joseph) – инженер-программист, разрабатывающий организацию развития решений по требованию в IBM. Он - архитектор и программист с отличными навыками и квалификацией в областях распределенного вычисления, Grid computing, Web-сервисов, бизнес-процессов и развития технологического процесса. Он - автор книги 'Grid computing', изданной Прентис Хол, 2003. Кроме того, он написал многочисленные технические статьи о Grid computing, разработке бизнес-процессов и Web-сервисах.



Навьен Сачдева, инженер-программист консультант, IBM 

Навьен Сачдева (Naveen Sachdeva) - инженер-програмист, консультант группы Application Integration Middleware IBM. Он имеет более чем 10 лет опыта работы в крупномасштабной системной интеграции, дизайне и развитии распределенных вычислительных систем. В настоящее время, он помогает деловым партнерам IBM в разработке технических средств и создании концепций, при помощи продуктов WebSphere.



Вей Лиу, инженер-программист, IBM 

Вей Лиу (Wei Liu) – инженер-программист Программной Группы IBM. Она в настоящее время работает с IBM группой развития процессов по требованию. Ее область знаний включает сервер приложений, Web-сервисы и развитие технологических процессов.



22.10.2004

Введение

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

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

Рисунок 1. Выполнение заказа в цепочке поставки.
Рисунок 1. Выполнение заказа в цепочке поставки.

Проект Oneida-2

Мы реализовали прототип сервис-ориентированной архитектуры (SOA), чтобы продемонстрировать преобразование по требованию реалистичного подмножества Систем для отслеживания и анализа команд заказчика (COATS), основной бизнес-процесс Integrated Supply Chain ® IBM. COATS реализуют главные бизнес-процессы, используемые IBM во всем мире для исполнения команд сложных аппаратных систем.

В проекте Oneida-2, было реализовано преобразование по требованию для существующей OTMPS. Нашей целью являлось создание прототипа, который удовлетворял бы следующим требованиям:

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

Данная серия статей также описывает применение методов, средств, моделей и концепции SOA для выполнения вышеприведенных требований. Мы применяем итерационных и восходящий методы разработки, используя шаблоны моделирования, разработки и развертывания продукта. Эти методы направлены на многократное использование бизнес-процессов, IT-продуктов и предоставление доступа к важным функциям в виде Web-сервисов. Главные пункты нашей итерационной разработки:

  1. Моделируем деловой процесс, используя IBM WebSphere ® Business Integration Modeler (WBI Modeler)
  2. Определяем модель объекта данных, используя IBM Rational ® XDE ™
  3. Разрабатываем реализацию, используя WebSphere Studio Application Developer Integration Edition (далее Application Developer)
  4. Разворачиваем получившиеся приложения на WBI Server Foundation
  5. Отображаем бизнес-метрику во время выполнения, используя WebSphere Portal

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


Сценарий

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

Заинтересованные стороны

Существует семь типов заинтересованных сторон OTMPS:

  • Потребители
  • Владельцы
  • Аналитики
  • Создатели
  • Разработчики
  • Администраторы
  • Операторы

Потребители - конечные пользователи (например, коммерческий штат, который вводит новые заказы, и производящий штат, который получает итоговый Список Материалов). Владельцы несут финансовую ответственность и определяют бизнес-требования, которые чаще всего выражены обычным языком. Аналитики ответственны за дизайн решения на бизнес-уровне. Они взаимодействуют с владельцами, определяя требования процесса, затем вводят соответствующую логику и потоки процесса в WBI Modeler. Архитекторы ответственны за перевод проекта с бизнес-уровня на техническую архитектуру. Они также ответственны за то, чтобы определять технические компоненты и интерфейсы выполнения. Разработчики реализуют архитектуру с помощью инструментальных средств, типа WebSphere Studio. Администраторы ответственны за управление системой во время ее работы. Операторы ответственны за то, чтобы поддерживать приложение OTMPS и управлять состояниями, которые требуют человеческого вмешательства (например, недопустимый заказ).

Функции

Следующие функциональные компоненты являются подмножеством OTMPS, над которым мы работали:

  1. Планировщик – Составляет расписание заказов и начинает их обработку
  2. Контроллер – Регулирует очередность и исполнение процесса
  3. Группировщик – Находит отношения между заказами и группирует их
  4. Подтверждение правильности – Проверяет соответствие заказа предопределенным правилам
  5. Транслятор – Создает итоговый Список Материалов в производственной номенклатуре
  6. Производство – Составляет итоговый Список Материалов для каждого завода - изготовителя

Вы можете немного изменять эти функциональные компоненты при проектировании и выполнении OTMPS.

Требования

На основе бесед с владельцами, аналитики определили следующие типовые требования для работы OTMPS:

  1. обработка сохраненных заказов в пакетном режиме;
  2. обрабатка заказов в режиме реального времени;
  3. адаптация к изменениям в бизнесе и политике информационных технологий;
  4. уведомление администратора о системных ошибках;
  5. обеспечение возможностей администратора по проверке и изменению статуса системы в режиме реального времени;
  6. уведомление операторов о недопустимых заказах и возможность исправлять ошибки;
  7. генерация и отображение ключевой бизнес-метрики в режиме реального времени;
  8. уведомление владельцев, о выходе ключевой бизнес-метрики из установленного диапазона;
  9. интеграция с унаследованными приложениями (например, аппаратная конфигурация);
  10. интеграция с внешними партнерами (например, поставщиками деталей);
  11. поддержка различных протоколов и форматов данных (например, Simple Object Access Protocol (SOAP)/HTTP или EDI);
  12. обеспечение динамической замены совместимых участников;
  13. отслеживание действий работников, администраторов и владельцев;
  14. обеспечение взаимодействия работников, администраторов и владельцев;
  15. реализация в соответствии с требованиями SOA.

Прецеденты

Основываясь на требованиях и вышеприведенном сценарии, OTMPS должна осуществить следующие сценарии поведения (неполный список):

  • Прецедент 0: Создать заказ
  • Прецедент 1: Составить расписание для набора заказов в режиме реального времени
  • Прецедент 2: Запустить/остановить процесс планирования
  • Прецедент 3: Обработать заказы:
    • Группы заказов
    • Подтвердить правильность заказов
    • Создать Список Материалов
    • Послать данные заводам - изготовителям
    • Запросить компоненты от поставщиков
    • Создать бизнес-метрику
  • Прецедент 4: Уведомить оператора об ошибках
  • Прецедент 5: Уведомить администратора о системной ошибке
  • Прецедент 6: Уведомить владельца о сервисном нарушении уровня
  • Прецедент 7: Контролировать панель бизнес-метрики
  • Прецедент 8: Изменить правила бизнеса
  • Прецедент 9: Обновить заказ
  • Прецедент 10: Отменить заказ
  • Прецедент 11: Проверить статус заказа

Для иллюстрации мы детально рассмотрим три прецедента (№1, №4 и №7):

  • Прецедент 1: Составить расписание для набора заказов в режиме реального времени

Действующее лицо: оператор

Предварительное условие: Портальные и Бизнес-Интеграционные сервера запущены и работают

Основной сценарий успеха:

  1. Операторы подключаются к портальному серверу.
  2. Система представляет страничку "Процесс".
  3. Операторы вводят список заказов и нажимают кнопку Execute (Исполнить).
  4. Система представляет текущий протокол своих действий.
  5. Система исполняет прецедент 3.
  6. Система передает сообщение "Исполнение успешно завершено".

Исключительные ситуации: 5a. Система передает сообщение "Ошибка"

Прецедент 4: Уведомить оператора об ошибках

Действующее лицо: оператор

Условие выполнения: неверный заказ, полученный во время исполнения прецедента 3

Основной сценарий успеха:

  1. Система определяет действия для операторов
  2. Оператор входит в систему портального сервера (если еще не вошел).
  3. Система отображает действия, которые должен выполнить оператор.
  4. Система находится в состоянии ожидания, пока оператор не потребует действие.
  5. Система отображает неверный заказ оператору.
  6. Оператор обновляет заказ и нажимает кнопку Update (Обновление).
  7. Система обновляет заказ во внутренней базе данных.

Исключительные случаи: 6a. Оператор взаимодействует с пользователем и обновляет или отменяет заказ.

Прецедент 7: Отображает метрику бизнес-процессса

Условие выполнения: Прецедент 1 был выполнен успешно по крайней мере один раз

Основной сценарий успеха:

  1. Владелец входит в систему портального сервера.
  2. Владелец открывает страничку "Диспетчер".
  3. Система отображает определенные бизнес-метрики (см. Отображение бизнес процесса).

Рисунок 2 иллюстрирует все сценарии поведения, представленные выше. Например, в прецеденте 7, владелец бизнеса взаимодействует с Диспетчерской системой, чтобы посмотреть информацию о реализации бизнеса. В другом примере оператор подключается к Управляющему приложению для выполнения прецедента 1, который в свою очередь отрабатывает прецедент 3 на системе Выполнение заказов. Поставщики представляют собой внешнюю систему, которая обеспечивает интерфейс для заинтересованных сторон. Действующая система и Система подтверждения правильности - существующие приложения, в которых используется прецедент 3.

Рисунок 2. Сценарии поведения для OTMPS
Рисунок 2. Сценарии поведения для OTMPS

Обзор процесса развертывания

На рисунке 3 показан процесс разработки, а также инструментальные средства и методы, используемые на каждой стадии разработки. Процесс разработки начинается с моделирования бизнес-процессов при помощи WBI Modeler. Первый шаг - аналитик привлекает экспертов по предметной области и четко формулирует бизнес-требования процесса. Используя эти входные данные, аналитик моделирует существующие "как есть" ("as is") деловые процессы, используя WBI Modeler. За счет совместной работы бизнес-процессы "как есть" преобразуются в более работоспособные бизнес-процессы "как должно быть" ("to be"). Созданные ранее методы моделирования, называемые элементами Процесса (см. Сервис и элементы процесса), хранящиеся в централизованном архиве, используются, если соответствуют требованиям. Также создаются и новые методы моделирования для будущего применения. Аналитик также идентифицирует бизнес-метрику, которая должна быть определена в течение выполнения процесса. Если он удовлетворен моделью, аналитик передает модель процесса группе разработчиков для реализации. Практически, IT-архитекторы должны быть вовлечены в процесс моделирования, чтобы гарантировать гладкий переход, как описано ниже.

WBI Modeler экспортирует модель процесса и связанные с ней определения объектов бизнес-уровня в соединении с объектами Делового Языка Выполнения Процесса (BPEL), XSD, и WSDL. Выполнение модели процесса требует интеграции с дополнительными объектами типа адаптеров для того, чтобы обращаться к унаследованным функциям, компонентам для бизнес-логики, привязкам Web-сервисов и т. д. Множество важных шаблонов можно применять для анализа модели, ее проектирования и реализации (см. Решение модели).


Жизненный цикл Oneida

Рисунок 3. Жизненный цикл процесса по требованию Oneida
Рисунок 3. Жизненный цикл процесса по требованию Oneida

Используя IBM Rational XDE, архитектор определяет объектную модель для дополнительных IT-объектов и генерирует соответствующий код Java. Затем разработчик использует Application Developer для интегрирации выходных данных WBI Modeler и Rational XDE с сервисами бизнес-партнерв, унаследованными системами и структурой правил. Используя Application Developer, разработчик связывает дополнительные объекты (XML схемы, Java-код, услуги и правила) с BPEL технологическим процессом. Вы можете использовать Common Event Infrastructure (CEI) API, чтобы видеть информацию о реализации. Окончательная реализация приложения развертывается в рабочей среде WBI Server Foundation.

Во время реализации инфраструктура CEI допускает контроль выполнения процесса. По возможности вы должны использовать WBI Monitor V5.1, который поддерживает CEI и обеспечивает соответствующие инструментальные средства контроля. Также можно использовать WebSphere Portal Server, чтобы отображать информацию о выполнении. Позднее аналитики используют эту информацию для улучшения бизнес-процесса.

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


Моделирование бизнес процессов

Моделирование включает разбиение бизнес-процесса на подпроцессы для того, чтобы идентифицировать функции, компоненты, сервисы вместе с входными и результирующими данными, политиками и метриками. Исходные модели могут быть использованы для имитации и определения текущих критических параметров. Исходные бизнес-процессы преобразуются в текущие бизнес-процессы, реализующие желаемые изменения. Текущие модели могут затем имитироваться для определения возможных улучшений процесса. Аналитик также определяет бизнес-метрики, которые нужно измерить во время выполнения процесса. Рисунок 4 иллюстрирует общий сегмент процесса в WBI Modeler V5.1. Эта простая OTMPS модель иллюстрирует течение заказов через процессы подтверждения и производства. Модель интегрирует подтверждающий сервис партнера, функцию подключения сервиса validate and generate topology. Рисунок также показывает точку решения успешности подтверждения (validation successful), два задания преобразования формата данных, локальные архивы данных для хранения заказов клиентов для дальнейшего использования в процессе и цикл процесса для выбора и направления заказов на соответствующее производственное предприятие.

Рисунок 4. Сегмент модели процесса in WBI Modeler V5.1
Рисунок 4. Сегмент модели процесса in WBI Modeler V5.1

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

Сервисы и элементы процесса

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

Элементом процесса является актив объекта, определяющий долю процесса, который разработан и управляется с целью многократного использования в рамках моделей бизнес-процесса. В него входят:

  • Установленный ряд задач и решений
  • Ссылки на объекты данных
  • Правила
  • Роли
  • Метрики

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

Третья статья цикла знакомит с методами и руководствами для управления пошаговым процессом моделирования с использованием WBI Modeler V5. Эта статья описывает как определить основные элементы процесса:

  • Контроль потоков
  • Подпроцессы
  • Правила
  • Роли
  • Измерения для сценария OTMPS

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

  • Идентификация и перечисление заданий
  • Определение последовательности заданий
  • Создание контрольных потоков между заданиями
  • Введение данных в процессы
  • Объединение сервисов с моделью процесса

Мы кратко описали использование WBI Modeler для выполнения подтверждения правильности модели и анализа через статические и динамические модели. Закончим мы описанием различных экспортных средств, доступных в WBI-Modeler и описыванием полученных методов.


Реализация

WBI modeler создает BPEL, XSD, и WSDL методы, с которых начинается реализация. Используя Rational XDE, разработчик определяет объектную модель для дополнительных IT-методов и генерирует для них соответствующий Java-код. Мы использовали Application Developer 5.1 "Business Integration" perspective для того, чтобы создать сервисный проект, с такими методами, как схемы XML, Web-сервисы, объекты и процессы. Методы Java-классов и XML-схем сгенерированы при помощи XDE и Application Developer и, соответственно, используются для получения доступа к внешним серверам. Технологический процесс BPEL расширяется (через Java-код) для интеграции правил, поддержки существующих бизнес-взаимодействий и для генерации бизнес-событий. Рисунок 5 показывает вид редактора Application Developer BPEL.

Процесс соединяет партнеров, использующих статический механизм связывания, который сгенерирован во время развертывания процесса. Необходимое связывание, код развертывания и составляющие пакеты интегрированы. Они включают код, сгенерированный для унаследованных компонентов фасадных методов, создавая WSDL/XSD и методы развертывания (Enterprise JavaBeans (EJB) и привязок SOAP). Исключения обрабатываются внешним макропотоком, который является долго выполняемым процессом и предоставляет сотрудникам возможность оценки условий ошибок и принятия решения по их обработке.

Рисунок 5. Редактор Application Developer BPEL
Рисунок 5. Редактор Application Developer BPEL

В четвертой статье данной серии мы рассказываем о том, как перенести результирующие данные из WBI Modeler и Rational XDE в Application Developer, а так же способы интеграции этих данных. Статья также описывает реализацию процесса, сервисных компонентов и то, как классы Java и методы XML-схем добавляются к ним в виде сообщений ввода-вывода и статических объектов. В завершении реализации создается упаковщик, и происходит соединение с сервисами и правилами внешних партнеров. Мы описываем несколько лучших механизмов для повышения быстродействия выполнения технологических процессов; объясняем различия между микропотоком и макропотоками в бизнес-поведении, распараллеливании и работе; предлагаем типы действий соответствующие различным ситуациям и наилучшие способы их комбинирования; приводим различные методы отображения данных, стили обращения, привязки, топологию развертывании, и производимый ими эффект на производительность системы.


Изготовление изделий: Стратегии и правила

Со временем владельцы OTMPS вводят новые требования к её реализации (например, изменение стратегий для решения вопроса, как формировать заказы). Цель состоит в том, чтобы приспособить OTMPS к таким быстро меняющимся требованиям.

Стратегия, правила и пункты принуждения

Стратегия обычно декларативна (например, "только клиенты из США могут управлять машиной X"). Каждая стратегия может требовать один или более пунктов принуждения. Точка принуждения может быть реализована как явный шаг в процессе или как особое место в коде. Она также может возникнуть при обработке событий. Правила - это удобный способ обработки точек принуждения стратегии. Правила обязательны и являются логически исполнимой программой. Пример простого правила:

"If !(location(customer) == "USA") then reject(order);"

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

Аналитики могли бы определить намеченные стратегии. Но стратегии должны быть прописаны явными, исполнимыми правилами. Смотрите раздел о стратегиях, правилах и точках принуждения для их определения.

В традиционных приложениях правила встроены в код. Таким образом, при изменении стратегии код приложения должен быть исправлен и повторно откомпилирован. Расширение правил позволяет бизнес-аналитикам и другим пользователям модифицировать стратегии, которые были определены, не меняя логики процесса и без повторного компилирования приложения.

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

Как часть пробной программы OTMPS, мы реализовали простую структуру обслуживания правил, которая состоит из механизмов Rules Service Facade и Rule Engine Selection (более подробно смотрите в пятой статье). В нашей реализации используется структура Business Rule Beans (BRBeans) (см. Рисунок 6).

BRBeans - структура в WBI-FS для создания, изменения и вызова правил. Данная структура реализована при помощи EJB типа Rule, RuleFolder, и RuleHelper. В BRBeans-структуре каждое правило представлено компонентом управления данными, который постоянно хранит информацию, связанную с соответствующим правилом. Каждому правилу соответствует название и определенные свойства (например, дата начала, дата окончания, наличие и javaRuleImplementorName), а это правило сохранаяется в соответствующей папке. Выполнение правила - алгоритм, написанный на Java и связанный с правилом через свойство 'javaRuleImplementorName'.

Риснок 6. BRBeans архитектура
Риснок 6. BRBeans архитектура

Вместо того, чтобы непосредственно активизировать BRBeans API из техпроцесса, мы предлагаем сервисный вызов, который в свою очередь использует структуру правил для запуска BRBeans API, как показано на Рисунке 7. Все правила, относящиеся к приложению, представлены в виде сервиса, где каждое правило открывается в виде метода. Все правила, общие для приложений (например, безопасность, бизнес выполнения и т. д.), могут быть определены в общих сервисах. Структура правил позволяет делать выбор различных инструментов правил. Особые правила кодируются аналитиком с помощью специальной административной системы инструментов правил (с использованием административного GUI) и разворачивается по соответствующим инструментам правил.

Рисунок 7. Сервисы правил
Рисунок 7. Сервисы правил

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


Контроль бизнес процесса

Возможности контроля бизнес процесса позволяют владельцам и администраторам отслеживать критические показатели работы (KPIs – см. Key Performance Indicator) в режиме реального времени. Они также позволяют аналитику определить проблему/узкое место в существующих процессах, как показано на Рисунке 3. Основываясь на этой обратной связи, аналитик может принять решение о настройке и изменении бизнес-процессов и повторить цикл разработки. Например, в пробном проекте владелец OTMPS определял следующие ключевые измерения выполнения:

  • Средняя производительность заказов
  • Коэффициент успеха для заказов
  • Число неверных заказов
  • Среднее время разрешения проблемы

Key Performance Indicator

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

Инфраструктура CEI позволяет вам создавать и распределять события в единой форме. Вы можете также создавать приложения/средства, которые используют эти события для вывода и отображения полезной информации. Обычно события используются для публикации информации, касающейся бизнес-процесса, которая в дальнейшем используется для подсчета метрик выполнения. События генерируются в формате Common Base Events (CBE) с помощью CEI API включая WBI-SF V5.1.1. Мы использовали WebSphere Portal Server Express для визуализации и агрегации информации в комбинированные страницы для представления информации пользователям в компактной форме. Мы переделали Web page portlet, развернутый на WebSphere Portal Server Express, для изображения бизнес событий и информации о выполнении.

В последующих статьях этой серии мы покажем, как осуществлять мониторинг бизнес-процесса с помощью CEI. Мы обсудим, как определить KPIs в WBI Modeler V5.1, как создать соответствующие события с помощью редактора BPEL и CEI API в Application Developer V5.1.1 и как запрашивать эти события с помощью CEI API. Мы кратко опишем структуру CBE, покажем, как запросить их с помощью языка запроса XPath и как создать группы событий с помощью WBI-SF V5.1.1 и использовать их для запроса событий с помощью CEI API.


Пример решения

Есть много важных шаблонов (см. Шаблоны), которые могут быть использованы для анализа, тестирования, развертывания OTMPS. Не всегда ясно, как эти шаблоны соединяются вместе, и как применять их в данном контексте для создания гибкого решения. Во второй статье мы описываем рецепт создания шаблона решения для OTMPS, используя шаблоны для электронного бизнеса. См. обзорную статью по электронному бизнесу: Jonathan Adams, Srinivas Koushik, Guru Vasudeva, George Galambos, Patterns for e-business: A Strategy for Reuse, IBM Press, 2001, ISBN 1-931182-02-7. См. IBM Patterns for e-business для дополнительных шаблонов для электронного бизнеса в IBM developerWorks.

Шаблоны

Шаблон описывает решение для повторяющихся запросов. Образец решения связывает много шаблонов вместе. Рецепт описывает образцы (составные части) и порядок, в котором они должны использоваться для создания шаблона решения.

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

  1. Шаблон сложного бизнес процесса позволяет человеку порождать бизнес-процесс, требующий взаимодействия и контроля.
  2. Шаблон страницы объединения приложения, образец получения доступа к интегрированному приложению, который предоставляет структуру для данного обращения для множественных приложений через общий интерфейс, который может быть переделан.
  3. Динамический шаблон одной точки доступа, основной динамический шаблон, соответствующий шаблону приложения Агрегации страниц, который предоставляет одну точку доступа к различным Web-приложениям.
  4. Динамический шаблон Web-клиентов - это образец управляемого сотрудничества, который позволяет Web- клиентам взаимодействовать асинхронно предопределенным способом.

Системная архитектура

Как было описано в начале этой статьи, мы выполнили преобразование по требованию для реальной OTMPS. В последующих статьях (см. Ресурсы), мы опишем методы и способы, которые вы можете использовать для разработки и построения схожих систем. Рисунок 8 иллюстрирует взаимоотношения среди главных компонент в прототипе OTMPS:

  • WebSphere Portal -- содержит portlets, которые обеспечивают пользователю доступ к сервисам OTMPS.
  • WBI Server Foundation V5.1.1 - Обеспечивает следующие возможности:
    • Web container -- содержит servlets, используемые для управления требованиями, которые исходят от portlets (например, чтобы начать новый бизнес-процесс, чтобы собрать данные выполнения и так далее).
    • Process container -- предоставляет средства, которые выполняют (BPEL) бизнес-процесс.
    • BRBeans -- способствует расширению бизнес-правила.
    • CEI -- используется для генерации и сбора бизнес событий
  • DB - -архив данных (DB2®) для хранения BRBeans правил и для хранения данных CEI.
  • External configurator and legacy service -- внешние партнерские сервисы, используемые для заказа конфигураций и подтверждений. Они поддерживают протоколы MQ и FTP.
Рисунок 8. Компоненты -- Логический Вид
Рисунок 8. Компоненты -- Логический Вид

Вывод

Эта серия статей представляет собой краткий обзор развития жизненного цикла и технологий, необходимых для осуществления мобильных деловых процессов, которые создают непрерывно изменяющиеся требования. Мы описываем порядок обработки заказа, который задает общий контекст и набор прецедентов для других статей в этой серии. Первый шаг - это моделирование существующих и желательных деловых процессов при использовании WBI Modeler. Затем результирующие объекты модели расширяют дополнительными объектами, и окончательное приложение разворачивают на WBI-FS.CEI, чтобы генерировать необходимые события для измерений бизнес-метрики, которая будет вычислена и отображена при помощи деловых приборных панелей. Эта метрика, тогда обеспечивает ввод аналитикам, чтобы улучшить процесс, закрывая цикл. Дизайн архитектуры основан на применении технологии с множественными образцами для электронной коммерции, чтобы создать решение образца.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • Библиотека документов

    Более трех тысяч статей, обзоров, руководств и других полезных материалов.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы, WebSphere
ArticleID=106242
ArticleTitle=Жизненный цикл бизнес-процессов по требованию, Часть 1: Создание основы для вашего бизнес-процесса по требованию
publish-date=10222004