Cloud-native extensibility for Experience Cloud - What’s in it for Experience Manager developers

Transcript

Hi, my name is Ron Nagy. Welcome to Adobe Developers Live. We have a fantastic session for you today. This Monday, October 4th, I guess you could call this Adobe Developers Live Fall Edition. Anyways, hope you guys are having a fantastic beginning of October here. And welcome to the session. We’re going to be covering cloud native extensibility for ExperianCloud solutions and specifically, what’s in it for experience manager developers. So, AEM developers have been with us for years. We have a great community of developers. And as AEM has moved to the cloud, you’re going to hear about how we have brought some new tooling capabilities that will help developers to make the most of this transition to the cloud. Some great speakers today and fantastic content that we’ve got planned for you. So, stay tuned and let’s get started. Next up, we have Lani Stark, Vice President of Strategy and Product here at Adobe. And she’s going to talk about cloud native extensibility. Take it away, Lani.

Thanks, Ron. Hi, everyone. I’m super excited to share our cloud native extensibility strategy in Adobe Solutions, starting with Adobe Experience Manager. And I’ve got some exciting news as well. Earlier this year, I shared at Adobe Summit what we all knew, which is that there’s been an explosion of digital experiences across all services as brands try to adapt to the changing ways in which consumers want to interact, shop and entertain and everything in between. And this poses, I think, a great opportunity for developers to rethink what kinds of digital experiences fueled by content need to be delivered in order to drive engagement and consumer lifetime value. And this opportunity that’s posed is really in three areas that’s very much aligned to the Adobe Experience Manager strategy that I shared. One is that companies, digital businesses, need to be able to democratize content creation access across the organization. And this requires developers to innovate to make sure that content within Experience Manager is able to reach to other applications, surfaces that are needed, that employees across an organization need in order to create great customer experiences that really serve the entire customer journey. The second is to be able to extend content to every interaction. And this isn’t just the SPAs or branded websites, but also in-product experiences and mobile apps and other interactions within CARVs and other innovations. And this is why we introduced the GraphQL APIs and a slew of market-leading headless CMS capabilities. And these are ones that Jean-Michel will be talking more about in another keynote. And this is an area that, along with the GraphQL APIs, there’s also the core components that we use to help developers speed up the development of web experiences. The third is to be able to optimize those experiences, that content, with intelligence. So machine learning data about that content, what’s working, what’s resonating, and having that information can really help developers improve the interactions of the experiences that they’re delivering. And to further support this strategy and support developers and continue to extend and innovate on Experience Manager, I’m super happy to announce that Project Firefly will go GA December 2021 of this year, so just a few months away, and it will be named Adobe Developer App Builder. So for all of you who’ve been part of the beta, 500-plus of you, thank you for all the feedback. I know that that feedback was taken to make sure that this is a great developer experience that’s purpose-built to really help you have a set of tools and services that extend and integrate Adobe Experience Manager, as well as other Adobe solutions that will come and integrate with third-party applications as well. What is Adobe App Builder? It really is an end-to-end developer framework, all the way from the Adobe Dev Console to the command line interface to code to app. And it’s really purpose-built to be able to extend and integrate Adobe applications. And so we have included, for example, UI components that have the look and feel of Adobe-designed components to make you be able to create and innovate great experiences and applications, as well as make sure that there are the integrations and hooks needed in our Adobe applications so that you can integrate it with back-end systems as well. Besides being able to, with App Developer, extend your investments that you’ve made in Adobe applications, starting with Experience Manager and being an all-in-one solution, it’s also built in a modern cloud-native way and available to all deployments of Experience Manager, from on-prem managed services to cloud service. And this is because I really want to make sure that everyone had access to be able to use cloud-native technologies to further innovate on Experience Manager. And second, the scalable and global. So performance is important, and we are hosting these apps for developers across Adobe’s globally co-located infrastructure. So what can you build with App Builder? Well, many things, but I would consider it in two categories. First, single-page apps or front-end, really being able to create these cloud-native applications and combine multiple Adobe capabilities, as well as integrated with third-party applications. And microservices, so the back-end being able to connect it to other services and platforms. With Adobe Content, AEM, and Commerce, think of App Builder helping in three different key ways. One, with middleware extensibility, examples of that are integrations with external systems, connections to third-party. As examples of this, it could be a third-party configuration tool or a pricing and billing tool for your very specialized product that you may have, that you’re trying to build a greater experience, a greater shopping experience around. The second is core services extensibility. You might have built a microservice, you might have built some custom worker application, and this is a great way, using App Builder, to hook it into Experience Manager. And finally, user experience extensibility, as I mentioned earlier, we want to make sure that the capabilities and content of Experience Manager is made accessible to anyone in the organization that needs it through the applications they’re used to, and App Builder provides that opportunity to do that.

App Builder, as a reminder, December 21st, it’s going to go GA. Learn more about it at this link and also join our trial so you can get a head start on innovating with App Builder. So with that, back over to you, Ron.

All right, thank you so much, Lani. That was great. I am really excited that we now have what was Project Firefly, now Adobe Developer App Builder, out for customers to both try and then soon for them to purchase and use in production. So this is amazing news. Thank you so much.

Okay, next up, we have Michael Martz, Senior Director of Engineering for AEM, and he’s going to talk a little bit about the tech stack and really behind the scenes of what we built Adobe Developer App Builder with, or just App Builder, a lot easier to say, and kind of take us through the technology and the principles that we put in place when we built it. So over to you, Michael.

Hey, Ron, thank you for having me. I’m so excited to be here today with you and be given the opportunity to talk about the technology stack behind Adobe Developer App Builder. So let’s dive right in, shall we? App Builder is a complete stack that allows you and enables you to build modern cloud native applications in the Adobe cloud.

So what are the bits and pieces that make up the stack? First of all, there’s a command line interface, a CLI that allows you to bootstrap new applications and manage your projects. It also comes with SDKs that are set up during project creation phase. Those SDKs make it very easy to connect to Adobe APIs without having to deal with authentication or other complexities.

Next, there is a UI framework called React Spectrum that we ship alongside with App Builder. React Spectrum is exactly the same framework that we use within Adobe to build Adobe products. So using React Spectrum in your custom applications will enable you to build apps that look and feel exactly like Adobe’s products and blend in right away. Next, there’s a serverless runtime called IO runtime. With IO runtime, you can upload custom code into the Adobe cloud that we run for you on request or on event. That is very powerful, especially in conjunction with our event gateway IO events. IO events allows you to register to be notified when something happens in Adobe cloud of interest. So for example, when a new asset gets uploaded to AMAssets cloud service, what happens is that you can register a function in IO runtime to run when such an event occurs. That is a very powerful pattern that allows you and enables you to build evented applications in the cloud. App Builder also comes with a set of cloud services like data storage, file storage, and a web-based developer console that enables you to manage your projects.

Last but not least, there’s a whole range of developer tools like a debugger, a testing framework, etc. that you will need to build full-blown production-ready enterprise applications.

So these are the bits and pieces that make up the complete stack. But what would an application that you build with App Builder actually look like? So here’s a simplified architecture. We’re following something that’s called Jamstack in the industry. So it starts with a single page application served out of a CDN that acts as a client. From that client, you have access to your functions that you have deployed into IO runtime. That could be a microservice or something that we see often. Functions are being used to orchestrate various backend services.

From those functions that run on the server side, you of course have access to all public Adobe APIs, be it Creative Cloud, Document Cloud, Experience Cloud, or AAP, but also App Builder data storage, file storage, and you can also have and use custom events that are specific to your application. Last but not least, there’s also of course access from IO runtime to any third-party app that’s out there in the internet.

So Ron, let me take you through some principles and key ideas that led our development of App Builder. First of all, the most important principle and idea, and it would even call it as a mantra for us, was to focus on developer productivity and efficiency. We want to enable you, the app developer, to go from scratch, from the command line with a new app into production in Experience Cloud Shell within 15 minutes. We will see a demo of that right after.

The next key idea is around all the developer tooling that’s already out there.

There’s GitHub, there’s VS Code, and all these other tools that we already come to use and love. We don’t want to replace any of those, quite the opposite. We want to enable you to use those tools to build apps within the Adobe ecosystem. Where we added value was to make it easy to use those tools, for example, within the Adobe IMS login system.

Next principle, I would call batteries included but removable. You need a lot of infrastructure around the application like CI, CD, testing, developer sandboxes, etc. All of that is already there right in the box of App Builder. However, if some of those pieces are not to your liking or you have different requirements, they’re very easy to rip and replace with whatever makes sense in your situation. The fourth principle I want to call cloud native or zero ops. Your job as an application developer is really to focus on building your app, not to run infrastructure. That’s what we are doing. Adobe makes sure that the serverless engine is running, the CDN is there behind the scenes. All you have to do yourself is build the app and leave it to us to keep it running. Fifth key idea is to make App Builder open source. Head over to github.com slash adobe and you’ll find React Spectrum. You will find the CLI and the SDKs and a lot more.

Please go over, check it out, and maybe even send us a pull request. We’re very happy to review and receive those. The last key idea and principle is that App Builder works across all of Experience Cloud. It’s not just for AM, it’s also for analytics, targets, or whichever other solution you work on within Experience Cloud. App Builder covers your needs for extending and building apps on all of those.

Well, Ron, how does that sound? Thank you so much, Michael. Really great content.

Now we’re going to shift gears again and we’re going to go over to my colleague Dave, who’s going to show us App Builder in three acts, if you will. The first act is going to be kind of the getting started, getting your feet wet. And you’ll see similar to what Michael talked about, around 15 minutes it takes to get from starting a project to having it show up inside of Experience Cloud as a full-scale app.

He’ll show that and then jump into a couple of real-world use cases. And with that, let’s hand it over to Dave. Over to you. Thanks, man.

Thanks, Ron. Hi, my name is Dave Benge. Today, I am super excited to show everybody some demos of App Builder. What I really love about App Builder is its versatility and its convenience. From headless to head full, App Builder can do it all. Everything you need is right in the box. Today, I’m going to start off my demos by showing you what it looks like to work with App Builder. We’re going to build out a quick little app with the front end and a couple of microservices while giving you a little tour of App Builder.

I know they didn’t invite me to this party to talk, so let’s get coding.

All right, let’s get started. So we’re going to start our journey here at developer.adobe.com.

I’m going to go into the Developer Console.

All right, so my org has been enabled for App Builder, so I’m going to have this button here. This is Create Project from Template, and I’m going to click that.

So we’re going to pick this, which is Project Firefly Template. This is the code name for App Builder, so I’m going to click this.

Project title will be Dev Live Demo 2021.

And we’ll give it an app name. In here, we have IO runtime enabled. We also have workspaces. Workspaces allow you to separate your services, your APIs, and your events into separated, isolated environments. Right here, we have stage. That would be for QA. Production is the workspace that you would use to put your production code. And if you had multiple developers working on a project, you could add more workspaces in here. And then you could have a workspace per developer so that they could work against their own isolated environment before they promoted to stage for QA and then production.

I’m going to hit save there.

All right. We’re going to land here on our project overview page.

So in this, when I start, I’m going to start in stage, and then I’m going to move it to production. So what I’m going to do is I’m going to go in here right now, and I’m just going to add a service in.

So this is where we’d find all the APIs that are available for us to put into our project.

And I’m going to be moving rather quickly. We’re just going to put in the IO management API. We’re going to put that one in. It’s going to generate a key pair for our service account.

Console goes through and builds this out for us and downloads the key pair for us. Excellent. Save the configured API.

Okay, great. This is our workspace overview page here. It’s showing us the overview of the credentials and the APIs and services that are in this workspace.

So now we’re going to jump from here and we’re going to jump right into it and get to the file system. We’re going to start this part of the tour in terminal.

All right. So here I am in the terminal. I’m all set up. This is a quick overview or a quick tour of what it’s like to work with the app builder here. So I already have node JS 14 installed. I already have app builder CLI installed. I have everything I need and I’m ready to go. So what I’m going to do in my demo directory here, which I already have set up, I am going to do AIO. So our CLI, I’m going to use the app plugin and I’m going to initialize a project.

This is going to go out and talk with the Adobe developer console and get some information. First off, I have to select the org and I created our project in the IO org. So I’m going to select that. And it’s using my credentials and now retrieving the list of projects that have been created there and my project hit the top there. So I’m going to select that.

Now the next question it’s going to ask is which extension point we’d like to implement. So I can select either experience cloud or asset compute worker here. Experience cloud is a single page application that would be deployed into experience.adobe.com for my organizational users to use. Asset compute worker is an extension to AEM. And then I can also select none at all here and create a generic microservice for other applications to use. Or I could create a generic SPA that is not extending the experience cloud. In this case, I’m going to select experience cloud. We’re going to be building just out a little shell here real quickly that will be very similar to what we’re going to build, the way we built demo three, which you’ll see later on. The great thing about those choices is like Michael said, batteries are included, but optional.

All right, there we go. It is done setting up our project for us. After all that great heavy lifting that the CLI is done, let’s take a peek at this. You can use any, again, you can use any IDE you want, but in this I’m going to use visual studio code. That’s my favorite.

All right. So in here we can see that it created a package.json to define our project. It’s got the information there. And because we actually picked, we’re going to extend the experience shell. It’s actually gone in here and added in all the pieces that are necessary. So we added react, react dom spectrum, et cetera. So we have react spectrum in here.

This can be any single page application. The reason that this built it out with react is because react spectrum makes your application look like it’s part of the Adobe stack. It makes it look like it was an Adobe product to begin with, which makes it really blend in with the experience. You could use again, angular or some other framework here, view, whatever you want. But for this, we’re building it out with the best practices, which is react spectrum.

All right. So we’ve also, the CLI has also gone out and grabbed some other things for us and created some other files. So here is our main extension point configuration or main configuration for the project. And it defines the extensions that are in this project. You can have multiple extension points at this time. We only have one extension point and it’s including the detailed configuration from a lower subdirectory. What’s great about the way that it built this out is this allows for a lot of flexibility for us to build to add in many extension points without overloading this file. And then also we can separate the project into multiple modules, which are cleanly isolated from each other, allowing for more modular development practices.

Now dot ENV. So this file was created for us by the CLI. And what it’s done is it’s talked to the developer console and went out and found out all the information about our project. And then it’s gone in and added everything we need in here to run our project. Each one of these will be exposed as environmental variables for our application to be able to consume. And it’s gone out and actually pulled in the technical ID, the client ID, the technical account email, the technical account ID, IMS most scopes, everything that we need to be able to interact with the services that we bound with this project. And it’s pulled in that in automatically for us.

Dot IO. This is used by the CLI.

Okay, so let’s get to the fun stuff. So in here we see that the CLI has built out a directory for us DX EXE shell one. And that is our extension project home directory. Inside there, you’ll find the detailed configuration file. It outlines the operations, hooks, runtime manifest. So this is actually pretty important here. The runtime manifest, basically all your configuration for your microservices. And this is based off of the open whisk package manifest specification. And it defines the packages that will be deployed for your project. And inside each of the packages are a number of actions. And the actions are your microservices. And in this case, it’s actually built out one action for us or microservice. And that’s generic. The source code for this lives here. It’s actually gone in and added a whole bunch of other variables here, our properties. We have inputs, and that defines inputs that can be bound to the input every time the action runs. We also have annotations. This one is particularly interesting. Again, we do a lot of upfront work for you. This annotation here, which is require Adobe auth true, actually puts your action in a sequence. And before your action will be called, there’ll be another action that’s magically invoked that will make sure all the authentication criteria is met before invoking your action. So it takes a lot of the work off of your shoulders.

And then since we’re doing an extension point for the experience shell, it put in a web source folder for us. And again, our best practices and the built-in boilerplates are all tailored to React Spectrum. So this is a React Spectrum application here. If you look in here, you’ll see all the React Spectrum goodies and components and the main.

Everything is here. It’s great. It looks great. And then you go up to test. This is built-out unit tests for our microservices, end-to-end tests for our microservices. And then here is our microservices in the actions folder. Under here, we have a generic, which it built out for us. Let’s take a peek at that.

In here, it’s a really common generic template. Basically, what this microservice does is it brings in parameters, it logs a bit of data, it checks for authorization, and then it basically calls this endpoint, which is a testing endpoint that just returns some dummy data. And then it actually takes that after it gets the response and it returns it in the response back to the caller. Really simple, but actually quite useful because a lot of your use cases, you’re actually just calling a service, getting some data back and returning it. It’s set up for best practices there.

Let’s run this application and see what it looks like. I’m going to go to terminal and do new terminal.

Then I’m going to do aio-app. Actually, before we run it, let me show you this. This is neat.

Actually, if I do aio-app get-url, it’s going to give me the URL of the microservices we’re going to expose when we actually run this application. That’s in this endpoint here can be called by any endpoint that has authorization to hit that.

So we’re going to do app run here, and then we’re going to check out this application.

This application is going to be really similar to what we’re going to build, what you’re going to see in demo number three today. The experience shell extension react application, I’m going to show you in demo three, where we took this and did something pretty cool with it. All right, so this URL here, we’ll open it in the experience shell.

There we go. Excellent. Just a little react application with three views. And then in this view, it allows you to actually test your actions, which is great. So I can invoke this real quick, and now it’s calling the microservice for us and returning some data. So we can see that our microservices doing what it should, and it’s just a nice little test hook. So this is great. This little react app. So actually, if you go back in here, and we go to web source, web source components, we’ll go to home, and then I’ll close this, minimize this terminal a bit.

We’ll do… Oops.

Well, we’ll leave the fallout and just do that. Anyways, let’s go back there and see what we have. We don’t have a lot of time, so I’m going to run quickly through here. So there you go. You know, it’s updated the application live, and now our UI is showing the update. So now if we go back here and use this other URL, this is a direct URL. It’s going to call our application on a local node instance. If you look here, it doesn’t have the experience shell wrapper, and this is what our application looks like when it’s not wrapped in the experience shell.

Okay. So now let’s take this application. It’s no good if only I can use it in my development environment. Let us deploy this to production. So what we’re going to do is we’re going to do AIO.

I’m going to do app use. And when I bring this up, it’s going to ask me what I want to do. And I’m going to tell it that I want to change the workspace. I’m going to switch to another workspace.

And all we have is production. So I’m going to select that.

It’s going to ask me to override the configuration files. And there we go. Now we’re in the production environment. This is great. So now AIO app deploy. We’re going to now deploy this into the production environment.

Okay, great. We’ve successfully deployed this. Now, what we can do is we go back to the developer console. Now we’re going to go into the production workspace.

And then I’m going to submit this for approval.

I gave it an app title of.

Oops. Okay.

And then we’ll put in my email.

Okay. So we have to put a logo in here, so let’s put one in.

Put a note for the reviewer.

And then we’ll submit this.

Excellent. So this is ready to go. Now let’s play. I’m going to switch and I’m going to go to the marketplace and we’re going to switch the role and check this out.

All right, here we are in my, in the exchange that adobe.com. I’m going to go to my exchange.

And then I’m going to go down to Adobe IO.

And there’s the dev live demo right here. I’m going to review it.

I’m going to approve it.

There we go. It’s approved. So now we should be able to go over to a new tab. We’ll go to experience. Adobe.com.

And then I should be able to go over to my applications. And there’s the dev live demo live in my organizations app builder catalog. And I should be able to run it.

And there we go. Just about spot on 15 minutes. And I was able to deploy an application into production. There’s not a lot in the application, but this is a react spectrum application that has been published and is available for our organization. Please see Sarah’s session later in the afternoon for way more details than what I was able to cover here.

All right. Now it was a fun little tour of what it’s like to work with firefly. I mean, app builder, sorry.

Sarah has a great session later today as five Oh one where she’ll have a lot more detail than I have time to go into right now.

So now I’m going to show you some more code that I’ve been working on. So now I’m going to show you some more compelling demos that were based on real world use cases.

Experience manager assets now offers customers a new capability called content automation. Using Photoshop and Lightroom APIs, our customers can increase their content velocity like never before.

Our customers have data across a variety of systems. Personalized asset workflows may be inefficient if they are not integrated. How can a customer integrate third party data while maximizing the performance and responsiveness of their dam? In this example, our customer is using the power of AEM assets, but they want to enrich their asset metadata with data from their product lifecycle management solution. They also need to have content intelligence to extract color tags from their product images.

Finally, they want to create renditions that have a stylistic filter applied. Now with App Builder, we can take the core AEM assets capability even further. Leveraging App Builder, we can connect not only our AEP content and commerce AI service, but also connect to Microsoft Dynamics 365 to pull in third party data into the customer’s workflow. Let’s see how this all works.

All right, so let’s get to looking at the code here. What I’m going to do is I’m going to show you a project that Dewey put together for us. And it’s going to do just what we talked about in the preface for this, which is we’re going to create a custom asset compute worker, a number of custom asset compute workers that we’re going to connect into a processing profile on AEM, and that will be applied to a folder. So let’s start by checking out the App Builder project for this. So here’s the App Builder project that is our custom asset workers. So if you look here, you can tell that this is an asset custom asset compute worker extension, right? And then what Dewey has done in here is he’s added a number of actions that will fulfill the customer’s request, right? These are custom. In this one project, we’re going to have one, two, three, four, five different custom workers. And to take a peek at these and what it takes code-wise, I mean, if you want to look at the whole project, you know, very compact, not bad. So if we go in here and look at actions, let’s look at AutoTone real quick.

I’ll close this up so you can see it better.

So in this custom worker here, this action, this microservice that we’re going to expose to AEM, you know, it imports our asset compute here. Our asset compute SDK.

It looks like it’s bringing the AIO SDK and the Photoshop API.

It’s going to go down through here, initializes the Photoshop SDK here, goes through and basically uses that via the PS client AutoTone call right here. And it takes in the source and the rendition path. And then basically goes back and file copies to the destination on the output and then delete, you know? So, I mean, this is the amount of work that it took to create the AutoTone version that we’ll see momentarily. So let’s take a peek at what this looks like to wire up into AEM.

All right. So in here we have our AEM site and I’m going to go into tools. I’m going to go to assets.

And then I’m going to go into processing profiles here. So now after we’ve deployed our microservices into the infrastructure and they’re running on the Adobe cloud, we went in here and we created, or Dui came in here and created a custom processing profile right here. So we’ll take a peek at this real quick.

So when you look here, you’ll see that there’s a number of microservices that have been registered here. So AutoTone right here is going to be the rendition name. And if you look, it is connected to our custom asset compute worker, and then it’s connected to the microservice for AutoTone.

Now over here, we have graphic design and that is connected to our action or a microservice called graphic design and so on and so forth. We have two more down here that are asset compute workers that will actually return metadata. And this one returns metadata. And I believe that this one is product info out of the skew. This comes from the PLM and adds it into the metadata for the asset. So now once you have your custom profile processing profile defined in AEM, you can go in here and apply it to a folder.

In our case, we’re going to connect it to this one right here. And then now we’re going to go back to that folder. And let’s upload some assets and see what this looks like.

So I’m going to come over here. I’m going to go to assets, files, projects.

Here’s our folder. And there’s currently no assets in here, but I’m going to grab some assets from my collection here of assets.

So one of the great things here is as we upload these into the dam, the actual processing is being handed off via an event to the Adobe runtime platform, right? So it’s going off to app builder and invoking those asset microservices. So the load is not being taken up by AEM.

All right, so these are being processed. Another great thing here is when you are using app builder to build these microservices, they scale automatically, right? So as you add more and more demand, they’re going to fire up more and more workers to take care of the requests. So you get automatic scaling, which is great. So let’s look at one of these and see what it looks like. So if I go in here and take a peek at it, I can see that we have an auto tone rendition right here. Excellent. That looks great. We have a graphic design right here.

And those both came from our custom worker.

And then if we go over into properties, we can take a peek at the extra metadata that we added to this asset.

So we extended the metadata schema right here with product info.

It’s pulling back the SKU, the color, the t-shirt, all from the PLM, right? All this data is coming from the PLM and being applied to the metadata for this asset.

And then we have the color extraction here. And this came from our other call, which is Sienna antique white. It’s giving us some colors, color data.

Let’s look at one more asset.

While we’re in here, let’s take a peek at this guy.

All right. So now we’ll go over here and look at the renditions. We’ll see that there’s an auto tone.

Excellent. And then a graphic design.

Well, that’s fun. And then now let’s look at the properties and make sure it brought in the other metadata. So we have color extraction. Excellent. And then we have product info. And again, the product info came from the PLM system and was added to the metadata of this image.

So that concludes our demo on custom asset compute workers. If you want more information on this, Dewey has a session later in the afternoon today. And he’s going to go into great detail on how to create a custom asset compute worker and how to connect it to AEM.

This last use case started life much like our getting started demo I did back at the beginning of this session. This user experience extensibility example highlights AEM screens.

While AEM can deliver content to a variety of surfaces, delivering content to interactive screens for retailers, airports, and hotel chains requires AEM screens.

The AEM screens team is on a journey to accelerate our customers time to value. We’ve reduced the time that it takes to deploy new digital screens with AEM screens as a cloud service.

Now with App Builder, I’ll show you how we can speed up the process even more. With this demo, we’re going to use a fictional hotel brand Savoy Resorts. With hotels all around the world, they’re looking to install screens in six different locations. AEM screens offers them the ability to deliver both localized and centralized guest communications to their customers. Given their scale, they work with multiple regional IT vendors to deploy their digital signage.

Deployments like this are complex in nature and need to train multiple IT vendors.

Let’s look at how App Builder can increase the speed of deploying AEM screens. The Savoy Resorts team has created a simple app to streamline the process of connecting the physical screen to the AEM cloud service backend.

While they could have given the IT vendors access to AEM, this simple app ensures they don’t need to spend the extra cycles training various vendors.

AV field techs know how to stack four 4K screens and then how to feed them through an AV room a mile away. But do they really need to know AEM screens? This app shows how we can extend AEM to a custom cloud native experience.

Let’s check it out. All right, so let’s get started with this demo. This is going to be a kind of a tricky one to pull off. I have a couple of machines up and we’ll see if I can pull this off. And I have to play a couple of different roles here. If I could do voices, that’d be great. Then I can make it totally clear to you all. So I’m going to start this off in the AEM screens cloud UI. And I’m just going to show you that we have a few displays set up for our fictitious brand here. I have some parking lots and I have some locations to find like London, Dubai, Nairobi, and some other locations. Now, another thing that I have set up in the backend is an AEM screens author is I’ve set up some registration codes for our technicians to use. These are great. It’s a simple one code fixes it all type of registration. It makes registering a new player into the system easy as can be. So we have locations, we have displays. I have some channels defined and the channels have some advertising and those are on the displays. I have it all set up for our poolside. I have it set up for the back of the line. I have it set up for the back of the lobby, the parking lots, et cetera. I have all my displays and everything ready to go. I as a content author know what content I want to show across my brand in the different areas. Now we’re going to switch to a different role here. I’m now going to play the role of Joe technician.

Give me a second while I switch a couple things.

Now here I am. I’m in London and I have installed this beautiful screen. It’s right near the reception. It’s looking great.

I got the player up and running on here and now I need to register this player with the AEM screens backend. So as a technician, what I need to do is I need to come in here and do the configuration to pair this with the AEM screen server. So what I’m going to do is I’m going to go to cloud mode here. And then I’m going to use the code that they gave me, the registration code, and I’m going to see if I can type it in without messing it up.

All right. You would think as a technician that did this day in and day out, I’d probably have this memorized by now, but I don’t. Okay. So now I’m going to register this. So now registering the player with the backend is now bound that player into our AEM screens instance.

And now the AEM screen, the player is ready to go. It’s just waiting to be put onto a display, which will tell it what content it needs to play. Right.

So as a technician, now what I need to do is I need to go in and configure the screen to the display. So what I’m going to do is I’m going to fire up my mobile device and here I am on my mobile device. And I wish I could do voices, then you’d know as the tech still. So I’m Joe Tech.

Joe Tech is going to have a lot less apps here. Unfortunately, I am a developer and I have a lot of applications in my experience cloud. So I’m at experience.adobe.com right here. And I am going down and I’m going to scroll down and find my app builder catalog. This is going to show me the app builder apps that have been deployed for my organization.

So now there’s a number of apps in here because my organization is really an app builder. We love it. And then down here, I see an application called the sign player to location. So I know where I’m at. I’m standing in the London lobby of this hotel. So this simplified application allows me to just say where I’m at. I’m going to do open locations. I’m going to go down to London and then the application is going to talk with the AM screens back in and get us the displays that are sitting there that are undersigned. And I’m going to look down and I’m going to find out, okay, there I am. I’m in the lobby. So now I’m going to look at this screen that’s right in front of me with my mobile device in hand, right? So I could just enter this and hope that that’s an L and not an I. All right. So let me double check this code with the screen player code.

Okay. That looks right. So now when I hit assign here, it’s going to assign this player to that display.

Okay. So now the player in the background will be going out and talking to the AM server. It’s always talking to the AM screen server in the background, but it will find out that it’s been assigned to a display and that there’s content there and it will download the account content and now it will start playing. And now we have a beautiful ad behind our lobby here and I’m going to move on. It looks like the next place I got to go is the parking lot. So I got to go install some screens in the parking lot and do this process again. Quick and easy. And now we have live content in the lobby.

This is the end of our demo.

All right. So that was amazing. Thank you so much, Dave. Great visualization and demos of showing really what’s possible with Adobe Developer App Builder. I just want to share a couple of things about the sessions that relate to App Builder or Project Firefly. They’re all in the agenda called Project Firefly because we didn’t rename them.

We didn’t want to spoil the surprise. So all you do is go to the main page for the Adobe Developer Live conference. Scroll all the way down to the bottom after all the speakers and you’ll get to the section on sessions. And so we have a bunch of sessions.

Sarah is giving one right after this introduction to Firefly. We’ve got a deep dive, technical deep dive. I think Meryl and Maddock and some other folks are doing some technical deep dive. We’ve got CLI. Jesse and Shaz are doing that one. We’ve got Carmen doing a session on the console. We’ve got a whole bunch of folks doing sessions about pretty much every aspect of this. So in addition to we’ve got AEM team members who were doing sessions on how to do a deep dive on how you can use Firefly with AEM. So it’s going to be awesome. Definitely check out some of the sessions that are listed here and join us. Talk to us. We’re all here. We’re all available.

Chat with us.

Yeah, definitely make the most of this conference. And even after this conference is over, I host a live stream every couple of weeks and the next one is this Thursday and we’ll do kind of a recap of DevLive. And any questions you’ve got, come on over to that live stream, which was called Exploring Project Firefly, but certainly now is going to be named Exploring App Builder. I think Exploring Adobe Developer App Builder, it’s a little bit long, so I think we’ll shorten it just to App Builder. All right. And then last, definitely reach out to us in terms of community. We are available on Twitter at Adobe devs, hashtag Adobe developer. And then on YouTube, as I just mentioned, the YouTube live stream that we have.

We’ve also got a whole host of old previous sessions that we did as well as tutorial videos up there. And then finally, Experience League. Experience League is where we are super active. Whenever you’ve got questions on how to use App Builder, definitely reach out to us there. And there’s even, I guess, a game that you can play that’s part of the conference. So there you go. Have an awesome conference. Thank you so much. And we’ll see you in the next session.