First of all, I really like the idea of having an API where I could trigger certain actions. One thing that comes to mind is operating on processes, like KitodoScripts do which to my knowledge can currently only be operated through the GUI.

When it comes to the DMS-export (a feature I have never used and currently have no clue about its purpose and function) I have to ask: why would you want to control it through an external application instead of making it an automatic step as described in the documentation?
And, if for some reason you can't make it an automatic step but need the trigger from an external application, why don't you use this application to fetch the data you need instead of resorting to Kitodo's internal function. (This question can maybe only occur to someone who doesn't understand the function. I found this suggestion when looking for information about the feature itself which I couldn't find elsewhere.)

I hope answering these questions helps to clarify the importance of your suggestion. (:

Ok, I have looked up the dms-export function in the documentation by now and understand its purpose. We are probably going to use this at some point. From what I gathered it is currently possible to make a workflow step at the same time automatic and a dms-export.
But you don't want just an automatic step but a step triggered by an external application. Ok. Still speaking about things I've only planned but not implemented, I would have assumed you could use a trigger step followed by the automatic export step and close the trigger step through ActiveMQ's FinalizeStep Queue. At least that is how I suppose things should work.
Does this not work for you? I would really like to know because I've been planning to use that a lot.

Thanks for the questions.

• Currently we need the export (in the end for the publication) for a project of several thousand processes which have not the "automatic DMS export" in the workflow. The workflow can not be changed afterwards.
• We publish in batches (e.g. 50 -100 processes at once) and in each, several errors can happen (METS-File not generated, METS-File not accepted by the presentation platform, upload of images fails, etc). Checking whether it worked or to find where the error is for a kitodo user would be cumbersome or even not possible.
• since we need the METS-File, this data can not be derived easily without kitodo

Maybe with the following solution, you can get rid of the script that imitates a user:

• you can apply the Export DMS in the action-menu of the process list to export several processes.

Here is what i do, if i want to export metadata of many processes. This works in the SLUB Dresden for around 1500 non-hierarchical processes without image data.

1. Choose "Abgeschlossene Vorgänge anzeigen" in the actions-menu
2. Search for the processes of a project, which should be exported
3. Choose "Exceldatei erzeugen" in the actions-menu in the process list
4. Copy some Kitodo-ID out of the Excel file into the filter-box with prefix id: as for example: id: 567308 567309 567310 567311 567312 567313
5. Select the processes, which need to be exported by Alle Treffer dieser Seite or Alle Treffer
6. Apply Export DMS in the actions-menu
7. The processes are then processed in the task manager without manual efforts

Most of the time has to be invested in managing the Excel file. However, if you know how many processes can be exported (e.g. per day) and if these are correctly marked as exported, you can integrate this quite well into your day-to-day business.

Aborted exports are documented in a log. We have a lot of misspelled values for collections, script types, ... because we used the value lists for these elements in Kitodo.Production 3. It is an effort to correct the processes, but afterwards, you will have correct data.

If i did not understand your requirements and this does not help you, just ignore it ;-)

Votes: 2

Thanks(!) for the hint that Export DMS can be triggered via the action-menu. This is a nice backup in case our script does not work anymore but shifts the work (in our case back) to the end user. Anyway, ... it seems to have not a high priory in the community (currently) and maybe such a service can be provided in future via ActiveMQ.

but shifts the work (in our case back) to the end user.

That is true, but in my opinion, the most effort is to define the list of processes, which should be exported.
I think, this is necessary too, when you work with ActiveMQ. But maybe i lack of the necessary information about the implementation.

For projects with less then ~1.000 processes, you might not need to create the Excel list and just export the processes at once. Then, the export is quite quick.

I'm reopening this issue because the functionality is not yet implemented. Others also need these if clicking is not an option in an automated system.