Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Open XML

Des standards pour communiquer ensemble

Open XML et les schémas métier - Quatrième et dernière partie - Les custom XML parts

Le support des custom XML parts au sein d’un package OPC (Open Packaging Conventions) est nouveauté de open XML . Grâce à cette fonctionnalité, il est possible de placer n’importe quel fichier XML existant au sein d’un document Open XML et ce fichier XML peut être ou non exposé à l’utilisateur en fonction de son choix. Il n’y a donc pas besoin de changer quoi que ce soit à son fichier XML, ni au balisage de son document et il n’est pas nécessaire de faire interférer son balisage customisé et le balisage de son document au sein du même part ou du même fichier (comme bien souvent dans les scénarios de balisage customisé).

Open XML permet d’utiliser les messages XML qui sont utilisés aujourd’hui – les mêmes que ceux qui sont générés par ses logiciels métier, les même qui sont échangés entre ses systèmes à travers des services Web – directement au sein des documents, comme ils sont, sans y changer quoi que ce soit. Il n’y a donc pas à écrire de code pour extraire des données métiers du balisage d’un document car les deux n’ont jamais été mixés ensemble.

Ceci permet la mise en œuvre d’une interopérabilité simple et puissante. Une telle interopérabilité n’est, en l’état actuel des choses, disponible qu’au sein d’un format standardisé tel qu’Open XML qui utilise une convention de packaging standardisé et flexible telle qu’OPC afin de permettre l’ajout de n’importe quel type de contenu à un document de telle façon qu’il n’y ait aucune interférence avec l’architecture du document lui-même (ces concepts ne sont pas d’ailleurs limitées aux données XML mais nous nous limiterons à ce domaine dans le présent document au sein duquel nous nous focaliserons sur la notion de XML part).

Comment cela fonctionne-t-il ?

Jetons un œil à la façon donc fonctionnent les XML parts customisés en commençant par le commencement. Nous allons télécharger une instance typique de données XML depuis un site Web public et l’inclure dans un document Open XML et démontrer quelques-unes des choses que l’architecture d’Open XML permet.

Pour cela, et à fin d’exemple, nous avons effectué une recherche sur le Web sur la chaîne de caractères « XML instance sample » et trouvé la page suivante : http://exchangenetwork.net/schema/WQX/1/WQX_XMLExample_v1.0.xml. C’est un exemple de document XML utilisé par « Exchange Network », un organisme qui aide les Etats américains et l’agence américaine de protection de l’environnement à échanger des informations ; nous allons utiliser ce document pour constituer nos données d’exemple.

Un des concepts clé du support des schémas customisés par Open XML est le fait que l’on peut utiliser n’importe quel schéma et n’importe quelle instance XML ce qui signifie que la source de ces données XML et la façon dont elles sont structurées n’ont aucune importance. Ce qui va être démontré dans la suite s’applique donc à n’importe quel fichier XML convenablement formé. Cet exemple a été choisi car il est plus compliqué que la plupart des exemples que l’on peut trouver sur le Web et qu’il constitue donc une approche à peu près réaliste d’un document XML. Voici un aperçu de ce qu’il contient :

image

 

Sauvegardons ce fichier XML en un fichier appelé item1.xml, que nous allons intégrer au sein d’un document Open XML sous la forme d’un XML part customisé et le faire correspondre à quelques content controls.

Ajouter un XML part customisé à un document

On doit d’abord placer les données au sein d’un document Open XML sous le forme d’un XML part customisé. Ceci nécessite un peu d’édition, ce que l’on peut faire avec Notepad et le support des fichiers ZIP qui est offert en standard avec Windows Vista. Si l’on utilise un autre environnement, il est possible d’utiliser n’importe que éditeur de texte et n’importe quel outil permettant de décompresser un fichier ZIP.

Voici les étapes concernées :

  1. Créer un fichier de traitement de texte Open XML. Ceci peut être obtenu en tapant quelques mots au sein de Word 2007 et en sauvegardant ce contenu au format par défaut sous le nom de fichier sample.docx.
  2. Renommer ce document en .ZIP et placer une copie des données XML (item1.xml) dans un répertoire appelé customXml au sein du package ZIP.
  3. Ajouter la ligne suivante à la partie relations (document.xml.rels) dans le répertoire word\_rels : <Relationship Id="myCustomXmlRelationship" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/customXml" Target="../customXml/item1.xml" />
  4. Renommer le document à nouveau en .DOCX.

Nous avons maintenant un document qui contient un XML part customisé. Nous ne renterons pas ici dans tous les détails afin de garder à l’exemple sa qualité de simplicité.

Si l’on ouvre ce document (sample.docx) avec Word 2007, qu’on le modifie et qu’on le sauvegarde, le XML part customisé fait partie du document mais on ne le voit pas dans l’interface homme – machine de Word car on n’a pas encore choisi d’exposer de quelque manière que ce soit les données métier qu’il contient maintenant. Mais Word suit les règles des spécifications Open XML ce qui fait que lorsqu’il sauvegarde un document, il a maintenant réalisé un certain nombre de choses automatiquement :

  • Il a créé un custom XML properties part  pour chacun des éléments XML customisés, appelé itemProps1.xml dans le répertoire customXml.
  • Il a ajouté une référence de schéma vers le custom XML properties part, indiquant le schéma pour les données métier considérées.
  • Il a affecté un GUID au XML part customisé, qui est également stocké dans le custom XML properties part. Ceci est très important car ce GUID sera utilise pour identifier de manière unique le XML part customisé quand on fera correspondre les éléments de présentation aux nœuds XML des données métier.
  • Word aime aussi énumérer les relations sous la forme rId1, rId2, etc. et a donc renommé myCustomXmlRelationship en rId1 ou quelque-chose d’approchant. Les identifiants de relations n’ont pas d’importance ici car il s’agit d’une relation implicite (il faut garder à l’esprit qu’il n’y a encore rien dans le corps du document qui fasse référence au XML part customisé.

Voici le contenu du fichier itemProps1.xml du document d’exemple que l’on a créé :
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ds:datastoreItem ds:itemID="{548E2E51-45D3-44E4-8845-1542F6638E2D}"
xmlns:ds="http://schemas.openxmlformats.org/officeDocument/2006/customXml">
    <ds:schemaRefs>
        <ds:schemaRef ds:uri="http://www.exchangenetwork.net/schema/wqx/1"/>
    </ds:schemaRefs>
</ds:datastoreItem>

Notre XML part customisé est maintenant inclus dans le document et tous les détails nécessaires sont en place au sein du document afin d’assurer que ce part restera intact au travers des différentes éditions. Ceci est utile pour de nombreux scénarios – par exemple la société Mindjet utilise cette technique pour inclure ses propre schémas propriétaires au sein d’un document Open XML et permettre ainsi une interopérabilité par aller et retour avec Word. Un consommateur de document Open XML (Word par exemple) peut complètement ignorer ces XML parts customisés et il n’y a rien dans le corps du document qui y fasse référence, de telle façon qu’il n’y ait aucun impact sur la logique de rendu ou de présentation.

Ajout de balises de structuration de document et mise en correspondance des données

Ensuite, il nous faut exposer les données métier au sein du document lui-même. Cette opération est facile à faire : on peut exposer les nœuds de ses données métier en utilisant une correspondance dans les deux sens qui permet à l’utilisateur d’éditer les données métier dans le document lui-même.

L’étape suivant consiste à ajouter quelques balises dans le document structuré. Pour cela on utilise l’onglet « Developer » (qu’il faut mettre en service sous les options de Word si cet onglet n’est pas affiché dans le « Ruban » puisque cette option est hors service par défaut – cf. plus haut). Ici, on a créé une table et entré du texte dans la colonne de gauche (décrivant ainsi quelques nœuds XML que l’on a sélectionné au hasard depuis nos données d’exemple) et ensuite inséré un simple contrôle de contenu textuel (c’est-à-dire une balise de document structuré) dans la colonne de droite pour chaque ligne :

image

L’étape suivante consiste à sauvegarder ce document et à ajouter l’élément de mise en correspondance des données qui connecte chaque balise du document structuré à un nœud du XML part customisé. 

L’élément y est appelé dataBinding et se trouve dans la section sdt properties. Voici, par exemple, l’élément inséré pour faire correspondre le premier contrôle de contenu à un nœud du XML part customisé :

<w:dataBinding w:prefixMappings="xmlns:ns0='http://www.exchangenetwork.net/schema/wqx/1'" w:xpath="/ns0:WQX[1]/ns0:Organization[1]/ns0:OrganizationDescription[1]/ns0:OrganizationFormalName" w:storeItemID="{548E2E51-45D3-44E4-8845-1542F6638E2D}" />

Il faut noter que cet élément spécifie trois choses :

  1. Le schéma associé avec le XML part customisé.
  2. L’expression XPath qui pointe vers le nœud que l’on fait correspondre dans le XML part customisé.
  3. Le GUID qui identifie le XML part customisé (il peut y avoir plusieurs XML part customisés dans un seul document si nécessaire).

Typiquement, on doit écrire ces éléments dataBinding dans le document à partir du code de son logiciel métier (dans cet exemple, ceci a été réalisé à l’aide de Notepad, mais cela reste un peu délicat). Une bonne solution pour ajouter des mises en correspondances est d’utiliser le Content Control Toolkit qui est disponible en téléchargement gratuit depuis Codeplex.

image

Maintenant, on dispose d’un document lié aux données avec une mise en correspondance bidirectionnelle entre les éléments de présentation du document (les content controls) et les nœuds du XML part customisé. Ce document fournit un « frontal » pour les données métier qui sont ainsi exposées de telle façon que lorsqu’un utilisateur change une valeur dans un content control, le nœud correspondant au sein des données métier est mis à jour. Réciproquement, les développeurs peuvent facilement remplacer le XML part customisé (avec n’importe quel environnement qui supporte les packages ZIP – il n’y a aucun balisage Open XML nécessaire) et ainsi peupler le document avec de nouvelles données.

L’utilisateur peut modifier l’apparence du document comme il le désire, indépendamment de l’architecture de mise en correspondance des données car ce document dispose d’une véritable séparation entre la présentation et les données : il n’y a aucune balise Open XML dans le XML part customisé et aucune balise non Open XML dans le corps du document. Tout ceci peut être réalisé avec n’importe quel fichier XML, en provenance de n’importe quelle source en utilisant n’importe quel schéma (ou par de schéma du tout – en fait, le schéma est optionnel et n’est pas nécessaire pour réaliser ce qui est effectué ici).

Afin de clarifier l’ensemble des notions que l’on vient de parcourir, le schéma ci-dessous résume l’architecture générique d’un document Open XML :

image

 

Conclusions

Ce que nous venons d’évoquer plus haut représente un aperçu rapide de la puissance des XML parts customisés au sein des documents Open XML. L’exemple que l’on a utilisé pour illustrer ces fonctionnalités avait pour but essentiel de démonter que Open XML peut travailler avec l’importe quel schéma, y compris les schémas métier déjà utilisés dans les entreprises et tous ceux qui pourront y être développés dans le futur.

Une telle approche est de nature à favoriser l’interopérabilité verticale que l’on a définie dans un post précédent afin de répondre aux besoins croissants des entreprises d’utiliser des formats de fichiers centrés sur les données contenues dans ces documents afin de pouvoir leur faire jouer un rôle plein et entier au sein des processus métier de l’entreprise.

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: vendredi 8 juin 2007 21:25 par Polo

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01