Jedná se o koncepční přehled architektury stroje pro obchodní pravidla na vysoké úrovni. Je nad skutečným kódem. Pokud stavíte engine pro obchodní pravidla – je vysoce pravděpodobné, že se vám tento text bude hodit.

Kdysi dávno jsem postavil Business Rules Engine, který umožňoval automatizaci podnikání pro malé a střední firmy a zároveň měl všechny možnosti a potenciál dobře sloužit velkým podnikům. Byla to cesta od běžné softwarové aplikace k sofistikovanému a komplexnímu řešení, které splňovalo náročné požadavky na škálovatelnost, udržovatelnost a rozšiřitelnost. Tento text poskytne přehled o tom, co je Business Rules Engine, a popíše jeden z moderních přístupů k jeho budování, který můžete při budování tohoto druhu softwaru zvážit.

Na začátek je důležité definovat základní pojmy. Motory obchodních pravidel se v oboru vyskytují v té či oné podobě již poměrně dlouho a pro téměř každý termín, který budeme používat, jsou uvedeny nějaké definice. Začněme „obchodním pravidlem“ – pro tento pojem existuje známá definice. Takže „obchodní pravidlo“ je:

Příkaz, který definuje nebo omezuje nějaký aspekt podnikání. Je určeno k potvrzení struktury podniku nebo k řízení či ovlivnění chování podniku.

T. Morgan, Pravidla podnikání a informační systémy. Boston: Addison-Wesley Publishing, 2002

Pravidla podnikání mají velmi široký rozsah a lze je aplikovat na jakýkoli aspekt podnikání. Například pravidlo „Když přijde zákazník, pozdravte ho vřelým úsměvem a přátelským „Dobrý den“ uplatňuje zaměstnanec firmy při setkání se zákazníky. Jiné pravidlo může definovat nebo omezovat přístupy k řešení rutinních úkolů konkrétní rolí ve firmě. Se stále rostoucí oblibou softwarových řešení, jako jsou systémy CRM, a s celkovou integrací softwaru do nejrůznějších podnikových oblastí se většina podnikových procesů částečně nebo plně orientuje na data. To vedlo k transformaci obchodních pravidel tak, že se stala softwarově orientovanými, například obchodní pravidlo „Když si zákazník koupí něco v našem obchodě, zavolej mu později s dotazem, zda si chce koupit další související zboží“ se změnilo na modernější „Když si zákazník koupí něco v našem internetovém obchodě, pošli mu později e-mail s výčtem dalšího souvisejícího zboží“. V dnešní době se mnoho společností při své každodenní činnosti zabývá převážně daty. Vzhledem k tomu, že většina podniků všech velikostí má do svých obchodních činností integrována softwarová řešení, lze definici pojmu „obchodní pravidlo“ upřesnit tak, že k výše uvedené definici T. Morgana přidáme upřesnění (je uvedeno tučně):

Business pravidlo je výrok, který definuje nebo omezuje nějaký aspekt podnikání. Je určeno k prosazení struktury podniku nebo k řízení či ovlivnění chování podniku. Je uloženo jako datová konstrukce v trvalém úložišti a obsahuje atomický balíček obchodní logiky. Je spravováno a automaticky aplikováno na obchodní procesy podniku prostřednictvím softwarového řešení.

Po definování pojmu „obchodní pravidlo“ je pojem „systém pro správu obchodních pravidel“ (BRMS) definován takto:

BRMS je softwarové řešení pro správu (ukládání, úpravu a mazání atd.) obchodních pravidel a také pro jejich aplikaci na obchodní procesy podniku.

Standartní komerční BRMS mohou být velmi nákladné na nákup licence a na integraci do podnikové IT infrastruktury, proto společnosti často implementují vlastní řešení, pokud se setkají s potřebou automatizace obchodních procesů nebo jiných druhů procesů.
BRMS se mohou stát nezbytnou a důležitou součástí každého podniku. Někdy může úspěch podniku záviset na tom, jaká má obchodní pravidla a jak dobře jsou tato obchodní pravidla spravována a aplikována.

Datová konstrukce obchodních pravidel

Obchodní pravidlo lze reprezentovat jako následnou řadu atomických příkazů. Příkazy mohou zahrnovat podmíněnou analýzu dat, příkazy pro čekání na čas, příkazy pro provedení akce atd. Příklad obchodního pravidla „Když si zákazník něco koupí v našem internetovém obchodě, pošlete mu později e-mail se seznamem dalšího souvisejícího zboží“ je dobrý a obecný a mnoho dalších obchodních pravidel může mít velmi podobnou logickou strukturu:

Proud zpracování pravidla se spustí, jakmile dojde k nákupu, a použije se určitá obchodní logika provedením příkazu „Pošli kupujícímu e-mail s nabídkami souvisejícího zboží“. Může se stát, že kupující má zakázaný odběr e-mailů. Pak je třeba do obchodního pravidla přidat další podmínku – „pokud má kupující povolený odběr e-mailu“:

Příkazy se provedou následně a nyní existuje příkaz pro analýzu dat, který zjišťuje, zda má kupující aktivní odběr e-mailu. Pokud ano – přejděte k provedení dalšího příkazu obchodního pravidla. A pokud ne – nepokračujte, obchodní pravidlo se považuje za ukončené, tok zpracování se zastaví, další příkazy se neprovedou.

Kupující může mít také předplatné SMS, a pokud je aktivní, měl by existovat i další příkaz – „Odeslat SMS se související promo nabídkou“. Tím je do logiky obchodního pravidla zavedeno větvení:

Větve pravidla se zpracovávají nezávisle na sobě. Zpracování jedné z větví se může zastavit na příkazu vyhodnocení podmínky a další větev může být zpracována až do konce.

Uživatelské rozhraní aplikace BRMS na straně klienta pro reprezentaci obchodního pravidla může být realizováno různými způsoby (bude fungovat jakýkoli druh stromové grafické reprezentace):

Datovou konstrukcí obchodního pravidla je směrovaný zakořeněný stromový graf (směrovaný acyklický graf, jehož základním neorientovaným grafem je strom). Vrcholy grafu obchodních pravidel jsou reprezentovány různými druhy příkazů: příkazy pro analýzu dat, příkazy pro provádění akcí, příkazy pro čekání na čas atd. Každý směrovaný vykořeněný strom má kořen – vrchol, z něhož směřují všechny hrany. Každé pravidlo tedy začíná speciálním vrcholem (neboli kořenovým vrcholem z hlediska teorie grafů) – vrcholem, který označuje vstupní bod pro zpracování pravidla.

CRUD operace nad datovou konstrukcí obchodních pravidel

Protože datová konstrukce je reprezentována pomocí směrovaného kořenového stromu a nikdy žádným jiným druhem grafu, zbavuje nás to nepříjemností, které provázejí ukládání obecných grafových struktur pomocí RDBMS (jako je ukládání vrcholů a hran do různých tabulek, což může mít za následek zvýšený počet vyhledávání pro jedno načtení pravidla atd.) A to je rozhodující, protože je zřejmé, že při běžném provozu BRMS dochází k vyhledávání dat mnohem častěji, než k jiným operacím, jako jsou vložení, aktualizace nebo odstranění.

Jen pro připomenutí – každý vrchol obchodního pravidla představuje atomický příkaz. Je uložen v tabulce RDBMS jako záznam s atributy, jako je typ příkazu, popis a další doplňující údaje. Ve stromu má každý vrchol jednoho jediného rodiče (kromě kořenového vrcholu, který nemá žádné rodiče), proto by každý záznam měl obsahovat ID rodičovského vrcholu. Je také vhodné mít další tabulku, která obsahuje záznamy o pravidlech s údaji relevantními pro samotné obchodní pravidlo. Při tomto přístupu není problém s ukládáním datových konstrukcí obchodních pravidel jakékoli složitosti.

Operace CRUD jsou poměrně jednoduché. Změny obchodních pravidel mohou vyžadovat aktualizace jedné nebo obou tabulek – pravidla nebo příkazu. Při mazání nebo vkládání příkazů je nutné zachovat odkazy mezi příkazy (jde v podstatě o mazání nebo vkládání uzlů do stromu).

Jedna z komponent BRMS, říkejme jí manažer, by měla provádět popsané databázové operace a poskytovat API pro operace CRUD nad obchodními pravidly.

Zpracování obchodního pravidla

Zpracování obchodního pravidla začíná, když nastane určitá obchodní událost. Může to být cokoli – uživatel se přihlásil, byl proveden nákup, byla převedena nějaká částka peněz atd. Tento druh činnosti by měl být sledován a systém BRMS by o něm měl být informován prostřednictvím nějakého přenosu. Pro tento druh úloh se s největší pravděpodobností nejlépe hodí protokol AMQP.

1. Celý koncept je postaven na architektuře mikroslužeb. Mikroslužba konzumenta obchodních událostí naslouchá všem obchodním událostem prostřednictvím deklarace fronty a její vazby na konkrétní výměnu na výměnném serveru RabbitMQ. Když v hlavním softwarovém systému dojde k obchodní činnosti (která je považována za významnou a je sledována), je zpráva odeslána na výměnný server RabbitMQ. Ta obsahuje informace o tom, co se stalo, a také některé relevantní doplňující údaje. Obchodní událost může být identifikována atributem libovolného druhu předaným ve zprávě nebo použitým jako směrovací klíč, například řetězec nákup.dokončeno. Zprávu pak konzumuje mikroslužba konzumenta obchodních událostí BRMS.

2. Když mikroslužba konzumenta obchodních událostí obdrží zprávu z hlavního softwarového systému, pak se dotáže mikroslužby správce, zda v databázi existují obchodní pravidla, která mají příslušný spouštěč pravidla pro událost obchodní činnosti. A pokud takové odpovídající obchodní pravidlo existuje, vrátí mikroslužba manažera mikroslužbě konzumenta obchodní události údaje o počátečním příkazu. Toto načtení dat od správce se provádí prostřednictvím gRPC a je vizualizováno přerušovanou čarou.

3. Hned poté, co mikroslužba správce odpoví počátečními daty příkazu, je mikroslužba konzumenta obchodních událostí připravena zahájit zpracování obchodního pravidla. Konzument obchodní události vytvoří další zprávu, která zapouzdří počáteční data příkazu (přijatá od mikroslužby manažera) a data obchodní události, přijatá z hlavního softwarového systému. Odesílá je prostřednictvím AMQP do interní výměny BRMS. Směrovací klíč zprávy odpovídá typu příkazu.

4. Mikroslužba pro zpracování počátečního příkazu zprávu spotřebuje (naslouchá frontě, kde jsou naskládány zprávy se směrovacím klíčem initial). Poté provede svou logiku (v základním případě počáteční blok neobsahuje žádnou logiku) a dotáže se správce, zda v obchodním pravidle existují následné příkazy (jedná se o příkazy s parent_id rovným id právě zpracovávaného příkazu). A pokud ano, získá údaje o dalším příkazu a odešle jak údaje o obchodní události, tak údaje o dalším příkazu na interní server RabbitMQ. Ano, nyní to vypadá jako procházení spojového seznamu, a když má pravidlo větve, je to procházení stromu! Takto je obchodní pravidlo zpracováváno příkaz po příkazu. Ještě jedna důležitá věc – v tomto kontextu se údaje o obchodní události předávají každému podřízenému příkazu. Je to kontext jedinečného provedení obchodního pravidla. Později je lze použít ve zpracovateli příkazů analýzy dat a zpracovateli akčních příkazů.

Pro ilustraci předpokládejme, že příklad pravidla má tuto strukturu: počáteční příkaz -> podmíněný příkaz analýzy dat -> příkaz obchodní akce. Pak dalším příkazem po počátečním příkazu je příkaz analýzy dat.

5. Příkaz analýzy dat je příkazem analýzy dat. Analytický příkazový procesor spotřebuje zprávu se směrovacím klíčem analysis z interní výměny. Na základě vyhodnocení podmínek, které jsou popsány v analytickém příkazu obchodního pravidla, a s využitím údajů o obchodní události zde může pokračovat nebo se zastavit tok provádění pravidla. Pokud se zastaví – neprovedou se žádné další příkazy obchodního pravidla. Pokud tok provádění pokračuje, zpracovatel analytického příkazu se dotáže manažera na další příkazy obchodního pravidla, načte je a vydá další zprávu na interní výměnný server.

6. V případě, že tok provádění pokračuje, zpracovatel analytického příkazu se dotáže manažera na další příkazy obchodního pravidla, načte je a vydá další zprávu na interní výměnný server. Nakonec je v interní výměně zpráva, která je připravena ke spotřebování zpracovatelem akčních příkazů. Pokud tok provádění business pravidla došel až k tomuto příkazu, znamená to, že v této větvi pravidla byla každá podmínka, která byla v příkazu analýzy dat, pravdivá a tok provádění nebyl přerušen. Zpracovatel akčního příkazu provede akci, např. odešle e-mail.

Tento druh procházení grafu je hloubkový, a když se vyskytne příkaz se dvěma nebo více podřízenými příkazy, začne současné hloubkové procházení pro každou větev vzhledem k asynchronní povaze zpracování obchodních pravidel v popisovaném systému.

Škálování

Popsaný přístup umožňuje nejen velké oddělení obav, ale také může ušetřit spoustu peněz, pokud jde o placení účtů za IaaS. Koncoví uživatelé vytvářejí různá obchodní pravidla s různým počtem příkazů různého druhu a různým počtem větví. Běžné scénáře škálování jsou však následující:
1. Zvyšuje se počet obchodních událostí – škáluje se konzument obchodních událostí.
2. Zvyšuje se počet obchodních pravidel spojených (spouštěných) obchodními událostmi – spolu se správcem se škáluje i procesor původních příkazů.
3. V obchodních pravidlech je mnoho analytických příkazů – škáluje se procesor analytických příkazů
4. Je třeba provést příliš mnoho akčních příkazů – škáluje se procesor akčních příkazů.

Spolehlivost

Cévou systému je doprava. Aby systém zůstal funkční i při vysokém zatížení, měla by být vnitřní výměna zpráv vysoce spolehlivá. RabbitMQ poskytuje clustering a dobře splňuje požadavky na spolehlivost (https://www.rabbitmq.com/clustering.html).

Další typy příkazů

Do systému lze zavést jakoukoli další obchodní logiku. Jedním z oblíbených a žádaných typů příkazů je časový čekací příkaz (např. „Počkejte 45 minut, pak pokračujte“). Po zavedení příkazu time-wait již zpracování obchodního pravidla není zpracováním v reálném čase, protože může být na určitou dobu pozastaveno. Takové změny vyžadují další příkazové procesory a několik úprav datových struktur, které jsou mimo rozsah tohoto textu. Hrátky s časem mohou být obtížné a napsat službu, která pracuje s plány a časem, může být náročné, zde je příklad dobré služby: https://github.com/nextiva/krolib

Alternativy třetích stran

Existují známé alternativy strojů pravidel/workflow, zde jsou tři nejlepší z nich (IMHO):
1. Comunda – jedná se o vyzrálý produkt s komunitní a podnikovou verzí, který můžete chtít používat. Podniková verze je samozřejmě placená.
2. Luigi – jedná se o nástroj workflow engine vyvinutý společností Spotify pro její interní potřeby, ale používají ho již desítky dalších společností.
3. Apache Airflow – jedná se o další známý produkt, který se osvědčil jako schopný, pohodlný a přizpůsobitelný.

Tyto nástroje spojuje to, že všechny používají přímé acyklické grafy jako datovou strukturu, která reprezentuje obchodní pravidla nebo workflow. Není to žádné překvapení.

Mohou existovat i další produkty, které stojí za pozornost, ale každé zkoumání by mělo začít u těchto tří.

Závěr

Vytvořit si vlastní engine obchodních pravidel může být náročné, ale je to přínosné. Nejenže získáte vlastní systém, ale navíc je sestaven podle konkrétních požadavků vašeho podniku. Dobrý tým DevOps je nutností, pokud jde o udržení spolehlivosti, škálovatelnosti a monitorování. Nakonec získáte fantastický produkt, na který můžete být hrdí.