The server uses the same PDF core as the desktop but has different transport and storage boundaries. An upload is stored once and subsequently referenced through a job ID. Configuration and preview must use the same checked files. A bounded worker processes the job while HTTP reports progress. PostgreSQL stores metadata. Local file storage holds document bytes. No automatic transaction joins those resources.
01Prepare the complete server version
Setup checks the server and required modules. In this new checkout, run cp .env.example .env and docker compose up --build. The example file contains only local configuration. According to the README, the app runs on localhost:8080. Do not use an existing product database for this exercise.
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
02Check upload ownership and file limits
Open the web interface and upload customer-template.pdf with customers.csv. The server creates a random ID and fixed internal file names. Original names are not accepted as arbitrary paths. The complete interface handles the intended session and CSRF boundaries. A copied bare curl POST would not automatically satisfy those rules.
03Configure the stored job
Inspection produces DRAFT. Map name → fullName and customerId → customerNumber. The configuration route checks the mapping and produces READY. Preview and processing read the same stored inputs again rather than accepting unchecked files from a second upload.
04Separate HTTP and background work
POST process starts the worker. GET job returns state. JobApplicationService and JobWorker check transitions and capacity. Parallel workers and the queue are bounded. A fast HTTP request does not mean processing has finished.
05Trace download and retention
After completion, the result route streams the ZIP. Check contents, naming rules and the report. Inactive jobs expire after configured retention. Active jobs must not accidentally disappear through ordinary deletion. Read the API lifecycle documentation and cleanup tests.
06Reproduce failure boundaries
Upload invalid-empty-header.csv and check understandable rejection. Try processing before valid configuration. Repeat with a cancelled job. The HTTP suite generates real AcroForms, uploads them and semantically reads results. An unexecuted PostgreSQL test because Docker is unavailable is not passed database evidence.
A valid upload reaches DRAFT, READY and a completed result state. The ZIP contains expected PDFs. Invalid inputs are rejected before processing.
- HTTP / session
- JobApplicationService
- PostgreSQL + workspace
- bounded worker
- ZIP stream / retention
Your exercise
Stop the server after upload but before processing. After restarting, check metadata and existing files.
Show the solution and explanation
A Docker restart retaining volumes must preserve durable resources. Project rules determine which states remain usable and how interrupted work is marked. Check both explicitly. docker compose down stops containers without deleting volumes. A volume-deleting variant is not part of this exercise.
Project context and sources
The example is simplified for learning. The linked source version shows its use in the project and the checks applied there.