Salesforceスケジューラ

We usually need to schedule some jobs within our Salesforce orgs to execute some specific piece of logic at some given time.

The basic use case for this might be deleting custom logs on schedule to release space to have new ones inserted into the database. Say, we only keep the very near 30 days logs which means we will execute deletion every day to remove logs generated 30 days ago.

Let’s presume what we have now is a small start-up business org where we have thousands of logs daily. We can delete all of them within a standalone scheduler.

Here we have a very simple scheduler with only one line in the block of the main method of a scheduler.

public with sharing class LogDeletionScheduler implements Schedulable {
    public void execute(SchedulableContext objSC) {
        delete [SELECT Id FROM Log__c LIMIT 10000];
    }
}

We have to implement three methods inside a batch class. execute is the main part for data handling. finish is usually used in chained jobs where we can invoke jobs one after another. start is used for splitting which returns an Iterable to iterate through all of the queried data.

global interface /*Database.*/Batchable 
{
    void execute(Database.BatchableContext param1, List<Object> param2);

    void finish(Database.BatchableContext param1);

    Iterable start(Database.BatchableContext param1);
}

Talk is cheap. Show me the code.

public with sharing class LogDeletionBatch implements Database.Batchable<SObject> {
    public Database.QueryLocator start(Database.BatchableContext objBC) {
        return Database.getQueryLocator([SELECT Id FROM Log__c]);
    }
    public void execute(Database.BatchableContext objBC, List<Log__c> lstLog) {
        delete lstLog;
    }
    public void finish(Database.BatchableContext objBC) {
    }
}

The scheduler was updated accordingly as below. The only thing we need in a scheduler is to execute the batch job with a given batch size. In this example, a default value is specified.

public with sharing class LogDeletionScheduler implements Schedulable {
    public void execute(SchedulableContext objSC) {
        Database.executeBatch(new LogDeletionBatch(), 200);
    }
}

Under the above structure, we don’t need the LIMIT in the SOQL. The batchable will split Logs into many smaller lists and execute the same logic onto each and every one of them until the last is finished.

It seems the Log deleting job works perfect so far. But what will happen with the further expansion of the business? Some other schedulers and batch jobs will be included into the very same org. There could be a scenario where many batch jobs are working at the same time. Each of them handles their own business, of course. For example, some jobs will be executed insanely during midnight when no end user is accessing the site. Another issue comes up again with Salesforce limitations.

You’ve exceeded the limit of 100 jobs in the flex queue for org 00D5f000006tSmL. Wait for some of your batch jobs to finish before adding more. To monitor and reorder jobs, use the Apex Flex Queue page in Setup.

We all have different parts to play.

With all said above around a batch, it does well in data splitting but not handling. Here comes another important interface, Queueable. As the name implies, it queues jobs. Compared with two stated interfaces, the new one is more flexible. The limitation of a Queueable is only counting against the whole asynchronous calls. Beyond that, we can usually enqueue jobs with Queueable freely.

With all above, we come into a conclusion that the three interfaces woking together will unleash the power of asynchronous solution. By doing so, we can reduce some future code refactoring and diminish some unexpected limitation issues.