Oglądasz dokumentację Apigee Edge.
Wyświetl dokumentację Apigee X.
W tym artykule opisujemy strukturę błędów zasad i rodzaje zmiennych przepływu, które są ustawiane, gdy wystąpi błąd. Ta informacja ma kluczowe znaczenie przy projektowaniu i implementowaniu obsługi błędów na serwerach proxy.
Ten temat zakłada, że masz ogólną wiedzę o działaniu obsługi błędów w Edge i wiesz, czym są reguły błędów. Jeśli potrzebujesz opinii, przeczytaj artykuł Obsługa błędów. Te informacje pomogą Ci również poruszać się po przewodniku po błędach zasad i go używać.
Domyślna odpowiedź na żądanie dotyczące zasad
Gdy zasada zgłasza błąd, Edge natychmiast przechodzi do przepływu błędu i generuje komunikat o błędzie. Ta wiadomość wygenerowana przez system to obiekt JSON zawierający 2 bity informacji: kod błędu i ciąg błędu.
Na przykład:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse" } }
Przeanalizujmy ten komunikat o błędzie:
Kod błędu składa się z prefiksu i nazwy błędu w ten sposób: [prefix].[error_name]
. W przykładzie powyżej „steps.extractvariables
” jest prefiksem, a SourceMessageNotAvailable
– nazwą błędu. Prefiks informuje, jakie zasady spowodowały błąd. W powyższym przykładzie widać, że zasada Wyodrębnij zmienne wygenerowała błąd, a nazwa błędu to SourceMessageNotAvailable
.
Fultstring – zawiera opis błędu. Ciąg znaków z błędem zwykle zawiera wskazówki, które ułatwiają znalezienie konkretnego problemu, np. nazwy zasady lub nazwy nierozstrzygniętej zmiennej lub dowolnej przyczyny tego błędu. Na przykład w powyższym komunikacie o błędzie „foo
” jest nazwą nierozpoznanej zmiennej, do której odwołuje się zasada, a „ParseJsonResponse
” to nazwa zasady, która spowodowała błąd.
Zmienne specyficzne dla błędów zasad
Gdy wystąpi błąd zasad, wypełnione zostaną określone zmienne przepływu dotyczące konkretnych błędów. Te zmienne są bardzo przydatne w przypadku obsługi błędów. Zgodnie z opisem w sekcji Obsługa błędów popularną praktyką jest wychwytywanie błędów zasad wygenerowanych przez system i wykonywanie kolejnych działań, takich jak utworzenie niestandardowej odpowiedzi błędu. Ze względów bezpieczeństwa możesz na przykład uniemożliwić klientom wyświetlanie rzeczywistych błędów i kodów stanu, które zwraca Edge.
Zmienna fault.name
Gdy zasada zgłasza błąd, ustawia zmienną fault.name
dla fragmentu error_name
kodu błędu (jak opisano w poprzedniej sekcji). Ocena tej zmiennej jest bardzo prosta w warunkach warunkowych.
Przykładowa reguła błędu o wartości fault.name
:
<faultrule name="VariableOfNonMsgType"<>/faultrule><FaultRule name="Source Message Not Available Fault"> <Step> <Name>AM-CustomErrorMessage</Name> <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition> </Step> </FaultRule>
Pamiętaj, że gdy zasada powoduje błąd, zmienna fault.name
zawsze zawiera nazwę błędu.
Zmienna [prefix].[policy_name].failed
Kolejną zmienną, która często jest sprawdzana przez programistów, jest fault.name
. Flaga [prefix].[policy_name].failed
ma wartość Prawda lub Fałsz po uruchomieniu zasady. Sprawdź w regułach błędów, czy jest to prawda, czyli czy wystąpił błąd. Oto jak utworzyć warunek, który sprawdzi flagę [prefix].[policy_name].failed
. Aby prawidłowo sprawdzić tę zmienną, musisz wiedzieć:
- Nazwa zasady, którą chcesz sprawdzić. To wartość atrybutu nazwy zasady, a nie wyświetlanej nazwy. Ten atrybut jest zawsze dodawany do kodu XML definicji zasady.
- Prefiks charakterystyczny dla typu sprawdzanej zasady. (Poniżej dowiesz się, jak znaleźć ten prefiks).
Oto jeszcze jeden przykład reguły błędu. Zwróć uwagę na zewnętrzny warunek tworzenia nazwy zmiennej [prefix].[policy_name].failed
. W tym przypadku prefiks to extractvariables
, a nazwa zasady to ParseJsonResponse
. W tym przypadku reguła błędu będzie uruchamiana tylko wtedy, gdy zmienna będzie miała wartość true. Wskazówka: ponieważ w tych regułach może być wiele kroków, może to być dobry sposób na dzielenie reguł na bloki.
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Extract Variable Faults"> <Step> <Name>AM-CustomErrorMessage</Name> <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition> </Step> <Condition>(extractvariables.ParseJsonResponse.failed = true) </Condition> </FaultRule>
Zmienne error
i message
Zmienna error
jest dostępna tylko w przypadku wystąpienia błędu serwera proxy. Informacje ze zmiennej błędu, takie jak komunikat o błędzie, kod stanu czy wyrażenie przyczyny, mogą służyć do przekazywania przydatnych informacji. Wzorzec formatowania zmiennej błędu wygląda tak:
error.[error_component] = [value]
Na przykład:
error.message
= "request message is not available for ExtractVariable:
ParseJsonResponse
i
error.status.code = "500"
Zmienna message
jest też dostępna w procesie błędu i można jej używać w podobnych celach co zmienna error
. Zmienna komunikatu jest wyjątkowa, ponieważ ma kontekst. W przepływie żądania działa on jak zmienna żądania i może służyć do pobierania lub ustawiania wartości odpowiedzi. Więcej informacji znajdziesz w artykule Przypadki użycia zmiennych wiadomości.
Informacje o wszystkich zmiennych brzegowych, w tym error
i message
, znajdziesz w dokumentacji zmiennych.