Introduction
Last week, I came across a scenario where I had to call the card verification service before updating the credit/debit card status. This was the first time I was consuming a Web Service in an orchestration, so I had a little trouble in the beginning. Very innocently, I made request and response messages of the schema types which I got from the WSDL, made a request-response port, and deployed the project. I configured the port to use the SOAP adapter, and gave the URI of the Web Service. I tested my orchestration and was expecting the results, but got an exception in the system Event Log:
"Failed to load "" type.
Please verify the fully-qualified type name is valid. Details: "".
The type must derive from System.Web.Services.Protocols.SoapHttpClientProtocol.
The type must have the attribute System.Web.Services.WebServiceBindingAttribute".
The solution
After a little search on the Internet, I found out that I have to add the web reference of the Web Service and configure web ports and web messages, and cannot call the Web Service in this manner. However, I succeeded to consume the Web Service, but I had to consume the Web Service without adding the web references. Because, I figured out if the schemas change in the future (which was most likely too), then I would have to update the web references, recompile and redeploy the project.
Adding the web reference in my project, I got the following items which will be used by BizTalk to consume the Web Service:
- Universal Resource locator (URI)
- WSDL which contains the methods, ports, and message type information of the Web Service.
- Reference map (which will contain XSDs).
BizTalk will then use the web port types and web messages from the web reference generated items. It will capture web ports from the WSDL and web messages from the reference.xsds generated.
The trick is if we can generate these items for BizTalk, we can surely call the Web Service without using a web reference. The workaround for this is generating the proxy class from wsdl.exe. You can generate the proxy class from the Visual Studio command prompt, and giving the proper switches will create the proxy class.
You can see the MSDN help for more switches of WSDL.
wsdl /out:[dir]proxy.cs http://localhost/[webservice URI].asmx?wsdl
After generating the proxy class, you can add the proxy class to a .NET Library project, give it a strong name key file, build the project. (Don’t forget to GAC the generated assembly before deploying the BizTalk project).
Technically, the SOAP.MethodName and SOAP.AssemblyName properties are promoted to the context of the message before being published to the message box, and these values are supplied automatically when we use a web port (which come from the web reference). We can supply the AssemblyName and MethodName from the proxy class we created. After it is GAC’d, we can configure the send port of the orchestration and supply the AssemblyName and MethodName properties for the message context. After the BizTalk Project is deployed, we can configure the send port calling the Web Service. In the Web Service tab, select the assembly which was created before by building the .NET library project containing the proxy class. Select the type name and method name, and in the General tab, specify the Web Service URI.
In this way, you can have more control over the proxy and handle its versioning, and a little change in the Web Service won't make you build deploy the project again.
