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

  • [アーティクル]

 

公開日: 2017年1月

対象: Dynamics 365 (online)、Dynamics 365 (on-premises)、Dynamics CRM 2016、Dynamics CRM Online

このトピックでは、Microsoft Dynamics 365 (オンラインおよび設置型) をカスタマイズするときのベスト プラクティスについて説明します。

重要

カスタマイズでサポートされている手法およびサポートされていない手法について理解するために、サポートされる Microsoft Dynamics 365 の拡張機能 を確認します。

このトピックの内容

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

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

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

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

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

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

複数のスレッドの使用

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

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

GUID (ID) を手動で作成する代わりに、システムで自動的に割り当てるようにします。 これにより、Microsoft Dynamics 365 で連続した 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 メソッドは Microsoft Dynamics 365 で頻繁に処理されます。 そのメッセージに関してプラグインを登録した場合、プラグインによってシステムのパフォーマンスが大きな影響を受ける可能性があります。なぜなら、Execute メソッドが処理されるたびに、そのプラグインが実行されるからです。これは頻繁に起こることです。

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

取得するデータの制限

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

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

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

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

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

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

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

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

プロキシ サーバーはキャッシュ サーバーとして機能し、Web ページをすばやく読み込めるようにしますが、正しく使用しないとパフォーマンスが下がる場合もあります。 多くの場合、手動プロキシ構成は敬遠され、自動プロキシ構成が使用されます。 自動プロキシ構成では、プロキシ サーバー間の負荷が分散されますが、構成スクリプトの複雑さによっては大幅な遅れが発生する場合があります。

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

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

Microsoft Dynamics 365 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)

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

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

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

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

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

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

Microsoft Dynamics 365 (オンライン) に関するベスト プラクティス

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

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

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

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

  • 新しいエンティティを作成するのではなく、既存のエンティティに対してカスタム属性を作成する。

  • 既存のエンティティの名前を変更して、エンティティの意味をわかりやすくする。

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

営業案件などのシステム エンティティは、新しいカスタム エンティティに置き換えるのではなくカスタマイズします。そうすれば、既存のエンティティのさまざまな組み込み機能を利用できます。 たとえば、営業案件エンティティとサポート案件エンティティには、顧客を関連付ける検索フィールドがあります。 顧客は取引先企業の場合もあれば、取引先担当者の場合もあります。 同じ種類の検索を持つカスタム エンティティを作成することはできません。 システム エンティティの表示名は変更できるので、実際のビジネスにとって意味のある名前にすることができます。

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

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

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

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

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

基準

プラグイン

ワークフロー

コア プラットフォーム操作 (作成、更新、削除など) の前または後での実行

コア操作の直前または直後に実行します (同期)。

キューに入れて、コア操作の後に実行することもできます (非同期)。

非同期ワークフローはキューに入って、コア操作の後に実行されます。

リアルタイム ワークフローはプラグインと同様の特性を備えています。

サーバーのパフォーマンスへの影響

同期プラグインはプラットフォームのメイン処理の一部なので、プラットフォームの応答時間を増大させる可能性があります。

非同期プラグインは別プロセスで実行されるので、サーバーの応答時間への影響は比較的小さいです。

非同期ワークフローは別プロセスで実行されるので、サーバーの応答時間への影響は比較的小さいです。

リアルタイム ワークフローは、サンドボックス プラグインと同様のパフォーマンス特性を備えています。

セキュリティ制限

プラグインをプラットフォームに登録するには、システム管理者またはシステム カスタマイザーのセキュリティ ロールと、展開管理者グループのメンバーシップが必要です。

ユーザーは Web アプリケーションでワークフローを対話的に作成できます。

しかし、カスタム ワークフロー活動を登録する場合は、プラグインを登録する場合と同じセキュリティ ロールが必要です。

Microsoft Dynamics 365 バージョン (SKU) サポート

サンドボックスに登録されると、Microsoft Dynamics 365 (オンライン) でサポートされます。 パートナーの判断によってはパートナー ホスト型のインストールでサポートされることもあります。

ワークフローは、すべての Dynamics 365 の展開でサポートされます。 ユーザー定義のワークフロー活動は、Microsoft Dynamics 365 (オンライン) のサンドボックスで、また設置型/IFD 展開のためのサンドボックスの内または外でサポートされます。

処理時間の長さ

同期実行または非同期実行として登録されるプラグインは、2 分という時間制限内に実行を完了するように制約を受けます。

短いプロセスにも長いプロセスにも適合します。 ただし、ワークフローの各アクティビティは完了までに 2 分を超えることはできません。

Outlook 用 Dynamics 365 クライアントがオフラインのときの動作

オンラインとオフラインの両方がサポートされます。

ワークフローはオフライン時には実行されません。

プロセスとデータの持続性

プラグインは完了するまで実行されます。 プラグインはメモリ内データが持続することのないステートレスとして記述する必要があります。

同期ワークフローは、SDK 呼び出しによって、または Web アプリケーションからユーザーが、一時停止、延期、取り消し、または再開することができます。 ワークフローの状態は、一時停止または延期に先立って自動的に保存されます。

リアルタイムのワークフローは、待機状態を持つことはできません。 プラグインと同じように、完了するまで実行する必要があります。

偽装

プラグインは別のシステム ユーザーに代わってデータ操作を実行できます。

リアルタイム ワークフローは偽装を使用できますが、非同期ワークフローは偽装を使用できません。 リアルタイム ワークフローは、ワークフローの所有者として、または呼び出し元ユーザーとして実行できます。

作成

ソフトウェア エンジニアまたはプログラマはプラグインを作成できます。

エンド ユーザー、ビジネス アナリスト、または管理者を含むだれでもが、適切な権限を持っていれば、ワークフローを作成できます。

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

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

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

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

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

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

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

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

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

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

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

全般

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

  • 組織の Microsoft Dynamics 365 実装について承認されたセキュリティ データ計画を立てます。

  • アプリケーション プールをセットアップする場合には、必要最小限の特権を割り当てます。

  • すべてのユーザーに各自のアカウントに強力なパスワードを使用することを義務付けます。 詳細については、Windows ヘルプで "強力なパスワード" に関するトピックを参照してください。

詳細:TechNet: Microsoft Dynamics CRM のセキュリティに関する考慮事項

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

Microsoft Dynamics 365 セキュリティ モデルを使用する際のベスト プラクティスを以下に示します。

  • システム管理者のロールを割り当てるユーザーの数を厳格に制限します。 このロールは削除しないでください。

  • 最小限の特権を割り当てるセキュリティのベスト プラクティスに従ってロールを作成し、タスクに必要な最小限のビジネス データへのアクセス権を与えます。 ユーザーにはそれぞれの業務に合ったロールを割り当てます。

  • ユーザーに追加のアクセス レベルや権限が必要な場合は、特定の特権を持つ新しいロールを作成し、ユーザーをその新しいロールに追加します。 ユーザーの権限は、そのユーザーが割り当てられているすべてのロールの和になります。 1 人または小数のメンバーにのみ必要な元のロール特権を与えないでください。

  • 特定の種類のすべてのオブジェクトに幅広い特権を与えるのではなく、適切な場合は共有を使用して個々のオブジェクトに対する特定の権限を特定のユーザーに与えます。

  • チームを使用して複数の機能にまたがるグループを作成し、特定のオブジェクトをチームで共有できるようにします。

  • アクセス権を共有するユーザーは、必要最小限の情報を共有するようにします。

特権の昇格の回避

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

サーバー側の開発

Microsoft Dynamics 365 のサーバー側コードの開発におけるベスト プラクティスを以下に示します。

  • Microsoft Dynamics 365 データベースを変更する場合は、必ず SDK を使用してください。それ以外の方法では、Microsoft Dynamics 365 セキュリティ モデルが適用されません。

  • プラグインは管理者のコンテキストで実行されます。ログオン ユーザーがアクセスできない情報にこのコードがアクセスする可能性がある点に留意してください。

  • ワークフロー アセンブリおよびプラグインには、実行に時間のかかるコードを記述しないでください。 非同期で実行するように登録するプラグイン コードはできるだけすばやく戻ることが重要です。

  • Microsoft Dynamics 365 のデータを独自のデータ ストアにレプリケートする場合、データのセキュリティを考慮する必要があります。 プラグインを使用してデータを送信する場合、コア プラットフォーム操作の後に実行するようにプラグインを登録してください。 ログオン ユーザーに対するセキュリティ特権チェックは、コア プラットフォーム操作の最中に行われます。

  • Microsoft Dynamics 365 のデータは安全にレンダリングできるとは限りません。 セキュリティで保護されていない HTML タグがデータに挿入されている可能性があります。

  • Microsoft Dynamics 365 データベースには SQL Server Enterprise Manager から直接アクセスしないでください。 SDK を使用しないと、SQL インジェクションの脅威にさらされる可能性があります。

  • インターネット経由で展開する場合、ソリューションは、非常に脆弱なリンクと同様の危険にさらされます。 アプリケーションをインターネットに露出すれば、セキュリティの脅威にさらすことになります。

  • バッファー オーバーラン、例外などからセキュリティを確保するため、マネージ コードを生成する言語のみを使用してください。

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

クライアント側の開発

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

  • 可能な限り、サーバー側の処理を必要とするページを使用せずに、Web リソースを使用します。 サーバー側の処理を使用するしかない場合は、作成するカスタム Web ページを Microsoft Dynamics 365 とは別の Web サイトにインストールしてください。 作成したコードのセキュリティ信頼レベルに応じて、サイトの信頼レベルを適切に設定してください。 こうすれば、クロスサイト スクリプティングなどの脅威を軽減できます。

  • セキュリティを高めるため、分離した Web サイトを Microsoft Dynamics 365 とは異なるアカウントで実行するようにしてください。 このアカウントに最小限のアクセスを許可し、Microsoft データベースに直接アクセスできないようにしてください。 このアカウントにはほかのだれもサインインせず、サインインするのは自分のアプリケーションに対してのみなので、有効期限のない複雑なパスワードを使用してもかまいません。

  • ActiveX コントロールには既知のセキュリティ上の問題があるため、使用しないでください。

  • クライアント スクリプトの制限に注意してください。詳細:Microsoft Dynamics 365 フォームのコードを記述する

  • データの変更がどのように行われるかに関係なく、プラグインを使用してビジネス ロジックを適用します。

  • レコードを削除したり、セキュリティにかかわる変更 (セキュリティ ロールに新しいユーザーを追加するなど) を適用するときは、常に確認ダイアログ ボックスを使用します。confirmDialog を使用して、ダイアログを表示することができます。 そうすれば、クリックジャッキング (UI redressing) などのテクニックを防ぐのに役立ちます。このような攻撃は、そのページが悪意のある開発者によって見かけは無害そうなページに埋め込まれることで行われます。その無害に見えるページでユーザーを騙して、セキュリティを危うくするようなアクションを実行させたり、データに対して望ましくないアクションを実行させます。

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

  • 匿名アクセスを使用しないでください。

  • 統合 Windows 認証、NTLM、または基本認証を Transport Layer Security (TLS) または Secure Sockets Layer (SSL) で使用してください。

  • 独自の Web サイトが Microsoft Dynamics 365 と異なるコンピューター上にある場合、暗号化されていないデータがネットワーク経由で送信されるのを防ぐため、TLS/SSL を使用してください。

詳細については、以下を参照してください。

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

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

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

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

プラグインおよびカスタム ワークフロー活動の格納場所

オンディスクのプラグインまたはカスタム フロー活動については、アセンブリを <installdir>\Server\bin\assembly フォルダーに格納します。

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

「ASPX Web ページまたは IFRAME からのシングル サインオンの実装」を参照してください。

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

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

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

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

  • アプリケーションを、Microsoft Dynamics 365 アプリケーションと異なるドメイン、プロトコル、またはポートにバインドする必要があるとき、または別のアプリケーション プール内で実行する必要があるとき。

  • アプリケーションは単独で存在しアクセスすることができます。 たとえば、サーバーとしての Microsoft Dynamics 365 と (Web サービスを使用して) 対話するポータルは、新しい Web サイトとしてホストする必要があります。

  • アプリケーションでは常に Active Directory または統合 Windows 認証 (IFD ではない) を使用します。クロス ドメイン スクリプトは問題になりません。 たとえば、アプリケーションは Web サービスを使用してバックエンドと対話し、Microsoft Dynamics 365 フォームと対話します。Microsoft Dynamics 365 フォームと対話しない Microsoft Dynamics 365 アプリケーションに含まれる IFRAME でホストされるページは、このカテゴリに入ります。

関連項目

サーバー上の Microsoft Dynamics 365 の拡張
ビット フラグの設定
Microsoft Dynamics 365 フォームのコードを記述する
ビジネス プロセスを拡張するためのプラグインを記述する
ユーザー定義ワークフロー活動 (ワークフロー アセンブリ)

Microsoft Dynamics 365

© 2017 Microsoft. All rights reserved. 著作権