Screencast: Using AssignMessage to determine the fault.name to test within FaultRule

[dchiesa1]

Hi everyone

Today I want to give you a tip on how to use an AssignMessage policy, coupled with the Apigee Trace capability, to determine the fault.name you can test for, in a FaultRule element.

As you may know, the FaultRule is a way to customize the error message and response that gets sent back to a client , when Apigee emits a fault while handling an API request. Apigee can "raise a fault" when executing any policy, for various reasons:

• the client app passed invalid data
• the policy that is executing references an unresolvable (unset) variable
• some other configuration or runtime inconsistency

An example of the client passing invalid data: perhaps the API Proxy is a token-dispensing proxy, and the client passed in invalid client credentials when requesting a token. That causes Apigee to generate a fault.

When Apigee raises a fault, Apigee also sets a "default" message that it returns to the requesting client. The API Proxy designer can override that fault message, and FaultRules are the way to do it. Read all about FaultRules here.

Of course, Apigee might generate a variety of different faults in different conditions. The way to have a different error message for each particular fault , is to apply a Condition to the fault rule. By convention the Condition tests the variable "fault.name". It looks like this

   <FaultRules>
     <FaultRule name='invalid-client'>
      <Step>
        <Name>AM-InvalidClient</Name>
      </Step>

      <Condition>fault.name = "InvalidClientIdentifier"</Condition>
    </FaultRule>
    ....

The key question is, how can an API Proxy designer know which fault.name to test for ?

Easy: just examine the fault.name context variable. A good way to do that is with Apigee trace.

In this short screencast video, I show you the technique I use to determine which fault.name to test in the Condition on a FaultRule.

The key is to use a simple AssignMessage policy that sets a variable to the value contained within fault.name. This causes an event to be emitted to the trace session, which allows you to visualize which fault.name value applies to which fault situation.

I hope this helps!

See attached for the API Proxy I used to illustrate this tech tip. apiproxy-checkfault.zip

For a more thorough treatment of how to structure fault handling, see Ozan's article.

LMK if questions.