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