Copie e transforme dados de e para um endpoint REST usando o Azure Data Factory

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Este artigo explica como usar a Copy Activity no Azure Data Factory para copiar dados de e para um endpoint REST. O artigo baseia-se na Atividade de Cópia em Azure Data Factory, que apresenta uma visão geral da Atividade de Cópia.

As diferenças entre este conector REST, o conector HTTP e o conector da tabela Web são:

• O conector REST suporta especificamente a cópia de dados de APIs RESTful.
• O conector HTTP é genérico para obter dados de qualquer ponto final HTTP, por exemplo, para fazer download de ficheiros. Antes deste conector REST, pode utilizar o conector HTTP para copiar dados de APIs RESTful, que é suportado, mas menos funcional comparativamente ao conector REST.
• O conector da tabela Web extrai o conteúdo da tabela de uma página Web HTML.

Capacidades suportadas

Este conector REST é suportado para os seguintes recursos:

(1) Runtime de integração Azure (2) Runtime de integração auto-hospedado

Para obter uma lista de armazenamentos de dados suportados como fontes/sumidouros, consulte Armazenamentos de dados suportados.

Especificamente, este conector REST genérico suporta:

• Copiar dados de um ponto de extremidade REST usando os métodos GET ou POST e copiar dados para um ponto de extremidade REST usando os métodos POST, PUT ou PATCH.
• Copiar dados usando uma das seguintes autenticações: Anónima, Básica, Entidade de Serviço, Credencial de Cliente OAuth2, Identidade Gerida Atribuída pelo Sistema e Identidade Gerida Atribuída pelo Utilizador.
• Paginação nas APIs REST.
• Para REST como origem, copiar a resposta JSON do REST tal como está ou analisar a utilizando mapeamento de esquema. Somente a carga útil de resposta em JSON é suportada.

Pré-requisitos

Se o seu armazenamento de dados estiver localizado numa rede local, numa rede virtual Azure ou na Amazon Virtual Private Cloud, precisa de configurar um runtime de integração auto-hospedado para se ligar a ele.

Se o seu armazenamento de dados for um serviço de dados na cloud gerido, pode usar o Azure Integration Runtime. Se o acesso for restrito a IPs aprovados nas regras do firewall, pode adicionar IPs Azure Integration Runtime à lista de autorizações.

Também pode usar a funcionalidade managed virtual network integration runtime no Azure Data Factory para aceder à rede local sem instalar e configurar um runtime de integração auto-hospedado.

Para obter mais informações sobre os mecanismos de segurança de rede e as opções suportadas pelo Data Factory, consulte Estratégias de acesso a dados.

Introdução

Para executar a atividade de cópia com um pipeline, você pode usar uma das seguintes ferramentas ou SDKs:

• Ferramenta Copiar dados
• Portal do Azure
• .NET SDK
• Python SDK
• Azure PowerShell
• API REST
• Modelo do Azure Resource Manager

Criar um serviço vinculado REST usando a interface do usuário

Use os passos seguintes para criar um serviço ligado REST na interface do portal Azure.

1. Navegue até ao separador Gerir no seu espaço de trabalho Azure Data Factory ou Synapse e selecione Serviços Ligados, depois selecione Novo:

   • Azure Data Factory
   • Azure Synapse

   

2. Procure REST e selecione o conector REST.

   

3. Configure os detalhes do serviço, teste a conexão e crie o novo serviço vinculado.

   

Detalhes de configuração do conector

As seções a seguir fornecem detalhes sobre as propriedades que você pode usar para definir entidades do Data Factory que são específicas para o conector REST.

Propriedades do serviço vinculado

As seguintes propriedades são suportadas para o serviço vinculado REST:

Para diferentes tipos de autenticação, consulte as seções correspondentes para obter detalhes.

• Autenticação básica
• Autenticação de Principal de Serviço
• Autenticação de credenciais de cliente OAuth2
• Autenticação de identidade gerenciada atribuída pelo sistema
• Autenticação de identidade gerenciada atribuída pelo usuário
• Autenticação anónima

Usar autenticação básica

Defina a propriedade authenticationType como Basic. Além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:

Exemplo

{
    "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"
        }
    }
}

Usar a autenticação da entidade de serviço

Defina a propriedade authenticationType como AadServicePrincipal. Além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:

Exemplo 1: Usando autenticação por chave do principal do serviço

{
    "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"
        }
    }
}

Exemplo 2: Usando a autenticação de certificado da entidade de serviço

{
    "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"
        }
    }
}

Guardar o certificado principal de serviço no Azure Key Vault

Tem duas opções para guardar o certificado do principal de serviço no Azure Key Vault:

• Opção 1

  1. Converta o certificado da entidade de serviço em uma cadeia de caracteres base64. Saiba mais neste artigo.

  2. Guarda a cadeia base64 como segredo no Azure Key Vault.

     

     

• Opção 2

  Se não conseguir descarregar o certificado do Azure Key Vault, pode usar este template para guardar o certificado de principal de serviço convertido como um segredo no Azure Key Vault.

  

Usar autenticação de credenciais de cliente OAuth2

Defina a propriedade authenticationType como OAuth2ClientCredential. Além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:

Exemplo

{
    "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>"
        }
    }
}

Usar autenticação de identidade gerenciada atribuída pelo sistema

Defina a propriedade authenticationType para ManagedServiceIdentity. Além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:

Exemplo

{
    "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"
        }
    }
}

Usar autenticação de identidade gerenciada atribuída pelo usuário

Defina a propriedade authenticationType para ManagedServiceIdentity. Além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:

Exemplo

{
    "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"
        }
    }
}

Usando cabeçalhos de autenticação

Além disso, você pode configurar cabeçalhos de solicitação para autenticação junto com os tipos de autenticação internos.

Exemplo: Usando a autenticação de chave de 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"
        }
    }
}

Propriedades do conjunto de dados

Esta seção fornece uma lista de propriedades suportadas pelo conjunto de dados REST.

Para obter uma lista completa de seções e propriedades disponíveis para definir conjuntos de dados, consulte Conjuntos de dados e serviços vinculados.

Para copiar dados do REST, as seguintes propriedades são suportadas:

Caso tenha definido requestMethod, additionalHeaders, requestBody, e paginationRules no conjunto de dados, ainda é suportado pelo modelo as-is, mas é recomendado que use o novo modelo em atividade daqui para frente.

Exemplo:

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

Copiar propriedades da atividade

Esta seção fornece uma lista de propriedades suportadas pela fonte REST e pelo coletor.

Para obter uma lista completa de seções e propriedades disponíveis para definir atividades, consulte Pipelines.

REST como fonte

As seguintes propriedades são suportadas na seção de origem da atividade de cópia:

Exemplo 1: Usando o método Get com paginação

"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>"
            }
        }
    }
]

Exemplo 2: Usando o método 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 como destino de dados

As seguintes propriedades são suportadas na seção coletor de atividade de cópia:

O conector REST como coletor funciona com as APIs REST que aceitam JSON. Os dados serão enviados em JSON com o seguinte padrão. Conforme necessário, você pode usar o mapeamento do esquema de atividade de cópia para remodelar os dados de origem para que estejam em conformidade com a carga esperada pela API REST.

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

Exemplo:

"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",
            },
        }
    }
]

Mapeando propriedades de fluxo de dados

O REST é suportado em fluxos de dados para conjuntos de dados de integração e conjuntos de dados embutidos.

Transformação da fonte

Transformação do lavatório

Você pode definir os métodos delete, insert, update e upsert, bem como os dados de linha relativos a serem enviados ao coletor REST para operações CRUD.

Script de fluxo de dados de exemplo

Observe o uso de uma transformação de linha de alteração antes do coletor para instruir o ADF sobre o tipo de ação a ser executada com o coletor REST. Ou seja, inserir, atualizar, atualizar, excluir.

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

Suporte à paginação

Quando você copia dados de APIs REST, normalmente, a API REST limita o tamanho da carga útil de resposta de uma única solicitação sob um número razoável; enquanto retorna uma grande quantidade de dados, ele divide o resultado em várias páginas e exige que os chamadores enviem solicitações consecutivas para obter a próxima página do resultado. Normalmente, o pedido de uma página é dinâmico e composto pelas informações retornadas da resposta da página anterior.

Este conector REST genérico suporta os seguintes padrões de paginação:

• URL absoluto ou relativo da próxima solicitação = valor da propriedade no corpo da resposta atual
• URL absoluto ou relativo da próxima solicitação = valor do cabeçalho nos cabeçalhos de resposta atuais
• Parâmetro de consulta da próxima solicitação = valor da propriedade no corpo da resposta atual
• Parâmetro de consulta da próxima solicitação = valor do cabeçalho nos cabeçalhos de resposta atuais
• O cabeçalho da próxima solicitação = o valor da propriedade no corpo da resposta atual
• Cabeçalho da próxima solicitação = valor do cabeçalho nos cabeçalhos de resposta atuais

As Regras de Paginação são definidas como um dicionário no conjunto de dados, que contém um ou mais pares chave-valor sensíveis a maiúsculas e minúsculas. A configuração será usada para gerar a solicitação a partir da segunda página. O conector irá parar de iterar quando ele recebe o código de status HTTP 204 (Sem Conteúdo), ou qualquer uma das expressões JSONPath em "paginationRules" retorna null.

Chaves suportadas em regras de paginação:

Valores suportados em regras de paginação:

Exemplos de regras de paginação

Esta seção fornece uma lista de exemplos de configurações de regras de paginação.

Exemplo 1: Variáveis em QueryParameters

Este exemplo fornece as etapas de configuração para enviar várias solicitações cujas variáveis estão em QueryParameters.

Vários pedidos:

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

Passo 1: Insira sysparm_offset={offset} seja no URL Base ou no URL Relativo, como mostrado nas capturas de ecrã seguintes:

ou

Etapa 2: Defina as regras de paginação como opção 1 ou opção 2:

• Opção1: "QueryParameters.{offset}" : "INTERVALO:0:10000:1000"

• Opção2: "AbsoluteUrl.{offset}" : "INTERVALO:0:10000:1000"

Exemplo 2:Variáveis em AbsoluteUrl

Este exemplo fornece as etapas de configuração para enviar várias solicitações cujas variáveis estão em AbsoluteUrl.

Vários pedidos:

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

Etapa 1: insira ou a {id} na página de configuração do serviço vinculado ou a URL Relativa no painel de conexão do conjunto de dados.

ou

Etapa 2: Defina as regras de paginação como "AbsoluteUrl.{ id}" :"INTERVALO:1:100:1".

Exemplo 3:Variáveis em cabeçalhos

Este exemplo fornece as etapas de configuração para enviar várias solicitações cujas variáveis estão em Headers.

Vários pedidos:

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

Passo 1: Entrada {id} em cabeçalhos adicionais.

Etapa 2: Defina Regras de Paginação como "Cabeçalhos.{id}" : "INTERVALO:0:100:10".

Exemplo 4:As variáveis estão em AbsoluteUrl/QueryParameters/Headers, a variável final não é predefinida e a condição final é baseada na resposta

Este exemplo fornece etapas de configuração para enviar várias solicitações cujas variáveis estão em AbsoluteUrl/QueryParameters/Headers, mas a variável final não está definida. Para respostas diferentes, diferentes configurações de regra de condição final são mostradas no Exemplo 4.1-4.6.

Vários pedidos:

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

Duas respostas encontradas neste exemplo:

Resposta 1:

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

Resposta 2:

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

Etapa 1: Defina o intervalo das Regras de Paginação como Exemplo 1 e deixe o final do intervalo vazio como "AbsoluteUrl.{offset}": "INTERVALO:0::1000".

Passo 2: Defina regras de condição final diferentes de acordo com diferentes últimas respostas. Veja abaixo exemplos:

• Exemplo 4.1: A paginação termina quando o valor do nó específico na resposta está vazio

  A API REST retorna a última resposta na seguinte estrutura:

  {
      Data: []
  }
  

  Defina a regra de condição final como "EndCondition:$.data": "Vazio" para encerrar a paginação quando o valor do nó específico em resposta estiver vazio.

  

• Exemplo 4.2: A paginação termina quando o valor do nó específico na resposta não está presente

  A API REST retorna a última resposta na seguinte estrutura:

  {}
  

  Defina a regra de condição final como "EndCondition:$.data": "NonExist" para encerrar a paginação quando o valor do nó específico na resposta não existir.

  

• Exemplo 4.3: A paginação termina quando o valor do nó específico em resposta existe

  A API REST retorna a última resposta na seguinte estrutura:

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

  Defina a regra de condição final como "EndCondition:$.Complete": "Exist" para terminar a paginação quando existir o valor do nó específico na resposta.

  

• Exemplo 4.4: A paginação termina quando o valor do nó específico em resposta é um valor const definido pelo usuário

  A API REST retorna a resposta na seguinte estrutura:

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

  ......

  E a última resposta está na seguinte estrutura:

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

  Defina a regra de condição final como "EndCondition:$. Complete": "Const:true" para finalizar a paginação quando o valor do nó específico em resposta for um valor const definido pelo usuário.

  

• Exemplo 4.5: A paginação termina quando o valor da chave de cabeçalho em resposta é igual ao valor const definido pelo usuário

  As teclas de cabeçalho nas respostas da API REST são mostradas na estrutura abaixo:

  Cabeçalho de resposta 1: header(Complete->0)
  ......
  Cabeçalho da última resposta: header(Complete->1)
  

  Defina a regra de condição final como "EndCondition:headers. Complete": "Const:1" para terminar a paginação quando o valor da chave de cabeçalho em resposta for igual ao valor const definido pelo usuário.

  

• Exemplo 4.6: A paginação termina quando a chave existe no cabeçalho da resposta

  As teclas de cabeçalho nas respostas da API REST são mostradas na estrutura abaixo:

  Cabeçalho de resposta 1: header()
  ......
  Cabeçalho da última resposta: header(CompleteTime->20220920)
  

  Defina a regra de condição final como "EndCondition:headers. CompleteTime": "Exist" para terminar a paginação quando a chave existir no cabeçalho da resposta.

  

Exemplo 5:Definir condição final para evitar solicitações intermináveis quando a regra de intervalo não estiver definida

Este exemplo fornece as etapas de configuração para enviar várias solicitações quando a regra de intervalo não é usada. A condição final pode ser definida consulte o Exemplo 4.1-4.6 para evitar solicitações intermináveis. A API REST retorna a resposta na estrutura a seguir, caso em que a URL da próxima página é representada em 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="
    }
}
...

A última resposta é:

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

Passo 1: Defina as regras de paginação como "AbsoluteUrl": "$.paging.next".

Passo 2: Se next na última resposta for sempre o mesmo com o URL do último pedido e não estiver vazio, serão enviados pedidos intermináveis. A condição final pode ser usada para evitar pedidos intermináveis. Portanto, defina a regra de condição final consulte o Exemplo 4.1-4.6.

Exemplo 6:Defina o número máximo de solicitação para evitar solicitações intermináveis

Defina MaxRequestNumber para evitar solicitações intermináveis, conforme mostrado na captura de tela a seguir:

Exemplo 7:A regra de paginação RFC 5988 é suportada por padrão

O back-end obterá automaticamente o próximo URL com base nos links de estilo RFC 5988 no cabeçalho.

Exemplo 8a: A próxima URL de solicitação está no corpo da resposta ao usar paginação no mapeamento de fluxos de dados

Este exemplo indica como definir a regra de paginação e a regra de condição final no mapeamento de fluxos de dados quando a próxima URL de solicitação é do corpo da resposta.

O esquema de resposta é mostrado abaixo:

As regras de paginação devem ser definidas como a seguinte captura de tela:

Por padrão, a paginação será interrompida quando o corpo. {@odata.nextLink}** é nulo ou vazio.

Mas se o valor de @odata.nextLink no último corpo de resposta for igual ao URL da última solicitação, isso levará ao loop infinito. Para evitar essa condição, defina regras de condição final.

• Se Valor na última resposta for Vazio, a regra de condição final pode ser definida conforme mostrado abaixo.

  

• Se o valor da chave completa no cabeçalho da resposta for igual a true, isso indica o fim da paginação; a regra da condição final pode ser definida como abaixo:

  

Exemplo 8b: O URL da próxima solicitação está no corpo da resposta ao usar paginação na atividade de cópia

Este exemplo demonstra como definir a regra de paginação em uma atividade de cópia quando a próxima URL de solicitação está contida no corpo da resposta.

O esquema de resposta é mostrado abaixo:

As regras de paginação devem ser definidas como mostrado na captura de tela a seguir:

Exemplo 9: O formato de resposta é XML e a próxima URL de solicitação é do corpo da resposta quando usar paginação no mapeamento de fluxos de dados

Este exemplo indica como definir a regra de paginação no mapeamento de fluxos de dados quando o formato de resposta é XML e a próxima URL de solicitação é do corpo da resposta. Como mostrado na captura de ecrã seguinte, o primeiro URL é https://<user>.dfs.core.windows.NET/bugfix/test/movie_1.xml

O esquema de resposta é mostrado abaixo:

A sintaxe da regra de paginação é a mesma do Exemplo 8 e deve ser definida como abaixo neste exemplo:

Exportar resposta JSON no estado em que se encontra

Você pode usar o conector REST para exportar a resposta JSON as-is de uma API REST para vários sistemas de armazenamento em bases de ficheiros (destinos). Para habilitar esse comportamento de cópia independente de esquema, use o mapeamento de esquema padrão (não defina nenhum mapeamento na guia Mapeamento da atividade de cópia.)

Mapeamento de esquema

Para copiar dados do ponto de extremidade REST para o coletor tabular, consulte o mapeamento de esquema.

Conteúdos relacionados

Para uma lista de armazenamentos de dados que o Copy Activity suporta como fontes e destinos no Azure Data Factory, veja Supported data stores and formats.