3 Patterns for Integrating Camunda with SAP S/4HANA

Camunda and SAP S/4HANA are a powerful combination. Camunda handles process orchestration. SAP handles transactional data. The integration between them is where most implementations either get it right or accumulate technical debt that compounds for years.

There are three patterns worth knowing. Each solves a different problem. Using the wrong one for a given use case is a mistake you'll pay for in maintenance cost and reliability incidents.

Pattern 1: RFC/BAPI (Synchronous Function Calls)

What it is: Camunda calls SAP Remote Function Calls (RFCs) or Business Application Programming Interfaces (BAPIs) directly via a JCo connector or RFC adapter. The Camunda worker calls the function, waits for the response, and advances the process.

When to use it:

• You need an immediate, confirmed result from SAP before the process can continue
• The SAP operation is transactional: create a purchase order, post a goods receipt, confirm a delivery
• The target system is SAP ECC or an S/4HANA system without BTP Event Mesh

What goes wrong: RFC/BAPI integration is synchronous and tightly coupled. If SAP is slow, your Camunda process is slow. If SAP is unavailable, your Camunda process fails. For low-volume, latency-tolerant processes this is fine. For high-volume or latency-sensitive workflows, it becomes a bottleneck.

Also: BAPI interfaces are notoriously inconsistent in error handling. Test every error path — don't assume a failed BAPI returns a clean error code.

Pattern 2: SAP Advanced Event Mesh (Asynchronous Events)

What it is: SAP S/4HANA publishes business events to SAP Advanced Event Mesh (formerly SAP Event Mesh on BTP). Camunda workers subscribe to event topics and start or advance process instances in response to those events.

When to use it:

• You need to react to SAP events without polling: SalesOrder.Created, Invoice.Posted, GoodsMovement.Created
• You are building event-driven, decoupled architecture where SAP and Camunda evolve independently
• You need guaranteed delivery and replay capability for high-volume event streams

What goes wrong: Event-driven integration requires careful idempotency design. Camunda may receive the same event more than once — your process must handle duplicate delivery without creating duplicate business outcomes. Design correlation keys carefully. Also, Event Mesh is a BTP service — if your SAP landscape is fully on-premise, this pattern requires BTP onboarding.

The payoff: This is the cleanest long-term architecture. SAP publishes what happened. Camunda decides what to do about it. No polling. No coupling. Full audit trail on both sides.

Pattern 3: REST/OData APIs

What it is: Camunda workers call SAP S/4HANA OData APIs exposed via the SAP API Business Hub or custom Fiori services. Standard HTTP, standard authentication, standard error codes.

When to use it:

• You are building against S/4HANA (ECC does not expose OData natively)
• The operation maps cleanly to a standard SAP API (business partner read, material read, sales order create)
• You want technology-agnostic integration that isn't locked to JCo or ABAP-specific protocols

What goes wrong: OData APIs in S/4HANA have inconsistent coverage. Core entities are well-covered; custom objects and industry-specific scenarios often require custom OData services or fall back to RFC. Know your coverage before committing to OData-only.

Also: OData batch operations are complex. If your process needs to create multiple SAP objects atomically, test the batch behavior thoroughly.

Choosing the Right Pattern

| Scenario | Recommended Pattern | |---|---| | Create/update SAP object, need confirmation | RFC/BAPI or OData | | React to SAP business events | Event Mesh | | Read SAP master data | OData | | High-volume, fire-and-forget | Event Mesh | | On-premise SAP, no BTP | RFC/BAPI | | S/4HANA Cloud | OData + Event Mesh |

Most production architectures use all three patterns. OData for reads. Event Mesh for triggers. RFC or OData for transactional writes. The orchestration layer in Camunda abstracts the pattern from the business process — the BPMN model doesn't care which integration pattern the worker uses.

Getting Started

Pick the pattern that matches your first process. Don't design a universal integration framework before you've shipped one integration. The patterns reveal their trade-offs in production, not in architecture documents.

Designing a Camunda-SAP integration architecture? Talk to us — we've implemented all three patterns across multiple S/4HANA landscapes and can help you avoid the expensive mistakes.