Fortunately, a pre-release allowed us to test out this new feature, which can fundamentally change the way Force.com applications are designed in the future. To sign up for the pre-release, go here: https://www.salesforce.com/form/signup/prerelease-summer-17.jsp
Platform events are a lot like the existing Streaming API. For example, they share the replay id mechanism (allowing to track state and build robust integrations) and they both use a REST endpoint to subscribe to using long-polling.
The main difference between the two, is the custom object like definition of a platform event versus the definition of so called push topics in case of the Streaming API. As a consequence, contrary to push topics, platform events have a setup menu user interface where you can declaratively manage them. Push topics do not have such an interface.
Another major difference is the underlying principle. While push topics are tied to an SObject, through a SOQL query and DML event(s), platform events may be emitted by other sources as well. For example:
An external system could publish a platform event explicitly using the REST or SOAP API
The same platform event could be emitted by DML from triggers on several different SObject types.
Platform events may be published using declarative tools (Process builder)
Publishing and subscribing
Publishing of platform events is more flexible than publishing a push topic.
Similarly, subscribing to a platform event is more flexible as well. Subscription using long-polling is possible, like with the Streaming API. For example using CometD. But as opposed to the Streaming API, platform events can also be subscribed to using APEX (a trigger) or declaratively (process builder).
So, what do platform events enable us to do, which would be hard, impractical or impossible to do now?
For my test case, I decided to try and emulate long-polling with APEX. Platform events make this a possibility. Normally recursively executing APEX callouts would not be possible without the APEX scheduler. The downside of the scheduler is the big interval at which it runs and the rather static, time based, execution of the recursive process. Other ways of infinite processing (which is theoretically needed for long-polling), would hit the governor limits of the Force.com platform.
Using platform events, the following configuration is possible:
1. Upsert an SObject record with a counter (denoting the number of callouts performed). A trigger or process on this SObject will publish a "Request__e" event:
In case of insert
In case of incremented counter
2. APEX trigger subscribes to "Request__e". This trigger calls the external HTTP service.
Optionally sets up or refreshes session
Handles the data payload
Update SObject from 1 with incremented counter
You will find this mechanism works perfectly. It will keep a connection to the API in question alive and the process will run indefinitely, until a quit-condition is met. Salesforce’s Live Agent REST API was used to test the approach successfully.
The key property that allows Platform Events to run logic infinitely, that was not available until now, is the decoupling of transactions. Another term you may come across when talking about a transaction is "execution context". Most Salesforce governor limits are enforced per transaction. The longer a transaction lasts and the more logic it executes, the more risk to hit a limit.
Until now, all processing had to be done either in a synchronous way, where the transaction remains open until all processing is done. This will hit some kind of governor limit eventually. Alternatively, asynchronous processing is available (e.g. @future, Queueable, Batch Apex), but the limitation that would prevent infinity here, is the injunction that asynchronous processes cannot recursively call itself in a useful way.
With Platform events, the initiation lies with the event, where the subscribing APEX trigger will spawn its own transaction. A transaction that will end when a new Request__e is inserted, only to spawn a new transaction when this happens.
The already rich toolbox of Force.com has a powerful new member. Platform Events allow distinctly new approaches to application design that were not possible before.
Other use cases for Platform Events would be:
Reduction of point-to-point integrations
Replacement of polling interfaces
Implementation of event based apps. For example: chat, monitoring, IoT and many more