API gateway vagy pont-pont integráció vállalatoknak

Egy webshop rendelése reggel bekerül az ERP-be, onnan a raktári rendszerbe, majd a számlázóba és a futárszolgálat rendszerébe. Amíg ez két-három kapcsolatból áll, a folyamat többnyire láthatatlanul működik. Néhány év növekedés után azonban új értékesítési csatornák, beszállítói kapcsolatok, ügyfélportálok és riportingigények jelennek meg. Ekkor az API gateway vagy pont-pont integráció kérdése már nem pusztán informatikai döntés: meghatározza, mennyire átlátható és fenntartható a működés.

A rossz döntés ritkán okoz azonnali leállást. Inkább fokozatosan jelenik meg: egy adatmezőt három helyen kell módosítani, egy rendszerfrissítés után váratlanul hibázik a rendelésátadás, és senki sem tudja pontosan, melyik kapcsolat felel egy eltűnt státuszért. Ilyenkor az üzleti folyamat látszólag rendszerek között fut, valójában viszont emberek tartják össze ellenőrzésekkel, e-mailekkel és táblázatokkal.

Mit jelent a pont-pont integráció?

Pont-pont integrációról akkor beszélünk, amikor két rendszer közvetlenül kommunikál egymással. Például a webshop elküldi a rendelési adatokat az ERP-nek, az ERP pedig továbbítja a készletinformációt a webshop felé. Mindkét kapcsolat saját szabályokkal, adatformátummal, jogosultságkezeléssel és hibakezeléssel működhet.

Ez a megközelítés nem hibás, sőt sok esetben a legésszerűbb választás. Ha egy vállalatnak egyetlen webshopja, egy ERP-je és egy világosan körülhatárolt adatcseréje van, a közvetlen kapcsolat gyorsan megvalósítható, könnyen érthető és arányos költségű lehet. Nem érdemes központi integrációs réteget építeni csak azért, mert technológiailag elegánsabbnak tűnik.

A probléma a kapcsolatok számának növekedésével kezdődik. Ha ugyanahhoz az ERP-hez webshop, CRM, raktári rendszer, szállítmányozó, beszállítói platform, BI-rendszer és ügyfélportál kapcsolódik, minden új kapcsolat saját függőséget hoz létre. Egy ERP-adatstruktúra módosítása ilyenkor nem egy fejlesztési feladat, hanem több rendszer és több üzleti folyamat összehangolása.

A pont-pont modellben gyakori, hogy ugyanaz az üzleti szabály több helyen jelenik meg. A rendelési státuszok átalakítása, a partneradatok tisztítása vagy a cikktörzs mezőinek megfeleltetése külön-külön bekerülhet minden integrációba. Ez nemcsak fejlesztési többletmunkát jelent. A későbbi hibaelhárítás is lassul, mert a vállalatnak először meg kell értenie, hol született az eltérés.

Mit ad egy API gateway?

Az API gateway egy központi belépési és szabályozási réteg a rendszerek közötti kommunikációban. Ahelyett, hogy minden alkalmazás közvetlenül érné el az összes többi rendszert, a külső és belső kérések meghatározott, felügyelt útvonalon haladnak át.

Üzleti nyelven ez azt jelenti, hogy a vállalat nem különálló technikai kapcsolatok halmazát kezeli, hanem kialakítja a rendszerkommunikáció rendjét. Meghatározható, ki milyen adatot kérhet le, milyen formátumban, milyen gyakorisággal, milyen jogosultsággal és milyen naplózás mellett. Egy új partneri felületnek vagy mobilalkalmazásnak nem kell közvetlen hozzáférést kapnia a belső ERP-hez csak azért, hogy készletet vagy rendelési státuszt lásson.

A gateway különösen értékes ott, ahol a hozzáférés és az üzembiztonság üzleti kockázat. Központilag kezelhető a hitelesítés, a jogosultság, a forgalmi korlátozás, a naplózás és a hibák megfigyelése. Ha egy külső rendszer hibásan ismétel meg egy kérést, nem terheli korlátlanul a belső rendszert. Ha egy partner hozzáférése megszűnik, nem kell több különálló kapcsolatban keresni a jogosultságait.

Fontos különbség, hogy az API gateway nem feltétlenül old meg minden integrációs feladatot. Nem automatikus adatminőség-javító eszköz, nem helyettesíti a folyamatok tisztázását, és nem döntheti el, melyik rendszer legyen egy adat hivatalos forrása. Ha a vevőadatok a CRM-ben, az ERP-ben és egy régi ügyfélnyilvántartásban is eltérnek, a gateway csak rendezettebben továbbíthatja az eltérést.

API gateway vagy pont-pont integráció: a döntés valódi szempontjai

A kérdésre nem az a jó válasz, hogy minden kapcsolatot központba kell terelni. Az a jó válasz, amelyik illeszkedik a vállalat folyamatainak összetettségéhez, változási üteméhez és kockázataihoz.

Pont-pont kapcsolat általában akkor indokolt, ha az adatcsere egyszerű, két rendszer között marad, ritkán változik, és nincs érzékeny külső hozzáférés. Egy termelési gép által naponta átadott, szűk körű adatállomány vagy egy egyedi fuvarozói címkenyomtatási kapcsolat esetén a közvetlen integráció lehet jól dokumentált és üzembiztos megoldás.

API gateway felé mutat a helyzet, ha ugyanazokat a szolgáltatásokat több rendszer, partner vagy csatorna használja. Tipikus példa, amikor a webshop, az ügyfélportál és az értékesítői alkalmazás egyaránt rendelési státuszt, készletet vagy ügyféladatot kér. Ilyenkor üzletileg sem célszerű, hogy mindegyik közvetlenül az ERP belső működéséhez igazodjon. Célszerűbb egy stabil, szabályozott szolgáltatási felületet kialakítani, amely mögött a belső rendszer később is módosítható.

A változás költsége szintén döntő szempont. Egy közvetlen kapcsolat kezdetben olcsóbbnak látszhat. De ha minden új csatorna külön fejlesztést, külön biztonsági ellenőrzést és külön hibakeresést igényel, a rövid távú egyszerűség hosszú távon drága lehet. Ezzel szemben egy gateway bevezetése kezdetben több tervezést és fegyelmezettebb architektúrát kér. Akkor térül meg, amikor a vállalatnak nem egyetlen kapcsolatot, hanem ismétlődően új kapcsolódásokat kell kezelnie.

Előbb az adat és a folyamat legyen tiszta

Sok integrációs projekt azért csúszik meg, mert a technikai kérdések megelőzik az üzleti tisztázást. Mielőtt eldőlne az architektúra, érdemes végigkövetni egy konkrét folyamatot: mi történik a rendelés beérkezésétől a kiszállításig, ki módosíthatja az adatot, hol keletkezik új információ, és melyik rendszerben válik az adat véglegessé.

Ha például a raktár az ERP készletét használja, de a webshop saját szabályok szerint mutat elérhetőséget, nem technikai részletkérdés, hogy melyik adat látszik a vásárlónak. Ez közvetlenül befolyásolja a rendelhetőséget, a vevői kommunikációt és a reklamációk számát. Az integráció csak akkor lesz megbízható, ha ezek a felelősségi és üzleti szabályok egyértelműek.

Ugyanez igaz a hibakezelésre. Mi történik, ha a számlázó rendszer átmenetileg nem elérhető? Megáll a rendelésfeldolgozás, várakozó sorba kerül az adat, vagy valaki kézzel próbálja pótolni? Ki kap értesítést, és mikor tekinthető egy hiba megoldottnak? A működő integráció nem attól jó, hogy normál helyzetben adatot küld, hanem attól, hogy rendellenes helyzetben is ellenőrizhető marad.

A fokozatos rendezés gyakran jobb, mint az átépítés

Egy növekvő vállalatnál nem reális elvárás, hogy minden meglévő kapcsolatot egyszerre újratervezzenek. Ráadásul a kritikus működést kiszolgáló integrációk esetében a túl nagy átalakítás komoly üzletmeneti kockázatot jelenthet.

Ésszerűbb lehet először feltérképezni a kapcsolatokat: melyik milyen adatot mozgat, ki használja, mennyire kritikus, ki felel érte, és van-e róla naprakész dokumentáció. Már ez a munka feltárhatja, hogy egyetlen munkatárs tudja, miért fut egy régi adatátadás, vagy hogy két rendszer között párhuzamosan, eltérő szabályokkal mozog ugyanaz az információ.

Ezután a legtöbb értéket adó területekkel érdemes kezdeni. Lehet, hogy egy új ügyfélportálhoz már indokolt gateway-alapú hozzáférést kialakítani, miközben két régi, stabil belső kapcsolat egyelőre közvetlen marad. A cél nem egy technológiai minta követése, hanem a kontroll, a karbantarthatóság és a változtathatóság fokozatos javítása.

A jó rendszerarchitektúra végül nem attól értékes, hogy hány modern komponens szerepel benne. Attól értékes, hogy egy rendelés, egy készletadat vagy egy számla útja érthető, ellenőrizhető és akkor is működőképes marad, amikor a vállalat következő növekedési lépése megérkezik.