Service Layer medium complexity backend
2
Dependencies
0
Dependents
1
Entities
0
Integrations

Description

Service that orchestrates re-generation and re-export of a past Bufdir report using the stored metadata and period parameters. Delegates actual report generation to the bufdir-report-export feature's pipeline and stores the new artifact reference.

Feature: Bufdir Report History & Audit Log

report-reexport-coordinator

Summaries

The Report Re-export Coordinator protects the organisation against data loss and audit failures by enabling any previously generated Bufdir report to be faithfully regenerated on demand using its original period parameters. Without this capability, a corrupted or accidentally deleted report file would require manual reconstruction — a time-consuming, error-prone process that could jeopardise compliance deadlines. By automating re-generation and immediately providing a fresh download link, this service eliminates recovery time, reduces reliance on backup procedures, and ensures the organisation can always produce complete historical evidence for Bufdir audits or internal reviews.

Medium-complexity backend service with two hard dependencies — the Report History Repository and Report File Storage Client — plus a soft coupling to the bufdir-report-export feature's generation pipeline, which must be stable before end-to-end testing of re-export flows can begin. The cross-feature dependency on the export pipeline is the primary scheduling risk: any delays or interface changes there directly block re-export validation. The coordinator must handle long-running generation gracefully — consider whether reexportReport(reportId) should return immediately with a job ID (async pattern) or block until completion, and align this decision with the frontend team early. Rollback strategy for partial failures (generation succeeds but storeReexportResult fails) must be defined.

Report Re-export Coordinator orchestrates a multi-step backend workflow: load the historical record via the Report History Repository, reconstruct export parameters using buildExportParams(historicalRecord), invoke the bufdir-report-export pipeline (injected as a dependency or called via an internal service interface), persist the new file reference with storeReexportResult(reportId, fileRef), and notify completion via notifyReexportComplete(reportId). The coordinator should be idempotent — repeated calls with the same reportId should not produce duplicate history entries. Use a database transaction or optimistic locking to prevent race conditions if two users trigger re-export simultaneously. Store both the original and re-exported file references to preserve audit lineage.

Execution context is backend only.

Responsibilities

  • Load historical report parameters for re-export
  • Invoke report generation pipeline with historical period
  • Store newly generated file reference in history table
  • Return download URL for the freshly generated artifact

Interfaces

reexportReport(reportId)
buildExportParams(historicalRecord)
storeReexportResult(reportId, fileRef)
notifyReexportComplete(reportId)

Relationships

Dependencies (2)

Components this component depends on

Related Data Entities (1)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/report-reexports 5 endpoints
GET /api/v1/report-reexports List re-export jobs with status tracking
GET /api/v1/report-reexports/:reexport_id Get status and result of a specific re-export job
POST /api/v1/report-reexports Trigger a re-export of a historical report with optional parameter overrides
PUT /api/v1/report-reexports/:reexport_id Update re-export job state (e.g. store result file ref, mark notification sent)
DELETE /api/v1/report-reexports/:reexport_id Cancel a pending re-export job