Build an app that consumes Adobe Experience Manager Events

Transcript

Hello everyone. Good morning, good evening. Thanks for joining in. I’m really excited to have you guys. We all developers, consultants, builders out there, and if there’s one thing that connects all of us here, it’s that we all want to build incredible end-to-end customer experiences. Event-driven architecture leading this way by a long run. It has made it possible. And we are seeing the shift of regular periodic processing to reacting to the changes in real time. In this session, I’ll share everything you need to know for creating an event-driven experience with Adobe. We will build an app that consumes events from AEM in real time and does something interesting with it. And while doing that, we will realize how easy it is to build an app using the Adobe Developer Builder. Before we go further, a few words about myself. My name is Sahil and I work as a Senior Computer Scientist at Adobe IOA Events Team. I’m passionate about building and architecting distributed rooms that are scalable and resilient. And in the last couple of years, I’ve really focused on event-driven architectures. During the pandemic, I usually find myself converting music and coffee to ideas. And eventually to code and software that runs on Adobe servers. So through this session, I want to share my love for our first consulting builders who want to create rich event-driven experiences for their customers. From one developer to the other, I want to share this working knowledge of building an app using the App Builder. And all this aims to make your journey even more big and playing on with the App Builder. Okay, and some of you might already know what is Adobe Developer App Builder, but don’t worry about the slide. There are a lot of technical jargons here. We will see everything in action in our hands-on demo when we build our consumer app. But just one line up for now. App Builder, everything that you need out of the box to build apps that extend to Adobe products. All you need to do, all you need here is in the box. And all you need to do is code just for your specific business logic. And everything else is taken care for you. It makes your life so easy. And once you use it, you’ll come to realize how much value it is adding in the developer productivity. You can build your app in around 10 minutes. Okay, and these are technical jargons. We’ll anyway see all those. Which will be very interesting. So here’s what we want to achieve. We want to build an app that consumes events. These events are generated by Adobe product, in our case, AEM. And this application consumes in real time and does something interesting with it. Okay, we will learn all the relevant concepts required to build and deploy such a consumer application. And we will also understand how an event that is generated by AEM is reliably and securely transported to the developer. And one promise out of the session that I can make right away is that you will have enough understanding of what is happening behind the scenes. You will know how to build an event consumer app. And you will know how to debug in case something goes wrong. And let’s play. All right, the stage is set. We know what we want to achieve. Let’s learn a couple of things first. So let’s start with the first part. We know how to achieve. Let’s learn a couple of things first. We have a AEM that produces event. We have an event consumer application that we want to build that consumes events in real time. And we all know these loosely coupled services, event provider and event core consumer find these… Like are these core components of an event-driven architecture? And the thing is that they are all miles apart. These services are independently developed, independently deployed, they are managed, scaled independently, they are using different technology stacks, they are totally coupled with each other. And this gives us a lot of flexibility in developing. But behind the scenes, what ties these two things together, even provider and even consumer, is I-O events, which you get as part of the event. I-O events is in the business of delivering events that are produced by, and they are external third party applications, the one that we will build. And all this happens in theory. It is scalable, you don’t have to worry about incoming scale, the throughput, the bearing throughput, it is reliable as it provides at least one delivery guarantee, and it has inbuilt resiliency. For example, the consumer app, there’s an outage. I-O events retries those event deliveries for the next 30 minutes to make sure that the event is. Okay, now you would ask me, you know about I-O events, from the context of our consumer application that we want to build, how do we consume from I-O events? Is there an API, can I-O events do some magic and push events into our system? Well, the answer is both. I-O is two ways to consume events. Events to your notebook that is deployed by the consumer application, or the consumer app can pull events by calling the events API. Pretty simple, right? Now, for our application, the question comes, which of these can, should we use? We can use the use case and the scale that we are handling. But if the throughput is very low, then probably push-based deliveries make more sense because otherwise our application will have to periodically pull the server, base a lot of resources, just to check whether there is any new incoming event or not. On the other hand, if the scale is not stable, or let’s say the scale is spiking in nature, where we don’t know how much to scale our consumer app, what we can do is we can build an app which can consume events at its own pace. So that app can call the events API and fetch events at the pace it can process those events. So probably pulling events from this API is preferable in this case. Okay, app, it’s a low throughput case, we’ll just run a couple of, so we will use this push-based delivery for our consumer. So we’ll use this push event delivery, but how do we bring this app into life? One brute force way to do that would be, perhaps write code, deploy code on server, manage the resiliency, make sure it is secure, make sure it is resilient, make sure uptime SLAs are met, and all this is a big rabbit hole, and it takes a lot of time, effort, and dollars to build such a consumer. And most of the times, the regular way of doing this is this one, the most inefficient way of doing this. And if you don’t have Adobe developer app builder, probably you would do this. And those of you who have taken this regular approach of deploying an event consumer, you will realize how tedious and expensive this process is. The app takes all these complexities away from you. And how does it do that? The answer is IO runtime. Let’s see what is IO runtime. IO runtime provides a serverless compute framework. And in other words, it allows you to run any code in Adobe’s infrastructure. And all the complexities that I mentioned, scalability, security, everything else is taken care for you. And moreover, integrated with IO events. There is an added layer of security behind the scenes when event flows from IO events to IO runtime. And lastly, we get CLI, SDKs, REST APIs, all those things are available in building things rapidly. The consumer app that build will run on IO runtime. Of course, this is the obvious choice now once we have the app builder. Sounds good? Okay, so we know everything we need to know for our event. Event will be produced by AEM, which is our event provider. It will be transported by IO events to our consumer application, which will run on IO runtime, which is hosted on Adobe’s infrastructure. And the consumer app that we will develop, so this app will simply forward the event to the Slack channel. And this is a simple use case I picked just for this demo purpose. You can build anything complex, anything that you can imagine here, reporting, analytics, complex processing that you want to do in case of any event notification. So the, yeah. For our case, we’ll just forward the event to a Slack channel. In this demo, all we are going to do is follow up CodeLab. So in case you don’t remember any of the, it is okay, don’t try to remember it. Just try to understand what is happening behind the scenes and how app builder really simplifies our life. Okay? This slides. And I’ll play a video for the demo. Full screen. So this is the hands that we have done to build the entire event consumer. And we start from scratch here. Okay? First thing we do is we go to the developer console. This is usually the starting. We get to discover all the things that are available to your, to our organization, the services, the APIs, and we can subscribe to APIs. We can create credentials to call the APIs. We can create event registrations that we’ll do in this demo. For now, let’s create a project with a template. We’ll select Project Firefly as a template here. This is getting rebranded to app builder. We all know that. Okay, I specify the project. I think it’s named under the link. Hello developers. We have workspaces predefined for us, stage and prod. So in this case, we have two workspaces. It was always a good idea to have multiple workspaces. It provides a kind of isolation for us. So if you want to build and develop and test something, we’ll probably do it on stage and we’ll move all of them to prod. Okay, so we’ll go with this predefined workspaces. And lastly, we’ll enable this IO runtime for our workspace. And we know why we need IO runtime now. All Zoom applications are returning on IO runtime. Okay, so the project is ready here. We have stage and prod workspaces and we have run time configured here. I think that’s where I have set things up using the developer console. Now what I need to do is actually develop the event consumer app that we have been talking about since a long time. Okay, and for that, we will use AI or CLI tool. This command line tool provides really easy and intuitive commands for us to initialize the projects and deploy the consumer application using the CLI. So what I’m doing here is the directory for myself. And the first thing I do, call AIO login. Basically CLI needs to know who am I. So it redirects me to the browser, I log in, and when I go back to the CLI, it knows who am I. And excuse this blue box, it is just to hide some security sensitive information. So we are logged into CLI now. The next thing that we do is AIO app init. This is the magic command that does a lot of things for us. I spent application name here, hello developers in AIO app init. It asks me a bunch of questions. Basically the project that we just created using the developer console, I select developers life and it asks me what kind of app I want to build. So in this case, I’ll select experience cloud app. Now this does a lot of magic behind the scenes where it is getting all the boilerplate code that I need for my application. It is configuring runtime behind the scenes. It gives me a very good starting point, a good starting project from where I can just start running things for myself. It takes a couple of minutes. Finally, once it installs and does everything, it creates a folder with the app name. So we have a folder here, hello developers. Okay, I open this in visual studio code to look at what we got. And this a source folder, a whole project itself. So we can see the actions, we have code here, we see a bunch of end to end test classes predefined for me. And we have a UI aspect of this application as well. So it creates index.html, index.ui related code that I might need for my application. And lastly, it has this bunch of configuration files that I can use to configure this project. Okay, let me hit pause here. And what I’ve… Let’s take a moment to realize that all we did was we created a project using developer console and moved to AIO CLI, we logged in and we just did AIO app in it. And we have this huge thing point, very useful starting point. All we need to do is just start, just to like start running things. And I don’t need to spend any time, everything else, all the plumbing, grunt work that I mentioned earlier is taken care of for you behind the scenes. Okay, so in this runtime action, what I need to do is, first thing I’ll do is I’ll disable the authentication. So basically I will fix an authentication token to get invoked, but with events run, security is there. So for events runtime integration, we don’t need to enable this authentication. Okay, so once all I need to do is run and magic command, which is AIO app run. This is your second best friend. The first one should be AIO app init, which saves a lot of time. So this AIO app runs, deploys this in my local host, UI application is running on local host, the runtime action that it created gets deployed on the runtime server in the Adobe’s infrastructure. It gives me a good starting point in the world. It gives me a way to invoke those actions manually, test our system and has a bunch of documentation. So to get started, let’s just call the underlying sample action that got created as part of this project. So when I click invoke, the action that is running on IOR runtime gets called and here it is what is returning. It is returning, I don’t know what that JSON is. So head back to the code, look at the sample code that got generated and try to understand things from there. So here we see there is an API endpoint and we are trying to call this API endpoint and whatever it returns, we have to return back to the caller URL in the browser and this is what was being returned the action also. So we know this is the code that gets called when the code is executed. So what we’ll do is we’ll remove this and just to warm up, we’ll add something else. So from my clipboard on this machine here, I’ll paste the code and what this code does is a very simple thing. It prevents the string event received and processed by the event and it just returns it back. Okay, this file, notice that AIO app run is not working and I go to my browser and well, the code that we just wrote is made available to runtime action that we just created, just modified and it is already hot deployed on the Adobe’s infrastructure. So in just a couple of seconds, what you get is whatever you write, it automatically gets deployed there and it is ready to be tested. We got the link here. So we know what to do. Our use case is to post this to a Slack channel. So what I’ll do, code with something that I’ve already created. This JavaScript code has a couple of functions which posts the event to the Slack channel. Okay, it’s a very simple point to the details of it, but it makes a post request to the Slack web book that we provide in the code. Okay, so it prepares the payload. It gives the initialised request to the Slack web book and finally, whatever it returns, it either returns us a success or error message. Pretty simple. So now we have that we wanted to build that this events to our Slack channel. AIO app run is already running. So that is already deployed onto our runtime action even before I shared this fact with you. So the next thing that we need to do is tie these two pieces together. The consumer that is deployed on runtime and we have AEM as an event provider. So I go to the developer console and create an event registration like express my interest in it. I select AEM as an event provider. I select what kind of events I’m interested in. We have a bunch of events. For this demo, I’ll use acid. What it means is when it will get uploaded to AEM, whenever it will get created, it creates a credit. Now let’s ignore this and specify the registration details, event registration details. Okay, and finally, the runtime section shows a brand new application that we just now developed and we just ran AIO app run. And with this dropdown, we connect these. And once we save this registration, all created from AEM, all the interesting relevant events that we subscribe to, to my runtime action. This is the part of our events it brings to the table. Okay, created events should get delivered to my runtime action. And finally, what is left is to test things out. What I’ll do is I’ll trigger an event from AEM and I’ll expect my consumer app to process those without. Channel there, I’m expecting all my events to get delivered. So I’ll go to AEM and I’ll try uploading a new asset there so that asset created, it gets transported by AI events to my consumer action that was just created. I’m creating a folder here just to keep things less messy. So in this folder will work. I look, asset one to AEM, asset one got successfully uploaded and I’m expecting an event here and I’m expecting an event here. So what do we do next? As a developer, we need clear ways to debug things. So we have this debug tracing in the developer console itself. So we go to debug tracing and we click on refresh just to get the latest events that were delivered. So in this tab, you can see the event deliveries that were made as part of this registration to your consumer. And in the request, we see it is an asset created event, it is generated by the AI provider and it shows us the payload. But in the response, we see that our event consumer that we just now deployed, returned this error. It returned an HTTP 500 with this error now. And the next thing we do is go around this, look at our code, dig into it, look at why we are getting this error. And we know things don’t work in the first attempt, they never work, we all make silly mistakes. So I made a silly mistake here is I forgot to update the Slack webhook URL. Corresponding to my channel there, I’m expecting the events to get delivered. So next thing I do is address this, the Slack webhook URL, I save it, the app run is already running, so it should automatically fix things. So I test this by uploading a new asset, two. The asset got uploaded, Slack channel, and yes, we got this new event for asset two in just a couple of minutes. How easy it is to build these things. So I go to debug tracing just to try and look at things, I refresh and I see this asset created event to asset two. And it’s so what is responded with HTTP 200. Okay, now you might be wondering, we talked about resiliency, the asset one event did not get delivered because the consumer had bugs in it. So what happens to this corresponding asset one’s event? To answer that, I travel and fast forward by two. So this video gets fast forwarded by two minutes and I click on this and I see this new event getting delivered. This is asset created event, it is corresponding to the asset one that was failing earlier. And if you notice here, this is X Adobe retry count two. What this does is in case there is a consumer error, it tries to retry all those events. So it uses it retry those events. So if you notice the timestamp in which the first delivery was done, it was around the second delivery at 11.04 and the last delivery happened at 11.06. Using exponential back of one minute, two minutes, four minutes into it. And whenever deliveries are there, you can identify it using this header X Adobe retry count. So it suggests that this is the second time this event was retried. Everything is successful. I go to my Slack channel, see my new event there. Of course, yes, we have it. So we end to end integration connected. We deliver app, we have the end to end consumer experience that is implemented in just around 10 minutes. Once things are done and tested, the last thing we do is app deploy, running on our local host, deployed onto a resource. For example, in this case, the UI application, which was running gets deployed, the servers gets pushed to CDNs so that it is made available to your consumers in no time. And the runtime action is also configured on the server. This is the last part of our app deployment. Once the step complete, end to end event driven application for us. We did all steps in around 10 minutes and we can realize how much easy has made things for us. Okay, let’s share about the demo. Let’s go to the slides. Yeah, I already read all we are doing is, all we have done in this demo is we have followed step by step instructions in this code lab. So I implore you to try this app builder, is its magic and just have fun with it, play with it a bit and you’ll realize how much value it is adding in our workflows. Okay, that’s all I wanted to share. Q&A time, if we have time to occur, we can take some questions. So, Kamsan, there are no questions in the chat board as of now. Okay. For the interest of the audience here, what we saw in your demo was that there were multiple touch points. For example, there was developer console, there was a ICLR. So are those multiple touch points required if I am onboarding onto app builder or could something else also work? Okay, yeah, thanks for bringing this up. So basically, in our demo, we use developer console and a ICLR. Almost every console can be done with the ICLR. But for this demo to get started, it is always useful to look at the web application because it is much more informative. In ICLR, to seriously know. So get started with developer console. Once you get hands on things to do things, quickly you can move on to ICLR. Or if you want to build some automations around all this workflow, you can use ICLR for that purpose. Got it. So like, thank you, Sahil, for this amazing presentation and demo. And I hope that everyone who attended this session learned something out of it and will probably be excited enough to try it out at their own time. So don’t forget to bookmark the links that we have shared in the chat box already. Because in case you have any follow up questions, we’ll be able to follow up in the forums out there. And don’t worry about the session recordings also. They will be made available in two to three weeks time. But again, I’ll remind you to bookmark the links that I’ve shared. So hope everyone had a great session and hope everyone took something away from this. And yeah. All right, thank you everyone for joining. Bye. Thank you guys.