WorkFlow Engine

Il motore dell' WorkFlow, come abbiamo già detto, opera in background: non ci sono interazioni con l' utente. Solitamente lo si attiva ad intervalli regolari di tempo compatibili con le emissioni delle RDA: una volta al gg, una volta ogni 1/2gg o ...

Con la BBT il motore viene assimilato ad una Decision Rule più o meno complessa in funzione delle logiche di approvazione: la DR diventa anche lo schema che documenta l' operatività del motore stesso.

Vediamo come possiamo costruire questo schema passo a passo, mantenendo l' attuale modello: di fatto costruiamo x passi il prototipo che poi diventerà l' applicazione effettiva.

Passo-1 impalcatura delle DR

 

 

(1)-Attivazione del metodo DefineGridRDAstatusNEWorWF (richiama la BBP_FillGridFromSqlTable): popola la grid WF_Rda riportando tutte le RDA che si trovano nello stato NEWWF. Gli altri stati sono propri di RDA eliminate o approvate o rifiutate e, quindi, non di interesse per il motore;
(2)-Nell' ipotesi in cui il metodo vada in errore, questo ramo si occupa di segnalare l' errore che si è verificato;
(3)-Attiva un loop di lettura delle RDA: il metodo BBP_ReadRowNumberFromGrid (richiama la BBP_ReadRowNumberFromGrid) legge ed esplode sul dettaglio la riga di cui viene passato l' indice. Se StatusOfCall (valore inizializzato dal metodo) è true significa che ci sono ancora righe da leggere, se è false significa l' indice punta oltre il numero di righe leggibili;
 (4)-Per la riga letta, si attiva la regola WFelaboraRDA, regola che vedremo nello step successivo. Il metodo BBP_IncrementValue (richiama la BBP_IncrementValue) in crementa il valore dell' indice di lettura: a seguire, abbiamo un GoTo alla label Continue il cui effetto è quello di prendere in esame la prossima riga;
 (5)-Terminata la lettura delle Rda, si segnala all' utente la fine dei lavori;

 

Passo-2 vediamo come viene costruita la DR WFelaboraRDA

 

DR: WFelaboraRDA 

 

Lo Stato della Rda che la regola prende in carico, può essere solo NEWWF: se NEW significa che la Rda è stata creata e mai elaborata dall' WF Engine, mentre se WF è già stata presa in carico dal WF Engine.

Nel caso NEW se il max livello di approvazione è Liv-0 (di fatto non c' è necessità di approvazione) allora si passa alla fase di approvazione della Rda lanciando la regola WFapprovaRDA: in caso contrario si procede alla richiesta del prossimo livello di approvazione previsto. Viene lanciata la regola WFrichiediApprovazione.

Nel caso WF se il livello di approvazione raggiunto dalla Rda è uguale a quello max richiesto, allora si passa alla fase di approvazione della Rda lanciando la regola WFapprovaRDA altrimenti si deve richiedere il prossimo livello di approvazione previsto. Viene lanciata la regola WFrichiediApprovazione.

 

DR WFapprovaRDA

Il compito della DR è quello di approvare la Rda ed eventualmente inviare una mail all' Amministrazione affinchè possa procedere con l' Ordine al Fornitore.

L' approvazione di fatto si traduce in un cambio di Stato che significa assegnare il nuovo valore al campo stesso ed attivare l' aggiornamento della Rda che si sta elaborando: per realizzare questa azione si utilizza il metodo BBP_UpdateRowInGridAndInSql.

Per quanto riguarda la Mail, utilizzeremo il metodo BBP_SendMailMessageFromServer per cui dobbiamo prevedere l' inizializzazione di alcuni campi:

subject: identificativo della stringa contenente il soggetto della mail. In questo caso il soggetto è costante per cui possiamo pensare di creare una costante che includa il messaggio: la chiamiamo SubjectApprovazione = "Approvazione RDA";

message: identificativo della stringa contenente il messaggio da inviare. In questo caso possiamo inviare come messaggio l' identificativo della Rda: il messaggio viene pertanto costruito ad hoc per ogni Rda. Per fare questo usiamo la costante TemplateMessaggioApprovazione = "Identificativo RDA approvata: {Identificativo}" ed il metodo SubstituteUsingBlackBox che costruisce il messaggio stesso;

emailTo: lista dei destinatari della mail. Ogni destinatario è separato da ';'. In questo caso possiamo ipotizzare come unico destinatario della Mail l' Amministrazione per cui anche qui utilizziamo la costante EmailToAmministrazione = "amministrazione@azienda.it";

Di seguito la regola in oggetto:

 

 

WFrichiediApprovazione

Questa di massima l' attività che la DR deve svolgere:

(1)-Se lo Stato della Rda è NEW, deve settare lo StatoWF che indica la presa in carico da parte del WF Engine della Rda;
(2)-Deve valorizzare il campo LivAppProssimo al prossimo livello di approvazione;
(3)-Deve avvertire l' approvatore (o gli approvatori) deputati ad avallare il nuovo livello di approvazione della Rda: ovviamenti quest' ultimo potrebbe anche rifiutare la richiesta;

 

Di seguito la regola in oggetto:

 

 

Per l' invio delle mail ci si è affidati ad una regola:

 

 

Sono stati utilizzati più metodi che usano la stessa procedura BBP standard BBP_SendMailMessageFromServer: ogni metodo è specializzato per una tipologia di invio.

Le mail vengono inviate agli approvatori per informarli che sono disponibili Rda per l' approvazione: nella mail sarà riportato anche il ink all' applicazione usata dagli approvatori per approvare le Rda. Questa applicazione può ovviamente essere utilizzata anche su smartphone.

 

Passo-3 vediamo come testare  l' engine dell' Work Flow

Dobbiamo creare una pagina che ci consenta di visualizzare le Rda inserite, in modo da verificarne l' avanzamento, e che ci consenta di attivare il motore o DR relativa in modo da verificare il funzionamento del motore stesso.

Il filmato che segue mostra la fase di test dell' engine WF: