Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

Avoid redundacy in the DAM

Avatar

Level 3

It is required to implement a DAM using AEM Assets. The taxonomy leverages on the product ID and the structure is the following one
.../Product ID/Images/image.jpg


It might happen that for different products we have the same picture. This causes a replication of assets as in the example below

.../Product ID1/Images/image.jpg
.../Product ID2/Images/image.jpg

 

How can I avoid the redundancy maintaining the taxonomy designed? Is it possible to refer to logical links?

Thanks in advance.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi,

 

Does this really match the expectations of the users? Wouldn't they be surprised, that if they remove a product asset for product A, that this asset is also used for different products? Especially if they are not aware that they influence other products as well?

 

To assess the impact this requirement, I would recommend you to list all different cases:

 

* an asset is added to a product, and the asset is not yet available in the system

* an asset is added to a product, and the asset is already available in the system

* an asset is removed from a product, and the asset is also used for other assets

* (and potentially more)

 

and define how the system should behave; also consider the various users in this case:

* the user who performs the activity

* a user who has worked with that asset before on the system and added it to an asset.

* ...

 

Then match this to the ootb capabilities of the AEM and understand where you need to add a customization so the system behaves as you want.

 

From my point of view this requirement is highly risky, and not only from an implementation side, but also from a management point of view. Not to mention the problematic to train all users dealing with it.

View solution in original post

20 Replies

Avatar

Community Advisor

Yes, you can try below: 

Create tags based on your requirement at http://<hostname>:<port>/aem/tags 

You can create Tags similar to product Ids, then attach tags for the image.

Example, if you have Products like Product ID1, Product ID2, Product ID3 ,

1. Create tags for each product

2. Go to the image and attach the specific product tags

 

Then if you're using component to render product details, configure the product tag at component level and query for the image based on tag and use it.

 

This way you can avoid keeping same image under multiple folders in DAM. 

 

Thanks

 

 

 

Avatar

Level 3

Hi @Siva_Sogalapalli and thanks for your reply but with this approach I should change the taxonomy right?

Thanks again.

Avatar

Community Advisor

@serenapitotti ,  if you have existing tags related to the products, you can use them otherwise you need to create new tags and attach respective tags for the images.

 

Your component should render images based on products tags.

Avatar

Level 3

 

I don't have any existing tag related to the products. I can create them but this will bring me to a hybrid solution for which for some products I get the Product ID from the folder (.../Product ID/Images/image.jpg) while for the others with these images in common, I get the Product ID from a tag.

Consequently how should I manage the assets retrieve using the QueryBuilder?
Cc: @Siva_Sogalapalli 

 

Avatar

Employee Advisor

Is this a common case, that you have the same asset for multiple asset? Do you have enough metadata on the image or the product that it is even possible to detect this situation automatically?  How should this be handled? What should happen if the image is removed from a product? What if moved or renamed?

 

 

Avatar

Level 3

Yes, it is a common case and unfortunately I don't have enough metadata to detect this situation automatically (I don't have any rule).
If the image is removed from a product, I expect to do the same with all the products with the same pic. 
Cc: @Jörg_Hoh 

Avatar

Community Advisor

@serenapitotti I have exact same questions as @Jörg_Hoh mentioned. 

 

  • If you have same image under P1 , P2, P3 ; will they be related in anyway ? Means , if the image is removed from P1 , should it be removed from all other products ? 
  • If you want to avoid duplication of images with exact same metadata, then better way to organize them would be using tags as @Siva_Sogalapalli mentioned. But that decision should be made after properly considering all the requirements. 

Avatar

Level 3
  • If I have the same image under P1, P2, P3, I'd like them to be related. Therefore, if the image is removed from P1, I expect it to be removed also from P2 and P3.
  • I agree about using tags but this will bring me to a such hybrid situation for which for some products I get the Product ID from the folder (.../Product ID/Images/image.jpg) while for the others with these images in common, I get the Product ID from a tag.

    Consequently, how should I manage the assets retrieve using the QueryBuilder? I think that a generic approach should be preferable.

Cc: @VeenaVikraman 

Avatar

Correct answer by
Employee Advisor

Hi,

 

Does this really match the expectations of the users? Wouldn't they be surprised, that if they remove a product asset for product A, that this asset is also used for different products? Especially if they are not aware that they influence other products as well?

 

To assess the impact this requirement, I would recommend you to list all different cases:

 

* an asset is added to a product, and the asset is not yet available in the system

* an asset is added to a product, and the asset is already available in the system

* an asset is removed from a product, and the asset is also used for other assets

* (and potentially more)

 

and define how the system should behave; also consider the various users in this case:

* the user who performs the activity

* a user who has worked with that asset before on the system and added it to an asset.

* ...

 

Then match this to the ootb capabilities of the AEM and understand where you need to add a customization so the system behaves as you want.

 

From my point of view this requirement is highly risky, and not only from an implementation side, but also from a management point of view. Not to mention the problematic to train all users dealing with it.

Avatar

Community Advisor

Hi,

If you have common images among products, you should be using the common folder and tag those images with product.

But still if you want to create duplicate copies then use Live copy of image to create duplicate image so that the duplicate images always in a sync with original one.



Arun Patidar

Avatar

Employee Advisor

Hi @arunpatidar 

I am not sure if the MSM is the correct solution here. First, that only works if not only the asset (the binary itself) are identical, but also if all the other properties are identical, and from my point of view that's questionable.

Also I assume that this requires then automation, because you cannot request that from authors, because you would require from that they know that they are about to upload the same asset as it's already available somewhere in the system. 

And you have to write that automation on your own.

Avatar

Community Advisor

Hi @Jörg_Hoh 

Yes, you are right, I totally forgot about the asset metadata which may vary due to different product.

If the binary and metadata is identical then this could be used to allow automatic sync if master changes.

Yes the Author has to know in advance if there is a same asset is already availble or not.



Arun Patidar

Avatar

Community Advisor

Hi,

Yes with the live copy , you can allow automatic syncing of content(Push on modify rollout) and do other stuff but not sure in your use case if this could be a ideal solution



Arun Patidar

Avatar

Level 3

What do you mean with MSM? The assets will be the same (the binary too) but I expect to rename the logical link according to the Product ID it is related to.

Cc: @Jörg_Hoh;

Avatar

Employee Advisor

Hi,

 

when you say "the assets are the same", do you mean that both the metadata of the assets and the binary itself are identical across even when it's linked to multiple assets?

In this case maintaining a single instance of the asset might work, but I still wonder how this should be managed.

 

* When a user uploads this asset to link it to a product, will the system notify the user, that this specific asst is already present? Will it offer an automatic linking of the existing asset to the product the user wanted to attach the asset to?

* When a user wants to remove an asset (e.g. because the product is no longer present), will the system check and prevent it, if this specific asset is still linked from other products?

* What if a user is not aware that a asset is linked to multiple products and changes metadata to better fit to the single asset he is aware of?

 

Without knowing your constraints and details I have many question which can potentially interfere with this requirement.

On the other hand side, I wonder why this requirement is present. What is the goal of it?

 

 

 

Avatar

Level 3

I also thought about using a common folder, but this will bring me in a situation without a fixed taxonomy. One of the consequences will be then the difficulty to retrieve or search assets.
May I ask you to explain me more about the Live Copy declined on my situation? I think this could be the solution.
Cc: @arunpatidar;

Avatar

Community Advisor

@serenapitotti Obviously there might be some difficulties , but for ease of development , I think we should not deviate from the best approaches. As all has recommended here , duplicating your assets with exact meta data, is a bad design. If the only issue which is stopping you from moving to common folder or using tags is searching the assets ,  then I think you must re-think and brainstorm this with your team once again. You can always use query builder to customize your searches. That should not be something really difficult. I have done asset searches with 10-20 different tag combination in my previous projects. Once implemented, it will work as smooth as butter