0

Our current design starts from a trigger, checks the data against a bunch of rules that the customer sets up. The ones that pass get sent to another job which exports it to another external system through a SOAP call.

The problem is that we hit governor limits when a user updates too much data at one time (in particular we are looking at a large import from an external system or through data loader.

Since it's a large amount of data that we are targeting (~200,000+ accounts) we were planing on using a batchable class. The problem I'm seeing with that is that we are only allowed to enqueue 5 batches at a time which could be a huge problem if our customer has multiple workflows (which they do).

I've seen posts on here talking about a singleton solution however I am not clear on how to get that to work with workflows. Is there a way to delay the execution until after workflows have completed? Do I have to settle with putting the sync job on a schedule/add a large delay to give it time to collect all instances from the workflows?

Thanks for the help.

Improve this question

2 Answers 2

Reset to default
1

I might go with:

  • Start a schedulable at Time(0)
  • Schedulable checks to see if batchable is running, if yes, abort
  • Schedulable calls Batchable that queries for work
  • On batchable finish(), start the schedulable again if not already running

Don't tie any of this to triggers; the triggers merely leave the database in a state such that the batchable can find work to do.

Improve this answer
2
  • I'm not entirely following. I'm doing a performance refactor on a system that is already utilizing triggers. It sounds like what you are describing would require a much larger effort than my team can afford to make.
    – J. Larson
    Commented Aug 21, 2020 at 5:25
  • I was trying to illustrate a singleton-type pattern
    – cropredy
    Commented Aug 21, 2020 at 18:13
0

Queueable is the only way to reasonably handle large volumes of data from a trigger. Batchable is for updating a large number of records in bulk, but is too limited for frequent use in triggers. You can chain Queueable calls like a Batchable class, but without the stricter limitations in place.

Improve this answer
9
  • Is Queueable able to handle the large volume we need? (over 200,000 records)
    – J. Larson
    Commented Aug 19, 2020 at 18:31
  • @J.Larson Generally speaking, yes, it's possible, but it depends on the specific circumstances. You can chain a queueable into another queueable to process a large amount of data. It's a different design from batchable, but better suited for triggers.
    – sfdcfox ♦
    Commented Aug 19, 2020 at 18:38
  • @J.Larson - chained queuables will have an SFDC-imposed backoff time delay after the 3rd or 4th link, asymptoting to 60 secs between links
    – cropredy
    Commented Aug 20, 2020 at 1:22
  • @cropredy In theory. I've never actually seen it happen, though (see this). I've never actually observed it happening.
    – sfdcfox ♦
    Commented Aug 20, 2020 at 3:03
  • Well I certainly have seen this but it is worth me revisiting this with v49
    – cropredy
    Commented Aug 20, 2020 at 6:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .