Clean-core extension strategies for SAP supply chain

Warehouse and supply chain landscapes tend to accumulate custom logic faster than other SAP modules, because operational reality — a specific automation interface, a customer-specific packing rule, a non-standard putaway strategy — rarely matches standard configuration exactly. Left unmanaged, that custom logic embeds itself in core objects and becomes the primary source of upgrade risk.

EWM in particular sits close to physical operations: automation interfaces, RF transactions and exception handling are exactly the kind of logic that gets extended under time pressure, directly in standard objects, when a project is racing toward go-live. That is precisely the debt that makes the next S/4HANA upgrade or EWM release update expensive and risky.

Clean core is the discipline of keeping that necessary customization out of standard objects and behind defined extension points, so upgrades touch configuration and extensions with known interfaces rather than modified core code with unpredictable side effects.

Side-by-side extensions run on SAP BTP, outside the ERP or EWM system itself, communicating through released APIs. The SAP Cloud Application Programming Model (CAP) and RESTful ABAP Programming Model (RAP) are the two standard toolsets for building this logic — CAP for BTP-native services, RAP where ABAP development is warranted, exposed through OData or REST.

This model fits functionality that doesn't need to run inside the EWM or S/4HANA process itself: reporting layers, exception investigation tooling, integration orchestration, or entire microservices that consume EWM data without needing to be deployed alongside it. It keeps the core system's upgrade path completely clear of that logic.

The trade-off is architectural complexity and latency — side-by-side extensions depend on API availability and network round-trips, which makes them a poor fit for logic that needs to execute synchronously inside a warehouse task confirmation or a tight RF transaction loop.

In-app extensibility uses released extension points — key-user extensibility tools, released BAdIs, CDS view extensions and released APIs — inside the S/4HANA or EWM system itself. It's the right choice for logic that genuinely needs to run in-process: custom fields, field validations, determination logic inside a warehouse task creation flow, or a released BAdI implementation for a specific EWM process step.

The discipline that matters is restraint: using only released, upgrade-stable extension points, and treating any object not marked as released or key-user-extensible as off-limits regardless of how convenient a direct modification would be. SAP's extensibility guidelines exist specifically to mark which objects are safe to extend without breaking future upgrades.

The practical test is where the logic needs to execute and how tightly it's coupled to the transaction it supports. Logic inside a warehouse task confirmation, a synchronous RF screen exit, or anything with hard latency requirements belongs in-app, through a released extension point. Logic that can run asynchronously, that serves multiple systems, or that benefits from independent deployment cycles belongs side-by-side on BTP.

In most EWM and S/4HANA supply chain landscapes, the answer is both, applied deliberately rather than by default — in-app extensibility for tightly coupled process logic, side-by-side extensions for orchestration, reporting and cross-system functionality, with clean-core governance defining which is which before development starts, not after.