Home > Blog > Salesforce Summer’17 Release: Platform Events

Salesforce Summer’17 Release: Platform Events

Platform Events is a new native feature that, when paired with the enterprise messaging platform, enables near real-time integrations in the spirit of event-driven architecture. Salesforce is known for its custom metadata platform, and now we’re delivering a custom messaging platform so our customers can build and publish their own events. Platform events simplify the entire process of communicating changes and responding to them without the need of complex logic. Platform events allow customers to increase interaction between data and Salesforce. For example: a software system can send events containing information about printer ink cartridges. Subscribers can subscribe to the events to monitor printer ink levels and place orders to replace cartridges with low ink levels. There is no need to poll the server to obtain information about a state. Instead, you subscribe to an event channel that will notify in case of a change in state. The goal is to reduce the number of point-to-point integrations and expand on the existing capabilities of our other integration options such as Outbound Messaging, Apex Callouts, and the Streaming API. How To create a Platform Event: Setup->Platform Events The pipe, the window, and the event: Message queue with sliding window   The pipe serves as a message bus that enables events to be added in chronological order with replay IDs. The window slides with time, and any events within the window can be replayed. Publishers are internal or external apps that push new events into the pipe. Internal events can be published declaratively with Flows or Process Builder and programmatically with Apex. External apps can use our native APIs (SOAP, REST, Bulk) to publish events. Consumers can subscribe to events via CometD/Bayeux protocols and with Apex. Create a new Platform event: You can create a platform event that will publish an event when a new Employee is created. Platform events contain standard fields. Add custom fields for your custom data. To define a platform event in Salesforce Classic or Lightning Experience:
  1. From Setup, enter Platform Events in the Quick Find box, and select Platform Events.
  2. On the Platform Events page, click New Platform Event.
  3. Complete the standard fields, and optionally add a description.
  4. Click Save.
  5. To add a field, in the Custom Fields & Relationships related list, click New.
  6. Follow the custom field wizard to set up the field properties.

Standard Fields

Platform events include standard fields. These fields appear on the New Platform Event page.  
Field Description  
Label Name used to refer to your platform event in a user interface page.
Plural Label Plural name of the platform event.
Starts with a vowel sound If it’s appropriate for your org’s default language, indicate whether the label is preceded by “an” instead of “a.”
Object Name Unique name used to refer to the platform event when using the API. In managed packages, this name prevents naming conflicts with package installations. Use only alphanumeric characters and underscores. The name must begin with a letter and have no spaces. It cannot end with an underscore nor have two consecutive underscores.
Description Optional description of the object. A meaningful description helps you remember the differences between your events when you are viewing them in a list.
Deployment Status Indicates whether the platform event is visible to other users.

Custom Fields

In addition to the standard fields, add custom fields to customize your event. Platform event custom fields support only these field types.
  • Checkbox
  • Date
  • Date/Time
  • Number
  • Text
  • Text Area (Long)


ReplayId System Field

The ReplayId field identifies a platform event record and is used to get stored events that are within the retention window. Only a subscribed CometD client can retrieve past events using the ReplayId field. SOQL queries aren’t supported. This field is among the standard fields that the system populates for each platform event. Each replay ID is guaranteed to be higher than the ID of the previous event, but not necessarily contiguous for consecutive events. The ID is unique for the org and the channel.

API Name Suffix for Platform Events

When you create a platform event, the system appends the __e suffix to create the API name of the event. For example, if you create an event with the object name Inklabel down, the API name is Inklabel_down__e. The API name is used whenever you refer to the event programmatically, for example, in Apex. The process of subscribing to platform event notifications through CometD is similar to subscribing to our Streaming API’s PushTopics or generic events. The only difference is the channel name. Here is the format of the Platform Event topic (channel) for my event: /event/Employee__e       {   “data”: { “schema”: “7cBPcbWRGAqoVPAYy2kiTD”, “payload”: { “CreatedDate”: “2017-08-14T18:45:23Z”, “CreatedById”: “005B00000031mqb”, “Employee_Number__c”: “KLRAC1044”, “Employee_Type__c”: “SoftwareEngineer” }, “event”: { “replayId”: 1 } }, “channel”: “/event/Employee__e } My external shipping app, subscribed to Order Event channel, is notified in near real-time when an order is placed thanks to my Apex trigger. Once my shipping app completes sending the shipment, does it let Salesforce know? Of course—ideally by publishing another event. Your app can publish an event to Salesforce using our SOAP, REST, or Bulk APIs. Publishing events uses the same process as inserting sObject records. Using the REST API, the endpoint looks like: /services/data/v40.0/sobjects/ Employee__e/ {  “Employee_Number__c”: “KLRAC1044”,   “Employee_Type__c”: “SoftwareEngineer”} Published another event: we will create two events of type Employee public class NewEmployeeClass {   public static void hirenewemployee(){   List<Employee__e> employeeEvents = new List<Employee__e>();   employeeEvents.add(new Employee__e(Employee_Number__c=’KLRAC1044′, Employee_Type__c=’SoftwareEngineer’)); employeeEvents.add(new Employee__e(Employee_Number__c=’KLRAC1078′, Employee_Type__c=’ProjectManager’));   // Call method to publish events List<Database.SaveResult> results = EventBus.publish(employeeEvents);   // Inspect publishing result for each event for (Database.SaveResult sr : results)   { if (sr.isSuccess())   { System.debug(‘Successfully published event.’); }   else { for(Database.Error err : sr.getErrors()) { System.debug(‘Error returned: ‘ + err.getStatusCode() + err.getMessage()); } } } } } These records will be inserted synchronously. Event publishing is similar to DML operation and hence DML limits apply. Events can be subscribed using triggers. After insert triggers can be used just like any other object type. After the event is published the after insert trigger is fired. Based on the conditions we can add business logic to suit your requirement.   trigger Newvacancy on Employee__e (after insert) {   // Trigger for catching new Employee events. // // Iterate through each notification. // // List to hold all Positions to be created. List<Position__c> pos = new List<Position__c>(); for (Employee__e event : Trigger.New) { System.debug(‘Employee type: ‘ + event.Position_Type__c);   // Create a Position to indicate Employee. Position__c p = new Position__c(); p.Name = event.Position_Type__c; pos.add(p); } // Insert all Positions corresponding to events received. // insert Position; insert pos; }   In the above scenario, we have written after insert trigger. So, in that case if we have a new Employee hired/created   then a corresponding record will be generated in object Position.     Reference link: https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm https://developer.salesforce.com/blogs/developer-relations/2017/05/first-impressions-platform-events-salesforce-enterprise-messaging-platform.html
Enquire Now

lets get over a cup of coffee and discuss!

Page Name: