Obsługa błędów i wyjątków w workflow w Azure Logic Apps

Dotyczy: Azure Logic Apps (Consumption + Standard)

Sposób, w jaki każda architektura integracji odpowiednio obsługuje przestoje lub problemy spowodowane przez systemy zależne, może stanowić wyzwanie. Aby ułatwić tworzenie niezawodnych i odpornych integracji, które bezpiecznie obsługują problemy i błędy, usługa Azure Logic Apps zapewnia najwyższej klasy środowisko obsługi błędów i wyjątków.

Zasady ponawiania prób

W przypadku najbardziej podstawowego zarządzania wyjątkami i obsługi błędów można użyć polityki ponawiania, o ile ta opcja jest dostępna w funkcji wyzwalacza lub akcji, na przykład w akcji HTTP. Jeśli oryginalne żądanie wyzwalacza lub akcji przekroczy limit czasu albo zakończy się niepowodzeniem, powodując odpowiedź 408, 429 lub 5xx, zasady ponawiania określają, że wyzwalacz lub akcja ponownie wysyła żądanie zgodnie z ustawieniami zasad.

Limity zasad ponawiania prób

Aby uzyskać więcej informacji na temat zasad ponawiania prób, ustawień, limitów i innych opcji, zapoznaj się z tematem Retry policy limits (Limity zasad ponawiania prób).

Typy zasad ponawiania prób

Operacje łącznika, które obsługują zasady ponawiania prób, używają zasad domyślnych , chyba że wybierzesz inne zasady ponawiania.

Zasady ponawiania	Opis
Wartość domyślna	W przypadku większości operacji Domyślna zasada ponawiania to zasada wykładniczych odstępów, która przewiduje maksymalnie 4 ponowienia w wykładniczo wydłużających się odstępach. Te interwały są skalowane o 7,5 sekundy, ale są ograniczone do zakresu od 5 do 45 sekund. Kilka operacji używa innych domyślnych zasad ponawiania, takich jak zasady o stałym interwale. Aby uzyskać więcej informacji, zapoznaj się z typem domyślnych zasad ponawiania.
Brak	Nie wysyłaj ponownie żądania. Aby uzyskać więcej informacji, zobacz Brak — brak zasad ponawiania prób.
Interwał wykładniczy	Ta strategia odczekuje losowy czas, wybrany z zakresu rosnącego wykładniczo, przed wysłaniem następnego żądania. Aby uzyskać więcej informacji, zapoznaj się z typem zasad interwału wykładniczego.
Stały interwał	Ta zasada czeka przez określony czas przed wysłaniem następnego żądania. Aby uzyskać więcej informacji, zapoznaj się z typem zasad o stałym interwale.

Zmień typ zasad ponawiania próby w projektancie

W witrynie Azure Portal otwórz zasób aplikacji logiki.
Na pasku bocznym zasobu wykonaj następujące kroki, aby otworzyć projektanta przepływu pracy na podstawie aplikacji logiki:
- Zużycie: w obszarze Narzędzia programistyczne wybierz projektanta, aby otworzyć przepływ pracy.
- Norma
  1. W obszarze Przepływy pracy wybierz pozycję Przepływy pracy.
  2. Na stronie Przepływy pracy wybierz przepływ pracy.
  3. W obszarze Narzędzia wybierz projektanta, aby otworzyć przepływ pracy.
W wyzwalaczu lub akcji, w której chcesz zmienić typ zasad ponawiania, wykonaj następujące kroki, aby otworzyć ustawienia:
1. W projektancie wybierz operację.
2. W okienku informacji o operacji wybierz pozycję Ustawienia.
3. W obszarze Sieć, w sekcji Polityka ponawiania prób, wybierz typ polityki, który chcesz zastosować.

Zmień typ zasad ponawiania próby w edytorze widoku kodu

Upewnij się, czy wyzwalacz lub akcja obsługują polityki ponawiania, wykonując wcześniejsze kroki w edytorze.
Otwórz przepływ pracy aplikacji logiki w edytorze widoku kodu.

W definicji wyzwalacza lub akcji dodaj retryPolicy obiekt JSON do obiektu wyzwalacza lub akcji inputs . pl-PL: Jeśli obiekt retryPolicy nie istnieje, wyzwalacz lub akcja używa default zasad ponawiania.

"inputs": {
   <...>,
   "retryPolicy": {
      "type": "<retry-policy-type>",
      // The following properties apply to specific retry policies.
      "count": <retry-attempts>,
      "interval": "<retry-interval>",
      "maximumInterval": "<maximum-interval>",
      "minimumInterval": "<minimum-interval>"
   },
   <...>
},
"runAfter": {}

Wymagane

Właściwości	Wartość	Typ	Opis
`type`	< Typ zasad ponawiania>	Sznurek	Typ zasad ponawiania do użycia: `default`, `none`, `fixed` lub `exponential`
`count`	< ponawianie prób>	Liczba całkowita	Dla typów zasad `fixed` i `exponential` liczba ponownych prób o wartości od 1 do 90. Aby uzyskać więcej informacji, zapoznaj się z interwałem stałym i interwałem wykładniczym.
`interval`	< interwał ponawiania prób>	Sznurek	W przypadku typów zasad `fixed` i `exponential` wartość interwału ponawiania musi być podana w formacie ISO 8601. W przypadku zasady `exponential` można również określić opcjonalne maksymalne i minimalne odstępy. Aby uzyskać więcej informacji, zapoznaj się z Interwałem stałym i Interwałem wykładniczym. Zużycie: 5 sekund (`PT5S`) do 1 dnia (`P1D`). Standardowa: w przypadku stanowych przepływów pracy od 5 sekund (`PT5S`) do 1 dnia (`P1D`). W przypadku bezstanowych przepływów pracy od 1 sekundy (`PT1S`) do 1 minuty (`PT1M`).

Opcjonalne

Właściwości	Wartość	Typ	Opis
`maximumInterval`	< maksymalny interwał>	Sznurek	Dla zasad `exponential` największy z losowo wybranych interwałów w formacie ISO 8601. Wartość domyślna to 1 dzień (`P1D`). Aby uzyskać więcej informacji, zapoznaj się z Interwałem wykładniczym.
`minimumInterval`	< minimalny interwał>	Sznurek	Dla zasady `exponential` najkrótszy losowo wybierany odstęp czasu jest podawany w formacie ISO 8601. Wartość domyślna to 5 sekund (`PT5S`). Aby uzyskać więcej informacji, zapoznaj się z Interwał wykładniczy.

Domyślna polityka ponawiania

Operacje łącznika, które obsługują zasady ponawiania prób, używają zasad domyślnych , chyba że wybierzesz inne zasady ponawiania. W przypadku większości operacji zasada ponawiania Default jest strategią wykładnicznego wydłużania odstępów i wykonuje maksymalnie 4 ponowienia w coraz dłuższych odstępach czasu. Te interwały są skalowane o 7,5 sekundy, ale są ograniczone do zakresu od 5 do 45 sekund. Kilka operacji używa innych domyślnych zasad ponawiania, takich jak zasady o stałym interwale.

W definicji przepływu pracy definicja wyzwalacza lub akcji nie definiuje jawnie zasad domyślnych, ale w poniższym przykładzie pokazano, jak działają domyślne zasady ponawiania dla akcji HTTP:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

Brak — brak zasad ponawiania prób

Aby określić, że akcja lub wyzwalacz nie ponawia nieudanych żądań, ustaw <retry-policy-type> na none.

Zasada ponawiania w stałych odstępach czasu

Aby określić, że przed wysłaniem następnego żądania akcja lub wyzwalacz ma czekać przez określony odstęp czasu, ustaw <retry-policy-type> na fixed.

Przykład

Ta zasada ponawiania przewiduje dwie dodatkowe próby pobrania najnowszych wiadomości po pierwszym nieudanym żądaniu, z 30-sekundowym opóźnieniem między każdą próbą:

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

Strategia ponownych prób z wykładniczo rosnącymi interwałami

Zasada ponawiania w odstępach wykładniczo narastających określa, że wyzwalacz lub akcja czeka losowy odstęp czasu przed wysłaniem następnego żądania. Ten losowy interwał jest wybierany z wykładniczo rosnącego zakresu. Opcjonalnie możesz zastąpić domyślne minimalne i maksymalne interwały własnymi wartościami, określając własne minimalne i maksymalne interwały w zależności od tego, czy masz przepływ pracy aplikacji logiki w warstwie Consumption czy Standard.

Nazwisko	Limit użycia	Limit standardowy	Uwagi
Maksymalne opóźnienie	Ustawienie domyślne: 1 dzień	Ustawienie domyślne: 1 godzina	Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Consumption, użyj parametru zasad ponawiania prób. Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Standard, zapoznaj się z artykułem Edytowanie ustawień hosta i aplikacji dla jednodzierżawnych aplikacji logiki w usłudze Azure Logic Apps.
Minimalne opóźnienie	Ustawienie domyślne: 5 s	Ustawienie domyślne: 5 s	Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Consumption, użyj parametru zasad ponawiania. Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Standard, zapoznaj się z artykułem Edytowanie ustawień hosta i aplikacji dla aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą.

Nazwisko

Limit użycia

Limit standardowy

Uwagi

Maksymalne opóźnienie

Ustawienie domyślne: 1 dzień

Ustawienie domyślne: 1 godzina

Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Consumption, użyj parametru zasad ponawiania prób.

Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Standard, zapoznaj się z artykułem Edytowanie ustawień hosta i aplikacji dla jednodzierżawnych aplikacji logiki w usłudze Azure Logic Apps.

Minimalne opóźnienie

Ustawienie domyślne: 5 s

Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Consumption, użyj parametru zasad ponawiania.

Aby zmienić domyślny limit w przepływie pracy aplikacji logiki w warstwie Standard, zapoznaj się z artykułem Edytowanie ustawień hosta i aplikacji dla aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą.

Zakresy zmiennych losowych

W przypadku zasad ponawiania interwałów wykładniczych w poniższej tabeli przedstawiono ogólny algorytm używany przez usługę Azure Logic Apps do generowania jednolitej zmiennej losowej w określonym zakresie dla każdego ponawiania próby. Określony zakres może zawierać maksymalnie liczbę ponownych prób.

Numer ponawiania próby	Minimalny interwał	Maksymalny interwał
1	max(0, <minimalny interwał>)	min(interwał, <maksymalny interwał>)
2	max(interwał, <minimalny interwał>)	min(2 * interwał, <maksymalny interwał>)
3	max(2 * interwał, <minimalny interwał>)	min(4 * interwał, <maksymalny interwał>)
4	max(4 * interwał, <minimalny interwał>)	min(8 * interwał, <maksymalny interwał>)
....	....	....

Zarządzanie działaniem „Uruchom po”

Podczas dodawania akcji w projektancie przepływu pracy niejawnie deklarujesz sekwencję uruchamiania tych akcji. Po zakończeniu działania akcja ta jest oznaczona stanem, takim jak Powodzenie, Niepowodzenie, Pominięte lub Przekroczenie limitu czasu. Innymi słowy, poprzednia akcja musi najpierw zakończyć się jednym z zezwolonych statusów, zanim będzie można uruchomić akcję następną.

Domyślnie akcja dodana w projektancie jest uruchamiana tylko wtedy, gdy poprzednia akcja kończy się stanem Powodzenie . Zachowanie uruchomienia po precyzyjnie określa kolejność wykonywania akcji w przepływie pracy.

W projektancie można zmienić domyślne zachowanie "Uruchom po" dla akcji, edytując ustawienie Uruchom po. To ustawienie jest dostępne tylko w przypadku kolejnych akcji, które są zgodne z pierwszą akcją w przepływie pracy. Pierwsza akcja w przepływie pracy zawsze jest uruchamiana po pomyślnym uruchomieniu wyzwalacza. Dlatego ustawienie Uruchom po jest niedostępne i nie ma zastosowania do pierwszej akcji.

W podstawowej definicji JSON akcji, ustawienie Uruchom po jest takie samo jak atrybut runAfter. Ta właściwość określa jedną lub więcej akcji poprzednika, które muszą najpierw zakończyć się z określonymi dozwolonymi statusami, zanim będzie można uruchomić akcję następnika. Właściwość runAfter jest obiektem JSON, który zapewnia elastyczność, umożliwiając określenie wszystkich poprzednich akcji, które muszą zostać zakończone przed uruchomieniem akcji następnika. Ten obiekt definiuje również tablicę dopuszczalnych stanów.

Na przykład aby akcja działała po pomyślnym wykonaniu akcji A, a także po pomyślnym lub niepomyślnym wykonaniu akcji B, gdy pracujesz nad definicją JSON akcji, skonfiguruj następującą runAfter właściwość:

{
   // Other parts in action definition
   "runAfter": {
      "Action A": ["Succeeded"],
      "Action B": ["Succeeded", "Failed"]
    }
}

Zachowanie "Uruchom po" na potrzeby obsługi błędów

Gdy akcja zgłasza nieobsługiwany błąd lub wyjątek, akcja jest oznaczona jako Niepowodzenie, a każda akcja następnika jest oznaczona jako Pominięta. Jeśli takie zachowanie występuje w przypadku akcji, która ma gałęzie równoległe, mechanizm usługi Azure Logic Apps śledzi pozostałe gałęzie, aby określić stan ich ukończenia. Na przykład, jeśli gałąź kończy się akcją Pominięto, status ukończenia tej gałęzi zależy od statusu poprzedzającej ją akcji. Po zakończeniu przebiegu przepływu pracy aparat określa stan całego przebiegu, oceniając wszystkie stany gałęzi. Jeśli jakakolwiek gałąź zakończy się niepowodzeniem, cały przebieg przepływu pracy zostanie oznaczony jako Niepowodzenie.

Aby upewnić się, że akcja może nadal być uruchamiana mimo statusu poprzednika, możesz zmienić ustawienie „Uruchom po” dla akcji, aby obsługiwało statusy niepowodzenia poprzednika. W ten sposób akcja zostanie uruchomiona, gdy stan poprzednika to Powodzenie, Niepowodzenie, Pominięto, Przekroczono limit czasu lub wszystkie te stany.

Na przykład aby uruchomić akcję Office 365 Outlook Wyślij wiadomość e-mail, gdy poprzedzająca ją akcja Excel Online Dodaj wiersz do tabeli ma stan Niepowodzenie, a nie Powodzenie, zmień zachowanie opcji „Uruchom po”, używając projektanta lub edytora widoku kodu.

Zmień zachowanie „Uruchom po” w projektancie

W witrynie Azure Portal otwórz zasób aplikacji logiki.
Na pasku bocznym zasobu wykonaj następujące kroki, aby otworzyć projektanta przepływu pracy na podstawie aplikacji logiki:
- Zużycie: w obszarze Narzędzia programistyczne wybierz projektanta, aby otworzyć przepływ pracy.
- Norma
  1. Na pasku bocznym zasobu w obszarze Przepływy pracy wybierz pozycję Przepływy pracy.
  2. Na stronie Przepływy pracy wybierz przepływ pracy.
  3. W obszarze Narzędzia wybierz projektanta, aby otworzyć przepływ pracy.
W wyzwalaczu lub akcji, w której chcesz zmienić zachowanie "Uruchom po", wykonaj następujące kroki, aby otworzyć ustawienia operacji:
1. W projektancie wybierz operację.
2. W okienku informacji o operacji wybierz pozycję Ustawienia.
  
  Sekcja Uruchom po zawiera listę Wybór działań, która pokazuje dostępne operacje poprzedzające dla aktualnie wybranej operacji, na przykład:
3. Na liście Wybierz akcje rozwiń bieżącą operację poprzednika, która jest HTTP w tym przypadku.
  
  Domyślnie status „Uruchom po” jest ustawiony na Zakończono pomyślnie. Ta wartość oznacza, że poprzednia operacja musi zakończyć się pomyślnie, zanim będzie można uruchomić bieżącą akcję.
Aby zmienić zachowanie "Uruchom po" na żądane stany, wybierz te stany.

W poniższym przykładzie wybrano pozycję Nie powiodło się.
Aby określić, że bieżąca operacja jest uruchamiana tylko wtedy, gdy poprzednia akcja zakończyła się statusem Niepowodzenie, Jest pominięta lub Przekroczono limit czasu, zaznacz te stany, a następnie usuń stan domyślny, na przykład:

Uwaga

Przed wyczyszczeniem stanu domyślnego upewnij się, że najpierw wybierzesz inny stan. Zawsze musisz mieć wybrany co najmniej jeden status.
Aby wymagać, aby wiele poprzednich operacji zostało uruchomionych i zakończonych, każda z własnymi statusami "uruchomienie po", wykonaj następujące kroki:
1. Otwórz listę Wybierz akcje i wybierz operacje poprzednika, które chcesz.
2. Wybierz stan "Uruchom po" dla każdej operacji.
Po zakończeniu zamknij okienko informacji o operacji.

Zmień działanie opcji „Uruchom po” w edytorze widoku kodu

Na pasku bocznym zasobu wykonaj następujące kroki, aby otworzyć edytor widoku kodu na podstawie aplikacji logiki:
- Użycie: w obszarze Narzędzia programistyczne wybierz widok kodu, aby otworzyć przepływ pracy w edytorze JSON.
- Norma
  1. W obszarze Przepływy pracy wybierz pozycję Przepływy pracy.
  2. Na stronie Przepływy pracy wybierz przepływ pracy.
  3. W obszarze Narzędzia wybierz widok kodu, aby otworzyć przepływ pracy w edytorze JSON.

W definicji JSON akcji zmodyfikuj runAfter właściwość, która ma następującą składnię:

"<action-name>": {
   "inputs": {
      "<action-specific-inputs>"
   },
   "runAfter": {
      "<preceding-action>": [
         "Succeeded"
      ]
   },
   "type": "<action-type>"
}

W tym przykładzie zmień właściwość runAfter z Succeeded na Failed:

"Send_an_email_(V2)": {
   "inputs": {
      "body": {
         "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>",
         "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}",
         "To": "Sophia.Owen@fabrikam.com"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "post",
      "path": "/v2/Mail"
   },
   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed"
      ]
   },
   "type": "ApiConnection"
}

Aby określić, czy akcja jest uruchamiana, czy poprzednia akcja jest oznaczona jako Failed, Skipped lub TimedOut, dodaj inne stany:
```
"runAfter": {
   "Add_a_row_into_a_table": [
      "Failed", "Skipped", "TimedOut"
   ]
},
```

Ocenianie akcji przy użyciu zakresów i ich wyników

Podobnie jak w przypadku uruchamiania kroków po wykonaniu poszczególnych akcji przy użyciu ustawienia „Uruchom po”, można grupować akcje wewnątrz zakresu. Zakresy można używać, gdy chcesz logicznie grupować akcje, oceniać stan agregacji zakresu i wykonywać akcje na podstawie tego stanu. Po zakończeniu wszystkich działań w obrębie zakresu sam zakres otrzymuje własny stan.

Aby sprawdzić stan zakresu, możesz użyć tych samych kryteriów, które są używane do sprawdzania stanu uruchomienia przepływu pracy, takich jak Powodzenie, Niepowodzenie itd.

Domyślnie, gdy wszystkie akcje zakresu zakończą się pomyślnie, stan zakresu jest oznaczany jako Zakończono pomyślnie. Jeśli końcowa akcja w obrębie zakresu jest oznaczona jako Niepowodzenie lub Przerwana, stan zakresu jest oznaczany jako Niepowodzenie.

Aby przechwytywać wyjątki w zakresie Failed i uruchamiać akcje obsługujące te błędy, możesz użyć ustawienia „Uruchom po” dla zakresu Failed. W ten sposób, jeśli jakiekolwiek akcje w zakresie kończą się niepowodzeniem i używasz ustawienia "Uruchom po" dla tego zakresu, możesz utworzyć jedną akcję w celu przechwycenia błędów.

Aby uzyskać informacje o limitach w zakresach, zobacz Limity i konfiguracja.

Skonfiguruj zakres za pomocą opcji „run after” do obsługi wyjątków

W witrynie Azure Portal otwórz zasób aplikacji logiki i przepływ pracy w projektancie.

Przepływ pracy musi już mieć wyzwalacz, który uruchamia przepływ pracy.
W projektancie wykonaj te ogólne kroki, aby dodać do przepływu pracy akcję Sterowanie o nazwie Scope.
W akcji Zakres wykonaj następujące ogólne kroki, aby dodać akcje do uruchomienia, na przykład:

Na poniższej liście przedstawiono przykładowe akcje, które można uwzględnić w akcji Zakres :
- Pobieranie danych z interfejsu API.
- Przetwarzanie danych.
- Zapisz dane w bazie danych.
Teraz zdefiniuj reguły „Uruchom po” dotyczące uruchamiania akcji w tym zakresie.
1. W projektancie wybierz tytuł „Zakres”. Po otwarciu okienka informacji o zakresie wybierz pozycję Ustawienia.
2. Jeśli masz więcej niż jedną poprzednią akcję w przepływie pracy, z listy Wybierz akcje wybierz akcję, po której chcesz uruchomić akcje o określonym zakresie.
3. Dla wybranej akcji wybierz wszystkie stany akcji, które mogą uruchamiać akcje o określonym zakresie.
  
  Innymi słowy, dowolny z wybranych stanów wynikających z wybranej akcji powoduje uruchomienie akcji w danym zakresie.
  
  W poniższym przykładzie akcje o określonym zakresie są uruchamiane po zakończeniu akcji HTTP z dowolnymi wybranymi stanami:

Uzyskaj kontekst i wyniki w przypadku niepowodzeń

Chociaż przechwytywanie błędów w obrębie zakresu jest przydatne, możesz też potrzebować dodatkowego kontekstu, aby ustalić, które dokładnie akcje zakończyły się niepowodzeniem, a także jakie błędy lub kody stanu im towarzyszyły. Funkcja result() zwraca wyniki działań najwyższego poziomu w akcji z określonym zakresem. Ta funkcja akceptuje nazwę zakresu jako pojedynczy parametr i zwraca tablicę z wynikami z tych akcji najwyższego poziomu. Te obiekty akcji mają te same atrybuty co atrybuty zwracane przez actions() funkcję, takie jak czas rozpoczęcia akcji, czas zakończenia, stan, dane wejściowe, identyfikatory korelacji i dane wyjściowe.

Uwaga

Funkcja result() zwraca wyniki tylko z działań na najwyższym poziomie, a nie z głębiej zagnieżdżonych działań, takich jak działania typu switch lub condition.

Aby uzyskać kontekst dotyczący akcji, które zakończyły się niepowodzeniem w zakresie, możesz użyć wyrażenia @result() z nazwą zakresu i ustawienia „Uruchom po”. Aby przefiltrować zwróconą tablicę tak, aby zawierała tylko akcje o stanie Failed, możesz dodać akcję Filtruj tablicę. Aby uruchomić akcję dla zwróconej akcji zakończonej niepowodzeniem, użyj zwróconej przefiltrowanej tablicy i pętli For each.

Poniższy przykład JSON wysyła żądanie HTTP POST z treścią odpowiedzi dla akcji, które zakończyły się niepowodzeniem w ramach akcji zakresu o nazwie My_Scope. Po przykładzie następuje szczegółowe wyjaśnienie.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": "@result('My_Scope')",
      "where": "@equals(item()['status'], 'Failed')"
   },
   "runAfter": {
      "My_Scope": [
         "Failed"
      ]
    }
},
"For_each": {
   "type": "foreach",
   "actions": {
      "Log_exception": {
         "type": "Http",
         "inputs": {
            "method": "POST",
            "body": "@item()['outputs']['body']",
            "headers": {
               "x-failed-action-name": "@item()['name']",
               "x-failed-tracking-id": "@item()['clientTrackingId']"
            },
            "uri": "http://requestb.in/"
         },
         "runAfter": {}
      }
   },
   "foreach": "@body('Filter_array')",
   "runAfter": {
      "Filter_array": [
         "Succeeded"
      ]
   }
}

W poniższych krokach opisano, co się dzieje w tym przykładzie:

Aby uzyskać wynik ze wszystkich akcji wewnątrz My_Scope, akcja Filtruj tablicę używa tego wyrażenia filtru: @result('My_Scope')
Warunkiem dla Tablicy filtrowania jest dowolny element @result(), którego status jest równy Failed. Ten warunek filtruje tablicę zawierającą wszystkie wyniki akcji z My_Scope do tablicy z tylko wynikami akcji zakończonej niepowodzeniem.
Wykonaj For_each akcję w pętli na danych wyjściowych przefiltrowanej tablicy. Ten krok wykonuje akcję dla każdego wyniku akcji zakończonego niepowodzeniem, który został wcześniej odfiltrowany.

Jeśli pojedyncza akcja w obrębie zakresu zakończy się niepowodzeniem, akcje w pętli For_each są wykonywane tylko raz. Wiele nieudanych działań powoduje jedno działanie na każde niepowodzenie.
Wyślij żądanie HTTP POST do treści odpowiedzi elementu For_each, czyli wyrażenia @item()['outputs']['body'].

Kształt elementu @result() jest taki sam jak kształt @actions() i może być parsowany w ten sam sposób.
Dołącz dwa nagłówki niestandardowe z nazwą akcji, która zakończyła się niepowodzeniem (@item()['name']) i identyfikatorem śledzenia klienta nieudanego uruchomienia (@item()['clientTrackingId']).

Dla odniesienia, oto przykład pojedynczego elementu @result(), pokazujący właściwości name, body i clientTrackingId, które są parsowane w poprzednim przykładzie. Poza akcją For_each, @result() zwraca tablicę tych obiektów.

{
   "name": "Example_Action_That_Failed",
   "inputs": {
      "uri": "https://myfailedaction.azurewebsites.net",
      "method": "POST"
   },
   "outputs": {
      "statusCode": 404,
      "headers": {
         "Date": "Thu, 11 Aug 2016 03:18:18 GMT",
         "Server": "Microsoft-IIS/8.0",
         "X-Powered-By": "ASP.NET",
         "Content-Length": "68",
         "Content-Type": "application/json"
      },
      "body": {
         "code": "ResourceNotFound",
         "message": "/docs/folder-name/resource-name does not exist"
      }
   },
   "startTime": "2016-08-11T03:18:19.7755341Z",
   "endTime": "2016-08-11T03:18:20.2598835Z",
   "trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
   "clientTrackingId": "08587307213861835591296330354",
   "code": "NotFound",
   "status": "Failed"
}

Aby wykonać różne wzorce obsługi wyjątków, możesz użyć wyrażeń opisanych wcześniej w tym artykule. Możesz wykonać jedną akcję obsługi wyjątków poza tym zakresem, która przyjmuje całą przefiltrowaną tablicę błędów, a następnie usunąć akcję For_each. Możesz również uwzględnić inne przydatne właściwości z odpowiedzi \@result(), jak opisano wcześniej.

Konfigurowanie dzienników usługi Azure Monitor

Poprzednie wzorce są przydatnymi sposobami obsługi błędów i wyjątków występujących w ramach przebiegu. Można jednak również identyfikować błędy występujące niezależnie od przebiegu i reagować na nie. Aby ocenić statusy uruchomień, możesz monitorować dzienniki i metryki swoich uruchomień lub publikować je w dowolnym wybranym narzędziu do monitorowania.

Na przykład usługa Azure Monitor zapewnia usprawniony sposób wysyłania wszystkich zdarzeń przepływu pracy, w tym wszystkich stanów uruchamiania i akcji, do miejsca docelowego. Alerty dla określonych metryk i progów można skonfigurować w usłudze Azure Monitor. Zdarzenia przepływu pracy można również wysyłać do obszaru roboczegousługi Log Analytics lub konta usługi Azure Storage. Możesz też przesyłać strumieniowo wszystkie zdarzenia za pośrednictwem usługi Azure Event Hubs do usługi Azure Stream Analytics. W usłudze Stream Analytics można pisać zapytania na żywo na podstawie wszelkich anomalii, średnich lub niepowodzeń z dzienników diagnostycznych. Usługi Stream Analytics można użyć do wysyłania informacji do innych źródeł danych, takich jak kolejki, tematy, SQL, Azure Cosmos DB lub Power BI.

Aby uzyskać więcej informacji, zobacz Konfigurowanie dzienników usługi Azure Monitor i zbieranie danych diagnostycznych dla usługi Azure Logic Apps.

Przykłady i scenariusze usługi Azure Logic Apps

Opinia

Czy ta strona była pomocna?

Last updated on 2026-07-10