Lesson 1 of 5
AS2 in practice
11 min
Listen to this lesson
AS2 (Applicability Statement 2, defined in RFC 4130) is how most large trading partners move EDI files over the internet. It is HTTP or HTTPS with S/MIME on top: the sender can sign the file, encrypt it and compress it, and asks the receiver for a signed receipt called a Message Disposition Notification (MDN). The MDN is what turns "we posted a file" into "you received exactly this file", and it is the reason AS2 is still the default for retail, automotive and fleet customers.
This course is for integration developers who build or troubleshoot the technical layer under B2B on SAP Integration Suite, whether the flows are SAP's generic Trading Partner Management flows or flows you build yourself. The running example is Great Lakes Fleet Services, Contoso's largest EDI customer, which sends X12 850 orders over AS2 and receives 855, 856 and 810 documents back. Today the traffic runs through the AS2 adapter of the B2B add-on on SAP Process Orchestration (XP1); it moves to Cloud Integration in integration wave 2 (February to March 2027), and the Contoso examples in this course come from that wave's tests in the Integration Suite test tenant.
What one AS2 exchange proves
The MDN is a transport-level receipt. It says the file arrived intact and was processed by the AS2 software. It says nothing about whether the 850 inside is valid EDI or whether it became a sales order: that is the job of the X12 997 functional acknowledgment (or EDIFACT CONTRL) and of business documents such as the 855. Keep the three apart in every test and every support conversation.
Synchronous or asynchronous MDN
The sender decides how it wants the receipt. With a synchronous MDN the receipt comes back on the same HTTP connection as the response to the post. With an asynchronous MDN the receiver posts the receipt later to a URL the sender supplied. Synchronous is simpler and common for small files; asynchronous suits large files or receivers that process before they acknowledge.
The AS2 sender adapter (receiving from partners)
In Cloud Integration you receive AS2 with a sender channel using the AS2 adapter and message protocol AS2. Partners post to https://<host>:<port>/as2/as2 plus the relative Address you configure, such as /orders; asynchronous MDNs go to /as2/mdn and are received by a separate channel using the AS2 MDN adapter. The settings that matter most:
| Tab | Setting | What to decide |
|---|---|---|
| Connection | Authorization | Client certificate, or user role (default role ESBMessaging.send). |
| Processing | Partner AS2 ID, Own AS2 ID, Message ID left and right parts, Message Subject | These identify the channel for an incoming message. Regular expressions are allowed, but the combination must be unique across all AS2 sender channels on the tenant. |
| Processing | Mandatory File Name, Duplicate Message ID, Duplicate File Name | Reject files without a name with a negative MDN; reject repeats of the same AS2 message ID or file name within a persist duration in minutes. |
| Security | Decrypt Message, Private Key Alias, Verify Signature, Public Key Alias | Decrypt with your private key; verify with the partner's certificate (trusted certificate or trusted root). |
| MDN | Private Key Alias for Signature, Signature Encoding, settings for asynchronous MDN | How your MDN is signed, and how Cloud Integration connects back to the partner for async MDNs. |
| Delivery Assurance | Quality of Service | Exactly Once or Best Effort (see below). |
| Conditions | Body and attachment size limits | Reject oversized messages; the minimum limit is 1 MB. |
The AS2 sender adapter settings that decide whether a partner's file is accepted.
Quality of Service changes when the partner gets its MDN. With Exactly Once, the message is stored in a JMS queue first and the MDN is sent at once; if later processing fails, the message is retried from the queue with the retry interval, optional exponential backoff and a dead-letter queue you configure. With Best Effort, the message is processed immediately and the MDN is sent only if processing succeeds, which also lets you customize the MDN through a script that changes the exchange property SAP_AS2_MDN. Exactly Once needs the tenant's message queues; stored messages expire after 90 days.
The AS2 receiver adapter (sending to partners)
Outbound documents leave through a receiver channel with the AS2 adapter. On the Connection tab you set the recipient URL, proxy type and authentication. On Processing you set the file name (default <Own AS2 ID>_File), the AS2 IDs, subject and content type, for example application/edi-x12. On Security you choose whether to compress, sign (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 or MD5) and encrypt (3DES, AES128, AES192, AES256 or RC2). On MDN you choose the MDN type (synchronous, asynchronous or none), whether to request a signed MDN and a MIC, and, for synchronous MDNs, whether to verify the MDN signature and MIC.
| Choice | Contoso's setting for Great Lakes | Why |
|---|---|---|
| Sign outbound | Yes, SHA-256 | Great Lakes verifies origin; SHA-1 and MD5 are offered but weak |
| Encrypt outbound | Yes, AES256 | Invoices carry prices and bank details |
| MDN type | Synchronous, signed, MIC requested and verified | Great Lakes returns MDNs immediately |
| Message Failure on Negative MDN | Enabled | A rejected 856 must show as Failed in monitoring |
| Inbound Quality of Service | Exactly Once | Great Lakes gets its MDN at once; Contoso retries internally |
What would you do?
Great Lakes says Contoso's 856 ship notices "keep bouncing", but every outbound 856 in Contoso's message monitor shows Completed. The AS2 receiver channel requests a synchronous MDN. What is the most likely explanation?
- AS2 adds signing, encryption, compression and a signed receipt (MDN with MIC) to HTTP; the MDN proves receipt, not EDI validity.
- Partners post to /as2/as2 plus your address; asynchronous MDNs arrive at /as2/mdn on an AS2 MDN sender channel.
- The AS2 IDs, message ID parts and subject select the sender channel and must be unique across the tenant.
- Exactly Once queues and then MDNs; Best Effort MDNs only after successful processing.
- Enable Message Failure on Negative MDN, or negative synchronous MDNs stay Completed.
Check your understanding · not graded
Lesson check
1. What does an AS2 MDN prove?
2. Which path do partners use to send asynchronous MDNs to Cloud Integration?
3. With Quality of Service Exactly Once on the AS2 sender, when does the partner get its MDN?
4. Which receiver-channel option makes a negative synchronous MDN set the message to Failed?