How to ingest and process assets into Experience Manager Assets as a Cloud Service

Transcript

Hey everyone, thanks for joining Adobe Developers Live and joining our talk, How to Ingest and Process Assets in AEM Assets as a Cloud Service. My name is Dan Kelso, I’m a Senior Computer Scientist at Adobe and working on the AEM Assets team. And I am joined by Tanya. Hello, I’m Tanya. I’m a computer scientist working in the Asset Computer Services team. Nice to see you all here today. So for today’s talk, there’s kind of two main takeaways we want for you to get out of it. First thing is how with AEM Assets as a cloud service, you can ingest assets into the AEM repository and some of the new features and capabilities of the platform to enable you to do that more efficiently. And then the second thing is once those assets are in AEM Assets as a cloud service, how you process them to get the maximum value out of those assets that you already have. We will reserve some time for Q&A at the end. So let’s go ahead and get started. So starting off with asset ingestion, if you’re familiar with AEM Assets, or if you’ve worked with a damn tool before, you’re probably familiar with asset migration, which is our first kind of use case from the asset ingestion side. For migration, you’re dealing with thousands or maybe even millions of assets that you need to get from one source into the AEM repository. Traditionally, we used a tool like ACS AEM Commons Asset Ingestion Tools. And now with AEM Cloud Service, that’s actually built into the product. So there’s a feature called AEM Assets Bulk Import that directly through the product allows you to ingest thousands or millions of assets into the AEM repository. Another common use case is where you may have a creative or a photographer or someone on site that’s creating hundreds or maybe up into thousands of assets, they want to be able to get those from their machine to the AEM repository. And AEM Desktop continues to be the tool for those use cases. We have enhanced and optimized AEM Desktop for cloud service and performance getting assets into AEM, but it is still the tool for doing that sort of use case. Our final use case is not uncommonly a customer may need to import assets into the AEM repository from some third party system on a regular basis, some sort of integration type use case. And traditionally, the way that we would do that either is through the Java APIs for AEM assets or the AEM REST API. Now with AEM assets as the cloud service, we would recommend you use the AEM Upload Tool. This tool has been built and optimized for importing assets into the AEM cloud service repository, both for performance as well as reliability. So I highly recommend taking a look at that rather than writing Java or REST calls directly. So starting with the bulk import use case, this use case is again for migration or when you have a large amount of assets, say a new catalog year or something like that, and you need to be able to ingest thousands of files from another cloud service. So you can import assets as well as actually metadata. So all of the properties associated with those assets and the structure of those assets into the AEM repository. We can support direct transfers from cloud storage services such as Azure Blob Store or Amazon S3. And essentially the process works by the system take the AEM system takes a look at all the blobs or files as we generally think of them on your cloud storage. It then evaluates those against a set of rules that you create. So you can create rules to decide based on content type, file names, file sizes, whether or not those assets should be imported. So if you want to exclude certain files, exclude certain directories, you can do that. Once it’s done that it creates an upload and download URL and then actually does a direct binary transfer between the clouds to transfer those assets into the AEM repository. That’s really important because that allows us to have maximum performance there because it never hits like a local server anywhere. Just going cloud to cloud streaming right on through. Once all of that’s done, once all the files are imported, it’ll then apply the metadata on top. Now it is important to note that that metadata is based on the target folders for those assets inside of the AEM repository. So you want to make sure that you understand how the files are going to get mapped from your Blob Store into the AEM repository. So let’s go ahead and demo that. So to open the tool, you go to tools, assets, and then bulk import. You can select the configurations, which you can have many. They have storage settings, so the username and password for your storage. Sources, which includes both the metadata file as well as the folder to look at and then target. You can check it, which basically checks the syntax. And you can do a dry run, which will actually tell you how many assets and about what size those will be imported. So we’ll go ahead and run this here. And the run can either be run immediately, which is what I did, or you can schedule it, which allows you to schedule it ahead of time. I’ll go ahead and view the job history. Job histories allows you to look at the different imports. If you rerun it multiple times, you can see the various times the job is run. This took about four minutes. I’ve sped it up here for demo purposes because no one wants to sit here for four minutes. But you can see here it shows the dates, the user that started it, as well as the log as it goes on of all the actions that are being performed. So now that should be wrapped up. And I can select that again to view the actual assets that have been imported. It’ll take me right to that so I can take a look. And you can see here it’s actually started processing them already. They have some thumbnails. So the other new tool on the ingestion side that I want to mention is the AEM upload tool. The use case here is for an automatic or manual ingestion use case. So you can use that for some sort of integrations as well as you can actually call it through your command line if you’re, say, a fairly technical person to be able to import assets. It will support importing the assets as well as the structure. So if you have folders containing folders containing assets, it can import all that. It does not support metadata. But then it’s also available either as a Node.js dependency. So for any Node project that you’re using, you can import that library directly. Or it’s also available in the Adobe IO or AIO CLI as one of the imports there. So the process for AEM upload works pretty similarly. It gathers up a list of files based on what you give it. So if you give it a folder, it will recurse down through there and gather up those files. If you give it a list of files, it takes those. It then creates upload URLs for each one of those, puts the binaries into those upload URLs, and then finishes the upload to combine it all together. The important note there is that that is a performance optimization, allowing the tool to really rapidly upload files into the system by breaking them into different parts. When I was preparing for this demo, one of the things I did put together is this 35-line import appliance just to kind of show how easy it is to use this tool. So the key dependency here, the thing that really makes the magic happen, is that add Adobe slash AM upload import there, a require there. So that imports the AEM upload library. This is written in Node.js, by the way. And in this case, it’s actually going to do a recursive import of any directory that you give it through the command line. Most of the code here is really the import statement, the setup, parsing out the command line, setting up Winston, that sort of thing. You can see here the actual code at the very bottom there is really only about eight lines. The library makes it very quick and easy to write these sort of import appliances. It does also allow you to do some things that I didn’t show here just for the sake of brevity. Like for example, you can map file names or directory names. So for example, if you wanted to change the structure of your directories, but not move a whole bunch of files around on your system, you could do that. Or if you have file names that may contain characters that aren’t valid in AEM, which there are some, you could filter those out ahead of time. Now, so what I do want to show too is how through the AEO, the Adobe IEO command line, you can use that AEM upload tool. So let’s go ahead and show that. So the first thing I do have to do is I have to create a local user. This is a cloud instance that I’m showing here. And so rather than connecting, doing the multi-part connection through IMS and just using basic authentication. So we’ll create an upload user, the same username and password. And then I need to add that user into the damn users group so that that user has the requisite permissions that I can write to the AEM assets repository. So I have a folder on my desktop with 877 files. And you can see here, I’ve got the host for my cloud instance, my username and password, the target folder inside of AEM, and then the source folder on my Mac that I’m importing the assets from. This took about a minute and 10 seconds. I have a fairly decent fiber connection, so it’s pretty fast. And you can see here it dumps out the results of that. And then when I refresh my page, my AEM instance here and navigate into the folder, you can see that the assets have been imported and are now in a processing state, which is the next step inside of the presentation, the next step of how assets get into the AEM repository and they’re processed. So for that, I’d like to switch over to Tanya to explain a little bit more about how assets get processed inside of AEM. So Daniel’s part was about talking about how do you get your binaries, your images, your PDF files into AEM. And I’m going to focus on the processing part that happens after that, namely the little processing label we saw in the AEM UI. So in AEM, to define the processing that happens to the asset once they are in AEM, we have a tool called Processing Profiles that we can scope to folders and a set of MIME types. And those processing profiles can do different actions, can define different actions to do on the imported asset, like extract metadata, create renditions, like doing image resizing, adding watermarks, changing formats. And the idea with these processing profiles is to define them once and we use them many times on different folders in order to start automating rendition generation and asset processing. So when are those processing profiles invoked? As mentioned, they are invoked after an asset was uploaded to AEM. So for each file, the processing profile is invoked and using that, the asset is sent to the Asset Compute Service for processing, which generates renditions and can extract metadata. So these are triggered automatically when on upload, or you can also do it manually via the UI or through Java APIs. Which allows for again, automation and streamlining the asset processing. So now I want to focus on what happens with the asset and the rendition, where they move, what is created when. So the first step in all these processes is getting the asset inside of our Adobe Experience Manager. Once this is done, AEM is going to create processing requests to the Asset Compute Services, which is going to do an asset processing of the asset to create renditions. That processing happens in the cloud, can use Adobe binaries, but can also call other Adobe services like Photoshop Lightroom, for instance, or even third party services. And once that processing is done, Asset Compute Services sends events, rendition created or rendition failed to the Adobe IOM Shorner, which is pulled by IOM so that it can know when the processing is done and the result of the processing. So now I would like to demo setting up a processing profile. So IOM comes with a set of default renditions that are generated during initial processing, like for instance, the terminals that IOM will use for previews, but we can extend that with custom processing profiles. So processing profiles are found into the configuration part of IOM in assets. In that example, we already have a set of processing profiles and we are going to create a new one. So as you see, there are different tabs, image, video, etc. And the first step is giving the name to the processing profile. Here I’m prefixing it with 10 10 10 so there is no need to scroll down later in the list. So now I’m defining the properties. So what renditions should look like when this processing profile is used. Here I’m going to create a simple processing profile for images, which is going to create two types of renditions. One is PNG, the other one is JPEG or WebP to show what we can do using the processing profile. So it can create many renditions and it’s not just one asset, one rendition. Once I have saved the processing profile, it becomes available in the processing profiles list. I can later on edit it again. So change the processing profile. Here I’m not going to do that. And so now that is the first step to automation my processing profile. Once I have that now I want to zoom in on how this processing profile is used in the back end in the cloud part in asset compute services. As we’ve seen before, we have our Rm client which is going to make HTTP requests using our REST API to asset compute services, but is also going to use a cloud binary storage to store the assets. Once that request is done, the asset compute services follow a microservices architecture and each of those microservices is what we call a worker that is going to handle a given set of assets and renditions, for instance images, videos or creative. Those workers also have access to the binary storage to download the assets and also later on to upload the renditions that are generated. And as mentioned before, they can access other Adobe services like the Creative Cloud Photoshop and Lightroom APIs or even third party services. So that processing that happens in the cloud using Adobe services or happening entirely on the worker, once it is done sends back the event to the Adobe IO Events Journal where then we go out of the asset compute services cloud part and come back with the renditions to IAM to the events. So what is a worker’s job? The first thing is that the workers process assets to generate renditions and everything here leverages REST APIs. Asset compute services exposes a REST API and we use other REST APIs from Adobe services too, which means here we can assemble the clouds, integrate with Creative Cloud and other Adobe services to apply Photoshop operations, for instance the cutout or applying Photoshop actions, but also apply Lightroom operations like AutoTune and Straighten. And last but not least, we also can integrate with Sensei to add intelligence to the content using for instance video tagging, image tagging, which allows us in the end to assemble in Adobe Experience Manager the different creative cloud and intelligent service APIs to automate processing and rendition generation to optimize the time used by creatives and people to get renditions. So the last demos I want to show in this presentation is how we can use Lightroom and Photoshop services combined with processing profiles to automatically create renditions. So the first thing I’m going to show is I’m going to pick up where I left off with the processing profiles and create one more, but this time using the creative APIs of Photoshop and Lightroom. So the first thing I want to show is that before I end, I have uploaded in IAM some presets, so Photoshop actions and Lightroom presets to use in my processing profiles and apply on the assets that will be uploaded and processed. And those are going to be reused in my asset processing profiles that I’m going to create now. So we still have the processing profile I created previously, it’s still here, and I’m going to add a new one. This time I’m going to do a creative processing profile which will reflect in the name. And I’m going to go on the creative tab. Here I’m going to add a new step, a new kind of rendition creative operation. And in my case here, first I will choose an autotone operation, define what kind of rendition, which formats I want. Here I’m going to go for an autotone TST rendition, which is a JPEG, and add another operation, which is going to be applying a Photoshop action. And I’m going to grab the action file that I previously uploaded into IAM as it is an asset, just like any other asset. So I’m going to select that, give a rendition name, and then save my processing profile. In this case I’m going to apply all the actions in the file. So now again I’m in the same step, I have my processing profile, and I am going to apply it to the folders where I’ve stored my assets, so that when I upload in this folder, the assets are automatically processed. If I want to have existing assets, I also get this processing profile like that. Other too I have to reprocess them. So the second part of the demo is showing you what happens in IAM with the processing after the upload. So for this example I’m going to choose something that is really visible and obvious to see which is a cut-out operation for which a processing profile was specially created and applied to this folder. So we are in IAM. We see currently there is no asset in this folder, so we are going to add some. It’s going to be a set of photos with people modeling t-shirts, and we want to remove the background of those photos using the cut-out operation provided by Creative Cloud. So we see here after upload the assets are processing, and after a very short time we see the new renditions being added in these folders. We see we have the original assets with the backgrounds and the renditions without. So this is a way using processing profiles and the capabilities we have in the cloud in AssetComputed Services to use and reuse other Adobe services to create renditions and especially automate renditions creation to make it faster and more efficient. So that is the end of the content automation part. Are there questions? So I think I saw a couple pop into the pod there, and I think we answered them in line, but it’s probably not a bad idea to repeat. And if anybody has any other questions, feel free to chime in. But one I did see was around bulk import and disabling workflows. And so in previous versions of AEM, you were kind of limited in the scalability since it was running on physical VMs that couldn’t scale horizontally. With AEM as a cloud service, you really don’t need to disable the workflows. The processing profiles and all of that is cloud scalable, so it’ll scale up asset compute workers as needed and extract all the renditions. And it’ll take time to process a whole lot of assets. You shouldn’t need to do the same sort of activities that we did with the on-premise installations. Let’s see. And then I think, yeah, one was pretty well answered by your presentation overall. One question that did come in was around the if asset processing fails. And I think Brendan responded to that as well, that it will get recorded in the IOB and the Fed journal. Yeah, and we will track it from there to make sure that we restart any processing jobs that fail so that it should get reprocessed. If you do have certain cases where the assets don’t process correctly, you would see a notification on that asset inside of AEM. And that processing badge won’t go away and won’t switch to new until they are fully processed through the system. Okay. So Jen’s asking, can you discuss the advantages to using AEM Desktop Manager for uploads? Oh, I guess that immediately switches over. So AEM Desktop, in terms of comparing to using like the drag and drop upload, first thing is that you can import folders, which is a not inconsiderable feature that you don’t have to like create a folder, upload the assets in it, create a folder, upload the assets to it. It’ll support resuming. It also has features there around like having a local copy of the assets available to you as well. So if you need to be able to put and then get and put and get assets, it makes that much more convenient. It’s also going to be significantly faster than just using the Web UI because it supports multiple processes, importing those assets at one time. It’s not going to be as scalable as say using the bulk import, which would be more appropriate for if you have hundreds of gigabytes or terabytes of assets that you need to get into the system. That’s really what bulk import is designed for. So I guess, Tanya, I do have one for you. If I were a customer and I wanted to check out some of those Photoshop actions that you were showing and some of that cool stuff, I think that’s some of the automotive customers I’ve had, right, where they want to create thousands of renditions of their cars. How would I go about doing that? So we already have official documentation out and examples you can use, but also the actions that are used can be generated from Photoshop, where Photoshop has a nice feature where you can see it playing the actions on the image you have been working on. So the action is a snapshot of the operations that were done and to use those actions, you would export them out of Photoshop, put them into IM like I did, and then use them in the processing profiles. Very cool. I’m imagining some of these large enterprises that they could get a lot out of being able to automatically cut up images like that. It’s being done right now. Yeah, the goal is to streamline the processing so that you define your action. And once it’s uploaded into IM, the action gets applied on the assets you want them to. And then you can see the results and show what you like best from the renditions. Yeah, and it’s probably worth mentioning that those processing profiles are applied at the folder level. So if you had particular processes that you want to execute based on the files, it is important to set up a taxonomy ahead of time of how you want your folders to be arranged. Yes, and it’s not only the Photoshop actions. It’s also, for instance, if you did a photo shoot of a product or clothing or jewelry, you can set up your processing profile to apply a set of Lightroom actions to edit and streamline the photos editing from the shoot. So that then again, you can easily see all the photos next to each other and choose which one is the best for the product. Makes sense. Let’s see, there’s one more question. Currently we have a custom process to purge image cache on DMCDN post image edits. So yeah, you can create a post-processing workflow and that’s on Experience League about how to do that. And any custom code you want really, you can be executed there. They would get executed after the images or assets, sorry, I should say assets come into AM assets and are fully processed. All right, well thanks everyone for attending and I hope you have a great rest of the day and enjoy the rest of the conference. Same, thank you for attending. Enjoy the conference. Thanks.