sistemi informativi WORKFLOW, Schemi e mappe concettuali di Sistemi Informativi

Scarica sistemi informativi WORKFLOW e più Schemi e mappe concettuali in PDF di Sistemi Informativi solo su Docsity! Sistemi Informativi Appunti Capitolo 5: I Workflow e WfMS 1. Che cosa si intende per workflow? Il concetto di workflow Un workflow è una sequenza di operazioni interconnesse tra loro, dichiarate come compiti assegnati a persone singole oppure a gruppi di persone all'intemo di una stessa organizzazione, finalizzate all'esecuzione di un certo processo. Un workflow è quindi l'automazione (totale o parziale) di un processo di business nel quale i documenti, le informazioni o i compiti sono passati da un partecipante ad un altro per svolgere attività, secondo un insieme di regole procedurali Molte singole istanze di processo possono essere operative durante l'enactment (messa in atto) di un processo (0 “caso” 0 “workflow case”). Utilizzare la tecnologia dei workflow significa quindi automatizzare i processi che coinvolgono una combinazione di attività umane ed automatiche, in particolare con il coinvolgimento di applicazioni e strumenti IT. Come definire un processo Dal concetto di workflow, risulta chiaro che la tecnologia del workflow richiede la definizione rigorosa dei processi di business. Vediamo allora come si può definire un processo. Per farlo, occorre individuare: 1. Larete di attività che lo costituiscono. 2. Quali sono i criteri per iniziare e per terminare il processo stesso. 3. Quali sono le informazioni sulle singole attività. 4. Chi sono i partecipanti al processo, dove il termine partecipante si può riferire sia ad una risorsa umana (cioè una persona fisica o un gruppo di persone), sia ad un'applicazione software. Quali sono i documenti e i dati legati alle attività del processo. In genere però non vengono rappresentati nello schema dei flussi di dati. Una volta individuati tutti questi elementi, bisogna definire il processo anche in una maniera formale, rappresentandolo in una forma che ne consenta la manipolazione automatica, per la modellazione e per la sua messa in atto. I costrutti di base che si utilizzano per la definizione della rete di attività sono: a) La sequenza (cioè due attività vengono eseguite l'una dopo l’altra). b) Il parallelo (due attività in parallelo sono 2 attività che vengono eseguite contemporaneamente). c) L'alternativa (due attività sono in alternativa se ne viene eseguita solo una, sulla base di opportune condizioni, che possono essere di vario tipo). Possiamo quindi dire che il processo di business è “ciò che si vuole che accada”, mentre la definizione del processo di business è la rappresentazione di ciò che si vuole che accada. All'interno di questa rappresentazione, potremo avere le definizioni di sottoprocessi. Inoltre, ogni processo è costituito da un insieme di attività, che possono essere manuali (e quindi non gestite da alcun sistema automatizzato) oppure automatizzate. Istanza di processo (o casi, o workflow case) In maniera informale, un'istanza di processo è una rappresentazione di ciò che sta realmente accadendo, e rispetta quanto è stato dettato dalle definizione del processo al quale corrisponde. Ogni volta che viene avviata l'esecuzione di un processo, si avvia quindi una nuova istanza di quel processo. In generale, è possibile che siano attive allo stesso tempo diverse istanze di processo, operanti su dati e/o caratterizzate da partecipanti diversi. Un'istanza di processo comprende una o più istanze di attività, ciascuna delle quali può comprendere uno o più: a) Elementi di lavoro (work items) Un elemento di lavoro è un task allocato ad uno specifico partecipante. b) Applicazioni invocate Le applicazioni invocate sono gli strumenti e le applicazioni informatiche di supporto. pag.i7 Sistemi Informativi Appunti 2. Stati di processi e attività Gli stati di un'istanza di processo In maniera molto simile a quanto accade per i processi informatici, i processi di business possono trovarsi in diversi stati. Il seguente diagramma mette in evidenza le transizioni da uno stato all’altro. Inizialmente, il processo si trova in stato “initiated”, cioè è pronto ad essere eseguito, ma la sua esecuzione non è ancora stata avviato. Dopo l'operazione di start, si passa allo stato “running”: il processo è quindi in esecuzione. Quando poi si hanno in esecuzione una o più istanze di attività, il processo passa allo stato “active”. Dallo stato active, si può tomare allo stato running, quando termina l'attività in esecuzione (0 terminano le attività in esecuzione) e ancora non è stata avviata la successiva. Il processo può poi essere terminato (tipicamente per un errore), e in tal caso si passa dallo stato active o running allo stasto terminated. Quando invece si è tornati allo stato running perché è terminata l'ultima attività del processo, allora si passerà allo stato “complete”(il processo cioè è terminato con successo). Dallo stato running è anche possibile passare allo stato “suspended”: il processo viene cioè sospeso per un certo intervallo di tempo, al termine del quale vine riavviato da capo (tramite restart), oppure si ritorna allo stato running. Infine, dallo stato running si può tornare allo stato initiated se si riavvia dall'inizio il processo in esecuzione. Transizioni di stato di un'attività Il seguente diagramma inoltre rappresenta in maniera intuitiva quali sono le transizioni di stato che si possono avere per una singola attività di un processo: Suspend fResume Start — % (iacive 2 (Aci) (Complete) L'attività è in stato “active” se ha almeno una istanza di lavore, ovvero qualcuno la sta realmente eseguendo. pag. 38 Sistemi Informativi Appunti 5. Modello di riferimento per la struttura di un WfMS Introduzione Vogliamo ora introdurre il scorkflcw reference model, ovvero il modello di riferimento per l'architettura dei sistemi di workflow. Tale modello è rappresentato nella figura seguente: tntersce } raRioW APT i Inirchange male] lnterfsce A #ori:flove Enaci Obe Wake Workflow: Enaetment Service E e inets) | taterface 2 } $ Imertice Wario Toeched Applications Come mostrato dalla figura, il WWÉMIS possiede al suo interno un certo numero di componenti che interagiscono tra loro in maniera predefinita. Al fine di consentire l'interoperabilità tra tali componenti, sono state definite delle interfacce standardizzate per lo scambio di dati tra i componenti stessi. Workflow Enactment Service (WES) . Cos'è un WES? Il Workflow Enaciment Service è quella parte del WEVIS che fornisce l'ambiente per l'esecuzione delle singole istanze dei processi. Possiamo quindi dire che il WES è un servizio software finalizzato alla creazione, gestione ed esecuzione di istanze di processo. Un WES è costituito da uno o più workflow engine. Workflow engine Un workflow engine è un'applicazione software che si occupa di interpretare, gestire ed eseguire una parte di un processo di business (o, al limite, l'intero processo di business). In particolare, l'engine determina quali sono le attività da mandare in esecuzione. Per fare ciò, esso deve interpretare gli eventi che si verificano (ad esempio, l'invio di documenti ad un server), e compiere delle azioni di risposta a tali eventi, in accordo ai processi definiti. Le azioni possono essere di ogni tipo (ad esempio, il salvataggio del documento în un apposito sistema, l'assegnazione di nuove attività mediante l'invio di e-mail agli utenti, ...). Tipicamente, un workflow engine fornisce i servizi per: 1. Interpretare la definizione del processo; 2. Controllare le istanze di processo (ovvero gestire la creazione, l'attivazione, la sospensione, la terminazione, ... cioè i vari passaggi da uno stato ad un altro). 3. Navigare tra la varie attività di processo, che potrebbero coinvolgere operazioni da svolgersi in maniera sequenziale o in parallelo. 4. Consentire l'ingresso e l'uscita di specifici partecipanti. 3. Identificare le attività da sottoporre all'attenzione degli utenti e mettere a disposizione un'interfaccia per supportare l'interazione con gli utenti. 6. Mantenere i dati di controllo e i dati salienti relativi al workflow, mediante lo scambio di tali dati con applicazioni o utenti. 7. Mettere a disposizione un'interfaccia per invocare applicazioni esterne e collegare tutti i dati rilevanti sul workflow. 8. Eseguire azioni di supervisione, per fini di controllo, amministrazione e verifica. pag.dl Sistemi Informativi . Appunti Osservazione Nonostante il workflow enactment service sia stato descritto come un'entità logica singola, in realtà esso può essere un sistema centralizzato, oppure un sistema distribuito. In questo secondo caso, diversi workflow engine controlleranno ciascuno una diversa parte della messa in atto del processo e interagiranno con quel sottoinsieme di utenti e applicazioni che sono legati alle attività di quella “fetta di processo” di cui sono responsabili. I sistemi di workflow distribuiti fanno uso di specifici protocolli e formati di scambio dati tra i workflow engine, al fine di sincronizzare le operazioni e scambiare informazioni di controllo del processo e delle attività. Altri componenti Gli altri componenti del WfMS sono: . L'interfaccia WAPI Le applicazioni possono interagire con i servizi offerti dal Workflow Enactment Service per mezzo di un'interfaccia detta Workflow API (0 WAPI). Essa mette quindi a disposizione un modo per invocare i servizi del WES. Process definition tools Contiene: 1. Il process model designer, che è uno strumento software per la definizione dei modelli dei processi. 2. Il process model repository, che è l'archivio dei modelli dei processi registrati nel WfMS. Administration & monitoring tools Si tratta di un'applicazione usata per amministrare il WfMS e per monitorare il funzionamento. Alcune sue tipiche aree funzionali sono la gestione degli utenti a dei ruoli, il controllo delle risorse, la supervisione dei processi, la gestione di operazioni di verifica, ... Workflow Enacument Service A Workflon Engines) Workflow client application (worklist handler) Come abbiamo detto, il workflow engine determina quali sono le attività da mandare in esecuzione e individua quali sono i partecipanti al workflow a doverle svolgere (si occupa di allocare le attività). Esso genera così delle worklist (una worklist è l'elenco di work items, ovvero di compiti, assegnati ad un certo partecipante al workflow). I vari partecipanti (ovvero utenti singoli o gruppi di utenti) devono perciò poter interagire con il workflow engine, al fine di poter ricevere la propria worllist e di mandare all’engine eventuali messaggi di notifica (ad esempio, per segnalare il completamento delle attività ad essi assegnate). L'applicazione che si occupa di svolgere tali operazioni prende il nome di woerklist Randler 0 workflow client application. Il workflow handler è perciò il sistema software responsabile dell'organizzazione del lavoro per conto di un utente. È il worklist handler ad avere la responsabilità di selezionare e far procedere le singole attività dalla worklist La client application interface L'interazione tra il workflow engine e il worklist handler avvien mediante un'opportuna interfaccia, detta client application interface. La invoked application interface È l'interfaccia che permette al workflow engine di attivare direttamente una specifica applicazione per intraprendere una particolare attività (tipicamente si tratta di un'applicazione server, priva di interfaccia con l'utente). pag.d2 Sistemi Informativi Appunti Diverse implementazioni del worklist handler Nel modello a workflow, l'interazione tra il worklist handler ed un particolare workflow engine avviene mediante un'interfaccia ben definita. Nel caso più semplice, la worklist è accessibile al workflow engine affinché quest'ultimo possa assegnare delle attività ai vari utenti, ed è accessibile al worlist handler allo scopo di presentare agli utenti le attività ad essi assegnate, in modo che possano poi eseguirle. Questa interazione può però essere implementata in maniera diversa, a seconda di vari fattori, tra i quali anche il tipo di infrastruttura usata per supportare la distribuzione delle worldist La figura seguente mostra 4 possibili scenari: Workflow Engine Server environment > ui 400 | RPC cul lWorklisr] ele ce La Clignt 1 da E È ‘orklis Worklis ‘arklis Worklisi ess. Ae ca Common API Workflow Worklow Workllew Workflow (Client Appaf || Cliem Appn.] - [Client Appr Client Appa Shared Filestore - Flectronic Mail ode Model 1. Host based model In questo modello, la comunicazione tra il client worklist handler e il workilow engine avviene mediante un'interfaccia che si trova su un terminale o su una workstation remota. L'utente deve quindi inviare a tale interfaccia la richiesta di accesso ai dati. L'interfaccia accede poi alla worklist mediante una chiamata locale. 2. Shared filestore model Il modello shared filestore model prevede che si abbia un archivio condiviso, che si trova sul confine ira la piattaforma client e la piattaforma server ed è accessibile ad entrambe. Il worklist handler è quindi implementato come una funzione client che comunica con tale archivio di dati. 3. Electronic Mail Model La comunicazione avviene per mezzo della posta elettronica, che supporta la distribuzione dei work items (ovvero dei compiti) a singoli partecipante del processo. 4. Procedure call or message passing model La comunicazione avviene mediante un meccanismo di scambio di messaggi (ad esempio, RPC: Remote Procedure Call). In questo scenario, la worklist potrebbe essere fisicamente allocata nel workflow engine o nel worklist handler, a seconda delle specifiche caratteristiche di implementazione. pag di