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
at
https://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 instances
This 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.