The basic structure of an AS2 message consists of MIME format inside an HTTP message with additional AS2-specific headers. The nature of the message beneath the HTTP, AS2, and MIME headers depends upon the type of message:
Signed – If the message is signed, a signature wrapper is added around the document payload.
Compressed – If the message is compressed, a compression wrapper is added around the document and signature payloads.
Encrypted – If the message is encrypted, an encryption wrapper is added around the document, signature, and compression payloads.
The message structure of an AS2 message, based upon encryption, signature, and compression is shown in the table below.
If the document payload consists of multiple documents, they are stored within a multipart/related MIME envelope as described in RFC 2387. A Content-Disposition MIME header can be used to specify the filename of each document within the message.
The following table shows the message structure of an AS2 message that contains multiple attachments, based upon the message encryption, signature, and compression options.
Context properties used in processing AS2 messages include properties that can be promoted as well as properties that are not publicly exposed, but can be viewed in suspended and tracked messages. For a list of AS2 context properties, see AS2 Context Properties.
AS2 Headers
The AS2 headers in AS2 messages describe the receiving and sending parties, and provide the information that the receiving party needs to send an MDN response. The receiving party will use the MDN headers unless the Use agreement settings for validation and MDN instead of message header property is selected in the AS2 agreement, or if the information is not available in the agreement properties.
The AS2-From header, AS2-To header, and MessageID context property uniquely describe an AS2 message. They are also used to correlate an MDN to the AS2 message that it is responding to.
These headers are listed (in alphabetical order) in the following table:
AS2 Header
Required/Optional
Values
AS2-Version
Optional
"1.1"
AS2-From
Required
Name of the company that sent that the AS2 message.
Values: string, printable ASCII, 1 to 128 chars in length
AS2-To
Required
Name of the company that the AS2 message is sent to.
Values: string, printable ASCII, 1 to 128 chars in length
AS2-Text
Required
Text (in this header in the message)
Values: string, printable ASCII, 1 to 128 chars in length
Disposition-Notification-To
Required
When present, serves as a request for an MDN to be returned. If it is accompanied by a receipt-delivery-option header, then it is a request for an asynchronous MDN. If not, then it is a request for a synchronous MDN.
When not present, an MDN is not required.
Value: a mail address that must be present. However, the address must not be used to identify where to return the MDN. The receiving application must ignore the mail address and must not complain about address syntax violations.
EDIINT-Features
Required
Indicates the features supported by the originating system. BizTalk uses this header to indicate support for multiple attachments.
Value: “MA”
Receipt-Delivery-Option
Required
Indicates the URL that the MDN should be sent to. When Receipt-Delivery-Option is present, Disposition-notification-to serves as a request for an asynchronous MDN. Receipt-Delivery-Option must always be accompanied by Disposition-Notification-To.
When Receipt-Delivery-Option is not present, and Disposition-notification-to is present, Disposition-notification-to serves as a request for a synchronous MDN.
Values: a URL string.
signed-receipt-protocol
(in Disposition-Notification-Options)
Optional
When set to "pcks7-signature", is used to request a signed receipt from the receiving party, and indicates the format in which the signed receipt should be returned to the requester.
Values: optional, pcks7-signature
signed-receipt-micalg
(in Disposition-Notification-Options)
Optional
A list of MIC algorithms preferred by the requester for use in signing the returned receipt. The list of MIC algorithms should be honored by the receiving party from left to right.
Values: optional, MD5 or SHA1
For incoming messages, the AS2EdiReceive and AS2Receive receive pipelines validate the values of the Signed Receipt Protocol and Signed Receipt MIC Algorithm from the AS2 agreement properties.
For outgoing AS2 messages, the AS2EdiSend and AS2Send send pipelines populate the above AS2 headers from values entered in the AS2 agreement (with the exception of the AS2-Version, which is hardcoded as 1.1).
Request for MDN
A request that the receiving party return an MDN (Message Disposition Notification) is made by placing the following header in the message to be sent:
The mail address is not used to identify where to return the MDN. Receiving applications must ignore the value, and not post an error about address syntax violations.
Do you want to know how to send and receive electronic documents in Business Central? This module explains the setup that is required to send electronic documents, and then it demonstrates how to send and receive electronic PEPPOL documents with and without a provider.