サイト プロビジョニング

概要

サイト プロビジョニングは、SharePoint のカスタマイズ分野の中で要望が高い機能です。 実際に、ほとんどの企業からは、権限を持ったエンド ユーザーがテンプレートを使用することにより、共通の情報アーキテクチャ、ブランド化、ユーザー エクスペリエンスなどを複数のサイトで再利用してサイトを作成するという機能要件が求められます。 開発者の観点からは、プログラム的にサイトを作成しプログラム的にこれらのサイトでカスタム情報アーキテクチャを提供することを可能にする必要があります。

例えば、既存の "プロジェクト サイト" のテンプレートを使って、手がけている複数のプロジェクトの一つ一つに専用サイトを作ることができると想像してみてください。 顧客や仕入先などに向けたサイトの作成においても、同様の需要があるでしょう。

しかし、テンプレートを使ってサイトの準備を容易にするプロビジョニング手法を提供することは基本であり、テンプレートのライフ サイクル マネージメントの提供も行える方法が求められます。 実際、個々のサイトの作成に使用されたテンプレートでの更新が、すべてのサイト インスタンスで適用されればとても便利です。

最近では、サイトとその情報アーキテクチャをプロビジョニングするためのたくさんの手法が知られています。この記事では、そうした手法の中から最も興味深いものを、それぞれの対象ターゲット プラットフォームと共に列挙します。

基本ガイドライン/一般的なルール

サイトをプロビジョニングするときに留意すべき基本ガイドラインとルールを説明します。

  • 情報アーキテクチャの適切なメンテナンスを他の要素から切り離して行えるように、情報アーキテクチャをブランド化、カスタム コンテンツ、UI 要素などの他の要素から独立させます。
  • 情報アーキテクチャ内では、サイト列とコンテンツ タイプの定義はサブ サイトではなくサイト コレクション レベルでのみ行い、サイト コレクション内のすべてのサブ サイトで同じ定義を使用します。

注:

サイト コレクションとサブ サイトの違いについての詳細は、このドキュメントの専用セクションを読んで下さい。

  • 組み込み成果物やその名前の変更はせず、カスタム要素の使用を優先させます。 たとえば、タイトルフィールドが使われているとの前提で開発が行われれること多いことから、タイトルフィールドの名前の変更は予期せぬ問題を引き起こす可能性があるため、これは避けてください。
  • お客様からの要望に速やかに応えるられるように、成果物のバージョン管理とテンプレートのライフ サイクル管理に向いたプロビジョニング手法を使用するようにします。

リモート プロビジョニング

適用対象: Office 365 | SharePoint Server 2016 | SharePoint Server 2013

リモート プロビジョニング手法は、CSOM や REST API などのリモート テクノロジを利用して、成果物、設定、ブランド化などの要素のプロビジョニングを行います。 この手法の主な特徴は、SharePoint ファームでコードを実行することなく、任意のリモート サービスや環境からサイトのプロビジョニングを行えることです。 この手法は、SharePoint アドイン、SharePoint リモート タイマー ジョブ、Azure 関数、Azure Web ジョブ、PowerShell など、様々な種類のソリューションで活用することができます。SharePoint 2013/2016 オンプレミスと SharePoint Online の両方で使用できます。

記事

サンプル

ビデオ

PnP プロビジョニング エンジン

適用対象: Office 365 | SharePoint Server 2016 | SharePoint Server 2013

PnP プロビジョニング エンジンは、PnP コミュニティ プロジェクトが提供するオープン ソース エンジンで、今すぐ使えるたくさんの機能を再利用してリモート プロビジョニング手法を活用できます。 PnP プロビジョニング エンジンを使用することにより、一から作り直す手間をかけずに情報アーキテクチャのプロビジョニングが行えます。 PnP プロビジョニング エンジンは、プロジェクトから参照可能な .NET ライブラリとして利用できる他、スクリプトを使用してリモート プロビジョニングをする必要がある場合は、一連の PowerShell コマンドレットを介しての利用もできます。 PnP プロビジョニング エンジンの大きな特徴の 1 つとして、運用中のサイトからテンプレートをエクスポートし、それ以前に作成する必要があったターゲット サイトにそのテンプレートを適用することができる点です。 このように、情報アーキテクチャを開発からステージング、そしてプロダクションへ移行するための強力なソリューションとなります。 それだけでなく、PnP プロビジョニング エンジンはバージョン管理と差分の取り扱いをサポートしているので、このエンジンを使い作成済みサイトの情報アーキテクチャの更新をすることができます。 PnP プロビジョニング エンジンはクラシック サイトだけでなくモダン サイトもターゲットに指定できます。

記事

サンプル

ソリューション

ビデオ

Web テンプレート

適用対象: SharePoint Server 2016 | SharePoint Server 2013

オンプレミス ユーザーの場合、Visual Studio を使用して Web テンプレートを定義する .WSP パッケージを作成するか、サイトをテンプレートとして保存し、生成された .WSP ファイルを使うことができます。 これはSharePoint Feature Framework に依存したプロビジョニング手法で、任意のターゲット サイト コレクションのソリューション ギャラリーに .WSP を格納します。 既存のサイトの情報アーキテクチャに基づいて新しいサイトを作成する手法です。

記事

サイト定義

適用対象: SharePoint Server 2016 | SharePoint Server 2013

Onet.xml ファイルに基づいたサイト定義は、オンプレミスで使える別の方法です。 SharePoint Feature Framework のグラマーに基づいた XML ファイルを活用し、SharePoint ファーム内のサーバーのローカル パスに保存されます。 常にファーム全体でデプロイされるため、既にプロビジョニングされたサイトに対しては、サポートされている方法でのアップグレードや変更を提供しません。 アーキテクチャと条件の関係上、SharePoint オンプレミスのみが対象となります。

記事

リスト定義

適用対象: SharePoint Server 2016 | SharePoint Server 2013

リストの定義を使用することにより、リスト テンプレートを定義し、その定義を再利用して複数のリスト インスタンスを作成することができます。 SharePoint Feature Framework に基づいたものです。 .WSP をマークアップのみのサンド ボックス ソリューションと定義することで作成できます。 しかし、ライフ サイクル管理の観点からするとメンテナンスを行いにくい旧式の手法であるため、リモート プロビジョニングの利用を優先させるべきでしょう。

記事

サンプル

リスト テンプレート

適用対象: SharePoint Server 2016 | SharePoint Server 2013

リスト テンプレートはオンプレミスのみが対象となりますが、リスト テンプレートギャラリーにアップロードできる .STP テンプレート ファイルを活用します。共通のリスト テンプレートに基づいて、リストの複数のインスタンスを作成することができます。 リスト テンプレートはオンプレミスのみで動作する旧式の手法であることから、クラウドや SharePoint Online への移行の妨げとなるため、使用は控えるべきです。

記事

サンプル

ビデオ

Feature stapling

適用対象: SharePoint Server 2016 | SharePoint Server 2013

Feature stapling はオンプレミス上で、既存のサイト定義をカスタマイズすることができます。 Feature stapling を使用すると、onet.xml にある元のサイト定義を変更することなくサイト テンプレートに成果物や機能を追加できます。特定のサイト定義に沿ったサイトの作成が行えるとともに、SharePoint Feature Framework に基づいたカスタム機能の適用が行えます。 オンプレミスではまだ動作しますが、旧式の手法であることから、新しいソリューションでの使用は控えるべきです。 代わりとして、SharePoint アドインまたは Office 365 アプリケーションでのリモート プロビジョニングなどの最新の手法の使用がのぞましいです。

記事

サンプル

サイト コレクションとサブ サイトの比較

サイトをプロビジョニングする必要がある場合は常に、「サイト コレクションまたはサブ サイトを作成する方が良いですか」というよく寄せられる質問があります。実際には、非常に多くの場合、答えは「依存」です。 どちらを選択するかを決めるための手がかりとなる情報を少し紹介します。

  • それぞれのサイト コレクションでは固有のユーザーとアクセス権が設定されているのに対し、サブ サイトではユーザーとアクセス権は親サイトから継承できます。 したがって、対象となるユーザーの集まりが複数ある場合、一つのサイト コレクション内にサブ サイトを作るのではなく、複数のサイト コレクションの作成を検討してみるのが良いでしょう。
  • SharePoint Online の観点から考えた場合、共有機能の有効化/無効化はサイト コレクション レベルではできますが、サブ サイト レベルではできません。
  • サイト列およびコンテンツ タイプをサイト コレクション レベルで定義した場合はこの定義はすべてのサブ サイトで継承されるため、同じサイト コレクション下のすべてのサイト間での情報アーキテクチャの共有を可能にします。
  • 一つのサイト コレクションに含まれるサブ サイト同士で同じ階層ナビゲーション構造を共有することとなり、ユーザー エクスペリエンスの全般的な向上につながります。
  • オンプレミスでの運用を考えた場合、サブ サイトは親サイト コレクションのデータベース ファイルに含まれてしまうのに対して、それぞれのサイト コレクションは専用のデータベースと関連付けることができます。 したがって、サード パーティ製の管理ツールを使った場合を除き、サブ サイト レベルではなくサイト コレクション レベルでのより細かなバックアップとメンテナンス ポリシーの実践が可能になります。
  • オンプレミスでの運用を考えた場合、サイト コレクションはデータベース ファイル間での移動を簡単に行えるのに対して、サブ サイトは親サイト コレクションのデータベースに常に付随した状態です。
  • サイト コレクション内に複数のサブ サイトを配置することで、コンテンツ クエリ Web パーツ (オンプレミスまたは SharePoint Online の従来の UI) を活用してより優れたデータ集計を可能にします。