5

I have been reading about the new Salesforce async triggers. Currently, I tend to handle these sort of needs with a trigger that passes data to a 'Handler class' that would evaluate if a certain change has occurred. If it has then we pass those Ids to a queueable class for further processing.

What advantage do CDC and async triggers offer over using queueable or batch apex?

https://developer.salesforce.com/blogs/2019/06/get-buildspiration-with-asynchronous-apex-triggers-in-summer-19.html

Improve this question

4 Answers 4

Reset to default
7

Even if it says Async, it has the same set of limits as Synchronous transaction, No Extra Heap , 60 sec CPU Time or 200 SOQL. Also, the thing to remember here is it's an Event and EventTrigger and so can run with the maximum Batch size of 2000, thus if moto was to split the process into lighter one, it seems hard again.

As its a trigger, YOU CAN'T DO CALLOUT. Whereas you can do callouts in Batch/Future/Queuable.

You don't have control, let's say in AccountChangeEvent you update the account's field, it will again fire a new AccountChangeEvent CDC Event. Infinite Loops you are welcome :)

In my Opinion :

CDC is supposed to be a Data Replication API for external Systems(Or react to field change), but now SF is trying to put people use it on the platform.

If you want to build decoupled architecture, use Platform Events instead, you can control when to fire events and when to not :)

Writing a normal object trigger and its changeEventTrigger doesn't seems right in my view.

Improve this answer
6
  • I agree, I can't find any value add to this. Or why I would stop using my normal patterns with queuable and batch Apex.
    – Brooks Johnson
    Jun 13, 2019 at 22:10
  • Does this mean that I cannot sanitize or validate the data using trigger on the cdc object?? I do not get the concept of after database change, how do validation rules/ trigger errors get communicated back ?? I assume sf will come up with system.iscdc kinda variable or we can control recursion using static variables is guess for the infinite loop part.
    – Rao
    Jun 25, 2019 at 16:24
  • @Rao CDC event is fired after commit, so you cant add validation rule, trigger code to stop it. As its not the original transaction, its something that runs async after sometime. Think about adding validation rule in future/queuable, it wont stop the actual transaction
    – Pranay Jaiswal
    Jun 25, 2019 at 16:33
  • @PranayJaiswal so does this mean that I cannot move my exact trigger logic into the CDC object? what if I update my sobject and there is a DML error? how do I get to know there has been a failure on the sobject update
    – Rao
    Jun 25, 2019 at 16:58
  • @Rao You cant move all logic in CDC trigger especially if it deals with validation. If there is an error in CDC trigger, you can retry it 9times(for Unable_to_Lock_Row kinda error), in the end you have to create a record, fire another event, send an email to get attention of the user who started the initial tranaction.
    – Pranay Jaiswal
    Jun 25, 2019 at 17:03
3

The first thing to understand is Change Event Triggers have some prerequisites in org like enabling the Change Data Capture for the object and not all objects are supported yet.

Change Event Triggers are async and break transaction hence can be useful to break transaction , which in turn can help you save the CPU time.

The future or queueable methods were for same reasons while queueable had more flexibility because of couple more reasons

1.You can enqueue a queueable job inside a queueable job (no more “Future method cannot be called from a future or batch method” exceptions).

2.You can have complex Objects (such as SObjects or Apex Objects) in the job context (@future only supports primitive data types)

When it comes to picking async triggers and queueable, if you need a proper decoupling then go for async triggers with change data capture as it looks clean in terms of architecture.

NOTE - Third party callouts will still be stopped in async triggers as callouts are not allowed so queueable seems better here .

It's based on publish and subscribe model where the processes will be loosely coupled.

Improve this answer
6
  • 1
    Right now, I don't think this statement is correct: Change Event Triggers are async and use async limits. I asked that question at TDX and was told that is on the roadmap, but right now, although you get separate limits, its the ones for sync NOT async
    – BritishBoyinDC
    Jun 21, 2019 at 18:22
  • Ah thanks for informing me .Async limits in terms of CPU ? I understand DML limits apply ?
    – Mohith Shrivastava
    Jun 21, 2019 at 18:38
  • It's same as platform event trigger 10 secs. Dml is 150 for sync and async.
    – Pranay Jaiswal
    Jun 21, 2019 at 19:07
  • Thanks for that answer. How would a CDC trigger provide me with more decoupled architecture than a trigger handler class that calls a queueable based on certain conditiions? I am trying to understand why I would choose CDC.
    – Brooks Johnson
    Jun 22, 2019 at 11:45
  • 2
    Let's say we have to roll-up no of contacts on an account .In queueable class what would happen is you will run after insert , after update and after delete trigger and write logic in code to kick off queuable .you will have to worry about checking trigger context variables, creating lists and also you don't know if there will be additional triggers that's gets executed from managed package triggers before this logic and consumes CPU and may not even reach code where you call queueable class .While in async trigger once a commit happens in contact there is another thread .
    – Mohith Shrivastava
    Jun 22, 2019 at 11:58
1

Using batch or queueable apex allows you to work with a higher set of limits, so if your apex processing is very complex, using batch/queueable is probably a good idea.

The new feature to me seems like pretty much the same as what I just described above, except that:

  • It's now the native way of handling changes
  • You don't need to use oldMap and newMap to see if field values have changed
  • It doesn't sound like these triggers will have a higher set of governor limits
  • Because it's now the native way of handling changes, it potentially allows for your code to be more consistent...rather than using future methods here, and batch apex there, you have one way of handing complex changes
Improve this answer
-1

The biggest use I see is when lets say an Opportunity Update, triggers multiple other object updates. Today this may become very large with multiple Queries, DML limits, SOQL limits, maybe even CPU limits. CDC would allow each of those subsequent objects to be updated in it's own context, and therefore much less chance of system limit hits. As long as those are dependant only on Opp changes and not on the subsequent Objects updates, then they can all run in their own Event handling. So 1 Pub of Opp update, and multiple Sub of Object updates based on Opp. Can be done with Platform events as well, but CDC has some pre-built details around the Publish.

Improve this answer

You must log in to answer this question.

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