Integráció API nélkül: régi és legacy rendszerek összekötése

A modern informatikában az adatok szinkronizálásának "Arany Standardja" a REST API (vagy a GraphQL). Amikor egy informatikus azt hallja, hogy egy szoftverhez Nincs API, sokszor automatikusan kijelenti: "Akkor nem lehet integrálni." Ez azonban üzleti szempontból ritkán igaz.

Amikor az adott szoftvergyártó (Vendor) azt mondja, hogy nincs API, az valójában több dolgot is jelenthet:

• Tényleg egy 20 éves, zárt "feketedoboz" a szoftver.
• Van API-ja, de nincs hozzá nyilvános (publikus) dokumentáció, ezért a szállító letagadja.
• Van API-ja, de csak egy külön (több milliós) licencdíj (Vendor Add-on) megfizetése után hajlandóak bekapcsolni.
• Nincs modern webes API, de van egy parancssoros (CLI) eszköze, vagy belső SDK-ja.

Az integrációs szakember feladata, hogy feltérképezze az alternatív, úgynevezett Workaround (Kerülőutas) adatkapcsolatokat. Lássuk a lehetőségeket a legbiztonságosabbtól a legkockázatosabbig haladva.

Minden asztali (Desktop) vagy zárt szoftver mögött (legyen az egy 15 éves könyvelőprogram vagy egy raktárszoftver) végső soron egy Adatbázis (Microsoft SQL Server, MySQL, PostgreSQL, Firebird) fut. Bár az alkalmazásnak nincs API-ja, az alatta lévő adatbázishoz (DB) általában közvetlenül hozzá lehet férni.

• Közvetlen Olvasás (Read-only DB Access): Ez egy nagyon stabil integráció. Ha a CRM-nek szüksége van az ERP-ben lévő készletadatra, egy integrációs script egyszerűen futtat egy SELECT lekérdezést az ERP adatbázisán. (Sokszor gyorsabb és stabilabb, mint egy API).
• Közvetlen Írás (Direct Write): Ez az abszolút vörös zóna! Egy idegen szoftver adatbázisába kívülről (az üzleti validációs réteg megkerülésével) adatot írni (pl. INSERT INTO) hatalmas kockázat. Ha az adatbázis struktúrája sérül (pl. nem jön létre a hozzá tartozó log rekord), az egész ERP összeomolhat. Szigorúan csak akkor írjunk direktben adatbázist, ha a Vendor ahhoz támogatott, dedikált Staging (Köztes) táblákat ad.

Ha az adatbázisba sem engednek be, a második legstabilabb út a "hivatalos" fájl export (CSV, XML, TXT). Sok régebbi ipari szoftver (és a legtöbb bank) a mai napig erre épül.

Hogyan lesz a fájlból integráció?

1. A régi rendszer minden éjjel 23:00-kor legenerálja (Scheduled Job) az aznapi mozgásokat egy export_20260911.csv nevű fájlba.
2. Ezt a fájlt lerakja egy biztonságos, jelszóval védett szerverre (SFTP, Hálózati Mappa / Watched Directory, vagy AWS S3).
3. A modern (Cél) rendszer integrációs motorja érzékeli az új fájlt, beolvassa, átdolgozza az adatokat, és feltölti a célrendszerbe.

Mikor jó ez? Kiváló olyan adatokhoz, ahol nem kell Valós Idejű (Real-Time) adat, és elég a napi (Batch) szinkronizáció (Pl. Bérszámfejtés, Előző napi eladások).

Meglepő, de a világ kereskedelmének egy jelentős része e-maileken keresztül van "integrálva". Ha a Partner régi rendszere (pl. egy régi beszállító programja) sem API-t, sem FTP-t nem tud kezelni, de e-mailben ki tudja küldeni a rendelésigazolást, azt automatizálni lehet.

• Egy háttér-script folyamatosan olvassa (IMAP) a dedikált fiókot (pl. [email protected]).
• Kicsomagolja a mellékletet (XML, PDF, Excel), és feldolgozza (Parse).

A kockázatok: Az e-mail nem garantált kézbesítésű. A levelek spambe kerülhetnek (Deliverability), a levél mérete (Attachment Limit) korlátozott, és a Sender Spoofing (amikor valaki hamis feladóval küld számlát) miatt extra biztonsági validációt igényel.

Ha sem API, sem Adatbázis, sem Export nem létezik, és az adott szoftvernek kizárólag Asztali (Desktop) vagy Böngészős (Web UI) felülete van, akkor jön képbe az RPA (Robotic Process Automation). A robot (A Script) szó szerint ugyanazt csinálja, amit az ember: Bejelentkezik a jelszóval (Login), kattint az egérrel, navigál a menüben, és kiolvassa (Screen Scraping) az adatokat a képernyőről.

Miért kell ezt a módszert a legutolsó helyre sorolni? Mert hihetetlenül törékeny (Fragile).

• Ha a szoftvergyártó frissíti a böngészős felületet (UI), és a "Mentés" gomb balról jobbra kerül, a robot eltörik, és az integráció leáll (Selector Issues).
• Ha felugrik egy váratlan Hibaüzenet (Pop-up), a robot nem tudja értelmezni, és lefagy (Screen State).
• Az automatizálást gyakran megtöri a kétfaktoros hitelesítés (MFA / Captcha), ami direkt arra van kitalálva, hogy távol tartsa a robotokat.

Ha egy régebbi, API nélküli szoftvert drótózunk össze egy modern rendszerrel (pl. E-mail vagy UI automatizáción keresztül), borítékolható, hogy az adatok sokszor formázatlanok lesznek. (A képernyőről leolvasott ügyfélnév összeolvad a címmel). Ilyenkor a kinyert "piszkos" (Raw) adatokat érdemes egy AI Modellen (LLM) átküldeni (Data Cleansing) mielőtt a célrendszerbe írnánk. Az AI kiválóan osztályozza a váratlan hibákat (Exception Classification), de fontos: Ne az AI legyen a törékeny UI-automatizálás "javító vakolata". Ha a robot nem tudja, hol kell kattintani, az egész folyamatot újra kell tervezni.

Mielőtt egy integrációs projektet elindít egy olyan rendszernél, amihez látszólag nincs hozzáférés, ezen a logikai útvonalon kell végigmenni, és az első "Igen"-nél megállni:

1. Meg lehet vásárolni az API Modult a gyártótól? → HA IGEN, vegye meg (Megéri).
2. Van biztonságos automatizálható CSV/XML Export? → HA IGEN, építsünk fájl-alapú folyamatot.
3. Hozzáférünk az (On-Premise) Adatbázishoz (Csak Olvasás)? → HA IGEN, írjunk SQL Scriptet.
4. Van a szoftvernek stabil, nem változó Képernyője/Böngészője? → HA IGEN, vizsgáljuk meg az RPA lehetőségét.
5. Nincs egyik sem? → Rendszercsere szükséges. Ezt a szoftvert le kell cserélni.

A mérnökök szinte bármit össze tudnak drótozni, a kérdés csak a karbantartási (Maintenance) költség. Ha egy vállalat egy kritikus (pl. gyártásirányító) szoftverét azért kell 3 darab törékeny RPA robottal, naponta leálló hálózati mappákkal és Screen Scrapinggel (Képernyő-olvasással) életben tartani, mert "2008-ban ezt szoktuk meg", akkor a workaround (megoldás) többe kerül, mint maga a licenc.

Egy szoftvert azonnal le kell cserélni (Decommission), ha:

• A gyártó már nem ad ki hozzá biztonsági frissítést (End of Life - EOL), ami óriási biztonsági (Compliance) kockázat.
• Nincs hozzá biztonságos hálózati hozzáférés.
• Az integrációk 80%-a emberi beavatkozást és állandó javítást igényel.

"Amikor egy vállalatvezető azzal keres meg minket, hogy 'itt van ez a 15 éves régi rendszer, nincs API-ja, de automatizálni kellene', az első válaszunk, hogy az API hiánya nem feltétlenül üzleti követelmény, hanem csak technikai akadály. A célunk sosem az, hogy bármi áron, 10 réteg 'sufnituning' kóddal automatizáljuk az öreg felületet. A cél, hogy megtaláljuk a legstabilabb, még támogatott adatkapcsolatot (pl. az adatbázist). Ha viszont a folyamat üzletkritikus, és az egyetlen integrációs útvonal az napi szinten törő UI-automatizálás (robot), akkor a vezetésnek komolyan össze kell vetnie az integráció (és a leállások) fenntartási költségét egy modern rendszer bevezetésének (csere) költségével."