SharePoint

Normalisez la gestion des données grâce aux types de contenu personnalisés

Pav Cherny

Vue d'ensemble:

• Gestion du cycle de vie des contenus avec SharePoint
• Création de panneaux Informations sur le document
• Modification des documents Office et SharePoint à l'aide d'Infopath

Télécharger le code de cet article: ContentTypes2008_02.exe (779KB)

Le grand nombre de documents et autres éléments de contenu généralement se trouvant dans un environnement d'entreprise présente des difficultés commerciales et techniques pour une gestion des documents, des

métadonnées et des comportements de façon centralisée et réutilisable. Microsoft® Office SharePoint® Server 2007 favorise la collaboration à l'échelle l'entreprise en permettant à diverses équipes d'une entreprise de partager des espaces de travail sur des sites Web, des bibliothèques de documents et des listes.

SharePoint 2007 permet la normalisation de nombreux aspects du contenu et des caractéristiques de cycle de vie par le biais des types de contenu. Les types de contenu de site sont des définitions de métadonnées qui peuvent être établies indépendamment de tout(e) site, collection de sites, liste ou bibliothèque de documents spécifique. Ceci vous permet de définir des propriétés, des flux de travail, des stratégies de gestion des informations et d'autres éléments de façon systématique à l'échelle de l'entreprise, tout en permettant à certains services ou propriétaires de site de personnaliser des types de contenu à des fins spécifiques.

Dans cet article, je vous montrerai comment utiliser le nouveau modèle de contenu SharePoint inclus dans Windows® SharePoint Services (WS) 3.0 et Microsoft Office SharePoint Server (MOSS) 2007 afin de créer des hiérarchies pour les contenus d'entreprise en vous basant sur des caractéristiques générales. Ces hiérarchies de contenu permettent l'application uniforme des métadonnées, flux de travail et stratégies de gestion des informations à un niveau global, tout en offrant une flexibilité permettant de répondre aux besoins de gestion de contenu uniques au niveau des sites, des collections de sites, des bibliothèques de documents et des listes.

Pour illustrer certains des aspects bas niveau des types de contenu de SharePoint, j'ai inclus plusieurs outils personnalisés dans les ressources associées, et j'ai également inclus le code source au cas où vous souhaiteriez développer ces outils en fonction de vos besoins spécifiques. Gardez juste à l'esprit que ces outils n'ont pas été testés à fond et ne doivent pas être utilisés sur un système de production. Vous pouvez télécharger le code à partir du site Web de TechNet Magazine, à l'adresse technetmagazine.com/code08.aspx.

Définitions des cycles de vie du contenu et des types de contenu

Ressources SharePoint

• Blog de l'équipe InfoPath
• Flux de travail dans Office SharePoint Server 2007
• Webcast TechNet : Installation et configuration de la recherche dans SharePoint Server 2007
• InfoPath Forms Services

Il y a beaucoup de détails à prendre en compte lorsque l'on gère des documents et d'autres contenus dans une entreprise. Il est notamment nécessaire de définir quelles personnes ou quels processus doivent exécuter quelle action lorsque le contenu est créé, publié, archivé ou détruit. Il est également souvent nécessaire pour une entreprise de développer des modèles spécifiques pour la création de contenu, de définir des rôles pour attribuer des responsabilités et des privilèges d'accès aux utilisateurs, de fournir un contrôle de version, de contrôler la conformité, de stocker et d'archiver, de définir des métadonnées etc.

Quelle que soit la complexité du cycle de vie d'un contenu particulier, le modèle de contenu SharePoint reconnaît qu'il existe certaines caractéristiques générales et certaines phases typiques qui déterminent la façon dont les éléments individuels du contenu doivent être gérés. Par exemple, vous pouvez structurer la création de contenu à l'aide de modèles et de formulaires de saisie, et l'affichage et les recherches de contenu via des métadonnées. Vous pouvez aussi utiliser la modification, l'approbation ou d'autres exigences de flux de travail, des exigences d'archivage, des calendriers d'expiration et des stratégies de gestion des informations applicables pour distinguer les éléments de contenu individuels. Certains contenus ne nécessitent pas de modèles spéciaux ou ne seront jamais archivés, mais même ceux-ci constituent des caractéristiques de cycles de vie qui permettent de distinguer ces éléments d'autres éléments.

Le modèle de contenu SharePoint vous permet de définir des types de contenu individuels et d'établir des relations hiérarchiques. Dans une relation hiérarchique, les enfants héritent des caractéristiques générales des types de contenu parents, et ajoutent des caractéristiques spécifiques si nécessaire.

La meilleure façon d'illustrer cela consiste à examiner les types de contenu prédéfinis de SharePoint. WS 3.0 et MOSS 2007 incluent plusieurs types de contenu prédéfinis pour des éléments types pouvant être stockés dans une bibliothèque de documents ou une liste, notamment des documents et des tâches. Vous trouverez les définitions de ces types de contenu standard sur un serveur SharePoint dans le dossier %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. Vous y trouverez un fichier de manifeste nommé feature.xml. Dans ce fichier, vous pouvez voir que SharePoint implémente les définitions de type de contenu standard en tant que fonctionnalité masquée (Hidden=« TRUE ») avec une étendue de collection de sites (Scope=« Site »), et que le fichier de manifeste Element, qui contient les éléments de type de contenu réel, est appelé ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).

Si vous souhaitez en savoir plus sur les fonctions de SharePoint, je vous recommande la lecture de l'article Office Space de Ted Pattison publié dans MSDN® Magazine et intitulé « Fonctionnalités pour SharePoint », qui est accessible à l'adresse msdnmagazine.com/issues/07/05/OfficeSpace.

Ouvrons maintenant le fichier ctypeswss.xml dans le Bloc-notes pour examiner les types de contenu standard indépendamment de leur visibilité dans l'interface utilisateur de SharePoint. Vous ne devez pas modifier le fichier ctypeswss.xml. Si vous envisagez de modifier ctypeswss.xml pour ajouter de nouveaux champs aux types de contenu standard ou pour rendre des types de contenu masqués visibles afin que les utilisateurs de SharePoint puissent les utiliser pour dériver de nouveaux types de contenu, remarquez que ceci n'est en général pas nécessaire. De plus, cela entraîne des configurations non prises en charge, et des installations ultérieures de services packs risquent d'écraser vos personnalisations et de détruire vos solutions de gestion du contenu.

Une meilleure approche consiste à copier ce dont vous avez besoin dans un nouveau fichier de manifeste des éléments, d'ajouter vos personnalisations selon vos besoins puis de déployer vos types de contenu personnalisés comme une nouvelle fonctionnalité avec une étendue de collection de sites afin qu'ils soient disponibles pour tous les sites de la collection de sites.

La définition basée sur le CAML (Collaborative Application Markup Language) du type de contenu Système tel qu'indiqué dans le fichier ctypeswss.xml est reproduite ici :

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

Les attributs Group et Sealed indiquent que le type de contenu Système est masqué et scellé pour qu'il ne puisse pas être modifié dans l'interface utilisateur SharePoint. Le type de contenu Système ne possède qu'un élément FieldRef qui référence une colonne de site prédéfinie nommée ContentType. C'est le niveau d'abstraction le plus élevé. Tous les autres types de contenu de SharePoint héritent de cette propriété à partir du type de contenu Système. De cette façon, SharePoint garantit que tous les éléments de contenu stockés dans une bibliothèque de documents ou une liste possèdent cette propriété en commun.

La Figure 1 reproduit un composant WebPart ContentTypeHierarchy, inclus dans les ressources associées à cet article, qui illustre les hiérarchies de façon plus intuitive. System est à la racine de tous les autres types de contenu, suivi par Item et ainsi de suite. Le type de contenu Élément, par exemple, établit le niveau de détail suivant. Si vous consultez le fichier ctypeswss.xml, vous pourrez voir qu'Élément définit un champ unique de métadonnées qui référence une colonne de site nommée Title. De cette façon, tous les types de contenu prédéfinis de niveaux inférieurs ont une propriété Title.

Figure 1** Hiérarchie des types de contenu prédéfinis dans WSS 3.0 **(Cliquer sur l'image pour l'agrandir)

Il est également possible de supprimer un champ hérité, comme la définition du type de contenu Document du fichier ctypeswss.xml le démontre. Le type de contenu Document inclut plusieurs éléments RemoveFieldRef correspondants, mais vous pouvez souhaiter conserver le champ Titre au lieu de vos types de contenu personnalisés parce que la colonne Title donne accès au menu déroulant Edit Control Box (ECB) dans les vues des bibliothèques de documents et des listes de SharePoint.

Le type de contenu Contact Extrême-Orient de ctypeswss.xml illustre parfaitement la façon de renommer des champs hérités. Recherchez 0x0116, qui est l'ID du type de contenu correspondant, puis vérifiez l'élément FieldRef avec l'attribut Name=« Title » pour voir comment vous pouvez utiliser l'attribut DisplayName pour renommer un champ dans l'interface utilisateur. Dans cet exemple, l'attribut DisplayName modifie le nom du champ Titre dans l'interface utilisateur en une valeur localisée référencée par « $Resources:core,Last_Name; ».

Si vous examinez de plus près la Figure 1, vous voyez que l'attribut ID de l'élément ContentType identifie de façon unique le type de contenu et établit la relation hiérarchique. Tous les ID commencent par l'ID du type de contenu parent auquel sont ajoutées des valeurs hexadécimales. Deux valeurs hexadécimales supplémentaires sont généralement ajoutées aux types de contenu standard possèdent pour créer un nouvel ID unique pour le type de contenu enfant. Une autre technique est d'ajouter « 00 » et un GUID hexadécimal. C'est la façon dont les types de contenu Fichier de connexion de données Office et Fichier UDC sont dérivés du type de contenu Document, par exemple.

Il est important que les utilisateurs gardent à l'esprit que l'attribut ID de l'élément ContentType ne peut pas être d'une longueur supérieure à 1 024 caractères. Ceci peut se révéler problématique dans une relation hiérarchique importante si tous les types de contenu utilisent la technique d'adressage de GUID hexadécimal. Cependant, il n'est pas recommandé de commencer par la technique la plus courte parce que ces ID peuvent ne pas être uniques.

Pour garantir l'unicité, utilisez la technique du GUID pour définir un espace de noms global pour vos types de contenu d'entreprise et adoptez la technique plus courte dans cet espace de noms. Pour obtenir des informations détaillées sur l'attribut ID et d'autres aspects des définitions de type de contenu, consultez la rubrique « Schéma des définitions de type de contenu » dans le kit de développement logiciel WSS 3.0.

Dépendances des types de contenu

Voyons maintenant comment utiliser les types de contenu de SharePoint pour structurer la gestion des éléments de contenu. Vous devez tenir compte de plusieurs dépendances, par exemple les interdépendances entre les bibliothèques de documents et les listes, les types de contenu, les colonnes de site et les types de champ. Les bibliothèques et les listes référencent des types de contenu, qui à leur tour référencent des colonnes de site, lesquelles référencent des types de champ (tels que les types de champ WSS standard Texte, Commentaire, Choix, Nombre, Devise, etc.) qui résident dans des assemblys de Microsoft .NET Framework tels que Microsoft.SharePoint.dll, l'assembly principal de WSS.

Á titre d'exemple, revenons au type de contenu Système tel qu'illustré plus tôt dans la définition CAML de l'entrée « System » du fichier de manifeste des types de contenu. Comme vous l'avez vu, ce type de contenu contient un élément FieldRef qui se réfère à une colonne de site nommée ContentType. Remarquez que la définition du type de contenu ne définit pas la colonne réelle du site ContentType. ContentType est un champ Texte, défini dans le manifeste des éléments fieldswss.xml, situé dans le dossier %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. Le type de champ Texte est à nouveau défini dans fldtypes.xml, que vous pouvez trouver sous %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Il est important de vérifier dans cette arborescence de dépendances que toutes les ressources sont disponibles sur vos serveurs SharePoint.

Les types de contenu que vous voulez utiliser doivent être créés au niveau site de vos bibliothèques de documents et de vos listes, ou plus haut dans la hiérarchie des sites. De même, les champs de métadonnées de vos types de contenu doivent se référer aux colonnes de site existantes. Vous pouvez ajouter à vos types de contenu des colonnes de site standard ou personnalisées basées sur des types de champ standard ou personnalisés, mais vous devez vous assurer que les colonnes de site existent sur le site local. De plus, si vous voulez utiliser des types de champ personnalisés, vous devez également vérifier que les assemblys .NET sous-jacents sont déployés sur vos serveurs SharePoint.

Des dépendances similaires existent pour les types de contenu qui référencent des modèles de documents, des destinataires d'événements personnalisés, des flux de travail et d'autres composants. Par exemple, la définition du type de contenu peut contenir un élément DocumentTemplate qui pointe sur le modèle de document associé au type de contenu. La définition du type de contenu peut également contenir un élément XmlDocument avec un ou plusieurs éléments XmlDocument enfants qui définissent des caractéristiques supplémentaires du type de contenu, telles que les définitions d'espace de noms, les définitions de panneau Informations sur le document ou toute information personnalisée.

Établissement de types de contenu globaux

Les utilisateurs avec des autorisations de création peuvent créer de nouveaux types de contenu et des colonnes de site directement dans l'interface utilisateur de SharePoint, mais les types de contenu sont ensuite uniquement disponibles dans le site local et aux niveaux inférieurs de la hiérarchie de site. Les colonnes de site personnalisées sont uniquement disponibles dans le site local. Ce n'est pas suffisant si vous voulez définir des types de contenu globaux. Vous devez vous assurer que les types de contenu globaux sont disponibles dans toutes les collections de sites de votre environnement. C'est là que les fonctionnalités de SharePoint s'avèrent utiles. Il est très facile d'installer et d'activer les fonctionnalités de SharePoint dans plusieurs collections de sites pour appliquer la colonne de site et les définitions de type de contenu correspondants de façon systématique dans tous les emplacements.

Les ressources associées à cet article incluent un exemple de fonctionnalité nommé AdventureWorks qui démontre comment définir un type de contenu global. Cette fonctionnalité définit un type de contenu général nommé Customer Documentation (Documentation client) qui peut être utilisé pour créer n'importe quel type de document client, par exemple des propositions et des lettres commerciales. Il est raisonnable de supposer que tous ces types de documents doivent être associés avec des informations clients telles que le nom de l'entreprise, les coordonnées de contact et l'adresse. J'ai spécifiquement créé un champ personnalisé nommé Customer Name (Nom du client) pour votre type de contenu et ai ajouté certains champs prédéfinis tels que Department (Service) et Primary Phone (Téléphone principal). Vous pouvez modifier le type de contenu et les champs en modifiant le fichier ContentTypes.xml, et modifier les références de champ en modifiant le fichier SiteColumns.xml dans l'exemple associé.

Si vous déployez la fonctionnalité comme il est indiqué dans le fichier lisezmoi.htm, vous pouvez l'activer de façon systématique dans plusieurs des collections de sites. Le type de contenu Customer Documentation (Documentation client) est ensuite disponible globalement. Chaque service distinct peut ensuite créer une documentation client spécifique via des types de contenu dérivés associés à des modèles de documents ciblés. Les ressources associées incluent des exemples de modèles de document qui pourraient être utilisés dans les domaines des ventes et du conseil. La figure 2 illustre les types de contenu résultants.

Figure 2** Types de contenu parents et enfants pour la documentation client **(Cliquer sur l'image pour l'agrandir)

Vous pouvez choisir entre plusieurs options pour créer des fonctionnalités pour les colonnes de site personnalisées et les types de contenu dans WSS 3.0 et MOSS 2007. Vous pouvez étudier le kit de développement logiciel  WSS 3.0 et écrire intégralement des fichiers XML. Vous pouvez également choisir d'utiliser SharePoint Designer pour exporter une liste dans un package Web personnel, renommer le fichier résultant .fwp en fichier .cab, extraire le fichier manifest.xml du fichier .cab puis rechercher les définitions ContentType dans le fichier manifest.xml. Malheureusement, les deux approches sont peu pratiques et favorisent les erreurs.

En revanche, il est remarquablement facile de créer des colonnes de site et des types de contenu personnalisés dans l'interface utilisateur de SharePoint. L'interface n'offre toutefois pas la possibilité de modifier les fichiers XML d'une fonctionnalité. Les fonctionnalités constituent un moyen efficace de configurer les ressources de SharePoint, mais une fois configurées, ces ressources n'existent que dans la base de données de contenu. Une version future de WSS comportera peut-être la possibilité d'exporter les colonnes de site et les types de contenu dans des fichiers XML via l'interface utilisateur de SharePoint, sur le modèle de l'exportation des composants WebParts. Pour le moment, vous devez faire avec ce dont vous disposez.

Les ressources associées incluent un composant WebPart nommé ContentTypeSchema qui peut servir de point de départ. Il utilise le modèle d'objet de SharePoint pour extraire la propriété SchemaXML du type de contenu sélectionné. Grâce à des transformations XSLT (eXtensible Stylesheet Language Transformation), le composant WebPart dérive des définitions Field ou des définitions ContentType qui dépendent de l'option que vous sélectionnez dans l'interface utilisateur avant de cliquer sur le bouton Afficher.

La figure 3 illustre ce composant WebPart en action. Il affiche le type de contenu Active Directory® Documentation (Documentation Active Directory®), que j'ai basé sur le type de contenu Customer Documentation (Documentation client). Le type de contenu Active Directory Documentation (Documentation Active Directory) est associé à un modèle Microsoft Word personnalisé (Active Directory Template.dot). Notez que ce type de contenu ne possède pas de champ supplémentaire. Tous les champs sont hérités du type de contenu parent.

Si vous envisagez d'utiliser le composant WebPart ContentTypeSchema dans votre propre environnement, gardez à l'esprit que ce composant WebPart n'a pas été testé à fond. Mon composant WebPart utilise des transformations XSL relativement complexes pour générer un delta entre la propriété SchemaXML du type de contenu actuellement sélectionné et le type de contenu parent. Pourtant, XSLT 1.0 n'est pas vraiment conçu pour les conversions avancées de documents XML. Il n'existe pas de fonctionnalité prédéfinie permettant de comparer les nœuds XML. Par ailleurs, les espaces de noms XML, ainsi que les sections CDATA, représentent des difficultés que XSLT 1.0 ne peut pas gérer efficacement.

SharePoint stocke la définition des colonnes de site et des types de contenu de site créés à l'aide de l'interface utilisateur de SharePoint ou du modèle d'objet de SharePoint dans la base de données de contenu, dans un tableau nommé ContentTypes. Examinez l'ID de mon type de contenu personnalisé à la figure 3. En conséquence, l'instruction T-SQL suivante donnerait des résultats corrects : SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>.

Figure 3** Définition personnalisée du type de contenu dans le composant WebPart ContentTypeSchema **(Cliquer sur l'image pour l'agrandir)

Quelle que soit l'approche que vous décidez d'utiliser, la création de fonctionnalités pour des types de contenu destinés à l'ensemble de l'entreprise est très simple dès lors que vous disposez des définitions de la colonne de site et du type de contenu. Je vous recommande d'utiliser une fonctionnalité unique pour toutes les colonnes de site et tous les types de contenu généraux de votre service ou de votre entreprise. Ainsi, il est facile de savoir où ajouter de nouvelles définitions de colonnes de site ou de types de contenu.

Recherches à l'échelle de l'entreprise sur les métadonnées personnalisées

L'un des avantages immédiats des hiérarchies de types de contenu réside dans le fait que tous les types de contenu enfants héritent des champs de métadonnées du type de contenu parent. Comme tous les types de contenu ont des champs de métadonnées en commun, les utilisateurs peuvent très facilement créer des vues et des filtres personnalisés dans les bibliothèques de documents.

L'exemple de fonctionnalité AdventureWorks le démontre de façon tout à fait intuitive. Quel que soit le contenu créé par un consultant ou un vendeur, l'enregistrement du document Word 2007 dans la bibliothèque de documents nécessite de spécifier le Customer Name parce que le type de contenu parent Customer Documentation (Documentation client) définit ce champ de métadonnées comme étant obligatoire. En groupant ou en filtrant les éléments dans une vue de bibliothèque de documents selon le Customer Name (Nom du client), les consultants et les vendeurs peuvent repérer rapidement et facilement toute la documentation existante sur client, comme illustré à la figure 4.

Figure 4** Regroupement de divers documents dans une bibliothèque en fonction des métadonnées communes **(Cliquer sur l'image pour l'agrandir)

Les métadonnées communes facilitent également la localisation du contenu dans les multiples bibliothèques de documents et sites en utilisant les fonctionnalités de recherche de WSS 3.0 et de MOSS 2007. WSS permet d'effectuer des recherches dans des bibliothèques, des listes et des sites au sein d'une collection de sites unique. MOSS 007 va au-delà de ces fonctionnalités de base en vous permettant d'implémenter un Centre de recherche à l'échelle de l'entreprise et de gérer des métadonnées personnalisées dans l'interface utilisateur Administration Centrale de SharePoint 3.0. Pour cette raison, les explications suivantes portent sur MOSS 2007.

Lorsque vous configurez un Fournisseur de services partagés dans MOSS 2007 et que vous analysez vos sites SharePoint, MOSS 2007 peut automatiquement retrouver les champs de métadonnées personnalisés utilisés dans les sources de contenu. Par conséquent, vous pouvez trouver les champs de métadonnées personnalisés dans la liste des propriétés analysées.

Les champs de métadonnées définis dans les fonctionnalités de SharePoint sont classés dans la catégorie SharePoint. Pour trouver son emplacement dans l'Administration centrale de SharePoint, dans le menu de lancement rapide sous Administration de services partagés, cliquez sur le lien vers votre Fournisseur de services partagés, cliquez sur Paramètres de recherche, cliquez sur Mappages des propriétés de métadonnées, puis cliquez sur Propriétés analysées dans le menu de lancement rapide et ouvrez la catégorie SharePoint.

Je vais vous montrer comment cela fonctionne à l'aide d'un exemple. Le champ de métadonnées nommé Customer Name (Nom du client) se transforme en propriété analysée nommée ows_Customer_x0020_Name. SharePoint préfixe les propriétés analysées par « ows_ », et « _x0020_ » est la version codée d'un espace unique. Si vous affichez les détails de cette propriété analysée, vous verrez qu'elle est incluse dans l'index de recherche par défaut pour que les utilisateurs puissent employer ses valeurs pour effectuer des recherches sur les contenus. Cependant, pour augmenter la précision de la recherche, vous pouvez ne pas vouloir mapper la propriété analysée sur une propriété gérée pour que les utilisateurs puissent chercher des contenus en utilisant explicitement le nom du client.

Lorsque vous mappez des propriétés analysées sur des propriétés gérées, vous avez deux possibilités. Vous pouvez générer automatiquement une nouvelle propriété gérée pour chaque propriété analysée ou vous pouvez mapper manuellement des propriétés analysées sur des propriétés gérées. La première option est disponible lorsque vous affichez les paramètres de la catégorie de propriété analysée souhaitée (lors de l'affichage des propriétés analysées dans une catégorie, par exemple la catégorie SharePoint, cliquez sur l'option Modifier la catégorie sur le lien de lancement rapide). Sous Paramètres de propriétés analysées en bloc, vous devez alors sélectionner la case à cocher « Générer automatiquement une nouvelle propriété gérée pour chaque propriété analysée découverte dans cette catégorie ». Cependant, SharePoint préfixe les propriétés gérées créées automatiquement par « ows » et les espaces par « x0020 ». La propriété gérée pour la propriété analysée ows_Customer_x0020_Name serait donc owsCustomerx0020Name. Ceci, cependant, n'est pas un nom de propriété très convivial.

Une meilleure stratégie consiste peut-être à mapper manuellement les propriétés analysées sur des propriétés gérées après avoir déployé vos types de contenu à l'échelle de l'entreprise. Vous pouvez mapper une propriété analysée sur une ou plusieurs propriétés gérées. Pour créer de nouvelles propriétés gérées, dans l'Administration centrale de SharePoint, dans le menu de lancement rapide sous Administration, des services partagés, cliquez sur le lien vers votre Fournisseur de services partagés, cliquez sur Paramètres de recherche, puis cliquez sur Mappages des propriétés de métadonnées et enfin sur Nouvelle propriété gérée pour spécifier les informations requises et associer la nouvelle propriété gérée à la propriété analysée souhaitée.

Les utilisateurs peuvent ensuite localiser des éléments de contenu pertinents en utilisant les propriétés gérées soit dans propriété: syntaxe ou en utilisant la recherche avancée. Par exemple, si vous mappez la propriété analysée ows_Customer_x0020_Name sur une propriété gérée nommée Customer, les utilisateurs peuvent ensuite rechercher tous les documents d'un client simplement en spécifiant Customer: <Customer Name> dans la boîte de dialogue de recherche standard, par exemple Customer: Contoso.

Il est également recommandé de prévoir les propriétés gérées pour les champs de métadonnées les plus importants de vos types de contenu dans la liste des propriétés, sur la page de recherche avancée. Pour cela, affichez la page Recherche avancée, puis cliquez sur Actions du site et sélectionnez la commande Modifier la page. Vous pouvez maintenant cliquer sur Modifier dans la boîte de dialogue Recherche avancée pour sélectionner l'option Modifier le composant WebPart partagé. Lorsque vous développez la catégorie Propriétés et que vous placez le curseur dans le champ de texte correspondant, vous pouvez cliquer sur le bouton pour modifier le document XML Properties. Vous devez ajouter une définition de propriété à l' élément <PropertyDefs> , par exemple <PropertyDef Name=« Customer » DataType=« text » DisplayName=« Customer Name »/>, et vous devez également ajouter une référence à cette définition de propriété sous un élément ResultType (par exemple, l'élément <ResultType DisplayName=« All Results » Name=« default »>), telle que <PropertyRef Name=« Customer » />. La figure 5a illustre l'interface utilisateur de recherche avancée qui en résulte. La figure 5b illustre les résultats de la recherche.

Figure 5a** Recherche de documentation d'infrastructure informatique en fonction du nom du client **(Cliquer sur l'image pour l'agrandir)

Figure 5b** Résultats de la recherche du nom de client **(Cliquer sur l'image pour l'agrandir)

Garantie de la cohérence des informations

À ce stade, j'ai normalisé avec succès les champs des métadonnées, les types de contenu et les fonctionnalités de recherche étendues les plus importants dans toutes les collections de sites de mon entreprise en m'appuyant sur MOSS 2007. Il importe à présent de s'assurer que les utilisateurs entrent des informations correctes dans les champs de métadonnées.

Il existe deux façons de faire. Première possibilité : vous pouvez remplacer le panneau standard Information sur le document de vos modèles de document par un formulaire Infopath® personnalisé qui fournit à vos utilisateurs une sélection prédéfinie d'options de saisie, comme celles que vous trouvez dans une zone de liste. Deuxième possibilité : vous pouvez lier un récepteur d'événements au type de contenu et vérifier ensuite la correction des métadonnées et autres informations à chaque fois que les utilisateurs créent, modifient ou suppriment des éléments de contenu correspondants.

Les deux options se complètent. Un formulaire Infopath fournit principalement une façon commode de modifier les propriétés d'un type de contenu SharePoint, tandis qu'un récepteur d'événements peut garantir la validité des métadonnées même si les utilisateurs modifient les propriétés du type de contenu sans utiliser le formulaire Infopath. Vous pouvez lier des gestionnaires d'événements à un type de contenu spécifique, ce qui vous permet de spécifier des événements et leurs réponses pour tous les documents associés à un type de contenu individuel dans toutes les collections de sites, quelle que soit la bibliothèque de documents. Vous trouverez plus d'informations sur la façon de développer et de déployer des gestionnaires d'événements à l'adresse msdn2.microsoft.com/ms453149.

La méthode la plus facile pour associer un type de contenu à un panneau Informations sur le document personnalisé consiste peut-être à afficher les paramètres Panneau Informations sur le document du type de contenu dans l'interface utilisateur de SharePoint sur un ordinateur où Infopath 2007 est installé. Vous pouvez ensuite cliquer sur le lien Créer un nouveau modèle personnalisé sous Modèle du panneau Informations sur le document pour démarrer Infopath 2007 en mode conception. Cependant, si votre type de contenu de site inclut des colonnes de site sans attribut SourceID explicite, vous risquez de vous trouver dans une situation dans laquelle Infopath ne peut pas créer de schéma XSD valide pour le formulaire Panneau Informations sur le document. Par exemple, le type de contenu Customer Documentation (Documentation client) présenté plus tôt comprend plusieurs colonnes spécifiques au contact telles que Department (Service), Office (Bureau) et E-mail, qui peuvent provoquer ce problème, comme illustré à la figure 6.

Figure 6** Incompatibilités du schéma XSD dans Infopath 2007 **(Cliquer sur l'image pour l'agrandir)

À ce stade, vous avez deux options si vous rencontrez ce problème. Vous pouvez soit supprimer les références aux colonnes de site qui n'ont pas un attribut SourceID explicite de la définition de type de contenu, soit remplacer les colonnes de site prédéfinies qui posent problème par des colonnes de site personnalisées compatibles avec Infopath 2007. Gardez à l'esprit que vous ne pouvez pas modifier les références de champ d'un type de contenu CAML une fois qu'il a été configuré dans la base de données de contenu, surtout si vous avez déjà créé des types de contenu enfants. Vous ne pouvez plus simplement mettre à jour le fichier de définition de type de contenu CAML, ni propager des modifications aux types de contenu enfants parce que Windows SharePoint Services ne suit pas les modifications apportées à la définition de type de contenu parent.

Pour propager les modifications, vous devez modifier le type de contenu parent via l'interface utilisateur de SharePoint ou le modèle objet, ou vous devez définir un nouveau type de contenu dérivé du type de contenu existant. Cette dernière technique vous permet de supprimer les champs critiques et d'ajouter de nouvelles colonnes. Vos utilisateurs peuvent ensuite dériver des types de contenu futurs à partir du nouveau type de contenu. Pour empêcher les utilisateurs de choisir le mauvais type de contenu, ajoutez le type de contenu précédent au groupe de type de contenu _masqué.

Comme je l'ai indiqué précédemment, vous ne pouvez pas mettre à jour des types de contenu CAML après les avoir déployés et activés. Il est donc très important de tester les types de contenu globaux avant le déploiement. Pour plus d'informations, consultez l'article de MSDN « Mise à jour des types de contenu » à l'adresse msdn2.microsoft.com/aa543504.

Une fois que vous avez créé un type de contenu avec des références de champ correctes, vous pouvez créer un panneau Informations sur le document personnalisé dans Infopath 2007. La meilleure stratégie consiste à laisser les propriétaires de site créer des panneaux Informations sur le document personnalisés pour leurs types de contenu enfants. Infopath 2007 fournit la possibilité de publier le panneau Informations sur le document personnalisé directement dans le type de contenu sélectionné, ce qui facilite le scénario de déploiement. Toutefois, il est également possible de publier le formulaire InfoPath dans un emplacement central, tel qu'une bibliothèque de documents, et d'inclure une référence au panneau Informations sur le document dans le type de contenu. Il s'agit de la meilleure solution si vous avez l'intention de fournir un panneau Informations sur le document personnalisé avec vos types de contenu CAML**. La figure 7** illustre l'architecture d'implémentation.

Figure 7** Implémentation du fichier XSN dans un emplacement central dans MOSS 2007 **(Cliquer sur l'image pour l'agrandir)

Le téléchargement associé à cet article inclut une fonctionnalité nommée AdventureWorks_Update qui prolonge la fonctionnalité précédente AdventureWorks en ajoutant des colonnes de site supplémentaires qui fonctionnent avec Infopath 2007. La fonctionnalité AdventureWorks_Update définit le type de contenu Customer Documentation (Documentation client) original comme masqué et dérive un nouveau type de contenu nommé Customer Docs (Docs client), qui remplace les champs prédéfinis hérités par les nouvelles colonnes de site et associe le nouveau type de contenu à un panneau Informations sur le document personnalisé.

La nouvelle définition de type de contenu Customer Docs (Docs client) inclut un élément XmlDocument qui fournit des informations sur le panneau Informations sur le document. En particulier, l'élément xsnLocation pointe sur le formulaire InfoPath http://companyresources/DIPs/customerDIP.xsn, qui implémente le panneau Informations sur le document. Pour obtenir des instructions détaillées sur la façon d'utiliser la fonctionnalité AdventureWorks_Update, consultez le fichier lisezmoi.htm dans le dossier AdventureWorks_Update.

Conclusion

Vous pouvez utiliser les types de contenu de SharePoint pour créer des stratégies de métadonnées et les utiliser régulièrement dans l'entreprise pour la gestion du contenu. La hiérarchie des types de contenu vous permet de normaliser des caractéristiques pertinentes pour l'ensemble de l'environnement d'entreprise et de les appliquer uniformément à tous les sites par héritage.

Il est notamment possible d'étendre les fonctionnalités de recherche intégrées de MOSS 2007 pour que les utilisateurs puissent localiser des contenus spécifiques plus rapidement et plus facilement. Il est également possible d'appliquer la cohérence des informations en fonction des métadonnées et de définir des stratégies de gestion des informations centralisées. La meilleure stratégie consiste à de normaliser les types de contenu globaux selon les caractéristiques les plus abstraites des métadonnées afin de réduire le besoin de modifications ultérieures. Basés sur un modèle de contenu soigneusement conçu, les types de contenu de SharePoint peuvent fournir de nouvelles possibilités pour normaliser la gestion du cycle de vie des contenus à l'échelle de l'entreprise.

Pav Cherny est président de Biblioso Corporation, expert en informatique et auteur spécialiste des technologies de collaboration et de communication unifiée Microsoft. Ses travaux publiés portent essentiellement sur l'exploitation et l'administration de système.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.