Azure Data Factoryを使用して REST エンドポイントとの間でデータをコピーおよび変換する

適用対象: Azure Data Factory Azure Synapse Analytics

この記事では、Azure Data Factoryでコピー アクティビティを使用して、REST エンドポイントとの間でデータをコピーする方法について説明します。 この記事は、Azure Data Factory の Copy アクティビティに基づいており、コピー アクティビティの概要を示します。

この REST コネクタ、HTTP コネクタ、および Web テーブル コネクタの違いは次のとおりです。

• REST コネクタでは、特に RESTful API からのデータのコピーがサポートされます。
• HTTP コネクタは、ファイルをダウンロードするなど、任意の HTTP エンドポイントからデータを取得するための一般的なものです。 この REST コネクタの前に、HTTP コネクタを使用して RESTful API からデータをコピーする場合があります。これはサポートされますが、REST コネクタと比べると機能は低くなります。
• Web テーブル コネクタでは、HTML Web ページからテーブルの内容を抽出します。

サポートされる機能

この REST コネクタでは、次の機能がサポートされます。

(1) Azure統合ランタイム (2) セルフホステッド統合ランタイム

ソースおよびシンクとしてサポートされているデータ ストアの一覧については、「サポートされているデータ ストア」を参照してください。

具体的には、この汎用 REST コネクタは以下をサポートします。

• GET または POST メソッドを使用した REST エンド ポイントからのデータのコピー、および POST、PUT または PATCH メソッドを使用した REST エンドポイントへのデータのコピー。
• 匿名、基本、サービス プリンシパル、OAuth2 クライアント資格情報、システム割り当てマネージド ID、ユーザー割り当てマネージド ID のいずれかの認証を使用したデータのコピー。
• REST API 内の改ページ位置の自動修正。
• ソースとしての REST の場合、REST JSON 応答をそのままコピーするか、スキーマ マッピングを使用して解析する。 JSON では応答ペイロードのみがサポートされます。

前提条件

データ ストアがオンプレミス ネットワーク、Azure仮想ネットワーク、または Amazon Virtual Private Cloud 内にある場合は、自身がホストする統合ランタイム を構成して接続する必要があります。

データ ストアがマネージド クラウド データ サービスの場合は、Azure Integration Runtimeを使用できます。 アクセスがファイアウォール規則で承認されている IP に制限されている場合は、許可リストに Azure Integration Runtime IP を追加できます。

Azure Data Factoryの 管理された仮想ネットワーク統合ランタイム機能を使用して、セルフホステッド統合ランタイムをインストールして構成することなく、オンプレミス ネットワークにアクセスすることもできます。

Data Factory によってサポートされるネットワーク セキュリティ メカニズムやオプションの詳細については、「データ アクセス戦略」を参照してください。

概要

パイプラインでコピー アクティビティを実行するには、次のいずれかのツールまたは SDK を使用できます。

• データのコピー ツール
• Azure portal
• .NET SDK
• Python SDK
• Azure PowerShell
• REST API
• Azure Resource Manager テンプレート

UI を使用して REST のリンク サービスを作成する

Azure ポータル UI で REST のリンクされたサービスを作成するには、次の手順に従います。

1. Azure Data Factoryまたは Synapse ワークスペースの [管理] タブを参照し、[リンクされたサービス] を選択し、[新規] を選択します。

   • Azure Data Factory
   • Azure Synapse

   Azure Data Factory UI を使用した新しいリンク サービスの作成のスクリーンショット

2. REST を検索し、REST コネクタを選択します。

   

3. サービスの詳細を構成し、接続をテストして、新しいリンク サービスを作成します。

   

コネクタの構成の詳細

次のセクションでは、REST コネクタに固有の Data Factory エンティティの定義に使用できるプロパティについて詳しく説明します。

リンクされたサービスのプロパティ

REST のリンクされたサービスでは、次のプロパティがサポートされます。

各種の認証の種類については、対応するセクションで詳細を参照してください。

• 基本認証
• サービス プリンシパル認証
• OAuth2 クライアント資格情報認証
• システム割り当てマネージド ID 認証
• ユーザー割り当てマネージド ID 認証
• [匿名認証]

基本認証を使用する

authenticationType プロパティを Basic に設定します。 前のセクションで説明した汎用的なプロパティに加えて、次のプロパティを指定します。

例

{
    "name": "RESTLinkedService",
    "properties": {
        "type": "RestService",
        "typeProperties": {
            "authenticationType": "Basic",
            "url" : "<REST endpoint>",
            "userName": "<user name>",
            "password": {
                "type": "SecureString",
                "value": "<password>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

サービス プリンシパル認証を使用する

authenticationType プロパティを AadServicePrincipal に設定します。 前のセクションで説明した汎用的なプロパティに加えて、次のプロパティを指定します。

例 1: サービス プリンシパル キー認証を使用する

{
    "name": "RESTLinkedService",
    "properties": {
        "type": "RestService",
        "typeProperties": {
            "url": "<REST endpoint e.g. https://www.example.com/>",
            "authenticationType": "AadServicePrincipal",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalCredentialType": "ServicePrincipalKey",
            "servicePrincipalKey": {
                "value": "<service principal key>",
                "type": "SecureString"
            },
            "tenant": "<tenant info, e.g. microsoft.onmicrosoft.com>",
            "aadResourceId": "<Azure AD resource URL e.g. https://management.core.windows.net>"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

例 2: サービス プリンシパル証明書認証を使用する

{
    "name": "RESTLinkedService",
    "properties": {
        "type": "RestService",
        "typeProperties": {
            "url": "<REST endpoint e.g. https://www.example.com/>",
            "authenticationType": "AadServicePrincipal",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalCredentialType": "ServicePrincipalCert",
            "servicePrincipalEmbeddedCert": {
                "type": "SecureString",
                "value": "<the base64 encoded certificate of your application registered in Microsoft Entra ID>"
            },
            "servicePrincipalEmbeddedCertPassword": {
                "type": "SecureString",
                "value": "<password of your certificate>"
            },
            "tenant": "<tenant info, e.g. microsoft.onmicrosoft.com>",
            "aadResourceId": "<Azure AD resource URL e.g. https://management.core.windows.net>"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

サービス プリンシパル証明書を Azure Key Vault に保存する

サービス プリンシパル証明書を Azure Key Vault に保存するには、次の 2 つのオプションがあります。

• 方法 1

  1. サービス プリンシパル証明書を base64 文字列に変換します。 詳しくは、こちらの記事をご覧ください。

  2. base64 文字列をシークレットとしてAzure Key Vaultに保存します。

     

     

• オプション 2

  Azure Key Vaultから証明書をダウンロードできない場合は、このtemplateを使用して、変換されたサービス プリンシパル証明書をシークレットとしてAzure Key Vaultに保存できます。

  

OAuth2 クライアント資格情報認証を使用する

authenticationType プロパティを OAuth2ClientCredential に設定します。 前のセクションで説明した汎用的なプロパティに加えて、次のプロパティを指定します。

例

{
    "name": "RESTLinkedService",
    "properties": {
        "type": "RestService",
        "typeProperties": {
            "url": "<REST endpoint e.g. https://www.example.com/>",
            "enableServerCertificateValidation": true,
            "authenticationType": "OAuth2ClientCredential",
            "clientId": "<client ID>",
            "clientSecret": {
                "type": "SecureString",
                "value": "<client secret>"
            },
            "tokenEndpoint": "<token endpoint>",
            "scope": "<scope>",
            "resource": "<resource>"
        }
    }
}

システム割り当てマネージド ID 認証を使用する

authenticationType プロパティを ManagedServiceIdentity に設定します。 前のセクションで説明した汎用的なプロパティに加えて、次のプロパティを指定します。

例

{
    "name": "RESTLinkedService",
    "properties": {
        "type": "RestService",
        "typeProperties": {
            "url": "<REST endpoint e.g. https://www.example.com/>",
            "authenticationType": "ManagedServiceIdentity",
            "aadResourceId": "<AAD resource URL e.g. https://management.core.windows.net>"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

ユーザー割り当てマネージド ID 認証を使用する

authenticationType プロパティを ManagedServiceIdentity に設定します。 前のセクションで説明した汎用的なプロパティに加えて、次のプロパティを指定します。

例

{
    "name": "RESTLinkedService",
    "properties": {
        "type": "RestService",
        "typeProperties": {
            "url": "<REST endpoint e.g. https://www.example.com/>",
            "authenticationType": "ManagedServiceIdentity",
            "aadResourceId": "<Azure AD resource URL e.g. https://management.core.windows.net>",
            "credential": {
                "referenceName": "credential1",
                "type": "CredentialReference"
            }    
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

認証ヘッダーの使用

また、組み込みの認証の種類と共に、認証用の要求ヘッダーを構成できます。

例: API キー認証の使用

{
    "name": "RESTLinkedService",
    "properties": {
        "type": "RestService",
        "typeProperties": {
            "url": "<REST endpoint>",
            "authenticationType": "Anonymous",
            "authHeaders": {
                "x-api-key": {
                    "type": "SecureString",
                    "value": "<API key>"
                }
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

データセットのプロパティ

このセクションでは、REST データセットでサポートされているプロパティの一覧を示します。

データセットの定義に使用できるセクションとプロパティの完全な一覧については、「データセットとリンクされたサービス」を参照してください。

REST からのデータ コピーについては、次のプロパティがサポートされています。

データセットで requestMethod、 additionalHeaders、 requestBody、 paginationRules を設定していた場合でも、as-isサポートされますが、今後のアクティビティで新しいモデルを使用することをお勧めします。

例:

{
    "name": "RESTDataset",
    "properties": {
        "type": "RestResource",
        "typeProperties": {
            "relativeUrl": "<relative url>"
        },
        "schema": [],
        "linkedServiceName": {
            "referenceName": "<REST linked service name>",
            "type": "LinkedServiceReference"
        }
    }
}

Copy アクティビティのプロパティ

このセクションでは、REST のソースとシンクでサポートされるプロパティの一覧を示します。

アクティビティの定義に利用できるセクションとプロパティの完全な一覧については、パイプラインに関する記事を参照してください。

ソースとしての REST

コピー アクティビティの source セクションでは、次のプロパティがサポートされます。

例 1: ページネーションを利用した Get メソッドの使用

"activities":[
    {
        "name": "CopyFromREST",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<REST input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "RestSource",
                "additionalHeaders": {
                    "x-user-defined": "helloworld"
                },
                "paginationRules": {
                    "AbsoluteUrl": "$.paging.next"
                },
                "httpRequestTimeout": "00:01:00"
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

例 2: Post メソッドを使用する

"activities":[
    {
        "name": "CopyFromREST",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<REST input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "RestSource",
                "requestMethod": "Post",
                "requestBody": "<body for POST REST request>",
                "httpRequestTimeout": "00:01:00"
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

シンクとしての REST

コピー アクティビティの sink セクションでは、次のプロパティがサポートされます。

シンクとしての REST コネクタは、JSON を受け入れる REST API と連携します。 データは次のパターンで JSON で送信されます。 必要に応じて、コピー アクティビティ スキーマ マッピングを使用し、REST API によって求められるペイロードに準拠するようにソース データを整形できます。

[
    { <data object> },
    { <data object> },
    ...
]

例:

"activities":[
    {
        "name": "CopyToREST",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<REST output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "<source type>"
            },
            "sink": {
                "type": "RestSink",
                "requestMethod": "POST",
                "httpRequestTimeout": "00:01:40",
                "requestInterval": 10,
                "writeBatchSize": 10000,
                "httpCompressionType": "none",
            },
        }
    }
]

データフローのマッピングプロパティ

REST は、統合データセットとインライン データセットの両方のデータ フローでサポートされています。

ソース変換

シンク変換

削除、挿入、更新、アップサートの各メソッドと、CRUD 操作のために REST シンクに送信する相対行データを設定できます。

データ フロー スクリプトのサンプル

シンクの前に行の変更変換を行うと、REST シンクで実行するアクションの種類が ADF に指示されることに注意してください。 つまり、挿入、更新、アップサート、削除です。

AlterRow1 sink(allowSchemaDrift: true,
	validateSchema: false,
	deletable:true,
	insertable:true,
	updateable:true,
	upsertable:true,
	rowRelativeUrl: 'periods',
	insertHttpMethod: 'PUT',
	deleteHttpMethod: 'DELETE',
	upsertHttpMethod: 'PUT',
	updateHttpMethod: 'PATCH',
	timeout: 30,
	requestFormat: ['type' -> 'json'],
	skipDuplicateMapInputs: true,
	skipDuplicateMapOutputs: true) ~> sink1

ページネーションサポート

REST API からデータをコピーするとき、通常、REST API では、1 つの要求の応答ペイロードのサイズが適切な数値を超えないように制限されています。大量のデータが返される場合は、結果が複数のページに分割され、呼び出し元に連続する要求を送信して結果の次のページを取得することが要求されます。 通常、1 つのページに対する要求は動的で、前のページの応答から返される情報で構成されます。

この汎用 REST コネクタは、次の改ページ位置の自動修正パターンをサポートしています。

• 次の要求の絶対または相対 URL = 現在の応答本文のプロパティ値
• 次の要求の絶対または相対 URL = 現在の応答ヘッダーのヘッダー値
• 次の要求のクエリ パラメーター = 現在の応答本文のプロパティ値
• 次の要求のクエリ パラメーター = 現在の応答ヘッダーのヘッダー値
• 次の要求のヘッダー = 現在の応答本文のプロパティ値
• 次の要求のヘッダー = 現在の応答ヘッダーのヘッダー値

ページネーション規則はデータセット内でディクショナリとして定義されます。このディクショナリには、大文字と小文字が区別される1つまたは複数のキーと値のペアが含まれています。 構成は 2 番目のページから始まる要求を生成するのに使用されます。 コネクタで HTTP 状態コード 204 (コンテンツなし) が取得されるか、"paginationRules" 内のいずれかの JSONPath 式で null が返されると、繰り返し処理が停止されます。

ページネーションルールでサポートされるキー:

ページネーション規則におけるサポートされる値:

改ページ規則の例

このセクションでは、改ページ規則の設定の例の一覧を示します。

例 1: QueryParameters の変数

この例では、QueryParameters に変数が含まれる複数の要求を送信する構成手順を示します。

複数の要求:

baseUrl/api/now/table/incident?sysparm_limit=1000&sysparm_offset=0,
baseUrl/api/now/table/incident?sysparm_limit=1000&sysparm_offset=1000,
...... 
baseUrl/api/now/table/incident?sysparm_limit=1000&sysparm_offset=10000

手順 1: 次のスクリーンショットに示すように、sysparm_offset={offset} または相対 URL に を入力します。

または

手順 2: 改ページ規則をオプション 1 またはオプション 2 として次のように設定します。

• オプション 1: "QueryParameters.{offset}" : "RANGE:0:10000:1000"

• オプション 2: "AbsoluteUrl.{offset}" : "RANGE:0:10000:1000"

例 2 : AbsoluteUrl の変数

この例では、AbsoluteUrl に変数が含まれる複数の要求を送信する構成手順を示します。

複数の要求:

BaseUrl/api/now/table/t1
BaseUrl/api/now/table/t2
...... 
BaseUrl/api/now/table/t100

手順 1: リンクされたサービス構成ページの {id} またはデータセット接続ウィンドウの [相対 URL] のどちらかに を入力します。

または

手順 2: 改ページ規則を "AbsoluteUrl.{id}" :"RANGE:1:100:1" として設定します。

例 3: ヘッダー内の変数

この例では、Headers に変数が含まれる複数の要求を送信する構成手順を示します。

複数の要求:

RequestUrl: https://example/table
Request 1: Header(id->0)
Request 2: Header(id->10)
......
Request 100: Header(id->100)

手順 1: {id} に を入力します。

手順 2: 改ページ規則を "Headers.{id}" : "RANGE:0:100:10" として設定します。

例 4:変数は AbsoluteUrl/QueryParameters/Headers にあり、終了変数は定義済みではなく、終了条件は応答に基づいています

この例では、変数が AbsoluteUrl/QueryParameters/Headers にあるが、終了変数が定義されていない複数の要求を送信する構成手順を示します。 異なる応答ごとに、異なる終了条件ルールの設定が「例 4.1-4.6」に示されています。

複数の要求:

Request 1: baseUrl/api/now/table/incident?sysparm_limit=1000&sysparm_offset=0, 
Request 2: baseUrl/api/now/table/incident?sysparm_limit=1000&sysparm_offset=1000,
Request 3: baseUrl/api/now/table/incident?sysparm_limit=1000&sysparm_offset=2000,
...... 

この例では、次の 2 つの応答が発生しました。

応答 1:

{
    Data: [
        {key1: val1, key2: val2
        },
        {key1: val3, key2: val4
        }
    ]
}

応答 2:

{
    Data: [
        {key1: val5, key2: val6
        },
        {key1: val7, key2: val8
        }
    ]
}

手順 1: 改ページ規則の範囲を例 1 として設定し、"AbsoluteUrl.{offset}": "RANGE:0::1000" として範囲の末尾を空にしておきます。

手順 2: 最後の応答ごとに異なる終了条件ルールを設定します。 次の例を参照してください。

• 例 4.1: 応答の特定のノードの値が空の場合に改ページが終了する

  REST API は、次の構造体の最後の応答を返します。

  {
      Data: []
  }
  

  応答の特定のノードの値が空の場合に改ページ調整を終了するには、終了条件ルールを "EndCondition:$.data": "Empty" に設定します。

  

• 例 4.2: 応答の特定のノードの値が存在しない場合に改ページが終了する

  REST API は、次の構造体の最後の応答を返します。

  {}
  

  特定のノードの値が応答に存在しない場合にページ付けを終了するために、終了条件ルールを "EndCondition:$.data": "NonExist" に設定します。

  

• 例 4.1: 応答の特定のノードの値が存在する場合に改ページが終了する

  REST API は、次の構造体の最後の応答を返します。

  {
      Data: [
          {key1: val991, key2: val992
          },
          {key1: val993, key2: val994
          }
      ],
              Complete: true
  }
  

  応答の特定のノードの値が存在する場合にページネーションを終了するには、終了条件ルールを "EndCondition:$.Complete": "Exist" に設定します。

  

• 例 4.1: 応答の特定のノードの値がユーザー定義の定数値の場合に改ページが終了する

  REST API は、次の構造体の応答を返します。

  {
      Data: [
          {key1: val1, key2: val2
          },
          {key1: val3, key2: val4
          }
      ],
              Complete: false
  }
  

  ......

  最後の応答は次の構造です。

  {
      Data: [
          {key1: val991, key2: val992
          },
          {key1: val993, key2: val994
          }
      ],
              Complete: true
  }
  

  応答の特定のノードの値がユーザー定義の定数値である場合に改ページ調整を終了するには、終了条件ルールを "EndCondition:$.Complete": "Const:true" に設定します。

  

• 例 4.5: 応答のヘッダー キーの値がユーザー定義の定数値に等しい場合に改ページが終了する

  REST API 応答のヘッダー キーは、次の構造に示されています。

  応答ヘッダー 1: header(Complete->0)
  ......
  最後の応答ヘッダー: header(Complete->1)
  

  応答のヘッダー キーの値がユーザー定義の定数値と同等である場合に改ページ調整を終了するには、終了条件ルールを "EndCondition:headers.Complete": "Const:1" に設定します。

  

• 例 4.6: 応答ヘッダーにキーが存在する場合、ページネーションが終了する

  REST API 応答のヘッダー キーは、次の構造に示されています。

  応答ヘッダー 1: header()
  ......
  最後の応答ヘッダー: header(CompleteTime->20220920)
  

  終了条件規則を "EndCondition:headers.CompleteTime": "Exist" として設定し、キーが応答ヘッダーに存在する場合に改ページを終了します。

  

例 5:範囲ルールが定義されていない場合に無限の要求を回避するように終了条件を設定する

この例では、範囲ルールが使用されていない場合に複数の要求を送信する構成手順を示します。 終了条件では、際限のない要求を避けるため、4.1-4.6 の例を参照して設定できます。 REST API によって、次の構造で応答が返されます。この場合、次のページの URL は paging.next で表されます。

{
    "data": [
        {
            "created_time": "2017-12-12T14:12:20+0000",
            "name": "album1",
            "id": "1809938745705498_1809939942372045"
        },
        {
            "created_time": "2017-12-12T14:14:03+0000",
            "name": "album2",
            "id": "1809938745705498_1809941802371859"
        },
        {
            "created_time": "2017-12-12T14:14:11+0000",
            "name": "album3",
            "id": "1809938745705498_1809941879038518"
        }
    ],
    "paging": {
        "cursors": {
            "after": "MTAxNTExOTQ1MjAwNzI5NDE=",
            "before": "NDMyNzQyODI3OTQw"
        },
        "previous": "https://graph.facebook.com/me/albums?limit=25&before=NDMyNzQyODI3OTQw",
        "next": "https://graph.facebook.com/me/albums?limit=25&after=MTAxNTExOTQ1MjAwNzI5NDE="
    }
}
...

最後の応答は次のとおりです。

{
    "data": [],
    "paging": {
        "cursors": {
            "after": "MTAxNTExOTQ1MjAwNzI5NDE=",
            "before": "NDMyNzQyODI3OTQw"
        },
        "previous": "https://graph.facebook.com/me/albums?limit=25&before=NDMyNzQyODI3OTQw",
        "next": "Same with Last Request URL"
    }
}

手順 1: 改ページ規則を "AbsoluteUrl": "$.paging.next" として設定します。

手順 2: 最後の応答の next が、最後の要求 URL と常に同じで、かつ空でない場合は、際限のない要求が送信されます。 終了条件は、際限のない要求を回避するために使用できます。 そのため、例 4.1-4.6 を参照して、終了条件規則を設定します。

例 6: 際限のない要求を回避するための最大要求数を設定する

次のスクリーンショットに示すように、 Maxrequestnumber を設定して際限のない要求を回避します。

例 7: RFC 5988 の改ページ規則が既定でサポートされている

バックエンドは、ヘッダー内の RFC 5988 スタイルのリンクに基づいて次の URL を自動的に取得します。

例 8a: データ フローのマッピングでページネーションを使用している場合、次のリクエスト URL はレスポンスボディに含まれています。

この例では、次の要求 URL が応答本文からのものである場合に、データ フローのマッピングで改ページ規則と終了条件規則を設定する方法を示します。

応答スキーマは次のようになります。

改ページ規則は、次のスクリーンショットのように設定する必要があります。

既定では、ページ分割は、body.{@odata.nextLink}** が null 値または空になると停止します。

ただし、最後の応答本文にある @odata.nextLink の値が最後の要求 URL と同じ場合は、無限ループになります。 この状況を回避するには、終了条件の規則を定義します。

• 最後の応答の値が空の場合、終了条件規則は次のように設定できます。

  

• 応答ヘッダーの完全なキーの値が true の場合、ページネーションの終了を示します。したがって、終了条件のルールを次のように設定できます。

  

例 8b: Copy アクティビティでページネーションを使用する場合、次の要求 URL は応答本文に含まれる。

この例では、次の要求 URL が応答本文に含まれている場合に Copy アクティビティで改ページ位置の自動修正ルールをどのように設定するかについて説明します。

応答スキーマは次のようになります。

ページネーションルールは、次のスクリーンショットに示されている通りに設定するべきです。

例 9: データフローのマッピングでページネーションを使用する場合、応答の形式はXMLであり、次のリクエストURLは応答本文から取得されます。

この例では、応答の形式が XML であり、次の要求 URL が応答本文からのものである場合に、マッピング データ フローで改ページ規則を設定する方法を示します。 次のスクリーンショットに示すように、最初の URL は https://user.dfs.core.windows.NET/bugfix/test/movie_1.xml

応答スキーマは次のようになります。

改ページ規則の構文は例 8 と同じであり、次の例のように設定する必要があります。

JSON の応答をそのままエクスポートする

REST コネクタを使用して、REST API の JSON 応答 as-is をさまざまなファイル ベースのストレージ システム (シンク) にエクスポートできます。 このスキーマに依存しないコピー動作を有効にするには、既定のスキーマ マッピングを使用します ([コピー アクティビティ] の [マッピング] タブでマッピングを定義しないでください)。

スキーマ マッピング

REST エンドポイントから表形式のシンクにデータをコピーするには、スキーマ マッピングを参照してください。

関連するコンテンツ

コピー アクティビティがAzure Data Factoryのソースおよびシンクとしてサポートするデータ ストアの一覧については、「サポートされているデータ ストアと形式を参照してください。