Kopiowanie i przekształcanie danych z i do punktu końcowego REST przy użyciu usługi Azure Data Factory

DOTYCZY: Azure Data Factory Azure Synapse Analytics

W tym artykule opisano sposób używania działania kopiowania w usłudze Azure Data Factory do kopiowania danych do i z punktu końcowego REST. Artykuł opiera się na artykule działaniu kopiowania w usłudze Azure Data Factory, który zawiera ogólne omówienie działania kopiowania.

Różnica między tym łącznikiem REST, łącznikiem HTTP i łącznikiem tabel sieci Web jest następująca:

• Łącznik REST obsługuje kopiowanie danych z interfejsów API RESTful.
• Łącznik HTTP jest ogólny w celu pobrania danych z dowolnego punktu końcowego HTTP, na przykład w celu pobrania pliku. Przed wprowadzeniem tego łącznika REST mogłeś używać łącznika HTTP do kopiowania danych z API RESTful, co jest obsługiwane, ale mniej funkcjonalne w porównaniu do łącznika REST.
• Łącznik tabeli sieci Web wyodrębnia zawartość tabeli ze strony internetowej HTML.

Obsługiwane możliwości

Ten łącznik REST jest obsługiwany dla następujących funkcjonalności:

(1) Środowisko Azure Integration Runtime (2) Self-hosted Integration Runtime

Aby uzyskać listę magazynów danych obsługiwanych jako źródła/ujścia, zobacz Obsługiwane magazyny danych.

W szczególności ten ogólny łącznik REST obsługuje następujące elementy:

• Kopiowanie danych z punktu końcowego REST przy użyciu metod GET lub POST i kopiowanie danych do punktu końcowego REST przy użyciu metod POST, PUT lub PATCH .
• Kopiowanie danych przy użyciu jednego z następujących uwierzytelnień: anonimowe, podstawowe, główna usługa, poświadczenia klienta OAuth2, zarządzana tożsamość przypisana przez system, i zarządzana tożsamość przypisana przez użytkownika.
• Stronicowanie w interfejsach API REST.
• W przypadku użycia REST jako źródła należy skopiować odpowiedź JSON REST bez zmian lub przeanalizować ją przy użyciu mapowania schematu. Obsługiwany jest tylko ładunek odpowiedzi w formacie JSON .

Wymagania wstępne

Jeśli magazyn danych znajduje się wewnątrz sieci lokalnej, sieci wirtualnej Azure lub Amazon Virtual Private Cloud, musisz skonfigurować własne środowisko uruchomieniowe integracji, aby się z nim połączyć.

Jeśli magazyn danych jest zarządzaną usługą danych w chmurze, możesz użyć środowiska Azure Integration Runtime. Jeśli dostęp jest ograniczony do adresów IP zatwierdzonych w regułach zapory, możesz dodać adresy IP środowiska Azure Integration Runtime do listy dozwolonych.

Możesz również użyć funkcji zarządzanego środowiska uruchomieniowego integracji sieci wirtualnej w usłudze Azure Data Factory, aby uzyskać dostęp do sieci lokalnej bez instalowania i konfigurowania własnego środowiska uruchomieniowego integracji.

Aby uzyskać więcej informacji na temat mechanizmów zabezpieczeń sieci i opcji obsługiwanych przez usługę Data Factory, zobacz Strategie dostępu do danych.

Wprowadzenie

Aby wykonać działanie kopiowania za pomocą potoku, możesz użyć jednego z następujących narzędzi lub zestawów SDK:

• Narzędzie do kopiowania danych
• Portal Azure
• zestawu SDK platformy .NET
• Zestaw SDK dla języka Python
• Azure PowerShell
• API REST
• Szablon usługi Azure Resource Manager

Tworzenie połączonej usługi REST przy użyciu interfejsu użytkownika

Wykonaj poniższe kroki, aby utworzyć połączoną usługę REST w interfejsie użytkownika witryny Azure Portal.

1. Przejdź do karty Zarządzanie w obszarze roboczym usługi Azure Data Factory lub Synapse i wybierz pozycję Połączone usługi, a następnie wybierz pozycję Nowe:

   • Azure Data Factory
   • Azure Synapse

   

2. Wyszukaj REST i wybierz łącznik REST.

   

3. Skonfiguruj szczegóły usługi, przetestuj połączenie i utwórz nową połączoną usługę.

   

Szczegóły konfiguracji łącznika

Poniższe sekcje zawierają szczegółowe informacje o właściwościach, których można użyć do definiowania jednostek usługi Data Factory specyficznych dla łącznika REST.

Właściwości połączonej usługi

Następujące właściwości są obsługiwane w przypadku połączonej usługi REST:

Aby uzyskać szczegółowe informacje, zobacz odpowiednie sekcje dotyczące różnych typów uwierzytelniania.

• Uwierzytelnianie podstawowe
• Uwierzytelnianie głównej usługi
• Uwierzytelnianie poświadczeń klienta OAuth2
• Uwierzytelnianie zarządzanej tożsamości przydzielanej przez system
• Uwierzytelnianie za pomocą zarządzanej tożsamości przypisanej przez użytkownika
• Uwierzytelnianie anonimowe

Korzystanie z uwierzytelniania podstawowego

Ustaw właściwość authenticationType na Basic. Oprócz właściwości ogólnych opisanych w poprzedniej sekcji określ następujące właściwości:

Przykład

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

Użyj uwierzytelniania podmiotu usługi

Ustaw właściwość authenticationType na AadServicePrincipal. Oprócz właściwości ogólnych opisanych w poprzedniej sekcji określ następujące właściwości:

Przykład 1: Używanie uwierzytelniania klucza jednostki usługi

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

Przykład 2: Używanie uwierzytelniania certyfikatu jednostki usługi

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

Zapisz certyfikat jednostki usługi w usłudze Azure Key Vault

Istnieją dwie opcje zapisania certyfikatu jednostki usługi w usłudze Azure Key Vault:

• Opcja 1

  1. Przekonwertuj certyfikat jednostki usługi na ciąg base64. Dowiedz się więcej z tego artykułu.

  2. Zapisz ciąg base64 jako wpis tajny w usłudze Azure Key Vault.

     

     

• Opcja 2

  Jeśli nie możesz pobrać certyfikatu z usługi Azure Key Vault, możesz użyć tego szablonu , aby zapisać przekonwertowany certyfikat jednostki usługi jako wpis tajny w usłudze Azure Key Vault.

  

Korzystanie z uwierzytelniania poświadczeń klienta OAuth2

Ustaw właściwość authenticationType na OAuth2ClientCredential. Oprócz właściwości ogólnych opisanych w poprzedniej sekcji określ następujące właściwości:

Przykład

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

Korzystanie z uwierzytelniania tożsamości zarządzanej przypisanej przez system

Ustaw właściwość authenticationType na ManagedServiceIdentity. Oprócz właściwości ogólnych opisanych w poprzedniej sekcji określ następujące właściwości:

Przykład

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

Użycie uwierzytelniania tożsamości zarządzanej przez użytkownika

Ustaw właściwość authenticationType na ManagedServiceIdentity. Oprócz właściwości ogólnych opisanych w poprzedniej sekcji określ następujące właściwości:

Przykład

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

Używanie nagłówków uwierzytelniania

Ponadto można skonfigurować nagłówki żądań na potrzeby uwierzytelniania wraz z wbudowanymi typami uwierzytelniania.

Przykład: używanie uwierzytelniania klucza interfejsu 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"
        }
    }
}

Właściwości zestawu danych

Ta sekcja zawiera listę właściwości, które obsługuje zestaw danych REST.

Aby uzyskać pełną listę sekcji i właściwości dostępnych do definiowania zestawów danych, zobacz Zestawy danych i połączone usługi.

Aby skopiować dane z interfejsu REST, obsługiwane są następujące właściwości:

Jeśli ustawiłeś requestMethod, additionalHeaders, requestBody i paginationRules w zestawie danych, nadal jest obsługiwane as-is, jednak zaleca się użycie nowego modelu w przyszłości.

Przykład:

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

Właściwości działania kopiowania

Ta sekcja zawiera listę właściwości obsługiwanych przez źródło REST i odbiornik.

Aby uzyskać pełną listę sekcji i właściwości dostępnych do definiowania aktywności, zobacz Pipelines.

REST jako źródło

Następujące właściwości są obsługiwane w sekcji źródło działania kopiowania:

Przykład 1. Używanie metody Get z podziałem na strony

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

Przykład 2: Używanie metody 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 jako odbiornik

Następujące właściwości są obsługiwane w sekcji ujścia działania kopiowania:

Łącznik REST jako ujście współdziała z interfejsami API REST, które akceptują kod JSON. Dane zostaną wysłane w formacie JSON przy użyciu następującego wzorca. W razie potrzeby możesz użyć działania kopiowania mapowania schematu do przekształcenia danych źródłowych, aby pasowały do oczekiwanego ładunku dla interfejsu API REST.

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

Przykład:

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

Mapowanie właściwości przepływu danych

Interfejs REST jest obsługiwany w przepływach danych zarówno dla zestawów danych integracyjnych, jak i zestawów danych inline.

Przekształcanie źródła

Przekształcenie zbiornika

Można ustawić metody usuwania, wstawiania, aktualizowania i upsert, a także względne dane wierszy do wysyłania do ujścia REST dla operacji CRUD.

Przykładowy skrypt przepływu danych

Zwróć uwagę na użycie przekształcenia alter row przed elementem docelowym, aby poinstruować usługę ADF, jakiego typu akcji należy podjąć z elementem docelowym REST. Oznacza to, że wstawianie, aktualizowanie, upsert, usuwanie.

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

Obsługa stronicowania

Podczas kopiowania danych z interfejsów API REST zwykle interfejs API REST ogranicza rozmiar ładunku odpowiedzi pojedynczego żądania w rozsądnej liczbie; chociaż zwraca dużą ilość danych, dzieli wynik na wiele stron i wymaga od wywołujących wysyłania kolejnych żądań w celu uzyskania następnej strony wyniku. Zwykle żądanie jednej strony jest dynamiczne i składa się z informacji zwróconych z odpowiedzi poprzedniej strony.

Ten ogólny łącznik REST obsługuje następujące wzorce stronicowania:

• Adres URL następnego żądania, zarówno bezwzględny jak i względny, jest równy wartości właściwości w treści bieżącej odpowiedzi.
• Bezwzględny lub względny adres URL następnego żądania = wartość nagłówka w bieżących nagłówkach odpowiedzi
• Parametr zapytania następnego żądania = wartość właściwości w bieżącej treści odpowiedzi
• Parametr zapytania następnego żądania = wartość nagłówka w bieżących nagłówkach odpowiedzi
• Nagłówek następnego żądania = wartość właściwości w bieżącej treści odpowiedzi
• Nagłówek następnego żądania = wartość nagłówka w bieżących nagłówkach odpowiedzi

Reguły paginacji są definiowane jako słownik w zestawie danych, który zawiera co najmniej jedną parę klucz-wartość z uwzględnieniem wielkości liter. Konfiguracja zostanie użyta do wygenerowania żądania rozpoczynającego się od drugiej strony. Łącznik przestanie iterować, gdy otrzyma kod stanu HTTP 204 (Bez zawartości) lub gdy każde z wyrażeń JSONPath w "paginationRules" zwróci wartość null.

Obsługiwane klucze w regułach stronicowania:

Obsługiwane wartości w regułach stronicowania:

Przykłady reguł stronicowania

Ta sekcja zawiera listę przykładów ustawień reguł stronicowania.

Przykład 1: Zmienne w parametrach QueryParameters

W tym przykładzie przedstawiono kroki konfiguracji służące do wysyłania wielu żądań, których zmienne znajdują się w parametrach QueryParameters.

Wiele żądań:

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

Krok 1: Wprowadź sysparm_offset={offset} albo w podstawowym adresie URL lub względnym adresie URL, jak pokazano na poniższych zrzutach ekranu:

lub

Krok 2. Ustaw reguły stronicowania jako opcję 1 lub 2:

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

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

Przykład 2:Zmienne w pliku AbsoluteUrl

W tym przykładzie przedstawiono kroki konfiguracji służące do wysyłania wielu żądań, których zmienne znajdują się w pliku AbsoluteUrl.

Wiele żądań:

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

Krok 1: Dane wejściowe {id} w Podstawowym adresie URL na stronie konfiguracji połączonej usługi lub Względnym adresie URL w okienku połączenia zestawu danych.

lub

Krok 2: Ustaw reguły stronicowania jako "AbsoluteUrl.{id}" :"RANGE:1:100:1".

Przykład 3:Zmienne w nagłówkach

W tym przykładzie przedstawiono kroki konfiguracji służące do wysyłania wielu żądań, których zmienne znajdują się w nagłówkach.

Wiele żądań:

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

Krok 1. Wprowadzanie {id} w dodatkowych nagłówkach.

Krok 2: Ustaw zasady reguł stronicowania jako "Nagłówki.{id}" : "RANGE:0:100:10".

Przykład 4: Zmienne znajdują się w parametrach AbsoluteUrl/QueryParameters/Headers, zmienna końcowa nie jest wstępnie zdefiniowana, a warunek końcowy jest oparty na odpowiedzi

W tym przykładzie przedstawiono kroki konfiguracji służące do wysyłania wielu żądań, których zmienne znajdują się w parametrach AbsoluteUrl/QueryParameters/Headers, ale zmienna końcowa nie jest zdefiniowana. W przypadku różnych odpowiedzi różne ustawienia reguły warunku końcowego są wyświetlane w przykładzie 4.1-4.6.

Wiele żądań:

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

W tym przykładzie napotkano dwie odpowiedzi:

Odpowiedź 1:

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

Odpowiedź 2:

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

Krok 1. Ustaw zakres reguł stronicowania na przykład 1 i pozostaw koniec zakresu pusty jako "AbsoluteUrl.{ offset}": "RANGE:0::1000".

Krok 2. Ustaw różne reguły warunków końcowych zgodnie z różnymi ostatnimi odpowiedziami. Zobacz poniższe przykłady:

• Przykład 4.1: stronicowanie kończy się, gdy wartość określonego węzła w odpowiedzi jest pusta

  Interfejs API REST zwraca ostatnią odpowiedź w następującej strukturze:

  {
      Data: []
  }
  

  Ustaw regułę warunku końcowego na "EndCondition:$.data": "Empty", aby zakończyć paginację, gdy wartość określonego węzła w odpowiedzi jest pusta.

  

• Przykład 4.2: Stronicowanie kończy się, gdy w odpowiedzi nie ma wartości dla określonego węzła

  Interfejs API REST zwraca ostatnią odpowiedź w następującej strukturze:

  {}
  

  Ustaw regułę końcową jako "EndCondition:$.data": "NonExist", aby zakończyć stronicowanie, gdy wartość określonego węzła w odpowiedzi nie istnieje.

  

• Przykład 4.3: Stronicowanie zatrzymuje się, gdy w odpowiedzi pojawia się wartość określonego węzła

  Interfejs API REST zwraca ostatnią odpowiedź w następującej strukturze:

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

  Ustaw regułę warunku końcowego na "EndCondition:$.Complete": "Exist", aby zakończyć stronicowanie, gdy istnieje wartość określonego węzła w odpowiedzi.

  

• Przykład 4.4: stronicowanie kończy się, gdy wartość określonego węzła w odpowiedzi jest wartością const zdefiniowaną przez użytkownika

  Interfejs API REST zwraca odpowiedź w następującej strukturze:

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

  ......

  Ostatnia odpowiedź znajduje się w następującej strukturze:

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

  Ustaw regułę warunku końcowego na "EndCondition:$.Complete": "Const:true", aby zakończyć stronicowanie, gdy wartość określonego węzła w odpowiedzi jest zdefiniowaną przez użytkownika wartością stałą.

  

• Przykład 4.5: stronicowanie kończy się, gdy wartość klucza nagłówka w odpowiedzi jest równa wartości const zdefiniowanej przez użytkownika

  Klucze nagłówków w odpowiedziach REST API są przedstawione w strukturze poniżej:

  Nagłówek odpowiedzi 1: header(Complete->0)
  ......
  Nagłówek ostatniej odpowiedzi: header(Complete->1)
  

  Ustaw regułę warunku końcowego jako "EndCondition:headers. Complete": "Const:1" , aby zakończyć stronicowanie, gdy wartość klucza nagłówka w odpowiedzi jest równa wartości const zdefiniowanej przez użytkownika.

  

• Przykład 4.6: stronicowanie kończy się, gdy klucz istnieje w nagłówku odpowiedzi

  Klucze nagłówków w odpowiedziach REST API są przedstawione w strukturze poniżej:

  Nagłówek odpowiedzi 1: header()
  ......
  Nagłówek ostatniej odpowiedzi: header(CompleteTime->20220920)
  

  Ustaw regułę warunku końcowego jako "EndCondition:headers.CompleteTime": "Istnieje", aby zakończyć stronicowanie, gdy klucz istnieje w nagłówku odpowiedzi.

  

Przykład 5: Ustawianie warunku końcowego w celu uniknięcia niekończących się żądań, gdy reguła zakresu nie jest zdefiniowana

W tym przykładzie przedstawiono kroki konfiguracji służące do wysyłania wielu żądań, gdy reguła zakresu nie jest używana. Warunek końcowy można ustawić, odwołując się do przykładów 4.1-4.6, aby uniknąć niekończących się żądań. Interfejs API REST zwraca odpowiedź w następującej strukturze, w której adres URL następnej strony jest reprezentowany w 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="
    }
}
...

Ostatnia odpowiedź to:

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

Krok 1. Ustaw reguły stronicowania jako "AbsoluteUrl": "$.paging.next".

Krok 2. Jeśli next w ostatniej odpowiedzi jest zawsze taki sam adres URL ostatniego żądania i nie jest pusty, żądania niekończące się będą wysyłane. Warunek końcowy może służyć do unikania niekończących się żądań. W związku z tym ustaw regułę warunku końcowego na przykład 4.1-4.6.

Przykład 6: Ustawianie maksymalnej liczby żądań, aby uniknąć niekończącego się żądania

Ustaw wartość MaxRequestNumber , aby uniknąć niekończącego się żądania, jak pokazano na poniższym zrzucie ekranu:

Przykład 7: Reguła stronicowania RFC 5988 jest domyślnie obsługiwana

Backend automatycznie pobierze następny adres URL na podstawie linków w stylu RFC 5988 w nagłówku.

Przykład 8a: Następny adres URL żądania znajduje się w treści odpowiedzi podczas korzystania z stronicowania w przepływach danych mapowania

W tym przykładzie przedstawiono sposób ustawienia reguły stronicowania i reguły warunku końcowego w przepływach danych, gdy następny adres URL żądania pochodzi z treści odpowiedzi.

Schemat odpowiedzi jest pokazany poniżej:

Reguły stronicowania powinny być zgodne z przedstawionym zrzutem ekranu.

Domyślnie stronicowanie zostanie zatrzymane, gdy treść. {@odata.nextLink}** ma wartość null lub jest pusta.

Jeśli jednak wartość @odata.nextLink w ostatniej treści odpowiedzi jest równa ostatniemu adresowi URL żądania, doprowadzi to do nieskończonej pętli. Aby uniknąć tego warunku, zdefiniuj reguły warunków końcowych.

• Jeśli wartość w ostatniej odpowiedzi jest pusta, można ustawić regułę warunku końcowego w następujący sposób:

  

• Jeśli wartość pełnego klucza w nagłówku odpowiedzi jest równa true i wskazuje koniec stronicowania, można ustawić regułę warunku końcowego w następujący sposób:

  

Przykład 8b: następny adres URL żądania znajduje się w treści odpowiedzi podczas korzystania z stronicowania w działaniu kopiowania

W tym przykładzie pokazano, jak ustawić regułę stronicowania w działaniu kopiowania, gdy następny adres URL żądania jest zawarty w treści odpowiedzi.

Schemat odpowiedzi jest pokazany poniżej:

Reguły stronicowania powinny być ustawione, jak pokazano na poniższym zrzucie ekranu:

Przykład 9: Format odpowiedzi to XML, a następny adres URL żądania pochodzi z treści odpowiedzi podczas używania paginacji w przepływach danych przy mapowaniu

W tym przykładzie przedstawiono sposób ustawiania reguły stronicowania w przepływach danych mapowania, gdy format odpowiedzi to XML, a następny adres URL żądania pochodzi z treści odpowiedzi. Jak pokazano na poniższym zrzucie ekranu, pierwszy adres URL to https://< user.dfs.core.windows.NET/bugfix/test/movie_1.xml>

Schemat odpowiedzi jest pokazany poniżej:

Składnia reguły stronicowania jest taka sama jak w przykładzie 8 i powinna być ustawiona jak poniżej w tym przykładzie:

Eksportuj odpowiedź JSON bez zmian

Łącznik REST umożliwia eksportowanie odpowiedzi JSON interfejsu API REST as-is do różnych systemów magazynowania opartych na plikach (ujściów). Aby włączyć to zachowanie niezależne od schematu kopiowania, użyj domyślnego mapowania schematu (nie należy definiować żadnego mapowania na karcie Mapowanie działania kopiowania).

Mapowanie schematu

Aby skopiować dane z punktu końcowego REST do ujścia tabelarycznego, zapoznaj się z schematem mapowania.

Powiązana zawartość

Aby uzyskać listę magazynów danych obsługiwanych przez działanie kopiowania jako źródła i ujścia w usłudze Azure Data Factory, zobacz Obsługiwane magazyny danych i formaty.