6. Integrazione di RemoteCCK
con sistemi di Document
Workflow
Nel capitolo precedente sono stati descritti i dettagli del modulo RemoteCCK e di come questo può essere utilizzato all’interno del CMS Drupal.
Inoltre sono stati presentati diversi esempi, che dimostrano il funzionamento all’atto di creazione di un nuovo contenuto che sarà successivamente pubblicato sul sito principale.
Come spiegato nel secondo capitolo, le potenzialità di Drupal vanno ben oltre la semplice pubblicazione di contenuti, infatti il CMS è sufficientemente potente da permettere di avere una gestione più fine dei contenuti.
In particolare è possibile implementare su Drupal sistemi di gestione di document workflow.
Ovviamente esistono diversi casi che rendono appetibile l’utilizzo di RemoteCCK all’interno di un sistema di questo genere.
Occorre quindi pensare se l’integrazione di RemoteCCK con un generico sistema di document workflow sviluppato su Drupal sia macchinoso o meno.
Per rispondere adeguatamente a questa domanda occorre fare una doverosa precisazione, RemoteCCK basa il suo funzionamento sul modulo CCK che permette la creazione e la gestione di content type generati.
Le funzionalità offerte dal modulo CCK lo rendono molto utile anche per lo sviluppo di un sistema di document workflow basato su Drupal.
In particolare un generico modulo di document workflow dovrà offrire la possibilità di far visualizzare il documento in modo diverso a seconda dell’utente.
Infatti un determinato campo potrebbe essere editato da un utente, solo visualizzato da un altro e nascosto per un’ulteriore tipologia.
Queste operazioni possono essere gestite dal modulo CCK e quindi, se si assume che il contenuto informativo del modulo di document workflow sia gestito tramite CCK, allora l’integrazione con il RemoteCCK è a costo zero.
Infatti, durante l’iter del documento tra i diversi utenti, le funzioni offerte da RemoteCCK saranno sempre riutilizzabili all’interno del routing del documento stesso.
Inoltre sarà possibile scegliere tra le modalità di richiesta before, during o after in accordo con la logica di visibilità dei campi del documento.
Di seguito verrà introdotto un esempio pratico di document workflow utilizzato all’interno del Consiglio Nazionale Ricerca (CNR) di Pisa.
Successivamente verrà specificato come RemoteCCK possa essere integrato con due diversi moduli, ancora in fase di sviluppo, di document workflow chiamati SMAIL e DruFlow.
6.1 Caso d'uso: ordine di missione
Nelle prove di integrazione effettuate è stato usato come esempio d’uso la richiesta d’ordine di missione dell’istituto CNR IIT (Istituto d’Informatica e Telematica).
Il workflow, che permette ad un impiegato di iniziare una richiesta d’ordine di missione, descrive i passi che la domanda dovrà eseguire prima di poter essere approvata o rifiutata.
Ovviamente gli attori di questo workflow sono molteplici, infatti l’impiegato inizialmente dovrà inviare la domanda all’amministrazione ed al manager, se entrambi l’approvano, questa passa al direttore che provvederà, tramite l’ufficio di risorse umane, a notifica all’impiegato l’accettazione o il rifiuto della domanda stessa.
Da notare che se l’amministrazione o manager rifiutano la domanda, questa non passa al direttore e verrà subito notificato all’impiegato il rifiuto della sua domanda.
Gli attori di questo workflow sono i seguenti:
2. amministrazione: che riceve il documento dall’impiegato e da una prima approvazione, passandolo al direttore, o rifiuto rispedendolo all’impiegato
3. manager: che riceve il documento dall’impiegato e da una prima approvazione, passandolo al direttore, o rifiuto rispedendolo all’impiegato
4. direttore: che riceve l’approvazione da parte dell’amministrazione che dal manager e manda alle risorse umane l’approvazione o rifiuto finale
5. risorse umane: che si occupa di notificare all’impiegato se la sua domanda è stata accettata o rifiutata
E’ possibile associare il seguente un grafo per avere una rappresentazione visiva dei passi che il documento dovrà eseguire, questo è il seguente:
Figura 61: Grafo dell'ordine di missione
Si consideri come form di immissione dati una modifica di quello presentato nel quarto capitolo (vedi figura 15) che sarà il seguente.
Questo caso d’uso risulta molto completo infatti permette la sua esecuzione rende necessario l’introduzione dei seguenti concetti:
gruppi di utenti
valutazione di condizioni (passo 4 del workflow sopra)
concetto di creatore di documento (in modo che il messaggio finale ritorni all’utente creatore)
permettere la visualizzazione e l’editazione di campi del content type a seconda dell’utente
Ovviamente un modulo Drupal che riesca ad implementare tutti i punti sopra descritti non è di semplice realizzazione.
Per questo negli esempi di uso successivi, qualora non sia possibile, verrà usato un modello di ordine di missione più semplice formato semplicemente dallo scambio di informazione tra un utente ed il proprio referente.
6.2 SMAIL
SMAIL (Smart MAIL) è un modulo prototipale che utilizza il concetto di gruppo di utenti proprio di Drupal per il routing di messaggi tra utenti diversi del CMS.
Esso è stato sviluppato internamente all’istituto IIT del CNR di Pisa partendo dall’osservazione che il routing di documenti può avviene anche tramite l’utilizzo di messaggi diretti a singole persone od a gruppi di persone.
SMAIL permette infatti di mandare messaggi non solo ad utenti singoli, ma anche a gruppi di utenti, dove i messaggi, che vengono scambiati dagli utenti, sono dei content type creati opportunamente.
Si consideri inoltre la presenza di un web service che ha in ingresso un numero di matricola e restituisce i dati anagrafici riguardanti il dipendente.
Se un dipendente inizia un documento di ordine di missione, la schermata di immissione potrebbe essere la seguente:
Figura 62: Creazione di ordine di missione
Nella figura sopra sia il dipendente manda una richiesta di ordine di missione al proprio referente e amministratore.I dati che inserisce sono semplicemente la propria matricola, la destinazione ed il costo preventivato.All’invio del messaggio da parte del dipendente corrisponde la ricezione dello stesso da parte del referente, come indicato nella seguente schermata:
Il messaggio una volta spedito sarà ricevuto dall’utente destinatario.
Si consideri la ricezione del messaggio da parte del referente:
Figura 64: Messaggio ricevuto
Ovviamente il numero di matricola identifica univocamente il dipendente, ma chiaramente il referente, nel caso voglia sapere i dati del dipendente, dovrà effettuare una ricerca basandosi sul numero di matricola.
Quest’operazione può essere automatizzata proprio grazie all’utilizzo di RemoteCCK.
Infatti è sufficiente inserire nel content type missione l’operazione di anagrafica, cosi come visto nel capitolo precedente, inoltre occorre settare modalità di richiesta la “Before Submit”.
Infatti come spiegato nel precedente capitolo, l’invocazione dell’operazione avviene all’apertura del messaggio spedito.
Ovviamente la visualizzazione dei campi è a carico del modulo SMAIL e quindi è possibile definire che i dati anagrafica saranno visualizzati a tutti, fuorché al creatore dell’ordine di missione.
La schermata visualizzata dal referente è la seguente:
Figura 65: Messaggio ricevuto con l'aggiunta delle informazioni esterne
6.3 DruFlow
DruFlow (35) e (36) è un motore di document workflow basato su Drupal che implementa i seguenti concetti:
gruppi di utenti
valutazione di condizioni (passo 4 del workflow sopra)
concetto di creatore di documento (in modo che il messaggio finale ritorni all’utente creatore)
Il sistema si basa su un linguaggio di descrizione chiamato SDWDL (Structured Document Workflow Description Language) che permette di descrivere il routing del documento.
Nell’esempio riportato verranno utilizzati due agenti, uno dipendente ed uno referente, mentre il primo crea l’ordine di missione il secondo lo visualizza (versione semplificata rispetto a quello originale).
La descrizione SDWDL del document workflow è la seguente:
SET WF_NAME ="missione" SET WF_TYPE ="missione" SET INITIATOR ="agente1" SET WF_ORGCHART ="prova.xml" SET WF_DOC ="missione.xml"
BEGIN AGENT "agente1" MAP //group[@name='gruppo1']//user setPermission ("/missione/response/nom10" , hidden ) setPermission ("/missione/response/cognom10" , hidden ) setPermission ("/missione/response/comunenascit10" , hidden ) setPermission ("/missione/response/datanascit10" , hidden ) setPermission ("/missione/response/sess10" , hidden ) SHOW()
send ("agente2") END AGENT
BEGIN AGENT "agente2" MAP //group[@name=' gruppo1']//user[@id=referente@gruppo1'] receiveany ("agente1")
SHOW()
END WORKFLOW END AGENT
Dopo aver installato il workflow all’interno del sistema, un qualunque utente appartenente al “gruppo1” può iniziare un ordine di missione.
Ipotizzando di avere un dipendete, che faccia parte del “gruppo1”, che inizi un ordine di missione, la form che lui visualizza sarebbe la seguente:
Figura 66: Ordine di missione tramite DruFlow
I campi visualizzati sono i medesimi, dell’esempio utilizzato nel paragrafo precedente, riguardante l’integrazione di RemoteCCK con SMAIL.
In seguito alla pressione di “Save”, verrà notificata un nuovo messaggio all’interno del “Workload” del referente:
Questa schermata del referente indica la ricezione di un nuovo messaggio:
