SharePoint

Standardizzazione della gestione dei dati con tipi di contenuto personalizzati

Pav Cherny

 

Panoramica:

  • Gestione del ciclo di vita del contenuto con SharePoint
  • Creazione di riquadri informazioni documento
  • Modifica dei documenti di Office e SharePoint tramite InfoPath

Scarica il codice per questo articolo: ContentTypes2008_02.exe (779KB)

L'elevata quantità di documenti e altri elementi di contenuti disponibili in genere all'interno di un ambiente aziendale crea diverse problematiche di carattere tecnico per la gestione centralizzata e riutilizzabile dei documenti,

dei metadati associati e delle relative caratteristiche. Microsoft® Office SharePoint® Server 2007 promuove la collaborazione aziendale consentendo ai diversi team all'interno di un'organizzazione di condividere aree di lavoro in siti Web, raccolte documenti ed elenchi.

SharePoint 2007 consente di standardizzare molti aspetti delle caratteristiche del contenuto e del ciclo di vita tramite i tipi di contenuto. I tipi di contenuto del sito sono definizioni di metadati che è possibile stabilire indipendentemente da raccolte siti, siti, elenchi o raccolte documenti specifiche. Questo consente di stabilire in modo coerente le proprietà, i flussi di lavoro, i criteri di gestione delle informazioni e altri elementi all'interno dell'azienda e offre ai singoli reparti o ai proprietari del sito la possibilità di personalizzare i tipi di contenuto per scopi specifici.

In questo articolo verrà illustrato come utilizzare il nuovo modello di contenuto SharePoint introdotto con Windows® SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 per creare gerarchie per il contenuto aziendale in base a caratteristiche generali. Queste gerarchie di contenuti consentono un'applicazione uniforme dei metadati, dei flussi di lavoro e dei criteri di gestione delle informazioni a livello globale, garantendo nel contempo la flessibilità necessaria per soddisfare specifiche esigenze di gestione dei contenuti a livello di raccolta siti, sito, raccolta documenti ed elenco.

Per illustrare alcuni degli aspetti basilari dei tipi di contenuto di SharePoint, nel materiale allegato al presente articolo sono stati inclusi una serie di strumenti personalizzati e il codice sorgente nel caso in cui si desideri estendere questi strumenti in base alle specifiche esigenze. Tenere presente che questi strumenti non sono stati sottoposti a test completi e non devono essere utilizzati in un sistema di produzione. È possibile scaricare il codice dal sito Web di TechNet Magazine all'indirizzo technetmagazine.com/code08.aspx.

Ciclo di vita del contenuto e definizioni dei tipi di contenuto

Risorse di SharePoint

Occorre prendere in considerazione molti dettagli durante la gestione di documenti e altri contenuti in un'organizzazione. In particolare, è necessario definire la persona o il processo che deve eseguire una specifica azione durante la creazione, la pubblicazione, l'archiviazione e l'eliminazione del contenuto. Inoltre, si rende spesso necessario per un'organizzazione sviluppare specifici modelli per la creazione del contenuto, definire ruoli per assegnare responsabilità e privilegi di accesso agli utenti, fornire il controllo delle versioni, monitorare la conformità, archiviare dati, definire i metadati e così via.

Per quanto complesso possa essere uno specifico ciclo di vita del contenuto, il modello di contenuto SharePoint stabilisce che esistono alcune caratteristiche generali e fasi tipiche che determinano la modalità di gestione dei singoli elementi di contenuto. È possibile, ad esempio, strutturare sia la creazione del contenuto attraverso modelli e moduli di input che la visualizzazione e le ricerche del contenuto attraverso i metadati. È inoltre possibile utilizzare i requisiti di modifica, approvazione o altri requisiti del flusso del lavoro, i requisiti di archiviazione, le date di scadenza e i criteri di gestione delle informazioni applicabili per operare una distinzione tra i singoli elementi di contenuto. Alcuni contenuti potrebbero non richiedere modelli speciali o potrebbero non essere mai archiviati, ma anche queste sono caratteristiche del ciclo di vita che consentono di distinguere tali elementi da altri tipi di elementi.

Il modello di contenuto SharePoint consente di definire singoli tipi di contenuto e di stabilire relazioni gerarchiche. In una relazione gerarchica, gli elementi figlio ereditano caratteristiche generali dai tipi di contenuto padre, aggiungendo caratteristiche specifiche.

Il metodo migliore per illustrare questo concetto consiste nell'esaminare i tipi di contenuto incorporati di SharePoint. WSS 3.0 e MOSS 2007 includono una serie di tipi di contenuto predefiniti per elementi tipici che possono essere archiviati in una raccolta documenti o un elenco, compresi documenti e attività. È possibile trovare le definizioni di questi tipi di contenuto standard su un server SharePoint nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. In tale cartella è disponibile un file manifesto denominato feature.xml. Se si esamina questo file, si potrà osservare che SharePoint implementa le definizioni dei tipi di contenuto standard come caratteristiche nascoste (Hidden="TRUE") con un ambito di raccolta siti (Scope="Site") e che il file manifesto dell'elemento, che contiene gli elementi dei tipi di contenuto effettivi, è ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).

Per ulteriori informazioni sulle funzionalità di SharePoint, è consigliabile leggere l'articolo della serie Spazio Office di Ted Pattison in MSDN® Magazine intitolato "Funzionalità per SharePoint," disponibile all'indirizzo msdnmagazine.com/issues/07/05/OfficeSpace.

A questo punto, aprire il file ctypeswss.xml nel Blocco note per esaminare i tipi di contenuto standard, indipendentemente dalla relativa visibilità nell'interfaccia utente di SharePoint. È consigliabile non modificare ctypeswss.xml. Se si intende modificare ctypeswss.xml per aggiungere nuovi campi ai tipi di contenuto standard o rendere visibili i tipi di contenuto nascosti in modo che possa essere utilizzati dagli utenti di SharePoint per derivare nuovi tipi di contenuto, tenere presente che questa operazione non è in genere necessaria. Inoltre, un'operazione di questo tipo conduce a configurazioni non supportate ed è possibile che l'installazione in un momento successivo dei Service Pack sovrascriva le personalizzazioni effettuate e comprometta il funzionamento delle soluzioni di gestione dei contenuti.

Un approccio molto più efficace consiste nel copiare i dati necessari in un nuovo file manifesto dell'elemento, nell'aggiungere le personalizzazioni necessarie e nel distribuire i tipi di contenuto personalizzati come nuova caratteristica con un ambito di raccolta siti in modo che siano disponibili a tutti i siti all'interno della raccolta siti.

La definizione basata su CAML (Collaborative Application Markup Language) del tipo di contenuto System specificato in ctypeswss.xml è riportata di seguito:

<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>

Gli attributi Group e Sealed mostrano che il tipo di contenuto System viene nascosto e sottoposto a sealing in modo che non possa essere modificato nell'interfaccia utente di SharePoint. Il tipo di contenuto System dispone di un solo elemento FieldRef che fa riferimento a una colonna del sito incorporata denominata ContentType. Questo è il livello più elevato di astrazione. Tutti gli altri tipi di contenuto di SharePoint ereditano questa proprietà dal tipo di contenuto System. In tal modo, SharePoint assicura che tutti gli elementi di contenuto archiviati in qualsiasi raccolta documenti o elenco abbiano questa proprietà in comune.

Nella Figura 1 viene riportata una web part ContentTypeHierarchy, inclusa nel materiale che accompagna questo articolo, che illustra le gerarchie in modo più intuitivo. Il tipo di contenuto System è alla base di tutti gli altri tipi di contenuto, seguiti dal tipo di contenuto Item e così via. Il tipo di contenuto Item, ad esempio, stabilisce il livello di dettaglio successivo. Se si controlla il file ctypeswss.xml, è possibile osservare che Item definisce un singolo campo di metadati che fa riferimento a una colonna del siti denominata Title. In tal modo, tutti i tipi di contenuto incorporati ai livelli inferiori includono una proprietà Title.

Figura 1 Gerarchia dei tipi di contenuto incorporati di WSS 3.0

Figura 1** Gerarchia dei tipi di contenuto incorporati di WSS 3.0 **(Fare clic sull'immagine per ingrandirla)

È inoltre possibile rimuovere un campo ereditato, come dimostrato dalla definizione del tipo di contenuto Document nel file ctypeswss.xml. Il tipo di contenuto Document include diversi elementi RemoveFieldRef corrispondenti, ma potrebbe essere opportuno non rimuovere il campo Title nei tipi di contenuto personalizzati, in quanto la colonna Title fornisce l'accesso al menu a discesa ECB (Edit Control Box) nelle visualizzazioni raccolta documenti ed elenco di SharePoint.

Un esempio efficace in cui viene illustrato come rinominare i campi ereditati è rappresentato dal tipo di contenuto Far East Contact in ctypeswss.xml. Cercare 0x0116, ovvero l'ID del tipo di contenuto corrispondente, e selezionare l'elemento FieldRef con l'attributo Name="Title" per vedere come utilizzare l'attributo DisplayName per rinominare un campo nell'interfaccia utente. In questo specifico esempio, l'attributo DisplayName modifica il nome del campo Title nell'interfaccia utente in un valore di dati localizzato a cui fa riferimento "$Resources:core,Last_Name;".

Se si esamina in modo più approfondito la Figura 1, è possibile osservare che l'attributo ID dell'elemento ContentType identifica in modo univoco il tipo di contenuto e stabilisce la relazione gerarchica. Tutti gli ID iniziano con l'ID del tipo di contenuto padre ma con l'aggiunta di altri valori esadecimali. Ai tipi di contenuto standard in genere vengono aggiungi due valori esadecimali per creare un nuovo ID univoco per il tipo di contenuto figlio. Un'altra tecnica prevede l'aggiunta di "00" e di un GUID esadecimale. Questa tecnica viene utilizzata, ad esempio, per derivare i tipi di contenuto Office Data Connection File e Universal Data Connection File dal tipo di contenuto Document.

Un punto importante da tenere presente è che l'attributo ID dell'elemento ContentType non può essere composto da più di 1.024 caratteri. Questo può costituire un problema in una relazione gerarchica di grandi dimensioni quando tutti i tipi di contenuto utilizzano la tecnica del GUID esadecimale Tuttavia, non è consigliabile iniziare con la tecnica più breve in quanto questi ID potrebbero non essere univoci.

Per assicurare l'univocità, utilizzare la tecnica GUID in modo da stabilire uno spazio dei nomi globale per i tipi di contenuto aziendali e passare alla tecnica più breve all'interno dello spazio dei nomi in questione. Per informazioni dettagliate sull'attributo ID e su altri elementi delle definizioni dei tipi di contenuto, vedere l'argomento relativo allo schema delle definizioni dei tipi di contenuto nell'SDK di WSS 3.0.

Dipendenze dei tipi di contenuto

A questo punto, è opportuno affrontare la questione relativa all'utilizzo dei tipi di contenuto SharePoint per strutturare la gestione degli elementi di contenuto. È necessario prendere in considerazione diverse dipendenze, come le interdipendenze tra le raccolte documenti e gli elenchi, i tipi di contenuto, le colonne del sito e i tipi di campi. Le raccolte e gli elenchi fanno riferimento ai tipi di contenuto, che fanno riferimento alle colonne del sito, che a loro volta fanno riferimento ai tipi di campo (come i tipi di campi standard di WSS testo, nota, scelta, numero, valuta e così via), che a loro volta risiedono negli assembly Microsoft .NET Framework, come l'assembly di base di WSS Microsoft.SharePoint.dll.

A scopo esemplificativo, si esamini di nuovo il tipo di contenuto System illustrato in precedenza nella definizione CAML della voce del file manifesto dei tipi di contenuto System. Come descritto in precedenza, questo tipo di contenuto contiene un elemento FieldRef che fa riferimento a una colonna del sito denominata ContentType. Notare che la definizione del tipo di contenuto non definisce la colonna del sito ContentType effettiva. ContentType è un campo di testo, definito nel manifesto per gli elementi fieldswss.xml, situato nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. Il tipo di campo di testo viene definito in fldtypes.xml, disponibile nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Un punto importante relativo a questa struttura di dipendenze è che è necessario assicurarsi che tutte le risorse siano disponibili sui server SharePoint.

I tipi di contenuto che si desidera utilizzare devono essere creati a livello di sito delle raccolte documenti e degli elenchi o a un livello più elevato nella gerarchia dei siti. Analogamente, i campi di metadati dei tipi di contenuto devono fare riferimento alle colonne del sito esistenti. È possibile aggiungere ai tipi di contenuti colonne del sito standard o personalizzate in base ai tipi di campi standard o personalizzati, ma occorre assicurarsi che le colonne del sito siano disponibili nel sito locale. Inoltre, se si desidera utilizzare i tipi di campo personalizzati, è necessario assicurarsi che gli assembly .NET sottostanti vengano distribuiti sui server SharePoint.

Dipendenze simili esistono per i tipi di contenuto che fanno riferimento a modelli di documento, riceventi di eventi personalizzati, flussi di lavoro e altri componenti. La definizione del tipo di contenuto, ad esempio, può contenere un elemento DocumentTemplate che fa riferimento al modello di documento associato al tipo di contenuto. La definizione del tipo di contenuto può contenere anche un elemento XmlDocuments con uno o più elementi XmlDocument figlio che definiscono caratteristiche aggiuntive del tipo di contenuto, come definizioni di spazi dei nomi, definizioni dei riquadri informazioni documento o qualsiasi informazione personalizzata.

Determinazione dei tipi di contenuto globali

Gli utenti che dispongono di autorizzazioni di creazione possono creare nuovi tipi di contenuto e nuove colonne del sito direttamente nell'interfaccia utente di SharePoint, ma, in tal caso, i tipi di contenuto sono disponibili solo nel sito locale e ai velli inferiori della gerarchia dei siti. Le colonne del sito personalizzate sono disponibili solo nel sito locale. Questo rappresenta un problema se si desidera stabilire tipi di contenuto globali. È necessario assicurare che i tipi di contenuto globali siano disponibili in tutte le raccolte siti nell'ambiente in uso. È in tale contesto che le caratteristiche di SharePoint possono risultare utili. È piuttosto semplice installare e attivare le caratteristiche di SharePoint in più raccolte siti per applicare in modo coerente le definizioni delle colonne del sito e dei tipi di contenuto corrispondenti in tutte le posizioni.

Il materiale accluso a questo articolo include una caratteristica di esempio denominata AdventureWorks che dimostra come stabilire un tipo di contenuto globale. La caratteristica definisce un tipo di contenuto generale denominato Customer Documentation che può essere utilizzato per creare qualsiasi tipo di materiale per clienti, come proposte e lettere di vendita. È ragionevole presupporre che tutti i tipi di documenti debbano essere associati alle informazioni relative ai clienti, come nome della società, dettagli di contatto e indirizzo. A tal proposito, è stato creato un campo personalizzato denominato Customer Name per il tipo di contenuto e sono stati aggiunti alcuni campi incorporati, come Department e Primary Phone. È possibile modificare il tipo di contenuto e i campi modificando il file ContentTypes.xml e i riferimenti di campo modificando il file SiteColumns.xml disponibile nell'esempio accluso.

Se si distribuisce la caratteristica descritta nel file readme.htm, è possibile attivarla in modo coerente in più raccolte siti. Il tipo di contenuto Customer Documentation viene quindi reso disponibile a livello globale. In tal modo, i singoli reparti possono creare una documentazione specifica per i clienti tramite tipi di contenuto derivati associati ai modelli di documento di destinazione. Il materiale di accompagnamento include modelli di documento di esempio che possono essere utilizzati nelle attività di vendita e di consulenza. Nella Figura 2 vengono illustrati i tipi di contenuto risultanti.

Figura 2 Tipi di contenuto padre e figlio per la documentazione dei clienti

Figura 2** Tipi di contenuto padre e figlio per la documentazione dei clienti **(Fare clic sull'immagine per ingrandirla)

Sono disponibili diverse opzioni per la creazione delle caratteristiche per le colonne del sito e i tipi di contenuto personalizzati in WSS 3.0 e MOSS 2007. È possibile consultare l'SDK di WSS 3.0 e scrivere i file XML da zero. È inoltre possibile scegliere di utilizzare SharePoint Designer per esportare un elenco in un pacchetto Web personale, rinominare il file .fwp risultante in file .cab, estrarre il file manifest.xml dal file .cab e cercare le definizioni ContentType nel file manifest.xml. Sfortunatamente, entrambi gli approcci sono poco pratici e suscettibili di errore.

È molto più semplice invece creare tipi di contenuto e colonne del sito personalizzati nell'interfaccia utente di SharePoint. Tuttavia, l'interfaccia non fornisce un'opzione per modificare i file XML di una caratteristica. Le caratteristiche sono un metodo efficiente per eseguire il provisioning delle risorse SharePoint ma, una volta effettuato il provisioning, le risorse sono disponibili solo nel database del contenuto. Probabilmente una versione futura di WSS includerà la capacità di esportare colonne del sito e tipi di contenuto in file XML tramite l'interfaccia utente di SharePoint, simile all'esportazione di web part. Per ora, è necessario utilizzare le opzioni disponibili.

Il materiale di accompagnamento contiene una web part denominata ContentTypeSchema che può essere utilizzata come punto di partenza. Questa web part utilizza un modello a oggetti SharePoint per estrarre la proprietà SchemaXML dal tipo di contenuto selezionato. Tramite le trasformazioni basate su XSLT (eXtensible Stylesheet Language Transformation), la web part deriva le definizioni Field o le definizioni ContentType in base all'opzione selezionata nell'interfaccia utente prima di fare clic sul pulsante Display.

Nella Figura 3 viene illustrata la web part in azione. Nella figura viene visualizzato il tipo di contenuto Active Directory® Documentation, che è basato sul tipo di contenuto Customer Documentation. Il tipo di contenuto Active Directory Documentation è associato a un modello di Microsoft Word personalizzato (Active Directory Template.dot). Notare che questo tipo di contenuto non presenta campi aggiuntivi. Tutti i campi vengono ereditati dal tipo di contenuto padre.

Se si prevede di utilizzare la web part ContentTypeSchema nell'ambiente in uso, tenere presente che questa web part non è stata sottoposta a test completi. La web part illustrata in questo articolo utilizza trasformazioni XSL relativamente complesse per creare un delta tra la proprietà SchemaXML del tipo di contenuto correntemente selezionato e il tipo di contenuto padre corrispondente. Tuttavia, XSLT 1.0 non è progettato per conversioni di documenti XML avanzate. Non è disponibile alcuna funzionalità incorporata per il confronto dei nodi XML. Inoltre, gli spazi dei nomi XML e le sezioni CDATA pongono le difficoltà che XSLT 1.0 non è in grado di gestire in modo efficace.

SharePoint prevede l'archiviazione delle definizioni delle colonne del sito e dei tipi di contenuto del sito creati utilizzando l'interfaccia utente o il modello a oggetti di SharePoint nel database del contenuto in una tabella denominata ContentTypes. Nella Figura 3 viene illustrato l'ID del tipo di contenuto personalizzato. Di conseguenza, l'istruzione T-SQL riportata di seguito fornirà risultati esatti: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>.

Figura 3 Definizione del tipo di contenuto personalizzato in ContentTypeSchema Web part

Figura 3** Definizione del tipo di contenuto personalizzato in ContentTypeSchema Web part **(Fare clic sull'immagine per ingrandirla)

Indipendentemente dall'approccio che si decide di utilizzare, la creazione di caratteristiche per i tipi di contenuto aziendali è molto semplice una volta ottenute le definizioni dei tipi di contenuto e delle colonne del sito. È consigliabile utilizzare una singola caratteristica per tutte le colonne e i tipi di contenuto del sito globali del proprio reparto o azienda. In tal modo, sarà chiaro dove aggiungere nuove definizioni dei tipi di contenuto e delle colonne del sito.

Ricerche a livello di organizzazione in metadati personalizzati

Un vantaggio immediato delle gerarchie dei tipi di contenuto è che tutti i tipi di contenuto figlio ereditano i campi di metadati del tipo di contenuto padre. Poiché tutti i tipi di contenuto hanno campi di metadati in comune, è piuttosto semplice per gli utenti creare visualizzazioni personalizzate e filtri nelle raccolte documenti.

Questo viene dimostrato in modo piuttosto intuitivo dalla caratteristica di esempio AdventureWorks. Indipendentemente dal tipo di contenuto creato da un consulente o un responsabile commerciale, il salvataggio del documento di Word 2007 risultante nella raccolta documenti richiede l'impostazione di un Customer Name, in quanto il tipo di contenuto padre Customer Documentation definisce questo campo di metadati in base alle esigenze. Raggruppando o filtrando gli elementi in una visualizzazione raccolta documenti in base al Customer Name, i consulenti e i membri del team di vendita possono individuare tutta la documentazione esistente per un cliente in modo rapido e semplice, come illustrato nella Figura 4.

Figura 4 Raggruppamento di vari documenti in una raccolta in base a metadati comuni

Figura 4** Raggruppamento di vari documenti in una raccolta in base a metadati comuni **(Fare clic sull'immagine per ingrandirla)

Anche i metadati comuni semplificano l'individuazione del contenuto in più raccolte documenti e siti utilizzando le funzionalità di ricerca di WSS 3.0 e MOSS 2007. WSS supporta le ricerche in raccolte, elenchi e siti all'interno di una singola raccolta siti. MOSS 2007 va oltre queste funzionalità di base consentendo di implementare un Centro ricerche a livello aziendale e di gestire metadati personalizzati nell'interfaccia utente Amministrazione centrale di SharePoint 3.0. Per questo motivo, le spiegazioni riportate di seguito sono incentrate su MOSS 2007.

Quando si configura un provider di servizi condivisi (SPP) in MOSS 2007 e si esegue una ricerca per indicizzazione nei siti SharePoint, MOSS 2007 è in grado di individuare automaticamente i campi di metadati personalizzati utilizzati nelle origini di contenuto. Di conseguenza, è possibile trovare i campi di metadati personalizzati nell'elenco delle proprietà sottoposte a ricerca per indicizzazione.

I campi di metadati definiti nelle caratteristiche di SharePoint rientrano in genere nella categoria SharePoint. Per trovare la relativa posizione in Amministrazione centrale SharePoint nel menu Avvio veloce in Amministrazione servizi condivisi, fare clic sul collegamento a SSP, quindi su Impostazioni di ricerca e su Mapping di proprietà dei metadati, infine scegliere Proprietà sottoposte a ricerca per indicizzazione dal menu Avvio veloce e aprire la categoria SharePoint.

Di seguito viene illustrato un esempio pratico di questa procedura. Il campo di metadati Customer Name diventa una proprietà sottoposta a ricerca per indicizzazione denominata ows_Customer_x0020_Name. In SharePoint le proprietà sottoposte a ricerca per indicizzazione includono il prefisso "ows_", mentre "_x0020_" rappresenta la versione codificata di un singolo spazio. Se si visualizzano i dettagli di questa proprietà sottoposta a ricerca per indicizzazione, è possibile rilevare che tale proprietà viene inclusa nell'indice di ricerca per impostazione predefinita in modo che gli utenti possano impiegare i valori della proprietà sottoposta a ricerca per indicizzazione per eseguire ricerche di contenuto. Tuttavia, per ottenere una maggiore precisione della ricerca, è opportuno eseguire il mapping della proprietà sottoposta a ricerca per indicizzazione a una proprietà gestita in modo da consentire agli tenti di cercare esplicitamente il contenuto in base al nome del cliente.

Quando si esegue il mapping delle proprietà sottoposte a ricerca per indicizzazione alle proprietà gestite sono disponibili due opzioni. È possibile generare automaticamente una nuova proprietà gestita per ciascuna proprietà sottoposta a ricerca per indicizzazione o è possibile eseguire manualmente il mapping delle proprietà sottoposte a ricerca per indicizzazione alle proprietà gestite. La prima opzione è disponibile quando si visualizzano le impostazioni della categoria delle proprietà sottoposte a ricerca per indicizzazione desiderata (durante la visualizzazione delle proprietà sottoposte a ricerca per indicizzazione in una categoria, come la categoria SharePoint, fare clic sull'opzione Modifica categoria nel collegamento Avvio veloce). In Impostazioni generali proprietà sottoposte a ricerca per indicizzazione è necessario selezionare la casella di controllo "Genera automaticamente una nuova proprietà gestita per ogni proprietà sottoposta a ricerca per indicizzazione individuata in questa categoria". Tuttavia, in SharePoint le proprietà gestite vengono automaticamente precedute dal prefisso "ows" mentre gli spazi escape vengono preceduti dal prefisso "x0020". La proprietà gestita per la proprietà sottoposta a ricerca per indicizzazione ows_Customer_x0020_Name sarà owsCustomerx0020Name. Questo, tuttavia, non è un nome di proprietà particolarmente intuitivo per l'utente.

Probabilmente, una strategia più efficace consiste nell'eseguire manualmente il mapping delle proprietà sottoposte a ricerca per indicizzazione alle proprietà gestite dopo aver distribuito i tipi di contenuto aziendali. È possibile eseguire il mapping di una proprietà sottoposta a ricerca per indicizzazione a una o più proprietà gestite. Per creare nuove proprietà gestite, in Amministrazione centrale SharePoint nel menu Avvio veloce in Amministrazione servizi condivisi, fare clic sul collegamento a SSP, quindi su Impostazioni di ricerca, su Mapping di proprietà dei metadati e infine su Nuova proprietà gestita per specificare le informazioni necessarie e associare la nuova proprietà gestita alla proprietà sottoposta a ricerca per indicizzazione desiderata.

Gli utenti possono individuare gli elementi di contenuto rilevanti utilizzando le proprietà gestite nella sintassi proprietà: o utilizzando la ricerca avanzata. Se, ad esempio, si esegue il mapping della proprietà sottoposta a ricerca per indicizzazione ows_Customer_x0020_Name a una proprietà gestita denominata Customer, gli utenti possono cercare tutti i documenti di un cliente specificando semplicemente Customer: <Customer Name> nella casella di ricerca standard, come Customer: Contoso.

È consigliabile inoltre includere le proprietà gestite per i campi di metadati più importanti dei tipi di contenuto nell'elenco delle proprietà nella pagina Ricerca avanzata. A tal fine, visualizzare la pagina Ricerca avanzata, fare clic su Azioni sito e scegliere il comando Modifica pagina. Fare clic su Modifica in Casella di ricerca avanzata per selezionare l'opzione Modifica web part condivisa. Quando si espande la categoria Proprietà e si posiziona il cursore nel campo di testo corrispondente, è possibile fare clic sul pulsante per modificare il documento XML delle proprietà. È necessario aggiungere una definizione di proprietà all'elemento <PropertyDefs>, come <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>, nonché aggiungere un riferimento a questa definizione di proprietà in un elemento ResultType, ad esempio l'elemento <ResultType DisplayName="All Results" Name="default">, come <PropertyRef Name="Customer" />.Nella Figura 5a viene visualizzata l'interfaccia utente di Ricerca avanzata risultante. Nella Figura 5b vengono visualizzati i risultati della ricerca.

Figura 5a Ricerca nella documentazione dell'infrastruttura IT in base al nome del cliente

Figura 5a** Ricerca nella documentazione dell'infrastruttura IT in base al nome del cliente **(Fare clic sull'immagine per ingrandirla)

Figura 5b Risultati della ricerca in base al nome del cliente

Figura 5b** Risultati della ricerca in base al nome del cliente **(Fare clic sull'immagine per ingrandirla)

Garanzia della coerenza delle informazioni

A questo punto, i tipi di contenuto e i campi di metadati più importanti sono stati standardizzati e le funzionalità di ricerca nelle raccolte siti sono state estese nell'ambiente aziendale in base all'applicazione MOSS 2007. Ora è importante assicurare che gli utenti immettano informazioni accurate nei campi di metadati.

Sono disponibili due metodi per eseguire questa operazione. Primo, è possibile sostituire il riquadro informazioni documento standard nei modelli di documento con un modulo InfoPath® personalizzato che fornisce agli utenti una selezione predefinita di opzioni di input, come quelle disponibili in una casella di riepilogo. Secondo, è possibile associare un ricevente dell'evento al tipo di contenuto e controllare l'accuratezza dei metadati e di altre informazioni ogniqualvolta gli utenti creano, modificano o eliminano gli elementi di contenuto corrispondenti.

Entrambe le opzioni si completano a vicenda. Un modulo InfoPath fornisce principalmente un metodo conveniente per modificare le proprietà di un tipo di contenuto SharePoint, mentre un ricevente dell'evento può assicurare la validità dei metadati anche se gli utenti modificano le proprietà del tipo di contenuto all'esterno del modulo InfoPath. È possibile associare i gestori eventi a uno specifico tipo di contenuto, che consente di specificare gli eventi e le relative risposte per tutti i documenti associati a un singolo tipo di contenuto in tutte le raccolte siti, indipendentemente dalla raccolta documenti. Ulteriori informazioni su come sviluppare e distribuire i gestori eventi sono disponibili all'indirizzo msdn2.microsoft.com/ms453149.

Probabilmente un metodo più semplice per associare un tipo di contenuto a un riquadro informazioni documento personalizzato consiste nel visualizzare le impostazioni del riquadro informazioni documento del tipo di contenuto nell'interfaccia utente di SharePoint su un computer con InfoPath 2007 installato. È possibile fare clic sul collegamento Creare un nuovo modello personalizzato in Modello del riquadro informazioni documento per avviare InfoPath 2007 in modalità di progettazione. Tuttavia, se il tipo di contenuto del sito include colonne del sito senza un attributo SourceID esplicito, è possibile che si verifichi una situazione in cui InfoPath non è in grado di creare uno schema XSD valido per il modulo Riquadro informazioni documento. Ad esempio, il tipo di contenuto Customer Documentation introdotto in precedenza include diverse colonne specifiche dei contatti, come Department, Office ed e-mail, che possono causare questo problema, come illustrato nella Figura 6.

Figura 6 Incompatibilità tra gli schemi XSD in InfoPath 2007

Figura 6** Incompatibilità tra gli schemi XSD in InfoPath 2007 **(Fare clic sull'immagine per ingrandirla)

A questo punto, nel caso in cui si verifichi questo problema, si hanno a disposizione due opzioni. È possibile rimuovere i riferimenti alle colonne del sito senza un attributo SourceID esplicito dalla definizione del tipo di contenuto o è possibile sostituire le colonne del sito incorporate che causano il problema con le colonne del sito personalizzare compatibili con InfoPath 2007. Tenere presente che non è possibile modificare i riferimenti di campo di un tipo di contenuto basato su CAML dopo che ne è stato eseguito il provisioning nel database del contenuto, in particolare se si sono già creati tipi di contenuto figlio. Non è più possibile aggiornare semplicemente il file della definizione del tipo di contenuto basato su CAML né è possibile applicare le modifiche ai tipi di contenuto figlio, in quanto in Windows SharePoint Services non vengono rilevate le modifiche apportate alla definizione del tipo di contenuto padre.

Per applicare le modifiche, è necessario modificare il tipo di contenuto padre tramite il modello a oggetti o l'interfaccia utente di SharePoint o è necessario definire un nuovo tipo di contenuto derivato da quello esistente. La seconda tecnica consente di rimuovere i campi critici e aggiungere nuove colonne. Gli utenti possono quindi derivare i tipi di contenuto futuri dal nuovo tipo di contenuto. Per impedire agli utenti di scegliere il tipo di contenuto errato, aggiungere il tipo di contenuto precedente al gruppo dei tipi di contenuto _Hidden.

Come affermato in precedenza, non è possibile aggiornare i tipi di contenuto basati su CAML dopo averli distribuiti e attivati. Pertanto, è molto importante testare i tipi di contenuto globali prima della distribuzione. Per ulteriori informazioni, vedere l'articolo MSDN "Aggiornamento dei tipi di contenuto" all'indirizzo msdn2.microsoft.com/aa543504.

Una volta creato un tipo di contenuto con i riferimenti di campo appropriati, è possibile creare un riquadro informazioni documento personalizzato in InfoPath 2007. La strategia migliore è consentire ai proprietari del sito di creare riquadri informazioni documento personalizzati per i relativi tipi di contenuto figlio. InfoPath 2007 consente di pubblicare il riquadro informazioni documento personalizzato direttamente sul tipo di contenuto selezionato, semplificando lo scenario di distribuzione. È inoltre possibile pubblicare il modulo InfoPath in una posizione centrale, come una raccolta documenti, e includere un riferimento al riquadro informazioni documento nel tipo di contenuto. Questa rappresenta l'opzione ideale se si intende fornire un riquadro informazioni documento personalizzato insieme ai tipi di contenuto CAML. Nella Figura 7 viene illustrata l'architettura di implementazione.

Figura 7 Implementazione dei file XSN in una posizione centrale in MOSS 2007

Figura 7** Implementazione dei file XSN in una posizione centrale in MOSS 2007 **(Fare clic sull'immagine per ingrandirla)

Il download per questo articolo include una funzione denominata AdventureWorks_Update che consente di estendere la funzione AdventureWorks precedente aggiungendo ulteriori colonne del sito compatibili con InfoPath 2007. La funzione AdventureWorks_Update consente di contrassegnare il tipo di contenuto Customer Documentation originale come nascosto e di derivare un nuovo tipo di contenuto denominato Customer Docs, che sostituisce i campi incorporati ereditati con le nuove colonne del sito e associa il nuovo tipo di contenuto a un riquadro informazioni documento personalizzato.

La nuova definizione del tipo di contenuto Customer Docs include un elemento XmlDocument che fornisce informazioni sul riquadro informazioni documento. In particolare, l'elemento xsnLocation fa riferimento al modulo InfoPath http://companyresources/DIPs/customerDIP.xsn, che implementa il riquadro informazioni documento. Per istruzioni dettagliate su come applicare la caratteristica AdventureWorks_Update, vedere il file readme.htm nella cartella AdventureWorks_Update.

Conclusione

È possibile utilizzare i tipi di contenuto di SharePoint per creare criteri di metadati e utilizzarli in modo coerente nell'ambiente aziendale per la gestione dei contenuti. La gerarchia dei tipi di contenuto consente di standardizzare le caratteristiche rilevanti per l'intero ambiente aziendale e applicarle uniformemente a tutti i siti tramite l'ereditarietà.

È possibile ad esempio estendere le funzionalità di ricerca incorporate di MOSS 2007 in modo che gli utenti possano individuare contenuti specifici in modo più rapido e semplice. È inoltre possibile garantire la coerenza delle informazioni correlate ai metadati e stabilire criteri di gestione delle informazioni centralizzati. La strategia migliore consiste nella standardizzazione dei tipi di contenuto globali in base alle caratteristiche dei metadati più astratte per ridurre al minimo la necessità di modifiche successive. Basati su un modello di contenuto attentamente progettato, i tipi di contenuto di SharePoint sono in grado di fornire nuove funzionalità per standardizzare la gestione del ciclo di vita del contenuto nell'ambiente aziendale.

Pav Cherny è presidente di Biblioso Corporation, un esperto IT e un autore specializzato nelle tecnologie Microsoft per la collaborazione e la comunicazione unificata. I libri che ha pubblicato sono incentrati sulle operazioni IT e sull'amministrazione dei sistemi.

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