Informazioni importanti sugli errori dei criteri

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza documentazione di Apigee Edge.

Questo argomento descrive la struttura degli errori dei criteri e i tipi di variabili di flusso che vengono viene impostata 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 Apigee e che tu sappia cosa sono le regole di errore. Se hai bisogno di una revisione, consulta Gestione dei guasti. La le informazioni qui per consultare e utilizzare la documentazione di riferimento sugli errori di criterio.

Informazioni sulla risposta di errore dei criteri predefinita

Quando un criterio genera un errore, Apigee 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: errorcode e faultstring.

Nota: è utile sapere che nelle parti di un errore come mostrato di seguito sono disponibili come variabili di flusso. Puoi modificare e personalizzare i messaggi di errore tramite queste variabili. La variabile fault.name è il valore del parametro errorcode e error.message è il valore dell'attributo faultstring. Queste variabili vengono trattate in modo più dettagliato nella le seguenti sezioni di questo argomento.

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 da un error name, come segue: [prefix].[error_name]. Nell'esempio precedente "steps.extractvariables è il prefisso, mentre 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 ExtractVariables e che il nome dell'errore è SourceMessageNotAvailable.

faultstring contiene una descrizione dell'errore. La stringa di errore solitamente 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 elemento che ha contribuito all'errore. Per Ad esempio, nel messaggio di errore precedente, mymessage è il nome di un problema la variabile di messaggio a cui viene fatto riferimento nel criterio e ParseJsonResponse è il nome della variabile che ha attivato l'errore.

Nota: nella sezione Riferimento agli errori dei criteri, utilizziamo una convenzione coerente per documentare le stringhe di errore dei criteri. Indichiamo dove si verificano le variabili di luogo con una notazione []. Ecco un esempio di come documentare la stringa di errore dell'errore riportato sopra:

VAR_NAME message is not available for ExtractVariable: POLICY_NAME

Variabili specifiche degli errori dei criteri

Quando viene attivato un errore del criterio, vengono compilate alcune 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 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 Apigee.

Variabile fault.name

Quando un criterio genera un errore, imposta la variabile di flusso fault.name sulla parte error_name del codice errore (come descritto nella sezione precedente). È molto è comune per valutare questa variabile ed eseguire regole di errore in modo condizionale.

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>

Tieni presente che quando un criterio attiva un errore, fault.name è sempre impostata sul nome dell'errore.

Nota: quando sviluppi il codice di gestione degli errori, consulta il riferimento agli errori relativi alle norme per conoscere il nome di ogni errore relativo alle norme. È inoltre una pratica comune utilizzare lo strumento di debug per esaminare le risposte di errore e le variabili impostate.

La variabile [prefix].[policy_name].failed

Oltre a fault.name, un'altra variabile che gli sviluppatori controllano di solito è 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, cioè per verificare se si è verificato un errore. Di seguito viene spiegato come creare un condizionale che verifichi [prefix].[policy_name].failed flag. Per controllare correttamente questa variabile, è necessario due cose:

• Il nome del criterio che stai controllando. Questo è il valore del parametro , non il nome visualizzato. Questo attributo è sempre incluso nel file XML della definizione del criterio.
• Un prefisso specifico per il tipo di criterio che stai controllando. (Lo faremo spiega come trovare il prefisso di seguito.)

Per esemplificare, 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 del criterio è 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 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>

Nota: come puoi sapere qual è il prefisso della variabile di errore? Non puoi necessariamente dedurlo dai contenuti della stringa di errore o del codice di errore. Devi cercare in Riferimento errore criterio oppure puoi utilizzare trace per ispezionare le variabili di flusso create quando si verifica un errore. Ad esempio, per il criterio Estrai variabili, il parametro Il prefisso [prefix].[policy_name].failed è extractvariables, che è piuttosto chiara. Tuttavia, per il criterio di controllo dell'accesso, il prefisso è acl. Quindi, il punto è che devi controllare.

Informazioni su 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 errore è il seguente:

error.ERROR_COMPONENT = VALUE

Ad esempio:

error.message = "request message is not available for ExtractVariable:
  ParseJsonResponse"

e

error.status.code = "500"

Suggerimento:puoi utilizzare questa variabile anche per impostare le intestazioni delle risposte. Questo può essere estremamente utile perché nel flusso di errore l'oggetto di risposta non è disponibile.

La variabile message è disponibile anche nel flusso di errore e può essere utilizzata per con scopi simili a quelli della variabile error. La variabile del messaggio è speciale perché sono contestuali. In un flusso di richiesta si comporta come una variabile di richiesta e in un flusso di risposta può essere utilizzato per ottenere/impostare i valori di risposta.

Consulta l'articolo Informazioni sulle variabili di flusso. per informazioni su tutte le variabili Apigee, tra cui error e message.