2

I'm running into an issue with too many future calls when handling Platform Events with a Process Builder that uses an invocable Apex class.

Basic setup is 2 processes: The first publishes an event on a custom object create (w/ a scheduled action to allow for the record to be committed before event subscriber gets the event)

The second pulls 2 fields from the Platform Event and passes them to an @Invocable Apex class, which in turns uses a @future method for async processing.

Everything works fine except for the fact that I appear to have no control over how many Platform Events are getting batched together on the way to the subscribing Process. I expected each Event would be executed in it's own context, however it clearly is not as I hit the "too many future calls limit" at 51. I've seen that this is in fact the case and that the "batch" size could be as large as 2000.

Is there any way to control that batch sizing so I can keep my @future call working? Or do I have to abandon ship on this whole architecture?

  • 2
    Queueable chaining is a good alternative to the one-future-method-per-record pattern that could allow you to keep the rest of your architecture intact. – David Reed Nov 13 '18 at 16:24
  • 1
    There doesn't seem to be a capability of controlling batch size, so you may need to design/implement it differently. – Jayant Das Nov 13 '18 at 16:28
  • 1
    According to trailhead triggers only execute on up to 200 records a time and you can also use a trigger instead of a PB as a listener for events. In the instance of even batches of 2000 records, that would translate to 10 triggers or 10 future calls, assuming your future calls are bulkified in their own right. The answer may be as simple as switching from a PB to a trigger. Otherwise, can you provide your @future code? – gNerb Nov 13 '18 at 16:49
  • I'm going to see where I can get using a trigger on the Platform Event itself. Previously I had been trying to publish from the custom object Trigger. That was problematic because the Subscriber started working on the Event before the custom object record was commited (as is noted in the dev guide). – torpy Nov 13 '18 at 18:34
1

In this instance I'm able to slice up Trigger.New Platform Events into manageable chunks that don't blow up the @future limit. Since the scale of my input is unlikely to grow large enough to break this model I'm happily chugging along. Publishing the Events with a Process does work well so I'll be keeping that part for now.

I'll definitely look into Queueable chaining for other purposes though, thanks for the reminder that exists David Reed!

I apologize for the rather broad question, and for answering it myself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.