Der Server verwendet denselben PDF-Kern wie der Desktop, besitzt aber andere Transport- und Speichergrenzen. Ein Upload wird einmal gespeichert und danach über eine Job-ID referenziert. Konfiguration und Vorschau müssen dieselben geprüften Dateien verwenden. Ein begrenzter Worker verarbeitet den Auftrag, während HTTP den Fortschritt liefert. PostgreSQL hält Metadaten. Lokale Dateispeicherung hält die Dokumentbytes. Keine automatische Transaktion verbindet beide Ressourcen.
01Den vollständigen Serverstand vorbereiten
Das Setup prüft Server und benötigte Module. Starte danach in diesem neuen Checkout cp .env.example .env und docker compose up --build. Die Beispieldatei enthält ausschließlich lokale Konfiguration. Die Anwendung liegt laut README auf localhost:8080. Nutze keine bestehende Produktdatenbank für diese Übung.
git clone https://github.com/wasiliy-strecker/pdf-batch-studio.git pdf-batch-studio-learning
cd pdf-batch-studio-learning
git checkout 9b85992b00f8ff20b46bff2b1ed16b59eb3869af
./mvnw -pl server/pdf-batch-server -am test
02Uploadbesitz und Dateigrenzen prüfen
Öffne die Weboberfläche und lade customer-template.pdf mit customers.csv hoch. Der Server erzeugt eine zufällige ID und interne feste Dateinamen. Originalnamen werden nicht als freie Pfade übernommen. Die vollständige Weboberfläche behandelt die vorgesehenen Session- und CSRF-Grenzen. Eine kopierte nackte curl-POST-Anweisung würde diese Regeln nicht automatisch erfüllen.
03Den gespeicherten Job konfigurieren
Inspektion erzeugt DRAFT. Weise name → fullName und customerId → customerNumber zu. Die Konfigurationsroute prüft die Zuordnung und erzeugt READY. Vorschau und Verarbeitung laden dieselben gespeicherten Inputs erneut, statt ungeprüfte Dateien aus einem zweiten Upload anzunehmen.
04HTTP und Hintergrundarbeit trennen
POST process stößt den Worker an. GET job liefert den Zustand. JobApplicationService und JobWorker prüfen erlaubte Übergänge und Kapazität. Die Anzahl paralleler Worker und die Warteschlange sind begrenzt. Ein schneller HTTP-Request bedeutet noch nicht, dass die Verarbeitung beendet ist.
05Download und Retention nachvollziehen
Nach Abschluss liefert die Ergebnisroute das ZIP als Stream. Prüfe Inhalt, Namensregeln und Report. Nicht aktive Jobs werden nach der konfigurierten Aufbewahrung entfernt. Aktive Jobs dürfen nicht versehentlich durch einen normalen Löschablauf verschwinden. Lies die API-Lifecycle-Dokumentation und die Cleanup-Tests.
06Fehlergrenzen reproduzieren
Lade invalid-empty-header.csv hoch und prüfe die verständliche Ablehnung. Versuche Verarbeitung vor gültiger Konfiguration. Wiederhole mit einem abgebrochenen Auftrag. Die HTTP-Suite erzeugt echte AcroForms, lädt sie hoch und liest die Ergebnisdateien semantisch. Ein nicht ausgeführter PostgreSQL-Test bei fehlendem Docker ist kein bestandener Datenbanknachweis.
Ein gültiger Upload erreicht DRAFT, READY und einen abgeschlossenen Ergebniszustand. Das ZIP enthält die erwarteten PDFs. Ungültige Inputs werden vor der Verarbeitung abgewiesen.
- HTTP / Session
- JobApplicationService
- PostgreSQL + Workspace
- begrenzter Worker
- ZIP-Stream / Retention
Deine Übung
Stoppe den Server nach dem Upload, bevor die Verarbeitung beginnt. Prüfe nach einem Neustart Metadaten und vorhandene Dateien.
Lösung mit Erklärung anzeigen
Ein Docker-Neustart mit erhaltenen Volumes muss die dauerhaften Ressourcen behalten. Die Projektregeln bestimmen, welche Zustände wieder nutzbar sind und welche unterbrochene Arbeit markiert wird. Prüfe beides ausdrücklich. docker compose down beendet Container, ohne die Volumes zu löschen. Eine volume-löschende Variante gehört nicht zu dieser Übung.
Projektbezug und Quellen
Das Beispiel ist zum Lernen vereinfacht. Die verlinkte Codeversion zeigt die Anwendung im Projekt und die dortigen Prüfungen.