Co musisz wiedzieć o błędach związanych z zasadami

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

W tym temacie opisujemy strukturę błędów zasad i rodzaje zmiennych przepływu ustawianych, gdy wystąpi błąd zasady. Ta informacja jest konieczna, gdy projektujesz i wdrażasz obsługę błędów serwerów proxy.

Zakładamy w nim, że znasz ogólne zasady działania obsługi błędów w Edge i wiesz, czym są reguły błędów. Jeśli chcesz je sprawdzić, zapoznaj się z artykułem Obsługa błędów. Zawarte tu informacje ułatwią Ci też poruszanie się po stronie z informacjami o błędach związanych z zasadami i korzystanie z niej.

Odpowiedź dotycząca błędu zasady domyślnej

Gdy zasada zgłasza błąd, Edge natychmiast wchodzi w proces błędów i generuje komunikat o błędzie. Ten komunikat wygenerowany przez system to obiekt JSON zawierający 2 bity informacji: errorcode i faultstring.

Na przykład:

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
   }
}

Przyjrzyjmy się szybko temu komunikatowi o błędzie:

Kod błędu składa się z prefiksu i nazwy błędu, jak to widać: [prefix].[error_name]. W tym przykładzie „steps.extractvariables” jest prefiksem, a SourceMessageNotAvailable to nazwa błędu. Prefiks informuje o rodzaju zasady, która wygenerowała błąd. W przykładzie powyżej można stwierdzić, że zasada Wyodrębnianie zmiennych wygenerowała błąd, a jego nazwa to SourceMessageNotAvailable.

Ciąg błędów zawiera opis błędu. Ciąg błędu zwykle zawiera wskazówki, które pomagają znaleźć konkretny problem, który spowodował błąd, takie jak nazwa zasady, nazwa nierozstrzygniętej zmiennej lub inne informacje, które przyczyniły się do wystąpienia błędu. Na przykład w powyższym komunikacie o błędzie „foo” jest nazwą nierozstrzygniętej zmiennej wiadomości, do której odwołuje się zasada, a „ParseJsonResponse” to nazwa zasady, która wywołała błąd.

Zmienne związane z błędami dotyczącymi zasad

W przypadku wystąpienia błędu zasad wypełnione są określone zmienne przepływu, związane z tym błędem. Te zmienne są bardzo przydatne przy obsłudze błędów. Jak wyjaśniliśmy w temacie Obsługa błędów, powszechną praktyką jest rejestrowanie błędów zasad wygenerowanych przez system i wykonywanie kolejnych działań, takich jak utworzenie niestandardowej odpowiedzi na błąd. Na przykład ze względów bezpieczeństwa możesz uniemożliwić klientom wyświetlanie rzeczywistych błędów i kodów stanu zwracanych przez Edge.

Zmienna fault.name

Gdy zasada zgłasza błąd, ustawia zmienną przepływu fault.name na część kodu błędu error_name (zgodnie z opisem w poprzedniej sekcji). Bardzo często ocenia się tę zmienną w celu warunkowego wykonywania reguł błędów.

Oto przykładowa reguła błędu, która testuje wartość 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 wywołuje błąd, zmienna fault.name jest zawsze ustawiana na nazwę błędu.

Zmienna [prefix].[policy_name].failed

Oprócz fault.name inna często sprawdzana zmienna to flaga [prefix].[policy_name].failed, która podczas wykonywania zasady ma wartość prawda lub fałsz. W przypadku reguł błędów musisz sprawdzić, czy ma wartość true (prawda), czyli aby ustalić, czy wystąpił błąd. Oto jak utworzyć warunek warunkowy, który sprawdza flagę [prefix].[policy_name].failed. Aby prawidłowo sprawdzić tę zmienną, musisz wiedzieć, że:

• Nazwa sprawdzanej zasady. To jest wartość atrybutu nazwy zasady, a nie wyświetlana nazwa. Ten atrybut jest zawsze zawarty w pliku XML definicji zasady.
• Prefiks specyficzny dla sprawdzanej zasady. Poniżej wyjaśnimy, jak znaleźć prefiks.

Dla zilustrowania podajemy kolejny przykład reguły błędu. Zwróć uwagę na to, jak tworzy się nazwa zmiennej [prefix].[policy_name].failed w warunku zewnętrznym. W tym przypadku prefiks to extractvariables, a nazwa zasady to ParseJsonResponse. W tym przypadku reguła błędu będzie wykonywana tylko wtedy, gdy ta zmienna będzie miała wartość prawda. Mam dla Ciebie wskazówkę: reguły błędów mogą obejmować wiele kroków, więc ten wzorzec jest dobrym sposobem na uporządkowanie reguł błędów w 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>

Informacje o zmiennych error i message

Zmienna error jest dostępna tylko podczas procesu błędów serwera proxy. Dzięki zmiennej błędu możesz uzyskać przydatne informacje, np. komunikat o błędzie, kod stanu, wyrażenie przyczyny itp. Wzorzec formatowania zmiennej błędu:

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łędów i można jej używać w podobnych celach co zmiennej error. Zmienna komunikatu jest wyjątkowa, ponieważ jest kontekstowa. W przepływie żądania działa ona jak zmienna żądania, a w przepływie odpowiedzi może być używana do pobierania/ustawiania wartości odpowiedzi. Więcej informacji znajdziesz w sekcji Przypadki użycia zmiennych wiadomości.

Informacje o wszystkich zmiennych Edge, w tym error i message, znajdziesz w dokumentacji zmiennych.