Business Process Manager 8 в примерах. Кейс №1 - "Согласование теста"

Цель настоящей статьи - показать простой и наглядный пример реализации бизнес-процесса средствами IBM Business Process Manager v8. В этом примере процесс выполняется пользователями из клиентского приложения IBM BPM под iPad и IBM Process Portal. Устойчивая тенденция развития информационных технологий в сторону мобильных приложений нашла свое отражение и в решении IBM BPM, начиная с недавно выпущенной версии 8. Статья может быть полезна для начинающих специалистов, интересующихся IBM BPM. Она поможет составить представление о некоторых базовых возможностях продукта и научиться проходить цикл работы с бизнес-процессами «от моделирования до выполнения» используя IBM BPM. Главы данной статьи соответствуют шагам реализации цикла.

Максим Арзуманян, ассистент кафедры "Информационных технологий в экономике" , Санкт-Петербургский университет телекоммуникаций им. Бонч-Бруевича

фото Максим АрзуманянМаксим Арзуманян - ассистент кафедры «Информационные технологии в экономике» Санкт-Петербургского государственного университета телекоммуникаций им. проф. М.А. Бонч-Бруевича, сертифицированный специалист в области бизнес-аналитики, управления бизнес-процессами и интегрированных информационных систем. Автор учебных курсов по управлению бизнес-процессами и архитектуре предприятия, соавтор более 10 научно-исследовательских работ и более 15 научных публикаций в области ИТ, бизнеса и образования. Руководитель проектов на факультете экономики и управления (ФЭУ СПбГУТ). Участвовал в проектах внедрения информационных систем на предприятиях, руководил проектом по разработке концепции автоматизации для управляющей строительной компании. С 2007 успешно сотрудничает с IBM по программе Академической инициативы IBM, что подтверждено опубликованной «Историей успеха» и уникальным для российской высшей школы опытом подготовки и сертификации студентов по продуктам IBM. Участник команды, награжденной в 2010 году грантами IBM Faculty Award и IBM Industry Innovation Award. Личная страница: arzumanyan.com.ru



Максим Деревянко, инженер кафедры "Информационных технологий в экономике" , Санкт-Петербургский университет телекоммуникаций им. Бонч-Бруевича

Фото Максим Деревяненко Максим Деревянко - инженер кафедры "Информационных технологий в экономике" Санкт-Петербургского университета телекоммуникаций им. Бонч-Бруевича. Является сертифицированным специалистом по следующим направлениям: - IBM WebSphere Lombardi Edition 7.2 , IBM Certified BPM Developer, IBM WebSphere Lombardi Edition 7.1 , IBM Certified BPM Analyst, XML 1.1 and Related Technologies , IBM Certified Solution Developer, IBM WebSphere Business Modeler Advanced 6.1 , IBM Certified Business Process Analyst. Имеет опыт работы с IBM Business Process Manager 8. Программирует на Java.



26.11.2012

Введение

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

  • Моделирование процесса на основе текстового описания;
  • Реализация бизнес-логика процесса;
  • Интеграция с базой данных и сервером электронной почты;
  • Разработка пользовательских веб-форм стандартного вида (без применения различных стилей);
  • Установка приложения на сервер;
  • Выполнение процесса с ПК и iPad2.

Описание процесса

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


Диаграмма действий

Рисунок 1. Диаграмма действий
Диаграмма действий

Требования к программному обеспечению

На рисунке 2 показана типичная архитектура IBM Business Process Manager.

Рисунок 2. Типичная архитектура IBM Business Process Manager
Типичная архитектура IBM Business Process Manager

["IBM Business Process Management Samples homepage"http://publib.boulder.ibm.com/bpcsamp/home.html]

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

  • Process Center сконсолью и со средой Process Designer;
  • Process Server с рабочей средой (при реализации реальных проектов также необходимо использовать Process Server со средой тестирования для отладки приложений);
  • База данных (в примере использована DB2 Express);
  • Почтовый сервер для email уведомлений (в примере использован Courier Mail Server).

В данной статье не рассмотрены следующие ключевые возможности IBM BPM:

  • Интеграция с ECM, BRMS, Case Management системами
  • Разработка расширенных служб интеграции информационных систем в среде Integration Designer;
  • Мониторинг ключевых показателей эффективности процесса;
  • Отслеживание и анализ различных параметров процесса: производительность исполнителей, значения параметров соглашения об уровне обслуживания (SLA) и т.д.

Подготовительные действия

Для реализации цикла «от моделирования до выполнения» необходимо выполнить следующие подготовительные действия:

  • Создать базу данных с перечнем тестов IBM;
  • Для подключения к БД на Application server создать DataSource;
  • Для отправки email-уведомлений на почтовом сервере создать учетные записи пользователей, логины которых соответствуют логинам пользователей BPM;
  • В Process Center создать приложение Test Application.

После выполнения подготовительных действий переходим шагам реализации цикла.


Шаг 1. Диаграмма процесса

В начале работы в приложении Test Application создаем определение бизнес-процесса как показано на рисунке 3.

Рисунок 3. Диаграмма определения бизнес-процесса
Диаграмма определения бизнес-процесса

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

На дорожках "Студенты" и "Преподаватель" расположены задачи, выполняемые пользователями. Указываем этим задачам тип "Задача пользователя" (раздел свойств "Реализация"). Для каждой из них необходимо создать неавтоматизированную службу, реализующую логику выполнения задачи (термин "Неавтоматизированная служба" используется в русской локализации IBM BPM, в оригинале - "Human service", т.е. служба, выполняемая пользователем). Неавтоматизированные службы создаются в том же разделе свойств - "Реализация".

На дорожке "Система" расположена задача отправки E-mail уведомления, которая вызывается по триггеру в процессе выполнения пользовательских задач. Указываем ей тип "Подпроцесс события".

Затем, создаем группы участников процесса (роли) и добавляем в них соответствующих пользователей. В данной статье это "Студенты" и "Преподаватель". После этого дорожки процесса связываем с созданными группами. Далее необходимо разрешить группе "Студенты" инициировать процесс. Для этого на вкладке процесса "Обзор" указываем группу "Студенты" в пункте "Предоставить для запуска:".В итоге должна получиться совокупность компонентов как показано на рисунке 4. Бизнес-объект "Тесты", Undercover Agent "E-mail триггер", а также служба "Формирование письма" будут созданы на шаге 2 - "Реализация задач". Служба развертывания создается автоматически.

Рисунок 4. Список компонентов процесса
Список компонентов процесса

Определения бизнес-процессов IBM Business Process Manager 8 поддерживают производный класс Common Executable класса моделирования процессов BPMN 2.0, предназначенный для работы с исполняемыми моделями.

BPMN (Business Process Model and Notation) нотация - это основополагающий стандарт для описания и моделирования процессов в инструментах IBM Process Designer и IBM Process Center. Диаграммы определений бизнес-процессов (BPD) соответствуют требованиям спецификации BPMN.

IBM Business Process Manager поддерживает следующие типы задач BPMN 2.0:

  • Отсутствие реализации (абстрактная задача в спецификации BPMN 2.0);
  • Системная задача (служебная задача в спецификации BPMN 2.0);
  • Пользовательская задача;
  • Сценарий;
  • Задача решения (задача бизнес-правила в спецификации BPMN 2.0).

Вместо задач отправки и приема BPMN используются промежуточные события сообщений IBM BPM.

["Обзор IBM Business Process Manager версия 8 выпуск 0" ftp://public.dhe.ibm.com/software/integration/business-process-manager/library/pdf800/ibpm_overview_pdf_ru.pdf

Шаг 2. Реализация задач

Важно отметить, что при использовании инструментов класса Business Pocess Management Sutes (BPMS), под реализацией понимается создание набора сервисов (служб), используемых для реализации процесса. Сервисы могут использоваться многократно для реализации нескольких задач. Ключевыми принципами BPM систем являются модуляризация, использование открытых стандартов и возможность построения гибких систем на основе сервис-оринтированной архитектуры (SOA).

Благодаря гибкости и широким возможностям среды разработки варианты реализации процессов могут сильно отличаться. Стоит отметить полноценную поддержку русского языка. Даже имена переменных можно именовать кириллическими символами, но было решено этого не делать для удобства работы - не нужно переключать язык при указании переменных (например: tw.local.test, где test - имя переменной). Тем не менее, всем остальным элементам реализации, включая службы, были даны кириллические имена.

Службу отправки E-mail уведомлений реализуем в виде подпроцесса, выполняемого системой, и вызываемого из пользовательских задач. Это соответствует концепции SOA в аспекте многократного использования отдельных логических блоков.

Для реализации подпроцесса отправки уведомлений последовательно выполняем приведенные ниже действия:

  1. Создаем службу принятия решений с именем "Формирование письма". Служба принятия решений используется для реализации бизнес-логики приложения посредством варьирования значениями параметров объектов системы на основе условий и правил. Для реализации служб принятия решений Process Designer предоставляет набор элементов, указанных на рисунке 5. В данном примере служба будет формировать текст уведомления в утвердительной или отказной форме, в зависимости от места вызова. Например, при отклонении сдачи теста преподавателем, служба будет формировать текст письма, содержащий отказ в сдаче теста. Реализуем это посредством таблицы решений (рисунки 8 и 9).
    Рисунок 5. Элементы реализации службы принятия решений в среде Process Designer
    Элементы реализации службы принятия решений в среде Process Designer

    Элементы реализации службы


    Тип Название Описание
    Таблица решенийФормирование текста письмаФормирует текст письма в зависимости от места вызова службы

    Рисунок 6. Диаграмма реализации службы "Формирование письма"
    Диаграмма реализации службы Формирование письма

    Переменные службы

    ТипНазваниеФорматОписание
    Входныеtest StringВыбранный тест
    date DateДата сдачи теста
    reason String Причина отклонения теста
    mailId String Номер варианта текста письма-уведомления
    Выходныеtext String Текст письма
    subject String Тема письма
    compare String Переменная сопоставления. Иногда требуется сопоставить данные для продолжения выполнения действий (например, экземпляры процесса). В данной статье этого делать не будем, поэтому выполним лишь формальное (технически необходимое) сопоставление
    Рисунок 7. Переменные службы "Формирование письма"
    Переменные службы Формирование письма

    Реализация элементов службы


    ЭлементВкладкаРеализацияОписание
    Формирование текста письмаЗаключительные присваиванияtw.local.subject = "Passing test: " + tw.local.test;Формирование темы электронного письма с указанием имени выбранного теста
    tw.local.compare= "1";Так как сопоставление в данном примере чисто формальное, то присваиваем переменной любое значение (для простоты - "1")
    Рисунок 8. Реализация действия "Отклонить тест" в таблице решений службы "Формирование письма"
    Реализация действия Отклонить тест в таблице решений службы Формирование письма
    Рисунок 9. Реализация действия "Утвердить тест" в таблице решений службы "Формирование письма"
    Рисунок 9
  2. Создаем элемент Undercover Agent и присваиваем ему имя "E-mail триггер". Undercover Agent стартует по наступлению события и инициирует выполнение какой либо службы, либо последовательности задач процесса. Событием, приводящем Undercover Agent в действие, может быть получение сообщения (внутреннего или от внешних систем) или наступление периода по определенному расписанию. В данном примере событием будет получение внутреннего сообщения, поэтому указываем тип расписания "Во время события". В качестве прикрепленной службы указываем службу "Формирование письма".
  3. Реализуем подпроцесс "Отправка E-mail уведомления".

    Элементы реализации подпроцесса

    ТипНазваниеОписание
    Промежуточное событиеЗапуск отправки Инициирует последовательность операций по вызову триггера
    Системная задачаОтправка E-mail Непосредственно отправляет E-mail уведомление
    Рисунок 10. Диаграмма подпроцесса "Отправка E-mail уведомления"
    Рисунок10

    Переменные подпроцесса

    ТипНазваниеФорматОписание
    Личныеtext String Текст письма
    subject String Тема письма
    compare String То же значение, что и в пункте 1
    Рисунок 11. Переменные подпроцесса "Отправка E-mail уведомления"
    Рисунок 11

    Реализация элементов подпроцесса

    ЭлементВкладкаРеализацияОписание
    Запуск отправкиРеализацияСведения о событии запуска-> СообщениеПодпроцесс должен инициироваться при получении сообщения
    Прикрепленный UCA->E-mail триггерЭлемент, созданный в пункте 2
    Прервать родительский процесс -> [ ] Подпроцесс отправки E-mail должен выполняться параллельно основному процессу и не влиять на него (не прерывать)
    Повторение->[ ] Подпроцесс отправки E-mail должен запускаться 1 раз за экземпляр основного процесса
    Связывание данныхtext (String) ->tw.local.text
    subject (String) ->tw.local.subject
    compare (String) -> tw.local.compare
    Отправка E-mailРеализация Системная задача->Send E-mail via SMTP Готовая реализация службы отправки E-mail через SMTP в IBM Process Manager
    Связывание данныхАдрес вашего SMTP сервера-> smtpHost(String)Адрес SMTP сервера
    tw.local.studentName->to (String)Получатель письма
    tw.local.teacherName->from (String)Отправитель письма
    tw.local.subject->subject (String)Тема письма
    tw.local.text->messageText (String)Текст письма

    Для реализации неавтоматизированных служб, которые обеспечивают логику работы пользовательских задач данного процесса, Process Designer предоставляет набор элементов, указанных на рисунке 12, которые необходимо связать в последовательность на диаграмме службы. Также, неавтоматизированную задачу можно реализовать в среде Integration Designer, предоставляющей иной способ разработки.

    Рисунок 12. Элементы реализации неавтоматизированной службы в среде Process Designer
    Рисунок 12

Для реализации пользовательских задач процесса последовательно выполняем приведенные ниже действия:

  1. Неавтоматизированная служба "Выбор теста". Предоставляет студенту веб-форму для выбора теста из базы данных, созданной на этапе подготовительных действий.

    Элементы реализации службы

    ТипНазваниеОписание
    Скриплет сервераФормирование SQL запроса Формирует текст запроса к БД. Связываем с переменной sql.
    Вложенная службаВыполнение SQL запросаВыполняет запрос к БД
    Сoach (веб-форма)Выбор тестаВеб-форма для выбора теста
    Рисунок 13. Диаграмма реализации службы "Выбор теста"
    Рисунок 25

    Переменные службы

    Создаем бизнес-объект "Тесты", структура которого соответствует структуре данных, получаемых из БД. В данной статье - NUMBER (String), NAME (String).

    ТипНазваниеФорматОписание
    ВыходныеtestStringВыбранный тест
    studentNameStringЛогин студента, запросившего сдачу теста
    ЛичныеsqlStringТекст SQL запроса к БД
    testListТесты (List)Список тестов, полученный как результат запроса
    Рисунок 14. Переменные службы "Выбор теста"
    Рисунок 14

    Реализация элементов службы

    ЭлементВкладкаРеализацияОписание
    Формирование SQL запросаРеализацияtw.local.sql->SELECT * FROM BPMADMIN."TABLE1";Выборка перечня всех тестов, хранящихся в БД
    Выполнение SQL запросаРеализацияПодключенная вложенная служба ->SQL Execute StatementГотовая реализация службы выполнения запроса к БД в IBM Process Manager
    Связывание данныхtw.local.sql->sql (String)Текст sql-запроса
    "Тесты"->returnType (String) Тип возвращаемых значений
    "TESthB_Source"-> dataSourceName (String) Имя DataSource, созданного на предварительном этапе
    results (ANY)->tw.local.testListВозвращаемые значения
    Выбор тестаCoachTable1("Тесты:")-> testsList[] Таблица результатов запроса
    Заключительные присваиванияtw.local.test = tw.local.testsList.
    listSelected.NUMBER + " " + tw.local.testsList.listSelected.NAME;
    Формирование названия теста из его кода и имени
    tw.local.studentName = tw.system.user_loginName; Присваивание переменной studentName имя пользователя, выполняющего текущую задачу,с целью назначения его на последующие задачи процесса данной роли
  2. Неавтоматизированная служба "Рассмотрение запроса". Предоставляет преподавателю веб-форму для рассмотрения запроса на сдачу теста.


    Элементы реализации службы

    ТипНазваниеОписание
    Сoach (веб-форма)Рассмотрение запроса Веб-форма рассмотрения запроса
    Сценарий сервераНазначение даты сдачи Скрипт утверждения и назначения даты сдачи теста
    Сценарий сервераОтклонение теста Скрипт отклонения теста
    Вызов UCAE-mail уведомление Вызывает триггер, инициирующий подпроцесс отправки E-mail уведомления.
    Рисунок 15. Диаграмма реализации службы "Рассмотрение запроса"
    Рисунок 15

    Переменные службы

    ТипНазваниеФорматОписание
    Входныеtest StringВыбранный тест
    studentName StringЛогин студента, запросившего сдачу теста
    Выходныеdate DateДата сдачи теста
    testAccepted BooleanСостояние теста (утвержден/отклонен)
    reason StringПричина отклонения теста
    teacherName StringЛогин преподавателя, рассматривающего запрос
    ЛичныеmailId String Номер варианта текста письма-уведомления (значение по-умолчанию - "1")
    Рисунок 16. Переменные службы "Рассмотрение запроса"
    Рисунок 16

    Реализация элементов службы

    ЭлементВкладкаРеализацияОписание
    Рассмотрение запросаЗаключительные присваиванияtw.local.teacherName = tw.system.user_loginName;Присваивание переменной teacherName имя пользователя, выполняющего текущую задачу, с целью назначения его на последующие задачи процесса данной роли
    CoachOutput_text1("Пользователь")-> studentName
    Output_text2("хочет сдать тест") -> test
    Date_Time_Picker1 ("Выбрать дату и время сдачи:")->date
    Text1 ("Причина отказа")->reason
    Назначение даты сдачиРеализацияtw.local.testAccepted = true; Указание, что тест утвержден
    Отклонение тестаРеализацияtw.local.testAccepted= false;Указание, что тест отклонен
    E-mail уведомлениеРеализацияПодключенный Undercover Agent -> E-mail триггер
    Связывание данных tw.local.test->test (String)
    tw.local.date->date (Date)
    tw.local.reason->reason (String)
    tw.local.mailId->mailId (String)
    Предварительные присваивания tw.local.date = tw.system.currentTask.dueDateВставка даты исполнения текущей задачи, пустая дата вызовет ошибку
  3. Неавтоматизированная служба "Координация даты сдачи". Предоставляет студенту веб-форму для рассмотрения даты, предложенной преподавателем, и принятие решения о сдаче теста.

    Элементы реализации службы

    ТипНазваниеОписание
    Сoach (веб-форма)Рассмотрение даты Веб-форма координации даты теста
    Сценарий сервераПринятие датыСкрипт утверждения даты
    Сценарий сервераЗапрос переноса даты Скрипт отклонения текущей и запроса другой даты
    Вызов UCAE-mail уведомление Вызывает триггер, инициирующий подпроцесс отправки E-mail уведомления.
    Рисунок 17. Диаграмма реализации службы "Координация даты сдачи"
    Рисунок 17

    Переменные службы

    ТипНазваниеФорматОписание
    Входныеtest StringВыбранный тест
    teacherDateDateДата сдачи теста, предложенная преподавателем
    decision StringРешение преподавателя о переносе даты (используется при повторных итерациях координации)
    ВыходныеdateAcceptedBoolean Состояние даты (утверждена/запрошена другая)
    date DateЗапрошенная дата сдачи теста
    reason StringПричина переноса даты
    ЛичныеteacherDateStringString Текстовое представление даты сдачи теста, предложенной преподавателем
    label String Метка на веб-форме(меняет значение при повторных итерациях координации)
    mailId String Номер варианта текста письма-уведомления (значение по-умолчанию - "2")
    Рисунок 18. Переменные службы "Координация даты сдачи"
    Рисунок 18

    Реализация элементов службы

    ЭлементВкладкаРеализацияОписание
    Рассмотрение датыПредварительные присваиванияtw.local.teacherDateString = tw.local.teacherDate.format(); Приведение даты к текстовому формату в виде "дд.мм.гггг чч:мм"
    if (tw.local.decision == "ask"){
      tw.local.label = "перенесена на";
    }
    else{
      tw.local.label = "назначена на";
    }
    Проверка решения преподавателя, от которого зависит текст метки на веб-форме
    CoachOutput_text1 ("Сдача теста:")-> test
    Output_text2(label)-> teacherDateString
    Date_Time_Picker1("Запросить другую дату")->date
    Text1 ("Причина переноса даты")->reason
    Принятие датыРеализацияtw.local.dateAccepted = true; Принятие даты, предложенной преподавателем
    tw.local.date = tw.local.teacherDate; Назначение даты теста (при первом согласовании) илипереопределение запрошенного значениядаты(при повторном согласовании)на значение, предложенное преподавателем
    Запрос переноса датыРеализацияtw.local.dateAccepted = false; Отклонениедаты, предложенной преподавателем
    E-mail уведомлениеРеализацияПодключенный Undercover Agent ->E-mail триггер
    Связывание данных tw.local.test->test (String)
    tw.local.date->date (Date)
    tw.local.reason->reason (String)
    tw.local.mailId->mailId (String)
  4. Неавтоматизированная служба "Рассмотрение переноса сдачи". Предоставляет преподавателю веб-форму для рассмотрения причины переноса даты и предложения новой даты сдачи теста.

    Элементы реализации службы

    ТипНазваниеОписание
    Сoach (веб-форма)Рассмотрение переноса даты Веб-форма для рассмотрения переноса даты сдачи теста
    Сценарий сервераПринять новую датуСкрипт утверждения новой даты
    Сценарий сервераОтменить сдачу теста Скрипт отклонения теста
    Сценарий сервераНазначить другую дату Скрипт предложения другой даты сдачи
    Вызов UCAE-mail уведомление Вызывает триггер, инициирующий подпроцесс отправки E-mail уведомления.
    Рисунок 19. Диаграмма реализации службы "Рассмотрение переноса сдачи"
    Рисунок 19

    Переменные службы

    ТипНазваниеФорматОписание
    ВходныеstudentName StringЛогин студента, запросившего сдачу теста
    test StringВыбранный тест
    dateDateДата сдачи теста, предложенная преподавателем
    reason StringПричина переноса теста
    requestedDate DateДата сдачи теста, запрошенная студентом
    Выходныеdecision String Решение преподавателя по согласованию даты
    anotherDate DateНовая дата сдачи сдачи, предложенная преподавателем
    rejectReasonStringПричина отмены теста
    ЛичныеdateStringString Текстовое представление даты сдачи теста
    requestedDateStringString Текстовое представление даты сдачи теста, запрошенной студентом
    mailId String Номер варианта текста письма-уведомления
    Рисунок 20. Переменные службы "Рассмотрение переноса сдачи"
    Рисунок 20

    Реализация элементов службы

    ЭлементВкладкаРеализацияОписание
    Рассмотрение переноса датыПредварительные присваиванияtw.local.dateString = tw.local.date.format(); Приведение даты к текстовому формату в виде "дд.мм.гггг чч:мм"
    tw.local.requestedDateString = tw.local.newDate.format();
    Coach Output_text1;("Пользователь");-> studentName;
    Output_text2;("просит перенести сдачу теста");->;test ;
    Output_text3;("с");->;dateString ;
    Output_text4;("на");-> requestedDateString ;
    Output_text5;("по причине");-> reason;
    Text1 ("Причина отказа:");-> rejectReason; ;
    Date_Time_Picker1 ("Предложить новую дату сдачи:"); -> anotherDate ;
    Принять новую дату Реализация tw.local.decision = "accept";; Принятие даты, предложенной студентом
    tw.local.anotherDate = tw.local.requestedDate; Указание даты, предложенной студентом, в качестве даты переноса
    tw.local.mailId = "2";Идентификатор для определения текста письма из таблицы решений
    Отменить сдачу тестаРеализацияtw.local.decision="reject";;Отклонение сдачи теста
    tw.local.mailId = "1";;Идентификатор для определения текста письма из таблицы решений
    Назначить другую датуРеализацияtw.local.decision="ask";Предложение новой даты сдачи теста
    E-mail уведомлениеРеализацияПодключенный Undercover Agent ->;E-mail триггер ;
    Связывание данныхtw.local.test;->;test (String);
    tw.local.requestedDate;->;date (Date);
    tw.local.rejectReason;->;reason (String);
    tw.local.mailId;->;mailId (String);
  5. Неавтоматизированная служба "Уведомление преподавателя". Предоставляет преподавателю веб-форму для просмотра решений студента о сдаче теста.


    Элементы реализации службы

    ТипНазваниеОписание
    Сoach (веб-форма)Уведомление преподавателя Веб-форма уведомления преподавателя
    Рисунок 21. Диаграмма реализации службы "Уведомление преподавателя"
    Рисунок 21

    Переменные службы

    ТипНазваниеФорматОписание
    ВходныеstudentName StringЛогин студента, запросившего сдачу теста
    dateDateДата сдачи теста, предложенная преподавателем
    test StringВыбранный тест
    ЛичныеdateStringString Текстовое представление даты сдачи теста
    Рисунок 22. Переменные службы "Уведомление преподавателя"
    Рисунок 22

    Реализация элементов службы

    ЭлементВкладкаРеализацияОписание
    Уведомление преподавателяПредварительные присваиванияtw.local.dateString = tw.local.date.format();Приведение даты к текстовому формату в виде "дд.мм.гггг чч:мм"
    CoachOutput_text1("Пользователь")-> studentName
    Output_text2("подтвердил сдачу теста")->test
    Output_text3(" ")->dateString
  6. Неавтоматизированная служба "Уведомление студента". Предоставляет студенту веб-форму для просмотра решений преподавателя о сдаче теста.

    Элементы реализации службы

    ТипНазваниеОписание
    Сoach (веб-форма)Уведомление студента Веб-форма уведомления студента
    Рисунок 23. Диаграмма реализации службы "Уведомление студента"
    Рисунок 23

    Переменные службы

    ТипНазваниеФорматОписание
    Входныеtest StringВыбранный тест
    reasonString Причина отклонения теста
    decision String Решение преподавателя
    dateDateДата сдачи теста, предложенная преподавателем
    ЛичныеlabelValue String Сообщение студенту о решении преподавателя
    label StringМетка на веб-форме
    Рисунок 24. Переменные службы "Уведомление студента"
    Рисунок 24

    Реализация шагов задачи

    ЭлементВкладкаРеализацияОписание
    Уведомление студентаПредварительные присваиванияif (tw.local.decision == "accept") {
    tw.local.label = "утверждена на";
    tw.local.labelValue =  
    tw.local.date.format();
    }
    else {
    tw.local.label="отклонена.Причина:";
    tw.local.labelValue=tw.local.reason;
    }
    Проверка решения преподавателя, от которого зависит текст метки на веб-форме
    CoachOutput_text1("Сдача теста")->test
    Output_text2(label)->labelValue

Шаг 3. Связывания данных процесса

Обмен данными между задачами процесса осуществляется через локальные переменные процесса, т.е. входную переменную одной из взаимосвязанных задач и выходную переменную другой необходимо связать с одной и той же локальной переменной процесса. Создаем переменные процесса как показано на рисунке 25. Зеленым цветом выделены переменные подпроцесса "Отправка E-mail уведомления", созданные на шаге 2. Красным цветом выделены переменные процесса, которые необходимо создать для связи пользовательских задач.

Рисунок 25. Переменные процесса
Рисунок 25

Для каждой пользовательской задачи связываем данные как показано на рисунках 26-31.

Рисунок 26. Связывание данных задачи "Выбор теста"
Рисунок 26
Рисунок 27. Связывание данных задачи "Рассмотрение запроса"
Рисунок 27
Рисунок 28. Связывание данных задачи "Координация даты"
Рисунок 28
Рисунок 29. Связывание данных задачи "Рассмотрение переноса даты"
Рисунок 29
Рисунок 30. Связывание данных задачи "Уведомление преподавателя"
Рисунок 30
Рисунок 31. Связывание данных задачи "Уведомление студента"
Рисунок 31

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

  • для задач "Координация даты" и "Уведомление студента" - переменную studentName;
  • для задач "Рассмотрение переноса даты" и "Уведомление преподавателя" - переменную teacherName.

Шаг 4. Реализация условий

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

Рисунок 32. Реализация точки принятия решения "Сдача утверждена?"
Рисунок 35
Рисунок 33. Реализация точки принятия решения "Дата принята?"
Рисунок 33
Рисунок 34. Реализация точки принятия решения "Перенос утвержден?"
Рисунок 34

Шаг 5. Установка приложения на сервер

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

  1. Создаем снимок (snapshot) приложения.
    Рисунок 35. Создание снимка приложения
    Рисунок 35
  2. На вкладке "Process App" в Process Center, выбираем созданный снимок и указываем сервер для установки.
    Рисунок 36. Установка снимка приложения на сервер
    Рисунок 36
  3. Проверяем, что приложение корректно установилось. Для этого на вкладке "Установленные приложение" в Process Server проверяем наличие приложения Test Application.
    Рисунок 37. Проверка инсталляции приложения
    Рисунок 37

Шаг 6. Выполнение процесса

Начиная с восьмой версии IBM BPM доступен клиент под iPad/iPhone. В настоящем примере студент работает с iPad2, а преподаватель с компьютера в Process Portal.

  1. Студент с iPad запускает процесс. Выполнении процесса с iPad показало, что клиентское приложение для iOS некорректно отображает кириллические названия процессов и задач (рисунки 38 и 39). В тоже время процессы и задачи, наименования которых содержат только латинские символы, отображаются правильно (рисунки 40 и 41).
    Рисунок 38. Рабочий стол пользователя на iPad (кириллица)
    Рисунок 38
    Рисунок 39. Выполнение задачи "Выбор теста" на iPad (кириллица)
    Рисунок 39
    Рисунок 40. Рабочий стол пользователя на iPad (латиница)
    Рисунок 40
    Рисунок 41. Выполнение задачи "Выбор теста" на iPad (латиница)
    Рисунок 41
  2. Преподаватель рассматривает запрос и назначает дату сдачи.
    Рисунок 42. Преподаватель получил запрос на сдачу теста
    Рисунок 42
    Рисунок 43. Выполнение задачи "Рассмотрение запроса" в Process Portal
    Рисунок 43
  3. Студент просит перенести сдачу теста на другой день
    Рисунок 44. Выполнение задачи "Координация даты сдачи" на iPad
    Рисунок 44
  4. Преподаватель утверждает перенос даты.
    Рисунок 45. Преподаватель получил запрос переноса даты
    Рисунок 45
    Рисунок 46. Выполнение задачи "Рассмотрение переноса сдачи" в Process Portal
    Рисунок 46
  5. Студент получает уведомление на IPad и E-mail.
    Рисунок 47. Выполнение задачи "Уведомление студента" на iPad
    Рисунок 47
    Рисунок 48. Просмотр E-mail уведомления в почтовом клиенте (из-за проблем с отображением русскоязычных символов в теле письма уведомление написано на английском языке)
    Рисунок 48

    Информацию по экземпляру процесса можно просмотреть в Process Server на вкладке "Process Inspector". Информация по вышеописанному экземпляру приведена на рисунке 49.

    Рисунок 49. Информация по экземпляру процесса
    Рисунок 49

Заключение

В статье рассмотрен простой пример использования средств IBM Business Process Manager 8 для моделирования, разработки и выполнения с использованием мобильных клиентских устройств типа iPad. Создана модель процесса и набор сервисов (служб) для ее реализации. Разработка исполняемого приложения приведенного в статье занимает около часа работы опытного пользователя. Необходимо отметить, что разработка подобного приложения не является полноценной целю использования IBM BPM. Основные преимущества и возможности раскрываются на последующих стадиях жизненного цикла, а эффективность применения BPMS возрастает при увеличении масштаба проекта. Следует отметить три важнейших преимущества IBM BPM, которые не были продемонстрированы в настоящей статье:

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

Ресурсы

Комментарии

developerWorks: Войти

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


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


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

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

 


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

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

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



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

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

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

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

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

 


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


  • Bluemix

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

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

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=847219
ArticleTitle=Business Process Manager 8 в примерах. Кейс №1 - "Согласование теста"
publish-date=11262012