by Ursula Johnson

Created

April 19, 2018

It’s a wrap! Adobe Summit NA 2018 is done, and we are excited to announce the winner of this year’s #AEMRockstar competition:

 

Brett Birschbach from HS2 Solutions

 

This year brought more outstanding submissions than ever, resulting in a fantastic field of semi-finalists. Congratulations to Brett and our other finalists, Bryan Williams, Joost van Dun, and Conrad Woeltge, who competed in front of an audience of 300 AEM enthusiasts! 

Brett (a previous CM guest blogger) has written a great post about his winning Rockstar Tip & Trick. He is the lead Adobe Marketing Cloud Solutions Architect for HS2 Solutions, a digital transformation company based in Chicago. He is a hands-on problem solver with experience leading large multinational, multi-site platform projects. Read on below: 

 

AEM Remote Assets –

Sync What You Need, When You Need It

 

Have you ever wanted to use AEM Assets on one server from AEM Sites on another? I bet you have, even if you don’t realize it. Until now, options to do so would have been custom and/or manual, so you may have simply blinded yourself to the idea. Here are some common uses cases that you’ve probably run into:

 

Use Case: Enterprise AEM Assets Instance

Ok, I admit this is probably not the most “common” use case, but for large enterprises in the digital age, it’s a critical use case. An enterprise DAM is a key part of an enterprise technology stack, often calling for a dedicated AEM server with DAM as its sole purpose. But then how do you use those assets for your AEM sites?

 

Use Case: Migrating Assets from Production to Non-Production Environments

Does your organization have Dev/QA/Stage AEM environments? Of course, it does. Are those environments consistently up to date with the latest set of assets from production? For almost everyone I talk to, the answer is almost invariably a resounding “No.” How can this be done in a way that is both automated and disk efficient?

 

Use Case: Site Assets for Local Developer Servers (i.e., localhost:4502)

Pulling down a copy of the production site pages to a local server is easy. Pulling down all of the assets associated with that site? Not so much. How can this be done in a way that leaves behind assets that are not applicable to the site?

A simplistic, brute-force solution might be to use AEM’s package manager to bundle up the entire DAM, copy it down to the Sites server, and call it a day, right? Not exactly. Assets are big…and numerous… Last I checked, numerous big things is rarely a simple situation. Copying the entire DAM can be problematic in terms of disk space, network transfer, and effective package sizes. And even if you can do it manually, as soon the first asset on the remote server changes, you’re out of date!

Ok, so why not just reference the assets directly from their remote location? This would be a nightmare for your authors and developers, no longer able to leverage simple OOTB tools like image components, DAM search, and the authoring sidebar. Ultimately, you’d no longer be able to leverage the full power of AEM sites.

In short, you need a solution that achieves all of the following objectives:

  • Access to all remote AEM Assets from the AEM Sites instance
  • Remote AEM Assets stored locally in AEM Sites for seamless authoring w/OOTB features
  • Copies of just the required remote AEM Assets, not the entire DAM
  • All accomplished in an automated fashion

 

Sync What You Need, When You Need It

AEM Remote Assets tackles this tricky problem in a unique way. The seemingly opposed objectives of “Access to all remote AEM Assets” and “Copy of just the required remote AEM Assets” are achieved by a “sync what you need, when you need it” strategy. What this means is the automated asset sync first copies the entire node structure from the remote DAM, pulling in the tags and metadata of all of the remote assets but leaving behind the large binary files in the source DAM. If and when any of these assets are requested for a real use case, only then does Remote Assets copy the binary files “just in time” via a second sync, leaving behind all of the other asset binary files that are not needed.

Let’s see how this works in practice. AEM Remote Assets first syncs in the node structure of the remote AEM Assets, substituting in a small, temporary binary file to keep all unused assets very small compared to their real counterparts.

Admin user viewing folder of remote assets on an AEM Sites instance.

As an admin user on the AEM Sites instance, I can see all of the “remote” assets that have been synchronized from the remote AEM Assets server. And though an asset may say it is 500+ KB in size, in actuality it is far smaller due to the temporary binary file.

Now the true magic begins. Because we have synchronized in all of the remote asset nodes and tags, we have everything we need as an author to search and use those assets, and AEM will take care of pulling over the binary files for the ones I want to use. Say for example I open a browser and search for “Bike” assets. The system finds the two assets, but as the request is being processed it first pulls over the associated binary files from the remote Assets server, making those two assets now “real” on the Sites server.

Right: Author user viewing two searched assets; Left: Admin user viewing folder with searched assets now made “real.”

The same thing happens if I pull up the page authoring sidebar to add an image to my page.

Right: Author user choosing asset from page authoring sidebar; Left: Admin user viewing folder with referenced asset now made “real.”

This is amazing for the “Enterprise Remote AEM Assets” use case, where authoring sites with remote assets is a critical business function. But what about the use cases of “Migrating Assets from Production to Non-Production Environments” and “Site Assets for Local Developer Servers” where largely we just want to be able to browse the site with all assets. Turns out that scenario (and any others you can think of) works as well.

Right: Web page as seen by an author user, all assets being made “real” simply by browsing to the page; Left: Web page with remote assets before access by an author user.

 

This is Awesome! Can I Has AEM Remote Assets Too?

You absolutely can! HS2 Solutions has contributed AEM Remote Assets to ACS AEM Commons, the most prominent open source feature library for AEM in the industry. You’re probably using this library already! We look forward to the community pitching in with their ideas on configuration options, additional functionality, and even direct code contributions!

For more on AEM Remote Assets, including a video demonstration, view my article on hs2solutions.com. You may also contact me via LinkedIn or email at brett.birschbach@hs2solutions.com.

All opinions are Brett Birschbach’s own and are not Adobe’s.