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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

W tym temacie opisujemy strukturę błędów związanych z zasadami i rodzaje zmiennych przepływu, które mogą ustawiany, gdy wystąpi błąd zasad. Te informacje są niezbędne, jeśli projektujesz zaimplementowanie obsługi błędów w serwerach proxy.

W tym temacie zakładamy, że masz ogólną wiedzę o działaniu obsługi błędów w Edge oraz że wiesz, czym są reguły błędów. Jeśli potrzebujesz sprawdzenia, zobacz Obsługa błędów. Podane tu informacje będą też pomocne w nawigacji i korzystaniu z informacji o błędach zasad.

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

Gdy zasada zgłasza błąd, Edge od razu rozpoczyna proces błędu i generuje błąd. . Ten komunikat wygenerowany przez system to obiekt JSON zawierający 2 bity informacji: errorcode i faultstring (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 błędu w następujący sposób: [prefix].[error_name]. W przykładzie powyżej „steps.extractvariables” to prefiks, a SourceMessageNotAvailable to nazwa błędu. Wskazuje on rodzaj zasady, która wygenerowała błąd. W powyższych możesz np. sprawdzić, że zasada Wyodrębnianie zmiennych wygenerowała błąd, a jego nazwa to SourceMessageNotAvailable

Ciąg znaków błędu zawiera opis błędu. Ciąg błędu zwykle zawiera wskazówki ułatwiające znalezienie problemu, który spowodował błąd, na przykład nazwa zasady, nazwa nierozwiązanej zmiennej lub inny element, który przyczynił się do błędu. Dla: np. w powyższym komunikacie o błędzie: „foo” to na przykład nazwa nierozstrzygniętej zmienna wiadomości, do której odwołuje się zasada i „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 są bardzo przydatne przy usuwaniu błędów. Jak wyjaśniliśmy w sekcji Postępowanie w przypadku błędów, często powtarza się przechwytywać wygenerowane przez system błędy zasad i wykonywać kolejne działania, takie jak utworzenie niestandardową odpowiedź na żądanie błędu. Ze względów bezpieczeństwa możesz na przykład uniemożliwić klientom z błędami i kodami stanu zwracanymi przez Edge.

fault.name zmienna

Jeśli zasada zgłasza błąd, ustawia zmienną przepływu fault.name na error_name części kodu błędu (jak opisano w poprzedniej sekcji). To bardzo często sprawdza się tę zmienną, aby warunkowo wykonywać reguły 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 wywołuje błąd, fault.name zmienna jest zawsze ustawiona na nazwę błędu.

Zmienna [prefix].[policy_name].failed

Oprócz fault.name inna zmienna, którą programiści często sprawdzają, to [prefix].[policy_name].failed, która jest ustawiona na wartość prawda lub fałsz, gdy . W przypadku reguł błędów warto sprawdzić, czy ma wartość true (prawda), czyli sprawdzenie, czy nie wystąpił błąd. Oto jak utworzyć warunek warunkowy, który sprawdza flaga [prefix].[policy_name].failed. Aby prawidłowo sprawdzić tę zmienną, należy: musisz wiedzieć 2 rzeczy:

• Nazwa zasady, którą chcesz sprawdzić. To jest wartość zasady name [nazwa], a nie wyświetlanej nazwy. Ten atrybut jest zawsze uwzględniany w zasadach XML definicji.
• prefiks specyficzny dla typu sprawdzanej zasady. (Zostanie jak znaleźć ten prefiks).

Aby zilustrować ten przykład, oto kolejny przykład reguły błędów. Zwróć uwagę na stan zewnętrzny, Utworzono nazwę zmiennej [prefix].[policy_name].failed. W tym przypadku prefiks jest taki: extractvariables, a nazwa zasady to ParseJsonResponse. W tym , reguła błędu będzie wykonywana tylko wtedy, gdy ta zmienna będzie prawdziwa. Na koniec wskazówka: błąd mogą obejmować wiele kroków, więc ten wzorzec jest dobrym sposobem na uporządkowanie reguł błędó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 programie Zmienne error i message

Zmienna error jest dostępna tylko w procesie błędu w serwera proxy. Ze zmiennej błędu można uzyskać przydatne informacje, np. komunikat o błędzie, stan kod, wyrażenie przyczyny itd. 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łędu i może być używana do o podobnych celach co zmienna error. Zmienna komunikatu jest wyjątkowa, ponieważ jest kontekstowa. W przepływie żądań działa jak zmienna żądania, a w procesie odpowiedzi może służyć do pobierania/ustawiania wartości odpowiedzi. Jeśli chcesz dowiedzieć się więcej, zapoznaj się z sekcją Korzystanie zmiennych wiadomości.

Patrz informacje o zmiennych. aby uzyskać informacje o wszystkich zmiennych Edge, w tym error i message