Build Event-Driven Experiences with Custom I/O Events

Transcript

So since we’re at 1115, I’ll get started. Good morning. Good evening. Thank you everybody for joining our session. Today, myself and Sangeeta would be talking about building event driven experiences with custom I events. To start with, we’ll start with a quick introduction and the product manager for runtime and events. You must have heard about the app builder J announcement yesterday. And these part are the part of the framework, both the products and over to Sangeeta for a quick introduction. Hello, everyone. My name is Sangeeta Krishnan and I’m a computer scientist. I’ve been working with Adobe I O events for the last five years and I’ve been working extensively on custom I O events. So over to you, Kanika. Thank you. Next slide, please. Here who we are and we started with the introductions in the next 30 minutes. We’ll cover with why event driven thinking about the overview, a quick introduction to custom I O events, how to use custom I O events and Sangeeta then would go through amazing demo for how custom I O events are used. We will try to reserve some time for Q&A. So we’ll start with we’ll try to reserve some time for Q&A. But in case not, please feel free to add everything in the chat pod and we’ll keep addressing the questions as well. So we’ll get started. Nowadays, everything in today’s world is event driven. I mean, talk about any businesses, all businesses right now need ability to react to real time events. And the businesses want to deliver customer experiences. And they have to be timely, targeted, effective, and obviously a lot of personalization that is needed in this times. And this actually opens up a lot of opportunities in the real world, where digital businesses can respond to real world events to innovate, create experiences, and be efficient. And this actually drives to the thinking of event driven, which is something which is event centric and digital business strategies are actually trying to guarantee continuous processing with this event driven thinking. Next slide, please. So a quick use case of this event driven solutions or event driven thinking comes in from a simple example on any of the ecommerce website, which most of us use nowadays, for example, let’s talk about Amazon. A use case of cart abandonment. For example, you are a customer who’s putting something into the cart, and is ready to check out. But for some reason, you start comparing prices and you do not complete the checkout. What happens at this time, this actually gives the business an opportunity to convert or make a conversion of the abandoned cart that was left. And this can be actually done by events. As simple as just fighting an event, when you see a cart has been abandoned for a couple of minutes. And that then gets delivered by the webhook to an application, which could probably send some discount coupons or some offer or personalized email to you, which probably would help you complete the purchase. This is just one example. But in today’s world, you would see every business, every vertical, every industry touching upon a lot of real time use cases that are needing to be responded right away. Next slide, please. So now I’m going to talk about what are the characteristics of the event driven architectures. If you see in the diagram, we have a producer, a consumer and a broker. Now, what iEvents does is we are actually coordinating the delivery of an event from a producer to a consumer, which the producers if you see on the left hand side are all the Adobe services. And on the right hand side, if you see are the consumers that are third party developers. Now, getting more into details, events, if you see here are being delivered through the broker in near real time experiences. This will actually give consumers an opportunity to respond to the events as soon as they occur. And both the producers and the consumers are decoupled from each other. Producers would not know which consumers are listening. And consumers are also decoupled from each other. And each consumer sees all the events that are coming from every producer. Most of our event producers, as I said, are all the product services, or event consumers, our partners, ISVs, and third party developers, or other Adobe services as well. Now, talking about custom events, custom events, as you know, app builder was just announced GA yesterday, and custom events are the third party developer events, or an opportunity to all our ISVs on the third party. Actually, events from their apps or the cloud native applications or the microservices, it’s actually giving you your applications an opportunity to tag the chat or interact with Adobe services in a bi directional flow. And all of this is loosely coupled, if you see independent, asynchronous and obviously, it can be scaled across services on the platforms. All of this is based on a pub sub model, which actually allows messages to be broadcasted to a different parts of system very asynchronously. And as we know, pub sub simply denotes publishers publishing the messages, which you see on the producer side, and consumer consuming or subscribing to the messages. And all these event notifications in these distributed applications happen on the go. Now talking about consumption, how a consumption of the event would happen. consumption of the events can be done by web hook on journaling and sangeeta is going to talk more about it in the upcoming slides. Next slide please singhita. Now, if you see if you see some events in the diagram, yes, we have a developer app builder GA. And custom events is a part of this offering. What custom events does is it would give you an ability to publish and consume custom events with support of either the method of books or journaling. And customer events are all these events that your app would be generating and talking with the Adobe services on the Adobe platform. Next slide please. Now, custom events talking more about it would allow all of your native applications to emit events and integrate with our products in a bidirectional form. And we have built custom events, basically keeping some product principles in mind. The first one is the open event specification on which we call this the cloud events format. We generally recommend and we strongly tell everybody to adopt to this standard, because cloud events is a new specification for describing the event data in a very common wage. It’s a new, I would say defining protocol or standard, but cloud events are going to simplify the event declaration and also delivery across services platforms. And obviously, it’s going to add a lot of interoperability across services and platforms within and outside Adobe. The next product principle we’ve been taking, building upon customer events is the simple event delivery mechanism, which I just showed you in the diagram before. It’s a simple pops up model. We guarantee near real time responses coming through the I events. And also all of this helps building more and more cloud native applications. So you’ve built a cloud native application or you have built a microservices and you want your service on an application to sign events, cloud, then that’s my events would be answered. Next slide please singita. Thank you. Thank you. I’m I was just about to say I’m going to hand over to singita. And now she’s going to walk you through how we can use customer events, and how the whole flow works from from the developer experience side. And over to you singita. Thank you so much. Thank you, Kanika. So let us look at how your app can be a customer events provider. So now what is a provider, a provider is any solution or product that emits events. Now consider an ecommerce website. In an ecommerce website, we, you need to first register as a seller in order to be able to sell event or sell products. So this is similar to the provider. It describes the source of the events, and these events and this provider is only visible to all the users within your organization. Then all the various types of products that you can sell on the ecommerce website that is similar to the event metadata. event metadata is the type of events. For example, let us consider analytics triggers. Analytics triggers indicates that provider analytics triggers indicates that these are trigger events coming from Adobe Analytics. And the various type of events include something like cart abandonment, which Kanika just spoke about, or maybe a session start, keeping track of all the number of all the sessions that are currently active, and so on. So once you register as a provider, your provider and the event metadata, you’re now ready to publish custom events in the cloud events format. Now that we have learned how to publish events, let us see how we can consume them. You can consume events either by the push or the pull mechanism. Push mechanism means we are pushing events to your web book, which can be any web action or an IO runtime action. Suppose your web book is down for a certain period of time, then we keep retrying the failed deliveries until it is successful, or the number of retries have been exhausted. The events that are published your web book are delivered in near real time. You can also opt for batch delivery support, which will be very useful in order to increase the performance during high throughput times. Now suppose you lost your suppose your web book was down for a very long time and the number of retries was also exhausted. The event may be dropped, but you can still consume them using the pull mechanism, which is through journaling. Journaling allows you to pull data from the journal at your own pace. You can also search for certain events. Suppose you have a slow consumer, and you are not able to process events at the way at the rate at which it is being published to a web book, you can opt for journaling. So you can journaling is based, it’s a hypermedia based API, which means that the link to the next pointer is present as part of your headers, and you need to keep traversing the next link in order to fetch all the data from the journal. The data and the journal is retained for up to seven days. In order to get started with custom IO events, there are three ways you can either opt for using the AIO CLI, the AIO CLI provides very easy and intuitive commands in order to manage your providers, your event metadata, all your registrations, you can simply follow the steps that are there to guide you for each command that are present. You can also use the also have the AI management API for our API lovers. In order to manage the events programmatically, it provides a wide range of API’s for you to create your providers delete providers, create the event metadata, update them, and also to manage your registrations and your journal web hook endpoint. We also have the events SDK, which is a node GS wrapper over the IO management API, which is easily integrated into the Adobe developer app builder. Now let us take a look at certain use cases where custom IO events plays a major role. The first use case is that of a funneling system. Consider you have a system that produces events at a very high rate, say at around 500 events per second. However, there’s a receiver that can process only up at the rate of 100 events per second. So ideally, what would you do in this case, you would probably have a queuing system like Kafka, which will help you know publish where you can publish events and then you can consume them. But then there’s a there’s an additional overhead of maintaining the infrastructure for managing these queuing systems. So here, custom IO events can play a major role. This is a sample architecture of how it would look like the client solutions that publish at the at the rate of 500 events per second published the customer events endpoint, we have an app builder, we have an app that is created using the app builder that pulls events from the journal batches these events and publishes it to the slow receiver, the slow receiver then can then process those batches of 100 events. And probably it’s probably updating a dashboard or had or sending emails or there could be various other use cases. Let us look at another use case. Suppose you are receiving events from certain Adobe products themselves. Like it could be cc libraries, it could be from am and you need to transform the payload or you need to enhance that payload and it needs to be published to various other channels. How can I custom IO events play a role in this in this use case. So you have the Adobe provider that is publishing events to IO events and you have an app that is created using the app builder that receives these events either by registering it as a webhook or an IO runtime action. Or you can use the journaling API to fetch these events. You can then transform these events and publish the same to the customer events endpoint. The custom events can then be subscribed to by the various channels by the various users and organizations, which can then be processed for various purposes. And now let us look at a third use case. Suppose a company wants to maintain a real time dashboard that needs to be that needs to be updated based on the usage. For example, let us take an example that the company publishes various articles or videos on multiple channels and they want to see how their content is performing on various channels. Then they want to get an a real time performance on their content on various channels and then act on the result to derive retention strategies. Let us take let us see this example with the help of a demo. First, let me go over the architecture. Here, we have custom IO events arising from various Adobe client solutions that are being published to IO events. We then have an app that is created using the app builder that uses the journaling API in order to fetch these events and update the dashboards. In this particular use case, we are using a journaling API in order to fetch the events. In the next talk, which is going to be given by Sahil Gera, you’ll also be seeing how you can use the webhook option or register registering your app as an IO runtime action in order to process events. Let’s go over the demo. So here is a sample with here’s a sample app that has been created that has the number of active users, the top articles in the last 24 hours, the top videos in the last 24 hours, and the various categories that these articles belong to, in this case, World Health and COVID-19. So let us simulate an action that is published by a client solution to the custom events endpoint, which is eventsingress.w.io. You have the type which is the type of the event and the source which is coming from the provider ID. We have the sample event that contains test news three and the categories that is cricket, sports and Australia, and also the video. Let us publish this event. When we publish this event, we see that the we see that the data is being updated in the dashboard almost immediately. We have we see that the number of viewers is increased by two because one is coming from the article and one is coming from the video. We see that test news three has been updated in the top 24 top articles in the last 24 hours, the video has been updated. And we also see the categories have been updated. Now based on this data, the client can decide either to promote test news one because it has more number of views, or it can choose to promote test news three and two, since they have lesser number of views, probably they require more ads in order to draw attention to those articles as well. Or if they see that a certain category is trending, for example, if sports is trending, then probably they will try to find more videos and articles that belong to the sports category because probably people are interested in those categories more. So let us see what went in creating this dashboard. Let us first look at what is required from the point of view of the IO console. You create a Firefly project on the console, and you need to add the IO management API, which is required to add a certain scope to the JWT token that is required in order to make the calls to the various IO management API and the even to publish the events to the customer events endpoint. We will then go to the code. Here is a sample here is a code that has been generated using the IO app generator, we then modified that template in order to suit our needs. In this case, we are using the events and the state modules from the IO SDK. The events module is used in order to pull events from the journaling endpoint, the state state module is being used to store the last pointer from where we had read from the journal. And once we every time the action is triggered, we use the the fetch the latest position from where we had read and continue reading from the same position. We also use the a IO lib IMS in order to keep generating the JWT token based on the private key that has been provided in the environments file. We also have the manifest dot YML where we list the various actions that we need to create. We also have triggers and rules. So this particular action needs to be executed every one minute in order to fetch data from the journal, and it needs to update the dashboard. So every one minute, we keep activating this particular action, it fetches the data from the journal that has taken place for that whole one minute, and then it updates the dashboard. We also have the AIO CLI. The AIO CLI provides very helpful ways in which you can create the provider, you can create the event metadata, you can also manage your registrations using the same. You can also once you have created the app, you can very simply deploy the app using a IO app deploy, which will deploy all these modules create these actions in Adobe IO runtime and can be invoked using simple URLs. We have a lot of resources for you to get started on IO events on customer IO events. There is an extensive API page that lists all the IO management API. And also you can find more details on the cloud event spec on the cloud events GitHub page. We also have extensive documentation on using the AIO CLI on using the SDK and also using the customer and also for a general IO events overview. We also have several code labs to get you started with how you can build simple apps using the Adobe Developer App Builder, simple apps that use the triggers and rules in order to set up a common job in order to use the journaling API in order to register your app as a runtime action. You can get all such examples through the code labs. Now I would like to I would request you to think about it for a second on how customer IO events can fit your organization. And would you like to do a POC for your idea? Do check out all the code labs to help get all the help you can add at the links that will be provided to you with the help of this presentation and also in the chat. And do reach out to us if you have any questions. We are now open for q&a. Thank you. Perfect. So there’s a question from Roger that says also does this work using a CDN like this execute executed on the edge servers or comes all the way through the origin? Okay. So if there’s a way in order to publish like, all we need is an event that needs to be published to the endpoint, which is a customer events endpoint in the cloud events format. So as long as you’re able to provide a payload that fits the needs and publish that endpoint, it should work. Kanika, you have any other suggestions? Yes, I think. And adding to that, it will work from any origin we recommend using our app builder framework because all these services are tied together very strongly. So it would be experience and I would say a smaller DTL. I’m happy to take Roger happy to take your questions in a DM or maybe I can reach out to you separately. If you want to discuss this more. Next question from Muthalagu. I hope I’m pronouncing your name correctly. So he has a use case that says show the retargeting banner in the website at the same or the next visit when someone left the page before completing the form or without the purchase. So I think this this is perfect. And it aligns with what we’re talking about something similar to a carton do you abandon men, all you would need to do is trigger a custom event that after consuming the API, which would then be able to take the next session and generate an event every time a person has left without completing a formal purchase. We do have a blog outside, which actually give details and I’ll share the reference of the block to another one from Roger, which is I noticed there is there’s a separate console for cart abandonment event driven experiences. Is this a part of Adobe IO or separate product. So Roger, we just have Adobe developers console, which is our standard one place for all building all these integrations. All you need to do is just have an enterprise login and to an Adobe ID. Once you log into that, there’s all the product API’s events and services are available within that console. There Carmen Sutter did a session yesterday on console and it has a details if you want to know more about console, we have also documentation available on how to get started with Adobe IO console on developers.adobe.com. That is our website and I’ll post a link here. Okay, um, and another question from Tina. Oh, sorry. So Tina is yeah, telling us to get the survey done for the session. But besides this, in case you have any other questions, we will stay here for another five minutes. Happy to connect with you if you have use cases you want to discuss. And also we have experience league forms, you can also reach out to me on kgarad.orobi.com in case you have specific questions which you want to discuss our use cases. Yeah, thank you so much for taking our time. We are hoping you’re going to brainstorm more about how we’re going to be part of the event driven scenarios and EDS and implement your business to respond real time. Feel free to post questions, we’re going to be here for another five minutes. And in case there’s something that comes across, feel free to reach us out on emails or the experience league forums.