Содержание


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

Создание основы для вашего бизнес-процесса по требованию

Comments

Серия контента:

Этот контент является частью # из серии # статей: Жизненный цикл бизнес-процессов по требованию, Часть 1

Следите за выходом новых статей этой серии.

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

Следите за выходом новых статей этой серии.

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

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

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

В проекте 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, над которым мы работали:

  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
Рисунок 2. Сценарии поведения для OTMPS

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

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

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

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

Рисунок 3. Жизненный цикл процесса по требованию 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
Рисунок 4. Сегмент модели процесса in WBI Modeler V5.1

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

Третья статья цикла знакомит с методами и руководствами для управления пошаговым процессом моделирования с использованием 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
Рисунок 5. Редактор Application Developer BPEL

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

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

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

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

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

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

Как часть пробной программы 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 архитектура
Риснок 6. BRBeans архитектура

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

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

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

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

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

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

Инфраструктура 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. Компоненты -- Логический Вид
Рисунок 8. Компоненты -- Логический Вид

Вывод

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

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