Documentation

This page tries to explain the communication to and from the edi4steel infrastructure that the participants will have to implement in order to send data to and receive data from the network.

The scope of this document is limited to implementing edi4steel communication, the following resources may be useful for information on the underlaying technology:
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/What+is+eDelivery
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+does+eDelivery+work

Defenitions

Defenition Description
Payload The accespoints are data agnostic. Because of this the contents to be transmitted between parties is described as a payload.

The payloads EDI4Steel accepts:
The XML specification: https://smartconnected.semantic-treehouse.nl/#/Standards. Overview of communication and examples: https://smart-connected-supplier-network.gitbook.io/processmanual/

1. Sending data

There are multiple ways to send data through the EDI4Steel network. Click on one of the below methods to view its documentation.

Edi4steel has reduced the complexity of using an accespoint by providing an API the participants may use. The API will:

  • Handle the accesspoint communication
  • Generate the corresponding DeliveryMessage content
  • Handle the hashing of the payload
  • Handle encrypting of the hash with the domains private key
  • Provide payload storeage and generate URL’s for those payload that are required by the accesspoint

The advantages of using this service: no need to understand eDelivery/AS4 messages nor infrastructure and thereby lower implementation costs and provide tools for message security like hashing and encrypting.

The communication flow between the sender and receiver is shown in the following flowchart.

To use the API you will have to contact edi4steel and provide the following information:

  • Your GLN provided by https://www.gs1.nl/
  • The company name
  • Tell us if you want to use encryption or not.

Our contact information is on the main page of https://edi4steel.eu

After that you can start implementing the API. More documentation on the calls can be found here

Edi4steel maintains an accesspoint that is used by the previous discussed API. This accesspoint will also allow direct communication/implementation.

The advantage of using the accesspoint directly is that it will increase the speed of messages and give you full control of message handling.

The disadvantage of using the accesspoint directly is that you will need some basic knowledge of eDelivery/AS4, handle encryption/hashing yourself, have to handle future changes made to the accesspoint and need to have an online storage location for the payloads.

The communication flow between the sender and receiver is shown in the following flowchart.

Howto talk to SAAS accesspoint directly:

  1. Upload per communication the XML payload to a publicly accessible location. The receiving accepoint will download the XML payload like a user would download a file with an internet browser (https method GET on a url). An example of the payload can bee found here
  2. Optional: Create an SHA256 hash of the complete XML payload. Currently edi4steel only uses SHA265.
  3. Optional: If you want to make the receiver able to determine if you actually send the payload and not a third (malicious) party you can encrypt the generated hash with a private key that belongs to a publicly accessible domain that is generated with a RSA algorithm. Set this encrypted hash in “Hash” value of the delivermessage.
    Because you are the sender this will have to be the certificate of your publicly accessable domain that you have the private key of.
    More on this topic in "Encryption / Decryption" below.
  4. Generate per communication a SubmitMessage, an example can bee found here: https://edi4steel.eu/Content/Examples/SubmitMessage.xml
  5. Create a HTTPS POST call to https://ap-saas.edi4steel.eu/msh/submit with content type application/octet-stream that has the SubmitMessage as body. Code would look something like:

To use the API you will have to contact edi4steel and provide the following information:

  • Your GLN provided by https://www.gs1.nl/
  • The company name
  • Tell us what messages you will be sending
  • Tell us if you want to use encryption or not.

Our contact information is on the main page of https://edi4steel.eu

EDI4Steel runs an SFTP server which will accept XML payloads. These payloads are automatically translated into AccessPoint communication based on metadata stored for the SFTP user. More information in this can be requested trough the contact details on page https://edi4steel.eu.

You can create your own accespoint and add it to the edi4steel network. We do not provide any code as a starting point, visit https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery for more information.

Once you have the AS4 eDelivery accesspoint up and running you can contact us with the details and we will communicate the PMode details and register the ASP in the SMP/SML.

2. Receiving data

Receiving data for the API accesspoint. You will have to create two publicly accessible endpoints, these two endpoints are described in “Receiver” on https://edi4steel.eu/swagger/ui/index

Receiving data for the SaaS accesspoint. You will have to create two publicly accessible endpoints, these two endpoints are described in “Receiver” on https://edi4steel.eu/swagger/ui/index

Receiving data for the SFTP solution will require polling for data on the SFTP server in dedicated folders per sender/receiver.

The self-created accesspoint may be configured in a different way so that will be up to you if you chose to create your own accesspoint, see configure details of receiving PMode’s.

3. Encryption / Decryption

The sender and receiver send data exclusively over the HTTPS protocol. So a man in the middle cannot see what has been send as data.

We’ve added some hashing and hash encryption (RSA) guidelines to ensure the sender is actually the person that created the message. In order for that to work sender and receiver do the following.

Sender creates (once until invalid) a certificate that belongs to a public domain and uses an RSA algorithm to do so. The private key is stored inside a pem file only accessable to him. He tells (one) the receiver what url uses that certificate so the receiver can load the public key from that public domain certificate.

If the sender uses the API from edi4steel this whole setup is automatic and the public certificate that will be used is https://edi4steel.eu

So:

If supplier Y uses the API to send messages to customer X only customer X has to enter https://edi4steel.eu, the API will take care of hashing and encryption, decryption and hash checking still has to be done on customer X side, see example code in: https://edi4steel.eu/Content/Examples/EncryptionAndDecryptionExample.cs.txt

If customer X send back an messages trough the API to supplier then supplier Y can use the key from https://edi4steel.eu, the API will take care of hashing and encryption, decryption and hash checking still has to be done on supplier Y side, see example code in: https://edi4steel.eu/Content/Examples/EncryptionAndDecryptionExample.cs.txt

If supplier Z does not use the API to send messages to customer X, he or she has to implement the setup process themselves.

4. Example: API send/receive flow

Below is an example commmunication flow between the different systems. In reality the complexcity is higher between the accesspoint, SML and SMP end but for clarity sake some details have been omitted end simplified.

If you decide to use the EDI4Steel API only the orange/brown fragments have to be implemented.

If you are the initiator (example assumes external is initiator) the same calls will be used but your startpoint will be "Call URLS (Send data)".