SAP and Oracle systems sit at the center of most large enterprise architectures in Europe. They are the systems of record for finance, HR, procurement, logistics, and manufacturing. Everything else — analytics platforms, customer portals, mobile applications, third-party services — needs data from or needs to write data into these systems. The integration pattern matters as much as the technology, and the pattern choice made in year one determines the maintenance burden for the next decade.
Three Integration Patterns: Trade-offs That Matter
Enterprise integration literature describes dozens of patterns. In practice, three dominate SAP and Oracle integration projects:
Point-to-Point Integration
Direct connections between source and target systems — SAP RFC calls from a custom application, direct Oracle DB connections, JDBC to an EBS table. Point-to-point is fast to implement and appropriate when integration scope is genuinely small and stable (one source, one target, infrequent change). It becomes a liability the moment you add a third system: you now have three connections to maintain, three places where credentials are stored, and no central monitoring of data flows.
Enterprise Service Bus (ESB)
An ESB — MuleSoft, IBM Integration Bus, WSO2 — introduces a central mediation layer that transforms, routes, and monitors all inter-system messages. ESBs are the right pattern when: message transformation is complex, multiple systems consume the same data feed, or regulatory compliance requires a single point of audit for all data flows. The cost is architectural complexity and the need for specialized ESB skills.
API Gateway Pattern
The API Gateway pattern exposes SAP and Oracle capabilities as managed REST or GraphQL APIs, with the gateway handling authentication, rate limiting, versioning, and observability. This is the pattern we recommend for new projects targeting DACH enterprise clients. It aligns with API-first design principles, scales to external developer consumption, and integrates naturally with modern cloud-native architectures.
Our recommendation: start with the API Gateway pattern for new integrations, use ESB when you have a complex existing landscape with many-to-many data flows, and avoid point-to-point for anything beyond a three-system perimeter.
SAP Integration: RFC, BAPI, and IDocs
SAP exposes three primary integration interfaces. RFC (Remote Function Call) and BAPI (Business Application Programming Interface) are synchronous interfaces suited for real-time lookups and transactional operations — checking stock levels, creating sales orders, posting financial documents. We implement RFC/BAPI integrations using the SAP Java Connector (JCo) or the SAP .NET Connector, wrapped in a service layer that handles connection pooling, retry logic, and structured error mapping.
IDocs (Intermediate Documents) are SAP's asynchronous document format for high-volume business document exchange — purchase orders, invoices, delivery notes. IDoc-based integrations are reliable and high-throughput but require careful monitoring: a failed IDoc is not always immediately visible, and reprocessing logic must be designed from the start.
Oracle EBS Integration via REST APIs
Oracle E-Business Suite (EBS) has evolved significantly in its REST API surface. Modern EBS versions expose REST APIs for core business objects — customers, orders, invoices, inventory — through Oracle Integration Cloud (OIC) or directly via EBS Integrated SOA Gateway. For legacy EBS deployments without REST coverage, we use Oracle database views and scheduled extracts as a pragmatic intermediate step, with clear migration path documentation toward REST when the client upgrades.
Message Queue Patterns and Error Handling
Enterprise integration fails silently if you let it. Every integration pattern we implement includes: dead letter queues for failed messages (RabbitMQ, Azure Service Bus, or AWS SQS depending on client infrastructure), structured error logging with enough context to reproduce and replay, idempotency keys on write operations to prevent duplicate processing, and alerting that pages the on-call engineer within 5 minutes of a message accumulating in the dead letter queue.
Our Middleware Reference Architecture
A proven reference architecture for enterprise integration converges on: an API gateway (Kong or Azure API Management) as the public-facing contract layer, an internal event bus (Kafka for high-throughput, Azure Service Bus for Microsoft-stack clients) for asynchronous flows, adapter services per system (SAP adapter, Oracle adapter) that encapsulate system-specific complexity, and a central observability stack (Prometheus, Grafana, distributed tracing via Jaeger or Tempo). The adapters are the only components that know about SAP or Oracle internals — everything above talks REST and CloudEvents.
Want to learn more about this topic?
First consultation is free — no strings attached.