IBM Lotus Forms Server – Lotus Forms Services Platform 技術概要

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 初級

小野 充志 (onoat@jp.ibm.com), WPLC 開発 & サービス　WPLC Business Partner Technical Enablement/ソフトウェア開発研究所, IBM

2007年 11月 16日

2007年9月末、XMLベースの電子フォームを作成・表示し、バックエンド・システムとの連携を容易にするためのプラットフォームである「IBM Workplace Forms」が、新たに「IBM Lotus Forms」（以下Lotus Forms）とブランド名を変え、バージョンも2.7から3.0にメジャー・バージョンアップし、大きな進化を遂げて発表されました。Lotus Forms 3.0には「ビジネス・プロセスの自動化」「ゼロ・フットプリント」「ウィザード形式のフォーム」「フィールド単位の電子署名」「簡単なフォーム設計」など数々の特徴があります。この中でもエンタープライズ規模の電子フォーム・ソリューションとして特に注目されるのは「ビジネス・プロセスの自動化」です。そして、このビジネス・プロセスの自動化に欠かせない電子フォームとバックエンド・システムとの連携を実現しているのが「Lotus Forms Services Platform」（以下Forms Services Platform）です。Forms Services Platformは、コーディングを必要とせず、簡単な設定ファイルの定義だけでバックエンド・システムとの連携を可能にする強力なプラットフォームです。本稿ではこのForms Services Platformの概要についてご紹介します。

Forms Services Platform 概要

Lotus Formsには以下の3つの製品がラインナップされています。

• Lotus Forms Designer　…　XMLベースの電子フォーム（XFDL, XForms）をデザインするためのデザイナー・ツール
• Lotus Forms Viewer　…　フォームのオフライン表示も可能にするクライアント
• Lotus Forms Server　…　サーバー側で電子フォームを処理するためのサーバー・コンポーネント

このうち、Lotus Forms Serverにはさらに以下の4つのサブコンポーネントがあります。

• API　…　フォームを処理するためのAPIとして、Java、CおよびCOMのAPIを提供
• Webform Server　…　XMLベースのフォームを動的にHTMLに変換してブラウザで表示できるようにするためのWebアプリケーション
• Deployment Server　…　Forms Viewerや各種フォームなどの配信をブラウザで管理するためWebアプリケーション
• Forms Services Platform …　本稿でピックアップしている、バックエンド・システムとの連携を容易にするためのプラットフォーム

Forms Services Platformは、前バージョンである2.7で新たに登場したプラットフォームです。Forms Services Platformが登場する以前は、Lotus Formsを既存のバックエンド・システムと連携させるために、図1のようにAPIを使用してシステムを構築していました。電子フォームを処理するための機能はAPIによって提供されていますが、バックエンド・システムと連携するための機能は特に提供されていなかったため、システムごとに独自のサーブレットを開発する必要がありました。

これに対し、バックエンド・システムと連携するための機能を汎用的なプラットフォームとして提供したのがForms Services Platformです。Forms Services Platformを使用したシステムは図2のような構成になります。

まず、従来はシステムごとに開発する必要があったサーブレットの部分が、Forms Services Platformで置き換えられました。Forms Services Platformではフォームの処理やバックエンド連携に必要な機能が、「Pipe（パイプ）」と呼ばれる小さな処理単位に分割されたコンポーネントとして事前に定義されており、ユーザーはその組み合わせを「Pipeline（パイプライン）」として定義ファイルに指定するだけで、コーディングなしで新しいサービスを作成することができます。

さらに、バックエンド・システムとの連携に、IBM WebSphere Transformation Extender（以下WebSphere TX）というミドルウェアを利用できるようになりました。WebSphere TXは、SAP、Siebel、PeopleSoftといった基幹システムに加え、DB2やOracleといったデータベース、さらにはWebサービスなどといった各種バックエンド・システムと連携するためのアダプターを多数提供しており（図3）、ユーザーはフォームが持っているデータ項目を定義する「TX Type Tree」ファイルと、フォームの各データ項目をバックエンド・システムのどの項目にマッピングさせるかを定義する「TX Map」ファイルを用意するだけで、フォームとバックエンド・システムとの連携が可能となります。

このように、Forms Services Platformを利用することで、サーバー・サイド・アプリケーションの開発工数を大幅に削減することができ、いくつかの設定ファイルを定義するだけで、コーディングすることなくバックエンド・システムとの連携を行うことが可能となりました。

上に戻る

Forms Services Platformのアーキテクチャー

Forms Services Platformの仕組みをもう少し詳しく紹介していきます。図4に示したのがForms Services Platformのアーキテクチャーです。

Forms Services Platformは全体としてはWebSphere Application Server上で動作する１つのWebアプリケーションです。その中の動きをご理解いただくために、先にも少し紹介した「Pipe」と「Pipeline」の考え方について説明します。

Pipeとは

Pipeとは「フォームの処理やバックエンド連携に必要な機能を小さな処理単位に分割したコンポーネント」です。図4では青枠内にあるパイプの図がこれに該当します。製品には、一般的なフォームの処理やバックエンド連携に必要な処理を行うためのPipeが18個提供されています。リスト1でそのうちのいくつかを紹介します。

製品が提供するPipeだけでは機能が足りない場合には、独自のPipeを作成することも可能です。Forms Services Platformの実行環境にはOSGi（Open Services Gateway initiative）を採用しているため、ちょうどJavaの統合開発環境であるEclipseにプラグインを簡単に追加できるのと同じように、作成したPipeをバンドルと呼ばれる形式で簡単に追加したり除去したりすることが可能です。本稿ではPipeの作成手順についてはご紹介しませんが、興味のある方はインフォメーション・センターをご覧ください。

Pipelineとは

Pipelineとは「Pipeを組み合わせることで処理の流れを定義したサービス」です。図3では緑枠部分がPipelineの定義されている部分にあたります。PipelineはHeadPipeを先頭にして、以下の3つのブランチで構成されます。このアーキテクチャーはJ2EEのアプリケーションでもよく使用されるMVC（Model-View-Controller）モデルを意識したものです。

• Actionブランチ　…　ビジネス・ロジックの処理を行う部分。MVCモデルのModelに相当。最初にこのブランチが実行される。
• Viewブランチ　…　クライアント側で表示するデータを生成する部分。MVCモデルのViewに相当。Actionブランチが完了したあとに実行される。
• Errorブランチ　…　エラー処理を行う部分。ActionブランチおよびViewブランチのどこかのPipeでエラーが起こった場合に、このブランチが実行される。

例えば、リスト1で紹介したPipeを組み合わせて、「リクエストで受け取ったフォームからXMLインスタンスのデータを抽出し、そのデータをデータベースに格納し、結果をHTMLで返す」というPipelineを構成した場合のイメージは図5のようになります。

先頭のHeadPipeから、まずActionブランチが呼び出されて、Pipeが順々に実行されます。Actionブランチの処理の流れは以下のようになります。

1. LoadFormPipe：　リクエスト・データからXFDLフォームのデータを取得する
2. ExtractInstancePipe：　XFDLフォームからXMLインスタンスを抽出する
3. RepoLoadPipe：　WebSphere TXに読み込ませるためのMapファイル（.mmc）およびデータベースのクエリ定義ファイル（.mdq）をファイル・レポジトリーからロードする
4. MapPipe：　WebSphere TXを呼び出し、3でロードしたMapファイルやデータベースのクエリ定義ファイルの定義に従ってデータベースにデータを保管し、結果をHTMLで受け取る
5. PreserveMapPipe：　　受け取った結果HTMLをViewブランチに渡すために保管する

Actionブランチの処理が完了したら、Viewブランチが呼び出されます。Viewブランチの処理の流れは以下のようになります。

6. RestoreMapPipe：　Actionブランチの最後のPreserveMapPipeで保管した結果HTMLを読み込む
7. ReturnDataPipe：　6で読み込んだ結果HTMLデータをクライアントにレスポンスとして返す

以上でこのPipelineの処理は完了です。もし、途中のいずれかのPipeでエラーが発生した場合には、Errorブランチが実行され、クライアントにレスポンスとしてエラー情報を返します。

Pipelineはいくつでも定義することが可能です。システムに必要なサービスの数だけPipelineを定義すれば、あとはそれらのサービスにリクエストを投げるフォームをLotus Forms Designerで作成するだけです。

上に戻る

バックエンド・システムと連携するためのPipeline定義手順

ここまでで、Forms Services Platformの仕組みについてご紹介しました。今度は、バックエンド・システムと連携するためのPipelineを実際に定義する手順をご紹介します。

WebSphere TXによる連携のためのマッピング定義

WebSphere TXを使用してバックエンド・システムとの連携を行うためには、フォームの各データ項目をバックエンド・システムのどの項目にマッピングさせるかを定義する必要があります。（WebSphere TXを使用してバックエンド・システムと連携を行う必要がない場合、他のパイプだけで処理が完了してしまう場合には、この手順は必要ありません。）

図6がマッピングを定義するまでの手順を示したものです。赤丸で囲った部分が「TX Map」と呼ばれるマッピングを定義する部分です。このマッピングを行うには、その両脇にある「TX Type Tree」と呼ばれるファイルを生成する必要があります。これは、データの構造と型をツリー形式で定義したものであり、フォームのデータ項目に対応するType Tree（赤丸の左側）とバックエンド・システムの項目に対応するType Tree（赤丸の右側）の双方が必要です。

フォームのデータ項目に対応するType Treeを作成するためには、図6のLotus Forms Designerという青枠で囲まれた部分のうち左側の3ステップを行います。各ステップは以下を意味しています。

1. インスタンスの抽出：　XFDLフォームの中から、データ部分だけを切り出したインスタンス呼ばれるXMLを抽出します。
2. スキーマの生成：　抽出したインスタンスからXMLスキーマを自動生成します。（最初からXMLスキーマをお持ちの場合は、それを使用して次のステップ3から始めることも可能です。）
3. TX Type Treeの生成：　XMLスキーマからWebSphere TX Type Treeを生成します。

実際の作業を行うためのツールとして、Lotus Forms Designerに専用プラグインが提供されています。このプラグインを使用して、Lotus Forms Designer上でフォームのデータ項目に対応するType Treeを作成する手順をまとめたものが図7です。どの操作も、右クリック・メニューから簡単に実行することができます。

一方、バックエンド・システムのデータ項目に対応したType Treeの作成には、WebSphere TX Type DesignerなどWebSphere TX Designer Studioに含まれるツールを使用します。具体的な手順はバックエンド・システムの種類ごとに異なりますが、非常に豊富な機能が提供されています。詳細はWebSphere TXの各種ドキュメントや製品付属のヘルプをご覧ください。

フォームのデータ項目に対応したType Treeとバックエンド・システムの項目に対応したType Treeの双方が準備できたところで、いよいよマッピングを行います。TX Mapを生成するにはWebSphere TX Map Designerと呼ばれるGUIツールを使用します。図8がWebSphere TX Map Designer上でマッピングを行う画面です。Lotus Forms Designerから図7の4番目のステップにある「Generate TX Map」を実行すると、この画面が起動します。左側に入力データ、右側に出力データのType Treeが表示されており、赤い矢印で示したように入力データから出力データへとドラッグ＆ドロップすることで各データを簡単にマッピングすることができます。

以上でマッピングは完了です。マッピング時に生成したTX Type TreeファイルやTX Mapファイルは、サーバー上のレポジトリーと呼ばれるファイル・システムに保存しておき、次に設定するPipelineから読み込めるようにしておきます。レポジトリーへの保存もLotus Forms Designerから行うことができます。

Pipelineの定義

Pipelineの定義には、Javaでよく使用されるプロパティー・ファイルを使用します。プロパティー・ファイルの中では、必要なパラメーターの値が「キー=値」の形式で定義されます。例えば、図5のPipelineを定義するプロパティー・ファイルはリスト2のようになります。

                
# Listen at /samples/submitForm
# Configure head pipe
ibm.HeadPipe.submit_form.connection = string:/samples/submitForm
ibm.HeadPipe.submit_form.pidOutputs.action = pipe:ibm.LoadRequestPipe.submit_form
ibm.HeadPipe.submit_form.pidOutputs.view = pipe:ibm.RestoreMapPipe.submit_form
ibm.HeadPipe.submit_form.pidOutputs.error = pipe:ibm.ReturnErrorPipe.submit_form

###########################################################################
# Action Pipeline
###########################################################################
# Load the Form object from the request
ibm.LoadFormPipe.submit_form.store = key:incomingForm
ibm.LoadFormPipe.submit_form.pidOutputs.main = pipe:ibm.ExtractInstancePipe.submit_form

# Extract customer instance data
ibm.ExtractInstancePipe.submit_form.form = key:incomingForm
ibm.ExtractInstancePipe.submit_form.instances.instance1.name = string:customerData
ibm.ExtractInstancePipe.submit_form.instances.instance1.store = key:customerInstance
ibm.ExtractInstancePipe.submit_form.pidOutputs.main = pipe:ibm.RepoLoadPipe.fsp_sample_su
bmit

# Load TX map from the repository
ibm.RepoLoadPipe.submit_form.repo = string:project-repository
ibm.RepoLoadPipe.submit_form.path = string:sampleTXProj/SampleTXMap.mmc
ibm.RepoLoadPipe.submit_form.storeAs = key:txmap
ibm.RepoLoadPipe.submit_form.pidOutputs.main = pipe:ibm.RepoLoadPipe.submit_form2

# Load TX data query file from the repository
ibm.RepoLoadPipe.submit_form2.repo = string:project-repository
ibm.RepoLoadPipe.submit_form2.path = string: sampleTXProj/SampleDB.mdq
ibm.RepoLoadPipe.submit_form2.storeAs = key:txmdq
ibm.RepoLoadPipe.submit_form2.pidOutputs.main = pipe:ibm.MapPipe.submit_form

# run the tx map with instance as input and retrieve a status html page 
# to send back to the client 
ibm.MapPipe.submit_form.map=service:mapping.impl.tx
ibm.MapPipe.submit_form.mapinputdata.TXMap = string:SampleTXMap.mmc
ibm.MapPipe.submit_form.mapinputdata.File1.data = key:txmap
ibm.MapPipe.submit_form.mapinputdata.File1.name = string:SampleTXMap.mmc
ibm.MapPipe.submit_form.mapinputdata.File2.data = key:txmdq
ibm.MapPipe.submit_form.mapinputdata.File2.name = string:SampleDB.mdq
ibm.MapPipe.submit_form.mapinputdata.InputCard1.data = key:customerInstance
ibm.MapPipe.submit_form.mapoutputdata.OutputCard1.data = key:outputHtml
ibm.MapPipe.submit_form.pidOutputs.main = pipe:ibm.PreserveMapPipe.submit_form 

# Store the extracted data into the render parameters
ibm.PreserveMapPipe.submit_form.keys = string:outputHtml

##########################################################################
# View Pipeline
###########################################################################
# Store the output data generated by the map into the render parameters
ibm.RestoreMapPipe.submit_form.keys = string:outputHtml
ibm.RestoreMapPipe.submit_form.pidOutputs.main = pipe:ibm.ReturnDataPipe.submit_form

# Returns the result html to the user 
ibm.ReturnDataPipe.submit_form.content = key:outputHtml
ibm.ReturnDataPipe.submit_form.mimetype = string:text/html

###########################################################################
# Error Pipeline
###########################################################################
# set the msg to display
ibm.ReturnErrorPipe.submit_form.pidOutputs.create = yes

プロパティー・ファイル内の各パラメーターには記述ルールがあります。図9に示したのは、各Pipeの次に呼び出すPipeを指定する際に使用する「pidOutputs.main」というパラメーターの値を指定する際の例です。このように、パラメーターを指定する場合には、<Pipe名>.<Pipeline名>.<パラメーター>という形式で記述し、イコールのあとにその値を<タイプ（string, key, pipeなど）>.<値>という形式で指定します。各Pipeで指定する必要のあるパラメーターについては、インフォメーション・センターにリファレンスがありますので、そちらを参照してください。また、プロパティー・ファイルの名前は一般的に<Pipeline名>.pipeline.propertiesとします。この例では、「submit_form.pipeline.properties」というファイル名になります。

このPipelineにアクセスするためのURLは、ibm.HeadPipe.<Pipeline名>.connectionというパラメーターで指定します。ここでは「string:/samples/submitForm」という値が指定されているので、実際にアクセスする際のURLは「http://<サーバー名>:<ポート番号>/wfsp/wfsp/samples/submitForm」となります。

Pipeline用プロパティー・ファイルの定義が完了したら、あとはこのファイルをForms Services Platformのextensionsフォルダーに保存するだけです。extensionsフォルダーはデフォルトでは <Forms Services Platformのインストール・フォルダー>\extensionsフォルダーですが、設定によって別のフォルダーを追加することも可能です。extensionsフォルダーに保存すれば、自動的にForms Services PlatformのWebアプリケーションがOSGi環境を通じてPipelineをロードします。

上に戻る

Java Access API

Lotus Forms 3.0から新しく追加された機能の1つにForms Services PlatformのJava Access APIがあります。

従来は、図4のようにLotus Formsの電子フォームからForms Services PlatformのサービスにHTTPリクエストを投げてアクセスするケースについてのみサポートされていたため、他のサーブレットやJavaアプリケーションからアクセスするためのAPIなどは提供されていませんでした。そのため、他のサーブレットやJavaアプリケーションから使用する場合には、HTTPリクエストをForms Services Platformのサービスに投げてレスポンスを受け取るというコーディングを行い、Webアプリケーションに対するクライアントとしてアクセスすることしかできませんでした（図10）。

これに対して、3.0から提供されたJava Access APIを使用すると、必要なライブラリーをインポートすることで、Forms Services Platformを同じアプリケーションの中の１つのコンポーネントとして呼び出せるようになりました（図11）。つまり、サーブレットやスタンドアロンJavaアプリケーションの中でForms Services Platform環境を実行することができます。このとき、呼び出し側のサーブレットやJavaアプリケーションと、呼び出された側のForms Services Platformは1つの同じアプリケーションとして動作しています。図10でアクセスしている、製品に含まれているForms Services PlatformのデフォルトWebアプリケーションは不要です。さらにスタンドアロンJavaアプリケーションの場合は、アプリケーション・サーバーも不要となります。

リスト3は、Forms Services PlatformをJava Access APIを使用して内部的に呼び出すサーブレットのサンプルです。ここではリスト2で定義したPipelineを呼び出しています。このサンプルでは、リクエストをそのままForms Services Platformに転送しているだけですが、さまざまな処理を付け加えてカスタマイズしながらForms Services Platformを呼び出すことも可能です。

                
import com.ibm.form.platform.front.access.java.PlatformJavaAccess;
import com.ibm.form.platform.front.access.java.WorkRequest;
import com.ibm.form.platform.service.view.ModelAndView;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class JavaAccessSampleServlet extends HttpServlet {
	private PlatformJavaAccess javaAccess;
	
	public void init() throws ServletException {
		super.init();
		this.javaAccess = PlatformJavaAccess.getInstance();
	}
	
	public void destroy() {
		PlatformJavaAccess.releaseInstance();
		super.destroy();
	}
	
	protected void doPost(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
		try {
			WorkRequest theRequest = javaAccess.createRequest(request, response);
			theRequest.setPathInfo("/samples/submitForm");
			if ( !javaAccess.performAction(theRequest) ) {
				response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
			} else {
				ModelAndView mv = javaAccess.performView(theRequest);
				if ( !javaAccess.render(theRequest, mv) ) {
					response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
				}
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

上に戻る

まとめ

本稿では、Lotus Forms Server – Forms Services Platformの技術概要をご紹介しました。Lotus Formsは、その名前からもフォームを作成・表示するためのプラットフォームという面がクローズアップされることが多いですが、実はForms Services Platformという強力なプラットフォームが用意されていて、システム連携も容易に実現可能になっています。データベースやWebサービスといったシステムはもちろん、SAP、Siebel、PeopleSoftといった基幹システムともコーディングなしで連携できるというのは非常に魅力的であり、ビジネス・プロセスの自動化を加速するのに十分な力を持っています。Forms Services Platformの可能性を垣間見ていただいた上で、もう一度Lotus Formsという製品をご覧になっていただき、今まで以上の魅力を感じていただければ幸いです。

参考文献

• IBM Lotus Forms
  
  
• IBM Lotus Forms V3.0 - Japan
  
  
• developerWorks Lotus: Lotus Forms
  
  
• developerWorks Lotus: Lotus Forms documentation
  
  
• Workplace Forms Forums
  

• Lotus Forms 3 インフォメーション・センター　– フォームを他のシステムと統合する
  
  
• IBM WebSphere Transformation Extender
  

• 特集： すぐわかる！ IBM Workplace Forms のすべて
  
  
• Workplace Forms 技術概説
  
  
• Workplace Forms Designer 技術概説
  
  
• Workplace Forms API Toolkit 技術概説
  
  
• Integrating XML forms-based processes into Service-Oriented Architectures using IBM Workplace Forms Services Platform
  
  
• Integrating IBM Lotus Forms with SAP using the Lotus Forms Services Platform
  
  
• What's new in IBM Lotus Forms V3.0
  

著者について

		筆者は日本アイ・ビー・エム　ソフトウェア開発研究所のWPLC開発&サービスに所属し、IBM Lotus FormsやIBM Lotus Notes/Domino, IBM WebSphere Portal などの各種WPLC製品に対応したアプリケーション開発に取り組むISV/BP様への技術支援を行っています。先日、長年の飛蚊症の原因が網膜裂肛だと判明し、レーザー治療を行いました。近視の人はなりやすいということを初めて知り、目をいたわるようになった今日この頃です。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

上に戻る