sections in the article
This article describes what the Adobe Experience Manager (AEM) Assets integration is and lists the main features.
The AEM Assets integration is referred to as the AEM integration in this article.
About the integration
The AEM integration provides seamless access to all your product media in AEM from inriver.
The integration uses the inriver External Asset Service which is an integral service of the inriver core. In order to communicate seamlessly with AEM Assets, there is a server-side package running inside the customer’s AEM asset instance. There is also an EntityListener running inside inriver to deliver changes from the Resource entity to AEM Assets.
Feature list
The AEM integration provides the following features:
- Bi-directional functionality of mapped fields between the Resource inside inriver and the Asset inside AEM Assets.
- Synchronization per asset can be toggled on or off from AEM. If synchronization is off, media will remain in both systems but will not be actively updated.
- Publishing or unpublishing an asset in AEM will determine if actual media is displayed in inriver.
- Support for assets initiated in AEM Assets.
- Allows for manual change as well as a programmatical change of assets in AEM.
- Support for AEM Assets as a Managed Service.
- No customization required, only configuration.
- Utilization of smart linking mechanisms in inriver to link assets in AEM to Products in inriver.
- Asset removed from AEM can be configured whether it should be removed or not from inriver.
Information flow
The below illustration is a conceptual view of the information flow between AEM and inriver.
Asset synchronization
- Asset uploaded to AEM.
- When an asset is placed into a folder associated with an inriver Metadata Schema, inriver-mapped fieldtypes will appear as properties on the asset.
- In this example, the AEM Asset has not been published yet.
- Open the asset’s properties, and check the Sync to inriver flag. The asset will then be sent over to inriver for synchronization.
- Resource Entity is created inside inriver.
- Metadata is passed over from the AEM Asset to the mapped inRiverFieldTypes.
- Linking can be created in two ways:
- By providing the exact value of the configured fields relevant for link lookup.
- Link properties can be extracted out of the filename of the asset being synchronized.
- The asset’s mapped metadata is available on the Resource entity:
- if AEM asset is published the image will be visible in inriver.
- if AEM asset is unpublished the image will not appear in inriver.
- Asset inside AEM Assets is seamlessly accessible from inriver as a standard Resource entity with all its related features.
Asset metadata synchronization
- If a change is made to the Asset properties inside AEM and it is mapped in the AEM inriver setup it will be synchronized to the fieldtype on the Resource entity in iniver.
- If a change is made to the Resource fieldtype inside inriver, it will be picked up by the AEM entity listener running in inriver and instantly synchronized to the mapped property on the asset inside AEM.
Accessing the integration
You must have a license agreement in place to download and use the adapter. Contact sales@inriver.com for more information.
Once you have a license you will be able to access the adapter download link in this article.
Note: If no license is in place you will receive an error message when attempting to use the link.
Further reading
Read this first: Inriver adapters
Get an inRiver license to view below content:
- Technical
- Configuring inriver
- Deploying the inriver AEM package on AEM
- Setting up the AEM workflow for inriver
- Using and mapping the adapter
- Q&A
- Release notes
- Download (valid adapter license required to access)
- Only valid for Partners: Inriver adapter download links
Comments
2 comments
Hi, we were wondering if there was a way to migrate current data from binary assets in inRiver to linked files in AEM.
We are currently working with a client that has thousands of resources in inRiver but is looking to migrate to AEM. We thought at first that matching entities (with the same file name) would simply be recreated / updated in inRiver, but it seems like we are receiving an error from the AEM extension.
-------
ERROR Error calling inRiver Aem Asset Service HTTP Status Code = 500
2020-08-13 17:41:15.367 ERROR Body content - {"ClassName":"System.ServiceModel.FaultException`1[inRiver.Remoting.Faults.ArgumentFault]","Message":"Trying to add entity with unique field where the data already exists","Data":null,"InnerException":null,"HelpURL":null,"StackTraceString":" at inRiver.Server.Repository.DataRepository.ValidateAddEntityFields(Entity entity)\r\n at inRiver.Server.Repository.DataRepository.AddEntity(Entity entity)\r\n at inRiver.AppService.ExternalAssetService.AemAssetService.addResource(String json)\r\n at inRiver.AppService.ExternalAssetService.Controllers.AemAssetStorageController.Post(String environmentId)","RemoteStackTraceString":null,"RemoteStackIndex":0,"ExceptionMethod":"8\nValidateAddEntityFields\ninRiver.Server, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null\ninRiver.Server.Repository.DataRepository\nVoid ValidateAddEntityFields(inRiver.Remoting.Objects.Entity)","HResult":-2146233087,"Source":"inRiver.Server","WatsonBuckets":null,"code":[{}],"reason":[{}],"messageFault":null,"action":null,"detail":{"method":"AddEntity","argument":"ResourceFilename","message":"Trying to add entity with unique field where the data already exists"}}
------
So our first guess was that the extension was trying to create an asset with the same unique FileName. We deleted the existing resource and everything worked.
Now, we are wondering if there is a configuration we missed somewhere that allows us to keep existing resources but only fill the Aem related fields and let my resource entities live there or simply replace it automatically if it already exists in inRiver and recreate its links?
The problem we have here is that we're going to have to delete all resources from inRiver before syncing from AEM. Are you planning on supporting this use case?
Hi,
No, you have not missed a setting.
The current suggested migration path is to download/export your images from inRiver, rename them following a relevant naming convention to apply linking, and then upload them to AEM Assets where you can synchronize them to inRiver. Read more here https://servicecenter.inriver.com/hc/en-us/articles/360009647660.
Adding support for Update and not only Forced Add sounds like a good suggestion for future functionality. It has not been planned into the adapter roadmap yet. Please add as a feature request and we will take your request into consideration. https://servicecenter.inriver.com/hc/en-us/community/topics/360000684740-Feature-Requests-Adapters
Please sign in to leave a comment.