Kazam WMS · warehouse platform
A readable stack, a controllable deployment.
Three clients — web, mobile and desktop — on one domain, one database and one set of rules. Every layer is isolatable, testable and replaceable: no monolith, and no implicit dependency on a proprietary cloud.
Logical architecture
- COREDomain in C# / .NET — The domain services — master data, receiving, put-away, picking, stock counts, quality control, KPIs — live in one place and do not know which client the request came from. That is why web, mobile and desktop always show the same numbers: they do not have three different logics, they share one.
- WEBKazam Web — Blazor Server on .NET 10 — The main client: 86 pages across 27 areas, 31 of them purely for configuration. It runs on the server and sends the browser only the interface differences, so a workstation has nothing to install and an update is immediate for everyone. Syncfusion components for grids, charts and the warehouse map; cookie authentication.
- BFFA layer for the web, not a generic API — Between the web app and the domain sits a backend for frontend: it exposes exactly what the pages need, aggregated the way they need it, and the web app consumes it through typed, key-authenticated clients. The web app never opens a database connection.
- MOBILEKazam Mobile — .NET MAUI — Android on industrial handhelds and WinUI on Windows tablets, for the people working among the racking. Hardware scanner input, offline operation and differential sync: the warehouse keeps going even where the Wi-Fi does not reach the end of the aisle.
- DESKTOPKazam Desktop — Windows client — The established WinForms client, complete and supported, for those who prefer an application installed on the workstation. It works on the same domain and the same data as the other two.
- WCSSun Tech WCS — the layer that talks to machines — Plant control for PLCs, shuttles, sorters and AGVs: plant model, missions, routes and recovery when a machine stops. Open source, under the Apache License 2.0. It is the layer an ERP does not have, and the one that separates an automated warehouse from a merely computerised one.
- EXCHANGEIntegration with the ERP — REST/JSON APIs indexed by ERP key, plus a database exchange area with a status on each record. Two routes to the same end: the synchronous one when an answer is needed now, the asynchronous one when the two systems should not wait for each other.
- DATASQL Server, on-premise or in the cloud — Transactional data sits on SQL Server, wherever you want it. No implicit dependency on a proprietary service: the database is yours, queryable with the tools you already use.
An exchange contract, not a per-vendor connector
Kazam does not embed connectors tied to a single ERP: it exposes a data exchange contract that any ERP can feed and consume. The integration is built on the customer's own record layouts during the analysis phase, and it holds even if the ERP changes tomorrow — the warehouse does not stop.
Correlation key
Every warehouse document carries the reference to its source ERP document (HOOK_TESTATA_ERP on headers and lines): the link between the two worlds is explicit, queryable and verifiable at any time.
Exchange area
Staging tables on SQL Server with a status on each record: the ERP writes, Kazam reads, and every row knows whether it has been imported, is pending or has failed.
Import service
A Windows service picks up whatever is queued at configurable intervals and feeds it into the WMS — customers, addresses, items, load units, orders — idempotently and repeatably.
REST API
Endpoints indexed by ERP key, with JWT authentication, to read and write in real time when polling is not enough. Plus optional SQL hooks for project-specific customisations.
How this applies to the most common ERPs: SAP · TeamSystem · Zucchetti · Microsoft Dynamics · Kazam vs Odoo (pages in Italian)
Clean stack, clear contracts, sustainable evolution
Clean Architecture + DI
Clear separation between domain, application and infrastructure. Dependency injection for testability.
Bounded Contexts (DDD-light)
WMS, WCS and Mobile operate in separate contexts with clear, versioned contracts.
Pragmatic CQRS
Commands and queries kept separate where throughput and scaling simplicity are needed.
Event-driven
Internal domain events; reactive integrations via MQTT / webhooks toward external systems.
Modern stack, industrial adapters
.NET 9/10-ready
- Modern C#, async-first
- WinForms + .NET MAUI
- DevExpress / Syncfusion
- Optimized ADO.NET
Industrial protocols
- MQTT for IoT / devices
- OPC-UA for automation
- Modbus, Omron FINS
- VDA 5050 for AGV / AMR
On-premise or Azure
- SQL Server / Express
- Optional Azure App Service
- Docker containers
- Configurable queues + storage
Audit-ready, native traceability
Authentication
JWT / OAuth2. RBAC (roles/profiles) down to the module and action level.
Multi-tenant
Optional: logical separation by customer/site with dedicated DB scopes or schema-per-tenant.
Encryption
TLS in transit; selective at-rest encryption (field/table); external secret management.
Audit & tracing
Append-only logs, audit trail on sensitive records, correlated distributed tracing.
Architecture whitepaper on request
A technical document for IT managers, integrators and developers with details on connectors, modules, FINS/OPC-UA, KPIs/BI.
Ready to try it?
Get access to the web application: you open it in the browser, with nothing to install on workstations. An engineer replies within one business day.
The three most recent developments: the web application — what changes and what stays —, the assistant that configures the warehouse by interviewing you and Sun Tech WCS, the Warehouse Control System released as open source.