What is an Event-Driven Software Architecture?
Why and When should I use platform events?
- The availability of the service is critical
- To add (integrate with) a new system, we need to establish a separate connection
- The availability of service is not critical. If the producer is not available, it's fine as it'll publish the events to the bus when it's available again and similarly if the consumer is not available for some time, it can also retrieve the events from the same event bus when it's back
- Adding/integrating a new system is fairly easy as we don't need to establish a separate connection to the service (event producer). The new consumer can simply connect to the event bus and can start receiving events
- The only consideration/dependency between event producer and consumer here is the format of the event message content as it'll be the same for all consumers
Types of Platform Events
- Standard Platform Events
- Custom Platform Events
Standard Platform Events
Custom Platform Events
- These event records cannot be viewed in salesforce directly so we don't have a page layout for them.
- Out of the CRUD operation, only CREATE and READ are valid for platform events. You CANNOT UPDATE or DELETE a platform event record.
- Published event messages cannot be rolled back
- The type of fields for platform event objects are limited. Only Checkbox, Date, Date/Time, Number, Text and Text Area (Long) fields are supported
Publishing Platform Events
- Publish Immediately - Platform events are published as they're fired. They won't wait for the current transaction to complete successfully. A good use case can be if you want to create error log (custom object to store errors) records when an exception is thrown. You can fire a platform event with the error message and it's published immediately. Therefore, an error log record will be created when this platform event is received (a separate transaction) even when the actual transaction is rolled back because of an exception.
- Publish After Commit - Platform events are published only after a transaction commits successfully. Let's say you want to send an email when something happens, so you want to be sure that the transaction is completed successfully before you fire a platform event which is subscribed by a flow (let's say) and it sends an email. In this case, Publish After Commit is a better option.
- Platform Events can be High Volume or Standard Volume. In API version 45.0 and later, all new custom platform events are high volume by default, so we'll focus mainly on that. A big difference between high volume and standard volume platform events is: High Volume platform events are stored in the event bus for 3 days whereas Standard Volume platform events are stored in the event bus for 1 day. The higher retention time makes the integration more robust as the system can be down for some time (due to any issue), can be up again and receive the event messages it lost when it was down
- The order in which the events are published remains the same - as we specify at the time of publishing these events, when you're publishing multiple events in the same publish call. If you're publishing multiple events separately using different calls to publish(), the order is not guaranteed.
- Platform Events are suffixed with __e
- Each platform event message has a replay id using which it can be replayed from the event bus.
- Some important terms include: Event Bus, Event Channel, Event Producer, Event Consumer and Event Message (we discussed all of these above in the Event-Driven software architecture section)