EDI Mail-In Entry Layer in SAP Cloud Integration
Share
Part 1 of 3 — EDI Mail-In Series
In many integration landscapes, inbound business documents are expected through channels such as AS2, SFTP, or API-based delivery. In practice, however, not every partner is able or willing to use those standard transport channels consistently. Some still send structured business data as email attachments.
That was the starting point for designing an EDI Mail-In solution in SAP Cloud Integration.
The important principle
The important point is that the business payload itself does not change. Formats such as ORDERS, SLSRPT, and INVRPT remain what they are.
What changes is only the technical entry path: instead of receiving the payload through a classical B2B transport channel, the system receives it through a central mailbox and then processes it in SAP CI.
Why move this into SAP CI?
The legacy setup was functional, but fragmented:
- more operational handover points
- less transparency when troubleshooting
- higher dependence on legacy components
- slower onboarding of new partners
The SAP CI target design centralizes inbound Mail-In processing.
The business process remains unchanged, but the integration architecture becomes more structured and transparent.
Business context and scope
The solution was originally designed for partners in the fashion and retail domain, where inbound EDI messages such as INVRPT (inventory reports) and SLSRPT (sales reports) are commonly exchanged.
The primary focus was on inbound message processing via email-based delivery. However, the architectural design is not limited to this scenario.
Due to its modular structure, the same approach can be extended to:
- outbound message handling
- additional document types
- non-EDI attachments such as Excel or CSV
This makes the solution adaptable beyond its original use case and applicable to a wider range of integration scenarios.
What makes Mail-In special?
A mail-based inbound scenario is fundamentally different from a typical system-to-system API integration.
With an API, the payload usually arrives in a controlled format. With email, the payload is wrapped in additional technical complexity:
- sender metadata
- subject and mail body
- attachment collection
- MIME structure
- possible ZIP containers
- file types such as Excel, CSV, TXT, or EDI
The key architectural principle is:
The email is the transport envelope.
The attachment is the actual business payload.
The entry point: mailbox to CI
The solution starts with a shared mailbox.
Incoming messages are retrieved via IMAPS using OAuth2 authentication.
Mailbox lifecycle operations such as folder lookup, creation, and message movement are handled separately via Microsoft Graph API.
This separation keeps responsibilities clean:
- IMAP for message intake
- Graph API for mailbox management
Early validation matters
The first processing step performs essential checks:
- sender validation
- attachment presence
- eligibility for processing
Only valid messages proceed further.
This keeps downstream flows clean and efficient.
Lightweight partner onboarding
Partner resolution is handled via SAP CI Value Mapping.
Onboarding a new partner requires only:
- sender email
- partner identifier
This keeps the operational model simple.
Traceability without changing payload
Traceability is achieved through:
- mailbox movement outcomes
- SAP CI monitoring
- custom headers and properties
- staged JMS processing
The payload stays unchanged, but the process becomes fully visible.
Conclusion
Mail-In is not a business format problem.
It is a transport and processing design problem.
Once that is understood, the architecture becomes clear:
the email is just the wrapper — the real challenge is building a stable processing path around the attachment.
SAP CI enables a clean separation between validation, normalization, routing, and handover.
The design is flexible enough to evolve beyond its initial use case and support broader integration scenarios.