Norme relative a ServiceCallout

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X.
Informazioni

Cosa

Questo criterio consente di chiamare un altro servizio dal flusso proxy API. Tu possono effettuare callout a un servizio esterno (ad esempio a un endpoint di servizio RESTful esterno) interni (ad esempio, un proxy API nella stessa organizzazione e nello stesso ambiente).

  • In un caso d'uso esterno, crei un callout per un'API di terze parti esterna al tuo proxy. La risposta dell'API di terze parti viene analizzata e inserita nella risposta dell'API arricchendo e integrando i contenuti i dati per gli utenti finali dell'app. Puoi anche inviare una richiesta utilizzando il criterio callout di servizio nel flusso della richiesta, poi passa le informazioni nella risposta al TargetEndpoint del proxy API.
  • In un altro caso d'uso, chiami un proxy che si trova nella stessa organizzazione e nello stesso ambiente di da quello da cui stai chiamando. Ad esempio, potrebbe essere utile se hai un proxy che offre alcune discrete funzionalità di basso livello che verranno utilizzate da uno o più altri proxy. Per Ad esempio, un proxy che espone le 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 su HTTP e HTTPS.

Campioni

Chiamata locale a un proxy interno

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

In questo esempio viene creato un callout per un proxy API locale (ossia uno nella stessa organizzazione) e l'ambiente) denominato data-manager, specificando il relativo endpoint proxy il cui nome è default.

URL come variabile

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

In questo esempio viene utilizzata una variabile nell'URL per compilare in modo dinamico l'URL del target. La la parte del protocollo dell'URL, http://, non può essere specificata da un . Inoltre, devi utilizzare variabili separate per la porzione di dominio dell'URL e per il resto dell'URL.

Geocodifica di Google / definisci richiesta

<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 un criterio come Assegna messaggio per creare l'oggetto di richiesta, puoi direttamente nel criterio relativo ai callout di servizio. In questo esempio, le norme sui callout di servizio imposta i valori di tre parametri di ricerca passati al servizio esterno. Puoi creare un nuovo l'intero messaggio di richiesta nel criterio callout di servizio che specifica un tipo di codifica payload ad esempio application/xml, intestazioni, parametri modulo ecc.

Ecco un altro esempio in cui viene effettuata la richiesta prima di raggiungere il 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 criterioAssignMessage). Il messaggio di risposta viene assegnato chiamata GeocodingResponse, dove è una disponibili per essere analizzati da un criterio Estrai variabili o da codice personalizzato scritto in JavaScript o Java. Il criterio attende 30 secondi di risposta dall'API Google Geocoding prima in timeout.

Per un proxy API di esempio completo che utilizza questo esempio di callout di servizio, insieme al Assegnare criteri per i messaggi ed estrarre le variabili. Consulta l'articolo sull'utilizzo dei criteri composizione.

Server target di chiamata

<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>

Questo criterio utilizza l'attributo LoadBalancer per chiamare i server di destinazione ed eseguire il bilanciamento del carico tra di loro. In questo esempio, il carico è distribuito tra due server di destinazione denominati "httpbin" e "yahoo". Per informazioni sulla configurazione dei server di destinazione per il proxy e sulla configurazione sul bilanciamento del carico, consulta Bilanciamento del carico server di backend.


Informazioni sulle norme relative ai callout di servizio

Esistono molti scenari in cui è possibile utilizzare un criterio callout di servizio nel proxy API. Per Ad esempio, puoi configurare un proxy API per effettuare chiamate a un servizio esterno dati di geolocalizzazione, recensioni dei clienti, articoli del catalogo di un partner e così via.

In genere, un callout viene utilizzato con due altri criteri: Assegna messaggio ed Estrai variabili.

  • Richiesta: Assegna messaggio compila il messaggio di richiesta inviato al telecomando completamente gestito di Google Cloud.
  • Risposta: l'opzione Estrai variabili analizza la risposta ed estrae specifiche. contenuti.

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

  1. Assegna messaggio policy: crea un messaggio di richiesta, compila le intestazioni HTTP e i parametri di query, imposta il parametro HTTP verbo e così via.
  2. Criterio Callout di servizio: fa riferimento a un messaggio creato dall'Assegna messaggio policy, 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 ai callout di servizio, come descritto in Thread della community Apigee: https://community.apigee.com/questions/34110/how-can-i-store-the-results-of-the-servicecallout.html.
  3. Estrai variabili policy: in genere definisce un'espressione JSONPath o XPath che analizza il messaggio generato dal callout di servizio. Il criterio quindi imposta variabili contenenti i valori analizzati dalla Risposta al callout del servizio.

Consulta la sezione Utilizzo dei criteri composizione per un proxy API di esempio completo che utilizza il criterio callout di servizio insieme a i criteri Assegna messaggio ed Estrai variabili.

Gestione personalizzata degli errori

Riferimento elemento

Di seguito sono riportati gli elementi e gli attributi che puoi configurare su questo criterio:

<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>

&lt;ServiceCallout&gt; attributi

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

The following table describes attributes that are common to all policy parent elements:

Attribute Description Default Presence
name

The internal name of the policy. The value of the name attribute can contain letters, numbers, spaces, hyphens, underscores, and periods. This value cannot exceed 255 characters.

Optionally, use the <DisplayName> element to label the policy in the management UI proxy editor with a different, natural-language name.

N/A Required
continueOnError

Set to false to return an error when a policy fails. This is expected behavior for most policies.

Set to true to have flow execution continue even after a policy fails.

false Optional
enabled

Set to true to enforce the policy.

Set to false to turn off the policy. The policy will not be enforced even if it remains attached to a flow.

true Optional
async

This attribute is deprecated.

false Deprecated

<DisplayName> element

Use in addition to the name attribute to label the policy in the management UI proxy editor with a different, natural-language name.

<DisplayName>Policy Display Name</DisplayName>
Default

N/A

If you omit this element, the value of the policy's name attribute is used.

Presence Optional
Type String

&lt;Request&gt; elemento

Specifica la variabile contenente il messaggio di richiesta che viene inviato dal proxy API allo altro servizio. La variabile può essere creata da un criterio precedente nel flusso oppure puoi crearla in linea nelle norme sui callout 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 Assegna messaggio .

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

Nell'esempio più semplice, passi una variabile contenente il messaggio di richiesta che è stato 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 utilizzando il criterio relativo ai callout del servizio stesso:

<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:

&lt;Request clearPayload=&quot;true&quot; variable=&quot;servicecallout.request&quot;/&gt;

Esaminiamo il significato di questi valori predefiniti. Innanzitutto, clearPayload=true indica che un nuovo request viene creato ogni volta che viene eseguito il criterio ServiceCallout. Ciò significa che la richiesta e il percorso dell'URI della richiesta non vengono mai riutilizzati. La seconda è la variabile predefinita servicecallout.request, è un nome riservato assegnato alla richiesta se non specifichi un nome.

È importante conoscere questo nome predefinito se utilizzi il mascheramento dei dati. Se ometti il nome della variabile, devi aggiungere servicecallout.request alla configurazione della maschera. Ad esempio: se volessi mascherare l'intestazione di autorizzazione in modo che non venga visualizzata nelle sessioni di Trace, alla configurazione di mascheramento si aggiunge quanto segue 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 di richiesta.

servicecallout.request Facoltativo
clearPayload

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

Imposta il metodo clearPayload su false solo se il messaggio di richiesta è obbligatorio dopo che il callout di servizio è eseguito.

true Facoltativo

&lt;Request&gt;/&lt;IgnoreUnresolvedVariables&gt; elemento

Se impostato su true, il criterio ignora eventuali errori relativi alle variabili non risolte presenti nella richiesta.

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

&lt;Response&gt; elemento

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

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

Se questo elemento viene omesso, il proxy API non attende una risposta; Flusso proxy API l'esecuzione continua con i passaggi successivi del flusso. Inoltre, per indicare l'ovvio, senza Response, la risposta dal target non è disponibile per l'elaborazione in base a passaggi successivi e il flusso proxy non rileva in alcun modo un errore nella chiamata remota. Un uso comune per omettere l'elemento Response quando si utilizza ServiceCallout: per registrare a un sistema esterno.

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

<Timeout> elemento

Il tempo in millisecondi durante il quale il criterio callout di servizio attende una risposta dal target. Non puoi impostare questo valore in modo dinamico in fase di runtime. Se il callout di servizio raggiunge un timeout, viene restituito un HTTP 500, il criterio ha esito negativo e il proxy API entra in uno stato di errore, descritta in Gestione degli errori.

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

&lt;HTTPTargetConnection&gt; elemento

Fornisce dettagli sul trasporto come URL, TLS/SSL e proprietà HTTP. Consulta le Riferimento alla configurazione di <TargetEndpoint>.

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

&lt;HTTPTargetConnection&gt;/&lt;URL&gt; elemento

L'URL del servizio chiamato:

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

Puoi fornire una parte dell'URL in modo dinamico con una variabile. Tuttavia, la parte del protocollo l'URL http:// riportato di seguito non può essere specificato da una variabile. Nel prossimo esempio, utilizzerai una variabile per specificare il valore di una 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, usa una sola 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

&lt;HTTPTargetConnection&gt;/&lt;SSLInfo&gt; elemento

La configurazione TLS/SSL al servizio di backend. Per informazioni sulla configurazione TLS/SSL, consulta Configurazione di TLS dal perimetro al backend (cloud e cloud privato) e alla configurazione dell'endpoint di destinazione 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

&lt;HTTPTargetConnection&gt;/&lt;Properties&gt; elemento

Proprietà di trasporto HTTP al servizio di backend. Per ulteriori informazioni, vedi 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

&lt;HTTPTargetConnection&gt;/&lt;LoadBalancer&gt; elemento

Chiama uno o più server di destinazione ed esegui il bilanciamento del carico sui server. Vedi il target di chiamata di esempio di server nella sezione Esempi. Vedi anche Bilanciamento del carico tra backend server web. Vedi anche questa community che illustra i modi per chiamare i server di destinazione sia dai criteri relativi ai callout di servizio sia usando le regole di route.

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

&lt;LocalTargetConnection&gt; elemento

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

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

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

&lt;LocalTargetConnection&gt;/&lt;APIProxy&gt; elemento

Il nome di un proxy API che è la destinazione di una chiamata locale. Il proxy deve essere nello stesso organizzazione e ambiente come proxy che effettua la chiamata.

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

Insieme all'elemento <APIProxy>, includi il parametro Elemento <ProxyEndpoint> per specificare il nome dell'endpoint proxy che deve essere scelto come target per la chiamata.

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

&lt;LocalTargetConnection&gt;/&lt;ProxyEndpoint&gt; elemento

Il nome dell'endpoint proxy che deve essere la destinazione delle chiamate. Questo è un endpoint proxy in il proxy API specificato con l'elemento <APIProxy>.

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

&lt;LocalTargetConnection&gt;/&lt;Path&gt; elemento

Un percorso dell'endpoint scelto come target. L'endpoint deve fare riferimento a un proxy nello stesso organizzazione e ambiente come proxy che effettua la chiamata.

Usa questa opzione al posto di una coppia <APIProxy>/<ProxyEndpoint> quando non conoscere (o non poter fare affidamento) sul nome del proxy. Il percorso potrebbe essere un obiettivo 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 a HTTP intestazioni, contenuti dei messaggi o contesto di Flow. Sono disponibili le seguenti variabili di flusso predefinite dopo l'esecuzione del criterio callout di servizio. Per ulteriori informazioni sulle variabili di flusso, consulta Riferimento per le variabili.

I callout di servizio hanno richieste e risposte proprie e puoi accedere a questi dati tramite come la codifica one-hot delle variabili categoriche. Poiché il messaggio principale utilizza request.* e response.*, utilizza i prefissi di variabile myrequest.* e calloutResponse.* (i valori predefiniti nella configurazione del callout di servizio) per ricevere i dati dei messaggi specifici del callout di servizio. Il primo esempio nella tabella seguente mostra come ottenere le intestazioni HTTP nel callout di servizio.

Variabile Descrizione

Di seguito è riportato un esempio di come ottenere le intestazioni delle richieste e delle risposte dei callout di servizio in modo simile alle intestazioni delle richieste e delle risposte principali.

calloutResponse.header.HeaderName

myRequest.header.HeaderName

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

calloutResponse.header.Content-Length

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

Ambito: dal callout di servizio in avanti
Tipo: stringa
Autorizzazione: lettura/scrittura

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

servicecallout.requesturi

Ambito: dall'inoltro della richiesta di callout del servizio
Tipo: stringa
Autorizzazione: lettura/scrittura

URI TargetEndpoint per un criterio ServiceCallout. L'URI è l'URL dell'endpoint di destinazione senza il protocollo e le specifiche del dominio.

servicecallout.{policy-name}.target.url

Ambito: dall'inoltro della richiesta di callout del servizio
Tipo: stringa
Autorizzazione: lettura/scrittura

L'URL di destinazione di un callout di servizio.

calloutResponse.content

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

Ambito: dalla risposta del callout del servizio in avanti
Tipo: stringa
Autorizzazione: lettura/scrittura

Il corpo della risposta del callout di servizio.

servicecallout.{policy-name}.expectedcn

Ambito: dall'inoltro della richiesta di callout del servizio
Tipo: stringa
Autorizzazione: lettura/scrittura

Il nome comune previsto del TargetEndpoint come definito in un ServiceCallout . Ciò è significativo solo quando TargetEndpoint fa riferimento a un protocollo TLS/SSL endpoint.

servicecallout.{policy-name}.failed

Ambito: dalla risposta del callout del servizio in avanti
Tipo: booleano
Autorizzazione: lettura/scrittura

Valore booleano che indica se il criterio ha avuto esito positivo, false o non riuscito, true.

Errori

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code HTTP status Cause Fix
steps.servicecallout.ExecutionFailed 500

This error can occur when:

  • the policy is asked to handle input that is malformed or otherwise invalid.
  • the backend target service returns an error status (by default, 4xx or 5xx).
steps.servicecallout.RequestVariableNotMessageType 500 The Request variable specified in the policy is not of type Message. For example, if it's a string or other non-message type, you'll see this error.
steps.servicecallout.RequestVariableNotRequestMessageType 500 The Request variable specified in the policy is not of type Request Message. For example, if it's a Response type, you'll see this error.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Error name Cause Fix
URLMissing The <URL> element inside <HTTPTargetConnection> is missing or empty.
ConnectionInfoMissing This error happens if the policy does not have an <HTTPTargetConnection> or <LocalTargetConnection> element.
InvalidTimeoutValue This error happens if the <Timeout> value is negative or zero.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

Variables Where Example
fault.name="fault_name" fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. fault.name = "RequestVariableNotMessageType"
servicecallout.policy_name.failed policy_name is the user-specified name of the policy that threw the fault. servicecallout.SC-GetUserData.failed = true

Example error response

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

Example fault rule

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

Argomenti correlati