Norme relative a ServiceCallout

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X.
info

Cosa

Il criterio Service Callout ti consente di chiamare un altro servizio dal flusso del proxy API. Puoi effettuare chiamate a un servizio esterno (ad esempio un endpoint di servizio RESTful esterno) o a servizi interni (ad esempio un proxy API nella stessa organizzazione e nello stesso ambiente).

  • In un caso d'uso esterno, effettui un callout a un'API di terze parti esterna al tuo proxy. La risposta dell'API di terze parti viene analizzata e inserita nel messaggio di risposta dell'API, arricchendo e combinando i dati per gli utenti finali dell'app. Puoi anche effettuare una richiesta utilizzando il criterio Service Callout nel flusso di richiesta, quindi passare le informazioni nella risposta a TargetEndpoint del proxy API.
  • In un altro caso d'uso, chiami un proxy che si trova nella stessa organizzazione e nello stesso ambiente di quello da cui stai chiamando. Ad esempio, potresti trovare questa funzionalità utile quando hai un proxy che offre alcune funzionalità discrete di basso livello che uno o più altri proxy utilizzeranno. Ad esempio, un proxy che espone operazioni di creazione/lettura/aggiornamento/eliminazione con un datastore di backend potrebbe essere il proxy di destinazione per più proxy che espongono i dati ai client.

Il criterio supporta le richieste tramite HTTP e HTTPS.

Campioni

Chiamata locale a un proxy interno

<LocalTargetConnection>
    <APIProxy>data-manager</APIProxy>
    <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

Questo esempio crea un callout a un proxy API locale (ovvero uno nella stessa organizzazione e nello stesso ambiente) chiamato data-manager, specificando il relativo endpoint proxy il cui nome è default.

URL come variabile

<HTTPTargetConnection>
    <URL>http://example.com/{request.myResourcePath}</URL>
</HTTPTargetConnection>

Questo esempio utilizza una variabile nell'URL per compilare dinamicamente l'URL del target. La parte del protocollo dell'URL, http://, non può essere specificata da una variabile. Inoltre, devi utilizzare variabili separate per la parte del dominio dell'URL e per il resto dell'URL.

Richiesta di geocodifica / definizione di Google

<ServiceCallout name="ServiceCallout-GeocodingRequest1">
    <DisplayName>Inline request message</DisplayName>
    <Request variable="authenticationRequest">
      <Set>
        <QueryParams>
          <QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
          <QueryParam name="region">{request.queryparam.country}</QueryParam>
          <QueryParam name="sensor">false</QueryParam>
        </QueryParams>
      </Set>
    </Request>
    <Response>GeocodingResponse</Response>
    <Timeout>30000</Timeout>
    <HTTPTargetConnection>
      <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
    </HTTPTargetConnection>
</ServiceCallout>
http://maps.googleapis.com/maps/api/geocode/json

Anziché utilizzare una policy come Assegna messaggio per creare l'oggetto richiesta, puoi definirlo direttamente nella policy Service Callout. In questo esempio, il criterio Service Callout imposta i valori di tre parametri di query passati al servizio esterno. Puoi creare un intero messaggio di richiesta nel criterio Callout del servizio che specifica un payload, un tipo di codifica come application/xml, intestazioni, parametri del modulo e così via.

Ecco un altro esempio in cui la richiesta viene formulata prima di raggiungere le norme relative ai callout di servizio.

<ServiceCallout name="ServiceCallout-GeocodingRequest2">
    <Request clearPayload="false" variable="GeocodingRequest"/>
    <Response>GeocodingResponse</Response>
    <Timeout>30000</Timeout>
    <HTTPTargetConnection>
      <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
    </HTTPTargetConnection>
</ServiceCallout>

Il contenuto del messaggio di richiesta viene estratto da una variabile denominata GeocodingRequest (che potrebbe essere compilata, ad esempio, da un criterio AssignMessage). Il messaggio di risposta viene assegnato alla variabile denominata GeocodingResponse, dove è disponibile per l'analisi da parte di un criterio Estrai variabili o di un codice personalizzato scritto in JavaScript o Java. Prima del timeout, il criterio attende 30 secondi la risposta dell'API Google Geocoding.

Per un proxy API di esempio completo che utilizza questo callout del servizio, insieme alle norme Assegna messaggio ed Estrai variabili, consulta Utilizzo della composizione delle norme.

Chiamare i server di destinazione

<ServiceCallout async="false" continueOnError="false" enabled="true" name="service-callout">
    <DisplayName>service-callout</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>myResponse</Response>
    <HTTPTargetConnection>
        <LoadBalancer>
            <Algorithm>RoundRobin</Algorithm>
            <Server name="httpbin"/>
            <Server name="yahoo"/>
        </LoadBalancer>
        <Path>/get</Path>
    </HTTPTargetConnection>
</ServiceCallout>

Questa policy utilizza l'attributo LoadBalancer per chiamare i server di destinazione ed eseguire il bilanciamento del carico tra questi. In questo esempio, il carico viene distribuito su due server di destinazione denominati "httpbin" e "yahoo". Per informazioni sulla configurazione dei server di destinazione per il proxy e sul bilanciamento del carico, vedi Bilanciamento del carico tra server di backend.


Informazioni sulla policy di callout del servizio

Esistono molti scenari in cui puoi utilizzare un criterio Service Callout nel tuo proxy API. Ad esempio, puoi configurare un proxy API per effettuare chiamate a un servizio esterno per fornire dati di geolocalizzazione, recensioni dei clienti, articoli del catalogo di vendita al dettaglio di un partner e così via.

Un callout viene in genere utilizzato con altre due norme: Assegna messaggio ed Estrai variabili.

  • Richiesta: Assegna messaggio compila il messaggio di richiesta inviato al servizio remoto.
  • Risposta: Estrai variabili analizza la risposta ed estrae contenuti specifici.

La composizione tipica delle norme relative ai callout di servizio prevede:

  1. Assegna criterio messaggio: crea un messaggio di richiesta, compila le intestazioni HTTP, i parametri di query, imposta il verbo HTTP e così via.
  2. Policy Service Callout: fa riferimento a un messaggio creato dalla policy Assign Message, definisce un URL di destinazione per la chiamata esterna e definisce un nome per l'oggetto di risposta restituito dal servizio di destinazione.

    Per migliorare le prestazioni, puoi anche memorizzare nella cache le risposte di Service Callout, come descritto in questo thread della community Apigee: How can I store the results of the ServiceCallout policy in cache and later retrieve it from cache?.
  3. Extract Variables policy: Typically defines a JSONPath or XPath expression that parses the message generated by the Service Callout. Il criterio imposta quindi le variabili contenenti i valori analizzati dalla risposta del callout del servizio.

Consulta la sezione Utilizzo della composizione delle norme per un proxy API di esempio completo che utilizza la norma Service Callout insieme alle norme Assign Message ed Extract Variables.

Gestione degli errori personalizzata

Riferimento elemento

Di seguito sono riportati gli elementi e gli attributi che puoi configurare in queste norme:

<ServiceCallout async="false" continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Custom label used in UI</DisplayName>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <Remove>
            <ReasonPhrase/>
            <StatusCode/>
            <Path/>
            <Version/>
            <Verb/>
         </Remove>
         <Copy>
            <ReasonPhrase/>
            <StatusCode/>
            <Path/>
            <Version/>
            <Verb/>
        </Copy>
        <Add>
            <Headers/>
            <QueryParams/>
            <FormParams/>
        </Add>
        <Set>
            <Headers/>
            <QueryParams/>
            <FormParams/>
            <Payload/>
            <ReasonPhrase/>
            <StatusCode/>
            <Path/>
            <Version/>
            <Verb/>
        </Set>
    </Request>
    <Response>calloutResponse</Response>
    <Timeout>30000</Timeout>
    <HTTPTargetConnection>
        <URL>http://example.com</URL>
        <LoadBalancer/>
        <SSLInfo/>
        <Properties/>
    </HTTPTargetConnection>
    <LocalTargetConnection>
        <APIProxy/>
        <ProxyEndpoint/>
        <Path/>
    </LocalTargetConnection>
</ServiceCallout>

Attributi <ServiceCallout>

<ServiceCallout async="false" continueOnError="false" enabled="true" name="Service-Callout-1">

La tabella seguente descrive gli attributi comuni a tutti gli elementi principali del criterio:

Attributo Descrizione Predefinito Presenza
name

Il nome interno del criterio. Il valore dell'attributo name può Deve contenere lettere, numeri, spazi, trattini, trattini bassi e punti. Questo valore non può superare i 255 caratteri.

Se vuoi, puoi utilizzare l'elemento <DisplayName> per etichettare il criterio in l'editor proxy della UI di gestione con un nome diverso in linguaggio naturale.

N/D Obbligatorio
continueOnError

Imposta il valore su false per restituire un errore quando un criterio non viene eseguito. Si tratta di un comportamento previsto per la maggior parte dei criteri.

Imposta su true per fare in modo che l'esecuzione del flusso continui anche dopo un criterio non riesce.

falso Facoltativo
enabled

Imposta il valore su true per applicare il criterio.

Imposta false per disattivare il criterio. Il criterio non verrà applicata anche se rimane collegata a un flusso.

true Facoltativo
async

Questo attributo è obsoleto.

falso Deprecato

&lt;DisplayName&gt; elemento

Da utilizzare in aggiunta all'attributo name per etichettare il criterio in editor proxy della UI di gestione con un nome diverso e in linguaggio naturale.

<DisplayName>Policy Display Name</DisplayName>
Predefinito

N/D

Se ometti questo elemento, il valore dell'attributo name del criterio è in uso.

Presenza Facoltativo
Tipo Stringa

Elemento <Request>

Specifica la variabile contenente il messaggio di richiesta inviato dal proxy API all'altro servizio. La variabile può essere creata da una policy precedente nel flusso oppure puoi crearla in linea nella policy Chiamata di servizio.

<Request clearPayload="true" variable="myRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Remove>
        <ReasonPhrase/>
        <StatusCode/>
        <Path/>
        <Version/>
        <Verb/>
    </Remove>
    <Copy>
        <ReasonPhrase/>
        <StatusCode/>
        <Path/>
        <Version/>
        <Verb/>
    </Copy>
    <Add>
        <Headers/>
        <QueryParams/>
        <FormParams/>
    </Add>
    <Set>
        <Headers/>
        <QueryParams/>
        <FormParams/>
        <Payload/>
        <ReasonPhrase/>
        <StatusCode/>
        <Path/>
        <Version/>
        <Verb/>
    </Set>
</Request>

La sintassi dei tag <Remove>, <Copy>, <Add> e <Set> è la stessa della policy Assegna messaggio.

La norma restituisce un errore se il messaggio di richiesta non può essere risolto o è di un tipo non valido.

Nell'esempio più semplice, passi una variabile contenente il messaggio di richiesta compilato in precedenza nel flusso del proxy API:

<Request clearPayload="true" variable="myRequest"/>

In alternativa, puoi compilare il messaggio di richiesta inviato al servizio esterno nella stessa policy di callout del servizio:

<Request>
  <Set>
    <Headers>
      <Header name="Accept">application/json</Header>
    </Headers>
    <Verb>POST</Verb>
    <Payload contentType="application/json">{"message":"my test message"}</Payload>
  </Set>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</Request>
Predefinita Se ometti l'elemento Request o uno qualsiasi dei suoi attributi, Edge assegna i seguenti valori predefiniti:

<Request clearPayload="true" variable="servicecallout.request"/>

Vediamo cosa significano questi valori predefiniti. Innanzitutto, clearPayload=true significa che viene creato un nuovo oggetto richiesta ogni volta che viene eseguita la policy ServiceCallout. Ciò significa che la richiesta e il percorso URI della richiesta non vengono mai riutilizzati. In secondo luogo, il nome della variabile predefinita, servicecallout.request, è un nome riservato che viene assegnato alla richiesta se non ne fornisci uno.

È importante conoscere questo nome predefinito se utilizzi la mascheratura dei dati: se ometti il nome della variabile, devi aggiungere servicecallout.request alla configurazione della maschera. Ad esempio, se vuoi mascherare l'intestazione Authorization in modo che non venga visualizzata nelle sessioni di tracciamento, aggiungi quanto segue alla configurazione di mascheramento per acquisire il nome predefinito:

servicecallout.request.header.Authorization.

Presenza Facoltativo.
Tipo N/D

Attributi

Attributo Descrizione Predefinito Presenza
variabile

Nome della variabile che conterrà il messaggio della richiesta.

servicecallout.request Facoltativo
clearPayload

Se true, la variabile contenente il messaggio di richiesta viene cancellata dopo l'invio della richiesta alla destinazione HTTP per liberare la memoria utilizzata dal messaggio di richiesta.

Imposta l'opzione clearPayload su false solo se il messaggio di richiesta è necessario dopo l'esecuzione del callout del servizio.

true Facoltativo

Elemento <Request>/<IgnoreUnresolvedVariables>

Se impostata su true, la policy ignora qualsiasi errore di variabile non risolto nella richiesta.

<Request clearPayload="true" variable="myRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</Request>
Predefinita falso
Presenza Facoltativo
Tipo Booleano

Elemento <Response>

Includi questo elemento quando la logica del proxy API richiede la risposta della chiamata remota per un'ulteriore elaborazione.

Quando questo elemento è presente, specifica il nome della variabile che conterrà il messaggio di risposta ricevuto dal servizio esterno. La risposta dalla destinazione viene assegnata alla variabile solo quando l'intera risposta viene letta correttamente dalla policy. Se la chiamata remota non va a buon fine per qualsiasi motivo, il criterio restituisce un errore.

Se questo elemento viene omesso, il proxy API non attende una risposta; l'esecuzione del flusso del proxy API continua con i passaggi del flusso successivi. Inoltre, per ovvie ragioni, senza l'elemento Response, la risposta dalla destinazione non è disponibile per l'elaborazione da parte dei passaggi successivi e non è possibile rilevare un errore nella chiamata remota. Un utilizzo comune dell'omissione dell'elemento Response quando si utilizza ServiceCallout: registrare i messaggi in un sistema esterno.

 <Response>calloutResponse</Response>
Predefinita ND
Presenza Facoltativo
Tipo Stringa

Elemento <Timeout>

Il tempo in millisecondi durante il quale il criterio Callout del servizio attenderà una risposta dalla destinazione. Non puoi impostare questo valore in modo dinamico in fase di runtime. Se il callout del servizio raggiunge il timeout, viene restituito un errore HTTP 500, il criterio non viene applicato e il proxy API entra in uno stato di errore, come descritto in Gestione degli errori.

<Timeout>30000</Timeout>
Predefinita 55.000 millisecondi (55 secondi), l'impostazione predefinita del timeout HTTP per Apigee Edge
Presenza Facoltativo
Tipo Numero intero

Elemento <HTTPTargetConnection>

Fornisce i dettagli di trasporto, come URL, TLS/SSL e proprietà HTTP. Consulta il riferimento alla configurazione di <TargetEndpoint>.

<HTTPTargetConnection>
    <URL>http://example.com</URL>
    <LoadBalancer/>
    <SSLInfo/>
    <Properties/>
</HTTPTargetConnection>
Predefinita N/D
Presenza Obbligatorio
Tipo N/D

Elemento <HTTPTargetConnection>/<URL>

L'URL del servizio chiamato:

<HTTPTargetConnection>
    <URL>http://example.com</URL>
</HTTPTargetConnection>

Puoi fornire parte dell'URL in modo dinamico con una variabile. Tuttavia, la parte del protocollo dell'URL, http:// di seguito, non può essere specificata da una variabile. Nell'esempio successivo, utilizzi una variabile per specificare il valore di un parametro di query:

<URL>http://example.com/forecastrss?w=${request.header.woeid}</URL>

In alternativa, imposta una parte del percorso dell'URL con una variabile:

<URL>http://example.com/{request.resourcePath}?w=${request.header.woeid}</URL>

Se vuoi utilizzare una variabile per specificare il dominio e la porta dell'URL, utilizza una variabile solo per il dominio e la porta e una seconda variabile per qualsiasi altra parte dell'URL:

<URL>http://{request.dom_port}/{request.resourcePath}</URL>
Predefinita N/D
Presenza Obbligatorio
Tipo Stringa

Elemento <HTTPTargetConnection>/<SSLInfo>

La configurazione TLS/SSL del servizio di backend. Per assistenza sulla configurazione TLS/SSL, consulta Configurazione di TLS da Edge al backend (cloud e cloud privato) e "Configurazione di TargetEndpoint TLS/SSL" in Riferimento alla configurazione del proxy API.

<HTTPTargetConnection>
    <URL>https://example.com</URL>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://mykeystoreref</KeyStore>  ## Use of a reference is recommended
        <KeyAlias>myKey</KeyAlias>
        <TrustStore>myTruststore</TrustStore>
        <Ciphers/>
        <Protocols/>
    </SSLInfo>
</HTTPTargetConnection>
Predefinita N/D
Presenza Facoltativo
Tipo N/D

Elemento <HTTPTargetConnection>/<Properties>

Proprietà di trasporto HTTP al servizio di backend. Per saperne di più, consulta Riferimento per le proprietà degli endpoint.

<HTTPTargetConnection>
    <URL>http://example.com</URL>
    <Properties>
        <Property name="allow.http10">true</Property>
        <Property name="request.retain.headers">
          User-Agent,Referer,Accept-Language
        </Property>
    </Properties>
</HTTPTargetConnection>
Predefinita N/D
Presenza Facoltativo
Tipo N/D

Elemento <HTTPTargetConnection>/<LoadBalancer>

Chiama uno o più server di destinazione ed esegui il bilanciamento del carico. Consulta l'esempio Server di destinazione delle chiamate nella sezione Esempi. Vedi anche Bilanciamento del carico tra server di backend. Vedi anche questo post della community che illustra i modi per chiamare i server di destinazione sia dal criterio Callout del servizio sia utilizzando le regole di routing.

<HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection>
Predefinita N/D
Presenza Facoltativo
Tipo N/D

Elemento <LocalTargetConnection>

Specifica un proxy locale, ovvero un proxy nella stessa organizzazione e nello stesso ambiente, come destinazione dei callout di servizio.

Per specificare ulteriormente la destinazione, utilizza gli elementi <APIProxy> e <ProxyEndpoint> oppure l'elemento <Path>.

<LocalTargetConnection>
   <APIProxy/>
   <ProxyEndpoint/>
   <Path/>
</LocalTargetConnection>
Predefinita N/D
Presenza Obbligatorio
Tipo N/D

Elemento <LocalTargetConnection>/<APIProxy>

Il nome di un proxy API che è la destinazione di una chiamata locale. Il proxy deve trovarsi nella stessa organizzazione e nello stesso ambiente del proxy che effettua la chiamata.

<LocalTargetConnection>
   <APIProxy>data-manager</APIProxy>
   <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

Oltre all'elemento <APIProxy>, includi l'elemento <ProxyEndpoint> per specificare il nome dell'endpoint proxy a cui deve essere indirizzata la chiamata.

<LocalTargetConnection>
   <APIProxy/>
   <ProxyEndpoint/>
</LocalTargetConnection>
Predefinita N/D
Presenza Obbligatorio
Tipo Stringa

Elemento <LocalTargetConnection>/<ProxyEndpoint>

Il nome dell'endpoint proxy che deve essere la destinazione delle chiamate. Si tratta di un endpoint proxy nel proxy API specificato con l'elemento <APIProxy>.

<LocalTargetConnection>
   <APIProxy>data-manager</APIProxy>
   <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>
Predefinita N/D
Presenza Facoltativo
Tipo N/D

Elemento <LocalTargetConnection>/<Path>

Un percorso verso l'endpoint di destinazione. L'endpoint deve fare riferimento a un proxy nella stessa organizzazione e nello stesso ambiente del proxy che effettua la chiamata.

Utilizza questa opzione anziché una coppia <APIProxy>/<ProxyEndpoint> quando non conosci o non puoi fare affidamento sul nome del proxy. Il percorso potrebbe essere un target affidabile.

<LocalTargetConnection>
   <Path>/data-manager</Path>
</LocalTargetConnection>
Predefinita N/D
Presenza Facoltativo
Tipo N/D

Schemi

Variabili di flusso

Le variabili di flusso consentono il comportamento dinamico di criteri e flussi in fase di runtime, in base alle intestazioni HTTP, al contenuto dei messaggi o al contesto del flusso. Le seguenti variabili di flusso predefinite sono disponibili dopo l'esecuzione di un criterio di chiamata del servizio. Per ulteriori informazioni sulle variabili di flusso, consulta Riferimento alle variabili.

I callout di servizio hanno una propria richiesta e risposta e puoi accedere a questi dati tramite le variabili. Poiché il messaggio principale utilizza i prefissi delle variabili request.* e response.*, utilizza i prefissi myrequest.* e calloutResponse.* (i valori predefiniti nella configurazione del callout di servizio) per ottenere dati dei messaggi specifici per il callout di servizio. Il primo esempio nella tabella seguente mostra come ottenere le intestazioni HTTP nel Service Callout.

Variabile Descrizione

Di seguito è riportato un esempio di recupero delle intestazioni di richiesta e risposta di Service Callout in modo simile a come si ottengono le intestazioni dalla richiesta e dalla risposta principali.

calloutResponse.header.HeaderName

myRequest.header.HeaderName

dove calloutResponse è il nome della variabile per la risposta nel Service Callout e myRequest è il nome della variabile per la richiesta. Ad esempio:

calloutResponse.header.Content-Length

restituisce l'intestazione Content-Length della risposta del callout del servizio.

Scope: From the Service Callout forward
Type: String
Permission: Read/Write

Un'intestazione del messaggio nella richiesta o nella risposta del callout di servizio. Ad esempio, se la destinazione del proxy API è http://example.com e la destinazione del callout del servizio è http://mocktarget.apigee.net, queste variabili sono le intestazioni del callout a http://mocktarget.apigee.net.

servicecallout.requesturi

Ambito: dalla richiesta di callout del servizio in poi
Tipo: stringa
Autorizzazione: lettura/scrittura

L'URI TargetEndpoint per un criterio ServiceCallout. L'URI è l'URL TargetEndpoint senza la specifica del protocollo e del dominio.

servicecallout.{policy-name}.target.url

Ambito: dalla richiesta di callout del servizio in poi
Tipo: stringa
Autorizzazione: lettura/scrittura

L'URL di destinazione di un callout di servizio.

calloutResponse.content

dove calloutResponse è il <Response>nome della variabile nella configurazione del callout del servizio.

Scope: dalla risposta del callout del servizio in poi
Type: String
Permission: Read/Write

Il corpo della risposta del richiamo del servizio.

servicecallout.{policy-name}.expectedcn

Ambito: dalla richiesta di callout del servizio in poi
Tipo: stringa
Autorizzazione: lettura/scrittura

Il nome comune previsto di TargetEndpoint a cui si fa riferimento in un criterio ServiceCallout. Questo è significativo solo quando TargetEndpoint fa riferimento a un endpoint TLS/SSL.

servicecallout.{policy-name}.failed

Scope: dalla risposta del callout del servizio in poi
Type: booleano
Permission: lettura/scrittura

Valore booleano che indica se il criterio è stato applicato correttamente (false) o meno (true).

Errori

Questa sezione descrive i codici e i messaggi di errore restituiti, nonché le variabili di errore impostate da Edge quando questo criterio attiva un errore. È importante sapere se stai sviluppando regole di errore per per gestire gli errori. Per saperne di più, consulta Cosa devi sapere sugli errori relativi ai criteri e sulla gestione di errore.

Errori di runtime

Questi errori possono verificarsi quando il criterio viene eseguito.

Codice di errore Stato HTTP Causa Correggi
steps.servicecallout.ExecutionFailed 500

Questo errore può verificarsi quando:

  • al criterio viene chiesto di gestire l'input non valido o altrimenti non valido.
  • il servizio di destinazione backend restituisce uno stato di errore (per impostazione predefinita, 4xx o 5xx).
steps.servicecallout.RequestVariableNotMessageType 500 La variabile di richiesta specificata nel criterio non è di tipo Messaggio. Ad esempio, se si tratta di una stringa o di un altro tipo non legato ai messaggi, viene visualizzato questo errore.
steps.servicecallout.RequestVariableNotRequestMessageType 500 La variabile di richiesta specificata nel criterio non è di tipo Messaggio di richiesta. Per Ad esempio, se si tratta di un tipo di risposta, visualizzerai questo errore.

Errori di deployment

Questi errori possono verificarsi quando esegui il deployment di un proxy contenente questo criterio.

Nome errore Causa Correggi
URLMissing L'elemento <URL> all'interno di <HTTPTargetConnection> mancante o vuoto.
ConnectionInfoMissing Questo errore si verifica se il criterio non ha un <HTTPTargetConnection> o <LocalTargetConnection> .
InvalidTimeoutValue Questo errore si verifica se il valore di <Timeout> è negativo o pari a zero.

Variabili di errore

Queste variabili vengono impostate quando si verifica un errore di runtime. Per ulteriori informazioni, vedi Cosa devi sapere sugli errori relativi alle norme.

Variabili Dove Esempio
fault.name="fault_name" fault_name è il nome dell'errore, come elencato nella precedente tabella Errori di runtime. Il nome dell'errore è l'ultima parte del codice di errore. fault.name = "RequestVariableNotMessageType"
servicecallout.policy_name.failed policy_name è il nome specificato dall'utente del criterio che ha generato l'errore. servicecallout.SC-GetUserData.failed = true

Esempio di risposta di errore

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.servicecallout.RequestVariableNotMessageType"
      },
      "faultstring":"ServiceCallout[ServiceCalloutGetMockResponse]: 
            request variable data_str value is not of type Message"
   }
}

Esempio di regola di errore

<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="RequestVariableNotMessageType">
    <Step>
        <Name>AM-RequestVariableNotMessageType</Name>
    </Step>
    <Condition>(fault.name = "RequestVariableNotMessageType")</Condition>
</FaultRule>

Argomenti correlati