Microsoft Developer Network >
Forums Home
>
BizTalk Server Forums
>
BizTalk ESB Toolkit
>
Problems with ESB Fault Handling
Problems with ESB Fault Handling
- I am testing out the ESB fault handling process and I am encountering some very basic issues. I took a simple scenario - an itinerary that receives a message via WCF & then routes via a dynamic ESB send port using WCF transport, the routing information being specified via a business rule. In the receiving WCF application I deliberately throw an exception. These are the issues I see:
a) Unable to deteremine error reason due to error message truncation
In the the ESB portal I find the error but the fault description & exception is truncated to 4096 characters. WCF generates very long exception messages so all I see is a message beginning "System.ServiceModel.FaultException ....". The ESB Portal doesn't even try to display the full 4096 characters, in fact I don't quite understand what it is displaying - it certainly does not look the same as the fault exception message found in the EsbExceptionDb. In the database I see:
System.ServiceModel.FaultException: <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><s:Header><a:Action s:mustUnderstand="1" u:Id="_2">http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher/fault</a:Action> ... etc
Whilst the ESB portal shows:
System.ServiceModel.FaultException: http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher/faulturn:uuid:021231b7-c5d1-441c-be45-b714fe8cf8182009-11-05T09:57:25.755Z2009-11-05T10:02:25.755Z024HALTMLJLHbupEDkpp5HwzA==WWZrr07Cx529SgpdjMdjhQ
which would be totally useless to any operator trying to determine the error. What is the ESB Portal doing? Is it having a problem because the full error is not being logged?
Buried in the WCF fault message is the actual error in the "<Body><Fault>..." - the ESB should be picking that up since inside it is the actual error message from the faulting target application.
b) Incorrect Service Name and Fault Generator
I have an itinerary with an orchestration service. The orchestration is sending a message to WCF using a dynamic port. If the receiving WCF service faults the ESB logs the error (with all the issues noted above) but "Service Name" and "Fault Generator" are being set to values from earlier in the itinerary and not the current service and port.
c) Message Retries
On a static send or send/receive port BizTalk normally defaults to performing 3 retries before failing the message, but with a dynamic send or send/receive an error is being generated immediately. How do we specify message retry and retry interval for ESB dynamic ports?
d) Message Content Type Set to "text/plain"
The ESB is capturing the failed message but it is setting the content type to "text/plain" within the EsbExceptionDb, yet BizTalk clearly shows these messages as being text/xml. The ESB Portal then subsequently does not allow you to resubmit the message since it will only submit text/xml messages back to the WCF OnRamp.
The ESB Fault handling is one of the things Microsoft says is a significant bonus of the ESB toolkit, but this catalogue of problems with the error handling starts to make it rather unusable.
Answers
- I have come up with work arounds for 3 of the problems:
a) Unable to deteremine error reason due to error message truncation
I changed the columns of the tables Fault and ContextProperty in EsbExceptionDb from varchar(4096) to varchar(max). I also changed the parameters in the SP's usp_insert_ContextProperty and usp_insert_Fault from varchar(4096) to varchar(max). Now I get the complete text of the error.
c) Message Retries
I created a custom pipeline to solve this. See my thread: http://social.msdn.microsoft.com/Forums/en-US/biztalkesb/thread/2b38c1bc-20bb-4476-ba7a-31adf21558e8.
d) Message Content Type Set to "text/plain"
See my response in this thread: http://social.msdn.microsoft.com/Forums/en-US/biztalkesb/thread/01259ab0-54e0-4186-8bb3-46c041fb7fc0.- Marked As Answer byMikeGBUK Friday, November 13, 2009 6:11 PM
All Replies
- Ah i found your post about the EX portal.
And i guess here is your poblem with the ESB toolkit as well...
I guess that send failure would be pretty easy to catch inside an orchestration witha a classic set up static send port...... And then you could do whatever you want with it. So what is the added value of using the ESB here ? (with this anser referring to my other post wich you have read).
Well0549 - Yes you are right about static port versus ESB dynamic ports. To send a message using within a Orchestration using the ESB you send it to the message box and from there it gets routed to the send port by the ESB filters. If the ESB port dynamic send fails you don't get an exception raised in the orchestration fault handler since the orchestration has long gone - it terminated after sending the message to the message box. So we can't catch these errors within the orchestration and notify somebody about it.
The only hope is some stand-alone fault handling process, but that means a generic fault handler having to handle all the different business messages, rather than each process handling the error according to the business rules for that process.- Proposed As Answer byAndrew_ZhuMSFT, ModeratorTuesday, November 10, 2009 2:45 AM
- imho the ESB Toolkt creates more problems then it solves.
Well0549 - I have come up with work arounds for 3 of the problems:
a) Unable to deteremine error reason due to error message truncation
I changed the columns of the tables Fault and ContextProperty in EsbExceptionDb from varchar(4096) to varchar(max). I also changed the parameters in the SP's usp_insert_ContextProperty and usp_insert_Fault from varchar(4096) to varchar(max). Now I get the complete text of the error.
c) Message Retries
I created a custom pipeline to solve this. See my thread: http://social.msdn.microsoft.com/Forums/en-US/biztalkesb/thread/2b38c1bc-20bb-4476-ba7a-31adf21558e8.
d) Message Content Type Set to "text/plain"
See my response in this thread: http://social.msdn.microsoft.com/Forums/en-US/biztalkesb/thread/01259ab0-54e0-4186-8bb3-46c041fb7fc0.- Marked As Answer byMikeGBUK Friday, November 13, 2009 6:11 PM
