SBDH provides a standard way to encode some message metadata. This can be used to simplify delivery and routing of payload, and to control the way content is processed (e.g. transformed).
The SBDH is a payload, it is not part of the eDelivery AS4 (or other) message header and therefore not dependent on any features or aspects of eDelivery AS4. This means that, when used with eDelivery AS4 in a Four Corner Topology, it can be used as an “end-to-end” header in all legs: from C1 to C2, from C2 to C3 and from C3 to C4. The information is preserved and is available to the Consumer.
What are the main drawbacks of using SBDH?
There may be an impact on the XML schemas of exchanged XML payloads.
The SBDH can be argued to be redundant. Some or all of its content may already be present in another part of an XML document or in the eDelivery header, e.g. the SBDH Sender party may, when used with a UBL Orderdocument, be the same as the BuyerCustomerParty and as the originalSender message property of the eDelivery AS4 header.
While SBDH has some extensibility features, it may not support all requirements and use cases for message metadata
Do we have to use SBDH if we are using eDelivery?
No, eDelivery is payload-neutral and intended to be used with arbitrary content. From the eDelivery point of view, SBDH is considered part of the content that is exchanged. Constraints on exchanged content are to be agreed within specific user communities.
Does use of SBDH require us to change our document schemas?
If a domain uses the SBDH as a header in one of more of its XML business documents, the XML schema for that business document needs to allow the SBDH to be used as a header element.
However, the SBDH can also be used as a separate, standalone XML payload that only provides metadata about (an) other payload(s). In that case, there is no impact on the XML schema for that (those) payload(s). In fact, there is no requirement that the payload(s) are XML. This situation is well supported in eDelivery AS4.
Does SBDH support the same metadata as the AS4 header?
No, some features of the AS4 header have no counterpart in SBDH, in particular the AgreementRef, party Role headers and payload part properties. Some headers are similar but have strictly speaking different semantics (e.g. ProcessIdentifier and Service).
Using ASiC, it is possible to package and sign any payload (or multiple payloads) in a single file container.
Unlike AS4 message signatures, ASiC signatures are part of payload and can therefore be preserved “end-to-end”, across multiple legs, even in four-corner topologies.
What are the main drawbacks of using ASiC?
End-to-end signing and encryption is often not feasible because of PKI incompatibilities and functional or technical limitations of backend applications. Messaging protocols have added and are providing signing and encryption features precisely for this reason.
End-to-end signature assumes payloads are exchanged without modifications, whereas often intermediaries perform payload transformation or other processing.
Do we have to use ASiC if we are using eDelivery?
No, eDelivery is payload-neutral and intended to be used with arbitrary content. From the eDelivery point of view, ASiC is considered part of the content that is exchanged. Constraints on exchanged content are to be agreed within specific user communities.
Do we have to use ASiC if we are exchanging multiple payloads in eDelivery?
Some users find it convenient to wrap all payloads of a message in a ZIP archive or other container before exchanging it using eDelivery. However, eDelivery AS4 does not pose any limit on the number of payloads in message, so you can exchange any number of payloads in a single message. In this aspect, AS4 is just as flexible as email or AS2 [RFC6362].