Skip to main content

SAP Commerce services

We work on Hybris and SAP Commerce Cloud only. Ten services, each with the tools we use and what your team gets.

Answer engines

SEO for ChatGPT and LLMs

When a shopper asks ChatGPT, Claude, Perplexity, or Google AI Overviews which product to buy, the answer comes from pages those engines can read. We make your SAP Commerce product and category pages readable to them: server-rendered text with the price and the stock in the HTML, structured data built from OCC, and robots rules that let AI crawlers in. Then we measure how often your products appear in the answers.

  • Crawl access: We open robots.txt to GPTBot, ClaudeBot, PerplexityBot, and Google-Extended, and publish llms.txt and a sitemap of every PDP with lastmod from the catalog sync.
  • Server rendering: We move product and category routes to SSR on Composable Storefront, so name, price, and stock are in the HTML and not loaded after hydration.
  • Structured data: We generate Product, Offer, AggregateRating, BreadcrumbList, and FAQPage JSON-LD from OCC on every PDP and PLP.
  • Citation report: Every month we run 50 buyer questions in ChatGPT, Perplexity, and AI Overviews and report which answers name your products and which name competitors.
Talk about AI search

Integrations

Integrations

We connect SAP Commerce to the systems around it and make every connection behave the same way: one contract per provider, one idempotency key per message, retries with backoff, and a dead-letter queue with an alert. We work with SAP S/4HANA and ECC over the Integration API, IDoc, or SAP Integration Suite, and with the providers your shop already uses for payments, tax, shipping, marketplaces, PIM, content, CRM, and events.

  • ERP orders and stock: We send orders to S/4HANA or ECC over the Integration API (OData) or IDoc with an idempotency key, and bring stock and prices back as deltas every 30 seconds.
  • Payments and tax: We integrate Stripe, Adyen, PayPal, Klarna, Vertex, and Avalara with signed webhooks that can be replayed from the event log.
  • Marketplace, PIM, and content: We connect Mirakl, Akeneo, Contentful, and Cloudinary with sync jobs that fail loudly: dead-letter queue, Dynatrace alert, runbook.
  • Runbooks and handover: Each integration ships with one runbook: the contract, the retry policy, the failure paths, and the person on your team who owns it.
Talk about integrations

Code

Code optimization

We find the code that makes your shop slow and rewrite it. Dynatrace method hotspots and the FlexibleSearch log show us which facades, populators, and converters run one query per product instead of one query per page. We batch those queries, prefetch the relations, and size the caches. Each rewrite ships with the query count and the response time before and after, measured on your data.

  • Query profiling: We record the FlexibleSearch queries per route on d1 with Dynatrace and the query log, then rank the routes by query count and wall time.
  • FlexibleSearch rewrites: We replace N+1 loops with IN (?params) batches, add prefetch joins for media and variants, and use projection queries where no model is needed.
  • Cache configuration: We size the region cache and the query cache per item type in EhCache and set eviction so price and stock rows stay hot.
  • Static analysis in the build: We add rules to the CCv2 build that fail a pull request when a query runs inside a loop, so the pattern does not come back.
Talk about code

Performance

Performance and scalability

We make every page of your shop fast at the traffic you expect at peak. We start with Dynatrace on CCv2 to name the slow route and the slow layer, then work through the cache regions, Solr, FlexibleSearch, the CDN, and the CCv2 pod sizing. Before release we run a k6 load test at peak volume and hand you the report next to the Dynatrace before and after.

  • Route analysis: We read Dynatrace PurePaths for PLP, PDP, cart, and checkout and name the layer that costs the most on each: database, Solr, OCC, or storefront.
  • Cache and Solr tuning: We resize the cache regions, set the Solr filterCache and query cache, and rewrite the slowest FlexibleSearch plans.
  • CDN and edge: We put Cloudflare or Azure Front Door in front of the storefront with cache keys per route and stale-while-revalidate for SSR pages.
  • Load test and sizing: We run k6 at the expected peak, then set pod count, heap, JVM flags, and readiness probes in the CCv2 manifest.json.
Talk about performance

Upgrades

2211 upgrades and CCv2 migration

We move shops from 1811, 1905, 2005, or 2105 to 2211-jdk21 on Commerce Cloud, the Java 21 and Spring 6 track, and from on-premise to CCv2. We start with a readiness report that lists every extension, addon, and API call that 2211 removed. Then we rewrite the manifest, the extension set, and the code, get the build green on d1, and plan the cutover for staging and production on your maintenance calendar.

  • Readiness report: We scan the codebase for removed APIs, Data Hub and Accelerator addons, custom cronjobs, and the Solr schema, and list the work per extension.
  • Build on Cloud Portal: We write the manifest.json for 2211-jdk21 with Java 21, Spring 6, and Solr 9, prune localextensions.xml, and get build and deploy green on d1.
  • Code rewrite: We rewrite every removed call, move javax packages to jakarta for Spring 6, migrate the Solr schema to 9.x, and keep the junit and Playwright checkout tests green.
  • Cutover and patch cadence: We plan the s1 and p1 deployments, the rollback, and the patch schedule after go-live, so every next patch is one build.
Talk about upgrades

Data

Data migration and ImpEx

We move product, category, price, media, customer, and consent data from Magento, Salesforce Commerce, Intershop, or an older Hybris into SAP Commerce, and we prove that nothing was lost. Each item type gets a mapping sheet, a dry run on the Staged catalog that fails early, batched ImpEx loads through the hot folder, and a reconciliation count against the source system.

  • Mapping specification: We document every legacy field, its Commerce attribute, the conversion rule, and the owner, one sheet per item type.
  • ImpEx loads: We write the ImpEx scripts, load in 5,000-row batches through the Azure Blob hot folder, and move media to Blob storage with CDN URLs.
  • Dry runs and validation: We run each load on Staged first and report missing mandatory values, duplicates, and unknown categories before the real load.
  • Cutover runbook: We rehearse the full load until it fits the window, then hand over the runbook with timings, rollback, and reconciliation counts.
Talk about migration

Storefront

Composable Storefront (Spartacus)

We move storefronts from Accelerator JSP to Composable Storefront 2211 on Angular, one route at a time, and we keep them fast after launch. We render product and category pages on the server on CCv2, reserve the height of every CMS slot so nothing jumps, batch the OCC calls, and put a CDN in front. A Lighthouse budget in the pipeline blocks a pull request that makes a page slower.

  • Route parity: We list every Accelerator route, its Composable equivalent, and the gap, and migrate in an order that lets both storefronts run side by side.
  • Custom CMS components: We build your components in Angular with SmartEdit contracts and SSR-safe rendering, so the content editors keep working.
  • OCC integration: We batch the OCC calls, request only the fields a route needs, set cache headers, and handle errors per route.
  • Performance budget: We add Lighthouse CI and Playwright checkout tests to the CCv2 pipeline with LCP under 1.2 s and CLS 0 on a mid-range phone.
Talk about the storefront

Backoffice

Backoffice and SmartEdit enablement

We make the content, merchandising, and customer service teams independent of developers for their daily work. Every custom CMS component gets registered in SmartEdit with an editor and a preview. Backoffice gets the editor areas, wizards, and validation each team needs. The catalog sync runs in minutes and never locks an edit. We train the teams and leave a playbook.

  • SmartEdit registration: We register each custom component with type, editor, decorator, and preview, and test the drop on d1.
  • Backoffice configuration: We build editor areas, wizards, restrictions, and validation per item type, so a campaign or a price change is a form and not a ticket.
  • Catalog sync: We tune catalogSyncJob to finish Staged to Online in minutes and schedule it so it never blocks the content team.
  • Training: We run two recorded sessions per team and write one playbook per task: campaign, promotion, product update, order lookup.
Talk about Backoffice

AI agents

AI agents on SAP Commerce

We connect the AI assistants your teams already use to your SAP Commerce environments. A customer service rep asks Claude in Slack about an order and gets the status, the cause, and the fix. A merchandiser asks ChatGPT or SAP Joule for the stock of a product line. The agents read orders, carts, customers, stock, prices, and cronjobs. Writes need an approval and leave an audit entry.

  • Claude in Slack and ChatGPT: We connect both to orders, customers, stock, and prices on production, scoped to the channel and the role.
  • SAP Joule: We set up Joule agents on Commerce Cloud for customer service and merchandising tasks.
  • Copilot and Gemini: We give Microsoft 365 Copilot in Teams and Gemini in Google Chat the same tools, so every team works in its own chat.
  • Guardrails: We map tool scopes to Backoffice roles, put every write behind an approval, and write an audit entry per call.
Talk about AI agents