Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
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:
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!
Business Applications communities