ServiceCallout policy

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

What

The Service Callout policy lets you call to another service from your API proxy flow. You can make callouts to either an external service (such as an external RESTful service endpoint) or internal services (such as an API proxy in the same organization and environment).

• In an external use case, you make a callout to a third-party API that's external to your proxy. The response from the third-party API is parsed and inserted in your API's response message, enriching and "mashing up" the data for app end users. You can also make a request using the Service Callout policy in the request flow, then pass the information in the response to the TargetEndpoint of the API proxy.
• In another use case, you call a proxy that's in the same organization and environment as the one you're calling from. For example, you might find this useful when you have a proxy that offers some discrete low-level functionality that one or more other proxies will consume. For example, a proxy that exposes create/read/update/delete operations with a backend data store could be the target proxy for multiple other proxies that expose the data to clients.

The policy supports requests over HTTP and HTTPS.

Samples

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

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

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

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

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

About the Service Callout policy

There are many scenarios where you can use a Service Callout policy in your API proxy. For example, you can configure an API proxy to make calls to an external service to deliver geolocation data, customer reviews, items from a partner’s retail catalog, and so on.

A callout is typically used with two other policies: Assign Message and Extract Variables.

• Request: Assign Message populates the request message sent to the remote service.

• Response: Extract Variables parses the response and extracts specific content.

The typical Service Callout policy composition involves:

1. Assign Message policy: Creates a request message, populates HTTP headers, query parameters, sets the HTTP verb, etc.
2. Service Callout policy: References a message created by the Assign Message policy, defines a target URL for the external call, and defines a name for the response object that the target service returns.
   
   For improved performance, you can also cache Service Callout responses, as described in this Apigee Community thread: https://community.apigee.com/questions/34110/how-can-i-store-the-results-of-the-servicecallout.html.
3. Extract Variables policy: Typically defines a JSONPath or XPath expression that parses the message generated by the Service Callout. The policy then sets variables containing the values parsed from the Service Callout response.

See Using policy composition for a complete sample API proxy that uses the Service Callout policy along with the Assign Message and Extract Variables policies.

Custom error handling

Element reference

Following are elements and attributes you can configure on this policy:

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

<ServiceCallout> attributes

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

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

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

<Request> element

Specifies the variable containing the request message that gets sent from the API proxy to the other service. The variable can be created by a previous policy in the flow, or you can create it inline in the Service Callout policy.

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

The syntax for the <Remove>, <Copy>, <Add>, and <Set> tags is the same as for the Assign Message policy.

The policy returns an error if the request message cannot be resolved or is of an invalid request message type.

In the simplest example, you pass a variable containing the request message that was populated earlier in the flow of the API proxy:

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

Or you can populate the request message sent to the external service in the Service Callout policy itself:

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

Attributes

<Request>/<IgnoreUnresolvedVariables> element

When set to true, the policy ignores any unresolved variable error in the request.

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

<Response> element

Include this element when the API proxy logic requires the response from the remote call for further processing.

When this element is present, it specifies the name of the variable that will contain the response message received from the external service. The response from the target is assigned to the variable only when the entire response is read successfully by the policy. If the remote call fails for any reason, the policy returns an error.

If this element is omitted, the API proxy does not wait for a response; API Proxy flow execution continues with any subsequent flow steps. Also, to state the obvious, with no Response element, the response from the target is not available for processing by subsequent steps, and there is no way for the proxy flow to detect a failure in the remote call. A common use for omitting the Response element when using ServiceCallout: to log messages to an external system.

 <Response>calloutResponse</Response> 

<Timeout> element

The time in milliseconds that the Service Callout policy will wait for a response from the target. You cannot set this value dynamically at runtime. If the Service Callout hits a timeout, an HTTP 500 is returned, the policy fails, and the API proxy goes into an error state, as described in Handling faults.

<Timeout>30000</Timeout>

<HTTPTargetConnection> element

Provides transport details such as URL, TLS/SSL, and HTTP properties. See the <TargetEndpoint> configuration reference.

<HTTPTargetConnection>
    <URL>http://example.com</URL>
    <LoadBalancer/>
    <SSLInfo/>
    <Properties/>
</HTTPTargetConnection>

<HTTPTargetConnection>/<URL> element

The URL to the service being called:

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

You can supply part of the URL dynamically with a variable. However, the protocol portion of the URL, http:// below, cannot be specified by a variable. In the next example, you use a variable to specify the value of a query parameter:

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

Or, set a portion of the URL path with a variable:

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

If you want to use a variable to specify the domain and port of the URL, then use one variable for the domain and port only, and a second variable for any other part of the URL:

<URL>http://{request.dom_port}/{request.resourcePath}</URL>

<HTTPTargetConnection>/<SSLInfo> element

The TLS/SSL configuration to the backend service. For help on TLS/SSL configuration, see Configuring TLS from Edge to the backend (Cloud and Private Cloud) and "TLS/SSL TargetEndpoint Configuration" in API proxy configuration reference.

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

HTTP transport properties to the backend service. For more information, see Endpoint properties reference.

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

<HTTPTargetConnection>/<LoadBalancer> element

Call one or more target servers and do load balancing on them. See the Call target servers sample in the Samples section. See also Load balancing across backend servers. See also this community post that discusses ways to call target servers from both the Service Callout policy and using Route Rules.

<HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection>

<LocalTargetConnection> element

Specifies a local proxy -- that is, a proxy in the same organization and environment -- as the target of service callouts.

To further specify the target, use either the <APIProxy> and <ProxyEndpoint> elements, or the <Path> element.

<LocalTargetConnection>
   <APIProxy/>
   <ProxyEndpoint/>
   <Path/>
</LocalTargetConnection>

<LocalTargetConnection>/<APIProxy> element

The name of an API proxy that is the target of a local call. The proxy must be in the same organization and environment as the proxy making the call.

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

Along with the <APIProxy> element, include the <ProxyEndpoint> element to specify the name of the proxy endpoint that should be targeted for the call.

<LocalTargetConnection>
   <APIProxy/>
   <ProxyEndpoint/>
</LocalTargetConnection> 

<LocalTargetConnection>/<ProxyEndpoint> element

The name of the proxy endpoint that should be the target of calls. This is a proxy endpoint in the API proxy specified with the <APIProxy> element.

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

<LocalTargetConnection>/<Path> element

A path to the endpoint that is being targeted. The endpoint must refer to a proxy in the same organization and environment as the proxy making the call.

Use this instead of a <APIProxy>/<ProxyEndpoint> pair when you don't know -- or can't rely on -- the proxy name. The path might be a reliable target.

<LocalTargetConnection>
   <Path>/data-manager</Path>
</LocalTargetConnection>

Schemas

Flow variables

Flow variables enable dynamic behavior of policies and Flows at runtime, based on HTTP headers, message content, or Flow context. The following predefined Flow variables are available after a Service Callout policy executes. For more information about Flow variables, see Variables reference.

Service Callouts have their own request and response, and you can access that data through variables. Because the main message is using the request.* and response.* variable prefixes, use the myrequest.* and calloutResponse.* prefixes (the defaults in the Service Callout configuration) to get message data specific to the Service Callout. The first example in the following table shows how you'd get HTTP headers in the Service Callout.

Errors

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.

Deployment errors

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

Fault variables

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

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>

Related topics

• Generate or modify messages: Assign Message policy
• Extract variables: Extract Variables policy
• Variables: Variables reference
• TLS/SSL configuration
  • Configuring TLS from Edge to the backend (Cloud and Private Cloud)
  • "TLS/SSL TargetEndpoint Configuration" in API proxy configuration reference
• HTTP transport properties: Endpoint properties reference
• Alternative to Service Callout: HTTPClient written in JavaScript, see JavaScript object model