Создание бизнес-процесса с помощью инструментов Rational и WebSphere

Моделирование. Бизнес-процесс

Разбить на страницы
Показывать лекцию целиком

В этой лекции мы описываем этапы создания и анализа нового бизнес-процесса с помощью WebSphere Business Integration Modeler, выступая в роли бизнес-аналитика.

Мы рассматриваем следующие темы:

  • введение в моделирование бизнес-процесса;
  • моделирование процесса изучения страховой претензии;
  • эмуляция процесса;
  • разработка реализации процесса.
    •  Внимание! На момент написания этой лекции курса последними версиями WebSphere Business Integration Modeler были 5.1.1.2 patch 3 и Modeler Version 6. Мы настоятельно рекомендуем вам использовать как минимум версию 5.1.1.2 patch 1для совместимости с Rational Software Architect 6.0.0.1. Существует исправление (патч) для переноса моделей с версии 5.1.1.1 в версию 5.1.1.2. Мы еще не тестировали цепочку инструментов для Modeler Version 6. Некоторые схемы в этом курсе были получены в версии 5.1.1.1, и в версии 5.1.1.2 они могут выглядеть немного иначе.

    4.1. Введение в управление бизнес-процессами

    В этом разделе мы познакомим вас с управлением бизнес-процессами и с WebSphere Business Integration Modeler v5 - инструментом для моделирования бизнес-процессов. Мы обсудим, кому, скорее всего, придется использовать данный инструмент, и рассмотрим две его редакции.

    4.1.1 Управление бизнес-процессами

    Управление бизнес-процессами (Business Process Management, BPM) - это концепция непрерывного создания, анализа и совершенствования бизнес-процесса (рис. 4.1).

    (рис 4.1) Непрерывный цикл совершенствования процесса

    Дональд Лайт (Donald Light) в работе "Deriving insurance business value from business process management tools" (см. библиографию) пишет, что BPM-решение, как правило, включает в себя следующие элементы:

  • интегрированную среду разработки (IDE);
  • библиотеку процессов;
  • систему выполнения процессов;
  • средства мониторинга;
  • базу данных выполнения;
  • средства моделирования и оптимизации.
    •

    Интегрированная среда разработки

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

    Библиотека процессов

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

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

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

    Мониторинг

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

    База данных выполнения

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

    Моделирование и оптимизация

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

    4.1.2 Комплект BPM-инструментов от IBM

    Эти элементы BPM-решения сведены вместе в комплект BPM-инструментов от IBM. В книге серии Redbooks под названием "Continuous business process management", SG24-6590, показано, как следует использовать инструменты WebSphere Business Integration, входящие в версию 4 платформы WebSphere, для реализации непрерывного цикла управления бизнес-процессами (рис. 4.2).

    (рис 4.2) Непрерывный цикл управления бизнес-процессом

    BPM-решение в WebSphere версии 4

    Эта версия включает в себя следующие элементы.

    Создание

    IBM WebSphere Business Integration Workbench V4.2.4. Business Modeler - это инструмент для создания бизнес-процесса, публикуемого в виде моделей на языке описания потоков (Flow Definition Language, FDL).

    Кооперация

    IBM WebSphere Business Integration Workbench Server V4.2.4. Business Repository и Web Publisher - это инструменты для донесения бизнес-процесса до других людей.

    Автоматизация

    WebSphere Business Integration Server V4.3 или IBM WebSphere MQ Workflow V3.5 - это рабочие среды для выполнения FDL-моделей.

    Управление

    IBM WebSphere Business Integration Workbench V4.2.4. Business Monitor - это инструмент для мониторинга бизнес-процессов.

    BPM-решение в WebSphere версии 5

    В версии 5 платформы WebSphere BPM-решение было переведено на применение открытых стандартов (использование Eclipse для инструментария, Java 2 Enterprise Edition) для рабочей системы и BPEL для моделирования и выполнения бизнес-процессов. Мы применили для нашего решения версию 5 платформы WebSphere.

    Создание

    WebSphere Business Integration Modeler Advanced Edition V5.1.1.2 - это инструмент, который мы использовали для изменения процесса обработки претензий и создания процесса для работы с внешними оценщиками, а также для оптимизации процессов обработки претензий на основе эмуляции.

    В WebSphere Business Integration Modeler есть функция создания отчетов, которая опрашивает бизнес-процессы и генерирует отчеты, которые можно направлять другим сотрудникам. Мы не использовали эту функцию в нашем примере.

    Как и в других инструментах, основанных на IBM Eclipse, в этом инструменте используется система конкурирующих версий (concurrent version system, CVS) для групповой работы. Мы использовали данный инструмент в автономном режиме, импортируя и экспортируя артефакты из других инструментов. Его также можно установить в качестве дополнения (плагина) к WebSphere Studio Application Development Integration Edition.

    Автоматизация

    После того как мы определили в WebSphere Business Integration Modeler процессы обработки претензий и работы с внешними оценщиками, мы смоделировали все решение, используя Rational Solution ArchitectВ действительности это 6-я версия продукта. Мы решили использовать ее, поскольку она лучше интегрирована с WebSphere Business Integration Modeler, чем Rational XDE $$\text{\texttrademark}$$ или Rational Rose (см. лекцию 5, "Архитектура системы").. На основе этой модели мы определили интерфейсы служб, которые мы собирались использовать для автоматизации операций в BPEL-модели. Затем мы использовали WebSphere Studio Application Development Integration Edition для детализации потоков BPEL для выполнения их в WebSphere Business Integration Server Foundation. Мы также использовали WebSphere MQ Workflow Buildtime для разработки процессов на языке Flow Definition Language (FDL), которые размещаются в WebSphere MQ Workflow. Кроме того, мы использовали Web-Sphere Business Integration Message Broker для маршрутизации и трансформации запросов к службам и WebSphere Application Server для размещения некоторых служб.

    Управление

    Мы не планировали проектировать и создавать решение для мониторинга в сценарии с обработкой претензий. Группа IBM System House Scenario будет создавать решение для мониторинга в следующем году. Это решение будет использовать инфраструктуру типовых событий (Common Event Infrastructure, CEI) и инструменты мониторинга, поддерживающие CEI.

    На данный моментВ версии 6 WebSphere Business Integration Modeler имеется широкая поддержка моделирования бизнес-параметров. существует возможность использовать CEI-монитор, поставляемый с WebSphere Business Integration Server Foundation, для мониторинга событий в потоке BPEL и IBM WebSphere Business Integration Workbench V4.2.4. Business Monitor для мониторинга WebSphere MQ Workflow.

    4.1.3 Зачем нужно моделирование бизнес-процессов

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

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

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

    • Мы использовали модели бизнес-процессов для разных целей, в том числе:

  • для документирования имеющихся процедур;
  • определения требований, предъявляемых к персоналу, системам и функциям;
  • планирования изменений существующих процессов и систем;
  • тестирования и анализа имеющихся и предлагаемых процессов;
  • выявления слабых мест в процессах.
    •

    4.1.4 WebSphere Business Integration Modeler

    Версия 5.1 является совершенно новой реализацией WebSphere Business Integration Modeler. В ней предлагается полное определение предприятия с точки зрения бизнеса, в частности:

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

    По сравнению с WebSphere Business Integration Modeler версии 4.2.4 в WebSphere Business Integration Modeler появились некоторые полезные новые свойства:

  • реализация на основе Eclipse;
  • BPEL-моделирование и поддержка Web-служб;
  • усовершенствованные возможности создания отчетов и выполнения эмуляции;
  • новая метамодель на основе UML2;
  • поддержка групповой работы.
    •  Внимание! Используя этот курс, вы можете создавать процессы в WebSphere Business Integration Modeler, не имея никакого опыта. Бизнес-аналитику, возможно, потребуется больше технической информации о Modeler, чем дается в этом курсе и в информационном центре Modeler. Однако если вы хотите использовать Modeler для создания потоков FDL или BPEL или если вы хотите получить более систематические данные, изучите книгу серии Redbooks под названием "BPEL4WS Business processes with WebSphere Business Integration: Understanding, Modeling, Migrating", SG24-6381, в частности лекцию 5.

    4.1.5 Редакции WebSphere Business Integration Modeler

    Существует две редакции WebSphere Business Integration Modeler. Это редакции Entry и Advanced. В табл. 4.1 перечислены возможности этих двух редакций.

    Свойства WebSphere Business Integration Modeler Entry edition и WebSphere Business Integration Modeler Advanced edition
    Свойства WebSphere Business Integration Modeler entry edition WebSphere Business Integration Modeler advanced edition
    Пользовательские профили Basic, intermediate и advanced Basic, intermediate и advanced
    Технологические режимы Operational Operational, BPEL и FDL
    Групповая работа Да Да
    Эмуляция Нет Да
    Статический и динамический анализ Нет Да
    Генерация отчетов Да Да
    Запросы Да Да
    Базовые шаблоны отчетов (доступность) Да Да
    Печать Да Да
    Импорт и экспорт проектов Modeler Да Да
    Импорт и экспорт файлов с разделителями Да Да
    Импорт ADF Да Да
    Импорт и экспорт XSD Нет Да
    Экспорт UML Нет Да
    Экспорт FDL и BPEL Нет Да
    Импорт FDL Нет Да

    4.2 Использование WebSphere Business Integration Modeler

    В этом разделе мы обсудим применение WebSphere Business Integration Modeler как в контексте ввода нового или измененного процесса в бизнес, так и в контексте разработки процесса в рамках более обширного программного решения.

    4.2.1 Кто применяет WebSphere Business Integration Modeler?

    На рис. 4.3 показаны типичные пользователи WebSphere Business Integration Modeler v5.x.

    (рис 4.3) Пользователи WebSphere Business Integration Modeler v5.x
  • Главными (первичными) пользователями являются бизнес-аналитики (ВА), специалисты по процессам и специалисты по ИТ-процессам.

    Бизнес-аналитики и специалисты по процессам применяют WebSphere Business Integration Modeler для создания бизнес-процессов, выявления возможностей для усовершенствований и оценки окупаемости инвестиций.

    Специалисты по ИТ-процессам (на схеме - корпоративные разработчики) применяют WebSphere Business Integration Modeler для детализации BPEL-процесса перед его экспортированием в инструмент автоматизации процессов.

  • Вторичные пользователи - это консультанты по стратегии и руководители направлений в бизнесе. Они должны понимать модели, создаваемые в WebSphere Business Integration Modeler, чтобы проверить и одобрить финансирование проекта. Мы называем этих пользователей бизнес-кураторами.
  • Другими пользователями WebSphere Business Integration Modeler являются ИТ-архитекторы. Они деляться друг с другом и обращаются к артефактам, созданным в рамках бизнес-модели, таким, как организационные структуры, задачи и роли, относящиеся к задачам в бизнес-процессе.
    •

    4.3 Моделирование процесса изучения претензии

    В этом разделе мы, взяв на себя роль бизнес-аналитика, будем работать с процессом изучения претензии, применяя WebSphere Business Integration Modeler Advanced Edition.

    В данном сценарии процесс изучения страховой претензии был смоделирован и работает как часть процесса обработки претензии WebSphere MQ Workflow компании LGI. Мы экспортировали процесс обработки претензии из WebSphere MQ Workflow и теперь имеем представление процесса изучения претензии на языке описания потоков Flow Definition Language (FDL), с которым начинаем работать.

    4.3.1 Запуск WebSphere Business Integration Modeler

    Если вы запускаете WebSphere Business Integration Modeler в первый раз, откроется мастер QuickStart (Быстрое знакомство). Нажмите Cancel (Отмена). WebSphere Business Integration Modeler запустится в раскладке с двумя панелями и перспективой Business Modeling (Бизнес-моделирование), как показано на рис. 4.4.

    Вы можете переключиться на 4-панельную раскладку, нажав на значок Apply 4-pane layout (Применить 4-панельную раскладку). Отобразятся следующие четыре панели:

  • Редактор процессов.
  • Представление Outline (Схема).
  • Дерево проекта.
  • Представление Attributes (Атрибуты).
    •  (рис 4.4) Двухпанельная раскладка WebSphere Business Integration Modeler

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

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

  • некоторые опции окажутся недоступными;
  • некоторые элементы нотации окажутся недоступными;
  • ранее работоспособная модель может стать неработоспособной, поскольку технологические режимы BPEL и MQ Workflow FDL являются более избирательными и имеют дополнительные правила проверки.
    •

    На рис. 4.5 приводится 4-панельная раскладка.

    (рис 4.5) Четырехпанельная раскладка WebSphere Business Integration Modeler

    4.3.2 Импортирование текущего процесса

    Чтобы импортировать текущий процесс, выполните следующие шаги:

  • В WebSphere Business Integration Modeler выберите пункт меню File (Файл) $$\to$$ Import (Импорт). Появится окно с заголовком Import (Импорт).
  • Выберите пункт WebSphere Business Integration Modeler Import $$\to$$ Next (Далее) $$\to$$ WebSphere MQ Workflow $$\to$$ Next (Далее), и вы увидите страницу WebSphere Business Integration Modeler Import Page, показанную на рис. 4.6.
  • Нажмите кнопку Browse (Обзор), чтобы указать директорию, в которой находится импортированный FDL-файл текущего процесса. У нас есть пример файла, который находится в директории .\SG24-6636\Modeler\Other\ClaimInvestigation_ASIS.fdl в папке дополнительных материалов к этому курсу.
  • Поскольку существующий процесс ClaimInvestigation достаточно простой и содержит только четыре задачи, как показано на рис. 2.4, мы отключили опцию Abstract logic in subprocess (Абстрактная логика в подпроцессе), чтобы Web-Sphere Business Integration Modeler не генерировал для него подпроцессов. Однако если FDL-процесс содержит больше задач и подпроцессов, мы рекомендуем установить эту опцию, чтобы WebSphere Business Integration Modeler мог сгенерировать число узлов, совпадающее с таковым в исходном процессе.
  • Нажмите кнопку New (Новый), чтобы создать новый проект, в который будет импортироваться процесс ClaimInvestigation. Укажите для этого проекта имя ITSOLGI и снимите все остальные опции, как это показано на рис. 4.7.
    •  (рис 4.7) WebSphere Business Integration Modeler Import Page(рис 4.6) Окно создания нового проекта бизнес-моделирования

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

    (рис 4.8) Успешный импорт FDL-процесса ClaimInvestigation

    4.3.3 Анализ имеющегося процесса

    В этом разделе мы изучим, каким образом WebSphere Business Integration Modeler представляет существующий процесс изучения претензии, импортированный из WebSphere MQ Workflow.

    Соответствия элементов

    Изучив проект ITSOLGI в дереве проектов, мы увидим соответствия элементов WebSphere MQ Workflow элементам WebSphere Business Integration Modeler, как показано на рис. 4.9.

    (рис 4.9) Соответствия элементов WebSphere MQ Workflow и WebSphere Business Integration Modeler
  • элементы из раздела Data structures (Структуры данных) импортируются как Business items (Бизнес-элементы) с теми же именами;
  • каталог процессов и процесс импортируются с теми же именами;
  • разделы Persons (Люди) и Roles (Роли) импортируются под теми же именами, но относятся теперь к разделу Resources (Ресурсы);
  • раздел Organizations (Организации) импортируется под тем же именем;
  • раздел Programs (Программы) не импортируется;
  • элементы закладки Network (Сеть) не импортируются.
    •

    Соответствия процессов

    Изучим соответствия процессов в WebSphere MQ Workflow и WebSphere Business Integration Modeler.

  • Исходный узел 1 (рис. 4.10) соответствует входу 1 (рис. 4.11) всего процесса.
  • Задача SelectReports 2 соответствует локальной задаче SelectReports 2.
  • Соответствия данных для двух коннекторов данных, соединяющих элемент SelectReports с элементами RequestExternalReports и SetClaimStat, реализуются в WebSphere Business Integration Modeler элементами Map 3 и 4 соответственно. На рис. 4-12 приводятся детали реализации элемента Map 4. Обратите внимание, что WebSphere Business Integration Modeler игнорирует поле Default value элемента-данных.
    •  (рис 4.11) Отображение процесса изучения претензии в WebSphere MQ Workflow (1)(рис 4.10) Отображение процесса изучения претензии в WebSphere Business Integration Modeler (1)(рис 4.12) Информация о соответствиях данных
  • Задача RequestExternalReports 5 соответствует локальной задаче RequestExternal-Reports 5 в WebSphere Business Integration Modeler.
  • Элемент Decision 6 явным образом используется в WebSphere Business Integration Modeler для двух элементов Control Connectors, связанных с элементом SelectReports в WebSphere MQ Workflow. Условия для двух ветвей выхода соответствуют условиям перехода двух элементов Control Connectors.
    •

    Одно из соответствий условий перехода показано в примерах 4-1 и 4-2.

    (Investigate_DataInput.Claim_DataInput.Status="V") AND (Report_Claim.AssReqDate <> "null")

    Пример 4-1 соответствует примеру 4-2.

    'RootProcessModel.Claim.ClaimInvestigation_ASIS.ClaimInvestigation_ASIS.
Decision.InputObjectPin.Investigate_DataInput.Claim_DataInput.Status'
is equal to "V" AND
'RootProcessModel.Claim.ClaimInvestigation_ASIS.ClaimInvestigation_ASIS.
Decision.InputObjectPin.Report_Claim.AssReqDate' is not equal to "null"

    На рис. 4-13 и 4-14 показана начальная часть процесса:

    (рис 4.14) Отображение процесса изучения претензии в WebSphere MQ Workflow (2)(рис 4.13) Отображение процесса изучения претензии в WebSphere Business Integration Modeler (2)
  • Элемент Fork используется в WebSphere Business Integration Modeler для разделения входа перед элементом UpdateExternalReports.
  • Связь 7 соответствует элементу Data Default Connector 7 в WebSphere MQ Workflow.
  • С выходными данными элемента UpdateExternalReports 8 не ассоциируется в WebSphere Business Integration Modeler никакого бизнес-элемента, поскольку элемент UpdateExternalReports 8 является асинхронной реализацией пользовательского сервера выполнения программ (User-Defined Program Execution Server, UPES).
  • Элемент Merge генерируется в WebSphere Business Integration Modeler для объединения входов 7, 9, 10 в следующий элемент.
    •

    На рис 4.15 и рис 4.16 показана последняя часть процесса. Обратите внимание на рис 4.13 и рис 4.14.

    (рис 4.16) Отображение процесса изучения претензии в WebSphere MQ Workflow (3)(рис 4.15) Отображение процесса изучения претензии в WebSphere Business Integration Modeler (3)
  • Связь 11 в WebSphere Business Integration Modeler соответствует элементу Data Default Connector 11 для элемента SetClaimStat в WebSphere MQ Workflow.
  • Элемент SetClaimStat 12 соответствует локальной задаче SetClaimStat 12. С выходными данными элемента SetClaimStat 12 не ассоциируется в WebSphere Business Integration Modeler никакого бизнес-элемента, поскольку этот элемент является в WebSphere MQ Workflow асинхронной реализацией пользовательского сервера выполнения программ (User-Defined Program Execution Server, UPES).
  • Выходной узел 13 WebSphere MQ Workflow соответствует выходу, обозначенному числом 13 WebSphere Business Integration Modeler.
  • Элемент Stop 14 добавляется в WebSphere Business Integration Modeler автоматически. Узел останова необходим для правильной работы любой эмуляции.
  • Как видно на рис. 2.6, задача RequestExternalReports является задачей, выполняемой вручную. Чтобы убедиться в этом, откройте процесс ClaimInvestigation в редакторе процессов и выберите элемент RequestExternalReports. В представлении Attributes (Атрибуты) перейдите на закладку Resources (Ресурсы).
    •

    На рис. 4.17 показаны соответствия ресурсов WebSphere MQ Workflow (две схемы в верхней части окна) и WebSphere Business Integration Modeler (одна схема в нижней части). Можно видеть, что задача RequestExternalReports требует кадровых ресурсов (Staff) для выполнения роли специалиста по обработке претензий (Claim handler) и относится к организации Claim Department (Отдел претензий). Значения в других полях генерируются автоматически в ходе импорта в WebSphere Business Integration Modeler. Значение в поле Time Required (Необходимое время) можно игнорировать.

    (рис 4.17) Требования к ресурсам: элемент RequestExternalReports в существующем процессе ClaimInvestigation

    4.3.4 Создание планируемого процесса

    Общая схема предполагаемого процесса была спроектирована на семинаре с использованием Microsoft Visio. Она представляет собой небольшую модификацию процесса ClaimInvestigation и новый подпроцесс, называемый RequestExternalReports, заменяющий собой выполняемую вручную задачу RequestExternalReports в процессе ClaimInvestigation.

    В данном разделе мы выполним поэтапную процедуру создания нового подпроцесса RequestExternalReports и изменения существующего процесса изучения претензии, используя рабочее пространство, которое мы только что создали, импортировав процесс из WebSphere MQ Workflow. Но сначала мы рассмотрим весь подпроцесс RequestExternalReports, созданный в Visio, и только потом перейдем к пошаговой процедуре детализации ее в WebSphere Business Integration Modeler.

    Логика планируемого процесса

  • Процесс RequestExternalReports инициируется из процесса ClaimInvestigation и начинается с разделения на две параллельных ветви.
  • В одной ветви создается список оценщиков, которые могут осуществить оценку претензии на основании своего географического положения и знакомства с данным типом автомобилей.
  • В другой ветви извлекается страховой полис клиента, и на основе согласованных в полисе данных определяется ожидаемое время проведения оценки.
    •  (рис 4.18) Процесс RequestExternalReports
  • По завершению выполнения этих задач всем подходящим оценщикам посылаются данные о претензии и требуемый срок проведения оценки. Им предлагается в фиксированный срок ответить, будут ли они выполнять оценку.
  • Далее процесс ожидает ответы, и отклоняет все, которые не уложились в отведенное время ответа.
  • Из списка оценщиков, пожелавших выполнить оценку, выбирается один оценщик на основании нескольких критериев, включая стоимость, качество оценки, надежность и т. п.
  • Если оценщиков, которые могли бы выполнить оценку, не оказывается, управление передается в задачу, выполняемую вручную. Специалист по обработке претензий должен вручную выбрать оценщиков, например расширив географическую область или увеличив время выполнения оценки.
  • Отправляется один запрос на выполнение оценки.
  • Процесс ожидает от оценщика подтверждения согласия на проведение оценки.
  • Оценщик отправляет отчет об оценке.
  • Отчет заносится в систему управления документами, после чего управление возвращается в процесс ClaimInvestigation, чтобы специалист по обработке претензии мог принять решение по претензии.
    •

    Контроль версий

    В WebSphere Business Integration Modeler для управления версиями применяется система конкурентных версий (Concurrent versions system, CVS). За дополнительной информацией о поддержке CVS обращайтесь к разделу Team Support (Поддержка групповой работы) центра информации WebSphere Business Integration Modeler: http://publib.boulder.ibm.com/infocenter/wbihelp/index.jsp.

    В этом курсе мы не будем демонстрировать реализацию CVS для WebSphere Business Integration Modeler. Вместо этого мы дадим разным версиям процесса разные имена: ClaimInvestigation_ASIS и ClaimInvestigation_TOBE, и соответственно каталоги ASIS и TOBEОт as-is (как есть, существующий) и to-be (будущий, планируемый). Примеч. пер .. Структура дерева проекта показана на рис. 4.19. Выполните следующие шаги:

  • Откройте дерево проектов. Щелкните правой кнопкой мыши по элементу ClaimInvestigation process $$\to$$ Rename (Переименовать) и укажите имя ClaimInvestigation_ASIS.
  • Щелкните правой кнопкой мыши по каталогу процесса Claim, выберите пункт меню New (Новый) $$\to$$ Process Catalog (Каталог процесса) и укажите имя ASIS. Будет создан каталог ASIS.
  • Щелкните правой кнопкой мыши по элементу ClaimInvestigation_ASIS, выберите пункт меню Copy (Копировать), щелкните правой кнопкой мыши по каталогу процесса ASIS и выберите пункт меню Paste (Вставить). Элемент ClaimInvestigation_ASIS будет скопирован в каталог ASIS.
  • Повторите шаг 2, чтобы создать еще один каталог - TOBE для бизнес-аналитика.
  • Повторите шаг 3, чтобы скопировать элемент ClaimInvestigation_ASIS в каталог TOBE, и переименуйте его в ClaimInvestigation_TOBE.
    •  (рис 4.19) Переименованные процессы ClaimInvestigation

    4.3.5 Создание нового процесса

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

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

    Для создания процесса RequestExternalReports у нас есть два варианта: создать его с нуля или импортировать презентацию Visio, созданную на семинаре. Мы предлагаем вам презентацию Visio в дополнительных материалах к этому курсу. За информацией о доступе к этим материалам обращайтесь к прил. "А", "Дополнительные материалы".

    Для начала мы покажем, как создать базовый процесс с нуля. Если же вы хотите импортировать процесс, созданный в Visio, обращайтесь к разделу "Вариант 2. Импорт процесса из Visio".

    Вариант 1. Создание процесса с нуля

    Чтобы создать процесс с нуля, выполните следующие шаги: в дереве проекта щелкните правой кнопкой мыши по каталогу TOBE, выберите пункт меню New (Новый) $$\to$$ Process (Процесс), укажите имя процесса - RequestExternalReports и любое его описание, после чего нажмите Finish (Готово). Процесс RequestExternalReports автоматически будет открыт в редакторе процесса. Убедитесь, что вы используете профиль Basic. Удалите узел Start, поскольку процесс запускается из другого процесса.

    Первая часть процесса

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

  • Выберите из палитры необходимые элементы, как показано на рис 4.20(рис 4.20) Процесс RequestExternalReports - часть 1 из 3
  • Мы используем элемент Fork для соединения входа процесса с двумя задачами - ResponsetimeBasedOnPolicy и IdentifyAssessorsResponsetimeBasedOnPolicy - время ответа на основе полиса; IdentifyAssessors - определение оценщиков. Примеч. пер ..Совет. Нажмите на небольшую стрелочку в левом углу значка join/fork/merge (соединение/разделение/слияние) палитры редактора процессов, чтобы переключить используемый элемент.
  • Информацию о каждой задаче можно ввести в поле Description (Описание), показанное на рис. 4.21. Мы также считаем удобным поместить описательную информацию в поле (рис 4.21) Поле описания задачи
  • Мы используем элемент Join (Соединение) для объединения выходных данных элементов ResponsetimeBasedOnPolicy и IdentifyAssessors. Элемент Join имеет следующие свойства:
  • снова соединяет и синхронизирует параллельно выполняющиеся ветви;
  • ожидает, пока каждая из ветвей получит все свои входные данные, а потом посылает выходные данные одновременно;
  • если вы хотите объединить в один вход несколько элементов-данных, вы должны добавить для этого специальную задачу.
    •
  • После того как вы поместите на канву указанные шесть элементов, выберите в процессе пункт Connections (Соединения), а затем щелкните внешний контур процесса. Щелкните в элементе fork по входному соединению, чтобы элемент fork стал первым элементом процесса. Откроется окно, показанное на рис. 4.22. Выберите пункт Input (Вход) в поле (рис 4.22) Выбор входа для процесса
  • Теперь рядом с соединением контура и входа элемента fork отображается значок с надписью String (рис. 4.23).
  • Теперь начнем соединять элементы. Начните с соединения 1 на рис 4.23. Вы увидите окно, показанное на рис 4.24. Выберите пункт Output:String (Выход:String) и нажмите (рис 4.24) Соединение процесса RequestExternalReports с его первым элементом(рис 4.23) Выбор выходного соединения в поле Fork:Source
  • Продолжайте соединять элементы. Вам будут снова предлагаться варианты точки назначения. Всегда выбирайте использование существующего соединения, а не создание нового.
    • Совет. Периодически сохраняйте процесс. Звездочка рядом с именем процесса на соответствующей закладке указывает на то, что процесс не сохранен. При сохранении будет проведена определенная проверка на ошибки. Другие ошибки вы также можете выявить, запустив статический анализ процесса (см. рис. 4.25). (рис 4.25) Проверка процесса на ошибки

    Вторая часть процесса

    Во второй части процесса выполняется выбор между двух вариантов:

  • ручной выбор оценщика, который будет проводить оценку;
  • процесс выбирает оценщика автоматически.
    •

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

    Вторая часть процесса показана на рис. 4.26, где WebSphere Business Integration Modeler переключен в режим Intermediate (Промежуточный), чтобы выводилось больше информации, в частности о режимах принятия решений.

    Совет. Мы рекомендуем вам создавать исходные соединения в базовом режиме (Basic), а затем переключиться в режим Intermediate, чтобы завершить определение критериев входа. В базовом режиме терминалы соединений создаются автоматически, а в промежуточном режиме вам нужно добавлять входные и выходные терминалы при помощи панели атрибутов. (рис 4.26) Процесс RequestExternalReports, часть 2 из 3
  • Мы использовали простой элемент Decision (Решение) с именем Any assessor? (Любой оценщик?), чтобы направлять поток либо к элементу SelectAssessor (Выбор оценщика), либо к элементу ManualSelectAssesor (Ручной выбор оценщика) после выполнения предыдущей задачи AssessorReceiveAndResponse. Если в списке оказывается хотя бы один оценщик, поток направляется к компоненту SelectAssessor, в противном случае - к компоненту ManualSelectAssessor.
  • Мы также добавили компонент Decision (Решение) с именем Confirmed (Подтверждено), чтобы вернуть поток к элементу ManualSelectAssessor, если выбранный оценщик не подтверждает получение запроса на оценку.
  • Мы указали логику ИЛИ (OR) для двух входов каждого из элементов Request-Assessment ManualSelectAssessor, поскольку обе эти задачи могут выполняться, если получен один из входов:
  • Чтобы задать логику входов, выберите пункт Modeling (Моделирование) $$\to$$ User Profile (Пользовательский профиль) $$\to$$ Intermediate (Промежуточный) в панели действий. Выберите пункт ManualSelectAssessor > Attributes View (Представление атрибутов) $$\to$$ Input logic (Логика входов) $$\to$$ Input criteria (Критерий входов) $$\to$$ Add (Добавить). Выберите Input (Вход) из панели доступных ( Available ) входов и перетащите его на панель выбранных ( Selected ) входов, после чего нажмите OK.
  • Повторите процедуру, чтобы добавить Input:2. Закладка логики входов панели атрибутов должна выглядеть так, как показано на рис 4.27(рис 4.27) Панель логики входов для элемента ManualSelectAssessor
  • Удалите первый критерий и очистите панель так, чтобы она выглядела, как по- казано на рис 4.28(рис 4.28) Критерий входов для задачи ManualSelectAssessor
    •  Совет. Ту же функцию можно реализовать при помощи элемента Merge (Слияние).

    Последняя часть процесса показана на рис. 4.29 в базовом режиме. Мы также соединяем элемент StoreReport (Сохранение отчета) с выходом процесса и узлом останова (Stop).

    (рис 4.29) Процесс RequestExternalReports, часть 3 из 3Совет. В данный момент мы можем запустить простую эмуляцию для проверки логики процесса. Можно выявить некоторые типичные ошибки, связанные с преждевременной остановкой. Например, процесс останавливается, если пропущен элемент Merge. Для выполнения эмуляции щелкните правой кнопкой мыши по процессу RequestExternalReports в дереве проекта и выберите пункт меню Simulate (Эмулировать).

    Вариант 2. Импорт процесса из Visio

    Чтобы импортировать схему Visio, вам нужна сохраненная схема Visio в форме XML - файл .vdx.

  • Выберите пункт меню File (Файл) $$\to$$ Import (Импорт) и в окне WebSphere Business Integration Modeler Import нажмите Next (Далее). Выберите в поле Types (Типы) пункт Microsoft Visio (vdx), нажмите Next (Далее) и выберите файл .\SG24-6636\Modeler\Other\RequestExternalReports.vdx из дополнительных материалов, поставляемых с этим курсом.
  • Нажмите Next (Далее) и выберите Page-1. Нажмите Add (Добавить).

    Окно мастера импорта будет выглядеть примерно так, как показано на рис. 4.31. При создании схемы Visio мы выбирали элементы из раздела Visio Business Process diagrams. Большая часть этих элементов уже имеет соответствия среди элементов WebSphere Business Integration Modeler. С помощью мастера импорта вы можете установить соответствия там, где их еще нет.

  • Нажмите Next (Далее) $$\to$$ Finish (Готово), чтобы завершить импортирование. Не обращайте внимания на предупреждения и рассмотрите импортированный процесс в папке Processes (Процессы). Результат показан на рис 4.30(рис 4.30) Процесс RequestExternalReports, импортированный из VisioОбратите внимание, что точки принятия решений не бинарные, а многовариантные.
  • Перенесите поток в каталог TOBE.
    •

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

  • Удалите два стартовых узла и две связи с элементом RequestAvailability.
  • Перетащите на канву элементы Fork и Join.
  • Соедините процесс RequestExternalReports с входным коннектором элемента Fork и задачей StoreReport.
  • Установите связи элементов Fork и Join.
  • Возможно, вы захотите перейти от многовариантных решений к бинарным, чтобы поток был более понятным.
    •

    Проверьте логику входов элементов ManualSelectAssessor и RequestAssessment. В обоих случаях должна использоваться логика OR (ИЛИ).

    (рис 4.31) Соответствие элементов Visio элементам WebSphere Business Integration ModelerСовет. На этом этапе создайте резервную копию своей работы. Функция отмены изменений имеет ограничения, поэтому вы регулярно должны создавать контрольные точки. Для этого существует много способов. Например, вы можете сохранить свою работку как проект WebSphere Business Integration Modeler. Если вам нужно будет выполнить восстановление, вы можете запустить новое рабочее пространство и загрузить в него проект.

    Изменение процесса ClaimInvestigation для вызова процесса RequestExternalAssessor

    Выполните следующие шаги:

  • Откройте проект ClaimInvestigation_TOBE в навигаторе проектов и удалите локальную задачу RequestExternalReports.
  • Перетащите процесс RequestExternalAssessor из навигатора проектов в процесс ClaimInvestigation_TOBE.
  • Добавьте в процесс ClaimInvestigation_TOBE новый элемент, Map (Соответствие):
  • Щелкните правой кнопкой мыши по процессу, выберите пункт меню New (Новый) $$\to$$ Map (Соответствие).
  • Откройте представление Attributes (Атрибуты) соответствия и перейдите на закладку Inputs (Входы). Сделайте двойной щелчок мышью по Associated data (Связанные данные), затем выберите Complex type (Сложный тип) $$\to$$ InvestigateClaim $$\to$$ OK.
  • Перейдите на закладку Outputs (Выходы). Сделайте двойной щелчок мышью по Associated data (Связанные данные), затем выберите Basic type (Базовый тип) $$\to$$ String $$\to$$ OK.
  • Соедините элементы, как показано на рис. 4.32.
    •  (рис 4.32) Добавление подпроцесса RequestExternalReports

    Определение ролей и организационных подразделений

    Чтобы выполнять только что определенные задачи, необходимы дополнительные роли и организационные подразделения. Они заключены на рис. 4.33 в синие рамки. Обратите внимание, что роли включают в себя как автоматизированные службы, так и людей. Это станет важным, когда мы будем использовать эту модель в Rational Software Architect или в Rational Software Modeler.

    Откуда берутся эти роли и организационные структуры? Как узнать на этой стадии определения процесса, какие автоматизированные службы необходимы?

    Бизнес-аналитик работает на семинарах совместно с архитектором решения. Как уже говорилось в разделе 3.2.2, "Области ответственности и разработка по контрактам", архитектура решения разрабатывается параллельно бизнес-процессу, чтобы можно было принимать решения о том, какие задачи следует автоматизировать. В настоящее время инструментарий еще недостаточно интегрирован, чтобы можно было вести одновременную интерактивную разработку бизнес-процесса и архитектуры решения. На семинарах мы использовали традиционные средства создания презентаций для создания исходного бизнес-процесса и предполагаемой архитектуры решения. Этого достаточно, чтобы понять, какие процессы в решении для работы с внешними оценщиками можно автоматизировать и какие роли должны быть добавлены в модель процесса (см. схему на рис. 3-16).

    Ниже мы дадим краткие описания ролей. Добавьте эти роли в рабочее пространство WebSphere Business Integration Modeler.

  • Claim handler (Специалист по обработке претензий) ведет в LGI обычную работу по обработке претензий. Измените при необходимости стандартную почасовую оплату ($15 за час) для этой роли.
  • Assessor (Оценщик) - это роль, которая проводит оценку претензий и посылает отчет об оценке. Оплата - $20 за час.
  • Роли Assessor Management (Управление оценщиками), Business Rules Engine (Система бизнес-правил) и Document Handler (Обработчик документов) представляют собой системы, которые работают автоматически. Мы устанавливаем для них стоимость $10 000 в год.
  • Claim handler Desktop (Рабочее место специалиста по обработке претензий) - это система, которую использует в своей работе специалист по обработке претензий. Стоимость - $10 000 в год.
    •  Совет. Выполнение роли обогащает ресурс, добавляя набор функций, которые ресурс должен иметь или осуществлять. Один ресурс может играть более чем одну роль.

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

  • External Assessors - это организационное подразделение для оценщиков претензий.
    •  Совет. Лучше связывать стоимость с ролями, чем с ресурсами, выделяемыми ролям, если только вы не хотите обозначить стоимость ресурса отдельно. Следует также принимать во внимание различные аспекты, связанные со стоимостью: мы можем определить стоимость в единицу времени для совокупного ресурса, например компьютера, когда он выполняет определенную роль, но не самому определению ресурса. (рис 4.33) Созданные роли и организационные подразделения

    Определение ресурсов для ролей

    Чтобы определить ресурсы для каждой роли, выполните следующие шаги:

  • Начните с добавления двух новых каталогов ресурсов:
  • Выберите в дереве проектов пункт Resources (Ресурсы), затем пункт New (Новый) $$\to$$ Resource Catalog (Каталог ресурсов). Назовите каталог Machines и нажмите Finish (Готово).
  • Повторите процедуру, чтобы создать каталог Timetables.
    •
  • Создайте новое определение ресурса для оценщиков претензий, назвав его External Resources.

    Выберите в дереве проектов пункт Resources (Ресурсы), затем пункт New (Новый) $$\to$$ Resource Definition (Определение ресурсов). Дайте определению имя ExternalResources. Укажите тип individual (Индивидуальный) [вместо bulk (Сово- купный)] и нажмите Finish (Готово).

  • Теперь создайте два компьютера:
  • Выберите пункт меню Machines > New (Новый) > Resource (Ресурс). Выберите Machine в качестве определения данного ресурса ( Associated resource definition ) и назовите ресурс Computer 001 (см. рис 4.34(рис 4.34) Создание нового ресурса-компьютера - шаг 1
  • Добавьте роли, которые этот компьютер будет выполнять, для чего перейдите на закладку Qualifications (Квалификация) и добавьте роли, как показано на рис 4.35(рис 4.35) Роли компьютера Computer 001
  • Чтобы создать второй компьютер (Computer 002), быстрее всего будет скопировать и вставить Computer 001 и изменить роли, как показано на рис 4.36(рис 4.36) Роль компьютера Computer 002
  • Добавьте специалистов по обработке претензий (Claim handlers). Здесь мы покажем, как создать первого такого специалиста:
  • Перейдите к дереву проектов, затем выберите пункт Persons (Люди) $$\to$$ New (Новый) $$\to$$ Resource (Ресурс) $$\to$$ individual (Индивидуальный) $$\to$$ Staff (Персонал). Назовите ресурс Claim handler 001 и нажмите Finish (Готово) (рис 4.37(рис 4.37) Создание нового специалиста по обработке претензий
  • Перейдите на закладку Qualifications (Квалификации), нажмите Add (Добавить) $$\to$$ (рис 4.38) Назначение специалисту по обработке претензий роли Claim handler
  • С помощью копирования/вставки создайте еще 19 специалистов. Если вы используете более раннюю версию, вам нужно выполнять копирование перед каждой вставкой. В исправленной версии WebSphere Business Integration Modeler 5.1.1 это необязательно.
  • Мы предполагаем наличие множества оценщиков (Assessors), которых относим к внешним ресурсам:
  • Перейдите к дереву проектов, затем выберите пункт Persons (Люди) $$\to$$ New (Новый) $$\to$$ Resource (Ресурс) $$\to$$ individual (Индивидуальный) $$\to$$ External Resources (Внешние ресурсы), назовите ресурс Assessor, после чего нажмите Finish (Готово).
  • Мы не указываем здесь стоимость, но назначаем роль (поле Role ) \Resources\Roles\Assessor.
    • Важно! Если какой-то роли не будет назначен индивидуальный или совокупный ресурс и роль будет связана с задачей, эмуляция завершится ошибкой.

    Определение расписаний (timetables)

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

  • Определите расписание (timetable) с именем NormalWorkTime, как показано на рис 4.39(рис 4.39) Расписание NormalWorkTime. Содержимое закладки Recurring time intervals (Периоды времени)
  • Перейдите к дереву проектов, затем выберите пункт Timetables (Расписание) $$\to$$ New (Новый) $$\to$$ Timetable (Расписание). Назовите расписание NormalWorkTime и нажмите Finish (Готово) (рис. 4.39).
  • Откройте расписание и выберите пункт Time interval (Временной интервал) $$\to$$ Remove (Удалить) $$\to$$ Add (Добавить). Введите значение Working hours и нажмите OK. Укажите значение 9:00 AM в поле Start time (Начало работы) и 8 hours в поле duration (Продолжительность). Оставьте заданную по умолчанию дату.
    •
  • Еще два расписания с именами LunchTime (рис 4.40) и Weekend (рис 4.41) определите сходным образом.
  • Сохраните все расписания и вернитесь к NormalWorkTime. Перейдите на закладку Exemption periods (Нерабочее время) и добавьте в качестве нерабочего времени расписания Lunchtime и Weekend.
    • (рис 4.41) Расписание LunchTime. Содержимое закладки Recurring time intervals (Периоды времени)(рис 4.40) Расписание Weekend. Содержимое закладки Recurring time intervals (Периоды времени)

    Таким образом, нормальным рабочим временем будет время с понедельника по пятницу с 9 утра до 5 вечера с получасовым обеденным перерывом. Окончательный вид расписания NormalWorkTime показан на рис 4.42, где рабочие часы обозначены синим цветом, а нерабочие - красным.

    (рис 4.42) Представление Attributes (Атрибуты) расписания NormalWorkTimeСовет. Наведите указатель мыши на представление Attributes (Атрибуты) и нажимайте кнопки мыши, чтобы увеличить или уменьшить увеличение. Указывайте на периоды в расписании, чтобы увидеть имя интервала и его начальный и конечный срок. Обратите внимание, что после того, как мы изменили имя временного интервала с заданного по умолчанию Time interval на Working hours, Lunch и Weekend, мы можем более ясно видеть построение расписания в этом представлении.

    Мы присваиваем расписание NormalWorkTime ролям Claim handler и Assessor. Для отдельных специалистов по обработке претензий или оценщиков расписание отображаться не будет.

    Назначение ресурсов задачам

    После того как роли определены, мы назначаем их задачам в процессе Request-ExternalReports.

  • Выберите задачу ResponseTimeBasedOnPolicy в редакторе процессов, щелкнув по ней мышью в представлении Attributes (Атрибуты), перейдите на закладку Resources (Ресурсы), раскройте пункт Role requirements (Необходимые роли) (если он еще не раскрыт), нажмите кнопку Add (Добавить), укажите данные в соответствии с таблица 4.2.(рис 4.43) Указание ролей для задачи ResponseTimeBasedonPolicy
  • Измените значение в поле Name (Имя) на что-нибудь более описательное. Это имя будет использоваться, если архитектор решения применяет схемы деятельности в Rational Software Architect. Задачи группируются по столбцам с использованием этого имени. Для начала можно использовать здесь то же имя, которое имеет роль.
    •  Совет. Вы можете перетаскивать ресурсы из дерева проектов прямо на задачу. Но вам нужно будет открыть каждую задачу и убедиться в том, что требования по необходимым ролям выполнены.

    Также определите организационное подразделение для задач, используя данные в таблица 4.2.

    (рис 4.44) Пример назначенных для задачи ресурсов и организацийСовет. Поле Time required for Resources (Время, необходимое для ресурсов) используется для вычисления стоимости определенных ресурсов при эмуляции. Это значение отличается от значения Time required to finish task (Время, необходимое для завершения задачи), которое вы можете указать при выполнении эмуляции.
    Параметры назначения задачам ресурсов и организационных подразделений
    Задача Роль Необходимое время Количество Определение ресурса Организация
    ResponseTimeBasedOnPolicy BusinessRules Engine 1 секунда 1 Machine Claim Department
    IdentifyAssesors AssessorManagement 1 секунда 1 Machine Claim Department
    RequestAvailability Assessor 2 минуты 1 External Resource External Assessors
    SelectAssessor Business Rules Engine 1 секунда 1 Machine Claim Department
    ManualSelectAssessor Claim handler 2 минуты 1 Staff Machine Claim Department
    Claim handler Desktop 2 минуты 1
    RequestAssessment Assessor 1 секунда 1 External Resource External Assessors
    AssessorSendReport Assessor 1 час 1 External Resource External Assessors
    StoreReport Document Handler 1 секунда 1 Machine Claim Department

    Вы также можете назначать задачам индивидуальные или совокупные ресурсы. При запуске задачи будет производиться выделение всех назначенных ресурсов. Например, мы назначили роль Claim handler количеством 2. Также мы назначили этой же задаче ресурс Claim handler 001, поэтому выполнять эту задачу будут три индивидуальных специалиста по обработке претензий. Два из них относятся к требованию по необходимым ролям, и они выделяются динамически, и еще один относится к требованию индивидуального ресурса, и это фиксированный ресурс Claim handler 001.

    Определяя критерий требования к индивидуальным ресурсам, вы заставляете проводить выделение ресурсов динамически. В этом случае значение в столбце индивидуального ресурса должно быть установлено в Person или в Staff, как это показано на рис 4.17.

    Просмотр всего процесса в Swimlane

    Нажав на кнопку Launch Swimlane Viewer (Запустить средство просмотра Swimlane) на палитре, как показано на рис 4.45, вы получаете возможность просмотреть схему процесса в формате swimlane, с сортировкой по ролям, ресурсам, организационным подразделениям или местоположению.

    (рис 4.45) Палитра WebSphere Business Integration Modeler

    На рис 4.46 показан вид процесса в Swinlane с сортировкой по ролям.

    (рис 4.46) Вид процесса в Swinlane с сортировкой по ролям

    4.3.6 Возможности, интересные для бизнес-аналитика

    Анализ модели процесса - это один из главных этапов цикла разработки модели. WebSphere Business Integration Modeler предоставляет различные аналитические функции, которые позволяют извлекать из моделей различные типы важной бизнес-информации.

    Существует два типа анализа - статический анализ и создание отчетов.

  • Статический анализ осуществляется на основе информации из модели. Например, мы можем использовать параметр Qualified Resources for Roles (Связанные с ро- лями ресурсы), чтобы узнать, сколько ресурсов было выделено определенным ролям. Для этого нужно щелкнуть правой кнопкой мыши в любом месте дерева проектов и выбрать пункт меню Static Analysis (Статический анализ) $$\to$$ Resource Analysis (Анализ ресурсов) $$\to$$ Qualified Resources for Role (Ресурсы, выделенные роли). В открывшемся окне выберите пункт Select all (Выбрать все), если вы хотите увидеть все ресурсы, а затем нажмите .(рис 4.47) Часть результатов анализа ресурсов, выделенных ролям
  • Динамический анализ выполняется на основе результатов эмуляции процесса, чтобы получить больше сведений. Существует четыре типа таких анализов:
  • Совокупный анализ ( Aggregated Analysis ). Дает сведения об операциях и ресурсах, используемых во всех экземплярах процесса, сгенерированных при эмуляции.
  • Анализ процесса ( Process Analysis ). Выполняется суммарный анализ по экземплярам процесса с выводом данных:
  • прецедентах процесса (process cases);
  • экземплярах процесса (process instances) сгенерированных в ходе эмуляции, а также показывается вероятность возникновения каждого прецедента процесса.
    •
  • Сравнительный анализ процессов (Process comparison analysis). Сравнивается средневзвешенная величина результатов анализа для двух эмулированных процессов, использующих одинаковые входные параметры.
  • Запросы (Queries). Запросы возвращают данные об элементах модели, относящихся к одному указанному типу.

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

    В категории Queries (Запросы) дерева проектов есть 25 готовых запросов. Вы также можете создавать новые запросы.

  • Отчеты (Reports) - это структурированное представление информации, относящейся к модели или к результатам анализа эмуляции процесса:
  • WebSphere Business Integration Modeler предлагает всего 95 типов шаблонов отчетов в категориях, относящихся к базовому профилю (Basic), промежуточному профилю (Intermediate) и усложненному профилю (Advanced), а также к вспомогательным отчетам (Collateral Reports);
  • вы можете генерировать отчеты по запросам, статическому или динамическому анализу;
  • вы можете просматривать отчеты в интерактивном режиме в WebSphere Business Integration Modeler, распечатывать их и экспортировать в различные файловые форматы.

    • 4.4 Эмуляция процесса

    После создания модели бизнес-процесса мы можем выполнить ее эмуляцию в WebSphere Business Integration Modeler, чтобы оценить ее производительность и внести соответствующие корректировки.

    Если вы хотите использовать здесь готовую модель, создайте новый проект или новое рабочее пространство и импортируйте файл .\SG24-6636\Modeler\Projects\ PreBPEL.zip. Результаты эмуляции находятся в файле .\SG24-6636\Modeler\Projects\ Simulation Results.zip. Обращайтесь к прил. "А", "Дополнительные материалы".

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

    4.4.1 Создание эмуляционного снимка

    Сейчас мы можем запустить эмуляцию для процесса RequestExternalReports.

  • Щелкните правой кнопкой мыши по модели процесса в дереве проектов и выберите пункт меню Simulate (Эмуляция). Будет создан эмуляционный снимок процесса (simulation snapshot), показанный на рис 4.48.(рис 4.48) Эмуляция процессаЭтот снимок содержит:
  • копию бизнес-процесса;
  • копию всех элементов модели в проекте на данный момент времени;
  • набор локальных настроек атрибутов эмуляции, показанный на рис 4.49.(рис 4.49) Локальные атрибуты эмуляции в эмуляционном снимке
    •  Примечание. Многие значения локальных настроек эмуляции происходят от глобальных параметров эмуляции. Настройки эмуляции конкретного процесса и задачи также происходят от локальных настроек эмуляции. Однако для эмуляции берутся значения, специально заданные для конкретного процесса или задачи.
  • Щелкнув мышью по пустой области снимка процесса в редакторе эмуляции, показанном на рис 4.50, вы откроете настройки эмуляции, заданные для всего процесса (рис 4.51).(рис 4.51) Снимок процесса в редакторе эмуляции(рис 4.50) Настройки эмуляции для всего процесса
  • Кроме того, мы можем указать атрибуты эмуляции задачи, выделив эту задачу. На рис 4.52 показаны атрибуты эмуляции задачи IdentifyAssessors. Они дополняют собой те атрибуты, которые были определены в настройках эмуляции процесса.(рис 4.52) Параметры эмуляции для задачи
  • Проверьте значения на других закладках параметров эмуляции процесса. В частности, внесите изменения в закладку Resources (Ресурсы), чтобы сюда включались только те ресурсы, которые мы хотим использовать при эмуляции (рис 4.53).(рис 4.53) Выбор ресурсов для эмуляции

    • 4.4.2 Определение значений для эмуляции

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

  • Перейдите на закладку Inputs (Входы) представления Attributes (Атрибуты) параметров эмуляции процесса (рис 4.51). Выберите строку, в которой отображаются входные данные. Окно будет выглядеть примерно так, как показано на рис 4.54:(рис 4.54) Параметры создания метки
  • Мы можем выбрать вариант Time trigger (Временной триггер), если нужно, чтобы эстафеты поступали с определенными интервалами, или Random time trigger (Триггер случайного срабатывания), если нужно, чтобы эстафеты поступали случайным образом.
  • При выборе варианта Random time trigger (Триггер случайного срабатывания) мы можем выбрать определенное распределение.
  • При выборе варианта Time trigger (Временной триггер) мы можем указать начальный момент создания эстафеты и Recurring time interval for bundle creation (Периодичность создания пакетов).
  • При указании параметра Recurring time interval for bundle creation (Периодичность создания пакетов) указывается время проведения эмуляции. Например, мы указываем:
  • Number of tokens per bundle (Количество эстафет в комплекте): 2;
  • Total number of tokens (Общее число эстафет): 20;
  • Recurring time interval for bundle creation (Периодичность создания пакетов): 3 минуты;
  • следовательно, период эмуляции составляет (20/2) * 3=30 минут.
    •  Совет. Хорошей практикой является до изменения любых параметров всегда запускать эмуляцию всего процесса, указывая число эстафет равным 1. Таким образом, вы можете проверить правильность логики процесса при сохранении минимального времени эмуляции.
  • Чтобы предсказать объем поступления претензий, мы будем использовать данные из реальной жизни, которые показывают, что в год в среднем поступает 1.5 претензии на 100 полисов автострахования. Для объединенной компании это даст нам следующий ожидаемый объем поступления претензий:
  • 6 000 000 * 1.5/100 = 90 000 претензий в год.
  • предполагая, что в году 250 рабочих дней, получаем 90 000/250 = 360 претензий в день;
  • предполагая, что оценка требуется для 70% претензий, получаем 360 * 70% = 252 оценки в день;
  • теперь мы можем получить периодичность создания пакетов: 8 * 60/252 = 1 минута 54 секунды, где количество эстафет в пакете = 1.

    • Установите 1-часовую обработку претензий на основе данных, указанных в шаге 2, чтобы длительность эмуляции была приемлемой. При таких данных эмуляция занимает около 5 минут на 2 ГГц Intel $$\text{\textregistered}$$ Pentium $$\text{\textregistered}$$ IBM Mseries Thinkpad (см. рис 4.55).

    (рис 4.55) Параметры создания эстафет для симуляции 1-часовой работы

    Указание продолжительности для каждой задачи

    Для каждой задачи, входящей в процесс, нужно заполнить в эмуляционном снимкеНачиная с WebSphere Business Integration Modeler 5.1.1.2 эти значения можно задавать как в модели, так и в эмуляционном снимке. Это удобно при работе с несколькими эмуляционными снимками. два поля (рис 4.56):

    (рис 4.56) Требования к ресурсу
  • Resource wait time (Время ожидания ресурса).

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

  • Processing time (Время обработки).

    Это время, которое требуется ресурсу для выполнения задачи. Сумма времени обработки и времени ожидания ресурса иногда называется в планировании проекта использованным временем (elapsed time).

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

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

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

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

    В других случаях в этих двух полях указываются разные значения. Например, в задаче RequestAvailability наша система посылает запросы всем подходящим оценщикам и ожидает от них ответ, показывающий, доступны они или нет. Может случиться так, что за несколько часов запрос никто не увидит. Однако после того как оценщик увидит запрос, ему нужно лишь несколько минут, чтобы просмотреть свой график работы и сообщить данные о своей готовности. В данном случае мы устанавливаем параметр Time required to finish task (Время, необходимое для выполнения задачи) (это время равно 4 часам), в то время как параметр Time required (Необходимое время) соответствует времени, равному 2 минутам.

    В табл. 4.3 перечислены параметры времени для задач. Введите эти числа в эмуляционный снимок, как показано на рис 4.56.

    Параметры продолжительности выполнения задачи, устанавливаемые для эмуляции
    Задача Время обработки Время, необходимое роли Ресурс
    ResponseTimeBased OnPolicy 1 секунда 1 секунда Business Rules Engine
    IdentifyAssesors 1 секунда 1 секунда AssessorManagement
    RequestAvailability 4 часа 0Указав здесь 0, мы не учитываем в этой эмуляции время и стоимость работы оценщика в задаче RequestAvailability. Assessor
    SelectAssessor 1 секунда 1 секунда Business Rules Engine
    ManualSelect Assessor 2 минуты 2 минуты Claim handler
    2 минуты 2 минуты Claim handler Desktop
    RequestAssessment 1 час 0Указав здесь 0, мы не учитываем в этой эмуляции время и стоимость работы оценщика в задаче RequestAssessment. Assessor
    AssessorSendReport 2 дня 0Указав здесь 0, мы не учитываем в этой эмуляции время и стоимость работы оценщика в задаче AssessorSendReport. Assessor
    StoreReport 1 секунда 1 секунда Document Handler

    Указание выходов для элементов Decision (Решение)

    Для элементов Decision (Решение) мы указываем вероятность для каждого типа выхода, как показано в табл. 4.4.

    Вероятности для выходов элемента Decision
    Элемент Decision Вероятность ответа "Да" Вероятность ответа "Нет"
    Any assessor? 90% 10%
    Confirmed? 95% 5%

    Параметры, приведенные в табл. 4.4, предполагают следующую ситуацию:

  • Существует 90%-я вероятность того, что хотя бы один оценщик будет доступен. Существует 10%-я вероятность того, что доступных оценщиков не окажется и, следовательно, специалисту по обработке претензий придется назначать его самому.
  • Существует 95%-я вероятность того, что оценщик, оказавшийся доступным, сможет выполнить оценку. Существует 5%-я вероятность того, что оценщик не сможет выполнить оценку из-за исключительных обстоятельств, например несчастного случая.
    •

    Теперь мы укажем в поле Method of selecting an output path (Метод выбора пути выхода) значение Based on probabilities to single path (Один путь на основе вероятности), как показано на рис 4.57.

    (рис 4.57) Снимок экрана с параметрами логики выходов для элемента Decision

    4.4.3 Запуск эмуляции

    Чтобы запустить эмуляцию, переключитесь на Control Panel (Панель управления) и нажмите кнопку Start (Пуск), как показано на рис 4.58.

    (рис 4.58) Панель управления эмуляциейСовет. Если вы не можете найти панель управления, выберите пункт меню Window (Окно) $$\to$$ Show View (Показать представление) $$\to$$ Control Panel (Панель управления) в главном меню.

    Мы можем всегда установить паузу, остановить эмуляцию или выполнить ее пошагово, нажимая соответствующие кнопки на панели управления.

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

    (рис 4.59) Анимация при эмуляции

    После завершения эмуляции ее результат сохраняется в дереве проектов, как показано на рис 4.60. Различать результаты разных эмуляций можно по времени их завершения.

    (рис 4.60) Результаты эмуляции, сохраненные в дереве проектовСовет. Если эмуляция останавливается и вы видите сообщение о том, что для завершения эмуляции не хватает ресурсов, то при этом имеются в виду ресурсы эмуляции, а не проблема в системе. Для процесса необходимо больше ресурсов. Возможно, вы сконфигурировали что-то неверно. Проверьте следующие возможности:
  • Максимальное время ожидания слишком мало и не позволяет эмуляции завершиться.
  • Ресурс Assessor относится к внешним ресурсам.
  • Для операций, выполняемых оценщиками, в поле Organization указано External Resources, а не Person или Staff.
    •

    4.4.4 Эмуляция всего процесса изучения претензии

    Для сравнения нам понадобится эмулировать процессы ASIS и TOBE.

  • Эмуляция процесса ClaimInvestigation_ASIS.

    Перед созданием эмуляционного снимка укажите время ручной обработки задачи RequestExternalReports равным 30 минутам на закладке Resources (Ресурсы) локальной задачи InvestigateClaim.

  • Эмуляция процесса ClaimInvestigation_TOBE.

    На этот раз укажите 360 претензий в день, из которых 70% требуют оценки.

    •

    Существует два способа выполнения эмуляции всего процесса ClaimInvestigation_TOBE, содержащего подпроцессы.

    Примечание. Нельзя провести оценку конкретного подпроцесса. Однако вы можете выбрать опцию, позволяющую указать, нужно ли оценивать все подпроцессы, включая те, содержимое которых неполно. Вы можете указать вариант No (Нет) для опции Evaluate all subprocesses (Оценивать все подпроцессы) в атрибутах эмуляции процесса, а также можете указать значение по умолчанию для этого атрибута как локального или как глобального параметра. Это означает, что эмуляция будет пропускать подпроцесс.
  • Укажите значения для всех подпроцессов на основании предыдущих эмуляций и эмулируйте только новый процесс.Примечание. Хорошей отправной точкой для эмуляции процесса TOBE является проект .\SG24-6636\Modeler\Projects\Claim preBPEL.zip или .\SG24-6636\Modeler\projects\Parms Set. Последний представляет собой набор параметров эмуляции процесса RequestExternalReports, поэтому нам нужно будет только установить параметры эмуляционного снимка ClaimInvestigation_TOBE. Откройте эмуляционный снимок в редакторе эмуляций и укажите на закладке General (Общие) представления Attributes (Атрибуты) в поле Evaluate all (Оценить все) значение No:
  • Выберите в редакторе эмуляции подпроцесс RequestExternalReports и укажите на закладке General (Общие) в поле Time required to finish this task (Время, необходимое для завершения задачи) средневзвешенное значение времени выполнения цикла процесса (weighted average Process cycle time), которое можно получить в результате динамического анализа результатов предыдущих эмуляций. Например, 2 дня 5 часов и 7 минут.
  • Выберите в редакторе эмуляции подпроцесс RequestExternalReports и укажите на закладке Cost and revenue (Стоимость и доход) в поле Cost per execution of the task (Стоимость одного выполнения задачи) средневзвешенное значение общей стоимости (weighted average total cost) для процесса RequestExternalReports (например, $0.105).
    •
  • Выполните эмуляцию процесса и всех подпроцессов.

    Оставьте в поле Evaluate all Subprocesses (Оценить все подпроцессы) на закладке General (Общие) представления Attributes (Атрибуты) значение Yes (Да):

  • Щелкните правой кнопкой мыши по процессу ClaimInvestigation и выберите пункт меню Expand All (Раскрыть все) (рис. 4.61);
  • Выберите задачи в процессе RequestExternalReports и установите для них параметры эмуляции, как это делалось ранее.
    • (рис 4.61) Раскрытие подпроцессов в редакторе эмуляции

    4.4.5 Анализ результатов

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

    (рис 4.62) Последние результаты по экземплярам процесса после эмуляции

    На закладке Tasks (Задачи) мы получаем стоимость по каждой задаче в каждом экземпляре процесса. На рис 4.63 показана стоимость задач в экземпляре процесса ClaimInvestigation_ASIS.

    (рис 4.63) Последние результаты по задачам после эмуляции

    На закладке Connections (Соединения) показаны эстафеты, переданные в каждом соединении.

    Динамический анализ результатов эмуляции

    На основе сохраненных результатов эмуляции мы можем выполнить динамический анализ. Щелкнув правой кнопкой мыши по результатам эмуляции в дереве проектов и выбрав пункт Dynamic Analysis (Динамический анализ), вы можете увидеть различные типы динамического анализа. Ниже мы приводим некоторые из выполненных нами анализов.

  • Activity Resource Allocation (Ресурсы, назначенные задачам). Показывает ресурсы, выделенные для каждой задачи. На рис 4.64 показаны ресурсы, выделенные задачам в процессе RequestExternalReports.(рис 4.64) Анализ: ресурсы, выделенные задачам в процессе RequestExternalReports
  • Resource Utilization Analysis (Анализ использования ресурсов). Показывает все ресурсы, которые были выделены в ходе эмуляции. В табл. 4.5 для примера показан один из таких ресурсов, Claim handler 001.
    Пример анализа использования ресурсов
    Claim handler 001
    Allocated from (выделялся в период с) December 6, 2004 3:14:00 PM GMT
    Allocated to (выделялся в период по) December 6, 2004 3:16:00 PM GMT
    Allocating process instance (экземпляр процесса, для которого был выделен) RequestExternalReports 39
    Allocating activity (задача, для которой был выделен) ManualSelectAssessor
    Allocating activity start time (начало выполнения задачи, для которой был выделен) December 6, 2004 3:14:00 PM GMT
    Quantity allocated (количество) 1
    Allocation duration (продолжительность) 2 minutes
    Shortage duration (нехватка времени) 0 seconds
    Allocation cost (стоимость выделения ресурса) $0.50
  • Process cost analysis (Анализ стоимости процесса). Выполняется применительно к процессу RequestExternalReports.
    •

    Как показывают результаты в табл. 4.6, существует четыре возможных прецедента (case) выполнения процесса RequestExternalReports. Это объясняется тем, что процесс имеет две точки принятия решения. Каждый прецедент имеет определенную вероятность возникновения. Средневзвешенное значение (Weighted average) стоимости для всего процесса составляет 0.080866$Может быть и более четырех прецедентов, если в каком-нибудь экземпляре элемент "Confirmed?" будет выполнен в цикле несколько раз..

    Анализ стоимости процесса для RequestExternalReports
    Имя прецедента Вероятность Доход Выполнение Простой Стоимость выделения ресурсов Итого
    Case 1 85.50% $0.00 $0.00 $0.00 $0.0013 $0.001
    Case 2 9.50% $0.00 $0.00 $0.00 $0.54 $0.539
    Case 3 0.48% $0.00 $0.00 $0.00 $1.078 $1.077
    Case 4 4.28% $0.00 $0.00 $0.00 $0.54 $0.539
    Weighted average $0.00 $0.00 $0.00 $0.081 $0.081
  • Activity cost analysis (Анализ стоимости для задачи). Выполнялся для процесса ClaimInvestigation_ASIS. Особый интерес для нас представляла задача Request- ExternalReports. Результаты показаны в табл. 4.7.
    •

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

    Анализ стоимости выполнения задачи RequestExternalReports в процессе InvestigateClaims_ASIS
    Средний доход Средняя стоимость выполнения Средняя стоимость простоя Средняя стоимость выделения ресурсов Средняя общая стоимость Средняя прибыль
    $0.00 $0.00 $0.00 $7.50 $7.50 ($7.50)
  • Process cost comparison analysis (Сравнительный анализ стоимости процес- сов). Выполняется для результатов двух эмуляций - ClaimInvestigation_ASIS и ClaimInvestigation_TOBE.

    После выполнения эмуляций щелкните правой кнопкой мыши по сохраненному результату эмуляции в дереве проектов и выберите пункт меню Dynamic analysis (Динамический анализ) $$\to$$ Process comparison analysis (Сравнительный анализ процессов) в появившемся окне Simulation results (Результаты эмуляции) (рис 4.65), после чего выберите эмуляцию для сравнения и нажмите OK.

    •  (рис 4.65) Окно выбора результата эмуляции для сравнительного анализа процессов

    Результаты показаны в табл. 4.8.

    Результаты анализа стоимости процессов
    Процесс Доход Стоимость выполнения Стоимость простоя Стоимость выделенных ресурсов Общая стоимость Прибыль
    ClaimInvestigation_TOB E $0.00 $0.00 $0.00 $0.250634 $0.250634 ($0.250634)
    ClaimInvestigation_ASIS $0.00 $0.00 $0.00 $7.750634 $7.750634 ($7.750634)
    Difference $0.00 $0.00 $0.00 ($7.50) ($3.740487) ($7.50)
    Change 0% 0% 0% -2,992.409% -2,992.409% -2,992.409%

    4.5 Разработка реализации процесса

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

    Важно! Бизнес-аналитик завершил формирование процесса для работы с оценщиками. Теперь основная ответственность за проект переходит к архитектору программного обеспечения, который проектирует решение. Мы вернемся к WebSphere Business Integration Modeler, когда ИТ-специалисты будут готовы начать реализацию решения.

    4.5.1 Экспортирование процессов

    Поскольку весь процесс обработки претензий уже функционирует в среде WebSphere MQ Workflow, мы решили свести к минимуму изменения в работающем процессе, внеся лишь небольшие модификации. Вместо вызова выполняемой вручную задачи RequestExternalReports мы теперь вызываем подпроцесс RequestExternalReports. Процесс обработки претензии продолжает функционировать в WebSphere MQ Workflow, а новый подпроцесс будет работать в WebSphere Business Integration Server Foundation.

    В WebSphere Business Integration Modeler есть возможность экспортировать процесс как в виде FDL, для работы с WebSphere MQ Workflow, так и в форме Business Process Execution Language (BPEL), который используется в нескольких системах работы с процессами, в том числе в WebSphere Business Integration Server Foundation.

    Поскольку изменения, внесенные в процесс обработки претензий, были минимальными, специалист по WebSphere MQ workflow решил не экспортировать модифицированный процесс обработки претензий из WebSphere MQ Workflow в виде FDL, а внести необходимые изменения прямо с помощью WebSphere MQ Workflow Buildtime. Обращайтесь к разделу 11.3, "Создание рабочего потока ClaimInvestigation_TOBE" (рис 4.66).

    Данному специалисту не нужно было определять структуру данных ClaimInvestigation на FDL, чтобы перевести процесс ClaimInvestigation из WebSphere MQ Workflow в WebSphere Business Integration Modeler. Было бы удобно экспортировать новые структуры данных из UML в Rational Software Architect в виде FDL, но Rational Software Architect не поддерживает FDL. В WebSphere Business Integration Modeler такая поддержка есть, и специалист по WebSphere MQ Workflow решил использовать Modeler для создания FDL-версии структуры данных. Об этом мы поговорим в лекции 11, "Изменение процесса изучения претензий".

    Зачем импортировать?

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

    Почему не экспортируется в WebSphere MQ Workflow?

  • Новый FDL-код существенно отличается от исходного.

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

  • Информация для размещения не импортируется и не экспортируется вместе с FDL.
  • Изменения процесса, превращение RequestExternalAssessor из локальной задачи в подпроцесс, нужно отменять перед экспортированием FDL. FDL не поддерживает возможности вызова подпроцесса из другой системы работы с процессом.
    •  (рис 4.66) Использование .fdl в WebSphere Business Integration Modeler

    4.5.2 Экспортирование в виде FDL-процесса

    Поскольку в данном сценарии мы не экспортируем процесс изучения претензии из WebSphere Business Integration Modeler, мы написали следующий раздел, чтобы просто показать, как это делается.

    Проверка модели процесса

    Прежде чем мы сможем экспортировать бизнес-процесс ClaimInvestigation_TOBE в FDL, нам нужно привести его в соответствие с той средой, в которую он будет экспортирован, если это необходимо.

  • Скопируйте процесс ClaimInvestigation_TOBE в категорию Claims.
  • Переименуйте ClaimInvestigation_TOBE в ClaimInvestigation.
  • Поскольку RequestExternalReports представляет собой подпроцесс, запускаемый в среде, отличной от WebSphere MQ Workflow, нам нужно рассматривать эту задачу как автоматизированную задачу в процессе ClaimInvestigation. Откройте процесс ClaimInvestigation в редакторе процессов, удалите (кнопка Delete) подпроцесс RequestExternalReports, добавьте (кнопка Add) локальную задачу RequestExternalReports. Заново соедините элементы, как показано на рис 4.67.(рис 4.67) Установление связей в ClaimInvestigation
  • Чтобы проверить соответствие модели нотации FDL, перейдите в режим FDL и в редакторе процессов щелкните мышью по пустой области.Внимание! Чтобы увидеть ошибки, вы должны сделать щелчок мышью в редакторе процессов по открытому процессу. Выбор процесса в дереве проектов не отобразит ошибки в другом процессе, пока вы не откроете этот процесс. В этом режиме действуют некоторые ограничения, специфичные для FDL. За подробной информацией о технологии FDL обращайтесь в информационный центр WebSphere Business Integration Modeler. http://publib.boulder.ibm.com/infocenter/wbihelp/index.jsp?topic=/com.ibm.btools.help.modeler.doc/doc/reference/techmodes/fdl.html
  • Если в процессе возникают какие-нибудь специфичные для FDL ошибки и пре- дупреждения, в дереве проектов вы увидите символ ошибки или предупреждения около имени процесса. На рис 4.68 показаны одинаковые процессы с разными символами в разных технологических режимах.(рис 4.68) Вид дерева с одинаковыми проектами в разных технологических режимахПодробную информацию о каждой ошибке и предупреждении можно видеть в представлении Error (Ошибки). На рис 4.69 показан снимок экрана с предупреждениями, относящимися к процессу ClaimInvestigation. Для каждой ошибки или предупреждения выводится определенная информация:
  • Description (Описание). Краткое описание ошибки или предупреждения.
  • Element name (Имя элемента). Элемент, к которому относится ошибка или предупреждение.
  • Element type (Тип элемента). Тип элемента.
  • Parent name (Элемент-предок). Элемент-предок, к которому относится данный элемент.
  • Patent location (Местоположение элемента-предка). Место, где находится элемент-предок.
  • Error code (Код ошибки). По коду ошибки в информационном центре WebSphere Business Integration Modeler можно найти подробное описание ошибки.
  • Profile (Профиль): В каком профиле вы можете исправить данную проблему.
    •  Можно выполнять сортировку списка, щелкнув мышью по заголовку столбца.(рис 4.69) Представление Error (Ошибки) при экспорте в FDL
  • C помощью фильтра вы можете выводить в представлении Error только те ошибки, которые относятся к конкретному набору элементов модели или имеют опреде- ленный уровень важности. Чтобы задать фильтр, нажмите кнопку окна опций фильтра, показанную на рис 4.69.
  • На рис 4.70 показано окно, в котором устанавливаются опции фильтра для пред- ставления Еrror (Ошибки). Посмотрите, что произойдет, если вы измените фильтр сообщений проекта на Selected element and children (Выбранный элемент и его потомки) и щелкните по процессу в дереве проекта.(рис 4.70) Фильтр для представления Error (Ошибки)
  • Теперь снова измените фильтр на Selected project (Выбранный проект).
  • Мы должны исправить все ошибки в процессе, прежде чем его можно будет экспортировать. У нас ошибок нет. Предупреждения можно игнорировать и продолжить экспортирование процесса.

    • Экспортирование процесса

    Чтобы экспортировать процесс, выполните следующие шаги.

  • Щелкните правой кнопкой мыши по имени процесса в дереве проектов и выберите пункт меню , а затем нажмите Next (Далее). Укажите директорию, в которою процесс должен быть экспортирован, и убедитесь в том, что выбран процесс ClaimInvestigation. Нажмите Finish (Готово).
  • Если ошибок нет, значит, экспорт прошел успешно. Вы можете найти экспортированный файл с именем, соответствующим имени проекта, и расширением .fdl. В нашем случае экспортированный файл будет иметь имя ITSOLGI.fdl.
  • Если при экспорте возникают ошибки, следуйте инструкциям, приведенным в сообщении об ошибке.
    •  (рис 4.71) Мастер экспорта в WebSphere Business Integration Modeler

    Теперь вы можете импортировать файл в WebSphere MQ Workflow Buildtime.

    Соответствия элементов

    В этом разделе мы покажем, как установить соответствия элементов из WebSphere Business Integration Modeler элементам WebSphere MQ Workflow.

    На рис. 4.72 показана первая часть процесса установления соответствий для WebSphere Business Integration Modeler и показаны соответствия процесса процессу WebSphere MQ Workflow. Цифры красного цвета обозначают соответствия "один к одному".

    (рис 4.72) Установление соответствий для ClaimInvestigation: часть 1(a) из 3
  • Вход процесса (1) соответствует узлу Data source (Источник данных) (1).
  • Локальная задача SelectReports (2) соответствует программной задаче SelectReports (2). С этой задачей связывается программа со случайно генерируемым именем. Требования к ролям соответствуют полю Member of roles (Назначения ролей) на закладке Staff2 свойств элемента SelectReports.
  • Элемент Decision (3) соответствует программной задаче Decision (3), с которой связывается программа FMCINTERNALNOOP.
  • Условия выхода (Output conditions) (4) соответствуют условиям перехода от элемента Decision к задачам Map и Map2 соответственно.
  • Элемент Map:2 (5) соответствует программной задаче Map (5). С этой задачей связывается программа со случайно генерируемым именем. Содержимое поля Description элемента Map:2 соответствует полю Description на закладке General (Общие) свойств элемента Map.
  • Элемент Map (6) соответствует программной задаче Map (6). С этой задачей связывается программа со случайно генерируемым именем.
  • Локальная задача RequestExternalReports (7) соответствует программной задаче RequestExternalReports (7). И снова с этой задачей связывается программа со случайно генерируемым именем.
    •

    На рис 4.74 показана вторая часть установления соответствий процесса WebSphere Business Integration Modeler и процесса WebSphere MQ Workflow, показанного на рис 4.75. Цифры красного цвета обозначают соответствия "один к одному".

    (рис 4.74) Установление соответствий для ClaimInvestigation: часть 1(b) из 3(рис 4.73) Установление соответствий для ClaimInvestigation: часть 2(а) из 3(рис 4.75) Установление соответствий для ClaimInvestigation: часть 2(b) из 3
  • Элемент Fork (8) соответствует программной задаче Fork (8), с которой связана программа FMCINTERNALNOOP.
  • Локальная задача UpdateExternalReports (9) соответствует программной задаче UpdateExternalReports (9). С этой задачей связывается программа со случайно генерируемым именем. Обратите внимание, что со следующем элементом не связан коннектор данных.
  • Элемент Merge (10) соответствует программной задаче Merge2 (10), с которой связана программа FMCINTERNALNOOP. Задача Merge2 принимает два входа и три управляющих коннектора. Условием запуска является значение ИСТИНА на всех входящих коннекторах.
  • Элемент Fork (11) соответствует программной задаче Fork2 (11), с которой связана программа FMCINTERNALNOOP.
    •

    На рис 4.76 показана последняя часть установления соответствия процесса WebSphere Business Integration Modeler и процесса WebSphere MQ Workflow, показан- ного на рис 4.77. Цифры красного цвета обозначают соответствия "один к одному".

    (рис 4.77) Установление соответствий для ClaimInvestigation: часть 3(а) из 3(рис 4.76) Установление соответствий для ClaimInvestigation: часть 3(b) из 3
  • Элемент SetClaimStat (12) соответствует программной задаче SetClaimStat (12). С этой задачей связывается программа со случайно генерируемым именем.
  • Локальная задача Merge (13) соответствует программной задаче Merge (13), с которой связана программа FMCINTERNALNOOP. Элемент Merge принимает один вход для данных и два управляющих коннектора. Условием запуска значение ИСТИНА на всех входящих коннекторах (All incoming connectors true).
  • Выход процесса (14) соответствует узлу выхода (Data sink) (11).
  • Узел Stop (15) не импортируется, поскольку не поддерживается в WebSphere MQ Workflow.
    •

    При экспорте из WebSphere Business Integration Modeler информация для размещения не генерируется.

    4.5.3 Экспорт процесса RequestExternalReports в виде процесса BPEL4WS

    Новый бизнес-процесс RequestExternalReports будет выполняться в WebSphere Business Integration Server Foundation. За экспорт процесса в формат BPEL4WS отвечает ИТ-специалист. Бизнес-аналитик эту задачу не выполняет.

    ИТ-специалисту, отвечающему за экспорт процесса RequestExternalReports в BPEL следует прочитать главу 5 книги "BPEL4WS Business processes with WebSphere Business Integration: Understanding, Modeling, Migrating", SG24-6381. В этой главе рассматриваются соответствия между элементами WebSphere Business Integration Modeler и элементами BPEL4WS. Глава 6 упомянутой книги поможет вам понять, какие артефакты экспортируются из WebSphere Business Integration Modeler в BPEL4WS.

    Проверка модели процесса

    Перед экспортом нам нужно проверить процесс RequestExternalReports на соответствие нотации BPEL. Мы снова увидим многочисленные предупреждения, которые можно игнорировать, и восемь ошибок, которые нужно исправить.

    В WebSphere Business Integration Modeler переключитесь в технологический режим BPEL и откройте процесс RequestExternalReports в редакторе процессов. В данном технологическом режиме мы увидим специфичные для BPEL ошибки и предупреждения. Если в модели процесса отсутствует информация, которая является обязательной для BPEL4WS, или если элементы включают в себя объекты и параметры, не поддерживаемые в BPEL4WS, WebSphere Business Integration Modeler выводит список возникающих проблем. Как и в случае с режимом FDL, мы должны исправить эти ошибки перед экспортированием модели, но мы можем игнорировать предупреждения.

    Существует ряд практических методов, которые можно применять в BPEL-режиме, при проверке модели при помощи WebSphere Business Integration Modeler Advanced Edition v5.1.1. Некоторые из них также применимы и к FDL-режиму.

  • Убедитесь в том, что каждый входной критерий соответствует одному и не более чем одному выходному критериюЭто относится и к FDL-режиму.. Иными словами, каждый входной критерий должен запускать один конкретный выходной критерий. Это соответствует WSDL-операции, которая может иметь только одно выходное сообщение. Если вы должны сочетать один входной критерий с несколькими выходными, попробуйте использовать элемент-решение, чтобы смоделировать логику ветвления с исключением.

    С этой проблемой в процессе RequestExternalReports связаны четыре ошибки.

    Совет. Убедитесь, что процесс RequestExternalReports открыт, а все изменения сохранены. Щелкните по сообщению об ошибке - и соответствующий элемент в модели процесса будет выделен цветом, показывая, где находится ошибка. Эти ошибки объясняются тем, что входные критерии локальных задач ManualSelectAssessor и RequestAssessment не связаны ни с одним выходным критерием. Для исправления проблемы переключитесь на пользовательский профиль Advanced, выберите пункт Advanced Output Logic (Дополнительная логика выходов) в представлении Attributes (Атрибуты), выберите пункт Output criteria (Выходной критерий), который вам нужно связать, и поставьте галочки напротив пунктов Input criteria (Входной критерий). Галочки должны быть установлены в обоих полях. На рис 4.78 показаны правильно установленные параметры.(рис 4.78) Параметры окна Advanced Output Logic (Дополнительная логика выходов)
  • Повторите указанные действия для элементов ManualSelectAssessor и RequestAssessment и сохраните процесс. Теперь, после того как мы отфильтруем сообщения об ошибках, у нас должно остаться пять ошибок.
  • Убедитесь, что каждый процесс имеет только один входной критерий и один выходной критерий. Это можно проверить, перейдя на закладку спецификаций в редакторе процессов. Например, чтобы проверить, является ли критерий входа единственным, выберите пункт Input specification (Спецификация входов) $$\to$$ Input Logic (Логика входов). Убедитесь, что в таблице Input settings (Параметры входов) имеется только один критерий входа, как это показано на рис 4.79.(рис 4.79) Параметр критерия входа для процесса
  • Если вы хотите, чтобы для задач и служб WebSphere Business Integration Modeler сгенерировал порт с несколькими операциями, определите для задачи или служ- бы несколько критериев входа. Каждый критерий входа должен быть связан с од- ним и не более чем, одним критерием выхода.
  • Убедитесь, что в модели процесса нет нижестоящих задач, связанных с вышестоя- щими задачами обратной связью, что разрешено в WebSphere Business Integration Modeler, но не разрешено в BPEL. То же относится и к FDL-режиму. Используйте вместо этого цикл while.

    В процессе RequestExternalReports есть одна ошибка такого типа - это выход No элемента-решения .

    (рис 4.80) Нижестоящая задача, связанная с вышестоящейЧтобы устранить эту проблему, мы добавим на схему локальное хранилище (LocalRepository) и соединим выход No элемента Confirmed? со входом этого хранилища, как показано на рис 4.81. Будут добавлены фиктивные данные типа String.(рис 4.81) Измененная часть процесса RequestExternalReportsМы изменим вход Input:2 элемента ManualSelectAssessors так, чтобы он получал данные из хранилища. (Сохраните процесс перед внесением изменений в элемент ManualSelectAssessors). Параметры этого элемента приведены на рис 4.82.(рис 4.82) Входные параметры локальной задачи ManualSelectAssessor
  • Убедитесь, что для связанных объектных входов и выходов двух узлов указаны одинаковые значения минимального и максимального числа элементов. Это также относится к FDL-режиму:
  • объектный выход Задачи1 связан с объектным входом Задачи2;
  • объектный выход Задачи1 имеет минимальное число элементов 3 и максимальное число элементов 5;
  • минимальное число необходимых элементов для объектного входа Задачи2 должно быть равно 3, а максимальное число должно быть равно 5. Иначе будет сгенерирован неверный код BPEL.
    •
  • Для элементов-решений вы должны определить условие для каждой из выходных ветвей. Это также относится к FDL-режиму.

    У нас с этим типом связаны четыре ошибки, которые объясняются тем, что не указаны условия перехода для двух узлов принятия решения. Для исправления проблемы мы добавим к элеме нтам-решениям фиктивный элемент-данные типа String и определим условия, используя Expression Builder. Выполните следующие шаги:

  • Убедитесь, что вы находитесь в режиме Advanced и процесс RequestExternalReports сохранен.
  • Выберите элемент Any Assessor? $$\to$$ Представление Attributes (Атрибуты) $$\to$$ Outputs (Выходы) $$\to$$ Select an output (Выбрать выход) $$\to$$ Associated data (Связанные данные) $$\to$$ String.
  • Выберите пункт Output Branches (Выходные ветви) $$\to$$ Yes (Да) $$\to$$ Details (Подробно) $$\to$$ Contents (Содержание) $$\to$$ Output:2 (Или другое используемое имя) $$\to$$ ).(рис 4.83) Задание условий для выходных ветвей элементов-решений
  • В открывшемся окне редактора выражений выберите First term (Первый член), укажите Modeling artifact (Моделируемый артефакт). Найдите и выберите элемент Input элемента Any Accessor. В поле Operator (Оператор) выберите пункт Is equal to (Равен). В поле Second term (Второй член) укажите Text (Текст), в поле Second term details (Подробнее о втором члене) укажите ).(рис 4.84) Использование Expression Builder для создания условия
  • Возможно, вам понадобится исправить еще какие-то ошибки. Может быть, с некоторыми коннекторами входов и выходов не связаны данные? Поищите незатененные серым цветом отметки входов и выходов во входных и выходных критериях. Преобразуйте их в тип String и заново соедините локальные элементы (рис 4.85).(рис 4.85) Другие ошибки, которые нужно исправить перед экспортом модели в BPEL
  • Когда вы свяжете данные String со всеми соединениями, вы можете увидеть ошибку DBL110014E - mismatched minimum and maximum number of items (Несовпадение минимального и максимального числа элементов). Измените вход элемента RequestAvailability, чтобы минимальное и максимальное число элементов было равно 2.
  • Когда все изменения будут сохранены, снова выполните статический анализ, чтобы убедиться, что все соединения работоспособны.

    • Некоторые элементы модели WebSphere Business Integration Modeler не могут быть преобразованы в BPEL либо из-за того, что они не имеют эквивалентных конструкций в BPEL, либо из-за того, что семантика сходных конструкций из BPEL отличается. Это элементы Notification broadcaster, Notification receiver, Observer, Timer, цикл For, цикл Do-while и глобальное хранилище. Мы не можем использовать эти элементы в BPEL-режиме.

    Экспортирование процесса

    После исправления всех ошибок сохраните процесс. Если ошибок не возникает, мы можем экспортировать процесс в BPEL, даже если остаются предупреждения.

  • Щелкните правой кнопкой мыши по процессу RequestExternalReports в дереве проектов и выберите пункт меню Export (Экспорт).
  • В мастере экспорта укажите пункт WebSphere Business Integration Server Foundation V5.1 (BPEL, WSDL, XSD), как показано на рис 4.86, и нажмите Next (Далее).(рис 4.86) Мастер экспорта WebSphere Business Integration Modeler - шаг 1
  • В следующем окне укажите директорию для экспорта, нажав кнопку Browse (Обзор). Выберите пункт Export Specific objects (Экспорт указанных объектов) и раскройте дерево проектов. Выберите процесс (рис 4.87) Мастер экспорта WebSphere Business Integration Modeler - шаг 2
  • Нажмите Next (Далее), чтобы указать режим выполнения процесса. Выберите Long-running (receive/reply) [Долговременный (получение/ответ)] и нажмите Finish (Готово).
  • Если при экспорте возникают ошибки, следуйте инструкциям в сообщениях об ошибках.
    •

    Теперь вы можете импортировать файлы в WebSphere Studio Application Development Integration Edition для разработки. Обращайтесь к лекции 10, "Создание процесса Request External Reports".

    Примечание. Копия экспортированного кода BPEL находится в директории .\SG24-6636\Modeler\BPEL Export. Существует также zip-файл проекта, содержащего процесс после исправлений, связанных с BPEL, который вы можете импортировать и изучить: .\SG24-6636\Modeler\Projects\PostBPEL.zip.

    4.6 Заключение

    В этой лекции мы показали, как использовать WebSphere Business Integration Modeler для моделирования бизнес-процесса, эмуляции и выполнения экспорта в FDL и BPEL для последующей реализации. Следующий этап - это передача проекта ИТ-архитектору для проектирования системы и выбора архитектуры решения с использованием инструментов от Rational.

    Страницы:

    В этой лекции мы описываем этапы создания и анализа нового бизнес-процесса с помощью WebSphere Business Integration Modeler, выступая в роли бизнес-аналитика.

    Мы рассматриваем следующие темы:

  • введение в моделирование бизнес-процесса;
  • моделирование процесса изучения страховой претензии;
  • эмуляция процесса;
  • разработка реализации процесса.
    •  Внимание! На момент написания этой лекции курса последними версиями WebSphere Business Integration Modeler были 5.1.1.2 patch 3 и Modeler Version 6. Мы настоятельно рекомендуем вам использовать как минимум версию 5.1.1.2 patch 1для совместимости с Rational Software Architect 6.0.0.1. Существует исправление (патч) для переноса моделей с версии 5.1.1.1 в версию 5.1.1.2. Мы еще не тестировали цепочку инструментов для Modeler Version 6. Некоторые схемы в этом курсе были получены в версии 5.1.1.1, и в версии 5.1.1.2 они могут выглядеть немного иначе.

    4.1. Введение в управление бизнес-процессами

    В этом разделе мы познакомим вас с управлением бизнес-процессами и с WebSphere Business Integration Modeler v5 - инструментом для моделирования бизнес-процессов. Мы обсудим, кому, скорее всего, придется использовать данный инструмент, и рассмотрим две его редакции.

    4.1.1 Управление бизнес-процессами

    Управление бизнес-процессами (Business Process Management, BPM) - это концепция непрерывного создания, анализа и совершенствования бизнес-процесса (рис. 4.1).

    (рис 4.1) Непрерывный цикл совершенствования процесса

    Дональд Лайт (Donald Light) в работе "Deriving insurance business value from business process management tools" (см. библиографию) пишет, что BPM-решение, как правило, включает в себя следующие элементы:

  • интегрированную среду разработки (IDE);
  • библиотеку процессов;
  • систему выполнения процессов;
  • средства мониторинга;
  • базу данных выполнения;
  • средства моделирования и оптимизации.
    •

    Интегрированная среда разработки

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

    Библиотека процессов

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

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

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

    Мониторинг

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

    База данных выполнения

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

    Моделирование и оптимизация

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

    4.1.2 Комплект BPM-инструментов от IBM

    Эти элементы BPM-решения сведены вместе в комплект BPM-инструментов от IBM. В книге серии Redbooks под названием "Continuous business process management", SG24-6590, показано, как следует использовать инструменты WebSphere Business Integration, входящие в версию 4 платформы WebSphere, для реализации непрерывного цикла управления бизнес-процессами (рис. 4.2).

    (рис 4.2) Непрерывный цикл управления бизнес-процессом

    BPM-решение в WebSphere версии 4

    Эта версия включает в себя следующие элементы.

    Создание

    IBM WebSphere Business Integration Workbench V4.2.4. Business Modeler - это инструмент для создания бизнес-процесса, публикуемого в виде моделей на языке описания потоков (Flow Definition Language, FDL).

    Кооперация

    IBM WebSphere Business Integration Workbench Server V4.2.4. Business Repository и Web Publisher - это инструменты для донесения бизнес-процесса до других людей.

    Автоматизация

    WebSphere Business Integration Server V4.3 или IBM WebSphere MQ Workflow V3.5 - это рабочие среды для выполнения FDL-моделей.

    Управление

    IBM WebSphere Business Integration Workbench V4.2.4. Business Monitor - это инструмент для мониторинга бизнес-процессов.

    BPM-решение в WebSphere версии 5

    В версии 5 платформы WebSphere BPM-решение было переведено на применение открытых стандартов (использование Eclipse для инструментария, Java 2 Enterprise Edition) для рабочей системы и BPEL для моделирования и выполнения бизнес-процессов. Мы применили для нашего решения версию 5 платформы WebSphere.

    Создание

    WebSphere Business Integration Modeler Advanced Edition V5.1.1.2 - это инструмент, который мы использовали для изменения процесса обработки претензий и создания процесса для работы с внешними оценщиками, а также для оптимизации процессов обработки претензий на основе эмуляции.

    В WebSphere Business Integration Modeler есть функция создания отчетов, которая опрашивает бизнес-процессы и генерирует отчеты, которые можно направлять другим сотрудникам. Мы не использовали эту функцию в нашем примере.

    Как и в других инструментах, основанных на IBM Eclipse, в этом инструменте используется система конкурирующих версий (concurrent version system, CVS) для групповой работы. Мы использовали данный инструмент в автономном режиме, импортируя и экспортируя артефакты из других инструментов. Его также можно установить в качестве дополнения (плагина) к WebSphere Studio Application Development Integration Edition.

    Автоматизация

    После того как мы определили в WebSphere Business Integration Modeler процессы обработки претензий и работы с внешними оценщиками, мы смоделировали все решение, используя Rational Solution ArchitectВ действительности это 6-я версия продукта. Мы решили использовать ее, поскольку она лучше интегрирована с WebSphere Business Integration Modeler, чем Rational XDE $$\text{\texttrademark}$$ или Rational Rose (см. лекцию 5, "Архитектура системы").. На основе этой модели мы определили интерфейсы служб, которые мы собирались использовать для автоматизации операций в BPEL-модели. Затем мы использовали WebSphere Studio Application Development Integration Edition для детализации потоков BPEL для выполнения их в WebSphere Business Integration Server Foundation. Мы также использовали WebSphere MQ Workflow Buildtime для разработки процессов на языке Flow Definition Language (FDL), которые размещаются в WebSphere MQ Workflow. Кроме того, мы использовали Web-Sphere Business Integration Message Broker для маршрутизации и трансформации запросов к службам и WebSphere Application Server для размещения некоторых служб.

    Управление

    Мы не планировали проектировать и создавать решение для мониторинга в сценарии с обработкой претензий. Группа IBM System House Scenario будет создавать решение для мониторинга в следующем году. Это решение будет использовать инфраструктуру типовых событий (Common Event Infrastructure, CEI) и инструменты мониторинга, поддерживающие CEI.

    На данный моментВ версии 6 WebSphere Business Integration Modeler имеется широкая поддержка моделирования бизнес-параметров. существует возможность использовать CEI-монитор, поставляемый с WebSphere Business Integration Server Foundation, для мониторинга событий в потоке BPEL и IBM WebSphere Business Integration Workbench V4.2.4. Business Monitor для мониторинга WebSphere MQ Workflow.

    4.1.3 Зачем нужно моделирование бизнес-процессов

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

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

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

    • Мы использовали модели бизнес-процессов для разных целей, в том числе:

  • для документирования имеющихся процедур;
  • определения требований, предъявляемых к персоналу, системам и функциям;
  • планирования изменений существующих процессов и систем;
  • тестирования и анализа имеющихся и предлагаемых процессов;
  • выявления слабых мест в процессах.
    •

    4.1.4 WebSphere Business Integration Modeler

    Версия 5.1 является совершенно новой реализацией WebSphere Business Integration Modeler. В ней предлагается полное определение предприятия с точки зрения бизнеса, в частности:

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

    По сравнению с WebSphere Business Integration Modeler версии 4.2.4 в WebSphere Business Integration Modeler появились некоторые полезные новые свойства:

  • реализация на основе Eclipse;
  • BPEL-моделирование и поддержка Web-служб;
  • усовершенствованные возможности создания отчетов и выполнения эмуляции;
  • новая метамодель на основе UML2;
  • поддержка групповой работы.
    •  Внимание! Используя этот курс, вы можете создавать процессы в WebSphere Business Integration Modeler, не имея никакого опыта. Бизнес-аналитику, возможно, потребуется больше технической информации о Modeler, чем дается в этом курсе и в информационном центре Modeler. Однако если вы хотите использовать Modeler для создания потоков FDL или BPEL или если вы хотите получить более систематические данные, изучите книгу серии Redbooks под названием "BPEL4WS Business processes with WebSphere Business Integration: Understanding, Modeling, Migrating", SG24-6381, в частности лекцию 5.

    4.1.5 Редакции WebSphere Business Integration Modeler

    Существует две редакции WebSphere Business Integration Modeler. Это редакции Entry и Advanced. В табл. 4.1 перечислены возможности этих двух редакций.

    Свойства WebSphere Business Integration Modeler Entry edition и WebSphere Business Integration Modeler Advanced edition
    Свойства WebSphere Business Integration Modeler entry edition WebSphere Business Integration Modeler advanced edition
    Пользовательские профили Basic, intermediate и advanced Basic, intermediate и advanced
    Технологические режимы Operational Operational, BPEL и FDL
    Групповая работа Да Да
    Эмуляция Нет Да
    Статический и динамический анализ Нет Да
    Генерация отчетов Да Да
    Запросы Да Да
    Базовые шаблоны отчетов (доступность) Да Да
    Печать Да Да
    Импорт и экспорт проектов Modeler Да Да
    Импорт и экспорт файлов с разделителями Да Да
    Импорт ADF Да Да
    Импорт и экспорт XSD Нет Да
    Экспорт UML Нет Да
    Экспорт FDL и BPEL Нет Да
    Импорт FDL Нет Да

    4.2 Использование WebSphere Business Integration Modeler

    В этом разделе мы обсудим применение WebSphere Business Integration Modeler как в контексте ввода нового или измененного процесса в бизнес, так и в контексте разработки процесса в рамках более обширного программного решения.

    4.2.1 Кто применяет WebSphere Business Integration Modeler?

    На рис. 4.3 показаны типичные пользователи WebSphere Business Integration Modeler v5.x.

    (рис 4.3) Пользователи WebSphere Business Integration Modeler v5.x
  • Главными (первичными) пользователями являются бизнес-аналитики (ВА), специалисты по процессам и специалисты по ИТ-процессам.

    Бизнес-аналитики и специалисты по процессам применяют WebSphere Business Integration Modeler для создания бизнес-процессов, выявления возможностей для усовершенствований и оценки окупаемости инвестиций.

    Специалисты по ИТ-процессам (на схеме - корпоративные разработчики) применяют WebSphere Business Integration Modeler для детализации BPEL-процесса перед его экспортированием в инструмент автоматизации процессов.

  • Вторичные пользователи - это консультанты по стратегии и руководители направлений в бизнесе. Они должны понимать модели, создаваемые в WebSphere Business Integration Modeler, чтобы проверить и одобрить финансирование проекта. Мы называем этих пользователей бизнес-кураторами.
  • Другими пользователями WebSphere Business Integration Modeler являются ИТ-архитекторы. Они деляться друг с другом и обращаются к артефактам, созданным в рамках бизнес-модели, таким, как организационные структуры, задачи и роли, относящиеся к задачам в бизнес-процессе.
    •

    4.3 Моделирование процесса изучения претензии

    В этом разделе мы, взяв на себя роль бизнес-аналитика, будем работать с процессом изучения претензии, применяя WebSphere Business Integration Modeler Advanced Edition.

    В данном сценарии процесс изучения страховой претензии был смоделирован и работает как часть процесса обработки претензии WebSphere MQ Workflow компании LGI. Мы экспортировали процесс обработки претензии из WebSphere MQ Workflow и теперь имеем представление процесса изучения претензии на языке описания потоков Flow Definition Language (FDL), с которым начинаем работать.

    4.3.1 Запуск WebSphere Business Integration Modeler

    Если вы запускаете WebSphere Business Integration Modeler в первый раз, откроется мастер QuickStart (Быстрое знакомство). Нажмите Cancel (Отмена). WebSphere Business Integration Modeler запустится в раскладке с двумя панелями и перспективой Business Modeling (Бизнес-моделирование), как показано на рис. 4.4.

    Вы можете переключиться на 4-панельную раскладку, нажав на значок Apply 4-pane layout (Применить 4-панельную раскладку). Отобразятся следующие четыре панели:

  • Редактор процессов.
  • Представление Outline (Схема).
  • Дерево проекта.
  • Представление Attributes (Атрибуты).
    •  (рис 4.4) Двухпанельная раскладка WebSphere Business Integration Modeler

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

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

  • некоторые опции окажутся недоступными;
  • некоторые элементы нотации окажутся недоступными;
  • ранее работоспособная модель может стать неработоспособной, поскольку технологические режимы BPEL и MQ Workflow FDL являются более избирательными и имеют дополнительные правила проверки.
    •

    На рис. 4.5 приводится 4-панельная раскладка.

    (рис 4.5) Четырехпанельная раскладка WebSphere Business Integration Modeler

    4.3.2 Импортирование текущего процесса

    Чтобы импортировать текущий процесс, выполните следующие шаги:

  • В WebSphere Business Integration Modeler выберите пункт меню File (Файл) $$\to$$ Import (Импорт). Появится окно с заголовком Import (Импорт).
  • Выберите пункт WebSphere Business Integration Modeler Import $$\to$$ Next (Далее) $$\to$$ WebSphere MQ Workflow $$\to$$ Next (Далее), и вы увидите страницу WebSphere Business Integration Modeler Import Page, показанную на рис. 4.6.
  • Нажмите кнопку Browse (Обзор), чтобы указать директорию, в которой находится импортированный FDL-файл текущего процесса. У нас есть пример файла, который находится в директории .\SG24-6636\Modeler\Other\ClaimInvestigation_ASIS.fdl в папке дополнительных материалов к этому курсу.
  • Поскольку существующий процесс ClaimInvestigation достаточно простой и содержит только четыре задачи, как показано на рис. 2.4, мы отключили опцию Abstract logic in subprocess (Абстрактная логика в подпроцессе), чтобы Web-Sphere Business Integration Modeler не генерировал для него подпроцессов. Однако если FDL-процесс содержит больше задач и подпроцессов, мы рекомендуем установить эту опцию, чтобы WebSphere Business Integration Modeler мог сгенерировать число узлов, совпадающее с таковым в исходном процессе.
  • Нажмите кнопку New (Новый), чтобы создать новый проект, в который будет импортироваться процесс ClaimInvestigation. Укажите для этого проекта имя ITSOLGI и снимите все остальные опции, как это показано на рис. 4.7.
    •  (рис 4.7) WebSphere Business Integration Modeler Import Page(рис 4.6) Окно создания нового проекта бизнес-моделирования

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

    (рис 4.8) Успешный импорт FDL-процесса ClaimInvestigation

    4.3.3 Анализ имеющегося процесса

    В этом разделе мы изучим, каким образом WebSphere Business Integration Modeler представляет существующий процесс изучения претензии, импортированный из WebSphere MQ Workflow.

    Соответствия элементов

    Изучив проект ITSOLGI в дереве проектов, мы увидим соответствия элементов WebSphere MQ Workflow элементам WebSphere Business Integration Modeler, как показано на рис. 4.9.

    (рис 4.9) Соответствия элементов WebSphere MQ Workflow и WebSphere Business Integration Modeler
  • элементы из раздела Data structures (Структуры данных) импортируются как Business items (Бизнес-элементы) с теми же именами;
  • каталог процессов и процесс импортируются с теми же именами;
  • разделы Persons (Люди) и Roles (Роли) импортируются под теми же именами, но относятся теперь к разделу Resources (Ресурсы);
  • раздел Organizations (Организации) импортируется под тем же именем;
  • раздел Programs (Программы) не импортируется;
  • элементы закладки Network (Сеть) не импортируются.
    •

    Соответствия процессов

    Изучим соответствия процессов в WebSphere MQ Workflow и WebSphere Business Integration Modeler.

  • Исходный узел 1 (рис. 4.10) соответствует входу 1 (рис. 4.11) всего процесса.
  • Задача SelectReports 2 соответствует локальной задаче SelectReports 2.
  • Соответствия данных для двух коннекторов данных, соединяющих элемент SelectReports с элементами RequestExternalReports и SetClaimStat, реализуются в WebSphere Business Integration Modeler элементами Map 3 и 4 соответственно. На рис. 4-12 приводятся детали реализации элемента Map 4. Обратите внимание, что WebSphere Business Integration Modeler игнорирует поле Default value элемента-данных.
    •  (рис 4.11) Отображение процесса изучения претензии в WebSphere MQ Workflow (1)(рис 4.10) Отображение процесса изучения претензии в WebSphere Business Integration Modeler (1)(рис 4.12) Информация о соответствиях данных
  • Задача RequestExternalReports 5 соответствует локальной задаче RequestExternal-Reports 5 в WebSphere Business Integration Modeler.
  • Элемент Decision 6 явным образом используется в WebSphere Business Integration Modeler для двух элементов Control Connectors, связанных с элементом SelectReports в WebSphere MQ Workflow. Условия для двух ветвей выхода соответствуют условиям перехода двух элементов Control Connectors.
    •

    Одно из соответствий условий перехода показано в примерах 4-1 и 4-2.

    (Investigate_DataInput.Claim_DataInput.Status="V") AND (Report_Claim.AssReqDate <> "null")

    Пример 4-1 соответствует примеру 4-2.

    'RootProcessModel.Claim.ClaimInvestigation_ASIS.ClaimInvestigation_ASIS.
Decision.InputObjectPin.Investigate_DataInput.Claim_DataInput.Status'
is equal to "V" AND
'RootProcessModel.Claim.ClaimInvestigation_ASIS.ClaimInvestigation_ASIS.
Decision.InputObjectPin.Report_Claim.AssReqDate' is not equal to "null"

    На рис. 4-13 и 4-14 показана начальная часть процесса:

    (рис 4.14) Отображение процесса изучения претензии в WebSphere MQ Workflow (2)(рис 4.13) Отображение процесса изучения претензии в WebSphere Business Integration Modeler (2)
  • Элемент Fork используется в WebSphere Business Integration Modeler для разделения входа перед элементом UpdateExternalReports.
  • Связь 7 соответствует элементу Data Default Connector 7 в WebSphere MQ Workflow.
  • С выходными данными элемента UpdateExternalReports 8 не ассоциируется в WebSphere Business Integration Modeler никакого бизнес-элемента, поскольку элемент UpdateExternalReports 8 является асинхронной реализацией пользовательского сервера выполнения программ (User-Defined Program Execution Server, UPES).
  • Элемент Merge генерируется в WebSphere Business Integration Modeler для объединения входов 7, 9, 10 в следующий элемент.
    •

    На рис 4.15 и рис 4.16 показана последняя часть процесса. Обратите внимание на рис 4.13 и рис 4.14.

    (рис 4.16) Отображение процесса изучения претензии в WebSphere MQ Workflow (3)(рис 4.15) Отображение процесса изучения претензии в WebSphere Business Integration Modeler (3)
  • Связь 11 в WebSphere Business Integration Modeler соответствует элементу Data Default Connector 11 для элемента SetClaimStat в WebSphere MQ Workflow.
  • Элемент SetClaimStat 12 соответствует локальной задаче SetClaimStat 12. С выходными данными элемента SetClaimStat 12 не ассоциируется в WebSphere Business Integration Modeler никакого бизнес-элемента, поскольку этот элемент является в WebSphere MQ Workflow асинхронной реализацией пользовательского сервера выполнения программ (User-Defined Program Execution Server, UPES).
  • Выходной узел 13 WebSphere MQ Workflow соответствует выходу, обозначенному числом 13 WebSphere Business Integration Modeler.
  • Элемент Stop 14 добавляется в WebSphere Business Integration Modeler автоматически. Узел останова необходим для правильной работы любой эмуляции.
  • Как видно на рис. 2.6, задача RequestExternalReports является задачей, выполняемой вручную. Чтобы убедиться в этом, откройте процесс ClaimInvestigation в редакторе процессов и выберите элемент RequestExternalReports. В представлении Attributes (Атрибуты) перейдите на закладку Resources (Ресурсы).
    •

    На рис. 4.17 показаны соответствия ресурсов WebSphere MQ Workflow (две схемы в верхней части окна) и WebSphere Business Integration Modeler (одна схема в нижней части). Можно видеть, что задача RequestExternalReports требует кадровых ресурсов (Staff) для выполнения роли специалиста по обработке претензий (Claim handler) и относится к организации Claim Department (Отдел претензий). Значения в других полях генерируются автоматически в ходе импорта в WebSphere Business Integration Modeler. Значение в поле Time Required (Необходимое время) можно игнорировать.

    (рис 4.17) Требования к ресурсам: элемент RequestExternalReports в существующем процессе ClaimInvestigation

    4.3.4 Создание планируемого процесса

    Общая схема предполагаемого процесса была спроектирована на семинаре с использованием Microsoft Visio. Она представляет собой небольшую модификацию процесса ClaimInvestigation и новый подпроцесс, называемый RequestExternalReports, заменяющий собой выполняемую вручную задачу RequestExternalReports в процессе ClaimInvestigation.

    В данном разделе мы выполним поэтапную процедуру создания нового подпроцесса RequestExternalReports и изменения существующего процесса изучения претензии, используя рабочее пространство, которое мы только что создали, импортировав процесс из WebSphere MQ Workflow. Но сначала мы рассмотрим весь подпроцесс RequestExternalReports, созданный в Visio, и только потом перейдем к пошаговой процедуре детализации ее в WebSphere Business Integration Modeler.

    Логика планируемого процесса

  • Процесс RequestExternalReports инициируется из процесса ClaimInvestigation и начинается с разделения на две параллельных ветви.
  • В одной ветви создается список оценщиков, которые могут осуществить оценку претензии на основании своего географического положения и знакомства с данным типом автомобилей.
  • В другой ветви извлекается страховой полис клиента, и на основе согласованных в полисе данных определяется ожидаемое время проведения оценки.
    •  (рис 4.18) Процесс RequestExternalReports
  • По завершению выполнения этих задач всем подходящим оценщикам посылаются данные о претензии и требуемый срок проведения оценки. Им предлагается в фиксированный срок ответить, будут ли они выполнять оценку.
  • Далее процесс ожидает ответы, и отклоняет все, которые не уложились в отведенное время ответа.
  • Из списка оценщиков, пожелавших выполнить оценку, выбирается один оценщик на основании нескольких критериев, включая стоимость, качество оценки, надежность и т. п.
  • Если оценщиков, которые могли бы выполнить оценку, не оказывается, управление передается в задачу, выполняемую вручную. Специалист по обработке претензий должен вручную выбрать оценщиков, например расширив географическую область или увеличив время выполнения оценки.
  • Отправляется один запрос на выполнение оценки.
  • Процесс ожидает от оценщика подтверждения согласия на проведение оценки.
  • Оценщик отправляет отчет об оценке.
  • Отчет заносится в систему управления документами, после чего управление возвращается в процесс ClaimInvestigation, чтобы специалист по обработке претензии мог принять решение по претензии.
    •

    Контроль версий

    В WebSphere Business Integration Modeler для управления версиями применяется система конкурентных версий (Concurrent versions system, CVS). За дополнительной информацией о поддержке CVS обращайтесь к разделу Team Support (Поддержка групповой работы) центра информации WebSphere Business Integration Modeler: http://publib.boulder.ibm.com/infocenter/wbihelp/index.jsp.

    В этом курсе мы не будем демонстрировать реализацию CVS для WebSphere Business Integration Modeler. Вместо этого мы дадим разным версиям процесса разные имена: ClaimInvestigation_ASIS и ClaimInvestigation_TOBE, и соответственно каталоги ASIS и TOBEОт as-is (как есть, существующий) и to-be (будущий, планируемый). Примеч. пер .. Структура дерева проекта показана на рис. 4.19. Выполните следующие шаги:

  • Откройте дерево проектов. Щелкните правой кнопкой мыши по элементу ClaimInvestigation process $$\to$$ Rename (Переименовать) и укажите имя ClaimInvestigation_ASIS.
  • Щелкните правой кнопкой мыши по каталогу процесса Claim, выберите пункт меню New (Новый) $$\to$$ Process Catalog (Каталог процесса) и укажите имя ASIS. Будет создан каталог ASIS.
  • Щелкните правой кнопкой мыши по элементу ClaimInvestigation_ASIS, выберите пункт меню Copy (Копировать), щелкните правой кнопкой мыши по каталогу процесса ASIS и выберите пункт меню Paste (Вставить). Элемент ClaimInvestigation_ASIS будет скопирован в каталог ASIS.
  • Повторите шаг 2, чтобы создать еще один каталог - TOBE для бизнес-аналитика.
  • Повторите шаг 3, чтобы скопировать элемент ClaimInvestigation_ASIS в каталог TOBE, и переименуйте его в ClaimInvestigation_TOBE.
    •  (рис 4.19) Переименованные процессы ClaimInvestigation

    4.3.5 Создание нового процесса

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

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

    Для создания процесса RequestExternalReports у нас есть два варианта: создать его с нуля или импортировать презентацию Visio, созданную на семинаре. Мы предлагаем вам презентацию Visio в дополнительных материалах к этому курсу. За информацией о доступе к этим материалам обращайтесь к прил. "А", "Дополнительные материалы".

    Для начала мы покажем, как создать базовый процесс с нуля. Если же вы хотите импортировать процесс, созданный в Visio, обращайтесь к разделу "Вариант 2. Импорт процесса из Visio".

    Вариант 1. Создание процесса с нуля

    Чтобы создать процесс с нуля, выполните следующие шаги: в дереве проекта щелкните правой кнопкой мыши по каталогу TOBE, выберите пункт меню New (Новый) $$\to$$ Process (Процесс), укажите имя процесса - RequestExternalReports и любое его описание, после чего нажмите Finish (Готово). Процесс RequestExternalReports автоматически будет открыт в редакторе процесса. Убедитесь, что вы используете профиль Basic. Удалите узел Start, поскольку процесс запускается из другого процесса.

    Первая часть процесса

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

  • Выберите из палитры необходимые элементы, как показано на рис 4.20(рис 4.20) Процесс RequestExternalReports - часть 1 из 3
  • Мы используем элемент Fork для соединения входа процесса с двумя задачами - ResponsetimeBasedOnPolicy и IdentifyAssessorsResponsetimeBasedOnPolicy - время ответа на основе полиса; IdentifyAssessors - определение оценщиков. Примеч. пер ..Совет. Нажмите на небольшую стрелочку в левом углу значка join/fork/merge (соединение/разделение/слияние) палитры редактора процессов, чтобы переключить используемый элемент.
  • Информацию о каждой задаче можно ввести в поле Description (Описание), показанное на рис. 4.21. Мы также считаем удобным поместить описательную информацию в поле (рис 4.21) Поле описания задачи
  • Мы используем элемент Join (Соединение) для объединения выходных данных элементов ResponsetimeBasedOnPolicy и IdentifyAssessors. Элемент Join имеет следующие свойства:
  • снова соединяет и синхронизирует параллельно выполняющиеся ветви;
  • ожидает, пока каждая из ветвей получит все свои входные данные, а потом посылает выходные данные одновременно;
  • если вы хотите объединить в один вход несколько элементов-данных, вы должны добавить для этого специальную задачу.
    •
  • После того как вы поместите на канву указанные шесть элементов, выберите в процессе пункт Connections (Соединения), а затем щелкните внешний контур процесса. Щелкните в элементе fork по входному соединению, чтобы элемент fork стал первым элементом процесса. Откроется окно, показанное на рис. 4.22. Выберите пункт Input (Вход) в поле (рис 4.22) Выбор входа для процесса
  • Теперь рядом с соединением контура и входа элемента fork отображается значок с надписью String (рис. 4.23).
  • Теперь начнем соединять элементы. Начните с соединения 1 на рис 4.23. Вы увидите окно, показанное на рис 4.24. Выберите пункт Output:String (Выход:String) и нажмите (рис 4.24) Соединение процесса RequestExternalReports с его первым элементом(рис 4.23) Выбор выходного соединения в поле Fork:Source
  • Продолжайте соединять элементы. Вам будут снова предлагаться варианты точки назначения. Всегда выбирайте использование существующего соединения, а не создание нового.
    • Совет. Периодически сохраняйте процесс. Звездочка рядом с именем процесса на соответствующей закладке указывает на то, что процесс не сохранен. При сохранении будет проведена определенная проверка на ошибки. Другие ошибки вы также можете выявить, запустив статический анализ процесса (см. рис. 4.25). (рис 4.25) Проверка процесса на ошибки

    Вторая часть процесса

    Во второй части процесса выполняется выбор между двух вариантов:

  • ручной выбор оценщика, который будет проводить оценку;
  • процесс выбирает оценщика автоматически.
    •

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

    Вторая часть процесса показана на рис. 4.26, где WebSphere Business Integration Modeler переключен в режим Intermediate (Промежуточный), чтобы выводилось больше информации, в частности о режимах принятия решений.

    Совет. Мы рекомендуем вам создавать исходные соединения в базовом режиме (Basic), а затем переключиться в режим Intermediate, чтобы завершить определение критериев входа. В базовом режиме терминалы соединений создаются автоматически, а в промежуточном режиме вам нужно добавлять входные и выходные терминалы при помощи панели атрибутов. (рис 4.26) Процесс RequestExternalReports, часть 2 из 3
  • Мы использовали простой элемент Decision (Решение) с именем Any assessor? (Любой оценщик?), чтобы направлять поток либо к элементу SelectAssessor (Выбор оценщика), либо к элементу ManualSelectAssesor (Ручной выбор оценщика) после выполнения предыдущей задачи AssessorReceiveAndResponse. Если в списке оказывается хотя бы один оценщик, поток направляется к компоненту SelectAssessor, в противном случае - к компоненту ManualSelectAssessor.
  • Мы также добавили компонент Decision (Решение) с именем Confirmed (Подтверждено), чтобы вернуть поток к элементу ManualSelectAssessor, если выбранный оценщик не подтверждает получение запроса на оценку.
  • Мы указали логику ИЛИ (OR) для двух входов каждого из элементов Request-Assessment ManualSelectAssessor, поскольку обе эти задачи могут выполняться, если получен один из входов:
  • Чтобы задать логику входов, выберите пункт Modeling (Моделирование) $$\to$$ User Profile (Пользовательский профиль) $$\to$$ Intermediate (Промежуточный) в панели действий. Выберите пункт ManualSelectAssessor > Attributes View (Представление атрибутов) $$\to$$ Input logic (Логика входов) $$\to$$ Input criteria (Критерий входов) $$\to$$ Add (Добавить). Выберите Input (Вход) из панели доступных ( Available ) входов и перетащите его на панель выбранных ( Selected ) входов, после чего нажмите OK.
  • Повторите процедуру, чтобы добавить Input:2. Закладка логики входов панели атрибутов должна выглядеть так, как показано на рис 4.27(рис 4.27) Панель логики входов для элемента ManualSelectAssessor
  • Удалите первый критерий и очистите панель так, чтобы она выглядела, как по- казано на рис 4.28(рис 4.28) Критерий входов для задачи ManualSelectAssessor
    •  Совет. Ту же функцию можно реализовать при помощи элемента Merge (Слияние).

    Последняя часть процесса показана на рис. 4.29 в базовом режиме. Мы также соединяем элемент StoreReport (Сохранение отчета) с выходом процесса и узлом останова (Stop).

    (рис 4.29) Процесс RequestExternalReports, часть 3 из 3Совет. В данный момент мы можем запустить простую эмуляцию для проверки логики процесса. Можно выявить некоторые типичные ошибки, связанные с преждевременной остановкой. Например, процесс останавливается, если пропущен элемент Merge. Для выполнения эмуляции щелкните правой кнопкой мыши по процессу RequestExternalReports в дереве проекта и выберите пункт меню Simulate (Эмулировать).

    Вариант 2. Импорт процесса из Visio

    Чтобы импортировать схему Visio, вам нужна сохраненная схема Visio в форме XML - файл .vdx.

  • Выберите пункт меню File (Файл) $$\to$$ Import (Импорт) и в окне WebSphere Business Integration Modeler Import нажмите Next (Далее). Выберите в поле Types (Типы) пункт Microsoft Visio (vdx), нажмите Next (Далее) и выберите файл .\SG24-6636\Modeler\Other\RequestExternalReports.vdx из дополнительных материалов, поставляемых с этим курсом.
  • Нажмите Next (Далее) и выберите Page-1. Нажмите Add (Добавить).

    Окно мастера импорта будет выглядеть примерно так, как показано на рис. 4.31. При создании схемы Visio мы выбирали элементы из раздела Visio Business Process diagrams. Большая часть этих элементов уже имеет соответствия среди элементов WebSphere Business Integration Modeler. С помощью мастера импорта вы можете установить соответствия там, где их еще нет.

  • Нажмите Next (Далее) $$\to$$ Finish (Готово), чтобы завершить импортирование. Не обращайте внимания на предупреждения и рассмотрите импортированный процесс в папке Processes (Процессы). Результат показан на рис 4.30(рис 4.30) Процесс RequestExternalReports, импортированный из VisioОбратите внимание, что точки принятия решений не бинарные, а многовариантные.
  • Перенесите поток в каталог TOBE.
    •

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

  • Удалите два стартовых узла и две связи с элементом RequestAvailability.
  • Перетащите на канву элементы Fork и Join.
  • Соедините процесс RequestExternalReports с входным коннектором элемента Fork и задачей StoreReport.
  • Установите связи элементов Fork и Join.
  • Возможно, вы захотите перейти от многовариантных решений к бинарным, чтобы поток был более понятным.
    •

    Проверьте логику входов элементов ManualSelectAssessor и RequestAssessment. В обоих случаях должна использоваться логика OR (ИЛИ).

    (рис 4.31) Соответствие элементов Visio элементам WebSphere Business Integration ModelerСовет. На этом этапе создайте резервную копию своей работы. Функция отмены изменений имеет ограничения, поэтому вы регулярно должны создавать контрольные точки. Для этого существует много способов. Например, вы можете сохранить свою работку как проект WebSphere Business Integration Modeler. Если вам нужно будет выполнить восстановление, вы можете запустить новое рабочее пространство и загрузить в него проект.

    Изменение процесса ClaimInvestigation для вызова процесса RequestExternalAssessor

    Выполните следующие шаги:

  • Откройте проект ClaimInvestigation_TOBE в навигаторе проектов и удалите локальную задачу RequestExternalReports.
  • Перетащите процесс RequestExternalAssessor из навигатора проектов в процесс ClaimInvestigation_TOBE.
  • Добавьте в процесс ClaimInvestigation_TOBE новый элемент, Map (Соответствие):
  • Щелкните правой кнопкой мыши по процессу, выберите пункт меню New (Новый) $$\to$$ Map (Соответствие).
  • Откройте представление Attributes (Атрибуты) соответствия и перейдите на закладку Inputs (Входы). Сделайте двойной щелчок мышью по Associated data (Связанные данные), затем выберите Complex type (Сложный тип) $$\to$$ InvestigateClaim $$\to$$ OK.
  • Перейдите на закладку Outputs (Выходы). Сделайте двойной щелчок мышью по Associated data (Связанные данные), затем выберите Basic type (Базовый тип) $$\to$$ String $$\to$$ OK.
  • Соедините элементы, как показано на рис. 4.32.
    •  (рис 4.32) Добавление подпроцесса RequestExternalReports

    Определение ролей и организационных подразделений

    Чтобы выполнять только что определенные задачи, необходимы дополнительные роли и организационные подразделения. Они заключены на рис. 4.33 в синие рамки. Обратите внимание, что роли включают в себя как автоматизированные службы, так и людей. Это станет важным, когда мы будем использовать эту модель в Rational Software Architect или в Rational Software Modeler.

    Откуда берутся эти роли и организационные структуры? Как узнать на этой стадии определения процесса, какие автоматизированные службы необходимы?

    Бизнес-аналитик работает на семинарах совместно с архитектором решения. Как уже говорилось в разделе 3.2.2, "Области ответственности и разработка по контрактам", архитектура решения разрабатывается параллельно бизнес-процессу, чтобы можно было принимать решения о том, какие задачи следует автоматизировать. В настоящее время инструментарий еще недостаточно интегрирован, чтобы можно было вести одновременную интерактивную разработку бизнес-процесса и архитектуры решения. На семинарах мы использовали традиционные средства создания презентаций для создания исходного бизнес-процесса и предполагаемой архитектуры решения. Этого достаточно, чтобы понять, какие процессы в решении для работы с внешними оценщиками можно автоматизировать и какие роли должны быть добавлены в модель процесса (см. схему на рис. 3-16).

    Ниже мы дадим краткие описания ролей. Добавьте эти роли в рабочее пространство WebSphere Business Integration Modeler.

  • Claim handler (Специалист по обработке претензий) ведет в LGI обычную работу по обработке претензий. Измените при необходимости стандартную почасовую оплату ($15 за час) для этой роли.
  • Assessor (Оценщик) - это роль, которая проводит оценку претензий и посылает отчет об оценке. Оплата - $20 за час.
  • Роли Assessor Management (Управление оценщиками), Business Rules Engine (Система бизнес-правил) и Document Handler (Обработчик документов) представляют собой системы, которые работают автоматически. Мы устанавливаем для них стоимость $10 000 в год.
  • Claim handler Desktop (Рабочее место специалиста по обработке претензий) - это система, которую использует в своей работе специалист по обработке претензий. Стоимость - $10 000 в год.
    •  Совет. Выполнение роли обогащает ресурс, добавляя набор функций, которые ресурс должен иметь или осуществлять. Один ресурс может играть более чем одну роль.

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

  • External Assessors - это организационное подразделение для оценщиков претензий.
    •  Совет. Лучше связывать стоимость с ролями, чем с ресурсами, выделяемыми ролям, если только вы не хотите обозначить стоимость ресурса отдельно. Следует также принимать во внимание различные аспекты, связанные со стоимостью: мы можем определить стоимость в единицу времени для совокупного ресурса, например компьютера, когда он выполняет определенную роль, но не самому определению ресурса. (рис 4.33) Созданные роли и организационные подразделения

    Определение ресурсов для ролей

    Чтобы определить ресурсы для каждой роли, выполните следующие шаги:

  • Начните с добавления двух новых каталогов ресурсов:
  • Выберите в дереве проектов пункт Resources (Ресурсы), затем пункт New (Новый) $$\to$$ Resource Catalog (Каталог ресурсов). Назовите каталог Machines и нажмите Finish (Готово).
  • Повторите процедуру, чтобы создать каталог Timetables.
    •
  • Создайте новое определение ресурса для оценщиков претензий, назвав его External Resources.

    Выберите в дереве проектов пункт Resources (Ресурсы), затем пункт New (Новый) $$\to$$ Resource Definition (Определение ресурсов). Дайте определению имя ExternalResources. Укажите тип individual (Индивидуальный) [вместо bulk (Сово- купный)] и нажмите Finish (Готово).

  • Теперь создайте два компьютера:
  • Выберите пункт меню Machines > New (Новый) > Resource (Ресурс). Выберите Machine в качестве определения данного ресурса ( Associated resource definition ) и назовите ресурс Computer 001 (см. рис 4.34(рис 4.34) Создание нового ресурса-компьютера - шаг 1
  • Добавьте роли, которые этот компьютер будет выполнять, для чего перейдите на закладку Qualifications (Квалификация) и добавьте роли, как показано на рис 4.35(рис 4.35) Роли компьютера Computer 001
  • Чтобы создать второй компьютер (Computer 002), быстрее всего будет скопировать и вставить Computer 001 и изменить роли, как показано на рис 4.36(рис 4.36) Роль компьютера Computer 002
  • Добавьте специалистов по обработке претензий (Claim handlers). Здесь мы покажем, как создать первого такого специалиста:
  • Перейдите к дереву проектов, затем выберите пункт Persons (Люди) $$\to$$ New (Новый) $$\to$$ Resource (Ресурс) $$\to$$ individual (Индивидуальный) $$\to$$ Staff (Персонал). Назовите ресурс Claim handler 001 и нажмите Finish (Готово) (рис 4.37(рис 4.37) Создание нового специалиста по обработке претензий
  • Перейдите на закладку Qualifications (Квалификации), нажмите Add (Добавить) $$\to$$ (рис 4.38) Назначение специалисту по обработке претензий роли Claim handler
  • С помощью копирования/вставки создайте еще 19 специалистов. Если вы используете более раннюю версию, вам нужно выполнять копирование перед каждой вставкой. В исправленной версии WebSphere Business Integration Modeler 5.1.1 это необязательно.
  • Мы предполагаем наличие множества оценщиков (Assessors), которых относим к внешним ресурсам:
  • Перейдите к дереву проектов, затем выберите пункт Persons (Люди) $$\to$$ New (Новый) $$\to$$ Resource (Ресурс) $$\to$$ individual (Индивидуальный) $$\to$$ External Resources (Внешние ресурсы), назовите ресурс Assessor, после чего нажмите Finish (Готово).
  • Мы не указываем здесь стоимость, но назначаем роль (поле Role ) \Resources\Roles\Assessor.
    • Важно! Если какой-то роли не будет назначен индивидуальный или совокупный ресурс и роль будет связана с задачей, эмуляция завершится ошибкой.

    Определение расписаний (timetables)

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

  • Определите расписание (timetable) с именем NormalWorkTime, как показано на рис 4.39(рис 4.39) Расписание NormalWorkTime. Содержимое закладки Recurring time intervals (Периоды времени)
  • Перейдите к дереву проектов, затем выберите пункт Timetables (Расписание) $$\to$$ New (Новый) $$\to$$ Timetable (Расписание). Назовите расписание NormalWorkTime и нажмите Finish (Готово) (рис. 4.39).
  • Откройте расписание и выберите пункт Time interval (Временной интервал) $$\to$$ Remove (Удалить) $$\to$$ Add (Добавить). Введите значение Working hours и нажмите OK. Укажите значение 9:00 AM в поле Start time (Начало работы) и 8 hours в поле duration (Продолжительность). Оставьте заданную по умолчанию дату.
    •
  • Еще два расписания с именами LunchTime (рис 4.40) и Weekend (рис 4.41) определите сходным образом.
  • Сохраните все расписания и вернитесь к NormalWorkTime. Перейдите на закладку Exemption periods (Нерабочее время) и добавьте в качестве нерабочего времени расписания Lunchtime и Weekend.
    • (рис 4.41) Расписание LunchTime. Содержимое закладки Recurring time intervals (Периоды времени)(рис 4.40) Расписание Weekend. Содержимое закладки Recurring time intervals (Периоды времени)

    Таким образом, нормальным рабочим временем будет время с понедельника по пятницу с 9 утра до 5 вечера с получасовым обеденным перерывом. Окончательный вид расписания NormalWorkTime показан на рис 4.42, где рабочие часы обозначены синим цветом, а нерабочие - красным.

    (рис 4.42) Представление Attributes (Атрибуты) расписания NormalWorkTimeСовет. Наведите указатель мыши на представление Attributes (Атрибуты) и нажимайте кнопки мыши, чтобы увеличить или уменьшить увеличение. Указывайте на периоды в расписании, чтобы увидеть имя интервала и его начальный и конечный срок. Обратите внимание, что после того, как мы изменили имя временного интервала с заданного по умолчанию Time interval на Working hours, Lunch и Weekend, мы можем более ясно видеть построение расписания в этом представлении.

    Мы присваиваем расписание NormalWorkTime ролям Claim handler и Assessor. Для отдельных специалистов по обработке претензий или оценщиков расписание отображаться не будет.

    Назначение ресурсов задачам

    После того как роли определены, мы назначаем их задачам в процессе Request-ExternalReports.

  • Выберите задачу ResponseTimeBasedOnPolicy в редакторе процессов, щелкнув по ней мышью в представлении Attributes (Атрибуты), перейдите на закладку Resources (Ресурсы), раскройте пункт Role requirements (Необходимые роли) (если он еще не раскрыт), нажмите кнопку Add (Добавить), укажите данные в соответствии с таблица 4.2.(рис 4.43) Указание ролей для задачи ResponseTimeBasedonPolicy
  • Измените значение в поле Name (Имя) на что-нибудь более описательное. Это имя будет использоваться, если архитектор решения применяет схемы деятельности в Rational Software Architect. Задачи группируются по столбцам с использованием этого имени. Для начала можно использовать здесь то же имя, которое имеет роль.
    •  Совет. Вы можете перетаскивать ресурсы из дерева проектов прямо на задачу. Но вам нужно будет открыть каждую задачу и убедиться в том, что требования по необходимым ролям выполнены.

    Также определите организационное подразделение для задач, используя данные в таблица 4.2.

    (рис 4.44) Пример назначенных для задачи ресурсов и организацийСовет. Поле Time required for Resources (Время, необходимое для ресурсов) используется для вычисления стоимости определенных ресурсов при эмуляции. Это значение отличается от значения Time required to finish task (Время, необходимое для завершения задачи), которое вы можете указать при выполнении эмуляции.
    Параметры назначения задачам ресурсов и организационных подразделений
    Задача Роль Необходимое время Количество Определение ресурса Организация
    ResponseTimeBasedOnPolicy BusinessRules Engine 1 секунда 1 Machine Claim Department
    IdentifyAssesors AssessorManagement 1 секунда 1 Machine Claim Department
    RequestAvailability Assessor 2 минуты 1 External Resource External Assessors
    SelectAssessor Business Rules Engine 1 секунда 1 Machine Claim Department
    ManualSelectAssessor Claim handler 2 минуты 1 Staff Machine Claim Department
    Claim handler Desktop 2 минуты 1
    RequestAssessment Assessor 1 секунда 1 External Resource External Assessors
    AssessorSendReport Assessor 1 час 1 External Resource External Assessors
    StoreReport Document Handler 1 секунда 1 Machine Claim Department

    Вы также можете назначать задачам индивидуальные или совокупные ресурсы. При запуске задачи будет производиться выделение всех назначенных ресурсов. Например, мы назначили роль Claim handler количеством 2. Также мы назначили этой же задаче ресурс Claim handler 001, поэтому выполнять эту задачу будут три индивидуальных специалиста по обработке претензий. Два из них относятся к требованию по необходимым ролям, и они выделяются динамически, и еще один относится к требованию индивидуального ресурса, и это фиксированный ресурс Claim handler 001.

    Определяя критерий требования к индивидуальным ресурсам, вы заставляете проводить выделение ресурсов динамически. В этом случае значение в столбце индивидуального ресурса должно быть установлено в Person или в Staff, как это показано на рис 4.17.

    Просмотр всего процесса в Swimlane

    Нажав на кнопку Launch Swimlane Viewer (Запустить средство просмотра Swimlane) на палитре, как показано на рис 4.45, вы получаете возможность просмотреть схему процесса в формате swimlane, с сортировкой по ролям, ресурсам, организационным подразделениям или местоположению.

    (рис 4.45) Палитра WebSphere Business Integration Modeler

    На рис 4.46 показан вид процесса в Swinlane с сортировкой по ролям.

    (рис 4.46) Вид процесса в Swinlane с сортировкой по ролям

    4.3.6 Возможности, интересные для бизнес-аналитика

    Анализ модели процесса - это один из главных этапов цикла разработки модели. WebSphere Business Integration Modeler предоставляет различные аналитические функции, которые позволяют извлекать из моделей различные типы важной бизнес-информации.

    Существует два типа анализа - статический анализ и создание отчетов.

  • Статический анализ осуществляется на основе информации из модели. Например, мы можем использовать параметр Qualified Resources for Roles (Связанные с ро- лями ресурсы), чтобы узнать, сколько ресурсов было выделено определенным ролям. Для этого нужно щелкнуть правой кнопкой мыши в любом месте дерева проектов и выбрать пункт меню Static Analysis (Статический анализ) $$\to$$ Resource Analysis (Анализ ресурсов) $$\to$$ Qualified Resources for Role (Ресурсы, выделенные роли). В открывшемся окне выберите пункт Select all (Выбрать все), если вы хотите увидеть все ресурсы, а затем нажмите .(рис 4.47) Часть результатов анализа ресурсов, выделенных ролям
  • Динамический анализ выполняется на основе результатов эмуляции процесса, чтобы получить больше сведений. Существует четыре типа таких анализов:
  • Совокупный анализ ( Aggregated Analysis ). Дает сведения об операциях и ресурсах, используемых во всех экземплярах процесса, сгенерированных при эмуляции.
  • Анализ процесса ( Process Analysis ). Выполняется суммарный анализ по экземплярам процесса с выводом данных:
  • прецедентах процесса (process cases);
  • экземплярах процесса (process instances) сгенерированных в ходе эмуляции, а также показывается вероятность возникновения каждого прецедента процесса.
    •
  • Сравнительный анализ процессов (Process comparison analysis). Сравнивается средневзвешенная величина результатов анализа для двух эмулированных процессов, использующих одинаковые входные параметры.
  • Запросы (Queries). Запросы возвращают данные об элементах модели, относящихся к одному указанному типу.

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

    В категории Queries (Запросы) дерева проектов есть 25 готовых запросов. Вы также можете создавать новые запросы.

  • Отчеты (Reports) - это структурированное представление информации, относящейся к модели или к результатам анализа эмуляции процесса:
  • WebSphere Business Integration Modeler предлагает всего 95 типов шаблонов отчетов в категориях, относящихся к базовому профилю (Basic), промежуточному профилю (Intermediate) и усложненному профилю (Advanced), а также к вспомогательным отчетам (Collateral Reports);
  • вы можете генерировать отчеты по запросам, статическому или динамическому анализу;
  • вы можете просматривать отчеты в интерактивном режиме в WebSphere Business Integration Modeler, распечатывать их и экспортировать в различные файловые форматы.

    • 4.4 Эмуляция процесса

    После создания модели бизнес-процесса мы можем выполнить ее эмуляцию в WebSphere Business Integration Modeler, чтобы оценить ее производительность и внести соответствующие корректировки.

    Если вы хотите использовать здесь готовую модель, создайте новый проект или новое рабочее пространство и импортируйте файл .\SG24-6636\Modeler\Projects\ PreBPEL.zip. Результаты эмуляции находятся в файле .\SG24-6636\Modeler\Projects\ Simulation Results.zip. Обращайтесь к прил. "А", "Дополнительные материалы".

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

    4.4.1 Создание эмуляционного снимка

    Сейчас мы можем запустить эмуляцию для процесса RequestExternalReports.

  • Щелкните правой кнопкой мыши по модели процесса в дереве проектов и выберите пункт меню Simulate (Эмуляция). Будет создан эмуляционный снимок процесса (simulation snapshot), показанный на рис 4.48.(рис 4.48) Эмуляция процессаЭтот снимок содержит:
  • копию бизнес-процесса;
  • копию всех элементов модели в проекте на данный момент времени;
  • набор локальных настроек атрибутов эмуляции, показанный на рис 4.49.(рис 4.49) Локальные атрибуты эмуляции в эмуляционном снимке
    •  Примечание. Многие значения локальных настроек эмуляции происходят от глобальных параметров эмуляции. Настройки эмуляции конкретного процесса и задачи также происходят от локальных настроек эмуляции. Однако для эмуляции берутся значения, специально заданные для конкретного процесса или задачи.
  • Щелкнув мышью по пустой области снимка процесса в редакторе эмуляции, показанном на рис 4.50, вы откроете настройки эмуляции, заданные для всего процесса (рис 4.51).(рис 4.51) Снимок процесса в редакторе эмуляции(рис 4.50) Настройки эмуляции для всего процесса
  • Кроме того, мы можем указать атрибуты эмуляции задачи, выделив эту задачу. На рис 4.52 показаны атрибуты эмуляции задачи IdentifyAssessors. Они дополняют собой те атрибуты, которые были определены в настройках эмуляции процесса.(рис 4.52) Параметры эмуляции для задачи
  • Проверьте значения на других закладках параметров эмуляции процесса. В частности, внесите изменения в закладку Resources (Ресурсы), чтобы сюда включались только те ресурсы, которые мы хотим использовать при эмуляции (рис 4.53).(рис 4.53) Выбор ресурсов для эмуляции

    • 4.4.2 Определение значений для эмуляции

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

  • Перейдите на закладку Inputs (Входы) представления Attributes (Атрибуты) параметров эмуляции процесса (рис 4.51). Выберите строку, в которой отображаются входные данные. Окно будет выглядеть примерно так, как показано на рис 4.54:(рис 4.54) Параметры создания метки
  • Мы можем выбрать вариант Time trigger (Временной триггер), если нужно, чтобы эстафеты поступали с определенными интервалами, или Random time trigger (Триггер случайного срабатывания), если нужно, чтобы эстафеты поступали случайным образом.
  • При выборе варианта Random time trigger (Триггер случайного срабатывания) мы можем выбрать определенное распределение.
  • При выборе варианта Time trigger (Временной триггер) мы можем указать начальный момент создания эстафеты и Recurring time interval for bundle creation (Периодичность создания пакетов).
  • При указании параметра Recurring time interval for bundle creation (Периодичность создания пакетов) указывается время проведения эмуляции. Например, мы указываем:
  • Number of tokens per bundle (Количество эстафет в комплекте): 2;
  • Total number of tokens (Общее число эстафет): 20;
  • Recurring time interval for bundle creation (Периодичность создания пакетов): 3 минуты;
  • следовательно, период эмуляции составляет (20/2) * 3=30 минут.
    •  Совет. Хорошей практикой является до изменения любых параметров всегда запускать эмуляцию всего процесса, указывая число эстафет равным 1. Таким образом, вы можете проверить правильность логики процесса при сохранении минимального времени эмуляции.
  • Чтобы предсказать объем поступления претензий, мы будем использовать данные из реальной жизни, которые показывают, что в год в среднем поступает 1.5 претензии на 100 полисов автострахования. Для объединенной компании это даст нам следующий ожидаемый объем поступления претензий:
  • 6 000 000 * 1.5/100 = 90 000 претензий в год.
  • предполагая, что в году 250 рабочих дней, получаем 90 000/250 = 360 претензий в день;
  • предполагая, что оценка требуется для 70% претензий, получаем 360 * 70% = 252 оценки в день;
  • теперь мы можем получить периодичность создания пакетов: 8 * 60/252 = 1 минута 54 секунды, где количество эстафет в пакете = 1.

    • Установите 1-часовую обработку претензий на основе данных, указанных в шаге 2, чтобы длительность эмуляции была приемлемой. При таких данных эмуляция занимает около 5 минут на 2 ГГц Intel $$\text{\textregistered}$$ Pentium $$\text{\textregistered}$$ IBM Mseries Thinkpad (см. рис 4.55).

    (рис 4.55) Параметры создания эстафет для симуляции 1-часовой работы

    Указание продолжительности для каждой задачи

    Для каждой задачи, входящей в процесс, нужно заполнить в эмуляционном снимкеНачиная с WebSphere Business Integration Modeler 5.1.1.2 эти значения можно задавать как в модели, так и в эмуляционном снимке. Это удобно при работе с несколькими эмуляционными снимками. два поля (рис 4.56):

    (рис 4.56) Требования к ресурсу
  • Resource wait time (Время ожидания ресурса).

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

  • Processing time (Время обработки).

    Это время, которое требуется ресурсу для выполнения задачи. Сумма времени обработки и времени ожидания ресурса иногда называется в планировании проекта использованным временем (elapsed time).

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

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

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

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

    В других случаях в этих двух полях указываются разные значения. Например, в задаче RequestAvailability наша система посылает запросы всем подходящим оценщикам и ожидает от них ответ, показывающий, доступны они или нет. Может случиться так, что за несколько часов запрос никто не увидит. Однако после того как оценщик увидит запрос, ему нужно лишь несколько минут, чтобы просмотреть свой график работы и сообщить данные о своей готовности. В данном случае мы устанавливаем параметр Time required to finish task (Время, необходимое для выполнения задачи) (это время равно 4 часам), в то время как параметр Time required (Необходимое время) соответствует времени, равному 2 минутам.

    В табл. 4.3 перечислены параметры времени для задач. Введите эти числа в эмуляционный снимок, как показано на рис 4.56.

    Параметры продолжительности выполнения задачи, устанавливаемые для эмуляции
    Задача Время обработки Время, необходимое роли Ресурс
    ResponseTimeBased OnPolicy 1 секунда 1 секунда Business Rules Engine
    IdentifyAssesors 1 секунда 1 секунда AssessorManagement
    RequestAvailability 4 часа 0Указав здесь 0, мы не учитываем в этой эмуляции время и стоимость работы оценщика в задаче RequestAvailability. Assessor
    SelectAssessor 1 секунда 1 секунда Business Rules Engine
    ManualSelect Assessor 2 минуты 2 минуты Claim handler
    2 минуты 2 минуты Claim handler Desktop
    RequestAssessment 1 час 0Указав здесь 0, мы не учитываем в этой эмуляции время и стоимость работы оценщика в задаче RequestAssessment. Assessor
    AssessorSendReport 2 дня 0Указав здесь 0, мы не учитываем в этой эмуляции время и стоимость работы оценщика в задаче AssessorSendReport. Assessor
    StoreReport 1 секунда 1 секунда Document Handler

    Указание выходов для элементов Decision (Решение)

    Для элементов Decision (Решение) мы указываем вероятность для каждого типа выхода, как показано в табл. 4.4.

    Вероятности для выходов элемента Decision
    Элемент Decision Вероятность ответа "Да" Вероятность ответа "Нет"
    Any assessor? 90% 10%
    Confirmed? 95% 5%

    Параметры, приведенные в табл. 4.4, предполагают следующую ситуацию:

  • Существует 90%-я вероятность того, что хотя бы один оценщик будет доступен. Существует 10%-я вероятность того, что доступных оценщиков не окажется и, следовательно, специалисту по обработке претензий придется назначать его самому.
  • Существует 95%-я вероятность того, что оценщик, оказавшийся доступным, сможет выполнить оценку. Существует 5%-я вероятность того, что оценщик не сможет выполнить оценку из-за исключительных обстоятельств, например несчастного случая.
    •

    Теперь мы укажем в поле Method of selecting an output path (Метод выбора пути выхода) значение Based on probabilities to single path (Один путь на основе вероятности), как показано на рис 4.57.

    (рис 4.57) Снимок экрана с параметрами логики выходов для элемента Decision

    4.4.3 Запуск эмуляции

    Чтобы запустить эмуляцию, переключитесь на Control Panel (Панель управления) и нажмите кнопку Start (Пуск), как показано на рис 4.58.

    (рис 4.58) Панель управления эмуляциейСовет. Если вы не можете найти панель управления, выберите пункт меню Window (Окно) $$\to$$ Show View (Показать представление) $$\to$$ Control Panel (Панель управления) в главном меню.

    Мы можем всегда установить паузу, остановить эмуляцию или выполнить ее пошагово, нажимая соответствующие кнопки на панели управления.

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

    (рис 4.59) Анимация при эмуляции

    После завершения эмуляции ее результат сохраняется в дереве проектов, как показано на рис 4.60. Различать результаты разных эмуляций можно по времени их завершения.

    (рис 4.60) Результаты эмуляции, сохраненные в дереве проектовСовет. Если эмуляция останавливается и вы видите сообщение о том, что для завершения эмуляции не хватает ресурсов, то при этом имеются в виду ресурсы эмуляции, а не проблема в системе. Для процесса необходимо больше ресурсов. Возможно, вы сконфигурировали что-то неверно. Проверьте следующие возможности:
  • Максимальное время ожидания слишком мало и не позволяет эмуляции завершиться.
  • Ресурс Assessor относится к внешним ресурсам.
  • Для операций, выполняемых оценщиками, в поле Organization указано External Resources, а не Person или Staff.
    •

    4.4.4 Эмуляция всего процесса изучения претензии

    Для сравнения нам понадобится эмулировать процессы ASIS и TOBE.

  • Эмуляция процесса ClaimInvestigation_ASIS.

    Перед созданием эмуляционного снимка укажите время ручной обработки задачи RequestExternalReports равным 30 минутам на закладке Resources (Ресурсы) локальной задачи InvestigateClaim.

  • Эмуляция процесса ClaimInvestigation_TOBE.

    На этот раз укажите 360 претензий в день, из которых 70% требуют оценки.

    •

    Существует два способа выполнения эмуляции всего процесса ClaimInvestigation_TOBE, содержащего подпроцессы.

    Примечание. Нельзя провести оценку конкретного подпроцесса. Однако вы можете выбрать опцию, позволяющую указать, нужно ли оценивать все подпроцессы, включая те, содержимое которых неполно. Вы можете указать вариант No (Нет) для опции Evaluate all subprocesses (Оценивать все подпроцессы) в атрибутах эмуляции процесса, а также можете указать значение по умолчанию для этого атрибута как локального или как глобального параметра. Это означает, что эмуляция будет пропускать подпроцесс.
  • Укажите значения для всех подпроцессов на основании предыдущих эмуляций и эмулируйте только новый процесс.Примечание. Хорошей отправной точкой для эмуляции процесса TOBE является проект .\SG24-6636\Modeler\Projects\Claim preBPEL.zip или .\SG24-6636\Modeler\projects\Parms Set. Последний представляет собой набор параметров эмуляции процесса RequestExternalReports, поэтому нам нужно будет только установить параметры эмуляционного снимка ClaimInvestigation_TOBE. Откройте эмуляционный снимок в редакторе эмуляций и укажите на закладке General (Общие) представления Attributes (Атрибуты) в поле Evaluate all (Оценить все) значение No:
  • Выберите в редакторе эмуляции подпроцесс RequestExternalReports и укажите на закладке General (Общие) в поле Time required to finish this task (Время, необходимое для завершения задачи) средневзвешенное значение времени выполнения цикла процесса (weighted average Process cycle time), которое можно получить в результате динамического анализа результатов предыдущих эмуляций. Например, 2 дня 5 часов и 7 минут.
  • Выберите в редакторе эмуляции подпроцесс RequestExternalReports и укажите на закладке Cost and revenue (Стоимость и доход) в поле Cost per execution of the task (Стоимость одного выполнения задачи) средневзвешенное значение общей стоимости (weighted average total cost) для процесса RequestExternalReports (например, $0.105).
    •
  • Выполните эмуляцию процесса и всех подпроцессов.

    Оставьте в поле Evaluate all Subprocesses (Оценить все подпроцессы) на закладке General (Общие) представления Attributes (Атрибуты) значение Yes (Да):

  • Щелкните правой кнопкой мыши по процессу ClaimInvestigation и выберите пункт меню Expand All (Раскрыть все) (рис. 4.61);
  • Выберите задачи в процессе RequestExternalReports и установите для них параметры эмуляции, как это делалось ранее.
    • (рис 4.61) Раскрытие подпроцессов в редакторе эмуляции

    4.4.5 Анализ результатов

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

    (рис 4.62) Последние результаты по экземплярам процесса после эмуляции

    На закладке Tasks (Задачи) мы получаем стоимость по каждой задаче в каждом экземпляре процесса. На рис 4.63 показана стоимость задач в экземпляре процесса ClaimInvestigation_ASIS.

    (рис 4.63) Последние результаты по задачам после эмуляции

    На закладке Connections (Соединения) показаны эстафеты, переданные в каждом соединении.

    Динамический анализ результатов эмуляции

    На основе сохраненных результатов эмуляции мы можем выполнить динамический анализ. Щелкнув правой кнопкой мыши по результатам эмуляции в дереве проектов и выбрав пункт Dynamic Analysis (Динамический анализ), вы можете увидеть различные типы динамического анализа. Ниже мы приводим некоторые из выполненных нами анализов.

  • Activity Resource Allocation (Ресурсы, назначенные задачам). Показывает ресурсы, выделенные для каждой задачи. На рис 4.64 показаны ресурсы, выделенные задачам в процессе RequestExternalReports.(рис 4.64) Анализ: ресурсы, выделенные задачам в процессе RequestExternalReports
  • Resource Utilization Analysis (Анализ использования ресурсов). Показывает все ресурсы, которые были выделены в ходе эмуляции. В табл. 4.5 для примера показан один из таких ресурсов, Claim handler 001.
    Пример анализа использования ресурсов
    Claim handler 001
    Allocated from (выделялся в период с) December 6, 2004 3:14:00 PM GMT
    Allocated to (выделялся в период по) December 6, 2004 3:16:00 PM GMT
    Allocating process instance (экземпляр процесса, для которого был выделен) RequestExternalReports 39
    Allocating activity (задача, для которой был выделен) ManualSelectAssessor
    Allocating activity start time (начало выполнения задачи, для которой был выделен) December 6, 2004 3:14:00 PM GMT
    Quantity allocated (количество) 1
    Allocation duration (продолжительность) 2 minutes
    Shortage duration (нехватка времени) 0 seconds
    Allocation cost (стоимость выделения ресурса) $0.50
  • Process cost analysis (Анализ стоимости процесса). Выполняется применительно к процессу RequestExternalReports.
    •

    Как показывают результаты в табл. 4.6, существует четыре возможных прецедента (case) выполнения процесса RequestExternalReports. Это объясняется тем, что процесс имеет две точки принятия решения. Каждый прецедент имеет определенную вероятность возникновения. Средневзвешенное значение (Weighted average) стоимости для всего процесса составляет 0.080866$Может быть и более четырех прецедентов, если в каком-нибудь экземпляре элемент "Confirmed?" будет выполнен в цикле несколько раз..

    Анализ стоимости процесса для RequestExternalReports
    Имя прецедента Вероятность Доход Выполнение Простой Стоимость выделения ресурсов Итого
    Case 1 85.50% $0.00 $0.00 $0.00 $0.0013 $0.001
    Case 2 9.50% $0.00 $0.00 $0.00 $0.54 $0.539
    Case 3 0.48% $0.00 $0.00 $0.00 $1.078 $1.077
    Case 4 4.28% $0.00 $0.00 $0.00 $0.54 $0.539
    Weighted average $0.00 $0.00 $0.00 $0.081 $0.081
  • Activity cost analysis (Анализ стоимости для задачи). Выполнялся для процесса ClaimInvestigation_ASIS. Особый интерес для нас представляла задача Request- ExternalReports. Результаты показаны в табл. 4.7.
    •

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

    Анализ стоимости выполнения задачи RequestExternalReports в процессе InvestigateClaims_ASIS
    Средний доход Средняя стоимость выполнения Средняя стоимость простоя Средняя стоимость выделения ресурсов Средняя общая стоимость Средняя прибыль
    $0.00 $0.00 $0.00 $7.50 $7.50 ($7.50)
  • Process cost comparison analysis (Сравнительный анализ стоимости процес- сов). Выполняется для результатов двух эмуляций - ClaimInvestigation_ASIS и ClaimInvestigation_TOBE.

    После выполнения эмуляций щелкните правой кнопкой мыши по сохраненному результату эмуляции в дереве проектов и выберите пункт меню Dynamic analysis (Динамический анализ) $$\to$$ Process comparison analysis (Сравнительный анализ процессов) в появившемся окне Simulation results (Результаты эмуляции) (рис 4.65), после чего выберите эмуляцию для сравнения и нажмите OK.

    •  (рис 4.65) Окно выбора результата эмуляции для сравнительного анализа процессов

    Результаты показаны в табл. 4.8.

    Результаты анализа стоимости процессов
    Процесс Доход Стоимость выполнения Стоимость простоя Стоимость выделенных ресурсов Общая стоимость Прибыль
    ClaimInvestigation_TOB E $0.00 $0.00 $0.00 $0.250634 $0.250634 ($0.250634)
    ClaimInvestigation_ASIS $0.00 $0.00 $0.00 $7.750634 $7.750634 ($7.750634)
    Difference $0.00 $0.00 $0.00 ($7.50) ($3.740487) ($7.50)
    Change 0% 0% 0% -2,992.409% -2,992.409% -2,992.409%

    4.5 Разработка реализации процесса

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

    Важно! Бизнес-аналитик завершил формирование процесса для работы с оценщиками. Теперь основная ответственность за проект переходит к архитектору программного обеспечения, который проектирует решение. Мы вернемся к WebSphere Business Integration Modeler, когда ИТ-специалисты будут готовы начать реализацию решения.

    4.5.1 Экспортирование процессов

    Поскольку весь процесс обработки претензий уже функционирует в среде WebSphere MQ Workflow, мы решили свести к минимуму изменения в работающем процессе, внеся лишь небольшие модификации. Вместо вызова выполняемой вручную задачи RequestExternalReports мы теперь вызываем подпроцесс RequestExternalReports. Процесс обработки претензии продолжает функционировать в WebSphere MQ Workflow, а новый подпроцесс будет работать в WebSphere Business Integration Server Foundation.

    В WebSphere Business Integration Modeler есть возможность экспортировать процесс как в виде FDL, для работы с WebSphere MQ Workflow, так и в форме Business Process Execution Language (BPEL), который используется в нескольких системах работы с процессами, в том числе в WebSphere Business Integration Server Foundation.

    Поскольку изменения, внесенные в процесс обработки претензий, были минимальными, специалист по WebSphere MQ workflow решил не экспортировать модифицированный процесс обработки претензий из WebSphere MQ Workflow в виде FDL, а внести необходимые изменения прямо с помощью WebSphere MQ Workflow Buildtime. Обращайтесь к разделу 11.3, "Создание рабочего потока ClaimInvestigation_TOBE" (рис 4.66).

    Данному специалисту не нужно было определять структуру данных ClaimInvestigation на FDL, чтобы перевести процесс ClaimInvestigation из WebSphere MQ Workflow в WebSphere Business Integration Modeler. Было бы удобно экспортировать новые структуры данных из UML в Rational Software Architect в виде FDL, но Rational Software Architect не поддерживает FDL. В WebSphere Business Integration Modeler такая поддержка есть, и специалист по WebSphere MQ Workflow решил использовать Modeler для создания FDL-версии структуры данных. Об этом мы поговорим в лекции 11, "Изменение процесса изучения претензий".

    Зачем импортировать?

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

    Почему не экспортируется в WebSphere MQ Workflow?

  • Новый FDL-код существенно отличается от исходного.

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

  • Информация для размещения не импортируется и не экспортируется вместе с FDL.
  • Изменения процесса, превращение RequestExternalAssessor из локальной задачи в подпроцесс, нужно отменять перед экспортированием FDL. FDL не поддерживает возможности вызова подпроцесса из другой системы работы с процессом.
    •  (рис 4.66) Использование .fdl в WebSphere Business Integration Modeler

    4.5.2 Экспортирование в виде FDL-процесса

    Поскольку в данном сценарии мы не экспортируем процесс изучения претензии из WebSphere Business Integration Modeler, мы написали следующий раздел, чтобы просто показать, как это делается.

    Проверка модели процесса

    Прежде чем мы сможем экспортировать бизнес-процесс ClaimInvestigation_TOBE в FDL, нам нужно привести его в соответствие с той средой, в которую он будет экспортирован, если это необходимо.

  • Скопируйте процесс ClaimInvestigation_TOBE в категорию Claims.
  • Переименуйте ClaimInvestigation_TOBE в ClaimInvestigation.
  • Поскольку RequestExternalReports представляет собой подпроцесс, запускаемый в среде, отличной от WebSphere MQ Workflow, нам нужно рассматривать эту задачу как автоматизированную задачу в процессе ClaimInvestigation. Откройте процесс ClaimInvestigation в редакторе процессов, удалите (кнопка Delete) подпроцесс RequestExternalReports, добавьте (кнопка Add) локальную задачу RequestExternalReports. Заново соедините элементы, как показано на рис 4.67.(рис 4.67) Установление связей в ClaimInvestigation
  • Чтобы проверить соответствие модели нотации FDL, перейдите в режим FDL и в редакторе процессов щелкните мышью по пустой области.Внимание! Чтобы увидеть ошибки, вы должны сделать щелчок мышью в редакторе процессов по открытому процессу. Выбор процесса в дереве проектов не отобразит ошибки в другом процессе, пока вы не откроете этот процесс. В этом режиме действуют некоторые ограничения, специфичные для FDL. За подробной информацией о технологии FDL обращайтесь в информационный центр WebSphere Business Integration Modeler. http://publib.boulder.ibm.com/infocenter/wbihelp/index.jsp?topic=/com.ibm.btools.help.modeler.doc/doc/reference/techmodes/fdl.html
  • Если в процессе возникают какие-нибудь специфичные для FDL ошибки и пре- дупреждения, в дереве проектов вы увидите символ ошибки или предупреждения около имени процесса. На рис 4.68 показаны одинаковые процессы с разными символами в разных технологических режимах.(рис 4.68) Вид дерева с одинаковыми проектами в разных технологических режимахПодробную информацию о каждой ошибке и предупреждении можно видеть в представлении Error (Ошибки). На рис 4.69 показан снимок экрана с предупреждениями, относящимися к процессу ClaimInvestigation. Для каждой ошибки или предупреждения выводится определенная информация:
  • Description (Описание). Краткое описание ошибки или предупреждения.
  • Element name (Имя элемента). Элемент, к которому относится ошибка или предупреждение.
  • Element type (Тип элемента). Тип элемента.
  • Parent name (Элемент-предок). Элемент-предок, к которому относится данный элемент.
  • Patent location (Местоположение элемента-предка). Место, где находится элемент-предок.
  • Error code (Код ошибки). По коду ошибки в информационном центре WebSphere Business Integration Modeler можно найти подробное описание ошибки.
  • Profile (Профиль): В каком профиле вы можете исправить данную проблему.
    •  Можно выполнять сортировку списка, щелкнув мышью по заголовку столбца.(рис 4.69) Представление Error (Ошибки) при экспорте в FDL
  • C помощью фильтра вы можете выводить в представлении Error только те ошибки, которые относятся к конкретному набору элементов модели или имеют опреде- ленный уровень важности. Чтобы задать фильтр, нажмите кнопку окна опций фильтра, показанную на рис 4.69.
  • На рис 4.70 показано окно, в котором устанавливаются опции фильтра для пред- ставления Еrror (Ошибки). Посмотрите, что произойдет, если вы измените фильтр сообщений проекта на Selected element and children (Выбранный элемент и его потомки) и щелкните по процессу в дереве проекта.(рис 4.70) Фильтр для представления Error (Ошибки)
  • Теперь снова измените фильтр на Selected project (Выбранный проект).
  • Мы должны исправить все ошибки в процессе, прежде чем его можно будет экспортировать. У нас ошибок нет. Предупреждения можно игнорировать и продолжить экспортирование процесса.

    • Экспортирование процесса

    Чтобы экспортировать процесс, выполните следующие шаги.

  • Щелкните правой кнопкой мыши по имени процесса в дереве проектов и выберите пункт меню , а затем нажмите Next (Далее). Укажите директорию, в которою процесс должен быть экспортирован, и убедитесь в том, что выбран процесс ClaimInvestigation. Нажмите Finish (Готово).
  • Если ошибок нет, значит, экспорт прошел успешно. Вы можете найти экспортированный файл с именем, соответствующим имени проекта, и расширением .fdl. В нашем случае экспортированный файл будет иметь имя ITSOLGI.fdl.
  • Если при экспорте возникают ошибки, следуйте инструкциям, приведенным в сообщении об ошибке.
    •  (рис 4.71) Мастер экспорта в WebSphere Business Integration Modeler

    Теперь вы можете импортировать файл в WebSphere MQ Workflow Buildtime.

    Соответствия элементов

    В этом разделе мы покажем, как установить соответствия элементов из WebSphere Business Integration Modeler элементам WebSphere MQ Workflow.

    На рис. 4.72 показана первая часть процесса установления соответствий для WebSphere Business Integration Modeler и показаны соответствия процесса процессу WebSphere MQ Workflow. Цифры красного цвета обозначают соответствия "один к одному".

    (рис 4.72) Установление соответствий для ClaimInvestigation: часть 1(a) из 3
  • Вход процесса (1) соответствует узлу Data source (Источник данных) (1).
  • Локальная задача SelectReports (2) соответствует программной задаче SelectReports (2). С этой задачей связывается программа со случайно генерируемым именем. Требования к ролям соответствуют полю Member of roles (Назначения ролей) на закладке Staff2 свойств элемента SelectReports.
  • Элемент Decision (3) соответствует программной задаче Decision (3), с которой связывается программа FMCINTERNALNOOP.
  • Условия выхода (Output conditions) (4) соответствуют условиям перехода от элемента Decision к задачам Map и Map2 соответственно.
  • Элемент Map:2 (5) соответствует программной задаче Map (5). С этой задачей связывается программа со случайно генерируемым именем. Содержимое поля Description элемента Map:2 соответствует полю Description на закладке General (Общие) свойств элемента Map.
  • Элемент Map (6) соответствует программной задаче Map (6). С этой задачей связывается программа со случайно генерируемым именем.
  • Локальная задача RequestExternalReports (7) соответствует программной задаче RequestExternalReports (7). И снова с этой задачей связывается программа со случайно генерируемым именем.
    •

    На рис 4.74 показана вторая часть установления соответствий процесса WebSphere Business Integration Modeler и процесса WebSphere MQ Workflow, показанного на рис 4.75. Цифры красного цвета обозначают соответствия "один к одному".

    (рис 4.74) Установление соответствий для ClaimInvestigation: часть 1(b) из 3(рис 4.73) Установление соответствий для ClaimInvestigation: часть 2(а) из 3(рис 4.75) Установление соответствий для ClaimInvestigation: часть 2(b) из 3
  • Элемент Fork (8) соответствует программной задаче Fork (8), с которой связана программа FMCINTERNALNOOP.
  • Локальная задача UpdateExternalReports (9) соответствует программной задаче UpdateExternalReports (9). С этой задачей связывается программа со случайно генерируемым именем. Обратите внимание, что со следующем элементом не связан коннектор данных.
  • Элемент Merge (10) соответствует программной задаче Merge2 (10), с которой связана программа FMCINTERNALNOOP. Задача Merge2 принимает два входа и три управляющих коннектора. Условием запуска является значение ИСТИНА на всех входящих коннекторах.
  • Элемент Fork (11) соответствует программной задаче Fork2 (11), с которой связана программа FMCINTERNALNOOP.
    •

    На рис 4.76 показана последняя часть установления соответствия процесса WebSphere Business Integration Modeler и процесса WebSphere MQ Workflow, показан- ного на рис 4.77. Цифры красного цвета обозначают соответствия "один к одному".

    (рис 4.77) Установление соответствий для ClaimInvestigation: часть 3(а) из 3(рис 4.76) Установление соответствий для ClaimInvestigation: часть 3(b) из 3
  • Элемент SetClaimStat (12) соответствует программной задаче SetClaimStat (12). С этой задачей связывается программа со случайно генерируемым именем.
  • Локальная задача Merge (13) соответствует программной задаче Merge (13), с которой связана программа FMCINTERNALNOOP. Элемент Merge принимает один вход для данных и два управляющих коннектора. Условием запуска значение ИСТИНА на всех входящих коннекторах (All incoming connectors true).
  • Выход процесса (14) соответствует узлу выхода (Data sink) (11).
  • Узел Stop (15) не импортируется, поскольку не поддерживается в WebSphere MQ Workflow.
    •

    При экспорте из WebSphere Business Integration Modeler информация для размещения не генерируется.

    4.5.3 Экспорт процесса RequestExternalReports в виде процесса BPEL4WS

    Новый бизнес-процесс RequestExternalReports будет выполняться в WebSphere Business Integration Server Foundation. За экспорт процесса в формат BPEL4WS отвечает ИТ-специалист. Бизнес-аналитик эту задачу не выполняет.

    ИТ-специалисту, отвечающему за экспорт процесса RequestExternalReports в BPEL следует прочитать главу 5 книги "BPEL4WS Business processes with WebSphere Business Integration: Understanding, Modeling, Migrating", SG24-6381. В этой главе рассматриваются соответствия между элементами WebSphere Business Integration Modeler и элементами BPEL4WS. Глава 6 упомянутой книги поможет вам понять, какие артефакты экспортируются из WebSphere Business Integration Modeler в BPEL4WS.

    Проверка модели процесса

    Перед экспортом нам нужно проверить процесс RequestExternalReports на соответствие нотации BPEL. Мы снова увидим многочисленные предупреждения, которые можно игнорировать, и восемь ошибок, которые нужно исправить.

    В WebSphere Business Integration Modeler переключитесь в технологический режим BPEL и откройте процесс RequestExternalReports в редакторе процессов. В данном технологическом режиме мы увидим специфичные для BPEL ошибки и предупреждения. Если в модели процесса отсутствует информация, которая является обязательной для BPEL4WS, или если элементы включают в себя объекты и параметры, не поддерживаемые в BPEL4WS, WebSphere Business Integration Modeler выводит список возникающих проблем. Как и в случае с режимом FDL, мы должны исправить эти ошибки перед экспортированием модели, но мы можем игнорировать предупреждения.

    Существует ряд практических методов, которые можно применять в BPEL-режиме, при проверке модели при помощи WebSphere Business Integration Modeler Advanced Edition v5.1.1. Некоторые из них также применимы и к FDL-режиму.

  • Убедитесь в том, что каждый входной критерий соответствует одному и не более чем одному выходному критериюЭто относится и к FDL-режиму.. Иными словами, каждый входной критерий должен запускать один конкретный выходной критерий. Это соответствует WSDL-операции, которая может иметь только одно выходное сообщение. Если вы должны сочетать один входной критерий с несколькими выходными, попробуйте использовать элемент-решение, чтобы смоделировать логику ветвления с исключением.

    С этой проблемой в процессе RequestExternalReports связаны четыре ошибки.

    Совет. Убедитесь, что процесс RequestExternalReports открыт, а все изменения сохранены. Щелкните по сообщению об ошибке - и соответствующий элемент в модели процесса будет выделен цветом, показывая, где находится ошибка. Эти ошибки объясняются тем, что входные критерии локальных задач ManualSelectAssessor и RequestAssessment не связаны ни с одним выходным критерием. Для исправления проблемы переключитесь на пользовательский профиль Advanced, выберите пункт Advanced Output Logic (Дополнительная логика выходов) в представлении Attributes (Атрибуты), выберите пункт Output criteria (Выходной критерий), который вам нужно связать, и поставьте галочки напротив пунктов Input criteria (Входной критерий). Галочки должны быть установлены в обоих полях. На рис 4.78 показаны правильно установленные параметры.(рис 4.78) Параметры окна Advanced Output Logic (Дополнительная логика выходов)
  • Повторите указанные действия для элементов ManualSelectAssessor и RequestAssessment и сохраните процесс. Теперь, после того как мы отфильтруем сообщения об ошибках, у нас должно остаться пять ошибок.
  • Убедитесь, что каждый процесс имеет только один входной критерий и один выходной критерий. Это можно проверить, перейдя на закладку спецификаций в редакторе процессов. Например, чтобы проверить, является ли критерий входа единственным, выберите пункт Input specification (Спецификация входов) $$\to$$ Input Logic (Логика входов). Убедитесь, что в таблице Input settings (Параметры входов) имеется только один критерий входа, как это показано на рис 4.79.(рис 4.79) Параметр критерия входа для процесса
  • Если вы хотите, чтобы для задач и служб WebSphere Business Integration Modeler сгенерировал порт с несколькими операциями, определите для задачи или служ- бы несколько критериев входа. Каждый критерий входа должен быть связан с од- ним и не более чем, одним критерием выхода.
  • Убедитесь, что в модели процесса нет нижестоящих задач, связанных с вышестоя- щими задачами обратной связью, что разрешено в WebSphere Business Integration Modeler, но не разрешено в BPEL. То же относится и к FDL-режиму. Используйте вместо этого цикл while.

    В процессе RequestExternalReports есть одна ошибка такого типа - это выход No элемента-решения .

    (рис 4.80) Нижестоящая задача, связанная с вышестоящейЧтобы устранить эту проблему, мы добавим на схему локальное хранилище (LocalRepository) и соединим выход No элемента Confirmed? со входом этого хранилища, как показано на рис 4.81. Будут добавлены фиктивные данные типа String.(рис 4.81) Измененная часть процесса RequestExternalReportsМы изменим вход Input:2 элемента ManualSelectAssessors так, чтобы он получал данные из хранилища. (Сохраните процесс перед внесением изменений в элемент ManualSelectAssessors). Параметры этого элемента приведены на рис 4.82.(рис 4.82) Входные параметры локальной задачи ManualSelectAssessor
  • Убедитесь, что для связанных объектных входов и выходов двух узлов указаны одинаковые значения минимального и максимального числа элементов. Это также относится к FDL-режиму:
  • объектный выход Задачи1 связан с объектным входом Задачи2;
  • объектный выход Задачи1 имеет минимальное число элементов 3 и максимальное число элементов 5;
  • минимальное число необходимых элементов для объектного входа Задачи2 должно быть равно 3, а максимальное число должно быть равно 5. Иначе будет сгенерирован неверный код BPEL.
    •
  • Для элементов-решений вы должны определить условие для каждой из выходных ветвей. Это также относится к FDL-режиму.

    У нас с этим типом связаны четыре ошибки, которые объясняются тем, что не указаны условия перехода для двух узлов принятия решения. Для исправления проблемы мы добавим к элеме нтам-решениям фиктивный элемент-данные типа String и определим условия, используя Expression Builder. Выполните следующие шаги:

  • Убедитесь, что вы находитесь в режиме Advanced и процесс RequestExternalReports сохранен.
  • Выберите элемент Any Assessor? $$\to$$ Представление Attributes (Атрибуты) $$\to$$ Outputs (Выходы) $$\to$$ Select an output (Выбрать выход) $$\to$$ Associated data (Связанные данные) $$\to$$ String.
  • Выберите пункт Output Branches (Выходные ветви) $$\to$$ Yes (Да) $$\to$$ Details (Подробно) $$\to$$ Contents (Содержание) $$\to$$ Output:2 (Или другое используемое имя) $$\to$$ ).(рис 4.83) Задание условий для выходных ветвей элементов-решений
  • В открывшемся окне редактора выражений выберите First term (Первый член), укажите Modeling artifact (Моделируемый артефакт). Найдите и выберите элемент Input элемента Any Accessor. В поле Operator (Оператор) выберите пункт Is equal to (Равен). В поле Second term (Второй член) укажите Text (Текст), в поле Second term details (Подробнее о втором члене) укажите ).(рис 4.84) Использование Expression Builder для создания условия
  • Возможно, вам понадобится исправить еще какие-то ошибки. Может быть, с некоторыми коннекторами входов и выходов не связаны данные? Поищите незатененные серым цветом отметки входов и выходов во входных и выходных критериях. Преобразуйте их в тип String и заново соедините локальные элементы (рис 4.85).(рис 4.85) Другие ошибки, которые нужно исправить перед экспортом модели в BPEL
  • Когда вы свяжете данные String со всеми соединениями, вы можете увидеть ошибку DBL110014E - mismatched minimum and maximum number of items (Несовпадение минимального и максимального числа элементов). Измените вход элемента RequestAvailability, чтобы минимальное и максимальное число элементов было равно 2.
  • Когда все изменения будут сохранены, снова выполните статический анализ, чтобы убедиться, что все соединения работоспособны.

    • Некоторые элементы модели WebSphere Business Integration Modeler не могут быть преобразованы в BPEL либо из-за того, что они не имеют эквивалентных конструкций в BPEL, либо из-за того, что семантика сходных конструкций из BPEL отличается. Это элементы Notification broadcaster, Notification receiver, Observer, Timer, цикл For, цикл Do-while и глобальное хранилище. Мы не можем использовать эти элементы в BPEL-режиме.

    Экспортирование процесса

    После исправления всех ошибок сохраните процесс. Если ошибок не возникает, мы можем экспортировать процесс в BPEL, даже если остаются предупреждения.

  • Щелкните правой кнопкой мыши по процессу RequestExternalReports в дереве проектов и выберите пункт меню Export (Экспорт).
  • В мастере экспорта укажите пункт WebSphere Business Integration Server Foundation V5.1 (BPEL, WSDL, XSD), как показано на рис 4.86, и нажмите Next (Далее).(рис 4.86) Мастер экспорта WebSphere Business Integration Modeler - шаг 1
  • В следующем окне укажите директорию для экспорта, нажав кнопку Browse (Обзор). Выберите пункт Export Specific objects (Экспорт указанных объектов) и раскройте дерево проектов. Выберите процесс (рис 4.87) Мастер экспорта WebSphere Business Integration Modeler - шаг 2
  • Нажмите Next (Далее), чтобы указать режим выполнения процесса. Выберите Long-running (receive/reply) [Долговременный (получение/ответ)] и нажмите Finish (Готово).
  • Если при экспорте возникают ошибки, следуйте инструкциям в сообщениях об ошибках.
    •

    Теперь вы можете импортировать файлы в WebSphere Studio Application Development Integration Edition для разработки. Обращайтесь к лекции 10, "Создание процесса Request External Reports".

    Примечание. Копия экспортированного кода BPEL находится в директории .\SG24-6636\Modeler\BPEL Export. Существует также zip-файл проекта, содержащего процесс после исправлений, связанных с BPEL, который вы можете импортировать и изучить: .\SG24-6636\Modeler\Projects\PostBPEL.zip.

    4.6 Заключение

    В этой лекции мы показали, как использовать WebSphere Business Integration Modeler для моделирования бизнес-процесса, эмуляции и выполнения экспорта в FDL и BPEL для последующей реализации. Следующий этап - это передача проекта ИТ-архитектору для проектирования системы и выбора архитектуры решения с использованием инструментов от Rational.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^