In the past you might have created a scheduled WebJob using a CORN expression. While that is still possible for non-.NET environments, if you want to run a .NET based WebJob you would need to use an Azure Scheduler.
If you have an existing WebJob with a CORN expression and a publish settings file with “runMode” set to “Scheduled”, you might get the following error while deploying it:
Error : An error occurred while creating the WebJob schedule: Response status code does not indicate success: 409 (Conflict).
The solution to this would be to create a triggered WebJob and trigger it using a scheduler. Let’s walk through this process:
Create a triggered WebJob
The default project template is to build process queue messages (refer to Function.cs). To change this to execute by a manual trigger, remove the “ProcessQueueMessage” method and add your own trigger handler.
Add the code to implement the functionality you wish your WebJob to do (Line # 14 thru 16). Now, modify the Program.cs to call the trigger handler (Line # 20).
Be sure to set the connection strings for AzureWebJobsDashboard and AzureWebJobsStorage. Those are required by the Azure WebJob infrastructure to store log and data.
When you try to publish the WebJob, you will see a dialog box to configure the WebJob. Provide a meaningful name and set the run mode to “Run on Demand”.
This configuration is saved in a file – webjob-publish-settings.json and added to the project under properties.
Assuming you have an App Service Plan and a Web App, go ahead and deploy your WebJob.
Once you have deployed, your WebJob is ready to run. What you need to is the scheduler to trigger it on a scheduled basis.
Create a Scheduler for the WebJob. Go to the Azure portal find your WebJob and click on properties to view the web hook and credentials that will be used to trigger the WebJob.
This information will be needed by the scheduler.
Creating a scheduler
Create a scheduler for the WebJob in the Azure portal:
The Scheduler needs a Scheduler Job collection. You can select an existing one or create new with the pricing tier that fits your requirements.
The free tier allows you to run up to 5 jobs with “every hour” as the max frequency. However it does not allow you to schedule jobs with authentication. For this example, at least a standard tier is required.
Next, select the action that the scheduler needs to take. In our case, it needs to trigger the WebJob via the web hook and credentials we saw in the properties of the WebJob. The web hook can only be called via the Post method. Using the retry policy, you could set how often the scheduler should retry if the scheduled request fails.
Finally set the schedule – once or reoccurring (with re-occurrence details).
Testing / verifying your setup
At this point you can go to the Job collection, and select the scheduler and look at the history of the job with details, in case of an error calling the end point. You can also make a one off call out of your schedule from the Scheduler by clicking the “Run now” button.
You can also verify the logs of each run in the KUDU console by clicking on Logs after selecting the WebJob from the WebJobs list.