AssignMessage vs RaiseFault in FaultRule

Not applicable

In both AssignMessage and RaiseFault policies we can generate the custom Error message for a Fault condition ,in FaultRule.Then,what is unique about the RaiseFault policy which is mentioned as the variation of Assignmessage?

Solved Solved
1 4 512
1 ACCEPTED SOLUTION

Dear @RadhamaniRamadoss ,

Assign Message is used to change or set a message payload. Most often, this is the request or response being handled by the proxy, but it could also be a message being sent via a ServiceCallout.

RaiseFault puts the execution state of the proxy into error flow. We can say this policy "triggers a fault". It is like the "throw" statement in many programming languages. When the proxy execution transfers to error flow, further processing of policies is interrupted. All remaining processing Steps (policies) are bypassed, and control transfers to the FaultRules (think of these as exception handlers), if there are any. After the FaultRules execute, the fault response is returned directly to the requesting app. RaiseFault has the side effect of Assigning a (response) message payload and status and headers.

RaiseFault is normally not used within a FaultRule. If you want to *modify* the response message from within a FaultRule, you can do that using the Assign Message policy. You CAN use RaiseFault within a FaultRule, but it interrupts the fault processing, and for that reason is probably undesirable.

Normally, RaiseFault is used from within the proxy flow as a policy, often wrapped by a Condition; it raises a fault & the message flow will be taken into error flow.

You cannot cause proxy execution to transfer into error flow using the AssignMessage Policy. (AssignMessage policy cannot be used to trigger a fault). You need to use RaiseFault for that.

  • 1662-screen-shot-2015-12-15-at-50505-pm.png

View solution in original post

4 REPLIES 4

Dear @RadhamaniRamadoss ,

Assign Message is used to change or set a message payload. Most often, this is the request or response being handled by the proxy, but it could also be a message being sent via a ServiceCallout.

RaiseFault puts the execution state of the proxy into error flow. We can say this policy "triggers a fault". It is like the "throw" statement in many programming languages. When the proxy execution transfers to error flow, further processing of policies is interrupted. All remaining processing Steps (policies) are bypassed, and control transfers to the FaultRules (think of these as exception handlers), if there are any. After the FaultRules execute, the fault response is returned directly to the requesting app. RaiseFault has the side effect of Assigning a (response) message payload and status and headers.

RaiseFault is normally not used within a FaultRule. If you want to *modify* the response message from within a FaultRule, you can do that using the Assign Message policy. You CAN use RaiseFault within a FaultRule, but it interrupts the fault processing, and for that reason is probably undesirable.

Normally, RaiseFault is used from within the proxy flow as a policy, often wrapped by a Condition; it raises a fault & the message flow will be taken into error flow.

You cannot cause proxy execution to transfer into error flow using the AssignMessage Policy. (AssignMessage policy cannot be used to trigger a fault). You need to use RaiseFault for that.

  • 1662-screen-shot-2015-12-15-at-50505-pm.png

sgilson
Participant V

One addition: usually fault rules do not not themselves include the Raise Fault policy unless you want to raise another fault for some reason as part of handling the fault.

However, 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

Here's the link to the doc on fault handling.

Thanks @Anil Sagar and @sgilson