Wywoływanie zewnętrznych punktów końcowych HTTP lub HTTPS z przepływów pracy w usłudze Azure Logic Apps

Dotyczy: Azure Logic Apps (Consumption + Standard)

Niektóre scenariusze mogą wymagać utworzenia przepływu pracy aplikacji logiki, który wysyła żądania wychodzące do punktów końcowych w innych usługach lub systemach za pośrednictwem protokołu HTTP lub HTTPS. Załóżmy na przykład, że chcesz monitorować punkt końcowy usługi dla witryny internetowej, sprawdzając ten punkt końcowy zgodnie z określonym harmonogramem. Gdy w tym punkcie końcowym wystąpi określone zdarzenie, takie jak awaria witryny internetowej, to zdarzenie wyzwala przepływ pracy i uruchamia przypisane do niego akcje.

W tym przewodniku pokazano, jak używać wyzwalacza HTTP i akcji HTTP, aby przepływ pracy mógł wysyłać wywołania wychodzące do innych usług i systemów, na przykład:

• Aby sprawdzić lub sondować punkt końcowy zgodnie z harmonogramem cyklicznym, dodaj wbudowany wyzwalacz o nazwie HTTP jako pierwszy krok w przepływie pracy. Za każdym razem, gdy wyzwalacz sprawdza punkt końcowy, wyzwalacz wywołuje lub wysyła żądanie do punktu końcowego. Odpowiedź punktu końcowego określa, czy przepływ pracy jest uruchamiany. Wyzwalacz przenosi dowolną zawartość z odpowiedzi punktu końcowego do działań w twoim przepływie pracy.

• Aby wywołać punkt końcowy z dowolnego miejsca w przepływie pracy, dodaj wbudowaną akcję o nazwie HTTP. Odpowiedź punktu końcowego określa sposób działania pozostałych akcji przepływu pracy.

Wymagania wstępne

• Konto i subskrypcja platformy Azure. Jeśli nie masz subskrypcji platformy Azure, zarejestruj się w celu założenia bezpłatnego konta platformy Azure.

• Adres URL docelowego punktu końcowego, który chcesz wywołać.

• Zasób aplikacji logiki z przepływem pracy, z którego chcesz wywołać zewnętrzny punkt końcowy.

  Aby uruchomić przepływ pracy za pomocą wyzwalacza HTTP , musisz mieć pusty przepływ pracy. Aby użyć akcji HTTP , przepływ pracy może rozpocząć się od wyzwalacza, który najlepiej pasuje do danego scenariusza. Przykładowe przepływy pracy w tym artykule używają wyzwalacza HTTP .

  Jeśli nie masz zasobu aplikacji logiki i przepływu pracy, utwórz je teraz, wykonując kroki dla żądanej aplikacji logiki:

  • Utwórz przykładowy przepływ pracy aplikacji Logic Apps typu Consumption
  • Stwórz przykładowy przepływ pracy standardowej aplikacji logicznej

Dokumentacja techniczna łącznika

Aby uzyskać informacje techniczne dotyczące parametrów wyzwalacza i akcji, zobacz następujące sekcje w przewodniku dokumentacji schematu:

• Parametry wyzwalacza HTTP
• Parametry akcji HTTP

Dodawanie wyzwalacza HTTP

Ten wbudowany wyzwalacz wykonuje wywołanie HTTP do określonego adresu URL punktu końcowego i zwraca odpowiedź.

Dodawanie akcji HTTP

Ta wbudowana akcja wysyła wywołanie HTTPS lub HTTP do określonego adresu URL punktu końcowego i zwraca odpowiedź.

Wyzwalanie i dane wyjściowe akcji

Wyzwalacz HTTP lub akcja generuje następujące informacje:

Zabezpieczenia adresu URL dla wywołań wychodzących

Aby uzyskać informacje na temat szyfrowania, zabezpieczeń i autoryzacji dla wywołań wychodzących z przepływu pracy, takich jak Transport Layer Security (TLS), certyfikaty z podpisem własnym lub Open Authentication Microsoft Entra ID, zobacz Dostęp do połączeń wychodzących do innych usług i systemów.

Uwierzytelnianie dla środowiska z jedną dzierżawą

Jeśli masz zasób standardowej aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą i chcesz użyć operacji HTTP z dowolnym z następujących typów uwierzytelniania, pamiętaj, aby wykonać dodatkowe kroki konfiguracji odpowiedniego typu uwierzytelniania. W przeciwnym razie wywołanie zakończy się niepowodzeniem.

• Certyfikat TLS: dodaj ustawienie WEBSITE_LOAD_ROOT_CERTIFICATESaplikacji i ustaw wartość na odcisk palca certyfikatu TLS.

• Certyfikat klienta lub Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) z typem poświadczeń Certyfikatu: Dodaj ustawienie aplikacji, a następnie ustaw wartość na WEBSITE_LOAD_USER_PROFILE.

Uwierzytelnianie certyfikatu TLS

1. W ustawieniach aplikacji zasobu aplikacji logiki dodaj lub zaktualizuj ustawienie aplikacji o nazwie WEBSITE_LOAD_ROOT_CERTIFICATES. Aby uzyskać szczegółowe instrukcje, zobacz Zarządzanie ustawieniami aplikacji — local.settings.json.

2. Dla wartości ustawienia podaj odcisk palca certyfikatu TLS jako certyfikat główny, który ma być zaufany.

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>"

Jeśli na przykład pracujesz w programie Visual Studio Code, wykonaj następujące kroki:

1. Otwórz plik local.settings.json projektu aplikacji logiki.

2. Values W obiekcie JSON dodaj lub zaktualizuj WEBSITE_LOAD_ROOT_CERTIFICATES ustawienie:

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>",
         <...>
      }
   }
   

Aby uzyskać więcej informacji, zobacz Zarządzanie ustawieniami aplikacji — local.settings.json.

Certyfikat klienta lub OAuth Microsoft Entra ID z uwierzytelnianiem typu certyfikatu

1. W ustawieniach aplikacji zasobu aplikacji logiki dodaj lub zaktualizuj ustawienie aplikacji o nazwie WEBSITE_LOAD_USER_PROFILE. Aby uzyskać szczegółowe instrukcje, zobacz Zarządzanie ustawieniami aplikacji — local.settings.json

2. Dla wartości ustawienia określ wartość 1.

   "WEBSITE_LOAD_USER_PROFILE": "1"

Jeśli na przykład pracujesz w programie Visual Studio Code, wykonaj następujące kroki:

1. Otwórz plik local.settings.json projektu aplikacji logiki.

2. Values W obiekcie JSON dodaj lub zaktualizuj WEBSITE_LOAD_USER_PROFILE ustawienie:

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_USER_PROFILE": "1",
         <...>
      }
   }
   

Jeśli pracujesz w portalu Azure, otwórz aplikację logiki. W obszarze Ustawienia w menu paska bocznego wybierz pozycję Zmienne środowiskowe. W obszarze Ustawienia aplikacji dodaj lub edytuj ustawienie.

Zawartość z typem multipart/form-data

Aby obsłużyć zawartość typu multipart/form-data w żądaniach HTTP, można dodać obiekt JSON, który zawiera atrybuty $content-type oraz $multipart w ciele żądania HTTP, stosując ten format.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

Załóżmy na przykład, że masz przepływ pracy, który wysyła żądanie HTTP POST dla pliku programu Excel do witryny internetowej przy użyciu interfejsu API tej witryny, który obsługuje multipart/form-data typ. W poniższym przykładzie pokazano, jak ta akcja może się pojawić:

Oto ten sam przykład pokazujący definicję JSON akcji HTTP w podstawowej definicji przepływu pracy:

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

Zawartość z typem application/x-www-form-urlencoded

Aby podać dane zakodowane w postaci adresu URL w treści żądania HTTP, należy określić, że dane mają application/x-www-form-urlencoded typ zawartości. Dodaj nagłówek content-type w wyzwalaczu lub akcji HTTP. Ustaw wartość nagłówka na application/x-www-form-urlencoded.

Załóżmy na przykład, że masz aplikację logiki, która wysyła żądanie HTTP POST do witryny internetowej obsługującej typ application/x-www-form-urlencoded. Oto jak ta akcja może wyglądać:

Zachowanie asynchronicznej odpowiedzi na żądanie

W przypadku stanowych przepływów pracy zarówno w wielodostępnych, jak i jednodostępnych usłudze Azure Logic Apps wszystkie akcje oparte na protokole HTTP są zgodne ze standardowym wzorcem operacji asynchronicznych jako zachowaniem domyślnym. Ten wzorzec określa, że po wywołaniu akcji HTTP lub wysłaniu żądania do punktu końcowego, usługi, systemu lub interfejsu API odbiorca natychmiast zwraca odpowiedź 202 ACCEPTED . Ten kod potwierdza, że odbiorca zaakceptował żądanie, ale nie zakończył przetwarzania. Odpowiedź może zawierać location nagłówek, który określa identyfikator URI i identyfikator odświeżania, którego obiekt wywołujący może użyć do sondowania lub sprawdzenia stanu żądania asynchronicznego, dopóki odbiorca nie przestanie przetwarzać i zwraca odpowiedź powodzenia 200 OK lub inną odpowiedź inną niż 202. Jednak obiekt wywołujący nie musi czekać na zakończenie przetwarzania żądania i może kontynuować wykonywanie następnej akcji. Aby uzyskać więcej informacji, zobacz Synchroniczne i asynchroniczne komunikaty.

W przypadku bezstanowych przepływów pracy w usłudze Azure Logic Apps z jedną dzierżawą akcje oparte na protokole HTTP nie używają wzorca operacji asynchronicznej. Zamiast tego są uruchamiane synchronicznie, zwracają odpowiedź 202 AKCEPTOWANO as-isi przechodzą do następnego kroku w wykonaniu przepływu pracy. Jeśli odpowiedź zawiera location nagłówek, bezstanowy przepływ pracy nie sonduje określonego identyfikatora URI w celu sprawdzenia stanu. Aby postępować zgodnie ze standardowym wzorcem operacji asynchronicznych, zamiast tego użyj stanowego przepływu pracy.

• Podstawowa definicja JSON akcji HTTP jest niejawnie zgodna ze wzorcem operacji asynchronicznej.

• Akcja HTTP, w przeciwieństwie do wyzwalacza, ma ustawienie wzorca asynchronicznego, które jest włączone domyślnie. To ustawienie określa, że obiekt wywołujący nie czeka na zakończenie przetwarzania i może przejść do następnej akcji, ale kontynuuje sprawdzanie stanu do momentu zatrzymania przetwarzania. Jeśli to ustawienie jest wyłączone, określa, że obiekt wywołujący czeka na zakończenie przetwarzania przed przejściem do następnej akcji.

  Aby znaleźć ustawienie wzorca asynchronicznego :

  1. W projektancie przepływu pracy wybierz akcję HTTP .
  2. W wyświetlonym okienku informacji wybierz pozycję Ustawienia.
  3. W sekcji Sieci znajdź ustawienie Wzorzec Asynchroniczny.

Wyłączanie operacji asynchronicznych

Czasami możesz wyłączyć asynchroniczne zachowanie akcji HTTP w określonych scenariuszach, na przykład wtedy, gdy chcesz:

• Unikaj przekroczenia limitu czasu http dla długotrwałych zadań
• Wyłączanie sprawdzania nagłówków lokalizacji

Wyłącz ustawienie wzorca asynchronicznego

1. W projektancie przepływu pracy wybierz akcję HTTP, a następnie w otwartym okienku informacji wybierz pozycję Ustawienia.

2. W sekcji Sieci znajdź ustawienie Wzorzec Asynchroniczny. Jeśli to ustawienie jest włączone, zmień ustawienie na Wyłączone .

Wyłącz wzorzec asynchroniczny w definicji JSON akcji

W podstawowej definicji JSON dla akcji HTTP dodaj opcję operacji DisableAsyncPattern do definicji akcji, aby akcja zamiast tego podążała za wzorcem operacji synchronicznej. Aby uzyskać więcej informacji, zobacz również Uruchamianie akcji we wzorcu operacji synchronicznej.

Unikaj przekroczeń limitu czasu HTTP w przypadku zadań o długim czasie wykonywania.

Żądania HTTP mają limit czasu. Jeśli masz długotrwałą akcję HTTP, która kończy się niepowodzeniem z powodu przekroczenia limitu czasu, masz następujące opcje:

• Wyłącz wzorzec operacji asynchronicznej akcji HTTP, żeby akcja nie ciągle sondowała ani sprawdzała stanu żądania. Zamiast tego akcja czeka na odpowiedź odbiorcy ze stanem i wynikami po zakończeniu przetwarzania żądania.

• Zastąp akcję HTTP akcją webhooku HTTP, która oczekuje, aż odbiorca odpowie stanem i wynikami po zakończeniu przetwarzania żądania.

Ustaw interwał między próbami ponownego wykonania za pomocą nagłówka Retry-After

Aby określić liczbę sekund między ponownymi próbami, możesz dodać Retry-After nagłówek do odpowiedzi akcji HTTP. Jeśli na przykład docelowy punkt końcowy zwraca 429 - Too many requests kod stanu, można określić dłuższy interwał między ponowną próbą. Nagłówek Retry-After działa również z kodem stanu 202 - Accepted.

Oto ten sam przykład przedstawiający odpowiedź akcji HTTP zawierającą element Retry-After:

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

Obsługa stronicowania

Czasami usługa docelowa odpowiada, zwracając wyniki jedną stronę po drugiej. Jeśli odpowiedź określa następną stronę z właściwością nextLink lub @odata.nextLink , możesz włączyć ustawienie Stronicowanie w akcji HTTP . To ustawienie powoduje, że akcja HTTP będzie automatycznie podążać za tymi linkami i uzyskać następną stronę. Jeśli jednak odpowiedź określa następną stronę z dowolnym innym tagiem, może być konieczne dodanie pętli do przepływu pracy. Wykonaj tę pętlę zgodnie z tym tagiem i ręcznie pobierz każdą stronę do momentu, aż tag ma wartość null.

Wyłącz sprawdzanie nagłówków lokalizacji

Niektóre punkty końcowe, usługi, systemy lub interfejsy API zwracają 202 ACCEPTED odpowiedź, która nie ma nagłówka location . Aby uniknąć, aby działanie HTTP ciągle sprawdzało status żądania, gdy nagłówek location nie istnieje, masz następujące opcje:

• Wyłącz wzorzec operacji asynchronicznej akcji HTTP, żeby akcja nie ciągle sondowała ani sprawdzała stanu żądania. Zamiast tego akcja czeka na odpowiedź odbiorcy ze stanem i wynikami po zakończeniu przetwarzania żądania.

• Zastąp akcję HTTP akcją webhooku HTTP, która oczekuje, aż odbiorca odpowie stanem i wynikami po zakończeniu przetwarzania żądania.

Znane problemy

Pominięto nagłówki HTTP

Jeśli wyzwalacz LUB akcja HTTP zawiera te nagłówki, usługa Azure Logic Apps usuwa te nagłówki z wygenerowanego komunikatu żądania bez wyświetlania żadnego ostrzeżenia lub błędu:

• Accept-* nagłówki z wyjątkiem Accept-version
• Allow
• Nagłówki Content-* z wyjątkiem Content-Disposition, Content-Encoding i Content-Type, które są respektowane podczas korzystania z operacji POST i PUT. Jednak usługa Azure Logic Apps usuwa te nagłówki, gdy używasz operacji GET.
• Cookie nagłówek, ale usługa Azure Logic Apps honoruje dowolną wartość `Cookie`, która jest określana przy użyciu właściwości `Cookie`.
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-Encoding

Chociaż usługa Azure Logic Apps nie uniemożliwia zapisywania aplikacji logiki korzystających z wyzwalacza HTTP lub akcji z tymi nagłówkami, usługa Azure Logic Apps ignoruje te nagłówki.

Zawartość odpowiedzi nie jest zgodna z oczekiwanym typem zawartości

Akcja HTTP zgłasza błąd BadRequest, jeśli akcja HTTP wywołuje interfejs API zaplecza z Content-Type nagłówkiem ustawionym na application/json, ale odpowiedź z zaplecza nie zawiera zawartości w formacie JSON, co powoduje niepowodzenie wewnętrznej walidacji formatu JSON.

Treści powiązane

• Łączniki zarządzane dla łączników usługi Azure Logic Apps
• Wbudowane łączniki dla usługi Azure Logic Apps