Zasady dotyczące INCREASEFault

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Co

Generuje komunikat niestandardowy w odpowiedzi na warunek błędu. Użyj funkcji PodnieśFault, aby zdefiniować odpowiedź błędu, która jest zwracana do aplikacji wysyłającej żądanie, gdy wystąpi określony warunek.

Ogólne informacje o obsłudze błędów znajdziesz w sekcji Obsługa błędów.

Sample

<RaiseFault name="404">
 <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
 <FaultResponse>
   <Set>
     <StatusCode>404</StatusCode>
     <ReasonPhrase>The resource requested was not found</ReasonPhrase>
   </Set>
 </FaultResponse>
</RaiseFault>

<RaiseFault name="ExceptionHandler">
 <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
 <FaultResponse>
   <Set>
     <Payload contentType="text/xml">
       <root>Please contact support@company.com</root>
     </Payload>
     <StatusCode>{response.status.code}</StatusCode>
     <ReasonPhrase>Server error</ReasonPhrase>
   </Set>
   <Add>
     <Headers>
       <Header name="FaultHeader">{fault.name}</Header>
     </Headers>
   </Add>
 </FaultResponse>
</RaiseFault>

Informacje o zasadzie bidFault

Apigee Edge umożliwia niestandardową obsługę wyjątków za pomocą zasady typu FoundFault. Zasada GrowFault, która jest podobna do zasady AssignMessage, umożliwia generowanie niestandardowej odpowiedzi o błędzie w odpowiedzi na warunek błędu.

Zasada GrowFault pozwala zdefiniować odpowiedź błędu, która jest zwracana do aplikacji wysyłającej żądanie w przypadku wystąpienia określonego stanu błędu. Odpowiedź błędu może zawierać nagłówki HTTP, parametry zapytania i ładunek wiadomości. Niestandardowa odpowiedź o błędzie może być bardziej przydatna dla deweloperów i użytkowników aplikacji niż ogólne komunikaty o błędach czy kody odpowiedzi HTTP.

Po uruchomieniu zasada bidFault przenosi kontrolę z bieżącego procesu do przepływu błędów, która zwraca wyznaczoną odpowiedź o błędzie do żądającej aplikacji klienckiej. Gdy przepływ komunikatu przełącza się na przepływ błędów, nie jest już przetwarzane żadne dalsze przetwarzanie zasady. Wszystkie pozostałe kroki przetwarzania są pomijane, a odpowiedź o błędzie jest zwracana bezpośrednio do aplikacji wysyłającej żądanie.

Funkcji GrowFault możesz używać w punkcie ProxyEndpoint lub TargetEndpoint. Zwykle do zasady PodnieśFault dołącza się warunek. Po wykonaniu RequestFault Apigee przeprowadzi normalne przetwarzanie błędów, oceniając reguły FaultRules, a jeśli nie ma zdefiniowanych reguł błędów, kończy przetwarzanie żądania.

Odwołanie do elementu

Dokumentacja elementów opisuje elementy i atrybuty zasady FoundFault.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="Raise-Fault-1">
    <DisplayName>RaiseFault 1</DisplayName>
    <FaultResponse>
        <AssignVariable>
          <Name/>
          <Value/>
        </AssignVariable>
        <Add>
            <Headers/>
        </Add>
        <Copy source="request">
            <Headers/>
            <StatusCode/>
            <ReasonPhrase/>
        </Copy>
        <Remove>
            <Headers/>
        </Remove>
        <Set>
            <Headers/>
            <Payload/>
            <ReasonPhrase/>
            <StatusCode/>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

Atrybuty <PodnieśFault>

<RaiseFault async="false" continueOnError="false" enabled="true" name="Raise-Fault-1">

Tabela poniżej zawiera opis atrybutów wspólnych dla wszystkich elementów nadrzędnych zasad:

Element <DisplayName>

Użyj oprócz atrybutu name, aby oznaczyć zasadę w edytorze serwera proxy interfejsu zarządzania inną nazwą w języku naturalnym.

<DisplayName>Policy Display Name</DisplayName>

Element <IgnorujNierozpoznane zmienne>

(Opcjonalnie) Ignoruje wszystkie nieusunięte błędy zmiennych w procesie. Prawidłowe wartości: prawda/fałsz. Domyślnie true.

Element <FaultResponse>

(Opcjonalnie) Definiuje wiadomość z odpowiedzią zwracaną klientowi, który wysłał żądanie. FaultResponse używa tych samych ustawień co zasada AssignMessage (niedostępna w Apigee Edge dla Private Cloud).

Element <FaultResponse><AssignVariable>

Przypisuje wartość do docelowej zmiennej przepływu danych. Jeśli zmienna przepływu nie istnieje, tworzy ją AssignVariable.

Na przykład użyj tego kodu, aby ustawić zmienną o nazwie myFaultVar w zasadzie romotingFault:

<FaultResponse>
  <AssignVariable>
    <Name>myFaultVar</Name>
    <Value>42</Value>
  </AssignVariable>
  ...
</FaultResponse>

Możesz później odwoływać się do tej zmiennej w szablonach wiadomości w zasadzie GrowFault. Ponadto zasada powiązana z regułą FaultRule może uzyskać dostęp do tej zmiennej. Na przykład poniższa zasada AssignMessage korzysta ze zmiennej ustawionej we RequestFault do ustawienia nagłówka w odpowiedzi błędu:

<AssignMessage enabled="true" name="Assign-Message-1">
  <Add>
    <Headers>
      <Header name="newvar">{myFaultVar}</Header>
    </Headers>
  </Add>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

<AssignVariable> w zasadzie GrowFault używa tej samej składni co element <AssignVariable> w zasadzie AssignMessage. Ta funkcja nie jest obecnie dostępna w Apigee Edge dla Private Cloud.

Element <FaultResponse><Add>/<Headers>

Dodaje nagłówki HTTP do komunikatu o błędzie. Zwróć uwagę, że pusty nagłówek <Add><Headers/></Add> nie zawiera żadnego nagłówka. W tym przykładzie wartość zmiennej przepływu request.user.agent jest kopiowana do nagłówka.

<Add>
    <Headers>
        <Header name="user-agent">{request.user.agent}</Header>
    </Headers>
</Add>

Element <FaultResponse><Copy>

Kopiuje informacje z komunikatu o błędzie do komunikatu o błędzie.source

    <Copy source="request">
        <Headers/>
        <StatusCode/>
        <ReasonPhrase/>
    </Copy>

Atrybuty

 <Copy source="response">

Element <FaultResponse><Copy>/<Headers>

Kopiuje określony nagłówek HTTP ze źródła do komunikatu o błędzie. Aby skopiować wszystkie nagłówki, wpisz <Copy><Headers/></Copy>.

<Copy source='request'>
    <Headers>      
        <Header name="headerName"/>
    </Headers> 
</Copy>

Jeśli kilka nagłówków ma taką samą nazwę, użyj tej składni:

<Copy source='request'>
    <Headers>
      <Header name="h1"/>
      <Header name="h2"/>
      <Header name="h3.2"/>
    </Headers>
</Copy>

W tym przykładzie skopiujemy „h1”, „h2” oraz drugą wartość „h3”. Jeśli parametr „h3” ma tylko 1 wartość, nie jest kopiowana.

Element <FaultResponse><Copy>/<StatusCode>

Kod stanu HTTP, który ma zostać skopiowany z obiektu określonego przez atrybut źródłowy do komunikatu o błędzie.

<Copy source='response'>
    <StatusCode>404</StatusCode>      
</Copy>

Element <FaultResponse><Copy>/<ReasonPhrase>

Opis przyczyny do skopiowania z obiektu określonego przez atrybut źródła do komunikatu o błędzie.

<Copy source='response'>     
    <ReasonPhrase>The resource requested was not found.</ReasonPhrase>     
</Copy>

Element <FaultResponse><Remove>/<Headers>

Usuwa określone nagłówki HTTP z komunikatu o błędzie. Aby usunąć wszystkie nagłówki, wpisz <Remove><Headers/></Remove>. Ten przykład usuwa z wiadomości nagłówek user-agent.

<Remove>     
    <Headers>      
        <Header name="user-agent"/>     
    </Headers> 
</Remove>

Jeśli kilka nagłówków ma taką samą nazwę, użyj tej składni:

<Remove>
    <Headers>
      <Header name="h1"/>
      <Header name="h2"/>
      <Header name="h3.2"/>
    </Headers>
</Remove>

W tym przykładzie usunięto „h1”, „h2” oraz drugą wartość „h3”. Jeśli „h3” ma tylko 1 wartość, nie jest usuwana.

Element <FaultResponse><Set>

Ustawia informacje w komunikacie o błędzie.

    <Set>
        <Headers/>
        <Payload> </Payload>
        <StatusCode/>
        <ReasonPhrase/>
    </Set>

Element <FaultResponse>/<Set>/<Headers>

Ustawia lub zastępuje nagłówki HTTP w komunikacie o błędzie. Pamiętaj, że pusty nagłówek <Set><Headers/></Set> nie ustawia żadnego nagłówka. W tym przykładzie nagłówek user-agent ustawia się na zmienną wiadomości określoną za pomocą elementu <AssignTo>.

<Set>
    <Headers>
        <Header name="user-agent">{request.header.user-agent}</Header>     
    </Headers>
</Set>

Element <FaultResponse>/<Set>/<Payload>

Ustawia ładunek komunikatu o błędzie.

<Set>
    <Payload contentType="text/plain">test1234</Payload>
</Set>

Ustaw ładunek JSON:

<Set>
    <Payload contentType="application/json">
        {"name":"foo", "type":"bar"}
    </Payload>
</Set>

W ładunku JSON możesz wstawiać zmienne za pomocą atrybutów variablePrefix i variableSuffix ze znakami separatora, jak w tym przykładzie.

<Set>
    <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
        {"name":"foo", "type":"@variable_name#"}
    </Payload>
</Set>

Natomiast od wersji Cloud 16.08.17 możesz używać nawiasów klamrowych do wstawiania zmiennych:

<Set>
    <Payload contentType="application/json">
        {"name":"foo", "type":"{variable_name}"}
    </Payload>
</Set>

Ustaw ładunek mieszany w pliku XML:

<Set>
    <Payload contentType="text/xml">
        <root>
          <e1>sunday</e1>
          <e2>funday</e2>
          <e3>{var1}</e3>
    </Payload>
</Set>

Atrybuty

 
<Payload contentType="content_type" variablePrefix="char" variableSuffix="char">

Element <FaultResponse>/<Set>/<StatusCode>

Ustawia kod stanu odpowiedzi.

<Set source='request'>
    <StatusCode>404</StatusCode>
</Set>

Element <FaultResponse>/<Set>/<ReasonPhrase>

Ustawia treść odpowiedzi.

<Set source='request'>     
    <ReasonPhrase>The resource requested was not found.</ReasonPhrase>
</Set>

Element <ShortFaultReason>

Określa, czy w odpowiedzi ma być wyświetlana przyczyna błędu:

<ShortFaultReason>true|false</ShortFaultReason>

Domyślnie przyczyna błędu w odpowiedzi zasady to:

"fault":{"faultstring":"Raising fault. Fault name : Raise-Fault-1","detail":{"errorcode":"errorCode"}}}

Aby wiadomość była bardziej czytelna, możesz ustawić w elemencie <ShortFaultReason> wartość true, aby skrócić faultstring tylko do nazwy zasady:

"fault":{"faultstring":"Raise-Fault-1","detail":{"errorcode":"errorCode"}}}

Prawidłowe wartości: true/false(domyślnie).

Zmienne przepływu

Zmienne przepływu umożliwiają dynamiczne zachowanie zasad i przepływów w czasie działania w zależności od nagłówków HTTP, treści wiadomości lub kontekstu przepływu. Poniższe wstępnie zdefiniowane zmienne przepływu są dostępne po wykonaniu zasady romotingFault. Więcej informacji o zmiennych przepływu znajdziesz w artykule Informacje o zmiennych.

Przykład użycia GrowFault

W tym przykładzie użyto warunku, aby w żądaniu przychodzącym wymusić obecność elementu queryparam o nazwie zipcode. Jeśli queryparam nie jest podany, przepływ spowoduje zgłoszenie błędu przez RequestFault:

<Flow name="flow-1">
  <Request>
    <Step>
        <Name>RF-Error-MissingQueryParam</Name>
        <Condition>request.queryparam.zipcode = null</Condition>
    </Step>
   ...
   </Request>
   ...
   <Condition>(proxy.pathsuffix MatchesPath "/locations") and (request.verb = "GET")</Condition>
</Flow>

<RaiseFault name='RF-Error-MissingQueryParam'>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <FaultResponse>
    <Set>
      <Payload contentType='application/json'>{
  "error" : {
    "code" : 400.02,
    "message" : "invalid request. Pass a zipcode queryparam."
  }
}
</Payload>
      <StatusCode>400</StatusCode>
      <ReasonPhrase>Bad Request</ReasonPhrase>
    </Set>
  </FaultResponse>
</RaiseFault>

Informacje o błędach

W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, a także zmienne błędów ustawiane przez Edge, gdy ta zasada aktywuje błąd. Te informacje są ważne, jeśli opracowujesz reguły dotyczące błędów do obsługi takich błędów. Więcej informacji znajdziesz w sekcjach Co musisz wiedzieć o błędach zasad i Postępowanie w przypadku błędów.

Błędy w czasie wykonywania

Te błędy mogą wystąpić podczas wykonywania zasady.

Błędy wdrażania

Brak.

Zmienne błędów

Te zmienne są ustawiane, gdy wystąpi błąd środowiska wykonawczego. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z naruszeniem zasad.

Przykładowa odpowiedź na błąd

{
   "fault":{
      "detail":{
         "errorcode":"steps.raisefault.RaiseFault"
      },
      "faultstring":"Raising fault. Fault name: [name]"
   }
}

Schemat

Każdy typ zasady jest definiowany przez schemat XML (.xsd). Schematy zasad są dostępne na GitHubie.

Powiązane artykuły

Patrz Obsługa błędów