次の方法で共有


SharePoint Online ポータル用のナビゲーション ソリューション

すべてのポータル プロジェクトは、ナビゲーション ソリューションを実装する必要があります。 ナビゲーション ソリューションでは、プロジェクト要件に基づき、既成のナビゲーション コンポーネントのみ、カスタム ナビゲーション コンポーネントのみ、あるいはそれら両方の組み合わせを活用することを選択できます。

この記事では、SharePoint Online 上で良好なパフォーマンスを発揮するナビゲーション システムを構築する方法について説明します。

注:

このガイダンスは主に SharePoint Online を対象にしていますが、大部分はオンプレミスの SharePoint 環境でホストされているポータルにも適用されます。

行うべきではないこと

以下の一覧に、ナビゲーション ソリューションを設計するときに行うべきではない主要な事柄を示します。

以下を行わないでください:

  • ポータルのサイト コレクションの構造が複雑な場合に、既成の構造サイト ナビゲーションを使用する (複数レベルのサイトおよび/または固有のアクセス許可)。
  • 初期状態で折りたたみ済み/非表示になっているコントロールの場合でも、ページが読み込まれるとすぐに、すべてのカスタム ナビゲーション コントロールに対してすべてのナビゲーション ノードを要求するカスタム ナビゲーション ソリューションを使用する。
  • 受信するナビゲーション ノードをキャッシュしないカスタム ナビゲーション ソリューションを使用する。
  • 従来のリスト (SOAP) Web サービスを対象とするカスタム ナビゲーション ソリューションを使用する。形式が正しくない CAML クエリを渡すと、さらに問題が発生します。
  • 名前または ID (var termStores = taxSession.get_termStores();var termStore = termStores.getByName("Taxonomy_Dmxzz8tIBzk8wNVKQpJ+xA=="); など) により、推奨されるガイダンスが既定のキーワードまたはサイト コレクション用語ストア (var termStore = taxSession.getDefaultSiteCollectionTermStore();var termStore = taxSession.DefaultKeywordsTermStore() など) を取得することである場合に、参照により用語ストアを取得します。

カスタム ナビゲーション ソリューションの理論的根拠

ポータル設計者がカスタム ナビゲーション ソリューションを推進しようと判断するのには、多数の理由があります。 ほとんどの理由は、モダン ポータル デザインが本質的に応答性が高く、通常、機能豊富なナビゲーション システムを備えているという事実に関連しています。一方、提案されたデザインの 1 つ以上の要件を満たすように既成のサーバー側ナビゲーション コントロールを構成できないため、提案されたデザインを SharePoint にマップしようとすると最終的に失敗します。 具体的な例を次に示します。

既成のコントロールでは...

  • その管理 UX で応答性の高い UI デザインがサポートされない。
  • 必要な動作 (ポップアップ/ホバー、メガ メニュー、リッチ メディア、遅延読み込みなど) が表示されない。
  • 必要なナビゲーション階層属性 (ヘッダー、グループ化、深さ、リンク制限など) がサポートされない。
  • 必要なナビゲーション リンク属性 (サムネイル、イメージへのリンク、発行の開始/終了、強調など) がサポートされない。
  • 利用できない、または利用できなくなった (フッター、階層リンクなど)。
  • カスタム/従来のナビゲーション データ ストアと統合されない。
  • 管理 UX は、ナビゲーション コントロール全体で一貫性がなく、ユーザー フレンドリではない。

納得のいく十分な理由があれば、カスタム ナビゲーション ソリューションを検討してください。

既成のナビゲーション ソリューションの使用

カスタム ナビゲーション ソリューションの理論的根拠が評価され、それらの根拠のどれも該当しないと判断されました。 幸い、既成のナビゲーション ソリューションの実証済みパターンを活用することができます。

ナビゲーション ソリューションは、基本的には、ナビゲーション ストアからデータを受信するナビゲーション コントロール一式で構成されています。 既成のナビゲーション ソリューションを選択した場合は、通常、管理ナビゲーション (この記事で後述します) がナビゲーション ストアの選択肢として優先されます。それは、ページ読み込みのパフォーマンスが向上するためです。

もう 1 つの選択肢である、既成の構造化ナビゲーション (この記事で後述します) では、リソースの消費量が非常に大きくなりやすく (特に、複雑なサイト コレクション構造の場合)、ページ読み込みのパフォーマンスが大幅に低下します。

カスタム ナビゲーション ソリューションの使用

カスタム ナビゲーション ソリューションの理論的根拠が評価され、それらのうち十分な数の根拠が該当すると判断されました。 幸い、カスタム ナビゲーション ソリューションを開発するにあたっては実証済みパターンを活用することができます。

次の図は、カスタム ナビゲーション ソリューションの論理アーキテクチャを示しています。

カスタム ナビゲーション ソリューションの論理アーキテクチャ

次のセクションでは、論理アーキテクチャの主要コンポーネントについて説明します。

これは、ページ上に存在するカスタムのクライアント側 JavaScript 表示コントロールです。

一般に、コントロールは、ページ読み込み時にナビゲーション ストアのクエリを実行して、ナビゲーション データの応答を処理し、ナビゲーション コンポーネント (プレゼンテーション、情報、動作) をレンダリングします。 実際には、コントロールは遅延読み込みパターンを監視して、必要なときにのみナビゲーション データ要求を実行し、可能な限り長く遅延させる必要があります。

表示コントロールは、デザイン時に、マスター ページ、ページ レイアウト、Web パーツを介してページの静的な定義に追加したり、実行時に JavaScript 埋め込み技法を使用してページの動的な状態に追加したりできます。

表示コントロールは、クライアント側データ アクセス層 (この記事で後述します) を活用して、ページ パフォーマンスを最適化します。

表示コントロールには、オプションでナビゲーション管理ページの設定リンクが用意されている場合があり、ナビゲーション コントロールの構成を管理するためのユーザー インターフェイスを提供しています。

カスタム ナビゲーション ソリューションで通常使用されるさまざまな種類のナビゲーション コントロールの一般的なガイダンスをいくつか次に示します。

標準的なナビゲーション表示コントロール

  • グローバル ナビゲーション: 集約型のポータル固有のナビゲーション構成エンティティを対象とするカスタム コントロールを実装します。 ナビゲーション ノードにはパブリック キャッシュを使用します。 既成の管理ページを検討してください。
  • フッター ナビゲーション: 中央のポータル固有のナビゲーション構成エンティティを対象とするカスタム コントロールを実装します。 ナビゲーション ノードにはパブリック キャッシュを使用します。 既成の管理ページを検討してください。
  • サイト マップ: 中央のポータル固有のナビゲーション構成エンティティを対象とするカスタム コントロールを実装します。
  • 現在のナビゲーション (左側): ローカルの Web 固有のナビゲーション構成エンティティを対象とするカスタム コントロールを実装します。 ナビゲーション ノードにはパブリック キャッシュを使用します。 既成の管理ページを検討してください。
  • 階層リンク: このカスタム コントロールは実装しないでください。現在の Web の URL に基づく Web オブジェクトの親チェーンの構築は、コストのかかる操作です。
  • 便利なリンク: ローカルの Web 固有のナビゲーション構成エンティティを対象とするカスタム コントロールを実装します。 ナビゲーション ノードにはパブリック キャッシュを使用します。 既成の管理ページを検討してください。
  • マイ リンクプライベートなユーザー固有のナビゲーション構成エンティティを対象とするカスタム コントロールを実行します。 ナビゲーション ノードにはプライベートなキャッシュを使用します。 カスタム管理ページを提供します。

ナビゲーション ストアは、カスタム ナビゲーション コントロールの構成を維持します。 カスタム ナビゲーション ストアまたは既成のナビゲーション ストアのいずれかを、カスタム ナビゲーション コントロールで使用することを選択できます。

カスタム ナビゲーション ストア

最も一般的に使用されるカスタム ナビゲーション ストアであるカスタム SharePoint リストは、拡張性、管理しやすさ、およびパフォーマンス (検索を介したクエリの実行時) をバランスよく兼ね備えています。 リスト スキーマは、ナビゲーション ヘッダー/グループとナビゲーション リンクを表すカスタム コンテンツ タイプと、必要なカスタム属性 (表示順序など) を定義するサイト列を使用して、簡単に拡張できます。 これらのサイト列のクロールされたプロパティは、SharePoint 検索内の管理プロパティにマップできます。 ナビゲーション データは、使い慣れた既成のリスト管理ページを介して簡単に管理できます。 ナビゲーション データには、SharePoint 検索 REST API を介してリモートでアクセスできます。

注:

検索ベースのナビゲーションは検索インデックスに依存しています。 SharePoint はポータル コンテンツを継続的にクロールしますが、SharePoint リストへの変更が検索インデックスに表示されるまでには僅かな遅延が生じます。

最も単純で最良パフォーマンスのカスタム ナビゲーション ストアは、JSON 文字列で初期化されているコンポーネント固有の構成変数 (たとえば footerNav) を宣言する JavaScript のリソース ファイル (たとえば nav.js) です。 ブラウザーは自動的にファイルをダウンロードし、後で使用するためにキャッシュします。 構成データは、JavaScript ランタイム環境に読み込まれると、すぐに使用できます。 このアプローチの主要なトレードオフには、管理ユーザー インターフェイスが関係しています。少なくとも、管理者は JavaScript ファイル内の JSON 文字列を手動で編集する必要があります。 管理からストアを抽象化して、より親しみやすいものにするには、カスタム ユーザー インターフェイスが必要です。

カスタム ナビゲーション ストアの対極には、カスタム データベースがあります。 このオプションは、究極の柔軟性を提供しますが、カスタム開発が最も多く必要です。 さらに、データベース、カスタム Web API、ナビゲーション管理ページ用のホスティング環境が必要です。

注:

クライアント側データ アクセス層を使用したカスタム ナビゲーション ストアを実装する方法を示す優れたサンプルについては、SharePoint PnP リポジトリの「クライアント側データ アクセス層 (DAL) サンプル」を参照してください。

既成のナビゲーション ストア

  • 既成の管理ナビゲーション (MMS): 管理ナビゲーションでは、Managed Metadata Service (MMS) 用語セットを使用して、特定のサイト コレクションのナビゲーション ノードを構成できます。 既成のナビゲーションの表示コントロールはこのデータを自動的に使用します。 既成のナビゲーション管理ページには、制約なしの階層 (深さ無制限) 内のナビゲーション ノードを管理するための、使いやすいユーザー インターフェイスが用意されています。 カスタム ナビゲーション表示コントロールでもこのデータを使用できますが、現在、管理ナビゲーションに利用できる REST API がないため、JSOM 経由で行う必要があります。

    注:

    管理ナビゲーションを介してグローバル ナビゲーション定義を構成して維持することは、非常に煩雑です。 新しいサイト コレクションが作成されるたびに、サイト コレクションとそれに関連する用語セットの構成を複製する必要があります。 また、管理ナビゲーションはセキュリティによるトリミングがなされていないため、アクセスできないリンクがユーザーに表示される可能性があることにご注意ください。

  • 既成の構造ナビゲーション (サイト): 構造ナビゲーションでは、サイト コレクションのネイティブ構造 (その Web とページ) および作成された見出しとリンクを使用して、特定のサイト コレクションのナビゲーション ノードを構成することができます。 既成のナビゲーション管理ページには、制約付きの階層 (深さ制限あり) 内のナビゲーション ノードを管理するためのユーザー インターフェイスが用意されています。 カスタム ナビゲーション表示コントロールでもこのデータを使用できますが、現在、構造ナビゲーションに使用できる REST API がないため、JSOM 経由で行う必要があります。

    注:

    既成のナビゲーション表示コントロールは、データベース クエリ (クエリによるコンテンツ) を使用して、ナビゲーション データを取得します。 これは、ページの読み込みごとに行われ、複雑なサイト コレクション構造では非常にリソースを集中的に使用します。 サイト コレクション構造が単純な小規模のポータルにのみ、構造ナビゲーションを使用することをお勧めします。 構造ナビゲーションは、セキュリティによってトリミングされた結果を常に返します。

  • 既成の検索インデックス (検索): 検索型のナビゲーションでは、適切な検索クエリを構築することでサイトとページの SharePoint 検索インデックスのクエリを実行できます。 特定の既成のナビゲーション管理ページはなく、カスタムのナビゲーション表示コントロールを実装して、検索クエリから取得したデータを使用する必要があります。

    注:

    検索型のナビゲーションを使用する場合、取得した検索結果をキャッシュして、ページを読み込むたびにサーバーにアクセスしないようにすることは重要です。 検索型のナビゲーションと組み合わせて使用するモデルであるクライアント側のデータ アクセス層については、この記事で後述します。 構造ナビゲーションと同じように、検索型のナビゲーションはセキュリティによってトリミングされているため、ユーザーには到達不能なリンクは表示されません。 検索型のナビゲーションの欠点は、返されたナビゲーション項目の順序を制御することが困難であることです。

ナビゲーション管理ページには、ユーザー フレンドリな方法でナビゲーション コントロールの構成を管理するためのユーザー インターフェイスが用意されています。 このページには直接アクセスすることも、ナビゲーション コントロール上にあるオプションのリンク (設定リンクなど) からアクセスすることもできます。 このページでは、選択したナビゲーション ストア用の適切なナビゲーション ストア API を使用して、ナビゲーション コントロールの構成を管理します。

カスタム ナビゲーション管理ページまたは既成のナビゲーション管理ページのいずれかを、カスタム ナビゲーション コントロールで使用することを選択できます。

多くの場合は、選択したナビゲーション ストアに関連付けられている既定の既成ナビゲーション管理ページ (SharePoint リスト ビューまたは用語セット管理ページなど) で十分です。 既定のページが使用できない場合は、もちろんカスタム ページを開発する必要があります。 既存の既定のページを適用できるかどうかを決定する際には、必ずカスタム管理ページの開発 (デザイン、開発/保守、ホスティング、ユーザー トレーニング) の総コストを考慮してください。

大まかに言って、カスタム管理ページを推進するのは、既定のオプションが存在しない場合、ページで応答性の高い UI をサポートする必要がある場合、ポータルのフロントエンド ユーザー ビュー (バックエンド管理ビューではなく) を介してページが使用されるように設計されている場合のみです。

ナビゲーション ストア API には、一貫性のある安全な方法でナビゲーション コントロールの構成を管理するためのプログラマティック インターフェイスが用意されています。 カスタム ナビゲーション ストア API または既成のナビゲーション ストア API のいずれかを、カスタム ナビゲーション コントロールで使用することを選択できます。

カスタム ナビゲーション ストア API を開発、展開したい場合、以下のガイドラインに従ってください。

  • 好みのテクノロジ スタック (ASP.Net Web API 2.0、Node.js など) を使用して実行する。
  • インターネットにアクセスできる環境で API をホストする。
  • 名前の解決にパブリック DNS を使用する。
  • SSL が必要であり、公的証明機関から SSL 証明書を取得する。
  • 匿名アクセスを有効にして、Azure AD で API をセキュリティで保護する。
  • クロス オリジン リソース サポート (CORS) のサポートを実装する。

.Net クライアント環境の場合:

  • Client-Side Object Model (CSOM または REST) を介して SharePoint API を対象にする。
  • REST を介してカスタム Web API を対象にする。
  • REST を介してサード パーティの API を対象にする (必要な場合のみ SOAP を使用する)。

ブラウザー クライアント環境の場合:

  • SharePoint REST API を介して SharePoint API を対象にする (必要な場合のみ JSOM を使用する)。
    • 別のサイト コレクションを対象とする場合は、クロス ドメイン ライブラリを使用する。
  • REST を介してカスタム Web API を対象にする。
    • JavaScript および暗黙的 OAuth フロー用の Microsoft 認証ライブラリを使用します。
  • REST を介してサード パーティの API を対象にする (または必要に応じて SOAP を使用する)。

クライアント側データ アクセス層

クライアント側データ アクセス層は、カスタム ナビゲーション表示コントロールを含む、すべてのカスタムのクライアント側表示コントロールで利用可能になったカスタムのクライアント側 JavaScript フレームワークです。 インテリジェントなデータ読み込みパターンをサポートし、クライアントからサーバーに対する要求の詳細を抽象化し、クライアントからサーバーに対する要求のトラフィックを最小限に抑えるためのデータ キャッシュ機能を提供し、体感するページ パフォーマンスの向上を実現します。

クライアント側データ アクセス層の詳細については、「SharePoint Online ポータル パフォーマンス ガイダンス」を参照してください。

関連項目