レベル: 中級 Si Ri Lin (linsiri@cn.ibm.com), Software Engineer, IBM
Steve Shewchuk, Information Development Manager, IBM
2007年 3月 06日
更新 2008年 2月 26日 IBM Lotus Forms を IBM WebSphere Portal と統合する方法を紹介します。その統合の一環として、ユーザーからのフォーム要求と、ユーザーからの入力済みフォーム送信の両方に応答するポータル・アプリケーションを作成する方法を説明します。
編集者注) この記事はUS環境での設定を記述しています。US以外の環境は、同じ設定にならない場合があります。
IBM Lotus Forms では、XML フォーム・アプリケーションを作成して配信することが可能です。IBM Lotus Forms には、コンポーネントの 1 つとして、オープンな共通アプリケーション・プログラミング・インターフェース (API) が用意されています。この API を使用して、電子フォーム・データをサーバー・サイド・アプリケーションと統合したり、フォームに構造化データ型としてアクセスして操作したりすることが可能です。また、IBM Lotus Forms には、Webform Server というコンポーネントが搭載されています。このコンポーネントは、真に占有面積がゼロのソリューションで、これにより外部ユーザーは、標準的な Web ブラウザーを通じて、追加のプラグインなしに、電子フォームを素早く簡単に表示して入力することができます。
この記事では、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 など)
ビジネス・シナリオ
この記事では、統合をわかりやすく示す例として、購入注文書の入力と送信のプロセス、という一般的なビジネス・シナリオを使用します。このシナリオではまず、ユーザーが WebSphere Portal のインターフェースを使用してフォームにアクセスすることができるよう、WebSphere Portal 内にホストされている XFDL 形式の購入注文書フォームを用意します。
ユーザーが新しい購入注文書を作成するために WebSphere Portal にログインすると、Webform Server によって XFDL フォームを HTML と JavaScript に変換します。フォームはその後、HTML 形式で、ユーザーの Web ブラウザーに表示されます。ユーザーがフォームの入力と送信を終えると、WebSphere Portal は送信されたデータからデータ・モデルを取り出し、これを 1 つ以上の処理アプリケーション (フォームを送付するワークフローなど) に引き渡します。
これらの処理アプリケーションの開発については、この記事では取り上げません。したがって、ここでは、ユーザー向け画面にフォーム・データを表示するだけのアプリケーションを作成することになります。
このサンプル・シナリオを作成するには、以下の手順に従います。
- Webform Server をインストールします。
- WebSphere Portal 上に API をインストールしてセットアップします。
- XFDL フォームを設計します。
- フォームを表示するポートレットを作成します。
- 2 つのペインからなるポータル・ページを作成します。
- ポータル・アプリケーションを構成します。
Webform Server のインストール
Webform Server をインストールする際には、以下の 2 つの中心的なコンポーネントについて考慮する必要があります。
-
変換プログラムフォームを XFDL から HTML へ、また HTML から XFDL へ変換するコンポーネントです。Webform Server の心臓部であり、作業の大半を担います。
-
サーブレット/ポートレット・アプリケーション これから記述する、フォームを担うアプリケーション (サーブレットまたはポートレットのいずれか) です。このアプリケーションが、変換プログラムを使用してフォームを変換します。
Webform Server の典型的なインストール形態は、分散型インストールです。これはすなわち、作成したフォーム・アプリケーション (サーブレットまたはポートレット) が通常アプリケーション・サーバー上にホストされ、他方で変換プログラムが通常第 2 のサーバーにインストールされることを意味します。Webform Server と WebSphere Portal の両方が、多くのリソースを消費するアプリケーションであるため、この工程が必要となります。これらの両方を同じサーバーにインストールすることは可能ですが、その場合、大きな負荷がかかった時のパフォーマンスは低下します。
シンプルなテスト環境のセットアップで、大きな負荷がかかるとは予想されない場合には、すべてのコンポーネントを単一のサーバーにインストールしても構いません。単一サーバーへのインストールは、負荷の高い環境、または実稼働環境には推奨されないということです。
この記事のソリューションでは、Webform Server を分散形態でインストールします。Webform Server のインストール方法については、Lotus Forms Webform Server Administration Manual V3.0 (US) の説明に従ってください。Webform Server のすべてのコンポーネントを専用サーバーにインストールします (すなわち、WebSphere Portal 上にはインストールしません)。これで、変換プログラムが稼働します。
インストールが完了したら、お使いの Web ブラウザーで以下のリンクを開いて、Webform Server が正常に動作することを確認してください。
http://<<Webform サーバー名>>:8085/translator/Translate?pwsAction=toolbelt
Webform Server が正常に動作していれば、ウェルカム・ページが表示されます。これで、変換プログラムが専用サーバー上で稼動するようになりました。この記事の以下の部分では、変換プログラムを呼び出すために必要なポートレット・アプリケーションの作成に焦点を当てます。ポートレットを開発したら、これを WebSphere Portal 上にインストールして、これが専用サーバー上の変換プログラムを呼び出すよう構成します。
WebSphere Portal 上での API のインストールとセットアップ
作成するアプリケーションが API からの機能を使用してフォームを処理できるようにするために、WebSphere Portal 上に API をインストールする必要があります。しかし、このセットアップは、ユーザーが WebSphere Portal アプリケーションを作成する際に直面する、唯一最大の問題であることが、経験上わかっています。API をセットアップするためのプロセスが特に難しい、というわけではありません。実際、難しくはありません。問題は単に、従うべき手順が多数あり、これらの手順が、いくぶんエラーの起こりやすい性質を持っているということなのです。
このセクションで説明されている手順に従うにあたり、このことを念頭に置いてください。慎重に手順に従い、各手順について先に進む前に二重チェックするようにしてください。
API のセットアップ手順は、API の「Installation and Setup Guide」(US)に記載されていますが、問題が生じやすい領域であるため、ここでも改めて説明します。この説明のインストール例では、Linux プラットフォームで作業します。別のプラットフォームにインストールする必要がある場合には、製品資料を参照してください。
API を WebSphere Portal と連携するようセットアップするには、以下の手順を実行します。
- root としてログインし、API をお使いのコンピューターにインストールするためのインストーラー WFServer_300_API_Linux.bin を実行します。
- 以下のようにして、再配布可能ファイルを「/usr/lib」ディレクトリーにコピーします。
cp-r-p <API インストール・フォルダー>/redist/Linux/* /usr/lib
注: 「<<API インストール・フォルダー>>」の部分を API のルート・インストール・ディレクトリー名に置き換えてください。デフォルトでは、「/opt/IBM/Workplace Forms/Server/3.0/API」ディレクトリーとなります。
- 以下のようにして、ユーザーがファイルにアクセスできるよう、ファイルを変更します。
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
- 「/etc」ディレクトリー内で、PureEdgeAPI.ini ファイルを作成または更新します。このファイルには以下の設定を含める必要があります。
[API] 7.5.* = /usr/lib/PureEdge/75
- 以下のようにして、他のユーザーが PureEdgeAPI.ini ファイルにアクセスできるようにします。
chmod a+r /etc/PureEdgeAPI.ini
- ディレクトリー「/etc/PureEdge/API 7.5/prefs」を指定します。このディレクトリーが存在しない場合には新たに作成します。ディレクトリー「API 7.5」にはスペースがあることに注意してください。
- ディレクトリー「/etc/PureEdge/API 7.5/prefs」内に、「prefs.config」という構成ファイルを作成します。API はこの構成ファイルを使用して、いくつかのプロパティーを設定します。このケースに関係するのは、Java 仮想マシン (JVM) 内で使用される libjvm.so ファイルのパスを設定する javaPath プロパティーのみです。構成ファイルには以下のサンプル・コンテンツを使用してください。
javaPath = /opt/IBM/WebSphere/AppServer/java/jre/bin/classic/libjvm.so
注: お使いのサーバー上に複数の JVM がインストールされている場合、API が WebSphere Portal と連携するようにするには、javaPath が WebSphere Portal によって使用されている JVM を指していなければなりません。デフォルトでは、WebSphere Portal は「/opt/IBM/WebSphere/AppServer/java」ディレクトリーにある JVM を使用します。WebSphere Portal がどの JVM を使用しているかが不明な場合には、WebSphere Application Server の管理コンソールを開いて、以下の情報を確認してください。「Environment」 - 「WebSphere Variables」と開いて、WebSphere Portal を含むノードの範囲を指定した上で、JAVA_HOME 変数をチェックして Java 基本ディレクトリーを確認します。
- 以下のようにして、root 以外のユーザーが構成ファイルにアクセスできるようにします。
chmod -R a+r /etc/PureEdge
- 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)
- 以下のようにして、Java プロセス定義を設定します。
- WebSphere Application Server のコンソールで、「Servers」 > 「Application servers」 > 「WebSphere_Portal」 > 「Java and Process Management」 > 「Process Definition」 > 「Custom Properties」を選択します (図 2 参照)。
- 既存の「LD_LIBRARY_PATH」プロパティーの冒頭に「${WFS_API_DIR}:${WFS_API_DIR}/PureEdge/75/system:」と追加します。
図 2. カスタム・プロパティーを変更する
注: 適切な区切り文字を使用するよう注意してください。Windows ではセミコロン (;)、UNIX ではコロン (:) を使用します。
- 以下のようにして、共用ライブラリーを設定します。
- WebSphere Application Server のコンソールで、「Environment」 > 「Shared Libraries」を開きます。
- 「Browse Nodes」をクリックして、WebSphere_Portal を含むノードを選択します。
- 「Server」フィールド内を消去して、「Apply」をクリックします。
- 「New」をクリックして共用ライブラリーを作成し、これに「WFS_API_LIB」という名前を付けます (図 3 参照)。「Classpath」の下に、以下のファイル名を入力します (1 行に 1 つずつ)。${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)
- 以下のようにして、サーバー・クラス・ローダーを設定します。
- WebSphere Application Server の管理コンソールで、「Servers」 > 「Application servers」 > 「WebSphere_Portal」 > 「Java and Process Management」 > 「Class loader」を選択します。
- 既存のクラス・ローダーを選択し、「Libraries」をクリックします。
- 「Add」をクリックして、新しいライブラリー参照を追加します。
- 「Library Name」の下で、「WFS_API_LIB」を選択して、「OK」をクリックします。
- すべての変更を主構成に保存し、WebSphere Portal を再起動します。
XFDL フォームの設計
このアプリケーションでは、WebSphere Portal でホスト可能な購入注文書フォームを作成する必要があります。フォームは IBM Lotus Forms Designer を使用して作成することができます。ここでは、参考のために、図 4 として完成形のフォームを用意しました。
図 4. 購入注文書フォーム
この購入注文書フォームでは、XForms 送信を使用して、フォームのデータ・モデルを送信します。これはすなわち、フォームの表示自体 (XFDL 要素) ではなく、フォームのデータのみを送信することを意味します。
これは、そのような設計上の選択を行った結果です。希望に応じてフォーム全体を送信することも可能です。ただしその場合、処理中にデータを抽出する必要が生じます。モデルのみを送信することにより、その手順を省くことができます。とはいえ、状況によっては、フォーム全体を送信することが望ましい場合もあります。例えば、規制上の目的のために取引の完全な記録を残す必要がある場合には、XFDL フォーム全体を送信して保管した方が良いといえます。
XForms モデルのみを送信するようフォームを設定するには、フォーム自体に一定の単純な設定を行う必要があります。先ほど提示したサンプル・フォームには既にこの設定が施されていますが、改めて簡単に解説しておきましょう。
IBM Lotus Forms Designer でフォームを開いて、XForms ビューで送信を確認します (図 5 参照)。送信には、以下のプロパティーがあります。
- 「http://」のアクション・プロパティー
- 「post」のメソッド・プロパティー
- 「all」の置換プロパティー
図 5. XForms 送信のプロパティーを設定する
XForms 送信において、アクション・プロパティーの設定は必須です。ここでは、Webform Server を使用してフォームを WebSphere Portal で表示するため、このプロパティーは任意の値に設定することができます。実際には、Webform Server ではこの設定は無視され、代わりにフォームの変換時にこの URL が適切なポートレット URL に上書きされます。このアプローチにより、あらかじめ URL を知っていなくても、フォームが常に適切なポートレットに対して返されるようになります。
注: Webform Server をサーブレットで使用する場合には、返されたURL は自動的には上書きされません。また、フォームが IBM Lotus Forms Viewer および Webform Server の両方と連携するようにする必要がある場合には、IBM Lotus Forms Viewer に対して URL を適切に設定するようにしてください。これにより、フォームが Workplace Forms Viewer と適切に連携しながらも、Webform Server で使用された時には上書きされるようになります。
また、Webform Server をポータル環境で実行する場合、ユーザーが一定の操作 (フォームを保存する、フォームを開くなど) を実行できないようにする必要がある場合があります。そのような設定は、Webform Server ツールバーのボタンを使用不可にすることにより可能です。
これらのボタンは、フォーム自体の設定により制御されます。このため、常にボタンをオンまたはオフのいずれかに設定しておかなければならないという制約を受けることなく、フォームごとにボタンを制御することができます。この点についても、先ほど提示したフォームでは、適切なツールバー・ボタンをオフにするよう既に設定されていますが、ここで簡単に解説しておきます。
Lotus Forms Designer (サンプル・フォームをあらかじめ読み込んでおきます) で、「Outline」ビューを表示し、「globalpage」 > 「Form Global」を選択します。「Properties」ビューで、「General」 > 「ufv_settings」 > 「menu」を開きます。「open」、「refresh」、および「save」のプロパティーがすべてオフに設定されていることに注意してください。
これにより、Webform Server で「open」、「refresh」、および「save」ボタンがオフになり、ユーザーがこれらを利用できなくなります。
注: この設定は、Webform Server と Lotus Forms Viewer におけるツールバー・ボタンのみを制御するものです。フォーム内に別途、保存ボタンや印刷ボタンなどのコントロールを用意する場合には、これらのコントロールはこの設定に関係なく通常どおり機能します。
フォーム表示ポートレットの作成
このシナリオでは、ユーザーが WebSphere Portal に対しフォームを要求すると、Webform Server がフォームをユーザーに送信する前に HTML 形式に変換します。図 6 はこの手順を示したものです。
図 6. Webform Server にフォームを要求する
以下の手順に従います。
- ユーザーがポートレットにフォームを要求します。
- ポートレットが要求を受け取り、Form Repository 内で適切なファイルを探します。
- ポートレットがフォームを取り出します。
- ポートレットがフォームを Webform Server に引き渡します。
- Webform Server がフォームを、HTML と JavaScript を組み合わせたものに変換し、変換後のフォームをポートレットに返信します。
- ポートレットが変換後のフォームをユーザーに引き渡します。
上記の手順から、記述するポートレットはどのようなものであっても、Webform Server との通信が必要であることがわかります。幸いなことに、Webform Server では、この通信を開発者に代わって実行する、特殊なポートレットとサーブレットのクラスも用意されています。これはすなわち、汎用のポートレットとサーブレットのクラスを拡張してアプリケーションを記述する代わりに、Webform 固有のポートレットまたはサーブレットのクラスを拡張するということです。これらのクラスが、Webform Server の変換プログラム・コンポーネントとのすべての通信を自動的に処理するため、開発者はこのためにコードを記述する必要は一切ありません。これらのクラスはそれぞれ、フォーム関連アプリケーションの開発を迅速化するための、小規模な API を搭載しています。例えば、ポートレットが常にフォームを HTML に変換するように設定する、またはユーザーのコンピューターに Viewer がインストールされているかどうかを自動的に判別し、インストールされている場合には XFDL を送信するように設定するなどが可能です。
このようなクラスが用意されていることにより、開発者は、フォーム変換の詳細なメカニズムを意識せずに済むため、常に XFDL で作業していることを前提としたコードを自由に記述することができます。開発者が自ら HTML を処理する必要はもうないのです。ユーザーから返送されたすべての HTML は、コードによって処理される前に、インターセプトされ XFDL に変換し直されます。
このサンプル・シナリオでは、フォームをユーザーに提供するポートレットを作成する必要があります。そのためには、JSR 168 Portlet の Web フォーム固有のカスタム実装を表した抽象クラスである IBMWorkplaceFormsServerPortlet クラスを拡張する必要があります。このクラスを拡張した後に必要なのは、ポートレットを開発するための一定の単純なルールに従うことだけです。
以下の手順は、フォームを表示し、フォームの送信を操作する FormViewPortlet というポートレットを作成する方法を示したものです。
- IBM Rational IDE で JSR168 Portlet Project を作成します。
- Webform Server API JAR ファイル 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 がビルド・パスに自動的に追加されます。
- Rational IDE で、「forms.portlets.FormViewPortlet」という新しい Java クラスを作成します。これは、IBMWorkplaceFormsServerPortlet 抽象クラスを拡張するものです (図 7 参照)。
- 「Inherited abstract methods」オプションを選択して、新規クラスのための抽象メソッド・スタブを作成します。
図 7. FormViewPortlet を作成する
- 以下のインポートを FormViewPortlet のソース・コードにコピーします。
import com.PureEdge.DTK;
import com.PureEdge.IFSSingleton;
import com.PureEdge.error.UWIException;
import com.PureEdge.xfdl.FormNodeP;
import com.PureEdge.xfdl.XFDL;
- Rational IDE を使用している場合には、pe_api.jar と the uwi_api.jar をビルド・パスに追加する必要があります。これらの 2 つのファイルは、API とともに「<API インストール・ディレクトリー>/ lib/java」ディレクトリーにインストールされています。IDE はこれらのファイルを使用してコードをコンパイルし、ポートレットはフォームを処理する際にこれらのファイルを必要とします。ただし、これらの 2 つの JAR を「WEB-INF/lib/」ディレクトリーには入れないようにしてください。WebSphere Portal と連携させる API を既にインストールしているからです。
- ポータル・プロジェクトを右クリックし、ポップアップ・メニューから「Properties」を選択します。
- 「Java Build Path」ページを選択します。
- 「Libraries」ページで、「Add External JARs」ボタンをクリックして pe_api.jar と uwi_api.jar をビルド・パスに追加します (図 8 参照)。
図 8. API JAR をビルド・パスに追加する
- リスト 1 のように、init メソッドを指定変更して、API が初期化されるようにします。
リスト 1. init メソッドの指定変更
public void init(PortletConfig config) throws PortletException {
// always invoke the ancestor's method
super.init(config);
try {
// Initialize the API
DTK.initializeWithLocale("WFS Portal Sample", "1.0.0", "7.5.0", null);
} catch (UWIException e) {
throw new PortletException(e);
}
}
|
- 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...");
// force the portlet to display the XFDL form in HTML mode
super.useHTML(request, true);
// invoke the ancestor's method
super.doView(request, response);
}
|
注: IBMWorkplaceFormsServerPortlet は、Empty (空) または Full (完全) のいずれかの状態を保持します。Empty (空) の状態とは、フォームが 1 つも読み込まれておらず、フォームを読み込むために doViewEx を呼び出す必要があることを意味します。Full (完全) の状態とは、1 つのフォームが読み込まれており、doViewEx を呼び出す必要がないことを意味します。
- doViewEx メソッドを実装します (リスト 3 参照)。このメソッドでは、ポートレットが、FormNodeP.updateXFormsInstance メソッドを使用することにより、API を使用して、ファイル・システムからフォームを読み取り、保管情報をフォームに事前に自動入力します。その後このメソッドはフォームを応答オブジェクトに書き込み、応答オブジェクトのコンテンツ・タイプを application/vnd.xfdl に設定します。
リスト 3. doViewEx メソッドを実装する
public void doViewEx(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
log.debug("Start to execute the doViewEx method...");
// inform the ancestor portlet of the XFDL form's filename
setFilename(request, "PurchaseOrder.xfdl");
PortletContext context = this.getPortletContext();
// obtain the form file
String formFilePath = context.getRealPath("/") +
"/WEB-INF/form/PurchaseOrder.xfdl";
FileInputStream fis = new FileInputStream(formFilePath);
FormNodeP theForm = null;
try {
// set the content type appropriately
response.setContentType("application/vnd.xfdl");
// obtain the XFDL object, which is an interface through which you can access
// the form’s root node.
XFDL theXFDL = IFSSingleton.getXFDL();
// read a form into memory from a specified file
theForm = theXFDL.readForm(fis, XFDL.UFL_SERVER_SPEED_FLAGS);
fis.close();
// obtain the store information
String storeFilePath = context.getRealPath("/") +
"/stores/ID001001.xml";
// replaces the XForms instance in the form’s data model to prepopulate
// the form with store information
theForm.updateXFormsInstance(null,
"instance('poInstance')/schemaNS1:store", null,
storeFilePath, null, XFDL.UFL_XFORMS_UPDATE_REPLACE);
// write the form to the portlet response output stream
theForm.writeForm(response.getPortletOutputStream(), null, 0);
} catch (Exception e) {
log.error("Failed to display the form!", e);
} finally{
if(theForm != null){
try {
// destroys the indicated FormNodeP to remove it from memory
theForm.destroy();
} catch (UWIException e1) {
log.error("Failed to destory the form object!", e1);
}
}
}
}
|
フォームを応答オブジェクトに書き込んだら、doViewEx メソッドを終了させることができます。IBMWorkplaceFormsServerPortlet はその時点から稼動を継続します。先ほど、ポートレットが常にフォームを HTML で表示するよう指定したため、IBMWorkplaceFormsServerPortlet オブジェクトは自動的に Webform Server を呼び出して変換を実行させ、Webform Server はユーザーに HTML フォームを返します。
- 以上で、ポートレットでフォームを表示するコードが完成し、XForms 送信を処理する processActionEx メソッドの実装が完了しました。
replace="all"」と設定されている XForms 送信の動作は、「replace="instance"」と設定されている XForms 送信の動作と異なります。「replace="instance"」送信を使用すると、送信されたデータは Webform Server から自動的に処理 URL に引き渡され、戻りデータは自動的にフォームに埋め込まれてユーザーに返されます。これにより、ユーザーがフォーム内のデータ・インスタンスを操作している間に、データ・インスタンスが置換されます。ただし、「replace="all"」は手動で処理する必要があります。Webform Server では、この要求が同様に自動的には処理されません。
Webform Server は、「replace="all"」属性を持つ XForms 送信を受け取ると、xformsreplaceall HTTP ヘッダーを 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) {
// the portlet received an XForms submission here
FormViewSessionBean bean = this.getFormViewSessionBean(request);
bean.reset();
bean.setReplaceAll(true);
bean.setReplaceAllContentType(request.getContentType());
// read the submission data from the request inputstream
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);
}
// store the data in a FormViewSessionBean object
bean.setReplaceAllData(replaceAllData.toString());
} else {
log.debug("Portlet received other kinds of action in the processActionEx.");
}
}
|
-
doViewEx メソッドを更新して、ユーザー向けの画面に送信データが表示されるようにします (リスト 5 参照)。このメソッドはセッション内の FormViewSessionBean オブジェクトから送信データを取得し、データをポートレット応答オブジェクトに書き込みます。
リスト 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()) {
// the method has been called after a submission that resulted in a replaceAll
String replaceAllData = bean.getReplaceAllData();
// write the XML data as text in the screen
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 {
// here is the code to display the form for the user
…
}
}
|
以上のことからわかるように、doViewEx メソッドは 2 つの異なるシナリオを処理する必要があります。第 1 のシナリオでは、doViewEx メソッドはフォームをユーザーに表示する必要があります。第 2 のシナリオでは、doViewEx メソッドは、フォーム送信に対する HTML 応答など、何らかの別の結果を表示する必要があります。
また、このサンプルでは、送信データをユーザーに返します。現実のアプリケーションでは、送信データを何らかの別のアプリケーション (ワークフローなど) に送信して、そのアプリケーションからの応答 (正常または障害のメッセージなど) を取得する、というケースがあります。その後この応答をユーザーに転送するか、またはユーザーをアプリケーション内の次のステージ (第 2 のフォームなど) に移動させるといったケースが考えられます。
 |
2つのペインからなるポータルの作成
ここからは、シナリオを拡張して、それぞれ別々のポートレットを表示する 2 つのペインからなるポータルを作成します。第 1 のペインは、作成した FormViewPortlet を表示し、第 2 のペインは、「SupplierListPortlet」と呼ばれ、サプライヤーのリストを表示します。ユーザーが SupplierListPortlet 内で、あるサプライヤーを選択すると、FormViewPortlet が選択されたサプライヤーに関する情報をフォームに事前に自動入力した上で、フォームを表示します。
このポータルを作成するには、以下の手順に従います。
- Rational IDE で新規の JSR 168 ポートレットを作成し、これに「SupplierListPortlet」という名前を付けます (図 9 参照)。SupplierListPortlet ポートレットは XFDL フォームを直接処理しないため、IBMWorkplaceFormsServerPortlet クラスを拡張する必要はありません。その代わりに、GenericPortlet クラスを拡張します。そのため、doView メソッドと processAction メソッドが必要となります。
図 9. SupplierListPortlet を作成する
- doView メソッドで、「<コンテキスト・ルート>/suppliers」フォルダー内にある利用可能なすべての XML ファイルのリストが作成されるよう SupplierListPortlet ポートレットを設定します (リスト 6 参照)。
リスト 6. XML ファイルのリストが作成されるよう SupplierListPortlet を設定する
public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
log.debug("Start to execute the doView method...");
// get the suppliers
File supplierDirectory = new
File(this.getPortletContext().getRealPath("/") + "/" +
"suppliers");
File[] supplier_files = supplierDirectory.listFiles(new SupplierXMLFileFilter());
// display the suppliers in the screen
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();
}
|
- processAction メソッドで、SupplierListSessionBean という Bean が使用されるよう SupplierListPortlet ポートレットを設定します (リスト 7 参照)。この Bean は、どのサプライヤーがユーザーに選択され、セッション内に保管されたかを記録します。
リスト 7. Bean が使用されるよう 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 {
// store the selected supplier in the session
SupplierListSessionBean bean =
getSupplierListSessionBean(request);
bean.setFilename(filename);
}
}
|
- この時点で、FormViewPortlet で doView メソッドを更新します (リスト 8 参照)。ポートレットは初めに、選択されたサプライヤーをセッションから取得する必要があります。前述のように、IBMWorkplaceFormsServerPortlet は、ポートレットがフォームを表示したかどうかを記録するための状態を保持します。この場合、新しいフォームが選択された時にポートレットを Empty (空) に設定する必要があります。この設定は、super.resetPortlet メソッドを呼び出すことにより行うことができます。その結果、ポートレットが doViewEx メソッドを呼び出します。またこれに伴い、ページがリフレッシュされる都度フォームが再ロードされないようにするために、セッションから情報を削除する必要もあります。
リスト 8. FormViewPortlet で doView メソッドを更新する
public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
log.debug("Start to execute the doView method...");
String requestFilename = null;
// obtain filename from the session. The value was put into the session by the
//SupplierListPortlet.
SupplierListSessionBean listSessionBean =
this.getSupplierListSessionBean(request);
if(listSessionBean != null && (requestFilename =
listSessionBean.getFilename()) != null){
log.debug("A supplier has been selected: "+requestFilename);
// obtain the session bean
FormViewSessionBean bean = this.getFormViewSessionBean(request);
// update the FormViewSessionBean bean's values based on those found
// in the request's session
bean.setFilename(requestFilename);
// remove the filename in the request's session once we got it to avoid reloading
// the form every time
listSessionBean.setFilename(null);
// reset the ancestor portlet so that we guarantee the doViewEx() method is
//invoked to read in the new XFDL form
super.resetPortlet(request);
}else{
log.debug("No supplier was selected");
}
// force the portlet to display the XFDL form in HTML mode
super.useHTML(request, true);
// invoke the ancestor's method
super.doView(request, response);
}
|
- 次に、FormViewPortlet で doViewEx メソッドを更新します (リスト 9 参照)。ポートレットは、フォームを応答出力ストリームに書き込む前に、セッションからファイル名を取得し、FormNodeP.updateXFormsInstance メソッドを使用して、サプライヤー情報をフォームに事前に自動入力します。
リスト 9. FormViewPortlet で doViewEx メソッドを更新する
// read the directory and filename from the session bean
String supplierFile = bean.getFilename();
if(supplierFile != null){
String supplierFilePath = context.getRealPath("/")+"/suppliers/"+supplierFile;
// prepopulate the form with the supplier information
theForm.updateXFormsInstance(null, "instance('poInstance')/schemaNS1:supplier",
null, supplierFilePath, null, XFDL.UFL_XFORMS_UPDATE_REPLACE);
}
|
ポータル・アプリケーションの構成
portlet.xml において、IBMWorkplaceFormsServerPortlet のための init パラメーター設定を構成する必要があります。これは、分散型インストールの場合に特に重要です。分散型インストールの場合、Webform Server のさまざまなコンポーネントが複数のサーバーに分散している可能性があるからです。portlet.xml は、各コンポーネントがどこにインストールされているかを判定するために使用されるマップを提供します。
主要な設定は以下のとおりです。
- translatorLocation: 必須。Webform 変換プログラム・サーブレット (変換プログラムと呼ばれます) の場所です。
- logServerName: オプション。ログ・サーバーのホスト名です。
- logServerPort: オプション。ログ・サーバーのポート番号です。
- 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」と呼ばれる特別なサーブレットも使用する必要があります。また、アプリケーションによって WebformPortletForwarder サーブレットが適切に使用されるようにするために、以下のコンテンツをポートレットの web.xml ファイルに追加する必要もあります (リスト 11 参照)。
リスト 11. ポートレットの web.xml ファイルに追加するコンテンツ
<servlet>
<servlet-name>PWSForwarder</servlet-name>
<servlet-class>
com.ibm.form.webform.framework.portlet.WebformPortletForwarder</servlet-class>
<init-param>
<!-- This parameter points to the location of the Translator
servlet in Webform Server -->
<!-- You can change the server name and port here according
to your configuration of 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>
|
最後に、以下のように関連ファイルが適切な場所にあることを確認する必要があります。
- PurchaseOrder.xfdl XFDL フォームが「WEB-INF/form」ディレクトリーに作成されること
- ストアのための XML ファイルが「WebContent/stores」ディレクトリーに作成されること
- サプライヤーのための XML ファイルが「WebContent/suppliers」ディレクトリーにあること
以上で、ポートレットを作成して、これらを WebSphere Portal にデプロイするための準備が完了しました。ここからは、詳細な手順説明を省き、デプロイが行われたことを前提とします。ただし、ポートレットをデプロイする際に、ポータル・ページ内で SupplierListPortlet を FormViewPortlet の上に置く必要があることに注意してください (図 10 参照)。
図 10. ポートレットをページにデプロイする
ポータル・アプリケーションのテスト
アプリケーションをテストすることにより、ポータルと WebSphere Portal が適切にセットアップされたことを確認することができます。
- Web ブラウザーを開いて、WebSphere Portal にログインし、構築したポータルをホストしているページを開きます。ページの上部にサプライヤー・リストが表示され、そのすぐ下にフォームが表示されます。フォームを見ると、適切なストア情報が既に自動入力されていることもわかります。
- Supplier List Portlet でサプライヤーを選択します。図 11 で、フォームがサプライヤーの情報を反映して更新されていることがわかります。
- 「Add Row」または「Delete」ボタンを使用して、フォーム内で購入するアイテムを追加または削除し、各アイテムについて値を入力することができます。
図 11. フォームに入力する
- フォームへの入力が完了した後、「Submit」ボタンをクリックして、データをサーバーに返します。アプリケーションから、送信したデータと「Document submitted successfully.」というメッセージが表示されます。
まとめ
IBM Lotus Forms では、XML フォーム・アプリケーションを作成して配信することが可能です。さらに、Webform Server を使用することにより、Lotus Forms Viewer を各ユーザーに配布する必要がなくなり、ユーザーは使用している Web ブラウザーのみで Lotus Forms を操作することができます。Webform Server を使用すると、製品に付属のポートレット (またはサーブレット) クラスを拡張することにより、これらのアプリケーションを作成することができます。その後、希望に応じて、他のアプリケーションとの連携 (ワークフローやデータベースなど) を含む、あらゆる処理コードを組み込むことができます。この記事では、他のシステムと連携しない単純な例を使用しましたが、どのようにしてその種の処理を追加して、それにより企業のためのエンドツーエンドのソリューションを作成することができるかは簡単におわかりいただけると思います。
ダウンロード | ファイル名 | サイズ | ダウンロード形式 |
|---|
| WFSPortalProject.war | 395 KB | HTTP |
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | | | Lin Si Ri is a Software Engineer at the IBM Shanghai Globalization Lab (SGL) located in Shanghai, China. He works on Globalization Interoperability Testing projects. He is interested in Java, J2EE, Globalization, and Open Source. You can reach him at linsiri@cn.ibm.com. |
| | | Steve Shewchuk is a manager with the IBM Victoria Software Lab located in Victoria, Canada. He joined IBM as part of the PureEdge acquisition and has been working with forms for more than 10 years. |
記事の評価
| 
