Microsoft Business Central, an EDI pipeline, a custom storefront, and Canada Post — wired together through a Python middleware layer that keeps the AL surface clean and the integration logic version-controllable. Wholesale operations running as one connected system instead of four.
Rose & MacDonald is a wholesale distributor. Their business runs on Microsoft Business Central — that is where the products, customers, orders, and inventory live. The growth path was online; they wanted a storefront for their customers to order through, with the orders flowing back into Business Central as the system of record. They also exchanged data with trading partners over EDI, on the SFTP-based pipelines that wholesale still runs on. And they shipped through Canada Post.
On paper, four pieces. In practice, the four pieces did not talk to each other. Business Central did not have a native connector that did what R&MD needed. The EDI pipeline ran on its own schedule. Canada Post was a manual lookup at the warehouse. The team in charge of all of this was small enough that any one piece taking longer than a week to manually reconcile broke the rest of the week.
R&MD did not need a connector. They needed the four systems to behave as one — and they needed someone who could work across the AL extension surface in Business Central, the Python middleware to bridge it, the custom storefront, the SFTP-based EDI flows, and the Canada Post API. That spans more disciplines than most agencies staff in one team.
Arc10 took the integration surface end-to-end. Senior engineers across the AL extension layer, the Python middleware, and the custom storefront built for R&MD's customers. Embedded into R&MD's workflow on the wholesale side so the engineering decisions reflected how the team actually ran orders day to day.
The architectural decision was to build a Python middleware layer between Business Central and everything else, rather than wire each external system directly into Business Central via AL.
AL extensions are powerful inside Business Central; they are not the right place to hold integration logic that needs to evolve with storefront features, Canada Post's rate cards, and EDI partner schemas. Putting that logic in Python middleware kept the AL surface clean.
The middleware is the place the business logic lives. It is version-controlled, deployed independently of Business Central, and observable on its own — so iteration on integration behavior does not require Business Central redeployments.
The decision was the architectural choice that made the rest of the engagement maintainable. The AL surface stays minimal. The integration logic evolves on its own cadence. The four systems behave as one without Business Central becoming the place every change has to land.
Senior engineers across the AL extension layer in Business Central, the Python middleware, the custom storefront, the SFTP-based EDI flows, and the Canada Post API. Arc10 owned the integration surface end-to-end while R&MD's team continued to run the wholesale operation in parallel.
AL extensions inside Business Central handle the operations that have to live there — schema additions, posting routines, custom fields on customers and items. Designed to be minimal: the extension layer is the contract Business Central exposes to the middleware, not the place business logic accumulates.
The connective layer between Business Central and the outside world. Translates storefront orders into Business Central transactions on one side; pushes inventory and product updates from Business Central back to the storefront on the other. Handles retry, idempotency, and reconciliation — when an order comes through twice, the middleware does not produce two Business Central orders. Version-controlled, deployed independently of Business Central, observable on its own.
Existing SFTP-based EDI flows wired into the same middleware. Trading-partner data lands in the same canonical format as storefront-sourced data, so the rest of the system does not have to know which channel the order came in on. Adding a new EDI partner becomes a configuration change, not a new build.
Shipping rates, label generation, and tracking pulled through the Canada Post API. Removed the manual lookup at the warehouse; orders flowing through R&MD now have shipping handled programmatically against the same data the rest of the system uses.
Four systems behaving as one — without Business Central becoming the place every change has to land.
Connecting an ERP to a storefront, an EDI pipeline, and a shipping provider? The senior engineer who built R&MD's middleware will take the call.