Platform Events: Inside and Out

Platform Events: Inside and Out

well hello everybody my name is Lawrence McAlpin I'm an architect in the enterprise messaging platform team and with me as Alix warshofsky is a principal engineer also in the enterprise messaging platform team at Salesforce and we're here to talk about platform events before we begin our lawyers would like you to know that during the course of the session I may speak about some features that we plan to implement some things that we'd like to do don't make any purchasing decisions based on that only make them based on commercially available products the fact is that you know sometimes we change their minds things don't work out like you plan that's me that's Alex and okay so one of the principal issues facing IT today is the need to integrate multiple data sources multiple systems and you have customers using many different interfaces they're using mobile apps or using web browsers desktop apps you got IOT and other machine-to-machine interactions and you got data in our cloud other clouds within your own corporate firewall and you need to integrate all of that and tie them all together all these point-to-point interactions become pretty unwieldy now twenty-something on years ago I graduated from college and I went to a small manufacturing company in the Midwest that makes big yellow earth moving equipment and we didn't have to make these kinds of decisions I wrote a COBOL transaction and it ran on the mainframe the data came from the mainframe our users filled out a form and hit enter connected on a dumb terminal connected to that mainframe but nowadays you have to tie in all kinds of components that are living in all sorts of places and it can quickly become unwieldy all these point-to-point interactions become hard to manage so we think platform events a feature that we've introduced provides a better way it simplifies your integrations your Apex code your mobile apps you know standalone apps something in Heroku they can all publish to this shared event bus and they can all subscribe to the events in your real time in any of these environments so one of the advantages of the event bus is that we provide a ubiquitous communication channel so you have this loose coupling between the components when you add a new event producer nothing that was already in part of your orchestration needs to know about that you can add new subscribers and no one needs to know about that another advantage of this approach is that we offer some durability and if a component goes down and then comes back up and a missed an event then it'll end up having a mendacious view of the world and that could be a problem so we provide you the mechanism to resupply from whatever you want inside a sliding window so that way it never misses an event and lastly we support polyglot enterprises you have objective-c for your mobile apps you have a ruby and nodejs for your web apps you have Java you have Apex it doesn't matter they're all integrate together using the event bus because you're communicating using open standards you're publishing using HTTP using soap and REST API s and you're subscribing using the Bayou protocol so platform events are basically just a new kind of object you're already familiar with many of our objects we have standard objects like lead and user custom objects external objects so the event object is a new class of object it differs in a few fundamental ways though these are write only objects you can only publish them and then you can receive notifications when they come in you can't query them you can't use Sokol you can't view it unto you i you can only emit them and receive notifications we didn't want to create a new parallel set of api's we're going to keep things simple and keep things you know built on the technologies you're already familiar with so you publish using existing platform features like Apex soap and REST API flash this process builder and then you consume them externally using our durable streaming API which some of you are probably already familiar with if you use push topics or generic messages and you can subscribe to those from web browsers or any external system and then you can consume events on platform using apex trigger and process builder so one of the fundamental differences between this and a record centric standard or custom object is that instead of publishing or instead of creating the record in a database we are publishing the event into a sliding window and the sliding window is currently about a days in length though and this is a forward-looking statement in the future we may offer additional licenses or options to increase that window your publishers add the events in time order at the tip of the window so you're guaranteed that you will get your events in the order that we received them and your consumers can start reading anywhere in the sliding window so that's how we offer that durability if you go down for maintenance or a crash all you have to do is remember the last event you saw and then we'll tell you we'll fill you in and what you missed so there's several types of events objects just like there's several types of objects we have standard events you might be using some right now and not realize it like asset token and in the future we plan to offer additional features that will emit events like on this is forward-looking statement but we might publish events when you have login failures or other kind of security events one of the features I'm very excited about is a changing event so our change data capture team is building a feature that will emit events whenever you create update or delete a supported record and you can react to that event in near real-time there's a session on Wednesday we can learn more detail about that that's a called synchronized data to post press will change data capture on the exciting thing about that is unlike a trigger you can subscribe to these things off platform so you can keep things in sync across your enterprise and currently earlier this year we released custom platform events which we'll go into in more detail a custom platform event is a bit like a custom object you define your metadata in a setup UI one of the differences is that it has an underscore underscore a suffix and the API name and then we have a standard field here I'm going to drive escape ok and so you can see here the API name has to underscore industry suffix we have a standard fields on it just like you have for objects but instead of an ID we have the replay ID field this is no Paik identifier that you can hold on to so when you see this event you give it back to us when you subscribe and that's where you would start your subscription from and then you can add custom fields and you can attach triggers and process builder and the manner that you're already familiar and also we support packaging and you can use a like profiles and crimp sets to control who can publish and subscribe so publishing like I said earlier you can do through API process builder the apex interface is a little bit different instead of a database method which doesn't make sense because we're not writing a database we have an event bus published method and one of the main differences here though is unlike a database insert this is not transactional if your apex transaction or rolls back your events still got published so you'll have to accommodate that in your design and also we do not throw a DML exception if you try to publish a batch of events and one of them has a field validation error the other events will still go through the one with a field validation error will just end up in the same result and we'll tell you why we didn't publish it so we do not support all-or-nothing it's whatever it works publishes and as non-transactional you can't roll it back and then your triggers there's some slight differences we only support after insert triggers and an event object we support in order execution one batch of the time so we guarantee that you will not receive these events concurrently on you know two instances of an apex execution you can guarantee that you will process your events in the order that they were published unlike standard triggers which camp out at about 200 we do allow more to around 2000 events are typically very small you just want to describe a thing that happened and not like packing all the data about the thing that exists so because they're smaller or they're supposed to be smaller we can allow you to receive larger batches of them and they run as automated process user which is a special user that we have in all orgs in the future this is another forward-looking statement we plan to allow you to customize some of these settings so you can limit the batch sizes or maybe allow concurrent execution or run as another user but these are the defaults that we go in go with went with right now so subscribing externally has done through our durable streaming API that's pretty well documented online it uses the open standard by you particle comedy library is a popular implementation of it and I think alex has a demo which would probably make illustrate that a little more clearly alright so at this point I would like to show you platform events in action I have two parts to this I have the same publishing and and receiving and so on the receiving end there's a lightning component that subscribes to event bus and on the sending end of this I have a Heroku app where customer can submit order feedback there are two pieces of information that come over as you might have seen from the event structure before one is the there is an order number and another one is description so what happens here is is randomly generated or their feedbacks so customers saying I have order 51 and I would like to return it and let's send another one okay and doesn't happen so there's so one way to publish events is through JavaScript and I will show you the details of that in a minute and you can also do it using REST API so there is another it just took a while for this order to come true there's another order feedback saying order 49 is a happy order and customer doesn't want to return it it will be important in a minute in this case I'm using a REST API there is a REST API at point Slash's objects customer request and I'm sending order number work vain 777 and then there is a description there turn this order please when they send this order it comes through as well and these notifications come up and what happens as the result of those order you can see order 49 51 and WB 777 and when i refresh this list of cases you will see that there is order 51 case created and then there is WB 77 and order 49 doesn't have a case associated with it because it didn't have the word return in it because customer is happy with it we don't have any case associated with that what happens behind the scene in this app on the sending end there is some JavaScript where rest api endpoint is being used customer request e that's the object that's the event object and i'm simply generating a random number between 1 and 100 and then before their number is greater than 50 i'm returning in order otherwise I'm happy this is only as a you know this is for the demo in the real life you would probably have a form and you would type out for their feedback and then on the receiving end what we have is we have a lightning component and the code inside of this lighting component is subscribing to events using comedy library so there is committee library here it's comedy URL is pointing back to Salesforce to use the streaming API and then there is a helper that's processing events as they come in so there is a subscription and then and as events come in something something happens right and if you look at this we're receiving events and then display toast is the notification notification widget that you saw on the bottom where order number is displayed with the description now what happens and how do these cases get treated well we have this trigger on the event as Lauren's mentioned it's an afternoon sir trigger which is the only trigger supported now four events and as these events are being processed you can see this loop here which is very familiar for anyone who wrote an ITEX trigger before and then we look for the word return in the description this is why when there was word return in a description there were cases created and when we see that we know that customer wants to return an order automatically create a case we just say process returned for order number and order number is captured and then customers feedback is still there in the description of the case this is so what I've shown you as part of demo is one way to test those triggers right you see the cases being created in the UI but triggers could be much more complicated and would need a lot more logic to be tested how would you do that what you can do is you can write a test class it's right here it's an apex class and what's special about it is you have its test annotation on it making it a test class and second thing is there is a very important block of code here when you publish events between tests that start test and test the stop test those events are published only for testing and they do not affect event bus in your org and you can habla sh up to 500 of them for the testing purposes so what this class does it verifies that for the order number that we're testing with we have zero cases before we start before we publish events then the event is being populated and then event is being published and then inside the test we see what happens as as part of that we query the cases and we see that there is one case that came back and we expect customers feedback in the description so we see what what happened as a result of that trigger now these events change over time just like any custom object you can see that there's couple of fields here description order number but as we know things change in business and you might want to capture other information here just for demonstration purposes what I wanted to show you is there is something that we do to show you the structure of the event over time and that is event schema if you look at the events coming through the wire and I can subscribe here when I publish this event for example using this that event will show up is part of the stream and you can see that it has couple of standard fields and couple of custom fields order number and description as part of that there's a special string called schema there's a field on there and Jason and that allows you to look up scheme of that event with that payload at that time right that's the schema at that point and if I take that string there there's the rest api endpoint / event / event schema and you can look up what schema look like at that point all right with that ID now what happens when I add another field so let's say I'm adding a number field and we can just call it number so there's a new field here on the event as you can see now when I publish this again and you look at what happens on the wire there's another field here since we didn't fill out any values it will be no but this is now part of the schema and you can see that the schema ID has changed and now this new schema is part of the event payload and that's the event structure project I'd like to also point out that when you subscribe there's an option to get the payload in a binary more compact format the messages are actually Avro encoded so if you have a Avro it's supported by most major library or most major languages the libraries available widely you can use that to deserialize your events thank you yes and part of that part of that evolution of the schema is that you can still look at the old schema because events might be still in the stream with the old schema right so you can introspect that older schema using this API and you can see that it still has four fields in it so when you validate that event for example against the fields that it's supposed to have you can look at this scheme and see what fields are supposed to be there at that time so as event payload come goes out it has schema attached to it so there's some things you can do on your own we let me show you this we have couple of trailhead modules one is called platform event basics that's where you learn about defining events learning about triggers there is another trailhead module which is a little bit more advanced which is called building this a notification app and that was the basis for big parts of my demo that you can play with that as well and of course we have online help part of platform events dollarz guy thank you [Applause] do we have time for questions okay we have a little bit of time any questions go ahead do do we have a microphone and the limits of platform events in terms of how much you can fire I mean that'll vary based on you like your addition and also there's additional licensing options to increase it do you remember offhand what they are like a hundred thousand a day I think is a base level now it's a aspired in the context of an org and that org it'll apply to that or their limits you want you have a question up to 2,000 it won't always get mm it's uh it's it's kicked off and you know just we wait a little while and then we'll maybe should turn off the microphone and we can we can just answer questions


2 thoughts on “Platform Events: Inside and Out”

Leave a Reply

Your email address will not be published. Required fields are marked *