How to Choose an SAP Integration Pattern: A Decision Framework

Knowing what the available SAP integration patterns are is one thing. Knowing which one is right for a specific scenario is another.

Most integration architecture problems don't come from ignorance of the options, but from applying a familiar or convenient option to a situation it wasn't designed for.

This post provides a structured framework for making that decision deliberately. It covers five questions that, when worked through in order, eliminate most of the wrong options before a tool comparison or configuration decision is ever reached. It also includes a pattern comparison table for quick reference and an overview of SAP's Integration Solution Advisory Methodology (ISA-M) for organizations working at the landscape level rather than the individual scenario level.

This is the third post in a series on SAP integration patterns. The first covers what integration patterns are and why the choice carries downstream consequences. The second catalogs the range of patterns available in SAP landscapes today. If you are already familiar with the pattern options and are ready to evaluate them against a specific scenario, this is where to start.

A Decision Framework for Pattern Selection

No integration decision exists in isolation. The patterns covered earlier each have legitimate use cases, and most of them have scenarios where they are clearly the wrong choice. What makes the difference is not familiarity with the options but a structured way of evaluating them against the specific scenario at hand. The following framework does not replace architectural judgment but rather organizes it. Work through these five questions in order before evaluating any specific pattern or tool.

5 Questions to Ask Before Choosing a Pattern

1. What is the trigger? The nature of the trigger is the most fundamental characteristic of an integration scenario, and it maps directly to the process/data divide. A business event points toward process integration patterns. A schedule points toward data integration patterns. A user action in a UI points toward synchronous, request/reply API-based integration. A data change detected at the database level points toward CDS-based extraction or event-driven patterns. Getting this answer wrong cascades into every subsequent decision.
2. What is the data volume and frequency? A single transactional record exchanged in real time has completely different infrastructure requirements than a million records extracted nightly or a continuous stream of IoT events. High-volume, infrequent batch scenarios favor data replication patterns with full or delta extraction. Low-volume, high-frequency transactional scenarios favor API-based or message-based patterns. Continuous high-volume streams favor event-driven architecture with a broker like SAP Event Mesh. Applying a pattern designed for one volume profile to a scenario with a different one is one of the more reliable ways to produce an integration that works in development and fails in production.
3. What are the latency requirements? This is where the synchronous/asynchronous timing dimension enters the decision. If the sending system needs an immediate response, the integration must be synchronous, and the pattern must support that. If the sender can fire a message and continue without waiting for acknowledgment, asynchronous patterns become available and often preferable, since they reduce coupling and improve resilience. The mistake to avoid is assuming that asynchronous is always more scalable and therefore always better. In scenarios with genuine real-time confirmation requirements, an asynchronous pattern doesn't scale better—it fails differently.
4. What is your deployment model? The deployment model is not just a technical context. It actively constrains which patterns are available. SAP Cloud ERP eliminates IDoc-based integration entirely. On-premise environments support the full pattern range but carry the additional consideration of SAP Process Orchestration's approaching end of maintenance deadline. Hybrid landscapes require composite pattern thinking, since the on-premise and cloud sides of the same integration may need different approaches connected through a translation layer. This question should be answered before pattern evaluation begins, not discovered during implementation.
5. Who owns the receiving system? The ownership and nature of the target system carries direct protocol implications. SAP-to-SAP integration within a managed landscape opens the full range of native SAP integration options. SAP-to-third-party integration typically requires OData or REST, since third-party systems do not speak IDoc or RFC. SAP-to-external-partner integration (suppliers, customers, logistics providers) often involves EDI standards and B2B protocols, which is where the Integration Advisor and Trading Partner Management capabilities of SAP Integration Suite become relevant. Assuming that what works for internal SAP-to-SAP integration will transfer directly to external partner integration is a common and avoidable scoping mistake.

The Role of ISA-M

The Integration Solution Advisory Methodology (ISA-M) is SAP's framework for helping enterprise and integration architects define and implement integration strategies. Where the five questions in the previous section help evaluate an individual integration scenario, ISA-M operates at the landscape level—providing a structured way to map the full range of integration requirements across an organization to the appropriate technologies.

The practical core of ISA-M for pattern selection is its technology mapping approach. It classifies integration requirements across three dimensions: integration domains (on-premise-to-on-premise, on-premise-to-cloud, cloud-to-cloud, B2B, user-facing, and IoT), integration styles (process integration, data integration, and others), and use cases within those styles. Working through these dimensions systematically produces a technology mapping that aligns each domain with both a current-state technology and a target-state recommendation. For most integration domains, Cloud Integration is the forward-looking recommendation, with SAP Process Orchestration reserved for existing implementations being maintained or adapted rather than net-new development.

ISA-M also provides architecture blueprints; these are reference architectures introduced in version 3.3 that translate the technology mapping into concrete implementation guidance. These are particularly useful for organizations building or refreshing an integration strategy, since they provide a starting point that can be extended with landscape-specific selection recommendations rather than requiring teams to derive architecture from first principles.

One practical note: ISA-M's full technology mapping can be more complex than day-to-day integration work requires. For individual pattern decisions, the five-question framework earlier is the right tool. ISA-M is most valuable when the question is not "which pattern fits this scenario" but "how do we govern integration decisions consistently across the entire landscape."

Conclusion

Choosing an SAP integration pattern is not primarily a technical decision. It is an architectural one, and like all architectural decisions, its consequences are felt long after the initial choice is made. The patterns themselves are not complicated. What is complicated is the discipline of applying them correctly: starting with the business requirement rather than the familiar tool, distinguishing process integration from data integration before anything else, and treating the deployment model as a constraint rather than an afterthought.

The framework discussed in this series will not make the decision for you. What it will do is ensure the decision is made deliberately, with the right variables on the table, before implementation begins. That is where most integration architecture goes wrong: not in the execution, but in the assumptions that were never examined because the team moved to tools before they had finished thinking about the problem.

The fourth post in this series covers deployment model constraints in detail. How public cloud, private cloud, on-premise, and hybrid environments each shape which patterns are available and what mistakes to avoid in each context.

 This post was originally published 5/2026.