As a user I want much improved documentation for Mule 3.1/3.2 on how to configure the default-exception-strategy element to achieve common use cases

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.3 M1
  • Component/s: Core: Exception Handling
  • Labels:
    None
  • User impact:
    Medium
  • Effort points:
    8
  • Similar Issues:
    None
  • Effort:
    M

Description

Acceptance Criteria

  • Each case is clearly defined, with examples of when you'd use each use case.
  • Each use case has a sample config which is explained in detail.
  • Each sample config is included in a test case in Mule source code (cross-referenced somehow)
  • Blog post(s) with similair content in more conversational form.

Use Case:

  • Route last state message before exception into exception strategy MPs and then to a DLQ
  • Route original message before exception into exception strategy MPs and then to a DLQ
  • Route by exception type
  • Preserve payload after exception strategy executes
  • Stop flow based on exception type
  • Rollback transaction and send a notification (email)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ramiro Rinaudo added a comment -

All scenarios defined and there tests cases.

Explanation on each already done. We need to review.

There are more examples created we need to include.

Integrate this/blog to documentation.

Show
Ramiro Rinaudo added a comment - All scenarios defined and there tests cases. Explanation on each already done. We need to review. There are more examples created we need to include. Integrate this/blog to documentation.
Hide
Permalink
Pablo La Greca added a comment -

Test cases for most common use cases implementation:

org.mule.test.integration.exceptions.ExceptionStrategyCommonScenariosTestCase

mule-ce-3.1.x : revision 23435
mule-ce-3.2.x : revision 23441
mule-ce-3.x: revision 23442

Show
Pablo La Greca added a comment - Test cases for most common use cases implementation: org.mule.test.integration.exceptions.ExceptionStrategyCommonScenariosTestCase mule-ce-3.1.x : revision 23435 mule-ce-3.2.x : revision 23441 mule-ce-3.x: revision 23442
Hide
Permalink
Pablo La Greca added a comment -

Norman,

Please review my changes in Mule documentation about error handling:

http://www.mulesoft.org/documentation/display/MULE3USER/Error+Handling
In this page I also need you to include the two diagrams that were part of Demystifying Mule Error Handling blog post

http://www.mulesoft.org/documentation/display/MULE3USER/Exception+Strategy+Most+Common+Use+Cases

Show
Pablo La Greca added a comment - Norman, Please review my changes in Mule documentation about error handling: http://www.mulesoft.org/documentation/display/MULE3USER/Error+Handling In this page I also need you to include the two diagrams that were part of Demystifying Mule Error Handling blog post http://www.mulesoft.org/documentation/display/MULE3USER/Exception+Strategy+Most+Common+Use+Cases
Hide
Permalink
Ramiro Rinaudo added a comment -

Reviewing the documentation for ES most common use cases I found the following.

  • Give more context of what each use case is trying to do, not just the exception part. For example: We will read a JMS message from Queue in, then add some text and then force it to fail, so the Exception strategy is called and sent to a DLQ. Otherwise you force the reader to understand what the whole XML is doing.
  • On the second example, you are missing the throwException="true" in the test component it seems. The same in the route message based on the exception type.
  • On the rollback transaction and send notification, instead of using your name, use a funny username, like mulejockey, and as host, use smtp.mycompany.com, to put all in the same line.
  • On the Stop flow, you need to let the reader know how they would start it again once the other service is back up.
  • On the implementing the custom ES, it would be great to give more context on when you actually want to do that. For maintaining the original payload you already explained how to do it in the other use case. It might be more meaningful to explain why you would go with that option, and which are the consequences. I would create a page just to explain how to implement your own exception strategy and why.
Show
Ramiro Rinaudo added a comment - Reviewing the documentation for ES most common use cases I found the following.
  • Give more context of what each use case is trying to do, not just the exception part. For example: We will read a JMS message from Queue in, then add some text and then force it to fail, so the Exception strategy is called and sent to a DLQ. Otherwise you force the reader to understand what the whole XML is doing.
  • On the second example, you are missing the throwException="true" in the test component it seems. The same in the route message based on the exception type.
  • On the rollback transaction and send notification, instead of using your name, use a funny username, like mulejockey, and as host, use smtp.mycompany.com, to put all in the same line.
  • On the Stop flow, you need to let the reader know how they would start it again once the other service is back up.
  • On the implementing the custom ES, it would be great to give more context on when you actually want to do that. For maintaining the original payload you already explained how to do it in the other use case. It might be more meaningful to explain why you would go with that option, and which are the consequences. I would create a page just to explain how to implement your own exception strategy and why.
Hide
Permalink
Pablo La Greca added a comment -

Ramiro, I change blogs post according your comments.

I agree that a new blog post explaining custom exception strategy implementation is needed but I think it would be best to put it as part of the effort to fix custom exception strategy implementation in Mule 3.2

Show
Pablo La Greca added a comment - Ramiro, I change blogs post according your comments. I agree that a new blog post explaining custom exception strategy implementation is needed but I think it would be best to put it as part of the effort to fix custom exception strategy implementation in Mule 3.2

People

Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: