Kopiera och transformera data från och till en REST-slutpunkt med hjälp av Azure Data Factory

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics

Den här artikeln beskriver hur du använder kopieringsaktivitet i Azure Data Factory för att kopiera data från och till en REST-slutpunkt. Artikeln bygger på Copy Activity i Azure Data Factory, som visar en allmän översikt över kopieringsaktivitet.

Skillnaderna mellan denna REST-kontakt, HTTP-kontakten och Web-tabellkontakten är:

• REST-anslutningsprogrammet stöder specifikt kopiering av data från RESTful-API:er.
• HTTP-koppling är generisk för att hämta data från vilken HTTP-endpoint som helst, till exempel för att ladda ner en fil. Innan denna REST-koppling kunde du använda HTTP-kontakten för att kopiera data från RESTful API:er, vilket stöds men fungerar mindre än REST-kopplaren.
• Webbtabell-anslutningsprogram extraherar tabellinnehåll från en HTML-webbsida.

Funktioner som stöds

Den här REST-anslutningsappen stöds för följande funktioner:

(1) Azure integration runtime (2) Lokalt installerad integrationskörning

En lista över datalager som stöds som källor/mottagare finns i Datalager som stöds.

Mer specifikt stöder den här allmänna REST-anslutningsappen:

• Kopiera data från en REST-endpoint med GET- eller POST-metoderna och kopiera data till en REST-endpoint med hjälp av POST-, PUT- eller PATCH-metoderna.
• Kopiera data genom att använda en av följande autentiseringar: Anonym,Basic, Service Principal, OAuth2 Client Credential, System Assigned Managed Identity och User Assigned Managed Identity.
• Sidnumrering i REST-API:erna.
• För REST som källa kopierar du REST JSON-svaret som det är eller parsar det med hjälp av schemamappning. Endast svarspayload i JSON stöds.

Förutsättningar

Om ditt datalager finns i ett lokalt nätverk, ett Azure virtuellt nätverk eller Amazon Virtual Private Cloud måste du konfigurera en självhostad integrationskörning för att ansluta till den.

Om ditt datalager är en hanterad molndatatjänst kan du använda Azure Integration Runtime. Om åtkomsten är begränsad till IP-adresser som är godkända i brandväggsreglerna kan du lägga till Azure Integration Runtime IP-adresser i listan över tillåtna.

Du kan också använda funktionen hanterad virtuell nätverksintegrering i Azure Data Factory för att få åtkomst till det lokala nätverket utan att installera och konfigurera en integrationskörning med egen värd.

Mer information om de nätverkssäkerhetsmekanismer och alternativ som stöds av Data Factory finns i Strategier för dataåtkomst.

Kom igång

Om du vill utföra kopieringsaktiviteten med en pipeline kan du använda något av följande verktyg eller SDK:er:

• Kopiera data-verktyget
• Azure Portal
• .NET SDK
• Python SDK
• Azure PowerShell
• REST-API
• mall för Azure Resource Manager

Skapa en REST-länkad tjänst med hjälp av användargränssnittet

Använd följande steg för att skapa en REST-länkad tjänst i användargränssnittet för Azure portalen.

1. Bläddra till fliken Hantera i din Azure Data Factory- eller Synapse-arbetsyta och välj Länkade tjänster och välj sedan Nytt:

   • Azure Data Factory
   • Azure Synapse

   

2. Sök efter REST och välj REST-anslutningsappen.

   

3. Konfigurera tjänstinformationen, testa anslutningen och skapa den nya länkade tjänsten.

   

Konfigurationsinformation för anslutningsprogram

Följande avsnitt innehåller information om egenskaper som du kan använda för att definiera Data Factory-entiteter som är specifika för REST-anslutningsappen.

Länkade tjänstegenskaper

Följande egenskaper stöds för den REST-länkade tjänsten:

Information om olika autentiseringstyper finns i motsvarande avsnitt.

• Grundläggande autentisering
• Autentisering av service principal
• OAuth2 klientinloggningsautentisering
• Autentisering med systemtilldelad hanterad identitet
• Användartilldelad hanterad identitetsautentisering
• Anonym autentisering

Använda grundläggande autentisering

Ange egenskapen authenticationType till Basic. Förutom de allmänna egenskaper som beskrivs i föregående avsnitt anger du följande egenskaper:

Exempel

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

Använda autentisering med tjänsthuvudnamn

Ange egenskapen authenticationType till AadServicePrincipal. Förutom de allmänna egenskaper som beskrivs i föregående avsnitt anger du följande egenskaper:

Exempel 1: Använda autentisering med tjänstehuvudnyckel

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

Exempel 2: Använda tjänstehuvudnamns certifikatautentisering

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

Spara certifikatet för tjänstens huvudnamn i Azure Key Vault

Du har två alternativ för att spara certifikatet för tjänstens huvudnamn i Azure Key Vault:

• Alternativ 1

  1. Konvertera certifikatet för tjänstens huvudnamn till en base64-sträng. Läs mer i den här artikeln.

  2. Spara base64-strängen som en hemlighet i Azure Key Vault.

     

     

• Alternativ 2

  Om du inte kan ladda ned certifikatet från Azure Key Vault kan du använda det här template för att spara det konverterade certifikatet för tjänstens huvudnamn som en hemlighet i Azure Key Vault.

  

Använd OAuth2 klientautentisering

Ange egenskapen authenticationType till OAuth2ClientCredential. Förutom de allmänna egenskaper som beskrivs i föregående avsnitt anger du följande egenskaper:

Exempel

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

Använda systemtilldelad hanterad identitetsautentisering

Ange egenskapen authenticationType till ManagedServiceIdentity. Förutom de allmänna egenskaper som beskrivs i föregående avsnitt anger du följande egenskaper:

Exempel

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

Använda användartilldelad hanterad identitetsautentisering

Ange egenskapen authenticationType till ManagedServiceIdentity. Förutom de allmänna egenskaper som beskrivs i föregående avsnitt anger du följande egenskaper:

Exempel

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

Använda autentiseringshuvuden

Dessutom kan du konfigurera begärandehuvuden för autentisering tillsammans med de inbyggda autentiseringstyperna.

Exempel: Använda API-nyckelautentisering

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

Egenskaper för datauppsättning

Det här avsnittet innehåller en lista över egenskaper som REST-datauppsättningen stöder.

En fullständig lista över avsnitt och egenskaper som är tillgängliga för att definiera datauppsättningar finns i Datauppsättningar och länkade tjänster.

Följande egenskaper stöds för att kopiera data från REST:

Om du sätter requestMethod, additionalHeaders, requestBody, och paginationRules i datasetet stöder kopieringsoperationen dem fortfarande as-is, även om du bör använda den nya modellen i aktiviteten framöver.

Exempel:

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

Egenskaper för kopieringsaktivitet

Det här avsnittet innehåller en lista över egenskaper som stöds av REST-källan och mottagaren.

En fullständig lista över avsnitt och egenskaper som är tillgängliga för att definiera aktiviteter finns i Pipelines.

REST som källa

Följande egenskaper stöds i källsektionen för kopieringsaktiviteten:

Exempel 1: Använda metoden Hämta med sidnumrering

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

Exempel 2: Använda postmetoden

"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 som slutpunkt

Följande egenskaper stöds i avsnittet för kopieringsaktivitetens sänke:

REST-anslutaren som mottagare fungerar med REST-API:er som accepterar JSON. Datan skickas i JSON med följande mönster. Vid behov används kopieringsaktivitetsschemakartläggningen för att omforma källdatan så att den överensstämmer med den förväntade nyttolasten av REST API:et.

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

Exempel:

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

Mappa dataflödesegenskaper

REST stöds i dataflöden för både integreringsdatauppsättningar och infogade datauppsättningar.

Källtransformering

Transformering av mottagare

Du kan ange metoderna delete, insert, update och upsert samt de relativa raddata som ska skickas till REST-mottagaren för CRUD-åtgärder.

Exempel på dataflödesskript

Lägg märke till användningen av en alter row-transformation före sänkan för att instruera Data Factory vilken typ av åtgärd som ska tas med din REST-sänka. Den åtgärden kan vara infoga, uppdatera, upsert eller ta bort.

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

Stöd för sidnumrering

När du kopierar data från REST-API:er begränsar REST-API:et normalt storleken på svarspayloaden för en enskild förfrågan till ett rimligt antal. För att returnera en stor mängd data delar den upp resultatet i flera sidor och kräver att anropare skickar på varandra följande förfrågningar för att få nästa resultatsida. Vanligtvis är förfrågan om en sida dynamisk och sammansatt av informationen som returnerades i svaret för föregående sida.

Den här allmänna REST-anslutningsappen stöder följande sidnumreringsmönster:

• Nästa begärans absoluta eller relativa URL = egenskapsvärde i den aktuella svarstexten
• Nästa begärans absoluta eller relativa URL = rubrikvärde i aktuella svarshuvuden
• Frågeparametern för nästa begäran = egenskapsvärdet i den aktuella svarstexten
• Nästa begärans frågeparameter = rubrikvärde i aktuella svarshuvuden
• Nästa begärans huvud = egenskapsvärde i aktuell svarstext
• Nästa begärans sidhuvud = rubrikvärde i aktuella svarshuvuden

Pagineringsregler definieras som en ordbok i datamängden, som innehåller ett eller flera kasuskänsliga nyckel-värde-par. Konfigurationen används för att generera förfrågan med start från andra sidan. Connectorn slutar iterera när den får HTTP-statuskod 204 (No Content), eller något av JSONPath-uttrycken i paginationRules returnerar null.

Nycklar som stöds i sidnumreringsregler:

Värden som stöds i sidnumreringsregler:

Exempel på sidnumreringsregler

Det här avsnittet innehåller en lista med exempel på inställningar för sidnumreringsregler.

Exempel 1: Variabler i QueryParameters

Det här exemplet innehåller konfigurationsstegen för att skicka flera begäranden vars variabler finns i QueryParameters.

Flera begäranden:

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

Steg 1: Ange sysparm_offset={offset} antingen i bas-URL eller relativ URL enligt följande skärmbilder:

eller

Steg 2: Sätt pagineringsregler som antingen alternativ 1 eller alternativ 2:

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

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

Exempel 2: Variabler i AbsoluteUrl

Det här exemplet innehåller konfigurationsstegen för att skicka flera begäranden vars variabler finns i AbsoluteUrl.

Flera begäranden:

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

Steg 1: Ange {id} antingen i bas-URL:en på konfigurationssidan för den länkade tjänsten eller relativ URL i fönstret för datauppsättningsanslutning.

eller

Steg 2: Ange sidnumreringsregler som "AbsoluteUrl.{ id}" :"RANGE:1:100:1".

Exempel 3: Variabler i huvuden

Det här exemplet innehåller konfigurationsstegen för att skicka flera begäranden vars variabler finns i Rubriker.

Flera begäranden:

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

Steg 1: Indata {id} i Ytterligare rubriker.

Steg 2: Ange sidnumreringsregler som "Rubriker.{ id}" : "RANGE:0:100:10".

Exempel 4: Variabler finns i AbsoluteUrl/QueryParameters/Headers, slutvariabeln är inte fördefinierad och slutvillkoret baseras på svaret

Det här exemplet innehåller konfigurationssteg för att skicka flera begäranden vars variabler finns i AbsoluteUrl/QueryParameters/Headers men slutvariabeln har inte definierats. För olika svar visas olika regelinställningar för slutvillkor i exempel 4.1-4.6.

Flera begäranden:

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

Två svar förekommer i detta exempel:

Svar 1:

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

Svar 2:

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

Steg 1: Ange intervallet för sidnumreringsregler som Exempel 1 och låt slutet av intervallet vara tomt som "AbsoluteUrl.{ offset}": "RANGE:0::1000".

Steg 2: Ange olika regler för slutvillkor enligt olika senaste svar. Se exempel nedan:

• Exempel 4.1: Sidnumreringen slutar när värdet för den specifika noden i svaret är tomt

  REST-API:et returnerar det sista svaret i följande struktur:

  {
      Data: []
  }
  

  Ange slutvillkorsregeln som "EndCondition:$.data": "Tom" för att avsluta sidnumreringen när värdet för den specifika noden som svar är tomt.

  

• Exempel 4.2: Pagineringen slutar när värdet för den specifika noden som svar inte existerar

  REST-API:et returnerar det sista svaret i följande struktur:

  {}
  

  Ange slutvillkorsregeln som "EndCondition:$.data": "NonExist" för att avsluta sidnumreringen när värdet för den specifika noden som svar inte finns.

  

• Exempel 4.3: Sidnumreringen slutar när värdet för den specifika noden i svaret finns

  REST-API:et returnerar det sista svaret i följande struktur:

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

  Ange slutvillkorsregeln som "EndCondition:$.Complete": "Exist" för att avsluta pagineringen när värdet för den specifika noden finns i svaret.

  

• Exempel 4.4: Sidnumreringen upphör när värdet för den specifika noden som svar är ett användardefinierat const-värde

  REST-API:et returnerar svaret i följande struktur:

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

  ......

  Och det sista svaret finns i följande struktur:

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

  Ange slutvillkorsregeln som "EndCondition:$.Complete": "Const:true" för att avsluta pagineringen när värdet av den specifika noden i svaret är ett användardefinierat const value.

  

• Exempel 4.5: Pagineringen slutar när värdet på headernyckeln som svar är lika med ett användardefinierat const-värde

  Huvudnycklarna i REST API-svar visas i strukturen nedan:

  Svarsrubrik 1: header(Complete->0)
  ......
  Senaste svarsrubrik: header(Complete->1)
  

  Sätt slutvillkorsregeln som "EndCondition:headers. Complete": "Const:1" för att avsluta pagineringen när värdet på headernyckeln i svar är lika med ett användardefinierat const-värde.

  

• Exempel 4.6: Sidnumreringen slutar när nyckeln finns i svarshuvudet

  Huvudnycklarna i REST API-svar visas i strukturen nedan:

  Svarsrubrik 1: header()
  ......
  Senaste svarsrubrik: header(CompleteTime->20220920)
  

  Ange slutvillkorsregeln som "EndCondition:headers.CompleteTime": "Finns" för att avsluta pagineringen när nyckeln finns i svarshuvudet.

  

Exempel 5: Sätt slutvillkor för att undvika oändliga förfrågningar när räckviddsregeln inte är definierad

Det här exemplet innehåller konfigurationsstegen för att skicka flera begäranden när intervallregeln inte används. Slutvillkoret kan anges i exempel 4.1-4.6 för att undvika oändliga begäranden. REST API:et returnerar svar i följande struktur, där nästa sidas URL representeras i 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="
    }
}
...

Det sista svaret är:

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

Steg 1: Ange paginering regler som "AbsoluteUrl": "$.paging.next".

Steg 2: Om next det sista svaret alltid är samma som den senaste förfrågan-URL:en och inte är tomt, skickar processen oändliga förfrågningar. Använd slutvillkoret för att undvika oändliga förfrågningar. Sätt därför slutvillkorsregeln genom att hänvisa till exempel 4.1 till 4.6.

Exempel 6: Sätt maxantalet förfrågningar för att undvika oändliga förfrågningar

Ange MaxRequestNumber för att undvika oändliga begäranden enligt följande skärmbild:

Exempel 7: RFC 5988-pagineringsregeln stöds som standard

Backend får automatiskt nästa URL baserat på RFC 5988-stilens länkar i headern.

Exempel 8a: Nästa begärande-URL finns i svarstexten när sidnumrering används i mappning av dataflöden

Det här exemplet anger hur du anger sidnumreringsregeln och regeln för slutvillkor i mappningen av dataflöden när nästa begärans URL kommer från svarstexten.

Svarsschemat visas nedan:

Sidnumreringsreglerna ska anges som följande skärmbild:

Som standard slutar pagineringen när body.{@odata.nextLink} är null eller tom.

Men om värdet på @odata.nextLink i sista svarets kropp är lika med den senaste förfrågan-URL:en, leder det till en oändlig loop. För att undvika det här villkoret definierar du regler för slutvillkor.

• Om Värdet i det senaste svaret är Tomt kan regeln för slutvillkor anges enligt nedan:

  

• Om värdet för den fullständiga nyckeln i svarshuvudet är sant och anger att sidnumreringen är slut, kan regeln för slutvillkor anges enligt följande:

  

Exempel 8b: Nästa begärande-URL finns i svarstexten när sidnumrering används i kopieringsaktiviteten

Det här exemplet visar hur du anger sidnumreringsregeln i en kopieringsaktivitet när nästa url för begäran finns i svarstexten.

Svarsschemat visas nedan:

Sidnumreringsreglerna ska anges enligt följande skärmbild:

Exempel 9: Svarsformatet är XML och nästa begärande-URL kommer från svarstexten när sidnumrering används i mappning av dataflöden

Det här exemplet anger hur du anger sidnumreringsregeln i mappning av dataflöden när svarsformatet är XML och nästa begärande-URL kommer från svarstexten. Som visas på följande skärmdump är den första URL: en https://< user.dfs.core.windows.net/bugfix/test/movie_1.xml>

Svarsschemat visas nedan:

Syntaxen för sidnumreringsregeln är densamma som i Exempel 8 och bör anges som nedan i det här exemplet:

Exportera JSON-svar som det är

Du kan använda REST-anslutningsappen för att exportera ett REST API:s JSON-svar as-is till olika filbaserade lagringssystem (mottagare). För att aktivera detta schema-agnostiska kopieringsbeteende, använd standardschemakartläggning (definiera ingen mappning i fliken Copy Activity's mapping).

Kartläggning av schema

Om du vill kopiera data från REST-slutpunkten till tabulär lagring, se schemamappning.

Relaterat innehåll

En lista över databutiker som kopieringsaktivitet stöder som källor och mottagare i Azure Data Factory finns i Stödda databutiker och format.