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

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

W tym temacie opisujemy strukturę błędów zasad i rodzaje zmiennych przepływu ustawianych w razie wystąpienia błędu zasad. Te informacje są niezbędne podczas projektowania i wdrażania obsługi błędów w serwerach proxy.

W tym artykule zakładamy, że wiesz, jak działa obsługa błędów w Edge, oraz że znasz reguły dotyczące błędów. Jeśli potrzebujesz pomocy, przeczytaj artykuł Rozwiązywanie problemów. Prezentowane tu informacje pomogą Ci też w korzystaniu z informacji o błędach zasad.

Informacje o odpowiedzi na błąd domyślnej zasady

Gdy polityka zwraca błąd, Edge natychmiast przechodzi do ścieżki błędu i generuje komunikat o błędzie. Ten komunikat wygenerowany 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 pokrótce ten komunikat o błędzie:

Kod błędu 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. Wskazuje on rodzaj zasady, która wygenerowała błąd. W powyższym przykładzie widać, że błąd wygenerowała zasada Wyodrębnianie zmiennych, a nazwa błędu to SourceMessageNotAvailable.

Ciąg znaków błędu zawiera opis błędu. Ciąg tekstowy błędu zawiera zwykle wskazówki, które pomogą Ci znaleźć konkretny problem, który spowodował błąd, np. nazwę zasady, nazwę niezdefiniowanej zmiennej lub cokolwiek innego, co przyczyniło się do błędu. Na przykład w powyższym komunikacie o błędzie „foo” to nazwa niezdefiniowanej zmiennej wiadomości, do której odwołuje się zasada, a „ParseJsonResponse” to nazwa zasady, która spowodowała błąd.

Zmienne związane z błędami związanymi z zasadami

Po wywołaniu błędu związanego z zasadami wypełniane są określone zmienne procesu związane z błędami. Te zmienne są bardzo przydatne przy obsłudze błędów. Jak wyjaśniliśmy w sekcji Obsługa błędów, powszechną praktyką jest przechwytywanie błędów zasad wygenerowanych przez system i wykonywanie kolejnych działań, na przykład utworzenie niestandardowej odpowiedzi na błąd. Ze względów bezpieczeństwa możesz na przykład 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 (jak opisano w poprzedniej sekcji). Zmienne te są często używane do warunkowego wykonywania reguł dotyczących błędów.

Oto przykładowa reguła błędu, 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 powoduje błąd, zmienna fault.name zawsze przyjmuje nazwę błędu.

Zmienna [prefix].[policy_name].failed

Oprócz zmiennej fault.name deweloperzy często sprawdzają też flagę [prefix].[policy_name].failed, która ma wartość prawda lub fałsz podczas wykonywania zasady. W przypadku reguł błędów należy sprawdzić, kiedy ma wartość true, czyli czy wystąpił błąd. Oto jak utworzyć regułę, która sprawdza flagę [prefix].[policy_name].failed. Aby prawidłowo sprawdzić tę zmienną, musisz pamiętać o 2 rzeczach:

• Nazwa zasady, którą sprawdzasz. Jest to wartość atrybutu nazwy w polityce, a nie wyświetlana nazwa. Ten atrybut jest zawsze zawarty w pliku XML definicji zasady.
• prefiks specyficzny dla typu sprawdzanej zasady. (poniżej wyjaśnimy, jak znaleźć prefiks).

Aby zilustrować ten przykład, oto kolejny przykład reguły błędów. Zwróć uwagę, jak w warunku zewnętrznym jest tworzona nazwa zmiennej [prefix].[policy_name].failed. W tym przypadku prefiks to extractvariables, a nazwa zasady to ParseJsonResponse. W tym przypadku reguła błędu zostanie wykonana tylko wtedy, gdy ta zmienna ma wartość Prawda. Wskazówka: reguły błędów mogą zawierać wiele kroków, więc ten wzorzec to dobry sposób 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 procesie błędu serwera proxy. Zmienne błąd zawierają przydatne informacje, takie jak komunikat o błędzie, kod stanu, fraza powodu itp. Formatowanie zmiennej błąd:

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 wiadomości jest szczególna, ponieważ jest kontekstowa. W przepływie żądania zachowuje się jak zmienna żądania, a w przepływie odpowiedzi może służyć 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 o error i message, znajdziesz w dokumentacji zmiennych.