How to access request.content within Fault Rule?

[Ian22]

From the documentation and in the forum I understood that request.content should be available even if Apigee enters an error state (i.e. it should be accessible from within a Fault Rule), but when I try to access it, I get nothing back. I am able however to access request.path and request.verb.

Here's the scenario I have in my application, which is an interaction between two systems (and consequently two proxies). Let's call them A and B:

1. The Proxy A will receive a request and try to allocate a resource in System A.
2. If successful, in the response part of Proxy A it will do a service callout (SC) to the Proxy B.
3. Proxy B will send the request to System B to then operate on the resource.
4. If Proxy B fails for any reason, I have a Fault Rule that sends the request back to System A (with a different path suffix) to deallocate the resource

There is a single message that contains the details required for allocation & deallocation of the resource in System A, and operation on the resource by System B. So I want to just send request.content in my SC payload, but when in the debug interface I see the request.content as empty.

I asked Gemini about this, and it told me the request.content would not be available if it's been altered by another flow/step before the error takes place, but I don't think that is the case in my proxy.

So my questions are:

• Should the request.content indeed be available in the error state?
• If yes, what could be happening in my proxy that prevent this from being the case?

[Ian22]

I'll describe here how I got around this issue. There might be unforeseen consequences to this approach, so this is not a recommendation for people with similar issues, and I'd be happy to get feedback:

• I added this in the Proxy B's target xml:
        <Properties>
              <Property name="success.codes">1xx,2xx,3xx,4xx,5xx</Property>
        </Properties>
  As a consequence the proxy does not enter into the error state when the response from the target system is an error;
• Immediately afterwards, I use a JS policy to check if the response was in the 200's range, and otherwise I throw an error passing the original request as part of the details;
• I then use the original request details in the error message inside the SC.

Proxy B is still considered as failed after this, which I think is appropriate in my case. But since the fallback was triggered I can also envision changing this via an AM policy to return something in the 200's.

[AlexET]

Hey @Ian22, thank you for sharing your solution and contributing to the community, we appreciate it!

If anyone has additional feedback or alternative solutions, please feel free to share.