Copia y transformación de datos de y a un punto de conexión REST mediante Azure Data Factory

SE APLICA A: Azure Data Factory Azure Synapse Analytics

En este artículo se describe cómo usar la actividad de copia en Azure Data Factory para copiar datos desde y hacia un punto de conexión REST. El artículo se basa en Copy Activity in Azure Data Factory, que presenta una introducción general de la actividad de copia.

Las diferencias entre este conector REST, el conector HTTP y el conector de mesa web son:

• El conector REST admite específicamente la copia de datos de las API de RESTful.
• El conector HTTP es genérico para recuperar datos de cualquier punto final HTTP, por ejemplo, para descargar un archivo. Antes de este conector REST, podrías usar el conector HTTP para copiar datos de APIs RESTful, que es compatible pero menos funcional que el conector REST.
• El conector de tabla web extrae el contenido de la tabla de una página web HTML.

Funcionalidades admitidas

El conector REST es compatible con las siguientes funcionalidades:

① Azure Integration Runtime ② Entorno de ejecución de integración autohospedado

Para obtener una lista de almacenes de datos que se admiten como orígenes o receptores, consulte Almacenes de datos admitidos.

En concreto, este conector REST genérico admite lo siguiente:

• Copiar datos desde un punto final REST usando los métodos GET o POST y copiar datos a un punto final REST usando los métodos POST, PUT o PATCH .
• Copiar datos utilizando una de las siguientes autenticaciones: Anónimo, Básico, Principal de Servicio, Credencial de Cliente OAuth2, Identidad Gestionada Asignada al Sistema e Identidad Gestionada Asignada por el Usuario.
• Paginación en las API de REST.
• Para REST como origen, copie la respuesta JSON de REST as-is o anótela mediante la asignación de esquemas. Solo se admite la carga de respuesta en formato JSON.

Requisitos previos

Si el almacén de datos se encuentra dentro de una red local, una red virtual Azure o una nube privada virtual de Amazon, debe configurar un entorno de ejecución de integración autohospedado para conectarse a él.

Si el almacén de datos es un servicio de datos en la nube administrado, puede usar el Azure Integration Runtime. Si el acceso está restringido a direcciones IP aprobadas en las reglas del firewall, puede agregar las direcciones IP de Azure Integration Runtime a la lista de autorizados.

También puede usar la funcionalidad runtime de integración de red virtual administrada en Azure Data Factory para acceder a la red local sin instalar ni configurar un runtime de integración autohospedado.

Para obtener más información sobre los mecanismos y opciones de seguridad de red compatibles con Data Factory, consulte Estrategias de acceso a datos.

Primeros pasos

Para realizar la actividad de copia con una canalización, puede usar una de los siguientes herramientas o SDK:

• Herramienta Copiar datos
• Azure Portal
• SDK de .NET
• SDK de Python
• Azure PowerShell
• REST API
• plantilla Azure Resource Manager

Creación de un servicio vinculado REST mediante la interfaz de usuario

Siga estos pasos para crear un servicio vinculado rest en la interfaz de usuario del portal de Azure.

1. Vaya a la pestaña Administrar del área de trabajo de Azure Data Factory o Synapse y seleccione Servicios vinculados y, a continuación, seleccione Nuevo:

   • Azure Data Factory
   • Azure Synapse

   

2. Busque REST y seleccione el conector de REST.

   

3. Configure los detalles del servicio, pruebe la conexión y cree el servicio vinculado.

   

Detalles de configuración del conector

En las secciones siguientes se proporcionan detalles sobre las propiedades que puede usar para definir entidades de Data Factory específicas del conector REST.

Propiedades del servicio vinculado

Las siguientes propiedades son compatibles con el servicio vinculado de REST:

Para conocer los distintos tipos de autenticación, consulte las secciones correspondientes para ver los detalles.

• Autenticación básica
• Autenticación de entidad de servicio
• Autenticación de credenciales de cliente OAuth2
• Autenticación de identidad administrada asignada por el sistema
• Autenticación de identidad administrada asignada por el usuario
• Autenticación anónima

Uso de la autenticación básica

Establezca la propiedad authenticationType en Basic. Además de las propiedades genéricas descritas en las secciones anteriores, especifique las siguientes:

Ejemplo

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

Uso de la autenticación de entidad de servicio

Establezca la propiedad authenticationType en AadServicePrincipal. Además de las propiedades genéricas descritas en las secciones anteriores, especifique las siguientes:

Ejemplo 1: uso de la autenticación de claves de entidad de servicio

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

Ejemplo 2: uso de la autenticación de certificados de entidad de servicio

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

Guarde el certificado de entidad de servicio en Azure Key Vault

Tiene dos opciones para guardar el certificado de entidad de servicio en Azure Key Vault:

• Opción 1

  1. Convierta el certificado de entidad de servicio en una cadena base64. Obtenga más información en este artículo.

  2. Guarde la cadena base64 como un secreto en Azure Key Vault.

     

     

• Opción 2

  Si no puede descargar el certificado de Azure Key Vault, puede usar este template para guardar el certificado de entidad de servicio convertido como secreto en Azure Key Vault.

  

Utiliza la autenticación de credenciales de cliente de OAuth2

Establezca la propiedad authenticationType en OAuth2ClientCredential. Además de las propiedades genéricas descritas en las secciones anteriores, especifique las siguientes:

Ejemplo

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

Uso de la autenticación de identidad administrada asignada por el sistema

Establezca la propiedad authenticationType en ManagedServiceIdentity. Además de las propiedades genéricas descritas en las secciones anteriores, especifique las siguientes:

Ejemplo

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

Uso de la autenticación de identidad administrada asignada por el usuario

Establezca la propiedad authenticationType en ManagedServiceIdentity. Además de las propiedades genéricas descritas en las secciones anteriores, especifique las siguientes:

Ejemplo

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

Uso de los encabezados de autenticación

Además, puede configurar los encabezados de solicitud para realizar la autenticación, junto con los tipos de autenticación integrados.

Ejemplo: Uso de la autenticación de clave 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"
        }
    }
}

Propiedades del conjunto de datos

En esta sección se proporciona una lista de las propiedades que admite el conjunto de datos de REST.

Para obtener una lista completa de secciones y propiedades que están disponibles para definir conjuntos de datos, consulte Conjuntos de datos y servicios vinculados.

Para copiar datos de REST, se admiten las siguientes propiedades:

Si configuras requestMethod, additionalHeaders, requestBody, y paginationRules en el conjunto de datos, la operación de copia sigue soportándolos as-is, aunque deberías usar el nuevo modelo en la actividad de ahora en adelante.

Ejemplo:

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

Propiedades de la actividad de copia

En esta sección se proporciona una lista de las propiedades compatibles con REST como origen y receptor.

Para obtener una lista completa de las secciones y propiedades que están disponibles para definir actividades, consulte Canalizaciones.

REST como origen

Se admiten las siguientes propiedades en la sección source de la actividad de copia:

Ejemplo 1: Uso del método Get con paginación

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

Ejemplo 2: Uso del 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 receptor

Se admiten las siguientes propiedades en la sección sink de la actividad de copia:

El conector de REST como receptor funciona con las API REST que aceptan JSON. Los datos se envían en JSON con el siguiente patrón. Según sea necesario, utiliza el mapeo del esquema de actividad de copia para remodelar los datos fuente y ajustarlos a la carga útil esperada por la API REST.

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

Ejemplo:

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

Propiedades de Asignación de instancias de Data Flow

REST se admite en flujos de datos de conjuntos de datos de integración y conjuntos de datos en línea.

Transformación de origen

Transformación de receptor

Puede establecer los métodos delete, insert, update y upsert, así como los datos de fila relativos que se van a enviar al receptor REST para las operaciones CRUD.

Script de flujo de datos de ejemplo

Fíjate en el uso de una transformación de fila de alter antes del fregadero para indicar a Data Factory qué tipo de acción realizar con tu fregadero REST. Esa acción puede ser insertar, actualizar, activar o eliminar.

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

Compatibilidad con la paginación

Cuando copias datos de APIs REST, normalmente la API REST limita el tamaño de la carga útil de respuesta de una sola petición a un número razonable. Para devolver una gran cantidad de datos, divide el resultado en varias páginas y requiere que los llamantes envíen solicitudes consecutivas para obtener la siguiente página de resultados. Normalmente, la solicitud de una página es dinámica y está compuesta a partir de la información devuelto en la respuesta de la página anterior.

Este conector REST genérico admite los siguientes patrones de paginación:

• Dirección URL absoluta o relativa de la siguiente solicitud = valor de propiedad en el cuerpo de la respuesta actual
• Dirección URL absoluta o relativa de la siguiente solicitud = valor de encabezado en los encabezados de la respuesta actual
• Parámetro de consulta de la siguiente solicitud = valor de propiedad en el cuerpo de la respuesta actual
• Parámetro de consulta de la siguiente solicitud = valor de encabezado en los encabezados de la respuesta actual
• Encabezado de la siguiente solicitud = valor de propiedad en el cuerpo de la respuesta actual
• Encabezado de la siguiente solicitud = valor de encabezado en los encabezados de la respuesta actual

Las reglas de paginación se definen como un diccionario en el conjunto de datos, que contiene uno o más pares clave-valor sensibles a mayúsculas minúsculas. La configuración se utiliza para generar la solicitud a partir de la segunda página. El conector deja de iterar cuando recibe el código de estado HTTP 204 (Sin contenido), o cualquiera de las expresiones paginationRules JSONPath devuelve null.

Claves admitidas en reglas de paginación:

Valores admitidos en reglas de paginación:

Ejemplos de reglas de paginación

En esta sección se proporciona una lista de ejemplos para la configuración de reglas de paginación.

Ejemplo 1: Variables en QueryParameters

En este ejemplo se proporcionan los pasos de configuración para enviar varias solicitudes cuyas variables se encuentran en QueryParameters.

Varias solicitudes:

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

Paso 1: Entrada sysparm_offset={offset} en dirección URL base o dirección URL relativa , como se muestra en las capturas de pantalla siguientes:

or

Paso 2: Establece las reglas de paginación como opción 1 o opción 2:

• Opción 1: "QueryParameters.{ desplazamiento}" : "RANGO:0:10000:1000"

• Option2: "AbsoluteUrl.{ offset}" : "RANGE:0:10000:1000"

Ejemplo 2: Variables en AbsoluteUrl

En este ejemplo se proporcionan los pasos de configuración para enviar varias solicitudes cuyas variables se encuentran en AbsoluteUrl.

Varias solicitudes:

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

Paso 1: Introduzca {id} ya sea en URL base en la página de configuración del servicio vinculado o en URL relativa en el panel de conexión del conjunto de datos.

or

Paso 2: Establecer reglas de paginación como "AbsoluteUrl.{ id}" :"RANGE:1:100:1".

Ejemplo 3: Variables en encabezados

En este ejemplo se proporcionan los pasos de configuración para enviar varias solicitudes cuyas variables se encuentran en encabezados.

Varias solicitudes:

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

Paso 1: Introducir {id} dentro de Encabezados adicionales.

Paso 2: Establecer reglas de paginación como "Encabezados.{ id}" : "RANGE:0:100:10".

Ejemplo 4: Las variables están en AbsoluteUrl/QueryParameters/Headers, la variable final no está predefinida y la condición final se basa en la respuesta

En este ejemplo se proporcionan pasos de configuración para enviar varias solicitudes cuyas variables están en AbsoluteUrl/QueryParameters/Headers, pero la variable final no está definida. Para respuestas diferentes, se muestra una configuración de regla de condición final diferente en el ejemplo 4.1-4.6.

Varias solicitudes:

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

En este ejemplo se encuentran dos respuestas:

Respuesta 1:

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

Respuesta 2:

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

Paso 1: Establecer el intervalo de reglas de paginación como ejemplo 1 y dejar el final del intervalo vacío como "AbsoluteUrl.{ offset}": "RANGE:0::1000".

Paso 2: Establecer diferentes reglas de condición de finalización según las respuestas diferentes. Vea los siguientes ejemplos:

• Ejemplo 4.1: La paginación finaliza cuando el valor del nodo específico en respuesta está vacío

  La API REST devuelve la última respuesta en la estructura siguiente:

  {
      Data: []
  }
  

  Establezca la regla de condición de finalización como "EndCondition:$.data": "Empty" para finalizar la paginación cuando el valor del nodo específico en respuesta esté vacío.

  

• Ejemplo 4.2: La paginación termina cuando el valor del nodo específico en respuesta no existe

  La API REST devuelve la última respuesta en la estructura siguiente:

  {}
  

  Establezca la regla de condición de finalización como "EndCondition:$.data": "NonExist" para finalizar la paginación cuando el valor del nodo específico en respuesta no existe.

  

• Ejemplo 4.3: La paginación finaliza cuando existe el valor del nodo específico en respuesta

  La API REST devuelve la última respuesta en la estructura siguiente:

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

  Establezca la regla de condición de finalización como "EndCondition:$. Complete": "Exist" para finalizar la paginación cuando exista el valor del nodo específico en respuesta.

  

• Ejemplo 4.4: La paginación finaliza cuando el valor del nodo específico en respuesta es un valor const definido por el usuario

  La API REST devuelve la respuesta en la estructura siguiente:

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

  ......

  Y la última respuesta está en la estructura siguiente:

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

  Establezca la regla de condición de finalización como "EndCondition:$. Complete": "Const:true" para finalizar la paginación cuando el valor del nodo específico en respuesta es un valor const definido por el usuario.

  

• Ejemplo 4.5: La paginación termina cuando el valor de la clave de cabecera en respuesta es igual a un valor const definido por el usuario

  Las claves de encabezado en las respuestas de la API REST se muestran en la estructura siguiente:

  Encabezado de respuesta 1: header(Complete->0)
  ......
  Encabezado de última respuesta: header(Complete->1)
  

  Establece la regla de condición final como "EndCondition:headers". Complete": "Const:1" para finalizar la paginación cuando el valor de la clave de cabecera en respuesta es igual a un valor const definido por el usuario.

  

• Ejemplo 4.6: La paginación finaliza cuando la clave existe en el encabezado de respuesta

  Las claves de encabezado en las respuestas de la API REST se muestran en la estructura siguiente:

  Encabezado de respuesta 1: header()
  ......
  Encabezado de última respuesta: header(CompleteTime->20220920)
  

  Establezca la regla de condición final como "EndCondition:headers. CompleteTime": "Exist" para finalizar la paginación cuando la clave existe en el encabezado de respuesta.

  

Ejemplo 5: Establecer la condición de fin para evitar solicitudes interminables cuando la regla de rango no está definida

En este ejemplo se proporcionan los pasos de configuración para enviar varias solicitudes cuando no se usa la regla de intervalo. La condición final se puede establecer según el ejemplo 4.1-4.6 para evitar solicitudes infinitas. La API REST devuelve la respuesta en la estructura siguiente, en cuyo caso la dirección URL de la página siguiente se representa en 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="
    }
}
...

La última respuesta es:

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

Paso 1: Establezca reglas de paginación como "AbsoluteUrl": "$.paging.next".

Paso 2: Si next en la última respuesta siempre es igual que la última URL de petición y no está vacía, el proceso envía peticiones sin fin. Usa la condición de fin para evitar peticiones interminables. Por lo tanto, establece la regla de la condición final refiriéndote a los Ejemplos 4.1 a 4.6.

Ejemplo 6: Establecer el número máximo de solicitudes para evitar peticiones interminables

Establezca MaxRequestNumber para evitar una solicitud infinita, como se muestra en la captura de pantalla siguiente:

Ejemplo 7: La regla de paginación RFC 5988 está soportada por defecto

El backend recibe automáticamente la siguiente URL según los enlaces de estilo RFC 5988 en la cabecera.

Ejemplo 8a: La siguiente dirección URL de solicitud del cuerpo de la respuesta cuando se utiliza la paginación en los flujos de datos de asignación

En este ejemplo se indica cómo establecer la regla de paginación y la regla de condición final en los flujos de datos de asignación cuando la siguiente dirección URL de solicitud es del cuerpo de la respuesta.

A continuación se muestra el esquema de respuesta:

Las reglas de paginación deben establecerse como la captura de pantalla siguiente:

Por defecto, la paginación se detiene cuando body.{@odata.nextLink} es nulo o vacío.

Pero si el valor de @odata.nextLink en el cuerpo de la última respuesta es igual a la última URL de la petición, se produce un bucle infinito. Para evitar esta condición, defina reglas de condición final.

• Si Value en la última respuesta es Empty, la regla de condición final se puede establecer como se indica a continuación:

  

• Si el valor de la clave completa en el encabezado de respuesta es igual a true e indica el final de la paginación, la regla de la condición de finalización se puede establecer como se indica a continuación:

  

Ejemplo 8b: La siguiente dirección URL de solicitud del cuerpo de la respuesta cuando se utiliza la paginación en la actividad de copia

En este ejemplo se muestra cómo establecer la regla de paginación en una actividad de copia cuando la siguiente dirección URL de solicitud se encuentra dentro del cuerpo de la respuesta.

A continuación se muestra el esquema de respuesta:

Las reglas de paginación deben establecerse tal y como se muestra en la captura de pantalla siguiente:

Ejemplo 9: El formato de la respuesta es XML y la siguiente dirección URL de solicitud es del cuerpo de la respuesta cuando se utiliza la paginación en los flujos de datos de asignación.

En este ejemplo se indica cómo establecer la regla de paginación en los flujos de datos de asignación cuando el formato de respuesta es XML y la siguiente dirección URL de solicitud es del cuerpo de la respuesta. Como se muestra en la siguiente captura de pantalla, la primera URL es https://< user.dfs.core.windows.net/bugfix/test/movie_1.xml>

A continuación se muestra el esquema de respuesta:

La sintaxis de la regla de paginación es la misma que en el ejemplo 8 y debe establecerse como se indica a continuación en este ejemplo:

Exportación de la respuesta JSON tal cual

Puede usar el conector REST para exportar la respuesta JSON de una API REST as-is a varios sistemas de almacenamiento basados en archivos (receptores). Para habilitar este comportamiento de copia independiente del esquema, utiliza el mapeo de esquema por defecto (no definas ningún mapeo en la pestaña de Mapeado de la Actividad de Copia).

Asignación de esquemas

Para copiar datos desde el punto de conexión de REST en un receptor tabular, vea asignación de esquemas.

Contenido relacionado

Para obtener una lista de almacenes de datos que la actividad de copia admite como orígenes y receptores en Azure Data Factory, consulte Almacenes de datos y formatos admitidos.