Step-by-Step Guide: Secure File Exchange with AS2 Adapter in SAP Cloud Integration
Sending and Receiving with AS2
Ready for a quick, hands-on story about sending files safely between companies? In this part, we’ll walk through how to set up the AS2 protocol—a popular way to send important documents online, keeping them private and making sure they arrive as intended.
You’ll learn how to:
- Set up your system to send and receive files using AS2
- Turn on security features to keep your files safe while they travel
- Get a special receipt (called an MDN) every time a file is delivered, so you know it made it safely
- Handle big batches of files and make sure each one is tracked properly
All of this is designed so you can follow along in just 10–15 minutes—no fuss, no confusion. By the end, you’ll have a working setup that connects smoothly with the tools we’ll cover next.
In this blog I am using two tenants One as sender Adapter [who is receiving the Data]and one as |Receiver Adapter [who is sending the Data].
Workflow Mechanism
Tenant 1: Sender Adapter Configuration
Feature |
Details |
Authentication 1 |
Role-Based via Load Balancer with ESB Messaging role |
Decryption |
Use Receiver’s Certificate |
Signing |
Use own Keypair Name Algorithm: e.g., SHA256withRSA |
MDN (Message Disposition Notification) |
Asynchronous MDN – Use same certificate used in Decryption – Authentication: Basic Auth or Client Certificate (depends on Tenant 2 setup) – Triggered by Asynchronous iFlow from Tenant 2 |
Tenant 2: Receiver Adapter Configuration
Feature |
Details |
Authentication |
Basic Auth or Client Certificate – Use Client ID/Secret or PFX file received from Sender |
Encryption |
– Create and configure a Key Pair – Specify keypair name in Encryption Section – Use the same algorithm as the keypair |
Signing |
– Upload and configure the Sender’s Certificate |
MDN Synchronous |
– Use Sender’s certificate for signing |
MDN Asynchronous |
– No authentication required |
Tenant 2: Asynchronous Flow (for MDN callback)
Feature |
Details |
Authorization |
– Role-based access – Forward the PFX file to Tenant 1 (Sender) – Used to sign MDN or decrypt incoming AS2 messages |
AS2 sender (Receiving data) Configurations
Step 1: Create an I Flow
- Log in to SAP Cloud Integration (CPI)
- Open your CPI tenant.
- Go to Design.
- Create a New Integration Flow:
- Click on Artifacts under your desired package.
- Click Add > Integration Flow.
- Provide a Name and Description.
- Click OK.
Step 2: Add Sender and Start Message
- Add Sender:
- In the IFlow canvas, drag the Sender element from the palette to the left side of the flow.
- Configure Sender with AS2 Adapter
- Click on the Sender element.
- Connect Sender to Start Message
- In the Adapter Type dropdown, select AS2.
- Click the pencil/edit icon to modify the AS2 adapter settings
Step 3: In the connection tab of AS2 Adapter
Address:
- This is the endpoint path to which the AS2 messages will be sent.
- Use a unique and descriptive path (e.g., /as2/receiver-partner).
- Ensure it is consistent with your partner configuration.
Authorization:
- You need to specify the authorization type for accessing the AS2 endpoint.
- Typically, this is “User Role”.
User Role:
- The user role assigned here must have access rights to call or expose the AS2 endpoint.
- Example: ESBMessaging.send, AS2InboundUser, or any custom role with proper permissions.
- This the role that I was being used in the AS2 Endpoint creation iflow. If you would like to create a new role. Create in the Manage Security Material > User Roles and you can assign the role in the Integration flow service key instance so that this service key instance credentials can be used for authentication.
I have assigned role in the Integration flow Instance (DEV) and Updated the Instance.
I have assigned role in the Integration flow Instance (DEV) and Updated the Instance.
Step 4: In the processing Tab of AS2 Adapter
PARTNER ID RESOLUTION
Source: Authorized User
- This means the AS2 partner is determined based on the authenticated user calling the endpoint.
- The user must be mapped to a partner AS2 ID in your system.
EXPECTED MESSAGES
These fields define criteria to filter and validate inbound AS2 messages:
Message ID Left Part / Right Part:
- Typically used to validate a pattern in the AS2 message ID.
- Default is 0 which means no filtering is applied.
Partner AS2 ID:
- Expected AS2 identifier of the partner.
- 0 means no specific partner filtering.
Own AS2 ID:
- Your tenant’s AS2 ID. Used to verify the To: AS2 header.
- If set to 0, it’s not enforced.
Message Subject:
- Can be used to filter messages based on the subject header.
- 0 means subject is not checked.
Number of Concurrent Processes:
- Controls parallel processing of incoming messages.
- Set to 1 in screenshot — means single-threaded processing for this endpoint.
MESSAGE SETTINGS
Mandatory File Name:
- If enabled, the AS2 message must include a filename.
- Useful for systems relying on filename-based routing.
Duplicate Message ID:
- If enabled, it checks for duplicate AS2 message IDs and avoids processing them again.
- Prevents reprocessing of already received messages.
Duplicate File Name:
- Checks for duplicate file names in incoming messages.
Step 5: Configuration of Security tab in AS2 Adapter:
MESSAGE DECRYPTION
Decryption Configuration Type: Channel Configuration
- This means the decryption settings are configured directly in the adapter, not inherited from integration flow settings.
Decrypt Message: (Checked)
- This indicates the incoming AS2 message is expected to be encrypted.
- CPI will decrypt it using the specified private key.
Private Key Alias:
- This is the alias of the private key created in the Keystore of your tenant.
- CPI uses this private key to decrypt the AS2 message.
- You have to create the Keypair in the keystore (with alias like as2_decryption_key). After Creating it, we have to download the certificate of the keypair which we have created.
- Ensure the certificate is sent to the person who is encrypting data.
SIGNATURE VERIFICATION
Verify Signature: Not Required
- Means the inbound AS2 message is not expected to be signed.
- CPI will not verify the digital signature of the message.
Required: TRUSTED CERTIFICATE
- Enforces signature verification.
- Verifies if signature is present but doesn’t fail if it’s missing.
- Add the Certificate in the keystore which received from the receiver with the name and mention it in the public key alias
Required: TRUSTED ROOT CERTIFICATE
- For this get the root certificate from the Receiver and upload in the Keystore with alias name and mention in the Iflow.
Step 6: Configuration of MDN tab in AS2 Adapter:
Private Key Alias for Signature:
- Used to sign the MDN (Message Disposition Notification).
- Ensure the alias exists in Keystore. (This is the name of the keypair that you have used in the decryption process)
Signature Encoding:
- Format of the MDN signature.
- Options: binary or base64. [ Better to keep it required as we have Provide private key]
Propagate MDN Details to Exchange:
- Sends MDN info (like disposition, timestamp) to integration flow.
- Optional – enable if needed by downstream logic. [Better to keep it required]
Negative MDN on Processing Failures:
- Sends a negative MDN if message processing fails.
- Useful for notifying partners about issues.
Asynchronous MDN Connection Settings:
Proxy Type:
- Typically set to Internet.
Authentication:
- Method to authenticate async MDN responses.
- Usually None unless required by proxy.
Timeout (in ms):
- Wait time for async MDN.
- Example: 300000 ms = 5 minutes.
Feature/Aspect |
Synchronous MDN (AS2) |
Asynchronous MDN (AS2) |
MDN Handling |
MDN (receipt) is generated and attached to the log immediately when the AS2 endpoint is hit, regardless of payload correctness. |
MDN response is delayed; the system waits to send the MDN to another AS2 endpoint (possibly on a different tenant). |
Endpoint |
MDN returned to sender in the same HTTP session as the original message. |
MDN sent to a different AS2 endpoint (may be on another tenant), not in the same session. |
Authentication |
Uses the sender’s own credentials or local settings. |
Requires the PFX file (certificate) of the target AS2 endpoint’s tenant for authentication. |
Use Case |
Immediate acknowledgment, simple integration, and logging. |
Flexible routing, multi-tenant or cross-system integrations, delayed or custom processing. |
Step 7: Configuration of Delivery Assurance tab in AS2 Adapter:
Quality of Service:
- Set to Exactly Once – ensures no duplicate message processing.
Retry Interval (in min):
- Initial retry delay.
- Example: 1 min before first retry.
Exponential Backoff:
- Retries wait longer after each failure (e.g., 1 → 2 → 4 min).
Maximum Retry Interval (in min):
- Max delay between retries.
- Example: 60 min.
Dead-Letter Queue:
- Failed messages go to DLQ after max retries – helps in error analysis.
Encrypt Message During Persistence:
- Ensures messages are encrypted when stored – enhances security.
Step 8: Configuration of Conditions tab in AS2 Adapter:
Body Size (in MB):
- Max size for the main AS2 message body.
- Example: 40 MB
- Set based on expected payload size.
- Helps avoid memory overload.
Attachments Size (in MB):
- Max total size for all attachments.
- Example: 100 MB
- Set based on typical file sizes (e.g., PDFs, XML).
- Prevents oversized message issues.
Note the As2 Endpoint after it gets deployed stage.
AS2 Receiver Adapter (Sending Request with payload)
- Create a new Iflow in the same tenant or any other different tenant (Would be best if it is another tenant)
- Design the iflow as specified in the above manner with all the necessary pallet functions
- In the Connection tab. Give the as2 endpoint that you have from the sender adapter.
- Select the authentication to be basic and paste the credential name from the security material.
Now for the basic authentication. Get the Client id and client secret from the Sender Adapter tenant which can be found in integration flow plan service key.
- After you have gained the client id and client secret. Go to Monitor>Manage Security material> Security Material
- Select Create>User Credentials
- Paste the Client id in the user section and the client secret in password and repeat password with a proper naming convention.
- In the processing tab. Give a proper File name for transferring and fill all the sections that you have done in the sender adapter iflow with the same ones.
- Mention the content type to be application/edi-x12 as we are transferring the payload from EDI format.
In the Security Tab.
- Select the Compress message for reducing the size of the payload you need to send.
- For Signing Message, you need to create Keypair in the Keystore>Monitor tab with the alias name AS2_signing.
- Give the alias name in private key alias
- You have to download the certificate from the keypair (which you have created just now for signing) and give it to the sender in the other tenant.
- For Encrypting the Message, you need to get the certificate from the person who is decrypting, then you have to upload certificate in the keystore > Monitor(with the alias name as as2_decrypting).
- Mention the alias name in the public key alias.
In the MDN. There will be four options to be selected [ Synchronous, Asynchronous, Dynamic , None ]
If you select the Synchronous type [ In case you want the response when you sent the request]
You can request signing, with the specific Algorithm.
If you need to verify signature. You need to give the Private key alias. Which is the certificate that you will get from the sender adapter which can be found in the Keystore.
Paste the EDI payload in the content modifier as specified above.
ISA*01*0000000000*01*0000000000*ZZ*ABCDEFGHIJKLMNO*ZZ*123456789012345*101127*1719*U*00401*000003438*0*P*>
GS*PO*4405197800*999999999*20101127*1719*1421*X*004010VICS
ST*850*000000010
BEG*00*SA*08292233294**20101127*610385385
REF*DP*038
REF*PS*R
ITD*14*3*2**45**46
DTM*002*20101214
PKG*F*68***PALLETIZE SHIPMENT
PKG*F*66***REGULAR
TD5*A*92*P3**SEE XYZ RETAIL ROUTING GUIDE
N1*ST*XYZ RETAIL*9*0003947268292
N3*31875 SOLON RD
N4*SOLON*OH*44139
PO1*1*120*EA*9.25*TE*CB*065322-117*PR*RO*VN*AB3542
PID*F****SMALL WIDGET
PO4*4*4*EA*PLT94**3*LR*15*CT
PO1*2*220*EA*13.79*TE*CB*066850-116*PR*RO*VN*RD5322
PID*F****MEDIUM WIDGET
PO4*2*2*EA
PO1*3*126*EA*10.99*TE*CB*060733-110*PR*RO*VN*XY5266
PID*F****LARGE WIDGET
PO4*6*1*EA*PLT94**3*LR*12*CT
PO1*4*76*EA*4.35*TE*CB*065308-116*PR*RO*VN*VX2332
PID*F****NANO WIDGET
PO4*4*4*EA*PLT94**6*LR*19*CT
PO1*5*72*EA*7.5*TE*CB*065374-118*PR*RO*VN*RV0524
PID*F****BLUE WIDGET
PO4*4*4*EA
PO1*6*696*EA*9.55*TE*CB*067504-118*PR*RO*VN*DX1875
PID*F****ORANGE WIDGET
PO4*6*6*EA*PLT94**3*LR*10*CT
CTT*6
AMT*1*13045.94
SE*33*000000010
GE*1*1421
IEA*1*000003438
This is the integration flow for which the MDN Attachment need to be sent as we have selected asynchronous Communication.
- In the Connection tab specify a path for the as2 endpoint.
- Select the Authorization to be UserRole/Client_Certificate[In my case I selected User Role]
- You need to send the PFX file to the SENDER ADAPTER iflow tenant because you will be receiving the response asynchronously from the sender adapter.
Monitoring the Artifacts in Trace Mode
Creation of PFX Certificate
Creation of PFX Certificate contains these below steps:
- Go to the Integration flow instance [DEV]
- Create a certificate in the Instance.
3. After creating Certificate (From the Form tab) Copy the Certificate and Align them as shown in image and save the file as <filename>.cert
4. Copy the Key, align as shown in image, save the file as <filename>.key
5. Now use this website (or any other online websites for pfx generation)https://www.sslshopper.com/ssl-converter.html
- Upload the cert file and key file in this website with the proper pfx password (remember the password)
- Click on Create and download PFX file.
Stay tuned for the next part, where we’ll get started with API proxies!