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

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Z tego artykułu dowiesz się, jak wygląda struktura błędów zasad oraz jakie rodzaje zmiennych przepływu są ustawiane, gdy wystąpi błąd zasady. Te informacje są niezbędne, jeśli projektujesz i wdrażasz obsługę błędów w swoich serwerach proxy.

W tym artykule zakładamy, że masz ogólną wiedzę na temat obsługi błędów w Edge i wiesz, czym są reguły błędów. Jeśli chcesz powtórzyć te informacje, przeczytaj artykuł Obsługa błędów. Informacje zawarte w tym artykule pomogą Ci też poruszać się po dokumentacji Błędy zasad i korzystać z niej.

Domyślna odpowiedź na błąd zasady

Gdy zasada zgłosi błąd, Edge natychmiast przechodzi do przepływu błędów i generuje komunikat o błędzie. Ten wygenerowany przez system komunikat to obiekt JSON, który zawiera 2 informacje: an errorcode i a faultstring.

Na przykład:

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

Szybko przeanalizujmy ten komunikat o błędzie:

errorcode składa się z prefiksu i nazwy błędu w następujący sposób: [prefix].[error_name]. W powyższym przykładzie „steps.extractvariables" to prefiks, a SourceMessageNotAvailable to nazwa błędu. Prefiks informuje, jaki rodzaj zasady wygenerował błąd. W powyższym przykładzie widać, że błąd został wygenerowany przez zasadę Extract Variables, a jego nazwa to SourceMessageNotAvailable.

faultstring zawiera opis błędu. Ciąg błędów zwykle zawiera wskazówki, które pomagają znaleźć konkretny problem, który spowodował błąd, np. nazwę zasady, nazwę nierozwiązanej zmiennej lub cokolwiek innego, co przyczyniło się do błędu. Na przykład w powyższym komunikacie o błędzie „foo” to nazwa nierozwiązanej zmiennej wiadomości, 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 zasady, wypełniane są określone zmienne przepływu specyficzne dla błędu. Te zmienne są bardzo przydatne w obsłudze błędów. Jak wyjaśniono w artykule Obsługa błędów, powszechną praktyką jest przechwytywanie wygenerowanych przez system błędów zasad i wykonywanie kolejnych działań, takich jak tworzenie 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łosi błąd, ustawia zmienną przepływu fault.name na część error_name kodu błędu (jak opisano w poprzedniej sekcji). Bardzo często ta zmienna jest oceniana w celu warunkowego wykonania reguł błędów.

Oto przykład reguły błędów, która sprawdza 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 spowoduje błąd, zmienna fault.name jest zawsze ustawiana na nazwę błędu.

Zmienna [prefix].[policy_name].failed

Oprócz fault.name deweloperzy często sprawdzają też flagę [prefix].[policy_name].failed, która jest ustawiana na true lub false, gdy zasada jest wykonywana. W regułach błędów warto sprawdzić, kiedy jest prawda – czyli czy wystąpił błąd. Oto jak utworzyć warunek, który sprawdza flagę [prefix].[policy_name].failed. Aby prawidłowo sprawdzić tę zmienną, musisz znać 2 rzeczy:

• Nazwę zasady, którą sprawdzasz. Jest to wartość atrybutu name zasady, a nie nazwa wyświetlana. Ten atrybut jest zawsze uwzględniany w kodzie XML definicji zasady.
• Prefiks , który jest specyficzny dla typu zasady, którą sprawdzasz. (Poniżej wyjaśnimy, jak znaleźć prefiks ).

Aby to zilustrować, podajemy kolejny przykład reguły błędów. Zwróć uwagę, jak w warunku zewnętrznym tworzona jest nazwa zmiennej [prefix].[policy_name].failed. W tym przypadku prefiks to extractvariables a nazwa zasady to ParseJsonResponse. W tym przypadku reguła błędów zostanie wykonana tylko wtedy, gdy ta zmienna ma wartość true. Wskazówka: ponieważ reguły błędów mogą zawierać wiele kroków, 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 w przepływie błędów serwera proxy. Możesz uzyskać przydatne informacje ze zmiennej error, takie jak komunikat o błędzie, kod stanu , fraza przyczyny itp. Wzorzec formatowania zmiennej error jest następujący:

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 przepływie błędów i może być używana do podobnych celów jak zmienna error. Zmienna message jest specjalna, ponieważ jest kontekstowa. W przepływie żądania zachowuje się jak zmienna żądania, a w przepływie odpowiedzi można jej używać do pobierania i ustawiania wartości odpowiedzi. Więcej informacji znajdziesz w artykule Przypadki użycia zmiennych wiadomości.

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