Questa è una panoramica concettuale di alto livello dell’architettura del motore di regole aziendali. È al di sopra del codice reale. Se state costruendo un motore di regole di business – è molto probabile che possiate trovare utile questo testo.

Una volta, ho costruito un Business Rules Engine che permetteva l’automazione del business per le piccole e medie imprese e aveva anche tutte le capacità e il potenziale per servire bene le grandi imprese. Era un modo per passare da una normale applicazione software a una soluzione sofisticata e complessa che soddisfaceva i difficili requisiti di scalabilità, manutenibilità ed estendibilità. Questo testo fornirà una panoramica di ciò che è il Business Rules Engine e descriverà uno dei moderni approcci per costruirlo che si può considerare quando si costruisce questo tipo di software.

Per cominciare è importante definire i termini di base. I motori di regole di business sono stati in giro nell’industria per un bel po’ di tempo in una forma o nell’altra e ci sono alcune definizioni date per quasi tutti i termini che stiamo per usare. Iniziamo con una “regola di business” – c’è una definizione ben nota per questo termine. Quindi una “regola di business” è:

Una dichiarazione che definisce o vincola qualche aspetto del business. Ha lo scopo di affermare la struttura del business o di controllare o influenzare il comportamento del business.

T. Morgan, Regole di business e sistemi informativi. Boston: Addison-Wesley Publishing, 2002

Le regole di business hanno una portata molto ampia e possono essere applicate a qualsiasi aspetto del business. Per esempio, la regola “Quando arriva un cliente, salutalo con un caldo sorriso e un amichevole “Ciao” è applicata dall’impiegato dell’azienda quando incontra i clienti. Un’altra regola può definire o vincolare gli approcci alla risoluzione dei compiti di routine da parte di un ruolo specifico in un’azienda. Con l’aumento costante della popolarità delle soluzioni software come i sistemi CRM e con l’integrazione totale del software in una varietà di domini aziendali, la maggior parte dei processi aziendali è diventata parzialmente o completamente orientata ai dati. Questo ha portato alla trasformazione delle regole di business in modo che diventassero orientate al software, per esempio, la regola di business “Quando un cliente compra qualcosa dal nostro negozio, chiamalo più tardi per chiedergli se vuole comprare altri beni correlati” si è trasformata in una più moderna “Quando un cliente compra qualcosa dal nostro negozio online mandagli un’email che elenca altri beni correlati più tardi”. Al giorno d’oggi molte aziende hanno a che fare principalmente con i dati nelle loro operazioni quotidiane. Tenendo conto che la maggior parte delle aziende di tutte le dimensioni hanno integrato soluzioni software alle loro attività di business, la definizione del termine “regola di business” può essere definita in modo più specifico aggiungendo una precisazione (è in grassetto) alla suddetta definizione di T. Morgan:

Una regola di business è una dichiarazione che definisce o vincola qualche aspetto del business. Ha lo scopo di affermare la struttura del business o di controllare o influenzare il comportamento del business. È memorizzata come un costrutto di dati nella memoria persistente e contiene un pacchetto atomico di logica aziendale. È gestita e applicata ai processi di business dell’azienda automaticamente tramite una soluzione software.

Definito il termine “regola di business”, il termine “Business Rules Engine Management System” (BRMS) è definito come segue:

BRMS è una soluzione software per gestire (memorizzare, modificare e cancellare, ecc.) le regole di business così come per applicarle ai processi di business dell’azienda.

I BRMS commerciali possono essere estremamente costosi per acquistare la licenza e per integrarli nell’infrastruttura IT dell’azienda, quindi le aziende spesso implementano soluzioni in-house quando hanno bisogno di automatizzare i processi di business o altri tipi di processi.
I BRMS possono diventare una parte essenziale e vitale di qualsiasi business. A volte il successo di un business può dipendere dalle regole di business che ha e da quanto bene queste regole di business sono gestite e applicate.

Il costrutto di dati delle regole di business

Una regola di business può essere rappresentata come una serie conseguente di comandi atomici. I comandi possono includere analisi di dati condizionali, comandi di attesa di tempo, comandi di esecuzione di azioni, ecc. L’esempio della regola di business “Quando un cliente compra qualcosa dal nostro negozio online gli manda un’email elencando altri beni correlati più tardi” è un buon esempio generico e molte altre regole di business possono avere una struttura logica molto simile:

Il flusso di elaborazione delle regole viene avviato quando viene effettuato un acquisto e viene applicata una certa logica di business eseguendo il comando “Invia all’acquirente un’email con le offerte di beni correlati”. Può succedere che l’acquirente abbia disattivato l’iscrizione all’e-mail. Allora, la condizione addizionale deve essere aggiunta alla regola di business – “se l’acquirente ha l’abbonamento email abilitato”:

I comandi sono eseguiti di conseguenza e c’è ora un comando di analisi dei dati per controllare se l’acquirente ha un abbonamento email attivo. Se è così – procedete all’esecuzione del prossimo comando della regola di business. E se no – non procedere, la regola di business è considerata finita, il flusso di elaborazione si ferma, i comandi successivi non vengono eseguiti.

L’acquirente può anche avere un abbonamento SMS, e se è attivo, ci dovrebbe essere anche un altro comando – “Invia un SMS con relativa offerta promozionale”. Con questo, si introduce la ramificazione nella logica della regola di business:

I rami della regola sono elaborati indipendentemente l’uno dall’altro. L’elaborazione di uno dei rami può fermarsi sul comando di valutazione della condizione e un altro ramo può essere elaborato fino alla fine.

L’UI dell’applicazione client-side BRMS per rappresentare una regola di business può essere implementata in vari modi (qualsiasi tipo di rappresentazione grafica ad albero funzionerà):

Il costrutto di dati delle regole di business è un grafo ad albero con radici dirette (un grafo aciclico diretto, che ha un albero come grafo non diretto sottostante). I vertici del grafo delle regole di business sono rappresentati con diversi tipi di comandi: comandi di analisi dei dati, comandi di esecuzione delle azioni, comandi di attesa, ecc. Ogni albero radicato diretto ha una radice – un vertice che ha tutti i bordi che puntano fuori da esso. Così ogni regola inizia con un vertice speciale (o vertice radice in termini di teoria dei grafi) – il vertice che designa il punto di ingresso per l’elaborazione della regola.

Operazioni CRUD sul costrutto di dati delle regole di business

Siccome il costrutto di dati è rappresentato con un albero con radici dirette e mai con qualsiasi altro tipo di grafico, questo ci solleva dagli inconvenienti che accompagnano la memorizzazione di strutture grafiche generali con RDBMS (come memorizzare i vertici e i bordi in tabelle diverse che possono comportare un numero maggiore di ricerche per un singolo recupero di regole, ecc.) E questo è critico perché è chiaro che durante le normali operazioni del BRMS i lookup dei dati avvengono molto più spesso, rispetto ad altre operazioni come inserti, aggiornamenti o cancellazioni.

Solo come promemoria – ogni vertice della business rule rappresenta un comando atomico. È salvato nella tabella RDBMS come un record con attributi come il tipo di comando, la descrizione e altri dati supplementari. In un albero ogni vertice ha un solo genitore (tranne il vertice radice, che non ha genitori), quindi ogni record dovrebbe contenere un ID del vertice genitore. È anche conveniente avere un’altra tabella che ospita i record delle regole con i dati rilevanti per la regola stessa. Non c’è nessun problema nel memorizzare i costrutti di dati delle regole di business di qualsiasi complessità con questo approccio.

Le operazioni CRUD sono abbastanza semplici. Le modifiche alla regola di business possono richiedere aggiornamenti a una o entrambe le tabelle – regola o comando. Quando si cancellano o inseriscono i comandi è necessario mantenere i riferimenti tra i comandi (questo è essenzialmente cancellare o inserire nodi in un albero).

Uno dei componenti del BRMS, chiamiamolo manager, dovrebbe eseguire le operazioni di database descritte e fornire un’API per le operazioni CRUD sulle regole di business.

L’elaborazione della regola di business

L’elaborazione della regola di business inizia quando accade un particolare evento di business. Può essere qualsiasi cosa – un utente ha fatto il login, un acquisto è stato fatto, una certa quantità di denaro è stata trasferita, ecc. Questo tipo di attività dovrebbe essere tracciata e il BRMS dovrebbe essere informato su di essa tramite qualche trasporto. AMQP è molto probabilmente il più adatto per questo tipo di compito.

1. L’intero concetto è costruito su un’architettura a microservizi. Il microservizio consumatore di eventi aziendali ascolta tutti gli eventi aziendali dichiarando una coda e legandola ad uno specifico scambio su un server di scambio RabbitMQ. Quando un’attività di business (che è considerata significativa e viene tracciata) accade nel sistema software principale, il messaggio viene inviato al server di scambio RabbitMQ. Esso contiene informazioni su ciò che è successo e alcuni dati supplementari rilevanti. L’evento aziendale può essere identificato con un attributo di qualsiasi tipo passato nel messaggio o usato come chiave di routing, per esempio, una stringa purchase.completed. Il messaggio viene quindi consumato dal microservizio consumatore di eventi di business BRMS.

2. Quando il microservizio consumatore di eventi di business riceve il messaggio dal sistema software principale, allora interroga il microservizio manager se ci sono delle regole di business nel database che hanno il trigger di regole appropriate per l’evento di attività di business. E se c’è una regola di business corrispondente, il microservizio del gestore restituisce i dati del comando iniziale al microservizio del consumatore dell’evento di business. Questo recupero di dati dal manager avviene tramite gRPC ed è visualizzato con una linea tratteggiata.

3. Subito dopo che il microservizio manager risponde con i dati del comando iniziale, il microservizio consumatore di eventi aziendali è pronto per inizializzare l’elaborazione della regola aziendale. Il consumatore di eventi aziendali forma un altro messaggio che incapsula i dati del comando iniziale (ricevuti dal microservizio gestore), e i dati dell’evento aziendale, ricevuti dal sistema software principale. Lo invia tramite AMQP a uno scambio BRMS interno. La chiave di routing del messaggio corrisponde al tipo di comando.

4. Il microservizio di elaborazione iniziale del comando consuma il messaggio (ascolta la coda dove sono impilati i messaggi con chiave di routing initial). Poi fa la sua logica (in un caso base il blocco iniziale non ospita alcuna logica) e interroga il manager se ci sono comandi successivi nella business rule (sono i comandi con parent_id uguale al id del comando che viene attualmente elaborato). E se è così, riceve i dati del comando successivo e invia sia i dati dell’evento aziendale che i dati del comando successivo al server RabbitMQ interno. Sì, ora sembra un linked list traversal, e quando la regola ha dei rami è un tree traversal! Questo è il modo in cui la regola di business viene elaborata comando per comando. Un’altra cosa importante qui – in questo contesto, i dati dell’evento aziendale vengono passati ad ogni comando figlio. È un contesto dell’esecuzione unica della regola di business. Può essere usato più tardi nel processore del comando di analisi dei dati e nel processore del comando di azione.

Per scopi illustrativi assumiamo che la regola di esempio abbia una struttura come questa: comando iniziale -> comando condizionale di analisi dei dati -> comando di azione aziendale. Quindi il comando successivo a quello iniziale è il comando di analisi dei dati.

5. Il processore dei comandi di analisi consuma il messaggio con la chiave di routing analysis dallo scambio interno. In base alla valutazione delle condizioni, che sono descritte nel comando di analisi della regola di business e usando i dati dell’evento di business, il flusso di esecuzione della regola può continuare o fermarsi qui. Se si ferma – non vengono eseguiti ulteriori comandi della regola di business. Se il flusso di esecuzione continua, il processore del comando di analisi interroga il manager per i prossimi comandi della regola di business, li recupera, e pubblica un altro messaggio al server di scambio interno.

6. Infine, c’è un messaggio nello scambio interno, che è pronto per essere consumato dal processore del comando di azione. Se il flusso di esecuzione della regola di business è arrivato fino a questo comando, significa che in questo ramo della regola ogni condizione che era presente nel comando di analisi dei dati era vera e il flusso di esecuzione non è stato interrotto. Il processore del comando d’azione esegue l’azione, per esempio invia un’e-mail.

Questo tipo di attraversamento del grafico è profondo, e quando si incontra un comando con 2 o più comandi figli, l’attraversamento profondo simultaneo inizia per ogni ramo a causa della natura asincrona dell’elaborazione delle regole di business nel sistema descritto.

Scaling

L’approccio descritto permette non solo una grande separazione delle preoccupazioni, ma anche di risparmiare molto denaro quando si tratta di pagare le bollette IaaS. Gli utenti finali creano una varietà di regole di business con diversi numeri di comandi di diverso tipo e diversi numeri di rami. Ma gli scenari di scaling comuni sono i seguenti:
1. Il numero di eventi di business aumenta – il consumatore di eventi di business aumenta.
2. Il numero di regole di business associate (innescate) dagli eventi di business aumenta – il processore di comando iniziale aumenta insieme al manager.
3. Ci sono molti comandi di analisi nelle regole di business – il processore di comando di analisi aumenta
4. Troppi comandi di azione devono essere eseguiti – il processore di comando di azione aumenta.

Reliability

Il vaso sanguigno del sistema è il trasporto. Affinché il sistema rimanga operativo sotto un carico elevato, lo scambio interno di messaggi deve essere altamente affidabile. RabbitMQ fornisce il clustering e soddisfa bene i requisiti di affidabilità (https://www.rabbitmq.com/clustering.html).

Altri tipi di comando

Qualsiasi altra logica di business può essere introdotta nel sistema. Uno dei tipi di comando popolari e richiesti è un comando di attesa a tempo (ad es. “Aspetta 45 minuti, poi continua”). Con l’introduzione del comando time-wait, l’elaborazione della regola di business non è più un’elaborazione in tempo reale poiché può essere sospesa per qualche tempo. Tali cambiamenti richiedono ulteriori processori di comando e alcune modifiche alle strutture dati che non rientrano nello scopo di questo testo. Pasticciare con il tempo può essere difficile e scrivere un servizio che gestisce gli orari e il tempo può essere impegnativo, ecco un esempio di uno buono: https://github.com/nextiva/krolib

Alternative di terze parti

Ci sono alternative ben note di motori di regole/motori di workflow, eccone le 3 migliori (IMHO):
1. Comunda – è un prodotto maturo con versioni community ed enterprise, che potresti voler usare. Ovviamente, la versione enterprise è a pagamento.
2. Luigi – è uno strumento di motore di flusso di lavoro sviluppato da Spotify per le loro esigenze interne, ma già utilizzato da decine di altre aziende.
3. Apache Airflow – questo è un altro prodotto ben noto che ha dimostrato di essere capace, conveniente e personalizzabile.

Quello che unisce questi strumenti, è che tutti usano grafici aciclici diretti come struttura di dati che rappresenta le regole di business o flussi di lavoro. Non è una sorpresa.

Ci possono essere altri prodotti degni di attenzione, ma qualsiasi indagine dovrebbe iniziare con questi tre.

Conclusione

Costruire il proprio motore di regole aziendali può essere impegnativo, ma è gratificante. Non solo si ottiene un sistema in-house, ma è anche costruito secondo i requisiti specifici del vostro business. Un buon team DevOps è un must quando si tratta di mantenere l’affidabilità, la scalabilità e il monitoraggio. Dopo tutto, si ottiene un prodotto fantastico di cui si può essere orgogliosi.