Skip to content
Sohel Rana

Case study

B2B trade ordering backed by SAP Business One for a fastener distributor

A B2B and retail store for a New Zealand fastener distributor, with SAP integration, complex customer pricing, barcode support, click and collect and Windcave payments.
Client
Industrial fasteners distributor
Region
New Zealand
Platform
Adobe Commerce Cloud

01

Problem

Trade customers expect to see their own prices, branch stock and account terms online, and all of that lives in SAP Business One. The store had to show it in real time without hammering the ERP.

02

Approach

I worked on the SAP integration for products, prices and inventory, set up and customised Adobe Commerce B2B for trade accounts, and built the pricing, barcode and checkout features. I also took the platform through upgrades from 2.4.4 to 2.4.8.

03

Outcome

Trade and retail customers order from the same store, see their own SAP pricing and branch stock, and can collect in store or pay on account.

Highlights

  • SAP integration. Product, stock and status imports from SAP Business One.
  • Pricing at scale. More than 40 GB of customer, tier and discount prices, served from a separate KeyDB price service in under a second (see below).
  • B2B customisation. Company accounts, personalised content for trade buyers, requisition lists and automatic invoicing for purchase order payments.
  • Barcodes. Barcode support for finding and ordering products.
  • Click and collect. Collection from the distributor's branches.
  • Windcave payments. Card payments through Windcave.
  • Checkout. A checkout that handles trade accounts, purchase orders, collection and delivery.

Serving 40 GB of prices

Every B2B company on the store has its own product prices, tier prices and discounts. Retail customers and guests have their own prices too. Altogether that comes to more than 40 GB of price data, and SAP refreshes it every day.

Keeping that in Adobe Commerce's own MariaDB wasn't realistic. A daily import of that size would be slow and heavy on the database, and reading prices back from tables that large was too slow for the storefront. Adobe Commerce Cloud also doesn't allow custom cache disk space, so we couldn't just add a bigger cache next to Commerce.

So we split the price data out, but kept the pricing logic in Commerce:

  1. Import. A Python service on a separate AWS server pulls prices from SAP Business One and loads them into KeyDB, an in-memory, Redis-compatible store.
  2. Serve. A small Laravel API in front of KeyDB returns prices for a given customer and product.
  3. Use. Adobe Commerce calls that API only when it needs a price. Each lookup takes less than a second, and all the rules about which price applies to whom stay in Commerce.

The daily import runs on its own server, so it never loads the Commerce database.

At a glance

40 GB+
Price data
< 1 s
Price lookup
6
Years on the project
44
Custom modules
StackAdobe Commerce B2B 2.4.8SAP Business OneMSIWindcaveKeyDBLaravelPythonAWSTagsB2BIntegrations