[3.3][CORE] Route Message Through Different Exception Paths (MULE-5894)

[Pablo La Greca]

Hi,

As part of 3.3 M2 we are working on improving exception strategy.

The following wiki page explains this new feature behavior and how configuration will look like:

[http://www.mulesoft.org/documentation/display/MULECDEV/Route+Message+Through+Different+Exception+Paths]

We need feedback from every user mostly around how this new behavior should be configured but any kind of feedback or comments will be appreciated.

Thanks, Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Franco Gasperino]

Not much of a response, but "i like it".

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Franco,

Even if it's not a comment, suggestion or whatever it makes us realize that this feature is useful :)

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Emiliano Lesende]

Can we include examples on how this would work with other evaluators that are not exception-type?

This is were I'm coming from. Imagine Salesforce connector, let say that we do a call there and then we have a SOAPFault in return.

The SOAPFault will not go into the payload but rather the exceptionPayload in the MuleMessage. SOAPFaults are all of the same type, but their content differs from fault to fault. So I want to do a catch-exception-strategy based on the content of the exception rather than the exception-type. The bean evaluator would not work in this situation since bean only works with the payload of the message and not the exceptionPayload.

What I'm looking for is how can I route the exception based on the content of the exception.

Em

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Em,

This is great feedback. Acceptance criteria for this story includes review current expression evaluators to make it easier to use expressions to route to different exception strategies.

Currently the only way to do that is using groovy as expressions evaluator since you have access to the message + the power of groovy you can do whatever you want with message.exceptionPayload. Also you can use OGNL.

Still, doing greater changes to expression evaluators is not part of this story but it's being addressed by Dan for this milestone.

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

I can't figure out how a global exception strategy [1] can be configured using conditionals. We should use wrapper element to be able to define it as a global exception strategy:

<route-exception-strategy name="reusableExceptionStrategy">
<catch-exception-strategy expression=".."/>
<rollback-exception-strategy expression=".."/>
</route-exception-strategy>

Expression attribute will only be allowed inside <route-exception-strategy>.

[1] http://www.mulesoft.org/documentation/display/MULECDEV/Error+Handling+Reuse

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Daniel Feist]

Agree, it seems this wrapper element is required, although the use of expression would reduce 3 levels to 2. That the way we'd talked about implementing it also.

We the expression attribute also be possible to configure on globally defined ES's? What about the global default, it doesn't really make sense there TBH.

Dan

Post by Pablo La Greca
<route-exception-strategy name="reusableExceptionStrategy">
<catch-exception-strategy expression=".."/>
<rollback-exception-strategy expression=".."/>
</route-exception-strategy>
Expression attribute will only be allowed inside <route-exception-strategy>.
[1] http://www.mulesoft.org/documentation/display/MULECDEV/Error+Handling+Reuse
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Dan,

Yes, it doesn't make sense. If you configure a default exception strategy with an expressions mule will fail at startup with a pretty description of the problem.

I need ideas for the wrapper element. So far we have:

* <switch-exception-strategy>
* <route-exception-strategy>
* <choice-exception-strategy>

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Daniel Feist]

<composite-exception-strategy/> ?

From what I understand this pattern choices the first match and uses that, and ignores the others, is that right?

What if I want to use this pattern to choice between two options based on exception type, but I'd like to log or send an email etc. in both cases?

e.g.

<compoisite-exception-strategy>
<on expression="">
<on expression=""/>
<otherwise/>
<always/>
</composite-exception-strategy>

Post by Pablo La Greca
Dan,
Yes, it doesn't make sense. If you configure a default exception strategy with an expressions mule will fail at startup with a pretty description of the problem.
* <switch-exception-strategy>
* <route-exception-strategy>
* <choice-exception-strategy>
Pablo.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Dan,

Otherwise doesn't make much sense since there's a default exception strategy configured and that one will be used in case that none of the configured exception strategies expressions matches.

I prefer to keep it simple. In case there's functionality that can be reused inside an exception strategy then a subflow with such configuration can be created and then use a <flow-ref> within each exception strategy.

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Daniel Feist]

Agree, just wondered if you'd planned anything for this either as part of this story or another.

Dan

Post by Pablo La Greca
Dan,
Otherwise doesn't make much sense since there's a default exception strategy configured and that one will be used in case that none of the configured exception strategies expressions matches.
I prefer to keep it simple. In case there's functionality that can be reused inside an exception strategy then a subflow with such configuration can be created and then use a <flow-ref> within each exception strategy.
Pablo.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Franco Gasperino]

Pablo - Since you appear to be point on the exception handling improvements, I would be glad to provide you more in-depth examples of how (at least one of) your EE customers are using what's available + customizations. Hit me up via direct email. This topic is of great interest to us.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Hi Franco,

It would be great if you can provide us information about your use cases. The idea for Mule 3.3 is to revamp exception strategy and make it very easy to use for most common use cases.

This page [1] contains documentation about all the things we are doing for error handling

I will contact you by email.

Thanks, Pablo.

[1] http://www.mulesoft.org/documentation/display/MULECDEV/Error+Handling

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email