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!!
Solved! Go to Solution.
Views
Replies
Total Likes
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.
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.
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:
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
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.
@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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies