Another issue we ran into while upgrading a client’s BizTalk 2004 solution to BizTalk 2006 R2 is related to exposing an orchestration as a web service. Our client has a website that calls a web service exposed orchestration. The website sends to BizTalk the information filled out on a “Sign Up” page by a potential new customer, and BizTalk maps and forwards the info to our customer’s internal CRM system.
This web service call was working in BizTalk 2004, but once we deployed the BizTalk 2006 version of the same orchestration, the following error was thrown by the web service:
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.Services.Protocols.SoapHeaderHandling.SetHeaderMembers(SoapHeaderCollection headers, Object target, SoapHeaderMapping[] mappings, SoapHeaderDirection direction, Boolean client)
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
The error stack continues to include the web service’s operation and the application’s Page_Load method. The null reference exception is an error that we all love isn’t it? It explains so much!
Anyways, during our investigation my friend and co-worker Mark realised that the operation description between the BizTalk 2004 and the BizTalk 2006 versions of the web service were different for some fields. All of the fields with enumeration had the correct enumeration in 2004 but show up as bytes in 2006.
So, say this is the URL for the operation:
http://localhost/MyTestProject_Proxy/MyTestOrchestration_MyTestPort.asmx?op=MyTestServiceOperation
In 2006 the SOAP sample shown was, for example (notice the NewCustomer field):
But in 2004 the SOAP sample has the correct enumeration:
And that happened to all the enumerated fields on the schema exposed by the orchestration. We had to fix this, even if it doesn’t end up fixing the null reference error. I knew I’d seen how to change this behaviour somewhere before… But where? Well, google gave me the answer. My own blog! I had run into this while writing this article on how to test an orchestration with WCF.
This behaviour is caused by a change on the way the web services wizard generates a class from the schema exposed by the orchestration. Try using xsd.exe to generate a class from the same schema in .NET 1.1 and .NET 2.0 and you will see that all enumerated fields in .NET 2.0 have an XML type attribute with AnonymousType set to true.
This generated class created by the BizTalk 2006 web services wizard sits on the App_Code folder under the root of the web service, and the file is called DataTypes.cs.
So, in my example, the code generated for the NewCustomer enumeration inside DataTypes.cs was:
[System.CodeDom.Compiler.GeneratedCodeAttribute(“xsd”, “2.0.50727.42”)]
[System.SerializableAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace=http://BizTalk)]
public enum MyTestMessageHeaderNewCustomer {
/// <remarks/> Y,
/// <remarks/> N,
}
Once we removed AnonymousType=true from all the enumerations inside DataTypes.cs the SOAP sample started showing the correct enumeration values and the website call worked. Phhew!
Yossi Dahan explains here in more detail what that attribute does to the WSDL.
Note (!!!): Don’t use namespaces like http://BizTalk or web service operation default namespace like http://tempuri.org/ in real implementations! Bad bad bad.
