UPDATE (14MAR2013): Uploaded a modified sample which addresses storing credentials in secure config and adds comments around how to encrypt those credentials. While I show a synchronous plugin in the demo for simplicity of the walkthrough, you should always evaluate whether your plugin logic can fire asynchronously if the action doesn’t require that the user see the result of the action immediately after the record is saved. Calling an external system from a synchronous plugin can have negative side effects for both user experience and tight coupling with the external system. When you absolutely must use a synchronous plugin, make sure your code is short lived and try to put your azure web role in a data center as close to your CRM Online data center as possible to minimize network latency. You should also weigh the pros / cons of using this approach over the inherent Azure Service Bust capabilities Dynamics CRM provides which I talk about in my Integrating with systems behind a firewall from CRM Online using Windows Azure Service Bus Relay post. While the context of my post is talking to systems behind a firewall, you can also use Azure Service Bus as a mechanism to integrate with a web service running in Windows Azure. As of the CRM Online December 2012 Service Update and Update Rollup 12, Dynamics CRM includes new support for Windows Azure persistent queues, use of the updated Windows Azure portal to configure ACS, and synchronous plug-in support for posting to the service bus.
“I need to execute some code from a plugin which requires full trust. CRM Online doesn’t give me the ability to run full trust code so I want to put my full trust code behind a web service running in a Windows Azure Web Role. However, every approach I attempt to use to authenticate from the plugin to the web service fails due to sandbox issues.”
While I thought I covered this in my Design for Online post, I learned that my assumptions were incorrect. I was under then impression that the approach I mention explained in the SharePoint Online and Windows Azure: Developing Secure BCS Connections using WCF Services post which uses UserNamePasswordValidator class would work in CRM Online. I swear I had it working at one point. That’s what they all say:). I recently tried it again and discovered that the client code (the code running in the plugin) required full trust. I couldn’t figure out a way to get this working in full trust. I still don’t know why this requires full trust and my attempts at finding an explanation internally at Microsoft came up short. If someone else has gotten this approach to work, then I would love to know what I am missing.
Anyway, I had originally been going down a SOAP based approach. I actually had a sample working from a sandboxed plugin using custom SOAP headers similar to what’s described here. If you are adamant about wanting to use SOAP, then take a look. If there’s sufficient comments asking for a SOAP based example, then I will try to find the time to write a post about it. However, what I realized after I got it all working was that the aforementioned approach is complex and hard to follow. I saw this as an opportunity to take advantage of the ASP.NET Web API. I think you’ll find the ASP.NET Web API approach more optimal for this scenario because:
- We want as efficient communication as possible between CRM Online and the Windows Azure web role. REST+JSON is the most efficient way I know.
- ASP.NET Web API makes it really easy to use JSON as the serialization format.
- It’s pretty easy to implement basic authentication for ASP.NET Web API based services.
- Basic authentication can be used from a sandbox plugin
Before watching this walkthrough, make sure you go through or at least understand the following ASP.NET Web API walkthroughs:
Watch the following video once you’ve gotten up to speed using ASP.NET Web API:
The video won’t make much sense if you don’t spend the time understanding ASP.NET Web API. The code sample I show in the video is available here: