ID4A Asset Management
Full-Stack Engineer · 2026Turns a mass RFID scan into a reconciled, audited state of an entire multi-site asset portfolio.
Built for VIRTUAL ERA, ID4A Asset Management sits in the gap between RFID hardware suites that impose a generic data model and general-purpose ERPs that have no native RFID support. It's built around one specific workflow: a multi-site patrimoine where every physical asset is RFID-tagged and inventoried by scanning a zone rather than counting by hand.
A Super Administrator manages the site structure, the asset catalog, and users; a site's Responsible scans their zone with an RFID reader, and the read tags are reconciled instantly against what the system expects to be there — with results shown before anything is written to the database.
Confirming that result is where the system earns its keep: missing assets are automatically marked lost, an inventory session is persisted with its aggregate counters, deduplicated alerts are generated for each meaningful discrepancy, and three report formats are derived from one JSON source of truth and stored on object storage — all in a single transaction.
Architecture
Angular SPA Client
Single-page Angular app with role-based route trees, talking to the backend exclusively through a REST/JSON API secured by a bearer JWT.
Layered Spring Boot API
Strict Web → Security → Business → Data-access layering, organized package-by-feature so each module (inventory, alerts, history…) owns its controller, service, repository and DTOs.
JWT Auth & Strategy Security
Role-gated access via @PreAuthorize, with a Strategy-pattern AuthenticationProvider chain designed to add MAC-based terminal auth without touching the existing login flow.
Inventory Reconciliation Engine
Matches a deduplicated mass RFID read against the theoretical state in one query, classifies every instance, and cascades status, alert, and report updates on confirmation.
PostgreSQL + MinIO Storage
Relational persistence via Spring Data JPA, with generated inventory reports, asset images, and technical sheets stored as objects on MinIO.
Tech stack
Backend
- Spring Boot
Web
- Angular
- Tailwind CSS
Security
- Spring Security
- JWT
Data
- PostgreSQL
- MinIO
DevOps
- Docker
- Traefik
- GitLab CI
Pipeline
How a mass RFID scan becomes a reconciled, audited state — from the moment a zone is scanned to the moment statuses, alerts, and a report are generated, ready for the next inventory cycle.
Zone scanned
RFID reader reads tags
Tags deduped & matched
vs. theoretical state
Classified by category
found / incomplete / missing / surprise / unknown
Inventory confirmed
explicit user decision
Lifecycle status updated
missing → lost, automatically
Session & alerts recorded
deduplicated per instance
Report built & stored
JSON → CSV/XLSX on MinIO
From RFID scan to reconciled report
Setting up a patrimoine
- 1Super Admin creates a site (siège, direction, entrepôt, or point de vente), which creates its Responsible account in cascade
- 2The site is broken into RFID-tagged zones, and assets are added to a shared catalog organized by category
- 3Each physical unit becomes an instance tied to one or more RFID tags — a composite asset like a workstation gets one tag per component
- 4The Responsible affects instances to a zone or an employee ahead of the first inventory
Scanning and confirming an inventory
- 1Responsible scans a zone; the RFID reader submits every tag it read in one request
- 2The backend dedupes the reads, then reconciles them in a single query against that zone's theoretical state
- 3Each instance is classified: found, incomplete (partial tags on a composite asset), missing, surprise, or unknown
- 4Responsible reviews the read-only classification before confirming — nothing is written yet
- 5On confirm: statuses update (missing instances become lost automatically), deduplicated alerts are generated, and a JSON/CSV/XLSX report is built and stored on MinIO
Quality & DevOps
- Specification pattern for dynamic multicriteria filtering across every list — assets, alerts, history — without multiplying repository methods
- Uniform ApiResponse<T> envelope and a global @RestControllerAdvice for centralized, consistent error handling
- Strategy pattern for authentication providers, built to add MAC-based terminal auth later without touching the existing flow
- Alert anti-duplication: a discrepancy persisting across several inventories never re-fires the same alert
- Composite-asset reconciliation counts tags read against tags expected per instance, rather than treating each tag independently
- Multi-stage Docker builds for backend and frontend behind a Traefik reverse proxy with automatic TLS, deployed through a CI/CD pipeline with 27 reviewed merge requests across the internship
Screenshots
Team
Mohamed Elgheith
Full-Stack Engineer
Want to talk through how it was built?