Azure WebJobs & Dynamics 365

Post Date: March 5, 2017

Microsoft Dynamics Consultant

Summary

In an earlier post, I demonstrated how you could connect to a WordPress site (with a MySQL backend), to the Microsoft Azure Service Bus. The Service Bus messages were picked up by Dynamics 365 where, after some basic processing, a new CRM Lead record was created. I was trying to illustrate systems scale and how the Azure Service Bus could be leveraged to manage integration with multiple WordPress sites. As part of the demonstration, I created a C# application. The only issue with the application was that it needed a dedicated server to run on. This meant that after creating the application, we had to provision a dedicated computer to run the application.

While I was writing up the post, the question arose – what if you didn’t have a dedicated server (physical or virtual) or you didn’t want to provision a single server, dedicated to running the application? What are your choices as far as Azure is concerned? Well, you could create a Virtual Machines (VM) and go via the IaaS route, but this would be overkill for such a small integration project. If you’re trying to go serverless then as of 2017, there are only two options that I can suggest:

  1. Azure Functions
  2. Azure WebJobs

 

In this post, I’ll be covering Azure WebJobs by taking you through some basic examples where Azure WebJobs can be used. I’ll also provide a quick overview on creating Azure WebJobs.

What are WebJobs?

Server-less code hosting!

As the name suggests, Azure WebJobs let you run your code in the cloud as a “job”. If you’ve ever heard of ‘Cron Jobs’, it’s similar to this. WebJobs allow you to write your own code, then, after uploading the code to Azure, you can create a new WebJob to run your code. It’s really that simple. You no longer need a dedicated server to run your application – just “host” that application in Azure as a WebJob. There is a thorough description on the Azure documentation site if you want to read the finer details.

As of 2017, there are three methods of running these WebJobs – Continuously, Triggered or using the Azure Scheduler. In this post, I’ll cover both Continuous and Triggered.

Step 1: Create a new Web App in Azure, if you don’t already have one

WebJobs need the Web App feature running in Azure. You’ll have to create a new Web App service if you don’t already have one. As of 2017, Microsoft offer 10 free Web Apps, conditions do apply.

Step 2: Create your Code

Now it’s time to create your code. In this example, we’ll create a basic C# console application that creates a CRM Lead record. Open Visual Studio, and start a new Console Application project.

Here is the snippet to create the Dynamics CRM Lead record:

Here is the Dynamics connection class:

As part of your assembly reference, you will have to include Microsoft.IdentityModel.dll in your Visual Studio project. The first time I tried running the WebJob, Azure logs complained of not having this DLL. My WebJob seemed to hang, then terminated.

Step 3: Zip your Code

After you have compiled the code, the next step is to Zip your files together ready to upload into Azure. I selected all the files in the Debug folder and created a single Zip file called Debug.zip. Ideally, if this is production code, you would not include associated debug files.

Step 4: Create a WebJob

Once you’ve created your Web App and you have your zip file ready, under the Web App Settings menu, you’ll find a link to view/create WebJobs.

Clicking on the WebJob link will allow you to create a new WebJob.

Step 4.1 – Triggered WebJobs (Choice A)

Add a name for this WebJob. In the ‘File Upload’ field, navigate to your Debug.zip file. Under Type, I have selected Triggered for this demonstration. This means that we will schedule our application to run when we specify – this can be a manual trigger (we request the application to run) or automated using a scheduled trigger such as the Azure Scheduler. The other option is Continuous, which means that it will continue to run indefinitely (see below).

Once this is complete, you should end up with your WebJob ready to run.

Step 4.2 – Continuous WebJobs (Choice B)

The other choice you have is to run the WebJob continuously. By this I mean, run it once and keep it running. There is a significant cost increase with this method, so if you are not using the free version of the Web App service, the Continuous method will cost.

There are some unsupported workarounds that will enable you to keep a triggered WebJob running continuously. Samuli Haverinen, in his blog post, covers this in a little more depth.

Step 5: Run the WebJob

If everything went well, you should be able to click on the Run icon and run the WebJob.

Once the WebJob is complete – you should be presented with a Completed status.

Taking a further look into the Log, you should see something very similar.

 

The Result

A new Dynamics CRM record should be created.

Example use case scenarios

As of now, real world implementation of Azure WebJobs consists largely of background processing. If you read the documentation on the Azure documentation site, there are some examples that cover image processing (reducing or scaling images uploaded), aggregating RSS feeds, processing file uploads, tracking web statistics, managing emails queues; but realistically, you can create WebJobs to handle a wide array of business cases.

A question that I get asked a lot is – Why can’t we just create a new Virtual Machine and run our application from there? There is actually nothing preventing you from doing just that, but the cost implications of running your application in a VM vs. running via a WebJob may influence your decision. As of March 2017, WebJobs are integrated into your Web App plan. The cost of running a triggered WebJob (not Continuous), is free. Continuous WebJobs on the other hand, as you might expect uses Azure resources, consequently, there is a fee to pay.

Some real-world business cases where Azure WebJobs and Dynamics 365 is being used:

  1. A nightly batch process of a Lead-scoring/grading. You could create a Lead scoring/grading system that taken in values of new Leads and gives it a probability score or grade.
  2. Run reoccurring custom Workflows to set Activity reminders like an annual birthday/anniversary of an important Contact.
  3. Roll-up queries that surpass the CRM Calculated fields limitation.
  4. Integration jobs like the WordPress, MySQL and Dynamics 365 post I mentioned at the start of this post.
  5. Data-migration jobs like nightly sales information from an Amazon store account.

Next Steps

This was a gentle introduction into Azure WebJobs and how to leverage WebJobs to run some code that integrates with Microsoft Dynamics CRM. The next step is to use Azure Functions to demonstrate how you can run serverless code in Azure. I’ll demonstrate Azure Functions and roll-up queries using LINQ in Dynamics 365.

Leave a Reply