assign ADM node content = webscript response?

[chrisb]

Hi,

I am trying to find the best way to store the response from a webscript call in an ADM repository node, ideally from Javascript.

I have had a look around the wiki and googled, but can't see an example of this (especially invoking a webscript from within JS code). The idea is to create an ADM node/document that stores the output from a webscript call.

I guess this could be done using a WCM project with a JSP to initiate and capture/store the webscript response? However, I don't want to add the WCM overhead just to do this unless absolutely necessary.

Can anyone point me at an example, or tell me whether its possible to do this? I am using 2.1.1 Enterprise release btw.

Thanks,

Chris

[jbarmash]

Interesting question.

I am assuming you are trying to do some kind of auditing-type functionality for this, so you want ability every time somebody calls a web script, to store the results.   I believe the key here is NOT to let the normal runtime process your freemarker, but to interrupt the process somehow and take control of it.

You can definitely do this through Java fairly easily, where you control the model / freemarker processing, interrupt the output and write it to the repo before flushing it it to HTTP output.

There may be other ways of doing this in JavaScript using ScriptActions API. 
  http://wiki.alfresco.com/wiki/JavaScript_API#Actions_API

Please share if you get it working and how.

[chrisb]

Thanks for the Script actions link - I looked at this, but when listing out the registered actions it seems to include only the core built in actions like mail, and not any of our webscripts registered in our alfresco install. I am guessing I would maybe need to add the webscripts to a config somewhere to may them available via the root actions JS object?

Just to add a bit more background to why I am asking about this - its basically to be able to generate HTML/XML/JSON files stored in the main repository which are then used as the underlying components for assembling web pages. I would need to capture the final output from the webscript, (including the result of the FTL processing), so any streaming / writing to an ADM node would need to be after the FTL component of the webscript has executed.

Going forward we may then decide to copy these ADM nodes/files out to multiple runtime WCM instances (AVM stores), and assemble the final web pages via JSP's, but I want to try and suss out if we can generate these component files in the main repository first.

The website we are generating uses categorised reverse date order sorted lists of items on several main pages, limited to X items per category. We retrieve these via a lucene search of the ADM repo, but then have to effectively reverse date sort and limit the results outside of the Lucene API. Currently this is done in the JS of the webscripts as this is faster than doing it in the FTL section of the webscript, but it is still an expensive operation.

As the item lists only need to be updated every hour or two we can avoid the overhead of a webscript call everytime someone hits the page by the scheduled generation of these lists via the Alfresco scheduling mechanism. This approach also reduces the dependency of front end website rendering performance on the main ADM repository performance, making the system more scalable.

We are already using the webscript caching mechanism to set the pages to cache for an hour, and have an apache / squid caching system in front of the alfresco instance. However if users do a hard refresh in their browser this will always bypass the cache and result in a webscript call on the main repository, which is unneccesary. If we use the interim file component approach described above, the webscript or JSP call needed to assemble the page would be very lightweight compared to running the original Lucene based webscript directly.

If I find out more on this I will add it to this post.

Thanks.

[jbarmash]

Thinking about it some more, the best way to do what you want is to take a look at org.alfresco.web.scripts.DeclarativeWebScript.  This is the class that executes the script.   Take the output of the generated page and store it in the ADM before returning.   

I just saw that the execute method is final, so perhaps you can just clone the orignal class and repoint web-scripts-application-context.xml file to your new one.  It means you'll have to be careful when upgrading, but should work.

[chrisb]

Just as a follow up to this we solved our problem in a different way in the end. The main issue that lead to us considering this caching approach was poor performance in returning large numbers of SORTED search results via the JS lucene search API.

As we were using 2.1.1E the lucene search API call that supports sorting search results was not available to our webscripts via the JS API. As a result we were having to sort our lucene results after they had been returned from the search call in the webscript. This was as you might expect extremely slow. Each call to the sort comparator function in the webscript involved a call to retrieve metadata for 2 nodes (in this case a date based attribute)…..

We patched the JS search API in 2.1.1E to add an extra method found in the 2.9 code that allows a sort parameter to be passed to the search along with an ASc or DESC boolean flag. With this solution in place the webscripts now run a factor of 10 faster which gives acceptable performance.

Longer term we are looking at replacing the webscripts running directly against the main repository with a WCM managed JSP based front end. The JSP's will assemble the web pages we need from calls to webscripts that only supply fragments of content for the page. Within the JSP's we will use a caching tag library along the lines of EhCache or OSCache. This will give us finer control over the cache lifetime of individual components on the pages. For example the search option categories only need to be refreshed at most once or twice a day, whereas other page content needs to be refreshed at least every hour.

On top of this we will still be using the built in cache settings for each webscript, as well as a front facing cache server (squid) between the users and our apache instance.

I still think there is a case for more direct support for being able to persist the response from a webscript into a repository node, but for us the requirement is now not as urgent as it was.

Thanks,

Chris