Scale and improve with the Scheduler Dispatcher Framework in Salesforce

Scale and improve with the Scheduler Dispatcher Framework in Salesforce

Posted by: Nayab Naseer
Category :Salesforce


Salesforce Scheduler Dispatcher Framework offers an effective way to utilize apex schedulers and batch apex in the platform. This helps developers overcome the day-to-day challenges related to scalability, code and governor limits, and other issues.

The problem of Scalability

Developers usually encounter problems with apex triggers, as their code progresses beyond the basic.

When developers insert, update, or delete a particular record in Salesforce, they usually invoke an index trigger as the point to hook up the logic. When the program is complex, or extensive, more and more logic is connected to a trigger. The problem occurs as one trigger is considered as one transaction and each transaction has its own set limits. The logic hooked up to the apex trigger has to obey the assigned governor limit, slowing up the transaction considerably. The governor limit gets eaten up fast as more and more logic gets added on to the trigger, further increasing the bottleneck. The problem compounds as developers have no control over the order of execution of a trigger on the same object. There is no real control over which trigger will execute first, making debugging and troubleshooting a nightmare.

The Problem of Sluggishness

Another common issue plaguing developers is the time taken to process a query. Consider the need to, say, update a lead address. When the database is extensive, as it is in any proper marketing set-up, with a large number of leads, the verification process takes a lot of time. The query is executed in a synchronous fashion, by calling in all the leads one by one, processing the address verification logic, and selecting the check box.

Schedulers to the Rescue

Programmers usually overcome the constraints caused by governor limits by restricting the logic, or imposing limits on each index trigger. Schedulers or batch effects now offer a healthier work-around to obtain more governor limits and thereby offer more room to run the logic.

scheduler dispatcher framework

With schedulers, every apex batch is considered as a separate thread of execution, as one single independent process with its own governor limit. Every batch of execution gets its own separate timers. In contrast, apex triggers have just one timer, regardless of the number of logic they have, leading to much pressure.

Apex schedulers allow up to 50 query cursors to be open at the same time and allow the query locator to refer up to 50 million records. The query string becomes a focal point and when a particular statement executes, a pointer is created in the Salesforce platform memory.

A batch can run 200 records at a particular time, without chunking. It allows 10 call outs each in start method, execute method, and finish method and it becomes possible to execute a whopping 2,50,000 number of batch jobs in 24 hours.

Another advantage of using scheduler dispatchers is the ability to chunk processing at platform level, thereby allocating more CPU time for processing. It is possible to automate schedulers using apex schedulers, depending on how developers make use of it.

Tweetable Quote: “The Scheduler Dispatcher Framework makes life easy for developers by freeing up the apex trigger throttles.”

The Framework

The Scheduler Dispatcher works with a main apex scheduler that automatically schedules and dispatches each apex batch as per the set criteria. For example, batch one may be set to execute at 9am every day and batch two may be set to execute at 10 am every day. Independent logic may be executed in relation with various criteria.

Every job short listed to run at specific time intervals is sent to a can-execute job. The can-execute job checks whether the environment in Salesforce is perfect to run this batch job. For instance, if the batch job is already running, then it is not executed. If apex flex queue is full, then the batch job is not executed and the “help up” and the “else” part of the code is invoked.

The scheduler dispatcher processes in an asynchronous fashion. The dispatcher undertakes the processes asynchronously, ensuring that each process gets completed quickly. Involving the dispatcher framework entails creating another custom object, which acts like a queue and another custom object is created to cache all requests for the dispatcher to process.

The dispatcher schedules, aborts, and reschedules itself depending on the time set for dispatcher interval in the environment settings and runs the batches. If the time set is, say, 10 seconds, it will check if any schedule job is eligible to run every 10 seconds. Increasing or decreasing the rate of dispatch schedule is as simple as editing the value in custom setting. The scheduler reschedules itself, without having to stop the process.

The apex scheduler dispatches and reschedules itself. Additional batch jobs may be designed as per requirements and attached to the dispatcher. It is also easy to detach a particular batch out of the framework, as required. If a batch job needs to be edited, only that batch job needs to be detached from the dispatcher, without shutting everything down. This ability to attach and detach as required, provided by scheduler dispatcher framework makes it very dynamic and infuses more scalability and maintainability into the system. The dispatcher container contains only the logic to filter out job and either execute it, or reschedule it.

Is this a path breaking paradigm?

Scheduler Dispatcher makes the life of the programmer easy, by offering them an easy way out of the common issues plaguing them, such as scalability and sluggishness. The best practice is to use scheduler dispatchers as a supplement, rather than as a replacement for apex triggers. This would definitely bring up revolutions in the future.

The scheduler dispatcher framework is not a total replacement to apex trigger. Rather, when there is a chance of more logic getting overloaded on apex trigger, some of them can be moved to the scheduler dispatcher framework.

The scheduler dispatcher framework runs on a 24×7 basis and it is a best practice to log any exceptions or errors encountered, into a custom object. This is essential to debug the framework for any errors in future.

Leave your thoughts about Salesforce Scheduler Dispatcher Framework here.
To know more about Suyati’s expertise on Salesforce Scheduler Dispatcher Framework, please write to us:

Leave a Comment

Your email address will not be published.