Amidst all of the work right now there does not seem to be too much time to blog. Actually I've started about three other posts but I haven't had time to complete them yet. As if things aren't busy enough, I'm currently in the chorus of the musical Oklahoma!. I wanted to sit this musical out as I had been in a musical over the summer since 2001 and I was ready to let one pass me by. However I was eventually "roped" in and find myself performing yet again.
We are using BizTalk in our current project as the Integration platform and another developer is implementing the BizTalk work. We are using another vendor to supply a web application and web services however they are not using .NET but rather Python. Now I like Python even though I don't get to use it enough, so that doesn't bother me too much. They recently delivered the web services and they are using HTTP Basic Authentication except if you don't supply the credentials on the initial try, you are redirected to a custom login page. By default, the web requests in .NET do not send basic authentication and one can argue whether it should or not. Since basic authentication is inherently insecure (unless over SSL or other encryption) it is not a bad idea to first query the web service to find out what type of authentication is needed before sending insecure credentials. On the other hand, it would be nice to have the ability to say, "I really know what I am doing -- send the credentials!" (I thought that was what .PreAuthenticate was supposed to do but apparently it is doing something more complex.) The vender was able find an override function for GetWebRequest that works for regular .NET applications, so I took the WSDL files and turned it into a web service assembly. I used the wsdl.exe utility to manually create the web service stubs and performed minor modifications to the files. Specifically, 1) added a namespace, 2) removed the partial keyword for the main class (so you can specify the class.Url and other properties), and 3) added the override GetWebRequest function.
At this point I created a Test UI to exercise the web services and everything worked great. Incidentally, the Fiddler2 HTTP debugging utility is great and can definitely help out with web service issues. Unfortunately, things weren't as smooth with the BizTalk development and we were at an impasse. As ridiculous as it seems, I ended up creating a wrapper or proxy web service in C# that called the Python web service. I am a big proponent of efficiency so this definitely bothers me but we are under a tight deadline and BizTalk could not communicate with the vendor's web services. Using the web service assembly, I simply repackaged the exact method and parameters and called the vendor's web service:
[WebMethod]
public TransmitResult insertData(DataPacket[] data)
{
using (VendorWebService ws = new VendorWebService())
{
ws.PreAuthenticate = true;
ws.Credentials = new System.Net.NetworkCredential(ConfigUtility.Username, ConfigUtility.Password);
return ws.insertData(data);
}
}
Hopefully the vendor will be able to resolve the issue quickly and we can get rid of the web service proxy but at least we can continue in the meantime.