Ugrás a fő tartalomra
FromNine
Menü

Fejlesztés

Integrációk, amelyek mozgásban tartják az adatokat, és jelzik, ha elakadnak.

CRM-, ERP- és ügykezelő rendszereket, valamint állami rendszereket, például a NAV Online Számla rendszerét, kötünk össze szerződésekkel, eseményekkel és szakszerű identitáskezeléssel, hogy az adatok megbízhatóan mozogjanak, a hibák látszódjanak, és új képességek, köztük az MI, biztonságosan kapcsolódhassanak.

Olyan szervezeteknek, amelyek rendszereket, partnereket és állami platformokat kapcsolnak össze Magyarországon és a csoport más tagállamaiban.

Beszéljük meg a projektjétPlatformok
Integrációk és API-k: képességrétegekNégy egymásra épülő réteg. Fentről lefelé: a felhasználóoldali rendszerek, például portálok, alkalmazások és MI-ügynökök, az API-átjáró identitáskezeléssel, az eseménygerinc, alul pedig a nyilvántartó rendszerek.01Portálok, alkalmazások és MI-ügynökök02API-átjáró és identitás03Eseménygerinc04Nyilvántartó rendszerek
  1. 01Szerződésalapú API-k OpenAPI és AsyncAPI leírással, verziózva és dokumentálva
  2. 02Események sorrendkezeléssel, idempotenciával, hibasorral és visszajátszással
  3. 03Elejétől a végéig figyelt adatfolyamok, a hibasorokért megnevezett csapatok felelnek

01 Problémák

Integrációs problémák, amelyekhez hívnak minket

  1. 01

    Pont-pont kapcsolatok, amelyekhez senki sem mer nyúlni

    Rengeteg közvetlen kapcsolat a CRM, az ERP és az egyedi rendszerek között. Egy mező módosítása tíz interfész tesztelését jelenti.

  2. 02

    Ismétlődések és csendes hibák

    Egy újrapróbálás második rendelést hoz létre. Egy sikertelen üzenet eltűnik. Az üzleti felhasználók az ügyfelektől tudják meg.

  3. 03

    Minden új csatorna új integrációs munkát jelent

    A portálnak, a mobilalkalmazásnak és most egy MI-asszisztensnek is ugyanazok az adatok kellenek, és mindegyik saját kivonatot kap.

  4. 04

    Az állami rendszerek bekötése külön projekt

    Egy állami rendszer vagy elektronikus azonosítási szolgáltatás bekötése minden alkalommal hosszú biztonsági és csatlakozási munka, és a NAV felé küldött számlaadatok hibáit sokszor kézzel javítják.

02 Szállítási tételek

Amit szállítunk

  1. 01 API-stratégia és API-menedzsment

    API-first tervezés OpenAPI és AsyncAPI szerződésekkel, verziózási szabályzat, egy átjáró, amely érvényesíti, és egy fejlesztői portál, hogy a csapatok megtalálják és újrahasznosítsák, ami már létezik.

    Amit csinálunk

    • API-térkép és felelősségi térkép
    • Tervezési irányelvek és felülvizsgálati folyamat
    • Átjárószabályok a biztonságra, a kvótákra és a verziózásra
    • Fejlesztői portál és API-katalógus

    Amit Ön kap

    • A csapatai által elfogadott API-irányelvek
    • Átjárókonfiguráció kódként
    • Dokumentált API-k katalógusa

  2. 02 Eseményvezérelt integráció

    Üzenetközvetítők, változásalapú adatrögzítés és az outbox minta, azokkal a részletekkel, amelyeken a működés múlik: sorrend, idempotens fogyasztók, hibasorok és visszajátszás.

    Amit csinálunk

    • Eseménymodell és elnevezési konvenciók
    • Outbox és CDC a forrásrendszereken
    • A fogyasztók idempotenciája és sorrendgaranciák
    • Hibasorok visszajátszó eszközökkel

    Amit Ön kap

    • Eseménygerinc éles üzemben
    • Sémaregiszter és kompatibilitási szabályok
    • Visszajátszási és helyreállítási útmutató

  3. 03 Integrációs platformok adatfolyamonként választva

    Az SAP Integration Suite-nek, a MuleSoftnak és a felhőnatív integrációs szolgáltatásoknak is megvan a helyük. Megmondjuk, mikor jobb egy iPaaS az egyedi kódnál, és mikor nem.

    Amit csinálunk

    • A meglévő köztes szoftverek felmérése
    • Platformválasztás a teljes birtoklási költség alapján
    • Újrahasznosítható leképezések és csatlakozók
    • Migráció az örökölt köztes szoftverekről

    Amit Ön kap

    • Döntési feljegyzés az integrációs platformról
    • Integrációs mintakönyvtár
    • Migrációs terv a meglévő interfészekre

  4. 04 Identitás és bizalom a rendszerek között

    OAuth 2.0 és OpenID Connect, kölcsönös TLS, szolgáltatások közötti identitás, valamint az állampolgári és üzleti elektronikus azonosítás bekötése: Magyarországon az Ügyfélkapu+ és a DÁP-alkalmazás, más tagállamokban az ottani nemzeti eID-rendszerek.

    Amit csinálunk

    • Identitásarchitektúra felhasználóknak és szolgáltatásoknak
    • Tokentervezés, jogosultsági körök és hozzájárulás
    • Támogatás az eID-csatlakozásban és a tanúsításban
    • Felkészülés az európai digitális személyiadat-tárcákra

    Amit Ön kap

    • Identitásterv és fenyegetésmodell
    • eID-integráció éles üzemben
    • Működő szolgáltatásidentitás és titokrotáció

  5. 05 Állami rendszerek és interopera­bilitás

    A NAV Online Számla rendszerébe irányuló valós idejű számlaadat-szolgáltatás, EN 16931 szerinti e-számlák az ajánlatkérőknek, az elektronikus ügyintézés belépési szolgáltatásai, a csoport más tagállamaiban működő adatcsere- és e-számla-csatornák, például a Peppol, valamint az uniós egyszeri adatszolgáltatás technikai rendszere (OOTS).

    Amit csinálunk

    • Csatlakozás és regisztráció a rendszer üzemeltetőjénél
    • Leképezés a hazai és uniós adatszabványokra
    • Az egyes rendszerek biztonsági és naplózási követelményei
    • Az egyszeri adatszolgáltatás elvén alapuló bizonyítékcsere tervezése

    Amit Ön kap

    • Éles, tesztelt kapcsolat a rendszerrel
    • Leképezési dokumentáció
    • Üzemeltetési eljárások az üzemeltetővel egyeztetve

  6. 06 Üzemeltetési átláthatóság az üzleti felhasználóknak

    Az üzleti felhasználók számára is olvasható adatfolyam-figyelés, egyeztetés a rendszerek között és hibasorok, amelyekért valaki felel, és amelyeket fel is dolgoz.

    Amit csinálunk

    • Üzleti szintű adatfolyam-figyelés
    • Egyeztető jelentések a rendszerek között
    • Hibák besorolása és irányítása
    • Riasztás adatfolyam-gazdánként

    Amit Ön kap

    • Integrációs irányítópult üzleti folyamatonként
    • Éles egyeztető ellenőrzések
    • Felelősségi térkép minden hibasorhoz

03 Architektúra

Szemléltető referencia­architektúra

Két út indul a nyilvántartó rendszerekből. A szinkron kérések rendszer-API-kon és egy átjárón haladnak át, amely ellenőrzi az identitást, a jogosultsági köröket és a kvótákat. A változások eseményként jelennek meg outboxon vagy változásalapú adatrögzítésen keresztül, a fogyasztók pedig idempotensen dolgozzák fel őket.

A sikertelen üzenetek visszajátszható hibasorba kerülnek, nem egy naplófájlba. Egy figyelősáv minden adatfolyamot üzleti fogalmakkal mutat, így a folyamat gazdái látják, ha valami megáll.

A rajz rétegei

Nyilvántartó rendszerek
Az ERP, a CRM és az ügykezelés rendelkezik a saját adatai felett.
Szinkron API-k
Verziózott rendszer-API-k egy átjáró mögött OAuth 2.0-val, mTLS-sel és kvótákkal.
Események
Outbox, üzenetközvetítő, hibasor és az integrációs platform leképezései.
Fogyasztók
Portálok, alkalmazások, MI-ügynökök, partnerek és állami rendszerek, állampolgárok esetén elektronikus azonosítással.
Szemléltető példa

  1. Nyilvántartó rendszerek

    • ERP-, CRM- és ügykezelő rendszerek

  2. Szinkron API-k

    • Rendszer-API-k
    • API-átjáró: OAuth 2.0, mTLS, kvóták

  3. Események

    • Outbox és CDC
    • Üzenet­közvetítő
    • Hibasor és visszajátszás
    • Integrációs platform leképezései

  4. Fogyasztók

    • Portálok, alkalmazások és MI-ügynökök
    • Partner- és állami rendszerek
    • Identitás: OIDC, mTLS, eID

  5. Üzemeltetés

    • Adatfolyam-figyelés, egyeztetés, gazdával rendelkező hibasorok
API-k és eseménygerinc egymás mellett

Szemléltető architektúra, nem ügyfélrendszer.

Az ábra szöveges változata

A fő útvonal a nyilvántartó rendszerektől verziózott rendszer-API-kon és egy API-átjárón át a portálokhoz, alkalmazásokhoz és MI-ügynökökhöz vezet.

Ezzel párhuzamosan a nyilvántartó rendszerek outboxon és változásalapú adatrögzítésen keresztül egy üzenetközvetítőnek adják át a változásokat, amely a partner- és állami rendszerekhez, valamint a leképezéseket végző integrációs platformhoz továbbítja őket. A sikertelen üzenetek visszajátszható hibasorba kerülnek. Az OAuth, mTLS és eID alapú identitásszolgáltatások védik a partnerkapcsolatokat.

Alul egy figyelősáv mutatja az adatfolyamok állapotát, az egyeztetést és a gazdával rendelkező hibasorokat.

04 Szempontok és korlátok

Mérnöki szempontok és korlátok

  • A pontosan egyszeri feldolgozás tervezés kérdése, nem beállításé

    Hogyan kezeljük

    Abból indulunk ki, hogy az üzenetek kétszer vagy rossz sorrendben érkeznek, és idempotens fogyasztókat tervezünk, eseménytípusonként egyeztetett kulcsokkal és sorrendszabályokkal.

    Korlátok és függőségek

    Egyes örökölt rendszerek nem fogadnak idempotenciakulcsot, és nem jelentik, mit dolgoztak fel. Ezek köré egyeztetést építünk, ahelyett hogy úgy tennénk, mintha a probléma nem létezne.

  • Egy iPaaS nem mindig a válasz

    Hogyan kezeljük

    Sok szabványos csatlakozónál és leképezésnél a platform nyer. Összetett logikánál, nagy volumennél vagy szigorú válaszidőnél az egyedi szolgáltatás. A döntést integrációnként dokumentáljuk.

    Korlátok és függőségek

    A licencmodellek változnak. Egy ma olcsó platform az integrációs költségvetése legnagyobb tételévé válhat, ezért a költségeket több évre modellezzük.

  • Az állami rendszerek a saját tempójukat diktálják

    Hogyan kezeljük

    A csatlakozási dokumentumokat, a biztonsági bizonyítékokat és a tesztterveket korán előkészítjük, és az első héttől együttműködünk a rendszer üzemeltetőjével.

    Korlátok és függőségek

    A tanúsítás és a csatlakozás ütemét az üzemeltető határozza meg, nem mi. Ehhez igazítjuk a tervet, és jelezzük, hol esik a kritikus útvonalra.

  • Az MI-felhasználóknak szűk API-k kellenek

    Hogyan kezeljük

    Az MI-ügynökök és -asszisztensek dedikált, korlátozott API-kat kapnak határértékekkel és auditnaplózással, nem ugyanazt a széles hozzáférést, mint a belső szolgáltatások.

    Korlátok és függőségek

    Egy API MI-ügynök számára való megnyitása kockázatot jelent. Mindegyiket átnézzük az információbiztonsági csapatával, mielőtt éles üzembe kerül.

05 Hogyan dolgozunk

Hogyan dolgozunk

Előbb kibogozzuk, aztán építünk, és minden adatfolyamnak gazdát adunk.

  1. 01

    Az adatfolyamok feltérképezése

    Minden interfész, a volumene, a hibatörténete és az üzleti gazdája.

    EredményIntegrációs térkép és kockázati rangsor

  2. 02

    A szabályok rögzítése

    API-irányelvek, eseménykonvenciók, identitásmodell és a platformválasztás.

    EredményIntegrációs irányelvek és döntési feljegyzések

  3. 03

    Áthelyezés adatfolyamonként

    A legkockázatosabb adatfolyamok először, a régi interfész mellett futó egyeztetéssel, amíg a számok meg nem egyeznek.

    EredményÁthelyezett adatfolyamok egyeztetési bizonyítékkal

  4. 04

    Átlátható üzemeltetés

    Irányítópultok üzleti folyamatonként és hibasorok megnevezett gazdákkal.

    EredményAdatfolyam-felelősségi térkép és irányítópultok

06 Emberi kontroll

Ahol az ember dönt

Az integráció felügyelet nélkül fut. A hibákért viselt felelősség nem lehet felügyelet nélküli.

  • Minden hibasornak gazdája van

    A sikertelen üzenetek egy felelős csapathoz kerülnek, kontextussal és visszajátszási lehetőséggel, nem egy közös naplóba.

  • A szerződés­változásokat átnézzük

    A visszafelé nem kompatibilis API- vagy eseményváltozásokat közzététel előtt a fogyasztókkal együtt vizsgáljuk felül.

  • A visszajátszás tudatos döntés

    Üzenetek visszajátszása egy nyilvántartó rendszerbe jogosultsághoz kötött művelet, amelyről naplózzuk, ki végezte és miért.

07 Technológiák

Technológiák, amelyekkel dolgozunk

Integrációs platformok
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • AWS és Google Cloud integrációs szolgáltatások
Események és adatfolyamok
  • Apache Kafka
  • RabbitMQ
  • Felhős üzenetközvetítők
  • Debezium változásalapú adatrögzítéshez
API-k
  • OpenAPI és AsyncAPI
  • API-átjárók és fejlesztői portálok
  • GraphQL, ahol illik
  • Szerződéstesztelés
Identitás
  • OAuth 2.0 és OpenID Connect
  • Kölcsönös TLS
  • Keycloak és felhős identitásszolgáltatók
  • Nemzeti eID-rendszerek

Egy technológia felsorolása a mérnöki tapasztalatunkat írja le. Nem jelent partnerséget a gyártóval, és nem jelenti azt, hogy a gyártó ajánlana minket.

08 Példa

Szemléltető példa

Szemléltető példa

ERP és NAV Online Számla hibakezeléssel és újraküldéssel

01Helyzet
Egy villamossági nagykereskedés a külföldi anyavállalat ERP-rendszerét használja. A NAV által visszautasított vagy figyelmeztetéssel elfogadott számlaadatokat egy munkatárs táblázatban követi, és egyes ajánlatkérő ügyfelek EN 16931 szerinti e-számlát kérnek.
02Amit építenénk
Integrációs réteg az ERP és a NAV Online Számla között: ellenőrzés beküldés előtt, a feldolgozási eredmény lekérdezése, hibasor újraküldéssel, napi egyeztetés az ERP és a NAV felé jelentett adatok között, valamint EN 16931 szerinti e-számla az ajánlatkérőknek ugyanabból az ERP-ből.
03Ahol ember dönt
A számla tartalmát érintő javítást, például módosító vagy sztornó számla kiállítását, a könyvelő hagyja jóvá; automatikusan csak a műszaki okból sikertelen beküldést küldjük újra.
04Amit mérnénk
Az első beküldésre elfogadott számlaadatok aránya, a hibás beküldések lezárásáig eltelt idő és a kézi javítások száma havonta.

09 Ágazati nézőpont

Az Ön ágazatában

  • Közszféra

    Adatcsere közhiteles nyilvántartásokkal az egyszeri adatszolgáltatás elve szerint, Ügyfélkapu+ és DÁP-alkalmazás alapú belépés és az állami rendszerek által előírt naplózás. Lásd: Közszféra.

  • Ipar és gyártás

    Az ERP, a MES és a beszállítói portálok eseményeken keresztül összekötve, hogy a tervezés, a gyártás és a szerviz ugyanazt a képet lássa.

  • Pénzügyi szolgáltatások

    Alaprendszerek, CRM és partner-API-k erős identitáskezeléssel, auditnaplózással és olyan egyeztetéssel összekötve, amelyben a pénzügy megbízik.

Magyarország

Online Számla itthon, eltérő szabályok a csoportban

Egy magyar vállalatnak minden belföldi számla adatát valós időben kell a NAV Online Számla rendszerébe jelentenie, miközben a csoport ERP-rendszere más tagállamokban más e-számlázási szabályokat követ, például a Peppolt. Az ajánlatkérők 2019 óta kötelesek fogadni az EN 16931 szerinti e-számlát, központi B2G-platform nélkül, mindegyik a saját megoldásán keresztül.

A közszférában az elektronikus ügyintézés belépési módja az Ügyfélkapu+ és a DÁP-alkalmazás; az eIDAS 2 szerint a tagállamoknak 2026. december 24-ig európai digitális személyiadat-tárcát kell biztosítaniuk, az Interoperábilis Európa jogszabály pedig a határokon átnyúló interoperabilitás értékelését kéri a közszférabeli szervezetektől. Olyan integrációs rétegeket tervezünk, ahol az állami rendszerek, az e-számla-csatornák és az azonosítási szolgáltatások stabil belső szerződések mögötti adapterek. Egy új ország vagy csatorna így egy adapter és annak bekötése, nem a mögötte lévő rendszerek átépítése.

Kérdések az integrációkról és az API-król

Integrációs platformot használjunk, vagy egyedi integrációkat építsünk?

Mindkettőt, különböző adatfolyamokhoz. A szabványos csatlakozók, a leképezések és a partnerek bekötése platformot kíván. A nagy volumenű, válaszidőre érzékeny vagy összetett logikájú adatfolyamoknál gyakran az egyedi szolgáltatás a jobb. Adatfolyamonként döntünk, és dokumentáljuk az okát.

Integrálják a Salesforce-t, az SAP-ot és az Odoo-t?

Igen, rendszeresen, egymással, valamint egyedi és állami rendszerekkel is. A FromNine mindhárom gyártó partnere (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), így integrációs csapataink platformszakértőkkel együtt dolgoznak. Lásd SAP-integrációs munkánkat.

Össze tudják kötni az ERP-rendszerünket a NAV Online Számla rendszerével?

Igen. Minden belföldi számla adatát valós időben kell a NAV-nak szolgáltatni. Az ERP és a NAV közé olyan réteget építünk, amely beküldés előtt ellenőrzi az adatokat, lekérdezi a feldolgozási eredményt, a hibás beküldéseket gazdával rendelkező hibasorba teszi újraküldési lehetőséggel, és egyezteti az ERP adatait a NAV-nak jelentett adatokkal. Ugyanabból az ERP-ből EN 16931 szerinti e-számlát is előállítunk az ajánlatkérőknek, amelyek a Kbt. 27/A. §-a szerint kötelesek ezt fogadni; a szállítókra ez nem ír elő kötelezettséget. A kötelező strukturált e-számlázásról jelenleg csak koncepció létezik, jogszabály nem, ezért az integrációt úgy tervezzük, hogy egy későbbi változás ne igényeljen újraírást.

Be tudják kötni az elektronikus azonosítást?

Igen. Magyarországon az elektronikus ügyintézés belépési módjai az Ügyfélkapu+ és a DÁP-alkalmazás; más tagállamokban az ottani állampolgári és üzleti eID-rendszerekkel dolgozunk. Felkészítjük a rendszereit az európai digitális személyiadat-tárcákra is, amelyeket a tagállamoknak az eIDAS 2 szerint 2026. december 24-ig kell biztosítaniuk. A csatlakozási követelmények rendszerenként eltérnek, ezért korán tervezünk velük.

Örökölt köztes szoftverünk van. Le kell cserélnünk?

Nem egyszerre. Feltérképezzük, mi fut rajta, először a legkockázatosabb vagy legdrágább adatfolyamokat helyezzük át, és az egyeztetést addig fenntartjuk, amíg minden áthelyezett adatfolyam nem bizonyít.

Hozza el azt az interfészt, amely a leggyakrabban hibázik

Megmutatjuk, hogyan tennénk megfigyelhetővé, idempotenssé és gazdával rendelkezővé, és mi kellene ahhoz, hogy a többivel is ugyanezt tegyük.

Beszéljük meg a projektjétÜgyfélszolgálati támogatás