InfoPath徹底解析 1.InfoPathとは？

Microsoft Office2003のハイライトとして、InfoPathという新製品が追加されました。XML対応が大幅に強化されたOffice2003の中でも、特にXMLに直接結びついた製品として特徴的な製品です。この特集記事では、このアプリケーションを徹底的に解剖し、サンプルを交えながら具体的な利用方法を探ります。

Section1：InfoPathとは？

コードネーム「XDocs」

InfoPathが最初に取り上げられたのは、Office2003の発売のほぼ1年前、2002年10月のこと。米国フロリダ州で開催されたSymposium/Itxpoにおいて、Microsoft社のCEOであるSteve Ballmer氏が「XDocs」というコードネームでこの製品に言及したのが始まりでした。その後、「XDocs」は「InfoPath」という名称になり、2003の中に加えられることになりました。

この製品にはOf.ceアプリケーションの中での存在、という意味でも大きな特徴があります。それは、InfoPathが他のOf.ceアプリケーションとは異なり、「完全に」企業・業務ユーザを対象にしている、ということです。WordやExcelを自宅で使う人は多くいますし、AccessやPublisherも、Wordほど多くないとはいえ、自宅で使っている方がいます。しかし、このInfoPathについては、業務以外の用途で使われるケースはほとんど考えられません。実際、店頭販売されるパッケージ版のOf.ce製品には（たとえProfessional Editionであっても）InfoPathは含まれていないのです。

しかし、純粋に企業向けアプリケーションであるInfoPathを、単体販売だけでなく、企業向けのみとはいえOf.ce製品の一部として加えたMicrosoftの戦略は興味深いものがあります。これには、既に広く普及しているOf.ce製品と共にInfoPathを浸透させ、企業内アプリケーションを大きく変えようとするMicrosoftの意気込みを感じさせます。確かに、InfoPathはそのポテンシャルを秘めているアプリケーションです。

今回の特集記事では、ケーススタディも含めながら、新たな分野のソフトウェアとも言えるInfoPathを徹底的に解剖していくことにしましょう。

まずその手始めに、InfoPathの概要を確認しておきましょう。

InfoPathとは？

InfoPathの話題になると必ず出てくるのは、「InfoPathって何？ InfoPathはどんなアプリケーション？」という質問です。確かに、Wordはワードプロセッサ、Excelは表計算、というようにソフトウェアをカテゴリで説明することがありますが、InfoPathはどういった種類のソフトウェアなのか、少々説明しにくいアプリケーションかもしれません。

InfoPathとは・・・
データベースやWeb サービスにデータを送信するための、『データ入力・表示用フォーム開発ツール』

Microsoftの製品説明によれば、InfoPathは「組織内に存在する情報の収集、そして情報の再利用プロセスを効率化するためのリッチフロントエンドアプリケーション」と説明されています。さらに思い切って簡略化してしまえば、InfoPathは「データ入力／表示用のフォーム開発／入力ツール」とでも言えるでしょう。

企業の内外を問わず、申請書や報告書など、何かの定型フォームに記入するという機会は非常に多くあります。これらの作業は、以前は紙を使って行われていましたが、現在ではオンラインでの入力・処理が一般的になってきました。それに伴って、フォームデータを処理するための数々のバックエンドシステム（データベースや処理系など）と様々な種類のフロントエンドシステム（ブラウザや入力画面など、ユーザの入力を受け付ける側）が作られ、運用されてきました。InfoPathは、この「フロントエンド」を作成、利用するためのアプリケーションです（図1を参照）。

図1：InfoPath を使った購入申請フォーム

InfoPathを使用する場合、まず開発者は、どんなデータを入力してもらうのか、入力されたデータをどのように収集するか、といった設計に基づいて、ユーザが使用するフォームをInfoPath上で作成します。フォーム上にはテキストボックスやリストボックス、ラジオボタンなどのコントロールを配置することができますし、InfoPathとデータを送受信するサーバ（バックエンドシステム）も、データベースやWebサービスなど、いろいろな選択肢の中から選ぶことができます。このように設計されたフォームはInfoPathデータファイルとして配布されます。

ユーザは、配布されたInfoPathデータファイルをInfoPathで開き、そのフォームにデータを入力します。入力が完了し、フォーム上の送信ボタンをクリックすれば、入力されたデータはサーバに送信され、その後の処理が行われます。また逆に、サーバ上にあるデータを特定の条件で検索し、その条件に合致したデータをフォーム上に表示することもできます。

既存のフロントエンドとの違いは？

InfoPathの利点を考えるため、単純な例を1つ考えてみましょう。たとえば、社員向けの交通費申請フォームを作るとします。各社員が入力したデータは社内にあるデータベースに送信され、保存されるとしましょう。このようなシステムを作り上げる場合、どんな方法が考えられるでしょうか？

• ASPやPHP、JSPなどを使い、Webサーバを使ったシステムを開発し、社員にURLを通知してブラウザでアクセス、入力してもらう。
• Accessを使って入力フォームを開発し、Accessプロジェクト（ADP）ファイルを配布する。
• Visual Basicなどの開発ツールを使い、専用クライアントソフトウェアを開発する。
• Lotus Domino/Notesなどのグループウェアを利用して構築する。

既にグループウェアによるインフラが整備されていれば4.という選択肢も有力ですが、それ以外の一般的なケースにおいては、おそらく最有力候補は1.になるでしょう。Webアプリケーションサーバとブラウザを使った処理システムはまさに今が「旬」とも言える構成で、幅広い分野で用いられています。もちろん個別の要件によって異なりますが、アプリケーションの更新の手軽さ、ユーザ教育が容易であること、開発コストが比較的抑えやすいこと、などにおいて、このような用途で最も利用されやすいのはWebシステムであるといえます。

しかし、Webシステムには避けきれない問題があります。その中でも最も大きい問題は、「フロントエンドはWebブラウザであり、入力にはHTMLフォームを使用する」という制約による限界です。たとえば、「リッチテキストを入力したい」、「ある項目の選択に応じて、別の項目の選択肢を動的に更新したい」、「フレキシブルな入力チェックを行いたい」、さらには「オフライン状態でも入力できるようにしたい」といった要望があると、Webブラウザを使ったシステムでは実現できないか、困難な場合が多くなります。確かにWebブラウザならではのメリットもありますが、ブラウザを使ったシステムは機能面においてどうしても専用クライアント（リッチクライアント）に大きく劣ってしまうのが現実です。そのようなケースでリッチクライアント特有の機能がどうしても必要になってしまうような場合は、Webブラウザだけで実現するのはあきらめ、FlashやActive Xコントロールを併用したりして対応しているのが実情でしょう。しかし、そのように作りこんでいくとなると、Webブラウザを使ったシステムの大きな利点であるメンテナンス性に影響が出てきます。

InfoPathが切り込もうとしているのは、まさにこのような領域です。Webブラウザの持つ導入面でのメリットと、グループウェアや独自開発の専用クライアントが持つリッチクライアントとしての高い機能、さらには特定のデータベースだけなく、Webサービスなどの他のデータソースへの接続性、それらすべてを併せ持つフォームを開発するためのツール、それがInfoPathなのです。

InfoPathと組み合わせるシステム

InfoPathでは、データの送受信の相手（バックエンドシステム）としてデータベースやWebシステムが利用できることを説明しました。バックエンドシステムとしては他にもいくつかの選択肢があり、それらを組み合わせて利用することもできます。主な選択肢には次のようなものがあります（図2を参照）。

図2：InfoPathを使ったデータ処理

データベース

簡単な設定だけで、InfoPathで作成したフォームとデータベースの間での送受信ができます。もちろん、リレーションが定義された複数のテーブルを扱うことも可能です。しかし、データソースとして直接データベースを指定できるのは、RDBMSとしてMicrosoft SQL Serverか、Accessを使っている場合のみという条件があります。他のRDBMS（Oracle やDB2 など）を使っている場合には、この方法では実現できません（別の方法で実現する必要があります）。

Web システム（ブラウザ）と比較した場合・・・
リッチテキストの入力や選択肢の動的な更新など、「リッチクライアント」としてのアドバンテージがある

Web サービス

InfoPathの1つの特徴として、Webサービスとのフォームデータの送受信が可能であることが挙げられます。しかも、複雑なコーディングや設定は必ずしも必要ではなく、簡単な設定だけでWebサービスとの通信が実現できるのです。通信先のWebサービス側では、InfoPathで入力されたデータを扱うためメソッドを提供している必要があります。Webサービス側で必要なメソッドは、Webサービスには作成するフォームの機能に応じて、（a）送受信両方、（b）送信のみ、（c）受信のみ、のいずれかです。これらのメソッドには、InfoPathとの間で送受信されるフォームデータを処理する機能を実装することになります。

ファイル

入力されたフォームデータを、XMLファイルとして保存することもできます。XMLスキーマなどで定義したデータ構造に忠実に書き出してくれますので、書き出されたXMLファイルを別のシステムに読み込ませ、処理させることもできます。さらに別の使用法もあります。データベースやWebサービスにデータを送信するフォームを使っている場合に、オフライン状態でデータを入力し、一時的に保存しておくためにも使用できるのです。オフラインの状態でもデータを入力し、XMLファイルとして保存しておけば、サーバとの通信が可能になった（オンラインになった）ときに、InfoPathで再度そのXMLファイルを開いて送信処理を行い、データをサーバに送ることができます。移動先で営業報告を作成する場合など、オフライン環境でデータを入力する必要のあるときには非常に便利な機能です。

その他

入力されたフォームデータをその他の方法で送信することもできます。たとえば、メールを使って送信する、独自の送信機構を利用する、Excelにエクスポートする、などの方法が考えられます。

入力されたデータは・・・
データベース、Web サービス、メール、さらには独自のシステムなど、幅広いデータソースとの送受信が可能

メール送信やExcelへのエクスポート、Share Point Portal Serviceへの送信はInfoPathの機能としても用意されていますので、要件に合致するようであれば、その機能をそのまま利用するのが簡単です。

さらに、InfoPathにはJScriptとVBScriptに対応したスクリプトエディタが備えられており、データ送受信用のスクリプトを独自に作成し、それを使うこともできます。入力されたデータをSOAP以外のプロトコルでWebサーバに送信したり、SQL ServerやAccess以外のRDBMSにデータを保存したりする場合には、独自スクリプトを利用することになるでしょう。

InfoPathでは、データベースやWebサービスとの送受信など、特に利用されることが多いと思われる方法を使う場合は特に、極力面倒な設定や開発作業を必要としないように設計されています。 InfoPathで作成されるフォームがシンプルな構造で、既にデータベースやXMLのスキーマがあるような場合、また特定のデータを受け付けるWebサービスが既に公開されているような場合は、プログラミングなどの開発作業はまったく必要とせずに（あるいはちょっとしたプログラミングだけで）、あっけないほど簡単に入力フォームを簡単に作成できます。この手軽さもInfoPathの特徴といえるでしょう。

XMLアプリケーションとしての顔

当初、コードネームが「XDocs」だったこと、また当初からXMLを活用するアプリケーションとして発表されていたことからもわかるように、InfoPathは単なるフォーム設計アプリケーションだけではなく、XMLアプリケーションとしての側面も持ち合わせています。XML対応が強化された各Of.ce 製品の中でも、「XMLアプリケーション」の色をより濃く持っているのはInfoPathでしょう。実際、InfoPathを少し使ってみると、フォーム設計や設定などにおいてことごとくXMLを意識した構成になっていることがわかります。この点については、この後のセクションの中でも詳しく取り上げます。先ほど、入力されたデータをXMLファイルとして保存できることに触れましたが、これはInfoPathをXMLエディタとして使うことができる、ともいえます。ある特定のスキーマがあれば、それを基にInfoPath でフォームを作成し、そのフォームを使ってユーザにデータを入力させることにより、スキーマに沿ったXMLをユーザが簡単に作成できます。ユーザはXMLのタグや属性などを意識する必要はまったくありませんから、テキストエディタなどでXMLファイルを直接編集するよりもはるかに安全ですし、簡単です。また、InfoPathの持つ入力チェック機能、スペルチェック機能などを併用すれば、データの正確性をよりいっそう高めることもできます。

アプリケーション開発者にとっても、InfoPathをXMLスキーマの設計ツールとしての利用法があります。InfoPath上でデータソースの構造を定義すると、その構造をXSDファイルとして保存することができます。このように作成されたXSDファイルを他のシステムなどで利用することももちろん可能です。

さらにもう1つ、InfoPathとXMLの密接な関係を示す興味深い特徴として、InfoPathのフォーム設計を保存するデータファイルにおいてもXMLが活用されていることが挙げられます。今までのOf.ce製品、たとえばWordの.docファイルやExcelの.xlsファイルなどのデータファイルは、バイナリファイルとして保存されており、データ形式もオープンなものではありませんでした。しかし、InfoPathのデータファイル（.xsnファイル）は、InfoPathのフォームやデータソースを定義したいくつかの種類のXMLファイルをキャビネット（cab）形式で圧縮したものなのです（図3を参照）。

図3：xenファイルの内容－スクリプトファイルやいくつかのXMLファイルがcabファイルとして圧縮されたもの

ですから、cabファイルと同じようにxsnファイルを解凍し、その中の構成ファイルを参照することができます。実際にこのファイルを解凍してみると、InfoPathのフォーム構成など、構成ファイルがすべてXMLファイルとして記述されている（スクリプトファイルは除いて）こともわかります。

では、前置きはこれぐらいにして、次のセクションから、InfoPathを実際に使いながら各機能を詳しく見ていきましょう。

InfoPathのフォーム設計データは・・・
スクリプトファイルを除き、すべてXMLファイルとして記述され、それらをcab形式で圧縮したものがInfoPathデータファイル（.xsn）である