IBM Workplace Forms представляет собой основанную на XML технологию, которая используется для сбора пользовательских данных. Этот процесс во многом напоминает использование традиционных бумажных форм. В документы Workplace Forms можно встраивать как уровень представления данных, так и сложную бизнес-логику. Собранные формой данные используются для запуска бизнес-процессов. Важно, что формы Workplace Forms можно легко интегрировать в сервис-ориентированные архитектуры (SOA). Например, при использовании языка Business Process Execution Language (BPEL) задачи бизнес-процессов создаются как Web-сервисы. Для интеграции форм Workplace Forms в эти бизнес-процессы требуется сопоставление моделей данных форм и Web-сервисов (т. е. экземпляров XForms с WSDL и WSDL с экземплярами XForms).

Новая платформа IBM Workplace Forms Services Platform и используемая ею встроенная среда выполнения IBM WebSphere Transformation Extender позволяет легко интегрировать электронные формы в SOA. Например, ранее при использовании сервисов SOA (Web-сервисов) в приложении IBM Workplace Forms приходилось вручную писать код, форматирующий ответ Web-сервиса в соответствии с конкретной формой. Как показано в данной статье, с помощью платформы Workplace Forms Services Platform можно быстро создать преобразование WebSphere Transformation Extender, преобразующее ответ Web-сервиса в соответствующий формат, а затем с помощью Workplace Forms API записать получившийся в результате экземпляр непосредственно в форму. Такой подход значительно снижает время, необходимое на разработку приложения Workplace Forms. Другим большим преимуществом платформы Workplace Forms Services Platform является то, что для создания приложений Workplace Forms не требуется глубоких технических знаний, что позволяет пользователям, такими знаниями не обладающим, разрабатывать и развертывать приложения Workplace Forms. .

Платформа IBM Workplace Forms Services Platform

В этом разделе в общих чертах рассматриваются основные функции платформы Workplace Forms Services Platform; подробные сведения по установке и настройке можно получить, ознакомившись со справочной документацией, входящей в комплект поставки продукта. Платформа Workplace Forms Services Platform — новый представитель семейства продуктов Workplace Forms, позволяющий разработчикам быстро интегрировать Workplace Forms в серверные системы. Хотя данная статья посвящена в основном сервисам SOA (Web-сервисам), платформа Workplace Forms Services Platform легко интегрируется с любой технологией, поддерживаемой WebSphere Transformation Extender. .

WebSphere Transformation Extender — это средство преобразования данных, позволяющее без труда сопоставлять данные из разных систем. В настоящее время WebSphere Transformation Extender поддерживает более 40 технологий, в том числе Web-сервисы, базы данных, SAP и т. д. Среду выполнения WebSphere Transformation Extender можно встраивать непосредственно в приложения, которым требуются возможности преобразования данных. Продукт также содержит несколько средств разработки, позволяющих создавать преобразования Transformation Extender. .

Платформа Workplace Forms Services Platform состоит из двух основных компонентов, показанных на рисунке 1:

• Web-приложение, установленное на IBM WebSphere Application Server
• Несколько плагинов Eclipse, добавленных в IBM Workplace Forms Designer

Web-приложение платформы IBM Workplace Forms Services Platform

В основе платформы Workplace Forms Services Platform лежит среда Open Services Gateway Initiative (OSGI). Это позволяет без труда создавать собственные пользовательские пакеты OSGI (плагины), которые можно интегрировать с сервером. См. рисунок 2. Пользователи могут создавать собственные службы OSGI с помощью предоставляемых API. Затем эти пакеты OSGI можно разворачивать на сервере платформы Workplace Forms Services Platform, добавляя их в следующий каталог на сервере:

Пользователи могут создавать собственные пакеты OSGI (плагины) для подключения разных репозиториев к платформе Workplace Forms Services Platform, например Content Manager и FileNet и других. В примере приложения, описываемом в настоящей статье, используется простой репозиторий на основе файловой системы, входящий в состав платформы Workplace Forms Services.

Платформу Workplace Forms Services Platform можно рассматривать как базовую среду, которую можно расширять, создавая пользовательские конвейеры (файлы свойств) и пакеты OSGI и интегрируя их в платформу Workplace Forms Services Platform во время выполнения.

Если требуется новое приложение интеграции Workplace Forms, создаются несколько конвейеров, которые затем можно развернуть на сервере Workplace Forms Services Platform; см. рисунок 2. Эти исполняемые конвейеры служат основой платформы Workplace Forms Services Platform. Конвейер состоит из нескольких каналов, которые выполняются последовательно. В комплект поставки платформы Workplace Forms Services Platform уже входит библиотека каналов многократного использования, однако можно создавать и пользовательские каналы. При получении запросов клиентом Web Dispatcher платформы Workplace Forms Services Platform тот передает их соответствующему конвейеру, вызывая канал Head конвейера.

Платформа Services Platform используется как при разработке, так и во время выполнения. Проекты (представляющие собой приложения Workplace Forms) можно передавать на сервер, загружать с сервера, а также публиковать их на сервере. При заполнении форм пользователями запросы отправляются компоненту сервера Web Dispatcher, который затем инициирует нужный конвейер.

Плагины IBM Workplace Forms Designer

Для IBM Workplace Forms Designer разработано множество плагинов Eclipse, которые позволяют делать следующее:

• Загружать проекты интеграции с сервера платформы Workplace Forms Services Platform, передавать их на этот сервер, а также публиковать их на сервере.
• Создавать деревья типов WebSphere Transformation Extender из моделей данных, содержащихся в форме, а также создавать преобразования Transformation Extender с помощью автоматически генерируемых деревьев типов.

Плагин Component Navigator

Component Navigator — это представление Eclipse, обладающее следующими возможностями:

• Отображает модели данных (например, экземпляры XForms) формы в древовидном списке.
• Позволяет создавать преобразования WebSphere Transformation Extender, сопоставляющие модели данных с серверными системами.

С помощью Component Navigator, показанного на рисунке 3, пользователи могут просматривать модели данных формы, создавать деревья типов Transformation Extender из этих моделей данных, а также запускать конструктор преобразований Transformation Extender для создания преобразований Transformation Extender. Все эти модели данных и созданные артефакты Transformation Extender можно выбирать в древовидном списке Component Navigator.

В начало

Интеграция электронных форм в SOA

В этом разделе показано, как легко интегрировать технологию IBM Workplace Forms в SOA в помощью платформы Workplace Forms Services Platform. Разработку приложения интеграции Workplace Forms можно подразделить на следующие этапы:

Разработка приложения

Разработка и развертывание проекта интеграции Workplace Forms:

1. Необходимо иметь работающие сервисы SOA (Web-сервисы). Следует создать для этих сервисов деревья типов WebSphere Transformation Extender с помощью WebSphere средства Transformation Extender WSDL Importer.
2. Создание нового проекта интеграции в Workplace Forms Designer.
3. Создание или импорт шаблона формы.
4. Создание деревьев типов WebSphere Transformation Extender для всех экземпляров XForms.
5. Создание преобразований WebSphere Transformation Extender.
6. Создание конвейеров SOA.
7. Настройка правил отправки форм с указанием нужных конвейеров
8. Передача всех компонентов на сервер платформы Workplace Forms Services Platform.

Выполнение приложения

Способ доступа пользователей к опубликованным формам в значительной степени зависит от настроек платформы Workplace Forms Services Platform; например, формы могут быть доступны через портлет или просто с HTML-страницы. При публикации проекта на сервере пользователи могут запросить опубликованную форму, а затем заполнить и передать ее. При этом на сервере выполняется несколько конвейеров. Например, приложение с интеграцией Workplace Forms может работать, как показано на рисунке 4.

1. Пользователь вводит URL-адрес в браузер, а тот инициирует конвейер GetForm на сервере платформы Workplace Forms Services Platform. В ходе выполнения этого конвейера необходимый шаблон формы доставляется из репозитория и заполняется данными из базы данных. Конвейер завершает работу, возвратив форму пользователю: она отображается в браузере пользователя.
2. Все кнопки формы можно настроить таким образом, чтобы они указывали на соответствующих конвейер на сервере. В следующем примере конвейера SOA пользовательская кнопка Look Up связывается с конвейером customerlookup.
3. Кнопка передачи формы может указывать на конвейер, который принимает на вход форму целиком, извлекает из нее всю необходимую информацию, инициирует выполнение некоторых бизнес-операций над данными и наконец сохраняет всю форму в базе данных (или репозитории) в виде записи.

См. рисунок 4 здесь.

Конвейер SOA

Как уже говорилось, конвейер состоит из нескольких каналов, которые выполняются последовательно. Канал можно рассматривать как отдельную единицу работы. В поставку платформы Workplace Forms Services Platform входит несколько стандартных каналов, однако можно разрабатывать и собственные каналы в виде пакетов OSGI с помощью предоставляемого API. Затем эти пакеты OSGI можно разворачивать на сервере платформы Workplace Forms Services Platform, добавляя их в каталог расширений (extensions).

Теперь опишем конвейер SOA под названием customerlookup. Этот конвейер является частью приложения Workplace Forms для работы с счетами и наглядно демонстрирует процесс интеграции электронной формы с сервисом SOA. Форма заказа на поставку содержит экземпляр XForms CustomerInformation. Нужно создать конвейер, позволяющий пользователям ввести свой клиентский номер в системе CRM и нажать кнопку, которая передаст введенный номер на сервер и инициирует запуск конвейера customerlookup.

На рисунке 5 показано, что должен сделать WebSphere Transformation Extender: получить номер CRM из экземпляра CustomerInformation, вызвать Web-сервис customerLookup с номером CRM и преобразовать ответ SOAP в подходящий для формы тип XML, т. е. в заполненный экземпляр CustomerInformation.

На рисунке 6 показан полный конвейер customerlookup. В приложении А приведен код, создающий этот конвейер. Конвейеры хранятся в файлах свойств, их можно загрузить во время выполнения с помощью платформы Workplace Lotus Forms Services Platform, поместив файл свойств в каталог "extensions". Для данного конвейера требуется создать один новый канал с именем LoadInstance. Этот канал считывает объект String из объекта запроса, который передается каналу Head. Был создан и добавлен в каталог "extensions" платформы Workplace Forms Services Platform новый пакет OSGI, содержащий этот канал. Подробные сведения о языке описания конвейера в файле свойств можно найти в документации по продукту. (Также можно поместить файл свойств в пакет OSGI, а не развертывать его отдельно.)

Конвейер customerlookup состоит из следующих каналов:

1. Канал Head

   Указывает, какой канал следует выполнять при запуске конвейера; в данном случае это канал LoadInstance. URL-адреса конвейеров имеют следующий формат:

   http://<hostname>:<port number>/wsfp/wfi/<name of pipeline>

   Когда клиент Web Dispatcher получает запрос, он запускает конвейер с именем конвейера и передает ему объект запроса. Кнопки в форме можно настраивать таким образом, чтобы они указывали на определенный конвейер, с помощью соответствующего URL-адреса.

2. Канал LoadInstance

   Когда пользователь нажимает кнопку Look Up в форме (см. рисунок 9), экземпляр CustomerInformation, содержащий номер CRM, отправляется в Web Dispatcher на сервер, конвейер customerlookup запускается и передает объект запроса из Web Dispatcher, а затем этот канал считывает экземпляр CustomerInformation в память из объекта запроса.

3. Канал RepoLoad

   Этот канал загружает преобразование WebSphere Transformation Extender (CustomerlookupMap.mmc) в память конвейера из репозитория. Преобразование WebSphere Transformation Extender CustomerlookupMap, созданное в Workplace Forms Designer, принимает номер CRM, вызывает Web-сервис CustomerLookup и создает на выходе заполненный экземпляр CustomerInformation. Второй экземпляр канала RepoLoad загружает преобразование ParseResponseCL в память конвейера.

4. Канал Map

   Канал map представляет наибольший интерес для нашей статьи. Этот канал вызывает сервис WebSphere Transformation Extender (OSGI) с преобразованием CustomerLookup и номером CRM в качестве параметров. Преобразование WebSphere Transformation Extender CustomerLookup более подробно рассматривается далее, пока же имейте в виду, что когда это преобразование завершается, на выходе получается заполненный экземпляр CustomerInformation, содержащий данные, возвращенные из Web-сервиса CustomerLookup.

   
   
   Листинг 1. Канал Map из файла customerlookup.pipeline.properties; конвейер целиком см. в Приложении A
   

   # Выполнение экземпляра через WebSphere Transformation Extender 1 ibm.MapPipe.customerlookup.map = service:mapping.impl.tx 2 ibm.MapPipe.customerlookup.mapinputdata.Transformation ExtenderMap = string:customerLookupMap.mmc 3 ibm.MapPipe.customerlookup.mapinputdata.File1.data = key:txmap 4 ibm.MapPipe.customerlookup.mapinputdata.File1. name = string:customerLookupMap.mmc 5 ibm.MapPipe.customerlookup.mapinputdata.File2.data = key:txmap2 6 ibm.MapPipe.customerlookup.mapinputdata. File2.name = string:ParseResponseCL.mmc 7 ibm.MapPipe.customerlookup.mapinputdata. InputCard1.data = key:incominginstance 8 ibm.MapPipe.customerlookup.mapinputdata. InputCard2.data = string:localhost 9 ibm.MapPipe.customerlookup.mapoutputdata. OutputCard3.data = key:outputinstance 10 ibm.MapPipe.customerlookup.pidOutputs.main = pipe:ibm.PreserveMapPipe.customerlookup

   
   
   • В строке 1 определяется, что данный экземпляр канала map должен использовать сервис преобразования WebSphere Transformation Extender.
   • В строках 2, 3 и 4 определяется высокоуровневое преобразование Transformation Extender (MMC-файл), которое будет выполняться. Это преобразование было загружено в память их репозитория предыдущим каналом ibm.RepoLoadPipe.customerlookup и сохранено с помощью key txmap.
   • В строках 5 и 6 определяется другое преобразование WebSphere Transformation Extender (ParseResponseCL.mmc), выполняемое преобразованием высокого уровня.
   • В строке 7 определяется ввод в InputCard 1 преобразования WebSphere Transformation Extender; в данном случае это экземпляр CustomerInformation (содержащий номер CRM), переданный при нажатии кнопки Lookup формы.
   • В строке 8 определяется ввод в InputCard 2 преобразования WebSphere Transformation Extender, имя хоста, на котором запущен Web-сервис CustomerLookup. В данном решении предполагается, что имя хоста Web-сервиса — localhost.
   • В строке 9 определяется, что необходимый для преобразования WebSphere Transformation Extender вывод будет направлен в Output Card 3, а выходное значение будет сохраняться с помощью key outputinstance. Другие каналы в конвейере могут затем получить доступ к выходным данным (завершенному экземпляру CustomerInformation) с помощью key outputinstance.
   • В строке 10 определяется следующий канал, который должен быть выполнен по завершении выполнения данного канала.
5. Канал ReturnData

   Возвращает завершенный экземпляр в форму; см. рисунок 9.

Создание преобразований WebSphere Transformation Extender, вызывающих Web-сервисы

В WebSphere Transformation Extender данные, вводимые в преобразование, помещаются в карту ввода (Input Card), а результат преобразования — в карту вывода (Output Card). Для реализации необходимой функциональности в WebSphere Transformation Extender для случая использования CustomerLookup необходимы два преобразования WebSphere Transformation Extender (см. рисунок 7):

1. Преобразование CustomerLookup: (Преобразование верхнего уровня)
   • Карта ввода:
     1. Принимает на вход экземпляр CustomerInformation (содержащий номер CRM).
     2. Принимает на вход расположение каталога возможных необходимых преобразований — например ParseResponseCL.mmc (см. пункт 2 ниже). В данном примере используется репозиторий на основе файловой системы, а необходимые преобразования можно считать с диска.
     3. Принимает на вход IP-адрес компьютера, на котором работает Web-сервис CustomerLookup. При таком подходе при перемещении Web-сервиса не нужно перекомпилировать преобразование.
   • Карта вывода:
     1. Создает сообщение SOAP.
     2. Вызывает Web-сервис CustomerLookup с сообщением SOAP, созданным картой вывода Output Card 1.
     3. Выполняет преобразование ParseResponseCL и передает ему в качестве входных данных следующее:
        • Ответ SOAP, возвращенный из Web-сервиса
        • Номер CRM
   После завершения преобразования ParseResponseCL его выходные данные направляются в карту вывода Output Card 3 преобразования CustomerLookup. Второе преобразование (ParseResponseCL) необходимо для того, чтобы преобразовать ответ Web-сервиса в соответствующий тип XML (экземпляр CustomerInformation), который можно записать непосредственно обратно в форму с помощью Workplace Forms API.
2. Преобразование ParseResponseCL
   • Карта ввода:
     1. Принимает на вход номер CRM.
     2. Принимает на вход ответ SOAP, возвращенный Web-сервисом CustomerLookup.
   • Карта вывода:
     1. Создает на выходе заполненный экземпляр CustomerInformation, содержащий номер CRM и все данные, возвращенные Web-сервисом CustomerLookup.

Запуск конвейера во время исполнения

Кнопка Look Up на рисунке 8 связана с конвейером customerlookup с помощью правила передачи XForms, передающего экземпляр CustomerInformation (содержащий номер CRM):

                
      				
        <xforms:submission   
	action=http://localhost:9081/wfsp/wfi/customerlookup id="LookUp" 
	method="post" ref="instance(&quot;CustomerInformation&quot;)" 
	replace="instance">
	</xforms:submission>

 
 	

Пользователь вводит номер CRM и нажимает кнопку Look Up Когда Web Dispatcher получает запрос, запускается конвейер customerlookup. При окончании работы конвейера возвращается заполненный экземпляр CustomerInformation, который отображается в форме; см. рисунок 9.

Создание любого преобразования WebSphere Transformation Extender для платформы Workplace Forms Services Platform, которое вызывает сервис SOA, предполагает такую же процедуру, как в примере с конвейером CustomerLookup.

В начало

Заключение

Платформа IBM Workplace Forms Services Platform предоставляет простую в использованию среду для создания законченных приложений IBM Workplace Forms. С помощью IBM Workplace Forms Designer разработчики могут создавать формы и преобразования Websphere Transformation Extender для подключения этих форм к серверным системам, а затем публиковать все эти артефакты на сервере платформы Workplace Forms Services Platform. После публикации новые приложения автоматически становятся доступными пользователям. Если в дальнейшем требуется обновить приложения, можно загрузить приложение с сервера, внести необходимые изменения и снова развернуть приложение на сервере. Такая система отходит от традиционных моделей развертывания, позволяя меньшему количеству технического персонала выполнять развертывание приложений в среде выполнения без глубоких знаний конкретной среды. Новая платформа значительно снижает уровень знаний и временные затраты, необходимые для создания законченных приложений интеграции IBM Workplace Forms.

Благодарности

Благодарим Майка Мэнселла (Mike Mansell) и Криса Филипса (Chris Philips) из группы IBM Workplace Forms за рецензирование данной статьи и ценные замечания.

Ресурсы

Научиться

• Оригинал статьи: Integrating XML forms-based processes into Service-Oriented Architectures using IBM Workplace Forms Services Platform . (EN)
  
  
• См. Приложение А.
  
  
• Прочтите статью developerWorks: Расширение модели данных XML на формы XFDL с помощью IBM Workplace Forms V2.6.
  
  
• Прочтите статью developerWorks: Интеграция пакета IBM Workplace Forms V2.6 с IBM DB2 версии 9.
  
  
• Прочтите статью developerWorks: Интеграция IBM Workplace Forms c WebSphere Portal для создания приложения на основе форм.
  
  
• Прочтите статью developerWorks: Расширение функциональности IBM Workplace Forms при помощи библиотеки Function Call Interface.
  
  
• Прочтите статью developerWorks: Создание форм с помощью IBM Workplace Forms Designer.
  
  
• Узнайте больше о IBM WebSphere Transformation Extender.(EN)
  
  

Получить продукты и технологии

• Загрузите ознакомительную версию IBM Workplace Forms V2.6 Viewer и Designer.(EN)
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Блог Джона Бойера Workplace Forms и Web-приложения следующего поколения. (EN)
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Платформа IBM Workplace Forms Services Platform
• Интеграция электронных форм в SOA
• Заключение
• Ресурсы
• Об авторах
• Комментарии