Antypattern: stosowanie zasady GrowFault w nieodpowiednich warunkach

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

Zasada RaiseFault umożliwia programistom interfejsów API inicjowanie przepływu błędów i ustawianie zmiennych błędów. w treści odpowiedzi i ustawić odpowiednie kody stanu odpowiedzi. Można również użyć funkcji RaiseFault zasady do ustawiania zmiennych przepływu związanych z błędem, np. fault.name, fault.type, i fault.category. Ponieważ te zmienne są widoczne w danych analitycznych i logach dostępu do routera do debugowania, ważne jest, aby dokładnie zidentyfikować błąd.

Za pomocą zasady RaiseFault możesz traktować określone warunki jako błędy, nawet jeśli rzeczywisty błąd został nie wystąpiła w innej zasadzie ani na serwerze backendu serwera proxy interfejsu API. Na przykład: serwer proxy do wysyłania niestandardowego komunikatu o błędzie do aplikacji klienckiej za każdym razem, gdy odpowiedź backendu [body] zawiera ciąg znaków unavailable, możesz więc wywołać zasadę RaiseFault jako w tym fragmencie 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 RaiseFault jest widoczna jako fault.name w API Monitoring oraz jako x_apigee_fault_policy w logach dostępu Analytics i routera. Pomoże to w łatwym zdiagnozowaniu przyczyny błędu.

Antywzór

Użycie zasady RaiseFault w ramach reguł FaultRules po tym, jak inna zasada zwróciła już błąd

Przyjrzyjmy się przykładowi poniżej, w którym zasada OAuthV2 w procesie proxy interfejsu API zakończyła się niepowodzeniem z użyciem parametru InvalidAccessToken . W przypadku niepowodzenia Edge ustawi w fault.name jako InvalidAccessToken, wpisz przepływu błędów i wykonanie wszystkich zdefiniowanych reguł FaultRules. W regule FaultRule znajduje się zasada RaiseFault o nazwie RaiseFault, który wysyła dostosowaną odpowiedź błędu za każdym razem, gdy InvalidAccessToken występuje błąd. Jednak użycie zasady RaiseFault w regule FaultRule oznacza, że 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 RaiseFault w regule błędów we wszystkich warunkach

W poniższym przykładzie zasada RaiseFault 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, kluczowe zmienne błędów fault.name, fault.code, i fault.policy są zastępowane nazwą zasady RaiseFault. Takie działanie sprawia, bez dostępu do logu czasu ustalenie, która zasada rzeczywiście spowodowała błąd, jest prawie niemożliwe plik zawierający błąd lub odtworzenie problemu.

Użycie zasady RaiseFault w celu zwrócenia odpowiedzi HTTP 2xx poza przepływem błędu.

W poniższym przykładzie zasada RaiseFault 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. Prowadzi to jednak do wprowadzających w błąd danych analitycznych, ponieważ zmienne błędów zawierają Nazwa zasady ZwiększFault, co utrudnia debugowanie serwera proxy. Właściwy sposób implementacji pożądanym działaniem jest używanie przepływów ze specjalnymi warunkami, tak jak to opisano w Dodanie obsługi CORS.

Wpływ

Zastosowanie zasady RaiseFault w opisany powyżej sposób powoduje zastąpienie kluczowych zmiennych błędów za pomocą parametru Nazwa zasady RaiseFault zamiast nazwy zasady, która powoduje błąd. W logach dostępu Analytics i NGINX zmienne x_apigee_fault_code i x_apigee_fault_policy zostaną zastąpione. W narzędziu API Monitoring Fault Code i Fault Policy są zastąpione. Utrudnia to rozwiązywanie problemów ustalenie, która zasada jest prawdziwą przyczyną niepowodzenia.

Na zrzucie ekranu poniżej z narzędzia API Monitoring zobaczysz, że zasady dotyczące kodu błędu i błędu zostały zastąpione ogólnym RaiseFault przez co niemożliwe jest ustalenie głównej przyczyny błędu na podstawie dzienników:

Sprawdzona metoda

Gdy zasada Edge zgłasza błąd i chcesz dostosować komunikat w odpowiedzi o błędzie, używa zasad AssignMessage lub JavaScript zamiast zasady RaiseFault.

Zasadę RaiseFault należy używać w przepływie innym niż błąd. Oznacza to, że za pomocą funkcji RaiseFault w celu wyeliminowania określonego błędu jako błąd, nawet jeśli żaden błąd nie wystąpił w zasadzie ani na serwerze backendu. serwera proxy interfejsu API. Możesz na przykład użyć zasady RaiseFault, aby zasygnalizować, że wymagane dane wejściowe brakuje parametrów lub mają one nieprawidłową składnię.

Tej funkcji możesz też użyć w regule błędu, jeśli chcesz wykrywać błąd podczas przetwarzania z powodu błędu. Na przykład sam moduł obsługi błędów może powodować błąd, który chcesz zasygnalizować za pomocą funkcji RaiseFault.

Więcej informacji