Is there a system variable that indicates any of the FaultRule conditions succeeded?

Not applicable

To DRY up my fault handling code, I have factored the common error processing code into the DefaultFaultRule with a conditional test to assign a generic error if no other error has been assigned. So in each AssignMessage policy that assigns a fault response, I include:

    <AssignVariable>
        <Name>wf.fault_assigned</Name>
        <Value>true</Value>
    </AssignVariable>

So if any fault condition is true and the AssignMessage executes, the flag is set true. Then in the DefaultFaultRule I do this:

    <DefaultFaultRule name="default_fault_rule">
        <Step>
            <Name>calculate_error_values</Name>
        </Step>
        <Step>
            <Name>calculate_response_headers</Name>
        </Step>
        <Step>
            <Name>fault_generic_error</Name>
            <Condition>(wf.fault_assigned != "true")</Condition>
        </Step>
        <AlwaysEnforce>true</AlwaysEnforce>
    </DefaultFaultRule>

So if no fault response has yet been assigned, then the generic fault message is assigned. I'm wondering if there is a system variable that performs essentially the same operation so I can eliminate this repeating code in every fault AssignMessage policy. It seems it would be needed to know whether to execute the DefaultFaultRule or not (when AlwaysEnforce is not true).

Note that this value is also useful when reaching the PostClientFlow to be able to select logging policies, thus:

    <PostClientFlow name="PostClientFlow">
        <Request/>
        <Response>
            <Step>
                <Name>log_to_papertrail</Name>
                <Condition>(wf.fault_assigned != "true")</Condition>
            </Step>
            <Step>
                <Name>log_errors_to_papertrail</Name>
                <Condition>(wf.fault_assigned = "true")</Condition>
            </Step>
        </Response>
    </PostClientFlow>
1 7 528
7 REPLIES 7

Not applicable

points for the approach? maybe make this a best practices doc?

Not applicable

Hello @George Shaw,

I think, you can try something like this:

<AssignMessage name="Assign.FaultName"> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>

<AssignVariable>

<Name>FAULTNAME</Name>

<Ref>fault.name</Ref>

<Value>"There is an error"</Value>

</AssignVariable>

<AssignVariable>

<Name>EXCEPTIONNAME</Name>

<Ref>exceptionName</Ref>

<Value>"There is an exception"</Value>

</AssignVariable>

<AssignVariable>

<Name>STATUSCODE</Name>

<Ref>errorCode</Ref>

<Value>400</Value>

</AssignVariable> </AssignMessage>

In the above example, I am using the flow variables fault.name, exceptionName and errorCode to be set based on the error raised. And then I can use these parameters in Raise Fault Policy. Perhaps, I can have a common Raise Fault Policy.

In case you are raising any error from JS, you need to specifically use "throw {your JS error}" and then catch it at the error flow.

Hope that helps.!

Thanks, but my code currently works fine so I'm not sure what your suggestion addresses. What I'm trying to avoid is setting a user-created state variable in every fault policy when a suitable system state variable likely already exists.

Good to know how to create an error from JS as I've wondered about that. Thanks.

Hello @George Shaw, I meant, fault.name, exceptionName and errorCode are the system parameters, which should be populated when the errors occur. These are the "suitable system state variable likely already exists"

I see, but I believe that these will always have a value when in the error flow. I need a system state variable that has a defined value to indicate that a one of the fault rules condition has evaluated to true.

Well. I would do a check on fault.name to check if it is null. If it is not null, then I would consider that an error has occured.

Thanks, but because the test is in the DefaultFaultRule, then the proxy is in the error flow and there will always be a value in fault.name. If it is not a fault that has matched a condition, it will still have the name of the unhandled fault. That is actually what the proxy reports in the fault_generic_error policy that is executed above.