phase4 provides two orthogonal retry mechanisms: PMode reception awareness (AS4 protocol-level reliability) and HTTP transport retries (connection-level resilience).Documentation Index
Fetch the complete documentation index at: https://mintlify.com/phax/phase4/llms.txt
Use this file to discover all available pages before exploring further.
PMode reception awareness
Reception awareness is configured per-PMode viaPModeReceptionAwareness. It governs the AS4 reliability layer: whether the sender should retry delivery when no receipt is received.
Default values
| Property | Default |
|---|---|
receptionAwareness | true |
retry | true |
maxRetries | 1 |
retryIntervalMS | 10000 (10 seconds) |
duplicateDetection | true |
Configuring PModeReceptionAwareness
Profile retry defaults
Different profiles ship with different retry configurations:| Profile | Max retries | Retry interval |
|---|---|---|
| Peppol | 1 | 10 seconds |
| CEF | 1 | 10 seconds |
| BDEW | 1 | 10 seconds |
| ENTSOG | 1 | 10 seconds |
| DBNAlliance | 5 | ~72 minutes (6h / 5) |
HTTP transport retries
For connection-level retries (e.g. when the remote server is temporarily unavailable), phase4 providesHttpRetrySettings.
HttpRetrySettings
- Retry 1: 5 seconds
- Retry 2: 10 seconds
- Retry 3: 20 seconds
1.0 (the default) means no increase – fixed-interval retries.
Applying HTTP retry settings to a message builder
Default values
| Property | Default |
|---|---|
maxRetries | 0 (disabled) |
durationBeforeRetry | 10 seconds |
retryIncreaseFactor | 1.0 (no increase) |
HTTP transport retries are disabled by default (
maxRetries = 0). You must explicitly configure them if you want connection-level retry behaviour.Retry try index in outgoing dumper
When message dumping is enabled, theIAS4OutgoingDumper.onBeginRequest(...) method receives a nTry parameter:
0= initial attempt1= first retryn= nth retry
Reception awareness and duplicate detection
WhenduplicateDetection is enabled in the PMode, phase4 automatically records incoming message IDs and rejects duplicates. This interacts with retries: if a message is successfully delivered but the receipt was lost, the sender may retry – and the duplicate detection on the receiver side will correctly identify and suppress the duplicate.
Checking retry feasibility
When sending messages, phase4 evaluates whether a retry is feasible based on the exception type. Transport errors (e.g. connection refused, timeout) are retryable. AS4 application-level errors (e.g. a received error signal message) are not.PModeReceptionAwareness fields reference
PModeReceptionAwareness fields reference
| Field | Type | Description |
|---|---|---|
receptionAwareness | ETriState | Whether reception awareness is active |
retry | ETriState | Whether retries are enabled |
maxRetries | int | Maximum number of retries (>= 0) |
retryIntervalMS | long | Milliseconds between retry attempts |
duplicateDetection | ETriState | Whether duplicate message IDs are rejected |