[SalesForce] Is using Database.executeBatch from a trigger an anti-pattern

In a managed package we have a trigger on Account that propagates a custom field status value from the Account to a large number of related custom objects and wrote the logic in a batchable to avoid hitting governor limits.

But we recently hit this error:

System.AsyncException Database.executeBatch cannot be called from a
batch start, batch execute, or future method

because a second managed package uses a batchable to update the Account.

This seems like a pretty nasty sort of coupling: if (in a trigger) you use up the one and only one layer of batchable possible, any other code that tries to use a batchable (that causes your trigger to run) then breaks.

So is using Database.executeBatch from a trigger an anti-pattern? Is it a better trade-off to schedule such updates instead?

Best Answer

I would certainly regard it as an anti-pattern yes, the Salesforce documentation here, states this...

Use extreme care if you are planning to invoke a batch job from a trigger. You must be able to guarantee that the trigger will not add more batch jobs than the five that are allowed. In particular, consider API bulk updates, import wizards, mass record changes through the user interface, and all cases where more than one record can be updated at a time.

I personally think this statement does not go far enough to discourage this, as it basically breaks bulkificaiton, which as you know is a big no no. Unless your users of the given object fully accept and understand the implicatons (and its often hard to be confident they do tbh), i would never use it.

Instead, as you suggest create a scheduled job and have the trigger insert into some kind of work action object to process work in the background, then either chatter post or email notification of any failed work items back to the user, with a means to re-queue the work once they have resolved the issue.

There is of course on the horizon the most welcome Batch Apex FlexQueue. Note however this has its own limit of up to 100 queued items.

If the Apex flex queue has the maximum number (100) of jobs, this method returns an error and doesn’t place the job in the queue.

So even with this in place, my standard advice is to avoid linking Batch Jobs or @future work to granular user or API actions as you can rapidly flood the platform, resulting in failure to enqueue or the platform slowing overall processing down to compensate. Instead consider a more robust way to group such work with a solid user notification and error recovery solution in place.

Related Solutions

[SalesForce] trigger design pattern

Someone will give you a much more detailed answers I an sure but:

The first example Controls the flow of all the processing done on all triggers throughout your org. This is useful in that you have one place to control the flow of your trigger processes. It is building on the second example.

The second example just take that processing out of the trigger and into a class. It is not reusable via other classes so all it is essentially doing is breaking up the code into two separate locations for easier reading / maintenance.

As far as a best practice, implementing the first example would be considered the best practice IMHO.

[SalesForce] Calling future method from batch class

Definitely you can use an HTTP callout as an escape mechanism. But this is pretty naughty. You'll need a Remote Site Setting and a Session ID and a global class etc etc etc (red flags, alarm bells).

May I humbly recommend the use of System.Queueable call instead of @Future. You can create a class that is constructed with any kind of argument that you want to hand in, like so:

public class DeferredHandler implements System.Queueable
{

    private Map<String,String> key2val;

    public DeferredHandler(Map<String,String> key2val) {
        this.key2val = key2val;
    }

    public void execute(System.QueueableContext objContext)
    {
        //do your @Future stuff here with this.key2val
    }

}

And invoke him from inside your batch like this:

//defer stuff
System.Queueable job = new DeferredHandler(key2val);
System.enqueueJob(job);

There is some literature about this in the docs and Josh Kaplan's awesome Queueable blog post.

Best Answer

Related Solutions

[SalesForce] trigger design pattern

[SalesForce] Calling future method from batch class

Related Topic