メインコンテンツまでスキップ

Microsoft Dynamics 365 コネクタに関するよくある質問

備考

プレビュー

この機能は パブリック プレビュー段階です。

このページではLakeFlow Connect用のMicrosoft Dynamics 365 コネクタに関するよく寄せられる質問に回答します。

マネージド インジェストに関する一般的な質問については、 「マネージド コネクタの FAQ」を参照してください。

コネクタ固有のFAQ

どのような Dynamics 365 アプリケーションがサポートされていますか?

Dynamics 365 コネクタは以下をサポートします。

データバース ネイティブ アプリケーション (直接アクセス、仮想エンティティや直接テーブルは不要)。例:

  • Dynamics 365 セールス
  • Dynamics 365 顧客サービス
  • Dynamics 365 マーケティング
  • Dynamics 365 フィールドサービス

非データバース ネイティブ アプリケーション (仮想エンティティまたは直接テーブルのいずれかが必要)。例:

  • Dynamics 365 財務および運用 (F&O)

セットアップの詳細については、 「 Microsoft Dynamics 365 取り込み用のデータ ソースの構成」を参照してください。

コネクタはどのようにして D365 データにアクセスしますか?

Dynamics 365 コネクタは、Azure Synapse Link for Dataverse を仲介として使用します。

  1. Azure Synapse Link は、D365 データを CSV 形式で ADLS Gen2 に継続的にエクスポートします。
  2. Synapse Link は、変更を追跡するためにVersionNumberタイムスタンプ付きの変更ログを維持します。
  3. Databricks は、Microsoft Entra ID 認証を使用して ADLS Gen2 からエクスポートされたファイルを読み取ります。
  4. コネクタは変更ログを処理して増分取り込みを実行します。

このアーキテクチャを使用すると、D365 への OData ベースの API 呼び出しを行わずに D365 データを取り込むことができるため、D365 環境の負荷が軽減されます。

Dataverse ネイティブ アプリと非 Dataverse ネイティブ アプリの違いは何ですか?

Dataverse ネイティブ アプリは、 データを Dataverse テーブルに直接保存します。コネクタは、Azure Synapse Link を構成するとすぐにこれらのテーブルにアクセスできます。

非 Dataverse ネイティブ アプリ (F&O など) は、データを Dataverse ではなく独自のデータベースに保存します。これらのアプリケーションからデータを取り込むには、仮想エンティティまたは直接テーブルのいずれかを使用できます。

定義:

  • 仮想テーブル (またはエンティティ) は、Dataverse 内で通常のテーブルのように表示され、動作しますが、それ自体にはデータは保存されません。代わりに、外部データソース (F&O など) から直接、オンデマンドでデータを取得します。 つまり、データは Dataverse データベース内で具体化されず、ユーザーはデータを複製したり保存したりせずにデータを操作できます。
  • 直接テーブルは、Dataverse 外部 (たとえば、 Azure Synapse Link 経由のAzureデータレイク ストレージ) にエクスポートされ、具体化されたアプリケーション データの物理コピーです。 データはソース システム (F&O など) から複製され、ソース スキーマに厳密に一致する生のトランザクション テーブルとして保存されます。データは永続化されるため、ソース システムにクエリを実行せずに、スケーラブルな分析と履歴分析をサポートします。

使用方法(F&O を例に挙げます):

  • 仮想エンティティを使用する場合、データは F&O 仮想エンティティ ソリューションを通じて Dataverse に公開されます。これらの仮想エンティティは、Dataverse ではリードスルー テーブル (mserp_ など) として表示され、Azure Synapse Link を使用して ADLS にエクスポートできます。そこから、 LakeFlow Connectパイプラインはエクスポートされたフォルダーをターゲット テーブルに取り込みます。 このオプションは通常、F&O エンティティが複数の基礎テーブルからのデータを非正規化ビューに集約することが多いため、下流の変換作業が少なく、ビジネスフレンドリーな事前結合ビューを提供します。
  • 直接テーブルを使用する場合、Azure Synapse Link を使用すると、生の F&O テーブルを直接エクスポートできます。これらのテーブルは、Synapse Link のセットアップ中に別のセクションで使用でき、生のトランザクション データとして ADLS に書き込まれます。

どちらをいつ使用するかを決める際の考慮事項:

どちらのオプションが最適かを判断するには、次の点を検討します。

  • データの粒度と制御: 直接テーブルは、データ モデリングを徹底的に制御するための、最も粒度の細かい生のトランザクション データを提供します。仮想テーブルは、コンピュート フィールドを含む可能性のある、よりフラット化された集約されたビューを提供します。
  • データの準備と変換の取り組み: 関連して、仮想テーブルは事前に結合されたビジネス対応データを提供することが多く、これにより Databricks でのダウンストリーム変換を最小限に抑えることができます。ダイレクト テーブルでは、複雑な結合や変換のために追加のデータ エンジニアリング作業が必要になることがよくあります。
  • パフォーマンス: どちらのオプションもかなり効率的ですが、フローのさまざまな部分でオーバーヘッドが発生します。仮想テーブルではソース側にオーバーヘッドが発生する可能性がありますが (その大きさはエンティティの複雑さに応じて異なります)、ダイレクト テーブルではビジネス ロジックのためにさらに下流のコンピュートが必要になる場合があります。

Azure Synapse Link for Dataverse が必要な理由:

  • 変更の追跡 : Synapse Link は、増分取り込みを可能にするVersionNumberフィールドを含む変更ログを提供します。
  • パフォーマンス : ADLS Gen2 からエクスポートされたファイルを読み取る方が、D365 への OData ベースの API 呼び出しを行うよりも効率的です。

増分取り込みはどのように機能しますか?

Dynamics 365 コネクタは、Azure Synapse Link の変更ログのVersionNumberフィールドを使用して変更を追跡します。

  1. Synapse Link は、ADLS Gen2 のタイムスタンプ付きフォルダーにデータをエクスポートします。
  2. 各エクスポートには、レコードが変更された日時を示すVersionNumber値を含む変更ログ ファイルが含まれます。
  3. コネクタは、タイムスタンプに基づいて時系列順にフォルダーを処理します。
  4. コネクタはフォルダーごとに変更ログを読み取り、変更 (挿入、更新、削除) を適用します。
  5. コネクタは最後に処理されたVersionNumberカーソルとして保存します。
  6. 後続のパイプライン実行では、最後のカーソルの後に作成された新しいフォルダーのみが処理されます。

このアプローチにより、コネクタは変更されていないデータを再処理することなく、すべての変更をキャプチャできるようになります。

コネクタが更新と削除を処理する方法については、 SCDタイプ」を参照してください。

Azure Synapse Link がデータのエクスポートを停止した場合:

  • コネクタは実行を継続しますが、処理する新しいフォルダーが見つかりません。
  • Synapse Link が再開されるまで、新しい変更は取り込まれません。
  • Synapse Link が再開すると、見逃されたすべての変更が新しいフォルダーにエクスポートされます。
  • コネクタは、次のパイプライン実行時にこれらのフォルダーを処理します。
重要

Synapse Link が長期間停止した場合、特に Synapse Link の保持期間が終了した場合には、データの一貫性を確保するために完全な更新を実行する必要がある場合があります。

継続的な操作を確実にするために、Power Apps メーカー ポータルで Synapse Link 接続を監視します。

D365 から添付ファイルを取り込むことはできますか?

Dynamics 365 コネクタは添付ファイルのメタデータ (ファイル名、サイズ、MIME タイプ、レコードの関連付け) を取り込みますが、添付ファイルの内容はダウンロードしません。これは、Synapse Link がバイナリ ファイルの内容ではなくテーブル データをエクスポートするためです。

添付ファイルにアクセスするには:

  1. 添付ファイルのメタデータ テーブル (例: annotationattachment ) を取り込みます。
  2. メタデータを使用して必要なファイルを識別します。
  3. Dynamics 365 Web API または Power Automate を使用して、D365 から直接ファイルをダウンロードします。
  4. ファイルを優先する保存場所 (ADLS Gen2 ボリュームなど) に保存します。

異なる D365 アプリごとに個別の接続が必要ですか?

いいえ、同じ Dataverse 環境内のすべての D365 アプリケーションに対して単一のUnity Catalog接続を使用できます。 接続は、個々の D365 アプリケーションではなく、ADLS Gen2 ストレージ アカウントに対して認証されます。

ただし、データバース環境ごとに個別のパイプラインが必要です ( source_schema )。例えば:

  • 単一接続 : ADLS Gen2 コンテナーに対して認証します。
  • 複数のパイプライン : Dataverse 環境ごとに 1 つのパイプライン。それぞれが異なるsource_schema値を指定します。

このアプローチにより、認証管理が簡素化されるとともに、複数の環境からの取り込みが可能になります。

D365 ではどのような権限が必要ですか?

Dynamics 365 コネクタをセットアップするには、次のものが必要です。

Dynamics 365 と Dataverse の場合 :

  • Azure Synapse Link を構成するには、システム管理者ロールまたは同等の権限が必要です。
  • 取り込むすべてのテーブルに対する読み取り権限。
  • 仮想エンティティまたは直接テーブルを構成するための権限 (F&O などのアプリケーションの場合)。

Azureの場合 :

  • ADLS Gen2 ストレージ アカウントとコンテナーを作成および構成するためのアクセス許可。
  • Microsoft Entra ID アプリケーションを作成および構成するための権限。
  • Entra ID アプリケーションにストレージ BLOB データ共同作成者ロールを割り当てるための権限。

Databricksの場合 :

  • Unity Catalog接続を作成するためのワークスペース管理者またはメタストア管理者の権限。
  • ターゲット カタログとスキーマに対する CREATE 権限。

詳細な権限要件については、 「 Microsoft Dynamics 365 取り込み用のデータ ソースの構成」を参照してください。

複数の Dataverse 環境からデータを取り込むことはできますか?

はい、単一の接続を使用して複数の Dataverse 環境から取り込むことができます。環境ごとに個別のパイプラインを作成します。

Python
# Pipeline for production environment
prod_pipeline = w.pipelines.create(
name="d365_prod_ingestion",
ingestion_definition=IngestionPipelineDefinition(
channel="PREVIEW",
connection_name="d365_connection", # Same connection
source_schema="https://prod.crm.dynamics.com", # Production
source_table=["account", "contact"],
destination_catalog="main",
destination_schema="d365_prod",
scd_type="SCD_TYPE_2"
)
)

# Pipeline for test environment
test_pipeline = w.pipelines.create(
name="d365_test_ingestion",
ingestion_definition=IngestionPipelineDefinition(
channel="PREVIEW",
connection_name="d365_connection", # Same connection
source_schema="https://test.crm.dynamics.com", # Test
source_table=["account", "contact"],
destination_catalog="main",
destination_schema="d365_test",
scd_type="SCD_TYPE_2"
)
)

すべての環境を同じ ADLS Gen2 ストレージ アカウントとコンテナーにエクスポートするか、ストレージの場所ごとに個別の接続を作成する必要があります。

摂取コストを削減するにはどうすればいいでしょうか?

コストを最適化するには:

  • 特定の列を選択 :列選択を使用して、必要な列のみを取り込みましょう。
  • テーブルをフィルター : パイプラインに必要なテーブルのみを含めます。
  • 履歴追跡を最適化 : 履歴追跡が不要な場合は、履歴追跡をオフにします (たとえば、SCD タイプ 1) (ストレージが削減されます)。

詳細な考慮事項については、 「Microsoft Dynamics 365 インジェスト コネクタの制限」を参照してください。

取り込み中にデータを変換できますか?

LakeFlow Connect変換せずに D365 から生データを取り込みます。 データを変換するには:

  1. 生データをランディング スキーマ (例: d365_landing ) に取り込みます。
  2. 変換用に下流のLakeFlow Spark宣言型パイプライン パイプラインを作成します。
  3. SQL または Python を使用して、データをキュレーションされたスキーマに変換します。

この関心の分離により、下流での柔軟な変換を可能にしながら、生データが保持されます。

D365 でスキーマの変更を処理するにはどうすればよいですか?

現時点では、すべてのスキーマ変更にはテーブルの完全な更新が必要です。D365 スキーマの変更を監視し、それに応じて完全な更新を計画します。

いいえ。