if a fault is handled by a local fault rule - will default fault policy still be called?

[#1]

According to the documentation (here I go again...):

"A default fault rule acts an exception handler for any error that is not explicitly handled by another fault rule."

(http://apigee.com/docs/api-services/content/fault-handling)

To me this means that if I have another fault rule that DOES handle an exception - that the default rule will not be called. what is the truth?

[#2 · Accepted solution]

Default Fault Rule is intended to be the catch all and should only execute if no other Fault Handler ran.

There are some intricacies to invoking FaultRules, including the Default. I see customers occasionally note that Fault rules are not running at all - this typically comes down to the continueOnError flag on a particular policy being set to true. In other cases, customers may have modified the default success codes on a target call by setting properties in the target definition such as:

<Property name="success.codes">1xx,2xx,3xx,400</Property>

With this configuration a 400 error will not be treated by Apigee as a fault and the flow will continue to run.

If you are seeing both fault rules and the default rule run - you might want to check if your fault rule is also raising a fault. That is the only scenario where I can see both being run.

[#3]

"if you are seeing both fault rules and the default rule run - you might want to check if your fault rule is also raising a fault. That is the only scenario where I can see both being run."

^^ this might also be an ingenious suggestion on how we can make centralized events happen in faults though @David Allen. In fact - im considering this as a way to allow DEFAULT fault behavior in our platform.

I would tell developers something like this:

"If you want our default policies to trigger on error -this includes logging, (and a bunch of other stuff) - make sure to raise fault as the last step in any of your own custom fault rules"

Not sure if this is a good idea in light of any Apigee roadmap decisions - but it sure seems like a good way to solve the problem im trying to.

[#4]

I like the way you think! A simple RaiseFault at the end of a Fault Rule could then trigger the Default rules allowing you encapsulate all that processing in one spot.

Note Flowfragments which are part of the proxy dependency maven plugin can give you a similar facility - essentially injecting the policy steps that comprise your common reusable code into a single line at deploy time.

[#5]

ive considered trying to make everyone use Maven - but the challenge is that we have so many different groups doing things that in the end they use the UI most of the time.

[sgilson]

Hi David,

I don't think a RaiseFault in a fault rule triggers the Default Fault Rule. According to the doc:

"If a fault rule other than the default fault rule invokes a Raise Fault policy, the default fault rule does not execute, even if the <AlwaysEnforce> element in the <DefaultFaultRule> tag is true."

Stephen

[sgilson]

The more I think about this, the more it makes sense. It prevents you from accidentally creating an infinite loop caused when the Default Fault Rule contains a RaiseFault policy. If <AlwaysEnforce> was true for the Default Fault Rule, a RaiseFault policy in the Default Fault Rule would trigger the Default Fault Rule over and over again.

[#8]

Right - but this now means that to force flow through a policy on fault - one has to manually put that policy in every place that you have an active fault policy right? So effectively - you get granular control at the expense of ease of management/policy enforcement. in a way this is kind of a disaster for my team - so we need some clear answer on how this works.

[sgilson]

I'm not sure of your scenario, but as long as <AlwaysEnforce> it set to true on the Default Fault Rule, it always executes after all other fault rules except for the one case where you invoke RaiseFault from a fault rule.

[#10]

Okay. Ill give this a try. Ill build a default fault rule w/ always enforce.

[nmunro]

I think this comment from @sgilson is correct: "If a fault rule other than the default fault rule invokes a Raise Fault policy, the default fault rule does not execute, even if the <AlwaysEnforce> element in the <DefaultFaultRule> tag is true."

This is used in the pattern described here an-error-handling-pattern-for-apigee-proxies

@Benjamin Goldman In terms of your needs, you could ask teams to follow this pattern and have your centralized, default error handling in the default fault rule.

We're using this pattern - we set the continueOnError flag to true for policies that we want to fall into this error handling.

As a simplified example

....
<Step>
	<Name>VerifyAPIKey</Name>
</Step>
<Step>
	<Name>AssignMessage.ErrorType.InvalidApiKey</Name>
	<Condition>verifyapikey.VerifyAPIKey.failed="true"</Condition>
</Step>
<Step>
	<Name>RaiseFault.GoToFaultRules</Name>
	<Condition>custom.error.type != NULL</Condition>
</Step>
...

In the above example,

• VerifyAPIKey has continueOnError set to true.
• AssignMessage.ErrorType.InvalidApiKey simply sets a value on the custom.error.type variable (e.g. invalid_key)
• RaiseFault.GoToFaultRules doesn't have any settings. Its purpose is to trigger the fault rules

From that point the pattern described in an-error-handling-pattern-for-apigee-proxies takes effect where a fault rule would have a condition

<Condition>custom.error.type = "invalid_key"</Condition>

The policy in the fault rule with the condition above, sets variables (via an AssignMessage policy, not a RaiseFault) and then as per the pattern you fall into the DefaultFaultRule where you can do any centralized tasks such as logging, or formatting of payloads, status codes and so on.

This way many teams don't have to have custom RaiseFault policies. They'd have the setting of a variable that determines which fault rule to execute coupled with a generic, (essentially) empty RasieFault.GoToFaultRules.

You could then not only keep the DefaultFaultRule centralized but also, if you wished, the specific FaultRules.

On top of this we do have a "Common API" set of flow fragments but we have a remote team about to start that is going to make this difficult - no maven and possibly not the same SCM.

The drawback to this pattern is that there is potential for an explosion in the number of policies and I find that the readability of the endpoint is reduced.

[nmunro]

Just noticed this was posted a year ago - sorry! I'm sure it appeared on the first page when I logged in...