-
Notifications
You must be signed in to change notification settings - Fork 18
Maven Module Structure
The project is organized into Maven submodules. The parent POM acts as a BOM (Bill of Materials) for dependency version management across all modules.
Spring is used only in the webapp module (Spring Boot application entry point and REST controllers). All other modules are framework-independent and use ph-db for JDBC-based database access, following the same patterns as phoss-smp.
graph TD
parent[phoss-ap-parent]
api[phoss-ap-api]
basic[phoss-ap-basic]
db[phoss-ap-db]
fwd[phoss-ap-forwarding]
sentry[phoss-ap-sentry]
validation[phoss-ap-validation]
core[phoss-ap-core]
webapp[phoss-ap-webapp]
api --> parent
basic --> parent
db --> parent
fwd --> parent
sentry --> parent
core --> parent
webapp --> parent
basic --> api
db --> api
fwd --> api
fwd --> basic
sentry --> api
validation --> api
validation --> basic
core --> api
core --> db
core --> fwd
webapp --> core
webapp --> fwd
webapp --> sentry
webapp --> validation
Straight lines mean "depends on".
The root POM. Acts as the BOM for all dependency version management (phase4, peppol-commons, peppol-reporting, ph-db, ph-commons, Spring Boot, PostgreSQL driver, Flyway, etc.). All submodules inherit from this POM.
Java interfaces, shared model classes, and enums. This is the contract layer that all other modules depend on.
Contains:
-
IDocumentPayloadManager— interface for reading, writing, and deleting document files (implemented by phoss-ap-basic, accessible viaAPBasicMetaManager) -
IDocumentForwarder— interface for forwarding received documents to the Receiver Backend (implemented by phoss-ap-forwarding) - Notification interface — generic failure notification SPI
- Retry strategy interface — customizable retry behavior (max attempts, backoff)
- Receiver check interface (
IReceiverCheckor similar) — pluggable SPI for verifying that this AP services the addressed receiver participant - Document verification interface (
IDocumentVerifieror similar) — optional pluggable verification SPI for both outbound and inbound documents - Domain model classes (transaction types, status enums, MLS codes, etc.)
- Callback interfaces (
onSuccessfulAS4Sending, etc.)
Dependencies: Minimal — ph-commons only.
Basic implementations and utilities that build on the API layer. This module provides reusable building blocks that don't require database or framework dependencies.
Contains:
-
DocumentPayloadManagerFileSystem— default implementation ofIDocumentPayloadManagerthat stores documents as flat files on the local filesystem, organized by date/hour directories -
DocumentPayloadManagerS3— alternative implementation ofIDocumentPayloadManagerthat stores documents in Amazon S3, usings3://bucket/keyURIs as opaque document paths -
APBasicMetaManager— singleton providing access to the document storage provider (selected viastorage.modeconfiguration), identifier factory, and timestamp manager - HTTP proxy configuration helper
Dependencies: phoss-ap-api, AWS SDK for S3.
No Spring dependencies in this module.
Database access layer for PostgreSQL using ph-db (JDBC wrapper).
Contains:
- Flyway migration scripts for PostgreSQL (under
resources/db/migrate-postgresql/) - JDBC manager classes extending
AbstractJDBCEnabledManager, one per table group:-
OutboundTransactionManagerJDBC— CRUD foroutbound_transactionandoutbound_sending_attempt -
InboundTransactionManagerJDBC— CRUD forinbound_transactionandinbound_forwarding_attempt -
ArchivalManagerJDBC— move completed transactions to archive tables
-
- DB query logic using
DBExecutorwithConstantPreparedStatementDataProviderfor parameterized queries - Flyway configuration class (similar to
SMPFlywayConfigurationin phoss-smp) - DataSource provider / JDBC configuration class
Dependencies: phoss-ap-api, ph-db-jdbc, PostgreSQL JDBC driver, Flyway.
No Spring dependencies in this module.
Core business logic and orchestration. This is the central module that ties together AS4 sending/receiving, DB operations, retry scheduling, MLS handling, and reporting.
Contains:
- Outbound orchestration: receive from API → store document to disk → record in DB → verify (optional) → send via phase4 → record attempt → trigger reporting
- Inbound orchestration: receive via phase4 servlet → duplicate check → receiver check → store document to disk → record in DB → verify (optional) → forward → record attempt → reporting
- MLS handling: generate MLS responses (as C3), receive and correlate MLS responses (as C2)
- Retry scheduler: periodic retry of failed outbound sends and failed inbound forwarding
- Archival scheduler: move completed transactions to archive tables
- Reporting integration: callbacks and peppol-reporting integration
- Notification dispatch: invoke generic notification interface on permanent failures
- Graceful shutdown logic
Dependencies: phoss-ap-api, phoss-ap-db, phase4-peppol-client, phase4-peppol-servlet, peppol-reporting, peppol-commons.
No Spring dependencies in this module.
Optional Sentry error tracking integration. This module provides a notification handler that reports business-level failure events to Sentry with structured attributes.
Contains:
-
APNotificationHandlerSentry— implementation ofINotificationHandlerSPIthat logs failure events (sending failures, forwarding failures, verification rejections, reporting failures) to Sentry
Dependencies: phoss-ap-api, io.sentry:sentry.
No Spring dependencies in this module. The Spring wiring (Logback appender registration, conditional activation via sentry.dsn) lives in phoss-ap-webapp.
Optional module providing document verification via the phorm Validation Service. Implements both IInboundDocumentVerifierSPI and IOutboundDocumentVerifierSPI in a single shared class (ValidationServiceDocumentVerifier).
Contains:
-
ValidationServiceDocumentVerifier— calls the phorm Validation Service's/api/dd_and_validate/endpoint, parses the phive JSON response, and rejects documents withINVALIDoverall conformance - ServiceLoader registration files for both inbound and outbound verifier SPIs
Dependencies: phoss-ap-api, phoss-ap-basic, ph-httpclient, ph-json, phive-result.
No Spring dependencies in this module.
All forwarding implementations in a single module. The active forwarding mode is selected at runtime via the forwarding.mode configuration property.
Contains:
- HTTP POST forwarder (async reporting variant) — posts SBD to configured endpoint
- HTTP POST forwarder (sync reporting variant) — posts SBD, reads C4 country code from response
- S3 uploader — stores the SBD in a configured S3 bucket
- SFTP uploader — uploads the SBD to a configured SFTP server using ph-jsch abstractions
Dependencies: phoss-ap-api, phoss-ap-basic, Apache HttpClient, AWS SDK for S3, ph-jsch (com.helger.web:ph-jsch).
No Spring dependencies in this module.
The Spring Boot application that assembles everything into a runnable deployment. This is the only module that depends on Spring.
Contains:
- Spring Boot application entry point
- REST controllers (outbound submit, status queries, inbound reporting API)
- AS4 servlet configuration (phase4 Peppol servlet registration)
- Application configuration (application.properties)
- Security / authentication (API token handling)
- Wiring: connects Spring Boot to the non-Spring core via dependency injection of manager instances
Dependencies: phoss-ap-core, phoss-ap-forwarding, phoss-ap-sentry, Spring Boot.
A deployment includes:
phoss-ap-parent
└── phoss-ap-api
└── phoss-ap-basic
└── phoss-ap-db
└── phoss-ap-forwarding
└── phoss-ap-sentry
└── phoss-ap-validation
└── phoss-ap-core
└── phoss-ap-webapp
All forwarding implementations are included in the single phoss-ap-forwarding module. The active forwarding mode is selected at runtime via the forwarding.mode configuration property.
It is appreciated if you star the GitHub project if you like it.
Donation link: https://paypal.me/PhilipHelger
- Home
- News and noteworthy
- Running phoss AP
- Architecture Overview
- API Specification
- Configuration Properties
- Code Lists
- Database Design Notes
- Maven Module Structure
- Runtime Extensions
- OpenTelemetry Integration
- Security Considerations
- Peppol Specifics
- Testing Without Peppol Network
- Known Users
- Migrating from phase4-peppol-standalone
- Contributing