XMLDB.jp

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

InfoPath徹底解析 1.InfoPathとは?

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



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

Section1:InfoPath とは?
コードネーム「XDocs」

InfoPath が最初に取り上げられたのは、Office 2003の発売のほぼ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 などのグループウェアを利用して構築する。

既にグループウェアによるインフラが整備されていれば④という選択肢も有力ですが、それ以外の一般的なケースにおいては、おそらく最有力候補は①になるでしょう。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)である





▲このページのTOPへ

  • 無償で使える!XMLDB「NeoCore」
  • サイバーテック求人情報
  • メールマガジン申し込み
  • TEchScore

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

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