Dynamics 365 Customer Engagement での開発におけるベストプラクティス

[アーティクル]
03/22/2023

このトピックでは、Dynamics 365 for Customer Engagement のカスタマイズにおけるベストプラクティスについて説明します。

重要

Dynamics 365 Customer Engagement (on-premises) でサポートされる拡張機能を見て、サポートされているカスタマイズの方法およびサポートされていない方法について確認してください。

パフォーマンスのベストプラクティス

次のベストプラクティスは、パフォーマンスの優れたコードを作成するのに役立ちます。

複数のスレッドの使用

アプリケーションにスレッドサポートを追加して、複数の CPU に作業を分割します。この提案は、コードがマルチプロセッサで実行されていることを前提としています。詳細: 「.NET Framework の拡張開発」の「マネージスレッド処理」。

システムによる GUID の作成の使用

GUID (ID) を手動で作成する代わりに、システムで自動的に割り当てるようにします。これにより、Dynamics 365 Customer Engagement (on-premises) で連続した GUID を利用できるようになり、SQL のパフォーマンスが向上します。次のコードサンプルは、Create メソッドを呼び出して、システムで割り当てられる GUID を取得する方法を示しています。

// Instantiate an account object.
Account account = new Account { Name = "Fourth Coffee" };  
// Create an account record named Fourth Coffee and retrieve the GUID.
accountId = serviceProxy.Create(account);

事前バインド型の使用

コードの作成時点で不明なエンティティと属性をコードで扱う必要がある場合は、Entity クラスを使用します。また、カスタムコードで数千件のエンティティレコードを処理する場合も、事前バインドエンティティ型ではなく Entity クラスを使用した方がパフォーマンスが少し高くなります。ただし、この柔軟性には、エンティティ名と属性名をコンパイル時に検証できないという欠点もあります。コードの作成時にエンティティが既に定義されていて、多少であればパフォーマンスの低下を許容できる場合は、CrmSvcUtil ツールで生成できる事前バインド型を使用してください。詳細: コードでの事前バインド型エンティティクラスの使用

プラグインの無効化

可能な場合は、アプリケーションを実行する前に登録されているプラグインを無効にします。

高速なプラグインの作成

常に目的のタスクを最小限の時間で実行できるプラグインを作成するようにしてください。たとえば、Execute メソッドは Dynamics 365 Customer Engagement (on-premises) で頻繁に処理されます。そのメッセージに関してプラグインを登録した場合、プラグインによってシステムのパフォーマンスが大きな影響を受ける可能性があります。なぜなら、Execute メソッドが処理されるたびに、そのプラグインが実行されるからです。これは頻繁に起こることです。

同期して実行するためのプラグインを登録する場合は、2 秒未満で操作が完了するように設計することをお勧めします。プラグインを実行する組織サービスと同じ組織サービスに接続されたクライアントアプリケーションの対話機能を維持するには、プラグインの処理時間を最小限に抑えることが最も重要です。

取得するデータの制限

サーバーからデータを取得するメソッドを使用する場合は、アプリケーションに最低限必要なデータを取得します。これは、取得するエンティティ属性セットである列セットを指定して行います。

たとえば、RetrieveAllEntitiesRequest クラスを使用し、EntityFilters プロパティに All` エンティティフィルターを指定して、RetrieveAllEntities メッセージですべてのメタデータを取得することは、ごくまれなケースを除いてはお勧めできません。代わりに、エンティティフィルターを制限するか、または次のいずれかの要求クラスを使用した方が、より良いパフォーマンスを得られます: RetrieveEntityRequest、RetrieveOptionSetRequest、RetrieveAttributeRequest、RetrieveRelationshipRequestまたは RetrieveMetadataChangesRequest 。 RetrieveMetadataChanges メッセージでは、必要なメタデータまたは変更されたメタデータだけを返すクエリを作成できます。詳細: メタデータへの変更の取得および検出。

オフライン用に有効になっているエンティティの数を制限します

オフライン作業中にエンティティをユーザーが使用できるようにする必要があるかどうかを慎重に検討してください。オフライン機能に対して有効にする各エンティティは、オンラインに戻ったときにユーザーがデータを同期するために必要な時間に直接影響します。これは、パワフルでないコンピューターを使用するユーザーの場合にはとりわけ真実です。

Update メソッドまたは UpdateRequest メッセージを使用するときは、所有者が実際に変わった場合を除いて、レコードに OwnerId 属性を設定しないでください。この属性を設定すると、多くの場合、関連するエンティティに変更内容が伝播されることで、更新操作に要する時間が増大します。詳細: カスケード動作

クライアントでのプロキシ設定の調整 (設置型のみ)

Web ブラウザーなどのクライアントアプリケーションと実際の対象サーバーの間には、プロキシサーバーがあります。 LAN に配置されている場合、コンピューターはプロキシサーバーを使用してインターネットに接続することができます。この場合、プロキシサーバーは、ゲートウェイサーバーやファイアウォールサーバーに組み込まれているか、またはこれらの一部です。プロキシは Web 要求をキャッシュに格納し、格納したデータを使用して複数のクライアント要求を処理することができます。要求されたデータがプロキシサーバーのキャッシュにない場合、プロキシサーバーは独自の IP アドレスを使用して、実際のサーバーにその要求を転送します。ここでは、プロキシサーバーはクライアントコンピューターとして機能します。

プロキシサーバーはキャッシュサーバーとして機能し、Web ページをすばやく読み込めるようにしますが、正しく使用しないとパフォーマンスが下がる場合もあります。

多くの場合、手動プロキシ構成は敬遠され、自動プロキシ構成が使用されます。自動プロキシ構成では、プロキシサーバー間の負荷が分散されますが、構成スクリプトの複雑さによっては大幅な遅れが発生する場合があります。

Dynamics 365 Server をインストールしている場合は、プロキシサーバーを迂回して、処理能力を向上させることができます。

サーバーは、プロキシにアクセスする必要がないローカル Web アドレスを提供します。 ローカルアドレスにはプロキシサーバーを使用しない を選択すると、Dynamics 365 Server の完全修飾ドメイン名を例外リストに指定できます。 SDK アセンブリを使用してレコードを作成している場合、スループットはさらに向上します。

サービスチャネル割り当てのパフォーマンスの改善

Dynamics 365 Customer Engagement (on-premises) Web サービスへの接続の確立とユーザーの認証は、サービスプロキシクラスの OrganizationServiceProxy と DiscoveryServiceProxy を使用して実行できます。ただし、これらのサービスプロキシクラスは、正しく使用しないとアプリケーションのパフォーマンスが低下することもあります。そのため、SDK で使用できるさまざまなクライアントクラスをいつどのように使用するかを理解しておくと、アプリケーションのパフォーマンスの向上に役立つことがあります。

組織の Web サービスを使用するなど、サービスエンドポイントを使用して Windows Communication Foundation (WCF) サービスチャネルを確立する場合、エンドポイントからのメタデータのダウンロードとユーザー認証という時間がかかる 2 つの処理をアプリケーションで行わなければなりません。これらの処理を各アプリケーションセッションで実行する回数を最小限に抑えれば、パフォーマンスを向上させることができます。

次の OrganizationServiceProxy コンストラクターでは、サービスプロキシオブジェクトが作成されるたびにこれらの両方の処理を実行します。

OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, 
    ClientCredentials deviceCredentials)

一般に、このコンストラクターを使用するとアプリケーションのパフォーマンスが向上します。このコンストラクターをアプリケーションセッションで 1 回だけ使用してサービスプロキシのインスタンスを作成すれば、返される参照をキャッシュしてアプリケーション内の別のコードパスで使用できるからです。ただし、返されるサービス参照はスレッドセーフではないため、マルチスレッドアプリケーションでは、インスタンスをスレッドごとに 1 つずつ割り当てる必要があります。また、サービスチャネルに割り当てられたリソースを解放するために、アプリケーションを終了する前にサービスプロキシオブジェクトで Dispose を呼び出す必要があります。

サービスプロキシクラスでは、次のクラスメソッドを使用してメタデータのダウンロードとユーザー認証を実行します。

IServiceManagement<IOrganizationService> orgServiceManagement = 
    ServiceConfigurationFactory.CreateManagement<IOrganizationService>(
    new Uri(organizationUrl));

AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials);

ServiceConfigurationFactory.CreateManagement メソッドでメタデータのダウンロードを行い、Authenticate(AuthenticationCredentials) メソッドでユーザー認証を行います。これらのメソッドから返されるオブジェクトはスレッドセーフであり、アプリケーションで静的にキャッシュできます。その後、それらのオブジェクトを使用して、使用可能な他のいずれかのコンストラクターを使用するサービスプロキシオブジェクトを作成できます。

OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)
OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)

サービス管理と認証済みの資格情報のオブジェクトをキャッシュすることで、サービスプロキシオブジェクトを 1 つのアプリケーションセッションで複数回作成する場合の効率を高めることができます。 OrganizationServiceProxy でいずれかの EnableProxyTypes() メソッドを使用して事前バインド型を有効にする場合は、キャッシュされた IServiceManagement<TService> オブジェクトから作成されるすべてのサービスプロキシについても同じように設定する必要があります。アプリケーションでメタデータを使用する場合は、取得したメタデータをキャッシュし、RetrieveTimestampRequest メッセージを定期的に呼び出して、キャッシュを更新する必要があるかどうかを確認することをお勧めします。

さらに、WCF セキュリティトークン (Token) を監視し、期限が切れる前に更新するようにしてください。これにより、トークンが失われずに済み、認証をやり直す必要がなくなります。トークンをチェックするには、OrganizationServiceProxy クラスまたは DiscoveryServiceProxy クラスを継承するカスタムクラスを作成し、トークンをチェックするビジネスロジックを実装します。それらのプロキシクラスは新しいクラスでラップしてもかまいません。また、別の手法として、Web サービスの各呼び出しの前にトークンを明示的にチェックする方法もあります。この手法を示すコード例については、ヘルパーコード: ServerConnection クラストピックの ManagedTokenDiscoveryServiceProxy クラス、ManagedTokenOrganizationServiceProxy クラス、および AutoRefreshSecurityToken クラスを参照してください。

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

次のベストプラクティスは、Dynamics 365 Customer Engagement (on-premises) をカスタマイズおよび拡張するのに役立ちます。

Dynamics 365 Customer Engagement (on-premises) のベストプラクティス

ソリューションビルダーの Microsoft Dynamics 365 Customer Engagement (on-premises) のパターンと原則ホワイトペーパーのダウンロードには、特に、Dynamics 365 for Customer Engagement を使用したソリューションの作成に関する手順が含まれています。

カスタムエンティティとカスタム属性の使用

コードおよびクエリのエンティティを参照しているエンティティ名を常に使用します。整数値は、異なる組織のユーザー定義エンティティでは異なるので、オブジェクトの種類コード (エンティティの種類コードとも呼ばれる) を使用しないでください。

次のテクニックを使用することでサーバー上の領域を節約します。

新しいエンティティを作成するのではなく、既存のエンティティに対してカスタム属性を作成する。
既存のエンティティの名前を変更して、エンティティの意味をわかりやすくする。

どんなときにエンティティをカスタマイズするのか

営業案件などのシステムエンティティは、新しいカスタムエンティティに置き換えるのではなくカスタマイズします。そうすれば、既存のエンティティのあらゆる組み込み機能を利用できます。

プラグインとワークフローのどちらを使用するか

Dynamics 365 Customer Engagement (on-premises) を拡張またはカスタマイズする場合、タスクの実行方法について、いくつかの選択肢があります。クライアント側の JavaScript コードをフォームに追加したり、カスタム ASP.NET ページを追加したりすることに加え、プラグインまたはカスタムワークフローを作成することもできます。カスタムワークフローの作成には、カスタムワークフロー活動を呼び出す Web インターフェイスを使用します。しかし、どんなときにプラグインを使用し、どんなときにワークフローを使用するかは、どうやって判断するのでしょうか。使用するテクノロジは、実行が必要なタスクとカスタマイズの作成者によって異なります。

たとえば、コアプラットフォーム操作の実行の直前または直後、および操作の結果がプラットフォームから返される前にカスタムコードを実行する場合は、同期プラグインによるリアルタイムワークフローを使用する必要があります。この状況で非同期ワークフローや非同期プラグインは使用できません。なぜなら、これらはキューに入れられて、コア操作の実行完了後に実行されることになり、いつ実行されるのか予測できないからです。 Dynamics 365 for Customer Engagement にカスタム機能を追加する場合、ワークフロー、カスタムワークフロー活動、およびプラグインはサポートされますが、カスタム XAML ワークフローはサポートされません。

これらのテクノロジを評価し、プラグインまたはワークフローのソリューションに関係する問題として、展開、パフォーマンス、およびメンテナンスのことを検討してから、ビジネスの目的に最適なものを選択するようにしてください。

次の表は、プラグインとワークフローの特性をまとめたものです。

基準	プラグイン	ワークフロー
コアプラットフォーム操作 (作成、更新、削除など) の前または後での実行	コア操作の直前または直後に実行します (同期)。キューに入れて、コア操作の後に実行することもできます (非同期)。	非同期ワークフローはキューに入って、コア操作の後に実行されます。リアルタイムワークフローはプラグインと同様の特性を備えています。
サーバーのパフォーマンスへの影響	同期プラグインはプラットフォームのメイン処理の一部なので、プラットフォームの応答時間を増大させる可能性があります。非同期プラグインは別プロセスで実行されるので、サーバーの応答時間への影響は比較的小さいです。	非同期ワークフローは別プロセスで実行されるので、サーバーの応答時間への影響は比較的小さいです。リアルタイムワークフローは、サンドボックスプラグインと同様のパフォーマンス特性を備えています。
セキュリティ制限	プラグインをプラットフォームに登録するには、システム管理者またはシステムカスタマイザーのセキュリティロールと、展開管理者グループのメンバーシップが必要です。	ユーザーは Web アプリケーションでワークフローを対話的に作成できます。しかし、カスタムワークフロー活動を登録する場合は、プラグインを登録する場合と同じセキュリティロールが必要です。
Dynamics 365 Customer Engagement (on-premises) バージョン (SKU) サポート	サンドボックスに登録すると、Dynamics 365 for Customer Engagement でサポートされます。パートナーの判断によってはパートナーホスト型のインストールでサポートされることもあります。	ワークフローは、すべての Customer Engagement の展開でサポートされます。ユーザー定義のワークフロー活動は、Dynamics 365 for Customer Engagement のサンドボックスで、また設置型/IFD 展開のためのサンドボックスの内または外でサポートされます。
処理時間の長さ	同期実行または非同期実行として登録されるプラグインは、2 分という時間制限内に実行を完了するように制約を受けます。	短いプロセスにも長いプロセスにも適合します。ただし、ワークフローの各アクティビティは完了までに 2 分を超えることはできません。
Dynamics 365 for Outlook クライアントがオフラインのときの動作	オンラインとオフラインの両方がサポートされます。	ワークフローはオフライン時には実行されません。
プロセスとデータの持続性	プラグインは完了するまで実行されます。プラグインはメモリ内データが持続することのないステートレスとして記述する必要があります。	同期ワークフローは、SDK 呼び出しによって、または Web アプリケーションからユーザーが、一時停止、延期、取り消し、または再開することができます。ワークフローの状態は、一時停止または延期に先立って自動的に保存されます。リアルタイムのワークフローは、待機状態を持つことはできません。プラグインと同じように、完了するまで実行する必要があります。
偽装	プラグインは別のシステムユーザーに代わってデータ操作を実行できます。	リアルタイムワークフローは偽装を使用できますが、非同期ワークフローは偽装を使用できません。リアルタイムワークフローは、ワークフローの所有者として、または呼び出し元ユーザーとして実行できます。
作成	ソフトウェアエンジニアまたはプログラマはプラグインを作成できます。	エンドユーザー、ビジネスアナリスト、または管理者を含むだれでもが、適切な権限を持っていれば、ワークフローを作成できます。

非同期プラグインもワークフローもサーバーパフォーマンスに大きな影響を与えることはありません。

どういう種類のワークフローがよいか

パフォーマンスの観点から見たとき、単一の長いワークフローを作成するのと、複数の子ワークフローを作成して、1 つの親ワークフローから呼び出すのとでは、どちらが好ましいでしょうか。子ワークフローというアプローチは、スループットの低下を引き起こしますが、ワークフロー定義を頻繁に変更する場合は管理しやすい方法です。コンパイルのオーバーヘッドは大きな問題にはなりません。なぜなら、ワークフローがコンパイルされるのは公開時だけだからです。ただし、Dynamics 365 Customer Engagement (on-premises) で各ワークフローインスタンスを開始する際のオーバーヘッドはあります。このオーバーヘッドは、ワークフローで使用される全エンティティを取得するときと、2 段階のプロセス ("ワークフロー展開タスク" と実際のワークフローインスタンスが含まれる) で子ワークフローを開始するときに発生します。そのため、スループットを最大化するなら、単一の長いワークフローを使用してください。

カスタムワークフロー活動を完了済みとしてマークする方法

Execute メソッドからの戻り値は、活動を "完了済み" としてマークするためにワークフローランタイムによって使用されます。活動で基本クラス機能をバイパスするのでない限り、return base.Execute(executionContext) を使用してください。 ActivityExecutionStatus.Closed を返すことは避けてください。詳細: ActivityExecutionStatus 列挙体

カスタムワークフロー活動での例外を報告する方法

コードで InvalidPluginExecutionException をスローしてください。このエラーはワークフローインスタンスフォームに表示されます。

部署固有のカスタムエンティティの定義

カスタムエンティティの特権は部署単位ではなくセキュリティロール単位です。指定の部署のみが見られるカスタムエンティティを定義するには、部署ごとに別々のセキュリティロールを定義し、該当するロールでカスタムエンティティに特権を与える必要があります。

セキュリティのベストプラクティス

ビジネスデータの保護に役立つように、次のガイドラインに従ってください。

全般

Dynamics 365 Customer Engagement (on-premises) の実装をセキュリティで保護するためのベストプラクティスを以下に示します。

組織の Dynamics 365 Customer Engagement (on-premises) 実装について承認されたセキュリティデータ計画を立てます。
アプリケーションプールをセットアップする場合には、必要最小限の特権を割り当てます。
すべてのユーザーに各自のアカウントに強力なパスワードを使用することを義務付けます。

詳細: Dynamics 365 Customer Engagement (on-premises) のセキュリティ概念

ロール、特権、およびアクセス権

Dynamics 365 Customer Engagement (on-premises) セキュリティモデルを使用する際のベストプラクティスを以下に示します。

システム管理者のロールを割り当てるユーザーの数を厳格に制限します。このロールは削除しないでください。
最小限の特権を割り当てるセキュリティのベストプラクティスに従ってロールを作成し、タスクに必要な最小限のビジネスデータへのアクセス権を与えます。ユーザーにはそれぞれの業務に合ったロールを割り当てます。
ユーザーに追加のアクセスレベルや権限が必要な場合は、特定の特権を持つ新しいロールを作成し、ユーザーをその新しいロールに追加します。ユーザーの権限は、そのユーザーが割り当てられているすべてのロールの和になります。 1 人または小数のメンバーにのみ必要な元のロール特権を与えないでください。
特定の種類のすべてのオブジェクトに幅広い特権を与えるのではなく、適切な場合は共有を使用して個々のオブジェクトに対する特定の権限を特定のユーザーに与えます。
チームを使用して複数の機能にまたがるグループを作成し、特定のオブジェクトをチームで共有できるようにします。
アクセス権を共有するユーザーは、必要最小限の情報を共有するようにします。

特権の昇格の回避

特権の昇格攻撃が起こるのは、ユーザーが所有者や管理者などの信頼されたアカウントの特権を使用できるときです。常に最小限の特権を持つユーザーアカウントの下で実行し、必要なアクセス許可のみを割り当ててください。コードを実行するために管理者や所有者のアカウントを使用するのは避けてください。そうすれば、攻撃が成功した場合に被る損害を少なくすることができます。追加的なアクセス許可を必要とするタスクを実行するときは、そのタスクの最中にだけプロシージャ署名または偽装を使用します。

サーバー側の開発

Dynamics 365 Customer Engagement (on-premises) のサーバー側コードの開発におけるベストプラクティスを以下に示します。

Dynamics 365 Customer Engagement (on-premises) データベースを変更する場合は、必ず SDK を使用してください。それ以外の方法では、Dynamics 365 Customer Engagement (on-premises) セキュリティモデルが適用されません。
プラグインは管理者のコンテキストで実行されます。ログオンユーザーがアクセスできない情報にこのコードがアクセスする可能性がある点に留意してください。
ワークフローアセンブリおよびプラグインには、実行に時間のかかるコードを記述しないでください。非同期で実行するように登録するプラグインコードはできるだけすばやく戻ることが重要です。
Dynamics 365 Customer Engagement (on-premises) のデータを独自のデータストアにレプリケートする場合、データのセキュリティを考慮する必要があります。プラグインを使用してデータを送信する場合、コアプラットフォーム操作の後に実行するようにプラグインを登録してください。ログオンユーザーに対するセキュリティ特権チェックは、コアプラットフォーム操作の最中に行われます。
Dynamics 365 Customer Engagement (on-premises) のデータは安全にレンダリングできるとは限りません。セキュリティで保護されていない HTML タグがデータに挿入されている可能性があります。
Dynamics 365 Customer Engagement (on-premises) データベースには SQL Server Enterprise Manager から直接アクセスしないでください。 SDK を使用しないと、SQL インジェクションの脅威にさらされる可能性があります。
インターネット経由で展開する場合、ソリューションは、非常に脆弱なリンクと同様の危険にさらされます。アプリケーションをインターネットに露出すれば、セキュリティの脅威にさらすことになります。
バッファーオーバーラン、例外などからセキュリティを確保するため、マネージコードを生成する言語のみを使用してください。

セキュリティの詳細については、次のトピックを参照してください。

クライアント側の開発

Customer Engagement Web アプリケーションと Dynamics 365 for Outlook のカスタマイズ開発のベストプラクティスには、以下の内容が含まれています。

可能な限り、サーバー側の処理を必要とするページを使用せずに、Web リソースを使用します。サーバー側の処理を使用するしかない場合は、作成するカスタム Web ページを Dynamics 365 Customer Engagement (on-premises) とは別の Web サイトにインストールしてください。作成したコードのセキュリティ信頼レベルに応じて、サイトの信頼レベルを適切に設定してください。こうすれば、クロスサイトスクリプティングなどの脅威を軽減できます。
セキュリティを高めるため、分離した Web サイトを Dynamics 365 Customer Engagement (on-premises) とは異なるアカウントで実行するようにしてください。このアカウントに最小限のアクセスを許可し、Microsoft データベースに直接アクセスできないようにしてください。このアカウントにはほかのだれもサインインせず、サインインするのは自分のアプリケーションに対してのみなので、有効期限のない複雑なパスワードを使用してもかまいません。
ActiveX コントロールには既知のセキュリティ上の問題があるため、使用しないでください。
クライアントスクリプトの制限に注意してください。詳細: ベストプラクティス: Customer Engagement のクライアントスクリプト
データの変更がどのように行われるかに関係なく、プラグインを使用してビジネスロジックを適用します。
レコードを削除したり、セキュリティにかかわる変更 (セキュリティロールに新しいユーザーを追加するなど) を適用するときは、常に確認ダイアログボックスを使用します。 openConfirmDialog を使用して、ダイアログを表示することができます。そうすれば、クリックジャッキング (UI redressing) などのテクニックを防ぐのに役立ちます。このような攻撃は、そのページが悪意のある開発者によって見かけは無害そうなページに埋め込まれることで行われます。その無害に見えるページでユーザーを騙して、セキュリティを危うくするようなアクションを実行させたり、データに対して望ましくないアクションを実行させます。

独自の Web サイトに関するセキュリティ上のベストプラクティスを以下に示します。

匿名アクセスを使用しないでください。
Transport Layer Security (TLS)またはSecure Sockets Layer (SSL)上で統合Windows認証、NTLM、または基本認証を使用します。
独自の Web サイトが Dynamics 365 Customer Engagement (on-premises) と異なるコンピューター上にある場合、暗号化されていないデータがネットワーク経由で送信されるのを防ぐため、TLS/SSL を使用してください。

詳細については、次を参照してください。
[Web アプリケーションのセキュリティ上の脅威の概要](/previous-versions/f13d73y6(v=vs.140)
ASP.NET Web アプリケーションのセキュリティ
Introduction to Web Application Security (Web アプリケーションセキュリティの概要)

ISV 拡張のベストプラクティス

ISV 拡張のポイントの 1 つは、インストールされている ISV ソリューションが他にもある可能性があることを考慮に入れておくことです。以下にベストプラクティスを示します。

Dynamics 365 Customer Engagement Web サービスを使用するためのベストプラクティス

Dynamics 365 Customer Engagement (on-premises) Web サービスの URL は構成ファイル (たとえば、app.config ファイル) で指定して、URL が変更されてもその影響がコードに及ばないようにします。たとえば、世界の Dynamics 365 for Customer Engagement データセンターに対して異なる URL があります。

カスタム Web アプリケーションまたは Web ページの格納場所

トピック ASPX Web ページまたは IFRAME からのシングルサインオンの実行を参照してください。

Web アプリケーションのグリッドビューが更新されたときのプラグインの実行方法

RetrieveMultipleRequest メッセージ要求にプラグインを登録します。登録の際にはエンティティの種類を指定しません。

どんなときに新しい Web サイトを作成するのか

新しい Web サイトを作成するのは、以下のいずれかに該当する場合です。

アプリケーションを、Dynamics 365 Customer Engagement (on-premises) アプリケーションと異なるドメイン、プロトコル、またはポートにバインドする必要があるとき、または別のアプリケーションプール内で実行する必要があるとき。
アプリケーションは単独で存在しアクセスすることができます。たとえば、サーバーとしての Dynamics 365 Customer Engagement (on-premises) と (Web サービスを使用して) 対話するポータルは、新しい Web サイトとしてホストする必要があります。
アプリケーションでは常に Active Directory または統合 Windows 認証 (IFD ではない) を使用します。クロスドメインスクリプトは問題になりません。たとえば、アプリケーションは Web サービスを使用してバックエンドと対話し、Dynamics 365 Customer Engagement (on-premises) フォームと対話します。 Dynamics 365 Customer Engagement (on-premises) フォームと対話しない Dynamics 365 Customer Engagement (on-premises) アプリケーションに含まれる IFRAME でホストされるページは、このカテゴリに入ります。

次の方法で共有

Dynamics 365 Customer Engagement での開発におけるベストプラクティス

パフォーマンスのベストプラクティス

複数のスレッドの使用

システムによる GUID の作成の使用

事前バインド型の使用

プラグインの無効化

高速なプラグインの作成

取得するデータの制限

オフライン用に有効になっているエンティティの数を制限します

クライアントでのプロキシ設定の調整 (設置型のみ)

サービスチャネル割り当てのパフォーマンスの改善

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

Dynamics 365 Customer Engagement (on-premises) のベストプラクティス

カスタムエンティティとカスタム属性の使用

どんなときにエンティティをカスタマイズするのか

プラグインとワークフローのどちらを使用するか

どういう種類のワークフローがよいか

カスタムワークフロー活動を完了済みとしてマークする方法

カスタムワークフロー活動での例外を報告する方法

部署固有のカスタムエンティティの定義

セキュリティのベストプラクティス

全般

ロール、特権、およびアクセス権

特権の昇格の回避

サーバー側の開発

クライアント側の開発

独自の Web サイトに関するセキュリティ上のベストプラクティスを以下に示します。

ISV 拡張のベストプラクティス

Dynamics 365 Customer Engagement Web サービスを使用するためのベストプラクティス

カスタム Web アプリケーションまたは Web ページの格納場所

Web アプリケーションのグリッドビューが更新されたときのプラグインの実行方法

どんなときに新しい Web サイトを作成するのか

関連項目

フィードバック

その他のリソース

次の方法で共有

Dynamics 365 Customer Engagement での開発におけるベスト プラクティス

パフォーマンスのベスト プラクティス

複数のスレッドの使用

システムによる GUID の作成の使用

事前バインド型の使用

プラグインの無効化

高速なプラグインの作成

取得するデータの制限

オフライン用に有効になっているエンティティの数を制限します

関連エンティティに伝播する操作の制限

クライアントでのプロキシ設定の調整 (設置型のみ)

サービス チャネル割り当てのパフォーマンスの改善

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

Dynamics 365 Customer Engagement (on-premises) のベスト プラクティス

カスタム エンティティとカスタム属性の使用

どんなときにエンティティをカスタマイズするのか

プラグインとワークフローのどちらを使用するか

どういう種類のワークフローがよいか

カスタム ワークフロー活動を完了済みとしてマークする方法

カスタム ワークフロー活動での例外を報告する方法

部署固有のカスタム エンティティの定義

セキュリティのベスト プラクティス

全般

ロール、特権、およびアクセス権

特権の昇格の回避

サーバー側の開発

クライアント側の開発

独自の Web サイトに関するセキュリティ上のベスト プラクティスを以下に示します。

ISV 拡張のベスト プラクティス

Dynamics 365 Customer Engagement Web サービスを使用するためのベスト プラクティス

カスタム Web アプリケーションまたは Web ページの格納場所

Web アプリケーションのグリッド ビューが更新されたときのプラグインの実行方法

どんなときに新しい Web サイトを作成するのか

関連項目

フィードバック

その他のリソース

Dynamics 365 Customer Engagement での開発におけるベストプラクティス

パフォーマンスのベストプラクティス

サービスチャネル割り当てのパフォーマンスの改善

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

Dynamics 365 Customer Engagement (on-premises) のベストプラクティス

カスタムエンティティとカスタム属性の使用

カスタムワークフロー活動を完了済みとしてマークする方法

カスタムワークフロー活動での例外を報告する方法

部署固有のカスタムエンティティの定義

セキュリティのベストプラクティス

独自の Web サイトに関するセキュリティ上のベストプラクティスを以下に示します。

ISV 拡張のベストプラクティス

Dynamics 365 Customer Engagement Web サービスを使用するためのベストプラクティス

Web アプリケーションのグリッドビューが更新されたときのプラグインの実行方法