XMLDB周辺技術
HOME  >  XMLDB周辺技術  >  InfoPath徹底解析 1.InfoPathとは?

InfoPath徹底解析 1.InfoPathとは?

2004年5月20日 更新
※この記事はDigital Xpress 2004 Vol.19(2-3月号)に掲載されたものです。

ソリューション関連記事InfoPath徹底解析

Microsoft Office 2003 のハイライトとして、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を参照)。

InfoPathを使った購入申請フォームの画面イメージ
図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を参照)。

InfoPathを使ったデータ処理イメージ
図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)である

▲このページのTOPへ

  • XMLとは?IT初心者でもすぐわかるXML超入門
  • 無償で使える!XMLDB「NeoCore」
  • サイバーテック求人情報
  • メールマガジン申し込み
  • TEchScore

  • ▲NeoCoreについて記載されています!

  • ▲XMLマスター教則本です。試験対策はこれでばっちり!
Copyright (c) CyberTech corporation ltd. All ights Reserved. | サイバーテックについて | ご利用ガイド