Reference Architecture: A Custom Web Portal Layer Over SAP.

SAP Business One is a capable ERP with a structural cost problem — every user who needs access needs a named licence. This is the pattern we use to put a fast, role-controlled web portal over SAP B1: full module access in the browser, live data through the DI API, and licence overhead cut for everyone doing routine work.

USERS & ROLES FinanceSales & Purchasing WarehouseRBAC · 4 permission tiers WEB PORTAL Browser access ASP.NET MVC · RazorBootstrap UI Custom dashboardsFilter & export BUSINESS LOGIC Layered architecture C# / .NET · data accessSQL optimisation Pagination · transactions DI API Real-timetwo-waysync SAP BUSINESS ONE Business PartnersSales PurchasingInventoryFinancials + MS SQL Server
Platform
Enterprise Web PortalSAP B1 IntegrationReference Architecture
Services
Enterprise EcosystemsCustom Enterprise SoftwareFull-Stack EngineeringData & ReportingSystems Architecture
Scope
SAP B1 ModulesDI API IntegrationRole-Based AccessCustom DashboardsPerformance Engineering
01Overview

SAP Business One is a capable ERP with a structural cost problem: every user who needs access needs a named licence. This is the architecture pattern Axlume uses to put a fast, role-controlled web portal over SAP B1 — centralising every core module (Business Partners, Sales, Purchasing, Inventory, Financials) behind one browser interface, with live data through the DI API and licence overhead cut for everyone doing routine work.

It’s drawn from a delivered engagement; the client remains confidential. What’s shown here is the pattern itself — the way we structure a portal layer over SAP so it stays fast, maintainable and cheap to run.

02The Problem

The SAP desktop client was costing more than it was giving.

The standard desktop client carries a licence problem: every user who needs access requires a named seat. For a growing organisation with cross-functional teams — finance, sales, purchasing, warehouse — those licence costs compound fast.

Worse, most of those users only need to read data or run a routine task. They were paying full-seat prices to sit in a heavy desktop client, while managers had no clean web view and reporting stayed manual.

The brief in plain terms: give every role the SAP data it needs, in the browser, without a per-seat licence for each of them.

03How We Operated

Design the access model first, then build the portal around it.

Access & Licence Audit

Map who actually needs which modules, and what “access” really means per role — so the portal replaces seats where it can and defers to SAP where it must.

Layered Architecture

A clean Presentation / Business Logic / Data Access split over the DI API — so the portal scales, stays maintainable, and isolates the SAP integration from the UI.

Module Integration

Wire every core module — Business Partners, Sales, Purchasing, Inventory, Financials — through the DI API with real-time, two-way synchronisation.

Performance Engineering

SQL-level optimisation, server-side pagination and tight transaction scoping so the portal is faster than the desktop client on the workflows it covers.

Access Control

Role-based access with permission tiers, so each role sees exactly the modules and actions it should — and nothing else.

04What We Build

Six parts that turn SAP into a web product.

Component 01
Centralised Module Interface

One web interface across all five core SAP B1 modules — the whole ERP surface a routine user needs, without opening the desktop client.

Component 02
Real-Time DI API Sync

Live, two-way synchronisation with SAP through the DI API — the portal reads and writes the same records the desktop client does, in real time.

Component 03
Custom Reporting Dashboards

Role-specific dashboards with filtering and export — the reporting the desktop client made painful, surfaced as a first-class view.

Component 04
Role-Based Access Control

Four permission tiers, so a warehouse user and a finance lead see completely different portals built from the same system.

Component 05
Performance Layer

Indexing, server-side pagination and transaction handling — the difference between a portal that feels slower than SAP and one that feels faster.

Component 06
Layered Architecture

Presentation, business logic and data access as separate concerns — so the SAP integration can change without touching the UI, and the whole thing stays maintainable.

05The Architecture

A portal layer over SAP, not a replacement for it.

SAP Business One stays the system of record. The portal sits in front of it: the browser talks to an ASP.NET MVC layer, which talks to a business-logic layer, which talks to SAP through the DI API. Reads and writes flow both ways in real time, so nothing forks away from SAP.

The stack is deliberately conventional — the value is in how the layers are structured and tuned, not in exotic technology.

FrontendASP.NET MVC · Razor Views · Bootstrap
BackendC# · .NET Framework
ERP IntegrationSAP Business One DI API
DatabaseMicrosoft SQL Server
ArchitectureLayered — Presentation / Business Logic / Data Access
AccessRole-Based Access Control (RBAC)
PerformanceSQL optimisation · server-side pagination · transaction handling
06The Outcome

Full SAP access, minus the per-seat bill.

What this pattern delivers:

Drawn from a delivered engagement; the client and commercial figures are confidential under NDA. We can walk a qualified prospect through the detail directly.

07The Technical Reality

The DI API is the hard part.

The SAP Business One DI API is not designed for high-frequency, high-volume web traffic. Point a busy portal at it naively and poorly-scoped calls create bottlenecks that make the web experience slower than the desktop client — which defeats the entire point.

The fix is three things working together: SQL-level query optimisation before data ever reaches the DI API layer, tight transaction scoping so connections don’t stay open under load, and server-side pagination to cap the data volume per request. Done properly, the portal outperforms the desktop client for the workflows it covers.

That’s the whole reason this is a reference architecture and not just “a web front-end for SAP”: the pattern is the performance discipline, not the screens.

More Enterprise Work
Integration Blueprint
WhatsApp-to-SAP Business One Automation
Automation · Systems Integration

From Message to ERP Record — WhatsApp
Automation Inside SAP Business One

Agentic AutomationWebhooksSAP DI API
Ready to Scale

From Proof of Concept to Global Scale.

You’ve seen our standard of engineering. Now, let’s build yours. From high-impact websites to complex enterprise applications, we specialize in transforming ambitious ideas into elite-grade digital reality. Whatever the platform, we bring the precision your vision demands.