Custom Adobe Experience Manager Assets Compute Worker with App Builder and Photoshop APIs

Transcript

So hi everyone, welcome to the section about custom asset compute worker with Adobe Developer App Builder. My name is Duy. I’m a software engineer in the AEM team and today together with me will be Dave Bench who is a senior engineer. It will be the moderator in the chat box. So if you have any questions during the session, feel free to ask there. Here is a brief agenda of the session today. I will start with an overview of custom asset processing in AEM, highlighting the important role of App Builder. We will go through a use case for which we need custom asset processing for and finally we come to the main part of the session, a hands-on demo of building the application from scratch. First, let’s take a brief into the technical overview. This diagram shows the assets processing layers in AEM. There are some out-of-the-box profiles that marketing practitioners can select and configure directly on the UI. If you have anything more than that, a developer will be needed to implement custom code that will be deployed on our runtime to run the custom processing. One example, as you can see here, is to call Creative Cloud APIs. AEM provides content automation as an add-on allowing you to configure your processing profiles that apply Photoshop magic at scale. Today, we will focus on the custom processing layer which allows you to even do more customized tasks. So, when do we need custom processing? The first scenario is when you call all the Adobe APIs such as Experience Platform and Sensei. In this case, all the API services are configured on the AEM console and you might want to leverage the out-of-the-box authentication that’s already supported by the Assets Compute service for this use case. Another class of APIs that you might view your custom worker for is the external third-party API such as Product Information Management in short PIM or CIM system to name a few. If you attended the keynote earlier today, you might have seen the demo by Dave having product info to the assets metadata on AEM assets. Another major use case is when you need a customized workflow which should run independently outside of the JVM environment of AEM. For example, you want to apply multiple steps of image processing with Photoshop APIs. We will see more details into that later in this session. And before going deeply into the use case, let’s have a look at the architecture of Custom Assets Compute Worker. In this case, AEM assets act as a client of the service. Changes in AEM are piped into IO events. They are then pulled by the Assets Compute Service as journals and dispatched to the custom workers to execute the task. We run the code, get the new image transitions and metadata, and return them back to the binary cloud storage which is synced with AEM assets. We will go into details of multi-step processing here in which we first need to call the Autotoll API to process raw image from camera. We take the result of that to call Photoshop Action API to generate the custom promotional image with a pre-defined Photoshop Action script. And finally, the promotional image is color tagged by the Content and Commerce AI which tells the color and their percentages to be required for printing. To get the clear results of each step, we will have three workers going from the most basic. The first worker only calls the library API to get the Autotoll rendition. The second worker gets the Autotoll rendition which is then the input of the next API call to Photoshop API executed on the Action script to get the promotional image. And then we come to the complete three-step worker, taking the result from the second worker to call the Content and Commerce AI, get the color tag back, and save them as metadata in AEM assets. Alright, enough diagrams. Let’s do some hands-on exercises. So I will open my browser on Adobe Developer Console. In order to create a new project, you would just go to the console and just select to create a new project from template. Then we have App Builder as the template for the project. Then you can name your project title as well as the app name. And by default, it provides you two workspaces for production and state. We come along with out-of-the-box runtime namespace. Of course, you can create new workspaces for different developers in your team or for different purposes. So I already have my project created here which comes with four workspaces. For example, let’s take a look into the stage workspace. For the Asset Compute Service Worker, we will need… So there are some must-have services for this, including IO Management API, Asset Compute, IO Event, and the runtime namespace which already comes out of the box. Because we are integrating with Photoshop API and Content and Commerce AI, we will need those services as well in our workspace. We don’t need to add an Asset Compute Journal because that is automatically created by the Asset Compute Service when we run the application. So we don’t need to add that manually. So once we have the project and workspace created on console, let’s head over to our terminal. So I will just use the AIO CLI App Logging. We need a live demo. And the CLI will come with a few questions that ask us to select the IMS org for the application. So I’m going to select Adobe IO. The next question is to select the project where we want to create the application. So I will select the custom worker work builder. And here there are several options for the extension points that we want to implement. Either that is the X experience cloud SBA that will be deployed on experience.albe.com or the Asset Compute Worker to be deployed on AEM. So we will select the second option. And after this, the CLI will automatically generate the code from the template as well as install all the NPM dependencies of the application. So in the meantime, I will just open our app in VS Code. Alright, so we have the code open now. And so let’s open the terminal in VS Code while the code is being lose-bred. Let’s see if it is completed or not. Okay, so, alright. Now as the template code starts to pipe in, let’s have a look into what it has. So first of all, because that is a node application, it will have a package.json and all of the metadata as well as the dependencies for your node application. And also because that is an application created with App Builder, it also has the app config.yaml which basically contains all the extension references for your app. In this case, we only have the one which is the Asset Compute Worker and the source slash dxAssetComputeWorker1. So we will go there to see into details what it has in the extension. So there is the extension config.yaml file that contains more details of your extension. So those include operation, worker process, the custom hooks for running the application locally, as well as the folder where the backend actions are located. And also all the I run time actions that are defined here to run your custom workers. So we can have a look at one worker. Well, this is the default worker that was generated by the template code. What it does here is pretty simple. It just checks the existence of the source file and it just copies one to one from the source folder to the destination folder on the end. And of course here you can add new custom logics for your worker to do things according to the me. One more thing here is that in order to run your custom worker, you will need to bootstrap your environment variable as that contains some credentials. I will just go to an example code of my environment variable. So environment sample. What it has here is all the AIO run time credentials for your namespace, including auth, namespace and API host. So all of them are already bootstrapped by the template. So normally you don’t need to enter them manually. The same for the service API key, which is useful for calling the APIs that your application is integrated with, such as Photoshop API. What is important here is that you need to provide a few more environment variables that are useful for running your custom worker locally. That includes the path to the private p5 for your integration and the integration file that you normally download from the Adobe Developer Console. And then in order to run the local developer environment of your application, you will need to configure either APS-S3 or Azure Storage. That just creates a local simulation of AM assets for your developer to run locally. So let me just copy what I already provisioned in my app. In V, we just use the namespace and just copy over here. And I will also use AIO CLI app login run to run the application locally. And what it does here is that it will deploy the worker action onto AIO runtime and it will spin up a local environment for developer tools that allow to interact with the workers visually. So in this UI, you can see on the top left, you can upload your images to the Cloud Storage of local UI. I already have a few images here, so I’m just going to select one of them. And under that, you can define all the permissions of your custom workers. So for the first worker, I’m going to select… Okay, so that’s already have worker off the box, so I don’t need to change that. And because that is a one-on-one copy from the source of the destination folder, so I just name it .dk.png. And then I just run with this now triggering the I run action to execute so that we get the rendition from the custom worker. So in a few seconds, we can see that now we have the .dk.png, which is the copy of the source file into the new folder. Now we will try to add more code into our custom worker so that it will become the first worker in our workflow to generate the out of home rendition out of the source file. So in order to do that, we go back to the package.json because we need to add a few dependencies for our SDKs. For example, we need the Photoshop API to call the API dependency. We also need the AIO SDK for the files and so on and so forth. And because we changed the package.json file, we will run npm install again. And then in the min-cap, I will just add a new terminal in a local environment in order to add the new custom worker. So we will also use the AIO CLI app login action. It will ask to select which template of the action that I want to select from. And of course, we are going to use the Adobe asset compute worker. Now we need to name the worker. So it will be under tone. And then, yes, I want to overwrite the config.yaml file. And then now if we go to the actions, we should see another one for out of home. So let’s have a look at the code. By default, it just has exactly the same code as the previous worker because they both come from the template. We want to replace this by the new code. That code, the other code, I will just show you what it does. So in this new code, we will import the file SDK from App Builder that allows us to upload files to the cloud storage. We also need Photoshop client for calling Photoshop API and VIA ID for generating unique ID for the 10 folders. This one is the same as before, just to check the existence of the source file. And we need to emit the files SDK. We create the 10 folder based on the ID. And we will copy the files from the source folder to the cloud storage so that it can be shared with Photoshop for image processing. And then we initiate the Photoshop SDK. And then we produce the Photoshop client. And with this client, we can call the out of home API and pull until the result is available from out of home form. And in the end, we just need to copy the file from the cloud storage back to the rendition folder of AEM and just do the final cleanup. So now we will just run AEM again so that the new code is uploaded to our runtime. And also we have a refresh section for our local. Okay, so now that the UI is open, we have the same layout as before. And because now we have a new worker, we will add a new religion to our definition here. And this one we will call the out of home instead of worker. And then we also name it the new name for out of home. And then we just click on run so that we have the new additions. And then we can also have a look on the right hand side, the request and the response of the workers. For example, the source folder, the religion, what are the workers and the name and target and so on. And the response which would contain the activation ID from IORuntime with this activation ID, you can either query your activation to debug or to query the activation logs as well. So in here, it also calls the activation log to this UI so that we can investigate the behavior of the activation. And those are the two relations that we got from the custom worker. So you can see that there’s also the advocate from the previous worker. And now we have a new out of home with our image writer as expected by out of home. So let’s assume that now we are completed with local development. We want to deploy the application onto IORuntime, oh sorry, onto AEM assets. And in order to do that, firstly in AIO app plugin, we also want to have another feature called get URL that basically return all the runtime URLs of your custom workers. And then we will use those URL for configuring on AEM. So I will go to my AEM UI and under tools, we go to assets, processing profiles. And of course, here you can create your new profiles. I already got one profile called left like section. So I’m just showing what is on that up. So in here I have three custom processing services. One for out of home that is mapped to the out of home worker. And then the second one for the graphic design to generate the relation, the promotional image. And then the last one is the metadata relation that will produce the color expression for our assets. And once you create the new processing profile, you can apply it to any folder in your AEM assets. So let’s say I go to project, I have a folder called left like section, and I’m going to just apply to that folder. So I’m going to AEM assets now under files. And then I go to project, left like section. And here I’m just going to upload a few images that we can test. And well, one of the benefits of using custom asset worker with App Builder is that now with all the custom workers running, that is completely outside of the AEM JVM. So we don’t use any resources of AEM. We don’t put any more load on the JVM. And this is really a separate process that runs on our runtime. So we have a few images here. Let’s try with the bicycle to see if we have some new relation out of it. So beside the default relations in AEM, we also see now the other core relation with just make with brightening our bicycle to work according to the other core API. Let me refresh the page to see if now we have the second image, which is out of the graphic design API. So this is a call to well, this is the result of the Photoshop API executing Photoshop action scripts. So with this one, we can process further for any like manual or something. And the last step of this process is to extract the colors out of our out of the image. So we open the assets metadata here. And yeah, so the colors name together with the RGB values are pulled from CCAI to be attached in the assets metadata. And I think this concludes our demo today. Let me go back to the slides. All right. And I hope that this section is a useful one for you to get started with custom assets compute work on AEM. All the questions should already be answered by Dave during the session. If you have further questions, feel free to post them on the experience link forum. Dave will share the link in our section so that you can follow there. And yeah, don’t forget to visit the booth in the Dev Live website and good luck with the competition. Thank you for your attendance and have a good day. Bye bye.