Case study
B2B trade ordering backed by SAP Business One for a fastener distributor
- 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:
- 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.
- Serve. A small Laravel API in front of KeyDB returns prices for a given customer and product.
- 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