Service Callout: Could not access headers when the service fails

Google Cloud Apigee
1

I am trying to call a proxy using service callout from my shared flow. The Shared flow is attached to the Pre-Proxy Flowhook. When the proxy throws an error, It sets a unique header in the response. I am not able to access that header in the Post proxy flow hook. I made sure I am accessing it the right way.

Is it because of the scope?

@alexkhimich @dchiesa1 @sidd-harth

2

If you have a ServiceCallout, within a SharedFlow, which is attached to the pre-proxy flowhook…

And that servicecallout is configured to call a proxy.

..Then

the first thing that will happen when the proxy gets invoked, is to execute the pre-proxy flowhook…

which will execute the servicecallout to call the proxy…

which sounds like an infinite loop to me. That’s bad. Don’t do that.

But maybe that is not your problem. Maybe the proxy you are calling is not in the same environment, so it does not get covered by the pre-proxy flowhook like the originating proxy. Or maybe you have some other kind of logic to avoid the infinite loop.

In that case I think all the detail about SharedFlows and pre-proxy flowhooks and so on… is irrelevant to the obstacle you are facing. The relevant fact is , you are unable to access the response headers when a request sent via ServiceCallout receives an error response (like a 4xx or 5xx response). Is that about right?

Can you test that narrow scenario? Remove all the other stuff, and just test a proxy with a ServiceCallout that calls an endpoint that returns a 400? Do you face the same problem there?

If so, then , I suspect what is happening is that when the ServiceCallout receives a 4xx or 5xx response, the policy is treating that as a flow error, and is entering fault state. That means the proxy that hosts the ServiceCallout will return a fault. Flow is interrupted from that point, and enters fault state. Read more about that in the documentation.

If you do not wish your proxy to enter faultstate when a ServiceCallout receives a 4xx or 5xx, then use the success.codes property. Like this:

<ServiceCallout name='SC-1'>
  <Request clearPayload="false">...</Request>
  <Response>scResponse</Response>
  <HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
      <IgnoreValidationErrors>true</IgnoreValidationErrors>
      <TrustStore>mytruststore</TrustStore>
    </SSLInfo>
    <Properties>
      <Property name='success.codes'>2xx, 4xx, 5xx</Property>
    </Properties>
    <URL>https://my-example-target.com</URL>
  </HTTPTargetConnection>
</ServiceCallout>

If you do this then a 4xx or 5xx return status code will not cause the flow to enter fault. You will be able to see the full response of the servicecallout policy.