SAP Commerce Cloud Architecture: Components and How They Connect

Every architectural decision in Commerce Cloud has a cost and a benefit. Customise too much and you create upgrade debt. Rely too heavily on standard features and you can’t differentiate. The architecture is designed to give you that balance — but only if you understand how the layers work together.

This guide breaks down Commerce Cloud’s architecture into its core components and explains how they 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 leadership position reflects an architecture designed for enterprise extensibility. Here are the layers.

Platform layer

The foundation. Commerce Cloud’s Platform provides:

• Type system — a declarative data model where you define item types, attributes, and relationships in XML. Extensions add new types without modifying existing ones. This is the single most important architectural concept — it enables customisation without forking.
• 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 extensively. Services are beans that you can override, extend, or replace through dependency injection.
• Extension mechanism — all functionality ships as extensions. You create your own extensions to add custom logic, keeping your code separate from SAP’s code.

Commerce modules

Business logic for e-commerce operations:

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

Product content management (PCM)

Built-in PIM capabilities: product hierarchies, classification systems, multi-dimensional variants, media management, and catalogue versioning. PCM eliminates the need for a separate PIM system in many scenarios.

OCC APIs (Omni Commerce Connect)

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

Composable Storefront

The Angular-based, headless frontend (formerly Spartacus). It consumes OCC APIs and renders the customer-facing storefront. CMS-driven page composition means marketers can modify layouts without developer involvement.

How Does the Extension Mechanism Work?

This is the most important architectural concept for any Commerce Cloud implementation. Extensions are self-contained modules that add functionality without modifying 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 conflict with their changes. You can upgrade the platform without re-implementing your custom logic. Teams that bypass this mechanism — directly modifying core code — create massive upgrade debt.

Best practice: 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.

How Should You Approach Customisation?

SAP’s clean core strategy recommends minimising modifications to standard code (SAP, 2025). For Commerce Cloud, this translates to a clear customisation 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 — avoid changing SAP’s delivered code

This hierarchy isn’t just theoretical advice. It directly impacts your total cost of ownership. Every custom extension requires maintenance through upgrades. Every core modification requires re-implementation.

For a broader look at what SAP 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 uses Java (Spring framework). The Composable Storefront uses Angular/TypeScript. Data modelling uses XML type definitions. Content management uses ImpEx (SAP’s proprietary import/export format). Build tooling uses 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 with full control but also full operational responsibility. SAP’s End of Mainstream Maintenance makes cloud migration increasingly urgent.

How does the CMS work?

SmartEdit provides a WYSIWYG page editor for content managers. Pages are composed of content slots, which contain CMS components (banners, product carousels, text blocks). The Composable Storefront renders CMS content dynamically — marketers change pages without developer involvement or deployments.

Can I use a non-Angular frontend?

Yes. OCC APIs are technology-agnostic REST endpoints. While the Composable Storefront (Angular) is SAP’s recommended frontend, you can build with React, Vue, Next.js, or any framework that consumes REST APIs. You lose SAP’s pre-built storefront components but gain full frontend flexibility.