By: Erik van der Starre, Solution Architect, Microsoft Based Solutions

One of the drawbacks of a web based solution: it can be a hassle when you need to access local devices. And will SaaS make this even more difficult? Not with Dynamics CRM Online and Silverlight!

Running your xRM application in the cloud using Microsoft Dynamics CRM Online has many advantages, but what if you need to connect a local device, like a RFID reader or a photo scanner, that is connected using the USB port of a local machine. For a client we needed to connect a scanning device and a weight scale, and read measurements from device. The results were to be presented on the screen graphically and were to be stored in the Dynamics CRM database.

The solution we chose was to use Silverlight. A Silverlight can be hosted as a customization in Dynamics CRM and has a rich user experience. But more important: it’s running locally on the client machine. Because it’s running locally it’s already close to the USB port and to the device. But, Silverlight is running in a sandbox which does not allow you to use all the .NET Framework features and it sure doesn’t allow you the use COM.

What it can do is use web services. So what we did is to create a web service that wraps the code to access the device. That ran beautifully, on the development machine. But, as often, it stopped working once we uploaded the Silverlight control to Dynamics CRM Online. This we found strange, because we had a cross domain policy file in place on the hosted service. If you place a Silverlight control within a form that resides on Dynamics CRM Online, then the control runs on the local machine as part of the Dynamics CRM Online domain. So if you do a web service call, you do a call from the Dynamics CRM Online domain to your local domain. Calling from one domain to another domain is called cross‑domain communication. When calling a cross-domain service, Silverlight will check for the existence of clientaccesspolicy.xml first.  This mechanism provides a pretty flexible way to define from which domain calls are allowed to be made to the service. In the clientaccesspolicy.xml file we allowed all access, and it still didn’t work. Once we discovered using Fiddler that there was no communication at all, we understood that the Silverlight runtime blocked the call (raising a rather generic security exception). Then we found out that we were doing cross‑zone communication. MSDN has an article on this, “URL Access Restrictions in Silverlight”, which states: “Internet Explorer defines the concept of security zones with a security level assigned to each zone. Four zones are defined: Internet, Local intranet, Trusted sites, and Restricted sites. In addition, the local machine is also considered to be another zone. A Silverlight application downloaded from a web server in one security zone tries to access resources on a target server in a different security zone. Cross-zone access restrictions are designed to prevent a Silverlight application downloaded from a server in the Internet zone from accessing resources in the more trusted zones. This prevents a Silverlight application run from a remote internet server from getting access to resources on the local intranet and other resources. Cross-zone access is blocked even if a security policy file on the target server would allow the resource to be accessed.” Putting Microsoft Dynamics CRM Online domain in the Local intranet zone did the trick.

Communication with the scanning device is a request-response type of communication. This was very straight forward. On a button press of the user the service is called and the measurement takes place. The results are presented to the user and stored in Dynamics CRM through the REST Endpoint.

The weight scale required another approach since this device has a continuous flow of measurements. For this a duplex channel can be used. The Silverlight SDK includes the System.ServiceModel.PollingDuplex.dll assembly, which can just do that. It’s perfect to create publish and subscribe style of communication.