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

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^{1За дополнительной информацией о 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. Обязательными атрибутами являются имя, версия и представляемая очередь^{2Версия UPES обозначает версию MQ Workflow API, которую поддерживает UPES и, соответственно, определяет, какие сообщения будут посылаться в соответствующую очередь и форматы этих сообщений.}.

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

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

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

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

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

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

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

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