Connected Assets

This is a feature introduced in 6.5 release.

To understand the concept of connected assets clearly, it is essential to understand the two basic terminologies we have seen being used increasingly as AEM evolved. AEM Assets & AEM Sites

• AEM Assets – This refers to the DAM part of AEM.
• AEM Sites – This refers to the Pages (web pages created, authored and maintained) part of AEM.

We know that the site pages authored can use the assets from DAM on that AEM instance. Connected assets stretches this concept to allow the site pages authored in one AEM instance to use the DAM assets from another AEM instance.

AEM instances in this architecture are designated as Assets instance and Sites instance.

Essentially they are (at least at this stage) regular AEM instances, which are just designated as Assets and Sites instances based on the purpose they serve.

With connected assets, the sites instance can search for assets on the remote AEM assets instance and use them on its pages, similar to how it works with assets in its local DAM. Assets in its local DAM can continue to be used on pages.

In fact, the assets from the remote assets instance that are used on site pages get downloaded to a designated folder (provided in the configuration) in the DAM of the local sites instance (after which it remains out of sync with its master copy in the assets instance).

Since the assets downloaded gets created as new assets in sites instance DAM, we will have to customize workflow launcher configuration to skip this download folder as otherwise the workflow would generate the renditions again when the asset gets downloaded.

The configurations to be made on the assets and sites instances, the users and groups to be defined and linked for managing permissions across instances is all detailed in the reference documentation on connected assets available athttps://helpx.adobe.com/experience-manager/6-5/assets/using/use-assets-across-connected-assets-instances.html

After going through this feature and the reference documentation, we found that we had a case to leverage this feature. But there were catches that would prevent us from using it. The first of it is the condition that the assets instance must be AMS hosted

Connecting sites instance to on premise assets instance
The reference documentation specifically mentions that the assets instance in the connected assets architecture must be a hosted instance on AMS. This is one of the pre-requisite for using connected assets.

But all our AEM implementations had on premise AEM installations. Not only were there no clients we have, who had AMS hosted AEM setup, none had any plan of migrating to AMS in their roadmap.

So we got curious. Here is a feature that we potentially had immediate need for, but couldn’t be leveraged as its not available for on premise hosted AEM installations.

But what stops us from trying the feature out on locally hosted instances. And below is the configuration we tried.


We made the configurations required and found that the two instances got connected and we could search for assets in (local hosted remote) assets instance from the sites instance. But soon we realized the catch…

The connected assets configuration includes providing the credentials of the service user used to connect the sites instance to the assets instance. But when we tried to search for remote assets, it prompted with a login screen of the assets instance. On authenticating (manually) connected assets works perfectly fine.

But why is it prompting for the user login when we have already configured the credentials in the configuration. Shouldn’t it be using that credentials and connect automatically without prompting for login again (You would not even realize this if you try this configuration with admin credentials everywhere)

Digging further, the reasons are obvious.

Site instance to Assets instance authentication depends on Adobe Identity Management Service and hence the dependency to host Assets instance on AMS.

We further found that there is an ACS Commons tool – Remote assets (https://adobe-consulting-services.github.io/acs-aem-commons/features/remote-assets/index.html) which uses a different approach for syncing assets, but would allow us to connect a sites instance to an on premise hosted assets instance.

Connecting sites instance to assets publish instance
Another use case we wanted to try out is that of assets AEM instance type. The reference documentation talks only of connecting a sites Author instance to an assets Author instance.

Sites author instance makes perfect sense as we will only be searching for and pulling in assets from remote assets instance only when authoring

But for the assets instance, we had scenarios where the assets would be in draft state and run through an approval workflow before it gets published. And we want sites to use only approved (and hence published) assets.

So we need a way to connect a sites instance to assets publish instance. Below is the configuration we tried for this.

This apparently failed. The components and services needed for connected assets functionality is enabled only on Author instance. So there is no way (at least without customization) to use connected assets feature to connect to the Assets instance in publish mode.

And this is understandable. We do not want multiple site author instances to connect to a publish instance and perform heavy operations on it like firing search queries and downloading asset binaries.

Also we could see the cases that for pure assets instance (that AEM instance which hosts only assets and serves no other functionality) may not need a publisher pair.

But the use case we had for letting sites use only published assets from the assets master instance is also valid. Interestingly, we found that the ACS Commons tool – Remote assets supports connecting to and downloading assets from publish instances.

Connecting sites instance to multiple assets instancesThis is one other use case that we felt is commonplace. We wanted to try out a configuration like the one shown below:


But the connected assets provide for connecting to only a single assets instance.

The only workaround we found for this is to change the connected assets configuration (an admin function) to point to different assets instance to download assets from them – a hardly useful option.

The ACS Commons tool – Remote assets doesn’t help here either. It also provides for only connecting to a single remote instance.

Modifying the master copy
After the asset gets downloaded to the sites instance, changes to the original asset does not get sync'd with its downloaded copy - one of the key limitations to be aware of when using the connected assets feature.

The downloaded copy can be edited on the local sites instance (though its recommended to maintain it as read only) and these edits stays in the sites instance.

So what happens when you try to use the same asset again from remote (that you had earlier downloaded, edited and used in a few pages)...

We tried and found that the previously downloaded and edited asset gets wiped out from local and the new copy gets downloaded. So be cautious when you are using the same remote asset in multiple places.

If the asset and/or its metadata in the remote has changed in the mean time or you have made some changes on the already downloaded asset - you might be in for some surprise.

Conclusion
We found connected assets to be a very compelling feature, but the restrictions with which it has come out limits the use cases for which it can be applied. We are hopeful that some of the limitations would be addressed in future releases.