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

Изменение процесса изучения претензий

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

11.1 WebSphere MQ Workflow: Длительно работающие процессы

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

Пользователи взаимодействуют с WebSphere MQ Workflow при помощи Web-приложений, портлетов WebSphere Portal Server или автономных клиентов Microsoft Windows. Применяя эти пользовательские интерфейсы, специалисты по обработке претензий могут выбирать элементы работы в соответствии с требованиями бизнес-процесса, обрабатывать их, а затем уведомлять об окончании работы над элементом систему Workflow. Система работы с процессами отслеживает все имеющиеся элементы работы, так что можно вести мониторинг всех текущих претензий и проверять состояние претензий. Можно изменять график обработки претензий и задействованный персонал.

При осуществлении интеграции внутренних и внешних бизнес-систем с Web-Sphere MQ Workflow процессы могут обращаться к приложениям и Web-службам, используя агенты выполнения WebSphere MQ Workflow, которые конфигурируются как часть рабочего потока. Рабочие элементы обрабатываются либо специалистами по обработке претензий, либо автоматизированными агентами выполнения, которые в ходе обработки вызывают приложения и Web-службы.

Инструменты разработки

Рабочая система WebSphere MQ Workflow Runtime представляет собой контейнер, в котором работают размещенные процессы. WebSphere MQ Workflow Runtime использует систему управления базами данных для слежения за внутренним состоянием процессов. В WebSphere MQ Workflow для связи с внешними сущностями используются очереди WebSphere MQ. WebSphere Application Server применяется для предоставления графического пользовательского интерфейса конечным пользователям, которые принимают участие в рабочем потоке.

Мониторинг и управление

Администратор WebSphere MQ Workflow использует административную утилиту (Administration Utility) для выполнения следующих действий:

  • запуска и останова серверов;
  • мониторинга и анализа журналов ошибок.
    •

    Кроме того, для анализа трассировочных данных, генерации отчетов и графических представлений бизнес-данных, генерируемых процессами, можно использовать WebSphere Business Integration Monitor V 4.3.5. Статистические данные, получаемые в WebSphere Business Integration Monitor, могут применяться для перестройки бизнес-процессов.

    11.2 Интеграция процессов: WebSphere MQ Workflow

    Если вы рассмотрите новый процесс RequestExternalReports с точки зрения WebSphere MQ Workflow, вы обнаружите, что системе WebSphere MQ Workflow необходимо лишь знать интерфейс нового процесса, чтобы вызывать его, используя интерфейс служб. В интерфейсе нужно определить три аспекта:

  • Имя процесса и его местоположение.

    Системе WebSphere MQ Workflow эта информация необходима для вызова процесса. В случае с процессом RequestExternalReports процесс – это бизнес-процесс на основе BPEL, который размещен в WebSphere Business Integration Server Foundation.

  • Структура входов процесса.

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

  • Структура выходов процесса.

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

    •

    Соответственно WebSphere MQ Workflow работает с процессом RequestExternalReports как с реализацией соответствующей операции в существующем процессе ClaimInvestigation.

    11.2.1 Реализация настраиваемых вызовов в WebSphere MQ Workflow

    Реализации операций обычно запускаются системой WebSphere MQ Workflow путем отправки внутреннего сообщения-запроса агенту выполнения программы (program execution agent, PEA) или серверу выполнения программы (program execution server, PES), которые представляют собой встроенные компоненты системы MQ WorkflowЗа дополнительной информацией о PEA и PES обращайтесь к документации WebSphere MQ Workflow - Concepts and Architecture.. Они, в свою очередь, вызывают программу, которая согласно модели реализует данную операцию. При использовании интерфейса на основе сообщений, также возможно сделать так, чтобы система MQ Workflow отправляла вызывающее сообщение-запрос в XML-формате в заданную пользователем очередь MQSeries.

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

    Поэтому такая программа называется определяемым пользователем сервером выполнения программы (user defined program execution server, UPES). Такой сервер может представлять собой любое написанное пользователем приложение или такую программу, как MQSeries Integrator, если она может обрабатывать формат XML-сообщений MQ Workflow. UPES и программная операция, выполняемая данным UPES, моделируются в MQ Workflow BuildTime.

    UPES определяется и конфигурируется для системы MQ Workflow путем моделирования в MQ Workflow BuildTime. Обязательными атрибутами являются имя, версия и представляемая очередьВерсия UPES обозначает версию MQ Workflow API, которую поддерживает UPES и, соответственно, определяет, какие сообщения будут посылаться в соответствующую очередь и форматы этих сообщений..

    Приложение, которое прослушивает очередь UPES, не находится под управлением MQ Workflow. За администрирование приложения отвечает системный администратор. С точки зрения MQ Workflow вызов реализации операции был успешным, если вызывающее сообщение было успешно поставлено в очередь UPES. Следующий рисунок иллюстрирует данную идею и отображает компоненты UPES.

    (рис 11.1) Настраиваемый вызов операции с использованием UPES

    Цифры на рисунке показывают архитектуру UPES:

  • UPES должен быть определен с помощью WebSphere MQ Workflow BuildTime и должен ссылаться на существующую очередь WebSphere MQ в качестве входной очереди. Кроме того, должна существовать программа, прослушивающая данную очередь.
  • Когда должна быть запущена реализация операции, MQ Workflow посылает сообщение вызова программы в очередь UPES (в формате XML).
  • Приложение, прослушивающее очередь UPES, читает XML-сообщение и выполняет соответствующее действие. Это может быть вызов реализации операции, например вызов программы на платформе, которая еще не поддерживается MQ WorkFlow.
  • Когда приложение завершает выполнение своего действия, оно создает, если это необходимо, XML-сообщение-ответ для MQ Workflow и помещает его в очередь ответов. Обратите внимание, что информация об очереди ответов является частью MQMD входного вызывающего XML-сообщения и по умолчанию задается очередь EXEXMLINPUTQ.
  • Система MQ Workflow читает сообщение-ответ, обрабатывает его и соответственным образом изменяет состояние операции.
    •

    Режимы вызова UPES

    При моделировании UPES можно также ввести в модель два режима вызова реализации операции:

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

    Исходя из этой информации, мы заключаем, что UPES является одним из главных подходов к реализации настраиваемого вызова приложений или процессов, не входящих в систему WebSphere MQ Workflow.

    11.3 Создание рабочего потока ClaimInvestigation_TOBE

    В разделе 7.2.4, "Инсталляция и конфигурирование WebSphere MQ Workflow", мы создали работающую систему WebSphere MQ Workflow. Теперь нам нужно изменить существующий процесс обработки претензий, чтобы автоматизировать задачу RequestExternalReports, выполняющуюся в рабочем потоке.

    Сюда входят следующие задачи:

  • Повторное создание процесса ClaimInvestigation_ASIS в WebSphere MQ Workflow Buildtime.
  • Создание структур данных, которыми процесс будет обмениваться с операцией RequestExternalReports.
  • Определение интерфейса операции RequestExternalReports, через который будет вызываться прокси-процесс RequestExternalReports в WebSphere Business Integration Server Foundation. Будет использоваться JMS-совместимый интерфейс XML Enterprise Service.
    •

    11.3.1 Импортирование рабочего потока ASIS

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

  • Откройте WebSphere MQ Workflow buildtime – FMC.
  • Выберите пункт Buildtime > Import (Импорт), найдите файл .\SG24-6636\Workflow\ClaimInvestigation_ASIS.fdl и нажмите OK (рис 11.2).(рис 11.2) Процесс ClaimInvestigation_ASIS
  • Чтобы открыть процесс ClaimInvestigation, сделайте двойной щелчок по процессу ClaimInvestigation на верхнем уровне.
    •

    11.3.2 Создание структур данных для RequestExternalReports

    Для этого существует несколько способов, но, к сожалению, нельзя импортировать WSDL пряо из Rational Software Architect.

  • Моделировать новые структуры данных прямо в WebSphere MQ Workflow.
  • Моделировать структуры данных в WebSphere Business Integration Modeler и импортировать их в виде FDL.
  • Создать новую XML-схему в WebSphere Studio Application Development Integration Edition.

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

    Альтернативный подход, где мы начинаем с WSDL, заданного целевой службой, и изменяем FDL, который используется WebSphere MQ Workflow, приводя его в соответствие с интерфейсом службы, более соответствует архитектурному направлению, которое мы пытаемся применять. Так что для полноты использования цепочки инструментов, которую мы стараемся применять, ниже описывается, как следует изменить WebSphere MQ Workflow, чтобы он играл роль клиента существующего интерфейса службы.

  • Перейдите к WSDL-файлу, который содержит структуры данных, которые нам нужно импортировать в WebSphere MQ Workflow. Для примера мы используем файл Proxy(1).wsdl.
  • В графическом редакторе WSDL раскройте тип порта RequestExternalReports_UPES и его сообщения и выберите структуру requestAssessor (см. рис 11.3).(рис 11.3) Структуры данных, которые нужно преобразовать в схемы
  • Перейдите на закладку Source (Исходный код), и курсор будет установлен в выбранной структуре. Скопируйте сложный тип requestAssessor.
  • Вставьте тип в новый файл схемы, между тегами схемы.
  • Повторите процесс для типа requestAssessorReponse.
  • Выполните глобальную замену xsd: $$\to$$ <blank>; пространство имен для схемы – заданное по умолчанию.
  • Сохраните изменения. Ошибок не будет.
  • Укажите пространство имен схемы http://workflow.lgi.itso (рис 11.4).(рис 11.4) Схема RequestExtenalReports
  • Экспортируйте файл схемы: выделите файл, нажмите правую кнопку мыши, выберите пункт меню Export (Экспорт) $$\to$$ File system (Файловая система) и укажите директорию для экспорта.
    •

    Конвертирование схемы в FDL

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

  • Откройте проект ITSOLGI в WebSphere Business Integration Modeler.
  • Выберите пункт меню File (Файл) $$\to$$ Import (Импорт) $$\to$$ WebSphere Business Integration Modeler $$\to$$ Import (Импорт) $$\to$$ XML Schema (XML-схема) $$\to$$ Next (Далее). Выберите файл RequestExternalReports.xsd, укажите в качестве целевого проекта ITSOLGI и нажмите Next (Далее). Должен быть выбран бизнес-элемент ( Business Item ). Нажмите Finish (Готово), а затем OK.
  • Выберите папку workflow.lgi.itso, нажмите Export (Экспорт) $$\to$$ WebSphere MQ Workflow FDL. Укажите целевую директорию – папку itso.lgi.workfow, выберите Export specific items (Экспорт специфических элементов) $$\to$$ Finish (Готово) $$\to$$ OK.
    •

    Импортирование в WebSphere MQ Workflow

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

  • Перейдите на закладку Implementation (Реализация) в WebSphere MQ Workflow Buildtime.
  • Выберите пункт Buildtime > Import (Импорт). Укажите файл ITSOLGI.fdl, который был экспортирован из Modeler.
  • Удалите w_ из имен структур данных, открыв свойства этих двух структур данных и изменив их свойство Name (Имя).
    •

    11.3.3 Определение интерфейса для RequestExternalReports

    Теперь нам нужно определить интерфейс рабочего потока для изучения претензий, который мы будем использовать для вызова процесса RequestExternalReports в WebSphere Business Integration Server Foundation.

    С точки зрения WebSphere MQ Workflow-процесс RequestExternalReports – это простая автоматизированная операция, которая вызывает процесс RequestExternalReports путем отправки сообщения JMS/XML при помощи WebSphere MQ. По окончании процесс RequestExternalReports возвращает операции RequestExternalReports другое сообщение.

    Единственный дополнительный этап, необходимый для того, чтобы система WebSphere MQ Workflow могла вызывать BPEL-процесс в WebSphere Business Integration Server Foundation, – это экспортирование из системы Workflow WSDL-файла, содержащего полное определение структур сообщений, передаваемых в систему Workflow и из нее. Этот файл может использоваться для определения процесса ClaimInvestigation как партнерской ссылки в процессе RequestExternalReports.

    Создание UPES для операции RequestExternalReports

    UPES (заданный пользователем сервер выполнения программы) определяет, как автоматизированная операция взаимодействует с внешней программой при выполнении автоматизированной операции от имени рабочего потока. Существует две формы UPES – синхронный и асинхронный. Асинхронный UPES не возвращает управление в WebSphere MQ Workflow. Синхронный UPES заставляет операцию ожидать завершения выполнения. Срок выполнения может быть длительным. Мы будем использовать синхронный UPES.

    На практике UPES реализуется как очередь WebSphere MQ. Рабочий поток помещает сообщение во входную очередь UPES, когда есть работа, которую нужно выполнить, а программная операция прослушивает очередь, извлекает сообщение и выполняет операцию. По завершении работы программная операция посылает в Workflow сообщение-ответ. Хотя для прослушивания входной программной операцией создается специфическая входная очередь UPES, в Workflow по умолчанию, как правило, есть только одна очередь ответов, EXECXMLINPUTQ, которая прослушивается на предмет поступления сообщений-ответов.

    Cоздание UPES

    Для создания UPES выполните следующие действия:

  • Выберите пункт меню BuildTime $$\to$$ закладка Network (Сеть) $$\to$$ DOMAIN (Домен) $$\to$$ FMCGRP.
  • Щелкните правой кнопкой мыши по FMCSYS и выберите пункт меню New UserDefined Program Execution Server (Новый пользовательский сервер выполнения программ).
  • На закладке General (Общие) укажите в поле имени значение UPESSVR, выберите версию 3.4.0 в раскрывающемся списке версий.
  • На закладке Message Queuing (Очереди сообщений) укажите в поле Queue Name (Имя очереди) значение WPCUPESQ, а поле Queue Manager Name (Имя менеджера очереди) оставьте пустым.Важно! Мы используем кластеризацию WebSphere MQ, и эта очередь будет кластерной очередью, определенной на машине с WebSphere Business Integration Server Foundation. Если вы не используете кластеризацию, то имя очереди должно представлять собой определение удаленной очереди или ее псевдоним. Плохой практикой является явное определение имени менеджера очереди, поскольку уменьшается прозрачность местоположений.
  • Укажите в поле Message Format (Формат сообщений) значение JMS-compliant XML (JMS-совместимый XML) и нажмите OK.
    •

    Создание программы для RequestExternalReports

    Это программа, которая будет использоваться операцией RequestExternalReports; она должна иметь то же имя, которое имеет и программа, которую мы собираемся создать в WebSphere Studio Application Development Integration Edition для запуска процесса RequestExternalReports.

  • На закладке BuildTime перейдите на закладку Implementations (Реализации), щелкните правой кнопкой мыши по элементу Programs (Программы) и выберите пункт меню New Program (Новая программа).
  • На закладке General (Общие) в поле Name (Имя) введите RequestExternalReportsProxy.
  • На закладке Data (Данные):
  • включите опцию Program requires these data structures (Программе требуются следующие структуры данных) > Input (Вход), найдите элемент requestAssessor и нажмите OK ;
  • для поля Output (Выход) найдите элемент requestAssessorResponse и нажмите OK ;
  • включите опцию ).
    •  (рис 11.5) Определение свойств данных для RequestExternalReportsProxy
  • На закладке Windows NT $$\text{\textregistered}$$ в поле Path and file name (Путь и имя файла) введите RequestExternalReportsProxy.exe.

    Мы могли бы ввести в это поле любое имя, поскольку исполняемый файл никогда не вызывается, и он не должен существовать в файловой системе. Он нужен только потому, что рабочей системе WebSphere MQ Workflow необходимо, чтобы существовало хотя бы одно определение платформы для программы, иначе определение будет считаться недействительным.

  • Нажмите OK.

    • Конфигурирование операции RequestExternalReports

    Теперь нам нужно настроить операцию и связи данными, в которых задействована операция:

  • В меню BuildTime выберите пункт Process Models (Модели процесса) $$\to$$ Claim $$\to$$ закладка Processes (Процессы) $$\to$$ ClaimInvestigation $$\to$$ RequestExternalReports.
  • На закладке General (Общие) измените значение в поле Name (Имя) на RequestExternalReportsProxy.
  • На закладке Execution (Выполнение):
  • отключите опцию User program execution agent (Пользовательский агент выполнения программы);
  • отметьте пункт Server (Сервер), найдите сервер UPESSVR, нажмите OK.
    •
  • На закладке Start (Запуск) убедитесь, что включена опция Automatic (Автоматически).
  • На закладке Exit (Выход) убедитесь, что включена опция Automatic (Автоматически).
  • На закладке Data (Данные):
  • в поле Input (Входные) найдите элемент requestAssessor и нажмите OK ;
  • в поле Output (Выходные) найдите элемент requestAssessorResponse и нажмите OK.
  • Нажмите OK.

    • Конфигурирование связей для потоков данных

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

  • Сделайте двойной щелчок мышью по зеленому коннектору (рис 11.6), расположенному между операциями SelectReports и RequestExternalReports ; нажмите OK в двух окнах с предупреждениями о том, что структуры данных некорректны. Мы собираемся исправить эти ошибки.(рис 11.6) Выберите коннектор потока данных, идущих к операции RequestExternalReports
  • Установите указанные ниже связи, перетаскивая поле столбца Member (Член) структуры Origin Data Structure (Исходная структура данных) в поле Member структуры ):(рис 11.7) Связывание входных структур данных для RequestExternalReports
  • Investigate_DataInput.Claim_DataInput.ClaimID $$\to$$ claimID;
  • Investigate_DataInput.PolicyID $$\to$$ policyID;
  • Report_Claim.AssReqDate $$\to$$ requiredDate;
  • Investigate_DataInput.LocVehicle $$\to$$ location;
  • Investigate_DataInput.MakeOfCar $$\to$$ makeOfCar.
    •
  • Повторите процедуру для коннектора, расположенного между операциями RequestExternalReports и UpdateExternalReports. Снова игнорируйте появляющиеся предупреждения. Свяжите следующие поля и нажмите OK (рис 11.8).
  • claimID $$\to$$ Investigate_DataInput.Claim_DataInput.ClaimID;
  • policyID $$\to$$ Investigate_DataInput.PolicyID;
  • assCompDate $$\to$$ Report_Claim.AssActDate;
  • reportLocal $$\to$$ Investigate_DataInput.AppEstRep.
    • (рис 11.8) Связывание выходных структур данных для RequestExternalReports

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

    Следующий шаг – это экспортирование FDL, чтобы мы могли определить структуру сообщений для процесса RequestExternalReports, работающего в WebSphere Business Integration Server Foundation.

  • Выберите процесс ClaimInvestigation на закладке Process (Процесс). Щелкните правой кнопкой мыши и выберите пункт меню Save (Сохранить).
  • Выберите пункт меню BuildTime > Export (Экспорт) > Export single objects (Экспорт одиночных объектов).
  • В разделе Show objects (Показать объекты) выберите все опции и нажмите Refresh (Обновить), чтобы увидеть все элементы модели.
  • Выделите элемент ClaimInvestigation process (если удерживать клавишу Shift и сделать щелчок мышью, значок окажется отмеченным). Включите также опцию Export deep (Экспорт нижележащих), чтобы экспортировались также структуры данных и программы, на которые ссылается процесс.
  • Выберите (Shift+левая кнопка мыши) UPES-сервер UPESSVR, найдя его в элементе Network (Сеть), и нажмите OK.
  • Выберите папку для экспорта и сохраните файл под именем Proxy(1).fdl. Нажмите OK.
    •

    11.4 Размещение процесса

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

    Чтобы разместить поток в рабочей системе (runtime), нужно импортировать в рабочую систему FDL. Импортирование можно производить прямо на сервере рабочей системы или с использованием клиентской машины, на которую установлены административные компоненты WebSphere MQ Workflow.

    Чтобы импортировать модель процесса в рабочую систему, мы используем утилиту fmcibie с такими опциями, как:

  • опция –i, указывающая файл, который мы хотим импортировать;
  • параметр –y, указывающий имя конфигурации;
  • параметры –u и –p, которые используются для указания имени и пароля администратора рабочего потока;
  • параметр –to, который заставляет утилиту перезаписывать имеющиеся объекты, если это необходимо, и преобразовывать модель процесса в шаблон процесса, который может выполняться в рабочей среде.
    •

    На рис. 11.9 показаны результаты запуска утилиты fmcibie в директории interop 5.1.1\bin, где был сохранен файл Proxy(1).fdl.

    (рис 11.9) Запуск утилиты fmcibie для размещения рабочего потокаСовет. Возможно, вам повезет не сразу. Поскольку система времени выполнения не синхронизована с системой компоновки, в команде размещения процесса могут использоваться неверные операторы, например UPDATE вместо REPLACE. Вам нужно отредактировать все проблемные команды UPDATE в файле Proxy(1).fdl, которые привели к появлению ошибок. Просто удалите ключевое слово UPDATE, и при размещении будет выполняться команда CREATE, что должно сработать.

    11.5 Заключение

    В этой лекции мы кратко рассмотрели систему WebSphere MQ Workflow и затем показали, как при минимальных изменениях существующего процесса обработки претензий можно ввести в него вызов автоматизированной операции RequestExternalReports с использованием UPES-сервера в качестве агента выполнения операции. UPES-сервер – это фактически очередь WebSphere MQ. В лекции 12, "Интеграция и тестирование бизнес-процессов", рассматривается задача интеграции с WebSphere Business Integration Server Foundation после завершения всех остальных частей сценария. Интеграция не требует внесения изменений в рабочий поток, и она осуществляется путем инсталляции вспомогательного пакета (supportpac), который содержит инструменты интеграции и процессы времени выполнения, которые работают на WebSphere Business Integration Server Foundation.

    Страницы:

    11.1 WebSphere MQ Workflow: Длительно работающие процессы

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

    Пользователи взаимодействуют с WebSphere MQ Workflow при помощи Web-приложений, портлетов WebSphere Portal Server или автономных клиентов Microsoft Windows. Применяя эти пользовательские интерфейсы, специалисты по обработке претензий могут выбирать элементы работы в соответствии с требованиями бизнес-процесса, обрабатывать их, а затем уведомлять об окончании работы над элементом систему Workflow. Система работы с процессами отслеживает все имеющиеся элементы работы, так что можно вести мониторинг всех текущих претензий и проверять состояние претензий. Можно изменять график обработки претензий и задействованный персонал.

    При осуществлении интеграции внутренних и внешних бизнес-систем с Web-Sphere MQ Workflow процессы могут обращаться к приложениям и Web-службам, используя агенты выполнения WebSphere MQ Workflow, которые конфигурируются как часть рабочего потока. Рабочие элементы обрабатываются либо специалистами по обработке претензий, либо автоматизированными агентами выполнения, которые в ходе обработки вызывают приложения и Web-службы.

    Инструменты разработки

    Рабочая система WebSphere MQ Workflow Runtime представляет собой контейнер, в котором работают размещенные процессы. WebSphere MQ Workflow Runtime использует систему управления базами данных для слежения за внутренним состоянием процессов. В WebSphere MQ Workflow для связи с внешними сущностями используются очереди WebSphere MQ. WebSphere Application Server применяется для предоставления графического пользовательского интерфейса конечным пользователям, которые принимают участие в рабочем потоке.

    Мониторинг и управление

    Администратор WebSphere MQ Workflow использует административную утилиту (Administration Utility) для выполнения следующих действий:

  • запуска и останова серверов;
  • мониторинга и анализа журналов ошибок.
    •

    Кроме того, для анализа трассировочных данных, генерации отчетов и графических представлений бизнес-данных, генерируемых процессами, можно использовать WebSphere Business Integration Monitor V 4.3.5. Статистические данные, получаемые в WebSphere Business Integration Monitor, могут применяться для перестройки бизнес-процессов.

    11.2 Интеграция процессов: WebSphere MQ Workflow

    Если вы рассмотрите новый процесс RequestExternalReports с точки зрения WebSphere MQ Workflow, вы обнаружите, что системе WebSphere MQ Workflow необходимо лишь знать интерфейс нового процесса, чтобы вызывать его, используя интерфейс служб. В интерфейсе нужно определить три аспекта:

  • Имя процесса и его местоположение.

    Системе WebSphere MQ Workflow эта информация необходима для вызова процесса. В случае с процессом RequestExternalReports процесс – это бизнес-процесс на основе BPEL, который размещен в WebSphere Business Integration Server Foundation.

  • Структура входов процесса.

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

  • Структура выходов процесса.

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

    •

    Соответственно WebSphere MQ Workflow работает с процессом RequestExternalReports как с реализацией соответствующей операции в существующем процессе ClaimInvestigation.

    11.2.1 Реализация настраиваемых вызовов в WebSphere MQ Workflow

    Реализации операций обычно запускаются системой WebSphere MQ Workflow путем отправки внутреннего сообщения-запроса агенту выполнения программы (program execution agent, PEA) или серверу выполнения программы (program execution server, PES), которые представляют собой встроенные компоненты системы MQ WorkflowЗа дополнительной информацией о PEA и PES обращайтесь к документации WebSphere MQ Workflow - Concepts and Architecture.. Они, в свою очередь, вызывают программу, которая согласно модели реализует данную операцию. При использовании интерфейса на основе сообщений, также возможно сделать так, чтобы система MQ Workflow отправляла вызывающее сообщение-запрос в XML-формате в заданную пользователем очередь MQSeries.

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

    Поэтому такая программа называется определяемым пользователем сервером выполнения программы (user defined program execution server, UPES). Такой сервер может представлять собой любое написанное пользователем приложение или такую программу, как MQSeries Integrator, если она может обрабатывать формат XML-сообщений MQ Workflow. UPES и программная операция, выполняемая данным UPES, моделируются в MQ Workflow BuildTime.

    UPES определяется и конфигурируется для системы MQ Workflow путем моделирования в MQ Workflow BuildTime. Обязательными атрибутами являются имя, версия и представляемая очередьВерсия UPES обозначает версию MQ Workflow API, которую поддерживает UPES и, соответственно, определяет, какие сообщения будут посылаться в соответствующую очередь и форматы этих сообщений..

    Приложение, которое прослушивает очередь UPES, не находится под управлением MQ Workflow. За администрирование приложения отвечает системный администратор. С точки зрения MQ Workflow вызов реализации операции был успешным, если вызывающее сообщение было успешно поставлено в очередь UPES. Следующий рисунок иллюстрирует данную идею и отображает компоненты UPES.

    (рис 11.1) Настраиваемый вызов операции с использованием UPES

    Цифры на рисунке показывают архитектуру UPES:

  • UPES должен быть определен с помощью WebSphere MQ Workflow BuildTime и должен ссылаться на существующую очередь WebSphere MQ в качестве входной очереди. Кроме того, должна существовать программа, прослушивающая данную очередь.
  • Когда должна быть запущена реализация операции, MQ Workflow посылает сообщение вызова программы в очередь UPES (в формате XML).
  • Приложение, прослушивающее очередь UPES, читает XML-сообщение и выполняет соответствующее действие. Это может быть вызов реализации операции, например вызов программы на платформе, которая еще не поддерживается MQ WorkFlow.
  • Когда приложение завершает выполнение своего действия, оно создает, если это необходимо, XML-сообщение-ответ для MQ Workflow и помещает его в очередь ответов. Обратите внимание, что информация об очереди ответов является частью MQMD входного вызывающего XML-сообщения и по умолчанию задается очередь EXEXMLINPUTQ.
  • Система MQ Workflow читает сообщение-ответ, обрабатывает его и соответственным образом изменяет состояние операции.
    •

    Режимы вызова UPES

    При моделировании UPES можно также ввести в модель два режима вызова реализации операции:

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

    Исходя из этой информации, мы заключаем, что UPES является одним из главных подходов к реализации настраиваемого вызова приложений или процессов, не входящих в систему WebSphere MQ Workflow.

    11.3 Создание рабочего потока ClaimInvestigation_TOBE

    В разделе 7.2.4, "Инсталляция и конфигурирование WebSphere MQ Workflow", мы создали работающую систему WebSphere MQ Workflow. Теперь нам нужно изменить существующий процесс обработки претензий, чтобы автоматизировать задачу RequestExternalReports, выполняющуюся в рабочем потоке.

    Сюда входят следующие задачи:

  • Повторное создание процесса ClaimInvestigation_ASIS в WebSphere MQ Workflow Buildtime.
  • Создание структур данных, которыми процесс будет обмениваться с операцией RequestExternalReports.
  • Определение интерфейса операции RequestExternalReports, через который будет вызываться прокси-процесс RequestExternalReports в WebSphere Business Integration Server Foundation. Будет использоваться JMS-совместимый интерфейс XML Enterprise Service.
    •

    11.3.1 Импортирование рабочего потока ASIS

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

  • Откройте WebSphere MQ Workflow buildtime – FMC.
  • Выберите пункт Buildtime > Import (Импорт), найдите файл .\SG24-6636\Workflow\ClaimInvestigation_ASIS.fdl и нажмите OK (рис 11.2).(рис 11.2) Процесс ClaimInvestigation_ASIS
  • Чтобы открыть процесс ClaimInvestigation, сделайте двойной щелчок по процессу ClaimInvestigation на верхнем уровне.
    •

    11.3.2 Создание структур данных для RequestExternalReports

    Для этого существует несколько способов, но, к сожалению, нельзя импортировать WSDL пряо из Rational Software Architect.

  • Моделировать новые структуры данных прямо в WebSphere MQ Workflow.
  • Моделировать структуры данных в WebSphere Business Integration Modeler и импортировать их в виде FDL.
  • Создать новую XML-схему в WebSphere Studio Application Development Integration Edition.

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

    Альтернативный подход, где мы начинаем с WSDL, заданного целевой службой, и изменяем FDL, который используется WebSphere MQ Workflow, приводя его в соответствие с интерфейсом службы, более соответствует архитектурному направлению, которое мы пытаемся применять. Так что для полноты использования цепочки инструментов, которую мы стараемся применять, ниже описывается, как следует изменить WebSphere MQ Workflow, чтобы он играл роль клиента существующего интерфейса службы.

  • Перейдите к WSDL-файлу, который содержит структуры данных, которые нам нужно импортировать в WebSphere MQ Workflow. Для примера мы используем файл Proxy(1).wsdl.
  • В графическом редакторе WSDL раскройте тип порта RequestExternalReports_UPES и его сообщения и выберите структуру requestAssessor (см. рис 11.3).(рис 11.3) Структуры данных, которые нужно преобразовать в схемы
  • Перейдите на закладку Source (Исходный код), и курсор будет установлен в выбранной структуре. Скопируйте сложный тип requestAssessor.
  • Вставьте тип в новый файл схемы, между тегами схемы.
  • Повторите процесс для типа requestAssessorReponse.
  • Выполните глобальную замену xsd: $$\to$$ <blank>; пространство имен для схемы – заданное по умолчанию.
  • Сохраните изменения. Ошибок не будет.
  • Укажите пространство имен схемы http://workflow.lgi.itso (рис 11.4).(рис 11.4) Схема RequestExtenalReports
  • Экспортируйте файл схемы: выделите файл, нажмите правую кнопку мыши, выберите пункт меню Export (Экспорт) $$\to$$ File system (Файловая система) и укажите директорию для экспорта.
    •

    Конвертирование схемы в FDL

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

  • Откройте проект ITSOLGI в WebSphere Business Integration Modeler.
  • Выберите пункт меню File (Файл) $$\to$$ Import (Импорт) $$\to$$ WebSphere Business Integration Modeler $$\to$$ Import (Импорт) $$\to$$ XML Schema (XML-схема) $$\to$$ Next (Далее). Выберите файл RequestExternalReports.xsd, укажите в качестве целевого проекта ITSOLGI и нажмите Next (Далее). Должен быть выбран бизнес-элемент ( Business Item ). Нажмите Finish (Готово), а затем OK.
  • Выберите папку workflow.lgi.itso, нажмите Export (Экспорт) $$\to$$ WebSphere MQ Workflow FDL. Укажите целевую директорию – папку itso.lgi.workfow, выберите Export specific items (Экспорт специфических элементов) $$\to$$ Finish (Готово) $$\to$$ OK.
    •

    Импортирование в WebSphere MQ Workflow

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

  • Перейдите на закладку Implementation (Реализация) в WebSphere MQ Workflow Buildtime.
  • Выберите пункт Buildtime > Import (Импорт). Укажите файл ITSOLGI.fdl, который был экспортирован из Modeler.
  • Удалите w_ из имен структур данных, открыв свойства этих двух структур данных и изменив их свойство Name (Имя).
    •

    11.3.3 Определение интерфейса для RequestExternalReports

    Теперь нам нужно определить интерфейс рабочего потока для изучения претензий, который мы будем использовать для вызова процесса RequestExternalReports в WebSphere Business Integration Server Foundation.

    С точки зрения WebSphere MQ Workflow-процесс RequestExternalReports – это простая автоматизированная операция, которая вызывает процесс RequestExternalReports путем отправки сообщения JMS/XML при помощи WebSphere MQ. По окончании процесс RequestExternalReports возвращает операции RequestExternalReports другое сообщение.

    Единственный дополнительный этап, необходимый для того, чтобы система WebSphere MQ Workflow могла вызывать BPEL-процесс в WebSphere Business Integration Server Foundation, – это экспортирование из системы Workflow WSDL-файла, содержащего полное определение структур сообщений, передаваемых в систему Workflow и из нее. Этот файл может использоваться для определения процесса ClaimInvestigation как партнерской ссылки в процессе RequestExternalReports.

    Создание UPES для операции RequestExternalReports

    UPES (заданный пользователем сервер выполнения программы) определяет, как автоматизированная операция взаимодействует с внешней программой при выполнении автоматизированной операции от имени рабочего потока. Существует две формы UPES – синхронный и асинхронный. Асинхронный UPES не возвращает управление в WebSphere MQ Workflow. Синхронный UPES заставляет операцию ожидать завершения выполнения. Срок выполнения может быть длительным. Мы будем использовать синхронный UPES.

    На практике UPES реализуется как очередь WebSphere MQ. Рабочий поток помещает сообщение во входную очередь UPES, когда есть работа, которую нужно выполнить, а программная операция прослушивает очередь, извлекает сообщение и выполняет операцию. По завершении работы программная операция посылает в Workflow сообщение-ответ. Хотя для прослушивания входной программной операцией создается специфическая входная очередь UPES, в Workflow по умолчанию, как правило, есть только одна очередь ответов, EXECXMLINPUTQ, которая прослушивается на предмет поступления сообщений-ответов.

    Cоздание UPES

    Для создания UPES выполните следующие действия:

  • Выберите пункт меню BuildTime $$\to$$ закладка Network (Сеть) $$\to$$ DOMAIN (Домен) $$\to$$ FMCGRP.
  • Щелкните правой кнопкой мыши по FMCSYS и выберите пункт меню New UserDefined Program Execution Server (Новый пользовательский сервер выполнения программ).
  • На закладке General (Общие) укажите в поле имени значение UPESSVR, выберите версию 3.4.0 в раскрывающемся списке версий.
  • На закладке Message Queuing (Очереди сообщений) укажите в поле Queue Name (Имя очереди) значение WPCUPESQ, а поле Queue Manager Name (Имя менеджера очереди) оставьте пустым.Важно! Мы используем кластеризацию WebSphere MQ, и эта очередь будет кластерной очередью, определенной на машине с WebSphere Business Integration Server Foundation. Если вы не используете кластеризацию, то имя очереди должно представлять собой определение удаленной очереди или ее псевдоним. Плохой практикой является явное определение имени менеджера очереди, поскольку уменьшается прозрачность местоположений.
  • Укажите в поле Message Format (Формат сообщений) значение JMS-compliant XML (JMS-совместимый XML) и нажмите OK.
    •

    Создание программы для RequestExternalReports

    Это программа, которая будет использоваться операцией RequestExternalReports; она должна иметь то же имя, которое имеет и программа, которую мы собираемся создать в WebSphere Studio Application Development Integration Edition для запуска процесса RequestExternalReports.

  • На закладке BuildTime перейдите на закладку Implementations (Реализации), щелкните правой кнопкой мыши по элементу Programs (Программы) и выберите пункт меню New Program (Новая программа).
  • На закладке General (Общие) в поле Name (Имя) введите RequestExternalReportsProxy.
  • На закладке Data (Данные):
  • включите опцию Program requires these data structures (Программе требуются следующие структуры данных) > Input (Вход), найдите элемент requestAssessor и нажмите OK ;
  • для поля Output (Выход) найдите элемент requestAssessorResponse и нажмите OK ;
  • включите опцию ).
    •  (рис 11.5) Определение свойств данных для RequestExternalReportsProxy
  • На закладке Windows NT $$\text{\textregistered}$$ в поле Path and file name (Путь и имя файла) введите RequestExternalReportsProxy.exe.

    Мы могли бы ввести в это поле любое имя, поскольку исполняемый файл никогда не вызывается, и он не должен существовать в файловой системе. Он нужен только потому, что рабочей системе WebSphere MQ Workflow необходимо, чтобы существовало хотя бы одно определение платформы для программы, иначе определение будет считаться недействительным.

  • Нажмите OK.

    • Конфигурирование операции RequestExternalReports

    Теперь нам нужно настроить операцию и связи данными, в которых задействована операция:

  • В меню BuildTime выберите пункт Process Models (Модели процесса) $$\to$$ Claim $$\to$$ закладка Processes (Процессы) $$\to$$ ClaimInvestigation $$\to$$ RequestExternalReports.
  • На закладке General (Общие) измените значение в поле Name (Имя) на RequestExternalReportsProxy.
  • На закладке Execution (Выполнение):
  • отключите опцию User program execution agent (Пользовательский агент выполнения программы);
  • отметьте пункт Server (Сервер), найдите сервер UPESSVR, нажмите OK.
    •
  • На закладке Start (Запуск) убедитесь, что включена опция Automatic (Автоматически).
  • На закладке Exit (Выход) убедитесь, что включена опция Automatic (Автоматически).
  • На закладке Data (Данные):
  • в поле Input (Входные) найдите элемент requestAssessor и нажмите OK ;
  • в поле Output (Выходные) найдите элемент requestAssessorResponse и нажмите OK.
  • Нажмите OK.

    • Конфигурирование связей для потоков данных

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

  • Сделайте двойной щелчок мышью по зеленому коннектору (рис 11.6), расположенному между операциями SelectReports и RequestExternalReports ; нажмите OK в двух окнах с предупреждениями о том, что структуры данных некорректны. Мы собираемся исправить эти ошибки.(рис 11.6) Выберите коннектор потока данных, идущих к операции RequestExternalReports
  • Установите указанные ниже связи, перетаскивая поле столбца Member (Член) структуры Origin Data Structure (Исходная структура данных) в поле Member структуры ):(рис 11.7) Связывание входных структур данных для RequestExternalReports
  • Investigate_DataInput.Claim_DataInput.ClaimID $$\to$$ claimID;
  • Investigate_DataInput.PolicyID $$\to$$ policyID;
  • Report_Claim.AssReqDate $$\to$$ requiredDate;
  • Investigate_DataInput.LocVehicle $$\to$$ location;
  • Investigate_DataInput.MakeOfCar $$\to$$ makeOfCar.
    •
  • Повторите процедуру для коннектора, расположенного между операциями RequestExternalReports и UpdateExternalReports. Снова игнорируйте появляющиеся предупреждения. Свяжите следующие поля и нажмите OK (рис 11.8).
  • claimID $$\to$$ Investigate_DataInput.Claim_DataInput.ClaimID;
  • policyID $$\to$$ Investigate_DataInput.PolicyID;
  • assCompDate $$\to$$ Report_Claim.AssActDate;
  • reportLocal $$\to$$ Investigate_DataInput.AppEstRep.
    • (рис 11.8) Связывание выходных структур данных для RequestExternalReports

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

    Следующий шаг – это экспортирование FDL, чтобы мы могли определить структуру сообщений для процесса RequestExternalReports, работающего в WebSphere Business Integration Server Foundation.

  • Выберите процесс ClaimInvestigation на закладке Process (Процесс). Щелкните правой кнопкой мыши и выберите пункт меню Save (Сохранить).
  • Выберите пункт меню BuildTime > Export (Экспорт) > Export single objects (Экспорт одиночных объектов).
  • В разделе Show objects (Показать объекты) выберите все опции и нажмите Refresh (Обновить), чтобы увидеть все элементы модели.
  • Выделите элемент ClaimInvestigation process (если удерживать клавишу Shift и сделать щелчок мышью, значок окажется отмеченным). Включите также опцию Export deep (Экспорт нижележащих), чтобы экспортировались также структуры данных и программы, на которые ссылается процесс.
  • Выберите (Shift+левая кнопка мыши) UPES-сервер UPESSVR, найдя его в элементе Network (Сеть), и нажмите OK.
  • Выберите папку для экспорта и сохраните файл под именем Proxy(1).fdl. Нажмите OK.
    •

    11.4 Размещение процесса

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

    Чтобы разместить поток в рабочей системе (runtime), нужно импортировать в рабочую систему FDL. Импортирование можно производить прямо на сервере рабочей системы или с использованием клиентской машины, на которую установлены административные компоненты WebSphere MQ Workflow.

    Чтобы импортировать модель процесса в рабочую систему, мы используем утилиту fmcibie с такими опциями, как:

  • опция –i, указывающая файл, который мы хотим импортировать;
  • параметр –y, указывающий имя конфигурации;
  • параметры –u и –p, которые используются для указания имени и пароля администратора рабочего потока;
  • параметр –to, который заставляет утилиту перезаписывать имеющиеся объекты, если это необходимо, и преобразовывать модель процесса в шаблон процесса, который может выполняться в рабочей среде.
    •

    На рис. 11.9 показаны результаты запуска утилиты fmcibie в директории interop 5.1.1\bin, где был сохранен файл Proxy(1).fdl.

    (рис 11.9) Запуск утилиты fmcibie для размещения рабочего потокаСовет. Возможно, вам повезет не сразу. Поскольку система времени выполнения не синхронизована с системой компоновки, в команде размещения процесса могут использоваться неверные операторы, например UPDATE вместо REPLACE. Вам нужно отредактировать все проблемные команды UPDATE в файле Proxy(1).fdl, которые привели к появлению ошибок. Просто удалите ключевое слово UPDATE, и при размещении будет выполняться команда CREATE, что должно сработать.

    11.5 Заключение

    В этой лекции мы кратко рассмотрели систему WebSphere MQ Workflow и затем показали, как при минимальных изменениях существующего процесса обработки претензий можно ввести в него вызов автоматизированной операции RequestExternalReports с использованием UPES-сервера в качестве агента выполнения операции. UPES-сервер – это фактически очередь WebSphere MQ. В лекции 12, "Интеграция и тестирование бизнес-процессов", рассматривается задача интеграции с WebSphere Business Integration Server Foundation после завершения всех остальных частей сценария. Интеграция не требует внесения изменений в рабочий поток, и она осуществляется путем инсталляции вспомогательного пакета (supportpac), который содержит инструменты интеграции и процессы времени выполнения, которые работают на WebSphere Business Integration Server Foundation.

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