Kopieren und Transformieren von Daten von und zu einem REST-Endpunkt mithilfe von Azure Data Factory

Gilt für: Azure Data Factory Azure Synapse Analytics

In diesem Artikel wird beschrieben, wie Sie die Kopieraktivität in Azure Data Factory verwenden, um Daten von und zu einem REST-Endpunkt zu kopieren. Der Artikel baut auf Copy Activity in Azure Data Factory auf, die eine allgemeine Übersicht über kopieraktivität darstellt.

Die Unterschiede zwischen diesem REST-Connector, dem HTTP-Connector und dem Web-Table-Connector sind:

• REST-Connector: Dieser unterstützt insbesondere das Kopieren von Daten aus RESTful-APIs.
• Der HTTP-Connector ist generisch, um Daten von jedem HTTP-Endpunkt abzurufen, zum Beispiel um eine Datei herunterzuladen. Vor diesem REST-Connector könnte man den HTTP-Connector nutzen, um Daten aus RESTful-APIs zu kopieren, die zwar unterstützt werden, aber weniger funktional sind als der REST-Connector.
• Webtabellen-Konnektor: Der extrahiert Tabelleninhalte aus einer HTML-Webseite.

Unterstützte Funktionen

Dieser REST-Connector wird für die folgenden Funktionen unterstützt:

(1) Azure Integrationslaufzeit (2) Selbst gehostete Integrationslaufzeit

Eine Liste der als Quellen/Senken unterstützten Datenspeicher finden Sie unter Unterstützte Datenspeicher.

Dieser allgemeine REST-Connector unterstützt Folgendes:

• Daten von einem REST-Endpunkt mit den GET - oder POST-Methoden kopieren und Daten auf einen REST-Endpunkt mit den POST-, PUT- oder PATCH-Methoden kopieren.
• Datenkopierung mittels Verwendung einer der folgenden Authentifizierungen: Anonym,Basic, Service Principal, OAuth2 Client Credential, System Assigned Managed Identity und User Assigned Managed Identity.
• Paginierung in den REST-APIs.
• Wenn REST die Quelle ist: Kopieren der unveränderten REST-JSON-Antwort oder Analysieren der Antwort mithilfe der Schemazuordnung. In JSON wird lediglich die Antwortnutzlast unterstützt.

Voraussetzungen

Wenn sich Ihr Datenspeicher in einem lokalen Netzwerk, einem Azure virtuellen Netzwerk oder amazon Virtual Private Cloud befindet, müssen Sie eine self-gehostete Integrationslaufzeit konfigurieren, um eine Verbindung damit herzustellen.

Wenn Ihr Datenspeicher ein verwalteter Clouddatendienst ist, können Sie die Azure Integration Runtime verwenden. Wenn der Zugriff auf IPs beschränkt ist, die in den Firewallregeln genehmigt wurden, können Sie der Zulassungsliste Azure Integration Runtime-IPs hinzufügen.

Sie können auch das Feature managed virtual network integration runtime in Azure Data Factory verwenden, um auf das lokale Netzwerk zuzugreifen, ohne eine selbst gehostete Integrationslaufzeit zu installieren und zu konfigurieren.

Weitere Informationen zu den von Data Factory unterstützten Netzwerksicherheitsmechanismen und -optionen finden Sie unter Datenzugriffsstrategien.

Erste Schritte

Zum Ausführen der Kopieraktivität mit einer Pipeline können Sie eines der folgenden Tools oder SDKs verwenden:

• Datenkopier-Werkzeug
• Azure Portal
• .NET SDK
• Python SDK
• Azure PowerShell
• REST-API
• Azure Resource Manager Vorlage

Erstellen eines verknüpften REST-Diensts über die Benutzeroberfläche

Führen Sie die folgenden Schritte aus, um einen REST-verknüpften Dienst in der benutzeroberfläche des Azure Portals zu erstellen.

1. Navigieren Sie in Ihrem Azure Data Factory- oder Synapse-Arbeitsbereich zur Registerkarte "Verwalten", und wählen Sie "Verknüpfte Dienste" und dann "Neu" aus:

   • Azure Data Factory
   • Azure Synapse

   

2. Suchen Sie nach REST, und wählen Sie den REST-Connector aus.

   

3. Konfigurieren Sie die Dienstdetails, testen Sie die Verbindung, und erstellen Sie den neuen verknüpften Dienst.

   

Details zur Connectorkonfiguration

In den folgenden Abschnitten finden Sie Details zu Eigenschaften, mit denen Sie Data Factory-Entitäten definieren können, die für den REST-Connector spezifisch sind.

Eigenschaften des verknüpften Diensts

Folgende Eigenschaften werden für den mit REST verknüpften Dienst unterstützt:

Ausführliche Informationen zu verschiedenen Authentifizierungstypen finden Sie in den entsprechenden Abschnitten.

• Standardauthentifizierung
• Dienstprinzipalauthentifizierung
• OAuth2-Client-Zugangsauthentifizierung
• Authentifizierung mit einer systemseitig zugewiesenen verwalteten Identität
• Authentifizierung mit einer benutzerseitig zugewiesenen verwalteten Identität
• Anonyme Authentifizierung

Verwenden der Standardauthentifizierung

Legen Sie die authenticationType-Eigenschaft auf Basic fest. Geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen generischen Eigenschaften die folgenden Eigenschaften an:

Beispiel

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

Verwenden Sie die Dienstprinzipalauthentifizierung

Legen Sie die authenticationType-Eigenschaft auf AadServicePrincipal fest. Geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen generischen Eigenschaften die folgenden Eigenschaften an:

Beispiel 1: Verwendung der Authentifizierung mit Dienstprinzipalschlüssel

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

Beispiel 2: Verwenden der Dienstprinzipal-Zertifikatauthentifizierung

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

Speichern des Dienstprinzipalzertifikats in Azure Key Vault

Sie haben zwei Möglichkeiten, das Dienstprinzipalzertifikat in Azure Key Vault zu speichern:

• Option 1:

  1. Konvertieren Sie das Dienstprinzipalzertifikat in eine Base64-Zeichenfolge. Mehr dazu erfahren Sie in diesem Artikel.

  2. Speichern Sie die base64-Zeichenfolge als geheimen Schlüssel in Azure Key Vault.

     

     

• Option 2:

  Wenn Sie das Zertifikat von Azure Key Vault nicht herunterladen können, können Sie dieses verwenden, um das konvertierte Dienstprinzipalzertifikat als geheimer Schlüssel in Azure Key Vault zu speichern.

  

Verwenden Sie die OAuth2-Client-Authentifizierung

Legen Sie die authenticationType-Eigenschaft auf OAuth2ClientCredential fest. Geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen generischen Eigenschaften die folgenden Eigenschaften an:

Beispiel

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

Verwenden der systemseitig zugewiesenen Authentifizierung mit einer verwalteten Identität

Legen Sie die authenticationType-Eigenschaft auf ManagedServiceIdentity fest. Geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen generischen Eigenschaften die folgenden Eigenschaften an:

Beispiel

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

Verwenden der benutzerseitig zugewiesenen Authentifizierung mit einer verwalteten Identität

Legen Sie die authenticationType-Eigenschaft auf ManagedServiceIdentity fest. Geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen generischen Eigenschaften die folgenden Eigenschaften an:

Beispiel

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

Authentifizierungs-Header verwenden

Darüber hinaus können Sie neben den integrierten Authentifizierungstypen auch Anforderungsheader für die Authentifizierung konfigurieren.

Beispiel: Verwenden der Authentifizierung mit API-Schlüssel

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

Dataset-Eigenschaften

Dieser Abschnitt enthält eine Liste der Eigenschaften, die das REST-Dataset unterstützt.

Eine vollständige Liste mit den Abschnitten und Eigenschaften, die zum Definieren von Datasets zur Verfügung stehen, finden Sie unter Datasets und verknüpfte Dienste.

Zum Kopieren von Daten aus REST werden die folgenden Eigenschaften unterstützt:

Wenn Sie , requestMethod, additionalHeaders, und requestBody im Datensatz setzenpaginationRules, unterstützt die Kopieroperation sie weiterhin as-is, obwohl Sie das neue Modell künftig in der Aktivität verwenden sollten.

Beispiel:

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

Eigenschaften der Kopieraktivität

Dieser Abschnitt enthält eine Liste der Eigenschaften, die von der REST-Quelle und -Senke unterstützt werden.

Eine vollständige Liste mit den verfügbaren Abschnitten und Eigenschaften zum Definieren von Aktivitäten finden Sie unter Pipelines.

REST als Quelle

Folgende Eigenschaften werden im Abschnitt source der Kopieraktivität unterstützt:

Beispiel 1: Verwenden der GET-Methode mit der Paginierung

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

Beispiel 2: Verwenden der POST-Methode

"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 als Senke

Folgende Eigenschaften werden im Abschnitt sink der Kopieraktivität unterstützt:

Ein REST-Connector als Senke funktioniert mit den REST-APIs, die JSON akzeptieren. Die Daten werden in JSON mit folgendem Muster gesendet. Verwenden Sie bei Bedarf das Kopierungsschema-Mapping , um die Quelldaten so umzugestalten, dass sie der erwarteten Nutzlast der REST-API entsprechen.

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

Beispiel:

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

Eigenschaften von Zuordnungsdatenflüssen

REST wird in Datenflüssen sowohl für Integrationsdatasets als auch für Inlinedatasets unterstützt.

Quellentransformation

Senkentransformation

Sie können die Methoden delete, insert, update und upsert sowie die relativen Zeilendaten festlegen, die für CRUD-Vorgänge an die REST-Senke gesendet werden sollen.

Beispiel-Datenflussskript

Beachten Sie die Verwendung einer Alter-Zeilen-Transformation vor dem Sink, um Data Factory anzuweisen, welche Art von Aktion mit Ihrem REST-Sink durchgeführt werden soll. Diese Aktion kann Einfügen, Aktualisieren, Upsert oder Löschen sein.

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

Unterstützung der Paginierung

Wenn Sie Daten aus REST-APIs kopieren, begrenzt die REST-API normalerweise die Antwortnutzlastgröße einer einzelnen Anfrage auf eine angemessene Zahl. Um eine große Datenmenge zurückzugeben, wird das Ergebnis auf mehrere Seiten aufgeteilt und die Anrufer müssen aufeinanderfolgende Anfragen senden, um die nächste Ergebnisseite zu erhalten. In der Regel ist die Anfrage für eine Seite dynamisch und besteht aus den Informationen, die in der Antwort auf die vorherige Seite zurückgegeben wurden.

Dieser generische REST-Connector unterstützt die folgenden Paginierungsmuster:

• Absolute oder relative URL der nächsten Anforderung = Eigenschaftswert im aktuellen Antworttext
• Absolute oder relative URL der nächsten Anforderung = Headerwert in aktuellen Antwortheadern
• Abfrageparameter der nächsten Anforderung = Eigenschaftswert im aktuellen Antworttext
• Abfrageparameter der nächsten Anforderung = Headerwert in aktuellen Antwortheadern
• Header der nächsten Anforderung = Eigenschaftswert im aktuellen Antworttext
• Der Header der nächsten Anfrage entspricht dem Headerwert in den aktuellen Antwortheadern.

Paginierungsregeln sind als Wörterbuch im Datensatz definiert, das ein oder mehrere groß- und kleinschreibungssensitive Schlüssel-Wert-Paare enthält. Die Konfiguration wird verwendet, um die Anfrage ab der zweiten Seite zu generieren. Der Connector hört auf zu iterieren, wenn er den HTTP-Statuscode 204 (No Content) erhält oder einer der JSONPath-Ausdrücke in null paginationRules zurückgibt.

In Paginierungsregeln unterstützte Schlüssel:

Unterstützte Werte in Paginierungsregeln:

Beispiele für Paginierungsregeln

In diesem Abschnitt werden Beispiele mit Einstellungen für Paginierungsregeln aufgeführt.

Beispiel 1: Variablen in QueryParameters

In diesem Beispiel werden die Konfigurationsschritte demonstriert, die durchgeführt werden müssen, um mehrere Anforderungen zu senden, deren Variablen sich in QueryParameters befinden.

Mehrere Anforderungen:

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

Schritt 1:Geben Sie sysparm_offset={offset} wie in den folgenden Screenshots gezeigt entweder in Basis-URL oder Relative URL ein:

oder

Schritt 2: Setzen Sie die Paginierungsregeln entweder als Option 1 oder Option 2:

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

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

Beispiel 2: Variablen in AbsoluteUrl

In diesem Beispiel werden die Konfigurationsschritte demonstriert, die durchgeführt werden müssen, um mehrere Anforderungen zu senden, deren Variablen sich in AbsoluteUrl befinden.

Mehrere Anforderungen:

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

Schritt 1: Geben Sie {id} entweder auf der Konfigurationsseite des verknüpften Diensts in Basis-URL oder im Bereich „Datasetverbindung“ in Relative URL ein.

oder

Schritt 2: Legen Sie die Pagination rules auf "AbsoluteUrl.{id}" :"RANGE:1:100:1" fest.

Beispiel 3: Variablen in Headern

In diesem Beispiel werden die Konfigurationsschritte gezeigt, die durchgeführt werden müssen, um mehrere Anforderungen zu senden, deren Variablen sich in Headern befinden.

Mehrere Anforderungen:

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

Schritt 1: Geben Sie {id} in Additional headers (Weitere Header) ein.

Schritt 2: Legen Sie die Paginierungsregeln auf "Headers.{id}" : "RANGE:0:100:10" fest.

Beispiel 4: Variablen befinden sich in AbsoluteUrl/QueryParameters/Headers, die Endvariable ist nicht vordefiniert und die Endbedingung basiert auf der Antwort

In diesem Beispiel werden Konfigurationsschritte zum Senden mehrerer Anforderungen bereitgestellt, deren Variablen sich in AbsoluteUrl/QueryParameters/Header befinden, die Endvariable jedoch nicht definiert ist. Für verschiedene Antworten werden in Beispiel 4.1-4.6 verschiedene Einstellungen der Endbedingungsregel gezeigt.

Mehrere Anforderungen:

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

In diesem Beispiel treten zwei Antworten auf:

Antwort 1:

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

Antwort 2:

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

Schritt 1: Legen Sie den Bereich der Pagination rules auf Beispiel 1 fest, und lassen Sie das Ende des Bereichs mit "AbsoluteUrl.{offset}": "RANGE:0::1000" leer.

Schritt 2: Legen Sie die unterschiedlichen Endbedingungsregeln gemäß der unterschiedlichen letzten Antworten fest. Hier einige Beispiele:

• Beispiel 4.1: Die Paginierung endet, wenn der Wert des bestimmten Knoten in der Antwort leer ist

  Die REST-API gibt die letzte Antwort in der folgenden Struktur zurück:

  {
      Data: []
  }
  

  Legen Sie die Endbedingungsregel auf "EndCondition:$.data": "Empty" fest, um die Paginierung zu beenden, wenn der Wert des bestimmten Knotens als Antwort leer ist.

  

• Beispiel 4.2: Die Paginierung endet, wenn der Wert des spezifischen Knotens als Antwort nicht existiert

  Die REST-API gibt die letzte Antwort in der folgenden Struktur zurück:

  {}
  

  Legen Sie die Endbedingungsregel als "EndCondition:$.data" fest: "NonExist" , um die Paginierung zu beenden, wenn der Wert des spezifischen Knotens in Antwort nicht vorhanden ist.

  

• Beispiel 4.3: Die Paginierung endet, wenn der Wert des bestimmten Knotens als Antwort vorhanden ist

  Die REST-API gibt die letzte Antwort in der folgenden Struktur zurück:

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

  Legen Sie die Endbedingungsregel auf "EndCondition:$.Complete": "Exist" fest, um die Paginierung zu beenden, wenn der Wert des bestimmten Knotens als Antwort vorhanden ist.

  

• Beispiel 4.4: Die Paginierung endet, wenn der Wert des bestimmten Knotens als Antwort ein benutzerdefinierter „const“-Wert ist

  Die REST-API gibt die Antwort in der folgenden Struktur zurück:

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

  ......

  Die letzte Antwort ist in der folgenden Struktur:

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

  Legen Sie die Endbedingungsregel auf "EndCondition:$.Complete": "Const:true" fest, um die Paginierung zu beenden, wenn der Wert des bestimmten Knotens als Antwort ein benutzerdefinierter „const“-Wert ist.

  

• Beispiel 4.5: Die Paginierung endet, wenn der Wert des Header-Schlüssels als Antwort einem benutzerdefinierten Const-Wert entspricht

  Die Headerschlüssel in REST-API-Antworten werden in der folgenden Struktur angezeigt:

  Antwortkopfzeile 1: header(Complete->0)
  ......
  „Letzte Antwort“-Header: header(Complete->1)
  

  Setze die Endbedingungsregel als "EndCondition:headers. Complete": "Const:1", um die Paginierung zu beenden, wenn der Wert des Header-Schlüssels als Antwort einem benutzerdefinierten Const-Wert entspricht.

  

• Beispiel 4.6: Die Paginierung endet, wenn der Schlüssel im Antwortheader vorhanden ist

  Die Headerschlüssel in REST-API-Antworten werden in der folgenden Struktur angezeigt:

  Antwortkopfzeile 1: header()
  ......
  „Letzte Antwort“-Header: header(CompleteTime->20220920)
  

  Legen Sie die Endbedingungsregel auf "EndCondition:headers.CompleteTime": "Exist" fest, um die Paginierung zu beenden, wenn der Schlüssel im Antwortheader vorhanden ist.

  

Beispiel 5: Setze Endbedingung, um endlose Anfragen zu vermeiden, wenn die Reichweitenregel nicht definiert ist

In diesem Beispiel werden die Konfigurationsschritte zum Senden mehrerer Anforderungen bereitgestellt, wenn die Bereichsregel nicht verwendet wird. Die Endbedingung kann wie in Beispiel 4.1-4.6 festgelegt werden, um endlose Anforderungen zu vermeiden. Die REST-API gibt eine Antwort in der folgenden Struktur zurück. In diesem Fall wird die URL der nächsten Seite in paging.next dargestellt.

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

Die letzte Antwort lautet:

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

Schritt 1: Legen Sie die Pagination rules auf "AbsoluteUrl": "$.paging.next" fest.

Schritt 2: Wenn next die letzte Antwort immer dieselbe wie die letzte Anfrage-URL ist und nicht leer ist, sendet der Prozess endlose Anfragen. Nutze die Endbedingung, um endlose Anfragen zu vermeiden. Setzen Sie daher die Endbedingungsregel, indem Sie sich auf die Beispiele 4.1 bis 4.6 beziehen.

Beispiel 6: Setze die maximale Anfrageanzahl, um endlose Anfragen zu vermeiden

Legen Sie MaxRequestNumber (die maximale Anzahl der Anforderungen) wie im folgenden Screenshot gezeigt fest, um endlose Anforderungen zu vermeiden:

Beispiel 7: Die Paginierungsregel RFC 5988 wird standardmäßig unterstützt

Das Backend erhält automatisch die nächste URL basierend auf den RFC-5988-Stil Links im Header.

Beispiel 8a: Die nächste Anforderungs-URL befindet sich im Antworttext, wenn die Paginierung in Zuordnungsdatenflüssen verwendet wird

In diesem Beispiel wird gezeigt, wie die Paginierungsregel und die Endbedingungsregel in Zuordnungsdatenflüssen festgelegt werden, wenn die nächste Anforderungs-URL aus dem Antworttext kommt.

Im Folgenden finden Sie das Antwortschema:

Die Paginierungsregeln sollte wie im folgenden Screenshot gezeigt festgelegt werden:

Standardmäßig endet die Paginierung, wenn body.{@odata.nextLink} null oder leer ist.

Wenn jedoch der Wert von @odata.nextLink im letzten Antwort-Body der letzten Anfrage-URL entspricht, führt das zu einer endlosen Schleife. Definieren Sie Endbedingungsregeln, um dies zu vermeiden.

• Wenn Wert in der letzten Antwort Leer ist, kann die Endbedingungsregel wie folgt festgelegt werden:

  

• Wenn der Wert des vollständigen Schlüssels im Antwortheader gleich TRUE ist, gibt dies das Ende der Paginierung an, und die Endbedingungsregel kann wie im Folgenden dargestellt festgelegt werden:

  

Beispiel 8b: Die nächste Anforderungs-URL befindet sich im Antworttext, wenn die Paginierung in der Copy-Aktivität verwendet wird

In diesem Beispiel wird veranschaulicht, wie die Paginierungsregel in einer Copy-Aktivität festgelegt wird, wenn die nächste Anforderungs-URL im Antworttext enthalten ist.

Im Folgenden finden Sie das Antwortschema:

Die Paginierungsregeln sollte wie im folgenden Screenshot gezeigt festgelegt werden:

Beispiel 9: Das Antwortformat ist XML, und die nächste Anforderungs-URL wird aus dem Antworttext erstellt, wenn die Paginierung in Zuordnungsdatenflüssen verwendet wird

In diesem Beispiel wird angegeben, wie die Paginierungsregel in Zuordnungsdatenflüssen festgelegt wird, wenn das Antwortformat XML und die nächste Anforderungs-URL aus dem Antworttext stammt. Wie im folgenden Screenshot gezeigt, lautet die erste URL https://< user.dfs.core.windows.net/bugfix/test/movie_1.xml>

Im Folgenden finden Sie das Antwortschema:

Die Syntax der Paginierungsregel ist mit der im Beispiel 8 identisch und sollte wie im folgenden Beispiel festgelegt werden:

Exportieren der unveränderten JSON-Antwort

Sie können den REST-Connector verwenden, um die JSON-Antwort einer REST-API as-is in verschiedene dateibasierte Speichersysteme (Senken) zu exportieren. Um dieses schema-agnostische Kopierverhalten zu aktivieren, verwenden Sie das Standard-Schema-Mapping (definieren Sie keine Abbildung im Tab Copy Activity Mapping).

Schemazuordnung

Informationen zum Kopieren von Daten aus dem REST-Endpunkt in eine tabellarische Senke finden Sie unter Schemazuordnung.

Zugehöriger Inhalt

Eine Liste der Datenspeicher, die von der Kopieraktivität als Quellen und Senken in Azure Data Factory unterstützt werden, finden Sie unter Unterstützte Datenspeicher und Formate.