Kitodo ist eine quelloffene Softwaresuite für die Digitalisierung von Kulturgut in großen wie kleinen Bibliotheken, Archiven, Museen und Dokumentationszentren.
Kitodo.Production ist das Workflowmanagementmodul der Kitodo-Suite. Es unterstützt den Digitalisierungsprozess von verschiedenen Materialarten wie Drucken, Periodika, Handschriften, Noten und Musikalien, Einblattmedien und Dokumentennachlässen. Kitodo.Production ist als Webapplikation in Java programmiert und kann plattform- und ortsunabhängig über einen herkömmlichen Webbrowser bedient werden.
Dieses Arbeitspaket beschreibt die Implementierung REST-Schnittstelle für Kitodo.Production.
1. Teilnahmebedingungen
Zum Nachweis von Erfahrungen mit Java sind drei Referenzen aus den vergangenen drei Jahren einzureichen. Referenzen können z.B. realisierte Projekte mit Beschreibung der eigenen Arbeitsanteile sein. Eine möglichst große Passgenauigkeit der Referenzprojekte zu den Inhalten der Leistungsbeschreibung sind dabei von Vorteil (s. a. 5. Zuschlagskriterien).
Zudem ist der Nachweis von Erfahrungen in der Entwicklung von Open-Source-Systemen bzw. der Durchführung von Open-Source-Projekten in vergleichbarer Weise zu erbringen.
Dem Angebot ist ein detaillierter Zeitplan beizufügen, aus dem ersichtlich ist, wann welche Arbeitsschritte innerhalb der vorgesehenen Projektlaufzeit von sechs Monaten durchgeführt werden. Der Zeitplan soll die geplanten Meilensteine (z.B. Beginn der Entwicklung, Implementierung, Erstellung der Pull-Requests, etc.) sowie den voraussichtlichen Aufwand pro Phase enthalten.
2. Angebotsfrist
Die Frist für die Abgabe eines Angebots ist der 18.09.2026.
3. Leistungsbeschreibung
Ausgangssituation/Hintergrund:
Kitodo.Production verfügt über eine ActiveMQ-Schnittstelle, über die verschiedene Aktionen in Kitodo von externen Systemen ausgelöst werden können. Viele Einrichtungen, die Kitodo einsetzen, nutzen diese Funktion nicht: Der Aufwand einen ActiveMQ-Brokes aufzusetzen ist vergleichsweise hoch, außerdem müssen Umsysteme ggf. noch in die Lage gebracht werden über ActiveMQ zu kommunizieren.
Leistungen
Im Rahmen dieses Arbeitspaketes soll ein REST-Interface in Kitodo.Production implementiert werden, welches die Kommunikation zwischen Kitodo und externen Systemen vereinfacht.
Grundsätzlich richtet sich der zu implementierende Leistungsumfang nach den bereits über ActiveMQ zur Verfügung stehenden Funktionen, ist aber nicht ganz darauf beschränkt. Insbesondere soll die Ausführung von Kitodo-Skripten und das Ändern von Vorgangs- und Aufgabenzuständen via Korrektur-Workflows über die REST-Schnittstelle äquivalent zur aktuellen Funktionsweise über ActiveMQ ermöglicht werden.
Alle REST-Endpunkte müssen über eine Authentifizierung abgesichert sein. Die Benutzer müssen Ihre Kitodo-Benutzerdaten bei Requests gegen die REST-Endpunkte mitgeben.
Die REST-Endpunkte sollen Antworten im JSON-Format zurückgeben. Diese müssen neben den abgefragten Daten passende http-Status-Codes und verständliche Erfolgs- bzw. Fehlermeldungen zurückgeben.
Es soll eine neue Berechtigung (e.g. „useRestInterface“) in Kitodo eingeführt werden, die die prinzipielle Voraussetzung für die Verwendung der REST-Schnittstelle darstellt. Verfügt das Konto des Kitodo-Nutzenden nicht über diese Berechtigung, sollen Anfragen an die REST-Endpunkte mit einem entsprechenden http-Fehler-Code abgewiesen werden (z.B. 403, „Forbidden“).
Zusätzlich benötigt der Kitodo-Nutzende zur Verwendung einzelner REST-Endpunkte die gleichen Berechtigungen, die auch zur Ausführung der korrespondierenden Aktion über die Oberfläche von Kitodo.Production benötigt werden. Zur Abfrage der Basisdaten eines Vorgangs wird neben der neuen REST-Nutzungsberechtigung z.B. die bereits existierende Berechtigung „viewProcess“ benötigt. Details zu den benötigten Berechtigungen werden in der folgenden Liste der zu implementierenden REST-Endpunkte beschrieben.
Vorgänge
REST-Endpunkte für die folgenden Interaktionen mit Digitalisierungsvorgängen in Kitodo.Production sind zu implementieren. Bei Anfragen an die jeweiligen REST-Endpunkte wird die ID des Vorgangs als Parameter zur Identifikation des jeweiligen Vorgangs mitgegeben.
Folgende Daten von Vorgängen sollen via REST-Schnittstelle abfragbar sein:
- Vorgangs-Aufgaben inkl. Status (abgeschlossen, offen, in Arbeit, blockiert)
- Basis-Daten: Projekt, Produktionsvorlage, Regelsatz, Workflow (jeweils ID, Titel)
- Metadaten: Metadaten-Datei „meta.xml“
Folgende Aktionen sollen auf Vorgänge ausgeführt werden können:
- Ausführung von Kitodo-Skripten:
→ Zusätzliche Parameter:
• Name des KitodoSkripts
• benötigte Parameter des KitodoSkripts in einer Map als Key-Value-Paare
→ Rückgabe: Erfolgsstatus der KitodoSkript-Ausführung
→ Bemerkungen:
• die Aktivierung einzelner Kitodo-Skripte sollte wie bei ActiveMQ über die Datei „kitodo_config.properties“ geschehen, d.h. alle Skripte, die über die REST-Schnittstelle ausführbar sein sollen, müssen explizit über die Konfiguration aktiviert werden
• Kitodo-Skripte, die derzeit nicht über ActiveMQ angestoßen werden können, sind nicht Teil der Ausschreibung - Auslösen von Korrektur-Workflows:
→ Zusätzliche Parameter:
• ID von Korrekturaufgabe
• Korrektur-Nachricht
→ Rückgabe: Erfolgsstatus der Auslösung eines Korrektur-Workflows
→ Bemerkungen:
• das Auslösen eines Korrektur-Workflows über die REST-Schnittstelle ist den gleichen Regeln unterworfen wie das Auslösen eines Korrektur-Workflows über ActiveMQ oder die Kitodo-Oberfläche: die Korrekturaufgabe muss vor der aktuellen Aufgabe liegen; es darf keine parallele Aufgabe in Bearbeitung durch einen anderen Nutzer sein
Projekte
Zur Abfrage von Informationen zu Projekten sollen die folgenden REST-Endpunkte mit lesendem Zugriff auf das System implementiert werden. Zur Identifikation eines Projektes wird bei der Abfrage dessen ID mitgegeben.
Lesende Zugriffe auf bestehende Projekte:
- Abfrage: Projekt-Basisdaten
→ Rückgabe: Projektinformationen der ersten beiden Tabs aus der Projekt-Bearbeitungsmaske
→ Benötigte Berechtigung:
• „viewProject“ - Abfrage: METS-Parameter
→ Rückgabe: METS-Parameter des dritten Tabs der Projekt-Bearbeitungsmaske
→ Benötigte Berechtigung:
• „viewProject“ - Abfrage: Workflow
→ Rückgabe: Workflow-Title und -ID
→ Benötigte Berechtigung:
• „viewProject“ - Abfrage: Produktionsvorlagen
→ Rückgabe: Liste von Produktionsvorlagen als Liste der Map mit IDs und Titeln der einzelnen Produktionsvorlagen
→ Benötigte Berechtigung:
• „viewProject“ - Abfrage: Standard-Importkonfigurationen
→ Rückgabe: ID und Titel der beiden Standard-Importkonfigurationen des Projektes
→ Benötigte Berechtigung:
• „viewProject“ - Abfrage: Vorgänge
→ Rückgabe: Liste aller Vorgänge des Projekts als Liste oder Map mit IDs und Titeln der einzelnen Vorgänge
→ Benötigte Berechtigung:
• „viewProject“
→ Zusätzliche Parameter:
• Index des ersten abzufragenden Vorgangs innerhalb der Liste aller Projektvorgänge
→ Bemerkung: der Endpunkt sollte die Vorgänge in Teillisten festgelegter Länge zurückgeben; der Index des ersten Vorgangs in der Teilliste wird als zusätzliche Parameter mitgegeben (siehe oben) - Abfrage: Projekt-Ordner
→ Rückgabe: Informationen zu konfigurierten Projekt-Ordnern
→ Benötigte Berechtigung:
• „viewProject“
Abfragen nach verschiedenen Projektinformationen können bei Bedarf in REST-Endpunkten zusammengefasst werden.
Wo sinnvoll, sollen REST-Endpunkte thematisch gebündelt und ihre Pfade entsprechend verschachtelt implementiert werden.
Dedizierte REST-Endpunkte zur Erzeugung neuer Projekte oder Vorgänge ist nicht Teil dieser Ausschreibung. Die Umsetzung der Punkte aus der Leistungsbeschreibung sollte jedoch so geschehen, dass Sie eine zukünftige Erweiterung um neue Endpunkte für weitere Funktionalitäten berücksichtigt und ohne prinzipielles Refactoring möglich ist.
GitHub-Issue: https://github.com/kitodo/kitodo-production/issues/6954
Dokumentation
Der Quellcode muss gemäß den Kitodo Coding Guidelines dokumentiert werden. Abweichungen werden mit dem Release Management abgesprochen.
Rahmenbedingungen
Die Entwicklung von Kitodo.Production erfolgt vollständig auf GitHub im Repository.
Das Releasemanagement für dieses Repository ist bei der Firma effective WEBWORK GmbH angesiedelt. Zu Beginn der Entwicklung muss mit dem Release Management die Vorgehensweise abgesprochen werden (z.B. Feature-Branch). Grundsätzlich arbeitet der Dienstleister in seinem eigenen Fork und bietet seine Entwicklungen als Pull-Request an. Jeder entwickelte Code muss mit Unit- und Integration-Tests getestet sein. Änderungen am Frontend müssen mit Selenium-Tests abgedeckt werden. Es ist anzustreben, möglichst kleinteilige Pull-Requests zu erstellen, die leicht und schnell gereviewt werden können.
Abnahme
Das Mergen in den Main-Entwicklungszweig durch das Releasemanagement gilt als Abnahme.
4. Zeitplanung
Der Beginn der Arbeiten soll in der Regel unmittelbar nach Auftragsvergabe erfolgen. Wegen möglicher Abhängigkeiten von anderen Entwicklungen ist der tatsächliche Beginn mit dem Releasemanagement abzusprechen
Der Abschluss der Entwicklung muss innerhalb von 6 Monaten, nach Beginn der Arbeiten erfolgen. Für diese Zeit ist wird angestrebt, dass sich der Quellcode nicht grundlegend ändert.
Die Geschäftsstelle muss monatlich über den aktuellen Stand der Entwicklungen informiert werden.
Änderungen am Zeitplan müssen frühzeitig kommuniziert und vom Auftraggeber abgestimmt werden.
5. Zuschlagskriterien
Den Zuschlag erhält das wirtschaftlichste Angebot unter Berücksichtigung der angebotenen Leistungen, der nachgewiesenen Referenzen (s. a. 1. Teilnahmebedingungen) und des Preises.
6. Vertragsbedingungen
Lizenzierung als Open Source Software
Der vollständige Quellcode und alle damit in Verbindung stehenden elektronischen Ressourcen (Images, Stylesheets, etc.) sind unter GNU General Public License in der Version 3 (GPL3) oder neuer an den Kitodo e. V. zu lizensieren. Werden Frameworks, Bibliotheken, Fonts oder andere Software Dritter verwendet, so müssen diese Bestandteile ebenfalls unter einer mit der GPL3 kompatiblen Lizenz vorliegen und die Lizenz explizit ausweisen.
Die freie Lizenzierung schließt die Dokumentation ein.
7. Einzureichende Unterlagen, Erklärungen und Nachweise
Zur Abgabe eines Angebots ist das angehängte Formblatt zu nutzen.
Darüber hinaus müssen folgende Erklärungen und Nachweise beigelegt werden:
- Handelsregisterauszug
- Referenzen (s. 1. Teilnahmebedingungen)
- Zeitplan (s. 1. Teilnahmenbedingungen)
Alle Unterlagen sind in elektronischer oder gedruckter Form in der Geschäftsstelle des Vereins Kitodo e. V. einzureichen.
8. Ansprechpersonen
Kitodo e. V.
Magdalena Eberle
Kitodo. Key to digital objects e. V. | Geschäftsstelle
c/o Staats- und Universitätsbibliothek Hamburg Carl von Ossietzky
Von-Melle-Park 3
20146 Hamburg
contact@kitodo.org
040-300393-213
Release-Management für Kitodo.Production
Arved Solth
effective WEBWORK GmbH
Neuer Wall 18
20354 Hamburg
solth@effective-webwork.de
040-609408577