{ Community }
  • Academy
  • Docs
  • Developers
  • Resources
    • Community Articles
    • Apigee on GitHub
    • Code Samples
    • Videos & eBooks
    • Accelerator Methodology
  • Support
  • Ask a Question
  • Spaces
    • Product Announcements
    • General
    • Edge/API Management
    • Developer Portal (Drupal-based)
    • Developer Portal (Integrated)
    • API Design
    • APIM on Istio
    • Extensions
    • Business of APIs
    • Academy/Certification
    • Adapter for Envoy
    • Analytics
    • Events
    • Hybrid
    • Integration (AWS, PCF, Etc.)
    • Microgateway
    • Monetization
    • Private Cloud Deployment
    • 日本語コミュニティ
    • Insights
    • IoT Apigee Link
    • BaaS/Usergrid
    • BaaS Transition/Migration
    • Apigee-127
    • New Customers
    • Topics
    • Questions
    • Articles
    • Ideas
    • Leaderboard
    • Badges
  • Log in
  • Sign up

Get answers, ideas, and support from the Apigee Community

  • Home /
  • Edge/API Management /
avatar image
1
Question by Edward · Jun 23, 2016 at 08:26 AM · 2.9k Views fault handlingfaultrulesfault

Policy Fault Handling

I can't seem to find anything in the Apigee documentation about the "fault" variable which gets populated when a policy raises a fault (eg. Access Token expired). There are several references to "fault.name" which will give you the generic name of the policy that caused the fault (eg. RaiseFault) but you can't specifically catch which policy raised the error.

Up until now I have resorted to workarounds - usually a combination of fault.name and reading status codes but now I need to return a different error depending on the exact cause of a policy failure. Conveniently, this exact cause is well documented under policy Error Code sections. Unfortunately, I can't extract this error code without first entering one of the fault rules and calling an Extract Variables or Javascript policy - not ideal as I want to be able to execute a fault rule depending on the error code.

Setting "continueOnError" to true doesn't seem to set any specific flow variables or error codes (just an XXX.failed) so I can't extract the error prior to entering Error flow.

Is there a solution for this? Some sort of undocumented "fault.errorcode" variable?

Comment
Add comment Show 4
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Sunandita Dam   · Jun 24, 2016 at 05:03 AM 0
Link

@Edward Unable to understand issue here. The fault.name variable contains the value of the code field of the error code. You then use the fault.name variable in the <Condition> tag and attach appropriate policy. What do you mean by "There are several references to "fault.name" which will give you the generic name of the policy that caused the fault"

avatar image Edward Sunandita Dam   · Jun 24, 2016 at 05:25 AM 0
Link

You're right...I must've been overthinking things. As a follow up question though, is there any way to find out the exact name of the policy that raised the error?

avatar image Sunandita Dam Edward   · Jun 24, 2016 at 06:28 AM 0
Link

@Edward I don't think its supported out of the box. Someone should confirm. Why do you need to know policy name as well? How will it help?

Show more comments

Close

3 Answers

  • Sort: 
avatar image
1

Answer by davissean   · Aug 03, 2016 at 11:04 AM

@Kurt Kanaskie @Edward

Error handling shouldn't be this hard. Check out this post for a really clean pattern for error handling: https://community.apigee.com/articles/23724/an-error-handling-pattern-for-apigee-proxies.html

I have used it on four or five projects, and it really makes it easier to define your error types, content and presentation.

Comment
Add comment Show 1 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Kurt Googler Kanaskie ♦ · Aug 03, 2016 at 11:59 AM 0
Link

Hi @Edward, I use that pattern as well, I was just pointing out a means by which you can differentiate among a fault.name (e.g. RaiseFault) to set specific variables via the AssignMessage.

avatar image
0

Answer by Kurt Googler Kanaskie · Jul 28, 2016 at 03:01 PM

@Edward Glad I'm not the only one struggling to come up with a clean and manageable solution to this, I would like to differentiate among multiple JavaScript, ServiceCallout, and conditional RaiseFaults policies.

I discovered a pattern that works by checking for the explicit "policy-name" that failed. I haven't tested it for all policy types nor do I have a comprehensive list of the "policy-type" values. Perhaps that should be added to the Error Code Reference page.

User an "outer" condition to catch the "fault.name" and then use an "inner" condition to differentiate by checking for the "policy-name".faile = true.

{policy-type}.{policy-name}.failed = true

For RaiseFault differentiation, you can check

raisefault.{policy-name}.failed

Then in your FaultRules section use this outer condition and inner conditions:

<FaultRule name="raise-faults">
    <Condition>(fault.name = "RaiseFault")</Condition>
    <Step>
        <Condition>(raisefault.RF-missing-required-params.failed = true)</Condition>
        <Name>AM-missing-required-params</Name>
    </Step>
    <Step>
        <Condition>(raisefault.RF-invalid-hmac.failed = true)</Condition>
        <Name>AM-invalid-hmac</Name>
    </Step>
    <Step>
        <Condition>(raisefault.RF-path-suffix-not-found.failed = true)</Condition>
        <Name>AM-resource-not-found</Name>
    </Step>
</FaultRule>

For JavaScript differentiation, you can check

javascript.{policy-name}.failed

Then in your FaultRules section use this outer condition and inner conditions:

<FaultRule name="script-error">
    <Condition>(fault.name = "ScriptExecutionFailed")</Condition>
    <Step>
        <Condition>(javascript.JS-verify-hmac.failed = true)</Condition>
        <Name>AM-Set-Script-Execution-Error-Variables</Name>
    </Step>
    <Step>
        <Condition>(javascript.JS-log.failed = true)</Condition>
        <Name>AM-Set-Script-Execution-Error-Variables</Name>
    </Step>
</FaultRule>

For ServiceCallout differentiation, you can use:

servicecallout.{policy-name}.failed

Then in your FaultRules section use this outer condition and inner conditions:

<FaultRule name="service-callout-error">
    <Condition>(fault.name = "ExecutionFailed")</Condition>
    <Step>
        <Condition>(servicecallout.SC-Get-OAuth-Token.failed = true)</Condition>
        <Name>AM-Set-SC-Execution-Get-OAuth-Variables</Name>
     </Step>
     <Step>
        <Condition>(servicecallout.SC-Get-Refresh-Token.failed = true)</Condition>
        <Name>AM-Set-SC-Execution-Get-Refresh-Variables</Name>
     </Step>
</FaultRule>


The problem with this approach is how to catch remaining "policy-type" errors that don't match the inner conditions. A Step with no condition will always execute and checking the opposite conditions is combersome. See below for a more managable approach.

Comment
Add comment · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image
0

Answer by Kurt Googler Kanaskie · Aug 01, 2016 at 12:36 PM

The problem with the above approach, is that once the outer condition matches, no other fault rules "outer" conditions will be matched and it is cumbersome to determine the unmatched condition.

So, rather than use and outer condition to match the fault type and an inner condition to match the specific, using a FaultRule with only outer conditions provides easier management of un-matched conditions, as would be the case if you forgot to add a specific condition.

Consider the following approach:

    <!-- RAISE FAULTS SECTION -->
    <FaultRule name="Raise-fault-not-specific">
	<!-- DEFAULT or UNMATCHED RASIE FAULT -->
        <Condition>(fault.name = "RaiseFault")</Condition>
        <Step>
            <Name>AM-default-raise-fault</Name>
        </Step>
    </FaultRule>

    <FaultRule name="Raise-fault-required-params">
        <Condition>(fault.name = "RaiseFault") and (raisefault.RF-missing-required-params.failed = true)</Condition>
        <Step>
            <Name>AM-missing-required-params</Name>
        </Step>
    </FaultRule>

    <FaultRule name="Raise-fault-invalid-hmac">
        <Condition>(fault.name = "RaiseFault") and (raisefault.RF-invalid-hmac.failed = true)</Condition>
        <Step>
            <Name>AM-invalid-hmac</Name>
        </Step>
    </FaultRule>

    <FaultRule name="Raise-fault-suffix-not-found">
        <Condition>(fault.name = "RaiseFault") and (raisefault.RF-path-suffix-not-found.failed = true)</Condition>
        <Step>
            <Name>AM-resource-not-found</Name>
        </Step>
    </FaultRule>

This allows you to differentiate among all RaiseFaults and to catch any unmatched specific RaiseFault conditions using the "AM-default-raise-fault" at the top, which also demonstrates that FaultRule conditions are evaluated from bottom-to-top."

The use of Assign Message in the steps is to set variables for subsequent use in the DefaultFaultRule as described here: https://community.apigee.com/content/kbentry/23724/an-error-handling-pattern-for-apigee-proxies.html

Comment
Add comment Show 2 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Kurt Googler Kanaskie ♦ · Aug 03, 2016 at 10:54 AM 0
Link

Just to clarify, fault rules in the proxy endpoint are evaluated bottom-to-top BUT, fault rules in the target endpoint are evaluated top-to-bottom AND the *first* one that matches is executed.

See this dicussion: https://community.apigee.com/questions/27639/fault-rule-conditional-policies-failing-to-execute.html#answer-29458

avatar image soujanyaedunuri · Aug 17, 2017 at 08:17 PM 0
Link

@Kurt Kanaskie In the first approach you provided, if we define first step without inner condition, would it not assign generic response message and subsequent step could overwrite if the error matches the inner condition of the step as below?

<FaultRulename="service-callout-error">
<Condition>(fault.name = "ExecutionFailed")</Condition>
	<Step>
		<Name>AM-Set-Generic-Variables </Name>
	</Step>
	<Step>
		<Condition>(servicecallout.SC-Get-OAuth-Toke			n.failed = true)</Condition>
		<Name>AM-Set-SC-Execution-Get-OAuth-Variables		</Name>
	</Step>
	<Step>
		<Condition>(servicecallout.SC-Get-Refresh-Tok		en.failed = true)</Condition>
		<Name>AM-Set-SC-Execution-Get-Refresh-Variabl		es</Name>
	</Step>
</FaultRule>

Follow this Question

Answers Answers and Comments

39 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

Fault handling for OAuth proxy for UnSupportedGrantType 1 Answer

Default Fault Rule not working 2 Answers

Can we use faultrules tag in policies ? 2 Answers

Node JS - Raise exception 2 Answers

Executing different step in shared flow depending on where the shared flow is getting called Target EndPoint or Proxy end point 1 Answer

  • Products
    • Edge - APIs
    • Insights - Big Data
    • Plans
  • Developers
    • Overview
    • Documentation
  • Resources
    • Overview
    • Blog
    • Apigee Institute
    • Academy
    • Documentation
  • Company
    • Overview
    • Press
    • Customers
    • Partners
    • Team
    • Events
    • Careers
    • Contact Us
  • Support
    • Support Overview
    • Documentation
    • Status
    • Edge Support Portal
    • Privacy Policy
    • Terms & Conditions
© 2021 Apigee Corp. All rights reserved. - Apigee Community Terms of Use - Powered by AnswerHub
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Create an article
  • Post an idea
  • Spaces
  • Product Announcements
  • General
  • Edge/API Management
  • Developer Portal (Drupal-based)
  • Developer Portal (Integrated)
  • API Design
  • APIM on Istio
  • Extensions
  • Business of APIs
  • Academy/Certification
  • Adapter for Envoy
  • Analytics
  • Events
  • Hybrid
  • Integration (AWS, PCF, Etc.)
  • Microgateway
  • Monetization
  • Private Cloud Deployment
  • 日本語コミュニティ
  • Insights
  • IoT Apigee Link
  • BaaS/Usergrid
  • BaaS Transition/Migration
  • Apigee-127
  • New Customers
  • Explore
  • Topics
  • Questions
  • Articles
  • Ideas
  • Badges