Dynamics 365 Customer Engagement (on-premises) のデータを外部システムと同期する
Dynamics 365 Customer Engagement (on-premises) のデータを、他のシステムに格納されているデータと同期させて、統合することが必要な場合があります。 一般的なデータ統合パターンには、外部システムからのデータの取得と Dynamics 365 Customer Engagement (on-premises) へのそのデータの転送、Dynamics 365 Customer Engagement (on-premises) からのデータの取得とそのデータと外部データ ストアとの同期、または外部データによる Dynamics 365 Customer Engagement (on-premises) の更新が含まれています。 現在は、複数の新機能を使用して、これらのシナリオを実現するコードの記述がより簡単になっています。
これらの新機能はどの状況でも必要に応じて別々に使用できますが、外部データとのデータの同期および統合に関連する共通の問題に組み合わせで対処できます。 次の表に、これらの新機能を紹介します。
| 機能 | 説明 |
|---|---|
| 特定のメッセージを削除する | Dynamics 365 Customer Engagement (on-premises) には、レコードを更新する個別の操作に対応した複数の特定のメッセージがあります。 これらのメッセージはこのリリースで廃止され、現在は、同じ操作を実行するために Update を使用するだけです。 削除されたメッセージを以下に示します。- 割り当て - SetParentSystemUser - SetParentTeam - SetParentBusinessUnit - SetBusinessEquipment - SetBusinessUnit - SetState 単にレコードを更新することは、これらのメッセージを使用するよりも簡単であり、データの統合と同期のシナリオに対する開発を効率化することになります。 詳細については、更新を使用して特化された操作を実行するを参照してください。 |
| 代替キー | Dynamics 365 Customer Engagement (on-premises) のエンタープライズ展開では、外部エンタープライズ システムからのデータを、ユーザーに提供できるように、Dynamics 365 Customer Engagement (on-premises) にロードすることが一般的です。 これら外部システムは、システムの同期に必要な GUID と呼ばれる、Dynamics 365 Customer Engagement (on-premises) レコード ID を格納するように拡張することができないことがよくあります。 一般的なソリューションは、外部システムに関連レコードの ID を格納するために使用できる Dynamics 365 Customer Engagement (on-premises) に、ユーザー定義のエンティティを追加することです。 Dynamics 365 Customer Engagement (on-premises) でレコードを更新し、Dynamics 365 Customer Engagement (on-premises) で関連レコードへの参照を割り当てるデータ ロード プロセスを作成するときは、まず追加の Dynamics 365 Customer Engagement (on-premises) の Web サービスを呼び出し、この外部の識別子に基づいて Dynamics 365 Customer Engagement (on-premises) の目標レコードを取得する必要があります。 この検索は、適切なインデックスがユーザー定義属性の適切な場所にない場合は遅くなる可能性があり、Dynamics 365 Customer Engagement (on-premises) のシナリオでは、これらの検索のそれぞれで、コストのかかるインターネット上のラウンド トリップが必要になります。 これらの余分なラウンド トリップは、Dynamics 365 Customer Engagement (on-premises) の各レコードの更新に必要な時間の桁数に応じて増大し、総合的な処理能力を劇的に低下させる一可能性があります。 現在は、Web サービスの操作は、GUID の代わりに、1 つまたは複数の代替キーを使用して、Dynamics 365 Customer Engagement (on-premises) のレコードを対象にすることができます。 また、関連レコードへのエンティティ参照を、1 つまたは複数の代替キーを使用して指定できます。 代替キーはインデックス付きなので、ユーザー定義属性を識別子として追加することと比較して、検索操作のパフォーマンスの向上が見られます。 何か問題がある場合は、システムはエラーをスローして、すべての変更をロールバックします。 詳細については、エンティティの代替キーの定義を参照してください。 |
| 変更の追跡 | 組織が Dynamics 365 Customer Engagement (on-premises)データを外部ストレージに維持する必要があるときは、データの最初の抽出後、または最後の同期後に変更されたデータを検出することによって、効率の良い方法でデータの同期を維持する方法を現在提供しています。 エンティティの変更が取得には、RetrieveEntityChangesRequest メッセージを使用します。 詳細については、変更の追跡を使用してデータを外部システムに同期 を参照してください。 |
| upsert | 外部システムから Dynamics 365 Customer Engagement (on-premises) にデータを読み込むとき、レコードが Dynamics 365 Customer Engagement (on-premises) に既に存在しているか、そして更新する必要があるかどうか、または新しいレコードを作成する必要があるかどうかが分からない場合があります。 新しい UpsertRequest メッセージを使用して、1 回の API 呼び出しで、存在する場合はレコードを更新し、存在しない場合は新しいレコードを作成します。 詳細については、Upsert を使用して、Dynamics 365 Customer Engagement (on-premises) を外部データで更新 を参照してください。 |
次の表は、これらの新しい機能を使用した場合と使用しない場合の同期の複雑度の比較です。
| 前 | 内容 |
|---|---|
 |
各レコードに対して以下を実行します。 1. Dynamics 365 Customer Engagement (on-premises) をクエリして、取引先企業が存在するかどうかを確認します。 存在する場合は、その取引先企業 ID (たとえば、ABC123) を取得します 2. 取引先担当者をクエリして、取引先担当者が存在することを確認します。 存在する場合は、取引先担当者の電子メール ID (例えば contact@company.com) を取得します。 3. 地域 ID (たとえば、NW) を取得または設定するためにクエリします。 4. 所有者を設定するためのユーザー ID を取得するためのクエリ (例えば user@mycompany.com) 5. 取引先企業を更新します。 6. SetState API を呼び出して、取引先企業の状態を設定します。7. Assign API を呼び出して、所有者を割り当てます。 |
現在は、この新機能により、前述と同じ操作を実行するのに必要なサーバーへの呼び出しは 1 回だけです。
| 後 | 内容 |
|---|---|
 |
1 回の呼び出しだけで、一意の ID ABC123 を持つ取引先企業の存在を検証するには、取引先責任者を contact@company.com に、地域を NW に、所有者を user@mycompany.com に、状態をアクティブに設定します。 |
エンティティの代替キーの定義
すべての Dynamics 365 Customer Engagement (on-premises) レコードには、GUID として定義されている一意の識別子を持っています。 これは、各エンティティの主キーです。 外部データ ストアと統合する必要がある場合は、Dynamics 365 Customer Engagement (on-premises) 内の一意の識別子への参照を格納するために、外部データベース テーブルに列を追加できる場合があります。 これにより、Dynamics 365 Customer Engagement (on-premises) レコードにリンクするためのローカル参照を設けることができます。 ただし、外部データベースを変更できないことがあります。 ユーザーは、現在は、代替キーを使用して、外部のデータ ストアが使用する一意の識別子 (または一意の列の組み合わせ) に一致するように、Dynamics 365 Customer Engagement (on-premises) エンティティの属性を定義できます。 主キーの代わりにこの代替キーを使用して、Dynamics 365 Customer Engagement (on-premises) 内のレコードを一意に識別できます。 どの属性が、レコードごとの一意の ID を表すかを定義できるようにする必要があります。 エンティティに対して一意となる属性を識別したら、それらの属性をカスタマイズ ユーザー インターフェイス (UI) によって、またはコードで、代替キーとして宣言できます。 このトピックでは、データ モデルでの代替キーの定義について説明します。 詳細については、Dataverse ドキュメントにある エンティティの代替キーの定義 を参照してください。
代替キーの使用
代替キーを使用して、Entity および EntityReference クラスのインスタンスを作成できます。 このトピックでは、使用パターンと、代替キー使用時にスローされる可能性のある例外について説明します。 エンティティに対して代替キーを定義する方法については、「エンティティの代替キーの定義」を参照してください。 詳細については、Dataverse ドキュメントにある 代替キーの使用 を参照してください。
変更の追跡を使用してデータを外部システムに同期
Dynamics 365 Customer Engagement (on-premises) の新しい変更追跡機能は、データが最初に抽出されてから、または最後に同期化されてからどのデータが変更されたかを検出することによって、データの同期を効率の良い方法で維持する方法を提供します。 以前は、この新しい機能がなかったので、Dynamics 365 Customer Engagement (on-premises) のどのレコードが変更されたかを決定する、信頼性のある効率の良いメカニズムを構築することは困難でした。 このトピックでは、エンティティの変更を取得する方法について説明します。 詳細については、Dataverse ドキュメントにある 変更の追跡を使用してデータを外部システムに同期 を参照してください。
upsert の使用
UpsertRequest メッセージを使用して、データ統合のシナリオに含まれる複雑さを減らすことができます。 データを外部システムから Dynamics 365 Customer Engagement (on-premises) に読み込むとき、大量データの統合の場合など、レコードが Dynamics 365 Customer Engagement (on-premises) に既に存在するかが分からない場合があります。 このような場合、UpdateRequest または CreateRequest 操作を呼び出す必要があるかどうかが分かりません。 この結果、適切な操作を実行する前に、そのレコードが存在するかどうかを決定するために、最初にそのレコードをクエリすることになります。 現在は、新しい UpsertRequest (更新または送信) メッセージを使用して、この複雑さを減らしてデータを Customer Engagement により効率よく読み込むことができます。 詳細については、upsert を使用してレコードを更新 (Dataverse ドキュメント内) を参照してください。
サンプル
サンプル: Upsert を使用してレコードを挿入または更新
サンプル: 変更の追跡を使用してデータを外部システムに同期
関連セクション
[更新] を使用して特化された操作を実行する
Dynamics 365 Customer Engagement (on-premises) 用カスタマイズの開発者ガイド
Hinweis
ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)
この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。
フィードバック
フィードバックの送信と表示