Ez egy magas szintű koncepcionális áttekintés az üzleti szabálymotorok architektúrájáról. A valódi kód fölött van. Ha ön üzleti szabálymotort épít – nagy valószínűséggel hasznosnak találhatja ezt a szöveget.

Egyszer építettem egy olyan üzleti szabálymotort, amely lehetővé tette az üzleti automatizálást kis- és középvállalkozások számára, és rendelkezett minden olyan képességgel és potenciállal is, amely jól szolgálhatta volna a nagyvállalatokat. Ez volt az út egy átlagos szoftveralkalmazástól egy kifinomult és összetett megoldásig, amely megfelelt a kemény skálázhatósági, karbantarthatósági és bővíthetőségi követelményeknek. Ez a szöveg áttekintést nyújt arról, hogy mi is az Üzleti Szabályok Motorja, és ismerteti az egyik modern megközelítést, amelyet az ilyen típusú szoftverek készítésekor figyelembe vehetünk.

Kezdésnek fontos definiálni az alapvető fogalmakat. Az üzleti szabálymotorok már elég régóta léteznek az iparágban valamilyen formában, és nagyjából minden általunk használt kifejezésre létezik néhány definíció. Kezdjük az “üzleti szabállyal” – erre a kifejezésre létezik egy jól ismert definíció. Az “üzleti szabály” tehát:

Egy olyan kijelentés, amely meghatározza vagy korlátozza az üzlet valamely aspektusát. Célja az üzleti struktúra érvényesítése vagy az üzlet viselkedésének irányítása vagy befolyásolása.

T. Morgan, Üzleti szabályok és információs rendszerek. Boston: Addison-Wesley Publishing, 2002

Az üzleti szabályok alkalmazási köre igen széles, és az üzlet bármely aspektusára alkalmazhatók. Például a “Amikor egy ügyfél bejön, üdvözöld őt egy meleg mosollyal és egy barátságos “Helló”-val” szabályt a cég alkalmazottja alkalmazza az ügyfelekkel való találkozáskor. Egy másik szabály meghatározhatja vagy korlátozhatja a rutinfeladatok megoldásának megközelítését a vállalat egy adott szerepkörében. Az olyan szoftvermegoldások, mint a CRM-rendszerek folyamatosan növekvő népszerűségével és a szoftverek teljes integrációjával a különböző üzleti területekhez, az üzleti folyamatok többsége részben vagy teljesen adatorientálttá vált. Ez az üzleti szabályok átalakulásához vezetett, így azok szoftverorientálttá váltak, például a “Ha egy vásárló vásárol valamit az üzletünkben, hívjuk fel később, hogy szeretne-e más kapcsolódó árukat vásárolni” üzleti szabály átalakult egy modernebb “Ha egy vásárló vásárol valamit az online áruházunkban, küldjünk neki később egy e-mailt, amelyben felsoroljuk a többi kapcsolódó árut” szabállyá. Napjainkban sok vállalat napi működése során többnyire adatokkal foglalkozik. Figyelembe véve, hogy a vállalkozások többsége minden méretben integrált szoftveres megoldásokat alkalmaz üzleti tevékenységeihez, az “üzleti szabály” fogalmának meghatározása konkrétabban is meghatározható, ha a T. Morgan által fent említett definíciót kiegészítjük egy pontosítással (félkövérrel):

Az üzleti szabály egy olyan kijelentés, amely meghatározza vagy korlátozza az üzleti tevékenység valamely aspektusát. Célja az üzleti struktúra érvényesítése vagy az üzlet viselkedésének ellenőrzése vagy befolyásolása. Adatkonstrukcióként tárolódik a perzisztens tárolóban, és az üzleti logika egy atomi csomagját tartalmazza. Egy szoftveres megoldáson keresztül automatikusan kezelik és alkalmazzák a vállalat üzleti folyamataiban.

Az “üzleti szabály” fogalmának meghatározása után az “üzleti szabálymotor-kezelő rendszer” (BRMS) fogalmát a következőképpen határozzuk meg:

A BRMS egy szoftveres megoldás az üzleti szabályok kezelésére (tárolására, szerkesztésére, törlésére stb.), valamint a vállalati üzleti folyamatokban való alkalmazására.

A kereskedelmi BRMS-ek megvásárlása és a vállalati informatikai infrastruktúrába való integrálása rendkívül költséges lehet, ezért a vállalatok gyakran házon belüli megoldásokat alkalmaznak, amikor az üzleti folyamatok vagy más típusú folyamatok automatizálásának igényével találkoznak.
A BRMS-ek bármely vállalkozás alapvető és létfontosságú részévé válhatnak. Néha egy vállalkozás sikere attól függhet, hogy milyen üzleti szabályokkal rendelkezik, és hogy ezeket az üzleti szabályokat mennyire jól kezelik és alkalmazzák.

Az üzleti szabály adatkonstrukció

Az üzleti szabály atomi parancsok következetes sorozataként ábrázolható. A parancsok tartalmazhatnak feltételes adatelemzést, idővárakozási parancsokat, műveletvégzési parancsokat stb. A “Ha egy ügyfél vásárol valamit a webáruházunkban, később küldjünk neki egy e-mailt, amelyben felsoroljuk a többi kapcsolódó árut” üzleti szabály példa jó és általános, és sok más üzleti szabály nagyon hasonló logikai felépítésű lehet:

A szabály feldolgozási folyamata akkor indul el, amikor a vásárlás megtörtént, és a “Küldj a vevőnek egy e-mailt a vonatkozó áruajánlatokkal” parancs végrehajtásával bizonyos üzleti logika kerül alkalmazásra. Előfordulhat, hogy a vevő letiltotta az e-mail feliratkozást. Ekkor az üzleti szabályhoz hozzá kell adni a további feltételt – “ha a vevőnek engedélyezve van az e-mail előfizetése”:

A parancsok következetesen végrehajtásra kerülnek, és most egy adatelemzési parancs van, amely ellenőrzi, hogy a vevőnek van-e aktív e-mail előfizetése. Ha igen – folytassa az üzleti szabály következő parancsának végrehajtását. Ha pedig nem – ne folytassa, az üzleti szabály befejezettnek tekinthető, a feldolgozási folyamat leáll, a következő parancsok nem kerülnek végrehajtásra.

A vevőnek lehet SMS-előfizetése is, és ha az aktív, akkor egy másik parancsnak is kell lennie – “SMS küldése kapcsolódó promóciós ajánlattal”. Ezzel elágazás kerül bevezetésre az üzleti szabály logikájába:

A szabály elágazásai egymástól függetlenül kerülnek feldolgozásra. Az egyik ág feldolgozása a feltétel kiértékelési parancsra megállhat, és egy másik ágat a végéig feldolgozhat.

A BRMS kliensoldali alkalmazás felhasználói felülete az üzleti szabály ábrázolására többféleképpen is megvalósítható (bármilyen fa grafikus ábrázolása működik):

Az üzleti szabály adatkonstrukciója egy irányított gyökerű fa gráf (egy irányított aciklikus gráf, amelynek egy fa az alapul szolgáló irányítatlan gráf). Az üzleti szabály gráfjának csúcsait különböző típusú parancsok reprezentálják: adatelemzési parancsok, műveletvégzési parancsok, idő-várakozási parancsok stb. Minden irányított gyökeres kifelé irányuló fának van egy gyökere – egy olyan csúcs, amelyből minden él kifelé mutat. Így minden szabály egy speciális csúccsal (vagy gráfelméleti kifejezéssel élve gyökércsúccsal) kezdődik – ez a csúcs jelöli ki a szabály feldolgozásának belépési pontját.

CRUD műveletek az üzleti szabályok adatkonstrukcióján

Mivel az adatkonstrukciót irányított gyökerű fával és soha semmilyen másfajta gráffal ábrázoljuk, ez megszabadít bennünket az általános gráfstruktúrák RDBMS-ben történő tárolásával járó kellemetlenségektől (például a csúcsok és élek különböző táblákban történő tárolása, ami egyetlen szabály lekérdezéséhez megnövekedett számú keresést eredményezhet, stb.) Ez pedig azért kritikus, mert nyilvánvaló, hogy a BRMS normál működése során az adatok keresése sokkal gyakrabban történik, mint más műveletek, például beszúrások, frissítések vagy törlések.

Csak emlékeztetőül – az üzleti szabály minden egyes csúcsa egy atomi parancsot képvisel. Ez az RDBMS táblában rekordként van elmentve olyan attribútumokkal, mint a parancs típusa, leírása és egyéb kiegészítő adatok. Egy fában minden csúcsnak csak egy szülője van (kivéve a gyökércsúcsot, amelynek nincsenek szülei), ezért minden rekordnak tartalmaznia kell a szülőcsúcs azonosítóját. Az is praktikus, ha van egy másik tábla, amely a szabályrekordokat tartalmazza a magára az üzleti szabályra vonatkozó adatokkal. Ezzel a megközelítéssel nem okoz gondot az üzleti szabály bármilyen összetettségű adatkonstrukciójának tárolása.

A CRUD műveletek meglehetősen egyszerűek. Az üzleti szabály módosításai az egyik vagy mindkét tábla – szabály vagy parancs – frissítését igényelhetik. A parancsok törlésénél vagy beszúrásánál szükséges a parancsok közötti hivatkozások fenntartása (ez lényegében egy fa csomópontjainak törlése vagy beszúrása).

A BRMS egyik komponensének, nevezzük menedzsernek, végre kell hajtania a leírt adatbázisműveleteket, és API-t kell biztosítania az üzleti szabályokon végzett CRUD műveletekhez.

Az üzleti szabály feldolgozása

Az üzleti szabály feldolgozása akkor kezdődik, amikor egy adott üzleti esemény bekövetkezik. Ez bármi lehet – egy felhasználó bejelentkezett, egy vásárlás megtörtént, valamilyen pénzösszeg átutalásra került stb. Az ilyen jellegű tevékenységeket nyomon kell követni, és a BRMS-t valamilyen transzporton keresztül tájékoztatni kell róla. Az AMQP valószínűleg a legalkalmasabb az ilyen jellegű feladatokra.

1. Az egész koncepció a mikroszolgáltatás-architektúrára épül. Az üzleti eseményfogyasztó mikroszolgáltatás az összes üzleti eseményt egy várólista deklarálásán keresztül hallgatja, és egy RabbitMQ cserekiszolgálón egy adott cseréhez köti. Amikor egy (jelentősnek tekintett és nyomon követett) üzleti tevékenység történik a fő szoftverrendszerben, az üzenet elküldésre kerül a RabbitMQ cserekiszolgálóra. Ez információt tartalmaz a történtekről, valamint néhány releváns kiegészítő adatot. Az üzleti eseményt az üzenetben átadott tetszőleges attribútummal lehet azonosítani, vagy útválasztási kulcsként lehet használni, például egy string purchase.completed. Az üzenetet ezután a BRMS üzleti eseményt fogyasztó mikroszolgáltatás fogyasztja.

2. Amikor az üzleti eseményt fogyasztó mikroszolgáltatás megkapja az üzenetet a fő szoftverrendszerből, lekérdezi a menedzser mikroszolgáltatást, hogy van-e olyan üzleti szabály az adatbázisban, amely rendelkezik az üzleti tevékenység eseményének megfelelő szabálykiváltóval. Ha van ilyen megfelelő üzleti szabály, a menedzser mikroszolgáltatás visszaküldi a kezdeti parancsadatokat az üzleti eseményt fogyasztó mikroszolgáltatásnak. Ez az adatlekérés a menedzsertől gRPC-n keresztül történik, és szaggatott vonallal látható.

3. Miután a menedzser mikroszolgáltatás válaszol a kezdeti parancsadatokkal, az üzleti eseményt fogyasztó mikroszolgáltatás készen áll az üzleti szabály feldolgozásának inicializálására. Az üzleti eseményfogyasztó egy másik üzenetet képez, amely magában foglalja a kezdeti parancsadatokat (amelyeket a menedzser mikroszolgáltatástól kapott), valamint az üzleti esemény adatait, amelyeket a fő szoftverrendszerből kapott. Ezt az AMQP-n keresztül elküldi egy belső BRMS-cserére. Az üzenet útválasztási kulcsa megfelel a parancs típusának.

4. A kezdeti parancsfeldolgozó mikroszolgáltatás elfogyasztja az üzenetet (azt a várólistát hallgatja, ahol a initial útválasztási kulcsú üzenetek vannak halmozva). Ezután elvégzi a logikáját (alapesetben a kezdeti blokkban nincs logika), és lekérdezi a menedzsert, ha vannak további parancsok az üzleti szabályban (ezek azok a parancsok, amelyek parent_id értéke megegyezik az éppen feldolgozott parancs id értékével). És ha igen, akkor megkapja a következő parancs adatait, és mind az üzleti esemény adatait, mind a következő parancs adatait elküldi a belső RabbitMQ-kiszolgálónak. Igen, ez most úgy néz ki, mint az összekapcsolt lista átjárása, és ha a szabály ágakkal rendelkezik, akkor ez egy fa átjárása! Így történik az üzleti szabály feldolgozása parancsról-parancsra. Egy másik fontos dolog itt – ebben a kontextusban az üzleti eseményadatok minden gyermekparancshoz továbbításra kerülnek. Ez az egyedi üzleti szabály végrehajtásának kontextusa. Ez később felhasználható az adatelemzési parancsfeldolgozóban és a műveleti parancsfeldolgozóban.

A szemléltetés kedvéért tegyük fel, hogy a példaszabály ilyen szerkezetű: kezdeti parancs -> feltételes adatelemzési parancs -> üzleti műveleti parancs. Ekkor a kezdeti parancs után a következő parancs az adatelemzési parancs.

5. Az elemzési parancsfeldolgozó a analysis útválasztási kulccsal ellátott üzenetet fogyasztja el a belső cseréből. Az üzleti szabály elemzési parancsában leírt feltételek értékelése alapján és az üzleti eseményadatok felhasználásával a szabály végrehajtási folyamata itt folytatódhat vagy megállhat. Ha megáll – további üzleti szabályparancsok nem kerülnek végrehajtásra. Ha a végrehajtási folyam folytatódik, az elemzési parancs feldolgozója lekérdezi a menedzsert a következő üzleti szabályparancsokért, lekérdezi azokat, és újabb üzenetet tesz közzé a belső cserekiszolgálón.

6. Végül a belső cserében van egy üzenet, amely készen áll az akcióparancs-feldolgozó számára a fogyasztásra. Ha az üzleti szabály végrehajtási folyamata eddig a parancsig jutott, az azt jelenti, hogy a szabály ezen ágában minden feltétel, amely az adatelemzési parancsban szerepelt, igaz volt, és a végrehajtási folyamata nem szakadt meg. Az akcióparancs-feldolgozó végrehajtja az akciót, pl. elküld egy e-mailt.

Ez a fajta gráfátjárás mélység-első, és amikor egy olyan parancsba ütközünk, amelynek 2 vagy több gyermekparancsa van, az üzleti szabály feldolgozásának aszinkron jellege miatt a leírt rendszerben minden ágban megkezdődik az egyidejű mélység-első átjárás.

Skálázás

A leírt megközelítés nem csak a problémák nagyfokú szétválasztását teszi lehetővé, hanem az IaaS-számlák kifizetésekor is sok pénzt takaríthat meg. A végfelhasználók különböző üzleti szabályokat hoznak létre különböző számú, különböző típusú parancsokkal és különböző számú elágazással. A leggyakoribb skálázási forgatókönyvek azonban a következők:
1. Nő az üzleti események száma – az üzleti eseményfogyasztó skálázódik.
2. Nő az üzleti eseményekhez kapcsolódó (kiváltott) üzleti szabályok száma – a kezdeti parancsfeldolgozó a kezelővel együtt skálázódik.
3. Sok elemzési parancs van az üzleti szabályokban – az elemzési parancsfeldolgozó skálázódik
4. Túl sok műveleti parancsot kell végrehajtani – a műveleti parancsfeldolgozó skálázódik.

megbízhatóság

A rendszer vérereje a szállítás. Ahhoz, hogy a rendszer nagy terhelés mellett is működőképes maradjon, a belső üzenetváltásnak rendkívül megbízhatónak kell lennie. A RabbitMQ biztosítja a klaszterezést, és jól kielégíti a megbízhatósági követelményeket (https://www.rabbitmq.com/clustering.html).

Más parancstípusok

Minden egyéb üzleti logika bevezethető a rendszerbe. Az egyik népszerű és keresett parancstípus a várakozási idő parancs (pl. “Várjon 45 percet, majd folytassa”). Az idő-várakozás parancs bevezetésével az üzleti szabály feldolgozása már nem valós idejű feldolgozás, mivel egy időre felfüggeszthető. Ezek a változások további parancsfeldolgozókat és az adatszerkezetek néhány olyan módosítását igénylik, amelyek nem tartoznak e szöveg tárgykörébe. Az idővel való szórakozás nehéz lehet, és az ütemezéseket és az időt működtető szolgáltatás megírása kihívást jelenthet, íme egy jó példa: https://github.com/nextiva/krolib

Harmadik féltől származó alternatívák

A szabálymotoroknak/munkafolyamatmotoroknak vannak jól ismert alternatívái, itt van a top 3 közülük (IMHO):
1. Comunda – ez egy kiforrott termék, közösségi és vállalati verzióval, amit érdemes használni. Nyilvánvalóan a vállalati verzió fizetős.
2. Luigi – ez egy munkafolyamat-motor eszköz, amelyet a Spotify fejlesztett ki belső igényeire, de már több tucat más vállalat használja.
3. Apache Airflow – ez egy másik jól ismert termék, amely bizonyította, hogy képes, kényelmes és testre szabható.

Ami ezeket az eszközöket összeköti, az az, hogy mindegyikük közvetlen aciklikus gráfot használ az üzleti szabályokat vagy munkafolyamatokat reprezentáló adatszerkezetként. Ez nem meglepő.

Lehetnek még más termékek is, amelyekre érdemes odafigyelni, de minden vizsgálatot ezzel a hárommal kell kezdeni.

Következtetés

A saját üzleti szabálymotor megalkotása kihívást jelenthet, de kifizetődő. Nemcsak egy saját rendszerhez jut, hanem az Ön vállalkozásának egyedi igényei szerint épül fel. Egy jó DevOps-csapat elengedhetetlen a megbízhatóság, a skálázhatóság és a felügyelet fenntartásához. Mindezek után egy fantasztikus terméket kap, amelyre büszke lehet.