SharePoint

Une approche intelligente de la collecte de données dans l'entreprise

Keith Deshaies

Vue d'ensemble:

• Collecte et traitement des données
• Séparation de la logique de présentation de la logique de gestion des informations
• Utilisation des technologies Microsoft Office 2007 pour la création d'une solution de collecte de données

Télécharger le code de cet article: DataGathering2008_02.exe (567KB)

Les entreprises collectent de grandes quantités d'informations à l'aide un grand nombre de méthodes. Les données arrivent via la messagerie électronique, des enquêtes, des formulaires Web et d'autres mécanismes de collecte de données. De façon générale, le fait de disposer de données est considéré comme

positif. Cependant, la gestion du large éventail d'outils de collecte de données et des différentes informations peut s'avérer complexe. L'intégration fiable et le partage sécurisé des données représentent des défis constants pour les entreprises informatiques. Toutefois, les normes et les architectures orientées services sont en train d'évoluer, permettant ainsi aux professionnels de l'informatique d'améliorer l'accessibilité et la sécurité des données. Mais même si vous possédez les outils et les technologies nécessaires pour construire une architecture d'entreprise efficace, il est très facile de se laisser emprisonner par des interfaces propriétaires, ce qui se traduit par des solutions isolées.

Prenons l'exemple des technologies disponibles dans le système Microsoft® Office. Windows® SharePoint® Services 3.0 permet de créer rapidement une enquête de service, mais celle-ci ne constituera pas nécessairement une solution standard, en fonction de votre entreprise. Si votre entreprise utilise ASP.NET et SharePoint comme plate-forme de collaboration Web et d'intégration de données, cette enquête fournit une solution standard. Mais si votre environnement ressemble à celui dans lequel je travaille, SharePoint n'est qu'une des nombreuses plates-formes utilisées.

Certes, SharePoint offre de nombreuses options d'intégration pour les systèmes IBM, HP, Siebel, etc. C'est assurément une bonne chose pour les utilisateurs chevronnés qui souhaitent créer des solutions ad hoc tout en maintenant le flux de données résultant dans toute une série de systèmes principaux. Cependant, si vous êtes un architecte de solutions, il existe une solution encore mieux adaptées : Infopath® 2007.

Avec Infopath 2007, qui fait partie d'Office 2007, vous pouvez séparer la logique de présentation de vos solutions de la logique de gestion des informations hébergées sur vos serveurs. Grâce à la technologie XML d'Infopath, vous pouvez générer des solutions de collecte de données adaptées aux besoins de l'entreprise. Et, pour l'essentiel, les concepteurs de formulaires d'Infopath ne nécessitent pas de connaissances poussées du XML, des services Web, des architectures de solution, d'ASP.NET ou du modèle d'objet de SharePoint.

Dans cet article, j'expliquerai comment créer des solutions de collecte de données flexibles à l'aide d'Infopath 2007, d'Office SharePoint Server 2007, et de Forms Services. Je vous montrerai également comment le XML permet de séparer la logique de présentation de la logique métier dans une architecture d'entreprise multiniveau.

Notez que lorsque je parle de la « collecte de données », je fais référence au processus de collecte d'informations provenant de sources humaines. Il y existe bien sûr d'autres moyens de collecter des données, tels que l'analyse des sources de données, mais ces méthodes automatisées sortent du cadre de cet article.

Acquisition et gestion des données

Les exigences d'acquisition de données peuvent être complexes, mais tous les processus possèdent certaines choses en commun. En traitant ces similarités dans des modules centralisés tout en gérant les exigences uniques dans des composants décentralisés, il est possible de limiter les efforts redondants, les frais de maintenance, ainsi que le coût total de possession.

Par exemple, les règlementations de conformité pour les sociétés anonymes entraînent des exigences commerciales qui se traduisent à leur tour par des stratégies de gestion des informations applicables à l'échelle de l'entreprise. Ces stratégies affectent les solutions de collecte de données par-delà les limites des services et mènent souvent à la duplication des efforts au sein de services individuels, par exemple les règles régissant la collecte d'informations d'identification personnelle collectées par un service de RH (qui gère les informations des employés) ou un service clientèle (qui gère les informations des clients). Même les processus métier de services individuels qui sont similaires, mais non apparentés, offrent des opportunités d'unification des solutions de gestion des informations.

La figure 1 illustre un exemple d'un processus métier typique. Un employé souhaitant échanger une tâche avec un collègue doit d'abord obtenir l'accord du collègue, puis l'approbation d'un responsable ou d'un coordinateur du calendrier d'attribution des tâches et enfin du superviseur. Il pourrait par exemple s'agir de deux employés qui échangent leurs horaires de travail. Bien que ces échanges surviennent dans des services différents et puissent dépendre de formulaires différents, les flux de travail et la logique de gestion des informations peuvent être répartis entre les différentes solutions de gestion des services.

Figure 1** Exemple de processus de collecte de données pouvant être partagé par plusieurs services **(Cliquer sur l'image pour l'agrandir)

Bien sûr, la consolidation des composants redondants représente une tâche gigantesque. Il n'est pas simple de procéder à des changements organisationnels à l'échelle d'une entreprise, mais grâce aux technologies Office, vous pouvez créer des fondations solides pour faciliter ces modifications. Infopath 2007 permet aux services individuels de créer des applications de formulaires qui s'intègrent dans des systèmes de gestion des informations centralisés normalisés. De son côté, SharePoint 2007 permet aux services informatiques de déléguer le contrôle administratif des collections de sites, des sites et des bibliothèques de documents à des services et des équipes individuels. Par conséquent, les équipes peuvent créer et déployer leurs propres solutions avec une intervention minimale du service informatique, tandis que ce dernier conserve le contrôle de tous les services et composants partagés, tels que les flux de travail, les stratégies de gestion des informations et les procédures de sauvegarde.

Centralisation des efforts de collecte de données

Les entreprises donnent souvent des serveurs d'applications de service aux équipes pour qu'elles puissent répondre à leurs besoins individuels de gestion des informations. La responsabilité du service informatique se limite à assurer le bon fonctionnement du matériel et du système d'exploitation, tandis que les services individuels s'occupent de tous les aspects de leurs solutions. La coordination entre les services est limitée, et le partage des informations est compliqué.

Les difficultés techniques liées à la centralisation des efforts de la collecte de données concernent principalement la sécurité, les performances, la maintenance et la prise en charge des composants personnalisés hébergés dans un environnement partagé. Par exemple, les effets d'un composant ne fonctionnant pas correctement sont isolés si les solutions individuelles sont hébergées sur des serveurs d'applications de service. Cependant, dans un environnement partagé, le mauvais fonctionnement d'un composant peut affecter les processus métier à une bien plus large échelle. Le service informatique doit donc établir des stratégies strictes en matière de déploiement et de maintenance de composants personnalisés sur les systèmes centralisés.

L'hébergement de solutions SharePoint de service sur une batterie de serveurs centrale nécessite le déploiement et la maintenance de tous les composants personnalisés de ces solutions de service sur les serveurs d'applications centraux. Une solution peut par exemple s'appuyer sur des types de champ personnalisés pour étendre l'interface utilisateur de la solution avec des listes déroulantes peuplées à partir des services Web principaux. Une autre solution peut quant à elle s'appuyer sur des composants WebPart aux mêmes fins, tandis qu'une autre utilisera les flux de travail, alors que toutes ces solutions sont écrites en code géré et déployées en tant qu'assemblys .NET Framework.

Le déplacement de ne serait-ce que quelques solutions SharePoint vers une batterie de serveurs d'applications centrale peut entraîner des difficultés de configuration et des problèmes de prise en charge. Si les assemblys doivent être déployés dans le GAC (Global Assembly Cache), la sécurité devient problématique parce que ces assemblys s'exécutent avec un niveau de confiance totale. Des composants mal programmés pourraient ouvrir le système à des attaques par injection SQL, par script intersites ou par déni de service. Vous devez vous assurer que les composants peuvent supporter la charge de travail typique ainsi que la demande maximale et les opérations de longue durée. Vous devez également vous assurer que les composants ne bloquent pas d'autres processus qui gèrent les évènements de façon synchrone et que les composants exécutent une validation des entrées fiable, afin que les utilisateurs ne puissent pas insérer de déclarations SQL ou de scripts dans les colonnes utilisées pour mettre à jour une base de données ou un système Web distant.

En bref, l'objectif est d'appliquer une configuration de serveur sécurisée et évolutive basée sur des fonctionnalités de produit standard. En vous appuyant sur des solutions réutilisables et testées à fond, vous pouvez éviter le piège consistant à créer d'innombrables composants personnalisés. Il est logique de garder le frontal décentralisé et le back-end centralisé. La clé est d'intégrer les composants d'une façon souple qui favorise la réutilisation des solutions existantes

Fractionnement de la logique métier

Donc, comment créer des solutions de collecte de données flexibles qui puissent être configurées sur vos serveurs ? La meilleure stratégie consiste à séparer l'architecture de la solution en niveaux individuels, comme illustré à la figure 2 : stockage de données, logique métier et présentation ou interface utilisateur. Á l'heure actuelle, l'interface utilisateur repose généralement sur un navigateur tandis que la logique métier réside sur des serveurs d'applications Web. Ces derniers accèdent à leur tour à des bases de données et des référentiels de données non relationnelles.

Figure 2** Solution d'entreprise typique créée sur une architecture à trois niveaux **(Cliquer sur l'image pour l'agrandir)

La logique métier inclut souvent la logique de transaction pour garantir que les transactions sont appliquées de façon atomique sur les divers systèmes de gestion de base de données. La logique métier peut également intégrer plusieurs services de niveau intermédiaire via HTTP, la mise en file d'attente de messages, les RPC, etc. L'architecture de la solution générale, cependant, reste essentiellement un modèle à trois niveaux.

Ce que la figure 2 n'illustre pas, c'est la complexité de la logique métier dans un environnement d'entreprise. Il semble que le serveur d'applications de cette illustration se concentre seulement sur l'affichage d'un formulaire basé sur un navigateur et la gestion des données soumises, mais cette représentation ne tient pas compte des flux de travail, de la conformité ou des exigences de gestion des informations. Pour répondre à ces exigences, vous devez fractionner la logique métier en deux : la logique de présentation et la logique de gestion des informations. Cela vous permet de combiner les composants de niveau intermédiaire en fonction des besoins sans recréer des composants à partir de zéro pour chaque solution.

La figure 3 illustre cette architecture. Le contenu ou les données sont au centre, entourées par la logique de gestion des informations, qui régit le contenu tout au long de son cycle de vie. La logique de présentation s'interface avec la logique de gestion des informations pour fournir l'accès aux données via l'interface utilisateur.

Figure 3** Séparation de la logique de présentation de la logique de gestion des informations **

Collecte et traitement du XML

Dans les environnements orientés services (SOA, Service Oriented Architecture), le XML est la norme dominante utilisée pour définir et partager les données et les structures de données entre les composants. Le XML constitue donc un bon choix pour créer une interface entre les composants de présentation et de gestion des informations.

La communication doit fonctionner de deux façons : vous devrez traduire le code XML en document lisible par le navigateur, ainsi qu'en document XML généré par le formulaire. Jusqu'à récemment, la création d'applications de formulaires en XML nécessitait des compétences de programmation approfondies. C'était surtout le cas lorsque les données XML résultantes devaient correspondre à un schéma d'entreprise pour faciliter l'échange d'informations entre plusieurs sites.

Infopath 2007 facilite considérablement le développement des formulaires XML. Si une compréhension détaillée du XML est utile, les créateurs de formulaires et les utilisateurs chevronnés n'ont plus besoin d'être des génies du XML pour créer des applications de formulaires basées sur XML. Le créateur de formulaires importe simplement un document XML ou un schéma XML dans Infopath et mappe ensuite les nœuds d'attribut et d'élément individuels de cette source de données aux champs du formulaire. Un créateur de formulaires peut également partir d'un service Web ou d'une base données SQL Server®, ou encore d'un modèle vierge et créer un formulaire à partir de zéro, tandis qu'Infopath crée automatiquement le schéma sous-jacent et les liaisons de données en arrière-plan.

La standardisation des formulaires à l'aide des schémas Infopath et XML possède plusieurs avantages. S'ils disposent déjà d'un schéma XML bien défini, les créateurs de formulaires et les développeurs de composants de flux de travail et de gestion des informations peuvent créer des solutions suivant les mêmes structures de données. Si un créateur de formulaires part de zéro, les développeurs doivent attendre que le formulaire soit terminé pour voir comme il affectera les structures de données sous-jacentes. Une fois que ces dernières sont définies, les futures solutions, comme les modèles de formulaire, peuvent réutiliser les flux de travail et les composants de gestion des informations existants s'ils reposent sur les mêmes structures de données. Par ailleurs, les futurs flux de travail et composants de gestion des informations peuvent collaborer ensemble avec les formulaires et données existants. Si vous créez vos solutions de collecte de données à l'aide de schémas standard établis, les résultats deviennent encore plus flexibles. En fait, ces solutions seront compatibles avec toutes les solutions créées par d'autres entreprises qui utilisent les mêmes schémas.

J'ai créé un schéma DirectReports simple qui associe des employés avec des responsables. Les responsables peuvent utiliser le formulaire résultant pour évaluer leurs rapports directs. Vous pouvez retrouver le schéma, le formulaire et un fichier readme.htm contenant les instructions pour recréer le formulaire dans le dossier Direct Reports du téléchargement qui accompagne cet article, disponible à l'adresse technetmagazine.com/code08.aspx. Le formulaire est basique, mais il illustre le concept général.

Un point très important à noter : je n'ai pas créé de logique de validation dans Infopath, mais Infopath exige quand même que l'ID et les adresses de messagerie de l'utilisateur soient entrés dans un format spécifique (domaine\compte et destinataire@domaine.tld). Á défaut, le document XML résultant ne sera pas valide. Cela est dû au fait que le schéma XML définit ces formats. Vous pouvez enregistrer le formulaire avec des données non valides mais vous ne pouvez pas l'envoyer, comme illustré aux figures 4a et 4b. (J'ai ajouté une règle d'envoi factice au formulaire pour que vous puissiez le tester sans envoyer les données vers un emplacement réel). La validation d'Infopath 2007 vérifie automatiquement que le formulaire est entièrement rempli et qu'il ne contient pas ce type d'erreurs.

Figure 4a** Des erreurs de validation empêchent l'utilisateur d'envoyer un formulaire **(Cliquer sur l'image pour l'agrandir)

Figure 4b** Message d'erreur généré **(Cliquer sur l'image pour l'agrandir)

Le schéma XML sert de contrat entre la logique de présentation et la logique de gestion des informations. Infopath verrouille le schéma si le créateur de formulaires ne peut pas modifier intentionnellement les structures de données. Ceci est important parce que la modification d'un schéma XML établi peut potentiellement interrompre le fonctionnement des solutions d'entreprise existantes, telles que des modules de flux de travail que vous souhaitez utiliser avec le nouveau modèle de formulaires.

Infopath fournit une abondance de fonctionnalités permettant de créer une logique de présentation avancée dans les applications de formulaires. Vous pouvez utiliser des données issues de fichiers XML, de services Web, de bibliothèques et listes SharePoint, de bases de données, etc. pour intégrer des valeurs par défaut significatives. Vous pouvez modifier par des règles les valeurs de champ en fonction de la sélection de l'utilisateur, inclure une logique de validation, ajouter un code géré pour les exigences de personnalisation les plus avancées, et utiliser Forms Services pour rendre le modèle de formulaire accessible via le Web. Dans tous les cas, les données du formulaire rejoignent finalement la logique de gestion des informations en tant que document XML conforme à une définition de schéma.

Utilisation du XML ou des métadonnées

Vous vous demandez peut-être si vous devez appliquer la logique de gestion des informations directement au document XML envoyés ou s'il vaut mieux utiliser un analyseur qui extrait les informations nécessaires dans les métadonnées. SharePoint prend en charge les deux approches. Les développeurs sont habitués à travailler directement avec les documents XML, mais les métadonnées offrent plus de flexibilité.

Pour démontrer cela, j'ai créé un service Web simple qui analyse un document XML transmis à partir du formulaire Direct Reports illustré à la figure 4a. (Le code source, les fichiers d'installation et un fichier readme.htm contenant des instructions détaillées sont disponibles dans le dossier XMLParsingWebService du téléchargement d'accompagnement). Le service Web lit simplement l'ID d'utilisateur du responsable à partir du document XML, fractionne l'ID d'utilisateur en parties domaine et nom d'utilisateur, crée un message en basé sur ces parties et génère ensuite une exception générique pour renvoyer et afficher les informations traitées sous forme d'un pseudo-message d'erreur dans le formulaire d'Infopath. Il s'agit là d'une façon pratique d'ouvrir une boîte de dialogue contextuelle dans Infopath après l'envoi de données. Le service Web fonctionne très bien, mais si vous modifiez la source de données sous-jacente (par exemple, si vous renommez l'élément OrgPerson en Manager dans DirectReports.xsd et mettez à jour le formulaire Infopath avec le nouveau schéma comme présenté dans le fichier readme.htm), le service Web échoue. Mais cela ne devrait pas vous surprendre. Le document XML est maintenant différent, et l'ancienne expression XPath permettant d'accéder à l'élément d'ID de connexion n'est plus valide. Les schémas de OrgPerson et Manager sont presque identiques, les formulaires Infopath sont identiques et les résultats de traitement souhaités sont les mêmes, mais même si les différences sont minimes, vous devez toujours déployer et maintenir des services Web dupliqués.

Cette approche n'est pas intéressante si vous souhaitez réduire la quantité de code personnalisé sur vos serveurs d'applications. En revanche, la mappage des nœuds XML sur les champs de métadonnées et l'exécution du traitement basé sur les métadonnées vous permet d'utiliser les mêmes flux de travail et logique de gestion des informations pour les structures de données similaires, bien que les schémas XML soient différents. Vous devez simplement vous assurer que l'élément enfant est mappé sur le bon champ de métadonnées et que le format des données répond aux exigences de traitement. Vous pourrez ensuite réutiliser le code existant.

Le mappage des nœuds XML sur les champs de métadonnées est semblable à la liaison des nœuds XML aux contrôles de l'interface utilisateur dans un formulaire Infopath, comme illustré à la figure 5. Dans SharePoint, les champs de métadonnées correspondent aux colonnes définies au niveau du site ou de la liste et référencées dans les définitions de type de contenu. Les types de contenu définissent les caractéristiques des éléments de contenu, tels quel les champs de métadonnées, les flux de travail et les formulaires. Pour maintenir la synchronisation des champs de métadonnées d'un type de contenu avec les nœuds correspondants dans le document XML associé, SharePoint s'appuie sur un analyseur XML intégré qui exécute la promotion et la rétrogradation d'une propriété. Pendant la promotion d'une propriété, l'analyseur XML extrait les valeurs de nœud d'un document XML dans les colonnes correspondantes de la bibliothèque de documents. La rétrogradation d'une propriété constitue le processus inverse, dans lequel des valeurs de colonne sont prises de la bibliothèque de documents et réécrites dans le document. Le plus important, c'est que l'analyseur XML maintient la synchronisation des champs de métadonnées avec les nœuds XML correspondants.

Figure 5** Mappages de schéma XML entre Infopath et SharePoint **(Cliquer sur l'image pour l'agrandir)

Lorsque vous utilisez le modèle d'objet de SharePoint, vos composants WebPart, vos flux de travail et votre logique de gestion des informations peuvent fonctionner avec les champs de métadonnées ou avec les documents XML sous-jacents. La modification de la valeur d'un champ de métadonnées mappé modifie la valeur de nœud dans le document XML, et inversement. Toutefois, le fait de travailler directement sur le document XML couple étroitement la logique métier avec le schéma XML. En revanche, les champs de métadonnées mappés augmentent la réutilisabilité du code. Évidemment, vous devez choisir l'approche qui correspond à votre environnement, mais globalement, les solutions SharePoint qui reposent sur les champs de métadonnées offrent davantage de flexibilité et d'opportunités pour la réutilisation de code.

Pour illustrer la façon dont SharePoint associe les nœuds XML aux champs de métadonnées, j'ai inclus une fonctionnalité SharePoint dans les ressources associées pour configurer une bibliothèque de documents personnalisée (voir le fichier OrgPersonContentType.xml situé dans le dossier OrgPersonLib du téléchargement d'accompagnement). Le type de contenu d’OrgPerson référence quatre champs : UserID, FullName, EMail et Direct_x0020_Reports. FullName et Email sont des champs prédéfinis. UserID et Direct_x0020_Reports sont des champs personnalisés définis dans OrgPersonSiteColumns.xml.

Les définitions de champ sont assez simples. Il est possible de lier directement des champs aux nœuds XML dans les définitions de champ, mais il est également possible de remplacer cette information dans les types de contenu. J'ai décidé d'utiliser cette deuxième technique parce que cela me permet d'utiliser les champs personnalisés dans des types de contenu non apparentés aux documents XML, ainsi que dans des types de contenu qui reposent sur des structures XML différentes. Le type de contenu d’OrgPerson lie les champs de métadonnées aux nœuds XML qui correspondent dans leur organisation au schéma d’OrgPerson que j'ai abordé plus haut. Il y a également un fichier AdditionalContentTypes.xml qui définit d'autres types de contenu liant les mêmes champs de métadonnées aux différents nœuds XML. Vous pouvez voir les différences en examinant les expressions XPath dans les attributs Node (Nœud).

Les bibliothèques de documents du type OrgPersonLib peuvent enregistrer différents types de documents XML tout en exposant les valeurs de nœud dans les mêmes colonnes de bibliothèque. Cette technique de mappage simple vous permet également de réutiliser la logique de flux de travail et de gestion des informations puisque les quatre types de contenu (OrgPerson, Manager, Supervisor et User) référencent un jeu de champs de métadonnées commun.

La figure 6 illustre l'élément FieldRef du type de contenu OrgPerson pour Direct_x0020_Reports, qui mappe le champ sur les nœuds d'ID d'utilisateur de Direct Reports conformément à l'expression XPath /OrgPerson/direct-report/user-id. Puisque le document XML peut inclure de plusieurs entrées de rapport direct, il est important que vous spécifiiez un attribut Aggregation (Agrégation). Celui-ci définit la façon dont l'analyseur de XML gèrera la collection de valeurs renvoyée. Si vous omettez cet attribut, l'analyseur de XML extrait uniquement la première valeur de nœud. Les valeurs d'agrégation prises en charge sont sum (somme), count (compte), average (moyenne), min, max, merge (fusion), plain text (texte brut), first (premier) et last (dernier).

Figure 6** Champ de métadonnées mappés sur une expression XPath **(Cliquer sur l'image pour l'agrandir)

Tous les types de contenu de l'exemple utilisent la page standard upload.aspx en tant que DocumentTemplate pour que vous puissiez télécharger les fichiers XML vers la bibliothèque de documents lorsque vous cliquez sur le bouton Nouveau dans l'interface utilisateur SharePoint. Tant que vous téléchargez des fichiers possédant une extension .xml, SharePoint invoquera automatiquement l'analyseur XML intégré (à l'exception des fichiers WordProcessingML, pour lesquels SharePoint invoque un analyseur WordProcessingML). L'analyseur XML examine le fichier .xml téléchargé pour déterminer le type de contenu associé. Il le fait pour pouvoir extraire les valeurs de nœud des emplacements spécifiés dans les définitions de champ et exécuter la promotion de la propriété. (Vous pouvez vérifier ce processus en téléchargeant le fichier OrgPerson.xml inclus dans le dossier OrgPersonLib\XMLFiles.) La structure de ce document XML correspond aux expressions XPath spécifiées dans la définition de type de contenu d'OrgPerson. En conséquence, SharePoint extrait les données du fichier .xml, écrit les données dans les colonnes de bibliothèque correspondantes et affiche les données dans la page EditForm.aspx pour que vous puissiez vérifier et mettre à jour les propriétés du document qui ne sont pas marquées en lecture seule. La figure 7 illustre le formulaire EditForm.aspx avec les données extraites d'OrgPerson.xml.

Figure 7** Formulaire EditForm.aspx avec les données extraites **(Cliquer sur l'image pour l'agrandir)

Si vous modifiez la valeur des champs UserID, FullName ou EMail dans EditForm.aspx, SharePoint exécute une rétrogradation de propriété pour modifier les valeurs de nœud dans le document XML sous-jacent. Notez cependant que SharePoint n'applique pas de restriction du Schéma XML à moins que vous implémentiez vous-même la logique requise dans le formulaire.

SharePoint n'exécute pas non plus la logique de présentation d'une application de formulaires. Par exemple, lorsque vous modifiez le champ UserID, SharePoint ne valide pas que la nouvelle valeur est conforme aux conventions NetBIOS, pas plus qu'il ne met automatiquement à jour les champs FullName et EMail pour qu'ils correspondent à la nouvelle sélection. C'est pourquoi, si la modification d'un champ individuel peut provoquer des incohérences, vous devez indiquer la colonne correspondante dans la définition de type de contenu comme étant en lecture seule. Ceci oblige l'utilisateur à utiliser l'application de formulaires, par exemple Infopath, pour mettre à jour les données. Ainsi, l'analyseur XML appliquera toutes les modifications du document XML aux champs de métadonnées correspondants dans SharePoint.

Dans l'exemple OrgPersonLib, vous pouvez télécharger n'importe quel fichier .xml à partir du dossier OrgPersonLib\XMLFiles. Les fichiers .xml utilisent des structures de données très différentes, mais SharePoint reconnaît les types de contenu et applique les valeurs de nœud correctes dans les colonnes du site. Cela vient du fait que j'ai utilisé une instruction de traitement dans les fichiers XML pour associer les documents XML à leurs types de contenu correspondants. Cependant, le fichier OrgPerson.xml n'inclut pas ces informations, mais ce n'est pas un problème. Si SharePoint ne peut pas associer un document XML avec un type de contenu via une instruction de traitement ou le modèle de document, SharePoint utilise le type de contenu par défaut. Dans le cas d'OrgPersonLib, il s'agit du type de contenu d'OrgPerson, et le document XML est donc correctement analysé.

La figure 8 illustre comment vous pouvez associer explicitement un document XML avec un type de contenu. L'instruction de traitement MicrosoftWindowsSharePointServices définit le ContentTypeID comme 0x010100668E393E4F0EFF4294DBD202D5D8321D. Il se trouve qu'il s'agit de l'ID du type de contenu User, comme défini dans AdditionalContentTypes.xml.

Figure 8** Traitement des instructions et des données XML du fichier exemple User.xml **(Cliquer sur l'image pour l'agrandir)

L'analyseur XML traite l'instruction de traitement MicrosoftWindowsSharePointServices et écrit la valeur de ContentTypeID dans le champ de métadonnées ContentType. Tous les types de contenu SharePoint partagent ce champ de métadonnées parce qu'il est défini au niveau de la racine dans le type de contenu Système. Si vous ouvrez le fichier fieldswss.xml (situé dans le dossier %CommonProgramFiles%\MicrosoftShared\WebServerExtensions\12\Template\Features\Fields) sur un serveur SharePoint et que vous recherchez « MicrosoftWindowsSharePointServices », vous verrez comment SharePoint associe l'instruction de traitement avec le champ ContentType. L'attribut PITarget pointe vers MicrosoftWindowsSharePointServices (l'instruction de traitement), et PIAttribute pointe vers ContentTypeID (qui contient l'ID du type de contenu User).

Associations de types de contenu dans Infopath

Les détails techniques de l'analyse XML et des associations de types de contenu intimident de nombreux concepteurs de formulaires, mais Infopath 2007 s'occupe de tous les petits détails. Le fichier readme.htm qui accompagne l'exemple OrgPersonLib inclut des instructions pour publier le modèle de formulaire de Direct Reports dans SharePoint et créer un type de contenu qui crée un lien vers les mêmes champs de métadonnées (UserID, FullName, EMail et Direct_x0020_Reports). Vous pouvez facilement ajouter le nouveau type de contenu à la bibliothèque de documents d’OrgPersonLib via l'interface utilisateur SharePoint. Mais le nouveau type de contenu pointe également vers le modèle de formulaire Infopath comme modèle de document pour invoquer l'application de formulaires lors de la mise à jour des documents XML existants. La figure 9 illustre la façon dont l'Assistant de publication d'Infopath simplifie le mappage de propriété entre les valeurs de nœud XML et les colonnes de site SharePoint. Là encore, si vous associez les valeurs de nœud avec les colonnes de site existantes, vous pourrez réutiliser les composants SharePoint existants.

Figure 9** Mappage de propriété dans Infopath 2007 **(Cliquer sur l'image pour l'agrandir)

Conclusion

Ressources supplémentaires en ligne

• Blog de l'équipe Infopath 2007
• Spécifications et développement de schémas XML W3C
• Introduction aux schémas XML
• Flux de travail dans Office SharePoint Server 2007
• InfoPath 2007 Forms Services

Grâce aux technologies disponibles dans Office, les architectes d'entreprise peuvent créer des solutions de collecte de données qui favorisent la réutilisation de code et l'échange d'informations. Infopath 2007 permet aux services de créer des solutions capables d'extraire des informations de diverses sources, et les données peuvent être ensuite envoyées à divers systèmes, tels que SharePoint. SharePoint fournit également aux développeurs un jeu complet de services Web et d'interfaces pour créer des composants de flux de travail et de gestion des informations. En hébergeant ces composants sur des serveurs SharePoint centralisés, les services possèdent ensuite l'infrastructure dont ils ont besoin pour créer leurs applications individuelles.

Par ailleurs, les services individuels peuvent créer plus rapidement leurs solutions de collecte de données. La conformité aux règlementations et les autres exigences commerciales globales peuvent être gérées à un niveau interservices, et la facilité de gestion ainsi que la fiabilité de l'environnement informatique augmentent avec l'utilisation d'un nombre moins élevé de composants personnalisés sur les serveurs d'applications.

Keith Deshaies est rédacteur technique indépendant et analyste informatique pour une grande entreprise de télécommunications. Il est spécialiste des technologies Microsoft Office et SharePoint, et est membre de la Society for Technical Communication (STC).

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