Skip to main content

Azure Scheduler (Day 11 of 31)

List of all posts from this series: http://vunvulearadu.blogspot.ro/2014/11/azure-blog-post-marathon-is-ready-to.html

Short Description 

Azure Schedulers is a service that can be used with success when we have recurrent actions that we want to run at a specific time interval (every few minutes, every few hours, days and so on).
This is a multi-tenant service that is offered by Microsoft and is quaranteed to run even in a case of network or hardware failure.

Main Features 
REST API
As you already observed, all the services offered by Azure, including this one is can be configured and accessed over a HTTP, using a REST API.
Job ad Job Collections
In Azure Scheduler terminology a Job is a recurrent task or action. A job collections is a group of jobs that are grouped together.
History
We have the ability to see the history of the jobs that were run by scheduler. How each trigger action ended and so on.
Job Action
For each job that we schedule we need to specify the action that we want to perform. The job action can be represented by:

  • A HTTP/S request (we can specify the call method – GET, PUT, POST, DELETE)
  • Storage Queue Message 
Error Endpoint
We have the ability to specify a secondary endpoint that can be used when the call to the first endpoint fails. Can be used with success if want to send a notification that the trigger calls failed.
Start Time
For each job we can specify the start time. This can be useful when we create the initial setup and we don’t want to start to trigger immediately our custom actions.
Recurrence
When we configure how often a specific job to be executed, we can specify the frequency as time interval or as time. On top of this we have the ability to specify how many time we want to execute our trigger (1 time, 10 times, 1000 times and so on).
When we create a job we can create a job that will not be recurrent (one time job). For the one that are recurrent we can specify not only the recurrence level but also:

  • Starting time
  • Ending time

State
Each job can have 4 states, which can be controlled by user not only by the system:

  • Enabled – Active
  • Disabled – Inactive 
  • Completed 
  • Faulted 
For the last two states, the job status cannot be changed by the user. In this two state the job can be only deleted. A job in this two state will be deleted automatically after 60 days.
Retry Policy
This is a pretty interesting option. We have the ability to specify the retry policy that should be applied if the job fails to run. Be By default this feature is not activated. To be able to activate it we need to specify the retry time interval and retry count.
Authentication
We have the ability to use Client Certificate authentication or our endpoints. To be able to do this we need to specify the authentication node when we create a job. In it we will need to add the pfx content and password of course.
Beside this, we can use authentication that is based on username and password (basic authentication).

Limitations 
Maximum Recurrence Time
The maximum recurrence time that is allowed is 18 month. From my perspective this is acceptable. The same limit exist on the start time.
Frequency
For standard jobs is 1 minutes. For the free one is 1 hours.
Maximum number of jobs
For the standard version it is 50 jobs. For the free one you can create maximum 5 jobs in the same collection. If you end up with more than 50 jobs, than you can create more than one job collections.
Also, we have the ability to use the Premium unit not the standard one where we can create 10.000 jobs collection. This mean that using Premium option we can have 500.000 jobs for only ~104e.

Applicable Use Cases 
In this section you will discover 4 use cases when I would use Azure Scheduler.
Facebook post processing
Let’s imagine that we have a service that at specific time interval takes all the posts of a user and select the most important one and send them as notification to the end user. For this use case we would need to trigger the processing action at a specific time interval. For this purpose we could use with success Azure Scheduler.
Daily Cleanup
Every big and ugly system is a ‘state of the art’. Because of this we need to run a cleanup process every day at a specific time interval. The trigger of this cleanup task can be made by Azure Scheduler.
Logs Processing
Yes, there are logs that are analyzed in real time, but in the same time, we have every few hours or days to take all the logs, apply same magic over there, and archive them and so on. As in the above use case, the trigger for this job can be Azure Scheduler.
Special Offers
Imagine that you have a system that at a specific time interval add a new product in the special offer section. This push can could be triggered by Azure Scheduler.

Code Sample 
There are not too much code that I could show here, but below you can find the JSON that is used to specify authentication data.
 "authentication": {
        "type": "clientcertificate",
        "password": "1234",
        "pfx": "pfxKey”
      }

Pros and Cons 
Pros

  • Scalable
  • Ability to specify at a very small granular level the recurrence time interval
  • HTTPS support
  • Retry policy

Cons

  • -


Pricing 
If you are thinking to use Azure Scheduler you should take into account:

  • The number of jobs and how often will run (based on this you can use the Free, Standard or Premium unit)
  • Outbound traffic (if applicable)


Conclusion
It is a service that is very simple to use. On top of this, is reliable and very scalable. It can be used with success in many scenarios. It one of the services from Azure that can make a difference on the quality of your products and services.

Comments

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

[Post-Event] Codecamp Conference Cluj-Napoca - Nov 19, 2016

Last day I was invited to another Codecamp Conference, that took place in Cluj-Napoca. Like other Codecamp Conferences, the event was very big, with more than 1.000 participants and 70 sessions. There were 10 tracks in parallel, so it was pretty hard to decide at  what session you want to join.
It was great to join this conference and I hope that you discovered something new during the conference.
At this event I talked about Azure IoT Hub and how we can use it to connect devices from the field. I had a lot of demos using Raspberry PI 3 and Simplelink SensorTag. Most of the samples were written in C++ and Node.JS and people were impressed that even if we are using Microsoft technologies, we are not limited to C# and .NET. World and Microsoft are changing so fast. Just looking and Azure IoT Hub and new features that were launched and I'm pressed (Jobs, Methods, Device Twin).
On backend my demos covered Stream Analytics, Event Hub, Azure Object Storage and DocumentDB.

Title:
What abo…