EDI Mail In Processing in SAP Cloud Integration

Part 2 of 3 — EDI Mail-In Series

Back to Part 1 — Entry Layer

Once the entry point for EDI Mail-In is in place, the next architectural question is obvious: how should the actual processing be structured?

One option would be to build a single large iFlow. In practice, this quickly becomes difficult to maintain, monitor, and troubleshoot.

Why modular?

A modular flow design provides:

• clear responsibility per iFlow
• better operational visibility
• lower coupling

The solution behaves like a processing pipeline rather than a monolithic flow.

The processing chain

The architecture consists of multiple stages:

• inbound validation
• attachment handling
• normalization
• routing
• downstream processing

Attachment-centric processing

Attachments are processed individually because they represent the actual business content.

Supported file types include:

• .edi
• .txt
• .csv
• .zip
• .xls
• .xlsx

ZIP files are unpacked.
Excel files are converted using custom logic based on Groovy scripts and Apache POI.

File classification

After preprocessing, files are classified into:

• EDI
• non-EDI

This separation allows different downstream processing paths.

Why JMS matters

JMS enables asynchronous handover between processing stages:

• reduced coupling
• better buffering
• improved resilience

It is not just a transport mechanism, but a key architectural decision shaping runtime behavior.

Conclusion

This solution works because it does not try to do everything in one place.

Instead, it breaks processing into clear stages:

• validation
• normalization
• routing
• handover

This results in better maintainability, traceability, and scalability.

Next: Part 3 — Lessons Learned