Project Online のパフォーマンスの調整

数年前にProject Onlineを開始すると、あらゆる規模の組織が、Microsoft のOffice 365 クラウド インフラストラクチャの利便性の範囲内で、Microsoft の豊富な Project Portfolio Management (PPM) 機能を使用できるようになりました。

クラウドベースのサービスを使用する明らかな利点の 1 つは、デプロイ、セットアップ、ハードウェアとソフトウェアのチューニングを回避することですが、組織がProject Onlineから最適なパフォーマンスを得られるようにするために実行できる手順がいくつかあります。

Project Onlineには多くの構成とカスタマイズ設定が用意されていますが、カスタマイズはパフォーマンスに影響する可能性があります。 この記事では、最も一般的なProject Online設定のパフォーマンスへの影響とトレードオフを取り上げ、Project Onlineのカスタマイズと構成に関する情報に基づいた意思決定を行うことができます。

この記事は、Office 365 プロジェクトのネットワーク計画とパフォーマンスチューニングの一部です。

Office 365と SharePoint Online のベスト プラクティス

SharePoint Online とOffice 365のネットワーク計画とパフォーマンスチューニングに関する豊富な情報があります。 この情報はすべてProject Online顧客に関連しており、Project Onlineに固有の次のベスト プラクティスに加えて、参照する必要があります。

Project Onlineの構成とカスタマイズ

Project Web App サイトの多くの要素は、管理設定からアクセス許可、コラボレーション設定からルック アンド フィールまで、構成およびカスタマイズできます。 Project Web App サイトの全体的なパフォーマンスに影響を与える可能性がある設定を見てみましょう。

以下について説明します。

• セキュリティアクセス許可モード

• エンタープライズ プロジェクトの種類

  • プロジェクト サイトの構成

  • Project Onlineと SharePoint Online の間の同期メカニズム

• Active Directory リソース プールの同期

• UI のカスタマイズと外観

• プロジェクト詳細ページ (PDP) とワークフロー

• イベント処理

• OData とレポート

• Project Online クォータ

(この情報の一部は Project Server 2013 およびProject Server 2016にも適用されます)。

アクセス許可モード: SharePoint または Project

Project Onlineと Project Server 2013 では、従来の Project アクセス許可モードではなく、SharePoint アクセス許可モードと呼ばれる新しい簡略化されたアクセス許可モデルが導入されました。 両方のモードの比較は Technet で確認できます。

新しいProject Online インスタンスは既定で SharePoint アクセス許可モードでプロビジョニングされ、このモードは大多数のお客様のニーズに対応できると確信しています。 このモードを使用すると、通常の SharePoint グループとアクセス許可を使用してユーザーの承認を管理できます。

プロジェクトのアクセス許可モードは高度なカスタマイズ性を提供しますが、パフォーマンスの面では価格が高くなる可能性があります。 何百ものカテゴリを作成し、リソース内訳構造 (RBS) を介して動的なアクセス許可に大きく依存している場合、管理者やポートフォリオ マネージャーなど、多くのコンテンツにアクセスできるユーザーのエンド ユーザー エクスペリエンスが遅くなる可能性があります。

推薦：

可能な場合は、全体的なパフォーマンスを向上させるために、既定の SharePoint アクセス許可モードを維持します。 プロジェクトのアクセス許可モードを使用する必要がある場合は、可能な限りカスタマイズを制限します。

エンタープライズ プロジェクトの種類

エンタープライズ プロジェクトの種類 (EPT) は、フェーズ、ステージ、1 つのワークフロー、およびプロジェクト詳細ページ (PDP) をカプセル化するラッパーを表します。

EPT では、次の定義も可能です。

• プロジェクト サイトの構成

• Project Onlineと SharePoint Online の間の同期メカニズム

プロジェクト サイトの構成

プロジェクト サイトは、SharePoint のコア機能に基づいて構築されています。 プロジェクト サイトの作成は簡単なプロセスではなく、組織でプロジェクト サイトが必要な場合とタイミングを決定することは、エンド ユーザー エクスペリエンス全体の向上に大きな意味を持ちます。

多くの組織は、資金を提供するプロジェクトを決定する前に、Project Onlineを使用してプロジェクトの提案を収集し、評価します。 プロジェクトが初めて発行されるときにプロジェクト サイトが自動的に作成されるように設定されている場合、すべてのプロジェクト提案 (カットを行わないものも含む) は、プロジェクト サイトを取得します。 これらの不要なサイトは、後で手動でクリーンアップする必要があります。

プロジェクト サイトを使用する場合は、ユーザーがコラボレーション サイトを作成するタイミングを選択できるようにするか、さらに優れた方法で、プロジェクト提案が特定のステージ ゲートに達するとすぐにワークフローによって作成されるようにします。

現在 SharePoint Online では、サイト コレクションごとに作成できるサブサイトの数が 制限 されています。 EPT を使用すると、新しいプロジェクト サイトを作成するサイト コレクションを定義できます。 これにより、複数のサイト コレクションにまたがるように、プロジェクトごとにプロジェクト サイトを作成できます。

たとえば、IT 部門専用のサイト コレクションがある場合は、 IT プロジェクト EPT を構成して、 からプロジェクト https://contoso.sharepoint.com/sites/IT サイトを作成できます。

推薦：

組織でプロジェクト サイトを使用している場合は、自動的に作成するのではなく、オンデマンドで作成するオプションを選択します。 これにより、最初の発行エクスペリエンスが高速化され、不要なサイトやコンテンツの作成が回避されます。

EPT ごとに、次の方法でこのオプションを構成できます。

1. [Project Web App設定] で、[エンタープライズ プロジェクトの種類] をクリックします。

2. 設定を変更する必要がある EPT を選択します。

3. [EPT 設定] ページの [ プロジェクト サイト ] セクションで、[ ユーザーの選択を許可する] を選択します。

   

   EPT によって独自のサイト コレクションにプロジェクト サイトを作成します。 サイト コレクション内のプロジェクト サイトの数は、SharePoint Online SharePoint Online の制限の下に保持します。

何を同期しますか?

Project Onlineは、SharePoint Server の上で Project Server が実行されるのと同じ方法で、SharePoint Online の上で実行されます。 その結果、2 つのシステム間で一定数のコンポーネントを同期し続ける必要があります。 これらの同期には時間がかかる場合があり、ビジネス ニーズによっては不要な場合があります。 この記事では、これらのさまざまな同期システムをすべて調べて、必要なものと、安全にオフにできる同期システムを決定するのに役立ちます。 これらの設定の一部は、既定で既にオフになっています。

次のセクションでは、次について説明します。

• プロジェクト サイトのユーザーのアクセス許可を同期する

• エンタープライズ プロジェクトの SharePoint タスク リストを同期する

ユーザーのアクセス許可を同期する

プロジェクト サイトは、プロジェクト チームが共同作業を行い、ドキュメントをアップロードし、問題を発生させるワークスペースです。 同期ユーザーのアクセス許可が有効になっている場合、ユーザーにプロジェクトへのアクセス許可が付与されるたびに、対応する Project サイトのアクセス許可が更新されます。

この同期は、プロジェクトが発行されるたびに行われます。 同期の利便性のトレードオフはパフォーマンスです。たとえば、同期が必要なユーザーやサイトが多いほど、特に複数のプロジェクトを一括発行、インポート、または作成する場合 (プロジェクト サイトを使用)、プロジェクト サイトのアクセス許可の再同期が必要なグループ メンバーシップを更新する場合は、操作が遅くなります。

EPT ごとに、ユーザーの同期アクセス許可が有効になっているかどうかを定義できます。

推薦：

展開に次のことが当てはまる場合は、[Project site permission sync]\(プロジェクト サイトのアクセス許可の同期\) オプションを無効にすることを強くお勧めします。

• リソースの数が多い (>1000)

• プロジェクト サイトを必要とする多数のプロジェクトがある (>1000)

• 多数のプロジェクト サイトへのアクセスを許可する必要があるリソースが多数ある

• プロジェクト サイトは既定のサイト コレクションの外部に作成されます (同期は無効になっています)

Project サイトのアクセス許可を管理するために考慮すべきいくつかのオプションを次に示します。

• プロジェクト チームの離職率が低い場合は、Project Publish と Project Detail Pages のパフォーマンスを向上させるために、プロジェクト サイトのアクセス許可の同期をオフにすることを検討してください。 その後、誰かがプロジェクト チームに参加または退出するたびに、プロジェクト サイトに対するアクセス許可を手動で付与または削除する必要があります。

• PWA のすべてのユーザーにアクセス権を付与する必要があり、既存のグループのアクセス許可にマップされている場合は、親 PWA サイトから 継承 するように Project サイトを構成することを検討してください。

• サイト アクセスが特定のロールと一致する場合は、それらのロールにマップする 1 つ以上のグループを作成し (グループ同期を有効にしている場合は、同じグループを使用できます)、それらのグループに Project サイトへのアクセス権を付与します。

EPT ごとに、次の方法でユーザーのパフォーマンスの同期を有効にすることができます。

1. [Project Web App設定] で、[エンタープライズ プロジェクトの種類] をクリックします。

2. 設定を変更する必要がある EPT を選択します。

3. [EPT 設定] ページの [ 同期 ] セクションで、[ ユーザーアクセス許可の同期] を選択します。

   

エンタープライズ プロジェクトの SharePoint タスク リストを同期する

SharePoint タスク リストの同期 は、プロジェクトの発行速度を向上させるために既定でオフになっています。 これにより、プロジェクト詳細ページ間の切り替えを高速化することもできます。 ユーザーが Project サイトのタスク リストとそのタイムラインの視覚化に依存している場合は、この機能を有効にして、プロジェクトの発行のパフォーマンスへの影響が妥当かどうかを確認できます。

推奨事項

[SharePoint タスク リストの同期] オプションは、小規模なプロジェクト プランで使用することを目的としていました。 プロジェクトに多数のタスクがある場合、各タスクを一度に 1 つずつ更新する必要がある場合、発行時にそれらを同期するには時間がかかります。 たとえば、500 個のタスク プロジェクト プランを SharePoint タスク リストに同期するには数分かかります。 キュー ジョブは別の相関関係にあり、プロジェクト 計画の保存と編集をブロックしない場合でも、[SharePoint タスク リストの同期] オプションを有効にしないことをお勧めします。 250 個未満のタスクを含むプロジェクトのみを同期することをお勧めします。

このオプションは既定でオフになっています。 ユーザーが各 EPT の機能を必要としている場合にのみ、SharePoint タスク リストの同期をオンにします。 このオプションを構成するには:

1. [Project Web App設定] で、[エンタープライズ プロジェクトの種類] をクリックします。

2. 設定を変更する必要がある EPT を選択します。

3. [EPT 設定] ページの [ 同期 ] セクションで、[ SharePoint タスク リストの同期] を選択します。

   

Active Directory リソース プールの同期

Active Directory リソース プールの同期自体には特定のパフォーマンスの問題がないため、数千ものリソースを数分でProject Web App インスタンスにインポートできます。 ただし、システムの他の部分に対するダウンストリーム効果は、パフォーマンスに影響を与える可能性があります。 監視する主なプロセスは、前述のリソースアクセス許可の同期です。 Active Directory グループ メンバーシップに大きなターンオーバーがあり、リソース プールを頻繁に同期する必要がある場合は、関連するアクセス許可同期ジョブに対するダウンストリームの潜在的な影響を監視します。

推薦：

Active Directory 同期を、実際にシステムを使用する必要があるリソースのグループに制限し、大規模なグループの同期後に潜在的なアクセス許可の問題を監視します。 (Active Directory エンタープライズ リソース プール同期を構成するには、[Project Web App設定] で [Active Directory リソース プールの同期] をクリックします。

PWA ページとビューのカスタマイズ

ページのカスタマイズ

SharePoint プラットフォームは、モジュール式の Web パーツ インフラストラクチャとカスタム ページのサポートを備えた優れたカスタマイズ機能を提供します。 ロゴ、カスタム Web パーツ、および新しいテーマを追加する場合、サーバーの近接性、待機時間の短さ、および高帯域幅ネットワークの利点により、オンプレミス インフラストラクチャのパフォーマンスに大きな影響を与えない可能性があります。 ただし、オンライン サービスでは、ストーリーは異なります。

ファイル サイズが大きいロゴまたはグラフィックをアップロードすると、オンプレミスの展開でページが少し遅くなる可能性がありますが、オンラインでは、ページの読み込み時のパフォーマンスヒットが大幅に発生します。

ページに複数の Web パーツを追加する場合も、同じ原則が適用されます。 複数の Web パーツを含むカスタム ページを作成したくなるかもしれませんが、ユーザーが実際にデータを並べて表示する必要がない限り、すべてを 1 か所に配置するよりも、個別の特殊なページを作成することをお勧めします。 ユーザーがページ上の 1 つの Web パーツのコンテンツのみを必要とする場合でも、ページが他のすべての Web パーツのデータを読み込んで表示するまで、さらに長く待つ必要があります。

推薦：

ページをカスタマイズするときは、Project Online サイトを通常のインターネット Web サイトとして扱い、できるだけ軽量のページを作成します。

ビューのカスタマイズ

ここでも、シンプルさはページ読み込みパフォーマンスを向上させる長い道のりになります。 組織は、Project Center、Resource Center、タスク、タイムシートなど、複数のProject Web App ページを使用してカスタム ビューを作成できます。

表示されるコンテンツが多いほど、ページのレンダリングが遅くなります。 複数の "オールインワン" ビューではなく、より多くの単純ビューとターゲット ビューをユーザーに提供する場合、各ページの読み込み時間を数秒短縮できます。

次の例では、2 番目のビューの読み込み時間が 1 番目のビューよりも平均 2 秒から 3 秒少なくなります。

推薦：

ビューを構成する場合、不要なデータをほとんどの場合読み込む複雑なオールインワン ビューではなく、より高速なナビゲーションのためのシンプルな特殊なビューをユーザーに提供します。

ユーザー ビューの設定

プロジェクト センター: ロールアップを使用したグループ化

ユーザーは、さまざまなフィールドでデータをグループ化するなど、ビューをレンダリングするさまざまな方法を構成できます。 グループ化を使用する場合は、サポートされている集計フィールド (コストの合計やユーザー設定フィールドなど) のデータをロールアップできます。 これらの集計値を計算すると、合計を表示するためにすべての値を読み込むようサービスに要求されます。

推薦：

ユーザーがロールアップされた値を表示する必要がない限り、リボンの [ロールアップ ] オプションを無効にします。

プロジェクト センター: ガント チャート

ガント チャート ビューのグラフ部分には、各プロジェクトがサマリー ガント バーとして表示されます。

推薦：

ユーザーがガントを表示する必要がない限り、リボンの [ガント チャート] オプションを無効にします。

カスタム プロジェクトの詳細ページとワークフロー

上記のページデザインに関する推奨事項に加えて、Project Detail Pages (PDP) は、プロジェクト全体の再計算をトリガーし、ワークフロー アクションを開始できる点に特に適しています。どちらも、カスタマイズに応じてパフォーマンスの面でコストのかかる操作になる可能性があります。

Project Onlineと Project Server には、プロジェクト情報の主な更新プロセスが 2 つあります。

• スケジュール再計算が必要な更新 (下記の一覧を参照)

• プロジェクト名、説明、所有者など、スケジュールに関連しないフィールド。

両方の更新プロセスを同時にトリガーしないように、両方の種類のデータを同じ PDP で更新しないことをお勧めします。

スケジュールの再計算を必要とする最も一般的なアクションの一覧を次に示します。

• プロジェクトカレンダーの変更

• 次の日付フィールドに対する変更:

  • 開始日

  • 終了日

  • 状態の日付

  • 現在の日付

• プロジェクトのユーザー設定フィールドの変更

• プロジェクトに成果物への依存関係がある場合

PDP のパフォーマンスを向上させる 2 つ目の方法は、各 PDP に表示される Web パーツとユーザー設定フィールドの数を減らすことです。 ビジネス プロセスで同じフィールド セットの更新が頻繁に必要な場合は、これらのフィールドのみを含む専用 PDP を作成して、負荷を向上させ、時間を節約します。 すべてのユーザー設定フィールドを常に表示すると、多くの不要なオーバーヘッドが発生します。

推薦：

軽量の特殊化された PDP を作成し、スケジュールに関連する更新プログラムとスケジュール以外の更新プログラムを混在させないようにします。

新しい REST API を使用したワークフローでのカスタム フィールドの一括更新

ワークフロー内のプロジェクト ユーザー設定フィールドの値を一度に 1 つずつ更新するには、[プロジェクト フィールドの設定] アクションを使用して個別のサーバー要求が必要です。 これにより、待機時間の長い低帯域幅ネットワークで多数のカスタム フィールドを同時に更新すると、パフォーマンスが低下します。

この問題を解決するために、 カスタム フィールドを一括で更新する CSOM メソッドがあります。 このメソッドでは、更新するすべてのユーザー設定フィールドの名前と値を含むディクショナリを渡す必要があります。

オンデマンドでプロジェクト サイトをプロビジョニングするための API

各プロジェクトには、チーム メンバーが共同作業を行い、ドキュメントを共有し、問題を発生させる専用の SharePoint サイトを用意できます。 これらのサイトは、最初の発行時に自動的に作成したり、Project Pro を使用してプロジェクト マネージャーによって手動で作成したり、Project Web App設定を使用して管理者が手動で作成したり、単に無効にしたりできます。

CreateProjectSite('') メソッドを使用して、プロジェクト サイトを作成するタイミングを決定できます。 これは、プロジェクト提案が最初の発行時ではなく、定義済みのワークフローの特定のステージに到達した後にのみサイトを作成する組織に特に役立ちます。 これにより、プロジェクト サイトの作成を延期することで、プロジェクト作成のパフォーマンスが大幅に向上します。

イベント処理

アドインは、Project Onlineで発生するイベントに応答できます。 たとえば、アドインは、プロジェクトの作成後に追加のアクティビティを実行できます。 ユーザーは、これらのアドインがイベントの処理を完了するまで待ってから、Project Onlineの操作を続行する必要があります。

推薦：

Project Onlineは、ユーザーが待機する必要がある時間を最小限に抑えるために、特定のイベントを非同期的に処理するように構成する必要があります。 これを行うには、使用するすべてのアドインの開発者に依頼して、コードが After イベントを非同期的に処理できることを確認します。 これらのイベントを処理するために従うことができるプラクティスの詳細については、 この記事 を参照してください。

開発者がアドインが変更の準備ができていると確認した場合は、[PWA 設定] ページで [非同期のイベント処理後に有効にする] 設定を有効にする必要があります。

1. [ PWA 設定] ページの [運用ポリシー] セクションで、[ 追加のサーバー設定] を選択します。

2. [ イベント後の非同期イベント処理 ] セクション で、[イベント処理後に非同期を有効にする ] が選択されていることを確認します。

   

3. [保存] を選択します。

   その後、インスタンスをテストして、すべてが正常に動作することを確認する必要があります。

   注:

   この設定は、サイト コレクション管理者のみが表示および変更できます。

OData とレポート

ProjectData OData Service

Project Onlineには OData レポート サービスがあり、サービスに格納されているデータに対してレポート/視覚化を構築する方法を提供します。 ProjectData OData レポート サービス API は 、ここで定義されています。

ProjectData OData レポート サービスへの呼び出しは、SharePoint Online によって管理されます。 SharePoint Online で調整またはブロックされないようにするに関する記事を参照して、呼び出しが調整される可能性が低くなることを確認し、再試行と指数関数的バックオフの推奨事項を正しく実装してください。

さらに、このドキュメントで説明されている推奨事項に従うと、データの取得に必要な呼び出しの数、長さ、頻度が減ります。 スロットルが頻繁に発生する場合は、複数の部門が同じデータに対してクエリを実行しているか、この記事で説明されているベスト プラクティスに従わず、すべてのユーザーに影響を与える可能性があることを組織全体で確認します。

タイムスケール レポート

Project Onlineでは、タイムスケールのレポート データに必要な粒度レベルを選択できます。 レベルのオプションと影響については、「Project Onlineでのタイムスケール レポート データのロールアップの構成」を参照してください。 シナリオに最も少なくデータ量を生成するレベルを選択すると、データを OData Reporting サービス エンドポイントにすばやく表示でき、ダウンロードにかかる時間が短縮されます。

パフォーマンス順のオプションの一覧 (生成されたデータの量と最もパフォーマンスが低いものから順に関連付けられる)。

• 絶対しません

• 会計期間

• 毎月

• Weekly (週単位)

• 毎日

会計期間 は、レポート データが定義された会計期間にのみ保持されるのに対し、月次はすべてのプロジェクトで完全な期間のデータを保持するという点で、 月次 よりも大きな利点があります。

Project OData サービスを使用すると、レポート用にProject Online インスタンスから情報を抽出できます。

推薦：

ビジネス ニーズと一致する最も時間配分の少ないデータを格納します。 発行が完了するまで待機するワークフローがある場合は、Daily を使用しないでください。 ワークフローが待機する原因となる必要なデータの生成には、毎日の時間がかかる場合があります。

サービスのクエリ

ProjectData OData サービスの 1 つのクエリで返すことができるエンティティの数には 制限 があります。 その結果、大量のデータに対してクエリを実行するには、複数の Web 要求をサービスに送信する必要があり、要求ごとにネットワーク オーバーヘッドと待機時間が増加します。

推薦：

"すべて更新" データの読み込みを完全に実行しないでください。 これらの更新は、特にピーク時の使用時間中に PWA サイトのパフォーマンスに影響を与え、PWA または調整でのユーザー操作の全体的なパフォーマンス低下につながる可能性があります。

Odata 更新アクションを数時間後に実行します。 リアルタイムまたは実際のレポートに近い状態を維持するための決定は、PWA サイトのユーザー エクスペリエンスに対するパフォーマンスのトレードオフも考慮する必要があります。 "すべてを更新する" 要件が存在する場合は、「SQL Server Integration Services (SSIS) – 大きなデータセットに推奨される」セクションを確認してください。

プロジェクト、割り当て、タスクなど、多数のエンティティを含むProject Web App インスタンスの場合は、少なくとも次のいずれかの方法で返されるデータを制限する必要があります。 返されるデータを制限しないと、クエリは既定の制限を超え、サーバーのパフォーマンスに影響を及ぼすことがあります。

• データを制限するには、常に $filter URL オプションと$selectを使用します。 たとえば、次のクエリでは、プロジェクトの開始日によってフィルター処理され、プロジェクト名の順に 4 つのフィールドのみが返されます。

  http://ServerName/ProjectServerName/_api/ProjectData/Projects?$filter=ProjectStartDate gt datetime'2012-01-01T00:00:00'&$orderby=ProjectName&$select=ProjectName,ProjectStartDate,ProjectFinishDate,ProjectCost
  

• 複数値参照であるユーザー設定フィールドは使用しないでください。 複数値参照であるユーザー設定フィールド値を処理するには、追加の計算が必要です。 これらのフィールドでは、より一般的な顧客シナリオに対して実装されているいくつかの最適化を利用することはできません。 複数値のユーザー設定フィールドが既に構成されている場合は、フィルター処理された Odata クエリでこれらのフィールドが指定されていないことを確認することで、検索速度と信頼性を向上させます。

• キーまたは関連付けによるエンティティのクエリ。 エンティティのクエリを実行する場合は、 のメタデータ ドキュメント https://yourdomain.sharepoint.com/sites/PWA/_api/ProjectData/$metadataを参照してください。 可能な限り、次のいずれかの方法でエンティティを照会します。

• Keys

  注:

  複数のキーがある場合、最初のキーを使用すると、2 番目のキーのみを使用するよりもパフォーマンスが向上します。

• 関連付け

  たとえば、AssignmentId と ProjectId を使用して 割り当て エンティティに対してクエリを実行できます。

  https://ServerName/ProjectServerName/_api/ProjectData/Assignments?$filter=AssignmentId eq guid'719d849a-79b4-e911-b073-00155d9c3d12' and ProjectId eq guid'b5b02399-79b4-e911-b073-00155d9c3d12'
  
  or
  
  https://ServerName/ProjectServerName/_api/ProjectData/Assignments(AssignmentId=guid'719d849a-79b4-e911-b073-00155d9c3d12',ProjectId=guid'b5b02399-79b4-e911-b073-00155d9c3d12') 
  

  AssignmentId を使用する:

  https://ServerName/ProjectServerName/_api/ProjectData/Assignments?$filter=AssignmentId eq guid'719d849a-79b4-e911-b073-00155d9c3d12'
  

  ProjectId 経由:

  https://ServerName/ProjectServerName/_api/ProjectData/Assignments?$filter= ProjectId eq guid'b5b02399-79b4-e911-b073-00155d9c3d12'
  

  Project を使用した関連付け:

  https://ServerName/ProjectServerName/_api/ProjectData/Projects(guid'263fc8d7-427c-e111-92fc-00155d3ba208')/Assignments
  

• $top 演算子および $skip 演算子を繰り返し使用してクエリを複数回実行し、1 回に 1 ページのデータを返すようにします。 たとえば、次のクエリは、 問題 に割り当てられているリソースの順序で、すべてのプロジェクトの問題 11 から 20 を取得します。

  https://ServerName/ProjectServerName/_api/ProjectData/Issues?$skip=10&$top=10&$orderby=AssignedToResource
  

• 割り当てエンティティのクエリを実行するときに、Project/Task/Resource 名を取得しないようにします。 サービスは、それぞれの名前を取得するために追加の処理を実行します。 他のクエリからデータが既に取得されている場合は、割り当てのクエリを実行するときに$select フィルターに含めないでください。

推薦：

• サーバー側のフィルター処理を使用して実行時にクエリを実行するデータの量を制限し、必要な列のみを取得します。 この影響は、ユーザー設定フィールドで最も顕著です。 必要な場合にのみ、カスタム フィールドにを追加します。

• エンティティ キーでフィルター処理していることを確認します。 エンティティ キーにはインデックスが作成され、よりパフォーマンスの高いデータ取得エクスペリエンスが提供されます。 PWA インスタンスのサービス メタデータ ドキュメントを確認することで、各エンティティのキーを見つけることができます: https://Contoso.sharepoint.com/sites/PWA/_api/ProjectData/$metadata

データの取得とレポートの作成

PowerBI

データの量が少ない場合、Power BI は Project OData サービスからデータを定期的に読み取り、さまざまなダイナミクス レポートを提供するのに役立ちます。 サンプル コンテンツ パックについては、 こちらを参照してください。

Project Onlineのデータ量が大きい場合でも、ここで説明する PowerBI データ サイズの制限を満たしている限り、データのサブセットを取り込むことができます。 もう 1 つのオプションは、移動ウィンドウでレポートを作成することです。つまり、過去 30 日間にアクティブだったプロジェクトをフィルター処理したり、今後 6 か月間リソース容量を表示したりします。 PowerBI がサービス側のフィルター処理の最適化を利用できない可能性があるため、ベスト プラクティスについては、「$filter/$select」セクションを参照してください。

Excel OData

Excel を使用してデータをダウンロードし、カスタムの視覚化/レポートを構築できます。 Project Online内のデータの量が多い場合、データのサブセットは移動ウィンドウを使用できます。つまり、過去 30 日間アクティブだったプロジェクトをフィルター処理したり、今後 6 か月間リソース容量を表示したりできます。 Excel ではサービス側のフィルター処理の最適化を利用できない可能性があるため、ベスト プラクティスについては、「$filter/$select」セクションを参照してください。

SQL Server Integration Services (SSIS)

SSIS を使用すると、Project Onlineレポート データを Project OData サービスからローカル SQL Server データベースまたは Microsoft Azure にダウンロードできます。 ダウンロードすると、すべてのレポート/視覚化を作成できます。 ローカル データを Project Online と同期させるために、さらにプロセスが必要です。

SSIS を使用する場合は、Project Online最適化された次のパターンを使用します。 このパターンにより、ローカル データの取得と同期の維持にかかる時間が短縮されます。さらに、ビジネス要件を実行するために必要なフィールドのみをダウンロードします。 クエリ対象のフィールドが少ないほど、データを迅速に取得できます。

完全同期

関心のあるレポート データの現在のスナップショットを取得します。 次のメソッドを使用して、 Project および関連エンティティを効率的に取得します。

たとえば、 Project エンティティを使用します。

1. 追加のフィルターを含む Project エンティティから ProjectId を照会します。 たとえば、特定の開始日または終了日があるプロジェクトをフィルター処理します。

2. 以前に取得した 1 つの ProjectId でフィルター処理して、ダウンロードする必要があるフィールドを指定して Project エンティティにクエリを実行します。 以下の差分同期パターンで使用される ProjectModifiedDate を含めます。

3. ProjectId ごとに手順 2 を繰り返します。 さらに、ProjectId ごとに、関連エンティティのデータをダウンロードします。

たとえば、 Task エンティティを使用する場合:

1. 前の手順の追加フィールドとプロジェクト ProjectId に対して、Task エンティティから TaskId を照会します。

2. 以前に取得した 1 つの TaskId に対して、ダウンロードする必要があるフィールドとフィルター処理を指定して、Task エンティティにクエリを実行します。 以下の差分同期パターンで使用される TaskModifiedDate を含めます。

3. TaskId ごとに繰り返します。

   同様に、関連エンティティごとに同じ方法を使用します (割り当て、TaskTimephasedData など)。

上記の手順は、タイムシート情報を取得する場合など、エンティティの他のグループに適用されます。

• タイムシート: フィルター条件に基づいて TimesheetId と ModifiedDate を取得し、タイムシート レコード、 TimeSheetId でフィルター処理する TimeSheetLines を取得し、他の関連エンティティに進み、主キー ID (TimesheetUID) と変更日フィールドでファイリングしていることを確認します。

リソース エンティティ情報を取得する場合:

• ResourceId と ResourceModifiedDate 、Resource レコード 、 ResourceTimephasedData などを取得します。それぞれの主キー ID と変更日フィールドを含めます。

Delta Sync

レポート データのローカル コピーを最新の状態に保つように定期的に確認します。 ライセンスの各グループ (タイムシート、リソースなど) について、必要に応じて以下の手順を繰り返します。

1. $filter条件を使用して、Project エンドポイントからすべての ProjectId と変更日を照会します。

2. ProjectId が存在しなくなったローカル プロジェクトと関連レコード (タスク、割り当てなど) を削除します。

3. プロジェクト レコードに対してサービスの変更日とローカル変更日が異なる場合は、一度に 1 つの ProjectId でフィルター処理するすべての必須フィールドについて Project エンドポイントに対してクエリを実行します。 さらに、ProjectId ごとに、関連エンティティのデータをダウンロードします。

たとえば、 Task エンティティを使用する場合:

1. 追加のフィールドと、データが変更された前の手順の project ProjectId (Project サービスの変更日がローカルの変更日と一致しなかった) に対して、TaskId と TaskModifiedDate をタスク エンティティからフィルター処理してクエリを実行します。

2. 存在しなくなった TaskId のローカル レコードと関連レコードを削除します。

3. サービスの変更日とローカル変更日が異なる場合は、TaskId とエンティティ主キーを渡す各エンティティ エンドポイントに対してクエリを実行し、ローカル バージョンを更新します。

割り当て、TaskTimephasedData など、関連するエンティティごとに繰り返します。

Project Web App クォータ

既定では、Project Web App サイトには 25 GB の制限があり、Project Web Appが有効になっている SharePoint サイト コレクションに格納されているすべてのデータの制限とは別です。 レポートの粒度オプションを使用してデータ 量を減らすと、クォータ内を維持するのに役立ちます。

まとめ

Project Online、インターネット上で実行されているクラウド サービスと同様に、オンプレミスのデプロイと比較して最適なパフォーマンスを実現するために、特定のチューニングが必要です。

パフォーマンスを向上させるためにシステムは常に改善されていますが、エンド ユーザーに優れたエクスペリエンスを提供するために、その間に実行できるいくつかの手順があります。

概要に関する推奨事項:

• 可能な場合は SharePoint アクセス許可モードを使用します。

• 実際に使用する機能のみをオンにします。

• ページの読み込み時間を短縮するために、ページとカスタマイズを可能な限りシンプルかつ軽量に保ちます。

• レポートの柔軟性を高めるために、サーバー側のフィルター処理を使用するか、Odata フィード データを SQL Server データベースにエクスポートします。

• レポートのニーズを満たす最小限のデータ量を使用するレポート粒度オプションを選択します。

関連項目

Project Online: ソフトウェアの境界と制限