Gestione degli errori

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Quando i proxy API gestiscono le richieste delle app, possono verificarsi molte condizioni di errore. Per Ad esempio, i proxy API potrebbero riscontrare problemi di rete durante la comunicazione con i servizi di backend, le app potrebbero presentare credenziali scadute, i messaggi di richiesta potrebbero essere formattati in modo errato e così via attiva.

Quando si verifica un errore dopo che un'app client chiama un proxy API, viene restituito un messaggio di errore a il cliente. Per impostazione predefinita, il client riceve un messaggio di errore spesso criptico, senza dettagli o guida. Tuttavia, se vuoi sostituire i messaggi di errore predefiniti con messaggi personalizzati più utili e e persino arricchirli con intestazioni HTTP aggiuntive, e la gestione dei dati in Edge.

La gestione personalizzata degli errori consente anche di aggiungere funzionalità come il logging dei messaggi ogni volta che si verifica un errore.

Prima di parlare dell'implementazione della gestione personalizzata degli errori nei proxy API, è utile: capire come si verificano gli errori e come i proxy API reagiscono ad essi.

Video

Guarda i video che seguono per scoprire di più sulla gestione dei guasti.

Come si verificano gli errori

Innanzitutto, vedremo semplicemente come si verificano gli errori. Sapere come si verificano gli errori ti aiuta a pianificare per le diverse situazioni in cui vuoi implementare una gestione personalizzata degli errori.

Errori automatici

Un proxy API genera automaticamente un errore nelle seguenti situazioni:

• Un criterio genera un errore. Ad esempio, se una chiamata API invia una chiave scaduta, Il criterio VerifyAPIKey genera automaticamente un errore; o se il numero di chiamate API supera un determinato limite, il criterio per le quote o il criterio SpikeArrest genera un errore. (consulta la Guida di riferimento agli errori di criteri per tipi di errori che possono essere generati dai criteri).
• Si è verificato un problema nel flusso dei messaggi proxy API, ad esempio un errore di routing.
• Si è verificato un errore del backend, ad esempio un errore HTTP dovuto a errori a livello di protocollo, TLS/SSL o un servizio di destinazione non disponibile.
• Errore a livello di sistema, ad esempio eccezione di esaurimento memoria.

Per maggiori informazioni su questi errori, consulta la sezione Tassonomia degli errori in questo argomento.

Errori personalizzati

Nei casi in cui non si verifica un errore automatico, puoi generare un errore personalizzato. della Ad esempio, se una risposta contiene la parola "unavailable" o se il codice di stato HTTP è maggiore di 201. Per farlo, aggiungi un criterio RaiseFault alla sezione posto appropriato in un flusso di proxy API.

Puoi aggiungere un criterio RaiseFault a un flusso proxy API come faresti con qualsiasi altro criterio. Nella nel seguente esempio di configurazione proxy, il criterio Raise-Fault-1 è associato la risposta TargetEndpoint. Se la parola "unavailable" è presente nella risposta da parte del servizio, il criterio RaiseFault viene eseguito e genera un errore.

<TargetEndpoint name="default">
...
  <Response>
    <Step>
      <Name>Raise-Fault-1</Name>
      <Condition>(message.content Like "*unavailable*")</Condition>
    </Step>
  </Response>

Hai solo l'obiettivo di mostrarti che puoi generare errori personalizzati. Approfondiamo l'argomento Criterio RaiseFault nel criterio FaultRules rispetto al criterio RaiseFault .

Per ulteriori esempi, leggi questi post nei Forum della community Apigee:

• Fare riferimento alle variabili JavaScript in RaiseFault

Comportamento dei proxy API quando si verificano errori

Ecco cosa succede quando un proxy restituisce un errore.

Esci dalla pipeline proxy

Quando un proxy API rileva un errore, indipendentemente da come si verifica, esce dalla pipeline di flusso normale ed entra uno stato di errore e restituisce un messaggio di errore all'app client. Una volta che il proxy API entra nella non può tornare all'elaborazione nella normale pipeline di flusso.

Ad esempio, supponiamo che un proxy API abbia criteri nel seguente ordine in ProxyEndpoint richiesta:

1. Verifica chiave API
2. Quota
3. Da JSON a XML

Se si verifica un errore durante la verifica della chiave API, il proxy API passa allo stato di errore. La I criteri per le quote e da JSON a XML non vengono eseguiti, il proxy non procede al TargetEndpoint e viene restituito un messaggio di errore all'app client.

Controlla FaultRules

Nello stato di errore, i proxy API verificano anche la presenza dei seguenti elementi (in ordine) nel Configurazione del proxy API prima di restituire un messaggio di errore predefinito all'app client:

1. Una sezione <FaultRules>, che contiene la logica per attivare messaggi di errore personalizzati (e altri criteri) in base a condizioni specifiche che definire.
2. Una sezione <DefaultFaultRule>, che attiva un valore predefinito nelle seguenti situazioni:
   • Nessun <FaultRules> definito.
   • Nessun <FaultRules> esistente viene eseguito.
   • L'elemento <AlwaysEnforce> è impostato su true.

In sostanza, il proxy API ti dà la possibilità di restituire un messaggio di errore personalizzato e attivare un'altra logica. Se il proxy non trova nessuna di queste sezioni o se esistono, ma non sono un errore, il proxy invia il proprio messaggio predefinito generato da Edge.

Esempio di gestione dei guasti semplice

Iniziamo con un semplice esempio, in cui una chiamata a un proxy API non contiene un'API richiesta chiave. Per impostazione predefinita, la seguente è la risposta che viene restituita all'app client:

HTTP/1.1 401 Unauthorized
Date: Wed, 20 Jul 2016 19:19:32 GMT
Content-Type: application/json
Content-Length: 150
Connection: keep-alive
Server: Apigee Router

* Connection #0 to host myorg-test.apigee.net left intact
{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

È possibile che i tuoi utenti dell'API siano in grado di capire il messaggio di errore, ma non è così. E molti modelli predefiniti gli errori sono più sottili e più difficili da decifrare.

In qualità di sviluppatore di API, è tua responsabilità modificare questo messaggio per soddisfare le esigenze di chiunque ricevono il messaggio di errore, che si tratti di uno sviluppatore di app per iOS o di un test interno con requisiti specifici per il formato dei messaggi di errore.

Ecco un esempio base di come creare un messaggio di errore personalizzato per gestire questo errore. Questo richiede 1) un criterio che definisce il messaggio personalizzato e 2) una regola di errore che esegua il criterio quando il proxy entra in stato di errore.

1. Crea un criterio che definisce il messaggio personalizzato,

Innanzitutto, crea un criterio che definisce il messaggio di errore personalizzato. Puoi usare qualsiasi tipo di criterio, come un criterioAssignMessage, che consente di impostare un payload e intestazioni HTTP facoltative come codice di stato e una frase del motivo. L'opzione Assegna messaggio è l'ideale. Permette di controllare il payload dei messaggi, un codice di stato HTTP diverso, impostare una frase di motivo HTTP diversa e aggiungere intestazioni HTTP.

Non collegare il criterio ad alcun flusso nel proxy API. È sufficiente che esista un bundle proxy. Per farlo, nell'editor proxy UI di gestione, vai alla scheda Sviluppo e il riquadro di navigazione e fai clic sull'icona + nella barra delle norme.

In questo modo puoi creare un criterio senza collegarlo a un flusso nel proxy API. Un criterio non associato ad alcun flusso viene contrassegnato con lo stato "Scollegato" nell'elenco Criteri, come accanto al criterio relativo ai messaggi chiave API mostrato nella figura precedente.

Di seguito è riportato un esempio di criterio AttributionMessage che:

• Restituisce un messaggio JSON.
• Imposta un codice di stato HTTP (911, che è un evidente codice di stato inesistente semplicemente per per illustrare la tua flessibilità). Il codice di stato viene visualizzato nell'intestazione HTTP.
• Imposta una frase di motivi HTTP per sostituire la frase predefinita "Non autorizzato" per questo errore chiave API mancante). La frase del motivo viene visualizzata accanto al codice di stato nella finestra HTTP intestazione.
• Crea e compila una nuova intestazione HTTP denominata invalidKey.

<AssignMessage async="false" continueOnError="false" enabled="true" name="invalid-key-message">
    <DisplayName>Invalid key message</DisplayName>
    <Set>
        <Payload contentType="application/json">{"Citizen":"Where's your API key? I don't see it as a query parameter"}</Payload>
        <StatusCode>911</StatusCode>
        <ReasonPhrase>Rejected by API Key Emergency Services</ReasonPhrase>
    </Set>
    <Add>
        <Headers>
            <Header name="invalidKey">Invalid API key! Call the cops!</Header>
        </Headers>
    </Add>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Quando questo criterio viene eseguito, la risposta all'app client sarà la seguente. Confrontala con la risposta predefinita mostrata in precedenza.

HTTP/1.1 911 Rejected by API Key Emergency Services
Date: Wed, 20 Jul 2016 18:42:36 GMT
Content-Type: application/json
Content-Length: 35
Connection: keep-alive
invalidKey: Invalid API key! Call the cops!
Server: Apigee Router

* Connection #0 to host myorg-test.apigee.net left intact
{"Citizen":"Where's your API key? I don't see it as a query parameter."}

Sì, è un po' sciocco, ma ti mostra le possibilità. Almeno ora lo sviluppatore quando ricevono il messaggio sa di aver dimenticato di includere una chiave API come parametro di query.

Come viene applicata questa norma? Viene mostrata la sezione successiva.

2. Crea il <FaultRule> che attiverà il criterio

Nelle sezioni <ProxyEndpoint> o <TargetEndpoint> di configurazione del proxy, dovrai aggiungere un blocco XML <FaultRules> che contiene o più sezioni <FaultRule> singole. Ogni regola di errore rappresenta un che vuoi gestire. In questo semplice esempio, utilizzeremo una sola regola di errore per mostrare è composto.

Devi anche aggiungere un <DefaultFaultRule> per fornire un errore generale personalizzato se nessuna delle tue regole Fault viene eseguita.

Esempio

<ProxyEndpoint name="default">
...
    <FaultRules>
       <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
    </FaultRules>
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

Punti chiave:

• Le FaultRules sono definite nel ProxyEndpoint. Questo è importante. Altre informazioni su come mettere FaultRules nel ProxyEndpoint rispetto a TargetEndpoint in seguito.
• <Name>: il nome del criterio da eseguire. Il nome proviene dall'attributo name del criterio nell'elemento principale, come mostrato nell'attributo precedente.

• <Condition> - Edge valuta la condizione e esegue il criterio solo se la condizione è true. Se esistono più regole di errore che se restituisce true, Edge esegue il primo valore true. Importante: il L'ordine di valutazione delle regole di errore (dall'alto verso il basso o dal basso verso l'alto) varia TargetEndpoint e ProxyEndpoint, come descritto nella sezione FaultRules e logica di esecuzione. Se non includi una condizione, la regola FaultRule è impostato su true automaticamente. Ma non è una best practice. Ogni regola FaultRule deve avere la propria .

• <DefaultFaultRule> - Se nessuna regola di errore personalizzata è eseguito, l'operazione <DefaultFaultRule> viene eseguita, inviando una query personalizzato invece del messaggio crittografico predefinito generato da Edge. R <DefaultFaultRule> può anche avere un <Condition>, ma in nella maggior parte dei casi non ne includerai uno perché vuoi che venga eseguito, a prescindere dall'ultima resort.

  La regola predefinitoFaultRule viene generalmente utilizzata per restituire un messaggio di errore generico per qualsiasi inaspettato. Un esempio può essere un messaggio che contiene i dati di contatto di all'assistenza tecnica. Questa risposta predefinita ha il duplice scopo di fornire informazioni ottimizzate per gli sviluppatori e offuscando al contempo gli URL di backend o altre informazioni essere utilizzati per compromettere il sistema.

Più FaultRules e logica di esecuzione

Nella sezione Esempio di gestione degli errori semplice, abbiamo utilizzato un semplice esempio. di una singola regola e condizione Fault. In un progetto API reale, con tutti i possibili errori che ciò può accadere, è probabile che siano presenti più FaultRules e una DefaultFaultRule sia <ProxyEndpoint> e <TargetEndpoint>. In definitiva, però, Viene eseguita una sola FaultRule quando un proxy API passa in stato di errore.

Questa sezione descrive la logica utilizzata da Edge nella gestione delle FaultRules, da come arriva a un singola FaultRule da eseguire in base a come "inner" Le condizioni dei passaggi vengono gestite quando la rispettiva regola di errore attivata. Questa sezione fornisce inoltre indicazioni su quando definire FaultRules nel <ProxyEndpoint> a confronto con <TargetEndpoint> e descrive il relazione tra FaultRules e il criterio RaiseFault.

Esecuzione di FaultRules

In breve, ecco la logica utilizzata da Edge quando un proxy API passa in stato di errore. Tieni presente che esiste una leggera differenza tra la valutazione FaultRules nel ProxyEndpoint e Endpoint di destinazione.

1. Edge valuta le FaultRules nel ProxyEndpoint o nel TargetEndpoint, a seconda in cui si è verificato l'errore:
   • ProxyEndpoint: l'edge inizia con il basso <FaultRule> nel file XML di configurazione e che sta avanzando, valutando <Condition> di ogni <FaultRule> (l'elemento "esterno" la condizione "interna" <Step>).
   • TargetEndpoint: Edge inizia con top <FaultRule> nel file XML di configurazione e procede fino in fondo, valutando <Condition> di ogni <FaultRule> (l'elemento "esterno" la condizione "interna" <Step>).
2. Esegue la prima regola di errore la cui condizione è true. Se una regola di errore ha nessuna condizione, è true per impostazione predefinita.
   • Quando viene eseguita una regola di errore, tutti i passaggi all'interno di quest'ultima vengono valutati in ordine. dall'alto verso il basso nella configurazione XML. I passaggi senza condizioni vengono eseguiti automaticamente (i criteri vengono eseguiti) e i passaggi con <Condition> che restituisce "true" vengono eseguite (condizioni che restituiscono "false" non sono eseguito).

   • Se viene eseguita una regola di errore, ma non viene eseguito alcun passaggio della regola di errore (perché condizioni vengono valutate come "false"), il messaggio di errore predefinito generato da Edge viene restituito l'app client. <DefaultFaultRule> non viene eseguito, poiché Edge ha già eseguito la sua unica regola Fault.

3. Se non viene eseguita alcuna FaultRule, Edge esegue <DefaultFaultRule>, se presenti.

Di seguito sono riportati alcuni esempi di commenti in linea.

Esecuzione proxyEndpoint

La valutazione di ProxyEndpoint FaultRules è dal basso verso l'alto, quindi inizia a leggere dall'ultima FaultRule nel seguente esempio e procedi come preferisci. Guarda l'ultima regola predefinitaFault.

<ProxyEndpoint name="default">
...
    <FaultRules>
<!-- 3. This FaultRule is automatically TRUE, because there's no "outer" 
     condition. But because the FaultRule just below this got
     executed (bottom-to-top evaluation in a ProxyEndpoint), Edge
     doesn't even evaluate this FaultRule.
     Note that it's not a best practice to have a FaultRule without 
     an outer condition, which automatically makes the FaultRule true. -->
        <FaultRule name="random-error-message">
            <Step>
                <Name>Random-fault</Name>
            </Step>
        </FaultRule>
<!-- 2. Let's say this fault is TRUE. The Quota policy threw a QuotaViolation
     error. This is the first FaultRule to be TRUE, so it's executed. 
     Now the Steps are evaluated, and for the ones whose conditions
     evaluate to TRUE, their policies are executed. Steps without
     conditions are automatically true. -->
<FaultRule name="over_quota">
            <Step>
                <Name>developer-over-quota-fault</Name>
                <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>global-over-quota-fault</Name>
                <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>log-error-message</Name>
            </Step>
            <Condition>(fault.name = "QuotaViolation")</Condition>
        </FaultRule>
<!-- 1. Because this is the ProxyEndpoint, Edge looks at this FaultRule
     first. But let's say this FaultRule is FALSE. A policy did not 
     throw a FailedToResolveAPIKey error. Edge moves UP to check
     the next FaultRule. -->
        <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
    </FaultRules>

<!-- If no <FaultRule> is executed, the <DefaultFaultRule> is executed. 
     If a FaultRule is executed, but none of its Steps are executed,
     The DefaultFaultRule is not executed (because Edge has already
     executed its one FaultRule). -->
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

Esecuzione Endpoint di destinazione

La valutazione delle regole di errore del punto di destinazione è dall'alto verso il basso, quindi inizia a leggere FaultRule nell'esempio seguente e procedi verso il basso. Guarda l'ultima regola predefinitaFault.

<TargetEndpoint name="default">
...
    <FaultRules>
<!-- 1. Because this is the TargetEndpoint, Edge looks at this FaultRule
     first. Let's say this FaultRule is FALSE. 
     A policy did not throw a FailedToResolveAPIKey error. 
     Edge moves down to the next FaultRule. -->
        <FaultRule name="invalid_key_rule">
            <Step>
                <Name>invalid-key-message</Name>
            </Step>
            <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
        </FaultRule>
<!-- 2. Let's say this fault is TRUE. The Quota policy threw a QuotaViolation
     error. This is the first FaultRule to be TRUE, so it's executed. 
     Now the Steps are evaluated, and for the ones whose conditions
     evaluate to TRUE, their policies are executed. Steps without
     conditions are automatically true. -->
        <FaultRule name="over_quota">
            <Step>
                <Name>developer-over-quota-fault</Name>
                <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>global-over-quota-fault</Name>
                <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
            </Step>
            <Step>
                <Name>log-error-message</Name>
            </Step>
            <Condition>(fault.name = "QuotaViolation")</Condition>
        </FaultRule>
<!-- 3. This FaultRule is automatically TRUE, because there's no "outer" 
     condition. But because the FaultRule just above this got
     executed (top-to-bottom evaluation in a TargetEndpoint), Edge
     doesn't even evaluate this FaultRule.
     Note that it's not a best practice to have a FaultRule without 
     an outer condition, which automatically makes the FaultRule true. -->
        <FaultRule name="random-error-message">
            <Step>
                <Name>Random-fault</Name>
            </Step>
        </FaultRule>
    </FaultRules>

<!-- If no <FaultRule> is executed, the <DefaultFaultRule> is executed. 
     If a FaultRule is executed, but none of its Steps are executed,
     The DefaultFaultRule is not executed (because Edge has already
     executed its one FaultRule). -->
    <DefaultFaultRule name="default-fault">
        <Step>
            <Name>Default-message</Name>
        </Step>
    </DefaultFaultRule>

Ordine delle regole di errore

Come puoi vedere nell'esempio precedente, l'ordine in cui vengono inserite le regole di errore è sono importanti a seconda che l'errore si verifichi nel ProxyEndpoint o meno Endpoint di destinazione.

Ad esempio:

Criteri da includere

Puoi eseguire qualsiasi criterio di una regola di errore inserendoli in passaggi. Ad esempio, puoi Eseguire un criterioAssignMessage per formattare una risposta all'app client, quindi registrare un messaggio con il criterio MessageLogging. I criteri vengono eseguiti nell'ordine in cui li hai inseriti (dall'alto verso il basso nel file XML).

Le regole di errore vengono attivate SOLO in uno stato di errore (informazioni su continueOnError)

Potrebbe sembrare che il titolo si ripeta, ma c'è una sfumatura particolare a conoscenza di un errore del proxy che causa l'ingresso in uno stato di errore di un proxy API; oppure non inserire uno stato di errore: l'attributo continueOnError su un .

Ricapitolando: un proxy API valuta <FaultRules> e <DefaultFaultRule> solo se il proxy è in uno stato di errore. Questo significa che anche se una condizione FaultRule restituisce true, non verrà attivata se il proxy non sia in stato di errore.

Tuttavia, ecco un esempio di errore che si verifica e il proxy non entra in uno stato di errore. Attivato qualsiasi criterio, puoi impostare un attributo nell'elemento principale chiamato continueOnError. Questo attributo è molto importante per quanto riguarda la gestione dei guasti, in quanto determina se il proxy entra in uno stato di errore se il criterio ha esito negativo. Nella maggior parte dei casi è consigliabile mantenere predefinita continueOnError="false", che visualizza il proxy in uno stato di errore se non riesce e viene attivata la gestione personalizzata degli errori. Tuttavia, se continueOnError="true" (ad esempio, se non vuoi che l'errore di un servizio callout per interrompere l'esecuzione del proxy), il proxy non entra in uno stato di errore se il criterio non riesce e il proxy non esaminerà le FaultRules.

Per informazioni sugli errori di logging quando continueOnError="true", consulta Gestione degli errori dei criteri nel flusso attuale.

Dove per definire FaultRules: ProxyEndpoint o TargetEndpoint

Quando si verifica un errore di un proxy API, l'errore si verifica nella <ProxyEndpoint> (richiesta da o risposta all'app del client) o nel <TargetEndpoint> (richiesta a o risposta dal servizio di destinazione). Ovunque quando Edge cerca FaultRules.

Ad esempio, se non è disponibile un server di destinazione (codice di stato HTTP 503), il proxy API passa in uno stato di errore nella risposta <TargetEndpoint> e il normale proxy API non continuerà più fino al <ProxyEndpoint>. Se hai definito FaultRules solo nell'<ProxyEndpoint>, non gestiranno l'errore.

Ecco un altro esempio. Se un criterio RaiseFault sulla <ProxyEndpoint> attiva un errore, una regola di errore in <TargetEndpoint> non riceverà eseguito.

FaultRules e il criterio RaiseFault

In apparenza le regole di errore e il criterio RaiseFault potrebbero sembrare modi alternativi per eseguire la gestione degli errori; e in qualche modo è vero. ma interagiscono anche tra di loro. Questo spiega la relazione tra i due. La comprensione di questa relazione dovrebbe aiutare devi progettare la gestione dei guasti, soprattutto se vuoi utilizzare entrambi.

In breve:

• Le regole di errore vengono sempre valutate quando un proxy API inserisce un errore. stato.

• Il criterio RaiseFault consente di impostare un proxy API in stato di errore. quando un errore non si sarebbe altrimenti verificato.

  Ad esempio, se vuoi generare un errore se il codice di stato HTTP nella risposta da Se il servizio di destinazione è maggiore di 200, aggiungi un criterio RaiseFault nella risposta flusso di lavoro. L'URL avrà il seguente aspetto:

  <TargetEndpoint name="default">
      <PreFlow name="PreFlow">
  ...
          <Response>
              <Step>
                  <Name>Raise-Fault-1</Name>
  <!-- If the condition is true, the Raise-Fault-1 policy gets executed -->
                  <Condition>(response.status.code GreaterThan "200")</Condition>
              </Step>
          </Response> 
  

  Il criterio RaiseFault invia anche un messaggio di errore all'app client.

Cosa succede quando un criterio RaiseFault attiva un errore, che causa un errore nel proxy che esegue potenzialmente una regola di errore? È qui che le cose possono diventare un po' complicate. Se il criterio RaiseFault restituisce un messaggio di errore e viene attivata una regola FaultRule, restituisce un messaggio di errore: che cosa viene restituito all'app client?

• Poiché la regola FaultRule o DefaultFaultRule viene eseguita dopo il criterio RaiseFault, I dati di risposta FaultRule vince.
• I dati di risposta del criterio RaiseFault (codice di stato, frase del motivo o payload del messaggio) sono utilizzata se i dati non sono impostati da FaultRule o DefaultFaultRule.
• Se sia il criterio RaiseFault che FaultRule aggiungono intestazioni HTTP personalizzate, entrambi sono inclusi nel la risposta. I nomi delle intestazioni duplicati creano un'intestazione con più valori.

Ecco un esempio di quanto impostato da un criterio RaiseFault e da una FaultRule, e cosa viene tornare all'app client. Gli esempi sono pensati per brevità, non per best practice.

Status Code: 468
Reason Phrase: Something happened
Payload: {"Whoa":"Sorry."}
Header: 
  errorNote: woops,gremlins

Status Code: [none] 
Reason Phrase: Something happened
Payload: {"Whoa":"Sorry."}
Header: 
  errorNote: gremlins

Status Code: 468
Reason Phrase: Can't do that
Payload: {"DOH!":"Try again."}
Header: 
  errorNote: woops

Condizioni dell'edificio

Le condizioni sono la chiave per l'esecuzione di FaultRule. Puoi creare le condizioni FaultRule nello stesso modo che puoi fare per altre condizioni in Edge, come i flussi condizionali o le condizioni RaiseFault.

Per contestualizzare il resto della sezione, ecco un esempio di regola di errore con un parametro Condizione FaultRule e una condizione Step interna.

<FaultRule name="invalid_key_rule">
    <Step>
        <Name>invalid-key-message</Name>
        <Condition>(oauthV2.Verify-API-Key-1.failed = true)</Condition>
    </Step>
    <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
</FaultRule>

Variabili specifiche del criterio errori

Variabili fault.name e {policy_namespace}.{policy_name}.failed sono disponibili quando un criterio genera un errore.

fault.name

Quando un criterio non funziona, rileva l'errore in una condizione utilizzando fault.name . Ad esempio:

<Condition>(fault.name = "policy_error_name")</Condition>

Il nome dell'errore viene visualizzato nel messaggio di errore predefinito. Ad esempio, nel seguente esempio, l'errore nome è FailedToResolveAPIKey. In questo caso, una variabile di flusso denominata fault.name è impostato sul valore FailedToResolveAPIKey.

{"fault":{"faultstring":"Failed to resolve API Key variable request.queryparam.apikey","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

La condizione sarebbe quindi la seguente:

<Condition>(fault.name = "FailedToResolveAPIKey")</Condition>

Consulta l'articolo Errore relativo alle norme riferimento per un elenco di errori relativi ai criteri.

{policy_namespace}.{policy_name}.failed

La variabile *.failed è disponibile quando un criterio non funziona. Di seguito sono esempi di variabili *.failed per criteri diversi. Per gli spazi dei nomi dei criteri, consulta le variabili di flusso in ciascun argomento Riferimento ai criteri.

• Criterio RaiseFault: raisefault.failed (lo stesso per tutti i criteri RaiseFault)
• CriterioVerifyAPIKey: oauthV2.{policy_name}.failed, per esempio, oauthV2.Verify-API-Key-1.failed
• Criteri per le quote e criteri di SpikeArrest: ratelimit.{policy_name}.failed, ad esempio, ratelimit.Quota-1.failed

Altre variabili disponibili

Quando un proxy API passa in stato di errore, le uniche variabili disponibili per l'utilizzo in condizioni sono:

• Le variabili del criterio per cui l'operazione non è riuscita.
• Le variabili del messaggio HTTP esistenti al momento dell'errore. Ad esempio, se un errore viene generata nella risposta, una regola di errore in <TargetEndpoint> potrebbe utilizzare HTTP dati response.status.code, message.content, error.content e così via. Oppure, se un criterio per le quote non funziona, puoi utilizzare variabile ratelimit.{quota_policy_name}.exceed.count. Utilizza lo strumento Tracce e il criterio argomenti di riferimento per aiutarti a capire quali sono le variabili e i dati HTTP disponibili.

Ulteriori informazioni

• Condizioni: riferimento alle condizioni, variabili di flusso e condizioni

• Errori: Riferimento agli errori relativi ai criteri
• Variabili: riferimento delle variabili e visualizzazione dei singoli valori pagine di riferimento alle norme per le variabili disponibili con ciascun criterio.

Best practice per la gestione dei guasti

La gestione dei guasti è una delle principali attività di progettazione dell'architettura per lo sviluppo di proxy API. È importante a capire come e quando gestire gli errori, per determinare quale e progettare i formati dei messaggi di errore. Dopo aver capito (o come) le cose, utilizza queste best practice come ausilio per l'implementazione della gestione dei guasti.

Di seguito sono riportate alcune best practice per la progettazione e la gestione dei guasti:

• Per ogni FaultRule, specifica un valore "esterno" <Condition> (associato al <Step>). Le regole di errore senza condizione esterna sono valutate automaticamente su true. "Interno" Le condizioni dei passi non vengono utilizzate per determinare se una regola di errore è vera o false. Le condizioni dei passaggi vengono valutate solo dopo che Edge ha eseguito la regola di errore che le contiene. In una regola di errore, è normale avere più passaggi con criteri di assegnazione messaggio (o altri), ognuna con una condizione Step.

• Per gestire gli errori in più criteri dello stesso tipo (ad esempio, più criteri dei criteri), crea una regola FaultRule per ogni errore del criterio che potresti ricevere. Ad esempio: crea una FaultRule per ogni probabile errore nei criteri per le quote, QuotaViolation, InvalidMessageWeight, StartTimeNotSupported. (Consulta la documentazione di riferimento sugli errori di criterio per degli errori delle norme. Man mano che scopri altri errori che devono essere gestiti, puoi tornare in un secondo momento e aggiungerle a FaultRules. È normale essere ripetitivi, anche se richiedono rideployment del proxy). In questo modo è possibile individuare lo stesso tipo di errore indipendentemente che genera il risultato, rendendo il tuo XML FaultRules efficiente.

  Quindi utilizza le condizioni dei passaggi interne se hai bisogno di un controllo degli errori più granulare. Ad esempio: se applichi sia la quota per sviluppatori individuali sia quella globale con due criteri in flusso di richiesta, imposta il valore "esterno" Condizione FaultRule da attivare QuotaViolation errore (che viene generato quando la quota supera in entrambi i casi). Poi imposta le condizioni dei passaggi per valutare le variabili exceed.count in entrambe le quote criteri. Al client viene inviato solo l'errore pertinente (superamento della quota sviluppatori o superamento della quota). Ecco un esempio di questa configurazione:

  <FaultRule name="over_quota">
  <!-- This condition catches a QuotaViolation in *any* Quota policy -->
    <Condition>(fault.name = "QuotaViolation")</Condition>
    <Step>
      <Name>developer-over-quota-fault</Name>
      <Condition>(ratelimit.developer-quota-policy.exceed.count GreaterThan "0")</Condition>
    </Step>
    <Step>
      <Name>global-over-quota-fault</Name>
      <Condition>(ratelimit.global-quota-policy.exceed.count GreaterThan "0")</Condition>
    </Step>
  </FaultRule>
  

  Per un altro esempio, vedi questo thread della community Apigee.

• Per gestire gli errori quando utilizzi un singolo criterio di un solo tipo, considera un singolo errore che viene eseguita quando quel criterio ha esito negativo e includono più passaggi che ogni possibile errore. In questo modo il tuo XML è efficiente utilizzando una singola FaultRule invece di più FaultRules (una per ogni tipo di errore). Ad esempio:

  <FaultRule name="raise-fault-3">
  <!-- This condition catches *any* error in the Verify-API-Key-1 policy. -->
    <Condition>(oauthV2.Verify-API-Key-1.failed = "true")</Condition>
    <!-- This first step always executes, which handles errors you haven't mapped with inner conditions. -->
    <Step>
      <Name>Generic-Key-Fault</Name>
    </Step>
    <Step>
      <Name>Assign-Message-Raise-Fault-1</Name>
      <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
    </Step>
    <Step>
      <Name>Assign-Message-Raise-Fault-2</Name>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </Step>
  </FaultRule>
  

• Aggiungi FaultRules in cui si verificano gli errori (lato client <ProxyEndpoint> o lato target <TargetEndpoint>). Includere FaultRules per ciascun criterio vengono visualizzate in ogni posizione.
• In FaultRules, puoi eseguire qualsiasi tipo di criterio in grado di restituire un messaggio al client. dell'app. Il criterioAssignMessage è l'ideale. Valuta anche la possibilità di registrare un messaggio con il criterio MessageLogging se vuoi tenere traccia degli errori.
• Quando usi i criteri RaiseFault insieme a FaultRules, coordina la risposta che vengono restituiti quando sia il criterio RaiseFault che una FaultRule restituiscono dati. Per Ad esempio, se il criterio RaiseFault reimposta il codice di stato HTTP, non deve essere reimpostata FaultRule il codice di stato. Il peggio che può accadere è che il codice di stato predefinito venga restituito dell'app client.
• Esecuzione di <DefaultFaultRule>:
  • Se vuoi che un <DefaultFaultRule> venga sempre eseguito quando non ci sono altre FaultRule viene eseguita, non includere <Condition>.
  • Se vuoi che un <DefaultFaultRule> venga sempre eseguito anche quando un altro FaultRule è stata eseguita, aggiungi <AlwaysEnforce>true</AlwaysEnforce> elemento secondario.

Sequenza per gestione dei guasti centralizzata e riutilizzabile

Il seguente post della community Apigee descrive un pattern per la gestione centralizzata dei guasti senza duplicazione del codice:

https://community.apigee.com/articles/23724/an-error-handling-pattern-for-apigee-proxies.html

Creazione di regole di errore

Per aggiungere una FaultRule devi modificare la configurazione XML di ProxyEndpoint. Endpoint di destinazione. Puoi utilizzare la UI Edge per apportare questa modifica nel riquadro Codice del Sviluppa per un proxy API o modifica il file XML che definisce il ProxyEndpoint o Endpoint di destinazione.

Se crei FaultRules nell'interfaccia utente di gestione, crea prima i criteri da eseguire, quindi aggiungerli alla configurazione FaultRule. (riceverai un errore nell'interfaccia utente se provi a salvare FaultRule che fa riferimento a un criterio non ancora creato).

Aggiunta di criteri a una regola di errore

Sebbene sia possibile inserire qualsiasi criterio in FaultRule, in genere si utilizza CriterioAssignMessage per generare un messaggio di risposta personalizzato per una condizione di errore. AssegnaMessage consente di configurare una risposta HTTP con payload, codice di stato HTTP, intestazioni e motivazione.

L'esempio seguente mostra una configurazione tipica del criterioAssignMessage:

<AssignMessage name="fault_invalidkey">
  <Set>
      <Payload contentType="text/plain">Contact support at support@mycompany.com.</Payload>
      <StatusCode>401</StatusCode>
      <ReasonPhrase>Unauthorized</ReasonPhrase>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Ora puoi usare questo criterio nella regola Fault. Nota come fai riferimento all'oggettoAssignMessage nome in FaultRule:

<ProxyEndpoint name="default">
  ...
  <FaultRules>
    <FaultRule name="invalid_key_rule">
      <Step>
        <Name>fault_invalidkey</Name>
      </Step>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </FaultRule>
  </FaultRules>
</ProxyEndpoint>

Quando esegui il deployment della configurazione riportata sopra, il proxy API eseguirà il criterioAssignMessage denominato fault_invalidkey ogni volta che un'app presenta una chiave API non valida.

Puoi eseguire più criteri in una regola di errore, come illustrato nell'esempio seguente:

<ProxyEndpoint name="default">
  ...
  <FaultRules>
    <FaultRule name="invalid_key_rule">
      <Step>
        <Name>policy1</Name>
      </Step>
      <Step>
        <Name>policy2</Name>
      </Step>
      <Step>
        <Name>policy3</Name>
      </Step>
      <Condition>(fault.name = "InvalidApiKey")</Condition>
    </FaultRule>
  </FaultRules>
</ProxyEndpoint>

I criteri vengono eseguiti nell'ordine definito. Ad esempio, puoi utilizzare il criterio MessageLogging, il criterio TakeoutVariables, CriterioAssignMessage o qualsiasi altro criterio nel FaultRule. Tieni presente che l'elaborazione della regola di errore si interrompe immediatamente se una delle seguenti situazioni avvengono nel seguente modo:

• Qualsiasi criterio in FaultRule causa un errore
• Tutti i criteri in FaultRule sono di tipo RaiseFault

La definizione messaggio di errore personalizzato restituito da una regola FaultRule

Come best practice, devi definire risposte di errore chiare dal tuo su quelle di livello inferiore. In questo modo, potrai fornire ai tuoi clienti informazioni coerenti e utili.

Il seguente esempio di criterioAssignMessage utilizza <Payload>, <StatusCode> e <ReasonPhase> per definire l'impostazione personalizzata risposta di errore inviata al client in caso di errore InvalidApiKey (consulta la precedente sezione FaultRules esempio).

<AssignMessage name="fault_invalidkey">
  <Set>
    <Payload contentType="text/plain">You have attempted to access a resource without the correct authorization. 
       Contact support at support@mycompany.com.</Payload>
    <StatusCode>401</StatusCode>
    <ReasonPhrase>Unauthorized</ReasonPhrase>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

La risposta include:

• Il payload contenente il messaggio di errore e un indirizzo email per contattare l'assistenza.
• Il codice di stato HTTP restituito nella risposta.
• La frase del motivo, che è una breve descrizione dell'errore.

Creazione di una regolaFaultDefault

Una regola predefinitaFaultRule agisce come gestore di eccezioni per qualsiasi errore non gestito esplicitamente dal un'altra regola Fault. Se le condizioni per tutte le regole Fault non corrispondono all'errore, defaultFaultRule gestisce l'errore. Abilita la gestione predefinita degli errori aggiungendo il parametro <DefaultFaultRule> come elemento secondario di un ProxyEndpoint o di un Endpoint di destinazione.

Ad esempio, la configurazione TargetEndpoint riportata di seguito definisce una regola defaultFault che richiama un oggetto criterio denominato ReturnGenericError:

<TargetEndpoint name="default">
  ...
  <FaultRules>
    ...
  </FaultRules>

  <DefaultFaultRule name="fault-rule">
    <Step>
      <Name>ReturnGenericError</Name>
    </Step>
  </DefaultFaultRule>

  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

La regola predefinitaFaultRule viene generalmente utilizzata per restituire un messaggio di errore generico per qualsiasi , ad esempio un messaggio che contiene i dati di contatto per l'assistenza tecnica. Questo valore predefinito la risposta ha il duplice scopo di fornire informazioni a misura di sviluppatore e allo stesso tempo offuscare gli URL di backend o altre informazioni che potrebbero essere utilizzate per compromettere il sistema.

Ad esempio, definisci il seguente criterioAssignMessage in modo che restituisca un errore generico:

<AssignMessage name="ReturnGenericError">
  <Set>
    <Payload type="text/plain">SERVICE UNAVAILABLE. PLEASE CONTACT SUPPORT: support@company.com.</Payload>
  </Set>
</AssignMessage>

Includi l'elemento <AlwaysEnforce> in <DefaultFaultRule> per eseguire la regola predefinitaFaultRule per ogni errore, anche se è già stata eseguita un'altra FaultRule. La regolaFaultpredefinita è sempre l'ultima regola di errore da eseguire:

  <DefaultFaultRule name="fault-rule">
    <Step>
      <Name>ReturnGenericError</Name>
    </Step>
    <AlwaysEnforce>true</AlwaysEnforce>
  </DefaultFaultRule>

La regola predefinitoFault consente di determinare il tipo di errore che si verifica quando altrimenti non è in grado di stabilirlo. Ad esempio, il proxy API non funziona a causa di un errore che non è in grado di determinarlo. Usa defaultFaultRule per richiamare il seguente criterioAssignMessage seguente. Questo il criterio scrive il valore fault.name in un'intestazione denominata DefaultFaultHeader nella risposta:

<AssignMessage async="false" continueOnError="false" enabled="true" name="DefaultFaultRule">
  <DisplayName>DefaultFaultRule</DisplayName>
  <Set>
    <Headers>
      <Header name="DefaultFaultHeader">{fault.name}</Header>
    </Headers>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

Puoi quindi visualizzare l'intestazione nello strumento Traccia perimetrale o nella risposta per verificare .

Aggiunta del logging dei messaggi alla PostClientFlow

PostClientFlow è l'unico flusso che viene eseguito dopo che il proxy ha inserito l'errore stato. È possibile collegare solo il criterio MessageLogging a questo flusso, che viene eseguito dopo l'invio della risposta al cliente. Sebbene il collegamento del criterio MessageLogging a questo flusso tecnicamente non la gestione degli errori, puoi utilizzarla per registrare le informazioni in caso di errore. Perché indipendentemente dall'esito positivo o negativo del proxy, puoi creare il logging dei messaggi i criteri in PostClientFlow e ne garantisce l'esecuzione.

Gestione degli errori dei criteri nel flusso attuale

Gli esempi mostrati finora usano tutti una FaultRule sul ProxyEndpoint o sul TargetEndpoint per gestire eventuali errori dei criteri nello stato di errore. Questo perché il valore predefinito L'elemento continueOnError di un criterio è false, il che significa che quando un si verifica in un criterio, il controllo viene indirizzato allo stato di errore. Quando lo stato è di errore, non può restituire il controllo alla pipeline normale e in genere si restituisce qualche forma di errore all'app per le chiamate.

Tuttavia, se imposti l'elemento continueOnError su true per un il controllo rimane nel flusso attuale e il criterio successivo nella pipeline viene eseguito dopo che ha causato l'errore. Il vantaggio di gestire l'errore nel flusso attuale è che potrebbe avere un modo per recuperare dall'errore e completare l'elaborazione della richiesta.

Di seguito è mostrato un criterioVerifyAPIKey denominato verify-api-key con Elemento continueOnError impostato su true:

<VerifyAPIKey async="false" continueOnError="true" enabled="true" name="verify-api-key">
  <DisplayName>Verify API Key</DisplayName>
  <APIKey ref="request.queryparam.apikey"/>
</VerifyAPIKey>

Se la chiave API manca o non è valida, il criterio VerifyAPIKey imposta la oauthV2.verify-api-key.failed per true, ma in fase di elaborazione continua nel flusso attuale.

Quindi aggiungi il criterio VerifyAPIKey come passaggio nel PreFlow del ProxyEndpoint:

<ProxyEndpoint name="default">
  ...
  <PreFlow name="PreFlow">
    <Request>
      <Step>
        <Name>verify-api-key</Name>
      </Step>
      <Step>
        <Name>FaultInFlow</Name>
        <Condition>(oauthV2.verify-api-key.failed = "true")</Condition>
      </Step>
    </Request>
    <Response/>
  </PreFlow>      
</ProxyEndpoint>  

Nota come il passaggio successivo nel PreFlow utilizza una condizione per verificare l'esistenza di un . Se si è verificato un errore nel criterio VerifAPIKey, il criterio denominato Il criterio FaultInFlow viene eseguito. In caso contrario, il criterio FaultInFlow viene saltata. Il criterio FaultInFlow può fare molte cose, ad esempio registrare l'errore, tentare di correggere l'errore o eseguire un'altra azione.

Attivazione di un errore tramite RaiseFault norme

Puoi utilizzare il criterio RaiseFault in qualsiasi momento in un flusso per attivare un errore. Quando Il criterio RaiseFault viene eseguito, termina il flusso attuale e trasferisce il controllo all'errore stato.

Un uso del criterio RaiseFault è il test di una condizione specifica che un altro criterio potrebbero non rilevare. Nell'esempio precedente, hai aggiunto un tag <Condition> a un Tag <Step> PreFlow che ha causato l'esecuzione del criterio FaultInFlow se la condizione è soddisfatta. Se FaultInFlow è un criterio RaiseFault, controlla vengono trasferiti allo stato di errore. In alternativa, potresti inserire un criterio RaiseFault in un flusso per eseguire il debug e e testa le tue FaultRules.

Quando un criterio RaiseFault attiva un errore, puoi usare la seguente regola e condizione di errore per elaborarlo:

<FaultRule name="raisefault_rule">
  <Step>
    <Name>{policy_name}</Name>
  </Step>
  <Condition>(fault.name = "RaiseFault")</Condition>
</FaultRule>

Tieni presente che la condizione verifica un errore denominato RaiseFault. L'elemento RaiseFault imposta sempre il valore di fault.name su RaiseFault.

Gestione personalizzata dei codici di errore HTTP dal server di destinazione

Gli esempi mostrati nelle sezioni precedenti si applicano agli errori creati dai criteri. Comunque tu creare una risposta personalizzata per gli errori a livello di trasporto, ovvero errori HTTP restituiti il server di destinazione. Per controllare la risposta da un errore HTTP, configura un TargetEndpoint in per elaborare i codici di risposta HTTP.

Per impostazione predefinita, Edge considera i codici di risposta HTTP compresi nell'intervallo 1xx-3xx come "success" e i codici HTTP codici di risposta nell'intervallo 4xx-5xx come "failure". Ciò significa che qualsiasi risposta dal backend un servizio con un codice di risposta HTTP 4xx-5xx richiama automaticamente lo stato di errore, che quindi restituisce un messaggio di errore direttamente al client richiedente.

Puoi creare gestori personalizzati per qualsiasi codice di risposta HTTP. Ad esempio, potresti non volere tratta tutti i codici di risposta HTTP nell'intervallo 4xx-5xx come "failure" ma solo 5xx o, se preferisci, per restituire messaggi di errore personalizzati per i codici di risposta HTTP 400 e 500.

Nel prossimo esempio, viene utilizzata la proprietà success.codes per configurare TargetEndpoint per trattare i codici di risposta HTTP 400 e 500 come operazioni riuscite, insieme al valore HTTP predefinito i codici. Trattando quei codici come un successo, TargetEndpoint prende il controllo dell'elaborazione dei di risposta, invece di richiamare lo stato di errore:

<TargetEndpoint name="default">
  ...
  <HTTPTargetConnection>
    <Properties>
          <Property name="success.codes">1xx,2xx,3xx,400,500</Property>
    </Properties>
    <URL>http://weather.yahooapis.com</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

Come vedi in questo esempio, puoi utilizzare i caratteri jolly per impostare la proprietà success.codes su un intervallo di valori...

L'impostazione della proprietà success.codes sovrascrive i valori predefiniti. Pertanto, se vuoi aggiungere il codice HTTP 400 all'elenco delle risposte riuscite predefinite, codici, imposta questa proprietà come:

<Property name="success.codes">1xx,2xx,3xx,400</Property>

Tuttavia, se vuoi che il codice HTTP 400 venga trattato solo come codice di operazione riuscita, imposta la proprietà come:

<Property name="success.codes">400</Property>

Ora puoi definire gestori personalizzati per i codici di risposta HTTP 400 e 500 per restituire un messaggio di risposta all'app che ha inviato la richiesta. Il seguente TargetEndpoint utilizza il criterio denominato ReturnError per gestire i codici di risposta HTTP 400 e 500:

<TargetEndpoint name="default">
  <PreFlow name="PreFlow">
    <Request/>
    <Response>
      <Step>
        <Name>ReturnError</Name>
        <Condition>(response.status.code = 400) or (response.status.code = 500)</Condition>
      </Step>
    </Response>
  </PreFlow>

  <HTTPTargetConnection>
    <Properties>
      <Property name="success.codes">1xx,2xx,3xx,400,500</Property>
    </Properties>
    <URL>http://weather.yahooapis.com</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

Questa configurazione di TargetEndpoint fa sì che il criterio chiamato ReturnError gestisca la risposta ogni volta che TargetEndpoint incontra un codice di risposta HTTP 400 o 500.

Tassonomia degli errori

I servizi API organizzano gli errori nelle seguenti categorie e sottocategorie.

Un errore è sempre accompagnato da una descrizione testuale del motivo dell'errore. Quando segnala un errore, viene compilato un insieme di attributi per facilitare la risoluzione dei problemi. Un errore include le seguenti informazioni:

• Motivo
• Attributi personalizzati definiti dall'utente