• [アーティクル]

Sharepoint

企業内のデータを賢く収集する方法

Keith Deshaies

 

概要:

  • データを収集して処理する
  • プレゼンテーション ロジックと情報管理ロジックを分離する
  • Microsoft Office 2007 テクノロジを使用してデータ収集ソリューションを構築する

この記事で使用しているコードのダウンロード: DataGathering2008_02.exe (567KB)

企業では、膨大な量の情報がさまざまな方法で収集されます。これらのデータは、電子メール、アンケート、Web フォーム、およびその他のデータ収集メカニズムによって取得されます。通常、データとは便利な

ものです。しかし、一連のデータ収集ツールとさまざまな種類の情報をすべて管理することは困難です。信頼性の高い方法でデータを統合して安全に共有することは、IT 組織が常に直面している課題です。標準とサービス指向アーキテクチャは進化しており、より安全かつ容易に IT プロフェッショナルがデータにアクセスできるようになってきました。しかし、企業のアーキテクチャを効率的に構築できるツールやテクノロジを所有していても、ツールやテクノロジどうしを相互運用できないことがよくあります。これは、ソリューションの孤立につながります。

たとえば、Microsoft® Office system で使用できるテクノロジを例に考えてみましょう。Windows® SharePoint® Services 3.0 を使用すると、部署別のアンケートをすばやく作成できますが、これが標準のソリューションであるかどうかは組織によって異なります。Web ベースのコラボレーションとデータの統合を実装するためのプラットフォームとして ASP.NET と SharePoint を使用している企業では、このようなアンケートを標準のソリューションとして使用できます。しかし、私が作業しているような環境では、SharePoint は数あるプラットフォームのうちの 1 つでしかありません。

確かに、SharePoint では IBM、HP、Siebel などのシステムとの統合を行うためのさまざまなオプションが提供されます。これは、特定の目的を達成するためのソリューションを作成し、最終的にデータをさまざまなバックエンド システムに渡す必要がある上級ユーザーにとっては便利です。ただし、ソリューション アーキテクトは、InfoPath® 2007 というさらに優れた方法も利用できます。

2007 Office system に含まれている InfoPath 2007 を使用すると、ソリューションのプレゼンテーション ロジックと、サーバー側でホストされる情報管理ロジックを分離できます。XML ベースの InfoPath テクノロジを使用すると、企業規模のデータ収集ソリューションを構築できます。また、InfoPath フォームをデザインする際に、XML、Web サービス、ソリューション アーキテクチャ、ASP.NET、SharePoint オブジェクト モデルなどに関する詳細な知識が必要になることはほとんどありません。

この記事では、InfoPath 2007、Office SharePoint Server 2007、および Forms Services を使用して柔軟なデータ収集ソリューションを構築する方法について説明します。また、XML を使用して、複数の層から構成されるエンタープライズ アーキテクチャのプレゼンテーション ロジックとビジネス ロジックをどのように分離できるかについても説明します。

この記事で使用する "データ収集" という言葉は、人的情報源から情報を収集するプロセスを指しています。もちろん、データ ソースのクロールなど、データ収集の方法は他にもありますが、このような自動化された方法については、この記事では扱いません。

データを取得して処理する

データの取得要件は複雑になる可能性がありますが、共通している部分がいくつかあります。このような共通部分を一元管理用のモジュールで処理し、分離したコンポーネントで一意の要件を処理することによって、余分な作業の量、保守作業に関連するオーバーヘッド、および総保有コストを削減できます。

たとえば、株式会社では、法令遵守規定を基にビジネス要件が決定され、この要件を基に全社の情報管理ポリシーが決定されます。このようなポリシーは、複数の部署にまたがるデータ収集ソリューションに影響し、多くの場合、各部署内で重複した作業が発生します。たとえば、個人情報の収集に関するルールがあります。人事部によって社員情報の処理のために個人情報が収集され、顧客サービス部門によって顧客情報の処理のために個人情報が収集される場合、2 つの部署で重複した作業が発生します。部署間で似ているが関連していないビジネス プロセスが存在する場合、情報管理ソリューションを統合できる可能性があります。

図 1 は、典型的なビジネス プロセスの例を示しています。仕事の割り当てを同僚と交換する場合、まずその同僚の同意を得ます。次に、仕事のスケジュールの管理者または調整役の承認を受け、最後に上司からの承認を受けます。たとえば、従業員が勤務シフトを交代する場合がこれに該当します。このような交換はさまざまな部署で発生し、異なるフォームが使用される可能性がありますが、ワークフローと情報管理ロジックは、各部署のソリューション間で共有できます。

図 1 部署間で共有できるデータ収集プロセスの例

図 1** 部署間で共有できるデータ収集プロセスの例 **(画像を拡大するには、ここをクリックします)

もちろん、重複するコンポーネントの統合は、非常に手間のかかる作業です。全社規模で組織の変更を進めるのは簡単ではありませんが、Office system テクノロジを使用すると、このような変更を簡略化できる堅固な基盤を構築することができます。InfoPath 2007 を使用すると、一元化および標準化された情報管理システムと統合できるフォーム アプリケーションを部署ごとに作成できます。また、IT 部門は、SharePoint 2007 を使用すると、サイト コレクション、サイト、およびドキュメント ライブラリの管理作業を個々の部署やチームに委任できます。この結果、IT 部門がほとんど関与しなくてもチームが独自のソリューションを構築および展開できるようになります。また、引き続き IT 部門が、ワークフロー、情報管理ポリシー、バックアップ手順など、すべての共有サービスおよびコンポーネントを管理できます。

データ収集作業を一元化する

多くの場合、企業では、各部署用のアプリケーション サーバーを用意して、それぞれの情報管理のニーズに対応しています。IT 部門の作業はハードウェアとオペレーティング システムの稼動状態を維持することのみであり、ソリューションの管理はすべて各部門が行います。部署間の調整はほとんどないため、情報の共有は困難です。

データ収集を一元化する際の技術的な課題は、主に、共有環境でホストされるカスタム コンポーネントのセキュリティ、パフォーマンス、保守、およびサポートに関連しています。たとえば、部署用のアプリケーション サーバーで個々のソリューションがホストされる場合は、動作に異常があるコンポーネントの影響範囲はそのアプリケーション サーバーに限定されます。しかし、共有環境では、動作に異常があるコンポーネントが、より広範囲のビジネス プロセスに影響する可能性があります。したがって、IT 部門は一元管理用のシステム上で実行されるカスタム コンポーネントの展開と保守に関する厳密なポリシーを定義する必要があります。

各部署の SharePoint ソリューションを一元管理用のサーバー ファームでホストするには、各部署のソリューションで実行されているカスタム コンポーネントをすべて一元管理用のアプリケーション サーバーに展開して保守する必要があります。あるソリューションでは、カスタム フィールド型を使用してソリューションの UI を拡張し、バックエンドの Web サービスから取得したデータを基にドロップダウン リストを表示している可能性があります。別のソリューションでは、同じ目的で Web パーツを使用していたり、カスタム ワークフローを使用していることが考えられます。これらはすべてマネージ コードで記述されており、Microsoft .NET Framework アセンブリとして展開されています。

比較的少数の SharePoint ソリューションを一元管理用のアプリケーション サーバー ファームに移動する場合でも、構成やサポートに関する複雑な問題が発生する可能性があります。アセンブリをグローバル アセンブリ キャッシュ (GAC) に展開する必要がある場合、そのアセンブリは完全に信頼されたアセンブリとして実行されるため、セキュリティに関する問題が発生します。プログラムが適切に記述されていないコンポーネントが原因で、システムが SQL インジェクション、クロスサイト スクリプティング、またはサービス拒否攻撃を受ける可能性があります。また、これらのコンポーネントが、通常のワークロードだけでなく、ピーク時の要求や長時間の運用にも対応できるようにする必要があります。さらに、これらのコンポーネントが他のプロセスをブロックしないようにして、イベントが同期を取って処理されるようにしたり、信頼性の高い入力データ検証を実行して、ユーザーがデータベースやリモート Web システムの更新に使用される列に、SQL ステートメントやスクリプトを挿入できないようにしたりする必要もあります。

まとめると、最終的な目標は、標準の製品機能を基に安全性とスケーラビリティに重点を置いたサーバーを構成することです。十分にテストされた再利用可能なソリューションを使用すると、多数のカスタム コンポーネントを作成する必要がなくなります。フロントエンドを分離し、バックエンドを一元管理するという方法は理にかなっています。重要なことは、コンポーネントの結合度を抑えて、既存のソリューションの再利用性を高めることです。

ビジネス ロジックを分離する

では、サーバー上に構成できる柔軟なデータ収集ソリューションを構築するには、どうすればよいでしょうか。最善の戦略は、図 2 のようにソリューションのアーキテクチャを個別の層に分割することです。これらは、データ リポジトリ層、ビジネス ロジック層、およびプレゼンテーションまたは UI 層です。最近の一般的なアーキテクチャでは、UI がブラウザで提供され、ビジネス ロジックが Web アプリケーション サーバーに配置されます。これらはそれぞれ、データベースや非リレーショナル データ リポジトリにアクセスします。

図 2 3 層アーキテクチャを基盤とする一般的な企業用ソリューション

図 2** 3 層アーキテクチャを基盤とする一般的な企業用ソリューション **(画像を拡大するには、ここをクリックします)

多くの場合、ビジネス ロジックにはトランザクション ロジックが含まれており、トランザクションがデータベース管理システム間で自動的に適用されるようになっています。また、ビジネス ロジックでは、HTTP、メッセージ キュー、RPC などを経由して複数の中間層サービスを統合している場合があります。ただし、全体的なソリューションのアーキテクチャは基本的に 3 層モデルのままです。

図 2 には、企業環境でのビジネス ロジックの複雑さが表されていません。この図のアプリケーション サーバーは、単にブラウザ ベースのフォームの表示と送信されたデータの処理のみを行っており、ワークフロー、法令遵守、または情報管理に関する要件は考慮されていないように見えます。これらの要件に対処するには、ビジネス ロジックをプレゼンテーション ロジックと情報管理ロジックの 2 つに分割する必要があります。これにより、ソリューションごとに最初からコンポーネントを構築し直すことなく、中間層のコンポーネントを必要に応じて組み合わせることができます。

図 3 は、このアーキテクチャを示しています。中心にはコンテンツやデータがあり、それを情報管理ロジックが囲んでいます。このロジックが、コンテンツのライフサイクルの最初から最後までコンテンツを制御します。プレゼンテーション ロジックは、情報管理ロジックと連動して、ユーザー インターフェイスを使用したデータへのアクセスを提供します。

図 3 プレゼンテーション ロジックと情報管理ロジックの分離

図 3** プレゼンテーション ロジックと情報管理ロジックの分離 **

XML を収集して処理する

サービス指向アプリケーション (SOA) 環境では、コンポーネント間でデータとデータ構造を共有したり、これらを定義したりする際に、主に XML が標準として使用されます。したがって、プレゼンテーション コンポーネントと情報管理コンポーネント間の通信には XML が適しています。

通信では 2 つの処理を実行する必要があります。つまり、XML をブラウザから参照できるドキュメントに変換するだけでなく、フォームから XML ドキュメントを生成する必要があります。最近まで、XML ベースのフォーム アプリケーションの作成には、かなり高度なプログラミング技術が必要でした。組織間の情報交換を容易にするために、結果として得られる XML データを業界で使用されているスキーマに準拠させる必要がある場合は、特に高度な技術が必要でした。

InfoPath 2007 を使用すると、XML ベースのフォームの開発が大幅に簡素化されます。XML に関する詳細な知識があれば役立つことは確かですが、フォーム デザイナや上級ユーザーは、XML に精通していなくても、XML ベースのフォーム アプリケーションを作成できます。必要な作業は、XML ドキュメントや XML スキーマを InfoPath にインポートし、データソースの個々の属性と要素のノードをフォームのフィールドにマップすることだけです。また、Web サービスや SQL Server® データベース、または空白のテンプレートを基にフォームを最初から作成することもできます。この場合、基になるスキーマとデータ バインドが InfoPath によってバックグラウンドで自動的に作成されます。

InfoPath と XML スキーマを使用したフォームの標準化には、いくつかの利点があります。既に適切に定義された XML スキーマがある場合は、ワークフローのフォーム デザイナと開発者、および情報管理コンポーネントが揃っていれば、同じデータ構造を基にソリューションを作成できます。フォーム デザイナが一から作業を行う場合、開発者は、基になるデータ構造にそのデザインが与える影響を確認するために、フォームが完成するまで待機する必要があります。データ構造を一度定義すれば、今後新しいフォーム テンプレートなどのソリューションを同じデータ構造で作成する際に、既存のワークフローと情報管理コンポーネントを再利用できます。また、今後作成するワークフローや情報管理コンポーネントを既存のフォームおよびデータと連携させることができます。業界の標準として確立されているスキーマを基にデータ収集ソリューションを作成すれば、ソリューションの柔軟性はさらに高まります。実際に、これらのソリューションでは、同じスキーマを使用する他社製のソリューションとの互換性も提供されます。

社員を上司と関連付ける簡単な DirectReports スキーマを作成しました。上司は、このスキーマに基づいて作成されたフォームを使用して、直属の部下を評価できます。この記事の付属リソース (technetmagazine.com/code08.aspx) の Direct Reports フォルダには、このスキーマ、フォーム、およびフォームの再作成手順が記載された readme.htm が含まれています。基本的なフォームですが、一般的な考え方をよく表しています。

非常に重要なことを 1 つお話します。InfoPath では検証ロジックを作成しませんでしたが、ユーザー ID と電子メール アドレスは特定の形式 (domain\account および recipient@domain.tld) で入力する必要があります。この形式に準拠していない XML ドキュメントは無効になります。これは、XML スキーマによって、これらの形式が定義されているためです。図 4 からわかるように、無効なデータが入力されたフォームを保存することはできますが、送信することはできません (フォームにダミーの送信ルールを追加してあるため、実際にデータを任意の場所に送信しなくても、このことを確認できます)。フォームの内容が適切に入力されており、このようなエラーが発生しないかどうかが、InfoPath 2007 の検証によって自動的に確認されます。

図 4a 検証エラーが発生するとユーザーはフォームを送信できない

図 4a** 検証エラーが発生するとユーザーはフォームを送信できない **(画像を拡大するには、ここをクリックします)

図 4b 生成されたエラー メッセージ

図 4b** 生成されたエラー メッセージ **(画像を拡大するには、ここをクリックします)

XML スキーマは、プレゼンテーション ロジックと情報管理ロジックをつなぐ役割を果たします。このスキーマは InfoPath によってロックされるため、フォーム デザイナが意図的にデータ構造を変更することはできません。このことは重要です。業界で標準として確立されている XML スキーマを変更すると、新しいフォーム テンプレートと組み合わせて使用するワークフロー モジュールなど、企業の既存のソリューションが機能しなくなる可能性があります。

InfoPath では、高度なプレゼンテーション ロジックからフォーム アプリケーションを作成するための機能が多数提供されています。XML ファイル、Web サービス、SharePoint のライブラリとリスト、データベースなどのデータを利用して、意味のある既定値を設定できます。ルールとユーザーの選択内容に基づいてフィールドの値を変更したり、検証ロジックを追加したりすることができます。また、最も複雑なカスタマイズ要件を満たすマネージ コードを追加したり、Forms Service を使用して Web 経由でフォーム テンプレートへのアクセスを提供したりすることもできます。どの場合も、フォームから収集されたデータは、最終的にスキーマの定義に準拠した XML ドキュメントとして情報管理ロジックに渡されます。

XML またはメタデータを使用して作業する

送信された XML ドキュメントに情報管理ロジックを直接適用するのと、必要な情報をメタデータに抜き出すパーサーを使用するのとでは、どちらがよいでしょうか。SharePoint では、どちらの方法もサポートされています。開発者は XML ドキュメントを直接操作することに慣れていますが、メタデータを使用した方がより高い柔軟性が得られます。

このことを示すために、Direct Reports フォームから渡された XML ドキュメントを解析する、図 4 のような簡単な Web サービスを作成しました (この記事の付属リソースの MLParsingWebService フォルダには、ソース コード、セットアップ ファイル、および詳細な手順が記載された readme.htm が含まれています)。この Web サービスは、上司のユーザー ID を XML ドキュメントから読み取り、そのユーザー ID をドメイン名とユーザー名に分割して、この 2 つの部分を基にメッセージを作成します。その後、処理された情報を擬似エラー メッセージの形式で InfoPath フォームに表示する汎用的な例外を生成します。この方法を使用すると、データが送信された後、簡単にダイアログ ボックスを InfoPath にポップアップ表示できます。この Web サービスは適切に機能しますが、基になっているデータ ソースを変更 (たとえば、readme.htm ファイルで説明されているように、DirectReports.xsd の OrgPerson 要素の名前を Manager に変更し、新しいスキーマを使用して InfoPath フォームを更新) すると失敗します。しかし、これは驚くようなことではありません。XML ドキュメントが変更されたため、user-id 要素にアクセスするための XPath 式は無効になっています。OrgPerson スキーマと Manager スキーマの内容はほぼ同じであるため、これを基に作成される InfoPath フォームや目的の処理結果も同じものになります。しかし、違いがほとんどない場合でも、別々の Web サービスを展開して維持する必要があります。

これは、アプリケーション サーバーにできるだけカスタム コードを配置しないようにする必要がある場合は、あまり良い方法ではありません。これに対して、XML ノードをメタデータ フィールドにマップし、メタデータに基づいて処理を実行する方法であれば、XML スキーマが異なる場合でも、類似したデータ構造に同じワークフローと情報管理ロジックを使用できます。子要素が正しいメタデータ フィールドにマップされ、データの形式が処理要件を満たすようにすれば、既存のコードを再利用できます。

XML ノードをメタデータ フィールドにマップする作業は、XML ノードを InfoPath フォームの UI コントロールにバインドする作業と似ています (図 5 参照)。SharePoint のメタデータ フィールドはサイトまたはリスト レベルで定義されており、コンテンツ タイプの定義で参照されている列に対応しています。コンテンツ タイプでは、メタデータ フィールド、ワークフロー、フォームなど、コンテンツ アイテムの特性が定義されます。SharePoint は、プロパティの昇格と降格を実行する組み込みの XML パーサーを使用して、コンテンツ タイプのメタデータ フィールドと、関連付けられている XML ドキュメント内の対応するノードの同期を維持します。プロパティの昇格時には、XML パーサーが XML ドキュメントからノードの値を抽出して、ドキュメント ライブラリの対応する列に設定します。プロパティの降格時にはこの逆の処理が実行され、ドキュメント ライブラリの列の値がドキュメントに書き込まれます。最も重要な点は、XML パーサーによって、メタデータ フィールドとマップされている XML ノードの同期が維持されるということです。

図 5 InfoPath と SharePoint との間の XML スキーマのマッピング

図 5** InfoPath と SharePoint との間の XML スキーマのマッピング **(画像を拡大するには、ここをクリックします)

SharePoint オブジェクト モデルを使用すると、Web パーツ、ワークフロー、および情報管理ロジックを、メタデータ フィールドだけでなく、基になっている XML ドキュメントと連携させることもできます。マップされたメタデータ フィールドの値と XML ドキュメントのノードの値は、片方を変更するともう一方が変更されます。しかし、直接 XML ドキュメントと連携させると、ビジネス ロジックと XML スキーマの結合度が高まります。一方、マップされたメタデータ フィールドを使用すると、コードの再利用性が高まります。自分の環境に適した方法を判断する必要があることは明らかですが、通常は、SharePoint ソリューションをメタデータ フィールドと連携させた方が、柔軟性が高まり、コードを再利用しやすくなります。

この記事の付属リソースには、SharePoint での XML ノードとメタデータ フィールドの関連付けを示すことを目的とした、カスタム ドキュメント ライブラリを準備する SharePoint 機能が含まれています (付属リソースの OrgPersonLib フォルダにある OrgPersonContentType.xml を参照してください)。OrgPerson コンテンツ タイプは、UserID、FullName、Email、および Direct_x0020_Reports という 4 つのフィールドを参照します。FullName と EMail は組み込みのフィールドです。UserID と Direct_x0020_Reports は、OrgPersonSiteColumns.xml で定義されているカスタム フィールドです。

フィールドの定義は非常に単純です。フィールドの定義内でフィールドを直接 XML ノードにバインドすることもできますが、コンテンツ タイプ内でこの情報を上書きすることもできます。今回は後者の手法を使用することにしました。これは、XML ドキュメントに関連付けられていないコンテンツ タイプのカスタム フィールドと、異なる XML 構造に依存するコンテンツ タイプのカスタム フィールドを使用できるためです。OrgPerson コンテンツ タイプにより、前述の OrgPerson スキーマの配置に対応する XML ノードにメタデータ フィールドがバインドされます。また、同じメタデータ フィールドをさまざまな XML ノードにバインドするその他のコンテンツ タイプの定義を記述した、AdditionalContentTypes.xml も提供されています。Node 属性の XPath 式を見ると、違いを確認できます。

OrgPersonLib タイプのドキュメント ライブラリには、さまざまな種類の XML ドキュメントを格納できますが、ノードの値は同じライブラリ列で公開されます。この単純なマッピング手法では、4 種類のコンテンツ タイプ (OrgPerson、Manager、Supervisor、および User) が共通のメタデータ フィールドを参照しているため、ワークフローと情報管理ロジックを再利用することもできます。

図 6 は、Direct_x0020_Reports を参照する OrgPerson コンテンツ タイプの FieldRef 要素を示しています。この要素は、XPath 式 /OrgPerson/direct-report/user-id に従って、フィールドを直属の部下の user-id ノードにマップしています。XML ドキュメントには直属の部下のエントリを複数含めることができるため、Aggregation 属性を指定することが重要です。この属性は、返された値のコレクションを XML パーサーがどのように処理するかを定義します。この属性を省略すると、XML パーサーは最初のノードの値のみを抽出します。サポートされる集計値は、sum、count、average、min、max、merge、plain text、first、および last です。

図 6 XPath 式にマップされたメタデータ フィールド

図 6** XPath 式にマップされたメタデータ フィールド **(画像を拡大するには、ここをクリックします)

すべてのサンプル コンテンツ タイプでは、DocumentTemplate に標準の upload.aspx ページが 使用されているため、SharePoint UI の [新規] をクリックすると、XML ファイルをドキュメント ライブラリにアップロードできます。拡張子が .xml のファイルをアップロードすると、SharePoint は自動的に組み込みの XML パーサーを呼び出します (例外は WordProcessingML ファイルであり、この場合は WordProcessingML パーサーが呼び出されます)。XML パーサーは、アップロードされた .xml ファイルを調べ、関連付けられているコンテンツ タイプを特定します。これは、フィールドの定義で指定されている場所からノードの値を抽出して、プロパティの昇格を実行できるようにするためです (OrgPersonLib\XMLFiles フォルダにある OrgPerson.xml ファイルをアップロードすると、この処理を確認できます)。この XML ドキュメントの構造は、OrgPerson コンテンツ タイプの定義で指定されている XPath 式に対応しています。SharePoint は、この対応関係に従って .xml ファイルからデータを抽出し、そのデータを対応するライブラリの列に書き込んで、EditForm.aspx ページに表示します。これにより、読み取り専用になっていないドキュメント プロパティを確認および更新できるようになります。図 7 は、OrgPerson.xml から抽出したデータが表示された EditForm.aspx フォームを示しています。

図 7 抽出したデータが表示された EditForm.aspx フォーム

図 7** 抽出したデータが表示された EditForm.aspx フォーム **(画像を拡大するには、ここをクリックします)

EditForm.aspx の User ID、Full Name、または E-Mail の値を変更すると、SharePoint はプロパティの降格を実行し、基になっている XML ドキュメント内のノードの値を変更します。ただし SharePoint では、ユーザーがフォーム自体に必要なロジックを実装しない限り、XML スキーマの制限は適用されません。

また、SharePoint では、フォーム アプリケーションのプレゼンテーション ロジックは実行されません。たとえば、User ID を変更すると、SharePoint では新しい値が NetBIOS の規則に準拠しているかどうかが検証されず、Full Name および E-Mail フィールドが新しい選択内容に合わせて自動的に更新されません。したがって、個々のフィールドを変更することによって不整合が発生する場合は、コンテンツ タイプの定義の対応する列を読み取り専用にする必要があります。これにより、ユーザーはデータの更新に InfoPath などのフォーム アプリケーションを使用することを強制されます。また、XML パーサーによって、XML ドキュメントの変更を対応する SharePoint のメタデータ フィールドに昇格する処理が実行されます。

OrgPersonLib サンプルでは、OrgPersonLib\XMLFiles フォルダにある任意の .xml ファイルをアップロードできます。これらの .xml ファイルでは非常にさまざまなデータ構造が使用されていますが、SharePoint はこれらのコンテンツ タイプを認識して、正しいノードの値をサイト内の列に昇格させます。これは、XML ファイル内の処理命令を使用して、XML ドキュメントを対応するコンテンツ タイプに関連付けているためです。ただし、OrgPerson.xml ファイルにはこの情報が含まれていません。しかし、このことは問題ではありません。SharePoint が処理命令やドキュメント テンプレートを使用して XML ドキュメントをコンテンツ タイプに関連付けることができない場合、SharePoint では既定のコンテンツ タイプが使用されます。OrgPersonLib の場合は OrgPerson コンテンツ タイプがこれに該当するため、XML ドキュメントは正しく解析されます。

図 8 は、どのようにして XML ドキュメントを明示的にコンテンツ タイプに関連付けることができるかを示しています。MicrosoftWindowsSharePointServices 処理命令では、ContentTypeID として 0x010100668E393E4F0EFF4294DBD202D5D8321D が定義されています。これは、AdditionalContentTypes.xml で定義されている User コンテンツ タイプの ID と同じです。

図 8 User.xml サンプル ファイルの処理命令と XML データ

図 8** User.xml サンプル ファイルの処理命令と XML データ **(画像を拡大するには、ここをクリックします)

XML パーサーは、MicrosoftWindowsSharePointServices 処理命令を処理し、ContentTypeID の値を ContentType メタデータ フィールドに書き込みます。このメタデータ フィールドは、すべての SharePoint コンテンツ タイプによって共有されています。これは、System コンテンツ タイプのルート レベルでこのフィールドが定義されているためです。fieldswss.xml ファイル (%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields フォルダにあります) を SharePoint サーバー上で開き、MicrosoftWindowsSharePointServices を検索すると、SharePoint では処理命令がどのように ContentType フィールドに関連付けられているかを確認できます。PITarget 属性は MicrosoftWindowsSharePointServices (処理命令) を参照し、PIAttribute は ContentTypeID (User コンテンツ タイプの ID を保持します) を参照しています。

InfoPath でのコンテンツ タイプの関連付け

XML の解析とコンテンツ タイプの関連付けには専門的な知識が必要であるため、多くのフォーム デザイナが敬遠していますが、InfoPath 2007 を使用すると細かい処理がすべて自動で行われます。OrgPersonLib サンプルに付属している readme.htm ファイルには、SharePoint で Direct Reports フォーム テンプレートを公開し、新しいコンテンツ タイプを作成して再び同じメタデータ フィールド (UserID、FullName、Email、および Direct_x0020_Reports) にバインドする手順が記載されています。SharePoint UI を使用して、OrgPersonLib ドキュメント ライブラリに新しいコンテンツ タイプを簡単に追加できます。ただし、新しいコンテンツ タイプのドキュメント テンプレートには InfoPath フォーム テンプレートが指定されているため、既存の XML ドキュメントを更新するとフォーム アプリケーションが呼び出されます。図 9 は、InfoPath 公開ウィザードにより、XML ノードの値と SharePoint サイトの列との間のプロパティのマッピングがどのように簡略化されるかを示しています。この場合も、ノードの値と既存のサイト列を関連付けると、既存の SharePoint コンポーネントを再利用できます。

図 9 InfoPath 2007 でのプロパティのマッピング

図 9** InfoPath 2007 でのプロパティのマッピング **(画像を拡大するには、ここをクリックします)

まとめ

オンラインの参考資料

企業のアーキテクトは、Office で提供されるテクノロジを使用すると、コードの再利用と情報交換を促進するデータ収集ソリューションを作成できます。InfoPath 2007 を使用すると、各部署がさまざまな情報源から情報を取得できるソリューションを作成し、収集したデータを SharePoint などのさまざまなシステムに送信できます。また、SharePoint では、ワークフローと情報管理コンポーネントの作成に使用できる、包括的な一連の Web サービスとインターフェイスが提供されます。これらのコンポーネントを一元管理用の SharePoint サーバーでホストすることによって、各部署専用のアプリケーションの作成に必要なインフラストラクチャを確立できます。

また、各部署はデータ収集ソリューションをこれまでよりも短時間で作成できるようになります。法令遵守やその他のグローバルなビジネス要件に全部門レベルで対処し、アプリケーション サーバー上に配置するカスタム コンポーネントの数を減らすことで、IT 環境の保守性と信頼性を高めることができます。

Keith Deshaies は、フリーランスのテクニカル ライターであり、大手電気通信企業の IT アナリストです。Microsoft Office および SharePoint テクノロジを専門としており、Society for Technical Communications の会員でもあります。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.