Zum Hauptinhalt springen

Proof-of-Concept für automatisierte Konvertierung

Diese Seite beschreibt einen prototypischen Ansatz, um bestehende automatisierte Prozesse um eine Konvertierung von OOXML nach ODF zu erweitern.

Python-basierte Konvertierung mit Collabora​

Für erste Praxisexperimente steht das Python-Skript collabora_document_converter.py zur Verfügung. Die Funktion convert_to_odf(...) lädt eine .docx-, .xlsx- oder .pptx-Datei hoch und speichert das Ergebnis als ODF-Pendant.

  1. Hinterlegen Sie zunächst Ihren Collabora-Host (z. B. mein-collabora-server.com) in einer .env-Datei im Projektverzeichnis:

    CONVERTER_HOST=<collabora-host>

  2. Installieren Sie bei Bedarf die benötigte Laufzeitabhängigkeit:

    pip install aiohttp

  3. Binden Sie die Funktion in Ihren Workflow ein:

    import asyncio
    from scripts.python.collabora_document_converter import convert_to_odf

    async def run_conversion() -> None:
        await convert_to_odf("Test-Konvertierung.docx", "documents/converted")

    asyncio.run(run_conversion())

Die Funktion erkennt .docx, .xlsx und .pptx und schreibt die jeweiligen ODF-Pendants (.odt, .ods, .odp) in das angegebene Ausgabeverzeichnis. Sie liefert ein ConversionResult-Objekt mit Pfad, HTTP-Status und Dateigröße zurück. Fehlerhafte Aufrufe werden als ConversionError signalisiert und können in Worker-Prozessen gezielt abgefangen oder erneut eingeplant werden.

Betriebshinweise für Collabora​

  • Schriftarten konsistent halten: Collabora Online ersetzt fehlende Fonts bei der Konvertierung stillschweigend. Um Layoutabweichungen zu vermeiden, installieren Sie auf den Collabora-Servern dieselben Schriftarten, die auch auf den Client-Systemen verwendet werden (z. B. ttf-mscorefonts-installer für Microsoft Core Fonts).

Python-basierte Konvertierung mit LibreOffice (lokal)​

Für Umgebungen ohne Zugriff auf eine Collabora-Instanz existiert ein äquivalentes Skript, das direkt auf eine lokale LibreOffice-Installation zugreift: soffice_document_converter.py. Die Schnittstelle ist bewusst identisch gestaltet, sodass Worker je nach Deployment lediglich den Import austauschen müssen.

  1. Hinterlegen Sie den Pfad zur LibreOffice-Binärdatei (soffice) in der .env:

    SOFFICE_EXECUTABLE_PATH=/opt/libreoffice/program/soffice
    # Optional, siehe Betriebshinweise zum Benutzerprofil
    SOFFICE_USER_PROFILE_PATH=/var/lib/soffice-profile

    Ist der SOFFICE_EXECUTABLE_PATH nicht gesetzt, versucht das Skript, soffice über den PATH zu finden.

  2. Verwenden Sie die Funktion in Ihrem bestehenden Workflow:

    import asyncio
    from scripts.python.soffice_document_converter import convert_to_odf

    async def run_conversion() -> None:
        await convert_to_odf("Test-Konvertierung.xlsx", "documents/converted")

    asyncio.run(run_conversion())

Die Funktion legt das konvertierte Dokument über den LibreOffice-CLI-Aufruf (--headless --convert-to ...) ab, verschiebt es an den gewünschten Zielpfad und liefert ebenfalls ein ConversionResult. Der status spiegelt hier den Exit-Code von soffice wider (0 bei Erfolg). Zeitüberschreitungen, fehlende Pfade oder ein nicht auffindbares soffice werden als ConversionError signalisiert.

Betriebshinweise für LibreOffice​

  • Schriftarten konsistent halten: LibreOffice ersetzt fehlende Fonts stillschweigend. Installieren Sie auf dem Konvertierungsserver dieselben Schriften wie auf den Clients (unter Debian/Ubuntu z. B. apt install ttf-mscorefonts-installer), um Layoutabweichungen zu vermeiden.

  • Benutzerprofil steuern (kritisch für Parallelbetrieb): Jede soffice-Instanz benötigt ein exklusives Benutzerprofilverzeichnis, um Konfigurationen und temporäre Dateien zu speichern. Ein entscheidender Mechanismus ist hierbei eine Lock-Datei, die verhindert, dass mehrere Prozesse gleichzeitig auf dasselbe Profil zugreifen. Dies führt bei falscher Konfiguration unweigerlich zu Fehlern.

    • Standardverhalten (Empfohlen für Parallelbetrieb): Wird SOFFICE_USER_PROFILE_PATH in der .env-Datei nicht gesetzt, erstellt das Skript für jede Konvertierung automatisch ein temporäres, isoliertes Profilverzeichnis. Dies ist die sicherste und empfohlene Methode für Umgebungen, in denen mehrere Konvertierungen gleichzeitig stattfinden könnten (z. B. Web-Server, Worker-Systeme).

    • Manuelle Konfiguration (Nur für sequentielle Verarbeitung): Das Setzen von SOFFICE_USER_PROFILE_PATH weist alle soffice-Prozesse an, dasselbe Verzeichnis zu verwenden.

      • Anwendungsfall: Dies ist nützlich, wenn Sie ein vorbereitetes Profil mit speziellen Erweiterungen, Vorlagen oder Konfigurationen für garantiert sequentielle (nacheinander ablaufende) Batch-Jobs verwenden möchten.
      • Warnung: Im Parallelbetrieb führt diese Konfiguration zu Sperrkonflikten (Race Conditions), bei denen Prozesse hängen bleiben, abstürzen oder das Profil beschädigen. Setzen Sie diese Variable nur, wenn Sie absolut sicherstellen können, dass immer nur eine einzige Konvertierung zurzeit läuft.

  • Performance bei Massenkonvertierung optimieren: Der Start einer neuen soffice-Instanz für jede einzelne Datei erzeugt erheblichen Overhead. Für Szenarien mit hohem Durchsatz gibt es effizientere Betriebsmodelle:

    • Listener-Prozess (z. B. unoconv): Dies ist der De-facto-Standard für serverseitige Konvertierungen. Ein langlebiger soffice-Prozess wird im Hintergrund gestartet und lauscht auf Aufträge. Konvertierungsanfragen werden an diesen Prozess gesendet, was den Start-Overhead eliminiert und die Verarbeitung dramatisch beschleunigt.
    • Containerisierung (z. B. Docker): Jede Konvertierungsaufgabe wird in einem eigenen, kurzlebigen Docker-Container ausgeführt. Dies bietet perfekte Isolation von Profilen, Schriftarten und Abhängigkeiten und ist ideal für Microservice-Architekturen und skalierbare Cloud-Anwendungen.