Miért van szükség eseményvezérelt architektúrára?
A korábbi, négyrészes SAP-integrációs blogsorozatomban azt mutattam be, hogyan kapcsolható egy saját fejlesztésű C#/.NET alkalmazás az SAP-hoz RAP és OData V4 segítségével. A sorozat a Modern SAP-integráció külső alkalmazásokkal című bejegyzéssel indult, és az SAP Gateway oldali ellenőrzésig jutottunk el. A fő tanulság az volt, hogy egy működő endpoint még nem jelent önmagában megbízható integrációt: az üzleti felelősségeket, a rendszerhatárokat és a hibakezelést is meg kell tervezni.
Most innen lépünk tovább. Mi történik akkor, ha a külső alkalmazás nemcsak adatokat tárol vagy lekérdez, hanem folyamatosan érzékel változásokat, és ezek közül néhány azonnali reakciót követel? Hogyan lesz egy technikai jelzésből olyan incidens, amelyre a helyi rendszer reagálni tud, miközben az SAP-ban a teljes folyamat visszakövethető marad? Ennek járunk utána egy új, háromrészes sorozatban.
A mérési adat még nem incidens
Képzeljünk el egy hűtött raktárat, ahol szenzorok mérik a hőmérsékletet. Másodpercenként új érték érkezhet: 20,1 °C, 20,2 °C, majd 20,8 °C. Attól, hogy egy adat megváltozott, még nem biztos, hogy üzleti beavatkozásra van szükség. A lényeg az, hogy a rendszer felismerje, mikor válik az eltérés tartóssá, veszélyessé vagy egy üzleti szabály szerint relevánssá.
- Telemetria: a mért értékek és eszközállapotok folyamatos gyűjtése.
- Monitoring: ezek értelmezése, küszöbértékek és trendek figyelése, rendellenességek felismerése.
- Incidenskezelés: a releváns eltéréshez felelős folyamat, állapot, intézkedés és lezárási feltétel rendelése.
Például egy rövid hőmérsékleti kilengésből nem célszerű új incidenst létrehozni. Ha viszont az eltérés egy meghatározott ideig fennáll, a rendszer Warning, majd Critical állapotba kerülhet. Ez már olyan üzleti esemény, amelyhez helyi jelzés, beavatkozás és SAP oldali nyilvántartás kapcsolódhat. Így a vállalati rendszer nem mérési adatok ezreit kapja meg, hanem a fontos állapotváltozásokat.
Miért nem elegendő mindenre a request–response?
A hagyományos API-kommunikáció jól működik, amikor egy rendszer konkrét választ vár egy konkrét kérésre. A C# backend például OData API-n keresztül létrehozhat egy incidenst az SAP-ban, módosíthatja annak állapotát, vagy lekérdezheti a részleteit. Ez továbbra is a megoldásunk fontos része marad.
Egy HTTP-válasz azonban elsősorban a kérés eredményéről ad információt; nem bizonyítja, hogy minden további rendszer már feldolgozta a változást. Ha több alkalmazásnak kell reagálnia ugyanarra az incidensre, a folyamatos lekérdezés (polling) felesleges forgalmat okozhat, a közvetlen egymásra hívások pedig szoros függőségeket építenek ki. Egy átmenetileg elérhetetlen fogyasztó ilyenkor könnyen a teljes folyamatot lassíthatja.
Az eseményvezérelt architektúra más kérdést tesz fel: nem azt, hogy mi az aktuális állapot, hanem azt, hogy milyen fontos állapotváltozás történt. Egy esemény például IncidentCreated vagy IncidentSeverityChanged jelzés a fogyasztóknak, nem pedig a teljes üzleti folyamat szinkron végrehajtása. Az API és az esemény tehát egymást egészíti ki: az elsővel állapotot kérünk le vagy műveletet kezdeményezünk, a másodikkal a megtörtént változásról értesítünk más rendszereket.
Fontos korlát: attól, hogy egy megoldás aszinkron, még nem lesz automatikusan gyorsabb, biztonságosabb vagy megbízhatóbb. Ha egy egyszerű művelet azonnali választ és erős konzisztenciát igényel, gyakran továbbra is a szinkron API a helyes választás.
Melyik rendszer miért felel?
A saját példaprojektben három jól elkülöníthető felelősséget tervezünk. A C#/.NET backend a szenzoradatok helyi kiértékelését és a gyors automatizálási döntéseket végzi. Ha kritikus eltérést észlel, nem várhat arra, hogy egy távoli vállalati szolgáltatás mikor válaszol: a helyi jelzést és a megfelelően megtervezett helyi reakciót önállóan kell kezelnie.
Az SAP feladata nem az összes nyers szenzorérték tárolása, hanem az üzletileg értelmezhető incidensállapot kezelése: melyik telephelyen mi történt, milyen súlyossággal, milyen intézkedések indultak, és mikor zárult le az eset. Ehhez a RAP-alapú üzleti objektum és az OData API kontrollált belépési pontot ad. A SAP RAP Business Event az SAP-ban bekövetkező releváns üzleti változást jelezheti; az SAP Event Mesh pedig köztes, aszinkron üzenetközvetítőként segíti, hogy a fogyasztók ne közvetlenül az incidens létrehozójához kapcsolódjanak.
A tervezett folyamat ezért röviden így áll össze: a C# alkalmazás helyben felismeri az eltérést, OData-n keresztül rögzíti vagy frissíti az SAP-incidenst, majd az SAP oldali üzleti állapotváltozás eseményként eljuthat az Event Mesh közvetítésével a feliratkozott fogyasztókhoz. Az esemény hordozhat azonosítót és alapvető kontextust; a részletes, aktuális állapot szükség esetén továbbra is API-n keresztül kérhető le.
Az incidens nem egyetlen riasztás
Egy jól felépített incidenskezelésben a létrehozás csak a kezdet. A példában a Normal állapot a rendes működést jelöli, aktív incidens nélkül. A Warning az első releváns eltérés; a Critical a súlyosbodó helyzet. A Mitigating szakaszban a rendszer már konkrét kockázatcsökkentő intézkedést hajt végre, a Recovering pedig azt jelzi, hogy a mért állapot visszatérőben van a megengedett tartományba. Resolved csak akkor lehet az incidens, amikor a meghatározott lezárási feltételek is teljesültek.
Itt különösen fontos megkülönböztetni a pillanatnyi javulást a tényleges helyreállástól. Ha egy érték néhány másodpercig a küszöb alá esik, majd újra fölé kerül, a rendszer ne nyisson és zárjon egymás után több tucat incidenst. Időtartamhoz kötött szabályok, eltérő be- és kilépési küszöbök (hiszterézis), valamint egyedi incidensazonosítók segítenek stabil állapotmodellt kialakítani.
A buktatókra már a tervezés közben gondolni kell
Túl sok vagy rosszul definiált esemény. Ha minden mérési mintát üzleti eseményként publikálunk, a fogyasztók és a hibakeresés is túlterhelődhet. Csak a jelentéssel bíró állapotátmeneteket érdemes eseménnyé alakítani. A zajszűrés és a küszöblogika a helyi feldolgozás része.
Késő, duplikált vagy elvesző üzenetek. Az aszinkron továbbításnál nem szabad abból kiindulni, hogy minden esemény pontosan egyszer, az elvárt sorrendben érkezik. Tartós queue, visszavárakoztatással működő retry, sikertelen üzenetek elkülönítése és idempotens fogyasztó szükséges. Egy eseményazonosító vagy incidensazonosító segít elkerülni ugyanannak a műveletnek a kétszeri végrehajtását.
Átmeneti eltérés a rendszerek között. Előfordulhat, hogy az SAP-ban egy incidens már Critical, miközben egy fogyasztó még a korábbi Warning állapotot mutatja. Ez az eventual consistency természetes következménye lehet. Állapotverzióval, időbélyeggel, szükség szerinti API-visszaellenőrzéssel és egyértelmű SAP oldali source of truth kijelöléssel kezelhető.
Nehezen követhető hibafolyamat. Egy szinkron kérésnél egyszerűbb végignézni a hívási láncot; eseményeknél több önálló komponens naplóit kell összekapcsolni. Azonos korrelációs azonosítót, strukturált naplózást, feldolgozási státuszt és queue-monitoringot már az első verzióban célszerű használni.
Biztonsági félreértések. Az autentikáció azt igazolja, ki a hívó. Az autorizáció azt szabályozza, mit tehet. A CSRF-védelem ettől különböző védelmi mechanizmus, amelyre a használt SAP/OData felület módosító kéréseinél szükség lehet. Az API-hozzáférést, az eseményekre való feliratkozást és a technikai hitelesítő adatokat külön jogosultsági határként kell kezelni.
Függés a központi elérhetőségtől. Ha az SAP vagy az üzenetközvetítő átmenetileg nem elérhető, a helyi észlelés nem állhat le. A lokális reakció, a megbízható késleltetett továbbítás és a későbbi egyeztetés külön feladat.
Mi az üzleti érték?
A végeredmény nem egyszerűen egy újabb értesítés. Egy jól modellezett SAP-incidensből visszakereshető, hol és mikor keletkezett a probléma, mi váltotta ki, milyen súlyosságot ért el, milyen beavatkozás történt, sikeres volt-e, és mennyi idő alatt állt helyre a normál működés. Így nemcsak a riasztások száma mérhető, hanem a reagálási és helyreállítási idő, valamint az ismétlődő hibák mintázata is.
Ez már vállalati szempontból értékelhető információ: támpontot ad az üzemeltetési döntésekhez, a visszatérő problémák megelőzéséhez és az auditálható folyamatok kialakításához. Az eseményvezérelt megközelítés valódi előnye ezért nem maga az üzenetküldés, hanem az, hogy az üzleti jelentőségű változások kontrolláltan és több rendszer számára feldolgozhatóan jelennek meg.
Hogyan folytatjuk?
Ebben az első részben azt láttuk, miért kell különválasztani a mérést, a monitoringot és az incidens kezelését, illetve hogyan illeszkednek egymás mellé az API-k és az események. A következő bejegyzésben technikai oldalról építjük fel a kapcsolatot: RAP Business Event, Event Binding, SAP Event Mesh, topic, queue és C# event consumer. A harmadik részben pedig egy szimulált raktári folyamatot követünk végig a szenzorjeltől a fizikai állapotjelzésen át az SAP-ban lezárt, visszakövethető incidensig.
Szakmai háttér
SAP Help – Business Events for Process Integrations
