All you need to know about AEM Assets as a Cloud Service

The new 'AEM Assets as a cloud service' which is part of AEM as a cloud (platform as a service solution) provides Digital Asset Management capabilities(storage, managing metadata online, versioning, upload, and download) with below-extended features.

• Based on asset microservices(asset ingestion and processing).
• Smart capabilities, such as AI/ML
• Highly scalable
• Always current
• Always available
• Autoscaled deployed and monitored

In older AEM all the asset operations happened at AEM Author instance - which consumes considerable CPU, memory, and I/O resource. Asset processing and storage requirements demand resources which in turn create performance issues impact the authoring and browsing experience of end-users.

A High-level Architecture of Assets as a Cloud Service can be seen below

The generic steps followed in the sequence are,

• Clients send an upload request - then start uploading binary directly to the cloud
• Once the direct upload is completed, the client notifies AEM
• Now the AEM sends a processing request to Assets Microservice
• The asset microservice now start processing the asset (based on the rendition request from AEM) - asset microservice runs relevant microservices for this. They access the binary from the cloud and processed assets are also placed in the binary cloud.
• Now assets microservice notifies AEM that renditions are available.

Assets as a Cloud Service Vs AEM Asset upload on-premise

Assets as a Cloud Service uses direct binary access principle for upload and download - Previously Assets were uploaded directly to AEM author instance for processing.

Assets as a Cloud Service uses 'asset microservices' for asset processing, which is external to AEM - But in older AEM versions, all processes happened within AEM.

In Assets as a Cloud Service, DAM Asset Update Not available [ asset microservices provide a scalable, readily available service that covers most of the default asset processing (renditions, metadata extraction, text extraction for indexing)]. But in older AEM we had DAM Asset Update workflow as default.

Assets as a Cloud Service comes with post-processing workflows which can be used or customizations(where additional processing of assets is required that cannot be achieved using the processing profiles) -In older AEM we had default + customized workflow steps (Even though it looks like an advantage it had used AEM for all processing).

In Assets as a Cloud Service the standard Asset upload interface is the Touch-enabled UI - In the older version, Classic UI was available.

In Assets as a Cloud Service, only the new upload APIs are supported -The older AEM Assets HTTP API(AEM 6.5), AssetManager Java API, is deprecated now

Advantages of new cloud
The uploaded binaries do not go through AEM, which is now simply coordinating the upload process with the binary cloud storage configured for the deployment. finally, clients get direct access to them to carry out their work. This minimizes the load on networks and duplication of binaries stored.

Binary cloud storage is fronted by a Content Delivery Network (CDN, Edge Network), which brings the upload endpoint closer to the client, helping to improve upload performance and user experience, especially for distributed teams uploading assets

More scalable and performant handling of asset uploads.

Ways of uploading Assets to Assets as a Cloud Service
Upload using the web interface, Adobe Asset Link, AEM desktop app, or custom applications that use the new HTTP API.

Post-processing workflows
There are cases where we need additional processing to be done, which are not done by asset microservices(For eg. Generating a rendition which requires integration with other applications), additional post-processing workflows can be added to the configuration.

Post-processing workflows, once configured, are automatically executed by AEM after the microservices processing finishes. There is no need to add workflow launchers manually to trigger them.

Some examples for Post Processing workflow use cases are:

Custom workflow steps to process assets.
Additional processing done by external services.
Integrations to add metadata or properties to assets from external systems

How to create Post - Processing Workflows: Steps involved

1. Create one or more workflow models. - they are of regular AEM workflow models
2. Add specific workflow steps to these models.
3. Add 'DAM Update Asset Workflow Completed' Process step at the end(To inform AEM once the processing is done)
4. Create a configuration for the Custom Workflow Runner Service(configuration of an OSGi service) - This ensures the execution of a post-processing workflow model either by a path (folder location) or by a regular expression.

Supported File Formats
Adobe formats - AI, COLLAGE, DN, IDEAS, INDD, INDT, PDF, PROTO, PSB, PSD, XD
Imaging file formats - BMP, EPS, GIF, JPEG, PNG, SVG, TIFF
Image formats in Dynamic Media - PNG, GIF, TIFF, JPEG, BMP, PSD , EPS, PICT
3D formats - DN, gLB, gLTF, OBJ, STL, USDz
Camera Raw file formats - 3FR, ARW, CR2, CR3, CRW, DCR, DNG, ERF, FFF, GPR, IIQ, KDC, MEF, MFW, MOS, MRW, NEF, NRW, ORF, PEF, RAF, RAW, RW2, RWL, SRF, SRW, X3F
Document formats - PDF,DOCX,DOC,PPTX,PPT, XLSX,XLS,ODF,OFG,ODM,ODP,ODS,ODT,EPUB,HTML,PS,RTF,TXT,XML
Document formats in Dynamic Media - AI, PDF, INDD
Video formats - 3G2,3GP,AVI,DIVX,F4V,FLV,M2T,M2TS,M2V,M4V,MKV,MOV,MP4,MPEG,MPG,MTS,OGV,QT,R3D,SWF,WEBM,WMV
Video formats in Dynamic Media for transcoding - MP4,MOV, QT,FLV, F4V,WMV,MPG, VOB, M2V, MP2,M4V,AVI,WebM,OGV, OGG,MXF,MTS,MKV,R3D, RM,RAM, RM,FLAC,MJ2,
Audio formats - AIF, ASF, M4A, MP3, WAV, and WMA