Reactor

2018-11-20

Termékbemutatás

Összefoglaló

Amikor még a vastagkliens megoldások voltak használatban, teljesen átlagos dolog volt az összetett ügyféladat változások tranzakció-jelleggel történő végrehajtása. A tranzakció-jelleg azt a működést takarja, amikor a felhasználó több, egymásra épülő változtatást hajt végre az ügyfélen, illetve annak szolgáltatásain, végül megnyomja a Mentés gombot, ha mindent rendben talál. A vastag kliensek jellemzően tartalmazták az összes üzleti logikát, amelyek a szabályos végrehajtást biztosították.

A vékonykliensek világa viszont szembesült azzal a problémával, hogy a kliensekben implementált logikákat nem lehetett API-okon megnyitni, ezért azok a különböző kliensekben párhuzamosan lettek megvalósítva.  A vékonykliensek világának egyik adottsága, hogy minden csatorna más-más technológiát használ, emiatt az egyes megoldások szükségszerűen eltérnek egymástól, újra és újra megvalósítva a különböző ügyfél- és szolgáltatás-manipulációs logikákat. Ebből következik, hogy a különbözőképpen működő csatornák használata egy idő után kész rémálommá vált, hiszen többcsatornás értékesítés és ügyfélszolgálat esetében gyakorlatilag lehetetlen azt garantálni, hogy az eltérő csatornán bejelentkező ügyfelekkel ugyanaz történjen!

A vékonykliensek további jellegzetessége, hogy általában az egy változás – egy frissítés logikával dolgoznak, így nem képesek kezelni a több lépéses összetett tranzakció-jellegű működést. Ez magával hozta a jól működő keresztértékesítési és bővítési logikák elvesztését illetve radikális termék-portfolió egyszerűsítést igényelt. A radikális portfolió-egyszerűsítés pedig még a keresztértékesítési és bővítési opciók elvesztésénél is fájdalmasabb bevételkiesésekhez tud vezetni.

A vastagkliensekhez leginkább hasonló megoldást a webshopokban látható bevásárlókosarak jelentik, de ezek jellemzően nem tudnak mit kezdeni a folyamatos szolgáltatások által támasztott manipulációs követelményekkel, illetve azzal a kezdő lépéssel, hogy a kosárnak nyitáskor már tartalmaznia kell az ügyfél aktuális szolgáltatásképét, szerződéses állapotát. Ezért aztán a szolgáltatószektorban (mint a telekommunikáció, a biztosítás vagy a pénzügyi szolgáltatások) működő cégeknek nincs a piacon megfelelő megoldás!

Nekik egy olyan tranzakciós motorra van szükségük, amely API-okon keresztül használható és képes választ adni az összes fentebb említett problémára illetve igényre.

Ez a Reactor.

A Reactor egy olyan tranzakcionális CRM megoldáscsalád része, amely lefedi a front-end, a humán-folyamatok, a háttérrendszerek gyorsítótárazása és a rendelés-végrehajtás területét.

Funkcionális képességek

A Reactor egyszerre 3 fő szerepkört lát el, melyek részletes kifejtését a következő bekezdések tartalmazzák:

  • tranzakciós motor (T)
  • szabálymotor (R)
  • árazó motor (P).

Tranzakció alapú működés (T)

A Reactor a gyakorlatban Termékajánlatok manipulációit tartalmazó tranzakciókat hajt futtat. Ezek a tranzakciók nagyon hasonlítanak az adatbázis tranzakciókhoz: létrehozhatók, rengeteg változtatás végezhető bennük és a végén jóváhagyhatjuk vagy eldobhatjuk őket.

A lehetséges műveletek a zöldmezős ügyféllétrehozástól kezdve az olyan egyszerű műveletekig terjednek, mint egy átirányítási telefonszám beállítása egy Termékajánlaton.

Az adatkonzisztencia biztosítására a Reactor egy speciális lockolási mechanizmust használ az ügyfeleken, amelyek egy tranzakcióban érintve vannak. A mechanizmus neve “optimistic locking”, ami úgy működik, hogy a tranzakció nyitásakor megjegyzett ügyfélállapotot összehasonlítja a jóváhagyáskor látható állapottal. Ha nincs eltérés a két állapotban, akkor a tranzakció átadható végrehajtásra. Ez a megközelítés elkerüli a nyitáskor alkalmazott lockolás problémáit (pl. beragadt lockolások), illetve lehetővé teszi párhuzamos tranzakciók (ún. “whatif” vizsgálatok) futtatását.

Szabályalapú üzleti logikák (R)

A Reactor által végrehajtott üzleti logikák előre meghatározott szabálytípusok paraméterezésével konfigurálhatók. úgymint előfeltétel, kizárás, minimum feltétel, együttmozgás és mások. A szabálytípusok a fejlesztés során gondos tesztelésnek lettek alávetve mind a funkcionalitás mind pedig a teljesítmény szempontjából, így a felhasználóknak nincs más dolga, mint egy szolgáltatás-modellezés (ahol a kezelni kívánt portfolió felmérése, és szabályrendszerre fordítása történik) elvégzése után a megfelelő szabályok felparaméterezése. A paraméterezés példányosítani fog pl. olyan előfeltétel szabályt, amelyben “A” szolgálatatás előfeltétele “B” megrendelésének, vagy hogy a lakossági szegmensben “X” szolgáltatás nem adható.

Szabályszegmentáció (R)

Bonyolult üzleti környezetben könnyen előfordulhat, hogy sok ezer vagy akár milliós szabálypéldányt kell kezelni azért, hogy az automatikusan ellenőrzött szolgáltatásmanipuláció megfelelően működhessen. Sok komplex üzleti helyzetet elemezve felismertük, hogy a szabályok és a termékek a Reactor szempontjából szegmensekbe sorolhatók, ahol szegmensenként már csak néhány tíz – száz szabályra van szükség.

A szabály-szegmentálásnak számos előnye van:

  • segít elkerülni az új szabályok által okozott nem várt mellékhatásokat (pl. amikor egy lakossági területnek szánt új szabály problémát okoz pl. az üzleti szolgáltatások területén)
  • a szabályok alacsony száma drámaian csökkenti az üzleti tesztelés erőforrásigényét
  • egy változás során pontosan meghatározható, hogy mely területek érintettek, új szabályszegmens hozható létre piaci szegmentáció módosítása esetén úgy, hogy a korábbi ajánlatok működése garantáltan nem változik
  • mivel egy tranzakciónak egyszerre csak egy szabályszegmenssel kell foglalkoznia, mind az üzemeltethetőség, mind pedig a nagy teljesítmény könnyen biztosítható.

A Reactor gyakorlatilag érzéketlen az üzleti szabályok számára: ha néhány száz szabály könnyen kezelhető; akárcsak néhány millió. A felhasználói élményben nincs érzékelhető változás.

A szegmentáció során jellemzően az alábbi kulcsokat használjuk: üzleti folyamat, ügyfél- és előfizetés típusa,  életciklus státuszok, termékportfolió azonosító, hűségidő illetve tarifacsomag.

Ügyfélhierarchia támogatás (R)

A Reactor alapértelmezésben kezeli mind az előfizetés/szerződés szintű, mind pedig az esetlegesen ezek felett létező ügyfél szintű Termékajánlat manipulációkat. Az ügyfél szinten végzett műveletek vonatkozhatnak ügyfél szinten definiált Termékajánlatokra és az ügyfél alatt szereplő előfizetések mindegyikén egyidőben végrehajtandó műveletekre is.

Pontok és egyenlegek használata (R)(P)

A Reactor fel van készítve tranzakcionális pénz és egyéb egyenleg (mint pl. hűségpont) kezelésére. Egy olyan környezetben, ahol hitelképesség vizsgálat fut egy új értékesítés előfeltételeként, a Reactor képes a vizsgálat eredményét felhasználva speciális (minimum előfeltétel) szabályok segítségével szűkíteni az Termékajánlatokat.

Hasonló a helyzet az egyenlegek esetében is, legyenek azok pénz vagy naturália egyenlegek. Vegyük a hűségpontok példáját. A Reactor megkapja egy adott tranzakcióban az érintett entitásokra vonatkozó hűségpontok mennyiségét a Hűségpontkezelő alkalmazástól. Ezek után a tranzakciónk ezt az összeget nyitóegyenlegként fogja kezelni, amely alapján pl. lehetőség van egy Termékajánlat árát ebből az egyenlegből fedezni. Minden ilyen művelet után a Reactor csökkenti tranzakcióban elérhető egyenleget, korlátozva az egyenleg terhére megvehető további ajánlatok listáját.

Részletfizetés (P)

Nagyértékű hardverelemek esetében merül fel az igény a részletfizetés használatára. A Reactor képes előre meghatározott üzleti feltételek mint például a kezdőösszeg, vagy a törlesztések minimum és maximum száma alapján fizetési részleteket kalkulálni.

Nemfunkcionális képességek

Magas rendelkezésreállás

A Reactor fel van készítve arra, hogy párhuzamosan, több példányban fusson, kétféle mód közül választva: stateful és stateless failover. A stateful failover esetében az egyes példányok egy nagy rendelkezésre állású memória-adatbázison keresztül megosztják egymással az általuk kezelt tranzakciók adatait, ezért bármely példány képes bármely tranzakciót továbbvinni. A stateless failover esetében ez a megosztás nem létezik, minden példány csak a saját tranzakcióit kezeli, ezért az egyes példányok megcímzésére egy ún. sticky mechanizmust használunk a tranzakciók azonosítóinak alapján.

Alacsony válaszidő

A Reactort nagy teljesítményű online környezetekkel való együttműködésre terveztük, mint pl. online áruházak, IVR vagy chatbot rendszerek. Ezekben a környezetekben a lassú válasz nem megengedhető. A Reactor esetében a maximális válaszidő néhány extrém bonyolult művelet esetében sem haladja meg az 1 másodpercet, míg a válaszidő várható érteke 0,3 másodperc alatt marad.

Nagy teljesítmény

A Reactor nagy számú tranzakció párhuzamos kezelésére képes, melyekben ezres vagy milliós nagyságrendben lehetnek a használt üzleti szabály példányok.

Adatvédelem

A tranzakciók sok esetben kezelnek személyes adatokat vagy más érzékeny üzleti információkat. Ezek kapcsán fontos, hogy a részletes logolási mechanizmusok figyelnek a logok megfelelő korosítására illetve arra, hogy a logokba ne kerüljenek bele érzékeny adatok, mint pl. egy szolgáltatás aktiválásakor megadott a használathoz szükséges jelszó.

Többcsatornás működés, csatorna-azonosítás alapján

A Reactort több üzleti csatorna is használhatja egy időben, mely használatot korlátozni, illetve védeni lehet a csatornákhoz rendelt authentikációs és authorizációs szabályokkal. Az authorizációs funkció biztosítja, hogy illetéktelenek ne tudják a Reactort használni, ahogy azt is meggátolja, hogy az egyes felhasználók egymás tranzakcióihoz hozzáférjenek.

A többcsatornás működés egy további lényeges lehetőséget biztosít: az egyes csatornák át tudják adni az általuk kezelt tranzakciót egy másik csatorna számára ellenőrzésre, vagy véglegesítésre. Pl. egy chatbot egy új szolgáltatás értékesítését egy már beazonosított ügyfél számára, amely műveletet a back-office-ban ellenőrizhetnek az adminisztrátorok a rendelés véglegesítése előtt. Ebben a szituációban a chatbot elküldi a tranzakció azonosítóját a back-office alkalmazás feladatlistájába, majd az adminisztrátor a saját felhasználói felületeit használva pontosan onnan folytathatja a rendelés kezelését, ahol a bot azt abbahagyta az ügyféllel folytatott interakcióban.

Tranzakciók korosítása (T)

A nagy teljesítmény biztosításának egyik feltétele, hogy az árván maradt tranzakciókat a Reactor automatikusan eldobja. A lejárat ideje környezeti paraméterként beállítható, mely által a Reactor jól tud alkalmazkodni a különböző típusú környezetek elvárásaihoz.

Az adatmodell testreszabhatósága

A Reactor alapvetően általános Termékajánlat elemekkel dolgozik, amelyek az adott piacon értékesített termékeket reprezentálják. A tervezés legfőbb irányelve itt az volt, hogy a lehető legtöbb funkció általánosan használható legyen. A speciális terméktípusoknak, mint pl. a telekommunikációban használatos tarifacsomagoknak, vagy a készletnyilvántartás alapján értékesíthető hardware elemeknek megvannak a maguk sajátosságai. Ezeket a sajátosságokat a Reactor használatbavétele előtt az adott környezet számára összeállítjuk, megőrizve közben az általánosan használható képességeket.

Referencia adatok

A Reactor egy referencia adatbázison keresztül konfigurálható, amely az összes kezelendő Termékajánlatot és a rájuk vonatkozó összes szabálypéldányt tartalmazza. A referencia adatokat a tranzakciók előre felolvassák, csökkentve ezzel az adatbáziselérések számát és maximalizálva a műveletek performanciáját.