Générer du XML

Version imprimable

28/12/2013, 13h03
Franck.H

Générer du XML

:salut:

Pour le boulot, il faudrait que je génère des fichiers XML en tenant compte d'un schéma (exemple) tout en y intégrant des données. Ce que je voulais savoir, c'est s'il existe une bibliothèque permettant de générer tout cela ou bien s'il faut le faire à l'ancienne ?

Je préfère poser la question avant d'entreprendre une telle tâche car c'est un gros dossier: créer un fichier qui soit valide (le fichier ne pourra être importé au niveau du receveur seulement s'il passe l'étape de validation par rapport au scénario d'échange de données) et avec les bonnes données récupérées un peu partout sur nos bases de données Oracle.

:merci:
28/12/2013, 13h38
plume13

Yes, of course ! XDocument :ccool:
28/12/2013, 14h05
Franck.H

:merci:

Mais est-ce que XDocument permet également d'ajouter l'en-tête du fichier ? Les exemples sont un peu pourris sur la MSDN (comme d'habitude j'dois dire) et ils disent vraiment mais alors vraiment rien du tout, un bout de code, une ligne de texte, le rendu final et basta.
28/12/2013, 14h08
DonQuiche

XDocument peut servir à valider le document vis-à-vis du schéma mais c'est tout. Pour l'écriture elle-même on en reste à devoir utiliser XmlWriter ou les attributs de sérialisation XML.

Fort heureusement MS fournit xsd.exe, un outil en ligne de commande capable de générer des classes C# correspondant au schéma fourni.
28/12/2013, 14h12
Franck.H

Citation:

Envoyé par DonQuiche

XDocument peut servir à valider le document vis-à-vis du schéma mais c'est tout. Pour l'écriture elle-même on en reste à devoir utiliser XmlWriter ou les attributs de sérialisation XML.

Fort heureusement MS fournit xsd.exe, un outil en ligne de commande capable de générer des classes C# correspondant au schéma fourni.

A voir car les fichiers que je dois générer comportent toujours une bonne quantité de données et donc de bloc complet qui sont facultatif il faut donc que j'ai un contrôle vraiment total sur la création de mes fichiers !
28/12/2013, 14h24
DonQuiche

Et ce que tu dois faire ne pourrait pas être accompli par l'ajout de nouvelles propriétés aux objets avec leurs propres attributs de sérialisation XML ? Au pire le code généré par XSD serait un bon point de départ.

Pour commencer es-tu familier de ces attributs ?
28/12/2013, 14h27
Franck.H

Citation:

Envoyé par DonQuiche

Et ce que tu dois faire ne pourrait pas être accompli par l'ajout de nouvelles propriétés aux objets avec leurs propres attributs de sérialisation XML ? Au pire le code généré par XSD serait un bon point de départ.

Pour commencer es-tu familier de ces attributs ?

Je n'y connais strictement rien du tout dans ce domaine que je vais découvrir et le pire, c'est que je dois être opérationnel pour fin janvier au plus tard car après je dois générer toute une année d'analyses et envoyer à différentes agences de surveillance de l'eau (je travaille dans le domaine de l'assainissement).
28/12/2013, 14h44
Franck.H

Je vous joint ici un guide qui me permettra de savoir ce qui est obligatoire et facultatif, faut le parcourir vite fait juste pour voir le style de fichier que je dois générer, pour chaque partie, il y a un petit schéma dont les cadre pointillés sont des blocs facultatifs dont je fournirais sans doute certains mais pas d'autres et ça va également en profondeur car pour chaque bloc facultatif qu'on ajoute il y a certaines données obligatoires et d'autres non... et ainsi de suite :aie:

Voilà ce à quoi je vais devoir faire face !
28/12/2013, 15h13
DonQuiche

D'accord, je vois ton problème.

1) En utilisant XmlSerializer et les attributs, tu peux adjoindre à chaque propriété à sérialiser un booléen disant si oui ou non le champ doit être sérialisé. Par exemple pour une propriété "string Nom" tu places à côté une propriété "bool NomSpecified" avec l'attribut XmlIgnore. Le suffixe "specified" est automatiquement reconnu.

2) Tu ne peux pas simplement laisser tes champs à "xsi:null" ? Ou avoir des balises avec un contenu vide dans le cas de listes (par exemple <personnes></personnes>) ? Au pire si ce genre de choses n'est jamais légal, alors tu peux les virer par un post-traitement.
28/12/2013, 15h18
Franck.H

Citation:

Envoyé par DonQuiche

1) En utilisant XmlSerializer et les attributs, tu peux adjoindre à chaque propriété à sérialiser un booléen disant si oui ou non le champ doit être sérialisé. Par exemple pour une propriété "string Nom" tu places à côté une propriété "bool NomSpecified" avec l'attribut XmlIgnore. Le suffixe "specified" est automatiquement reconnu.

Comme dit, je n'y connais rien du tout à la sérialisation xml et d'ailleurs pourquoi parler de sérialisation ? Je ne veux pas faire des objets je veux créer un fichier à partir de différents DataSet que je remplirais au préalable grâce aux procédures stockées en place.

Citation:

Envoyé par DonQuiche

2) Tu ne peux pas simplement laisser tes champs à "xsi:null" ? Ou avoir des balises avec un contenu vide dans le cas de listes (par exemple <personnes></personnes>) ? Au pire si ce genre de choses n'est jamais légal, alors tu peux les virer par un post-traitement.

Non, un champs vide = fichier non validé :aie: Chaque balise que j'ajoute doit contenir une valeur ou bien je n'ajoute pas la balise.

Ca va à un point où j'ai une fois reçu un fichier de ce genre à importer sur nos bases de données dont les SIRET n'étaient pas conformes et le programme de validation l'a détecté alors un champs vide... mon dieu non :aie:
28/12/2013, 15h38
DonQuiche

Citation:

Envoyé par Franck.H

Comme dit, je n'y connais rien du tout à la sérialisation xml et d'ailleurs pourquoi parler de sérialisation ? Je ne veux pas faire des objets je veux créer un fichier à partir de différents DataSet que je remplirais au préalable grâce aux procédures stockées en place.

Dans la mesure où ta question était posée sur le forum dotnet, je suis parti du principe que tes données étaient sous formes d'objets dotnet.

Si le but est d'exporter une base de données en XML, alors l'idéal est de chercher les outils du SGBD lui-même. Tous ont leurs propres outils pour exporter du XML. Au besoin s'il est impossible de spécifier ton propre schéma, on peut toujours utiliser une transformation XML (XSLT) pour passer d'un schéma à l'autre.

Et si pour une raison ou une autre il te fallait vraiment travailler au niveau de dotnet depuis tes datasets plutôt que depuis la DB elle-même, alors les datasets ont une méthode WriteXML qui utilisera un schéma créé à la volée et il te faudra ensuite avoir recours à une XSLT.

Enfin si pour telle ou telle raison cette approche ne convenait pas non plus et que tu en sois réduit à faire l'export contrôlé par C#, alors soit tu utilises manuellement XmlWriter, soit tu crées des objets à la volée et tu utilises XmlSerializer.
28/12/2013, 15h48
Franck.H

Oui je sais, j'ai le choix d'où mon problème car je préfère travailler avec DotNet (VB ou C# je m'enfiche) plutôt que la DB elle-même car au final dans l'application, les différents chefs de secteurs sélectionnerons leur secteur, les stations pour lesquelles ils veulent envoyer les résultats et choisirons aussi les destinataires.

Les fichiers et les archives (oui faut compresser également) devront respecter les conventions de nommages en vigueur et être envoyés par mail.

Je ne sais pas si une DB permettra de faire tout cela, faut que je regarde ce que propose Oracle mais s'il faut faire certaines choses en-dehors de la DB alors je préfère tout faire sur DotNet.