Area for missing Pictures
The domibusConnector Suite
The domibusConnector Suite
The domibusConnector suite consists of the following products:

+ domibusConnector web-application
+ domibusConnectorClient
+ domibus-connector-plugin
domibusConnector web-application

To support message workflows between e-CODEX participants, the domibusConnector provides the following features:

 

  • ETSI-REM evidences: Those are evidences generated by the domibusConnector in a signed XML format. The purpose of those evidences is to inform the sender of a message on the successful or non-successful processing of the message. Evidences are generated and submitted by the domibusConnector at different stages of message processing:
    • SUBMISSION_ACCEPTANCE/SUBMISSION_REJECTION: This evidence is generated by the sending connector and informs the original sender of the message (via national backend application) if the message was processed successfully by the sending connector and submitted to the sending gateway. This evidence is also attached to the message as business attachment.
    • RELAY_REMMD_FAILURE: If the message was submitted to the gateway, but the gateway cannot submit it to the recipients’ gateway, this evidence is generated and sent to the original sender by the sending connector. To be able to do so, the domibusConnector relies on the information from the gateway that the submission has failed.
    • RELAY_REMMD_ACCEPTANCE/REJECTION: Once the message arrives at the recipients’ domibusConnector, this connector generates the evidences, adds it to the message, but also sends it back to the original sender. Once received, an original sender can conclude, that the message was received by the recipients’ gateway and connector, but not, if the processing of the message on the recipients’ side was successful.
    • DELIVERY / NON_DELIVERY: In case the processing of the message on the receiver side fails, a NON_DELIVERY is generated by the connector and sent back to the original sender. Once the message could be processed successfully and is delivered to the national backend application, the domibusConnector depends on the trigger of the national backend application if the delivery to the final recipient was successful or not. If triggered, the domibusConnector generates the DELIVERY (if successful) or NON_DELIVERY (if not successful) and send it back to the original sender.
    • RETRIEVAL / NON_RETRIEVAL: This evidence type is optional and hardly used by participants. This is due to the fact that it is not easy for national backend systems to acknowledge the retrieval of a message. But, if triggered by the backend application, the domibusConnector generates such an evidence and sends it back to the original sender.

 

The first evidence generated, the SUBMISSION_ACCEPTANCE, is signed by the sending connector. Every following evidence is built in a chained way based on the one before.

 

Also, the domibusConnector, offers timer-triggered jobs (depending on the configuration of the domibusConnector) that are started once a message is processed on the senders’ side. Those jobs wait for a configurable period of time, if evidences from the receiving connector arrive. If this is not the case, the message gets rejected on the senders’ side, a negative evidence is generated by the sending connector and is sent back to the original sender of the message.

 

  • TrustOK Token: The sending domibusConnector validates the signature of the business document of a message. The outcome of this validation is written in a so called TrustOK Token. This token is generated by a sub-module of the domibusConnector: the security library. It is generated in two ways:
    • An XML file: This XML file contains the outcome of the validation in a computable way.
    • A PDF file: A human readable output of the validation outcome.

 

Both files are attached to the message.

 

This ensures that the business document of the message has not been manipulated on its way from the original sender to the sending connector.

 

  • ASIC-S container: Once the validation of the business document and the generation of the TrustOK Token is done successfully, the domibusConnector builds a container that holds the documents that are included in a message. Those documents are:
    • The business document itself
    • Every business attachment
    • The TrustOK Token PDF file

 

The container then is signed by the domibusConnector. Within the message, the documents that are included in the ASIC-S container are replaced by the container.

 

On the receiving side, the domibusConnector validates the signature of the ASIC-S container, unpacks it (if signature validation is successful) and replaces it within the message with the contents of the container.

 

This way it is ensured that business documents cannot be manipulated on their way from the sending connector to the receiving connector.

 

  • WS-Security[1]: To higher the transmission security of messages, the domibusConnector uses the ws-security on both ends (gateway side as well as national backend side) for transmission. This means that every message the domibusConnector submits or receives is encrypted and signed.

     

    By request of participants, this feature can be switched off as the implementation of ws-security requires a relatively high amount on configuration. The reason for that is that in most e-CODEX environments the domibusConnector is placed within a secure infrastructure.

 

  • Common API: The domibusConnector offers a stable API which defines the web services that are used to connect to the gateway and the national backend application(s). Also, the structure of messages exchanged with the domibusConnector is described in the domibusConnectorAPI.

 

Technical prerequisites:

The domibusConnector is a web-based application. It runs on any Java Servlet container recent enough to support Java 8 and later.

 

From the version 4.2.0-RELEASE onwards additionally a package that starts without servlet container set up beforehand. This distribution is experimental and should not be used in a production environment.

 

Also, the support for building docker container is introduced with version 4.2.0-RELEASE.

 

For production environments the usage of a web server within a secure infrastructure is recommended. Also to use a central serviced database. The domibusConnector distribution packages come with database setup and migration scripts for MySQL and Oracle. Though the domibusConnector is designed to support any SQL compliant database.

 

Availability:

The domibusConnector is hosted on the e-Codex Nexus repository server. Access will be granted after contacting the e-CODEX technical team.

domibusConnectorClient

The domibusConnectorClient is an optional software component that is designed to support developers that implement use-case specific applications at the participants site. It comes in 3 distribution packages:

  • domibusConnectorClient-Libraries
  • domibusConnectorClient-Application
  • domibusConnectorClient-UI

 

domibusConnectorClient-Libraries

 

This package contains different Java libraries to support implementers in communicate with the domibusConnector web application. A detailed description of the different libraries, their API documentation and their purpose is also part of the package.

 

The libraries are meant to support functionalities from the sole connection to the domibusConnector to the management of timer-triggered jobs to connect the application’s backend with the domibusConnector.

 

domibusConnectorClient-Application

 

The domibusConnectorClient application is a first step to connect to e-CODEX if no use-case support is given by a custom backend application (yet).

 

Therefore, it runs out of the box once configured and is able to exchange messages with other e-Codex participants.

 

It is also convenient for usage when testing connectivity with the CTP.

 

To run on a server without graphical interaction, the domibusConnectorClient application runs as a command line tool.

 

As the application also offers a REST service interface, it also can be used to set up use-case specifics (as a user-interface, for example) and leave the message communication part to the client application.

 

A detailed documentation of the application is delivered within the package.

 

domibusConnectorClient-UI

 

This is a common user interface that interacts with the domibusConnectorClient-Application over REST service. It is a generic user interface without any use-case specific behaviour.

Domibus-connector-plugin

This plugin is developed to support the connection between the domibusConnector web application and a DOMIBUS gateway. It implements API functionality of the DOMIBUS gateway and is ready to use to establish a push/push connection between the gateway and the domibusConnector.

 

For further details on how to install a plugin at a DOMIBUS gateway, please refer to the DOMIBUS website or contact the CEF e-Delivery support.

Subscribe to our newsletter

 
 Click here to see the terms.