FACOLTA’ DI INGEGNERIACORSO DI LAUREA TRIENNALE IN
INGEGNERIA INFORMATICA
PROGETTO E SVILUPPO DI UNA APPLICAZIONE PER LA GESTIONE DI MODULISTICA INFORMATIZZATA IN AMBIENTE INTEGRATO SHAREPOINT - INFOPATH
LaureandoDebora Spogliarich
RelatoreChiar.mo Prof. Maurizio Fermeglia
UNIVERSITÀDEGLI STUDI DI TRIESTE
Anno Accademico 2011-2012
Grazie a coloro che ci hanno creduto e pazientemente hanno aspettato
i
INDICE
1. INTRODUZIONE 1
2. ANALISI 3
3. TECNOLOGIE 11 3.1. Microsoft InfoPath 2010 11 3.2. Microsoft SharePoint 2013 13
4. REALIZZAZIONE 15 4.1. Primo prototipo 15 4.2. Secondo prototipo 19
4.2.1 Pubblicazione della form 19
4.2.2. Data Connection 22
4.3. Terzo prototipo 244.3.1. Prima vista: la richiesta 24
4.3.2. Seconda vista: l’approvazione 27
4.3.3. Terza vista: l’archiviazione 29
4.3.4. Workflow di approvazione 30
5. SVILUPPI FUTURI 33
6. CONCLUSIONI 36
ii
INDICE DELLE FIGURE
1. INTRODUZIONE 1
2. ANALISI 3 2.1 Bozza della form di richiesta 5 2.2 Bozza della form di richiesta con informazioni sull’approvazione 6 2.3 Workflow di approvazione 8
3. TECNOLOGIE 11
4. REALIZZAZIONE 15 4.1 Form di richiesta 15 4.2 Dettaglio della form di richiesta - tipologia del bene 16 4.3 Dettaglio della form di richiesta - bene nuovo/in sostituzione 16 4.4 Vista di InfoPath - conferma di invio richiesta 17 4.5 Vista di InfoPath - conferma di invio richiesta 23 4.6 Form di richiesta 25 4.7 Form di approvazione 27 4.8 Sezione a cura della Ripartizione 28 4.9 Sezione da compilare in caso di approvazione 28 4.10 Sezione da compilare in caso di rifiuto 29 4.11 Workflow di approvazione 30 4.12 Messaggio inviato alla Ripartizione 31 4.13 Oggetto del messaggio 31 4.14 Messaggio inviato al Capo Struttura 32 4.15 Form library Hardware Online 32
5. SVILUPPI FUTURI 33
6. CONCLUSIONI 36
Si vuole realizzare una applicazione in ambiente integrato SharePoint – InfoPath per la gestione
delle richieste di dispositivi hardware mediante delle form, che permetta ai tecnici del supporto IT
di valutare le richieste e tenere traccia di alcune informazioni aggiuntive, necessarie alla corretta
inventariazione delle attrezzature distribuite.
Microsoft InfoPath e SharePoint offrono un ambiente completo per la progettazione, la distribuzione,
l’hosting e l’integrazione delle form: utilizzati assieme consentono di implementare dei flussi paper-
less a diversi livelli di complessità, con poca o nessuna attività di programmazione.
L’obiettivo da raggiungere è la creazione di una form browser-based e pubblicazione della stessa
su SharePoint in modo da consentire al richiedente di compilarla online. Si utilizzeranno i workflow
presenti in SharePoint per automatizzare il flusso delle informazioni fra il richiedente ed i tecnici del
supporto IT.
La normativa statale riconosce fin dal 1997 pieno valore giuridico al documento informatico, la
dematerializzazione è stata uno dei temi centrali del Codice dell’Amministrazione Digitale (D.Lgs 7
marzo 2005, n.82) ed attualmente assume un ruolo la cui centralità è resa evidente dal fatto di es-
sere compresa tra gli obiettivi del Piano e-Governament 20121. La dematerializzazione documentale
costituisce una delle possibili azioni da intraprendere per ridurre i costi della spesa pubblica, sia in
termini di costi diretti (carta, spazi, ecc.) che indiretti (tempo, efficienza, ecc.). La gestione cartacea
dei documenti è caratterizzata da eccessiva onerosità dovuta alla difficoltà di archiviazione e condi-
visione, ai tempi di ricerca elevati ed alla facilità nel commettere errori.
Nello svolgere il progetto è stato necessario:
- studiare le tecnologie utilizzate, in particolare SharePoint 2013 ed InfoPath 2010;
- effettuare l’analisi al fine di raccogliere le informazioni necessarie alla progettazione;
- realizzare l’applicazione;
- testare l’applicazione;
- valutare le migliorie da effettuare per la messa in produzione.
Il vincolo del progetto consiste nel realizzare l’applicazione in ambiente Microsoft in quanto l’Univer-
1. INTRODUZIONE
1 DigitPA è l’Ente nazionale per la digitalizzazione della Pubblica Amministrazione, che ha sostituito per D.Lgs. 1 dicembre 2009, n.177 il Centro Nazionale per l’Informatica nella Pubblica Amministrazione (CNIPA).
1
sità degli Studi di Trieste è firmataria di un contratto di leasing denominato Microsoft Enrollment for
Education Solutions. La sottoscrizione dell’accordo permette l’utilizzo su tutti i personal computer di
proprietà dell’Ateneo di alcuni prodotti Microsoft fra cui sono inclusi sia il sistema operativo desktop
che suite di produttività. Fra i benefici è da sottolineare la disponibilità della suite Office che include
InfoPath.
SharePoint è disponibile in DreamSpark Premium, un programma offerto da Microsoft a tutte le
università: a fronte di una quota annuale di adesione gli studenti ed i docenti possono scaricare ed
ottenere la licenza di svariati prodotti. L’unico vincolo è che il software deve venir utilizzato per la
didattica ed è escluso l’utilizzo commerciale.
Per il nostro Ateneo il programma DreamSpark Premium è collegato al contratto Microsoft Enrollment
for Education Solutions ed offre questa opportunità a tutti gli studenti e docenti afferenti alle Facoltà
ed ai Dipartimenti che erogano corsi in “Science, Technology, Engineering e Math”.
Di seguito un breve riassunto dei capitoli in cui è suddiviso questo documento.
Capitolo 2: analisi del progetto preso in esame, delle metodologie attualmente utilizzate per la
gestione delle richieste dei dispositivi hardware e suddivisione dell’obiettivo per passi
successivi.
Capitolo 3: breve cenno alle tecnologie utilizzate.
Capitolo 4: sviluppo dell’applicazione per passi successivi a seconda delle tecnologie utilizzate.
Capitolo 5: valutazione delle migliorie da effettuare per la messa in produzione.
Capitolo 6: conclusioni a cui si è giunti durante lo svolgimento del progetto.
2
2. ANALISI
Sfruttando i prodotti che mi vengono messi a disposizione dall’Ateneo come dipendente e studente,
si è voluto cercare un caso semplice ma esemplificativo di un processo che richieda l’interazione di
più attori, realizzabile attraverso un flusso completamente paperless.
Questo progetto non ha velleità di rappresentare un vero processo di dematerializzazione docu-
mentale ma vuole essere un Proof of Concept allo scopo di dimostrare la fattibilità e la fondatezza
dell’utilizzo di SharePoint ed InfoPath per il raggiungimento dello scopo.
Le richieste di dispositivi hardware per la Direzione Generale (escluso il Centro Servizi di Ateneo per
il Trasferimento delle Conoscenze – CENTRACON) e l’Amministrazione centrale dovrebbero pervenire
alla Ripartizione Supporto utenti e assistenza tecnica2 che si occupa sia dell’acquisizione del mate-
riale informatico che della sua gestione, assegnazione ed installazione.
La Direzione Generale comprende circa 40 persone ed è suddivisa in sette Uffici di staff, ognuno dei
quali ha un Responsabile di unità.
L’Amministrazione centrale comprende circa 350 persone organizzate in cinque Divisioni, suddivise a
loro volta in Sezioni e Ripartizioni.
Essendo la Direzione Generale e l’Amministrazione centrale organizzate in modo gerarchico, la Ri-
partizione ha individuato i Capi Struttura3 come le persone incaricate ad effettuare le richieste per i
propri afferenti.
Nonostante sia stata inviata una circolare a tutti i Capi Struttura, con le indicazioni su come effet-
tuare le richieste per il materiale informatico, il risultato non è stato quello sperato e da qui è nata
l’esigenza di realizzare una applicazione per la gestione delle richieste.
Le richieste attualmente pervengono per la maggior parte tramite email ma non sempre dal Capo
Struttura e tanto meno all’indirizzo email preposto a tale scopo, un problema da non trascurare è che
spesso non sono ben formulate e di conseguenza è necessario contattare il richiedente per capire
2 La Ripartizione Supporto utenti e assistenza tecnica nel seguito verrà indicata più brevemente come la Ripartizione oppure il supporto IT.
3 Capi Struttura nella fattispecie i Responsabili di unità di staff, i Direttori di Divisione, i Capi Sezione ed i Capi Ripartizione.
3
qual è l’effettiva necessità.
Realizzando una form browser-based e pubblicandola in una form library di SharePoint si può garan-
tire che:
- saranno raccolte tutte le informazioni necessarie al supporto IT per la gestione della richiesta;
- le richieste verranno compilate esclusivamente dai Capi Struttura;
- tutte le richieste verranno archiviate in un’unica form library.
Nel progettare la form si deve pensare a raccogliere solo i dati strettamente necessari alla gestione
della richiesta. Lo scopo è quello di agevolare i Capi Struttura nella compilazione e di far pervenire le
informazioni utili alla sua gestione alla Ripartizione, in modo che possa valutarne la fattibilità senza
dover contattare nuovamente il richiedente al fine di ottenere le informazioni mancanti od ulteriori
chiarimenti.
I dati di cui abbiamo bisogno sono:
- nome, cognome e struttura di afferenza del richiedente;
- nome e cognome dell’assegnatario del bene;
- la tipologia del bene;
- sapere se si tratta di una nuova assegnazione o sostituzione;
- il motivo della richiesta.
Riguardo alla tipologia del bene, sarebbe utile indicare nella form un elenco di possibili scelte, le
richiese più frequenti sono: cuffie, desktop, laptop, monitor, mouse, scanner, stampante, tastiera e
webcam.
In questo modo è sicuramente più facile catalogare le richieste per tipologia del bene in quanto si
è certi che non verranno utilizzati dei sinonimi per indicare lo stesso bene. Nella form dovrà venir
inserito un campo compilabile, per dare la possibilità al Capo Struttura di scrivere la tipologia del
bene che non è presente nell’elenco, in quanto è difficile prevedere tutte le necessità di materiale
informatico.
E’ importante indicare se il bene rappresenta una nuova richiesta oppure se il bene va in sostituzione
ad uno preesistente, questo aiuterà il supporto IT a valutarne l’effettiva necessità.
4
Nel caso si tratti di una sostituzione è necessario indicare il numero di inventario del bene.
Tutti i beni presenti in Ateneo devono essere censiti dall’ufficio di competenza, al fine di mantenere
aggiornato l’inventario. I beni guasti o con caratteristiche tecniche tali da non poter essere riutilizzati
proficuamente in altre strutture dell’Ateneo devono seguire la procedura di scarico inventariale prima
di venir eliminati, da qui la necessità di tener traccia dei numeri di inventario di tutti i beni gestiti.
Solo negli ultimi anni alcuni beni di uso comune, come ad esempio mouse e tastiere, sono entrati a
far parte dei beni di consumo e quindi non vengono più inventariati.
L’ultima informazione di cui si ha bisogno per valutare la richiesta è la motivazione, non può venir
omessa in quanto è fondamentale alla Ripartizione per decidere se approvare o meno la richiesta.
Date le informazioni necessarie per la gestione della richiesta, una bozza della form potrebbe essere
la seguente:
Figura 2.1: bozza della form di richiesta
UNIVERSITÀDEGLI STUDI DI TRIESTE
5
Dopo aver visionato la richiesta il supporto IT sarà in grado di valutarne la fattibilità, approvandola
oppure respingendola, concludendo così il flusso del processo.
Le informazioni che verranno inserite nella form a cura della Ripartizione variano nel caso la richiesta
venga approvata o respinta:
- se la richiesta viene approvata la motivazione può essere facoltativa ma dovranno venir indicati
la marca, il modello ed il numero di inventario del bene assegnato. Può esser utile prevedere un
campo per le note.
- Se la richiesta viene rifiutata è indispensabile inserire la motivazione.
La bozza della form potrebbe venir modificata con l’aggiunta in calce delle seguenti informazioni:
Figura 2.2: bozza della form di richiesta con informazioni sull’approvazione
L’analisi per quanto riguarda le informazioni da inserire nella form si può dire conclusa, ora prendia-
mo in considerazione la pubblicazione della form nella form library di SharePoint.
Prima di pubblicare la form in SharePoint sarà necessario:
- creare un sito in SharePoint;
- creare una form library all’interno del sito;
- assegnare le autorizzazioni.
UNIVERSITÀDEGLI STUDI DI TRIESTE
6
I Capi Struttura dovranno poter compilare e salvare nella form library la richiesta mentre non è
previsto possano modificarla o cancellarla in quanto, al momento dell’inserimento, verrà avviato il
processo di approvazione.
La Ripartizione dovrà avere il controllo completo sulla form library in quanto deve poter gestire tutte
le richieste inserite dai Capi Struttura e, in caso di necessità, poter modificare le impostazioni della
libreria stessa.
Una volta conclusa la compilazione, la form verrà salvata all’interno della stessa form library in cui è
stato pubblicato il template, fondamentale è l’unicità del nome assegnato in modo da evitare l’impos-
sibilità di salvare la form in caso di nome duplicato o la sovrascrittura del file già esistente se questa
opzione è consentita.
Dovendo assicurare l’unicità del file non si può lasciare la scelta del nome a carico del richiedente ed
è necessario definire una regola per la sua composizione.
Il nome della form può essere predefinito durante la progettazione del template, sia con valori
statici, sia con valori basati sulle voci del modulo, sia utilizzando una formula. Si potrebbe utilizzare
una concatenazione di stringhe prendendo il nome ed il cognome del richiedente e poi aggiungendo
il riferimento temporale di invio. Per evitare di ritrovarci con delle stringhe vuote sarà necessario
impostare che i campi contenenti il nome ed il cognome del richiedente siano obbligatori.
La formula now() cattura la data del sistema nel formato “aaaa-mm-gg” e l’ora nel formato “hh_
mm_ss” e le concatena nel seguente modo: “aaaa-mm-ggThh_mm_ss”.
Solo l’aggiungere il risultato della formula now() ci garantisce che il nome del file sarà unico in quan-
to formare il nome del file con il solo nome e cognome del richiedente non può essere sufficiente
nell’ipotesi realistica che un Capo Struttura possa effettuare più richieste di dispositivi hardware per
gli afferenti alla struttura. Anche l’aggiungere a questi campi il risultato della formula today() potreb-
be non essere sufficiente in quanto un Capo Struttura potrebbe effettuare più richieste nello stesso
giorno.
L’analisi per quanto riguarda la pubblicazione della form può considerarsi conclusa, ora prendiamo
7
Figura 2.3: workflow di approvazione
in considerazione l’aggiunta di un workflow per automatizzare il flusso delle informazioni fra il richie-
dente ed i tecnici del supporto IT.
La gestione della richiesta di dispositivi hardware si può sintetizzare nei seguenti passi:
- una nuova richiesta viene salvata nella form library ed è in attesa di approvazione;
- il supporto IT valuta la richiesta;
- la richiesta è stata completata.
Quando il Capo Struttura inserisce una nuova richiesta nella form library, il workflow viene avviato e
l’attività di approvazione invia una email di avviso al supporto IT con il link alla richiesta.
Quando il supporto IT ha completato la valutazione della richiesta approvandola o rifiutandola viene
inviata una email di avviso al Capo Struttura con il link alla richiesta completata.
Il workflow di approvazione potrebbe venir così rappresentato:
8
Utilizzare il workflow porta valore aggiunto all’applicazione in quanto viene favorita la collaborazione
mediante la gestione automatizzata delle notifiche e si eliminano i possibili errori umani.
Una possibile ipotesi di realizzazione dell’obiettivo che ci siamo prefissi è la sua suddivisione in step
successivi a seconda delle tecnologie utilizzate, in questo modo si possono ottenere tre prototipi con
diversi livelli di automazione ma tutti rispondenti alle necessità della Ripartizione.
Step 1:
creazione della form, compilazione della stessa da parte del Capo Struttura ed invio della richiesta
via mail alla Ripartizione. A questo punto i tecnici del supporto IT possono visionare la richiesta ed
inviare una email al richiedente informandolo se la sua richiesta è stata approvata o respinta.
Vengono utilizzati i seguenti prodotti:
- Microsoft InfoPath Designer per la creazione della form;
- Microsoft InfoPath Filler per la compilazione della form da parte del Capo Struttura;
- Microsoft Outlook per l’invio della form alla Ripartizione e per la risposta riguardante l’approva-
zione al Capo Struttura.
Già con l’utilizzo del solo InfoPath è possibile raccogliere dati e semplificare i processi aziendali con
moduli elettronici facili da progettare, distribuire ed utilizzare.
Da sottolineare che sul parco macchine degli uffici amministrativi, la compilazione di una form me-
diante l’ausilio di InfoPath Filler e l’invio della stessa attraverso Outlook, può avvenire fin da subito in
quanto su tutte le postazioni viene installato il pacchetto Office comprensivo di questi due prodotti.
Step 2:
pubblicazione della form su SharePoint in modo da consentire al Capo Struttura di compilare e salva-
re la richiesta in una form library. A questo punto i tecnici del supporto IT possono visionare la richie-
sta ed inviare una email al richiedente informandolo se la sua richiesta è stata approvata o respinta.
Vengono utilizzati i seguenti prodotti:
- Microsoft InfoPath Designer per la creazione della form;
- Microsoft InfoPath Filler per la compilazione della form da parte del Capo Struttura;
9
- Microsoft SharePoint per pubblicare la form ed archiviare le richieste;
- Microsoft Outlook per la risposta al Capo Struttura riguardo all’approvazione della richiesta.
Step 3:
creazione di una form browser-based e pubblicazione della stessa su SharePoint in modo da con-
sentire al Capo Struttura di compilarla online ed utilizzare i workflow presenti in SharePoint per au-
tomatizzare il flusso delle informazioni fra il richiedente ed i tecnici del supporto IT. I tecnici possono
approvare o respingere la richiesta motivando.
Vengono utilizzati i seguenti prodotti:
- Microsoft InfoPath Designer per la creazione della form;
- Microsoft SharePoint per pubblicare la form, compilare ed archiviare le richieste;
- Microsoft SharePoint Designer per progettare il workflow ed automatizzare il flusso delle informa-
zioni.
Ovvero viene utilizzato l’ambiente integrato SharePoint - InfoPath
10
3. TECNOLOGIE
In questo capitolo verrà fatto solo un breve cenno ad InfoPath e SharePoint e trattati gli aspetti tec-
nici di interesse per la realizzazione del progetto.
3.1 MICROSOFT INFOPATH 2010
InfoPath4 è un programma della suite Microsoft Office che è stato pensato per la progettazione e la
compilazione di moduli dinamici ed è strutturato in due parti:
- InfoPath Designer per la progettazione dei moduli;
- InfoPath Filler per la compilazione dei moduli.
InfoPath si basa sul formato Extensible Markup Language (XML). Quando si progetta un modulo
viene creato un file con estensione XSN, ovvero un file cabinet (cab) contenente i file necessari per
il normale funzionamento, quali i file schema XML (XSD) e di trasformazione XSL (XSLT).
L’XML Schema è l’unico linguaggio di descrizione del contenuto di un file XML che abbia per ora rag-
giunto la validazione ufficiale del W3C (World Wide Web Consortium, associazione non governativa
internazionale che ha come scopo quello di sviluppare tutte le potenzialità del World Wide Web).
XSD è l’acronimo di XML Scheme Definition, è lo schema di definizione della struttura di un docu-
mento XML scritto in linguaggio XML Schema. Definisce il documento in termini di vincoli, contiene i
parametri e gli attributi e può venir utilizzato anche con un programma di validazione.
XSLT è l’acronimo di eXtensible Stylesheet Language Transformation, è un linguaggio basato su XML
che permette di definire delle regole per trasformare un documento XML in un altro documento XML
o in un documento HTML. La trasformazione viene realizzata da un XSLT Processor che riceve come
input il file XML da trasformare ed il file XSL con la definizione dello stylesheet da applicare e produce
come output il file trasformato.
Quando un utente compila un modulo in InfoPath, i dati di quel modulo vengono salvati o inviati nel
formato XML standard, in questo modo i dati sono separati dai moduli e possono essere utilizzati da
altri programmi.
4 Maggiori informazioni su InfoPath 2010 sono reperibili alla pagina http://office.microsoft.com/it-it/infopath/
11
Tuttavia, non è necessario conoscere il linguaggio XML per progettare un modello di modulo o com-
pilare un modulo.
La creazione di moduli avviene attraverso la modifica della ricca dotazione di modelli preimpostati
oppure con la creazione ex-novo ma in entrambi i casi si lavora in un ambiente WYSIWYG “What
You See Is What You Get”.
Quando si compila un modulo, l’utente è aiutato dalla funzione Autocomplete che fornisce diverse
alternative sulla base di valori inseriti in precedenza e l’inserimento dei dati può essere ulteriormente
velocizzato sfruttando la possibilità di estrarre dati da sorgenti esterne quali database, web services
o file XML.
I dati inseriti dall’utente possono essere validati, prima di essere effettivamente inviati o memorizza-
ti, sia tramite scripting che usando delle regole di convalida (XML Schema).
Il modulo può essere strutturato in modo da inviare i dati con cui è stato completato ad un web
service, ad un database o ad un file XML ed esiste la possibilità, qualora non sia disponibile una
connessione di rete, di lavorare off-line ed inviare i dati in un secondo momento.
Un altro aspetto importante è che il formato XML del modulo può facilitare in misura considerevole
il reimpiego dei dati da parte di un’organizzazione.
12
5 Maggiori informazioni su SharePoint 2013 sono reperibili alla pagina http://technet.microsoft.com/it-it/sharepoint/fp142366
3.2 MICROSOFT SHAREPOINT 2013
SharePoint5 è un insieme di prodotti e tecnologie per creare siti collaborativi e portali intranet,
extranet ed internet. Consente di gestire documenti (Document Management) e gestire contenuti
(Content Management System).
SharePoint 2013 è stato rilasciato il 28 ottobre 2012 sul canale di distribuzione Volume e le versioni
attualmente disponibili sono: SharePoint Foundation e SharePoint Server.
SharePoint Foundation viene distribuito gratuitamente, è la tecnologia alla base di tutti i siti Share-
Point e nelle versioni precedenti era noto come SharePoint Services.
SharePoint Server è un prodotto server basato sulla tecnologia SharePoint Foundation, rispetto alla
versione gratuita, di cui include tutte le funzionalità, ha delle caratteristiche aggiuntive quali la ge-
stione del contenuto aziendale, la business intelligence, la ricerca di contenuti aziendali ed i profili
personali utilizzabili tramite i siti personali. E’ disponibile per la distribuzione in locale oppure nell’am-
bito di un’offerta di servizi basata su cloud come Microsoft Office 365.
SharePoint 2013 va ad aggiungere alla base architetturale di SharePoint 2010 alcune novità/miglio-
ramenti che riguardano in particolare:
- l’interfaccia utente, che è stata resa il più coerente possibile con i nuovi paradigmi “Modern User
Interface” che Microsoft ha introdotto con Windows 8.
- Nuovo modello delle App, ora è possibile sviluppare applicazioni che bypassano tutti i limiti archi-
tetturali imposti fino ad ora da SharePoint. Le applicazioni possono venir eseguite all’interno del
browser dell’utente oppure interagire tramite un rinnovato modello ad oggetti con le piattaforme
di Cloud Computing come Windows Azure.
- La funzionalità di ricerca che deriva dalla fusione di tutte le varie versioni del search di SharePoint
in un unico prodotto basato principalmente su FAST.
- È stata estesa la parte di Social Networking aggiungendo funzionalità in grado di migliorare le
attività di community nel team di lavoro. L’introduzione della funzionalità di following su siti, liste,
documenti e persone e la possibilità di utilizzare il simbolo @ e # come su Twitter sono le due
13
novità più importanti6.
- Fra le tante modifiche architetturali quella che ha un maggior impatto è l’utilizzo del Framework
.NET 4.5.
InfoPath e SharePoint sono perfettamente integrati e si può scegliere di progettare un modello di
modulo compatibile con il browser. Quando il template del modulo viene distribuito in un server che
esegue InfoPath Forms Services, gli utenti possono compilarlo in un browser senza dover disporre
di InfoPath Filler. La modalità di compilazione e le funzionalità come la convalida dei dati7 sono pro-
gettate per l’utilizzo nel browser evitando in tal modo di ripetere gli accessi al server. I risultati che
vengono visualizzati in determinate condizioni sono pertanto immediatamente visibili in quanto nel
browser non è necessario ricaricare il modulo ad ogni interazione dell’utente.
Di default una form viene visualizzata nel portale con una pagina a tutto schermo, il rendering web
di un modulo InfoPath avviene per merito di un controllo web, XmlFormViewer, che si trova nell’as-
sembly Microsoft.Office.InfoPath.Server.
Ci sono altre due possibili soluzioni per il rendering web di InfoPath:
- includere XmlFormViewer all’interno di una pagina aspx personalizzata da integrare all’interno di
Sharepoint;
- includere XmlFormViewer all’interno di una web part.
I workflow inclusi nei prodotti SharePoint8 consentono di automatizzare i processi aziendali renden-
doli più semplici e standardizzati e posso essere di due tipi: sequenziali e macchine a stati finiti. Il
primo tipo consiste in una successione di attività che devono essere svolte in un ordine prefissato e
sono facilmente implementabili mediante i workflow presenti in SharePoint che offrono delle opera-
zioni standard componibili tra loro, ovvero condizioni ed azioni raggruppabili in step. Nel secondo tipo
il modello è organizzato in determinati stati, a loro volta composti da attività che qualora completate
originano un evento che determina la transizione da uno stato all’altro.
5 Maggiori informazioni sui workflow inclusi in SharePoint 2013 e sulle novità introdotte alla pagina http://technet.microsoft.com/it-it/library/jj227177.aspx
6 @ indirizza un post agli utenti SharePoint e # identifica la parola successiva come parola chiave dinamica per seguire il Managed Meta-data Service (MMS) su SharePoint.
7 Processo di verifica della precisione dei dati. Insieme di regole che è possibile applicare ad un controllo per specificare il tipo e l’inter-vallo dei dati che gli utenti possono immettere.
14
4. REALIZZAZIONE
4.1 PRIMO PROTOTIPO
La form realizzata per il primo prototipo è la seguente:
Figura 4.1: form di richiesta
UNIVERSITÀDEGLI STUDI DI TRIESTE
15
Le richieste devono venir effettuate dal Capo Struttura che inserirà i dati relativi a se stesso (nome,
cognome, indirizzo email e struttura) e quelli relativi all’assegnatario (nome e cognome) in dei campi
testuali.
La tipologia del bene viene selezionata in una drop-down list che riporta alcune possibili scelte. Se
viene selezionata l’opzione Altro… si ha la possibilità di scrivere la tipologia del bene in una casella
di testo compilabile che viene visualizzata solo nel caso venga scelta questa opzione.
Se si seleziona l’opzione Altro… l’aspetto della form è il seguente:
Per indicare se il bene richiesto è nuovo o se va in sostituzione va selezionata l’opzione corrisponden-
te mediante l’option button. Se si seleziona In sostituzione verrà visualizzato un campo di testo nella
quale va inserito il numero di inventario del bene da sostituire e l’aspetto della form è il seguente:
Figura 4.2: dettaglio della form di richiesta – tipologia del bene
Figura 4.3: dettaglio della form di richiesta – bene nuovo/in sostituzione
L’ultimo campo da compilare è quello riguardante la motivazione, questa informazione è fondamen-
tale ai tecnici del supporto IT per decidere se approvare o meno la richiesta ma spesso non viene
indicata, così è stato impostato come campo obbligatorio. Se non si inserisce la motivazione non è
possibile inviare la richiesta.
Dopo aver completato l’inserimento dei dati il richiedente può premere il bottone Invia Richiesta
affinché la form venga inviata come allegato di una email indirizzata alla Ripartizione.
Quando si clicca il bottone Invia Richiesta viene visualizzato un messaggio in cui viene notificato a
16
chi verrà inviata la form, l’oggetto del messaggio ed il testo. Per confermare l’invio bisogna scegliere
Send, se invece si vuole modificare la form si può scegliere Cancel, questo messaggio viene visua-
lizzato automaticamente da InfoPath.
Sono state associate due regole alla pressione del bottone Invia Richiesta:
- l’invio della form attraverso l’email;
- la visualizzazione di una vista di InfoPath nella quale viene confermato l’invio della richiesta e la
presa in consegna della stessa da parte della Ripartizione, inoltre viene segnalato che verrà inviata
una email di risposta all’indirizzo indicato nella form. E’ necessario chiudere la pagina premendo
il bottone OK.
La vista di InfoPath è la seguente:
Figura 4.4: vista di InfoPath - conferma di invio richiesta
Solo la prima regola inserita merita un approfondimento.
InfoPath mette a disposizione quattro possibili Data Connection per l’invio della form:
- ad un Web Service;
- ad una raccolta documenti su SharePoint;
- in un messaggio di posta;
- ad un ambiente hosting, come ad esempio una pagina web ASP.NET.
In questo caso si è scelto di inviare la form compilata dal Capo Struttura via email, scegliendo questa
opzione la Data Connection Wizard richiede l’inserimento di alcune informazioni e di effettuare delle
scelte.
UNIVERSITÀDEGLI STUDI DI TRIESTE
17
La prima scelta da effettuare è: a chi inviare l’email. Si possono inserire uno o più indirizzi e po-
polare i campi To:, CC:, BCC:. In questo caso è sufficiente inserire l’indirizzo email utilizzato dalla
Ripartizione per le richieste di dispositivi hardware nel campo To: in quanto le email indirizzate a
[email protected] vengono automaticamente inoltrate a tutti gli afferenti alla Ripartizione ed al
personale della Divisione ISI coinvolti nel processo di assegnazione.
Poi bisogna indicare l’oggetto del messaggio ed un breve messaggio di testo del tipo “Questo mes-
saggio è stato creato da Microsoft InfoPath, la form è stata allegata.”
Gli indirizzi del messaggio, la riga dell’oggetto ed il nome della form allegata possono essere pre-
definiti durante la progettazione del template, sia con valori statici, sia con valori basati sulle voci del
modulo, sia utilizzando una formula. Si è scelto di personalizzare l’oggetto del messaggio mediante
una formula di concatenazione di stringhe al fine di ottenere il testo “Richiesta di fornitura hardware
per” seguito dal nome e cognome dell’assegnatario.
Per concludere è necessario indicare un nome per la form allegata e per la Data Connection.
La form di richiesta è stata inviata con successo da parte del Capo Struttura ed ora il supporto IT sarà
in grado di valutarne la fattibilità, approvandola oppure respingendola ed in questo modo concluderà
il flusso del processo.
Nel caso la richiesta venga approvata, nella email di risposta verranno riportate le indicazioni sul
bene assegnato, come la marca, il modello ed il numero di inventario.
In caso contrario sarà richiesto di indicare la motivazione del rifiuto.
18
4.2 SECONDO PROTOTIPO
Microsoft InfoPath Designer verrà utilizzato per effettuare le necessarie modifiche alla form del pri-
mo prototipo: verranno analizzate solo le modifiche apportate in quanto le scelte già effettuate e
motivate nel primo progetto rimangono invariate.
Per consentire l’utilizzo di SharePoint Server 2013 si è proceduto ad installare una macchina virtuale
con Windows Server 2012 Standard inserita nel dominio ds.units.it.
Si è utilizzato un solo server, installandovi tutti i ruoli ed utilizzando le impostazioni predefinite: que-
sta tipologia di installazione è consigliata esclusivamente per scopi valutativi o di sviluppo.
La procedura di setup installa Microsoft SQL Server 2008 R2 SP1 Express Edition e SharePoint Server
2013.
Al termine della procedura di installazione, è necessario eseguire la procedura di configurazione
guidata dei prodotti SharePoint per i database di configurazione e del contenuto, nonché per il sito
di amministrazione centrale.
Si è scelto di creare un Team Site, che è una tipologia di sito nata per la collaborazione fra gli utenti
di un organizzazione e spesso include del contenuto che non viene direttamente pubblicato ma uti-
lizzato solo internamente.
Alla form creata nel realizzare il primo prototipo è stato necessario apportare solo alcune modifiche:
- pubblicare il template della form nella raccolta moduli;
- modificare la Data Connection.
4.2.1 Pubblicazione dell Form
Esistono tre metodi per pubblicare le form in Sharepoint:
- la Form library viene utilizzata quando il modulo deve essere compilato ed inviato solo ad una
singola posizione del sito. Quando una form viene pubblicata in una raccolta moduli, il file XS della
form diventa il template della raccolta. In genere, quando si sceglie questo metodo, anche la form
compilata verrà salvata all’interno della stessa raccolta.
19
- Il Site content type viene utilizzato quanto la form deve venir distribuita in più raccolte del sito.
- L’Administrator approved form template viene utilizzata quando la form deve venir distribuita a
livello globale della farm o quando contiene codice personalizzato. A differenza degli altri due
metodi, in questo caso, il modulo non viene distribuito automaticamente in SharePoint ma viene
creato un file XSN come output che poi deve venir caricato in InfoPath Forms Services dall’ammi-
nistratore.
Il processo di creazione di una form genera in realtà un template che viene salvato con l’estensione
XSN. Dopo averlo pubblicato in un percorso accessibile agli utenti, questi possono creare una nuova
istanza della form che verrà poi salvata come file in formato XML, basato sul template del modulo e
con uno schema XML associato.
Si è scelto di utilizzare il primo metodo in quanto soddisfa le nostre esigenze.
A tal fine è stata creata una form library dal nome Hardware nella quale è stato pubblicato il tem-
plate della form e che verrà utilizzata anche per salvare le form compilate.
In SharePoint è possibile controllare l’accesso al sito ed al suo contenuto tramite l’assegnazione di
autorizzazioni a utenti o gruppi ulteriormente raffinabili a livello di raccolta o elenco, cartella, do-
cumento o elemento. Essendo il sito dedicato al progetto si possono assegnare le autorizzazioni a
questo livello, in un caso reale potrebbe esserci la necessità di assegnare dei permessi più granulari
a livello di raccolta.
Quando si assegnano le autorizzazioni è fondamentale trovare il giusto compromesso tra facilità di
amministrazione, prestazioni e la necessità di controllare l’accesso ai singoli elementi. Di norma, se
si utilizzano diffusamente le autorizzazioni specifiche si impiegherà più tempo per gestire le autoriz-
zazioni.
E’ consigliato attenersi alle seguenti linee guida quando si pianificano le autorizzazioni:
- seguire il principio dei privilegi minimi, in base al quale gli utenti devono disporre esclusivamente
dei livelli di autorizzazione o delle autorizzazioni singole di cui hanno la necessità per eseguire le
attività loro assegnate;
- utilizzare i gruppi standard, come ad esempio Visitors, Members ed Owners per controllare le
autorizzazioni a livello di sito.
20
Il gruppo Members, denominato Request Forms Members, conterrà i Capi Struttura. Per impostazio-
ne predefinita gli utenti inclusi in questo gruppo possono collaborare al sito aggiungendo o rimuo-
vendo elementi o documenti, ma non ne possono modificare la struttura, le impostazioni o l’aspetto.
Le impostazioni predefinite devono venir aggiustate in quanto non è previsto che i Capi Struttura
possano modificare od eliminare le richieste inserite.
E’ stato necessario creare un livello personalizzato di autorizzazioni, denominato Contribute with Re-
strictions: dai permessi di collaborazione assegnati al gruppo Members è stata tolta l’autorizzazione
a modificare e cancellare elementi o documenti.
Il gruppo Owners, denominato Request Forms Owners, conterrà gli amministratori del sito, ovvero
gli afferenti alla Ripartizione. In generale, è buona norma limitare il numero delle persone apparte-
nenti a questo gruppo inserendovi solo gli utenti che si ritiene possano modificare in modo affidabile
la struttura, le impostazioni o l’aspetto del sito.
Per simulare i permessi assegnati al sito sono stati creati degli utenti fittizi nel Directory Servi-
ce di Ateneo (dominio ds.units.it) che rappresentano i Capi Struttura: RequestFormsUser001, Re-
questFormsUser002 e RequestFormsUser003.
Nel dominio ds.units.it è stato creato anche un gruppo denominato RequestFormsMember, in cui
sono stati inseriti gli utenti RequestFormsUser001, RequestFormsUser002 e RequestFormsUser003,
poiché è più agevole e corretto utilizzare i gruppi per l’assegnazione dei permessi.
Nel gruppo Request Forms Members di SharePoint è stato inserito l’omonimo gruppo di dominio.
Nel gruppo Request Forms Owners di SharePoint è stato inserito il gruppo di dominio A_000801, i
cui membri sono gli afferenti alla struttura con codice 000801 ovvero la Ripartizione Supporto utenti
e assistenza tecnica.
Ora che sono stati assegnati i permessi alla raccolta Hardware si può pubblicare la form, per far ciò
è necessario selezionare l’opzione Publish nel menu File di InfoPath.
Le informazioni necessarie alla pubblicazione, e richieste dal wizard, sono:
- l’URL del sito in cui si vuole pubblicare la form, nel nostro caso http://raijin/sites/RequestForms/;
21
- selezionare la raccolta, fra quelle proposte, in cui si vuole pubblicare il modello. Nel nostro caso
Hardware.
- I campi che si intende promuovere, ovvero i campi della form che si desidera inserire come co-
lonne nella visualizzazione predefinita della raccolta. Nel nostro caso chi sia il richiedente lo si può
desumere dal nome del file, di conseguenza potrebbe essere utile promuovere a colonne i campi
NomeAssegnatario, CognomeAssegnatario e Tipologia. Così facendo, sarà sufficiente visualizzare
il nome del file e le colonne promosse per ricavare gli estremi della richiesta.
Conclusa la pubblicazione del template, la form non sarà visibile all’interno della raccolta Hardware
bensì si potrà scegliere l’opzione New document in SharePoint per creare un’istanza del modulo da
compilare tramite InfoPath Filler.
4.2.2 Data Connection
Dopo aver selezionato New document, aver compilato la form e verificato la correttezza dei dati
inseriti, il richiedente potrà premere il bottone Invia Richiesta affinché la form venga salvata nella
raccolta Hardware sul sito SharePoint.
Per far ciò è necessario definire una nuova Data Connection e le prime informazioni che vengono
richieste sono l’URL della raccolta (http://raijin/sites/RequestForms/Hardware) unitamente al nome
con cui verrà salvata la form.
Ovviamente in questo caso, a differenza del primo prototipo, non si può scegliere come nome as-
segnato quello predefinito (form) ma invece è necessario che il file abbia un nome sicuramente
univoco all’interno della raccolta.
Si è implementato quanto definito nell’analisi, ovvero si è imposto che il campo NomeRichiedente e
CognomeRichiedente fossero obbligatori ed è stato aggiunto un campo SubmitDateTime contenente
il risultato della formula now(). Mediante la concatenazione di questi campi si ottiene il nome della
form.
Essendo il campo SubmitDateTime di unico interesse per la composizione del nome della form il
controllo è stato nascosto.
22
L’ultima opzione proposta nella definizione della Data Connection è la possibilità di sovrascrivere i file
esistenti, non sfruttata nel nostro caso in quanto i privilegi sugli elementi della raccolta dipendono
dai permessi assegnati al gruppo Request Forms Members di SharePoint.
Sono state associate due regole alla pressione del bottone Invia Richiesta:
- il salvataggio della form nella raccolta in base a quanto definito nella Data Connection;
- viene visualizzata una vista di InfoPath nella quale viene confermato il salvataggio della richiesta
nella raccolta Hardware e viene segnalato che verrà inviata una email di risposta all’indirizzo indi-
cato nella form. E’ necessario chiudere la pagina premendo il bottone OK.
La vista di InfoPath è la seguente:
Figura 4.5: vista di InfoPath - conferma di invio richiesta
Nel caso la richiesta venga approvata, nella email di risposta verranno riportate le indicazioni sul bene
assegnato, come la marca, il modello ed il numero di inventario.
In caso contrario sarà richiesto di indicare la motivazione del rifiuto
UNIVERSITÀDEGLI STUDI DI TRIESTE
23
4.3 TERZO PROTOTIPO
Nel realizzare il terzo prototipo, è stato utilizzato Microsoft InfoPath Designer per effettuare le modi-
fiche necessarie alla form creata nello svolgere il secondo step dell’obiettivo ed anche in questo caso,
si analizzeranno solo le modifiche apportate in quanto le scelte già effettuate e motivate nel primo
e nel secondo progetto rimangono invariate.
Scegliendo la voce Form Options nel menu File, si possono modificare le opzioni di visualizzazione
della form all’interno del browser: in questo caso verrà visualizzata la barra degli strumenti di Info-
Path nella parte superiore ed inferiore della form in quanto, non venendo visualizzata per intero all’in-
terno della pagina, per la sua compilazione sarà necessario utilizzare la barra di scorrimento laterale.
Nella barra degli strumenti, oltre ai pulsanti standard (Paste, Copy e Cut) presenti nella sezione
Clipboard, sarà visibile il solo tasto Close nella sezione Commit.
La form si compone di tre viste le quali rappresentano i passi del processo di approvazione: una per
la richiesta, una per consentire al supporto IT di valutarla e l’ultima con tutte le informazioni raccolte
disponibili in sola lettura a dimostrare che il processo è stato completato.
Per la richiesta da parte del Capo Struttura viene utilizzata la form creata negli step precedenti op-
portunamente modificata.
La seconda e la terza vista sono create appositamente per questo prototipo, rappresentano la parte
del processo di approvazione che negli step precedenti non era automatizzata. Nei primi due prototi-
pi, il supporto IT inviava una mail al Capo Struttura al termine del processo di approvazione.
4.3.1 Prima vista: la richiesta
Rispetto a quanto realizzato nel secondo prototipo, sono state apportate delle modifiche anche all’e-
stetica della form:
- è stato eliminato l’indirizzo email del richiedente in quanto non più necessario, sarà il sistema ad
inviare automaticamente una email al proprietario del documento al termine del processo di ap-
provazione;
24
Figura 4.6: form di richiesta
Alla pressione del bottone Invia Richiesta, sono state associate le seguenti regole:
- al campo FormStatus viene assegnato il valore “Approvazione”;
- la form viene salvata nella raccolta come definito nella Data Connection;
UNIVERSITÀDEGLI STUDI DI TRIESTE
- i campi testuali riguardanti il nome ed il cognome del richiedente e dell’assegnatario, sono stati
condensati in modo da agevolare l’aggiunta in calce di una sezione, che verrà compilata dalla
Ripartizione in fase di approvazione.
La form modificata avrà il seguente aspetto:
25
- la form viene chiusa automaticamente.
Il campo nascosto FormStatus viene utilizzato per indicare a che punto del processo di approvazione
ci si trova: in base al valore assegnato viene visualizzata una vista piuttosto che un’altra e vengono
attivate le azioni predefinite nel workflow associato alla form library.
Alla prima apertura della form al campo FormStatus viene assegnato il valore “Nuovo” e viene visua-
lizzata la form per inserire la richiesta.
Quando il Capo Struttura completa la compilazione del modulo e seleziona il bottone Invia Richiesta,
al campo FormStatus viene assegnato il valore “Approvazione” per l’inserimento di una nuova richie-
sta in attesa di valutazione da parte del supporto IT.
L’utilizzo del campo FormStatus nel workflow di approvazione verrà illustrato al termine della descri-
zione delle viste create.
Per consentire la pubblicazione di questa form è stata creata una nuova form library nel sito Share-
Point dal nome Hardware Online e di conseguenza, sono state modificate le impostazioni di pubbli-
cazione e la Data Connection.
Alla form library Hardware Online vengono applicati gli stessi permessi della form library Hardware,
in quanto assegnati a livello di sito.
Per quanto riguarda le impostazioni di pubblicazione è stato modificato l’URL della raccolta in http://
raijin/sites/RequestForms/HardwareOnline ed ai campi già promossi (NomeAssegnatario, Cogno-
meAssegnatario e Tipologia) è stata aggiunta la colonna FormStatus. I possibili valori visualizzati
nel campo FormStatus sono “Approvazione” e “Completato”: in questo modo si ottiene la visibilità
immediata di quali richieste debbano ancora venir valutate.
La form di richiesta viene salvata all’interno della stessa form library in cui è stato pubblicato il mo-
dello (http://raijin/sites/RequestForms/HardwareOnline), di conseguenza è stato necessario modifi-
care la Data Connection.
La regola, definita nello step precedente per l’assegnazione del nome, è rimasta invariata.
26
4.3.2 Seconda vista: l’approvazione
La seconda vista viene compilata dal supporto IT dopo aver valutato la richiesta del Capo Struttura,
ed è composta da due parti: la parte superiore è la replica della prima vista mentre la parte inferiore
è identificata dalla dicitura “A cura della Ripartizione Supporto utenti e assistenza tecnica”.
L’aspetto della form è il seguente:
Figura 4.7: form di approvazione
UNIVERSITÀDEGLI STUDI DI TRIESTE
27
La parte superiore della form consiste in una ripetizione della prima vista dove vengono riportati in
sola lettura i dati inerenti al richiedente, all’assegnatario ed al bene stesso, in modo da consentire al
supporto IT di visionare la richiesta, valutarla e decidere se approvarla.
La parte inferiore della form deve venir compilata dalla Ripartizione ed è composta da tre sezioni:
- la sezione contenente l’option button per selezionare i valori Approvata o Respinta;
- la sezione contenente i campi da compilare nel caso la richiesta venga approvata;
- la sezione contenente i campi da compilare nel caso la richiesta venga respinta.
Prima sezione:
in base all’opzione scelta viene visualizzata la corrispondente sezione sottostante.
Seconda sezione:
Figura 4.8: sezione a cura della Ripartizione
Figura 4.9: sezione da compilare in caso di approvazione
viene visualizzata se è stata scelta l’opzione Approvata.
E’ formata da campi testuali e contiene tutte le informazioni necessarie ad individuare il bene asse-
gnato: Marca, Modello e Numero di Inventario, oltre al campo informativo Note.
Non è possibile impostare come obbligatori i campi Marca, Modello e Numero di Inventario perché,
se viene scelta l’opzione Respinta, essi non verrebbero compilati. Il loro inserimento, in caso di as-
segnazione del bene, sarà a cura ed interesse della Ripartizione.
28
Terza sezione:
Figura 4.10: sezione da compilare in caso di rifiuto
viene visualizzata se è stata scelta l’opzione Respinta.
E’ formata dalla sola motivazione ed anche in questo caso il campo testuale non può venir impostato
come obbligatorio in quanto, se venisse scelta l’opzione Approvata sarebbe necessario compilarla.
Alla pressione del bottone Chiudi, sono state associate le seguenti regole:
- al campo FormStatus viene assegnato il valore “Completato” ad indicare che il processo di appro-
vazione si è concluso;
- la form viene salvata nella raccolta come definito nella Data Connection, la medesima utilizzata
nella prima vista;
- la form viene chiusa automaticamente.
4.3.3 Terza vista: l’archiviazione
Una volta concluso il processo di approvazione, la terza vista ha uno scopo meramente riepilogati-
vo, in quanto riprende tutte le informazioni inserite nella prima e nella seconda vista proponendole
in sola lettura poiché non è previsto che una richiesta, e la sua relativa valutazione, possano venir
modificate a processo terminato.
Rappresenta l’archiviazione della richiesta stessa e di conseguenza non è presente alcuna regola
all’interno della form.
Per chiudere la form è necessario selezionare il bottone Close presente sulla barra degli strumenti
di InfoPath, inserito proprio per l’utilizzo in questa fase in quanto la chiusura della prima e della se-
conda vista avviene automaticamente.
29
4.3.4 Workflow di approvazione
Per implementare il workflow di approvazione è stato utilizzato SharePoint Designer 20139, pro-
gramma gratuito per la progettazione di siti web ed applicazioni, utilizzato per progettare, creare e
personalizzare siti eseguiti su SharePoint.
Il workflow invia una email al supporto IT quando viene inserita una nuova richiesta e successiva-
mente al Capo Struttura quando il processo di approvazione è concluso.
La prima operazione da fare consiste nell’indicare qual è il sito da personalizzare (http://raijin/sites/
RequestForms/) per poi scegliere che tipo di workflow si vuole realizzare tra List, Reusable e Site
Workflow. In questo caso si tratta di un List Workflow associato alla form library Hardware Online
e si basa sulla piattaforma di wokflow di SharePoint 2010 (incluso con SharePoint Server 2013), in
quanto dovendo definire un semplice flusso di lavoro non è stato necessario installare il componente
di Management Workflow per SharePoint 2013.
Le opzioni di avvio selezionate sono le seguenti:
- Start workflow automatically when an item is created per l’invio della prima email alla Ripartizione
che segnala che una nuova richiesta è stata inserita;
- Start workflow automatically when an item is changed per l’invio della seconda email al Capo
Struttura a conclusione del processo di approvazione.
Gli step definiti nel workflow sono due:
1 Maggiori informazioni su SharePoint Designer 2013 alla pagina http://msdn.microsoft.com/it-it/sharepoint/hh850380.aspx
Figura 4.11: workflow di approvazione
30
La prima azione viene eseguita se il campo FormStatus è uguale ad “Approvazione”.
Anche in questo caso si è utilizzato un indirizzo email fittizio a scopo di test.
Il messaggio che viene inviato è il seguente:
Figura 4.12: messaggio inviato alla Ripartizione
L’oggetto può venir personalizzato percui si è scelto di utilizzare la funzione di concatenazione di
stringhe in modo che nell’oggetto venga inserito anche il nome ed il cognome dell’assegnatario del
bene.
La stringa che viene utilizzata in entrambe le email inviate è la seguente:
Figura 4.13: oggetto del messaggio
31
La seconda azione viene eseguita se il campo FormStatus è uguale a “Completato”.
Il messaggio viene inoltrato a colui che ha creato il documento ed è il seguente:
Figura 4.14: messaggio inviato al Capo Struttura
Per inviare le email è stato necessario installare il servizio smtp su SharePoint Server e configurarlo
per le impostazioni di Outgoing E-mail Settings per il sito:
- smtp.units.it è stato impostato come Outbound SMTP server
- l’indirizzo email del mittente è [email protected]
- il set di caratteri selezionato è Unicode – UTF8
Ecco come si presenta la form library Hardware Online con delle richieste inserite in diverse fasi del
processo di approvazione:
Figura 4.15: form library Hardware Online
32
5. SVILUPPI FUTURI
Nonostante il prototipo sia stato testato con successo, per la sua messa in produzione andrebbero
rivisti i seguenti punti:
- l’installazione di SharePoint;
- le autorizzazioni assegnate agli utenti;
- la compilazione della form;
- l’invio delle email di notifica.
L’installazione collassata su di un unico server è adottata solo per scopi valutativi o di sviluppo, in
produzione dovremmo valutare se installare SharePoint in un server singolo oppure su più server.
L’installazione su server singolo, nel caso si utilizzi SQL Server Standard o superiore invece della
versione Express, è facilmente scalabile per creare topologie di farm a due o tre livelli. E’ possibile
installare e configurare SharePoint su di un server singolo, se si prevede di ospitare un modesto
numero di siti dedicato ad un numero limitato di utenti, oppure nel caso si desideri creare una farm
per rispondere ad esigenze interne e solo successivamente si preveda di aggiungere ulteriori server.
Una configurazione di farm a due livelli è composta da un application server e da un database server.
L’installazione di Sharepoint su più server, e la topologia a tre livelli che ne risulta, costituisce la base
per implementare qualsiasi soluzione ed è generalmente utilizzata per le farm medio-grandi. Una
configurazione di farm a tre livelli è composta da due server web per il front-end, da un application
server e da un database server.
In termini di prestazioni, capacità e scalabilità, una topologia a tre livelli è preferibile ad una topolo-
gia a due livelli in quanto offre un layout fisico e logico più efficiente per la scalabilità orizzontale e
verticale, inoltre assicura una migliore distribuzione dei servizi tra i server membri della farm.
Se si considera l’utilizzo in produzione le autorizzazioni andrebbero riviste, si potrebbero ipotizzare
due casi:
- nella farm si creano diverse raccolte di siti mantenendo il sito Request Forms, con le autorizzazio-
ne a livello di sito;
- Nella farm, all’interno dello stesso sito, vengono create raccolte multiple utilizzate da gruppi di
utenti diversi. In questo caso emerge la necessità di assegnare dei permessi a livello di raccolta.
33
In entrambi i casi, al gruppo di dominio A_000801, i cui membri sono gli afferenti alla Ripartizione
Supporto utenti e assistenza tecnica, verrà garantito il controllo completo.
Ai Capi Struttura si continueranno ad assegnare i permessi di modifica, utilizzando gli account istitu-
zionali in modo da agevolare l’autenticazione integrata di Windows. In questo modo, i Capi Struttura
che accederanno al sito di SharePoint tramite Internet Explorer utilizzeranno le credenziali con cui
è in esecuzione il processo che, per impostazione predefinita, sono le medesime utilizzate per acce-
dere al computer. Negli uffici dell’Amministrazione centrale gli utenti accedono sulle loro postazioni
effettuando un login sul dominio ds.units.it con le credenziali istituzionali.
La posizione organizzativa ricoperta da un soggetto non rientra fra le proprietà valorizzate per l’og-
getto utente presente nel directory service d’Ateneo. Volendo autorizzare un gruppo contenente i
soli Capi Struttura, sarà necessario creare un gruppo di dominio ad hoc e popolarlo sulla base del
risultato di una opportuna query effettuata sul database autoritativo del personale.
I dati riferiti al richiedente (nome, cognome e struttura) ed all’assegnatario (nome e cognome) sono
tutti dei campi testuali che vengono inseriti dal Capo Struttura, sarebbe più opportuno che venissero
estratti dal database d’Ateneo che contiene tutte le informazioni riguardati l’anagrafica e la carriera
del dipendente.
E’ possibile connettere i moduli di InfoPath ad altre origini dati e sistemi line of business (LOB) grazie
all’interoperatività ottenibile tramite i servizi di integrazione applicativa di SharePoint Server 2013,
nel nostro caso sarebbe necessario accedere ad una base dati Oracle. L’inserimento del nome e
cognome del richiedente potrebbe avvenire tramite la selezione in una drop-down list ed il campo
afferenza verrebbe popolato automaticamente. L’origine dati della drop-down list è il risultato di una
query di selezione sul personale che ricopre una posizione di Capo Struttura.
Anche per l’inserimento del nome e cognome dell’assegnatario si potrebbe utilizzare una drop-down
list con origine il risultato di una query di selezione sul personale afferente alla struttura del richie-
dente.
Nel realizzare il prototipo non si è ritenuto necessario simulare questa situazione in quanto, non po-
tendo accedere ai dati reali, non ci sarebbero state implicazioni di una qualche rilevanza.
34
Per quanto riguarda i dati riferiti al richiedente, ci sarebbe anche un’ulteriore soluzione: si potrebbe-
ro estrarre nome, cognome e struttura dal directory service d’Ateneo. Prima di poter compilare una
nuova richiesta il Capo Struttura deve effettuare il login, di conseguenza, in fase di caricamento della
form, potrebbero venir popolati automaticamente i campi riferiti al richiedente mediante l’utilizzo di
codice per l’estrazione dei valori.
I messaggi di notifica vengono inviati automaticamente da SharePoint utilizzando l’indirizzo email del
destinatario, valorizzato utilizzando l’attributo mail dell’oggetto utente presente nel directory service
d’Ateneo.
Al termine del processo di approvazione viene inviata una email di notifica a colui che ha creato il file:
utilizzando gli account istituzionali dei Capi Struttura, si può avere la certezza che gli attributi mail
saranno correttamente valorizzati con l’indirizzo email istituzionale.
35
6. CONCLUSIONI
L’obiettivo è stato raggiunto, è stata realizzata una applicazione in ambiente integrato SharePoint
– InfoPath implementando dei flussi paperless fra più attori e completamente rispondenti alla neces-
sita della Ripartizione Supporto utenti e assistenza tecnica. Si è deciso di realizzare tre prototipi con
diversi livelli di automazione a seconda delle tecnologie utilizzate, tutti rispondenti alle necessità: la
gestione delle richieste di dispositivi hardware mediante delle form è stata realizzata in tutte le fasi
successive di sviluppo.
In questo momento il progetto è allo stato prototipale e, come illustrato nel capito precedente, sono
necessarie diverse migliorie per la sua messa in produzione. Andrebbe rivisto sia l’ambiente di svilup-
po, per quanto riguarda la tipologia di installazione di SharePoint ed i livelli di autorizzazioni assegnati
agli utenti, sia l’interfaccia delle form, da migliorarsi integrando SharePoint alla base dati Oracle, in
modo da poter estrarre i dati dal database autoritativo dell’Ateneo.
Dei tre prototipi realizzati, si potrebbe procedere con la messa in produzione del primo e del secon-
do. Come si è detto, sulle postazioni degli uffici amministrativi, la compilazione di una form mediante
l’ausilio di InfoPath Filler e l’invio della stessa attraverso Outlook può avvenire fin da subito in quanto
sul parco macchine viene installato il pacchetto Office comprensivo di questi due prodotti.
Il primo non richiede l’installazione di SharePoint, di conseguenza si potrebbe mettere a disposizione
il modello della form su una share concordata e visibile a tutti gli afferenti dell’Amministrazione cen-
trale. Dei prototipi realizzati è quello meno innovativo.
Il secondo è applicabile da subito e l’utilizzo di SharePoint per la distribuzione ed archiviazione delle
form è da considerarsi un valore aggiunto.
Il terzo prototipo richiede l’installazione di SharePoint Server per il rendering del modulo InfoPath
all’interno del browser e sicuramente è la situazione più costosa sia per l’acquisto del prodotto e delle
licenze, sia per la sua configurazione.
Questo progetto è un Proof of Concept allo scopo di dimostrare la fattibilità e la fondatezza dell’uti-
lizzo dell’ambiente integrato SharePoint - InfoPath per il raggiungimento dello scopo ma si potreb-
be applicare anche ad altri workflow su tematiche diverse, come ad esempio, se consideriamo le
necessità di un Dipartimento, alle richieste di acquisto, di missione, di contratti di collaborazione a
progetto.
36
[1] Darvish Shadravan, Laura Rogers. Using Microsoft InfoPath 2010 with Microsoft SharePoint
2010. Step by Step. Microsoft.
[2] Sito web contenente informazioni su Microsoft InfoPath 2010.
http://office.microsoft.com/it-it/infopath/
[3] Sito web contente informazioni sull’utilizzo dei workflow con moduli di InfoPath.
http://office.microsoft.com/it-it/infopath-help/introduzione-all-utilizzo-di-flussi-di-lavoro-con-
moduli-di-infopath-HA010204143.aspx
[4] Sito web contenente informazioni su Microsoft SharePoint 2013.
http://technet.microsoft.com/it-it/sharepoint/fp142366
[5] Sito web contenente informazioni sull’installazione e configurazione di SharePoint 2013.
http://technet.microsoft.com/it-it/library/cc262957.aspx
[6] Sito web contenente informazioni sulla configurazione della posta elettronica in uscita per una
farm di SharePoint 2013.
http://technet.microsoft.com/it-it/library/cc263462.aspx
[7] Sito web contenente informazioni sulla pianificazione delle autorizzazioni in SharePoint2013.
http://technet.microsoft.com/it-it/library/cc262939.aspx
[8] Sito web contente informazioni sulla pianificazione dei metodi di autenticazione in SharePoint
2013.
http://technet.microsoft.com/it-it/library/cc262350.aspx#planwin
[6] Sito web contente informazioni sull’utilizzo dei workflow in SharePoint Server 2013.
http://technet.microsoft.com/it-it/library/jj227177.aspx
BIBLIOGRAFIA
