Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza
Documentazione di Apigee Edge.
Il criterio RaiseFault consente agli sviluppatori di API di avviare un flusso di errore e impostare le variabili di errore
nel corpo del messaggio della risposta e imposta i codici di stato della risposta appropriati. Puoi anche usare il metodo RaiseFault
per impostare le variabili di flusso relative all'errore, ad esempio fault.name
, fault.type
,
e fault.category
. Poiché queste variabili sono visibili nei dati di analisi e nei log di accesso al router
per il debug, è importante identificare l'errore in modo preciso.
Puoi utilizzare il criterio RaiseFault per trattare patologie specifiche come errori, anche se un errore effettivo ha generato
non si è verificato in un altro criterio o nel server di backend del proxy API. Ad esempio, se vuoi
il proxy per inviare un messaggio di errore personalizzato all'app client ogni volta che la risposta del backend
body contiene la stringa unavailable
, puoi richiamare il criterio RaiseFault come
come mostrato nello snippet di codice riportato di seguito:
<!-- /antipatterns/examples/raise-fault-conditions-1.xml --> <TargetEndpoint name="default"> ... <Response> <Step> <Name>RF-Service-Unavailable</Name> <Condition>(message.content Like "*unavailable*")</Condition> </Step> </Response> ...
Il nome del criterio RaiseFault è visibile come fault.name
in
API Monitoring e come x_apigee_fault_policy
nei log di accesso ad Analytics e al router.
In questo modo è più facile diagnosticare la causa dell'errore.
Antipattern
Utilizzo del criterio RaiseFault all'interno di FaultRules dopo che un altro criterio ha già generato un errore
Considera l'esempio riportato di seguito, in cui un criterio OAuthV2 nel flusso del proxy API non ha avuto esito positivo con un InvalidAccessToken
. In caso di errore, Apigee imposta fault.name
su InvalidAccessToken
, entra in
il flusso di errori ed eseguire le FaultRules definite. In FaultRule, è presente un criterio RaiseFault denominato
RaiseFault
che invia una risposta di errore personalizzata ogni volta che un InvalidAccessToken
si verifica un errore. Tuttavia, l'uso del criterio RaiseFault in una FaultRule significa che fault.name
viene sovrascritta e maschera la vera causa dell'errore.
<!-- /antipatterns/examples/raise-fault-conditions-2.xml --> <FaultRules> <FaultRule name="generic_raisefault"> <Step> <Name>RaiseFault</Name> <Condition>(fault.name equals "invalid_access_token") or (fault.name equals "InvalidAccessToken")</Condition> </Step> </FaultRule> </FaultRules>
Utilizzo del criterio RaiseFault in una regola Fault in tutte le condizioni
Nell'esempio seguente, un criterio RaiseFault denominato RaiseFault
viene eseguito se fault.name
non è RaiseFault
:
<!-- /antipatterns/examples/raise-fault-conditions-3.xml --> <FaultRules> <FaultRule name="fault_rule"> .... <Step> <Name>RaiseFault</Name> <Condition>!(fault.name equals "RaiseFault")</Condition> </Step> </FaultRule> </FaultRules>
Come nel primo scenario, le variabili di errore chiave fault.name
, fault.code
,
e fault.policy
vengono sovrascritti con il nome del criterio RaiseFault. Questo comportamento rende
è quasi impossibile determinare quale criterio ha effettivamente causato l'errore senza accedere a una traccia
che mostra l'errore o la riproduzione del problema.
Utilizzo del criterio RaiseFault per restituire una risposta HTTP 2xx al di fuori del flusso di errore.
Nell'esempio seguente, un criterio RaiseFault denominato HandleOptionsRequest
viene eseguito quando
il verbo di richiesta è OPTIONS
:
<!-- /antipatterns/examples/raise-fault-conditions-4.xml --> <PreFlow name="PreFlow"> <Request> … <Step> <Name>HandleOptionsRequest</Name> <Condition>(request.verb Equals "OPTIONS")</Condition> </Step> … </PreFlow>
Lo scopo è restituire immediatamente la risposta al client API senza elaborare altri criteri. Tuttavia, ciò porterà a dati di analisi fuorvianti perché le variabili di errore conterranno il Il nome del criterio RaiseFault, che rende più difficile il debug del proxy. Il modo corretto per implementare il comportamento desiderato è utilizzare flussi con condizioni speciali, come descritto in Aggiunta del supporto CORS.
Impatto
L'utilizzo del criterio RaiseFault come descritto sopra determina la sovrascrittura delle variabili di errore chiave con il parametro
Il nome del criterio RaiseFault anziché il nome del criterio con errori. Nei log di accesso di Analytics e NGINX,
le variabili x_apigee_fault_code
e x_apigee_fault_policy
vengono sovrascritti. In Monitoraggio API, Fault Code
e Fault Policy
vengono sovrascritte. Questo comportamento rende difficile
determinare quale criterio è la vera causa dell'errore.
Nello screenshot di Monitoraggio API riportato di seguito
puoi vedere che i criteri Fault Code e Fault sono stati sovrascritti in generici RaiseFault
rendendo impossibile determinare la causa principale dell'errore dai log:
![Da definire](https://cloud.google.com/static/apigee/docs/api-platform/images/antipatterns/raise-fault-conditions.png?authuser=8&hl=it)
Best practice
Quando un criterio Apigee genera un errore e vuoi personalizzare il messaggio di risposta di errore, utilizzare il criterioAssignMessage o JavaScript anziché del criterio RaiseFault.
Il criterio RaiseFault deve essere utilizzato in un flusso non di errore. Vale a dire, usa RaiseFault solo per trattare un caso specifico come errore, anche se non si è verificato un errore effettivo in un criterio o nel server di backend. del proxy API. Ad esempio, potresti utilizzare il criterio RaiseFault per segnalare che l'input obbligatorio parametri mancanti o con sintassi errata.
Puoi anche utilizzare RaiseFault in una regola di errore se vuoi rilevare un errore durante l'elaborazione di un per errore. Ad esempio, il gestore degli errori stesso potrebbe causare un errore che vuoi segnalare utilizzando RaiseFault.
Per approfondire
- Gestione dei guasti
- Criterio RaiseFault
- Discussione della community sui modelli di gestione dei guasti