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

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 Импортирование текущего процесса

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

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

Рис. 4.6. WebSphere Business Integration Modeler Import Page

Рис. 4.7. Окно создания нового проекта бизнес-моделирования

После завершения импортирования будет отображено сообщение, сходное с приведенным на рис. 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.10. Отображение процесса изучения претензии в WebSphere MQ Workflow (1)

увеличить изображение
Рис. 4.11. Отображение процесса изучения претензии в 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.13. Отображение процесса изучения претензии в WebSphere MQ Workflow (2)

увеличить изображение
Рис. 4.14. Отображение процесса изучения претензии в 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.15. Отображение процесса изучения претензии в WebSphere MQ Workflow (3)

увеличить изображение
Рис. 4.16. Отображение процесса изучения претензии в 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