Foundations of Enterprise Integration Patterns in SAP Landscapes
Introduces the core integration pattern categories relevant to SAP landscapes and why choosing the right pattern early prevents costly rework later.
Explanation
Enterprise Integration Patterns (EIPs) are reusable architectural solutions for connecting systems that need to exchange data or trigger processes. In SAP environments, integration is rarely optional: a typical landscape includes ECC or S/4HANA as the core ERP, satellite systems for warehouse, transportation or CRM functions, BTP-based extensions, and third-party or legacy systems. Each connection between these systems must be designed deliberately, because integration decisions affect performance, data consistency, operational cost and long-term maintainability far more than most functional configuration choices. At a beginner level, it is important to understand the broad families of patterns before diving into implementation. First is point-to-point integration, where two systems talk directly to each other, typically via RFC, IDoc, file transfer or a direct API call. This is simple to build initially but scales poorly: as the number of systems grows, the number of direct connections grows quadratically, making the landscape brittle and hard to change. Second is hub-based or mediated integration, where a middleware layer (such as SAP Process Orchestration in on-premise landscapes, or SAP Integration Suite on BTP) sits between systems, handling routing, transformation and protocol mediation. This reduces the number of direct dependencies and centralizes monitoring and error handling, at the cost of an additional component to operate and secure. A second dimension is synchronous versus asynchronous communication. Synchronous calls (like RFC or OData in request-response mode) are simple to reason about but couple the availability and performance of both systems tightly together: if the receiving system is slow or down, the calling process blocks or fails immediately. Asynchronous patterns (message queues, IDocs, event-based publishing) decouple systems in time, allowing the receiver to process messages when ready, and providing natural resilience against short outages, but they introduce complexity in guaranteeing delivery, ordering and idempotency. A third foundational concept is the difference between data integration (moving master or transactional data, e.g. material master replication) and process integration (triggering a business process step in another system, e.g. creating a delivery in a warehouse system). Data integration patterns often favor batch or event-driven replication, while process integration patterns often require closer to real-time, transactional guarantees. In SAP's clean core strategy, integration is increasingly expected to happen through released, stable interfaces (APIs, events) rather than direct table access or custom RFC function modules, especially in S/4HANA Cloud public edition where such access is not available at all. This has direct architectural consequences: extensions and integrations built against ECC-era techniques (direct table reads, custom BAPIs) will not migrate cleanly to S/4HANA public cloud, and architects must plan integration patterns with this constraint in mind from the outset, even in on-premise projects that may migrate later. Understanding these foundational categories equips an architect to ask the right early questions on any integration requirement: does this need to be synchronous or can it tolerate delay, does it need a middleware hub or can it be direct, and is this data or process integration. These questions set the stage for the more detailed trade-off analysis covered in subsequent lessons.
Real project scenario
During a project scoping workshop for a retail company running ECC with plans to move to S/4HANA Private Cloud, the integration team initially proposed direct RFC connections from ECC to five new e-commerce microservices. After mapping out the pattern categories, the architect flagged that five point-to-point RFC connections would become fifteen to twenty connections once the microservices count grew, and none of them offered retry or dead-letter handling. The team pivoted to an event-based pattern via a middleware hub, which reduced the direct dependency count and gave them a single place to monitor failures across all five integrations.
Common mistakes
• Choosing point-to-point integration by default without considering how many systems will eventually need to connect. • Treating synchronous RFC or OData calls as a substitute for proper decoupled event patterns for high-volume or unreliable connections. • Assuming integration patterns validated on ECC will transfer unchanged to S/4HANA Cloud public edition without checking API and extensibility constraints. • Not distinguishing between data replication needs and process orchestration needs, leading to overly complex single-pattern designs. • Underestimating the operational burden of a middleware hub when only two or three systems are actually involved.
Best practices
• Map out expected system count and growth before choosing point-to-point versus hub-based patterns. • Separate data integration requirements from process integration requirements early in design. • Validate any integration approach against clean core and target deployment constraints (ECC, on-premise, private cloud, public cloud) before implementation. • Document the chosen pattern rationale so future architects understand why a given integration was built a certain way. • Prefer asynchronous, decoupled patterns for high-volume or cross-system-boundary integrations unless a hard real-time requirement exists.
Interview angle
Interviewers at architect level often ask candidates to justify why they chose point-to-point versus hub-based integration for a described scenario. Strong answers reference the number of systems involved, growth expectations, need for centralized monitoring, and whether clean core or public cloud constraints apply, rather than giving a generic 'always use middleware' answer.