[[{“value”:”

Introduction

As commerce landscapes evolve toward composability, frontend architectures must deliver speed, modularity, resilience, and seamless integration with enterprise ecosystems.
SAP Composable Storefront, built on Angular and powered by OCC APIs, offers a modern, headless, and flexible foundation for B2B/B2C experiences — but building it for production requires deliberate architectural choices and strong engineering discipline.

In this blog, I provide a practical and deeply technical blueprint for designing, implementing, and running a production-ready SAP Composable Storefront application. Whether you’re an architect, senior engineer, or SAP Commerce integrator, these guidelines will help you scale efficiently, avoid common pitfalls, and achieve high performance on the edge.

1. Architectural Overview

SAP Composable Storefront is essentially an Angular application composed from Spartacus libraries with custom modules layered on top. It communicates with SAP Commerce Cloud via:

• OCC REST APIs (product, cart, checkout, CMS)

• Third-party services (identity, search, payments, analytics)

• Edge/CDN layers (for caching & performance)

High-Level Flow

1. User request hits the CDN. If an SSR HTML page is cached → return instantly.

2. If not cached, request is forwarded to the SSR Node server pool.

3. Once delivered, the Angular client hydrates and fetches additional data from Commerce APIs.

4. Connectors, adapters, and interceptors handle mapping, authentication, and context (site/catalog/currency).

Design Goals

• Modular, maintainable features

• Clean separation of concerns

• Efficient API mapping & error handling

• Strong observability and operational readiness

• High performance on edge delivery

2. Project Setup & Recommended Foundation

A solid foundation begins with the right scaffolding. The recommended project initialization:

ng new my-storefront –routing –style=scss
cd my-storefront
ng add /schematics –ssr

After running Spartacus schematics:

• Configure environment.ts with occBaseUrl, site, and API prefix

• Validate Commerce Cloud compatibility matrix

• Choose feature libraries (B2B, Wishlists, CDS, CDC, etc.)

• Establish a multi-env config strategy: dev / staging / prod / SSR / preview

3. Folder Structure & Module Strategy

A clean folder structure is critical for scalability in large storefront implementations.

src/
app/
core/ → interceptors, guards, root services
shared/ → UI components, directives, pipes
features/ → cart, product, checkout, account, etc.
config/ → all Spartacus + application configs
styles/ → SCSS tokens, global mixins, theming
server/ → Angular Universal SSR code
assets/ → images, i18n, icons

Core Principles

• CoreModule contains all singletons.

• SharedModule contains pure components, no business logic.

• Feature Modules are route-based and lazily loaded.

• Config Modules centralize Spartacus and custom configurations.

This organization prevents module bloat and ensures low coupling.

4. Theming, Styling & Asset Strategy

• Use SCSS with centralized variables/tokens (_tokens.scss)

• Prefer BEM methodology for predictable styling

• Keep global styles minimal

• Host large asset bundles on a CDN in production

• Use WebP and responsive image sets for performance

• Avoid overriding Spartacus styles excessively — extend, don’t fork

5. Data Flow: Connectors, Adapters & Mappers

SAP Composable Storefront’s architecture encourages clean data handling:

Best Practices

• Keep raw OCC models in adapters

• Map OCC → UI-friendly models in dedicated mappers

• Use HTTP interceptors for:

  • Auth token injection

  • Site/tenant context headers

  • Request correlation IDs

• Keep services thin; let adapters handle network concerns

• Implement custom endpoints using Spartacus’ OccConfig extension approach

This ensures maintainability through upgrades and avoids code duplication.

6. State Management & RxJS Best Practices

Spartacus already ships with internal NgRx stores; custom state can extend it cleanly.

Guidelines

• Prefer async pipes instead of manual subscription/unsubscription

• Use OnPush change detection for all components

• Apply correct RxJS operators:

  • switchMap → dependent API calls

  • exhaustMap → checkout flow steps

  • combineLatest → merged UI streams

• Keep state local wherever possible — global store only when necessary

7. Server-Side Rendering (SSR) & Pre-Rendering

SSR is essential for SEO and for first-load performance of SAP storefronts.

Key SSR Considerations

• Leverage Angular Universal for rendering

• Pre-render static routes (homepage, category pages)

• Implement fast fallback for SSR server failures

• Always guard DOM access using:

if (isPlatformBrowser(this.platformId)) {
// browser-only logic
}

Scaling SSR

• Deploy SSR nodes behind a load balancer

• Use horizontal autoscaling based on CPU/memory

• Cache SSR HTML aggressively at the CDN

8. Performance, Caching & CDN Strategy

Recommendations

• Use long cache TTLs with content-hashed asset filenames

• Enable API-level caching for read-only endpoints (CMS, product, categories)

• Implement lazy loading & route-based code splitting

• Consider image optimization and responsive formats

• Cache SSR output at CDN for key pages

• Monitor TTFB and Core Web Vitals continuously

This significantly reduces backend loads and improves Lighthouse scores.

9. Security Considerations

• Enforce HTTPS everywhere

• Apply Content Security Policy (CSP) headers

• Use HttpOnly cookies for tokens when possible

• Sanitize CMS-driven HTML

• Rate-limit OCC endpoints at the gateway layer

• Avoid leaking internal config via environment files

Security must be treated as a continuous practice, not a one-time setup.

10. Testing Strategy

Layers of Testing

• Unit tests → Services, components, mappers

• Integration tests → Using Cypress or Playwright

• Visual regression tests → Percy or Playwright snapshots

• Contract tests → Pact against OCC

• API mocks for local development

A mature storefront requires confidence across all layers.

11. CI/CD & Deployment Patterns

A modern pipeline should include:

1. Linting

2. Unit tests

3. Build (client + server bundles)

4. Integration/E2E tests

5. Deploy to staging

6. Canary/Blue-Green deployment

7. Final production release

Infrastructure Guidance

• SSR Nodes deployed in Kubernetes

• Zero-downtime rolling updates

• Automatic CDN cache invalidation on release

• Tight integration with observability stack

12. Monitoring & Operational Runbook

Monitoring Stack

• Error tracking (Sentry / Dynatrace / Kibana)

• Node SSR logs with correlation IDs

• Alerts for:

  • Memory pressure

  • 5xx spikes

  • Slow OCC endpoints

  • CDN cache miss patterns

Runbook Should Include

• How to disable SSR in emergencies

• Cache purge strategy

• Rollback instructions

• Recovering from Commerce outages

This ensures stable operations even under stress.

13. Extensibility, Upgrades & Governance

To keep the storefront healthy long-term:

• Never fork Spartacus libraries

• Maintain compatibility matrix with Commerce & Spartacus versions

• Use linting + Angular style guide

• Treat every new feature as an isolated module

• Have a structured upgrade plan for both Angular & Spartacus versions

Good governance reduces technical debt dramatically.

Conclusion

Building a production-ready SAP Composable Storefront requires more than installing Spartacus libraries — it demands a carefully crafted architecture, operational excellence, and adherence to enterprise-grade engineering standards.

By following the patterns outlined above, teams can deliver storefronts that are:

• Performant

• Composable

• Upgrade-friendly

• Highly maintainable

• Secure

• Ready for enterprise scale

This blueprint aligns with SAP’s recommended best practices and equips teams to deliver future-proof digital commerce experiences.

“}]] 

 [[{“value”:”IntroductionAs commerce landscapes evolve toward composability, frontend architectures must deliver speed, modularity, resilience, and seamless integration with enterprise ecosystems.SAP Composable Storefront, built on Angular and powered by OCC APIs, offers a modern, headless, and flexible foundation for B2B/B2C experiences — but building it for production requires deliberate architectural choices and strong engineering discipline.In this blog, I provide a practical and deeply technical blueprint for designing, implementing, and running a production-ready SAP Composable Storefront application. Whether you’re an architect, senior engineer, or SAP Commerce integrator, these guidelines will help you scale efficiently, avoid common pitfalls, and achieve high performance on the edge.1. Architectural OverviewSAP Composable Storefront is essentially an Angular application composed from Spartacus libraries with custom modules layered on top. It communicates with SAP Commerce Cloud via:OCC REST APIs (product, cart, checkout, CMS)Third-party services (identity, search, payments, analytics)Edge/CDN layers (for caching & performance)High-Level FlowUser request hits the CDN. If an SSR HTML page is cached → return instantly.If not cached, request is forwarded to the SSR Node server pool.Once delivered, the Angular client hydrates and fetches additional data from Commerce APIs.Connectors, adapters, and interceptors handle mapping, authentication, and context (site/catalog/currency).Design GoalsModular, maintainable featuresClean separation of concernsEfficient API mapping & error handlingStrong observability and operational readinessHigh performance on edge delivery2. Project Setup & Recommended FoundationA solid foundation begins with the right scaffolding. The recommended project initialization:ng new my-storefront –routing –style=scss
cd my-storefront
ng add /schematics –ssrAfter running Spartacus schematics:Configure environment.ts with occBaseUrl, site, and API prefixValidate Commerce Cloud compatibility matrixChoose feature libraries (B2B, Wishlists, CDS, CDC, etc.)Establish a multi-env config strategy: dev / staging / prod / SSR / preview3. Folder Structure & Module StrategyA clean folder structure is critical for scalability in large storefront implementations.src/
app/
core/ → interceptors, guards, root services
shared/ → UI components, directives, pipes
features/ → cart, product, checkout, account, etc.
config/ → all Spartacus + application configs
styles/ → SCSS tokens, global mixins, theming
server/ → Angular Universal SSR code
assets/ → images, i18n, iconsCore PrinciplesCoreModule contains all singletons.SharedModule contains pure components, no business logic.Feature Modules are route-based and lazily loaded.Config Modules centralize Spartacus and custom configurations.This organization prevents module bloat and ensures low coupling.4. Theming, Styling & Asset StrategyUse SCSS with centralized variables/tokens (_tokens.scss)Prefer BEM methodology for predictable stylingKeep global styles minimalHost large asset bundles on a CDN in productionUse WebP and responsive image sets for performanceAvoid overriding Spartacus styles excessively — extend, don’t fork5. Data Flow: Connectors, Adapters & MappersSAP Composable Storefront’s architecture encourages clean data handling:Best PracticesKeep raw OCC models in adaptersMap OCC → UI-friendly models in dedicated mappersUse HTTP interceptors for:Auth token injectionSite/tenant context headersRequest correlation IDsKeep services thin; let adapters handle network concernsImplement custom endpoints using Spartacus’ OccConfig extension approachThis ensures maintainability through upgrades and avoids code duplication.6. State Management & RxJS Best PracticesSpartacus already ships with internal NgRx stores; custom state can extend it cleanly.GuidelinesPrefer async pipes instead of manual subscription/unsubscriptionUse OnPush change detection for all componentsApply correct RxJS operators:switchMap → dependent API callsexhaustMap → checkout flow stepscombineLatest → merged UI streamsKeep state local wherever possible — global store only when necessary7. Server-Side Rendering (SSR) & Pre-RenderingSSR is essential for SEO and for first-load performance of SAP storefronts.Key SSR ConsiderationsLeverage Angular Universal for renderingPre-render static routes (homepage, category pages)Implement fast fallback for SSR server failuresAlways guard DOM access using:if (isPlatformBrowser(this.platformId)) {
// browser-only logic
}Scaling SSRDeploy SSR nodes behind a load balancerUse horizontal autoscaling based on CPU/memoryCache SSR HTML aggressively at the CDN8. Performance, Caching & CDN StrategyRecommendationsUse long cache TTLs with content-hashed asset filenamesEnable API-level caching for read-only endpoints (CMS, product, categories)Implement lazy loading & route-based code splittingConsider image optimization and responsive formatsCache SSR output at CDN for key pagesMonitor TTFB and Core Web Vitals continuouslyThis significantly reduces backend loads and improves Lighthouse scores.9. Security ConsiderationsEnforce HTTPS everywhereApply Content Security Policy (CSP) headersUse HttpOnly cookies for tokens when possibleSanitize CMS-driven HTMLRate-limit OCC endpoints at the gateway layerAvoid leaking internal config via environment filesSecurity must be treated as a continuous practice, not a one-time setup.10. Testing StrategyLayers of TestingUnit tests → Services, components, mappersIntegration tests → Using Cypress or PlaywrightVisual regression tests → Percy or Playwright snapshotsContract tests → Pact against OCCAPI mocks for local developmentA mature storefront requires confidence across all layers.11. CI/CD & Deployment PatternsA modern pipeline should include:LintingUnit testsBuild (client + server bundles)Integration/E2E testsDeploy to stagingCanary/Blue-Green deploymentFinal production releaseInfrastructure GuidanceSSR Nodes deployed in KubernetesZero-downtime rolling updatesAutomatic CDN cache invalidation on releaseTight integration with observability stack12. Monitoring & Operational RunbookMonitoring StackError tracking (Sentry / Dynatrace / Kibana)Node SSR logs with correlation IDsAlerts for:Memory pressure5xx spikesSlow OCC endpointsCDN cache miss patternsRunbook Should IncludeHow to disable SSR in emergenciesCache purge strategyRollback instructionsRecovering from Commerce outagesThis ensures stable operations even under stress.13. Extensibility, Upgrades & GovernanceTo keep the storefront healthy long-term:Never fork Spartacus librariesMaintain compatibility matrix with Commerce & Spartacus versionsUse linting + Angular style guideTreat every new feature as an isolated moduleHave a structured upgrade plan for both Angular & Spartacus versionsGood governance reduces technical debt dramatically.ConclusionBuilding a production-ready SAP Composable Storefront requires more than installing Spartacus libraries — it demands a carefully crafted architecture, operational excellence, and adherence to enterprise-grade engineering standards.By following the patterns outlined above, teams can deliver storefronts that are:PerformantComposableUpgrade-friendlyHighly maintainableSecureReady for enterprise scaleThis blueprint aligns with SAP’s recommended best practices and equips teams to deliver future-proof digital commerce experiences.”}]] Read More Technology Blog Posts by SAP articles 

#SAPCHANNEL