A probléma
A terepen végzett munka adatai több csatornán érkeztek: telefonon, papíron, fényképen és utólag kitöltött táblázatokban. A diszpécser nem egy közös operatív képet látott, hanem külön rendszerekből próbálta összerakni, hogy melyik jármű hol van, ki dolgozik rajta, és elkészült-e a feladat.
Nem egy újabb mobilalkalmazás kellett. Olyan rendszer kellett, amelyik a terepi eseménytől a meglévő adatbázisig végig birtokolja az adat útját.
A korlátok
- Több mint 5 000 jármű és 1 000 földrajzi lokáció.
- iOS-, Android- és webes használat ugyanazon üzleti szabályokkal.
- Meglévő SQL Server-adatmodell és olyan üzleti logika, amit nem lehetett egyszerre lecserélni.
- Gyenge vagy időszakos mobilkapcsolat a terepen.
- Fényképek, GPS-koordináták és időbélyegek bizonyító erejű tárolása.
- Folyamatos működés: a migrációk alatt sem állhatott le az operáció.
A nehéz rész nem a mobilképernyő volt. A nehéz rész az volt, hogy a mobil, a backend, a régi adatmodell és a napi operáció ugyanazt tekintse igaznak.
Az architektúra
A terepi alkalmazás egy Flutter-kódbázisból szolgálja ki az iOS- és Android-eszközöket. Az alkalmazás a szükséges adatot lokálisan is tartja, így a rögzítés hálózati hiba esetén sem áll meg. A szinkronizáció API-kon keresztül éri el a .NET backendet.
A backend több mint 100 REST endpointot, háttérfolyamatokat, integrációkat és geolokációs számításokat kezel. A tranzakciós adat SQL Serverben marad; a nagy bináris állományokat külön tárolóréteg kezeli. A megoldás komponensei fokozatosan cserélhetők, ezért az üzleti működés nem függ egyetlen nagy átállási naptól.
Amit megépítettünk
- Terepi munkafolyamat iOS-re és Androidra, offline-tűrő rögzítéssel.
- GPS-, időbélyeg-, QR- és fotóalapú események.
- Egységes fotófeldolgozás és képméret mindkét mobilplatformon.
- Diszpécsernézet a napi munka követésére.
- .NET backend és több mint 100 API endpoint.
- SQL Server-adatmodell, riportok és integrációs folyamatok.
- Production deployment, monitoring és operatív hibakezelés.
Mért és műszaki eredmények
| Előtte | Utána | |
|---|---|---|
| Fő operatív riport válaszideje | 306 s | 0,4 s |
| Fotófeldolgozás | platformonként eltérő | egységes méret és tömörítés iOS-en és Androidon |
| Fotók tárolása | tranzakciós adatbázisban | elkülönített fájltárolás, adatbázisban csak hivatkozással |
| Km-óra automatikus felismerése | kézi bevitel | 74,6% valós, zajos mintán |
| Terepi rögzítés | papír / utólag | helyben, GPS + idő + fotó |
A megrendelő saját becslése szerint a diszpécseri telefonálás napi körülbelül két órával csökkent, a munkalapok utólagos gépelése pedig megszűnt. Ez ügyfélbecslés; a fenti technikai eredményeket rendszeroldali mérések és a megvalósított működés támasztják alá.
Mit csinálnánk ma másképp
Korábban választanánk külön a tranzakciós adatot és a fájltárolást. Szigorúbb teljesítménybüdzsét adnánk minden operatív riportnak, és a szinkronizáció hibamódjait már az első prototípusban valós hálózati körülmények között mérnénk.
Az architektúra legjobb döntése továbbra is a fokozatosság lenne: egy kritikus folyamatot élesíteni, mérni, majd erre építeni a következőt. Ez kisebb technikai kockázatot és gyorsabb operatív visszajelzést ad, mint egy teljes rendszer egyszeri cseréje.
Az esettanulmány anonimizált. Megnevezett referencia szakmai hívás keretében, kérésre elérhető.