Solved: Having problems with error handling multiple scena... - Page 2

Char-K · 10-02-2023 04:58 AM

Hello

Need help with my proxy.

My Proxy Endpoint Flow have different error handling ---> this is the main idea of what I want it to be. Currently, the happy path works, the only problem is the error scenarios for this api. I am having problems routing the error base on the error thrown from the backend or when the policies entered "error state" when I explicitly added the conditions to route them base on conditions. Hope someone can help. @dchiesa1

Also, I posted this same thing but was deleted, not sure why.

dchiesa1

Wow that's a lot of configuration.

First let's talk about the XML. If I were you I would make some changes there:

handle CORS with the new-ish (it's at least 2 years old now) CORS policy. That way you don't need a check for OPTIONS scattered throughout your proxy. screencast.
convert your API Proxy to have specific Flows for all valid verb + path pairs, and have a "catch-all" flow with NO condition that returns a 404 Not Found.
Allow errors (for example in MessageValidation) to bubble to FaultRules, and handle things there.
use a Test driven development approach

For #2, an example of what I mean:

  <Flows>
    <Flow name='flow1'>
      <Request>
      </Request>
      <Response>
      </Response>
      <Condition>proxy.pathsuffix MatchesPath "/po" and request.verb = "GET"</Condition>
    </Flow>

    <Flow name='flow2'>
      <Request>
      </Request>
      <Response>
      </Response>
      <Condition>proxy.pathsuffix MatchesPath "/po/request" and request.verb = "POST"</Condition>
    </Flow>
   <!-- as many flows as you like here -->
    <Flow name='unknown request'>
      <!-- anything that did not match above, gets caught here -->
      <Request>
        <Step><Name>RF-404-Unknown-Request</Name></Step>
      </Request>
      <Response>
      </Response>
    </Flow>

  </Flows>

If, for specific verb+path pairs you want to validate the inbound headers or XML, then, you can do that with steps in the request flow. Like so:

    <Flow name='flow2'>
      <Request>
        <Step>
          <Name>RF-415-Unsupported-Media-Type</Name>
          <Condition>request.header.content-type != "text/xml"</Condition>
        </Step>
        <Step>
          <Name>MV-Payload-Schema</Name>
          <!-- The above MessageValidation step THROWS A FAULT if it fails -->
        </Step>
      </Request>
      <Response>
      </Response>
      <Condition>proxy.pathsuffix MatchesPath "/po/request" and request.verb = "POST"</Condition>
    </Flow>

Then, handle faults in the FaultRules, rather than in the Request flow for a particular flow. Keep the logic in the faultrules as simple as possible. It looks like you have LOTS of error handling logic in JavaScript. That looks unwieldy and ... gosh... inappropriate. Are you sure you need all of that? Not the ideal use of the Apigee Javascript policy. You COULD do error formatting there, but it's probably not the right tool for the job. If I were the Apigee architect on this project, I would want to see that JS eliminated and replaced with AssignMessage policies attached to FaultRules.

Last thing - I would add some apickli tests to your error so you can check the happy and error paths. An example is here. Doing it this way, you can use this workflow:

add a single test,
run it and observe that it fails
implement the APIproxy and appropriate FaultRules to allow the test to succeed
run all tests to make sure there have been no regressions. If any are found, correct them.
if there are more scenarios, return to step 1

Good luck!

View solution in original post

Having problems with error handling multiple scenarios