Last week I started this series of articles on using the Azure Scheduler with Dynamics CRM. I expected a pretty smooth ride, however it turns out to be an infuriated dragon that needs to be tamed. In this article I’ll describe what I achieved till so far.
I started with reading about Azure and the Azure Scheduler. I discovered that there are not many articles on using the Azure Scheduler. Basically there are two options in using the Azure Scheduler: the Azure SDK object model or REST. Ofcourse I can use the Azure SDK to connect to the Azure Scheduler, but that means that I probably have to merge a number of Azure dll’s with my functionality when I want to use it from within the CRM sandbox.
My functionality is going to be straightforward:
Post a new scheduler job in Azure. That scheduler job will trigger a job hosted on Azure. The triggered job will interact with Dynamics CRM.
I decided to go the hard route: using REST to connect to Azure.
The advantages of using REST:
- it is a lightweight protocol
- it is fast
- I don’t need to rely on external dll’s in order to use the object model
The disadvantages are:
- You have to do everything yourself
- You need to do a lot of puzzling
- You have to do your own authentication
But then: where do you start?
I found a couple of great articles, which helped me a great deal:
- David Ebbo’s blog: Calling the Azure API using plain REST
- David Ebbo’s blog: Automating Azure … using a Service Principal
- The Code Project: how to make REST requests with C#
- MSDN: Azure Scheduler REST API
- Channel 9 – Episode 127 – Windows Azure Scheduler
David’s article gave me a good starting point in solving the authentication issue. In order to connect to Azure services you need to authenticate yourself. One way of authentication yourself is by requesting a bearer token from your Azure subscription. The code is shown below:
In order to set up a connection, you need to know your Azure tenant Id. One way of finding the tenant id is by checking the App EndPoints in your Azure Management Portal. The tenant Id is the first Guid in the url’s shown.
You can find the client id and the key in the settings screen of the Azure App (see David Ebbo’s blog: Automating Azure … using a Service Principal).
Once you have the client id, the key and the tenant id, you can pass these to the authentication class described below.
The result of the authentication call is a token that you can pass in the headers of your REST request.
The header that you need to add is “Authorization” with the value “Bearer ” + token. From there on you can assemble the URL and perfom the Get, Put, Post or Delete request.
In the example below I do a get on the jobs present in the job collection “SchedulerDemo”.
var client = new HttpClient();
client.DefaultRequestHeaders.Add(“Authorization”, “Bearer “ + bearerToken);
client.BaseAddress = new Uri(https://management.azure.com/);
var response = client.GetAsync(url).Result;
The response results in an HTTP code 200 (OK).
When I wanted to add a new job to my job collection, I ran into problems. The first problem was getting the URL required for posting in the correct format’, a struggle that costed me a couple of evenings this week.
Fortunately the Channel 9 video, provided me with the insights to build the URL in a proper way.
This format, additional request headers and the Json request body are described on the MSDN page Create Job (Scheduler).
Now when I post the Url with the request body, I get an error 403 (Forbidden), while before I received a 400 (Bad Request) or a 404 (Not Found).
I’ve not reached my goal yet, but I feel I’m on the right track. It is just a matter of time before I can create a new job in the scheduler using plain REST technology. From there on, things will be a breeze.
p.s. Please let me know if you know how to tackle the 403 error.