1 person found this helpful
I'm thinking that what you intend to accomplish will require some customization of how CQ5 resolves "references". The API that CQ uses to resolve references, uses a JCR search to find, "What other things in the content repository store the path to this resource?" You have this ability because when everything lives inside of CRX, you can rely on Sling resource resolution to "retrieve" different things (in your case DAM assets). JCR search allows you to find the references. Sling allows you to resolve them.
Now, you want to reference DAM assets by external applications. If you are just retrieving those assets by making HTTP requests from the external app to CQ5, you techincally have nothing maintaining that connection between CQ and the other app. CQ is completely unaware of the fact that something else is requesting one of its pieces of content. It's effectively the same as someone attempting to retrieve that asset by making a browser request. Furthermore, you wouldn't want (in my opinion) CQ to be aware of external systems that are requesting CQ assets. It should be the other way around.
What you want to do is probably difficult, if even possible. In my opinion, if you have need to integrate CQ and non-CQ applications in this way, it may be a flag that you should put serious thought into putting some/all of these "external" applications inside CRX. Maybe there are options for adding a service layer in there or something...tough to say with limited information.
Thanks for your response. I understand retrieving the assets outside CQ applications are straight forward. I was more looking to share DAM to external applications and the way to maintain the assets at enterprise wide level rather than just at CQ application level. I want to share some of the assets between various business units and the way to maintain them. How do I achieve that? Can I just write custom DAM asset editors, share components and made them accessible via CQ webapplication? Even then I have this issue of which other pages (non CQ pages) using the assets when somebody want to delete the assets or renaming the assets. Please let me know if you don't understand what we are trying to achieve with DAM. I can probably explain more.
Yeah, I'm not clear on what you mean by "share DAM to external applications". You want to be able to edit/retrieve DAM assets from within non-CQ applications so that it isn't required that you log into CQ to get to the DAM to make that kind of a change?
No still the users would have to login to DAM alone (restricting all other standard CQ consoles) and based on their access roles - they see and manage the assets. I still need to find out how to maintain the references to the assets if they are being used by external pages (application pages like custom JSP pages, ASP pages, from external applications) ..I am not sure whether this is the right way or not, I am trying to find best way to expose DAM outside. Make any sense?
The DAM is exposed externally via HTTP to the extent that you allow it to be exposed using your web server. My understanding is you want a DAM author to be able to log into the DAM, look at a DAM asset, look at its "References" tab and see where that DAM asset is used in CQ pages (OOTB functionality) and in non-CQ applications/pages...right?
Is the problem that you cannot use DAM assets in external apps? Or is the problem that DAM authors (the people who log into CQ and go to the DAM) have no visibility into which external applications use which DAM assets?
We haven't done anything. I need both the functionalities ideally where external applications can reference DAM assets and DAM authors would be able to see those reference when they are trying to edit or delete the assets. This gives them authors to decide to edit or delete the asset (if the assets is being used by external apps as well) .. I need to find out a best way to achieve this. Is it possible?
The first thing you mentioned...
where external applications can reference DAM assets
...is possible, out of the box. You can reference DAM assets by making HTTP GET requests to them (i.e. http://server:port/content/dam/path/to/my/dam/asset). You can also make POSTs to them (or any content) to update their metadata as well, assuming your POST request is authenticated appropriately.
The second thing you mentioned...
DAM authors would be able to see those reference when they are trying to edit or delete the assets
...requires some significant customization. The APIs set up to resolve "references" in CQ are references that are internal to the content repository. External references will not be accounted for. This is what I meant when I said that CQ/CRX has no knowledge of what is externally making requests to retrieve content (in your case, DAM assets).
Not knowing the details of your environment and what exactly will be referencing the DAM from outside CQ, it's difficult to outline an approach in too much detail. I think, at a high level, you'll need to create some kind of contract between CQ and these external systems. You will have to build something custom in the DAM interface that can ask these external systems if a specific DAM asset is being used. You need this contract so that CQ can interface with external systems the same way every time (I'm assuming each one of these systems has different API and/or means of data retrieval). By creating this intermediary service that standardizes the interface from CQ's perspective, you can kind of "plug in" the different external apps that need to be accounted for. This probably requires substantial effort to accomplish.
Again, this is high-level and not completely thought through, but conceptually does it make sense? This is how I would probably start approaching the problem.
Yes make sense. First part I am clear on the approach. I still trying to figure out how it would be for the second part. I still have to get detailed information from my business on how they want to use this. May be I will post to this thread as and when I get more detailed information and will share my approach and we can take it from there.
Thanks once again for your time and I really appreciate your help!