SharePoint

Un approccio intelligente alla raccolta di dati nelle aziende

Keith Deshaies

Panoramica:

• Raccolta ed elaborazione dei dati
• Separazione della logica di presentazione dalla logica di gestione delle informazioni
• Utilizzo delle tecnologie di Microsoft Office 2007 per la creazione di una soluzione di raccolta dei dati

Scarica il codice per questo articolo: DataGathering2008_02.exe (567KB)

Nelle aziende si raccolgono grandi quantità di informazioni utilizzando metodi diversi. I dati arrivano tramite posta elettronica, sondaggi, moduli Web e altri meccanismi di raccolta dei dati. La disponibilità di dati, di solito, è una buona

cosa. Tuttavia, la gestione di una pletora di strumenti di raccolta dei dati e di tutte le informazioni più disparate è un compito complesso. L'integrazione affidabile e la condivisione protetta dei dati sono delle sfide costanti per le organizzazioni IT. Le architetture standard e orientate ai servizi si evolvono e consentono ai professionisti IT di rendere i dati più accessibili, in modo più protetto. Ma se da un lato sono disponibili tutti gli strumenti e le tecnologie necessarie per creare un'architettura aziendale efficiente, è fin troppo facile restare imprigionati in una selva di interfacce proprietarie, con la conseguente produzione di soluzioni isolate.

Le tecnologie disponibili in Microsoft® Office System sono un valido esempio. È possibile creare rapidamente un sondaggio in un reparto basato su Windows® SharePoint® Services 3.0, ma se questo poi diventa una soluzione standard dipende solo dall'organizzazione. Se l'azienda utilizza ASP.NET e SharePoint come piattaforma per l'integrazione di collaborazione basata sul Web e dati, il sondaggio costituisce una soluzione standard. Se invece l'ambiente somiglia a quello in cui lavoro io, SharePoint è solo una delle tante piattaforme.

SharePoint è dotato di molte opzioni per l'integrazione con sistemi quali IBM, HP, Siebel e così via. Questa è un'ottima notizia per gli utenti avanzati che vogliono creare soluzioni ad hoc e ricevono ancora flussi di dati in una varietà di sistemi back-end. Tuttavia, per gli architetti di soluzioni esiste una soluzione ancora migliore: InfoPath ® 2007.

Con InfoPath 2007, che è parte di Office System 2007, è possibile separare la logica di presentazione delle soluzioni dalla logica di gestione delle informazioni ospitata sui server. Con la tecnologia di InfoPath basata su XML, si possono creare soluzioni di raccolta dei dati su misura per l'azienda. In genere, inoltre, chi si occupa di progettare i moduli di InfoPath non deve necessariamente conoscere a fondo il linguaggio XML, i servizi Web, le architetture delle soluzioni, ASP.NET o il modello a oggetti di SharePoint.

In questo articolo si illustrerà la creazione di soluzioni di raccolta dei dati flessibili con InfoPath 2007, Office SharePoint Server 2007 e Forms Services. Si dimostrerà inoltre come XML consenta di separare la logica di presentazione dalla logica aziendale in un'architettura aziendale multilivello.

Quando si parla di "raccolta dei dati", si fa riferimento al processo di raccolta delle informazioni da fonti umane. Esistono, ovviamente, altri metodi per raccogliere i dati, come eseguire ricerche nelle origini dati, ma i metodi automatici non sono tra gli argomenti dell'articolo.

Acquisizione e gestione dei dati

I requisiti di acquisizione dei dati possono essere complessi, ma i processi hanno alcune cose in comune. Se si sfruttano le somiglianze con moduli centralizzati gestendo i requisiti univoci in componenti decentralizzati, è possibile limitare il lavoro ridondante, una manutenzione eccessiva e il costo totale di proprietà.

La conformità alle normative, ad esempio, per le aziende pubbliche producono dei requisiti aziendali che si traducono a propria volta in criteri di gestione delle informazioni nell'intera azienda. I criteri influiscono sulle soluzioni di raccolta dei dati nei diversi reparti e conducono spesso a una duplicazione del lavoro all'interno dei singoli reparti. Ne sono un esempio le normative per la raccolta di informazioni personalmente identificabili da parte di un ufficio del personale (con la gestione delle informazioni sui dipendenti) e di un reparto di assistenza ai clienti (con la gestione delle informazioni sui clienti). Anche i processi aziendali tra i singoli reparti che sono simili, ma non correlati, rappresentano un'opportunità per unificare le soluzioni di gestione delle informazioni.

Nella Figura 1 viene illustrato un esempio di processo aziendale tipico. Un dipendente che intende scambiare un incarico con un collega deve ottenere prima un consenso dal collega, quindi l'approvazione da un responsabile o coordinatore della pianificazione dell'incarico e, infine, dal supervisore. Lo scambio potrebbe comportare, ad esempio, un cambiamento nei turni di lavoro. Anche se questi scambi si verificano in reparti diversi e potrebbero prevedere l'impiego di moduli diversi, la logica dei flussi di lavoro e della gestione delle informazioni può essere condivisa fra le varie soluzioni dei reparti.

Figura 1** Processo di esempio di raccolta dei dati che può essere condiviso fra i reparti **(Fare clic sull'immagine per ingrandirla)

Il consolidamento dei componenti ridondanti è, naturalmente, un'attività molto impegnativa. Apportare delle modifiche di carattere organizzativo nell'intera azienda non è facile, ma con le tecnologie di Office System è possibile gettare delle fondamenta solide per le modifiche. InfoPath 2007 consenti ai singoli reparti di creare applicazioni a moduli che si integrano con i sistemi di gestione delle informazioni centralizzati e standardizzati,. SharePoint 2007, nel frattempo, consente ai reparti IT di delegare il controllo amministrativo su raccolte di siti, siti e raccolte documenti ai singoli reparti e team. Di conseguenza, i team possono creare e distribuire le proprie soluzioni con un coinvolgimento minimo del reparto IT, a cui resta la responsabilità del controllo di tutti i servizi e componenti condivisi, come i flussi di lavoro, i criteri di gestione delle informazioni e le procedure di backup.

Centralizzazione del lavoro di raccolta dei dati

Le aziende spesso affidano ai team dei server applicazioni dipartimentali per soddisfare le esigenze particolari di gestione delle informazioni. Al reparto IT viene semplicemente attribuita la responsabilità del corretto funzionamento di hardware e sistema operativo, mentre i singoli reparti si occupano di tutti gli altri aspetti delle soluzioni personalizzate. La coordinazione tra i reparti è scarsa e la condivisione delle informazioni è difficile.

Le sfide tecniche per la centralizzazione del lavoro di raccolta dei dati riguardano principalmente la protezione, le prestazioni, la manutenzione e il supporto dei componenti personalizzati ospitati in un ambiente condiviso. Gli effetti di un componente che non funziona, ad esempio, restano isolati quando le singole soluzioni sono ospitate sui server applicazioni dipartimentali. In un ambiente condiviso, tuttavia, un componente che non funziona può coinvolgere i processi aziendali su una scala molto più ampia. Ne consegue che il reparto IT deve stabilire dei criteri rigorosi sulla distribuzione e manutenzione dei componenti personalizzati nei sistemi centralizzati.

Per ospitare le soluzioni SharePoint dipartimentali in una server farm centralizzata, è necessario distribuire e gestire tutti i componenti personalizzati delle soluzioni dipartimentali sui server applicazioni centralizzati. Una possibile soluzione si basa sui tipi di campo personalizzati, per estendere l'interfaccia utente della soluzione con elenchi a discesa precompilati dai servizi Web back-end. Un'altra possibile soluzione si basa, allo stesso scopo, sulle Web part mentre un'altra ancora prevede l'utilizzo dei flussi di lavoro personalizzati. Tutte le soluzioni sono comunque scritte in codice gestito e distribuite come assembly di Microsoft .NET Framework.

Lo spostamento anche di un numero relativamente ridotto di soluzioni SharePoint a una server farm applicazioni centralizzata può implicare difficoltà di configurazione e problemi di supporto. Se gli assembly devono essere distribuiti nella Cache di assembly globale (GAC), la protezione diventa un problema perché gli assembly vengono eseguiti con attendibilità totale. I componenti programmati in modo non ottimale potrebbero esporre il sistema ad attacchi intrusivi nel codice SQL, attacchi con script da altri siti o attacchi Denial of Service. È necessario verificare che i componenti possano sostenere il carico di lavoro tipico, oltre ai picchi di richieste e alle operazioni a esecuzione prolungata. È inoltre necessario verificare che i componenti non blocchino altri processi, gestendo gli eventi in modo sincrono, e che i componenti eseguano convalide degli input affidabili. In tal modo si impedirà agli utenti di inserire istruzioni SQL o script nelle colonne utilizzate per aggiornare un database o un sistema Web remoto.

In breve, lo scopo è enfatizzare una configurazione protetta e scalabile dei server basata su funzionalità di prodotto standard. L'adozione di soluzioni riutilizzabili e testate a fondo consente di evitare la trappola rappresentata dalla creazione di troppi componenti personalizzati. È utile decentrare il front-end e centralizzare il back-end. La chiave è l'integrazione dei componenti in associazioni non rigide, in modo da promuovere il riutilizzo delle soluzioni esistenti

Divisione della logica aziendale

Come è quindi possibile creare soluzioni di raccolta dei dati flessibili, che possano essere configurate sui server? La strategia migliore consiste nel separare l'architettura della soluzione in singoli livelli come illustrato nella Figura 2: archiviazione dei dati, logica aziendale e presentazione o interfaccia utente. Oggi l'interfaccia utente è in genere basata sul browser, mentre la logica aziendale risiede sui server delle applicazioni Web. I server, a propria volta, accedono a database e archivi di dati non relazionali.

Figura 2** Una soluzione aziendale tipica creata su un'architettura a tre livelli **(Fare clic sull'immagine per ingrandirla)

La logica aziendale comprende spesso la logica di transazione, per garantire che le transazioni vengano applicate automaticamente ai sistemi di gestione dei database. La logica aziendale può comprendere anche più servizi di livello intermedio tramite HTTP, code dei messaggi, RPC e così via. L'architettura complessiva della soluzione, tuttavia, resta sostanzialmente un modello a tre livelli.

Ciò che nella Figura 2 non viene illustrato, è la complessità della logica aziendale nell'ambiente di una grande azienda. Sembra che il server applicazioni in questa figura si limiti a eseguire il rendering di un modulo basato su browser e a gestire i dati inviati; ma la rappresentazione non tiene conto dei requisiti di flussi di lavoro, conformità o gestione delle informazioni. Per rispondere a questi requisiti, è necessario dividere la logica aziendale in due: logica di presentazione e logica di gestione delle informazioni. La divisione consente di combinare e associare i componenti di livello intermedio in base alle esigenze, senza ricreare i componenti da capo per ciascuna soluzione.

Nella Figura 3 è illustrata questa architettura. In definitiva il contenuto, nel corso del suo ciclo di vita, viene governato dai dati, racchiusi nella logica di gestione delle informazioni. La logica di presentazione si interfaccia alla logica di gestione delle informazioni per garantire l'accesso ai dati tramite l'interfaccia utente.

Figura 3** Separazione della logica di presentazione dalla logica di gestione delle informazioni **

Raccolta ed elaborazione di XML

Negli ambienti delle applicazioni orientate ai servizi (SOA), XML è lo standard dominante utilizzato per la definizione e condivisione di dati e strutture di dati tra i componenti. XML, quindi, rappresenta un'ottima interfaccia tra i componenti di presentazione e di gestione delle informazioni.

La comunicazione deve muoversi in due direzioni: è necessario tradurre il codice XML in un documento leggibile dai browser, oltre che in un documento XML generato dal modulo. Fino a qualche tempo fa, per la creazione di applicazioni a moduli basate su XML erano necessarie competenze approfondite nel campo della programmazione. Questo era particolarmente vero quando i dati XML risultanti dovevano aderire a uno schema di settore per facilitare lo scambio di informazioni tra le organizzazioni.

InfoPath 2007 semplifica di molto lo sviluppo di moduli basati su XML. Certo una buona conoscenza dei dettagli dell'XML resta utile, ma progettisti e utenti esperti non devono essere maghi dell'XML per creare delle applicazioni con moduli basati su XML. Chi progetta il modulo deve semplicemente importare uno documento XML o uno schema XML in InfoPath e associare i singoli nodi di attributi ed elementi dell'origine dei dati e dei campi del modello. Il progettista inoltre può assumere come punto di partenza un servizio Web o un database di SQL Server® oppure un modello vuoto e creare un modulo da zero mentre InfoPath crea automaticamente lo schema sottostante e le associazioni di dati in background.

La standardizzazione dei moduli con gli schemi InfoPath e XML offre molti vantaggi. Quando è già disponibile uno schema XML ben definito, chi progetta i moduli e sviluppa flussi di lavoro e componenti di gestione delle informazioni ha la possibilità di creare delle soluzioni a fronte delle stesse strutture di dati. Se un progettista di moduli inizia da zero, gli sviluppatori devono restare in attesa del modulo definitivo prima di poter valutare in che modo questo influisca sulle strutture di dati sottostanti. Una volta definite le strutture di dati, inoltre, per le soluzioni future, come i nuovi modelli di moduli, si potranno riutilizzare i flussi di lavoro e i componenti di gestione delle informazioni esistenti che poggiano sulle medesime strutture di dati. I flussi di lavoro e i componenti di gestione delle informazioni futuri si integreranno ai moduli e ai dati esistenti. Se si creano le soluzioni di raccolta dei dati in base a schemi standard del settore, i risultati diventano ancora più flessibili. Infatti, le soluzioni saranno compatibili con le soluzioni create da altre aziende che utilizzano gli stessi schemi.

Ho creato un semplice schema DirectReports, che associa i dipendenti ai responsabili. Questi ultimi possono utilizzare il modulo che ne risulta per valutare i report diretti. Lo schema, il modulo e il file readme.htm con le istruzioni per ricreare il modulo nella cartella Direct Reports sono disponibili nel download che accompagna l'articolo, all'indirizzo technetmagazine.com/code08.aspx. Il modulo è molto semplice, ma illustra il concetto generale.

Un punto molto importante è il seguente: Non ho creato alcuna logica di convalida in InfoPath, anche se InfoPath richiede che ID utente e indirizzi di posta elettronica vengano immessi in un formato specifico (dominio\account e destinatario@dominio.tld). In caso contrario, il documento di XML che ne risulta non è valido. Ciò accade perché lo schema XML definisce questi formati. È possibile salvare il modulo con dei dati non validi, ma non è possibile inviarlo, come illustrato nella Figura 4. Al modulo è stata aggiunta una regola di invio fittizia, in modo che si possa verificare questo comportamento senza inviare effettivamente i dati ad altre posizioni. La convalida di InfoPath 2007 garantisce automaticamente che il modulo venga compilato in modo completo, senza errori di sorta.

Figura 4a** Un modulo con errori di convalida non può essere inviato **(Fare clic sull'immagine per ingrandirla)

Figura 4b** Il messaggio di errore generato **(Fare clic sull'immagine per ingrandirla)

Lo schema XML ha la funzione di contratto di associazione tra la logica di presentazione e la logica di gestione delle informazioni. InfoPath blocca lo schema, in modo che il progettista di moduli non possa modificare le strutture di dati. Si tratta di una funzionalità importante, perché la modifica di uno schema XML prestabilito può provocare problemi alle soluzioni aziendali esistenti, come i moduli del flusso di lavoro che si intende utilizzare in combinazione con il nuovo modello di modulo.

InfoPath è dotato di molte funzionalità utili per l'implementazione di una logica di presentazione avanzata nelle applicazioni con moduli. È possibile utilizzare dati da file XML, servizi Web, raccolte ed elenchi SharePoint, database e così via per incorporare i valori predefiniti significativi. È possibile modificare i valori dei campi in base alle selezioni degli utenti utilizzando delle regole, implementare una logica di convalida, aggiungere codice gestito per i requisiti di personalizzazione più avanzati e utilizzare Forms Service per rendere il modello di modulo accessibile sul Web. In ogni caso i dati del modulo raggiungono alla fine la logica di gestione delle informazioni come documento XML conforme a una definizione dello schema.

Utilizzo di XML o metadati

È lecito a questo punto chiedersi se è preferibile applicare la logica di gestione delle informazioni direttamente al documento XML inviato oppure utilizzare un parser che estrae le informazioni richieste nei metadati. SharePoint supporta entrambi gli approcci. Gli sviluppatori sono abituati a lavorare direttamente sui documenti XML, ma i metadati offrono una maggiore flessibilità.

A fini dimostrativi, è stato creato un semplice servizio Web che analizza un documento XML passato dal modulo Direct Reports illustrato nella Figura 4a (il codice sorgente, i file di installazione ed un file readme.htm con le istruzioni dettagliate sono disponibili nella cartella XMLParsingWebService del download). Il servizio Web si limita a leggere l'ID utente del responsabile dal documento XML, dividere l'ID utente nelle parti di dominio e nome utente, creare un messaggio basato su tali parti e generare un'eccezione generica per restituire e visualizzare le informazioni elaborate nel modulo di uno pseudomessaggio di errore nel modulo InfoPath. Questo è un semplice modo per far apparire una finestra di dialogo in InfoPath dopo l'invio dei dati. Il servizio Web funziona bene, ma se si modifica l'origine dati sottostante (ad esempio, rinominando l'elemento OrgPerson come Manager in DirectReports.xsd e aggiornando il modulo InfoPath con il nuovo schema come delineato nel file readme.htm) si verifica un errore. Questo non deve sorprendere. Il documento XML ora è diverso e l'espressione XPath precedente per l'accesso all'elemento dell'ID utente non è valido. Gli schemi OrgPerson e Manager sono quasi identici, i moduli InfoPath sono identici e i risultati di elaborazione desiderati sono gli stessi ma, sebbene le differenze siano minime, resta necessario distribuire e gestire servizi Web duplicati.

Non è un buon approccio se si desidera minimizzare l'impatto in termini di codice personalizzato sui server applicazioni. Al contrario, se si associano i nodi XML ai campi di metadati e si esegue l'elaborazione in base ai metadati, è possibile utilizzare gli stessi flussi di lavoro e logica di gestione delle informazioni per strutture di dati simili, anche se gli schemi XML differiscono. Per riutilizzare il codice esistente, è sufficiente verificare che l'elemento figlio venga associato al campo di metadati corretto e che il formato dei dati soddisfi i requisiti di elaborazione.

L'associazione dei nodi XML ai campi di metadati è un'operazione simile all'associazione dei nodi XML ai controlli dell'interfaccia utente in un formato InfoPath, come illustrato nella Figura 5. In SharePoint i campi di metadati corrispondono a colonne definite a livello di sito o elenco e a cui si fa riferimento nelle definizioni di tipo di contenuto. I tipi di contenuto definiscono le caratteristiche degli elementi di contenuto, come i campi di metadati, i flussi di lavoro e i moduli. Per tenere sincronizzati i campi di metadati di un tipo di contenuto con i nodi corrispondenti nel documento XML associato, SharePoint utilizza un parser XML incorporato che esegue la promozione e il declassamento delle proprietà. Durante la promozione delle proprietà, il parser XML estrae i valori del nodo da un documento XML nelle colonne corrispondenti della raccolta documenti. Il declassamento delle proprietà si riferisce al processo inverso, con i valori delle colonne che vengono prelevati dalla raccolta documenti e scritti nel documento. Il punto più importante è la capacità del parser XML di tenere sincronizzati i campi di metadati e i nodi XML associati.

Figura 5** Associazioni dello schema di XML tra InfoPath e SharePoint **(Fare clic sull'immagine per ingrandirla)

Quando si utilizza il modello a oggetti SharePoint, le web part, i flussi di lavoro e la logica di gestione delle informazioni corrispondente possono essere utilizzati sia con i campi di metadati che con i documenti XML sottostanti. La modifica del valore di un campo di metadati associato comporta la modifica del valore del nodo nel documento XML e viceversa. Quando si lavora direttamente con il documento XML, si correla in modo stretto la logica aziendale allo schema XML. I campi di metadati associati, d'altra parte, fanno aumentare il tasso di riutilizzabilità del codice. È quindi necessario individuare l'approccio più adatto al proprio ambiente, ma in generale le soluzioni SharePoint basate sui campi di metadati garantiscono maggiore flessibilità e maggiori opportunità di riutilizzo del codice.

Per illustrare il meccanismo di associazione dei nodi XML ai campi di metadati in SharePoint, nel materiale di esempio è stato inclusa una funzionalità SharePoint per fornire dati a una raccolta documenti personalizzata (vedere il file OrgPersonContentType.xml che si trova nella cartella OrgPersonLib del download). Il tipo di contenuto OrgPerson fa riferimento a quattro campi: UserID, FullName, EMail e Direct_x0020_Reports. FullName ed EMail sono campi incorporati. UserID and Direct_x0020_Reports sono campi personalizzati definiti in OrgPersonSiteColumns.xml.

Le definizioni dei campi sono relativamente semplici. È possibile associare i campi ai nodi XML direttamente nelle definizioni dei campi, come è d'altra parte possibile sovrascrivere queste informazioni nei tipi di contenuto. Si è deciso di utilizzare quest'ultima tecnica perché in tal modo è possibile utilizzare i campi personalizzati in tipi di contenuto non correlati a documenti XML, oltre che in tipi di contenuto basati su strutture XML diverse. Il tipo di contenuto OrgPerson associa i campi di metadati ai nodi XML che corrispondono, come disposizione, allo schema OrgPerson illustrato in precedenza. Esiste anche un file AdditionalContentTypes.xml che definisce altri tipi di contenuto che associano gli stessi campi di metadati a nodi XML diversi. È possibile notare le differenze esaminando le espressioni XPath negli attributi Node.

Nelle raccolte documenti del tipo OrgPersonLib è possibile archiviare tipi diversi di documenti XML, mentre i valori del nodo vengono esposti tramite le stesse colonne delle raccolte. Questa semplice tecnica di associazione consente inoltre di riutilizzare i flussi di lavoro e la logica di gestione delle informazioni, poiché i quattro tipi di contenuto (OrgPerson, Manager, Supervisor e User) fanno riferimento a una serie comune di campi di metadati.

Nella Figura 6 viene illustrato l'elemento FieldRef dal tipo di contenuto OrgPerson per Direct_x0020_Reports, che associa il campo ai nodi dell'ID utente dei report diretti in base all'espressione XPath, /OrgPerson/direct-report/user-id. Poiché il documento XML può contenere più voci di report diretti, è importante specificare un attributo Aggregation, che definisce la modalità di gestione dell'insieme di valori da parte del parser XML. Se si omette l'attributo, il parser XML estrae solo il primo valore del nodo. I valori di aggregazione supportati sono somma, conteggi, media, minimo, massimo, testo normale, primo e ultimo.

Figura 6** Campo di metadati associato a un'espressione XPath **(Fare clic sull'immagine per ingrandirla)

Tutti i tipi di contenuto dell'esempio utilizzano la pagina upload.aspx standard come DocumentTemplate, in modo che si possano caricare i file XML nella raccolta documenti con un clic sul pulsante Nuovo nell'interfaccia utente di SharePoint. Fino a che si caricano file con un'estensione .xml, SharePoint chiama automaticamente il parser XML incorporato (un'eccezione è rappresentata dai file WordProcessingML, per cui SharePoint chiama un parser WordProcessingML). Il parser XML esamina il file .xml caricato per determinare il tipo di contenuto associato. L'operazione è congegnata in modo che vengano estratti i valori del nodo dalle posizioni specificate nelle definizioni del campo ed eseguita la promozione delle proprietà. È possibile verificare il processo quando si carica il file OrgPerson.xml contenuto nella cartella OrgPersonLib\XMLFiles. La struttura di questo documento XML corrisponde alle espressioni XPath specificate nella definizione di tipo di contenuto OrgPerson. Di conseguenza, SharePoint estrae i dati dal file .xml, scrive i dati nelle colonne della raccolta corrispondenti e riporta i dati nella pagina EditForm.aspx, in modo che si possano verificare e aggiornare le proprietà del documento non contrassegnate come di sola lettura. Nella Figura 7 viene illustrato il modulo EditForm.aspx con i dati estratti da OrgPerson.xml.

Figura 7** Modulo EditForm.aspx con i dati estratti **(Fare clic sull'immagine per ingrandirla)

Se in EditForm.aspx si modificano i valori di User ID, Full Name o E-Mail, SharePoint esegue il declassamento delle proprietà per modificare i valori del nodo nel documento XML sottostante. Tuttavia, SharePoint non applica le restrizioni dello schema XML, a meno che nel modulo non si implementi la logica necessaria.

SharePoint inoltre non esegue la logica di presentazione di un'applicazione a moduli. Quando, ad esempio, si modifica il valore di User ID, SharePoint non verifica se il nuovo valore è conforme alle convenzioni NetBIOS e non aggiorna automaticamente i campi Full Name ed E-Mail in modo che corrispondano alla nuova selezione. Quando la modifica di un singolo campo può causare l'introduzione di incoerenze, è quindi necessario contrassegnare come di sola lettura la colonna corrispondente nella definizione di tipo di contenuto. In tal modo si obbliga l'utente a utilizzare l'applicazione a moduli, come InfoPath, per aggiornare i dati. Il parser XML, inoltre, promuoverà le eventuali modifiche dal documento XML ai campi di metadati corrispondenti in SharePoint.

Nell'esempio OrgPersonLib è possibile caricare uno qualsiasi dei file .xml dalla cartella OrgPersonLib\XMLFiles. I file .xml utilizzano strutture di dati molto diverse, ma SharePoint riconosce i tipi di contenuto e promuove i valori del nodo corretti nelle colonne del sito. Questo accade perché nei file XML è stata utilizzata un'istruzione di elaborazione per associare i documenti XML con i tipi di contenuto corrispondenti. Il file OrgPerson.xml, tuttavia, non contiene queste informazioni, ma ciò non costituisce un problema. Se non può associare un documento XML a un tipo di contenuto tramite un'istruzione di elaborazione o il modello del documento, SharePoint utilizza il tipo di contenuto predefinito. Nel caso di OrgPersonLib, questo corrisponde al tipo di contenuto OrgPerson e, quindi, il documento XML viene analizzato in modo corretto.

Nella Figura 8 si illustra come sia possibile associare esplicitamente un documento XML a un tipo di contenuto. L'istruzione di elaborazione MicrosoftWindowsSharePointServices definisce il ContentTypeID come 0x010100668E393E4F0EFF4294DBD202D5D8321D. Questo è l'ID del tipo di contenuto User, come definito in AdditionalContentTypes.xml.

Figura 8** Istruzioni di elaborazione e dati XML del file di esempio user.xml **(Fare clic sull'immagine per ingrandirla)

Il parser XML elabora l'istruzione MicrosoftWindowsSharePointServices e scrive il valore di ContentTypeID nel campo di metadati ContentType. Tutto i tipi di contenuto SharePoint condividono questo campo di metadati, perché è definito a livello di radice nel tipo di contenuto System. Se si apre il file fieldswss.xml su un server SharePoint (nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields) e si cerca MicrosoftWindowsSharePointServices, si noterà come SharePoint associ l'istruzione di elaborazione al campo ContentType. L'attributo PITarget punta verso MicrosoftWindowsSharePointServices (questa è l'istruzione di elaborazione) e i punti PIAttribute verso ContentTypeID (che contiene l'ID del tipo di contenuto User).

Associazioni del tipo di contenuto in InfoPath

Molti progettisti di moduli trovano molto complessi i dettagli tecnici dell'analisi XML e dell'associazione dei tipi di contenuto, ma InfoPath 2007 si occupa direttamente di tutta la parte essenzialmente tecnica. Il file readme.htm fornito con l'esempio OrgPersonLib contiene le istruzioni per la pubblicazione del modello di modulo Direct Reports in SharePoint e la creazione di un tipo di contenuto che venga associato di nuovo agli stessi campi di metadati (UserID, FullName, EMail e Direct_x0020_Reports). È possibile aggiungere facilmente il nuovo tipo di contenuto alla raccolta documenti di OrgPersonLib nell'interfaccia utente di SharePoint. Ma il nuovo tipo di contenuto punta anche verso il modello di modulo InfoPath come modello di documento, per chiamare l'applicazione a moduli quando si aggiornano i documenti XML esistenti. Nella Figura 9 viene illustrato come Pubblicazione guidata di InfoPath semplifichi l'associazione delle proprietà tra i valori del nodo XML e le colonne del sito SharePoint. Anche in questo caso, se si associano i valori del nodo con le colonne del sito esistenti, sarà possibile riutilizzare i componenti SharePoint esistenti.

Figura 9** Associazione delle proprietà in InfoPath 2007 **(Fare clic sull'immagine per ingrandirla)

Conclusioni

Risorse aggiuntive in linea

• Il blog del team di InfoPath 2007
• Specifiche W3C e sviluppo degli schemi XML
• Introduzione agli schemi XML
• Flussi di lavoro in Office SharePoint Server 2007
• InfoPath 2007 Forms Services

Con le tecnologie disponibili in Office, gli architetti aziendali possono creare soluzioni di raccolta dei dati che promuovano il riutilizzo del codice e lo scambio di informazioni. InfoPath 2007 consente ai singoli reparti di creare soluzioni in grado di estrarre dati da varie fonti e di inviare quindi i dati a diversi sistemi, come SharePoint. SharePoint inoltre fornisce agli sviluppatori una serie completa di servizi e interfacce Web per la creazione di flussi di lavoro e componenti di gestione delle informazioni. Se ospitano questi componenti su server SharePoint centralizzati, i reparti ottengono l'infrastruttura necessaria per creare le applicazioni personalizzate.

Inoltre i singoli reparti possono creare in modo più rapido soluzioni di raccolta dei dati personalizzate. È infine possibile soddisfare le esigenze di conformità alle normative e di altri requisiti aziendali a livello interdipartimentale, con un significativo incremento della gestibilità e affidabilità dell'ambiente IT grazie all'uso di meno componenti personalizzati sui server applicazioni.

Keith Deshaiesè un technical writer professionista e un analista informatico per una grande azienda di telecomunicazioni. Si è specializzato nelle tecnologie di Microsoft Office e SharePoint ed è membro della Society for Technical Communications.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.