Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Zasada GrowFault umożliwia deweloperom interfejsu API inicjowanie przepływu błędów, ustawianie zmiennych błędu w komunikacie treści odpowiedzi i ustawianie odpowiednich kodów stanu odpowiedzi. Za pomocą zasady GrowFault możesz też ustawić zmienne przepływu dotyczące błędu, na przykład fault.name, fault.type i fault.category. Te zmienne są widoczne w danych analitycznych i logach dostępu do routera używanych do debugowania, dlatego ważne jest dokładne rozpoznanie błędu.
Dzięki zasadzie GrowFault możesz traktować określone warunki jako błędy, nawet jeśli rzeczywisty błąd nie wystąpił w innej zasadzie ani na serwerze backendu serwera proxy interfejsu API. Jeśli na przykład chcesz, aby serwer proxy wysyłał do aplikacji klienckiej niestandardowy komunikat o błędzie za każdym razem, gdy treść odpowiedzi backendu zawiera ciąg unavailable, możesz wywołać zasadę romotingFault zgodnie z poniższym fragmentem kodu:
<!-- /antipatterns/examples/raise-fault-conditions-1.xml -->
<TargetEndpoint name="default">
...
<Response>
<Step>
<Name>RF-Service-Unavailable</Name>
<Condition>(message.content Like "*unavailable*")</Condition>
</Step>
</Response>
...
Nazwa zasady GrowFault jest widoczna jako fault.name w
monitorowaniu interfejsów API oraz jako x_apigee_fault_policy w logach dostępu Analytics i routera.
Ułatwi to zdiagnozowanie przyczyny błędu.
Antywzór
Używanie zasady PodnieśFault w regułach FaultRules po tym, jak inna zasada już wywołała błąd
Przyjrzyj się temu przykładowi, w którym zasada OAuthV2 w procesie serwera proxy interfejsu API nie powiodła się z powodu błędu InvalidAccessToken. W przypadku niepowodzenia Edge ustawi fault.name na InvalidAccessToken, przejdzie do przepływu błędów i uruchomi wszystkie zdefiniowane reguły FaultRule. W regule FaultRule znajduje się zasada GrowFault o nazwie RaiseFault, która wysyła niestandardową odpowiedź dotyczącą błędu, gdy wystąpi błąd InvalidAccessToken. Jednak użycie zasady GrowFault w regule FaultRule oznacza, że zmienna fault.name jest zastępowana i maskuje prawdziwą przyczynę błędu.
<!-- /antipatterns/examples/raise-fault-conditions-2.xml -->
<FaultRules>
<FaultRule name="generic_raisefault">
<Step>
<Name>RaiseFault</Name>
<Condition>(fault.name equals "invalid_access_token") or (fault.name equals "InvalidAccessToken")</Condition>
</Step>
</FaultRule>
</FaultRules>
Używanie zasady PodnieśFault w regule błędów w dowolnych warunkach
W poniższym przykładzie zasada GrowFault o nazwie RaiseFault jest wykonywana, jeśli fault.name nie jest RaiseFault:
<!-- /antipatterns/examples/raise-fault-conditions-3.xml -->
<FaultRules>
<FaultRule name="fault_rule">
....
<Step>
<Name>RaiseFault</Name>
<Condition>!(fault.name equals "RaiseFault")</Condition>
</Step>
</FaultRule>
</FaultRules>
Tak jak w pierwszym scenariuszu, najważniejsze zmienne błędu fault.name, fault.code i fault.policy są zastępowane nazwą zasady GrowFault. Takie działanie niemal uniemożliwia określenie, która zasada faktycznie spowodowała błąd, bez dostępu do pliku śledzenia, który pokazuje błąd lub powoduje odtworzenie problemu.
Użycie zasady GrowFault do zwrócenia odpowiedzi HTTP 2xx poza przepływem błędów.
W przykładzie poniżej zasada GrowFault o nazwie HandleOptionsRequest jest wykonywana, gdy czasownik żądania to OPTIONS:
<!-- /antipatterns/examples/raise-fault-conditions-4.xml -->
<PreFlow name="PreFlow">
<Request>
…
<Step>
<Name>HandleOptionsRequest</Name>
<Condition>(request.verb Equals "OPTIONS")</Condition>
</Step>
…
</PreFlow>
Intencją jest natychmiastowe zwrócenie odpowiedzi klientowi interfejsu API bez przetwarzania innych zasad. Będzie to jednak prowadzić do wprowadzania w błąd danych analitycznych, ponieważ zmienne błędu będą zawierać nazwę zasady romotingFault, co utrudnia debugowanie serwera proxy. Prawidłowy sposób wdrożenia pożądanego działania to użycie przepływów ze specjalnymi warunkami, jak opisano w sekcji Dodawanie obsługi CORS.
Wpływ
Zastosowanie zasady GrowFault zgodnie z powyższym opisem spowoduje zastąpienie kluczowych zmiennych błędów nazwy zasadą GrowFault zamiast nazwy zasady z błędami. W logach dostępu w Analytics i NGINX zmienne x_apigee_fault_code i x_apigee_fault_policy są zastępowane. W monitorowaniu interfejsów API wartości Fault Code i Fault Policy są zastępowane. Takie zachowanie utrudnia rozwiązanie problemu i ustalenie, która zasada jest prawdziwą przyczyną niepowodzenia.
Na zrzucie ekranu poniżej z usługi API Monitoring widać, że zasady dotyczące kodów błędów i błędów zostały zastąpione ogólnymi wartościami RaiseFault, co uniemożliwia ustalenie głównej przyczyny błędu na podstawie logów:
Sprawdzona metoda
Gdy zasada brzegowa zgłasza błąd i chcesz dostosować komunikat o błędzie, użyj zasady AssignMessage lub JavaScript zamiast zasady ThroughFault.
Zasadę romotingFault należy używać w przepływie innym niż błąd. Oznacza to, że funkcja ThroughFault powinna być używana tylko do traktowania konkretnego warunku jako błędu, nawet jeśli rzeczywisty błąd nie wystąpił w zasadzie ani na serwerze backendu serwera proxy interfejsu API. Możesz na przykład użyć zasady GrowFault, aby zasygnalizować, że brakuje wymaganych parametrów wejściowych lub że ich składnia jest nieprawidłowa.
Możesz również użyć funkcji romotingFault w regule błędu, jeśli chcesz wykrywać błąd podczas jego przetwarzania. Na przykład sam moduł obsługi błędów może spowodować błąd, który chcesz zasygnalizować za pomocą funkcji romotingFault.