Remote Assets

This tool allows site builders on Adobe Experience Manager (AEM) to search, access, and use assets from a dedicated Digital Asset Manager (DAM) on a separate server. Remote Assets is currently built to support AEM Assets, with intentions to support alternative DAM or PIM products in the future.

Remote Assets was voted the winner of the 2018 Adobe Summit AEM Rock Star competition and was the first publicly available implementation allowing assets from a remote server to be leveraged effectively from AEM Sites.

Use Cases

One of the most obvious and attractive use cases for this feature is using assets from an enterprise DAM or PIM from AEM Sites in a seamless fashion. A side note here is that if your remote DAM is AEM Assets and your AEM Sites instance is hosted with Adobe Managed Services, Adobe’s follow-on “Connected Assets” feature (which I talk about in the article Unveiling AEM Remote Assets) may be a fit for you.

Assuming Adobe’s implementation or inherent limitations of AMS hosting and AEM Assets leave you searching for an alternative solution, here are some of the use cases that Remote Assets was designed to solve:

• Keeping Dev/QA/Stage AEM servers up to date with current assets
• Allowing developers to work locally, automatically pulling in assets as-needed
• Leveraging assets directly from a non-Adobe DAM or PIM (future)

In the video at the bottom, I walk through an example using AEM Remote Assets for local development of the `we-retail` website, where a developer has copied the site content but not the assets since there’s no easy way without copying the entire DAM. This example can be extrapolated to any AEM website where the remote server is perhaps a Dev or Stage server and the DAM potentially includes many gigabytes (or even terabytes) of assets making a full sync to the local development server infeasible.

How to Use

1. (DO NOT SKIP) Configure DAM Workflow Launchers

Do not pass GO, do not collect $200 without first performing this step! Seriously, skipping this step will at best result in Remote Assets performing poorly, and at worst overload your AEM server.

Configure all Workflow Launchers in AEM that act upon DAM paths to ignore activities that contain `event-user-data:changedByWorkflowProcess`, which is stamped into events triggered by Remote Assets. To do this, go to the admin page for Workflow Launchers in AEM (`/libs/cq/workflow/admin/console/content/launchers.html`), open each launcher that operates on a path that contains `/content/dam`, and update the “Exclude List” field to contain `event-user-data:changedByWorkflowProcess`.

Note that some launchers will already have this in place out-of-the-box (OOTB), and thus not require updating. Others may have `event-user-data:<someOtherThing>` in which case you would append `,changedByWorkflowProcess`, resulting in a value like `event-user-data:<someOtherThing>,changedByWorkflowProcess`.

2. Configure the Remote Assets Feature

Give AEM the connection details of the remote server, what paths to include (both tags and assets), and any additional options by configuring the `com.adobe.acs.commons.remoteassets.impl.RemoteAssetsConfigImpl` service. You can do this from the admin console in AEM, or by deploying a `sling:OsgiConfig` node from your codebase.

3. Configure the Remote Asset Resource Decorator

Enable AEM to listen for requests to remote asset placeholders so that the asset binary files (i.e. the “real” assets) can be synced to the server “just-in-time” by deploying a blank OSGi configuration of the `com.adobe.acs.commons.remoteassets.impl.RemoteAssetDecorator` service, which you can include in your codebase as an empty `sling:OsgiConfig` node.

4a. Trigger a Manual Sync of Remote Asset Placeholders

Synchronize tags and the DAM node structure (using small placeholder assets to minimize disk usage) by triggering a sync from the JMX admin console at `/system/console/jmx`, opening the “Remote Asset Node Sync” service, and invoking the `syncAssetNodes()` operation.

Depending on the size of the DAM you are using remote assets for, this can take anywhere from a few seconds to a few hours.

4b. Schedule a Repeating Sync of Remote Asset Placeholders

To keep your asset node structure up to date with changes in the remote DAM without requiring periodic manual syncs, configure the sync to occur automatically on a scheduled basis by providing an OSGi config for the `com.adobe.acs.commons.remoteassets.impl.RemoteAssetsNodeSyncScheduler` service, which consumes a standard cron expression for scheduling. Similar to other configs, this can be done by deploying a `sling:OsgiConfig` node from your codebase or directly via the admin console in AEM.

Example config scheduling Remote Assets node sync every morning at 2:00 a.m.:

5. Use the Assets Like They Are Real!

The last step to using Remote Assets actually takes care of itself. As a non-admin user accessing assets, “remote” assets become “real” assets as you use them in your everyday tasks. Whether you are viewing a page, searching the DAM, or navigating DAM folders, any assets for which binary files have not yet been synced to your AEM Sites server will be pulled in “just-in-time” as they are requested, giving you the impression that the assets were “real” the entire time.

It’s one thing to read this step and think, “that sounds kinda cool” but truthfully you need to experience the “magic” of Remote Assets yourself by watching the Remote Assets video demonstration (starting at 4:48 if you want to cut to the exciting stuff!).

 

Learn More

For additional implementation guidance including configuration options and troubleshooting, visit the official documentation.