Pillér oldal

Rendszerintegráció vállalatok számára

ERP-t, CRM-et, számviteli, bér- és HR-rendszereket, KRS-t, MS Graphot, Salesforce-t és SAP-t kötünk össze. Integrációk API-n, üzenetsorokon, ETL-en és webhookokon keresztül — teljes minőségellenőrzéssel, audit trail-lel és produkciós monitoringgal.

Integrációs projekt egyeztetése Minden szolgáltatás

Egy átlagos cég tucatnyi vagy több tucat üzleti alkalmazást használ. Mindegyik ugyanazon adatok egy-egy szeletét tárolja — ügyfél, számla, munkavállaló, megrendelés. Integráció nélkül a munkavállalók napi órákat töltenek azzal, hogy kézzel másolják, exportálják és importálják az adatokat a rendszerek között.

A rendszerintegráció nem luxus — ez a digitális transzformáció alapja. Jól tervezett integrációval: a CRM-be felvett ügyfél emberi beavatkozás nélkül megjelenik az ERP-ben, a könyvelésben kiállított számla frissíti a vezérigazgató pénzügyi dashboardját, a megrendelés státusza konzisztens a webáruházban, a raktárban és az ügyfélszolgálaton.

Miért nehezek az integrációk?

Minden rendszernek saját adatmodellje, saját elnevezése van ugyanazoknak a mezőknek, saját műveletsorrendje, saját API-korlátai (limitek, késések, átmeneti hibák). Két rendszer elméletben „kompatibilisnek" tűnhet, a gyakorlatban azonban hetekig tartó munkát igényelhetnek a leképezések, transzformációk, edge-case-ek kezelése és a konfliktusok feloldása.

A második nehézségi réteg a produkciós megbízhatóság. Egy dev környezetben helyesen működő integráció az út ~30%-a. A maradék 70% a kivételes helyzetek kezelése: a külső rendszer elérhetetlen, megváltoztatta az API-szerződést, váratlan adatokat ad vissza, új ügyfelet vittünk be a CRM-be magyar ékezetekkel, amelyeket a régi ERP nem kezel. Minden ilyen eset átgondolást, tesztet és riasztást igényel, ha előfordul.

Integrációtípusok

Hat alapvető minta. A legtöbb projektben többet kombinálunk, az adott helyzethez illesztve a módszert.

REST API / GraphQL

Szinkron kommunikáció az alkalmazások között. JSON mint csereformátum, OAuth2/JWT az autorizációhoz, OpenAPI/Swagger a dokumentációhoz. A leggyakoribb választás modern, felhőalapú rendszerekhez.

Üzenetsorok

RabbitMQ, Redis Streams, Kafka — aszinkron csere, amikor a küldő nem várja meg a fogadót. Ideális értesítésekhez, üzleti eseményekhez, hosszan futó műveletekhez. Garantált kézbesítés + retry.

ETL / ELT

Adatok kötegelt betöltése adattárházba (Snowflake, BigQuery, Redshift, helyi PostgreSQL). Airflow vagy dbt mint orchestrator, adatminőségi validáció (Great Expectations), lineage monitoring.

Webhookok

Push értesítések a forrásrendszerből (Stripe, GitHub, Slack, Salesforce) a saját alkalmazásunkba. HMAC signature verification, idempotencia, dead-letter queue a sikertelen kézbesítésekhez.

SOAP / XML

Régebbi enterprise rendszerek (SAP, Oracle, banki, biztosítói) — teljes WSDL támogatás, XSD validáció, WS-Security. Adapter a rendszer többi része felé modern protokollokkal.

Adatbázisok — replikáció, CDC

Change Data Capture (Debezium, AWS DMS) a változások streaming replikációjához forrás- és célbázis között. Logical replication PostgreSQL-ben a magas rendelkezésre álláshoz és riportokhoz.

Hat kulcsfontosságú produkciós kihívás

Dolgok, amelyekre minden integrációs projektben figyelünk. Bármelyik elem hiánya = időzített bomba.

Idempotencia

Minden többszöri lekérdezés ugyanazt az eredményt adja. Idempotency-kulcsok a fejlécben, deduplikáció alkalmazás szintjén, tranzakciók a kritikus műveletek körül.

Retry és backoff

Az átmeneti hálózati hibák normálisak. Exponential backoff (1s, 2s, 4s, 8s...), jitter a thundering herd elkerülésére, circuit breaker N sikertelen próba után.

Leképezés és transzformációk

Az A rendszer a mezőt „client_id"-nek, a B „customerId"-nek, a C „id_klienta"-nak hívja. Központi leképezési katalógus, transzformációk egy helyen, minden transzformáció tesztelve.

Eventual consistency

Két rendszer adatai sosem konzisztensek 100%-ban valós időben. Elfogadjuk a késéseket (tipikusan másodpercek), monitorozzuk a driftet, riasztunk hosszabb eltéréseknél.

Audit és compliance

Minden integrációs művelet rögzíti: ki/mit/mikor/honnan/hová, payload (anonimizálva, ha PII-t tartalmaz), eredmény. Az audit log teljesíti a GDPR és ISO 27001 követelményeit.

Skálázás és költségek

Az integrációk a vállalkozással együtt nőnek. Horizontal scaling (több instance), rate limiting (védelem a túlzott kérések ellen), költségmonitoring integrációnként.

Hogyan valósítunk meg egy integrációs projektet

  1. Discovery (1-2 hét): a jelenlegi adatáramlások feltérképezése, az igazság forrásainak azonosítása minden entitásra, API-szerződések összegyűjtése, kockázatok és függőségek értékelése.
  2. Architecture design (1 hét): minták kiválasztása (szinkron vs aszinkron, push vs pull, hub-and-spoke vs point-to-point), audit log séma, monitoring terv.
  3. Pilot egy entitáson (2-3 hét): integrációt valósítunk meg egy adattípusra (pl. ügyfelek) end-to-end. Szerződések validálása, terheléstesztek, dry-run a tesztkörnyezetben.
  4. Bővítés a többi entitásra (4-8 hét): további szinkronizációk (számlák, megrendelések, termékek) ugyanazzal a mintával. Minden bevezetést Change Request és regressziós tesztek előznek meg.
  5. Historikus migráció (1-3 hét): a meglévő adatok átvitele. Dry-run, audit, rollback terv. Inkrementális migráció vagy szervizablakban.
  6. Hypercare (4 hét produkció után): intenzív monitorozás, gyors reagálás incidensekre, riasztások finomhangolása. Hypercare után átállás standard üzemeltetésre.

Megvalósított integrációk példái

KRS + CRBR — RejestrFirm

Mikroszolgáltatás, amely összekapcsolja a lengyel Cégbíróság (740 ezer+ cég) adatait a Tényleges Tulajdonosok Központi Nyilvántartásával. Smart caching (24 óra), dual-source automatikus fallbackkal, 15+ REST végpont. KYC folyamatokban, partnerek ellenőrzésében, compliance riportok generálásában használjuk.

SSO több alkalmazással

Központi Keycloak platform (eskom-ai realm), amely tucatnyi ügyfélalkalmazással integrálva van. OAuth2/OIDC + PKCE, social login (Google, Microsoft, Apple, Facebook), felhasználói provisioning, LLM tokenfelhasználáson alapuló számlázás. Single sign-on az összes ESKOM AI termékhez.

Microsoft Graph — naptár, e-mail, OneDrive

Microsoft 365 integráció a naptár automatizálásához (MI-asszisztens által szervezett megbeszélések), tranzakciós e-mailek küldéséhez, dokumentumok archiválásához. OAuth2 delegated permissions-szel, refresh tokenek Vaultban, Graph API rate limit monitoring.

LLM Proxy — multi-provider routing

Központi üzenetsor, amely több LLM-szolgáltatót köt össze (Anthropic, OpenAI, helyi Ollama). Feladatonkénti routing (apró feladatok — helyi modell, bonyolultak — Claude Opus), válaszcache, költségmonitoring projektenként, fail-over a szolgáltatók között.

Gyakran ismételt kérdések

Mit jelent a rendszerintegráció?
A rendszerintegráció két vagy több alkalmazás olyan összekapcsolásának folyamata, hogy adatokat tudjanak cserélni, eseményeket tudjanak egymásban kiváltani és megőrizzék az információk konzisztenciáját. A gyakorlatban: amikor egy ügyfelet hozzáadnak a CRM-hez, automatikusan megjelenik az ERP-ben; amikor a könyvelésben kiállítanak egy számlát, az adatok átkerülnek a CRM-be és az analitikába. Integráció nélkül a cég kézzel zsonglőrködik az adatokkal (CSV-exportok, másolás rendszerek között), ami hibákat, késedelmeket és költségeket okoz.
Milyen integrációs technológiákat alkalmaznak?
A technológia kiválasztása a kontextustól függ: REST API és webhookok modern felhőrendszerekhez, SOAP/XML régebbi ERP-khez/banki rendszerekhez, message queues (RabbitMQ, Redis Streams, Kafka) az aszinkron cseréhez, ETL/ELT az adattárházak feltöltéséhez, GraphQL amikor az ügyfél rugalmasságot szeretne. Gyakran kombináljuk a megközelítéseket — szinkron ott, ahol a felhasználó vár az eredményre, aszinkron ott, ahol a throughput számít.
Elromlanak az integrációk a forrásrendszerek frissítésekor?
Ez az integrációk egyik legnagyobb problémája — ezért építünk izolációval rendelkező adaptereket (anti-corruption layer). A külső rendszer megváltoztatja a szerződést → csak az adapter változik, az integráció többi része nem. Ráadásul: a szerződések verziózva vannak (v1, v2), az integrációs tesztek naponta futnak sandbox API-kon, Sentry/Wazuh riasztások figyelik a válaszformátum változásait. Az ügyfél azelőtt értesül a problémáról, hogy az eljutna a felhasználókhoz.
Mennyi időt vesz igénybe egy tipikus integráció?
Egyszerű integrációkat (egyik rendszer a másikkal, ~5 végpont, egyirányú szinkronizáció) 1-2 hét alatt valósítunk meg. A bonyolultak (kétirányú szinkronizáció, tucatnyi entitás, leképezések, transzformációk, deduplikáció) 4-8 hetet vesznek igénybe. Több rendszerrel egyidejű integrációkat (hub-and-spoke) fázisokban tervezünk, 2-3 hetes iterációkban szállítva üzleti értéket.
Mi történik a historikus adatokkal egy új integráció esetén?
Minden integrációs projektnek külön szakasza van a historikus migrációra. Először teljes elemzés: hány rekord, milyen adattípusok, hol vannak duplikátumok, mely mezők kötelezők és melyek opcionálisak. Aztán migrációs szkript dry-run-nal, audit trail-lel (mi került átvitelre, mi lett elutasítva és miért) és rollback tervvel. A migráció szervizablakban vagy inkrementálisan történik, az üzleti kockázattól függően.
Az integrációnak 24/7 működnie kell?
Az üzleti kritikusságtól függ. Az online folyamatok (fizetések, autorizációk) magas rendelkezésre állást igényelnek — redundanciával tervezzük (load balancer, multiple instances, health checks, auto-restart). Az éjszakai folyamatok (riportok, kötegelt szinkronizációk) szervizablakokban futhatnak. Minden integrációt SLA-ban kategorizálunk: p95 válaszidő, elfogadható havi downtime, RTO/RPO.
Hogyan monitorozzák a produkciós integrációkat?
Minden integráció Prometheus-nak küldi a metrikákat (request rate, error rate, latency p50/p95/p99), a logokat központi SIEM-nek (Wazuh), a hibákat Sentry-nek. Riasztások a throughput csökkenésekor, az error rate emelkedésekor vagy timeoutoknál. A dashboard egy helyen mutatja az összes integráció állapotát — az operátor látja, hogy pl. az X szolgáltatóval való integrációnál 3% a hibaarány, miközben a többi simán működik.
Mi a helyzet a biztonsággal a külső integrációknál?
Minden integráció a legkevesebb szükséges jogosultságot használja (least privilege). A kulcsokat és tokeneket HashiCorp Vaultban tároljuk (nem .env fájlokban, nem a kódban). A kommunikáció mindig TLS 1.2+ felett, a tanúsítványokat ellenőrizzük (soha nem verify=False). A bejövő webhookok HMAC signature verification-nel vannak ellátva. Token szivárgás esetén — azonnali rotáció, az audit log megmutatja, mit és mikor csináltunk.
Miben különbözik az ESKOM AI integrációja a klasszikus ESB-től (Enterprise Service Bus)?
A klasszikus ESB (Mule, BizTalk, WebMethods) monolitikus platform, drága licencekkel, dedikált csapatot igényel. A mi modellünk: integrációs mikroszolgáltatások, minden integráció külön komponens saját deploy-jal és monitoringgal, az infrastruktúra open source alapokon (FastAPI, RabbitMQ, Redis, PostgreSQL, Vault). Alacsonyabb licencköltség, könnyebb karbantartás, nincs vendor lock-in. Egyes ügyfeleknek ez pénzügyi érv, másoknak — stratégiai.
Integrálódnak lengyel közigazgatási rendszerekkel (KRS, CRBR, KSeF, ePUAP)?
Igen. Produkcióban van egy mikroszolgáltatásunk, amely a KRS-szel és CRBR-rel integrálódik (rejestrfirm.eskom.ai — 740 ezer+ cég adatai tényleges tulajdonosokkal). KSeF (e-számlázás) — kész integrációs komponenseink vannak a Kontroling projektben. ePUAP, e-Kézbesítés — Microsoft Graph API-n és közvetlen integrációkon keresztül elérhetők. Teljes megfelelés a lengyel joggal (GDPR, beszámolási kötelezettségek).

Van integrációs projektje?

Ingyenes audittal kezdünk — feltérképezzük a jelenlegi adatáramlásokat, azonosítjuk a szűk keresztmetszeteket és világos szakaszokra bontott tervet javasolunk.

Integrációs audit egyeztetése Termékeink