次の方法で共有

データ エクスポート サービス

  • [アーティクル]

重要

このコンテンツはアーカイブされており、更新されていません。 最新のドキュメントについては、Microsoft Dynamics 365 製品のドキュメントを参照してください。 最新のリリース計画については、Dynamics 365 および Microsoft Power Platform のリリース計画を参照してください。

注意

リリース ノートで説明されている機能は、まだリリースされていない場合があります。 この機能のリリース予定については、「Common Data Model とデータ統合の新機能と予定されている機能」をご覧ください。 提供タイムラインおよび予定されている機能は、変更される可能性、または出荷されない可能性があります (Microsoft ポリシーを参照)。

Microsoft Dynamics365 のデータ エクスポート サービス (DES) は Microsoft AppSource 提供の無料アドオンであり、Microsoft Dynamics 365 (online) のデータを、顧客が所有する Microsoft Azure サブスクリプションの Microsoft Azure SQL Database に同期します。

サポートされているターゲットの同期先は、Microsoft Azure 仮想マシン上の Microsoft Azure SQL Database と Microsoft SQL Server です。 データ エクスポート サービスは、完全な書き込みを行った後、Microsoft Dynamics 365 (online) システムでの発生に合わせてデルタ変更を継続的に行います。 これにより、Dynamics 365 データに関するいくつかの分析およびレポート作成シナリオが可能になります。

2019 年 4 月リリースでは、お客様からのフィードバックに基づき、データ エクスポート サービスの信頼性とパフォーマンスの向上に関して以下の作業が行われています。

収束の状態を検証および通知するためにレコードの数と傾向を表示する

Dynamics 365 for Sales (CRM) および Azure SQL Database からのレコードの数と傾向を表示することは、変更が正常に書き込まれたことを確認するために、同期元と同期先両方のレコード数を見たいというお客様からの最大の要望です。 さらに、この機能では、1 時間ごとに Dynamics 365 for Sales (CRM) と Azure SQL Database 両方のエンティティ別のレコード数を比較することによって、レコード数の傾向が提供されます。 また、Dynamics 365 for Sales (CRM) と Azure SQL Database の両方で、最新のバージョンと、エンティティごとのレコードのメタデータのバージョンも比較されます。

これらの機能強化により、お客様はレコードの収束 (または発散) を予測し、必要に応じて適切な措置を講じることができます。 また、データが同期していないためにエンティティ レコードに失敗通知がある場合にユーザーに知らせるアラート メカニズムを追加しています。

データの前のメタデータを優先することで書き込みの失敗を最小限に抑える

お客様の環境でよく見られる失敗の 1 つは、データがメタデータよりも前に表示され、書き込みが失敗することです。 この機能を利用して、データ メッセージよりメタデータ メッセージを優先させるためのキューを実装し、メタデータ メッセージの処理が失敗した場合にデータ メッセージの処理を一時停止するようにしました。 また、データ メッセージの "受信メタデータ バージョン" 部分を検証し、それが SQL のものと異なる場合は、データ メッセージを処理せずにキューに入れます。

変更追跡でサポートされていないエンティティを表示する

これまでは、変更追跡が有効になっていないエンティティを識別する簡単な方法がありませんでした。 それらのエンティティはサポートされませんでした。 今回の変更により、すべてのエンティティがユーザー インターフェイスに表示され、変更追跡の対象としてサポートされていないエンティティはグレー表示されます。 これにより、いっそう直感的なエクスペリエンスが提供されます。

待機時間を短縮してパフォーマンスを向上させる

データ エクスポート サービスでは、プロファイルごとに 1 つの削除ログが保持されます。 このログを使用して、削除とそのタイムスタンプが追跡されます。 お客様との話し合いによれば、特に多数のエンティティを含む大規模なプロファイルでは、単一の削除ログがパフォーマンスのボトルネックの原因になります。 この変更では、エンティティごとに削除ログを分割して、エンティティごとに 1 つ作成し、それによって削除処理の待機時間を大幅に短縮しました。 削除ログ テーブルにインデックスを追加することで、クエリのパフォーマンスがさらに向上します。