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

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

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

В лекции 11, "Изменение процесса обработки претензий", мы описывали, как следует изменить процесс обработки претензий, чтобы он мог использовать автоматизированный процесс RequestExternalReports. Однако мы не объяснили, как сообщение-запрос, поступающее от процесса обработки претензий, будет вызывать запуск процесса RequestExternalReports и получение от него ответа, возможно после нескольких недель ожидания. В этой лекции мы описываем интеграцию процесса обработки претензий с новой автоматизированной операцией RequestExternalReports.

Для нашего решения требуется новый вспомогательный пакет (supportpac) WA0D и обновление WebSphere Application Server до версии 5.1.1.7, а WebSphere Business Integration Server Foundation – до версии 5.1.1.3.

12.1 Интеграция WebSphere MQ Workflow и WebSphere BI Server Foundation

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

Данные вспомогательные пакеты можно легко скачать с Web-сайта IBM по адресу http://www.ibm.com/software/integration/support/supportpacs/product.html#wmqwf

12.1.1 Какой вспомогательный пакет использовать?

Существует два вспомогательных пакета, удовлетворяющих нашему требованию возможности вызова WebSphere Business Integration Server Foundation из WebSphere MQ Workflow:

  • WA07: WebSphere MQ Workflow Web services Process Management Toolkit.

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

    Кроме того, данный инструментарий может использоваться для размещения любого бизнес-процесса WebSphere MQ Workflow в виде службы потока (flow service), т. е. Web-службы, обеспечивающей доступ к протоколу жизненного цикла бизнес-процесса.

  • 2. WA0D: WebSphere MQ Workflow and WAS Enterprise Process Choreographer Inter- Operability.

    Данный вспомогательный пакет обеспечивает взаимодействие между WebSphere MQ Workflow и WebSphere Business Integration Server Foundation. Наличие возможности работать с процессами, охватывающими оба продукта, сводит воедино сильные стороны обоих продуктов и позволяет безболезненно и постепенно переносить имеющиеся процессы из WebSphere MQ Workflow в Process Choreographer.

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

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

  • 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) Интеграция процессов

    12.3 Инсталляция и конфигурирование WA0D SupportPac

    Инсталляция и конфигурирование WA0D SupportPac включает в себя следующие шаги, показанные на рис 12.3. Эти шаги описаны в соответствующим образом пронумерованных абзацах ниже.

    (рис 12.3) Инсталляция и конфигурирование WA0D
  • Обновление WebSphere Application Server и WebSphere Business Integration Server Foundation пакетами cumulative fix pack 3 и 7 соответственно, если эти пакеты еще не были установлены.
  • WPCUPESQ – это очередь (кластеризованная), которая получает запросы от системы Workflow для отправки в Process Choreographer.
  • Пакет WA0D инсталлируется в систему Workflow, на которой также должен быть установлен WebSphere Application Server.
  • Процесс Workflow использует программную задачу, и UPES-сервер конфигурируется для размещения WPC-запросов в WPCUPESQ. Мы делаем этов разделе 11.3.3, "Определение интерфейса для RequestExternalReports".
  • FDL процесса и определение UPES экспортируются в FDL-файл (см. раздел "Экспорт FDL").
  • Команда runfdl2wsd l, входящая в WA0D, преобразует FDL в WSDL, принимаемый WebSphere Studio Application Development Integration Edition для определения процесса proxyRequestExternalReports.
  • Исталляция плагина Eclipse com.ibm.workflow.wmqwf_1.0.0 в WebSphere Studio Application Development Integration Edition.

    Извлеките файл com.ibm.workflow.wmqwf_1.0.0.zip из директории, в которую вы установили WA0D, в инсталляционную директорию WebSphere Studio Application Development Integration Edition, поддиректорию \eclipse\plugins, и перезапустите WebSphere Studio Application Development Integration Edition.

  • Создайте новый прокси-процесс RequestExternalReportsProxy в WebSphere Studio Application Development Integration Edition для приема запросов от программной операции RequestExternalReportsProxy процесса ClaimInvestigation системы Workflow. Совпадение имен определяет маршрутизацию запроса в нужный процесс Process Choreographer.
  • Добавьте в новый процесс файл WMQ_Formatter.jar и добавьте его в компоновочный путь Java. Этот JAR-файл обрабатывает входящее сообщение JMS/XML.
  • (Замените файл bpeInterop.jar в библиотеке WebSphere Business Integration Server Foundation тем файлом, который поставляется с SupportPac.) Этот этап не является обязательным, если вы работаете с WebSphere Business Integration Server Foundation cumulative Fix Pack 3 и WebSphere Application Server cumulative Fix Pack 7.
  • Инсталлируйте и запустите файл bpeInterop.ear в WebSphere Business Integration Server Foundation. Это общий фасадный MDB-компонент, который осуществляет маршрутизацию и запуск процесса RequestExternalReportsProxy.
  • Используя административную консоль WebSphere Application Server, подключенную к WebSphere Business Integration Server Foundation, сконфигурируйте провайдер сообщений WebSphere MQ. Это описано ниже, в разделе 12.3.1, "Обновление WebSphere Business Integration Server Foundation".
  • Инсталлируйте и запустите EAR-файлы RequestExternalReportsProxy на WebSphere Business Integration Server Foundation.
  • 12.3.1 Обновление WebSphere Business Integration Server Foundation

    Вспомогательный пакет WA0D требует применения исправлений к WebSphere Business Integration Server Foundation, которые, в свою очередь, требуют обновления WebSphere Application Server. Инструкции по проведению обновления приводятся в разделе 7.3.3, "WebSphere Business Integration Server Foundation".

    12.3.2 Определение очереди WPCUPESQ

    В данном примере мы определим локальную очередь WPCUPESQ на машине SAH414B, используя WebSphere MQ Explorer, и сделаем ее членом кластера FMCGRP.

    12.3.3 Инсталляция WA0D

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

    (рис 12.4) Как убедиться, что вспомогательный пакет установлен на машине SAH414A
  • Создайте поддиректорию в инсталляционной директории Workflow, например с именем WA0D, скопируйте инсталляционный файл interop.exe и запустите его.
  • В ответ на приглашение укажите местоположение WebSphere Application Server.
  • В ответ на приглашение указать местоположение рабочей системы Java (Java runtime) укажите местоположение Java-системы WebSphere Application Server.
  • 12.3.4 Конфигурирование процесса изучения претензий

    Убедитесь, что операция RequestExternalReports была модифицирована для правильного вызова UPES, как это описано в разделе 11.3.3, "Определение интерфейса для RequestExternalReports".

  • Программная операция должна быть названа RequestExternalReportsProxy.
  • UPES-сервер должен быть назван UPESSVR и указывать на менеджер очереди FMCQM и очередь WPCUPESQ.
  • Реализация программы должна быть названа RequestExternalReportsProxy.
  • Контейнеры входных и выходных данных должны быть связаны.
  • 12.3.5 Генерация FDL

    Мы описывали экспортирование измененного FDL из процесса ClaimInvestigation в разделе "Экспорт FDL".

    12.3.6 Генерация WSDL для прокси-процесса

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

  • Откройте окно командной строки и сделайте текущей папкой папку bin инсталляционной папки InterOp, для чего, например, введите такую команду:
    cd D:\mqworkflow\SMP\InterOp5.1.1\bin
  • Выполните файл setenv.bat, введя следующую команду:
    setenv.bat
  • Сгенерируйте WSDL-файл, введя приведенную ниже команду. Будет сгенерирован и сохранен файл Proxy.wsdl:
    runfdl2wsdl Proxy.fdl Proxy.wsdl
  • Проверьте WSDL-код в вашем любимом редакторе. Вы сможете увидеть определения интерфейса RequestExternalReports, встроенные в более крупные структуры данных.

    12.3.7 Инсталляция плагина Eclipse как вспомогательного пакета

    Извлеките файл com.ibm.workflow.wmqwf_1.0.0.zip из директории, в которую вы установили WA0D, в поддиректорию \eclipse\plugins инсталляционной директории WebSphere Studio Application Development Integration Edition и перезапустите WebSphere Studio Application Development Integration Edition.

    12.3.8 Создание процесса RequestExternalReportsProxy

    Выполните следующие шаги:

  • Убедитесь, что вы сохранили файл Project Interchange для проектов RequestExternalReports.
  • Откройте новое рабочее пространство и импортируйте проект службы ITSOLGI из zip-файла Project Interchange с именем RequestExternalReports.
  • Выполните шаг, описанный в разделе 12.3.9, "Добавление в процесс файла WMQ_Formatter.jar", а затем перейдите к следующему шагу.
  • Создайте новый бизнес-процесс (рис 12.5). Используйте мастер создания бизнес-процессов, предлагаемый во всплывающем меню.(рис 12.5) Добавление долговременно работающего прокси-процесса
  • Задайте атрибут long running (долговременный) для бизнес-процесса на закладке Server (Сервер) процесса RequestExternalReportProxy.
  • Добавьте в процесс поток и поместите в поток операции запроса и ответа.
  • Импортируйте файл proxy.wsdl в новый пакет и перенесите WSDL-файл на канву, чтобы создать новую ссылку на партнера.
  • Создайте новую переменную OutputVariable и соедините операции приема и ответа. Не забудьте задать роль.
  • Временно соедините операции запроса и ответа, сохраните поток и проверьте, нет ли ошибок компиляции.
  • Перетащите процесс RequestExternalReports в поток и свяжите его с вызывающей задачей (Invoke), создав две новые входные и выходные переменные с именами RequestExternalReportsInputVariable и RequestExternalReportsOutputVariable. Свяжите входное и выходное сообщения из файла ExternalClaimsAssessorInterface.wsdl. Задайте действие (Operation) для вызывающей операции.
  • Вновь установите связи в потоке, сохраните его и проверьте, чтобы не было ошибок компиляции.
  • Теперь вам нужны две трансформирующие службы: простая трансформирующая служба для входа процесса RequestExternalReports и агрегирующая трансформирующая служба для выхода. Часть входных данных нужно передавать обратно в поток. Вы должны ссылаться на пакет Claim.TOBE.Proxy:
  • используйте мастер создания простых трансформаций для создания трансформации TransformRequestExternalReports, перетащите ее на канву и установите соединения;
  • при создании агрегирующей трансформации обращайтесь к wsdl AggregateReplyRequestExternalReportProxy.
  • Сохраните поток, показанный на рис 12.6.(рис 12.6) Долговременно работающий прокси-процесс, вызывающий процесс RequestExternalReports
  • Сгенерируйте код размещения для процесса RequestExternalReports.
  • Создайте тестовый сервер в WebSphere Studio Application Development Integration Edition, добавьте в него проект ITSOLGI, создайте таблицы базы данных и выполните модульное тестирование потока.
  • 12.3.9 Добавление в процесс файла WMQ_Formatter.jar

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

  • Выберите проект службы, нажмите Import (Импорт) $$\to$$ File system (Файловая система), найдите файл WMQWF_Formatter.jar во вспомогательном пакете и нажмите Finish (Готово).
  • Щелкните правой кнопкой мыши по папке ShortRunningProcess, выберите пункт меню Properties (Свойства) $$\to$$ Java Build Path (Компоновочный путь Java), перейдите на закладку Libraries (Библиотеки), выберите Add JARs (Добавить JAR-файлы) $$\to$$ WMQWF_Formatter.jar $$\to$$ OK $$\to$$ OK.
  • 12.3.10 Замена файла bpeInterop.jar в библиотеке сервера

    Этот шаг не является необходимым, если вы устанавливаете WA0D поверх WebSphere Business Integration Server Foundation 5.1.1.3.

    12.3.11 Установка файла bpeInterop.ear

    Чтобы установить файл bpeInterop.ear, выполните следующие шаги:

  • Откройте административную консоль WebSphere Business Integration Server Foundation, введя в браузер следующий адрес:
    http://SAH414B:9090/Admin
  • В разделе Applications (Приложения) выберите Install (Инсталляция) $$\to$$ bpeInterop.ear.
  • Проверьте привязки по умолчанию, задайте короткое имя директории, например D:\Apps в качестве инсталляционной директории, и установите флажок Deploy EJBs (Размещать EJB-компоненты).
  • В шаге 2 (рис 12.7) укажите в качестве порта слушателя (Listener port) значение InteropMDBListenerPort.(рис 12.7) Конфигурирование порта слушателя для MDB-компонента, обеспечивающего взаимодействие
  • Сохраните конфигурацию и запустите приложение.
  • Конфигурирование ресурсов для обмена сообщениями

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

  • Убедитесь, что фабрика соединений очереди jms/BPECF указывает на менеджер очереди, находящийся на сервере WebSphere Business Integration Server Foundation.
  • Добавьте два новых пункта назначения: jms/WPCUPESQ для входящих запросов и FMC.FMCGRP.EXE.XML для исходящих ответов и запросов (рис 12.8).(рис 12.8) Конфигурирование jms/WPCUPESQПоле Queue manager (Менеджер очереди) остается пустым. В нашем примере менеджером очереди по умолчанию является SAH414B (рис 12.9).(рис 12.9) Конфигурирование пункта назначения FMC.FMCGRP.EXE.XML
  • Определите на сервере порт слушателя для MDB-компонента bpeInterop, которому присвойте имя InterOpMDBListenerPort (рис 12.10).(рис 12.10) Конфигурирование порта слушателя bpeInteropСо вспомогательным пакетом поставляется jacl-скрипт InterOp_Sample1_config.jacl, который можно изменять для настройки параметров взаимодействия. Образец настройки параметров рабочей среды в скрипте иллюстрируется в примере 12.1.
  • #####################################################################
    # SETUP MQ Queue Connector Factory, MQ queue name and listener port
    ##
    for IBM MQ Websphere Workflow Inter operability support pack
    ##
    ####################################################################
    set MQINSTALLROOT "D:\\WebSphere MQ"
    set InterOp_HOME "D:\\Interop5.1.1"
    set serverName "server1"
    set FMCQM_QCF_Name "FMCQM"
    set EXEXMLINPUTQ_QName "FMC.FMCGRP.EXE.XML"
    set MYUPESQ_QName "WPCUPESQ"
    set ListenerPort_Name "InterOpMDBListenerPort"
    set JMSProviderName "WebSphere MQ JMS Provider"
    set nodeName $env(local.node)
    D:\Websphere\AppServer\bin\wsadmin -f InterOp_Sample_config.jacl

    Вам также нужно изменить строчку, которая устанавливает образец бизнес-процесса. Измените приведенные ниже строки, чтобы они указывали на файл RequestExt ernalReportsProxy.ear.

    puts "Install sample 1 ear file: WMQWF2WPC.ear"
    $AdminApp install $InterOp_HOME\\samples\\WMQWF2WPC\\WMQWF2WPC.ear

    Запустите скрипт, используя команду wsadmin:

    D:\Websphere\AppServer\bin\wsadmin -f InterOp_Sample_config.jacl

    12.3.12 Инсталляция процесса RequestExternalReportsProxy

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

  • Используйте описанную выше процедуру установки, но на этот раз не указывайте порт слушателя.
  • Назовите приложение RequestExternalReportsProxy.
  • Если вам нужно переустановить EAR-файл, остановите приложение и бизнес-процесс.
  • Совет. Если вам нужно переустановить приложение, вам нужно остановить его перед деинсталляцией. Признаком успешного останова является изменение цвета значка выполнения на красный. Вам нужно остановить все задачи, включая длительно выполняющиеся, прежде чем вы сможете остановить приложение. Однако попытка деинсталляции может оказаться неудачной.

    Эту проблему можно решить путем ручного останова контейнера бизнес-процесса. Нажмите Enterprise Applications (Корпоративные приложения) $$\to$$ RequestExternalReports $$\to$$ EJB Modules (EJB-модули) (в списке Related Items) $$\to$$ Business processes (Бизнес-процессы) $$\to$$ stop the process manually (Остановить процесс вручную). Это поможет решить проблему и позволит деинсталлировать приложение.

    Теперь все готово к тестированию интеграции Workflow и Business Process Choreographer.

    12.4 Тестирование интеграции

    Мы рекомендуем проводить тестирование интеграции в три этапа:

  • Модульное тестирование всего процесса RequestExternalReportsProxy при помощи тестового клиента бизнес-процесса.
  • Новое модульное тестирование процесса ClaimInvestigation.
  • И наконец, тестирование интегрированного процесса путем запуска оценки претензии с помощью тестового клиента Workflow.
  • 12.5 Заключение

    В этой лекции мы описали, как нужно устанавливать, конфигурировать и использовать вспомогательный пакет WA0D для интеграции существующего процесса изучения претензий с новым автоматизированным процессом RequestExternalReports.

    Страницы:

    В лекции 11, "Изменение процесса обработки претензий", мы описывали, как следует изменить процесс обработки претензий, чтобы он мог использовать автоматизированный процесс RequestExternalReports. Однако мы не объяснили, как сообщение-запрос, поступающее от процесса обработки претензий, будет вызывать запуск процесса RequestExternalReports и получение от него ответа, возможно после нескольких недель ожидания. В этой лекции мы описываем интеграцию процесса обработки претензий с новой автоматизированной операцией RequestExternalReports.

    Для нашего решения требуется новый вспомогательный пакет (supportpac) WA0D и обновление WebSphere Application Server до версии 5.1.1.7, а WebSphere Business Integration Server Foundation – до версии 5.1.1.3.

    12.1 Интеграция WebSphere MQ Workflow и WebSphere BI Server Foundation

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

    Данные вспомогательные пакеты можно легко скачать с Web-сайта IBM по адресу http://www.ibm.com/software/integration/support/supportpacs/product.html#wmqwf

    12.1.1 Какой вспомогательный пакет использовать?

    Существует два вспомогательных пакета, удовлетворяющих нашему требованию возможности вызова WebSphere Business Integration Server Foundation из WebSphere MQ Workflow:

  • WA07: WebSphere MQ Workflow Web services Process Management Toolkit.

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

    Кроме того, данный инструментарий может использоваться для размещения любого бизнес-процесса WebSphere MQ Workflow в виде службы потока (flow service), т. е. Web-службы, обеспечивающей доступ к протоколу жизненного цикла бизнес-процесса.

  • 2. WA0D: WebSphere MQ Workflow and WAS Enterprise Process Choreographer Inter- Operability.

    Данный вспомогательный пакет обеспечивает взаимодействие между WebSphere MQ Workflow и WebSphere Business Integration Server Foundation. Наличие возможности работать с процессами, охватывающими оба продукта, сводит воедино сильные стороны обоих продуктов и позволяет безболезненно и постепенно переносить имеющиеся процессы из WebSphere MQ Workflow в Process Choreographer.

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

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

  • 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) Интеграция процессов

    12.3 Инсталляция и конфигурирование WA0D SupportPac

    Инсталляция и конфигурирование WA0D SupportPac включает в себя следующие шаги, показанные на рис 12.3. Эти шаги описаны в соответствующим образом пронумерованных абзацах ниже.

    (рис 12.3) Инсталляция и конфигурирование WA0D
  • Обновление WebSphere Application Server и WebSphere Business Integration Server Foundation пакетами cumulative fix pack 3 и 7 соответственно, если эти пакеты еще не были установлены.
  • WPCUPESQ – это очередь (кластеризованная), которая получает запросы от системы Workflow для отправки в Process Choreographer.
  • Пакет WA0D инсталлируется в систему Workflow, на которой также должен быть установлен WebSphere Application Server.
  • Процесс Workflow использует программную задачу, и UPES-сервер конфигурируется для размещения WPC-запросов в WPCUPESQ. Мы делаем этов разделе 11.3.3, "Определение интерфейса для RequestExternalReports".
  • FDL процесса и определение UPES экспортируются в FDL-файл (см. раздел "Экспорт FDL").
  • Команда runfdl2wsd l, входящая в WA0D, преобразует FDL в WSDL, принимаемый WebSphere Studio Application Development Integration Edition для определения процесса proxyRequestExternalReports.
  • Исталляция плагина Eclipse com.ibm.workflow.wmqwf_1.0.0 в WebSphere Studio Application Development Integration Edition.

    Извлеките файл com.ibm.workflow.wmqwf_1.0.0.zip из директории, в которую вы установили WA0D, в инсталляционную директорию WebSphere Studio Application Development Integration Edition, поддиректорию \eclipse\plugins, и перезапустите WebSphere Studio Application Development Integration Edition.

  • Создайте новый прокси-процесс RequestExternalReportsProxy в WebSphere Studio Application Development Integration Edition для приема запросов от программной операции RequestExternalReportsProxy процесса ClaimInvestigation системы Workflow. Совпадение имен определяет маршрутизацию запроса в нужный процесс Process Choreographer.
  • Добавьте в новый процесс файл WMQ_Formatter.jar и добавьте его в компоновочный путь Java. Этот JAR-файл обрабатывает входящее сообщение JMS/XML.
  • (Замените файл bpeInterop.jar в библиотеке WebSphere Business Integration Server Foundation тем файлом, который поставляется с SupportPac.) Этот этап не является обязательным, если вы работаете с WebSphere Business Integration Server Foundation cumulative Fix Pack 3 и WebSphere Application Server cumulative Fix Pack 7.
  • Инсталлируйте и запустите файл bpeInterop.ear в WebSphere Business Integration Server Foundation. Это общий фасадный MDB-компонент, который осуществляет маршрутизацию и запуск процесса RequestExternalReportsProxy.
  • Используя административную консоль WebSphere Application Server, подключенную к WebSphere Business Integration Server Foundation, сконфигурируйте провайдер сообщений WebSphere MQ. Это описано ниже, в разделе 12.3.1, "Обновление WebSphere Business Integration Server Foundation".
  • Инсталлируйте и запустите EAR-файлы RequestExternalReportsProxy на WebSphere Business Integration Server Foundation.
  • 12.3.1 Обновление WebSphere Business Integration Server Foundation

    Вспомогательный пакет WA0D требует применения исправлений к WebSphere Business Integration Server Foundation, которые, в свою очередь, требуют обновления WebSphere Application Server. Инструкции по проведению обновления приводятся в разделе 7.3.3, "WebSphere Business Integration Server Foundation".

    12.3.2 Определение очереди WPCUPESQ

    В данном примере мы определим локальную очередь WPCUPESQ на машине SAH414B, используя WebSphere MQ Explorer, и сделаем ее членом кластера FMCGRP.

    12.3.3 Инсталляция WA0D

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

    (рис 12.4) Как убедиться, что вспомогательный пакет установлен на машине SAH414A
  • Создайте поддиректорию в инсталляционной директории Workflow, например с именем WA0D, скопируйте инсталляционный файл interop.exe и запустите его.
  • В ответ на приглашение укажите местоположение WebSphere Application Server.
  • В ответ на приглашение указать местоположение рабочей системы Java (Java runtime) укажите местоположение Java-системы WebSphere Application Server.
  • 12.3.4 Конфигурирование процесса изучения претензий

    Убедитесь, что операция RequestExternalReports была модифицирована для правильного вызова UPES, как это описано в разделе 11.3.3, "Определение интерфейса для RequestExternalReports".

  • Программная операция должна быть названа RequestExternalReportsProxy.
  • UPES-сервер должен быть назван UPESSVR и указывать на менеджер очереди FMCQM и очередь WPCUPESQ.
  • Реализация программы должна быть названа RequestExternalReportsProxy.
  • Контейнеры входных и выходных данных должны быть связаны.
  • 12.3.5 Генерация FDL

    Мы описывали экспортирование измененного FDL из процесса ClaimInvestigation в разделе "Экспорт FDL".

    12.3.6 Генерация WSDL для прокси-процесса

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

  • Откройте окно командной строки и сделайте текущей папкой папку bin инсталляционной папки InterOp, для чего, например, введите такую команду:
    cd D:\mqworkflow\SMP\InterOp5.1.1\bin
  • Выполните файл setenv.bat, введя следующую команду:
    setenv.bat
  • Сгенерируйте WSDL-файл, введя приведенную ниже команду. Будет сгенерирован и сохранен файл Proxy.wsdl:
    runfdl2wsdl Proxy.fdl Proxy.wsdl
  • Проверьте WSDL-код в вашем любимом редакторе. Вы сможете увидеть определения интерфейса RequestExternalReports, встроенные в более крупные структуры данных.

    12.3.7 Инсталляция плагина Eclipse как вспомогательного пакета

    Извлеките файл com.ibm.workflow.wmqwf_1.0.0.zip из директории, в которую вы установили WA0D, в поддиректорию \eclipse\plugins инсталляционной директории WebSphere Studio Application Development Integration Edition и перезапустите WebSphere Studio Application Development Integration Edition.

    12.3.8 Создание процесса RequestExternalReportsProxy

    Выполните следующие шаги:

  • Убедитесь, что вы сохранили файл Project Interchange для проектов RequestExternalReports.
  • Откройте новое рабочее пространство и импортируйте проект службы ITSOLGI из zip-файла Project Interchange с именем RequestExternalReports.
  • Выполните шаг, описанный в разделе 12.3.9, "Добавление в процесс файла WMQ_Formatter.jar", а затем перейдите к следующему шагу.
  • Создайте новый бизнес-процесс (рис 12.5). Используйте мастер создания бизнес-процессов, предлагаемый во всплывающем меню.(рис 12.5) Добавление долговременно работающего прокси-процесса
  • Задайте атрибут long running (долговременный) для бизнес-процесса на закладке Server (Сервер) процесса RequestExternalReportProxy.
  • Добавьте в процесс поток и поместите в поток операции запроса и ответа.
  • Импортируйте файл proxy.wsdl в новый пакет и перенесите WSDL-файл на канву, чтобы создать новую ссылку на партнера.
  • Создайте новую переменную OutputVariable и соедините операции приема и ответа. Не забудьте задать роль.
  • Временно соедините операции запроса и ответа, сохраните поток и проверьте, нет ли ошибок компиляции.
  • Перетащите процесс RequestExternalReports в поток и свяжите его с вызывающей задачей (Invoke), создав две новые входные и выходные переменные с именами RequestExternalReportsInputVariable и RequestExternalReportsOutputVariable. Свяжите входное и выходное сообщения из файла ExternalClaimsAssessorInterface.wsdl. Задайте действие (Operation) для вызывающей операции.
  • Вновь установите связи в потоке, сохраните его и проверьте, чтобы не было ошибок компиляции.
  • Теперь вам нужны две трансформирующие службы: простая трансформирующая служба для входа процесса RequestExternalReports и агрегирующая трансформирующая служба для выхода. Часть входных данных нужно передавать обратно в поток. Вы должны ссылаться на пакет Claim.TOBE.Proxy:
  • используйте мастер создания простых трансформаций для создания трансформации TransformRequestExternalReports, перетащите ее на канву и установите соединения;
  • при создании агрегирующей трансформации обращайтесь к wsdl AggregateReplyRequestExternalReportProxy.
  • Сохраните поток, показанный на рис 12.6.(рис 12.6) Долговременно работающий прокси-процесс, вызывающий процесс RequestExternalReports
  • Сгенерируйте код размещения для процесса RequestExternalReports.
  • Создайте тестовый сервер в WebSphere Studio Application Development Integration Edition, добавьте в него проект ITSOLGI, создайте таблицы базы данных и выполните модульное тестирование потока.
  • 12.3.9 Добавление в процесс файла WMQ_Formatter.jar

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

  • Выберите проект службы, нажмите Import (Импорт) $$\to$$ File system (Файловая система), найдите файл WMQWF_Formatter.jar во вспомогательном пакете и нажмите Finish (Готово).
  • Щелкните правой кнопкой мыши по папке ShortRunningProcess, выберите пункт меню Properties (Свойства) $$\to$$ Java Build Path (Компоновочный путь Java), перейдите на закладку Libraries (Библиотеки), выберите Add JARs (Добавить JAR-файлы) $$\to$$ WMQWF_Formatter.jar $$\to$$ OK $$\to$$ OK.
  • 12.3.10 Замена файла bpeInterop.jar в библиотеке сервера

    Этот шаг не является необходимым, если вы устанавливаете WA0D поверх WebSphere Business Integration Server Foundation 5.1.1.3.

    12.3.11 Установка файла bpeInterop.ear

    Чтобы установить файл bpeInterop.ear, выполните следующие шаги:

  • Откройте административную консоль WebSphere Business Integration Server Foundation, введя в браузер следующий адрес:
    http://SAH414B:9090/Admin
  • В разделе Applications (Приложения) выберите Install (Инсталляция) $$\to$$ bpeInterop.ear.
  • Проверьте привязки по умолчанию, задайте короткое имя директории, например D:\Apps в качестве инсталляционной директории, и установите флажок Deploy EJBs (Размещать EJB-компоненты).
  • В шаге 2 (рис 12.7) укажите в качестве порта слушателя (Listener port) значение InteropMDBListenerPort.(рис 12.7) Конфигурирование порта слушателя для MDB-компонента, обеспечивающего взаимодействие
  • Сохраните конфигурацию и запустите приложение.
  • Конфигурирование ресурсов для обмена сообщениями

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

  • Убедитесь, что фабрика соединений очереди jms/BPECF указывает на менеджер очереди, находящийся на сервере WebSphere Business Integration Server Foundation.
  • Добавьте два новых пункта назначения: jms/WPCUPESQ для входящих запросов и FMC.FMCGRP.EXE.XML для исходящих ответов и запросов (рис 12.8).(рис 12.8) Конфигурирование jms/WPCUPESQПоле Queue manager (Менеджер очереди) остается пустым. В нашем примере менеджером очереди по умолчанию является SAH414B (рис 12.9).(рис 12.9) Конфигурирование пункта назначения FMC.FMCGRP.EXE.XML
  • Определите на сервере порт слушателя для MDB-компонента bpeInterop, которому присвойте имя InterOpMDBListenerPort (рис 12.10).(рис 12.10) Конфигурирование порта слушателя bpeInteropСо вспомогательным пакетом поставляется jacl-скрипт InterOp_Sample1_config.jacl, который можно изменять для настройки параметров взаимодействия. Образец настройки параметров рабочей среды в скрипте иллюстрируется в примере 12.1.
  • #####################################################################
    # SETUP MQ Queue Connector Factory, MQ queue name and listener port
    ##
    for IBM MQ Websphere Workflow Inter operability support pack
    ##
    ####################################################################
    set MQINSTALLROOT "D:\\WebSphere MQ"
    set InterOp_HOME "D:\\Interop5.1.1"
    set serverName "server1"
    set FMCQM_QCF_Name "FMCQM"
    set EXEXMLINPUTQ_QName "FMC.FMCGRP.EXE.XML"
    set MYUPESQ_QName "WPCUPESQ"
    set ListenerPort_Name "InterOpMDBListenerPort"
    set JMSProviderName "WebSphere MQ JMS Provider"
    set nodeName $env(local.node)
    D:\Websphere\AppServer\bin\wsadmin -f InterOp_Sample_config.jacl

    Вам также нужно изменить строчку, которая устанавливает образец бизнес-процесса. Измените приведенные ниже строки, чтобы они указывали на файл RequestExt ernalReportsProxy.ear.

    puts "Install sample 1 ear file: WMQWF2WPC.ear"
    $AdminApp install $InterOp_HOME\\samples\\WMQWF2WPC\\WMQWF2WPC.ear

    Запустите скрипт, используя команду wsadmin:

    D:\Websphere\AppServer\bin\wsadmin -f InterOp_Sample_config.jacl

    12.3.12 Инсталляция процесса RequestExternalReportsProxy

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

  • Используйте описанную выше процедуру установки, но на этот раз не указывайте порт слушателя.
  • Назовите приложение RequestExternalReportsProxy.
  • Если вам нужно переустановить EAR-файл, остановите приложение и бизнес-процесс.
  • Совет. Если вам нужно переустановить приложение, вам нужно остановить его перед деинсталляцией. Признаком успешного останова является изменение цвета значка выполнения на красный. Вам нужно остановить все задачи, включая длительно выполняющиеся, прежде чем вы сможете остановить приложение. Однако попытка деинсталляции может оказаться неудачной.

    Эту проблему можно решить путем ручного останова контейнера бизнес-процесса. Нажмите Enterprise Applications (Корпоративные приложения) $$\to$$ RequestExternalReports $$\to$$ EJB Modules (EJB-модули) (в списке Related Items) $$\to$$ Business processes (Бизнес-процессы) $$\to$$ stop the process manually (Остановить процесс вручную). Это поможет решить проблему и позволит деинсталлировать приложение.

    Теперь все готово к тестированию интеграции Workflow и Business Process Choreographer.

    12.4 Тестирование интеграции

    Мы рекомендуем проводить тестирование интеграции в три этапа:

  • Модульное тестирование всего процесса RequestExternalReportsProxy при помощи тестового клиента бизнес-процесса.
  • Новое модульное тестирование процесса ClaimInvestigation.
  • И наконец, тестирование интегрированного процесса путем запуска оценки претензии с помощью тестового клиента Workflow.
  • 12.5 Заключение

    В этой лекции мы описали, как нужно устанавливать, конфигурировать и использовать вспомогательный пакет WA0D для интеграции существующего процесса изучения претензий с новым автоматизированным процессом RequestExternalReports.

    Вернуться к учебному плану