cancel
Showing results for 
Search instead for 
Did you mean: 

How to remotely process/parse a queue in Alfresco (CMIS?)

alexr
Champ in-the-making
Champ in-the-making
I am trying to determine a best practice for a remote server application to process a queue in Alfresco.

In Documentum a common solution was to parse the dmi_queue_item on the remote server through a query:
select stamp from dmi_queue_item where name = '<<specific render process name here>>' and delete_flag = False;

From the document (node) that is related to a specific dmi_queue_item entry (i.e. the document to be processed) the application
needs to access custom attributes.

1.) What would be the common way to do this in Alfresco?
- Populating the queue in Alfresco
- Parsing the queue on the remote server and setting a delete_flag like semaphore on items that have been processed.

2.) How does the Alfresco queue mechanism relate to a task/workflow in Alfresco?

3.) Does the current CMIS support this kind of solution (Alfresco Labs 3.2)? Closest thing to DQL would be the CMIS query (CQL) But then of course it would also have to support retrieving custom attributes
and not only reading the queue but also setting a semaphore, uploading a rendition to the document or a changed version of a document.

Regards,

Alex
3 REPLIES 3

mrogers
Star Contributor
Star Contributor
I think this could be problematic.   Although Alfresco has all the components to build a remote queueing system (and in fact uses these internally for actions and workflows)  AFAIK there is no exposed "Queueing API", in particular there is no "test and set" or "poll" operation.   It would be a fairly easy addition,  but its not there at the moment.

You are right that you could use actions or workflow but then the logic for processing the actions needs to be on the alfresco server rather than in your remote process.    The advantage here is that you can easily hold a transaction lock while you are processing a node.

Reading properties, uploading new versions is all standard stuff.

alexr
Champ in-the-making
Champ in-the-making
Thanks Mark.

Since you mentioned that the queue/task accessing is already used in Alfresco internally and should be easily
exposed through an external API. How can I propose to have this put on the roadmap for any future Alfresco releases?

Do you think exposing this kind of functionality externally through CMIS could/should be put on the list of proposed features to be adopted by the CMIS group?
The queue object could be exposed for instance through CMIS sql (CQL) ("select" and "update" queries) as with the dmi_queue_item in Documentum.

Of course a temporary solution could be to use Alfresco's functionality rules/actions to update a custom property used solely for the purpose of the external process
to select the documents with the property set to a certain value to be marked as to be processed.
This means to CMIS query all documents (perhaps of a certain type), instead querying  a queue object. Process the document in the external application and then
having the external application  set (again through CMIS) the custom attribute to a not-to-be-processed value.
This is technically valid, but certainly not a best practice to implement a process on a content management system. The solution should work even on an existing document type
and not introduce extra metadata to make it work. That's why you normally implement business processes with workflows, lifecycles etc. that contain the extra information on
the document concerned.


Regards,

Alex

mrogers
Star Contributor
Star Contributor
To suggest an enhancement for Alfresco you can discuss it here, then if there is a firm proposal, raise an Enhancement Request in JIRA.  
(If it's not in JIRA then it can't be worked on)
However the list of enhancements for Alfresco is already long and competition for resources to implement new features is fierce.
Even better would be to develop a solution and contribute it to Alfresco which you also do though JIRA.

AFAIK the CMIS interface (and CQL) does not support UPDATE semantics.     I'm by no means an expert so perhaps someone with more knowledge could come in on the discussion?