• [アーティクル]

Sharepoint

カスタム コンテンツ タイプを使用してデータ管理を標準化する

Pav Cherny

 

概要:

  • SharePoint を使用してコンテンツのライフサイクルを管理する
  • ドキュメント情報パネルを作成する
  • InfoPath を使用して Office ドキュメントと SharePoint ドキュメントを編集する

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

企業環境でよく見られますが、ドキュメントやその他のコンテンツ アイテムが大量に存在する場合、それらのドキュメント、関連するメタデータ、およびドキュメントの動きを集中的かつ再利用可能な方法で管理することは、

業務上および技術上困難な作業になります。Microsoft® Office SharePoint® Server 2007 を使用すると、組織内のさまざまなチームが Web サイトのワークスペース、ドキュメント ライブラリ、およびリストを共有できるようになるため、企業全体のコラボレーションが促進されます。

SharePoint 2007 のコンテンツ タイプを使用することで、コンテンツのさまざまな要素とライフサイクルの特性を標準化できます。サイト コンテンツ タイプは、特定のサイト コレクション、サイト、リスト、またはドキュメント ライブラリとは無関係に作成できるメタデータ定義です。これにより、企業全体で使用する一貫したプロパティ、ワークフロー、情報管理ポリシーなどの要素を設定し、各部門またはサイト所有者が目的に応じてコンテンツ タイプをカスタマイズできるようになります。

この記事では、Windows® SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server (MOSS) 2007 で導入された新しい SharePoint コンテンツ モデルを使用して、一般的な特性に基づいたエンタープライズ コンテンツの階層を構築する方法について説明します。これらのコンテンツ階層を使用すると、一貫したメタデータ、ワークフロー、および情報管理ポリシーをグローバル レベルで適用し、サイト コレクション、サイト、ドキュメント ライブラリ、およびリスト レベルで、それぞれのコンテンツ管理のニーズに合わせてこれらを柔軟に変更できるようになります。

この記事の付属リソースには、SharePoint コンテンツ タイプの下位レベルのいくつかの要素についてわかりやすく説明することを目的とした、多くのカスタム ツールが含まれています。また、ツールを必要に応じて拡張できるように、これらのソース コードも提供されています。ただし、これらのツールは十分にテストされていないため、運用システムでは使用しないようにしてください。これらのコードは、TechNet Magazine** Web サイト (technetmagazine.com/code08.aspx) からダウンロードできます。

コンテンツのライフサイクルとコンテンツ タイプの定義

SharePoint の関連リソース

組織でドキュメントやその他のコンテンツを管理する場合、多くのことを考慮する必要があります。特に、コンテンツを作成、公開、アーカイブ、および削除するときに、どのユーザーまたはプロセスがそれぞれどのような操作を実行するかを定義する必要があります。また、多くの場合、コンテンツを作成するための特定のテンプレートの作成、ユーザーに職責とアクセス権を割り当てるためのロールの定義、バージョン管理の提供、規制遵守の監視、保存とアーカイブ、メタデータの定義などを行う必要があります。

SharePoint コンテンツ モデルは、特定のコンテンツのライフサイクルがどれほど複雑でも、全般的な特性と個々のフェーズによって各コンテンツ アイテムの処理方法が決定されることを認識しています。たとえば、テンプレートと入力フォームを使用してコンテンツの作成を構造化したり、メタデータを使用してコンテンツの表示と検索を構造化したりできます。また、編集や承認などのワークフローの要件、アーカイブの要件、有効期間、および適用可能な情報管理ポリシーを使用して、各コンテンツ アイテムを識別できます。一部のコンテンツは、特別なテンプレートを必要としない場合や、アーカイブされない場合がありますが、それらのこともライフサイクルの特性として他のアイテムとの識別に使用されます。

SharePoint コンテンツ モデルを使用すると、各コンテンツ タイプを定義して、階層関係を確立できるようになります。階層関係では、子が親コンテンツ タイプから一般的な特性を継承し、必要に応じて特定の特性を追加します。

これを理解するための最も良い方法は、SharePoint の組み込みのコンテンツ タイプを調べてみることです。WSS 3.0 と MOSS 2007 には、ドキュメントやタスクなど、ドキュメント ライブラリまたはリストに格納できる一般的なアイテム用にあらかじめ定義された多くのコンテンツ タイプが含まれています。これらの標準のコンテンツ タイプの定義は、SharePoint サーバーの %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes フォルダにあります。このフォルダには、feature.xml というマニフェスト ファイルがあります。このファイルの内容を調べると、SharePoint では、標準のコンテンツ タイプの定義が、サイト コレクションを対象範囲とする (Scope="Site") 非表示の機能 (Hidden="TRUE") として実装されていることがわかります。また、実際のコンテンツ タイプの要素が格納されている要素マニフェスト ファイルが ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />) であることも確認できます。

SharePoint 機能についてさらに詳しく理解するには、MSDN® Magazine (msdnmagazine.com/issues/07/05/OfficeSpace) の Ted Pattison の Office Space コラム「SharePoint の機能」を参照することをお勧めします。

では、ctypeswss.xml ファイルをメモ帳で開き、これらの標準のコンテンツ タイプを調べてみましょう。SharePoint ユーザー インターフェイスに表示されるかどうかに関係なく、さまざまなコンテンツ タイプの内容を確認してください。ctypeswss.xml の内容は変更しないようにする必要があります。ctypeswss.xml を編集して、標準のコンテンツ タイプに新しいフィールドを追加したり、非表示のコンテンツ タイプを表示して SharePoint ユーザーが新しいコンテンツ タイプの作成に使用できるようにすることを考えるかもしれませんが、通常はその必要はありません。また、ctypeswss.xml を編集するとサポートされていない構成になるため、後から Service Pack をインストールしたときに、カスタマイズした内容が上書きされ、コンテンツ管理ソリューションが機能しなくなる場合があります。

より適切な方法は、必要な要素を新しい要素マニフェスト ファイルにコピーし、必要に応じてカスタマイズしてから、サイト コレクションを対象範囲とする新しい機能としてそのカスタム コンテンツ タイプを展開することです。サイト コレクションを対象範囲とすることで、サイト コレクション内のすべてのサイトでそのコンテンツ タイプを使用できるようになります。

ctypeswss.xml に Collaborative Application Markup Language (CAML) で記述されている System コンテンツ タイプの定義を次に示します。

<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>

Group 属性と Sealed 属性は、System コンテンツ タイプが非表示であり、シールされていることを示しています。そのため、SharePoint ユーザー インターフェイスでこのコンテンツ タイプを変更することはできません。System コンテンツ タイプには、ContentType というサイト内の組み込みの列を参照する FieldRef 要素が 1 つだけ含まれています。これは、最上位レベルの抽象要素です。他のすべての SharePoint コンテンツ タイプは、System コンテンツ タイプからこのプロパティを継承します。このようにして、SharePoint では、ドキュメント ライブラリまたはリストに格納されるすべてのコンテンツ アイテムにこのプロパティが含まれます。

図 1 は、この記事の付属リソースに含まれている ContentTypeHierarchy Web パーツを示しています。この図で階層をより直感的に理解していただけると思います。System が他のすべてのコンテンツ タイプのルートであり、その後に Item などが続きます。たとえば、Item コンテンツ タイプでは、それに続くレベルの設定が定義されています。ctypeswss.xml を確認すると、Title というサイト内の列を参照する単一のメタデータ フィールドが定義されていることがわかります。このようにして、下位レベルのすべての組み込みのコンテンツ タイプに Title プロパティが含まれます。

図 1 WSS 3.0 の組み込みのコンテンツ タイプの階層

図 1** WSS 3.0 の組み込みのコンテンツ タイプの階層 **(画像を拡大するには、ここをクリックします)

ctypeswss.xml に記述されている Document コンテンツ タイプの定義が示しているように、継承されたフィールドを削除することもできます。Document コンテンツ タイプには、対応する複数の RemoveFieldRef 要素が含まれています。ただし、Title フィールドによって、SharePoint のドキュメント ライブラリ ビューとリスト ビューの編集コントロール ボックス (ECB) ドロップダウン メニューへのアクセスが提供されるため、Title フィールドはカスタム コンテンツ タイプでも維持した方がよいでしょう。

継承されたフィールドの名前を変更する方法を示す良い例は、ctypeswss.xml の Far East Contact コンテンツ タイプです。対応するコンテンツ タイプ ID の 0x0116 を検索した後、Name="Title" という属性が含まれた FieldRef 要素を調べます。DisplayName 属性を使用して、ユーザー インターフェイスに表示されるフィールドの名前をどのように変更できるかを確認してください。この例では、DisplayName 属性を使用して、ユーザー インターフェイスに表示される Title フィールドの名前を "$Resources:core,Last_Name;" で参照されるローカライズ版のデータ値に変更しています。

図 1 をよく見ると、ContentType 要素の ID 属性によってコンテンツ タイプが一意に識別され、階層関係が確立されていることがわかります。どの ID も、親コンテンツ タイプの ID で始まり、その後に 16 進値が続いています。通常、標準のコンテンツ タイプには、子コンテンツ タイプに固有の新しい ID を作成するための 2 つの 16 進値が付加されます。もう 1 つの手法は、"00" と 16 進数の GUID を付加することです。たとえば、Office Data Connection File と Universal Data Connection File は、この手法を使用して Document コンテンツ タイプから派生させたコンテンツ タイプです。

ユーザーが覚えておく必要がある重要なポイントは、ContentType 要素の ID 属性を 1,024 文字以下にする必要があるということです。このため、16 進数の GUID を付加する方法をすべてのコンテンツ タイプで使用していると、階層関係の規模が大きくなった場合に問題が発生する可能性があります。ただし、2 つの 16 進値を追加する方法では ID が一意にならない場合があるため、この方法から始めることはお勧めできません。

一意性を確保するには、GUID の手法を使用してエンタープライズ コンテンツ タイプ用のグローバル名前空間を作成し、その名前空間内で、2 つの 16 進値を追加する方法に切り替えます。ID 属性と、コンテンツ タイプの定義のその他の要素については、WSS 3.0 SDK の「コンテンツ タイプ定義スキーマ」を参照してください。

コンテンツ タイプの依存関係

次に、SharePoint コンテンツ タイプを使用してコンテンツ アイテムの管理を構造化する方法について説明します。ドキュメント ライブラリとリスト、コンテンツ タイプ、サイト内の列、フィールド型との間の相互依存関係など、いくつかの依存関係を考慮する必要があります。ライブラリとリストはコンテンツ タイプを参照し、コンテンツ タイプはサイト内の列を参照します。また、サイト内の列はフィールド型 (Text、Note、Choice、Number、Currency といった標準的な WSS フィールド型) を参照します。これらの型は、Microsoft .NET Framework アセンブリ (WSS のコア アセンブリである Microsoft.SharePoint.dll など) に含まれています。

例として、もう一度 System コンテンツ タイプを使用します。先ほどは、CAML で定義された、このコンテンツ タイプのマニフェスト ファイルのエントリについて説明しました。既に説明したように、このコンテンツ タイプには、ContentType というサイト内の列を参照する FieldRef 要素が含まれています。このコンテンツ タイプの定義では、サイト内の列である ContentType そのものは定義されていないことに注意してください。ContentType は Text フィールドであり、%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields フォルダにある要素マニフェスト fieldswss.xml で定義されています。Text フィールド型は、%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML にある fldtypes.xml で定義されています。この依存関係ツリーからわかる重要なポイントは、SharePoint サーバー上のすべてのリソースを利用できるようにする必要があるということです。

使用するコンテンツ タイプは、ドキュメント ライブラリとリストのサイト レベル、またはさらに上位のサイトに作成する必要があります。同様に、コンテンツ タイプのメタデータ フィールドは、サイト内の既存の列を参照する必要があります。標準またはカスタム フィールド型に基づいて、コンテンツ タイプに標準またはカスタムのサイト内の列を追加できますが、これらのサイト内の列がローカル サイトに存在する必要があります。さらに、カスタム フィールド型を使用する場合は、基になっている .NET アセンブリが SharePoint サーバーに展開されている必要があります。

同様の依存関係は、ドキュメント テンプレート、カスタム イベント レシーバ、ワークフロー、およびその他のコンポーネントを参照するコンテンツ タイプにも当てはまります。たとえば、コンテンツ タイプの定義に、そのコンテンツ タイプに関連付けられたドキュメント テンプレートを参照する DocumentTemplate 要素を含めることができます。また、コンテンツ タイプの定義には、名前空間定義、ドキュメント情報パネルの定義、カスタマイズされた情報など、コンテンツ タイプの追加の特性を定義する 1 つ以上の XmlDocument 子要素を持つ XmlDocuments 要素を含めることもできます。

グローバル コンテンツ タイプを作成する

作成権限を持つユーザーは、新しいコンテンツ タイプとサイト内の列を SharePoint ユーザー インターフェイスで直接作成できます。ただし、そのコンテンツ タイプは、ローカル サイトとそれよりも下位のサイトでのみ使用できます。カスタムのサイト内の列は、ローカル サイトでのみ使用できます。これは、グローバル コンテンツ タイプを作成する場合には不十分です。グローバル コンテンツ タイプは、環境内のすべてのサイト コレクションで使用できるようにする必要があります。ここで、SharePoint 機能が役立ちます。SharePoint 機能は、簡単に複数のサイト コレクションにインストールしてアクティブ化することができます。このため、すべての場所に一貫性のあるサイト内の列とコンテンツ タイプの定義を適用することができます。

この記事の付属リソースには、グローバル コンテンツ タイプの作成方法を示す AdventureWorks というサンプル機能が含まれています。この機能では、Customer Documentation (顧客用ドキュメント) という汎用的なコンテンツ タイプが定義されています。これは、提案書やセールス レターなど、さまざまな種類の顧客資料を作成する際に使用できます。このようなドキュメントには、会社名、連絡先の詳細、住所などの顧客情報が関連付けられている必要があると考えるのが妥当です。このため、このコンテンツ タイプ用に Customer Name というカスタム フィールドを作成し、Department や Primary Phone などの組み込みフィールドをいくつか追加しました。付属のサンプルでは、ContentTypes.xml ファイルを編集してコンテンツ タイプとフィールドを変更し、SiteColumns.xml ファイルを編集してフィールドの参照を変更することができます。

readme.htm ファイルの説明に従ってこの機能を展開すると、複数のサイト コレクションで同時にこの機能をアクティブ化することができます。展開後、Customer Documentation コンテンツ タイプをグローバルに使用できます。個々の部門では、対象のドキュメント テンプレートに関連付けられた派生コンテンツ タイプを使用して、特定の顧客用ドキュメントを作成できます。付属リソースには、営業とコンサルティングで使用できるサンプル ドキュメント テンプレートが含まれています。図 2 は、コンテンツ タイプの作成例を示しています。

図 2 顧客用ドキュメントの親コンテンツ タイプと子コンテンツ タイプ

図 2** 顧客用ドキュメントの親コンテンツ タイプと子コンテンツ タイプ **(画像を拡大するには、ここをクリックします)

WSS 3.0 と MOSS 2007 では、いくつかの方法でカスタムのサイト内の列とコンテンツ タイプの機能を作成できます。まず、WSS 3.0 SDK を参考にして、XML ファイルを一から作成できます。SharePoint Designer を使用して、個人用 Web パッケージへのリストのエクスポート、エクスポートした .fwp ファイルから .cab ファイルへの名前の変更、および .cab ファイルからの manifest.xml ファイルの抽出を行い、その後 manifest.xml ファイルの ContentType 定義を検索することもできます。残念ながら、どちらも不便でエラーが発生しやすい方法です。

対照的に、SharePoint ユーザー インターフェイスでは、カスタムのサイト内の列とコンテンツ タイプを非常に簡単に作成できます。ただし、このインターフェイスでは、機能の XML ファイルを編集することはできません。機能を使用すると SharePoint リソースを効率的に準備できますが、一度準備されたリソースはコンテンツ データベース内にしか存在しなくなります。おそらく、今後の WSS のバージョンでは、Web パーツのエクスポートと同じように、サイト内の列とコンテンツ タイプを SharePoint ユーザー インターフェイスから XML ファイルにエクスポートする機能が追加されるでしょう。現時点では、今あるもので対応する必要があります。

付属リソースには、出発点として使用できる ContentTypeSchema という Web パーツが含まれています。この Web パーツは、SharePoint オブジェクト モデルを使用して、選択したコンテンツ タイプから SchemaXML プロパティを抽出します。この Web パーツは eXtensible Stylesheet Language Transformation (XSLT) ベースの変換を使用し、ユーザー インターフェイスで [Display] (表示) ボタンをクリックする前に選択したオプションに応じて、Field の定義や ContentType の定義を導き出します。

図 3 は、この Web パーツを実際に使用したときの画面を示しています。この画面には、Customer Documentation コンテンツ タイプから派生した Active Directory® Documentation コンテンツ タイプが表示されています。Active Directory Documentation コンテンツ タイプは、カスタムの Microsoft Word テンプレート (Active Directory Template.dot) に関連付けられています。このコンテンツ タイプにはフィールドが追加されていないことに注意してください。すべてのフィールドは、親コンテンツ タイプから継承されます。

環境で ContentTypeSchema Web パーツの使用を計画している場合は、この Web パーツが十分にテストされていないことに注意してください。この Web パーツでは、比較的複雑な XSL 変換を使用して、現在選択されているコンテンツ タイプの SchemaXML プロパティとその親コンテンツ タイプとの間の差分を作成しています。ただし実際には、XSLT 1.0 の設計は高度な XML ドキュメント変換には対応していません。XML ノードを比較する機能は組み込まれていません。また、XML 名前空間では、CDATA セクションと同様、XSLT 1.0 で効率的に対処できない問題が発生します。

SharePoint では、SharePoint ユーザー インターフェイスや SharePoint オブジェクト モデルを使用して作成されたサイト内の列とサイト コンテンツ タイプの定義が、コンテンツ データベース内の ContentTypes というテーブルに格納されます。図 3 で、カスタム コンテンツ タイプの ID を見てみましょう。この ID を使用して、T-SQL ステートメント SELECT Definition FROM ContentTypes WHERE ContentTypeId = <コンテンツ タイプの ID> を実行すると、図 3 とまったく同じ結果が返されます。

図 3 ContentTypeSchema Web パーツ内のカスタム コンテンツ タイプの定義

図 3** ContentTypeSchema Web パーツ内のカスタム コンテンツ タイプの定義 **(画像を拡大するには、ここをクリックします)

どの方法を使用する場合でも、一度サイト内の列とコンテンツ タイプの定義を取得すれば、企業全体に適用するコンテンツ タイプ用の機能を非常に簡単に作成できます。部門または企業のすべてのグローバルなサイト内の列とコンテンツ タイプに 1 つの機能を使用することをお勧めします。これにより、どこにサイト内の列とコンテンツ タイプの定義を新しく追加する必要があるかが明らかになります。

カスタム メタデータに基づいた企業全体の検索

コンテンツ タイプ階層のメリットとしてまず挙げられるのは、すべての子コンテンツ タイプが親コンテンツ タイプのメタデータ フィールドを継承することです。すべてのコンテンツ タイプには共通のメタデータ フィールドが含まれているため、ユーザーはドキュメント ライブラリのカスタム ビューおよびフィルタを非常に簡単に作成できます。

AdventureWorks サンプル機能は、このことを非常に直感的に表しています。コンサルタントと営業担当者のどちらが作成したコンテンツであるかにかかわらず、作成した Word 2007 文書をドキュメント ライブラリに保存する際には、Customer Name を指定する必要があります。これは、Customer Documentation 親コンテンツ タイプで、このメタデータ フィールドが必須のフィールドとして定義されているためです。コンサルタント チームや営業チームのメンバは、ドキュメント ライブラリ ビューで、Customer Name に基づいたアイテムのグループ化またはフィルタを実行することにより、顧客用の既存のドキュメントを迅速かつ便利に検索できます (図 4 参照)。

図 4 共通のメタデータに基づいてライブラリ内のさまざまなドキュメントをグループ化する

図 4** 共通のメタデータに基づいてライブラリ内のさまざまなドキュメントをグループ化する **(画像を拡大するには、ここをクリックします)

また、共通のメタデータを使用することにより、WSS 3.0 と MOSS 2007 の検索機能で、複数のドキュメント ライブラリとサイトのコンテンツを簡単に検索することができます。WSS では、1 つのサイト コレクション内のサイト、ライブラリ、およびリストの検索がサポートされています。MOSS 2007 ではこれらの基本的な機能がさらに強化されており、企業規模の検索センターを実装して、SharePoint 3.0 サーバーの全体管理のユーザー インターフェイスでカスタム メタデータを管理することができます。ここからは、この MOSS 2007 に重点を置いて説明します。

MOSS 2007 の共有サービス プロバイダ (SSP) を構成して SharePoint サイトをクロールすると、コンテンツ ソースで使用されているカスタム メタデータ フィールドを MOSS 2007 が自動的に検出できるようになります。したがって、クロールされたプロパティのリスト内にあるカスタム メタデータ フィールドを検索できます。

SharePoint 機能で定義されているメタデータ フィールドは、通常、SharePoint カテゴリに分類されます。SharePoint サーバーの全体管理で SharePoint カテゴリを開くには、サイド リンク バーの [共有サービス管理] で、SSP へのリンクをクリックし、[検索の設定]、[メタデータ プロパティのマッピング] を順にクリックします。次に、サイド リンク バーの [クロールされたプロパティ] をクリックします。

次に、実際の例を示します。Customer Name というメタデータ フィールドのクロールされたプロパティは、ows_Customer_x0020_Name になります。SharePoint では、クロールされたプロパティの前に "ows_" が付けられます。"_x0020_" は、1 つのスペースがエンコードされた表現です。このクロールされたプロパティの詳細を表示すると、このプロパティが検索インデックスに既定で含まれていることがわかります。そのため、ユーザーは、このクロールされたプロパティの値を使用して、コンテンツの検索を実行できます。ただし、検索の精度を高めるために、クロールされたプロパティを管理プロパティにマップしないようにして、ユーザーが明示的に顧客名でコンテンツを検索できるようにすることもできます。

クロールされたプロパティを管理プロパティにマップする場合、2 つの方法を使用できます。これらは、クロールされたプロパティごとに新しい管理プロパティを自動的に生成する方法、およびクロールされたプロパティを管理プロパティに手動でマップする方法です。最初の方法は、目的のクロールされたプロパティが属するカテゴリの設定を表示する場合に使用できます (クロールされたプロパティを SharePoint カテゴリなどのカテゴリ別に表示する場合は、サイド リンク バーの [カテゴリの編集] をクリックします)。[クロールされたプロパティの一括設定] で、[このカテゴリのクロールで検出された各プロパティ用に新しい管理プロパティを自動生成する] チェック ボックスをオンにする必要があります。ただし、SharePoint では、自動的に作成された管理プロパティに "ows" が付けられ、スペースが "x0020" でエスケープされます。クロールされたプロパティ ows_Customer_x0020_Name の管理プロパティは、owsCustomerx0020Name になります。ただしこれは、あまりわかりやすいプロパティ名ではありません。

おそらく、より適切な方法は、企業全体用のコンテンツ タイプを展開してから、クロールされたプロパティを管理プロパティに手動でマップすることです。クロールされたプロパティは、1 つ以上の管理プロパティにマップできます。SharePoint サーバーの全体管理で新しい管理プロパティを作成するには、サイド リンク バーの [共有サービス管理] で、SSP へのリンクをクリックし、[検索の設定]、[メタデータ プロパティのマッピング] を順にクリックします。次に、[新しい管理プロパティ] をクリックし、必要な情報を指定して、新しい管理プロパティを目的のクロールされたプロパティに関連付けます。

ユーザーは、管理プロパティを "プロパティ: 構文" の形式で指定するか、高度な検索で指定することによって、関連するコンテンツ アイテムを検索できます。たとえば、クロールされたプロパティ ows_Customer_x0020_Name を管理プロパティ Customer にマップすると、ユーザーは、単純に標準の検索ボックスで "Customer: <顧客名>" (Customer: Contoso など) と指定するだけで、顧客用のドキュメントを検索できます。

また、[高度な検索] ページのプロパティ リストには、コンテンツ タイプの最も重要なメタデータ フィールドの管理プロパティを含めることをお勧めします。これを行うには、[高度な検索] ページを表示し、[サイトの操作] をクリックして、[ページの編集] を選択します。この後、高度な検索のボックスで [編集] をクリックして、[共有 Web パーツの変更] を選択できます。[プロパティ] カテゴリを展開し、対応するテキスト フィールドにカーソルを移動してボタンをクリックすると、そのプロパティの XML ドキュメントを編集できます。<PropertyDefs> 要素には、<PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/> などのプロパティ定義を追加する必要があります。また、ResultType 要素 (<ResultType DisplayName="All Results" Name="default"> など) の下に、このプロパティ定義への参照を <PropertyRef Name="Customer" /> のように追加する必要があります。図 5a は、変更後の [高度な検索] のユーザー インターフェイスを示しています。図 5b は、検索結果を示しています。

図 5a 顧客名に基づいて IT インフラストラクチャに関するドキュメントを検索する

図 5a** 顧客名に基づいて IT インフラストラクチャに関するドキュメントを検索する **(画像を拡大するには、ここをクリックします)

図 5b 顧客名による検索の結果

図 5b** 顧客名による検索の結果 **(画像を拡大するには、ここをクリックします)

情報の一貫性を保つ

これで、最も重要なメタデータ フィールドとコンテンツ タイプを標準化し、MOSS 2007 に基づいて検索機能の範囲を企業内のすべてのサイト コレクションに拡張することができました。次は、ユーザーによってメタデータ フィールドに正確な情報が入力されるようにする必要があります。

これを行うための方法は 2 つあります。1 つ目は、ドキュメント テンプレート内の標準のドキュメント情報パネルを、ユーザーに定義済みの入力オプション (リスト ボックスなどで提供されます) を提供するカスタム InfoPath® フォームに置き換える方法です。2 つ目は、イベント レシーバをコンテンツ タイプにバインドし、対応するコンテンツ アイテムの作成、変更、削除をユーザーが行うたびに、メタデータや他の情報の精度を確認する方法です。

2 つの方法は、相互に補完し合っています。InfoPath フォームの主なメリットは、SharePoint コンテンツ タイプのプロパティの編集に便利であることです。一方、イベント レシーバを使用すると、ユーザーが InfoPath フォーム以外の方法でコンテンツ タイプのプロパティを編集した場合でも、有効なメタデータが入力されることが保証されます。イベント ハンドラは、特定のコンテンツ タイプにバインドできます。これにより、ドキュメント ライブラリとは関係なく、すべてのサイト コレクション内の各コンテンツ タイプに関連付けられたすべてのドキュメントに、イベントとその応答を指定できます。イベント ハンドラを作成および展開する方法については、msdn2.microsoft.com/ms453149 を参照してください。

コンテンツ タイプをカスタム ドキュメント情報パネルに関連付ける作業は、InfoPath 2007 がインストールされたコンピュータの SharePoint ユーザー インターフェイスで、そのコンテンツ タイプの [ドキュメント情報パネルの設定] を表示すると簡単に行うことができます。[ドキュメント情報パネル テンプレート] の [新しいカスタム テンプレートの作成] をクリックすると、InfoPath 2007 をデザイン モードで起動できます。ただし、サイト コンテンツ タイプに含まれているいずれかのサイト内の列に SourceID 属性が明示的に指定されていない場合、InfoPath がドキュメント情報パネル フォーム用の有効な XSD スキーマを作成できないことがあります。たとえば、前述の Customer Documentation コンテンツ タイプには Department、Office、e-mail など、連絡先固有の列が複数含まれているため、図 6 のような問題が発生する可能性があります。

図 6 InfoPath 2007 で発生する XSD スキーマの互換性に関する問題

図 6** InfoPath 2007 で発生する XSD スキーマの互換性に関する問題 **(画像を拡大するには、ここをクリックします)

この問題が発生した場合の解決方法は 2 つあります。1 つ目は、SourceID 属性が明示的に指定されていないサイト内の列への参照をコンテンツ タイプの定義から削除する方法です。2 つ目は、問題の原因である組み込みのサイト内の列を、InfoPath 2007 と互換性があるカスタムのサイト内の列に置き換える方法です。ただし、CAML で記述されたコンテンツ タイプのフィールド参照をコンテンツ データベースに準備した後、特に子コンテンツ タイプが既に作成されている場合は、そのフィールド参照を変更できないことに注意してください。Windows SharePoint Services では親コンテンツ タイプの定義に加えられた変更が追跡されないため、CAML で記述されたコンテンツ タイプの定義ファイルを簡単に更新することも、子コンテンツ タイプに変更を加えることもできません。

子コンテンツ タイプに変更を加えるには、SharePoint ユーザー インターフェイスまたはオブジェクト モデルから親コンテンツ タイプに変更を加えるか、既存のコンテンツ タイプから派生した新しいコンテンツ タイプを定義する必要があります。後者の方法を使用した場合、問題のフィールドを削除し、新しい列を追加できます。ユーザーは、新しいコンテンツ タイプから、その後使用するコンテンツ タイプを定義できます。ユーザーが不適切なコンテンツ タイプを選択しないようにするには、問題がある古いコンテンツ タイプを _Hidden コンテンツ タイプ グループに追加します。

既に述べたように、CAML で記述されたコンテンツ タイプを展開してアクティブ化した後に、そのコンテンツ タイプを更新することはできません。したがって、展開前にグローバル コンテンツ タイプをテストすることが非常に重要です。詳細については、MSDN の記事「コンテンツ タイプの更新」 (msdn2.microsoft.com/aa543504) を参照してください。

適切なフィールド参照が含まれたコンテンツ タイプを作成したら、InfoPath 2007 でカスタム ドキュメント情報パネルを作成できます。最適な方法は、サイト所有者が子コンテンツ タイプのカスタム ドキュメント情報パネルを作成できるようにすることです。InfoPath 2007 では、選択したコンテンツ タイプにカスタム ドキュメント情報パネルを直接発行するためのオプションが提供されます。このオプションを使用すると、展開作業が簡略化されます。また、ドキュメント ライブラリなどの集中管理された場所に InfoPath フォームを公開し、ドキュメント情報パネルへの参照をコンテンツ タイプに含めることもできます。CAML コンテンツ タイプと共にカスタム ドキュメント情報パネルを提供する場合は、この方法が最適です。図 7 は、このファイルの実装のアーキテクチャを示しています。

図 7 MOSS 2007 の集中管理された場所に公開する XSN ファイルの実装

図 7** MOSS 2007 の集中管理された場所に公開する XSN ファイルの実装 **(画像を拡大するには、ここをクリックします)

この記事のダウンロード ファイルには、AdventureWorks_Update という機能が含まれています。この機能は以前の AdventureWorks 機能を拡張したものであり、InfoPath 2007 と連携するサイト内の列が追加されています。AdventureWorks_Update 機能では、Customer Docs という新しいコンテンツ タイプが提供され、基になっている Customer Documentation コンテンツ タイプは非表示になるようにマークされています。この Customer Docs コンテンツ タイプでは、継承された組み込みのフィールドが新しいサイト内の列に置き換わっており、カスタム ドキュメント情報パネルと関連付けられています。

新しい Customer Docs コンテンツ タイプの定義には、ドキュメント情報パネルに関する情報を提供する XmlDocument 要素が含まれています。具体的には、xsnLocation 要素によって、ドキュメント情報パネルを実装する InfoPath フォーム http://companyresources/DIPs/customerDIP.xsn が参照されています。AdventureWorks_Update 機能を適用するための詳細な手順については、AdventureWorks_Update フォルダにある readme.htm ファイルを参照してください。

まとめ

SharePoint コンテンツ タイプを使用してメタデータのポリシーを作成し、それらの標準化されたポリシーを企業全体で使用してコンテンツを管理することができます。また、コンテンツ タイプ階層により、企業環境全体に関連する特性を標準化し、継承によってそれらをすべてのサイトに適用できるようになります。

特に重要なのは、MOSS 2007 の組み込みの検索機能を拡張することにより、ユーザーが特定のコンテンツを迅速かつ容易に検索できるようになるということです。また、メタデータに関連する情報の一貫性を維持し、情報管理ポリシーを集中管理することもできます。最適な方法は、最も抽象的なメタデータの特性に基づいてグローバル コンテンツ タイプを標準化し、後から変更が発生する可能性を最小限に抑えることです。注意深く設計されたコンテンツ モデルに基づいて作成された SharePoint コンテンツ タイプにより、企業全体でコンテンツのライフサイクルの管理を標準化できる新たな機能が提供されます。

Pav Cherny は、Biblioso Corporation の代表取締役です。主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでには、IT の運用とシステム管理について扱った書籍を執筆しています。

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