Profile HR eDelivery - phax/phase4 GitHub Wiki
Underlying specifications: https://porezna.gov.hr/fiskalizacija/bezgotovinski-racuni/eracun for the full specifications
See also https://github.com/phax/phase4-hredelivery-standalone for an example of a standalone application
This submodule comes with one profile only:
- ID
hredelivery
To perform testing with HR eDelivery you MUST have a valid HR eDelivery certificate. Testing with a self-signed certificate does not work.
OASIS AS4 is a profile of OASIS EBMS v3. CEF AS4 is a profile of OASIS AS4. HR eDelivery AS4 is a profile of CEF AS4.
HR eDelivery has a very limited use of AS4. Some highlights are:
- It uses only one-way push
- TLS certificates can be anything - basically no server trust can be created
- Signing and encryption rules follow the CEF AS4 profile requirements (AES 128 CGM, SHA-256)
- It allows only for one AS4 payload
- You have to use MIME encoding for the payload (as defined by the underlying SOAP with Attachments specification) - and are not allowed to add it into the SOAP body
- The payload is always an SBD envelope (Standard Business Document; mostly wrongly addressed as SBDH - Standard Business Document Header) - same as it was for Peppol AS2
- Compression must be supported but can be chosen on the senders choice
<dependency>
<groupId>com.helger.phase4</groupId>
<artifactId>phase4-profile-hredelivery</artifactId>
<version>x.y.z</version>
</dependency>This subproject is your entry point for sending messages into the HR eDelivery network.
The contained project contains a class called Phase4HREDeliverySender.HREDeliveryUserMessageBuilder
(accessible via factory method Phase4HREDeliverySender.builder()) - it contains
all the parameters with some example values so that you can start easily.
Alternatively the class Phase4HREDeliverySender.HREDeliveryUserMessageSBDHBuilder
(accessible via factory method Phase4HREDeliverySender.sbdhBuilder())
offers a builder class where you can add your pre-build StandardBusinessDocument, which implies that no implicit validation
of the business document takes place. This class contains utility methods to explicitly validate the payload.
As a prerequisite, the file application.properties must be filled out correctly and your HR eDelivery AP certificate must be provided.
See the folder https://github.com/phax/phase4/tree/master/phase4-hredelivery-client/src/test/java/com/helger/phase4/hredelivery for different examples on how to send messages via the HR eDelivery AS4 client. Some of them use the SMP client to find the connection parameters, in some cases the X.509 certificates and endpoint URLs are provided explicitly (for testing purposes only of course).
The client side validation of outgoing business documents is implemented using phive (Philip Helger Integrative Validation Engine, OSS, Apache 2.0 Licence). When available, the HR eDelivery CIUS rules are available. Additional rules for other formats are available via phive-rules (OSS, Apache 2.0 License) and can be added to the configuration.
This subproject is your entry point for receiving messages from the HR eDelivery network using the well known Servlet technology.
It assumes you are running an Application server like Apache Tomcat or Eclipse Jetty to handle incoming connections. Integrations into other application servers like vertx or even the deployment as an AWS Lambda is possible but needs a bit more hand-crafting.
Register the Servlet com.helger.phase4.servlet.AS4Servlet in your application.
Then implement the SPI interface com.helger.phase4.peppol.servlet.IPhase4PeppolIncomingSBDHandlerSPI to handle incoming Peppol messages. See Introduction to the Service Providers Interface if you are not familiar with the Java concept of SPI.
Sample setup for WEB-INF/web.xml:
<servlet>
<servlet-name>AS4Servlet</servlet-name>
<servlet-class>com.helger.phase4.servlet.AS4Servlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>AS4Servlet</servlet-name>
<url-pattern>/as4</url-pattern>
</servlet-mapping>By default the "receiver checks" are enabled. They are checking if an incoming message is targeted for the correct
Access Point and if not will reject the message. That is done by performing an SMP lookup on the
receiver/document type/process ID and check if the resulting values match the preconfigured values.
That of course requires that the preconfigured values need to be set, before a message can be received.
That needs to be done via the static methods in class Phase4PeppolServletConfiguration.
Alternatively you can disable the receiver checks using the setReceiverCheckEnabled method in said class.
Additionally before you can start, an IAS4CryptoFactory MUST be set.
An implementation of this interface provides the keystore as well as the private key for doing signing and/or
encryption services in phase4.
By default the crypto factory is taken from the configuration file.