Fejlesztés
Oracle Forms kiváltás
A kiváltás nem technológiai csere. Az évtizedek alatt felhalmozott üzleti logika és a végfelhasználói munkafolyamatok újraépítése a tényleges feladat — és ezt szokták alulbecsülni.
A Forms 12c Premier Supportja 2026 decemberében, a díjköteles Extended Support 2027 decemberében jár le. Maga a Forms nem szűnik meg: a 14c-t az Oracle 2030-ig Premier, 2033-ig Extended Supporttal támogatja. A 12c-n vagy régebbi verzión futó rendszereknél ezért időszerű a kérdés, hogy frissítés 14c-re vagy kiváltás. Ezt ritkán a dátum dönti el. Többnyire az üzemeltetési elvárások változása, a fejlesztői utánpótlás szűkülése, a modern integrációs igények és a megfelelőségi szempontok döntenek. A cél nem az Oracle alapok megkérdőjelezése, hanem annak meghatározása, hogy az Oracle Database-re épülő rendszerek milyen úton tarthatók fenn hosszú távon.
Miért becsülik alul
Egy Forms-alkalmazásban a képernyők mögött egy teljes fejlesztési platform dolgozik. Ha a projektet tisztán technológiai migrációként írják ki, a becslésből rendszerint az alábbi öt dolog marad ki.
Végfelhasználói követelmények
Hogy a felhasználók valójában hogyan dolgoznak a rendszerrel, az ritkán van leírva. Aki évek óta egér nélkül, billentyűzetről rögzít, az az új felületen is ezt fogja keresni, és az elfogadás ezen múlik. Ha egy megszokott működés az új platformon nem oldható meg, a felhasználókkal együtt kell alternatívát találni.
Beágyazott üzleti logika
Az üzleti szabályok szétszórva élnek a triggerekben, a kliensoldali kódban és az adatbázisban, és egy részükről már senki nem tudja, miért kerültek oda. Összegyűjtésük külön munka, amit külön kell becsülni.
Fejlesztési és kiszállítási lánc
A Forms-világban automatizált build, teszt és kiszállítás jellemzően nincs: a modulokat kézzel fordítják és másolják ki. Az új rendszerhez ezt a láncot az elejéről kell felépíteni.
Authentikáció és session-kezelés
A Forms-ban a bejelentkezés és a munkamenet jellemzően az adatbázis-felhasználóhoz kötődik. Egy modern rendszerben ezt token- vagy föderációs alapú azonosítás váltja, és ehhez az architektúrát is át kell tervezni.
Rendszerintegrációk
A környező rendszerekkel kiépült kapcsolatokat újra kell gondolni. Ezek gyakran olyan függőségeket is hoznak, amelyek túlmutatnak a kiváltandó rendszeren.
Egyik célplatform sem „on-click" migráció. Még az APEX sem, az Oracle-közelség ellenére: a Forms és az APEX működési modellje érdemben eltér, az átírás valódi újratervezést igényel.
Pilot projekttel kezdünk
A pilot a döntést készíti elő, a portfólió átírása csak utána jöhet. Közösen kiválasztunk egy jellemző rendszert, és ugyanazt a működését egyszerre két technológiával építjük újra. A végén a két út ugyanazon a feladaton mérve hasonlítható össze.
A pilot kicsiben, kontrollált körülmények között mutatja meg, mit kell majd a nagy projektben végrehajtani.
Három kimenet
Szervezetre szabott módszertan
Leírt, megismételhető folyamat a feltárástól az éles átadásig, amely az adott szervezet működéséhez és üzemeltetési rendjéhez igazodik.
Reális technológiai irányok
Mindkét célplatformról kiderül, mire jó az adott környezetben, hol vannak a korlátai, és milyen tudás kell a fenntartásához. Ezt egy valódi rendszer újraépítése mutatja meg.
Teljes költség- és ráfordításkép
A fejlesztés mellett azt is megbecsüljük, mennyibe kerül majd az új rendszer üzemeltetése és a hozzá szükséges tudás megszerzése. Erre a számra már tervezhetően lehet építeni a teljes kiváltást.
A pilot lépései
- 01Feltárás. Feltérképezzük, hogyan működik a rendszer, milyen üzleti logika és integrációk vannak benne, és mit használnak belőle valójában. Ez a szakasz még egyik technológiához sincs kötve.
- 02Párhuzamos megvalósítás. Ugyanazt a funkcionalitást újraépítjük Oracle APEX-ben, valamint Spring Boot és React/Angular alapokon is.
- 03Összehasonlítás. A két változatot ugyanazon szempontok szerint mérjük: mennyi munka volt, mi lett az eredmény, mit igényel az üzemeltetése, és milyen tudás kell hozzá.
- 04Tanulságok. Leírjuk a módszertant és a kockázati térképet, hogy a nagy projekt ne nulláról induljon.
Oracle APEX
Adatközpontú, az Oracle-ökoszisztémához szorosan illeszkedő megközelítés. A PL/SQL logika nagyrészt megmarad, ez a gyorsabb út. Cserébe erősebb az Oracle-kötődés.
Spring Boot + React/Angular
Szétválasztott frontend és backend. Akkor jön szóba, ha ki kell szabadulni az adatbázisból, vagy külső integráció, mobil, több csatorna a cél. Lassabb és drágább, viszont szabadabb.
Nem minden Forms rendszert érdemes lecserélni, és nem mindet ugyanoda. A pilot eredménye az is lehet, hogy a rendszer marad Formsban. Ilyenkor a 14c-re frissítést is elvégezzük, ezt több ügyfélnél csináltuk már.
Miért tőlünk
A forrásoldalt és mindkét célplatformot ismerjük, az átállás üzemeltetési oldalát pedig mi is el tudjuk látni.
A forrásoldal: Oracle Database, PL/SQL, adatmodell
Több mint húsz év Oracle-környezetben, és tanfolyamot tartunk PL/SQL-ből, Advanced PL/SQL-ből és adatmodellezésből
A célplatform: Oracle APEX
Építjük, üzemeltetjük és tanítjuk
A célplatform: Spring Boot és React/Angular
Mindhárommal építünk, és mindhármat oktatjuk
A kockázatos rész: átállás, párhuzamos üzem, adatintegritás
Ez üzemeltetési munka. Éles rendszereket üzemeltetünk 7×24-es készenléttel, eddig 96 690+ készenléti órában
Kezdjük egy beszélgetéssel
Arról, mi van egy Forms rendszerben, és mit használnak belőle valójában. Ebből már látszik, merre érdemes elindulni.