Detta är en konceptuell översikt på hög nivå av arkitekturen för Business Rules Engine. Den ligger ovanför den riktiga koden. Om du bygger en business rules engine – är det högst troligt att du kan finna den här texten användbar.

En gång i tiden byggde jag en Business Rules Engine som möjliggjorde affärsautomatisering för små och medelstora företag och som också hade alla möjligheter och potential att tjäna väl till stora företag. Det var en väg från en vanlig mjukvaruapplikation till en sofistikerad och komplex lösning som uppfyllde de tuffa kraven på skalbarhet, underhållbarhet och utbyggbarhet. Den här texten kommer att ge en översikt över vad Business Rules Engine är och beskriva ett av de moderna tillvägagångssätt för att bygga den som du kan överväga när du bygger den här typen av programvara.

För att börja är det viktigt att definiera grundläggande termer. Affärsregelmotorer har funnits i branschen ganska länge i en eller annan form och det finns vissa definitioner som ges för i stort sett varje term som vi kommer att använda. Låt oss börja med en ”affärsregel” – det finns en välkänd definition för denna term. En ”affärsregel” är alltså:

Ett uttalande som definierar eller begränsar någon aspekt av verksamheten. Det är avsett att bekräfta verksamhetens struktur eller att kontrollera eller påverka verksamhetens beteende.

T. Morgan, Business Rules and Information Systems. Boston: Addison-Wesley Publishing, 2002

Business rules har ett mycket brett tillämpningsområde och kan tillämpas på alla aspekter av verksamheten. Till exempel tillämpas regeln ”När en kund kommer in, hälsa på honom med ett varmt leende och ett vänligt ”Hej” av företagets anställda när de möter kunder. En annan regel kan definiera eller begränsa tillvägagångssättet för att lösa rutinuppgifter för en viss roll i ett företag. I och med den stadigt ökande populariteten för programvarulösningar som CRM-system och den totala integrationen av programvara i en rad olika affärsområden har en majoritet av affärsprocesserna delvis eller helt och hållet blivit datainriktade. Detta har lett till att affärsreglerna har omvandlats så att de blivit mjukvaruorienterade, t.ex. har affärsregeln ”När en kund köper något i vår butik ringer du honom senare och frågar om han eller hon vill köpa andra relaterade varor” omvandlats till en modernare ”När en kund köper något i vår webbutik skickar du honom ett e-postmeddelande med en förteckning över andra relaterade varor senare”. I dag arbetar många företag huvudsakligen med data i sin dagliga verksamhet. Med hänsyn till att majoriteten av företag av alla storlekar har integrerade programvarulösningar i sin affärsverksamhet kan definitionen av begreppet ”affärsregel” definieras på ett mer specifikt sätt genom att lägga till ett förtydligande (det är i fetstil) till den ovannämnda definitionen av T. Morgan:

En affärsregel är ett uttalande som definierar eller begränsar någon aspekt av verksamheten. Det är avsett att hävda verksamhetsstrukturen eller att kontrollera eller påverka verksamhetens beteende. Den lagras som en datakonstruktion i det beständiga lagret och innehåller ett atomärt paket av affärslogik. Den hanteras och tillämpas på företagets affärsprocesser automatiskt via en programvarulösning.

Med begreppet ”affärsregel” definierat definieras begreppet ”Business Rules Engine Management System” (BRMS) på följande sätt:

BRMS är en programvarulösning för att hantera (lagra, redigera och radera, etc.) affärsregler samt för att tillämpa dem på företagets affärsprocesser.

Standalone kommersiella BRMS kan vara extremt dyra att köpa licensen och att integrera dem i företagets IT-infrastruktur, därför implementerar företagen ofta interna lösningar när de stöter på ett behov av att automatisera affärsprocesser eller andra typer av processer.
BRMS kan bli en väsentlig och vital del av varje företag. Ibland kan ett företags framgång bero på de affärsregler som det har och hur väl dessa affärsregler hanteras och tillämpas.

Datakonstruktionen för affärsregler

En affärsregel kan representeras som en följdriktig serie av atomära kommandon. Kommandona kan omfatta villkorlig dataanalys, kommandon för tidsväntetid, kommandon för utförande av åtgärder osv. Exemplet med affärsregeln ”När en kund köper något i vår webbutik skickar vi honom senare ett e-postmeddelande med en förteckning över andra relaterade varor” är ett bra och generiskt exempel och många andra affärsregler kan ha en mycket liknande logisk struktur:

Flödet för behandling av regeln startas när ett köp har gjorts och viss affärslogik tillämpas genom att kommandot ”Skicka köparen ett e-postmeddelande med relevanta erbjudanden om varor” utförs. Det kan hända att köparen har inaktiverat e-postprenumerationen. Då måste ytterligare ett villkor läggas till i affärsregeln – ”om köparen har aktiverad e-postprenumeration”:

Kommandona utförs i enlighet med varandra och det finns nu ett dataanalyskommando för att kontrollera om köparen har en aktiv e-postprenumeration. Om så är fallet – gå vidare till utförandet av nästa kommando i affärsregeln. Om inte – fortsätt inte, affärsregeln anses avslutad, bearbetningsflödet stannar och de efterföljande kommandona utförs inte.

Köparen kan också ha en SMS-prenumeration, och om den är aktiv bör det också finnas ett annat kommando – ”Skicka ett SMS med tillhörande kampanjerbjudande”. Med detta införs förgrening i affärsregelns logik:

Regelns förgreningar behandlas oberoende av varandra. Behandlingen av en av grenarna kan avbrytas vid kommandot för utvärdering av villkoret och en annan gren kan behandlas fram till slutet.

Upplägget i BRMS-klienttillämpningen för att representera en affärsregel kan implementeras på olika sätt (vilken typ av grafisk trädrepresentation som helst fungerar):

Datakonstruktionen för en affärsregel är ett riktat rotat trädgraf (ett riktat acykliskt grafen, som har ett träd som ett underliggande oriktat graf). Vertikalerna i affärsregelgrafen representeras av olika typer av kommandon: dataanalyskommandon, kommandon för utförande av åtgärder, tidsavvaktningskommandon osv. Varje riktat rotad träd har en rot – en topp som har alla kanter som pekar ut från den. Varje regel börjar alltså med en speciell topp (eller rotspets i grafteoretiska termer) – den topp som anger ingångspunkten för regelbehandlingen.

CRUD-operationer på datakonstruktionen för affärsregler

Då datakonstruktionen representeras med ett riktat rotat träd och aldrig någon annan typ av graf, befriar detta oss från de olägenheter som följer med lagring av generella grafstrukturer med RDBMS (som att lagra hörn och kanter i olika tabeller, vilket kan resultera i ett ökat antal sökningar för att hämta en enskild regel, etc.). Och detta är kritiskt eftersom det är uppenbart att under den normala driften av BRMS-data sker sökningar mycket oftare än andra operationer, t.ex. insättningar, uppdateringar eller borttagningar.

Som en påminnelse – varje hörn i en affärsregel representerar ett atomärt kommando. Det sparas i RDBMS-tabellen som en post med attribut som kommandotyp, beskrivning och andra kompletterande uppgifter. I ett träd har varje vertex en och endast en förälder (utom rotvertexen, som inte har några föräldrar), vilket innebär att varje post bör innehålla ett ID för den överordnade vertexen. Det är också lämpligt att ha en annan tabell som innehåller regelposter med de uppgifter som är relevanta för själva affärsregeln. Det finns inga problem med att lagra affärsregelns datakonstruktioner av någon komplexitet med detta tillvägagångssätt.

Den CRUD-operationen är ganska okomplicerad. Ändringarna av affärsregeln kan kräva uppdateringar av en eller båda tabellerna – regel eller kommandot – eller båda tabellerna. När man tar bort eller lägger in kommandon är det nödvändigt att upprätthålla referenserna mellan kommandona (detta är i huvudsak att ta bort eller lägga in noder i ett träd).

En av BRMS-komponenterna, låt oss kalla den manager, bör utföra de beskrivna databasoperationerna och tillhandahålla ett API för CRUD-operationer på affärsregler.

Bearbetningen av affärsregeln

Bearbetningen av affärsregeln startar när en viss affärshändelse inträffar. Det kan vara vad som helst – en användare har loggat in, ett köp har gjorts, ett visst belopp har överförts osv. Denna typ av aktivitet bör spåras och BRMS bör informeras om den via någon transport. AMQP är troligen bäst lämpad för den här typen av uppgifter.

1. Hela konceptet bygger på en mikrotjänstarkitektur. Mikrotjänsten för konsumenten av affärshändelser lyssnar på alla affärshändelser genom att deklarera en kö och binda den till ett specifikt utbyte på en RabbitMQ-utbytesserver. När en affärsverksamhet (som anses viktig och spåras) inträffar i huvudprogramvarusystemet skickas meddelandet till RabbitMQ-utbytesservern. Det innehåller information om vad som har hänt samt vissa relevanta tilläggsdata. Affärshändelsen kan identifieras med ett attribut av vilket slag som helst som överförs i meddelandet eller används som en routningsnyckel, t.ex. en sträng purchase.completed. Meddelandet konsumeras sedan av BRMS-mikrotjänsten för konsumenter av affärshändelser.

2. När mikrotjänsten för konsumenter av affärshändelser får meddelandet från huvudprogramvarusystemet frågar den sedan mikrotjänsten för förvaltare om det finns några affärsregler i databasen som har en lämplig regelutlösare för händelsen för affärsaktiviteten. Om det finns en sådan matchande affärsregel returnerar förvaltarmikrotjänsten de initiala kommandodata till mikrotjänsten för konsumenten av affärshändelser. Denna datahämtning från förvaltaren sker via gRPC och visualiseras med en streckad linje.

3. Direkt efter det att förvaltaren mikrotjänst har svarat med de initiala kommandodata är affärshändelsekonsumentens mikrotjänst redo att initialisera behandlingen av affärsregeln. Konsumenten av affärshändelsen bildar ett annat meddelande som kapslar in de initiala kommandodata (som mottagits från manager microservice) och data från affärshändelsen, som mottagits från huvudprogramvarusystemet. Det skickar det via AMQP till ett internt BRMS-utbyte. Meddelandets routningsnyckel motsvarar kommandotypen.

4. Mikrotjänsten för behandling av det initiala kommandot konsumerar meddelandet (den lyssnar på kön där meddelandena med routningsnyckel initial är staplade). Sedan utför den sin logik (i ett grundläggande fall innehåller initialt block ingen logik) och frågar förvaltaren om det finns efterföljande kommandon i affärsregeln (dessa är de kommandon med parent_id som är lika med id för det kommando som för närvarande behandlas). Och om så är fallet tar den emot nästa kommandodata och skickar både affärshändelsedata och nästa kommandodata till den interna RabbitMQ-servern. Ja, det ser nu ut som en länkad listtraversering, och när regeln har grenar är det en trädtraversering! Det här är hur affärsregeln bearbetas kommando för kommando. En annan viktig sak här – i det sammanhanget överförs affärshändelsedata till varje underkommando. Det är en kontext för det unika utförandet av affärsregeln. Det kan användas senare i processorn för dataanalyskommandon och processorn för åtgärdskommandon.

För illustrationsändamål antar vi att exempelregeln har en struktur som denna: initialt kommando -> villkorligt dataanalyskommando -> åtgärdskommando för affärshändelse. Då är nästa kommando efter initial kommandot dataanalyskommandot.

5. Processorn för analysorder konsumerar meddelandet med routningsnyckeln analysis från det interna utbytet. Baserat på utvärderingen av de villkor som beskrivs i analyskommandot för affärsregeln och med hjälp av data om affärshändelser kan flödet för regelexekvering fortsätta eller upphöra här. Om det slutar – utförs inga ytterligare affärsregelkommandon. Om flödet av utförandet fortsätter, frågar processorn för analyskommandot manager efter nästa affärsregelkommandon, hämtar dem och publicerar ytterligare ett meddelande till den interna utbytesservern.

6. Slutligen finns det ett meddelande i det interna utbytet, som är redo att konsumeras av processorn för handlingsorder. Om flödet för utförandet av affärsregeln har kommit så här långt till detta kommando betyder det att i denna gren av regeln var varje villkor som fanns i dataanalyskommandot sanningsenligt och att flödet för utförandet inte avbröts. Åtgärdskommandoprocessorn utför åtgärden, t.ex. skickar ett e-postmeddelande.

Denna typ av graftraversering är djupgående, och när ett kommando med två eller flera underordnade kommandon påträffas, börjar den samtidiga djupgående traverseringen för varje gren på grund av den asynkrona karaktären hos behandlingen av affärsregler i det beskrivna systemet.

Skalering

Det beskrivna tillvägagångssättet möjliggör inte bara en stor åtskillnad av problem utan kan också spara mycket pengar när det gäller att betala IaaS-räkningarna. Slutanvändarna skapar en mängd olika affärsregler med olika antal kommandon av olika slag och olika antal förgreningar. Men de vanligaste skalningsscenarierna är följande:
1. Antalet affärshändelser ökar – konsumenten av affärshändelser skalar upp
2. Antalet affärsregler som är kopplade till (utlöses) av affärshändelserna ökar – processorn för initiala kommandon skalar upp tillsammans med förvaltaren
3. Det finns många analyskommandon i affärsreglerna – processorn för analyskommandon skalar upp
4. Alltför många åtgärdskommandon måste utföras – processorn för åtgärdskommandon skalar upp

Trovärdighet

Systemets blodkärl är transporten. För att systemet ska kunna fortsätta att fungera under hög belastning bör det interna meddelandeutbytet vara mycket tillförlitligt. RabbitMQ tillhandahåller klusterbildning och uppfyller kraven på tillförlitlighet väl (https://www.rabbitmq.com/clustering.html).

Andra kommandotyper

Alla andra affärslogiker kan införas i systemet. En av de populära och efterfrågade kommandotyperna är kommandot ”vänta i tid” (t.ex. ”Vänta i 45 minuter och fortsätt sedan”). När kommandot ”vänta” införs är behandlingen av affärsregeln inte längre en behandling i realtid, eftersom den kan avbrytas under en viss tid. Sådana ändringar kräver ytterligare kommandoprocessorer och några justeringar av datastrukturerna som ligger utanför den här textens räckvidd. Det kan vara svårt att mixtra med tiden och att skriva en tjänst som hanterar schemat och tiden kan vara en utmaning, här är ett exempel på en bra tjänst: https://github.com/nextiva/krolib

Alternativ från tredje part

Det finns välkända alternativ till regelmotorer/arbetsflödesmotorer, här är de tre bästa av dem (IMHO):
1. Comunda – det är en mogen produkt med community- och enterprise-versioner, som du kanske vill använda. Självklart är företagsversionen betald.
2. Luigi – det är ett arbetsflödesmotorverktyg som utvecklats av Spotify för deras interna behov, men som redan används av dussintals andra företag.
3. Apache Airflow – detta är en annan välkänd produkt som har visat sig vara kapabel, bekväm och anpassningsbar.

Det som förenar dessa verktyg är att de alla använder direkta acykliska grafer som datastruktur som representerar affärsregler eller arbetsflöden. Det är ingen överraskning.

Det kan finnas andra produkter som är värda att uppmärksammas, men varje undersökning bör börja med dessa tre.

Slutsats

Att bygga sin egen affärsregelmotor kan vara utmanande, men det är givande. Du får inte bara ett eget system, utan det är också byggt enligt de specifika kraven i ditt företag. Ett bra DevOps-team är ett måste när det gäller att upprätthålla tillförlitlighet, skalbarhet och övervakning. När allt kommer omkring får du en fantastisk produkt som du kan vara stolt över.