次の方法で共有


カスタマイズのベスト プラクティス

Dynamics 365 Field Service のパフォーマンス、ユーザビリティ、サポート性の問題を回避するために、以下のベストプラクティスに従ってください。

フォームのカスタム フィールドを最小化する

システム カスタマイザーは、業種や業務に特化した情報を取得し、ビジネス プロセスを実行し、報告するための情報を収集するために、エンティ ティフォームにカスタムフィールドを追加します。 ただし、フォームのカスタム フィールドが多すぎると、パフォーマンスの問題が発生する可能性があります。

パフォーマンスの問題を回避する方法:

  • すべてのフォームで、カスタム フィールドの数を最小限に抑えます。 作業指示書が Field Service アプリで最も使用されるフォームであれば、そのフォームから始めることをお勧めします。
  • カスタム フィールドのうち、ルックアップ型フィールドとサブグリッドの数を最小限にします。
  • カスタム フィールド (特にルックアップとサブグリッド) を最初のフォームタブから他のフォームタブに移動します。
  • フォームの使用頻度の低いフィールドを既定で非表示にします。

標準機能の Web リソース、オプション セット、セキュリティ ロール、またはワークフローは変更しないでください

標準機能の Web リソース、オプション セット、セキュリティ ロール、ワークフローを変更またはカスタマイズしないでください。 そうでない場合は、意図しないシステム動作を引き起こす可能性があります。

これらのコンポーネントをカスタマイズした組織は、環境ですぐに問題が発生しない可能性があります。 しかし、マイクロソフトが既成コンポーネントをカスタマイズしてリリースする変更は、それらのコンポーネントの最上位レイヤーには適用されません。 その代わりに、特定のカスタマイズされたレイヤーは、将来のすべての変更を上書きし、それらの上書きは最終的に予測不可能なエラーや動作を引き起こします。

日付フィールドやシステム状態を変更、編集、削除しないでください

データ フィールドと状態を変更、編集、削除すると、ビジネス ロジックに影響を与え、ソリューションの更新で問題が発生する場合があります。 作業指示書の日付フィールドの例には、確約した開始時間確約した終了時間 があります。 ステータス フィールドの例には、作業指示書のシステム ステータスや契約のシステム ステータスなどがあります。

既成フィールドを編集したり、フォームから削除したりしないでください

顧客は、ビジネス ニーズに合わせて既成のフィールドを編集します。 しかし、既成フィールドの編集は、特にプロセスがそのフィールドの値に依存している場合、エラーを引き起こす可能性があります。

エラーを回避するには:

  • フォーム上の不要なフィールドを非表示にします。
  • 不要なフィールドを別のフォームタブに移動します。

たとえば、Field Service プロセスは、予約可能リソース予約レコードの到着予定時刻フィールドの値を計算し、現場作業員がいつ現場に到着するかを示します。 このフィールドが不要な場合は、フォームから削除する代わりにフォームから非表示にしてください。

オプション セット (選択) 値は編集しないでください

既成のフィールドのオプション セット値を編集すると、特に、そのフィールドの値に依存するプロセスやアップグレード中にエラーが発生することがあります。

エラーを回避するには:

  • 既成フィールドのオプション セット ラベルのみを編集します。 これらのフィールドのオプション設定の絶対に編集しないでください。
  • オプション セットの選択肢は削除しないでください。
  • オプションセットの選択肢を追加しないでください。

たとえば、Field Service 作業指示書には、既定で システム ステータス フィールドが含まれています。 このフィールドは (選択肢タイプの) オプションセットで、スケジュールなしスケジュール済み進行中完了キャンセル などのオプションがあります。 各オプションにはラベルと関連する数値があります。 システム管理者は、オプションセットのラベル (スケジュールなしなど) を編集することはできますが、ラベルに関連付けられた数値を編集することはできません。

カスタム スクリプトの使用を減らし、ベスト プラクティスに従う

システム カスタマイザーは、通常は JavaScript のウェブリソースであるスクリプトを記述して、ビジネス ロジックを実行します。 しかし、カスタム スクリプトは、アップグレード時にパフォーマンスの問題やエラー、複雑な問題を引き起こす可能性があります。

これらの問題を回避する方法:

  • 読み込み時に実行されるスクリプトの数を最小限に抑えます。
  • 大量のデータを呼び出すスクリプトや、同じデータを呼び出す複数のスクリプトの記述を避けます。

以下のサブセクションでは、ベスト プラクティスについて説明します。 また、Dynamics 365 Customer Engagement を使った開発のベストプラクティス に記載のフォームスクリプトのベストプラクティスに従ってください。

OnLoad イベントで要求されるネットワーク要求の数とデータの量を最小限に抑えます

フォームの読み込み中に、より多くのネットワーク リクエストが行われ、それらのリクエストからより多くのデータがダウンロードされればされるほど、フォームの読み込みにかかる時間は長くなります。 必要最小限のデータのみを要求します。 さらに、将来のフォーム読み込み時に不必要にデータを要求しないように、可能な限りデータをキャッシュすることを検討してください。

同期ネットワーク要求の使用は避けてください

同期ネットワーク要求により、ページの読み込みが遅くなり、フォームが応答しなくなる可能性があります。 代わりに非同期要求を使用する。 次のブログ記事で、さらに多くの例を紹介しています: 同期リクエストからの移行によるモデル駆動型アプリの高速化。 また、同じエンティティやレコードに対して複数のネットワーク呼び出しが必要な場合は、「非同期と待機」の使用を検討してください。 非同期と待機の詳細をご覧ください。

不要な JavaScript Web リソース ライブラリの組み込みの回避

フォームにより多くのスクリプトを追加すると、それらをダウンロードする時間が余計にかかります。 通常、スクリプトは、最初に読み込まれた後にブラウザーにキャッシュされます。 しかし、初めてフォームを表示したときのパフォーマンスは、多くの場合、大きな印象を与えます。

Onload イベントでのすべてのスクリプトの読み込みの回避

列の OnChange イベントのみ、または OnSave イベントのみをサポートするコードがある場合は、OnLoad イベントではなく、それらのイベントのイベント ハンドラをスクリプト ライブラリに設定してください。 こうすることで、これらのライブラリの読み込みを延期することができ、フォームが読み込みされるときのパフォーマンスが向上します。

Web リソースの読み込みを延期するには、折りたたまれたタブを使用します

折りたたみ可能なタブのセクションに含まれる Web リソースまたは iFrame コンポーネントは、タブが折りたたまれると読み込まれません。 タブが展開されたときにのみ読み込まれます。 タブの状態が変化すると、TabStateChange イベントが発生します。 折りたたまれたタブで Webウェブリソースや iFrame をサポートするために必要なコードは、TabStateChange イベントのイベントハンドラを使用することができ、OnLoad イベントで発生する可能性のあるコードを減らすことができます。

クライアント側のコードで重複するネットワーク要求を回避する

複数のネットワーク リクエストや重複したネットワーク リクエストがある場合は、Web ブラウザが停止し、フォームの読み込み時間に影響する可能性があります。 リクエストの数を減らすことで、パフォーマンスを向上させることができます。 別の方法としては、ネットワーク リクエストを統合し、これらのリクエストの値をキャッシュする方法があります。 さらに、前述したように、非同期ネットワーク要求についても検討してください。

関連する情報が XRM API で得られる場合は、ロールやシステム ユーザー固有の呼び出しの使用を避けてください

XRM API を使用して、ユーザーの権限情報の取得で発生するネットワーク リクエストを回避します。 同期リクエストからの移行方法については、こちらをご覧ください。 さらに、XRM API からの情報が要件を満たしている場合は、システム ユーザーの呼び出しを避けてください。

既定の表示オプションの設定

OnLoad のイベントの場合、フォーム要素を隠すようなフォーム スクリプトの使用は避けてください。 その代わりに、非表示になる可能性のあるフォーム要素については、フォームが読み込まれたときに既定で非表示になるように、既定の表示オプションを設定します。 次に、OnLoad イベントでスクリプトを使用して、表示したいフォーム要素を表示します。

詳しくは以下の資料をご覧ください:

スクリプトのソリューション チェッカーを実行する

Power Apps ソリューション チェッカーは、問題のある Power Apps ソリューションをチェックし、ベストプラクティスを推奨するマイクロソフトの便利なツールです。 これらの問題には、JavaScript、HTML、プラグイン、カスタム ワークフロー アクティビティに関する問題が含まれます。

詳しくは以下の資料をご覧ください:

同期型ではなく非同期型のワークフローを採用する

システム カスタマイザーは、Field Serviceでデータが変更されたときに実行されるビジネス ロジックをリアルタイムで実行する同期ワークフローを記述することが一般的です。 ただし、ワークフローを同期して実行すると、パフォーマンスが低下します。 代わりにワークフローを非同期で実行し、パフォーマンスの問題を回避します。

Field Service とリソース スケジュールの既成のプロセスをアクティブ化する

Field Service とリソース スケジュールには、必要なビジネス ロジックを実行する多くのプロセスが含まれています。 非アクティブ化されたプロセスはエラーの原因となります。 問題を回避するには、すべての Field Service とリソース スケジュールのプロセスがアクティブな状態になっていることを確認してください。 プロセスが非活性化状態にあるかどうかを確認するには、Field Service Solution Health Hub を定期的に実行します。

ソリューション正常性ハブを実行して問題を検出する

ソリューション正常性ハブは、環境の状態を把握し、Dynamics 365 環境の問題を検出する際に役立ちます。 環境の構成は、自然なシステム操作によって時間の経過とともに変化する可能性があります。 ソリューション正常性ハブはインスタンス内でルールを実行し、環境の構成を検証します。 ルールの中には Field Service に特化したものもあり、問題が発生したときにオンデマンドで実行できます。 一部のルールは、Field Service がインストールまたは更新されると自動的にトリガーされます。

環境の健全性を監視するには、ソリューション正常性ハブのルール セットを定期的に実行します。

モバイル アプリのパフォーマンスに関する考慮事項

モバイルア プリのカスタマイズはパフォーマンスに影響を与える可能性があります。 詳細については、モバイル アプリをカスタマイズする際のパフォーマンスに関する考慮事項 を参照してください。