In the previous post, we had an overview about Change Data Capture (CDC). But in this one, I would like to go a bit into the detail by highlighting my favorite points of what I observed along this pilot program.
Publishers will be automatically generated.
In CDC you do not have to care about publishers. Alright, maybe just a bit. But it is not going to be like with Platform Events (PE). If you remember, and in case you don’t you can always visit any of these posts, with PE you need a trigger or a process builder or a visual flow in order to publish events. But with CDC you just need to change a value through the Metadata API or, in the future, change a value in the object setup.
Don’t decide what to send.
Again this can be a significant difference with PE. And it is also related to the previous point. While with PE you have to define what info to send. In CDC you will be sending every single modification. Imagine you have a sObject with 3 fields and you are modifying just 2 of this 3 fields, the JSON sent from this modification will contain the 2 fields you are modifying. So, every single field in your sObject will be a field in the Change Event sent. But just those with modifications will be shown.
JSON will contain a high detail.
But not only the modified fields will be sent. JSON will contain a really handy info in its header. Info like a timestamp, the change type, transaction key, sequence number, commit user, the origin of this change could be a really significant information for your business logic, for keeping the data synchronized along different data sets or to track who and when has been done the changes. And who knows, this still a pilot program so maybe Salesforce will add some more info in the header.
Listen to the crowd or just one.
We have mentioned already the publishers. But what is the difference with PE regarding the listeners? In this case, we can easily decide if we want to listen to every single change event or just to the ones we decide. How to do that? Eeeeasy, all we have to do is get subscribed to the right channel.
- Subscribe to all Change Events
- Subscribe to a standard object
- Subscrive to a custom object
Because record changes do not use to come by its own. This value represents the position of this Change Event in the transaction. But be careful, because this is a nice but tricky feature. When I started to play with it, I thought the number in the sequence was going to represent the number in the whole transaction. But it is not like this. Imagine you have 3 sObjects in a business logic. So, when you modify the first a trigger is run to modify the second and then, a Process Builder is run to modify the third. But you have enabled CDC just in the first and the third sObject.
My thought was to find 2 sequence numbers. But a no consecutive sequence numbers. Remember we are modifying 3 records but just the one in the middle of the process has not enabled CDC. So, my thought was to find the 1st seq number equal to “1” and the second seq number equal to “3”. Those values will represent the sequence of the change in the whole transaction. But instead of that, I found 1 and 2 as seq numbers. So seq number represents the position in the transaction of those sObjects with CDC enabled.
As a conclusion, I just can say that CDC is a great feature. It is easy to use, extends Platform Events functionalities and is perfect for the tracking of modifications and DB replication.
When it will be ready I most probably will do a full analysis or check the new features. But so far I do not want to go deeper, as CDC can change a lot from today till the day it is released.
Thanks for reading!!