Workflow Tracking Service
Articolo da me pubblicato su Week.it del 18 settembre 2007.
Il motore di Windows Workflow Foundation espone nativamente un servizio per tenere traccia delle operazioni effettuate all’interno di instance di workflow. È un ottimo strumento per monitorare in tempo reale oppure a posteriori lo svolgimento delle operazioni delle varie activity eseguite all’interno dei vari workflow.
Il servizio non é abilitato per default e necessita delle creazione della struttura e logica (stored procedure) su un database Sql Server: operazione che si effettua manualmente tramite il lancio di due file .sql facilmente rintracciabili nella directory Windows Sdk.
Una volta creata la struttura è sufficiente fornire la connection string verso il database creato al servizio di tracking e aggiungere il servizio stesso al runtime di workflow interessato.
È possibile utilizzare lo stesso database per diverse tipologie di workflow e condividere la struttura a più workflow runtime. Il servizio, per default, lavora nella stessa transazione utilizzata dal persistence service: questo implica che le informazioni di tracking verranno salvate nel database solo durante i persistence point e quindi non siano visibili fino a che il workflow non viene persistito. Il motivo è semplice: mantenere allineate le informazioni di tracking con lo stato del workflow. È possibile modificare questo comportamento tramite un semplice flag che indica al servizio di tracking d’inserire le informazioni appena disponibili. Valutare con cura la scelta su questo comportamento.
Se il database di tracking è lo stesso del database utilizzato per la persistenza é consigliabile utilizzare anche il servizio (da aggiungere sempre ai runtime) SharedConnectionWorkflowCommitWorkBatch che consente di riutilizzare lo stesso oggetto connection per persistenza e tracking evitando l’utilizzo di due connessioni che implicano una transazione distribuita e quindi l’uso di Distributed Transaction Coordinator (Ms Dtc).
Il secondo consiglio riguarda le informazioni da tracciare: per default si tracciano tutti gli stati di tutte le attività presenti nel workflow (e del workflow stesso visto che in ultima battuta è a sua volta una activity).
Potrebbe quindi venir tracciata una grossa mole di dati, spesso non interessante ai fini di monitoraggio. Conviene creare quindi un profilo di tracking che indichi solamente quali stati tracciare in modo da ridurre al minimo indispensabile le informazioni da memorizzare. Il servizio espone anche la possibilità di partizionare i dati su base temporale, spostando in automatico o manualmente tramite lancio di stored procedure (da schedulare ovviamente), i dati in tabelle storiche.