Copier et transformer des données depuis et vers un point de terminaison REST à l’aide de Azure Data Factory

S'APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Cet article explique comment utiliser l’activité de copie dans Azure Data Factory pour copier des données depuis et vers un point de terminaison REST. L’article s’appuie sur l’activité Copy dans Azure Data Factory, qui présente une vue d’ensemble générale de l’activité de copie.

Les différences entre ce connecteur REST, le connecteur HTTP et le connecteur Web Table sont les suivantes :

• Le connecteur REST prend spécifiquement en charge la copie de données à partir d’API RESTful.
• Le connecteur HTTP est générique pour récupérer des données de n’importe quel point de terminaison HTTP, par exemple, pour télécharger un fichier. Avant ce connecteur REST, vous pouvez utiliser le connecteur HTTP pour copier les données des API RESTful, qui est supporté mais moins fonctionnel que le connecteur REST.
• Le connecteur Table web extrait le contenu de tables d’une page web HTML.

Fonctionnalités prises en charge

Ce connecteur REST est pris en charge pour les fonctionnalités suivantes :

(1) Moteur d'intégration Azure (2) Moteur d'intégration auto-hébergé

Pour obtenir la liste des magasins de données pris en charge en tant que sources et récepteurs, voir Magasins de données pris en charge.

Plus précisément, ce connecteur REST générique prend en charge ce qui suit :

• Copier des données d’un point de terminaison REST en utilisant les méthodes GET ou POST et copier les données vers un point de terminaison REST en utilisant les méthodes POST,PUT ou PATCH .
• Copie des données en utilisant l’une des authentifications suivantes : Anonyme, Basic, Service Principal, Identifiant client OAuth2, Identité managée assignée par le système, et Identité managée assignée par l’utilisateur.
• Pagination dans les API REST.
• Pour REST en tant que source, copier la réponse JSON REST en l'état ou la parser à l'aide d'un mappage de schéma. Seule la charge utile de réponse dans JSON est prise en charge.

Prérequis

Si votre magasin de données se trouve à l’intérieur d’un réseau local, d’un réseau virtuel Azure ou d’Amazon Virtual Private Cloud, vous devez configurer un runtime d’intégration auto-hébergé /c0<> pour vous y connecter.

Si votre magasin de données est un service de données cloud managé, vous pouvez utiliser le Azure Integration Runtime. Si l’accès est limité aux adresses IP approuvées dans les règles de pare-feu, vous pouvez ajouter adresses IP d'Azure Integration Runtime à la liste autorisée.

Vous pouvez également utiliser la fonctionnalité runtime d’intégration de réseau virtuel managé dans Azure Data Factory pour accéder au réseau local sans installer et configurer un runtime d’intégration auto-hébergé.

Pour plus d’informations sur les mécanismes de sécurité réseau et les options pris en charge par Data Factory, consultez Stratégies d’accès aux données.

Bien démarrer

Pour effectuer l’activité Copy avec un pipeline, vous pouvez vous servir de l’un des outils ou kits SDK suivants :

• Outil Copier des données
• portail Azure
• Kit de développement logiciel (SDK) .NET
• sdk Python
• Azure PowerShell
• REST API
• modèle Azure Resource Manager

Créer un service lié REST à l’aide de l’interface utilisateur

Procédez comme suit pour créer un service lié REST dans l’interface utilisateur du portail Azure.

1. Accédez à l’onglet Gérer dans votre espace de travail Azure Data Factory ou Synapse, puis sélectionnez Services liés, puis Sélectionnez Nouveau :

   • Azure Data Factory.
   • Azure Synapse

   

2. Recherchez REST et sélectionnez le connecteur REST.

   

3. Configurez les informations du service, testez la connexion et créez le nouveau service lié.

   

Détails de configuration des connecteurs

Les sections suivantes fournissent des informations sur les propriétés utilisées pour définir les entités Data Factory propres au connecteur REST.

Propriétés du service lié

Les propriétés prises en charge pour le service lié REST sont les suivantes :

Pour les différents types d’authentification, consultez les sections correspondantes pour plus d’informations.

• Authentification de base
• Authentification du service principal
• Authentification des identifiants clients OAuth2
• Authentification via une identité managée affectée par le système
• Authentification de l'identité managée assignée par l'utilisateur
• Authentification anonyme

Utiliser une authentification de base

Définissez la propriété authenticationType sur De base. Outre les propriétés génériques décrites dans la section précédente, spécifiez les propriétés suivantes :

Exemple

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

Utiliser une authentification de principal de service

Définissez la propriété authenticationType sur AadServicePrincipal. Outre les propriétés génériques décrites dans la section précédente, spécifiez les propriétés suivantes :

Exemple 1 : utilisation de l’authentification de la clé du principal de service

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

Exemple 2 : utilisation de l’authentification par certificat du principal du service

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

Enregistrez le certificat du principal de service dans Azure Key Vault

Vous avez deux options pour enregistrer le certificat de principal de service dans Azure Key Vault :

• Option 1 :

  1. Convertissez le certificat de principal du service en chaîne de base64. Apprenez-en plus dans cet article.

  2. Enregistrez la chaîne base64 en tant que secret dans Azure Key Vault.

     

     

• Option 2 :

  Si vous ne pouvez pas télécharger le certificat à partir de Azure Key Vault, vous pouvez utiliser ce template pour enregistrer le certificat de principal de service converti en tant que secret dans Azure Key Vault.

  

Utilisez l’authentification des identifiants clients OAuth2

Définissez la propriété authenticationType sur OAuth2ClientCredential. Outre les propriétés génériques décrites dans la section précédente, spécifiez les propriétés suivantes :

Exemple

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

Utiliser l’authentification d’identité managée affectée par le système

Définissez la propriété authenticationType sur ManagedServiceIdentity. Outre les propriétés génériques décrites dans la section précédente, spécifiez les propriétés suivantes :

Exemple

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

Utiliser l'authentification par identité managée attribuée par l'utilisateur

Définissez la propriété authenticationType sur ManagedServiceIdentity. Outre les propriétés génériques décrites dans la section précédente, spécifiez les propriétés suivantes :

Exemple

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

Utilisation d’en-têtes d’authentification

En outre, vous pouvez configurer des en-têtes de demande pour l’authentification en plus des types d’authentification intégrés.

Exemple : Utilisation de l’authentification par clé 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"
        }
    }
}

Propriétés du jeu de données

Cette section contient la liste des propriétés prises en charge par le jeu de données REST.

Pour obtenir la liste complète des sections et propriétés disponibles pour la définition de jeux de données, consultez Jeux de données et services liés.

Pour copier des données à partir de REST, les propriétés suivantes sont prises en charge :

Si vous définissez requestMethod, additionalHeaders, requestBody, et paginationRules dans le jeu de données, l’opération de copie les supporte toujours as-is, bien que vous deviez utiliser le nouveau modèle dans l’activité à l’avenir.

Exemple :

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

Propriétés de l’activité de copie

Cette section fournit la liste des propriétés prises en charge par la source et le récepteur REST.

Pour obtenir la liste complète des sections et des propriétés permettant de définir des activités, consultez Pipelines.

REST en tant que source

Les propriétés prises en charge dans la section source de l’activité de copie sont les suivantes :

Exemple 1 : Utilisation de la méthode Get avec la pagination

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

Exemple 2 : Utilisation de la méthode 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 en tant que récepteur

Les propriétés prises en charge dans la section sink de l’activité de copie sont les suivantes :

Le connecteur REST en tant que récepteur fonctionne avec les API REST qui acceptent JSON. Les données sont envoyées en JSON selon le motif suivant. Si nécessaire, utilisez la cartographie du schéma d’activité de copie pour remodeler les données sources afin qu’elles s’adaptent à la charge utile attendue par l’API REST.

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

Exemple :

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

Propriétés du mappage de flux de données

REST est pris en charge dans les flux de données pour les jeux de données d’intégration et les jeux de données inline.

Transformation de la source

Transformation du récepteur

Vous pouvez définir les méthodes delete, insert, update et upsert, ainsi que les données de ligne relatives à envoyer au récepteur REST pour les opérations CRUD.

Exemple de script de flux de données

Remarquez l’utilisation d’une transformation de rangée d’alter avant l’évier pour indiquer à Data Factory quel type d’action effectuer avec votre évier REST. Cette action peut être d’insérer, de mettre à jour, d’activer ou de supprimer.

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

Prise en charge de la pagination

Lorsque vous copiez des données à partir d’API REST, l’API REST limite normalement la taille de la charge utile de réponse d’une seule requête à un nombre raisonnable. Pour retourner une grande quantité de données, il divise le résultat en plusieurs pages et exige que les appelants envoient des requêtes consécutives pour obtenir la page suivante de résultats. En général, la demande pour une page est dynamique et composée à partir des informations retournées dans la réponse de la page précédente.

Ce connecteur REST générique prend en charge les modèles de pagination suivants :

• URL absolue ou relative de la requête suivante = valeur de propriété dans le corps de la réponse en cours
• URL absolue ou relative de la requête suivante = valeur d’en-tête dans les en-têtes de la réponse en cours
• Paramètre de requête de la demande suivante = valeur de propriété dans le corps de la réponse en cours
• Paramètre de requête de la demande suivante = valeur d’en-tête dans les en-têtes de la réponse actuelle
• En-tête de la requête suivante = valeur de la propriété dans le corps de la réponse en cours
• En-tête de la requête suivante = valeur de l’en-tête dans les en-têtes de la réponse en cours

Les règles de pagination sont définies comme un dictionnaire dans le jeu de données, qui contient une ou plusieurs paires clé-valeur sensibles à la casse. La configuration est utilisée pour générer la requête à partir de la deuxième page. Le connecteur cesse d’itérer lorsqu’il reçoit le code d’état HTTP 204 (Aucun contenu), ou qu’une expression JSONPath dans paginationRules le site restitue null.

Clés prises en charge dans les règles de pagination :

Valeurs prises en charge dans les règles de pagination :

Exemples de règles de pagination

Cette section fournit une liste d’exemples de paramètres de règles de pagination.

Exemple 1 : variables dans QueryParameters

Cet exemple fournit les étapes de configuration pour envoyer plusieurs demandes dont les variables sont dans QueryParameters.

Plusieurs demandes :

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

Étape 1 : entrez sysparm_offset={offset} dans l’URL de base ou l’URL relative, comme indiqué dans les captures d’écran suivantes :

ou

Étape 2 : Définir les règles de pagination comme option 1 ou option 2 :

• Option1 : "QueryParameters.{offset}" : "RANGE:0:10000:1000"

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

Exemple 2 : variables dans AbsoluteUrl

Cet exemple fournit les étapes de configuration pour envoyer plusieurs demandes dont les variables se trouvent dans AbsoluteUrl.

Plusieurs demandes :

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

Étape 1 : entrez {id} soit dans l’URL de base dans la page de configuration du service lié ou dans l’URL relative dans le volet de connexion du jeu de données.

ou

Étape 2 : définissez les Règles de pagination sur "AbsoluteUrl.{id}" :"RANGE:1:100:1".

Exemple 3 : Variables dans les en-têtes

Cet exemple fournit les étapes de configuration pour envoyer plusieurs demandes dont les variables sont dans les en-têtes.

Plusieurs demandes :

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

Étape 1 : entrez {id} dans les En-têtes supplémentaires.

Étape 2 : Définissez les Règles de pagination sur "Headers.{id}" : "RANGE:0:100:10".

Exemple 4 : Les variables sont dans AbsoluteUrl/QueryParameters/Headers, la variable finale n’est pas prédéfinie et la condition finale est basée sur la réponse

Cet exemple fournit des étapes de configuration pour envoyer plusieurs requêtes dont les variables sont dans AbsoluteUrl/QueryParameters/Headers, mais la variable de fin n’est pas définie. Pour différentes réponses, différents paramètres de règle de condition de fin sont affichés dans l’exemple 4.1-4.6.

Plusieurs demandes :

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

Deux réponses sont rencontrées dans cet exemple :

Réponse 1 :

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

Réponse 2 :

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

Étape 1 : définissez la plage de Règles de pagination comme Example 1 et laissez la fin de la plage vide en tant que "AbsoluteUrl.{offset}": "RANGE:0::1000".

Étape 2 : définissez des règles de condition de fin différentes en fonction des dernières réponses. Consultez les exemples ci-dessous :

• Exemple 4.1 : la pagination se termine quand la valeur du nœud spécifique dans la réponse est vide

  L’API REST retourne la dernière réponse dans la structure suivante :

  {
      Data: []
  }
  

  Définissez la règle de condition de fin sur "EndCondition:$.data": "Empty" pour terminer la pagination quand la valeur du nœud spécifique dans la réponse est vide.

  

• Exemple 4.2 : La pagination se termine lorsque la valeur du nœud spécifique en réponse n’existe plus

  L’API REST retourne la dernière réponse dans la structure suivante :

  {}
  

  Définissez la règle de condition de fin sur « EndCondition :$.data » : « NonExist » pour mettre fin à la pagination lorsque la valeur du nœud spécifique en réponse n’existe pas.

  

• Exemple 4.3 : la pagination se termine quand la valeur du nœud spécifique dans la réponse existe

  L’API REST retourne la dernière réponse dans la structure suivante :

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

  Définissez la règle de condition de fin sur "EndCondition:$.Complete": "Exist" pour terminer la pagination quand la valeur du nœud spécifique dans la réponse existe.

  

• Exemple 4.4 : la pagination se termine quand la valeur du nœud spécifique dans la réponse est une valeur constante définie par l’utilisateur

  L’API REST retourne la réponse dans la structure suivante :

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

  ......

  Et la dernière réponse est présentée dans la structure ci-après :

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

  Définissez la règle de condition de fin sur "EndCondition:$.Complete": "Const:true" pour terminer la pagination quand la valeur du nœud spécifique dans la réponse est une valeur constante définie par l’utilisateur.

  

• Exemple 4.5 : La pagination se termine lorsque la valeur de la touche d’en-tête en réponse est égale à une valeur const définie par l’utilisateur

  Les clés d’en-tête dans les réponses de l’API REST sont affichées dans la structure ci-dessous :

  En-tête de réponse 1 : header(Complete->0)
  ......
  Dernier en-tête de réponse : header(Complete->1)
  

  Définissez la règle de fin condition comme « EndCondition :headers. Complete » : « Const :1 » pour terminer la pagination lorsque la valeur de la touche d’en-tête en réponse est égale à une valeur const définie par l’utilisateur.

  

• Exemple 4.6 : la pagination se termine quand la clé existe dans l’en-tête de réponse

  Les clés d’en-tête dans les réponses de l’API REST sont affichées dans la structure ci-dessous :

  En-tête de réponse 1 : header()
  ......
  Dernier en-tête de réponse : header(CompleteTime->20220920)
  

  Définissez la règle de la condition de fin sur "EndCondition:headers.CompleteTime": "Exist" pour terminer la pagination quand la clé existe dans l’en-tête de réponse.

  

Exemple 5 : Définir la condition de fin pour éviter les requêtes sans fin lorsque la règle de plage n’est pas définie

Cet exemple fournit les étapes de configuration permettant d’envoyer plusieurs requêtes lorsque la règle de plage n’est pas utilisée. La condition de fin peut être définie. Reportez-vous à l’exemple 4.1-4.6 pour éviter les demandes sans fin. L’API REST retourne une réponse dans la structure suivante. Dans ce cas, l’URL de la page suivante est représentée dans 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 dernière réponse est :

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

Étape 1 : définissez les Règles de pagination sur "AbsoluteUrl": "$.paging.next".

Étape 2 : Si next dans la dernière réponse est toujours identique à l’URL de la dernière requête et n’est pas vide, le processus envoie des requêtes sans fin. Utilisez la condition de fin pour éviter les demandes sans fin. Par conséquent, fixez la règle de la condition finale en vous référant aux exemples 4.1 à 4.6.

Exemple 6 : Définir le nombre maximal de requêtes pour éviter les requêtes sans fin

Définissez MaxRequestNumber pour éviter les demandes sans fin, comme illustré dans la capture d’écran suivante :

Exemple 7 : La règle de pagination RFC 5988 est prise en charge par défaut

Le backend obtient automatiquement l’URL suivante en fonction des liens de style RFC 5988 dans l’en-tête.

Exemple 8a : l'URL de la requête suivante se trouve dans le corps de la réponse lors de l'utilisation de la pagination dans les flux de données de mappage

Cet exemple indique comment définir la règle de pagination et la règle de la condition de fin dans les flux de données de mappage quand l’URL de la demande suivante provient du corps de la réponse.

Le schéma de réponse est illustré ci-dessous :

Les règles de pagination doivent être définies comme dans la capture d’écran suivante :

Par défaut, la pagination s’arrête lorsque body.{@odata.nextLink} la page est nulle ou vide.

Mais si la valeur de @odata.nextLink dans le corps de la dernière réponse est égale à la dernière URL de requête, cela conduit à une boucle sans fin. Pour éviter cette condition, définissez des règles de condition de fin.

• Si la Valeur dans la dernière réponse est Vide, la règle de la condition de fin peut être définie comme suit :

  

• Si la valeur de la clé complète dans l’en-tête de réponse est égale à true et indique la fin de la pagination, la règle de la condition de fin peut être définie comme suit :

  

Exemple 8b : l'URL de la requête suivante se trouve dans le corps de la réponse lors de l'utilisation de la pagination dans l'activité de copie

Cet exemple montre comment définir la règle de pagination dans une activité de copie lorsque l’URL de la prochaine requête est contenue dans le corps de la réponse.

Le schéma de réponse est illustré ci-dessous :

Les règles de pagination doivent être définies comme indiqué dans la capture d'écran suivante :

Exemple 9 : le format de réponse est XML et l’URL de la demande suivante provient du corps de la réponse en cas d’utilisation de la pagination dans le flux de données de mappage

Cet exemple indique comment définir la règle de pagination dans les flux de données de mappage quand le format de réponse est XML et l’URL de la demande suivante provient du corps de la réponse. Comme montré dans la capture d’écran suivante, la première URL est https://< user.dfs.core.windows.net/bugfix/test/movie_1.xml>

Le schéma de réponse est illustré ci-dessous :

La syntaxe de la règle de pagination est identique à l’exemple 8 et doit être définie comme dans l’exemple ci-dessous :

Exporter la réponse JSON en l’état

Vous pouvez utiliser le connecteur REST pour exporter la réponse JSON d’une API REST as-is vers différents systèmes de stockage basés sur des fichiers (récepteurs). Pour permettre ce comportement de copie indépendant du schéma, utilisez la correspondance de schéma par défaut (ne définissez aucune correspondance dans l’onglet Mappage de l’activité de copie).

Mappage de schéma

Pour copier des données d’un point de terminaison REST vers un récepteur tabulaire, consultez Mappage de schéma.

Contenu connexe

Pour obtenir la liste des magasins de données pris en charge par l’activité de copie en tant que sources et récepteurs dans Azure Data Factory, consultez Magasins de données et formats pris en charge.