Интеграция и тестирование бизнес-процессов

12.2 Общий обзор пакета SupportPac WA0D

В данном вспомогательном пакете предлагается возможность вызова процесса Choreographer из WebSphere MQ Workflow и наоборот. Для этого требуется понимать интерфейсы WebSphere MQ Workflow и Process Choreographer.

12.2.1 Интерфейсы WebSphere MQ Workflow

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

Информация о процессах WebSphere MQ Workflow, инфраструктуре и задействованных сотрудниках (персонале) становится известна серверу выполнения после заполнения соответствующими данными базы данных рабочей системы. Делается это путем импортирования файла с кодом языка определения потоков (FDL), который генерируется с помощью WebSphere MQ Workflow Buildtime или иного инструмента, сходного с WebSphere Business Integration Modeler.

Сервер выполнения использует для обмена сообщениями между очередями Web-Sphere MQ два формата сообщений:

• SDDS – внутренний формат WebSphere MQ Workflow;
• XML – часть, входящая в сообщения XML-формата SDDS, а также включающая JMS-заголовки для поддержки протокола JMS.

12.2.2 Интерфейсы Process Choreographer

Компоненты Choreographer можно сконфигурировать под использование WebSphere MQ в качестве провайдера JMS, чтобы можно было посылать и получать сообщения через очереди WebSphere MQ.

В Process choreographer для связи с внешним миром существует два основных интерфейса:

• API и фасадные компоненты, управляемые сообщениями (facade message driven beans).

  Доступ к базовой функциональности Choreographer осуществляется через API для работы с шаблонами процесса, экземплярами процессов, экземплярами операций и рабочими элементами. Кроме того, для каждого процесса генерируется специфичный для него EJB-компонент – дополнительный фасадный MDB. Фасадный MDB представляет процесс в соответствии с шаблоном проектирования фасада (facade design pattern). За дополнительной информацией о шаблонах проектирования обращайтесь по адресу http://www.research.ibm.com/designpatterns/

  Фасадный MDB позволяет отправлять JMS-сообщения пользовательского формата в выделенную очередь. Прием такого сообщения MDB-компонентом приводит к неявному вызову соответствующего процесса. По завершении процесса ответ отправляется в очередь ответов, указанную в запросе.
• Дополнительные модули (плагины ) Choreographer.

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

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

12.2.3 Архитектура вспомогательного пакета

SupportPac состоит из двух основных компонентов:

• Инструменты, инсталлированные на сервер MQ WorkFlow.

  Эти инструменты предоставляют возможность экспортировать WSDL-файл существующего процесса BuildTime из пользовательского интерфейса BuildTime. Этот файл применяется, когда нам нужно вызвать процесс WebSphere MQ Workflow из WPC. Существует еще одна утилита, запускаемая из командной строки, для генерации WSDL-файла из файла FDL, и она используется, когда нужно вызвать WPC-процесс из WebSphere MQ Workflow. Об этом подробно рассказывается в следующих разделах.
• Компонент, управляемый сообщениями (Message-driven bean, MDB), установленный в WebSphere BI Server Foundation.

  Помимо упомянутых инструментов, в SupportPac включен MDB в форме EAR-файла (Enterprise Archive). Разместите его в WebSphere BI Server Foundation, где этот MDB будет прослушивать вызывающие сообщения, прибывающие в очередь MQ (очередь UPES), интерпретировать эти сообщения и вызывать соответствующий WPC-процесс.

Подробнее об этих компонентах, реализующих возможности SupportPac, рассказывается в следующем разделе.

12.2.4 Как работает SupportPac

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

• как процесс WebSphere MQ Workflow вызывает процесс Choreographer;
• как процесс Choreographer вызывает процесс WebSphere MQ Workflow.

Мы остановимся только на первом сценарии, который был реализован в нашем решении.

Как WebSphere MQ Workflow вызывает Choreographer

Предположим, что мы уже имеем:

• интерфейс процесса Choreographer с именем;
• входные и выходные данные;
• процесс WebSphere MQ Workflow, в котором одна из операций отвечает за вызов процесса Choreographer.

Данная операция определена как автоматизированная, не требующая вмешательства операция с определением UPES, ссылающимся на очередь WebSphere MQ. Кроме того, мы должны определить программу, которая имеет то же имя, входные и выходные структуры данных, как и процесс, вызываемый в Choreographer. Мы будем использовать эту программу для программирования данной операции.

После завершения шагов, связанных с моделированием, мы экспортируем FDL-файл, содержащий внесенные модификации, и используем входящую в SupportPac утилиту (runfdl2wsdl.bat), работающую из командной строки, для генерации WSDL-файла с интерфейсом для WPC-процесса. В нем определяются структуры входящего и исходящего сообщений бизнес-процесса Process Choreographer. Сгенерированный WSDL-файл содержит определения интерфейсов всех процессов и всех операций UPES, имеющихся во входном FDL-файле.

WSDL-файл нужно импортировать в WebSphere Studio Application Development Integration Edition для генерации соответствующих объектов, представляющих собой сообщения. После этого мы создаем процесс в WebSphere Studio Application Development Integration Edition и используем WSDL-файл как партнерскую ссылку для принимающих и отвечающих операций и моделирования внутреннего функционирования процесса в WebSphere Studio Application Development Integration Edition. Эти этапы иллюстрируются на рис. 12.1.

Рис. 12.1. Этапы вызова процесса Choreographer из WebSphere MQ Workflow

Для каждой интеграции нам требуется уникальный процесс Choreographer. Чтобы процессы WebSphere MQ Workflow могли взаимодействовать с существующим процессом Choreographer, мы можем создать в процессе новую операцию, которая запускает существующий процесс Choreographer. Это шаблон проектирования с прокси, поскольку новый процесс Choreographer является оболочкой или прокси для существующего процесса Choreographer. Он управляет доступом к существующему процессу, обеспечивая совместимость с интерфейсом при взаимодействии.

Выполнение

Когда выполняется процесс MQ Workflow и запускается операция UPES, сервер выполнения посылает для WebSphere MQ Workflow XML-сообщение типа ActivityImplInvoke в указанную очередь UPES. MDB-компонент, входящий в SupportPac, читает это сообщение, получает из него имя программы, выполняет в Choreographer поиск процесса, имеющего то же имя, что и программа, и вызывает его, передавая ему данные, включенные в сообщение. По завершении процесса MDB преобразует ответ процесса в XML-сообщение WebSphere MQ Workflow типа ActivityImplInvokeRes ponse и помещает его во входную очередь WebSphere MQ Workflow. По умолчанию входной очередью для XML-сообщений сервера выполнения в WebSphere MQ Workflow является EXEXMLINPUTQ.

На рис. 12.2 показаны этапы выполнения, когда процесс WebSphere MQ Workflow вызывает процесс Choreographer.

увеличить изображение
Рис. 12.2. Интеграция процессов