SAP Commerce Cloud Architecture: Components and How They Connect

Every architecture decision in Commerce Cloud is a trade-off. Customise too aggressively and you’re buried in upgrade debt. Stay too close to standard and you can’t differentiate. The trick is knowing where the layers meet and what each one actually does. I’ve seen teams burn months because they didn’t understand this upfront.

Let me walk through how the pieces connect.

TL;DR: SAP Commerce Cloud architecture consists of five layers: Platform (type system, persistence, Spring framework), Commerce Modules (cart, checkout, pricing, fulfilment), Product Content Management, OCC REST APIs, and the Composable Storefront. Gartner recognises SAP as a Leader in Digital Commerce (Gartner, 2024). The architecture’s strength is extensibility without forking — you add new types and override services without modifying core code.

What Are the Core Architecture Layers?

Gartner recognises SAP as a Leader in the Magic Quadrant for Digital Commerce (Gartner, 2024). That position reflects an architecture built for enterprise extensibility. The type system is the foundation. It’s what separates Commerce Cloud from platforms that force you into schema modifications for every customisation.

Platform layer

This is the bedrock. Everything else sits on top of it.

• Type system: a declarative data model where you define item types, attributes, and relationships in XML. Extensions add new types without touching existing ones. This is the single most important concept in the whole architecture. Learn it first.
• Persistence: the Platform translates type definitions into database tables and handles ORM. You work with items, not SQL.
• Spring framework: Commerce Cloud uses Spring IoC throughout. Services are beans you can override, extend, or replace through dependency injection.
• Extension mechanism: all functionality ships as extensions. You build your own to add custom logic, keeping your code cleanly separated from SAP’s.

Commerce modules

The business logic layer:

• Cart and checkout: cart management, delivery modes, payment integration, order placement
• Pricing: promotion engine, tax calculation, currency conversion, B2B contract pricing
• Order management: order lifecycle, fulfilment, returns, refunds
• Customer management: account registration, address management, B2B organisation hierarchies
• Search: Solr-based product search with faceted navigation, boosting rules, synonym management

Product content management (PCM)

Built-in PIM capabilities. Product hierarchies, classification systems, multi-dimensional variants, media management, catalogue versioning. It’s solid enough that many clients skip a separate PIM system entirely. We’ve run into situations where teams bought an external PIM before even looking at what PCM could do. Bit of a waste.

OCC APIs (Omni Commerce Connect)

RESTful APIs that expose all commerce functionality to external consumers. The Composable Storefront, mobile apps, kiosks, third-party systems. OCC is the decoupling layer that makes headless commerce possible.

Composable Storefront

The Angular-based headless frontend (used to be called Spartacus). It consumes OCC APIs and renders everything customers see. CMS-driven page composition means your marketing team can change layouts without filing developer tickets. That alone is worth the architecture.

How Does the Extension Mechanism Work?

If you take one thing away from this post, make it this. Extensions are self-contained modules that add functionality without touching SAP’s core code.

How extensions work:

• You declare custom item types that extend SAP’s type system
• You override Spring beans to replace or extend standard service behaviour
• You add new OCC endpoints or modify existing ones
• Your code lives in your own extensions. SAP’s code stays untouched.

Why this matters: when SAP releases an update, your customisations don’t collide with their changes. You upgrade the platform without re-implementing your custom logic. Teams that bypass this and directly modify core code create massive upgrade debt. We’ve cleaned up a few of those situations and it’s never fun. Never fast either.

Before building a custom extension, check SAP’s extension marketplace and the standard accelerator extensions. Commerce Cloud ships with 200+ extensions covering most common scenarios. No point building what already exists.

How Should You Approach Customisation?

SAP’s clean core strategy recommends minimising modifications to standard code (SAP, 2025). For Commerce Cloud, that translates to a crisp hierarchy:

1. Configuration first: use standard settings and business rules
2. Extension second: use existing SAP extensions or marketplace extensions
3. Custom development third: build your own extensions following SAP’s patterns
4. Core modification never: don’t change SAP’s delivered code

This isn’t theoretical. It directly shapes your total cost of ownership. Every custom extension needs maintenance through upgrades. Every core modification needs re-implementation. The most successful implementations we work on follow something like an 80/20 split: 80% standard, 20% custom extensions for genuine differentiation. De facto, that’s the sweet spot.

For a broader look at what Commerce Cloud delivers, including pricing, industry use cases, and implementation methodology, see our SAP Commerce Cloud solution page.

FAQ

What programming languages does Commerce Cloud use?

The backend runs on Java (Spring framework). The Composable Storefront is Angular/TypeScript. Data modelling uses XML type definitions. Content management uses ImpEx (SAP’s proprietary import/export format). Build tooling runs on Gradle.

How does Commerce Cloud handle scalability?

Commerce Cloud runs on SAP’s managed cloud infrastructure with horizontal scaling. You configure autoscaling policies that add or remove application server nodes based on traffic patterns. The platform handles session management, cache synchronisation, and load balancing across nodes.

What’s the difference between SAP Commerce Cloud and SAP Commerce (on-prem)?

Same codebase, different deployment model. Commerce Cloud runs on SAP’s managed infrastructure with automatic patching, scaling, and monitoring. On-premise Commerce runs on your own infrastructure: full control, but full operational responsibility too. SAP’s End of Mainstream Maintenance makes cloud migration increasingly urgent.

How does the CMS work?

SmartEdit gives content managers a WYSIWYG page editor. Pages are composed of content slots containing CMS components (banners, product carousels, text blocks). The Composable Storefront renders CMS content dynamically. Marketers change pages without developer involvement or deployments. Spot on for marketing agility.

Can I use a non-Angular frontend?

Absolutely. OCC APIs are technology-agnostic REST endpoints. The Composable Storefront (Angular) is SAP’s recommended frontend, but you can build with React, Vue, Next.js, or any framework that calls REST APIs. You lose SAP’s pre-built storefront components, but you gain complete frontend freedom. Your call.