Annexes
Emplacement : Documentation ICS2 > Interface Control Document
Annex 1. SERVICE OPERATIONS
In the following table, the reader can find the description of ICS2 TI services, the operations (or actions) of those services and the user messages payload of those operations. The payload is the part of transmitted data that is the actual intended message. The actions of the services map to the message ID as given in ICS2 Information Exchange Specifications document [R04]. Each action has a corresponding message payload which corresponds to the relevant information exchange message name in that same document.
Table 12: Description of ICS2 TI User Messages payload
- Mode of transport: Sea and inland waterways — Message Id : An ENS Filing Message is submitted by the EO system and is received by the ICS2 TI Application. An ENS Filing means either partial or full ENS data set required by the legislation per specific mode of transport or business model. In case the reader wishes to find detailed information regarding the content (payload) of each message, they can refer to the ICS2 Information Exchange Specifications document [R04] and look- up the relevant message ID.
- IE3F10 — Message Id : IE3F10 ; Short Description : Complete dataset – Straight bill of lading containing the necessary information from consignee
- IE3F11 — Message Id : IE3F11 ; Short Description : Complete dataset – Master bill of lading with underlying house bill(s) of lading containing the necessary information from consignee at the level of the lowest house bill of lading
- IE3F12 — Message Id : IE3F12 ; Short Description : Partial dataset – Master bill of lading only
- IE3F13 — Message Id : IE3F13 ; Short Description : Partial dataset – Straight bill of lading only
- IE3F14 — Message Id : IE3F14 ; Short Description : Partial dataset – House bill of lading only
- IE3F15 — Message Id : IE3F15 ; Short Description : Partial dataset – House bill of lading with the necessary information from consignee
- IE3F16 — Message Id : IE3F16 ; Short Description : Partial dataset – Necessary information required to be provided by consignee at the lowest level of transport contract (the lowest house bill of lading)
- IE3F17 — Message Id : IE3F17 ; Short Description : Partial dataset – Necessary information required to be provided by consignee at the lowest level of transport contract (straightbill)
- Mode of transport: Air cargo (general)
- IE3F20 — Message Id : IE3F20 ; Short Description : Complete dataset lodged pre-loading
- IE3F21 — Message Id : IE3F21 ; Short Description : Partial dataset – Master air waybill lodged pre-arrival
- IE3F22 — Message Id : IE3F22 ; Short Description : Partial dataset – House air waybill lodged pre-arrival
- IE3F23 — Message Id : IE3F23 ; Short Description : Partial dataset — Minimum dataset lodged pre-loading in accordance with Article 106(1) second subparagraph of Delegated Regulation (EU) 2015/2446 without master air waybill reference number
- IE3F24 — Message Id : IE3F24 ; Short Description : Partial dataset — Minimum dataset lodged pre- loading in accordance with Article 106(1) second subparagraph of Delegated Regulation (EU) 2015/2446 with master air waybill reference number
- IE3F25 — Message Id : IE3F25 ; Short Description : Partial dataset — Master air waybill reference number lodged pre-loading in accordance with Article 106(1) second subparagraph of Delegated Regulation (EU) 2015/2446
- IE3F26 — Message Id : IE3F26 ; Short Description : Partial dataset — Minimum dataset lodged pre- loading in accordance with Article 106(1) second subparagraph of Delegated Regulation (EU) 2015/2446 and containing additional house air waybill information
- IE3F27 — Message Id : IE3F27 ; Short Description : Complete dataset lodged pre-arrival
- IE3F28 — Message Id : IE3F28 ; Short Description : Complete dataset lodged pre-loading – Direct air waybill
- IE3F29 — Message Id : IE3F29 ; Short Description : Complete dataset lodged pre-arrival – Direct air waybill
- Mode of transport: Express consignments
- IE3F30 — Message Id : IE3F30 ; Short Description : Complete dataset lodged pre-arrival
- IE3F31 — Message Id : IE3F31 ; Short Description : Express consignments on air cargo general – Complete dataset lodged pre-arrival by the express operator
- IE3F32 — Message Id : IE3F32 ; Short Description : Partial dataset — Minimum dataset lodged pre-loading in accordance with Article 106(1) second subparagraph of Delegated Regulation (EU) 2015/2446
- IE3F33 — Message Id : IE3F33 ; Short Description : Express consignments on air cargo general – Partial dataset – House air waybill lodged pre-arrival by a person pursuant to Article 127(6) of the Code and in accordance with Article 113(1)
- IE3F34 — Message Id : IE3F34 ; Short Description : Express consignments on road – Complete dataset lodged pre-arrival
- Mode of transport: Postal consignments
- IE3F40 — Message Id : IE3F40 ; Short Description : Postal consignments – Partial dataset – Road Master bill of lading
- IE3F41 — Message Id : IE3F41 ; Short Description : Postal consignments – Partial dataset – Rail master transport document information
- IE3F42 — Message Id : IE3F42 ; Short Description : Partial dataset - Master air waybill containing necessary postal air waybill information lodged in accordance with the time-limits applicable for the mode of transport concerned
- IE3F43 — Message Id : IE3F43 ; Short Description : Partial dataset — Minimum dataset lodged pre- loading in accordance with Article 106(1) second subparagraph of Delegated Regulation (EU) 2015/2446
- IE3F44 — Message Id : IE3F44 ; Short Description : Partial dataset — Receptacle identification number lodged pre-loading in accordance with Article 106(1) second subparagraph of Delegated Regulation (EU) 2015/2446
- IE3F45 — Message Id : IE3F45 ; Short Description : Postal consignments – Partial dataset – Sea and inland waterways
- Mode of transport: Road
- IE3F50 — Message Id : IE3F50 ; Short Description : Road mode of transport
- Mode of transport: Rail
- IE3F51 — Message Id : IE3F51 ; Short Description : Rail mode of transport
- IE3A10 — Message Id : IE3A10 ; Short Description : Amend ENS ; Payload Description : An ENS Amendment Message is submitted by the Sender access point and is received by the ICS2 TI Application. An ENS Amendment Message with name E_ENS_xxx_AMD amends the movement declaration filed through the corresponding message with name E_ENS_xxx_DEC. In case the reader wishes to find detailed information regarding the content (payload) of each message, they can refer to the ICS2 Information Exchange Specifications document [R04] and look- up the relevant message ID.
- IE3A11 — Message Id : IE3A11
- IE3A12 — Message Id : IE3A12
- IE3A13 — Message Id : IE3A13
- IE3A14 — Message Id : IE3A14
- IE3A15 — Message Id : IE3A15
- IE3A16 — Message Id : IE3A16
- IE3A17 — Message Id : IE3A17
- IE3A20 — Message Id : IE3A20
- IE3A21 — Message Id : IE3A21
- IE3A22 — Message Id : IE3A22
- IE3A23 IE3A24 — Message Id : IE3A23 IE3A24
- IE3A26 — Message Id : IE3A26
- IE3A27 — Message Id : IE3A27
- IE3A28 — Message Id : IE3A28
- IE3A29 — Message Id : IE3A29
- IE3A30 — Message Id : IE3A30
- IE3A31 — Message Id : IE3A31
- IE3A32 — Message Id : IE3A32
- IE3A33 — Message Id : IE3A33
- IE3A34 — Message Id : IE3A34
- IE3A40 — Message Id : IE3A40
- IE3A41 — Message Id : IE3A41
- IE3A42 — Message Id : IE3A42
- IE3A43 — Message Id : IE3A43
- IE3A44 — Message Id : IE3A44
- IE3A45 — Message Id : IE3A45
- IE3A50 — Message Id : IE3A50
- IE3A51 — Message Id : IE3A51
- IE3Q04 — Message Id : IE3Q04 ; Short Description : Invalidation Request ; Payload Description : An Invalidation Request is submitted by the Sender access point and is received by the ICS2 TI Application. An Invalidation Request is the request for invalidation of an already registered ENS filing.
- IE3Q05 — Message Id : IE3Q05 ; Short Description : Consult ENS ; Payload Description : A Consult ENS request is submitted by the Sender access point and is received by the ICS2 TI Application. Its purpose is to enable the requesting party to look for information about a specific ENS filing and/or an ENS that this filing concerns.
- IE3N06 — Message Id : IE3N06 ; Short Description : Arrival Notification ; Payload Description : An Arrival Notification is submitted by the Sender access point and is received by the ICS2 TI Application. An arrival notification identifies the Member State of Actual First Entry and triggers controls on goods which were identified being a risk requiring a control at the first point of entry in the EU.
- IE3R02 — Message Id : IE3R02 ; Short Description : Additional Information Response ; Payload Description : An Additional Information Response is submitted by the Sender access point and is received by the ICS2 TI Application. Through an Additional Information Response, the Economic Operator will respond with the additional information that was requested. This can be through text and/or attached images or documents.
- IE3R03 — Message Id : IE3R03 ; Short Description : High Risk Cargo & Mail screening response ; Payload Description : An HRCM screening response is submitted by the Sender access point and is received by the ICS2 TI Application. Through an HRCM screening response, the Economic Operator will respond to the request for high risk cargo screening with the results of the screening that the Economic Operator performed.
- IE3R01 — Message Id : IE3R01 ; Short Description : ENS Registration Response ; Payload Description : The ICS2 TI receives an ENS filing, performs validation on received ENS filing, registers ENS filing and assigns MRN to ENS filing. The ICS2 TI notifies successful registration and MRN to the Person filing. This notification may be also communicated to the Carrier when it has requested to be informed and is different from the Person filing.
- IE3N10 — Message Id : IE3N10 ; Short Description : Amendment notification ; Payload Description : ENS lifecycle validation is performed on an amendment of an ENS filing and succeeds. The ENS filing is now amended. The ICS2 TI creates an Amendment notification and sends it to the Person filing.
- IE3R07 — Message Id : IE3R07 ; Short Description : Invalidation Acceptance Response ; Payload Description : ENS lifecycle validation is performed on an invalidation request for an ENS filing and succeeds. The ENS filing is now invalidated. The ICS2 TI creates an Invalidation Acceptance Response and sends it to the Person filing.
- IE3R08 — Message Id : IE3R08 ; Short Description : ENS Consultation results ; Payload Description : The ICS2 TI send the ENS consultation results to the party that requested the consultation.
- IE3R04 — Message Id : IE3R04 ; Short Description : Arrival Registration Response ; Payload Description : The ICS2 TI receives an Arrival Notification of the means of transport, performs validation on received Arrival Notification, registers Arrival Notification and assigns MRN to Arrival Notification. The ICS2 TI notifies successful arrival notification registration and MRN to the Person filing.
- IE3Q02 — Message Id : IE3Q02 ; Short Description : Additional Information request ; Payload Description : The Responsible Member State makes a request for Information. The ICS2 TI creates an Additional Information Request and sends it to the Person filing. The message will contain an indication on whether: the additional information is to be provided through a response to this message; or through an amendment to the EO's original filing.
- IE3Q03 — Message Id : IE3Q03 ; Short Description : High Risk Cargo & Mail screening request ; Payload Description : Decision to request HRCM screening was made. The ICS2 TI creates an HRCM Screening Request and sends it to the Person filing.
- IE3Q01 — Message Id : IE3Q01 ; Short Description : Do Not Load Request ; Payload Description : The risk assessment of an ENS filing is complete. The Economic Operator will be requested to not load a part of his initially declared consignment. The ICS2 TI sends the Do Not Load Request to the Person filing. This notification must be also communicated to the Carrier when the Carrier is different from the Person filing. The specific parts that are not to be loaded will be indicated through the message.
- IE3N04 — Message Id : IE3N04 ; Short Description : Additional Information Request notification ; Payload Description : The Responsible Member State makes a request for Information. The ICS2 TI creates an Additional Information Request notification and sends it to the Carrier when it has requested to be informed and is different from the Person filing.
- IE3N05 — Message Id : IE3N05 ; Short Description : High Risk Cargo & Mail screening request notification ; Payload Description : Decision to request HRCM screening was made. The ICS2 TI creates an HRCM screening request notification and sends it to the Carrier. The Carrier is notified that the Person filing was requested to perform high risk cargo screening and provide his results.
- IE3N03 — Message Id : IE3N03 ; Short Description : Assessment Complete notification ; Payload Description : The risk assessment of an ENS filing is complete. The ICS2 TI sends the Assessment Complete Notification to the Person filing. This notification may be also communicated to the Carrier when it has requested to be informed and is different from the Person filing.
- IE3N08 — Message Id : IE3N08 ; Short Description : Control notification ; Payload Description : A control recommendation was received. e- Screening was performed and it was decided that a control is to be performed at the first port or airport of arrival. The ICS2 TI creates a Control Notification to the Person filing (carrier) who submitted the arrival notification.
- IE3N09 — Message Id : IE3N09 ; Short Description : AEO Control notification ; Payload Description : The Authorised Economic Operator will be notified about the controls that will be performed on the goods that are under his responsibility. The ICS2 TI sends an (AEOS) Control Notification to the Person filing. This notification may be also communicated to the Carrier whenever applicable.
- IE3N02 — Message Id : IE3N02 ; Short Description : ENS Not complete notification ; Payload Description : An ENS is marked as not complete after: the timer for ENS completion has expired; and completeness did not derive from the "Relate ENS filings" sub process. The ICS2 TI sends the ENS Not Complete Notification to the Person filing. This notification may be also communicated to the Carrier whenever applicable. This notification shall also be communicated to all persons that have not yet filed that are connected to the TI.
- IE3N07 — Message Id : IE3N07 ; Short Description : ENS In Incorrect State notification ; Payload Description : The state of an ENS filing is checked upon arrival. The ENS is not in a correct state to announce its arrival. The ICS2 TI creates an Incorrect State Notification and sends it to the Person filing (carrier) who submitted the arrival notification.
- IE3N01 — Message Id : IE3N01 ; Short Description : ENS lifecycle validation error notification ; Payload Description : ENS lifecycle validation is performed on a stored ENS filing and fails. The ICS2 TI creates an ENS Lifecycle Validation Error Notification and sends it to the Person filing. The produced error will be about: one or more key data element(s) being not unique; and/or the incorrect state of any of the concerned ENS(s).
- IE3N99 — Message Id : IE3N99 ; Short Description : Notify Error ; Payload Description : When an syntactical or semantic validation error is found while the Person filing is using the ICS2 TI, the ICS2 TI creates a Validation Error Notification, logs a security event and sends it to the Person filing. The error notification includes the error description and the error code.
- IE3N11 — Message Id : IE3N11 ; Short Description : ENS Pending Notification ; Payload Description : The Person not yet filed is informed that he is obliged to file an ENS filing. The ICS2 TI sends the ENS Pending Notification with ID IE3N11 to the Person not yet filed.
Annex 2. P-MODES SUMMARY
The following table lists the processing mode parameters defined by the eDelivery AS4 specifications and specifies where the TI specifications further constrain the processing mode.
It also describes whether the parameter is not part of eDelivery (not profiled) or whether it is not applicable in the TI use case (unused). Unprofiled parameters may be part of the AS4 profile and may allow a sending MSH to choose a value, which would then be used by the receiving MSH to handle the reception and the response. The MSH ignores unused parameters.
The names of the P-Mode parameter in the table follow the notation described in Annex D 2.1 of [R07].
GENERAL P-MODE PARAMETERS
Table 13. General P-Mode Parameters
- PMode.ID — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode.Agreement — Value in the TI profile (eDelivery AS4 default) : EU-ICS2-TI-V1.0 ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3AMessaging%2Feb%3AUserMessage%2Feb%3ACollaborationInfo - PMode.MEP — Value in the TI profile (eDelivery AS4 default) : http://docs.oasis-open.org/ebxml- msg/ebms/v3.0/ns/core/200704/one Way ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#Message-Exchange-Pattern - PMode.MEPBinding — Value in the TI profile (eDelivery AS4 default) : http://docs.oasis-open.org/ebxml- msg/ebms/v3.0/ns/core/200704/push http://docs.oasis-open.org/ebxml- msg/ebms/v3.0/ns/core/200704/pull ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#Message-Exchange-Pattern - PMode.Initiator.Party — Value in the TI profile (eDelivery AS4 default) : Initiating MSH specific value ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3APartyId - PMode.Initiator.Role — Value in the TI profile (eDelivery AS4 default) : Initiating MSH specific value: 'Trader' or 'Customs' ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3ARole - PMode.Initiator.Authorization.username — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode.Initiator.Authorization.password — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode.Responder.Party — Value in the TI profile (eDelivery AS4 default) : Responding MSH specific value ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3APartyId - PMode.Responder.Role — Value in the TI profile (eDelivery AS4 default) : Responding MSH specific value: 'Trader' or 'Customs' ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3ARole - PMode.Responder.Authorization.username — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode.Responder.Authorization.password — Value in the TI profile (eDelivery AS4 default) : Unused
PROTOCOL
Table 14. Protocol
- PMode[1].Protocol.Address: required — Value in the TI profile (eDelivery AS4 default) : (Required, https URL of the receiver)
- PMode[1].Protocol.SOAPVersion — Value in the TI profile (eDelivery AS4 default) : (1.2)
BUSINESSINFO
Table 15. BusinessInfo
- PMode[1].BusinessInfo.Service — Value in the TI profile (eDelivery AS4 default) : Message specific value: eu_ics2_t2c or eu_ics2_c2t ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3AService - PMode[1].BusinessInfo.Action — Value in the TI profile (eDelivery AS4 default) : Message specific value as per functional specifications ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3AAction - PMode[1].BusinessInfo.Properties — Value in the TI profile (eDelivery AS4 default) : Unused ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3AMessaging%2Feb%3AUserMessage%2Feb%3AMessageProperties - PMode[1].BusinessInfo.MPC — Value in the TI profile (eDelivery AS4 default) : Set to a URI value that is unique to one specific party ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3AMessaging%2Feb%3ASignalMessage%2Feb%3APullRequest - PMode[1].BusinessInfo.subMPCext — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].BusinessInfo.PayloadProfile — Value in the TI profile (eDelivery AS4 default) : Unused
ERRORHANDLING
Table 16. ErrorHandling
- PMode[1].ErrorHandling.Report.SenderErrorsTo — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].ErrorHandling.Report.ReceiverErrorsTo — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].ErrorHandling.Report.AsResponse — Value in the TI profile (eDelivery AS4 default) : (True)
- PMode[1].ErrorHandling.Report.ProcessErrorNotifyConsumer — Value in the TI profile (eDelivery AS4 default) : (True)
- PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer — Value in the TI profile (eDelivery AS4 default) : (True)
RELIABILITY
The reliability P-Mode parameters refer to an older protocol and are unused in AS4 eDelivery. eDelivery relies on receipts and errors in this regard.
SECURITY
Table 17. Security
- PMode[1].Security.WSSversion — Value in the TI profile (eDelivery AS4 default) : (1.1.1)
- PMode[1].Security.X509.Sign — Value in the TI profile (eDelivery AS4 default) : (True)21 ; Notes : See
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#Message-Layer-Security - PMode[1].Security.X509.Signature.Certificate — Value in the TI profile (eDelivery AS4 default) : (Signing Certificate of the Sender) Carefully read section
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#Message-Layer-Security ; Notes : Seehttps://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#Message-Layer-Security - PMode[1].Security.X509.Signature.HashFunct ion — Value in the TI profile (eDelivery AS4 default) : (http://www.w3.org/2001/04/xmlenc#sha256)
- PMode[1].Security.X509.Signature.Algorithm — Value in the TI profile (eDelivery AS4 default) : (http://www.w3.org/2001/04/xmldsig-more#rsa-sha256)
- PMode[1].Security.X509.Encryption.Encrypt — Value in the TI profile (eDelivery AS4 default) : False
- PMode[1].Security.X509.Encryption.Certificat e — Value in the TI profile (eDelivery AS4 default) : (Encryption Certificate of the Receiver)
- PMode[1].Security.X509.Encryption.Algorith m — Value in the TI profile (eDelivery AS4 default) : (http://www.w3.org/2009/xmlenc11#aes128-gcm)
- PMode[1].Security.X509.Encryption.Minimu mStrength — Value in the TI profile (eDelivery AS4 default) : (128)
- PMode[1].Security.UsernameToken.username — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].Security.UsernameToken.password — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].Security.UsernameToken.Digest — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].Security.UsernameToken.Nonce — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].Security.UsernameToken.Created — Value in the TI profile (eDelivery AS4 default) : Unused
- PMode[1].Security.PModeAuthorize — Value in the TI profile (eDelivery AS4 default) : (False)
- PMode[1].Security.SendReceipt — Value in the TI profile (eDelivery AS4 default) : (True)
- PMode[1].Security.SendReceipt.NonRepudiati on — Value in the TI profile (eDelivery AS4 default) : (True)
- PMode[1].Security.SendReceipt.ReplyPattern — Value in the TI profile (eDelivery AS4 default) : (Response)
21 In addition to setting this value to true, a product specific configuration has to be performed in order to ensure that the complete certificate chain used for signature is embedded in the messages (see section
PAYLOADSERVICE COMPRESSIONTYPE
Table 18. Payload Service Compression Type
- PMode[1].PayloadService.Compressi onType — P-Mode Parameter : (application/gzip)
RECEPTIONAWARENESS
Table 19. Reception Awareness
- PMode[1].ReceptionAwareness — P-Mode Parameter : (True)
- PMode[1].ReceptionAwareness.Retry — P-Mode Parameter : (True)
- PMode[1].ReceptionAwareness.Retry.Parameters — P-Mode Parameter : not profiled ; Notes : Implementation specific22
- PMode[1].ReceptionAwareness.DuplicateDetection — P-Mode Parameter : (True)
- PMode[1].ReceptionAwareness.DetectDuplicates.Para meters — P-Mode Parameter : not profiled ; Notes : Implementation specific22
22 The way this parameter is specified (format) is product specific. In a later version of this document, guidelines will be given about the number of retries and the interval between retries.
Annex 3. SAMPLE MESSAGE SCENARIO
The following sequence diagram provides an overview of an ENS Filing message by an Economic Operator (EO) and its reply by a Trader Interface from an AS4 perspective.
Figure 19: ENS Filing message scenario The sequence diagram depicts the following scenario:
IE3Fxx - ENS Filing. An Economic Operator (EO) submits an ENS Filing (IE3Fxx) using an AS4 message handler (C2-MSH) to an STI/NTI AS4 message handler (C3-MSH):
- This message has as eb:MessageId a unique value '1'23;
- The eb:From/eb:PartyId identifies the EO and has an eb:From/eb:Role of 'Trader';
- The eb:To/eb:PartyId identifies the addressed STI/NTI and has an eb:To/eb:Role of 'Customs';
- The addressed eb:Service is 'eu_ics2_t2c' with an eb:Action of 'IE3Fxx';
- In the eb:PayloadInfo a single eb:PartInfo that specifies in its eb:Property's as Mime type 'application/xml', as Characterset 'utf-8' and as CompressionType 'application/gzip' (see section
https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347120133/4.+TECHNICAL+INFORMATION+EXCHANGE+SPECIFICATIONS#eb%3AMessaging%2Feb%3AUserMessage%2Feb%3APayloadInfo ); - The message contains one additional Mime part (as specified in the eb:PayloadInfo) containing the functional payload, i.e. a functional message IE3Fxx as specified in the common functional specification and encoded in the XML format as specified by the applicable XSD. The functional message contains an LRN specified by the EO.
The SignalMessage depicted in the sequence diagram for each of UserMessages is a synchronous http response and contains the AS4 receipt of the UserMessage by the receiving MSH. It contains the seal of the receiving MSH in relation with the submitted UserMessage (see section
The UserMessage IE3Fxx is received by the C3-MSH of the STI/NTI addressed and further processed by this system. This processing will result in a single reply message with regards to this ENS filing. This message can be an ENS registration response, an Error notification or an ENS lifecycle validation error notification. Independent of the message type, the following AS4 properties apply:
- The message has as eb:MessageId a unique value of '2';
- The eb:ReftoMessageId is specified and has a value of '1' referring to the eb:MessageId of the initial ENS filing;
- The eb:From and eb:To Parties are inversed;
- The addressed eb:Service is 'eu_ics2_c2t'. However, the eb:Action property depends on the specific message type returned;
- In the eb:PayloadInfo a single eb:PartInfo is specified with in its eb:Property's as Mime type 'application/xml', as Characterset 'utf-8' and CompressionType 'application/gzip';
- The message contains one additional Mime part (as specified in the eb:PayloadInfo) containing the specific functional message as specified in the eb:Action property as specified in the common functional specification and encoded in the XML format as specified by the applicable XSD.
Depending on the STI/NTI processing one of the following reply messages applies:
(2a) IE3R01 – ENS Registration response. The message confirms the registration of the ENS Filing and the attribution of an MRN to this filing. In addition to the common properties the following AS4 properties apply:
- The eb:Action is set to the value 'IE3R01';
- The additional Mime part contains a functional message of type IE3R01. This message contains the LRN provided in the functional payload of the initial ENS filing and the corresponding MRN attributed by the STI/NTI.
(2b) IE3N01 – ENS lifecycle validation error notification. The message indicates that the ENS to which this filing is related is in a state that does not allow a filing. In addition to the common properties the following AS4 properties apply:
- The eb:Action is set to the value 'IE3N01';
- The additional Mime part contains a functional message of type IE3N01. This message contains the LRN provided in the functional payload of the initial ENS filing. It also provides an indication of the actual reason(s) for the life cycle validation error.
(2c) IE3N99 – Error notification. The message indicates that there are syntax and/or semantical errors found in the initial ENS filing. In addition to the common properties the following AS4 properties apply:
- The eb:Action is set to the value 'IE3N99';
- The additional Mime part contains a functional message of type IE3N99. This message contains the LRN provided in the functional payload of the initial ENS filing if it could be extracted from the initial ENS filing. It also provides an indication of the actual error(s). In the case no LRN can be provided, the only way to associate this reply message with the initial ENS filing is the eb:RefToMessageId property.
IE3R01 – ENS Registration response to Carrier. In case of the registration of the ENS filing (2a), the ENS registration response message is optionally also sent to the carrier identified in the initial ENS filing if the carrier has expressed the preference to receive such messages24. In addition to the common properties the following AS4 properties apply:
- The eb:Action is set to the value 'IE3R01';
- The additional Mime part contains a functional message of type IE3R01. This message contains the LRN provided in the functional payload of the initial ENS filing and the corresponding MRN attributed by the STI/NTI.
23 In this document, simple values like '1','2' are used for readability of the document. However in a real implementation, the sender must guarantee uniqueness of these message id's and typically would consists out of an UUID or equivalent id generating system.
24 Note that this means that the Carrier must be registered in this TI.
Annex 4. EBMS ERRORS
The following sections describe ebMS errors according to the stage they are likely to occur. It also includes a table for UUM&DS extensions.
EBMS PROCESSING ERRORS
The table below describes the Errors that may occur within the ebMS Module itself (ebMS Errors that are not Escalated Errors), i.e. with @origin="ebms". These errors MUST be supported by an MSH, meaning generated appropriately, or understood by an MSH when reported to it.
Table 20. ebMS Processing Errors
- EBMS:0001 — Short Description : ValueNotRecognized ; Severity : failure ; Category Value : Content ; Description or Semantics : Although the message document is well formed and schema valid, some element/attribute contains a value that could not be recognized and therefore could not be used by the MSH.
- EBMS:0002 — Short Description : FeatureNotSupported ; Severity : warning ; Category Value : Content ; Description or Semantics : Although the message document is well formed and schema valid, some element/attribute value cannot be processed as expected because the related feature is not supported by the MSH.
- EBMS:0003 — Short Description : ValueInconsistent ; Severity : failure ; Category Value : Content ; Description or Semantics : Although the message document is well formed and schema valid, some element/attribute value is inconsistent either with the content of other element/attribute, or with the processing mode of the MSH, or with the normative requirements of the ebMS specification.
- EBMS:0004 — Short Description : Other ; Severity : failure ; Category Value : Content
- EBMS:0005 — Short Description : ConnectionFailure ; Severity : failure ; Category Value : Communication ; Description or Semantics : The MSH is experiencing temporary or permanent failure in trying to open a transport connection with a remote MSH.
- EBMS:0006 — Short Description : EmptyMessagePartitionChannel ; Severity : warning ; Category Value : Communication ; Description or Semantics : There is no message available for pulling from this MPC at this moment.
- EBMS:0007 — Short Description : MimeInconsistency ; Severity : failure ; Category Value : Unpackaging ; Description or Semantics : The use of MIME is not consistent with the required usage in this specification.
- EBMS:0008 — Short Description : FeatureNotSupported ; Severity : failure ; Category Value : Unpackaging ; Description or Semantics : Although the message document is well formed and schema valid, the presence or absence of some element/ attribute is not consistent with the capability of the MSH, with respect to supported features.
- EBMS:0009 — Short Description : InvalidHeader ; Severity : failure ; Category Value : Unpackaging ; Description or Semantics : The ebMS header is either not well formed as an XML document, or does not conform to the ebMS packaging rules.
- EBMS:0010 — Short Description : ProcessingModeMismatch ; Severity : failure ; Category Value : Processing ; Description or Semantics : The ebMS header or another header (e.g. reliability, security) expected by the MSH is not compatible with the expected content, based on the associated P-Mode.
- EBMS:0011 — Short Description : ExternalPayloadError ; Severity : failure ; Category Value : Content ; Description or Semantics : The MSH is unable to resolve an external payload reference (i.e. a Part that is not contained within the ebMS Message, as identified by a PartInfo/href URI).
SECURITY PROCESSING ERRORS
The table below describes the Errors that originate within the Security Module, i.e. with @origin="security". These errors MUST be escalated by an MSH, meaning generated appropriately, or understood by an MSH when reported to it.
Table 21. Security processing errors
- EBMS:0101 — Short Description : FailedAuthentication ; Severity : failure ; Category Value : Processing ; Description or Semantics : The signature in the Security header intended for the "ebms" SOAP actor, could not be validated by the Security module_._
- EBMS:0102 — Short Description : FailedDecryption ; Severity : failure ; Category Value : Processing ; Description or Semantics : The encrypted data reference the Security header intended for the "ebms" SOAP actor could not be decrypted by the Security Module.
- EBMS:0103 — Short Description : PolicyNoncompliance ; Severity : failure ; Category Value : Processing ; Description or Semantics : The processor determined that the message's security methods, parameters, scope or other security policy-level requirements or agreements were not satisfied.
RELIABLE MESSAGING ERRORS
The table below describes the Errors that originate within the Reliable Messaging Module, i.e. with @origin="reliability". These errors MUST be escalated by an MSH, meaning generated appropriately, or understood by an MSH when reported to it.
Table 22. Reliable message errors
- EBMS:0201 — Short Description : DysfunctionalReliability ; Severity : failure ; Category Value : Processing ; Description or Semantics : Some reliability function as implemented by the Reliability module, is not operational, or the reliability state associated with this message sequence is not valid.
- EBMS:0202 — Short Description : DeliveryFailure ; Severity : failure ; Category Value : Communication ; Description or Semantics : Although the message was sent under Guaranteed delivery requirement, the Reliability module could not get assurance that the message was properly delivered, in spite of resending efforts_._
AS4 FEATURE ERRORS
The following error codes are extending the set of ebMS V3 error codes to support the AS4 additional features. They are to be generated and/or processed by an AS4 MSH depending on which feature is supported (i.e. depending on the conformance profile):
Table 23. AS4 feature errors
- EBMS:0301 — Short Description : MissingReceipt ; Severity : failure ; Category Value : Communication ; Description or Semantics : A Receipt has not been received for a message that was previously sent by the MSH generating this error.
- EBMS:0302 — Short Description : InvalidReceipt ; Severity : failure ; Category Value : Communication ; Description or Semantics : A Receipt has been received for a message that was previously sent by the MSH generating this error, but the content does not match the message content (e.g. some part has not been acknowledged, or the digest associated does not match the signature digest, for NRR).
- EBMS:0303 — Short Description : Decompression- Failure ; Severity : failure ; Category Value : Communication ; Description or Semantics : An error occurred during the decompression.
UUM&DS FEATURE ERRORS
UUM&DS validation errors returned by the Trader Interface AS4 access point is described here. The ebMS error EBMS:0004 will be returned, with the sub-code as defined in the table below.
Table 24. UUM&DS errors
- EBMS:0004 — Subcode : A001 ; Meaning : UUM&DS rejected the authorization and the incoming message is rejected.
- EBMS:0004 — Subcode : A002 ; Meaning : Technical user trying to connect to the rest API is rejected.
- EBMS:0004 — Subcode : A003 ; Meaning : Internal UUM&DS error, or UUM&DS is down
- EBMS:0004 — Meaning : Other internal error not related to UUM&DS, please contact the helpdesk
Annex 5. MESSAGE LAYER SECURITY CONTROLS
The next paragraphs provide a detailed description of the security controls of an eDelivery AS4 implementation, as well as the communication flow between Access Points as depicted in the figure below.
Figure 20: Security controls of eDelivery AS4 implementation 1. The sender Access Point creates an AS4 message composed of a SOAP header, an empty SOAP body and one payload (or more if attachments are handled as separate payloads) with the receiver as a recipient. The unencrypted and electronic sealed content is included in an attachment. The electronic seal is performed using a recommended cipher suite with the private key of the sender. In addition, the header containing the message metadata details, such as message ID is also sealed by the sender. The electronic seal digest of the header and of the content payload are included in the WS-Security header, whereas the SOAP body is sent empty as described in the eDelivery AS4 profile; 2. The message is sent through a TLS connection, providing message confidentiality and authenticity at the transport layer. The TLS cipher suites should follow the ENISA guidelines as described in the eDelivery AS 4 specifications; 3. The receiver verifies the integrity and authenticity of the message according to the digital certificate (public key) of the sender. This assures the receiver that the sender was the sender of the message, and that the message was not tampered with during communication; 4. Upon reception and verification, the receiver generates an evidence receipt based on the message information received, electronically seals it using its digital certificate and sends it to the sender as proof of receipt. The electronic seal provides integrity and authenticity of the evidence as the sender can verify that the message has been received by the receiver.
Annex 6. EXAMPLE
An example message can help to clarify what the eDelivery AS4 conformant solutions selected by the trader must produce
```
The Security header contains the security header information.
The BinarySecurityToken element defines a security token that is binary encoded. The ValueType must be #X509PKIPathv1 and not #X509v3.
The Signature element contains information about the signature of the message.
The SignedInfo contains information about the canonicalization algorithm and signature algorithm used for the XML signature for each of the attachments and the business message. Attachment-Content-Signature-Transform is used for the signature of the MIME Parts. (MIME headers are not part of the signature, only the content).
The SignatureValue contains the value of the XML digital signature25.
25 Please note both the message as the receipt must be signed. Please also note that the signature must also encompass the signature of the empty SOAP Body, e.g. the signature is over the AS4 header and the empty SOAP body.
The KeyInfo contains the signatory's certificate, or a reference to a MIME part as in the example below.
The Messaging element contains the UserMessage.
The MessageInfo as described in
The PartyInfo as described in
The CollaborationInfo as described in
The PayloadInfo as described in
An alternative example with attachments is given below
``` MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="ics2@trader.com" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-ID: < ics2@trader.com >
Source : https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/3347841043