Ci stiamo evidentemente facendo una gran bella esperienza nella gestione di motori di regole.  Grazie a questo progetto ci siamo dovuti occupare sia della realizzazione delle regole sia della implementazione di un sistema che permettesse di generare configuratori di prodotto facili da usare.

Un motore di regole è “tecnicamente” un bel giocattolo. Vederlo funzionare su migliaia di condizioni in un batti baleno fa impressione a noi informatici. E anche divertisi a scrivere regole esoteriche è bel gioco.
Inoltre, consente effettivamente di approcciare vecchi problemi in modi completamente nuovi ed, effettivamente, molto efficaci.

Diciamo però che come tutte le “librerie” la messa in produzione di un tale sistema, renderlo fruibile ad una platea di umani non così innamorati dello sviluppo richiede alcune funzioni che il motore di regole di per se non fornisce.

Se poi la platea di utilizzatori del “risultato” del motore di regole si estende, beh, allora siamo nell’ambito di un sistema di produzione fatto e finito .

COSA SI DEVE FARE PER METTERE IN PRODUZIONE UN SISTEMA COME DROOLS?

Il motore di regole utilizzato (Drools) non è altro che una libreria in grado di collegarsi al sistema di regole definito con Guvnor,generare una Working Memory, prendere in pasto una serie di oggetti e “sparare” tutte le regole in base agli oggetti inseriti.

Il risultato è la creazione o rimozione o la modifica degli oggetti.

Gli oggetti devono poi essere riletti e interpretati fuori dalla libreria.

I problemi principali che abbiamo individuato e cercato di superare sono i seguenti

PROBLEMA 1: GESTIONE DELLA COMPLESSITÀ SU MOLTI “MODELLI”

In un ambiente di produzione la complessità dei modelli che ragguppano le regole può variare nel tempo e in particolare il numero di modelli può crescere man mano che si risolvono problemi.

Per questo in un ambiente di produzione risulta molto importante poter definire “dipendenze” tra i modelli.

Di fatto poter riutilizzare modelli preesistenti in modelli più complessi senza impazzire con catalogazioni delle regole e definizioni astruse di priorità.

Il contesto può essere quello che abbiamo sperimentato presso il nostro cliente in cui sono stati definiti modelli per selezionare il prodotto migliore tra molti per il cliente e poi modelli diversi per configurare singoli prodotti.

PROBLEMA 4: MANCANZA DI PERSISTENZA DELLE SESSIONI

Se un utente “remoto” trova  un errore durante l’ utilizzo di una sessione di Drools, è necessario replicare tutte le condizioni di ingresso.  A meno che non ci sia qualche sistema furbo che ha salvato e permette di richiamare la sessione

La persistenza, inoltre consentirebbe di effettuare attività di utilizzo di una sessione del motore di regole anche su tempi lunghi senza rischiare di perdere dati in caso di spegnimento del server

La persistenza consentirebbe poi di creare algoritmi per riduzione della memoria in uso (visto che ogni WorkingMemory su ogni package per ogni utente è, appunto, in memoria).

PROBLEMA 5: MODIFICA DEL COMPORTAMENTO IN BASE A CONDIZIONI AL CONTORNO

In un ambiente di produzione le regole non sono scatole nere avulse dal resto dei sistemi. Al contrario devono modificarsi nel tempo, magari in base a condizioni esterne quali dati presenti in un database. E questo deve essere fatto senza dovere riscrivere le regole.

ECCO COSA ABBIAMO FATTO PER SUPERARE I LIMITI

Abbiamo sviluppato un intero sistema software in grado di “embeddare” Drools e filtrarne l’utilizzo per semplificarlo.

PRIMO COMPONENTE : SISTEMA DI CONFIGURAZIONE DEI MODELLI

Un sistema centrale che gestisca un Repository di modelli. Ogni Repository contiene un riferimento ad un package in Guvnor e consente di definire ambienti di test o di produzione.

SECONDO COMPONENTE : LIBRERIE “ESTERNE” PER CHIAMATE INTRA-MODELLO

Una libreria istanziabile in Guvnor che pilota il motore di esecuzione così che si possano scrivere regole che chiamano altri package. Un modello che scelga tra i prodotti può poi generare in autonomia una sessione su un altro modello (configurazione del singolo prodotto) e ricevere degli output.

TERZO COMPONENTE: LAYER REST

Il core del sistema dialoga con l’esterno mediante chiamate rest supportate da RESTX. Un qualunque sistema terzo può, generare sessioni, riciamarle,  inserire oggetti in drools e leggere i risultati, eseguire i report del sitema etc.

QUARTO COMPONENTE: SISTEMA AVANZATO DI DEBUG

Un’ intera suite di debug web che mostra l’esecuzione di ogni sessione come è andata, che regole ha sparato e che errori ha avuto.
Questa funzione è particolarmente necessaria quando la gerarchia dei modelli diventa complessa.

Qui di seguito le immagini mostrano cosa si legge nel debug in relazione all’inserimento di variabili nel sistema (scelta di opzioni da parte dell’utente nella applicazione web)

Argomento del post è la gestione “UMANA” del motore di regole, ovvero come rendere usabile un sistema come questo in contesti in cui ci sia un essere umano che deve interagire. Questà è stata la nostra stella polare per cui abbiamo deciso che un sistema di regole così fatto dovesse ragionare sul concetto di domanda e risposta: io ti chiedo una cosa, tu mi rispondi, in base alla tua risposta io calcolo altre domande.

Questo consente di rappresentare la interazione Uomo<->Motore di regole ma anche una relazione qualsiasi del tipo Sistema informatico e no<-> Motore di regole. (si veda qui )

Questa metafora è fondamentale perchè di fatto CONSENTE DI RAPPRESENTARE IL COMPORTAMENTO DEL SISTEMA SU UN GRAFO LEGGIBILE. Grafo che può essere calcolato dal sistema e mostrato all’utente per verificare che TUTTE le combinazioni di opzioni siano corrette.

Per calcolare il grafo il sistema deve percorrere tutte le combinazioni possibili di domande – risposte e poi normalizzare il tutto.

Un grafo medio può arrivare a decine di migliaia di nodi da percorrere in fase di test: un tempo disumano di debug che può essere invece fatto dal sistema. I tempi di calcolo sono comunque molto lunghi ma …