9

I have seen Apex Promises, Apex libraries to chain Queueables, read about Continuations but I am still unsure what is the best solution for:

  1. run multiple long-running callouts
  2. Sequentially (wait for previous to complete)
  3. Stop or decide on how to cope with errors

in 2021. I am looking for a solution, which is:

  • as native as possible
  • usable in managed packages
  • somewhat scalable
  • doesn't require costly add-on licenses

1 Answer 1

11

Roughly speaking, this is what Queueables are for. Once Transaction Finalizers are GA, I think they'll be a pretty good solution for this.

There are many concerns, though:

  • The Queues If you're starting batches from a trigger, you can overwhelm the flex queue pretty quickly. If you're starting Queueables, you can degrade the performance of other async processes by flooding the queue
  • Saving your progress If you're making callouts, you'll probably need to store the progress of the overall process somewhere in SF. There's no generic answer to that
  • Too many record updates If you keep updating the record every few seconds, this can invalidate manual updates attempted by the user and that can be a usability problem
  • The Queuable delay After a few chained calls, you start getting time penalties before they can run again. This might or might not be acceptable
  • Error Handling If you were to use Platform Events, this is super-hard. With BatchApexErrorEvent (packageable in Spring 21) or Transaction Finalizers, this is achievable

Today, I'd use a Batch that works like a Queueable and BatchApexErrorEvent to handle fatal errors. When Transaction Finalizers are GA and packageable, they'd be good too.

To be industrial-strength, I'd want some sort of monitoring to make sure I don't flood the queue.

Edited to clarify the separation of queues: Thanks PhilW

12
  • 3
    @RobertSösemann For value that small, Queueable is ideal. It should do what you want it to do in a reasonable amount of time.
    – sfdcfox
    Mar 16, 2021 at 18:26
  • 1
    Aiden, to be clear, as far as I'm aware, the Queueable delay is still a myth. Nobody's ever seen it in production (unless you have, in which case I'd like to know how you managed to do it). I know they had some talk about suicide scheduling having a 60 second penalty, Queueable with an exponential penalty, etc, but I've never seen it happen.
    – sfdcfox
    Mar 16, 2021 at 18:27
  • 5
    I have certainly seen queueable delay with chained queueables - penalty goes to 60 secs after 4 links. I workaround with a counter then call to future that starts queueable chain all over
    – cropredy
    Mar 16, 2021 at 18:42
  • 3
    The other thing to note with using a queueable, when it is self-chaining, you are limited to a chain depth of 5 on non-production orgs. This is a total pain in the a**e, meaning that to allow it to function correctly on sandboxes etc. you HAVE to toggle to a future to avoid this problem. And that means you are limited on the type of state data you can pass along.
    – Phil W
    Mar 16, 2021 at 21:13
  • 1
    @Aidan I'm wondering why you mention the flex queue; AFAIK that's just for batches, not queueables.
    – Phil W
    Mar 16, 2021 at 21:23

You must log in to answer this question.

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