Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Questo argomento descrive la struttura degli errori dei criteri e i tipi di variabili di flusso impostate quando si verifica un errore dei criteri. Queste informazioni sono essenziali se stai progettando e implementando la gestione degli errori per i tuoi proxy.
Questo argomento presuppone che tu abbia una conoscenza generale del funzionamento della gestione degli errori in Apigee e che tu sappia cosa sono le regole di errore. Se hai bisogno di una revisione, consulta Gestione dei difetti. Le informazioni riportate qui ti aiuteranno anche a navigare e utilizzare il riferimento agli errori relativi alle norme.
Informazioni sulla risposta di errore dei criteri predefinita
Quando un criterio genera un errore, Apigee entra immediatamente nel flusso di errori e genera un messaggio di errore. Questo messaggio generato dal sistema è un oggetto JSON che include due informazioni: un
errorcode e un faultstring.
Ad esempio:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"mymessage message is not available for ExtractVariable: ParseJsonResponse" } }
Analizziamo rapidamente questo messaggio di errore:
errorcode è composto da un prefix e un error
name, come segue: [prefix].[error_name]. Nell'esempio riportato sopra,
"steps.extractvariables è il prefisso e SourceMessageNotAvailable è
il nome dell'errore. Il prefisso indica il tipo di norma che ha generato l'errore. Nell'esempio
precedente, puoi notare che l'errore è stato generato da una policy ExtractVariables e che il nome dell'errore è
SourceMessageNotAvailable.
Il file 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 della norma, il nome di una variabile non risolta o qualsiasi altro elemento che ha contribuito all'errore. Ad esempio, nel messaggio di errore riportato sopra, mymessage è il nome di una variabile di messaggio non risolta a cui viene fatto riferimento nelle norme e ParseJsonResponse è il nome delle norme che hanno attivato l'errore.
Variabili specifiche per gli errori dei criteri
Quando viene attivato un errore relativo ai criteri, vengono compilate determinate variabili di flusso specifiche per l'errore. Queste variabili sono estremamente utili nella gestione degli errori. Come spiegato in Gestione degli errori, è prassi comune intercettare gli errori delle policy 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 visualizzare gli errori e i codici di stato effettivi restituiti da Apigee.
Variabile fault.name
Quando un criterio genera un errore, imposta la variabile di flusso fault.name sulla parte error_name del codice di errore (come descritto nella sezione precedente). È molto
comune valutare questa variabile per eseguire in modo condizionale le regole di errore.
Ecco un esempio di regola di errore che verifica il valore di 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>La cosa da ricordare è che quando un criterio attiva un errore, la variabile fault.name
viene sempre impostata sul nome dell'errore.
La
variabile [prefix].[policy_name].failed
Oltre a fault.name, un'altra variabile che gli sviluppatori controllano spesso è il
flag [prefix].[policy_name].failed, che viene impostato su true o false quando viene eseguita una
policy. Nelle regole di errore, devi verificare quando la condizione è true, ovvero se si è verificato un errore. Ecco come creare una condizione che controlla il flag
[prefix].[policy_name].failed. Per controllare correttamente questa variabile, devi
sapere due cose:
- Il nome della norma che stai controllando. Si tratta del valore dell'attributo name del criterio, non del nome visualizzato. Questo attributo è sempre incluso nel file XML della definizione della policy.
- Un prefisso specifico per il tipo di criterio che stai controllando. (Spiegheremo come trovare il prefisso di seguito).
Per illustrare, ecco un altro esempio di regola di errore. Nella condizione esterna, nota 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 verrà eseguita solo se questa variabile è vera. Ecco un suggerimento: poiché le regole di errore possono contenere più passaggi, questo pattern è un buon modo per organizzare le regole di errore 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 di stato e così via. Il pattern di formattazione per la variabile di errore è il seguente:
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 del 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.
Consulta Riferimento alle variabili di flusso
per informazioni su tutte le variabili Apigee, incluse error e
message.