Service Callout: Could not access headers when the service fails

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 

 

0 1 139
1 REPLY 1

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.