Red Hat Bugzilla – Bug 871868
Improve Error message management.
Last modified: 2012-11-07 10:34:25 EST
Description of problem:
By default when an error occurs during the execution of an ESB service, an error message is created with the fault inside and the ID of the initial message. Then this newly created message is forwarded to the Dead Letter Service (if nothing else specified) for its treatment. The problem is that the incoming error message is no longer containing all the initial ESB message variables needed to analyze the reason of the error.
I know that we should be able to retrieve the initial message (using the stored ID) if we had previously called the "persist" action to store the message into the DB.
Am I right so far ?
If it is right, I have two problems with that behavior:
1 We should add a specific “persist” action before every action of the ESB action pipeline as it is not done automatically. Doing so will make the service a lot less readable and complicated to write and maintain.
2) We are not sure that we will have the latest variables values in the retrieved inital message body as some of them may have been modified during the action itself causing the exception. Due to that, the content of the initial message will be less relevant for the error analysis.
That is why for our need we have patched the Factory.java within the jbossesb-rosetta.jar to add the follwing line:
just before this original one:
--> errorMessage.getBody().add(Fault.THROWABLE_CONTENT, problem);
This will alow us to retrieve all the original message body for the error analysis.
Another use case where the current error message creation is causing issues:
We have a secured service defined.
When invoking the secured service without credentials, we receive the following exception:
org.jboss.soa.esb.services.security.SecurityServiceException: Service 'AuthServiceOk' has been configured for security but no AuthenticationRequest could be located in the Message Context. Cannot authenticate without an AuthenticationRequest.
This is fine. However our specified fault-to service is then invoked, but not with out original message.
How do we ensure when an authentication error occurs our original message is available to our fault-to service?
I do have the relates-to, but I no longer have the message instance. The client is remote, so cannot even get the client to persist and lookup using the relates-to message id.