Expand my Community achievements bar.

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

nt:file or dam:Asset for better performance

Avatar

Level 4

Hi Team,

 

I am programmatically creating pdf , docx and txt files and saving in /content/projectFolder. I need good/fast performance when I want to save these files in AEM programmatically . I am thinking if I create nt:file as jcr:primaryType then it will be faster as compared to dam:Asset(since nt:file will not create renditions, related or metadata nodes) . Shall I go ahead with nt:file? 

 

Thanks!!

1 Accepted Solution

Avatar

Correct answer by
Level 4

Hi @kautuk_sahni  @aanchal-sikka @himanshu ,

 

What I found was it's better to go with dam:Asset because if I want to put some custom properties on nt:file,  jcr is not allowing to add custom properties on nt:file or nt:resource node . Hence I am switching to dam:Asset. Also we have good no of APIs to create and manage dam:Asset as compared to nt:file. Hence I believe it's better to go with dam: Asset.

 

Thanks,

Ramesh.

View solution in original post

7 Replies

Avatar

Employee

Why are you bringing in these files to AEM if you don't want them to be treated as assets?

 

/content/dam is the designated area in AEM for assets. By placing these files outside DAM you will not get the assets UI to access these files.

 

Review your use-case and decide if these files are not needed in AEM as assets. If you need them, let them be assets.

Avatar

Community Advisor

Hello @Uppari_Ramesh 

 

Its not just the upload that you need to worry about, but also how these assets/files are to be used/maintained.

 

If the authors want to use features specific to PDF, DOCX, then these need to uploaded as dam:Asset

Example of features:

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/assets/manage/manag...

 


Aanchal Sikka

Avatar

Level 4

Hi @aanchal-sikka @himanshu ,

 

My requirement is the assets should not be visible to authors and that's the reason I am not storing assets in /content/dam. These assets are always accessed via Java program only. So I am thinking of creating nt.files instead of dam:Asset. Would like to if it increases the performance.

 

Thanks

Avatar

Employee

For access control, use ACLs to hide the assets from authors. given the assets are only required to be accessed programmatically (TBH, without the detailed use-case its hard to validate if this is a good approach) you should anyway use a service user.

 

Have you done any performance test for Assets API (REST) or AssetManager(Java) to compare the performance with nt:file creation? is the volume/frequency really that significant to build this custom?

 

Again, without looking at the detailed use-case its hard to advice but having assets outside DAM is certainly an anti-pattern.

Avatar

Administrator

@Uppari_Ramesh Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.

 



Kautuk Sahni

Avatar

Correct answer by
Level 4

Hi @kautuk_sahni  @aanchal-sikka @himanshu ,

 

What I found was it's better to go with dam:Asset because if I want to put some custom properties on nt:file,  jcr is not allowing to add custom properties on nt:file or nt:resource node . Hence I am switching to dam:Asset. Also we have good no of APIs to create and manage dam:Asset as compared to nt:file. Hence I believe it's better to go with dam: Asset.

 

Thanks,

Ramesh.

Avatar

Community Advisor

Thanks for sharing the reasons with us @Uppari_Ramesh .

 

Wishing you a great day !

 


Aanchal Sikka