Skip to main content

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.

The CEF eDelivery AS4 profile is defined by the European Commission for interoperability between public administrations across Europe. It supports both one-way/push and two-way/push-push messaging patterns.

Maven Artifact

phase4-profile-cef

Profile ID

cef / cef-four-corner

​
Maven dependency

<dependency>
  <groupId>com.helger.phase4</groupId>
  <artifactId>phase4-profile-cef</artifactId>
  <version>4.4.1-SNAPSHOT</version>
</dependency>

​
Overview

The CEF eDelivery profile is used across a range of EU infrastructure programmes. The profile supports two MEP combinations:
  • One-way / Push – a single message is pushed from initiator to responder
  • Two-way / Push-Push – both parties can push messages on each leg
Both MEP modes share the same security requirements.

​
PMode structure

Two factory methods are provided in CEFPMode: 
import com.helger.phase4.profile.cef.CEFPMode;
import com.helger.phase4.model.pmode.IPModeIDProvider;

PMode pMode = CEFPMode.createCEFPMode(
    "initiator-id",
    "responder-id",
    "https://responder.example.com/as4",
    IPModeIDProvider.DEFAULT_DYNAMIC,
    true  // persist
);
ParameterValue
Agreement IDurn:as4:agreement
SOAP versionSOAP 1.2 (AS4 default)
WSS versionWS-Security 1.1.1
One-way MEPOne-Way / Push
Two-way MEPTwo-Way / Push-Push

​
Security requirements

The CEFCompatibilityValidator enforces the following constraints on every PMode leg:
Deviating from these values will cause the compatibility validator to report an error.
SettingRequired value
Signature algorithmRSA_SHA_256 (http://www.w3.org/2001/04/xmldsig-more#rsa-sha256)
Signature hash functionSHA-256 (http://www.w3.org/2001/04/xmlenc#sha256)
Encryption algorithmAES-128-GCM (http://www.w3.org/2009/xmlenc11#aes128-gcm)
Minimum encryption strength128-bit
WSS version1.1.1
PModeAuthorizefalse
Receipt reply patternResponse (synchronous)
Non-repudiationtrue
Error handling – ReportAsResponsetrue

​
Four-corner model flag

The CEFCompatibilityValidator has an optional flag that controls whether the four-corner model (requiring originalSender and finalRecipient message properties) is enforced: 
import com.helger.phase4.profile.cef.CEFCompatibilityValidator;

// Default: four-corner model IS enforced
CEFCompatibilityValidator validator = new CEFCompatibilityValidator();

// Disable four-corner model requirement (for two-corner scenarios)
validator.setExpectFourCornerModel(false);

​
Message properties

When the four-corner model is enabled (default), each user message must include:
  • originalSender – C1 party identifier
  • finalRecipient – C4 party identifier

​
PartyInfo constraints

  • PartyInfo/From must contain at most one PartyID
  • PartyInfo/To must contain at most one PartyID
Unlike Peppol, CEF does not mandate a specific party type ID format.

​
Compression

If payload compression is configured, only GZIP compression is accepted: 
// PMode.PayloadService.CompressionMode must be GZIP if set
new PModePayloadService(EAS4CompressionMode.GZIP)

​
Reception awareness

// From CEFPMode.generatePModeReceptionAwareness():
// receptionAwareness = true
// retry = true
// maxRetries = 1
// retryIntervalMS = 10_000 (10 seconds)
// duplicateDetection = true

​
EUDAMED usage

The EUDAMED profile (EU Medical Devices Database) is built on top of the CEF profile. The phase4-eudamed-client module uses AS4CEFProfileRegistarSPI.AS4_PROFILE_ID_FOUR_CORNER internally and adds EUDAMED-specific HTTP client settings.

Build docs developers (and LLMs) love

Get started for freeTalk to us