Platform Events by Tim Taylor

Editor's Notes

• #3: In 2017 Salesforce introduced platform events to support the Event-Driven software architecture Prior to this integrating distributed systems required tightly coupled point to point integrations such as the request response REST API integrations. Systems in request-response communication models make a request to a web service. In comparison, systems in an event-driven architecture react to an event in near real time when the event occurs. Event producers don’t know the consumers that receive the events. Any number of consumers can receive and react to the same events. The only dependency between producers and consumers is the semantic of the message content. Example: eCommerce system publishes a single event that is consumed by several services to handle (payment processing, shipping, inventory updates, …).
• #4: Event similar to sObject -> Event message similar to how a record is an instance of a sObject. Note the API name suffix of __e instead of __c Published events cannot be edited/deleted. To consume the event, an app can subscribe to it (as opposed to querying it). Custom fields become the content or semantics of the event message. Publish Behavior: Publish After Commit. When subscriber dependent on data to be present or if you simply don’t want an event to publish if transaction fails. Publish Immediately. Without fear of rollback. This is especially convenient for logging purposes so that you don’t have to relay on debug logs.
• #6: Not following best practices here for brevity In this example I want to publish the event when the case JIRA Status is changed to Awaiting Reply Populating and instantiating the same platform event we saw earlier. EventBus.publish() method pushes the message to the channel. Behavior is similar to Database.insert() where you can interrogate the Database.SaveResult. Apex governor limits apply. Each EvenBus.publish execution counts as a DML statement. You can also capture the Database.SaveResult object to determine whether the operation was successful or not in same fashion as you would insert or update sObjects.
• #7: For Flows, add a Create Records element to the appropriate flow. Where you'd usually pick an object to create, select the custom platform event.
• #8: Such as SOAP API, REST API, or Bulk API. POST request to the endpoint Request body will contain a JSON formatted message containing values for any of the fields defined for the event.
• #9: We’ll look at some examples of subscribing by trigger and process and talk a little about the lightning components BUT we won’t explicitly go over CometD
• #10: Not following best practices here for brevity Very similar to trigger for any sObject The after insert trigger event corresponds to the time after a platform event is published Along with processes, it is the most straight forward method of consuming published events Trigger Batch size: The Apex trigger batch size for platform events is 2,000 as opposed to trigger batch size of 200 for standard/custom objects.
• #11: Build the process to start when it receives a platform event message. In the process’s trigger, associate the process with a platform event and an object. The object you choose determines with object fields you can access throughout your process. The process looks for a case record whose Id matches the case id in the event message. Flow Builder subscribes to events by using a Pause element instead of starting of flow when a platform event occurs. When the event is receives the flow resumes.
• #12: Using empApi component is slightly different for Lightning Web Components versus Aura Components but both involve defining the empApi component and utilizing the empApi components methods of subscribe, unsubscribe, etc.
• #13: Visualforce pages can use CometD as well. CometD is a scalable WebSocket and HTTP based event and message routing bus. CometD is a set of library to write web applications that perform messaging over the web. The replay ID is a system generated value, and it is used to position the event in the event stream.
• #14: Great for situations where the error is likely to go away later. Could be timeouts, row locks. Or as simple as a field value change. Events are resent after a small delay that increases in subsequent retries. Retrying the event causes all events in the batch to be resent. May retry events 9 times (the initial run plus 9 retries). Make sure to retry LESS THAN 9 times. After the ninth retry, the trigger moves to an error state and must then be fixed and saved.
• #15: Unhandled exceptions such as CPU or heap size limits. Intentionally designing trigger batch size limits or some other processing logic. Because trigger batch sizes can be 2000 instead of normal 200, you can reach some limits more readily. New batch starts with event message after the one with replay ID you set.
• #17: Lightning Email Templates are not available for use in Email Alerts, so basic Process Builder or Workflow Rules are not an option. Additionally, there are dozens of these labels with the corresponding email templates which complicates the logic needed to implement with Process Builder or Workflow Rule. Since the label values match the email template names, I can query the needed email templates through Apex and send the notification to the customer.