Tämä on korkean tason käsitteellinen katsaus liiketoimintasääntömoottorin arkkitehtuuriin. Se on todellisen koodin yläpuolella. Jos olet rakentamassa liiketoimintasääntömoottoria – on erittäin todennäköistä, että pidät tätä tekstiä hyödyllisenä.

Aikanaan rakensin liiketoimintasääntömoottorin, joka mahdollisti liiketoiminnan automatisoinnin pienille ja keskisuurille yrityksille ja jolla oli myös kaikki valmiudet ja potentiaali palvella hyvin suuria yrityksiä. Se oli tie tavallisesta ohjelmistosovelluksesta kehittyneeksi ja monimutkaiseksi ratkaisuksi, joka täytti kovat skaalautuvuus-, ylläpidettävyys- ja laajennettavuusvaatimukset. Tässä tekstissä luodaan yleiskatsaus siihen, mitä Business Rules Engine on, ja kuvataan yksi nykyaikaisista lähestymistavoista sen rakentamiseen, jota voit harkita, kun rakennat tällaista ohjelmistoa.

Aluksi on tärkeää määritellä perustermit. Liiketoimintasääntömoottoreita on ollut alalla melko pitkään muodossa tai toisessa, ja melko jokaiselle käyttämällemme termille on annettu joitakin määritelmiä. Aloitetaan ”liiketoimintasäännöstä” – tälle termille on olemassa tunnettu määritelmä. ”Liiketoimintasääntö” on siis:

Lausuma, joka määrittelee tai rajoittaa jotakin liiketoiminnan osa-aluetta. Sen tarkoituksena on vahvistaa liiketoiminnan rakenne tai valvoa tai vaikuttaa liiketoiminnan käyttäytymiseen.

T. Morgan, Liiketoimintasäännöt ja tietojärjestelmät. Boston: Addison-Wesley Publishing, 2002

Liiketoimintasääntöjen soveltamisala on hyvin laaja ja niitä voidaan soveltaa mihin tahansa liiketoiminnan osa-alueeseen. Esimerkiksi sääntöä ”Kun asiakas tulee sisään, tervehdi häntä lämpimästi hymyillen ja ystävällisesti tervehtien” soveltaa yrityksen työntekijä tavatessaan asiakkaita. Toinen sääntö voi määritellä tai rajoittaa tietyn roolin lähestymistapoja rutiinitehtävien ratkaisemiseen yrityksessä. CRM-järjestelmien kaltaisten ohjelmistoratkaisujen suosion jatkuvasti kasvaessa ja ohjelmistojen täydellisen integroitumisen myötä useisiin liiketoiminta-alueisiin valtaosasta liiketoimintaprosesseista on tullut osittain tai kokonaan datakeskeisiä. Tämä on johtanut liiketoimintasääntöjen muuttumiseen ohjelmistokeskeisiksi, esimerkiksi liiketoimintasääntö ”Kun asiakas ostaa jotain myymälästä, soita hänelle myöhemmin ja kysy, haluaisiko hän ostaa muita siihen liittyviä tuotteita” on muuttunut nykyaikaisemmaksi ”Kun asiakas ostaa jotain verkkokaupastamme, lähetä hänelle myöhemmin sähköpostiviesti, jossa luetellaan muita siihen liittyviä tuotteita”. Nykyään monet yritykset käsittelevät päivittäisessä toiminnassaan enimmäkseen tietoja. Kun otetaan huomioon, että suurimmalla osalla kaikenkokoisista yrityksistä on integroituja ohjelmistoratkaisuja liiketoimintaansa, termin ”liiketoimintasääntö” määritelmää voidaan tarkentaa lisäämällä selvennys (se on lihavoitu) edellä mainittuun T. Morganin määritelmään:

Liiketoimintasääntö on lausunto, joka määrittelee tai rajoittaa jotakin liiketoiminnan osaa. Sen tarkoituksena on vakuuttaa liiketoiminnan rakenne tai valvoa tai vaikuttaa liiketoiminnan käyttäytymiseen. Se tallennetaan datarakenteena pysyvään tallennustilaan, ja se sisältää atomisen paketin liiketoimintalogiikkaa. Sitä hallinnoidaan ja sovelletaan yrityksen liiketoimintaprosesseihin automaattisesti ohjelmistoratkaisun avulla.

Kun termi ”liiketoimintasääntö” on määritelty, termi ”Business Rules Engine Management System” (BRMS) määritellään seuraavasti:

BRMS on ohjelmistoratkaisu, jonka avulla hallinnoidaan (tallennetaan, muokataan ja poistetaan jne.) liiketoimintasääntöjä sekä sovelletaan niitä yrityksen liiketoimintaprosesseihin.

Kaupalliset BRMS-järjestelmät voivat olla erittäin kalliita lisenssin hankkimiseksi ja niiden integroimiseksi yrityksen IT-infrastruktuuriin, joten yritykset ottavat usein käyttöön omia ratkaisujaan, kun ne kohtaavat tarvetta liiketoimintaprosessien tai muunlaisten prosessien automatisointiin.
BRMS-järjestelmistä voi tulla olennainen ja elintärkeä osa mitä tahansa yritystä. Joskus yrityksen menestys voi riippua siitä, millaisia liiketoimintasääntöjä sillä on ja miten hyvin näitä liiketoimintasääntöjä hallitaan ja sovelletaan.

Liiketoimintasääntöjen tietorakenne

Liiketoimintasääntö voidaan esittää johdonmukaisena sarjana atomisia komentoja. Komennot voivat sisältää ehdollisen data-analyysin, ajan odottamista koskevia komentoja, toimintojen suorittamista koskevia komentoja jne. Liiketoimintasääntöesimerkki ”Kun asiakas ostaa jotain verkkokaupastamme, lähetä hänelle myöhemmin sähköpostiviesti, jossa luetellaan muut siihen liittyvät tavarat” on hyvä ja yleinen esimerkki, ja monilla muilla liiketoimintasäännöillä voi olla hyvin samanlainen looginen rakenne:

Säännön käsittelyvirta käynnistyy, kun osto on tehty, ja jotakin liiketoimintalogiikkaa sovelletaan suorittamalla komento ”Lähetä ostajalle sähköpostiviesti, jossa on asiaankuuluvat tavaratarjoukset”. Saattaa käydä niin, että ostaja on poistanut sähköpostitilauksen käytöstä. Silloin liiketoimintasääntöön on lisättävä lisäehto – ”jos ostajalla on sähköpostitilaus käytössä”:

Käskyt suoritetaan tämän seurauksena, ja nyt on data-analyysi-komento, jolla tarkistetaan, onko ostajalla aktiivinen sähköpostitilaus. Jos on – siirry liiketoimintasäännön seuraavan komennon suorittamiseen. Ja jos ei – älä jatka, liiketoimintasääntö katsotaan päättyneeksi, käsittelyvirta pysähtyy, seuraavia komentoja ei suoriteta.

Ostajalla voi olla myös tekstiviestitilaus, ja jos se on aktiivinen, pitäisi olla myös toinen komento – ”Lähetä tekstiviesti ja siihen liittyvä tarjous”. Tämän myötä liiketoimintasäännön logiikkaan otetaan käyttöön haarautuminen:

Säännön haarautumiset käsitellään toisistaan riippumatta. Yhden haaran käsittely voi pysähtyä ehdon arviointikomentoon ja toista haaraa voidaan käsitellä loppuun asti.

BRMS:n asiakassovelluksen käyttöliittymä liiketoimintasäännön esittämiseksi voidaan toteuttaa eri tavoin (mikä tahansa puumainen graafinen esitys toimii):

Liiketoimintasäännön tietokonstruktio on suunnattu juurtunut puugraafi (suunnattu asyklinen graafi, jonka perustana on suuntaamaton graafi puu). Liiketoimintasääntögraafin kärkipisteet esitetään erityyppisillä komennoilla: data-analyysikomennoilla, toimintojen suorituskomennoilla, aika-odotuskomennoilla jne. Jokaisella suunnatulla, juurtuneella ulospäin suuntautuvalla puulla on juuri – huippu, josta kaikki särmät osoittavat ulospäin. Näin ollen jokainen sääntö alkaa erityisellä pisteellä (tai juuripisteellä graafiteorian termein) – pisteellä, joka määrittää säännön käsittelyn aloituspisteen.

CRUD-operaatiot liiketoimintasääntöjen tietorakenteelle

Koska tietorakenne esitetään suunnatun juuripuun eikä koskaan minkään muunlaisen graafin avulla, tämä vapauttaa meidät hankaluuksista, joita liittyy yleisten graafirakenteiden tallentamiseen RDBMS-tietokantaan (kuten kärkipisteiden ja reuna-alueiden tallentaminen eri taulukoihin, mikä voi johtaa lisääntyneeseen hakujen määrään yksittäisen säännön hakua varten, jne). Ja tämä on kriittistä, koska on selvää, että BRMS:n normaalien toimintojen aikana tietojen hakuja tapahtuu paljon useammin kuin muita operaatioita, kuten lisäyksiä, päivityksiä tai poistoja.

Muistutuksena – jokainen liiketoimintasäännön huippu edustaa atomista komentoa. Se tallennetaan RDBMS-tauluun tietueena, jossa on attribuutteja, kuten komennon tyyppi, kuvaus ja muita lisätietoja. Puussa jokaisella pisteellä on yksi ja vain yksi vanhempi (paitsi juuripisteellä, jolla ei ole vanhempia), joten jokaisessa tietueessa pitäisi olla vanhemman pisteen tunnus. On myös kätevää, että on olemassa toinen taulukko, johon tallennetaan sääntötietueet, joissa on itse liiketoimintasäännön kannalta olennaiset tiedot. Tällä lähestymistavalla ei ole mitään ongelmaa minkään monimutkaisten liiketoimintasäännön tietorakenteiden tallentamisessa.

CRUD-operaatiot ovat melko suoraviivaisia. Liiketoimintasäännön muutokset voivat vaatia päivityksiä jompaankumpaan tai molempiin taulukoihin – sääntöön tai komentoon. Kun käskyjä poistetaan tai lisätään, on tarpeen ylläpitää käskyjen välisiä viittauksia (tämä on lähinnä solmujen poistamista tai lisäämistä puuhun).

Jonkin BRMS-komponentin, kutsuttakoon sitä manageriksi, tulisi suorittaa kuvatut tietokantaoperaatiot ja tarjota API liiketoimintasääntöjen CRUD-operaatioita varten.

Liiketoimintasäännön käsittely

Liiketoimintasäännön käsittely käynnistyy, kun jokin tietty liiketoimintatapahtuma tapahtuu. Se voi olla mitä tahansa – käyttäjä on kirjautunut sisään, ostos on tehty, jokin rahasumma on siirretty jne. Tällaista toimintaa olisi seurattava ja BRMS:lle olisi ilmoitettava siitä jonkin kuljetuksen kautta. AMQP soveltuu todennäköisesti parhaiten tällaiseen tehtävään.

1. Koko konsepti perustuu mikropalveluarkkitehtuuriin. Liiketapahtumien kuluttajan mikropalvelu kuuntelee kaikkia liiketapahtumia ilmoittamalla jonon ja sitomalla sen tiettyyn vaihtoon RabbitMQ-vaihtopalvelimella. Kun liiketoimintatoimi (jota pidetään merkittävänä ja jota seurataan) tapahtuu pääohjelmistojärjestelmässä, viesti lähetetään RabbitMQ-vaihtopalvelimelle. Se sisältää tietoa siitä, mitä on tapahtunut, sekä joitakin asiaankuuluvia lisätietoja. Liiketoimintatapahtuma voidaan yksilöidä minkä tahansa viestissä välitettävän attribuutin avulla tai sitä voidaan käyttää reititysavaimena, esimerkiksi merkkijono purchase.completed. Tämän jälkeen BRMS-liiketoimintatapahtuman kuluttajan mikropalvelu kuluttaa viestin.

2. Kun liiketoimintatapahtuman kuluttajan mikropalvelu saa viestin pääohjelmistojärjestelmästä, se kysyy sen jälkeen hallinnoijamikropalvelulta, jos tietokannassa on liiketoimintasääntöjä, joilla on liiketoiminta-aktiviteettitapahtumalle sopiva sääntökäynnistin. Jos tällainen vastaava liiketoimintasääntö löytyy, manager-mikropalvelu palauttaa alkuperäiset komentotiedot liiketoimintatapahtuman kuluttajamikropalvelulle. Tämä tietojen haku managerilta tapahtuu gRPC:n kautta, ja se on visualisoitu katkoviivalla.

3. Heti sen jälkeen, kun manager-mikropalvelu on vastannut alkukomentotiedoilla, liiketoimintatapahtuman kuluttaja-mikropalvelu on valmis aloittamaan liiketoimintasäännön käsittelyn. Liiketapahtuman kuluttaja muodostaa toisen viestin, joka kapseloi alkuperäiset komentotiedot (jotka on saatu manager-mikropalvelusta) ja pääohjelmistojärjestelmästä saadut liiketapahtuman tiedot. Se lähettää sen AMQP:n kautta sisäiseen BRMS-vaihtoon. Viestin reititysavain vastaa komennon tyyppiä.

4. Alustavan komennon käsittelyä suorittava mikropalvelu kuluttaa viestin (se kuuntelee jonoa, jossa reititysavaimella initial varustetut viestit ovat pinottuna). Sitten se tekee logiikkansa (perustapauksessa alkulohkossa ei ole logiikkaa) ja kysyy managerilta, onko liiketoimintasäännössä seuraavia komentoja (nämä ovat komentoja, joiden parent_id on yhtä suuri kuin parhaillaan käsiteltävän komennon id). Jos näin on, se vastaanottaa seuraavan komennon tiedot ja lähettää sekä liiketapahtumatiedot että seuraavan komennon tiedot sisäiselle RabbitMQ-palvelimelle. Kyllä, se näyttää nyt linkitetyn listan läpikäynniltä, ja kun säännössä on haaroja, se on puun läpikäynti! Näin liiketoimintasääntöä käsitellään komento kerrallaan. Toinen tärkeä asia tässä – tässä yhteydessä liiketoimintatapahtumatiedot välitetään jokaiselle lapsikomennolle. Se on ainutkertaisen liiketoimintasäännön suorituksen konteksti. Sitä voidaan käyttää myöhemmin data-analyysikomennon käsittelijässä ja toimintakomennon käsittelijässä.

Oletetaan havainnollistamistarkoituksessa, että esimerkkisäännön rakenne on seuraavanlainen: Aloituskomento -> ehdollinen data-analyysikomento -> liiketoimintatoimikomento. Tällöin alkukomennon jälkeen seuraava komento on data-analyysikomento.

5. Analyysikomennon prosessori kuluttaa sanoman, jossa on reititysavain analysis, sisäisestä vaihdosta. Liiketoimintasäännön analyysikomennossa kuvattujen ehtojen arvioinnin ja liiketapahtumatietojen perusteella säännön suoritusvirta voi jatkua tai pysähtyä tähän. Jos se pysähtyy – muita liiketoimintasäännön komentoja ei suoriteta. Jos suoritusvirta jatkuu, analyysikomennon käsittelijä kysyy managerilta seuraavia liiketoimintasääntökomentoja, hakee ne ja julkaisee toisen viestin sisäiselle vaihtopalvelimelle.

6. Lopuksi sisäisessä vaihdossa on viesti, joka on valmis toimintakäskyprosessorin kulutettavaksi. Jos liiketoimintasäännön suoritusvirta on päässyt tähän asti tähän komentoon, se tarkoittaa, että tässä säännön haarassa jokainen ehto, joka oli data-analyysikomennossa, oli totuudenmukainen eikä suoritusvirta katkennut. Toimintakäskyprosessori suorittaa toiminnon, esimerkiksi lähettää sähköpostin.

Tällainen graafin läpikäynti on syvyyssuuntainen, ja kun kohdataan käsky, jolla on kaksi tai useampia lapsikomentoja, samanaikainen syvyyssuuntainen läpikäynti alkaa jokaisessa haarassa, koska liiketoimintasäännön käsittely on kuvatussa järjestelmässä asynkronista.

Skaalautuminen

Kuvatun lähestymistavan avulla voidaan paitsi erottaa huolenaiheet toisistaan hyvin, myös säästää paljon rahaa IaaS-laskuja maksettaessa. Loppukäyttäjät luovat erilaisia liiketoimintasääntöjä, joissa on erilainen määrä erityyppisiä komentoja ja erilainen määrä haaroja. Yleiset skaalautumisskenaariot ovat kuitenkin seuraavat:
1. Liiketoimintatapahtumien määrä kasvaa – liiketoimintatapahtumien kuluttaja skaalautuu.
2. Liiketoimintatapahtumiin liittyvien (laukaisevien) liiketoimintasääntöjen määrä kasvaa – alkuperäisten komentojen prosessori skaalautuu managerin mukana.
3. Liiketoimintasäännöissä on paljon analyysikomentoja – analyysikomentojen prosessori skaalautuu.
4. Liian monta toimintakomentoa joudutaan suorittamaan – toimintakomentojen prosessori skaalautuu.

Luotettavuus

Systeemien verisuonet ovat kuljetus. Jotta järjestelmä pysyisi toimintakykyisenä suuressa kuormituksessa, sisäisen viestinvaihdon on oltava erittäin luotettavaa. RabbitMQ tarjoaa klusterointia ja täyttää luotettavuusvaatimukset hyvin (https://www.rabbitmq.com/clustering.html).

Muut komentotyypit

Järjestelmään voidaan ottaa käyttöön muuta liiketoimintalogiikkaa. Yksi suosituimmista ja kysytyimmistä komentotyypeistä on aika-odotuskomento (esim. ”Odota 45 minuuttia ja jatka sitten”). Time-wait-komennon käyttöönoton myötä liiketoimintasäännön käsittely ei ole enää reaaliaikaista käsittelyä, koska se voidaan keskeyttää joksikin aikaa. Tällaiset muutokset edellyttävät lisää käskyprosessoreita ja muutamia muutoksia tietorakenteisiin, jotka eivät kuulu tämän tekstin piiriin. Ajan kanssa sotkeminen voi olla vaikeaa, ja aikatauluja ja aikaa operoivan palvelun kirjoittaminen voi olla haastavaa, tässä on esimerkki hyvästä palvelusta: https://github.com/nextiva/krolib

Kolmannen osapuolen vaihtoehdot

Sääntömoottoreille/työnkulkumoottoreille on tunnettuja vaihtoehtoja, tässä on niistä top 3 (IMHO):
1. Comunda – se on kypsä tuote, josta on yhteisö- ja yritysversiot, joita kannattaa käyttää. Yritysversio on luonnollisesti maksullinen.
2. Luigi – se on Spotifyn sisäisiin tarpeisiinsa kehittämä työnkulkumoottorityökalu, mutta sitä käyttävät jo kymmenet muut yritykset.
3. Apache Airflow – tämä on toinen tunnettu tuote, joka on osoittanut kykenevyytensä, helppokäyttöisyytensä ja räätälöitävyytensä.

Nämä työkalut yhdistää se, että ne kaikki käyttävät suoria asyklisiä graafeja tietorakenteena, joka edustaa liiketoimintasääntöjä tai työnkulkuja. Se ei ole yllätys.

Voi olla muitakin huomionarvoisia tuotteita, mutta kaikki tutkimukset tulisi aloittaa näistä kolmesta.

Johtopäätös

Oman liiketoimintasääntömoottorin rakentaminen voi olla haastavaa, mutta se on palkitsevaa. Sen lisäksi, että saat oman järjestelmän, se on myös rakennettu yrityksesi erityisvaatimusten mukaisesti. Hyvä DevOps-tiimi on välttämätön, kun on kyse luotettavuuden, skaalautuvuuden ja seurannan ylläpitämisestä. Loppujen lopuksi saat loistavan tuotteen, josta voit olla ylpeä.