Questa pagina si applica ad Apigee e Apigee hybrid.
Panoramica
Il criterio IntegrationCallout consente di eseguire un'Application Integration con un'API trigger. Tuttavia, prima di eseguire un'integrazione, devi eseguire il criterio SetIntegrationRequest. Il criterio SetIntegrationRequest crea un oggetto di richiesta e rende l'oggetto disponibile per il criterio IntegrationCallout (IntegrazioneCallout) come variabile di flusso. L'oggetto richiesta contiene i dettagli dell'integrazione, ad esempio il nome dell'attivatore dell'API, l'ID progetto di integrazione, il nome dell'integrazione e altri dettagli configurati nel criterio SetIntegrationRequest. Il criterio IntegrationCallout utilizza la variabile di flusso dell'oggetto richiesta per eseguire l'integrazione. Puoi configurare il criterio IntegrationCallout per salvare la risposta dell'esecuzione dell'integrazione in una variabile di flusso.
Il criterio IntegrationCallout è utile se vuoi eseguire l'integrazione nel mezzo flusso proxy. In alternativa, anziché configurare il criterio IntegrationCallout, puoi anche eseguire un'integrazione specificando un endpoint di integrazione come endpoint di destinazione. Per ulteriori informazioni, consulta IntegrationEndpoint.
Questo criterio è una norma estendibile e il suo utilizzo potrebbe comportare costi o di utilizzo delle applicazioni, a seconda della licenza Apigee. Per informazioni sui tipi di criteri e sulle implicazioni per l'utilizzo, consulta Tipi di criteri.
<IntegrationCallout>
Specifica il criterio IntegrationCallout.
| Valore predefinito | N/D |
| Obbligatorio? | Obbligatorio |
| Tipo | Tipo complesso |
| Elemento principale | N/D |
| Elementi secondari |
<DisplayName><AsyncExecution><Request><Response> |
La tabella seguente fornisce una descrizione generale degli elementi secondari di <IntegrationCallout>:
| Elemento secondario | Obbligatorio? | Descrizione |
|---|---|---|
<DisplayName> |
Facoltativo | Un nome personalizzato per la norma. |
<AsyncExecution> |
Facoltativo | Specifica se l'integrazione deve essere eseguita in modalità sincrona o asincrona. |
<Request> |
Obbligatorio | La variabile del flusso contenente l'oggetto della richiesta creato dal criterio SetIntegrationRequest. |
<Response> |
Facoltativo | La variabile di flusso per salvare la risposta dell'integrazione. |
La sintassi dell'elemento <IntegrationCallout> è la seguente:
Sintassi
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <IntegrationCallout continueOnError="[true|false]" enabled="[true|false]" name=POLICY_NAME> <DisplayName>POLICY_DISPLAY_NAME</DisplayName> <AsyncExecution>BOOLEAN_ASYNC_EXECUTION</AsyncExecution> <Request clearPayload="[true|false]">REQUEST_FLOW_VARIABLE_NAME</Request> <Response>RESPONSE_FLOW_VARIABLE_NAME</Response> </IntegrationCallout>
Esempio
L'esempio seguente mostra la definizione del criterio IntegrationCallout:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <IntegrationCallout continueOnError="false" enabled="true" name="Integration-Callout"> <DisplayName>Integration-Callout-1</DisplayName> <AsyncExecution>true</AsyncExecution> <Request clearPayload="true">my_request_flow_var</Request> <Response>my_response_flow_var</Response> </IntegrationCallout>
Questo elemento ha i seguenti attributi comuni a tutti i criteri:
| Attributo | Predefinito | Obbligatorio? | Descrizione |
|---|---|---|---|
name |
N/A | Obbligatorio |
Il nome interno del criterio. Il valore dell'attributo Facoltativamente, utilizza l'elemento |
continueOnError |
falso | Facoltativo | Imposta su false per restituire un errore in caso di errore del criterio. Questo è un comportamento previsto per
la maggior parte dei criteri. Imposta su true per continuare l'esecuzione del flusso anche dopo un errore nel criterio. Vedi anche:
|
enabled |
true | Facoltativo | Imposta su true per applicare il criterio. Imposta su false per disattivare il
criterio. Il criterio non verrà applicato anche se rimane collegato a un flusso. |
async |
falso | Deprecato | Questo attributo è stato ritirato. |
Riferimento all'elemento secondario
Questa sezione descrive gli elementi secondari di<IntegrationCallout>.
<DisplayName>
Da utilizzare insieme all'attributo name per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso e più naturale.
L'elemento <DisplayName> è comune a tutti i criteri.
| Valore predefinito | N/D |
| Obbligatorio? | Facoltativo. Se ometti <DisplayName>, viene utilizzato il valore dell'attributo name del criterio. |
| Tipo | Stringa |
| Elemento principale | <PolicyElement> |
| Elementi secondari | Nessuno |
La sintassi dell'elemento <DisplayName> è la seguente:
Sintassi
<PolicyElement> <DisplayName>POLICY_DISPLAY_NAME</DisplayName> ... </PolicyElement>
Esempio
<PolicyElement> <DisplayName>My Validation Policy</DisplayName> </PolicyElement>
L'elemento <DisplayName> non ha attributi o elementi secondari.
<AsyncExecution>
Specifica la modalità per eseguire l'integrazione. Puoi eseguire l'integrazione in modo sincrono o asincrono.
Se impostato su true, l'integrazione viene eseguita in modo asincrono. E se impostato su
false, l'integrazione viene eseguita in modo sincrono.
- Modalità asincrona: quando la richiesta di eseguire l'integrazione raggiunge l'endpoint, quest'ultimo restituisce immediatamente.
gli ID di esecuzione dell'integrazione, ma ne avvia l'esecuzione nel momento specificato
dall'elemento
<ScheduleTime>. Se non hai impostato<ScheduleTime>, l'integrazione è pianificata per l'esecuzione immediata. Anche se l'integrazione è pianificata per essere eseguita immediatamente, l'esecuzione potrebbe iniziare dopo alcuni secondi. Quando l'integrazione vengono eseguiti i seguenti due casi:- L'integrazione restituisce il codice di stato HTTP
200 OKin modo che il chiamante possa continuare l'elaborazione. - Il criterio IntegrationCallout viene completato.
- L'integrazione restituisce il codice di stato HTTP
- Modalità sincrona: quando la richiesta di esecuzione dell'integrazione raggiunge l'endpoint, quest'ultimo avvia immediatamente l'esecuzione dell'integrazione e attende la risposta. Il limite di tempo massimo per completare l'esecuzione è di 2 minuti. Al termine dell'esecuzione, l'endpoint restituisce una risposta con gli ID esecuzione e altri dati di risposta.
| Valore predefinito | falso |
| Obbligatorio? | Facoltativo |
| Tipo | Booleano |
| Elemento principale |
<IntegrationCallout> |
| Elementi secondari | Nessuno |
L'elemento <AsyncExecution> utilizza la seguente sintassi:
Sintassi
<AsyncExecution>BOOLEAN</AsyncExecution>
Esempio
L'esempio seguente imposta l'esecuzione asincrona su true:
<AsyncExecution>true</AsyncExecution>
<Request>
Specifica la variabile di flusso contenente l'oggetto della richiesta creato dal criterio SetIntegrationRequest. Il criterio IntegrationCallout invia questo oggetto della richiesta ad Application Integration per l'esecuzione dell'integrazione.
| Valore predefinito | N/D |
| Obbligatorio? | Obbligatorio |
| Tipo | Stringa |
| Elemento principale |
<IntegrationCallout> |
| Elementi secondari | Nessuno |
L'elemento <Request> utilizza la seguente sintassi:
Sintassi
<Request clearPayload="true">FLOW_VARIABLE_NAME</Request>
Esempio
L'esempio seguente specifica che l'oggetto richiesta è disponibile nella variabile di flusso my_request_flow_var:
<Request clearPayload="true">my_request_flow_var</Request>
La tabella seguente descrive gli attributi di <Request>:
| Attributo | Obbligatorio? | Tipo | Descrizione |
|---|---|---|---|
clearPayload |
Facoltativo | boolean | Specifica se l'oggetto di richiesta deve essere cancellato dalla memoria dopo aver inviato la richiesta di esecuzione dell'integrazione.
Se non specifichi questo attributo, il valore predefinito è |
<Response>
Specifica la variabile di flusso per salvare la risposta dell'integrazione.
Se non specifichi questo elemento, il criterio salva la risposta nella variabile di flusso integration.response.
| Valore predefinito | integration.response |
| Obbligatorio? | Facoltativo |
| Tipo | Stringa |
| Elemento principale |
<IntegrationCallout> |
| Elementi secondari | Nessuno |
integration.response.content o flow_variable.content sono accessibili all'output dell'integrazione. L'elemento <Response> utilizza la seguente sintassi:
Sintassi
<Response>FLOW_VARIABLE_NAME</Response>
Esempio
L'esempio seguente salva la risposta dell'esecuzione dell'integrazione nella variabile di flusso my_response_flow_var:
<Response>my_response_flow_var</Response>
Codici di errore
Questa sezione descrive i codici, i messaggi di errore e le variabili di errore. impostato da Apigee quando questo criterio attiva un errore. Queste informazioni sono essenziali se stai sviluppando regole di errore per gestire gli errori. Per scoprire di più, consulta Informazioni importanti sugli errori relativi alle norme e Gestione degli errori.
Errori di runtime
Questi errori possono verificarsi quando il criterio viene eseguito.
| Codice di errore | Stato HTTP | Causa |
|---|---|---|
entities.UnresolvedVariable |
500 |
Questo errore si verifica se Apigee non riesce a risolvere le variabili integration.project.id
o integration.name. |
steps.integrationcallout.ExecutionFailed |
500 |
Questo errore può verificarsi se il servizio di destinazione di backend restituisce uno stato di errore HTTP come
|
steps.integrationcallout.NullRequestVariable |
500 |
Questo errore si verifica se la variabile di flusso specificata in <Request> è nulla. |
steps.integrationcallout.RequestVariableNotMessageType |
500 |
Questo errore si verifica quando la variabile di flusso specificata dall'elemento Request
non è di tipo message. |
steps.integrationcallout.RequestVariableNotRequestMessageType |
500 |
Questo errore si verifica quando la variabile di flusso specificata dall'elemento Request
non è di tipo Messaggio di richiesta. |
messaging.adaptors.http.filter.GoogleTokenGenerationFailure |
500 |
Questo errore può verificarsi a causa di una configurazione errata dell'account di servizio. La Le possibili cause sono:
|
Variabili di errore
Ogni volta che si verificano errori di esecuzione in un criterio, Apigee genera messaggi di errore. Puoi visualizzare questi messaggi di errore nella risposta di errore. Spesso i messaggi di errore generati dal sistema potrebbero non essere pertinenti nel contesto del tuo prodotto. Ti consigliamo di personalizzare i messaggi di errore in base alle tipo di errore per rendere i messaggi più significativi.
Per personalizzare i messaggi di errore, puoi utilizzare le regole di errore o il criterio RaiseFault. Per
informazioni sulle differenze tra le regole di errore e il criterio RaiseFault, vedi
FaultRules e il criterio RaiseFault.
Devi verificare le condizioni utilizzando l'elemento Condition sia nelle regole di errore sia nel criterio RaiseFault.
Apigee fornisce variabili di errore univoche per ogni criterio e i valori delle variabili di errore vengono impostati quando un criterio attiva errori di runtime.
Utilizzando queste variabili, puoi verificare la presenza di condizioni di errore specifiche e intraprendere le azioni appropriate. Per ulteriori informazioni su come controllare le condizioni di errore, consulta Condizioni di compilazione.
La tabella seguente descrive le variabili di errore specifiche di questo criterio.
| Variabili | Dove | Esempio |
|---|---|---|
fault.name |
fault.name può corrispondere a uno dei guasti elencati nella tabella Errori di runtime.
Il nome dell'errore è l'ultima parte del codice dell'errore. |
fault.name Matches "UnresolvedVariable" |
IntegrationCallout.POLICY_NAME.failed |
POLICY_NAME è il nome specificato dall'utente del criterio che ha generato l'errore. | IntegrationCallout.integration-callout-1.failed = true |
Argomenti correlati
Per scoprire di più sulla funzionalità di integrazione delle applicazioni, consulta Panoramica di Application Integration