Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info
Questo argomento descrive la struttura degli errori dei criteri e i tipi di variabili di flusso impostate quando si verifica un errore del criterio. Queste informazioni sono essenziali se stai progettando e implementando la gestione degli errori per i proxy.
Questo argomento presuppone che tu abbia una conoscenza generale del funzionamento della gestione degli errori in Edge e che tu sappia cosa sono le regole di errore. Se devi eseguire una revisione, consulta la sezione Gestione degli errori. Le informazioni riportate qui ti aiuteranno inoltre a navigare e utilizzare il riferimento agli errori delle norme.
Informazioni sulla risposta di errore del criterio predefinito
Quando un criterio genera un errore, Edge entra immediatamente nel flusso di errore e genera un messaggio di errore. Questo messaggio generato dal sistema è un oggetto JSON che include due bit di informazioni: un errorcode e una faultstring.
Ad esempio:
{
"fault":{
"detail":{
"errorcode":"steps.extractvariables.SourceMessageNotAvailable"
},
"faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
}
}
Scomponiamo rapidamente questo messaggio di errore:
Il errorcode è composto da un prefisso e da un nome dell'errore, come segue: [prefix].[error_name]. Nell'esempio precedente, "steps.extractvariables" è il prefisso e SourceMessageNotAvailable è il nome dell'errore. Il prefisso indica il tipo di norma che ha generato l'errore. Nell'esempio riportato sopra, puoi capire che l'errore è stato generato da un criterio Estrazione variabili e che il nome dell'errore è SourceMessageNotAvailable.
Il campo faultstring contiene una descrizione dell'errore. La stringa di errore in genere include indizi per aiutarti a trovare il problema specifico che ha causato l'errore, ad esempio il nome del criterio, il nome di una variabile non risolta o qualsiasi cosa abbia contribuito all'errore. Ad esempio, nel messaggio di errore precedente, "foo" è il nome di una variabile di messaggio non risolta a cui viene fatto riferimento nel criterio, mentre "ParseJsonResponse" è il nome del criterio che ha attivato l'errore.
Variabili specifiche degli errori dei criteri
Quando viene attivato un errore relativo al criterio, vengono compilate alcune variabili di flusso specifiche dell'errore. Queste variabili sono estremamente utili nella gestione degli errori. Come spiegato nell'argomento Gestione degli errori, è pratica comune eseguire il trap degli errori dei criteri generati dal sistema ed eseguire un'azione successiva, ad esempio creare una risposta di errore personalizzata. Ad esempio, per motivi di sicurezza, potresti voler impedire ai client di vedere gli errori e i codici di stato effettivi restituiti da Edge.
La variabile fault.name
Quando un criterio genera un errore, imposta la variabile di flusso fault.name nella
parte error_name del codice di errore (come descritto nella sezione precedente). È molto comune valutare questa variabile per eseguire condizionatamente le regole di errore.
Di seguito è riportato un esempio di regola di errore che verifica il valore 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>
Devi ricordare che quando un criterio attiva un errore, la variabile fault.name
viene sempre impostata sul nome dell'errore.
Variabile
[prefix].[policy_name].failed
Oltre a fault.name, un'altra variabile controllata solitamente dagli sviluppatori è il flag [prefix].[policy_name].failed, che viene impostato su true o false quando viene eseguito un criterio. Nelle regole di errore, vorrai verificare se è true, ossia per verificare se si è verificato un errore. Ecco come creare un'espressione condizionale che controlli il flag [prefix].[policy_name].failed. Per controllare correttamente questa variabile, devi sapere due cose:
- Il nome del criterio che stai controllando. Questo è il valore dell'attributo nome del criterio, non il nome visualizzato. Questo attributo è sempre incluso nel file XML della definizione del criterio.
- Un prefisso specifico per il tipo di norme che stai controllando. (di seguito spiegheremo come trovare il prefisso.)
Per esemplificare, ecco un altro esempio di regola di errore. Nota nella condizione esterna come viene formato il nome della variabile [prefix].[policy_name].failed. In questo caso il prefisso è
extractvariables e il nome della norma è ParseJsonResponse. In questo caso, la regola di errore viene eseguita solo se questa variabile è true. Ecco un suggerimento: poiché le regole di errore possono contenere più passaggi, questo pattern è un ottimo modo per organizzarle in blocchi.
<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>
Informazioni sulle variabili error e message
La variabile error è disponibile solo nel flusso di errori di un
proxy. Puoi ottenere informazioni utili dalla variabile error, ad esempio il messaggio di errore, il codice stato, la frase del motivo e così via. Il pattern di formattazione per la variabile di errore è:
error.[error_component] = [value]
Ad esempio:
error.message = "request message is not available for ExtractVariable:
ParseJsonResponse"
e
error.status.code = "500"
La variabile message è disponibile anche nel flusso di errori e può essere utilizzata per scopi simili a quelli della variabile error. La variabile messaggio è speciale perché è contestuale. In un flusso di richieste, si comporta come una variabile di richiesta e in un flusso di risposte può essere utilizzata per ottenere/impostare i valori di risposta. Per scoprire di più, consulta la sezione Casi d'uso per le variabili dei messaggi.
Per informazioni su tutte le variabili Edge, tra cui error e message, consulta Riferimento delle variabili.