Using CRM from an external website – part 3: Stage one “Web API”

Ya mas! It has been over two weeks since I posted the last article in this series. As I mentioned before it is hard to stay focused while enjoying the summer ans spending holidays with your family on a beach in Greece.


My ultimate goal is to integrate Dynamics CRM in an external website. This website is running on non Microsoft technology (read HTML 5, javascript, jquery). To reach that goal, I go through a couple of stages (it helps me to get the correct mindset). The stages I’m going through are the following:

  • Stage one: Web API
  • Stage two: client side scripting
  • Stage three: Authentication
  • Stage four: external website

Web API scenario

For most .NET programmers, Web API is quite easy to master. Often this is the scenario I prefer. The drawback is that you have to run a website on Microsoft infrastructure (Internet Information Server). Running on a recent version of the Microsoft.Net framework. An alternative is running the Web API scenario in a Mono environment that can be hosted on a linux platform.

Without having to rely on the MVC framework and way of working (in my eyes a complex and bloated framework), we can use one simple aspect from the framework called the Web API controller. The Web API controller will allow us to use simple REST calls to call our functionality. These REST calls can be made from the web page, by using a simple javascript call. I am able to call server side functionality, exposed by the Web API Controller (instead of having to rely on SOAP calls).

The Web API controller can handle the authentication and connection to Dynamics CRM. Using the Dynamics CRM object model.


The beauty of this scenario, is that you can use the WEB API controller, to provide an abstraction layer. In this absctraction layer you iron out all technical details in relation to CRM. A design pattern that crosses my mind directly is the façade pattern.

In this pattern, you can use simple method to communicate with the façade. The façade responds by returning simple data objects that can be used  by the calling function.. Of course you can use other patterns like inversion of control. For this article I’ll stick to the good old façade.


For the readers not familiar with the façade pattern. The façade hosts all functions that are accessible for the client. The façade handles calling the data objects to  get or set data, without having knowledge of the structure of the data. The façade also handles the coordination of actions containing multiple data objects. In other word the façade acts like a business layer

The data objects are responsible for getting and setting data. A data object contains read and write properties. The data object maps these properties on the appropriate fields in the underlying CRM entity (or entities).

The great thing about the Web API Controller is that the objects returned to the webpage / javascript are JSON objects. In other words the Web API Controller handles all the technical serialization and deserialization.


The integration pattern I described is straight forward. I combine trusty .NET code with javascript to get the data on the page. The concept that I can reuse in stage two is to have an abstraction layer in the client side code to ease up development. Do I hear some “knock-out”?

In the next article I’m going to provide a sample application, in which I connect my web page with the Web API Controller. The Web API Controller will be set up as a façade  using a data object to get and set data from Dynamics CRM.

For now I’ll enjoy my last days in a very sunny Greece. Ya mas!