In this series of articles I’m working on a scenario in which I want to hookup the Azure Scheduler to Dynamics CRM. In the previous article I established a breakthrough. Using REST calls and Json, I’m able to create new jobs in the Azure scheduler.
This paves the way for the next challenge: Creating an Azure web job that interacts with Dynamics CRM.
I’m new when it comes to Azure web jobs. Before firing up Visual Studio to hammer out a piece of code, I need to do some reading first.
In my research I stumbled on a couple of very useful articles:
- Scott Hanselman – Introducing WIndows Azure web jobs
- MSDN: Create a .NET WebJob in Azure App Service
- Tom Dykstra – Run background tasks with web jobs (MSDN)
- Troy Hunt – Azure web jobs are awesome and you should start using them right now!
- David Ebbo – Hooking up a scheduler job to a Web job
- Blog.Amit Apple – Scheduling Azure WebJobs with cron expressions
In Tom Dykstra’s article I noticed something very interesting. He states that you can use .NET command line exe’s as web jobs. Now that would ease up development quite a lot.
Writing a command line exe means, that you can develop and debug the exe as a normal windows console application. One huge advantage: full debugging capabilities.
In the next article I want to write a long running command line exe, that I want to deploy as an Azure web job. In order to make the command line exe really useful I want to test if it is possible to pass command line arguments. These command line arguments will be passed by the Azure Job Scheduler.
A good reason for passing command line arguments is that I want to pass in a Guid which identifies the job I started from within CRM. This would enable me to write back information about the job into CRM, making it managable by the administrator.
The scenario/framework I want to build in this series of articles is the following:
In Dynamics CRM I create a new job entity. In that entity I register information about the job I want to schedule (name, interval, job name, job parameters, etc…).
When I “finalize” the job, a plugin on the job entity is triggered, placing a new job in the Azure Scheduler.
The Scheduler will fire the Azure web job. The long running (5 minutes or more) Azure web job receives the job id, and uses it to write back information regarding the job.
Once this works, the scenario/framework can be extended and refined to act as a scalable batch job engine, in which long running processes can be executed without facing the dreaded two minute sandbox execution limit.
Anyway, enough food for thought for this evening!