Копирование и преобразование данных из конечной точки REST с помощью Фабрика данных Azure

ПРИМЕНИМО К: Фабрика данных Azure Azure Synapse Analytics

В этой статье описывается, как использовать действие копирования в Фабрика данных Azure для копирования данных из конечной точки REST и из нее. В статье рассматривается действие копирования в Фабрика данных Azure, которое дает общий обзор этой функции.

Различия между этим REST-разъёмом, HTTP-разъёмом и разъёмом Web Table следующие:

• Соединитель REST поддерживает копирование данных из API RESTful.
• HTTP-коннектор является универсальным для получения данных с любой HTTP-конечной точки, например, для загрузки файла. До этого REST-разъёма можно было использовать HTTP-разъём для копирования данных из RESTful API, которые поддерживаются, но работают менее эффективно, чем REST-разъём.
• Соединитель веб-таблиц извлекает содержимое таблицы со страницы HTML.

Поддерживаемые возможности

Соединитель REST поддерживает следующие возможности:

(1) Azure среды выполнения интеграции (2) локальная среда выполнения интеграции

Список хранилищ данных, которые поддерживаются в качестве источников/приемников, см. в разделе Поддерживаемые хранилища данных.

Этот универсальный соединитель REST, в частности, поддерживает следующее.

• Копирование данных с конечной точки REST с помощью методов GET или POST и копирование данных на конечную точку REST с помощью методов POST,PUT или PATCH .
• Копирование данных с помощью одной из следующих аутентификаций: Anonymous, Basic, Service Principal, Учетные данные клиента OAuth2, Управляемая идентификация, назначенная системой, и управляемая идентификация, назначенная пользователем.
• Разбиение на страницы в интерфейсах REST API.
• Если источником является REST: копирование JSON ответа REST как есть или его разбор с помощью картирования схем. Поддерживается только ответ в формате JSON.

Предварительные требования

Если хранилище данных находится в локальной сети, виртуальной сети Azure или Amazon Virtual Private Cloud, необходимо настроить самостоятельно размещаемую среду выполнения интеграции для подключения к нему.

Если хранилище данных является управляемой облачной службой данных, можно использовать Azure Integration Runtime. Если доступ ограничен ip-адресами, утвержденными в правилах брандмауэра, в список разрешений можно добавить ip-адреса Azure Integration Runtime/c0.

Вы также можете использовать функцию управляемой среды выполнения интеграции виртуальной сети в Фабрика данных Azure для доступа к локальной сети без установки и настройки локальной среды выполнения интеграции.

Дополнительные сведения о вариантах и механизмах обеспечения сетевой безопасности, поддерживаемых Фабрикой данных, см. в статье Стратегии получения доступа к данным.

Начало работы

Для выполнения действия копирования с конвейером можно использовать один из следующих средств или пакетов SDK:

• Средство копирования данных
• портал Azure
• SDK .NET
• пакет SDK Python
• Azure PowerShell
• REST API
• шаблон Azure Resource Manager

Создание связанной службы REST с помощью пользовательского интерфейса

Выполните следующие действия, чтобы создать связанную службу REST в пользовательском интерфейсе портала Azure.

1. Перейдите на вкладку "Управление" в рабочей области Фабрика данных Azure или Synapse и выберите "Связанные службы", а затем нажмите кнопку "Создать".

   • Фабрика данных Azure
   • Azure Synapse

   

2. Выполните поиск REST и выберите соединитель REST.

   

3. Настройте сведения о службе, проверьте подключение и создайте связанную службу.

   

Сведения о конфигурации соединителя

В разделах ниже приведены сведения о свойствах, которые используются для определения сущностей Фабрики данных, относящихся к соединителю REST.

Свойства подключенной службы

Для связанной службы REST поддерживаются следующие свойства.

Сведения о различных типах проверки подлинности см. в соответствующих разделах.

• Обычная проверка подлинности
• Аутентификация сервисного принципала
• Аутентификация удостоверения данных клиента OAuth2
• Проверка подлинности с помощью назначенного системой управляемого удостоверения
• Аутентификация с использованием управляемого удостоверения, назначенного пользователем
• Анонимная проверка подлинности

Используйте базовую проверку подлинности

Задайте для свойства 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:

• Вариант 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>"
        }
    }
}

Используйте аутентификацию с управляемым удостоверением, назначенным системой

Задайте для свойства 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"
        }
    }
}

Проверка подлинности с помощью управляемого удостоверения, назначаемого системой

Задайте для свойства 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"
        }
    }
}

Свойства операции копирования

Этот раздел содержит список свойств, поддерживаемых источником и приемником 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 в качестве приемника работает с API REST, принимающими JSON. Данные передаются в формате 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 поддерживается в потоках данных как для интеграции наборов данных, так и для встроенных наборов данных.

Преобразование источника

Преобразование раковины

Вы можете задать методы delete (удалить), insert (вставить), update (обновить) и upsert (обновить или вставить), а также соответствующие данные строки для отправки в приемник REST для операций CRUD.

Простой скрипт потока данных

Обратите внимание на использование преобразования Alter Row перед приёмником, чтобы указать Data Factory, какой тип действия следует выполнить с вашим REST-приёмником. Это действие может быть вставить, обновить, увеличить или удалить.

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 обычно ограничивает размер полезной нагрузки ответа одного запроса разумным числом. Чтобы вернуть большое количество данных, результат разбивает на несколько страниц и требует от звонящих отправлять последовательные запросы, чтобы получить следующую страницу результатов. Обычно запрос на одну страницу является динамическим и состоит из информации, возвращаемой в ответе на предыдущую страницу.

Этот универсальный соединитель REST поддерживает следующие шаблоны разбиения на страницы:

• абсолютный или относительный URL-адрес следующего запроса = значение свойства в текущем тексте ответа;
• абсолютный или относительный URL-адрес следующего запроса = значение заголовка в текущих заголовках ответа;
• параметр запроса следующего запроса = значение свойства в текущем тексте ответа;
• параметр запроса следующего запроса = значение заголовка в текущих заголовках ответа;
• заголовок следующего запроса = значение свойства в текущем тексте ответа;
• заголовок следующего запроса = значение заголовка в текущих заголовках ответа.

Правила пагинации задаются в наборе данных в виде словаря, содержащего одну или несколько пар «ключ — значение» с учетом регистра. Эта конфигурация используется для генерации запроса, начиная со второй страницы. Коннектор прекращает итерацию, когда получает код состояния HTTP 204 («Нет содержимого») или когда любое из выражений JSONPath в paginationRules возвращает 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-адрес или Относительный 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-адрес на странице настройки связанной службы или в поле Относительный URL-адрес в области подключения к набору данных.

или

Шаг 2. Задайте правила разбиения на страницы как "AbsoluteUrl.{id}" :"RANGE:1:100:1".

Пример 3: Переменные в заголовках

В этом примере приведены шаги настройки для отправки нескольких запросов, переменные которых находятся в заголовках.

Несколько запросов:

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,
...... 

В этом примере встречаются два ответа:

Ответ 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.3. Постраничная разбивка завершается, когда значение определенного узла существует в ответе

  REST API возвращает последний ответ в следующей структуре:

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

  Задайте правило условия завершения как "EndCondition:$.Complete": "Exist", чтобы завершить разбиение на страницы в том случае, если существует значение определенного узла в ответе.

  

• Пример 4.4. Разбиение на страницы завершается, когда значение конкретного узла в ответе равно заданному пользователем константному значению

  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: Пагинация заканчивается, когда значение ключевого заголовка в ответ равно пользовательскому значения const

  Ключи заголовков в ответах REST API показаны в следующей структуре:

  Заголовок ответа 1: header(Complete->0)
  ......
  Последний заголовок ответа: header(Complete->1)
  

  Установите правило конечного условия как «EndCondition:headers. Complete": "Const:1 " для завершения пагинации, когда значение заголовочного ключа в ответ равно пользовательскому const-значению.

  

• Пример 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 поддерживается по умолчанию

Бэкенд автоматически получает следующий URL на основе ссылок в стиле RFC 5988 в заголовке.

Пример 8a. Следующий URL-адрес запроса находится в тексте ответа при использовании разбиения на страницы в потоках данных сопоставления

В этом примере показано, как задать правило разбиения на страницы и правило условия завершения в потоках данных для сопоставления, если следующий URL-адрес запроса находится в тексте ответа.

Схема ответа приведена ниже:

Правила разбиения на страницы должны быть заданы так, как показано на следующем снимке экрана:

По умолчанию страницирование прекращается, когда body.{@odata.nextLink} нулевая или пустая.

Но если значение @odata.nextLink в последнем теле ответа равно URL последнего запроса, это приводит к бесконечному циклу. Чтобы избежать этого условия, определите правила условий завершения.

• Если значение в последнем ответе пусто, правило условия завершения можно задать следующим образом:

  

• Если значение полного ключа в заголовке ответа равно true (что означает завершение разбиения на страницы), правило условия завершения можно задать следующим образом:

  

Пример 8b. Следующий URL-адрес запроса находится в тексте ответа при использовании разбиения на страницы в действии копирования

В этом примере показано, как задать правило разбиения на страницы в действии копирования, когда следующий URL-адрес запроса содержится в тексте ответа.

Схема ответа приведена ниже:

Правила разбиения на страницы должны быть заданы, как показано на следующем снимке экрана:

Пример 9. В ответе используется формат XML, а следующий URL-адрес запроса находится в тексте ответа при использовании разбиения на страницы в потоках данных для сопоставления

В этом примере показано, как задать правило разбиения на страницы в потоках данных для сопоставления, если в ответе используется формат XML, а следующий URL-адрес запроса находится в тексте ответа. Как показано на следующем скриншоте, первый URL — https://< user.dfs.core.windows.net/bugfix/test/movie_1.xml>

Схема ответа приведена ниже:

Синтаксис правила разбиения на страницы такой же, как и в примере 8, и должен быть задан следующим образом:

Экспорт ответа JSON "как есть"

Соединитель REST можно использовать для экспорта ответа JSON REST API as-is в различные системы хранения на основе файлов (приемники). Чтобы активировать это поведение копирования, не зависящее от схемы, используйте стандартное отображение схем (не определяйте отображение во вкладке «Отображение» активности копирования).

Сопоставление схем

Инструкции по копированию данных из конечной точки REST в табличный приемник см. в разделе о сопоставлении схем.

Связанный контент

Список хранилищ данных, поддерживаемых функцией копирования в качестве источников и приемников в Фабрика данных Azure, см. в разделе Поддерживаемые хранилища данных и форматы.