Az alkalmazásunk régóta ismert és népszerű ismertetőjegye a gyors és egyszerű bevezetés, amely az általunk használt egyedi fejlesztési módszernek köszönhető. Az építőkockák a frissítések végrehajtását is kényelmesebbé teszik.

 

Amikor az ügyfeleinkkel együtt egy új appot készítünk, sokat nyom a latban, hogy gyorsan az gyorsan bevezethető, miközben az adott iparágban, az adott munkakörben szükséges teljes funkcionalitással rendelkezik. Az az idő, amit ezek a cégek a bevezetésen és a csapat betanításán spórolnak, azonnal lefordítható teljesítmény- és profitbeli növekedésre. A SCOLVO iparág-specifikus tapasztalatain alapuló, készre fejlesztett építőkockák a pénzügyi szektor, a közműszolgáltatók, vagy a kiskereskedelem területén egyaránt használhatóak.

De azt is megértettük, hogy a frissítések esetében is hasonlóan egyszerű és könnyen használható megoldásra van szükség. Még ha minden szempontból körültekintően is járunk el a bevezetés során, később óhatatlanul felmerül az igény új funkciók vagy adatbeviteli lehetőségek hozzáadására. Előfordul, hogy az adatlapok nem minden részletre kérdeznek rá, vagy nincs hely több közreműködő hozzáadására. Esetleg a státusz-frissítési lehetőségek nem kielégítőek. Mindez belefér a normál üzleti működésbe.

A szokásos forgatókönyv esetében a frissítések, kiegészítések egy csomó bonyodalmat okoznak. Vegyünk egy logisztikai példát: a küldő fél elvállalja, hogy egy leszállít egy extra küldeményt, de ehhez a szokásos azonosítókon kívül még egyéb adatokat is kér a címzettől, hogy biztosítsa a küldemény célba juttatását. Ezért egy új mezőt szeretne felvenni az appba, a személyi igazolvány-szám beírására.

Nem nagy ügy? A hagyományos megoldás ilyenkor az, hogy újra kell írni a kódot, újra definiálni az adatbázist, és kiadni egy új verziót az appból minden felhasználó számára, hogy láthatóvá váljanak a változtatások. De az egyszerűség SCOLVO-mantrája ennek ellentmond: ez a megoldás szerintünk túlságosan hosszú ideig tart, és túl bonyolult. Az építőkockák frissítése egyszerűbb kell, hogy legyen.

Hogy megmutassuk, a mi alkalmazásunk ebben a helyzetben is helytáll, nemrégiben egy rugalmasabb adattárolási és -kezelési megoldást vezettük be: a szemantikus adatbázist. Ezt egy konfigurációs fájl vezérli, amely mind a backendnek, mind az admin felületnek megmondja, hogy hogyan kezelje az információkat. Ezért amikor az ügyfél azt kéri, hogy adjunk hozzá még egy beviteli mezőt valamelyik felülethez, csak ezt a konfigurációs fájlt kell kiegészítenünk, és az megmondja a backendnek, hogy milyen struktúrába illessze be az új adatot, és a webes admin felületnek, hogy hogyan jelenítse meg azt.

A szemantikus adatkezelés az adatkonzisztencia megőrzését is leegyszerűsíti. Az úgynevezett “flow engine” a megfelelő sorrendben tartja a módosításokat akkor is, ha a hálózat hiánya miatt nem lehet azonnal szinkronizálni azokat. Visszatérve a logisztikai példára, a felrakodásra és lerakodásra vonatkozó státusz-frissítések olyan sorrendben fognak megjelenni, ahogy a munkafolyamat megkívánja, függetlenül attól,hogy volt-e elérhető internetkapcsolat.

Amikor több változtatás is offline módban történik, mint például a felelősök késznek jelölik a felrakodási és lerakodási feladatokat, a flow engine sorban várakoztatja ezeket a változtatásokat egészen addig, amíg újra hozzá nem tud férni egy hálózathoz, amikor is az elvégzés sorrendjében élesíti a frissítéseket. Mivel minden módosítást így tud kezelni, azokat anélkül lehet élesíteni, hogy káoszt okoznának a korábban és a nemrégiben hozzáadott adatok kezelésében.

Az ügyfelek számára ez a háttérben zajló folyamat javarészt láthatatlan. Amit látnak, hogy az alkalmazás frissítése fennakadások nélkül valósítható meg, és a munkafolyamatokat vagy a felhasználókat akkor is helyesen kezeli, amikor új adattípus kerül a rendszerbe.