SAP Integration Done Right: OData, IDocs, and the Middleware Question

The Integration Challenge

Every advanced planning system (APS) needs to talk to SAP. Orders come from SAP. Material availability comes from SAP. Production confirmations go back to SAP. The quality of this integration determines whether your APS becomes a productivity multiplier or an expensive headache.

After implementing 20+ SAP integrations across manufacturing companies, we have learned what works—and what does not.

Three Integration Approaches

Approach 1: Middleware Platforms

Tools like SAP PI/PO, MuleSoft, or Boomi sit between your APS and SAP. They transform data formats, handle errors, and provide monitoring.

Pros:

• Centralized integration management
• Built-in error handling and retry logic
• Good for complex enterprise landscapes

Cons:

• Significant licensing costs (50,000-200,000 EUR annually)
• Requires dedicated integration expertise
• Adds latency and failure points
• Often overkill for point-to-point APS integration

Approach 2: Direct IDoc Interface

IDocs (Intermediate Documents) are SAP's native messaging format. Your APS sends and receives IDocs directly through RFC connections.

Pros:

• No middleware licensing
• Native SAP format with guaranteed consistency
• Transaction-safe with automatic retry
• Well-suited for production confirmations and order updates

Cons:

• Complex initial setup
• Requires SAP Basis expertise
• Batch-oriented rather than real-time
• Limited flexibility for custom data structures

Approach 3: OData Services

SAP's REST-based API layer provides modern web service access to SAP data.

Pros:

• Real-time data access
• Standard REST protocols (any developer can work with it)
• Flexible querying and filtering
• Good for master data and read operations

Cons:

• Performance limitations for large data volumes
• Not transaction-safe like IDocs
• May require custom service development for complex scenarios

Our Recommended Architecture

Based on experience, here is what works:

Master Data (Materials, BOMs, Work Centers): OData

• Pull on schedule (daily or on-demand)
• Leverage standard SAP OData services
• Cache locally in APS for performance

Production Orders and Demand: OData or RFC

• Near-real-time pull when planning runs
• Use delta queries to minimize data transfer

Schedule Publication: Custom RFC

• Push optimized operation dates back to SAP
• Update routing operation scheduled start/end times

Production Confirmations: IDocs (LOIPRO/AFKO)

• Transaction-safe write-back of completions
• Automatic retry on failure
• Native SAP process integration

This hybrid approach uses each technology where it excels.

Common Mistakes

Mistake 1: Over-engineering with Middleware

A 50-person job shop does not need MuleSoft. Direct OData + IDoc integration costs a fraction and performs better for straightforward scenarios.

Mistake 2: Real-Time Everything

Not all data needs real-time sync. Material master changes once a month. Work center data changes quarterly. Poll these on schedule and save your integration bandwidth for what matters: orders and confirmations.

Mistake 3: Ignoring Error Handling

What happens when an IDoc fails? When SAP is down during your planning run? Robust integration requires explicit failure modes: retry logic, error queues, alerting, and manual recovery procedures.

Mistake 4: Insufficient Testing

SAP integration must handle edge cases: orders with missing master data, confirmations for already-closed orders, partial updates during planning runs. Test these scenarios before go-live.

Performance Benchmarks

From our implementations:

These numbers assume proper indexing and optimized queries. Naive implementations can be 10x slower.

Security Considerations

SAP integration requires careful security design:

• Service accounts with minimum necessary authorizations
• Encrypted connections (TLS 1.2+) for all communication
• API rate limiting to prevent runaway queries
• Audit logging of all SAP transactions initiated by APS

Your SAP security team will (rightly) scrutinize any external system connecting to SAP. Be prepared with a clear security architecture document.

Conclusion

SAP integration is not a solved problem—it requires thoughtful architecture for each situation. But it also does not require expensive middleware in most cases. OData for reading, IDocs for writing, and clear error handling will serve most manufacturing APS integrations well.

The goal is invisible integration: data flows reliably between systems without anyone thinking about it. That requires upfront investment in architecture, but the payoff is an APS that actually delivers on its promise.