メインコンテンツまでスキップ
に最終更新

Microsoft Dynamics 365 の取り込みに関するトラブルシューティング

このページでは、Lakeflow Connect の Microsoft Dynamics 365 コネクタに関する一般的な問題のトラブルシューティングガイダンスを提供します。すべてのマネージド取り込みパイプラインに適用される一般的なトラブルシューティングガイダンスについては、マネージド取り込みパイプラインのトラブルシューティングを参照してください。

コネクタは Azure Synapse Link が ADLS Gen2 にエクスポートした内容を読み取るため、ほとんどの取り込みエラーはパイプラインではなくエクスポートに起因します。パイプライン自体を調査する前に、Synapse Link が実行されており、ファイルが書き込まれていることを確認してください。

症状 : Synapse Link の構成後に ADLS Gen2 コンテナにフォルダが表示されない、フォルダの Timestamp が更新されなくなる、またはパイプラインのランが「No data found」エラーで失敗する。

原因 ：Synapse Link接続が停止されている、Azureストレージアカウントの権限が正しくない、選択したテーブルがエクスポート用に構成されていない、またはエクスポート中にSynapse Linkでエラーが発生しました。

解決方法 :

  1. Synapse Link のステータスを確認してください：

    • Power Appsにサインインします。
    • 環境内の Azure Synapse Link に移動します。
    • 接続が「アクティブ」ステータスになっていることを確認します。
    • 一時停止している場合は、 再開 をクリックしてエクスポートを再開します。

  2. ストレージ権限を確認します。

    • Azure ポータルで、ストレージ アカウントに移動します。
    • アクセス制御(IAM) をクリックします。
    • Synapse Link マネージドIDに ストレージ BLOB データ共同作成者 ロールがあることを確認します。
    • ロールが存在しない場合は、ロールの割り当てを追加します。

  3. テーブル構成を確認してください：

    • Power Apps で、Synapse Link 接続を選択します。
    • 選択したテーブルのリストを確認し、取り込むテーブルが含まれていることを検証します。
    • 不足しているテーブルを追加し、初期エクスポートが完了するまで 5～15 分待ちます。

  4. Synapse Link の Logs を確認します：

    • Power Apps で、Synapse Link 接続を選択します。
    • Logs または 履歴 をクリックします。
    • エクスポートの失敗を示すエラーメッセージを確認し、特定のエラー（ストレージクォータやアクセス権限など）に対処してください。

Synapse Linkはアクティブですが、ファイルが表示されていません​

症状 ：Synapse Link は「Active」ステータスを示していますが、ADLS Gen2 コンテナーにファイルが表示されない、またはパイプラインのランが「No data found」エラーで失敗します。

原因 : Synapse Link が初期エクスポートを完了していない、Synapse Link プロファイルが停止しているかエクスポートエラーが発生した、またはストレージアカウントの権限が正しくありません。

解決方法 :

このコネクタは CSV と Parquet の両方のエクスポートをサポートしており、Synapse Link が書き込む形式を自動的に検出するため、ファイルが見つからない場合でもエクスポート形式を再構成する必要はありません。Parquet の取り込みは ベータ版 です。トラブルシューティングを行うには、Synapse Link が実際にデータをエクスポートしていることを確認してください：

  1. ADLS Gen2 にファイルが存在することを確認します：

    • Azure ポータルで、ADLS Gen2 ストレージ アカウントとコンテナーに移動します。
    • テーブルフォルダーを開き、データファイルが含まれていることを確認してください。CSVエクスポートの場合、ファイルには.csv拡張子が付きます。Parquetエクスポートの場合、Synapse Linkは各テーブルを<profileRoot>/deltalake/<tableName>/配下にParquet形式のDeltaテーブルとして書き込みます。
    • フォルダが空の場合、初期エクスポートがまだ進行中である可能性があります。

  2. Synapse Link のステータスを確認してください：

    • Power Apps で Synapse Link プロファイルを開き、ステータスが「Active」と表示されていることを確認します。
    • 一時停止または停止している場合は、 再開 をクリックしてエクスポートを再起動します。
    • Synapse Link の Logs または履歴でエクスポートエラーを確認し、発生しているエラー（ストレージクォータや権限など）に対処してください。

  3. エクスポートが完了するまで待ちます：

    • 大規模なデータセットの場合、最初の Synapse Link エクスポートに数時間かかることがあります。
    • コンテナーにファイルが表示されたら、パイプラインのランを再試行してください。

エラー： FILE_PATH_DOES_NOT_EXIST​

症状 : パイプラインのランが FILE_PATH_DOES_NOT_EXIST エラーで失敗する、コネクタが ADLS Gen2 内の予期されたファイルを見つけられない、またはエラーがフォルダやファイルパスの欠落を示している。

原因 : Synapse Linkの構成時に Enable Incremental Update Folder Structure （増分更新フォルダー構造を有効にする）オプションがオンになっていなかったため、コネクタが想定した場所でファイルを見つけられません。

解決方法 :

  1. 増分更新フォルダー構造を有効にします：

    • Power Apps で、Synapse Link 接続を編集します。
    • 高度な設定 をクリックして、詳細な構成設定を表示します。
    • Enable Incremental Update Folder Structure （増分更新フォルダー構造を有効にする）をオンにします。
    • 設定を保存します。
    • Synapse Link がフォルダー構造を再生成するまで待機します。大規模なデータセットの場合、これには数時間かかることがあります。

  2. フォルダー構造を確認します：

    • Azure ポータルで、ADLS Gen2 ストレージ アカウントとコンテナーに移動します。
    • テーブルフォルダーにTimestamp付きのサブフォルダーが含まれていることを確認します（例：2025-12-19T10-30-00-000Z）。これらのTimestampフォルダーには、コネクタが必要とする増分更新が含まれています。

  3. パイプラインを再試行してください。コネクタは、期待される場所にあるファイルを検出できるようになりました。

Synapse Linkの変更履歴が見つかりません versionnumber​

症状 ：パイプラインのランが「versionnumber field not found」エラーで失敗する、インクリメンタルな取り込みが機能しない、またはフル更新のみが成功する。

原因 : Synapse Linkが変更ログをエクスポートするように構成されていない、テーブルの変更追跡が有効になっていない、またはSynapse Linkのバージョンが古い可能性があります。

解決方法 :

  1. 変更の追跡をオンにします：

    • Power Apps で、Synapse Link 接続を編集します。
    • Enable change tracking （変更の追跡を有効にする）が選択されていることを確認します。
    • 保存して、Synapse Link がエクスポートを再生成するまで最大 30 分待ちます。

  2. 変更ログファイルを確認してください：

    • Azureポータルで、ADLS Gen2コンテナーに移動します。
    • テーブル フォルダーを開き、 SynapseLinkサブフォルダーを見つけます。
    • 最近の変更ログファイル (CSV または JSON) を開き、versionnumber 列が含まれていることを確認します。
    • 列が見つからない場合は、Microsoft サポートに連絡して変更トラッキングを有効にしてください。

  3. Synapse Linkを更新します。Azure Synapse Link for Dataverseのバージョン1.0以降を使用していることを確認してください。古いバージョンでは versionnumber がサポートされていない可能性があります。

  4. 完全更新を実行します。変更の追跡を有効にできない場合は、完全更新モードのみを使用できます。完全更新はランのたびにすべてのデータを再読み込みするため、低速でコストが高くなります。

エラー： The selected storage account has restricted network access​

症状 ：Synapse Link のセットアップが次のエラーで失敗します：

The selected storage account has restricted network access. To proceed, please setup an enterprise policy and connect it to your Dataverse environment. Once done, please enable the 'Select Enterprise Policy with Managed Service Identity' option below.

原因 : ADLS ステージング場所がファイアウォールで保護されており、Dataverse がアクセスできません。

解決策 ：マネージドID（以前のマネージドサービスID）を設定して、データにアクセスします。Microsoftドキュメントで「AzureデータレイクストレージでAzureのマネージドIDを使用する」を参照してください。

Microsoft Entra ID 認証が失敗します​

症状 ：パイプラインの作成が「Authentication failed」エラーで失敗する、Catalog Explorer での接続テストが失敗する、またはパイプラインのランが「401 Unauthorized」エラーで失敗する。

原因 : テナント ID、クライアント ID、またはクライアントシークレットが正しくない、クライアントシークレットの有効期限が切れている、アプリケーションに必要な権限がない、またはスコープが正しくありません。

解決方法 :

  1. 認証パラメーターを確認してください：

    • Azureポータルで、 Microsoft Entra ID > アプリの登録 に移動します。
    • アプリケーションを見つけ、 アプリケーション (クライアント) ID と ディレクトリ (テナント) ID が接続構成と一致していることを確認します。
    • 正しい値をコピーし、必要に応じて接続を更新します。

  2. クライアントのシークレットの有効期限を確認します：

    • アプリケーションで、 証明書とシークレット をクリックします。
    • クライアントシークレットの有効期限が切れていないことを確認してください。
    • 期限切れの場合は、 + 新しいクライアント シークレット をクリックし、説明と有効期限を入力して、シークレット値をコピーし、新しいシークレットで接続を更新します。

  3. スコープを確認してください。接続には https://storage.azure.com/.default スコープを使用する必要があります。これにより、Microsoft Dynamics 365に直接ではなく、Azure Storageへのアクセス権が付与されます。

  4. 接続をテストしてください：

    • カタログエクスプローラーで、接続先に移動します。
    • [ テスト接続 ] をクリックして、認証を確認します。
    • テストが失敗した場合は、具体的なガイダンスについてはエラー メッセージを確認してください。

認証が失敗し続ける場合は、Databricks ノートブックで以下のスクリプトを使用して、どこで中断されているかを特定してください。

スクリプトのデバッグ

クライアント ID とクライアント シークレットが正しく機能していることを確認します。

Python
%pip install azure-storage-blob==12.22.0 azure-identity==1.17.1 azure-storage-file-datalake==12.16.0
%restart_python

# Required libraries
from azure.identity import ClientSecretCredential
from azure.storage.blob import BlobServiceClient

# --- Your Azure Credentials and Storage Details ---
# Replace the placeholder values with your actual information

# Entra ID (Azure Active Directory) details
tenant_id = "<tenant-id>"
client_id = "<client-id>"
client_secret = "<client-secret>"

# Azure Storage details
storage_account_name = "<storage-account>"
container_name = "<container-name>"

# --- Script to List Folders ---

# Construct the Blob Storage URL
storage_account_url = f"https://{storage_account_name}.blob.core.windows.net"

# 1. Authenticate using the service principal
# The ClientSecretCredential object will handle the OAuth 2.0 flow
try:
    credential = ClientSecretCredential(tenant_id, client_id, client_secret)
except Exception as e:
    print(f"Error creating credential: {e}")
    # You may want to stop execution if credentials are not valid
    dbutils.notebook.exit("Failed to create credentials")

# 2. Create a BlobServiceClient
# This client is the main entry point for interacting with the Blob service
try:
    blob_service_client = BlobServiceClient(account_url=storage_account_url, credential=credential)
except Exception as e:
    print(f"Error creating BlobServiceClient: {e}")
    dbutils.notebook.exit("Failed to create BlobServiceClient")

# 3. Get a client for the specific container
try:
    container_client = blob_service_client.get_container_client(container_name)
except Exception as e:
    print(f"Error getting container client for '{container_name}': {e}")
    dbutils.notebook.exit("Failed to get container client")

# 4. List the "folders" in the container
# Folders in Blob Storage are virtual and are represented by prefixes in blob names.
# This code iterates through the blobs and extracts the top-level directory names.
try:
    blob_list = container_client.list_blobs()
    folder_list = set()

    for blob in blob_list:
        if "/" in blob.name:
            folder_name = blob.name.split('/')[0]
            folder_list.add(folder_name)

    # Print the list of unique folder names
    if folder_list:
        print(f"Folders found in container '{container_name}':")
        for folder in sorted(list(folder_list)):
            print(folder)
    else:
        print(f"No folders found in container '{container_name}'.")

except Exception as e:
    print(f"An error occurred while listing blobs: {e}")

Unity Catalog接続がアクセス許可を送信できることを確認します。

Python
import requests
import json
import os

# --- Databricks Notebook Context and API Token Retrieval ---
# This section securely retrieves the necessary API token from your Databricks environment
# to interact with Unity Catalog.
notebook_context = dbutils.notebook.entry_point.getDbutils().notebook().getContext()
WORKSPACE_URL = notebook_context.apiUrl().get()
API_TOKEN = notebook_context.apiToken().get()

# --- Unity Catalog Connection Configuration ---
# IMPORTANT: Replace with the name of your Unity Catalog external connection to ADLS Gen2.
# This connection must be configured in Unity Catalog and granted necessary permissions
# to access your Azure Data Lake Storage Gen2 account.
CONNECTION_NAME = "<uc-connection-name>"

def get_uc_connection_access_token(connection_name: str, api_token: str) -> str:
    """
    Retrieves the access token for a Unity Catalog external connection to ADLS Gen2.
    """
    url = f"{WORKSPACE_URL}/api/2.1/unity-catalog/foreign-credentials"
    body = '{{"securables": [{{"type": "CONNECTION", "full_name": "{}"}}]}}'.format(
        connection_name
    )
    headers = {
        "Authorization": "Bearer {}".format(api_token),
        "Content-Type": "application/json",
    }
    response = requests.post(url=url, headers=headers, data=body)
    response.raise_for_status()  # Raise an exception for HTTP errors (e.g., 401, 403, 404)

    print(response.json())

    credentials = response.json()["securable_to_credentials"][0]["credentials"]["foreign_credential"]["options"]["options"]
    access_token = credentials["access_token"]
    return access_token

print(get_uc_connection_access_token(CONNECTION_NAME, API_TOKEN))

Unity Catalog接続を使用してコンテナの内容を一覧表示できることを確認してください：

Python
import requests
import json
import os
from datetime import datetime, timedelta
from azure.core.credentials import AccessToken, TokenCredential
from azure.storage.filedatalake import DataLakeServiceClient

notebook_context = dbutils.notebook.entry_point.getDbutils().notebook().getContext()
WORKSPACE_URL = notebook_context.apiUrl().get()
API_TOKEN = notebook_context.apiToken().get()

CONNECTION_NAME = "<uc-connection-name>"
storage_account_name = "<storage-account-name>"
container_name = "<container-name>"

# --- Custom Credential Object for Azure SDK ---
class StaticTokenCredential(TokenCredential):
    """
    A simple credential class to wrap an existing access token for Azure SDKs.
    The expiration is set arbitrarily for the SDK's internal logic;
    your token's real expiry is governed by its issuer.
    """
    def __init__(self, token: str):
        self._token = AccessToken(token, expires_on=(datetime.now() + timedelta(hours=1)).timestamp())

    def get_token(self, *scopes, **kwargs) -> AccessToken:
        return self._token

# ==================== Main Logic to List Top-Level Folders ====================
try:
    # --- Input Validation ---
    if CONNECTION_NAME == "<uc-connection-name>":
        raise ValueError("Please update 'CONNECTION_NAME' with the name of your Unity Catalog connection.")
    if storage_account_name == "<storage-account-name>":
        raise ValueError("Please update 'storage_account_name' with your Azure Storage Account Name.")
    if container_name == "<container-name>":
        raise ValueError("Please update 'container_name' with your ADLS Gen2 Container Name.")

    print(f"Retrieving access token from Unity Catalog connection: '{CONNECTION_NAME}'...")
    access_token_string = get_uc_connection_access_token(CONNECTION_NAME, API_TOKEN)
    print("Access token retrieved successfully.")

    # 1. Initialize the DataLakeServiceClient using the retrieved token
    account_url = f"https://{storage_account_name}.dfs.core.windows.net"
    credential = StaticTokenCredential(access_token_string)
    datalake_service_client = DataLakeServiceClient(account_url=account_url, credential=credential)
    file_system_client = datalake_service_client.get_file_system_client(file_system=container_name)

    print(f"\nSuccessfully connected to ADLS Gen2 container: '{container_name}' in storage account: '{storage_account_name}'.")

    # 2. Get and print only the top-level directories
    print("\n--- Listing Top-Level Folders ---")

    all_paths = file_system_client.get_paths(path="/")

    for path in all_paths:
        print(path.name)
except Exception as e:
    print(f"An unexpected error occurred during execution.")
    print(f"Error details: {e}")

ADLS Gen2ストレージにアクセスできません​

症状 ：パイプラインの実行が "403 Forbidden" または "Access denied" エラーで失敗する、接続テストは成功するがパイプラインが失敗する、あるいは一部のテーブルは機能するが他が失敗する。

原因 : Microsoft Entra ID アプリケーションに ストレージ BLOB データ共同作成者 ロールがない、ロールの割り当て範囲が誤ったコンテナーまたはパスになっている、あるいはネットワーク制限やストレージアカウントのファイアウォール規則によって Databricks のアクセスがブロックされています。

解決方法 :

  1. ロールの割り当てを確認します：

    • Azure ポータルで、ストレージ アカウントに移動します。
    • アクセス制御(IAM) をクリックし、 [ロールの割り当て] をクリックします。
    • Microsoft Entra ID アプリケーションに ストレージ BLOB データ共同作成者 ロールがあることを確認します。
    • Scope （スコープ）が特定のコンテナーではなく、ストレージアカウント全体に設定されていることを確認してください。

  2. 不足しているロールを追加してください：

    • + 追加 > ロールの割り当てを追加 をクリックします。
    • Storage Blob Data Contributor を検索します。
    • 「次へ」 をクリックして、アプリケーションを追加します。
    • Review + assign をクリックし、権限の変更が反映されるまで5～10分待ちます。

  3. ネットワーク制限を確認してください:

    • ストレージ アカウントで、 [ネットワーク] をクリックします。
    • パブリックネットワークアクセス が すべてのネットワークから有効 に設定されているか、Databricks の IP 範囲が含まれていることを確認してください。
    • プライベートEndpointを使用している場合は、Databricks がそれらにルーティングできることを確認します。

  4. ファイアウォールのルールを確認してください：

    • [ Networking ] で、[ Firewall ] 設定を確認します。
    • 必要に応じて Databricks の IP アドレスを許可リストに追加するか、 [信頼されたサービス リストの Azure サービスを許可する] をオンにします。

スキーマ検出に仮想エンティティが表示されていません​

症状 : テーブルを一覧表示しても仮想エンティティが表示されない、仮想エンティティに対して「Table not found」エラーが発生してパイプラインの作成に失敗する、または Dataverse ネイティブのテーブルのみが検出可能である。

原因 : 仮想エンティティが構成または同期されていない、Synapse Link がそれらをエクスポートしていない、または仮想エンティティ名がテーブル構成と一致していません。

解決方法 :

  1. 仮想エンティティの構成を確認してください：

    • Power Platform 管理センターで、環境に移動します。
    • [設定] > [製品] > [機能] に移動します。
    • 仮想エンティティ データソース がオンになっていることを確認してください。
    • F&O仮想エンティティが構成され、アクティブになっていることを確認してください。

  2. 同期が完了するまで待機してください。仮想エンティティは通常、構成後に同期されるまで最大15分かかりますが、Dataverseに表示されるまでに最大30分かかる場合があります。その期間が経過してから、もう一度確認してください。

  3. Synapse Linkに仮想エンティティが含まれていることを確認します：

    • Power Apps で、Synapse Link 接続を編集します。
    • 選択したテーブルを確認し、仮想エンティティがエクスポートリストに含まれていることを検証します。
    • 不足している仮想エンティティを追加して保存します。

  4. 仮想エンティティ名を確認してください。仮想エンティティの論理名は、F&O テーブル名と異なる場合があります。Power Apps で [テーブル] に移動し、仮想エンティティを見つけて、正確な [論理名] をコピーし、パイプライン構成で使用します。

仮想エンティティのスキーマ変更が反映されていません​

症状 : F&O の新しい列がターゲットの Delta テーブルに表示されない、パイプラインのランは成功するがデータが不完全である、またはパイプラインの Logs にスキーマ drift の警告が表示される。

原因 ：Dataverse で仮想エンティティのメタデータが更新されていない、Synapse Link がキャッシュされたスキーマを使用している、または仮想エンティティにスキーマ進化の制限が適用されている。

解決方法 :

  1. 仮想エンティティのメタデータを更新してください：

    • Power Platform管理センターで、環境に移動します。
    • 仮想エンティティの 設定に移動します。
    • 影響を受ける仮想エンティティに対して メタデータを更新 をクリックします。
    • メタデータが同期されるまで最大30分お待ちください。

  2. Synapse Link エクスポートを再作成します：

    • Power Apps で、Synapse Link 接続を編集します。
    • 影響を受ける仮想エンティティをエクスポートリストから削除し、保存して 5 分間待機します。
    • 仮想エンティティをエクスポートリストに戻して保存し、初期エクスポートが完了するまで待機します。

  3. 完全更新を実行します。仮想エンティティのスキーマ変更には、多くの場合完全更新が必要です。パイプラインを停止し、影響を受ける仮想エンティティのターゲット Delta テーブルを削除してから、パイプラインを再起動して更新されたスキーマでテーブルを再作成します。

このコネクタは自動スキーマ進化をサポートしていないため、ソースのスキーマ変更には手動での介入が必要です。See スキーマ進化.

データ型の変更によりパイプラインが失敗する​

症状 ：パイプラインのランが「Type mismatch」または「Cannot cast」エラーで失敗する、Dynamics 365の更新や構成変更後にデータ取り込みが停止する、またはエラーメッセージが特定の列やデータ型を参照している。

原因 : Dynamics 365 で列のデータ型が変更されたため（例: 文字列から整数へ）、ターゲットの Delta テーブルスキーマが新しいデータと互換性がなくなっています。

解決方法 :

  1. 変更された列を識別します。

    • パイプラインのエラー Logs を確認して、影響を受けている列とテーブルを特定します。

    • Power Apps で、列の現在のデータ型のテーブル定義を確認します。

    • ターゲットの Delta テーブルスキーマと比較してください：

      SQL
      DESCRIBE main.d365_data.tablename;

  2. 完全更新を実行します。データ型の変更には、テーブルを再作成するための完全更新が必要です。影響を受けるパイプラインを停止し、ターゲットテーブルを削除してから、パイプラインを再起動して新しいスキーマでテーブルを再作成します：

    SQL
    DROP TABLE IF EXISTS main.d365_data.tablename;

  3. 将来の問題を防止します。スキーマを変更する前に Dynamics 365 管理者と調整し、まず非本番運用環境でスキーマの変更をテストしてから、メンテナンス期間中に完全更新をスケジュールしてください。

重要

Dynamics 365 コネクタは、データ型の変更を自動的に処理しません。テーブルスキーマを更新するには、完全更新を実行する必要があります。See スキーマ進化.

列の名前変更が正しく処理されません​

症状 : 名前が変更された列が NULL 値を持つ新しい列として表示される、古い列のデータが失われる、またはターゲットテーブルに古い列名と新しい列名の両方が存在する。

原因 : コネクターは列の名前変更を削除および追加操作として扱い、古い列名から新しい列名への自動的なデータ移行は行われません。

解決方法 :

  1. 名前の変更が行われる前に、Dynamics 365 管理者と連携して完全更新を実行してください。これにより、新しい列名の下でヒストリカルデータが保持されます。

  2. 名前の変更後、完全更新を実行して、新しい列名ですべてのデータを再読み込みします。その後、ヒストリカルデータが新しい列に格納されます。

  3. フル更新が実行できない場合は、データを手動で移行してください：

    SQL
    -- Copy data from old column to new column
    UPDATE main.d365_data.tablename
    SET new_column_name = old_column_name
    WHERE new_column_name IS NULL AND old_column_name IS NOT NULL;

    -- Drop old column after verification
    ALTER TABLE main.d365_data.tablename DROP COLUMN old_column_name;
ヒント

中断を最小限に抑えるには、スケジュールされたメンテナンス期間中に列の名前変更を計画し、直後に完全更新を実行します。

初期同期に時間がかかりすぎています​

症状 : パイプラインが完了せずに何時間も実行される、初期同期が想定より遅い、または最初のラン中にパイプラインがタイムアウトするか失敗する。

原因 : ソーステーブル内のデータ量が多い、Synapse Linkのエクスポートが遅い、ネットワーク帯域幅の制限、または単一のパイプライン内のテーブル数が多すぎる。

解決方法 :

  1. まずは少ないテーブル数から開始してください。5～10個のテーブルでパイプラインを作成し、正しく動作することを確認してから、テーブルを段階的に追加してください。
  2. Synapse Link のエクスポートを待ちます。パイプラインを実行する前に、Synapse Linkによる初期エクスポートが完了していることを確認してください。In the Azure portal, verify that all table folders contain data files.大規模なデータセットの場合、初期エクスポートに数時間かかることがあります。
  3. 作業を複数のパイプラインに分割します。100個のテーブルを持つ1つのパイプラインではなく、20個のテーブルを持つ5つのパイプラインを作成し、リソースの可用性に基づいてそれらを並列または順次実行します。これにより、個々のパイプラインの実行時間が短縮されます。
  4. Azure の帯域幅を監視します。Azure Storage のメトリクスを確認し、スロットルや帯域幅の制限がないか調べてください。スロットルが発生している場合は、ストレージアカウントのティアを上げるか、ネットワーク容量を追加してください。

増分更新が遅い​

症状 ：インクリメンタルなパイプラインのランが想定よりも時間がかかる、パイプラインのパフォーマンスが時間の経過とともに低下する、または変更量が多く遅延が発生する。

原因 : 変更ログファイルが大きい、ADLS Gen2に蓄積されたフォルダーが多すぎる、または高頻度の変更によって多数の小さなフォルダーが作成されている。

解決方法 :

  1. パイプラインのラン頻度を上げます。小規模で頻繁な変更ログファイルの方が、大規模なファイルよりも高速に処理されます。変更頻度が高い環境では、1時間ごとではなく5～15分ごとに実行してください。
  2. Synapse Linkのエクスポート頻度を確認します。Power Appsで、Synapse Linkのエクスポートスケジュールを確認します。Synapse Linkは、通常5～15分間隔で定期的にフォルダーを作成します。その頻度に合わせてパイプラインのランを調整してください。
  3. 古いエクスポートフォルダーをクリーンアップします。ストレージアカウントでライフサイクルポリシーを構成し、古いエクスポートを削除して、リカバリのニーズに応じて過去7～30日間のみを保持するようにしてください。これにより、コネクタがスキャンする必要のあるフォルダの数が削減されます。
  4. 変更量を減らしてください。高頻度で更新を生成する Dynamics 365 プロセスを確認し、可能な場合は更新をバッチ処理して個別の変更イベントを減らしてください。

取り込み後にレコードが欠落している​

症状 : ターゲットテーブルの行数がソーステーブルと一致しない、特定のレコードが欠落している、または断続的にデータが欠落している。

原因 : Synapse Link のエクスポートが不完全であるか、エラーが原因でパイプラインがフォルダーをスキップしたか、ソースシステムのフィルタリングや権限によって可視性が制限されているか、または Synapse Link が削除レコードをエクスポートしていません。

解決方法 :

  1. レコード数を比較します。Dynamics 365 の行数を確認します：

    SQL
    SELECT COUNT(*) FROM account;

    次に、ターゲット Delta テーブルの行数を確認し、不一致の大きさを特定します:

    SQL
    SELECT COUNT(*) FROM main.d365_data.account;

  2. Synapse Link のエクスポートが完了していることを確認します。ADLS Gen2 で、すべてのテーブルフォルダーに最近のTimestampフォルダーがあることを確認します。フォルダーのTimestampにギャップがないか確認します。ギャップがある場合、Synapse Link が一時的に停止した可能性があります。

  3. フィルタリングを確認します。一部のDynamics 365テーブルには、表示可能なレコードを制限するセキュリティフィルターがあります。Synapse Linkサービスアカウントにすべてのレコードを表示する権限があることを確認し、レコードの所有権またはビジネスユニットのフィルターが適用されているかどうかを確認します。

  4. 完全更新を実行します。レコードが継続的に欠落している場合は、フル更新を実行してすべてのデータを再読み込みし、カウントを再度比較してください。

  5. 削除の処理を確認してください。欠落しているレコードがDynamics 365で削除された場合は、Synapse Linkが削除をエクスポートしていることを確認してください。Power Appsで、削除追跡のSynapse Link設定を確認してください。削除がエクスポートされない場合、削除されたレコードはターゲットテーブルに反映されません。

添付ファイルのメタデータが不完全です​

症状 ：添付テーブル（例：annotation または attachment）のデータが欠落しているか不完全である、あるいはファイル名やメタデータが正しくない。

原因 : Synapse Link が添付テーブルをエクスポートしていない、添付ファイルの権限によって可視性が制限されている、または添付データが別のテーブルに保存されています。

解決方法 :

  1. 添付テーブルがエクスポートされていることを確認します。Power Apps で Synapse Link 接続を確認し、添付ファイル関連のテーブルが含まれていることを検証してから、不足しているテーブルを追加してエクスポートを待ちます：

    • annotation メモおよびファイル添付用
    • attachment Eメール添付ファイル用
    • activitymimeattachment アクティビティの添付ファイル用

  2. 添付ファイルのアクセス許可を確認してください。Synapse Link サービスアカウントが添付レコードを読み取れることを確認してください。一部の添付ファイルはセキュリティロールによって制限されている可能性があるためです。

  3. メタデータのみの制限について理解してください。コネクタは、ファイルの内容ではなく添付ファイルのメタデータを取り込みます。ファイルをdownloadするには、Dynamics 365 Web APIを別途使用してください。添付ファイルとファイルを参照してください。

  4. 正しい添付フィールドをクエリしていることを確認してください：

    SQL
    SELECT
      annotationid,
      objectid,
      subject,
      filename,
      filesize,
      mimetype,
      documentbody  -- Usually NULL; binary content not ingested
    FROM main.d365_data.annotation;

追加サポート​

上記の手順で問題が解決しない場合は、サポートに連絡する前に診断データを収集してください。

  1. 診断情報を収集します:

    • パイプライン ID と実行タイムスタンプ。
    • パイプラインのLogsからの完全なエラーメッセージ。
    • Azure Synapse Link のログとステータス。
    • エラー メッセージまたは構成のスクリーンショット。

  2. 既知の問題を確認してください。既知の問題を確認して既知のトラブルを把握し、Databricksのリリースノートで最新の更新情報を確認してください。

  3. サポートチケットを作成します。ワークスペースで ヘルプ > サポートへの問い合わせ に移動し、 テクニカルサポート を選択して、問題の明確な説明、再現手順、収集した診断情報、および影響と緊急度を提供してください。

  4. フィードバックを提供バグ、機能リクエスト、ドキュメントの問題など、フィードバックを Databricks アカウントチームに共有してください。

このページの見出し