• PKI service

• This service is provided to the European Union (EU) and European Economic Area (EEA) public administrations which are using eDelivery.

• You can find more information on eDelivery PKI service.

• SML service

• This service is provided to the European Union (EU) and European Economic Area (EEA) public administrations and private organisations which are using eDelivery.

• You can find more information on eDelivery SML service.

• Service Desk:

• This service is provided to the European Union (EU) and European Economic Area (EEA) public administrations and private organisations which are using eDelivery. The service may also be provided for non-EU/EEA users in the context of their meaningful participation in a EU/EEA eDelivery project.

• You can find more information on eDelivery Service Desk.

• Conformance Testing service:

• This service is provided to software or service providers to confirm that their software or service is conformant to the eDelivery specifications.

• You can find more information on eDelivery Conformance Testing service.

• Connectivity Testing service:

• This service is provided to the European Union (EU) and European Economic Area (EEA) public administrations and private organisations which are using eDelivery. The service may also be provided for non-EU/EEA users in the context of their meaningful participation in a EU/EEA eDelivery project.

• You can find more information on eDelivery Connectivity Testing service.

You can find more information about the eDelivery service offering at eDelivery services.

Domibus (Domain Interoperability Bus) is an e-Delivery AS4 profile conformant Access Point Sample Implementation maintained by the European Commission. This sample implementation may be used to test other implementations of the technical specifications or as a working solution. The users of the sample implementation remain fully responsible for the integration with backend systems, its deployment and operation. The support and maintenance of the sample implementation, as well as any other auxiliary services, are provided according to the terms and conditions defined in the Master Service Arrangement of eDelivery.

The latest version of Domibus is available here.

You can submit change requests to add features in Domibus on the eGovernance space page. Please note that you need to be a member of the eDelivery community to be able to submit a change request (to become a member, introduce an access request via the eGovernance page).

Depending on the Domibus version, different application server versions are supported. Details for the different supported applications servers versions are available on the corresponding Domibus release pages.

Additional application servers may benefit from the "Support for additional Application Servers" space driven by the users of eDelivery. Specific patches for supporting additional application servers can be developed and published.

Domibus Log Level configuration is well explained in the Domibus Administration Guide which can be downloaded from the "Digital portal".

Domibus being fully developed in Java is therefore portable to any platform supporting Oracle Java JRE/JDK 8. 

Domibus has been deployed and tested successfully on Windows and Linux platforms.

For more details on supported platforms for Domibus specific versions, please check the corresponding Domibus release pages.

No, you must choose one auto-discovery parameter in the domibus.properties. It is not possible to have both PEPPOL and OASIS supported simultaneously.

Domibus supports the "self-sending" feature (when two backend applications connected to the same Domibus Access point exchange messages between them) starting from Domibus 5.0 versions.

Note that we discourage users from enabling it in production environments in versions previous to Domibus 5.1.

Some configuration steps are required to use it:
- the party ID of the AP must be mentioned in both the "From" and "To" properties of the message
- in the Pmode, the AP party must be mentioned in both the "InitiatorParties" and "ResponderParties" sections

Internally, since Domibus requires messageIDs on an AP domain to be unique, the message ID used for the received message must be derived from the message ID used for the sent message with the following rule: the suffix "_1" is added to the sent message id.

For more details please refer to the "Domibus Administration Guide".

Yes, it is possible to configure Domibus to save the message payloads on the file system instead of the database. This setting is recommended when exchanging payloads bigger than 30MB.

For more details please refer to the "Domibus Administration Guide"

In order to attach a file to a message, use the following steps:

Import into Soap UI the following downloaded project file:

<CEF_eDelivery_path>/domibus-MSH-X.Y.Z-sample-configuration-and-testing.zip\test\soapui\AS4-test-guide-soapui-project.xml.

Open Web Service Submission,  Business Scenario, Test Steps, sendMessage

Add "<payload payloadId="cid:attachment">cid:12345</payload>" in the sendRequest body like below:

Remark:

The cid defined above is just an example and any other cid can be defined based on your requirements

<_1:sendRequest>

  <payload payloadId="cid:message">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGhlbGxvPndvcmxkPC9oZWxsbz4=</payload>

  <payload payloadId="cid:attachment">cid:12345</payload>

</_1:sendRequest>

Click on Attachments

Click on the Adds an attachment icon

Select the file you desire to attach in the request then click on Open

Click on Yes

Select the Part corresponding to the cid of the payload used to attach the file

Click on the Submit request icon

Domibus is freely downloadable from the "Digital portal".

Yes, Domibus is released under the "European Union Public Licence".

Currently there are two licences that you can use: the EUPL 1.1 and the EUPL 1.2. If you are using Domibus version 3.3 or above, you must use the EUPL 1.2 and if you are using a version of Domibus before Domibus 3.3 you must use the EUPL 1.1.

The upgrade to the latest available Domibus version is not mandatory but recommended. Note that the custom plugins need to be updated in order to be compatible with a new Domibus version. 

Domibus releases are supported by default for a period of at least one year starting from the release date of their minor version (for more information, see Domibus releases and Support arrangement). Domibus releases labelled as Long-Term Support Arrangement (LTS) are supported for a period of at least two years from the release date of their minor version. The exact expiration dates of the support period are presented in the release notes and in the Domibus roadmap. Releases under LTS will be clearly identified.

eDelivery Support offers the following services:

• Service Desk

• Training and Deployment

• AS4 Connectivity Test

• AS4 Conformance Testing

• eDelivery PKI service

All the eDelivery services are listed here.

The training and deployment services on site are only available for public administrations. eDelivery Support can however provide training and guidance on eDelivery and AS4 remotely for private companies.

The Domibus source code is available on the "eDelivery git repository".

Domibus eDelivery Messaging is based on a simple messaging topology known as the four-corner model, This means that the information exchanged between the original sender in corner one (C1) and the final recipient in corner four (C4) goes via Access Points, corners two and three (C2 and C3) respectively. These Access Points are interoperable with each other because they implement the same message exchange protocol and implementation guidelines, i.e. the AS4 message protocol as defined in the eDelivery profile .

The performance of Domibus depends on a combination of factors: the underlying hardware (CPU, RAM, disk type), network performance, configuration settings and installation type (single node versus clustered setup).

As an example, during several test campaigns with their own specificities, it has been verified that Domibus 4.2.x can send +/- 50 messages per second in a single node setup and send/receive +/- 270 messages per second in a clustered setup.

This means that Domibus needs to be scaled and tested according to your specific environment, configuration setup and business needs.

Starting with 5.0, Domibus can reliably handle a throughput of more than 1,000 messages/s* and, with added support for table partitioning, ensures this high level of performance even as the size of the database increases. These results were measured during a 2-hour period with Domibus working in single-tenancy mode, deployed in a 4-node cluster, using Oracle WebLogic Server and Oracle Database, with a message size of 5 kB, configured to receive 500 messages/s and send 1,000 messages/s. The performance results are dependent on several variables, such as message size, data base disk speed, RAM, etc

Domibus 5.1 version supports the following database backends:

• MYSQL 8 (future versions might work)

• Oracle 12c R2 and Oracle 19c

Depending on the Domibus version, different database versions are supported. Details for the different supported database versions are available on the corresponding Domibus release pages.

Additional backend databases may benefit from the "Support for additional Databases" space driven by the users of eDelivery. Specific patches for supporting additional backend databases can be developed and published.

The JDBC drivers can be downloaded from the official websites of the manufacturers:

• MYSQL JDBC Driver

• Oracle JDBC Driver

Restarting the server is not required after uploading the Pmode.

Domibus uses a Plugin architecture to communicate with the Backend. It is provided by default with three plugins: a WebService Plugin (WS), a Java Messaging Service plugin (JMS) and a File System plugin, which can be installed together or separately. Users can also develop their own Custom Plugin using the Cookbook and the Software Architecture Domain (SAD).

We currently don’t have publicly available performance reports for Domibus.

Note that the performance of Domibus depends on a combination of factors: the underlying hardware (CPU, RAM, disk type), network performance, configuration settings and installation type (single node versus clustered setup).

Example with Domibus 4.2.x: during several test campaigns with their own specificities, it has been verified that Domibus can send +/- 50 messages per second in a single node setup and send/receive +/ 270 messages per second in a clustered setup. As a conclusion, Domibus needs to be scaled and tested according to your specific environment, configuration setup and business needs.

Here are the details of 2 typical environments:

 Single Node specs:

 4 CPU, 16GB memory, 30 GB SSD disk

10KB messages were sent at 55 messages per second

Clustered setup specs:

F5 Loadbalancer, 4 nodes (each with 8 CPUs, 32GB RAM , SSD disk) in a cluster that run Domibus  (Weblogic), connected to an Oracle DB and a Blue Coat forward proxy.

30KB messages were simultaneously sent at 135 messages per second and received at 135 messages per second, totalling 270 messages handled per second.

NOTE: It is possible that these performance test results could not be perfectly matched as there are other hardware configurations which may affect the performance.

Starting with 5.0, Domibus can reliably handle a throughput of more than 1,000 messages/s* and, with added support for table partitioning, ensures this high level of performance even as the size of the database increases. These results were measured during a 2-hour period with Domibus working in single-tenancy mode, deployed in a 4-node cluster, using Oracle WebLogic Server and Oracle Database, with a message size of 5 kB, configured to receive 500 messages/s and send 1,000 messages/s. The performance results are dependent on several variables, such as message size, data base disk speed, RAM, etc.

Yes

• The Sender (in the diagram), configured with Client authentication, is able to send a message via 1-way SSL to Receiver 1, setup with 1-way SSL configuration.

• The Sender is also able to send a message via 2-way SSL to  Receiver 2, setup with 2-way SSL configuration.

• The complete setup procedure is described in the Admin Guide

The goal of the Connectivity Test is to test if a newly installed AS4 Access Point, conformant with the eDelivery specifications, can successfully communicate with the sample AS4 Access Point hosted by the European Commission.

If successful, these tests confirm that the new Access Point is in all likelihood correctly deployed and configured.

The eDelivery Support Team is responsible for the AS4 Connectivity test. The team facilitates the connectivity testing by making available a sample AS4 Access Point in a cloud environment as well as providing guidelines and support during the testing process.

The benefits of the AS4 Connectivity tests include the following:

• Users of the service get the confirmation that the newly deployed AS4 Access Points can successfully communicate with a neutral organization i.e. the sample Access Point of the European Commission,

• Supported by professional staff of the European Commission,

• Quick testing cycle with reduced cost and time,

• Testing anywhere at any time,

• Tests are fully domain-neutral.

From version 4.0 onwards, Domibus stores the attachment in the Database, table tb_part_info, column binary_data by default.To store the attachments on the File system instead of the Database, the domibus.attachment.storage.location parameter has to be added and configured. For more information on such configurations, please consult the Administrator Guide for Domibus.

The eDelivery Dynamic Discovery process enables the Sending Access Point to dynamically discover  the  address of the Receiving Access Point. 

Instead of looking at a static list of addresses, the Sending Access Point finds out, in the DNS, the Service Metadata Publisher (SMP) where information about every participant and data exchange network is kept up to date, including addresses of their Access Point.

Check here for more detailed information.