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. 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 the 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. ".
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 of the web service (which was most likely too) then I had 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 xsd's).
![web_reference]( "web_reference")
BizTalk will then use 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.xsd's generated.
The trick is if we can generate these items for BizTalk we can surely call the web service without using web reference. The work around for this is generating the proxy class from wsdl.exe. You can generate the proxy class from 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 web port (which come from the web reference). We can supply the AsemblyName and MethodName from the proxy class we created. After its 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.
![proxy_port]( "proxy_port")
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.