Dit is een conceptueel overzicht op hoog niveau van de architectuur van de business rules engine. Het staat boven de echte code. Als u een business rules engine aan het bouwen bent – is het zeer waarschijnlijk dat u deze tekst nuttig vindt.

Ooit heb ik een Business Rules Engine gebouwd die bedrijfsautomatisering mogelijk maakte voor kleine en middelgrote bedrijven en die ook alle mogelijkheden en potentie had om grote ondernemingen goed van dienst te zijn. Het was een weg van een gewone software-applicatie naar een verfijnde en complexe oplossing die voldeed aan de strenge eisen van schaalbaarheid, onderhoudbaarheid en uitbreidbaarheid. Deze tekst zal een overzicht geven van wat de Business Rules Engine is en een van de moderne benaderingen beschrijven die u zou kunnen overwegen bij het bouwen van dit soort software.

Om te beginnen is het belangrijk om basisbegrippen te definiëren. Business rules engines bestaan al heel lang in de industrie in een of andere vorm en er zijn enkele definities gegeven voor zowat elke term die we gaan gebruiken. Laten we beginnen met een “business rule” – er is een bekende definitie voor deze term. Een “business rule” is dus:

Een verklaring die een of ander aspect van het bedrijf definieert of beperkt. Zij is bedoeld om de bedrijfsstructuur te bevestigen of om het gedrag van het bedrijf te controleren of te beïnvloeden.

T. Morgan, Bedrijfsregels en informatiesystemen. Boston: Addison-Wesley Publishing, 2002

Business rules hebben een zeer breed toepassingsgebied en kunnen worden toegepast op elk aspect van het bedrijf. Bijvoorbeeld, de regel “Als een klant binnenkomt, begroet hem dan met een warme glimlach en een vriendelijk “Hallo” wordt door de bedrijfsmedewerker toegepast bij ontmoetingen met klanten. Een andere regel kan de aanpak van routinetaken door een specifieke rol in een bedrijf definiëren of aan banden leggen. Met de gestaag groeiende populariteit van softwareoplossingen zoals CRM-systemen en de totale integratie van software in een verscheidenheid van bedrijfsdomeinen, zijn de meeste bedrijfsprocessen gedeeltelijk of volledig gegevensgeoriënteerd geworden. Dit heeft geleid tot de transformatie van bedrijfsregels zodat ze softwaregeoriënteerd zijn geworden, bijvoorbeeld, de bedrijfsregel “Wanneer een klant iets koopt in onze winkel, bel hem dan later op om te vragen of hij nog andere gerelateerde goederen wil kopen” is getransformeerd in een modernere “Wanneer een klant iets koopt in onze online winkel, stuur hem dan later een e-mail met een lijst van andere gerelateerde goederen”. Tegenwoordig houden veel bedrijven zich bij hun dagelijkse activiteiten voornamelijk bezig met gegevens. Aangezien de meeste bedrijven, ongeacht hun omvang, softwareoplossingen hebben geïntegreerd in hun bedrijfsactiviteiten, kan de definitie van de term “bedrijfsregel” op een meer specifieke manier worden gedefinieerd door een verduidelijking (vetgedrukt) toe te voegen aan de hierboven vermelde definitie van T. Morgan:

Een bedrijfsregel is een verklaring die een bepaald aspect van het bedrijf definieert of beperkt. Het is bedoeld om de bedrijfsstructuur te bevestigen of om het gedrag van het bedrijf te controleren of te beïnvloeden. Het wordt opgeslagen als een gegevensconstructie in de persistente opslag en bevat een atomair pakket van bedrijfslogica. Het wordt via een softwareoplossing automatisch beheerd en toegepast op de bedrijfsprocessen.

Na de term “bedrijfsregel” is gedefinieerd, wordt de term “Business Rules Engine Management System” (BRMS) als volgt gedefinieerd:

BRMS is een softwareoplossing voor het beheren (opslaan, bewerken en verwijderen, enz.) van bedrijfsregels en voor het toepassen ervan op de bedrijfsprocessen van het bedrijf.

De aanschaf van een licentie en de integratie van commerciële BRMS’en in de IT-infrastructuur van een bedrijf kunnen zeer duur zijn, zodat bedrijven vaak interne oplossingen implementeren wanneer zij bedrijfsprocessen of andere soorten processen willen automatiseren.
BRMS’en kunnen een essentieel en vitaal onderdeel van elk bedrijf worden. Soms kan het succes van een bedrijf afhangen van de bedrijfsregels die het heeft en hoe goed deze bedrijfsregels worden beheerd en toegepast.

De gegevensconstructie van bedrijfsregels

Een bedrijfsregel kan worden weergegeven als een consequente reeks atomaire opdrachten. De commando’s kunnen voorwaardelijke gegevensanalyse, wachttijdcommando’s, actieuitvoeringscommando’s, enz. omvatten. Het voorbeeld van de bedrijfsregel “Als een klant iets koopt in onze onlinewinkel, stuur hem dan later een e-mail met een lijst van andere verwante goederen” is een goed en algemeen voorbeeld en veel andere bedrijfsregels kunnen een zeer vergelijkbare logische structuur hebben:

De regelverwerkingsstroom wordt gestart wanneer een aankoop is gedaan en een aantal bedrijfslogica wordt toegepast door het uitvoeren van het commando “Stuur de koper een e-mail met relevante goederenaanbiedingen”. Het kan gebeuren dat de koper het e-mailabonnement heeft uitgeschakeld. Dan moet de extra voorwaarde aan de bedrijfsregel worden toegevoegd – “als het e-mailabonnement van de koper is ingeschakeld”:

De opdrachten worden vervolgens uitgevoerd en er is nu een opdracht voor gegevensanalyse om te controleren of de koper een actief e-mailabonnement heeft. Zo ja, ga dan verder met de uitvoering van de volgende opdracht van de bedrijfsregel. En zo niet – ga dan niet verder, de business rule wordt als voltooid beschouwd, de verwerkingsstroom stopt, de volgende commando’s worden niet uitgevoerd.

De koper kan ook een SMS-abonnement hebben, en als dat actief is, moet er ook een ander commando zijn – “Stuur een SMS met gerelateerde promo-aanbieding”. Hiermee wordt vertakking geïntroduceerd in de logica van de bedrijfsregel:

De vertakkingen van de regel worden onafhankelijk van elkaar verwerkt. De verwerking van een van de takken kan stoppen bij de opdracht om de voorwaarde te evalueren en een andere tak kan tot het einde worden verwerkt.

De UI van de BRMS-clienttoepassing voor de weergave van een bedrijfsregel kan op verschillende manieren worden geïmplementeerd (elke grafische weergave in de vorm van een boom werkt):

De gegevensconstructie voor bedrijfsregels is een directed rooted tree graph (een gerichte acyclische grafiek, die een boom als onderliggende ongerichte grafiek heeft). De hoekpunten van de bedrijfsregelgrafiek worden voorgesteld met verschillende soorten opdrachten: opdrachten voor gegevensanalyse, opdrachten voor de uitvoering van acties, opdrachten voor de wachttijd, enz. Elke directed rooted out-tree heeft een root – een vertex waarvan alle edges naar buiten wijzen. Elke regel begint dus met een speciaal vertex (of root vertex in grafiektheoretische termen) – het vertex dat het beginpunt voor de regelverwerking aangeeft.

CRUD operaties op de business rule data construct

Omdat de data construct wordt gerepresenteerd met een directed rooted tree en nooit een ander soort grafiek, verlost dit ons van de ongemakken die gepaard gaan met het opslaan van algemene grafiekstructuren in RDBMS (zoals het opslaan van de vertices en edges in verschillende tabellen wat kan resulteren in een verhoogd aantal opzoekingen voor een enkele regel op te halen, etc.). En dit is van cruciaal belang omdat het duidelijk is dat tijdens de normale werkzaamheden van het BRMS gegevens lookups veel vaker voorkomen, dan andere bewerkingen zoals inserts, updates of deletes.

Even ter herinnering – elk hoekpunt van de bedrijfsregel vertegenwoordigt een atomaire opdracht. Deze wordt in de RDBMS-tabel opgeslagen als een record met attributen zoals het type commando, de beschrijving en andere aanvullende gegevens. In een boom heeft elke vertex één of slechts één ouder (behalve de root vertex, die geen ouders heeft), dus elk record moet een ID van de ouder vertice bevatten. Het is ook handig om een andere tabel te hebben die de regelrecords bevat met de gegevens die relevant zijn voor de bedrijfsregel zelf. Er is geen probleem met het opslaan van de business rule data constructies van enige complexiteit met deze aanpak.

De CRUD operaties zijn vrij rechttoe rechtaan. De business rule veranderingen kunnen updates van een of beide tabellen vereisen – rule of commando. Bij het verwijderen of invoegen van commando’s is het noodzakelijk om de referenties tussen de commando’s te onderhouden (dit is in wezen het verwijderen of invoegen van knooppunten in een boom).

Een van de BRMS-componenten, laten we het een manager noemen, moet de beschreven databasebewerkingen uitvoeren en een API bieden voor CRUD-bewerkingen op bedrijfsregels.

De verwerking van de bedrijfsregel

De verwerking van de bedrijfsregel begint wanneer een bepaalde bedrijfsgebeurtenis plaatsvindt. Dat kan van alles zijn – een gebruiker heeft ingelogd, een aankoop is gedaan, een geldbedrag is overgemaakt, enz. Dit soort activiteit moet worden bijgehouden en het BRMS moet erover worden geïnformeerd via een of ander transport. AMQP is waarschijnlijk het meest geschikt voor dit soort taken.

1. Het hele concept is gebaseerd op een microservicearchitectuur. De microservice voor bedrijfsevenementen luistert naar alle bedrijfsevenementen door een wachtrij te declareren en deze te binden aan een specifieke uitwisseling op een RabbitMQ-uitwisselingsserver. Wanneer een bedrijfsactiviteit (die als belangrijk wordt beschouwd en wordt bijgehouden) plaatsvindt in het hoofdsoftwaresysteem, wordt het bericht naar de RabbitMQ-uitwisselingsserver gezonden. Het bevat informatie over wat er is gebeurd, alsmede een aantal relevante aanvullende gegevens. De bedrijfsgebeurtenis kan worden geïdentificeerd met een attribuut van welke aard dan ook dat in het bericht wordt doorgegeven of als een routingsleutel wordt gebruikt, bijvoorbeeld de string purchase.completed. Het bericht wordt vervolgens geconsumeerd door de BRMS-microservice voor bedrijfsevenementen.

2. Wanneer de microservice voor bedrijfsevenementen het bericht ontvangt van het hoofdsoftwaresysteem, vraagt zij de microservice voor managers of er in de database bedrijfsregels zijn die de juiste regel-trigger hebben voor de gebeurtenis uit de bedrijfsactiviteit. En als er zo’n passende bedrijfsregel is, retourneert de manager-microservice de initiële opdrachtgegevens aan de business event consumer-microservice. Het ophalen van deze gegevens bij de manager gebeurt via gRPC en wordt gevisualiseerd met een stippellijn.

3. Direct nadat de microservice voor bedrijfsevenementen heeft geantwoord met de initiële opdrachtgegevens, is de microservice voor bedrijfsevenementconsumenten klaar om de verwerking van de bedrijfsregel te initialiseren. De afnemer van de bedrijfsgebeurtenis stelt een ander bericht op waarin de initiële opdrachtgegevens (ontvangen van de microdienst van de manager) en de gegevens van de bedrijfsgebeurtenis, ontvangen van het hoofdsoftwaresysteem, worden ingekapseld. Het stuurt het via de AMQP naar een interne BRMS-uitwisseling. De routeringssleutel van het bericht komt overeen met het type opdracht.

4. Initiële opdrachtverwerkingsmicroservice consumeert het bericht (het luistert naar de wachtrij waar de berichten met routeringssleutel initial zijn gestapeld). Vervolgens voert het zijn logica uit (in een basisgeval bevat het initiële blok geen logica) en vraagt het de manager of er volgende opdrachten in de bedrijfsregel zijn (dit zijn de opdrachten met parent_id gelijk aan de id van de opdracht die nu wordt verwerkt). En zo ja, dan ontvangt het de volgende commando gegevens en stuurt zowel de business event gegevens als de volgende commando gegevens naar de interne RabbitMQ server. Ja, het lijkt nu op linked list traversal, en als de regel vertakkingen heeft is het een tree traversal! Dit is hoe de bedrijfsregel opdracht-voor-opdracht wordt verwerkt. Nog een belangrijk ding hier – het is die context, de bedrijfsgebeurtenis gegevens worden doorgegeven aan elk kind commando. Het is een context van de unieke bedrijfsregel uitvoering. Het kan later worden gebruikt in de gegevensanalyse-commandoprocessor en de actiecommandoprocessor.

Laten we ter illustratie aannemen dat de voorbeeldregel een structuur als deze heeft: initieel commando -> voorwaardelijk gegevensanalyse-commando -> bedrijfsactie-commando. Het volgende commando na het initiële commando is dan het data-analysecommando.

5. De verwerkingseenheid voor analyseopdrachten verbruikt het bericht met de routeringssleutel analysis uit de interne uitwisseling. Op basis van de evaluatie van de voorwaarden die zijn beschreven in het analysecommando van de bedrijfsregel en met behulp van de bedrijfsgebeurtenisgegevens, kan de regeluitwerkingsstroom hier worden voortgezet of gestopt. Als het stopt – worden geen verdere bedrijfsregel commando’s uitgevoerd. Als de uitvoeringsstroom doorgaat, vraagt de processor van de analyseopdracht Manager om de volgende opdrachten van de bedrijfsregel, haalt deze op en publiceert nog een bericht naar de interne uitwisselingsserver.

6. Ten slotte is er een bericht in de interne uitwisseling, dat klaar is voor de actie-opdrachtverwerker om te worden geconsumeerd. Als de uitvoeringsstroom van de bedrijfsregel tot aan dit commando is gekomen, betekent dit dat in deze tak van de regel elke voorwaarde die in het gegevensanalysecommando was opgenomen, waar was en dat de uitvoeringsstroom niet werd onderbroken. De actie-opdrachtverwerker voert de actie uit, b.v. stuurt een e-mail.

Dit soort grafiek traversal is depth-first, en wanneer een commando met 2 of meer kind-opdrachten wordt aangetroffen, begint de gelijktijdige depth-first traversal voor elke tak als gevolg van de asynchrone aard van de business rule verwerking in het beschreven systeem.

Scaling

De beschreven aanpak maakt niet alleen een grote scheiding van zorgen mogelijk, maar kan ook veel geld besparen als het gaat om het betalen van de IaaS-rekeningen. Eindgebruikers maken een verscheidenheid aan bedrijfsregels met verschillende aantallen commando’s van verschillende soorten en verschillende aantallen vertakkingen. Maar de veel voorkomende schaalscenario’s zijn als volgt:
1. Het aantal business events neemt toe – de business event consumer schaalt op.
2. Het aantal business rules dat geassocieerd (getriggerd) wordt door de business events neemt toe – de initiële command processor schaalt mee op met de manager.
3. Er zijn veel analyse commands in de business rules – de analyse command processor schaalt op
4. Er moeten te veel actie commands worden uitgevoerd – de actie command processor schaalt op.

Betrouwbaarheid

Het bloedvat van het systeem is het transport. Om het systeem operationeel te houden onder hoge belasting, moet de interne berichtenuitwisseling zeer betrouwbaar zijn. RabbitMQ voorziet in clustering en voldoet goed aan de betrouwbaarheidseisen (https://www.rabbitmq.com/clustering.html).

Andere opdrachttypen

Er kan nog andere bedrijfslogica in het systeem worden ingevoerd. Een van de populaire en veelgevraagde commandotypes is een “time-wait”-commando (bv. “Wacht 45 minuten, ga dan verder”). Met de invoering van het “time-wait”-commando is de verwerking van de bedrijfsregel niet langer een real-time verwerking, aangezien zij gedurende enige tijd kan worden opgeschort. Dergelijke veranderingen vereisen bijkomende commandoprocessoren en een paar aanpassingen aan de gegevensstructuren die buiten het bestek van deze tekst vallen. Knoeien met de tijd kan moeilijk zijn en het schrijven van een service die de schema’s en de tijd bedient kan een uitdaging zijn, hier is een voorbeeld van een goede: https://github.com/nextiva/krolib

Derde partij alternatieven

Er zijn bekende alternatieven van rules engines/workflow engines, hier zijn top 3 van (IMHO):
1. Comunda – het is een volwassen product met community en enterprise versies, die je wellicht wilt gebruiken. Uiteraard is de enterprise versie betaald.
2. Luigi – het is een workflow engine tool ontwikkeld door Spotify voor hun interne behoeften, maar al gebruikt door tientallen andere bedrijven.
3. Apache Airflow – dit is een ander bekend product dat heeft bewezen capabel, handig en aanpasbaar te zijn.

Wat deze tools verbindt, is dat ze allemaal gebruik maken van direct acyclic graphs als de datastructuur die de business rules of workflows representeert. Het is geen verrassing.

Er kunnen andere producten zijn die de aandacht waard zijn, maar elk onderzoek zou moeten beginnen met deze drie.

Conclusie

Het bouwen van je eigen business rules engine kan een uitdaging zijn, maar het is de moeite waard. Je krijgt niet alleen een systeem in huis, maar het is ook gebouwd volgens de specifieke eisen van je bedrijf. Een goed DevOps-team is een must als het gaat om het handhaven van betrouwbaarheid, schaalbaarheid en monitoring. Uiteindelijk krijg je een fantastisch product waar je trots op kunt zijn.