Monday, November 29, 2010
Integrating Biztalk with Mobile CE device
One of my recent projects involved developing Biztalk services to be consumed by Windows CE mobile devices. I got a chance to work with compact Microsoft framework. In an ideal world, one would expose Biztalk as WCF service and use advanced feature set to integrate the services with the mobile client using compact framework. There is a whole set of compact power tools with own svc generating utility that matches svcutil.exe of .net framework world. Compact framework svcutil may work well with pure WCF kind of services (not tested though) but it will not work with Biztalk services that are exposed as WCF using WCF publishing wizard. It seems there is a bug in the svc util tool for compact framework and the only other option is to consume exposed WCF as a webservice from the client side. This can be done by simply using Add Web Reference option in the mobile client project. Doing this will generate requisite client side proxy objects to talk with the exposed Biztalk service. Service side is to be exposed as WCF with basic-http binding to be consumed as a web service from mobile client. There is one caveat to this approach though. While using a SSL at transport level, it was observed that the client could not pass the request to the service hosted inside the corporate domain from a client situated on WAN (internet). Everything would work fine for calls made within the LAN though. The key difference between LAN and WAN scenarios was the use of reverse proxy ISA. Client requests would have to be routed through ISA for WAN scenarios whereas in LAN scenario ISA will be automatically by passed. This issue could be circumvented by exposing Biztalk as ASMX service (instead of WCF) and using SOAP adapter. Apparently, the security information that is carried over from client through ISA to Biztalk is carried in the envelope part of the SOAP message over the wire. It is possible that the way this security information is formatted in a service exposed as WCF v/s the one exposed as ASMX service is different. That could possibly explain why the client call will work in WAN scenario for ASMX type service and not work for WCF type service.