Перейти к тексту

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Вся введенная информация защищена.

  • Закрыть [x]

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

Вся введенная информация защищена.

  • Закрыть [x]

Интеграция IBM Lotus Forms с WebSphere Portal для создания приложения на основе форм

Си Жи Линь, инженер-программист, IBM
Линь Си Жи (Lin Si Ri) – инженер-программист в лаборатории IBM Shanghai Globalization Lab (SGL), расположенной в Шанхае, Китай. Он работает над проектами тестирования оперативной совместимости в условиях глобализации (Globalization Interoperability Testing). Интересуется Java, J2EE, глобализацией и Open Source. Связаться с ним можно по адресу linsiri@cn.ibm.com.
Стив Шевчук, менеджер по разработке документации, IBM
Стив Шевчук (Steve Shewchuk) – менеджер в лаборатории IBM по разработке ПО, расположенной в провинции Виктория, Канада. Он стал сотрудником IBM после приобретения ей компании PureEdge и работает с формами более 10 лет.

Описание:  Мы покажем, как объединить IBM Lotus Forms с IBM WebSphere Portal. В частности мы продемонстрируем процесс создания приложения портала, которое предоставляет пользователю форму для заполнения, а затем отправляет заполненную форму.

Дата:  27.02.2010
Уровень сложности:  средний
Активность:  4089 просмотров
Комментарии:  


IBM Lotus Forms позволяет создавать и поставлять приложения на основе XML-форм. Одним из компонентов Lotus Forms является стандартный открытый программный интерфейс (API). С помощью этого API можно объединять данные электронных форм с серверными приложениями, а также управлять формами и предоставлять к ним доступ как к структурированным типам данных. В IBM Lotus Forms также имеется компонент под названием Webform Server, с помощью которого можно создать практически не потребляющее ресурсов решение, позволяющее пользователям, находящимся за пределами организации, быстро и легко просматривать и заполнять электронные формы через стандартный веб-браузер без использования дополнительных подключаемых модулей.

В данной статье мы объясним, как объединить IBM WebSphere Portal V6 с API-интерфейсом и компонентом Webform Server, чтобы создать приложение на основе форм.

Предполагается, что читатель имеет некоторый опыт разработки форм с помощью Java, а также разработки портлетов в IBM WebSphere Portal.

Для выполнения рассматриваемых в статье операций потребуется следующее программное обеспечение:

  • IBM WebSphere Portal V6 или более поздней версии;
  • IBM Lotus Forms Server V3.0 или более поздней версии;
  • IBM Rational IDE (например, IBM Rational Software Architect или IBM Rational Application Developer)

Бизнес-сценарий

Интеграция демонстрируется с помощью стандартного бизнес-сценария: процесса заполнения и отправки заказа на поставку. Сценарий начинается с создания XFDL-заказа на поставку, размещенного на портале WebSphere Portal, чтобы пользователи могли обратиться к форме при помощи интерфейса WebSphere Portal.

Когда пользователь выполняет вход на портал WebSphere Portal для создания нового заказа на поставку, Webform Server преобразует XFDL-форму в HTML и JavaScript. Затем преобразованная в HTML форма отображается в браузере пользователя. После заполнения и отправки формы WebSphere Portal извлекает модель данных из отправляемых данных и передает ее в одно или несколько приложений обработки (например, в рабочий процесс, выполняющий отправку формы).

Разработка подобных приложений обработки выходит за рамки данной статьи. Поэтому наше приложение будет просто отображать данные формы на экране.

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

  1. Установить Webform Server.
  2. Установить и настроить API-интерфейс на WebSphere Portal.
  3. Разработать XFDL-форму.
  4. Создать портлет для отображения формы.
  5. Создать страницу портала с двумя окнами.
  6. Настроить приложение портала.

Установка Webform Server

Устанавливая Webform Server, следует помнить, что в нем есть два основных компонента.

  • Компонент Translator. Этот компонент преобразует формы из XFDL в HTML. Это основной компонент Webform Server, выполняющий большую часть работы.
  • Сервлет/портлет-приложение. Это наше сервлет- либо портлет-приложение, обслуживающее формы. Оно преобразует формы с помощью компонента Translator.

Обычно установка Webform Server выполняется распределенно. Это означает, что приложение для работы с формами (наш сервлет или портлет) обычно размещается на сервере приложений, а компонент Translator устанавливается на другом сервере. Это необходимо, поскольку Webform Server и WebSphere Portal потребляют значительный объем ресурсов. Можно установить их и на одном сервере, однако в этом случае при большой нагрузке сильно снизится производительность.

Если вы не хотите усложнять тестовую среду, а большая нагрузка не планируется, все компоненты можно установить на одном сервере. Подобное решение работает, однако оно не рекомендуется для сред с высокой нагрузкой и производственных сред.

В нашем случае выполним распределенную установку Webform Server. Для установки Webform Server следуйте инструкциям, приведенным в руководстве администратора Lotus Forms Webform Server V3.0. Установите все компоненты Webform Server на выделенный сервер (то есть не на WebSphere Portal). В результате будет установлен и запущен компонент Translator.

После завершения установки откройте в браузере следующую ссылку, чтобы убедиться, что Webform Server работает правильно:

http://<<имя сервера Webform>>:8085/translator/Translate?pwsAction=toolbelt

Если Webform Server работает правильно, вы увидите страницу приветствия. Теперь компонент Translator работает на выделенном сервере. Далее в статье рассматривается создание портлет-приложения, необходимого для вызова компонента Translator. После разработки портлета выполняется его установка на WebSphere Portal и настройка для вызова компонента Translator на выделенном сервере.


Установка и настройка API-интерфейса на WebSphere Portal

На WebSphere Portal необходимо установить API, чтобы приложение могло использовать его функции для обработки формы. Однако опыт показывает, что настройка API представляет собой наиболее серьезнуюпроблему, с которой сталкиваются пользователи при создании приложений WebSphere Portal. И дело не в том, что этот процесс очень сложен. Просто для настройки требуется множество операций, при выполнении которых легко допустить ошибку.

Помните об этом при выполнении действий, описываемых в этом разделе. Точно выполняйте все действия выполняется точно и ничего не пропускайте.

Операции по установке API описаны в соответствующем "Руководстве по установке и настройке", однако мы приводим их здесь, так как при установке часто возникают проблемы. В нашем случае мы работаем с платформой Linux. Если необходимо выполнить установку на другую платформу, обратитесь к документации по продукту.

Для настройки API для работы с WebSphere Portal выполните следующие шаги.

  1. Войдите в систему как администратор (root) и запустите программу установки WFServer_300_API_Linux.bin для установки API на компьютер.
  2. Скопируйте содержимое дистрибутива в каталог /usr/lib:
    cp –r –p <каталог установки API>/redist/Linux/* /usr/lib

    ПРИМЕЧАНИЕ. Замените <<каталог установки API>> на корневой установочный каталог API. По умолчанию это каталог /opt/IBM/Workplace Forms/Server/3.0/API.
  3. Измените файлы, чтобы другие пользователи могли получить к ним доступ:
    chmod -R a+r+x /usr/lib/PureEdge
    chmod a+r /usr/lib/libpe_cc.so /usr/lib/libpe_java.so /usr/lib/libuwi_java.so
  4. В каталоге /etc создайте или обновите файл PureEdgeAPI.ini. В файле должен присутствовать следующий параметр:
    [API]
    7.5.* = /usr/lib/PureEdge/75
  5. Позаботьтесь о том, чтобы другие пользователи имели доступ к файлу PureEdgeAPI.ini:
    chmod a+r /etc/PureEdgeAPI.ini
  6. Найдите каталог /etc/PureEdge/API 7.5/prefs. Если каталог не существует, создайте его (имейте в виду, что в имени "API 7.5" должен присутствовать пробел).
  7. В каталоге /etc/PureEdge/API 7.5/prefs создайте файл конфигурации с именем prefs.config. Этот файл требуется API для определения нескольких свойств. В данном случае нас интересует только свойство javaPath, задающее путь к файлу libjvm.so, который используется виртуальной машиной Java (JVM). В нашем случае содержимое файла должно быть следующим:
    javaPath = /opt/IBM/WebSphere/AppServer/java/jre/bin/classic/libjvm.so

    ПРИМЕЧАНИЕ. Если на сервере установлено две или более виртуальных машин Java, свойство javaPath должно указывать на ту же JVM, которая используется для работы API с WebSphere Portal. По умолчанию WebSphere Portal использует JVM из каталога /opt/IBM/WebSphere/AppServer/java. Если вы точно не знаете, какая JVM используется WebSphere Portal, в консоли администрирования WebSphere Application Server откройте open Environment — WebSphere Variables, укажите диапазон для узла, содержащего WebSphere Portal, а затем проверьте значение переменной JAVA_HOME — это и есть основной каталог Java.
  8. Позаботьтесь о том, чтобы не только администратор (root), но и другие пользователи имели доступ к файлу конфигурации.
    chmod –R a+r /etc/PureEdge
  9. Присвойте значения переменным WebSphere:
    • В консоли администрирования WebSphere Application Server выберите Environment — WebSphere Variables.
    • Нажмите Browse Nodes и выберите узел, содержащий WebSphere_Portal.
    • Нажмите New, чтобы создать переменную среды, и назовите ее WFS_API_DIR (см. рисунок 1). Присвойте ей значение /usr/lib.
    • Повторите предыдущий шаг и создайте еще одну переменную среды с именем WFS_API_LIB_DIR. Ее значение должно быть ${WFS_API_DIR}/PureEdge/75/java/classes.

Рисунок 1. Добавление новой переменной WebSphere — WFS_API_DIR
Добавление новой переменной WebSphere — WFS_API_DIR
  1. Задайте определения процесса Java (Java process definitions):
    • В консоли WebSphere Application Server откройте Servers — Application servers — WebSphere_Portal — Java and Process Management — Process Definition — Custom Properties (см. рисунок 2).
    • Добавьте ${WFS_API_DIR}:${WFS_API_DIR}/PureEdge/75/system: в начало имеющегося свойства LD_LIBRARY_PATH.

Рисунок 2. Изменение пользовательских свойств
Изменение пользовательских свойств

ПРИМЕЧАНИЕ. Используйте правильный разделитель; в Windows используется точка с запятой (;), а в системах на основе UNIX — двоеточие (:).

  1. Задайте общие библиотеки:
    • В консоли WebSphere Application Server выберите Environment — Shared Libraries.
    • Нажмите Browse Nodes и выберите узел, содержащий WebSphere_Portal.
    • Очистите поле Server и нажмите кнопку Apply.
    • Нажмите New, чтобы создать общую библиотеку, и назовите ее WFS_API_LIB (см. рисунок 3). В поле Classpath введите список имен следующих файлов (в каждой строке должно быть одно имя): ${WFS_API_LIB_DIR}/pe_api.jar
      ${WFS_API_LIB_DIR}/pe_api_native.jar
      ${WFS_API_LIB_DIR}/uwi_api.jar
      ${WFS_API_LIB_DIR}/uwi_api_native.jar

Рисунок 3. Добавление новой общей библиотеки — WFS_API_LIB
Добавление новой общей библиотеки – WFS_API_LIB
  1. Задайте серверный загрузчик классов:
    • В консоли администрирования WebSphere Application Server откройте Servers — Application servers — WebSphere_Portal — Java and Process Management — Class loader.
    • Выберите существующий загрузчик классов, а затем нажмите Libraries.
    • Нажмите Add для добавления новой ссылки на библиотеку (Library Reference).
    • В разделе Library Name выберите WFS_API_LIB, а затем нажмите ОК.
  1. Сохраните все изменения в главную конфигурацию и перезапустите WebSphere Portal.

Разработка XFDL-формы

Для данного приложения необходимо создать форму заказа на поставку, которую можно разместить на портале WebSphere Portal. Создавать формы можно с помощью IBM Lotus Forms Designer. Для удобства мы уже создали заполненную форму, она показана на рисунке 4.


Рисунок 4. Форма заказа на поставку
Форма заказа на поставку

В форме заказа на поставку для отправки модели данных формы используется передача XForms. Это означает, что передаются только данные формы, а не презентации (XFDL-элементы).

Такой вариант выбран не случайно. При желании можно отправлять и всю форму, но в этом случае пришлось бы извлекать данные во время обработки. Если отправлять только модель, этот шаг можно пропустить. Тем не менее, в некоторых случаях предпочтительнее отправлять форму целиком. Например, если требуется полная запись транзакции для целей регулирования, оптимальным выбором будет отправка и хранение XFDL-формы целиком.

Чтобы при отправке формы передавалась только модель XForms, необходимо настроить несколько параметров в самой форме. В предоставленном примере формы эти параметры уже заданы, тем не менее рассмотрим их вкратце.

Откройте форму в IBM Lotus Forms Designer и выберите раздел "submission" в представлении XForms (см. рисунок 5). В нем имеются следующие свойства:

  • Свойство "action" со значением "http://"
  • Свойство "method" со значением "post"
  • Свойство "replace" со значением "all"

Рисунок 5. Установка свойств для передачи XForms
Установка свойств для передачи XForms

Определение свойства "action" для передачи XForms обязательно. Так как для отображения формы в WebSphere Portal используется Webform Server, можно присвоить этому свойству любое значение. Webform Server игнорирует этот параметр и при преобразовании перезаписывает этот URL-адрес правильным адресом портлета. При таком подходе форма всегда возвращается в правильный портлет, а знать заранее нужный URL-адрес не требуется.

ПРИМЕЧАНИЕ. При использовании Webform Server в сервлете URL-адрес возврата не перезаписывается автоматически. Кроме того, если требуется, чтобы форма работала как в IBM Lotus Forms Viewer, так и в Webform Server, обязательно задайте правильный URL-адрес для Viewer. В этом случае адрес будет работать в Workplace Forms Viewer, однако он будет перезаписан при использовании в Webform Server.

При запуске Webform Server в среде портала может потребоваться запретить пользователям выполнять некоторые действия, например сохранять или открывать формы. Это можно сделать, отключив кнопки на панели инструментов Webform Server.

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

В Lotus Forms Designer (предварительно загрузив в него пример формы) перейдите в представление Outline и выберите globalpage — Form Global. В представлении Properties откройте General — ufv_settings — menu. Обратите внимание, что свойства open (открыть), refresh (обновить) и save (сохранить) имеют значение off (отключено).

Поэтому кнопки открытия, обновления и сохранения в Webform Server отключены и недоступны пользователю.

ПРИМЕЧАНИЕ. Этот параметр управляет только кнопками панели инструментов в Webform Server и Lotus Forms Viewer. Если в форме предусмотрены отдельные элементы управления, например кнопка сохранения или печати, они будут работать нормально.


Создание портлета для отображения формы

В нашем сценарии, когда пользователь запрашивает форму из WebSphere Portal, Webform Server преобразует ее в HTML, прежде чем отправлять ее пользователю. На рисунке 6 показаны выполняемые при этом действия.


Рисунок 6. Запрос формы из Webform Server
Запрос формы из Webform Server

Выполняются следующие действия:

  1. Пользователь запрашивает форму из портлета.
  2. Портлет получает запрос и определяет местонахождение нужного файла в хранилище форм (Form Repository).
  3. Портлет доставляет форму.
  4. Портлет передает форму Webform Server.
  5. Webform Server преобразует форму в сочетание HTML с JavaScript и отправляет преобразованную форму обратно портлету.
  6. Портлет передает преобразованную форму пользователю.

Из этих действий видно, что любой создаваемый портлет должен обмениваться данными с Webform Server. К счастью, в Webform Server имеется специализированный класс портлета и сервлета, отвечающий за обмен данными. Это означает, что вместо расширения стандартных классов портлета и сервлета при создании приложения нужно расширять классы портлета и сервлета для конкретной Web-формы. Эти классы автоматически выполняют обмен данными с компонентом Translator сервера Webform Server – для этого не нужно создавать код. В каждом из этих классов также имеется небольшой API-интерфейс, облегчающий разработку приложений на основе форм. К примеру, можно настроить портлет таким образом, чтобы формы всегда преобразовывались в HTML; можно также автоматически определять, установлен ли на компьютере Viewer, и если установлен, отправлять XFDL.

Так как предоставляемые классы позволяют при преобразовании формы не вникать в подробности, можно создавать любой код, основываясь на предположении, что вы работаете с XFDL. Вам никогда не придется обрабатывать HTML самостоятельно. Весь отправляемый обратно пользователем HTML-код перехватывается и снова преобразуется в XFDL, прежде чем код программы сможет его обработать.

В нашем примере сценария создается портлет, предоставляющий формы пользователю. Для этого нужно расширить класс IBMWorkplaceFormsServerPortlet, который является абстрактным классом, представляющим относящуюся к конкретной Web-форме пользовательскую реализацию JSR 168 Portlet. Расширив этот класс, нужно разработать собственный портлет, следуя нескольким простым правилам.

Выполнив следующие действия, можно создать портлет под названием FormViewPortlet, отображающий форму и управляющий ее передачей.

  1. Создайте проект JSR168 Portlet Project в среде разработки IBM Rational.
  2. Скопируйте JAR-файлы Webform Server API ws_framework.jar, ws_common.jar, ws_resourcestore.jar, ehcache_1.2.2.jar, commons_cache.1.3.jar, commons_httpclient_3.0.jar и log4j.jar из каталога <каталог установки Webform Server>/redist/ в каталог WebContent/WEB-INF/lib/ проекта портала. JAR-файлы будут автоматически добавлены в путь сборки.
  3. В среде разработки Rational создайте новый Java-класс с именем forms.portlets.FormViewPortlet, расширяющий абстрактный класс IBMWorkplaceFormsServerPortlet (см. рисунок 7).
  4. Отметьте флажком параметр Inherited abstract methods для создания заглушек абстрактных методов для нового класса.

Рисунок 7. Создание класса FormViewPortlet
Создание класса FormViewPortlet
  1. Скопируйте следующий импорт в исходный код класса FormViewPortlet:
    import com.PureEdge.DTK;
    import com.PureEdge.IFSSingleton;
    import com.PureEdge.error.UWIException;
    import com.PureEdge.xfdl.FormNodeP;
    import com.PureEdge.xfdl.XFDL;
  2. При использовании среды разработки Rational IDE необходимо добавить файлы pe_api.jar и uwi_api.jar в путь сборки. Эти два файла устанавливаются с API в <каталог установки API>/ lib/java. С их помощью среда разработки компилирует код, а портлету эти файлы нужны при работе с формами; однако в каталог WEB-INF/lib/ эти два JAR-файла добавлять нельзя, так как API уже установлен и настроен на работу с WebSphere Portal.
    • Правой кнопкой мыши щелкните проект портала, а затем во всплывающем меню выберите Properties.
    • Выберите страницу Java Build Path.
    • На странице Libraries нажмите кнопку Add External JARs, чтобы добавить файлы pe_api.jar и uwi_api.jar в путь сборки (см. рисунок 8).

Рисунок 8. Добавление JAR-файлов API в путь сборки
Добавление JAR-файлов API в путь сборки
  1. Переопределите метод init для инициализации API, как показано в листинге 1.


    Листинг 1. Переопределение метода init
                            
    public void init(PortletConfig config) throws PortletException {
    	// всегда вызываем метод-предок
    	super.init(config);
    	try {
    			// Инициализируем API
    			DTK.initializeWithLocale
    			("WFS Portal Sample", "1.0.0", "7.5.0", null);
    			
    	} catch (UWIException e) {
    		throw new PortletException(e);
    	}
    }
    

  1. Переопределите метод doView для визуализации представления портлета; см. листинг 2. В этом методе вызов super.useHTML(request, true) заставляет портлет преобразовать XFDL-форму в HTML. Затем вызывается метод super, который затем завершается. После этого объект IBMWorkplaceFormsServerPortlet продолжает работу и в зависимости от своего состояния определяет, нужно ли вызывать метод doViewEx.


    Листинг 2. Переопределение метода doView
                            
    public void doView(RenderRequest request, RenderResponse response)
    			throws PortletException, IOException {
    		log.debug("Start to execute the doView method...");
    		// заставляем портлет отображать XFDL-форму в HTML-режиме
    		super.useHTML(request, true);
    		// вызываем метод-предок
    		super.doView(request, response);
    	}
    

    ПРИМЕЧАНИЕ. Объект IBMWorkplaceFormsServerPortlet имеет два состояния: empty или full. Состояние empty означает, что форма не загружена, а для ее загрузки нужно вызвать doViewEx. Состояние full означает, что форма загружена, а вызывать doViewEx не нужно.
  1. Реализуйте метод doViewEx; см. листинг 3. В этом методе портлет с помощью API выполняет чтение формы из файловой системы и вносит в форму сведения из хранящихся данных с помощью метода FormNodeP.updateXFormsInstance. Затем метод записывает форму в объект response и задает тип содержимого объекта response — application/vnd.xfdl.


    Листинг 3. Реализация метода doViewEx
                            
    
    public void doViewEx(RenderRequest request, RenderResponse response)
    			throws PortletException, IOException {
    		log.debug("Start to execute the doViewEx method...");
    		// сообщаем портлету-предку имя XFDL-формы 
    		setFilename(request, "PurchaseOrder.xfdl");
    		PortletContext context = this.getPortletContext();
    		// получаем файл формы
    		String formFilePath = context.getRealPath("/") + 
    "/WEB-INF/form/PurchaseOrder.xfdl";
    		FileInputStream fis = new FileInputStream(formFilePath);
    		FormNodeP theForm = null;
    		try {
    			// задаем соответствующий тип содержимого
    			response.setContentType("application/vnd.xfdl");
    // получаем объект XFDL, представляющий собой интерфейс, с помощью которого
    // можно получить доступ к корневому узлу формы.
    			XFDL theXFDL = IFSSingleton.getXFDL();
    			// считываем форму в память из указанного файла
    			theForm = theXFDL.readForm(fis, XFDL.UFL_SERVER_SPEED_FLAGS);
    			fis.close();
    
    			// получаем сведения о магазинах
    			String storeFilePath = context.getRealPath("/") + 
    			"/stores/ID001001.xml";
    // заменяет экземпляр XForms в модели данных формы, чтобы 
    // ввести в форму сведения о магазинах
    theForm.updateXFormsInstance(null,
    	"instance('poInstance')/schemaNS1:store", null,	
    	storeFilePath, null, XFDL.UFL_XFORMS_UPDATE_REPLACE);
    			// записываем форму в выходной поток ответа портлета
    			theForm.writeForm(response.getPortletOutputStream(), null, 0);
    		} catch (Exception e) {
    			log.error("Failed to display the form!", e);
    		} finally{
    			if(theForm != null){
    				try {
    					// уничтожает указанный FormNodeP, 
    					чтобы удалить его из памяти
    					theForm.destroy();
    				} catch (UWIException e1) {
    					log.error
    					("Failed to destory the form object!", e1);
    				}
    			}
    		}
    	}
    

    Записав форму в объект response, можно завершить метод doViewEx. С этого момента работу продолжает IBMWorkplaceFormsServerPortlet. Так как мы настроили портлет, чтобы он ысегда отображал форму в HTML, объект IBMWorkplaceFormsServerPortlet автоматически вызывает Webform Server для выполнения преобразования, а HTML-форма возвращается пользователю.
  1. Завершив создание кода, отображающего форму в портлете, реализуем метод processActionEx для обработки передачи XForms.

    Передача XForms с параметром replace="all" отличается от передачи XForms с параметром replace="instance". При передаче с параметром replace="instance" отправляемые данные автоматически передаются Webform Server в URL-адрес обработки, а возвращаемые данные автоматически встраиваются в форму и возвращаются пользователю. В результате экземпляр данных в форме заменяется в то время когда пользователь еще работает с ним. Однако случай replace = "all" требует ручной обработки; Webform Server не выполняет аналогичную автоматическую обработку такого запроса.

    Когда Webform Server получает передачу XForms с атрибутом replace="all", он присваивает HTTP-заголовку xformsreplaceall значение true и возвращает данные в приложение. В этом методе используется функция isReplaceAll, чтобы определить, получил ли портлет передачу XForms; см. листинг 4. Если передача XForms получена, портлет считывает передаваемые данные из входного потока запроса, а затем сохраняет данные в объекте FormViewSessionBean, который сохраняется на время сеанса.

    Листинг 4. Использование функции isReplaceAll
                            
    
    public void processActionEx
    (ActionRequest request, ActionResponse response)
    			throws PortletException, IOException {
    		log.debug("Start to execute the processActionEx method...");
    		if (isReplaceAll() == true) {
    			// здесь портлет получил передачу XForms
    			FormViewSessionBean bean = this.getFormViewSessionBean(request);
    			bean.reset();
    			bean.setReplaceAll(true);
    			bean.setReplaceAllContentType(request.getContentType());
    
    			// считываем передаваемые данные из входного потока запроса
    			InputStreamReader reader = new 
    InputStreamReader(request.getPortletInputStream(), "UTF-8");
    			StringBuffer replaceAllData = new StringBuffer();
    			char[] chars = new char[32000];
    			int charsRead;
    			while ((charsRead =
    			 reader.read(chars, 0, chars.length)) != -1) {
    				replaceAllData.append(chars, 0, charsRead);
    			}
    			
    			// сохраняем данные в объекте FormViewSessionBean
    			bean.setReplaceAllData(replaceAllData.toString());
    		} else {
    			log.debug
    			("Portlet received other kinds
    			 of action in the processActionEx.");
    		}
    	}
    

  1. Обновите метод doViewEx для отображения передаваемых данных на экране пользователя; см. листинг 5. Метод получает передаваемые данные из объекта FormViewSessionBean этого сеанса и записывает данные в объект response портлета.


    Листинг 5. Обновление метода doViewEx
                            
    public void doViewEx(RenderRequest request, RenderResponse response)
    			throws PortletException, IOException {
    		log.debug("Start to execute the doViewEx method...");
    		FormViewSessionBean bean = this.getFormViewSessionBean(request);
    		if (bean.isReplaceAll()) {
    			// метод был вызван после передачи, завершившейся replaceAll
    			String replaceAllData = bean.getReplaceAllData();
    			// выводим XML-данные на экран в виде текста
    			replaceAllData = replaceAllData.replaceAll("<", "<");
    			replaceAllData = replaceAllData.replaceAll(">", ">");
    			response.setContentType("text/html; charset=UTF-8");
    			String userMessage = "Document submitted successfully. <BR><BR> ";
    			PrintWriter writer = response.getWriter();
    			writer.write(userMessage);
    			writer.write(replaceAllData);
    			writer.flush();
    			bean.reset();
    		} else {
    			// сюда вставляется код, отображающий форму для пользователя
    			…
    		}
    	}
    

    Как можно видеть, метод doViewEx должен обрабатывать два разных сценария. В первом сценарии методу doViewEx требуется отобразить форму для пользователя. А во втором этот метод должен отобразить какой-либо другой результат, например ответ в виде HTML на передачу формы.

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

Создание страницы портала с двумя окнами

Теперь расширим сценарий, включив в него портал с двумя окнами, каждое их которых представляет собой отдельный портлет. Первое окно — это наш FormViewPortlet, а второе, SupplierListPortlet, отображает список поставщиков. Когда пользователь выбирает поставщика в SupplierListPortlet, FormViewPortlet вносит сведения об этом поставщике в форму, а затем отображает ее.

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

  1. Создайте новый портлет JSR 168 в среде разработки Rational и назовите его SupplierListPortlet (см. рисунок 9). Так как портлет SupplierListPortlet не обрабатывает непосредственно XFDL-формы, он не обязательно должен расширять класс IBMWorkplaceFormsServerPortlet. Вместо этого он расширяет класс GenericPortlet. Поэтому ему требуются методы doView и processAction.

Рисунок 9. Создание портлета SupplierListPortlet
Создание портлета SupplierListPortlet
  1. В методе doView настройте портлет SupplierListPortlet на создание списка всех XML-файлов, доступных в папке <context root>/suppliers; см листинг 6.

    Листинг 6. Настройка портлета SupplierListPortlet на создание списка XML-файлов
                            
    
    public void doView(RenderRequest request, RenderResponse response)
    			throws PortletException, IOException {
    		log.debug("Start to execute the doView method...");
    		// получаем поставщиков
    		File supplierDirectory = new 
    		File(this.getPortletContext().getRealPath("/") + "/" + 
    "suppliers");
    		File[] supplier_files = supplierDirectory.
    		listFiles(new SupplierXMLFileFilter());
    		// отображаем поставщиков на экране
    		response.setContentType("text/html; charset=UTF-8");
    		StringBuffer html = new StringBuffer();
    		html.append("Please select a supplier for the purchase order:");
    		html.append("\n<UL>");
    		int length = supplier_files.length;
    		for (int i =0; i<length; i++) {
    			File element = supplier_files[i];
    			PortletURL url = response.createActionURL();
    			url.setParameter("file", element.getName());
    			html.append("\n<LI><a href=\"").
    			append(url.toString()).append("\">");
    			
    			html.append(element.getName()).append("</a></LI>");
    		}
    		html.append("\n</UL>");
    		PrintWriter writer = response.getWriter();
    		writer.write(html.toString());
    		writer.flush();
    	}
    

  1. В методе processAction настройте портлет SupplierListPortlet на использование компонента SupplierListSessionBean; см. листинг 7. Этот компонент регистрирует, какой поставщик выбран пользователем и сохранен в сеансе.

    Листинг 7. Настройка портлета SupplierListPortlet на использование компонента
                            
    
    
    public void processAction(ActionRequest request, ActionResponse response)
    			throws PortletException, IOException {
    		log.debug("Start to execute the processAction method...");
    		String filename = null;
    		if ((filename = request.getParameter("file")) == null) {
    			log.debug("No file has been selected!");
    		} else {
    			// сохраняем выбранного поставщика в сеансе
    			SupplierListSessionBean bean = 
    			getSupplierListSessionBean(request);
    			bean.setFilename(filename);
    		}
    	}
    

  1. Теперь обновите метод doView в FormViewPortlet; см. листинг 8. Портлет сначала должен получить выбранного поставщика из сеанса. Как упоминалось ранее, IBMWorkplaceFormsServerPortlet поддерживает состояние, регистрирующее, была ли форма отображена портлетом. В этом случае требуется сделать портлет пустым при выборе новой формы. Для этого вызовите метод super.resetPortlet. Это приведет к вызову портлетом метода doViewEx. Соответственно, необходимо также удалить эти сведения из сеанса, чтобы форма не перезагружалась всякий раз при обновлении страницы.

    Листинг 8. Обновление метода doView в FormViewPortlet
                            
    
    public void doView(RenderRequest request, RenderResponse response)
    			throws PortletException, IOException {
    		log.debug("Start to execute the doView method...");
    		
    String requestFilename = null;
    		// получаем имя файла из сеанса. Значение было добавлено в сеанс 
    		// SupplierListPortlet.  
    		SupplierListSessionBean listSessionBean = 
    this.getSupplierListSessionBean(request);
    		if(listSessionBean != null && (requestFilename = 
    		listSessionBean.getFilename()) != null){
    			log.debug("A supplier has been selected: "+requestFilename);
    			// получаем компонент сеанса
    			FormViewSessionBean bean = this.getFormViewSessionBean(request);
    			// обновляем значения компонента FormViewSessionBean
    //  на основе значений из сеанса запроса
    			bean.setFilename(requestFilename);
    			// удаляем имя файла в сеансе запроса, как только оно будет
    // получено, чтобы форма не перезагружалась каждый раз
    			listSessionBean.setFilename(null);
    			// перезапускаем портлет-предок, чтобы обеспечить вызов
    // метода doViewEx() для чтения новой XFDL-формы
    			super.resetPortlet(request);
    		}else{
    			log.debug("No supplier was selected");
    		}
    
    		// заставляем портлет отображать XFDL-форму в режиме HTML
    		super.useHTML(request, true);
    		// вызываем метод предка
    		super.doView(request, response);
    	}
    

  1. Далее, обновите метод doViewEx в FormViewPortlet; см. листинг 9. Прежде чем записать форму в выходной поток ответа, портлет получает имя файла из сеанса и с помощью метода FormNodeP.updateXFormsInstance вносит в форму сведения о поставщике.

    Листинг 9. Обновление метода doViewEx в FormViewPortlet
                            
    
    // считываем каталог и имя файла из компонента сеанса
    	String supplierFile = bean.getFilename();
    	if(supplierFile != null){
    		String supplierFilePath = 
    		context.getRealPath("/")+"/suppliers/"+supplierFile;
    		// вносим в форму сведения о поставщике
    		theForm.updateXFormsInstance
    		(null, "instance('poInstance')/schemaNS1:supplier", 
    null, supplierFilePath, null, 
    XFDL.UFL_XFORMS_UPDATE_REPLACE);
    	}
    


Настройка приложения портала

В файле portlet.xml необходимо настроить параметры init-param для IBMWorkplaceFormsServerPortlet. Это важно в случае распределенной установки, при которой различные компоненты Webform Server могут находиться на нескольких серверах. В файле portlet.xml имеется сопоставление, с помощью которого можно определить, где установлен каждый компонент.

Ниже перечислены основные параметры.

  • translatorLocation: обязательный. Местоположение сервлета Webform Translator (компонента Translator).
  • logServerName: необязательный. Имя хоста сервера журналов (Log Server).
  • logServerPort: необязательный. Номер порта сервера журналов (Log Server).
  • logLevel: необязательный. Определяет, какие события регистрируются в журнале.
  • portletWidth: необязательный. Ширина портлета в браузере.
  • portletHeight: необязательный. Высота портлета в браузере.

Как говорилось выше, в создаваемом в рамках статьи решении все компоненты Webform Server устанавливаются на выделенном сервере. Назовем его ogrdform. Портлеты размещаются на портале WebSphere Portal и с помощью файла portlet.xml определяют местонахождение компонентов Webform Server. Файл portlet.xml приведен в листинге 10.


Листинг 10. Файл portlet.xml
<portlet>
		<description>Form View Portlet</description>
		<portlet-name>Form View Portlet</portlet-name>
		<display-name>Form View Portlet</display-name>
		<portlet-class>forms.portlets.FormViewPortlet</portlet-class>
		<init-param>
			<name>translatorLocation</name>
			<value>http://ogrdform:8085/translator</value>
		</init-param>		
		<init-param>
			<name>logServerName</name>
			<value>ogrdform</value>
		</init-param>
		<init-param>
			<name>logServerPort</name>
			<value>4560</value>
		</init-param>				
		<init-param>
			<name>logLevel</name>
			<value>1</value>
		</init-param>
		<init-param>
			<name>portletWidth</name>
			<value>800</value>
		</init-param>			
		<init-param>
			<name>portletHeight</name>
			<value>400</value>
		</init-param>
		<expiration-cache>0</expiration-cache>
		<supports>
			<mime-type>text/html</mime-type>
			<portlet-mode>VIEW</portlet-mode>
		</supports>
		<supported-locale></supported-locale>       
		<resource-bundle></resource-bundle>
	</portlet>	

При использовании портлетов с Webform Server необходим специальный сервлет WebformPortletForwarder. Требуется также добавить содержимое в файл web.xml портлета, чтобы приложение правильно использовало сервлет WebformPortletForwarder; см. листинг 11.


Листинг 11. Содержимое, добавляемое в файл web.xml портлета
<servlet>
	<servlet-name>PWSForwarder</servlet-name>
	<servlet-class>
	com.ibm.form.webform.framework.portlet.WebformPortletForwarder</servlet-class>
		<init-param>
			<!-- Этот параметр указывает на местоположение
сервлета Translator в Webform Server -->
			<!-- Здесь можно поменять имя сервера и 
номер порта в соответствии с конфигурацией Webform Server-->
			<param-name>translatorLocation</param-name>
			<param-value>http://ogrdform:8085/translator</param-value>
		</init-param>	
</servlet>
<servlet-mapping>
	<servlet-name>PWSForwarder</servlet-name>
	<url-pattern>/PWSForwarder/*</url-pattern>
</servlet-mapping>	

Наконец, нужно убедиться,что файлы поддержки расположены там, где надо.

  • XFDL-форма PurchaseOrder.xfdl должна находиться в каталоге WEB-INF/form.
  • XML-файл со сведениями о магазинах должен находиться в каталоге WebContent/stores.
  • XML-файлы со сведениями о поставщиках должны находиться в каталоге WebContent/suppliers.

Теперь мы готовы к созданию портлетов и их развертыванию на WebSphere Portal. Процедура развертывания портлета детально не описывается, однако имейте в виду, что при развертывании необходимо поместить SupplierListPortlet над FormViewPortlet на странице портала (см. рисунок 10).


Рисунок 10. Развертывание портлетов на странице
Развертывание портлетов на странице

Тестирование приложения портала

Тестирование приложения позволяет убедиться, что портал и WebSphere Portal настроены правильно.

  1. Откройте браузер и выполните вход в WebSphere Portal, а затем откройте страницу, на которой размещаются созданные вами порталы. В верхней части страницы можно увидеть список поставщиков, а форма располагается непосредственно под ним. Взглянув на форму, можно также заметить, что в нее уже добавлены соответствующие сведения о магазинах.
  2. Выберите поставщика в портлете со списком поставщиков. На рисунке 11 видно, что теперь в форму добавлены сведения о поставщике.
  3. С помощью кнопок Add Row или Delete можно добавить в форму или удалить из нее приобретаемые изделия; затем можно ввести значения по каждому пункту.

Рисунок 11. Заполнение формы
Заполнение формы
  1. После заполнения формы нажмите кнопку Submit, чтобы отправить данные обратно на сервер. Приложение возвратит переданные данные и выведет сообщение "Document submitted successfully" (Документ успешно отправлен).

Заключение

IBM Lotus Forms позволяет создавать и поставлять приложения на основе XML-форм. К тому же при использовании Webform Server отпадает необходимость устанавливать Lotus Forms Viewer каждому пользователю – для работы с формами Lotus Forms потребуется лишь браузер. В Webform Server подобные приложения создаются путем , расширения класса портлета или сервлета, поставляемого с продуктом. В дальнейшем можно добавлять любой обрабатывающий код, в том числе для взаимодействия с другими приложениями (например, рабочими процессами и базами данных). Хотя в данной статье приводится простой пример, не предполагающий использования других систем, легко понять, как добавить такую поддержку для создания комплексного решения для предприятия.



Загрузка

ИмяРазмерМетод загрузки
WFSPortalProject.war395 KБHTTP

Информация о методах загрузки


Ресурсы

Научиться

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

Обсудить

Об авторах

Линь Си Жи (Lin Si Ri) – инженер-программист в лаборатории IBM Shanghai Globalization Lab (SGL), расположенной в Шанхае, Китай. Он работает над проектами тестирования оперативной совместимости в условиях глобализации (Globalization Interoperability Testing). Интересуется Java, J2EE, глобализацией и Open Source. Связаться с ним можно по адресу linsiri@cn.ibm.com.

Стив Шевчук (Steve Shewchuk) – менеджер в лаборатории IBM по разработке ПО, расположенной в провинции Виктория, Канада. Он стал сотрудником IBM после приобретения ей компании PureEdge и работает с формами более 10 лет.

Помощь по сообщениям о нарушениях

Сообщение о нарушениях

Спасибо. Эта запись была помечена для модератора.


Помощь по сообщениям о нарушениях

Сообщение о нарушениях

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.


developerWorks: вход


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Выберите ваше отображаемое имя

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

(Должно содержать от 3 до 31 символа.)


Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Комментарии

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Lotus, WebSphere
ArticleID=470138
ArticleTitle=Интеграция IBM Lotus Forms с WebSphere Portal для создания приложения на основе форм
publish-date=02272010
author1-email=linsiri@cn.ibm.com
author1-email-cc=
author2-email=stevesh@ca.ibm.com
author2-email-cc=

Теги

Help
Используйте форму поиска, чтобы найти любой контент с данным тегом в My developerWorks. Используйте ползунок, чтобы отразить больше или меньше тегов.

КнопкаПопулярные теги отображает самые распространенные теги для данной области контента (например: Java, Linux, WebSphere).

Кнопка Мои теги отображает Ваши теги для данной области контента (например: Java, Linux, WebSphere).

Используйте форму поиска, чтобы найти любой контент с данным тегом в My developerWorks. Кнопка Популярные теги отображает самые распространенные теги для данной области контента (например: Java, Linux, WebSphere). Кнопка Мои теги отображает Ваши теги для данной области контента (например: Java, Linux, WebSphere).