Tallan's Technology Blog

Tallan's Top Technologists Share Their Thoughts on Today's Technology Challenges

ESB Exception Encoder: Value cannot be null

Dan Field

I was working on a message flow that involved routing the response from a Request-Response send port directly to another send port. The ultimate send port had failed message routing turned on so that messages would get properly routed by the ESB ToolKit to the EsbExceptionDb for further analysis or processing. In this particular case, the send port was an SFTP port with a misconfigured username/password combination, which would result in failed messages. However, when the message failed I’d get the following exception in the EventLog:

Value cannot be null.
 Parameter name: guid 
Source: Microsoft.Practices.ESB.ExceptionHandling.PipelineComponents.ProcessFault
Method: Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext, Microsoft.BizTalk.Message.Interop.IBaseMessage)
Error Source: Microsoft.Practices.ESB.ExceptionHandling
Error TargetSite: System.String GetApplication(ServiceType, System.String, System.String, System.String, System.String)
Error StackTrace: at Microsoft.Practices.ESB.ExceptionHandling.Utility.GetApplication(ServiceType serviceType, String mgmtDBServer, String mgmtDBName, String guid, String serviceName)
 at Microsoft.Practices.ESB.ExceptionHandling.PipelineComponents.ProcessFault.WriteHeaderFailedMessageRouting(XmlTextWriter writer, IBaseMessage pInMsg, Object& portName)
 at Microsoft.Practices.ESB.ExceptionHandling.PipelineComponents.ProcessFault.WriteHeader(XmlTextWriter writer, XmlTextReader reader, FaultSource faultSource, IBaseMessage pInMsg, Object& portName)
 at Microsoft.Practices.ESB.ExceptionHandling.PipelineComponents.ProcessFault.Execute(IPipelineContext pContext, IBaseMessage pInMsg)

I found another MSDN user going through the same problem, and his findings suggested that the problem was somehow related to BTS.ReceivePortID not being in the message context in this messaging scenario (the request-response port put the SendPort name into the BTS.ReceivePortName property, did not write or promote the ReceivePortID). The ESB ToolKit was trying to run some logic that uses this property, and throwing an exception when trying to pass a null value to that function.

An initial attempt to promote ReceivePortID as an empty GUID got rid of the exception, but the ESB Portal had no information in the application field for that message (the application lookup logic failed). Further inspection of the code the ESB Encoder component uses indicated that it tried to use the SendPortName on the error report (it seems like this is a faulty piece of code in the toolkit), but then would also check the “WasSolicitResponse” property. By nulling out WasSolicitResponse from the context, I was able to get the message to process correctly.


const string _sysProps = "http://schemas.microsoft.com/BizTalk/2003/system-properties";

pInMsg.Context.Write("WasSolicitResponse", _sysProps, null);

This results in removing WasSolicitResponse from the message context, and allows the ESB ToolKit to properly process the message through to the EsbExceptionDb. Ideally, this should be done on the ultimate send port (in my case, the SFTP send port) to avoid interfering with any Orchestration processing that may have to be done on this message (an Orchestration might use this property to implement correlation). However, this avoids the need to create a copy of the message or add an orchestration in for special handling (but additional overhead!).

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>