-
Notifications
You must be signed in to change notification settings - Fork 50
Subscription Based Platform Events
John Storey edited this page May 16, 2020
·
4 revisions
Salesforce explicitly recommends that an SObject should have only one trigger. In our demonstration project, the Accounts trigger exists in the Common implementation.
The Sales implementation wants to know when the Account object has changes, so that some related business logic can be executed. However given Salesforce's recommendation, Sales should not create a new trigger for its use.
Using Salesforce's Platform Events feature, the Core implementation provides the PlatformEventDistributor that provides event information to subscribed classes, as defined by the PlatformEvents_Subscription custom metadata type in which Sales placed a record referring to the Sales_PlatformEventsConsumer class.
- The Sales implementation creates a PlatformEvents_Subscription CMDT record defining the Sales_PlatformEventsConsumer as the subscriber to platform events on the Event__e bus and related to the Account.
- In the Common implementation, an Account trigger creates a platform event on the Event__e bus with certain information. Note: This pattern requires external documentation about published events facilitating the creation of subscription records.
- The Core implementation has an Event__e trigger which executes the PlatformEventDistributor class.
- During instantiation, the PlatformEventDistributor reads the PlatformEvents_Subscription CMDT records.
- After reducing the subscriber list to those meeting the filtering criteria, the distributor provides the events to each subscriber.
- The distributor then executes each subscriber in a Queueable manner.