Co musisz wiedzieć o błędach zasad

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.