Mivel már maga a tervezés is rengeteg időt emészt fel, a megvalósításról, átadásról, bevezetésről nem is beszélve, ezért a felhasználók gyakran nem várják meg ezek elkészültét és az évek során maguk építenek fel egy olyan megoldást, amely hatékonyan segíti a vállalat napi munkáját.
Természetesen a klasszikus fejlesztési alapelvek figyelmen kívül hagyása hosszú távon okozhat fejtörést, de ma már számos olyan low-code eszköz létezik, amely lehetővé teszi, hogy a tudás hiányában ne egy hatalmas excel tábla tábla jöjjön létre, hanem olyan megoldás, amire hosszú távon is lehet építkezni.
Az általunk használt Oracle Application Express már eddig is bizonyított mint felhasználóbarát, de mégis sokoldalú és hatalmas adatmennyiséget kezelő keretrendszer, amely az üzleti felhasználók körében is népszerű eszköz. Mivel kevés fejlesztői tudással, gyors és látványos eredmények érhetőek el, melyek az egész szervezet számára hozzáférhetőek.
Rövidesen már nemcsak az egyes régiók, oldalelemek és azok tulajdonságai készülhetnek kódolás nélkül, hanem magát az információt összegyűjtő SQL utasítások is.

Vegyünk egy egyszerű példát:
Szeretnénk az alkalmazásunkban egy olyan diagrammot létrehozni, amely megjeleníti az áltagfizetéseket szervezeti egységenként.
Indítsuk el a diagramm létrehozó varázslót.

Itt meg kellene adnunk egy SQL utasítást, de ehelyett fogalmazzuk meg a következő kérést:
„Jelenítsd meg a dolgozók átlagfizetését a szervezeti egységek szerint”.

A a fejlesztő (aki esetünkben lehet a felhasználó is) ezután az „APEX Assistant” gombra kattintva generálhatja a megfelelő SQL utasítást.
Az APEX elküldi a szöveget egy Generative AI REST szolgáltatásnak amely az alábbi példában látható módon egy Oracle SQL utasítás formájában adja vissza az eredményt.
Ahelyett, hogy elkezdenénk a megfelelő táblákat keresgélni, majd összekapcsolni őket és a megfelelő műveleteket elvégezni, megteszi ezt az APEX Assistant helyettünk.

Természetesen a dolog úgy is működhet, hogy maga a felhasználó írja be, mit szeretne látni ahelyett, hogy különféle gombokra kattintva egy már meglévő riport eredményeit tudja csak módosítani, ahogy azt már egy hagyományos BI eszközben megszokhattuk.

A folyamat tehát a következő:
A fejlesztő – aki esetünkben a low-code megközelítés miatt maga a felhasználó is lehet – létrehoz egy kérést (prompt).
A kérést a beépített RAG (Retrieval Augmented Generation) modul kiegészíti további információkkal – esetünkben az Oracle adatbázisból, melyek lehetnek:- Az APEX-alkalmazásban használt táblázatok nevei- A táblák attribútumai az adattípusukkal együtt- A táblák elsődleges kulcsai, azonosítói- A táblák idegen kulcsai
A kiegészített kérés (prompt) elküldésre kerül az LLM (Large Language Model) feldolgozónak
A válasz – SQL utasítás formájában – visszaérkezik az APEX Assistanthoz

Mivel az APEX alkalmazásokban minden megjelenített elem, oldal, felhasználói szokás, beállítás – ugyanúgy mint maguk az adatok – az adatbázisban tárolódnak és lekérdezhetőek, így a nyelvi modellt semmi sem akadályozza meg abban, hogy idővel mégjobb válaszokat adjon a kérdéseinkre.
Mindez nagyon izgalmas jövőt vetít előre nemcsak az alkalmazásfejlesztésre de az alkalmazások használatára vonatkozóan is.

Az APEX alacsony kódolási igényő keretrendszert használva egyre inkább elmosódik a határ a fejlesztők és felhasználók, a szállítók és megrendelők, az IT és az üzleti területek között, sokkal inkább egy olyan szoros kollaboráció jön létre, amely minden vállalat számára az elérhető leghatékonyabb informatikai megoldásokat eredményezi.
A cikk az Oracle blogbejegyzése alapján készült.