Signaler un problème
Ce qu'il suffit d'envoyer pour qu'un problème soit reproductible — et ce qu'il ne faut surtout pas joindre.
Ce qui suffit
Quatre éléments rendent un signalement exploitable. Aucun ne demande vos fichiers.
- L'en-tête de session du journal : trois lignes qui donnent la version, le système, la version de Java et la langue. Elles évitent l'aller-retour le plus fréquent.
- Ce que vous faisiez, en une phrase : le fichier ouvert, le bouton pressé, la transformation lancée.
- Ce que vous attendiez à ce moment-là.
- Ce qui s'est produit à la place, et le message affiché mot pour mot si vous l'avez encore.
Et si vous n'avez rien de tout cela, écrivez quand même. Un signalement imprécis se travaille par questions ; un signalement qui n'a pas été envoyé ne se travaille pas.
Les trois lignes à copier
L'application tient un journal sur votre poste, en local. Pour l'ouvrir : le même menu que « À propos », puis la ligne « Dossier des journaux ». Si le système refuse d'ouvrir le dossier, l'application affiche le chemin avec un bouton « Copier ».
Le fichier lui-même :
%USERPROFILE%\.debugxmltool\logs\debugxmltool.log
Au début de chaque session, le journal écrit trois lignes de cette forme. Ce sont celles-là :
=== Debug XML Tool — session du … ===
version=… vendor=Debug XML Tool build=…
os=… java=… locale=…Le fichier n'est jamais vidé : il s'allonge à chaque démarrage, et la session en cours se trouve à la fin, pas au début.
Certaines lignes techniques affichent des accents abîmés. Copiez-les telles quelles : c'est un défaut d'affichage de notre côté, sans conséquence pour la lecture.
Ce que ce journal contient — à lire avant de l'envoyer
Nous ne vous demanderons jamais « le journal ». Voici pourquoi, et ce que vous y verrez si vous l'ouvrez.
- Tous les chemins de fichiers y sont écrits en entier. Sur un poste professionnel, cela comprend le nom de votre compte Windows, et souvent le nom d'un client ou d'un projet dans le chemin lui-même.
- Les erreurs de l'analyseur XML citent le document : nom du fichier, ligne, colonne, et le nom de l'élément en cause. Dans une feuille de style d'intégration, ces noms d'éléments sont le modèle de données de votre client.
- Le journal note aussi l'espace de travail ouvert, les fichiers chargés, les lignes où vous avez posé des points d'arrêt et les noms des fichiers produits. Un extrait large dessine la carte de votre projet.
En revanche il n'y figure jamais votre clé de licence, ni l'empreinte de votre poste, ni votre adresse électronique : c'est une règle du produit, précisément parce que ce fichier est fait pour être transmis.
D'où la consigne : copiez l'en-tête de session et les lignes d'erreur, pas le fichier. Relisez-les. Remplacez ce qui doit l'être — un extrait caviardé reste utile.
Caviarder, en pratique
Tel quel, dans le journal :
[Fatal Error] C:\Users\dupont\clients\ACME\factures.xml:8:5:
The end-tag for element type "montant_ht" must end with a '>' delimiter.Envoyable :
[Fatal Error] <fichier>.xml:8:5:
The end-tag for element type "<element>" must end with a '>' delimiter.La ligne, la colonne et la nature de l'erreur suffisent à la reproduire. Le nom réel du fichier et celui de l'élément n'y ajoutent rien.
Ce qu'il ne faut pas envoyer
Le XSLT d'intégration se pratique en banque, en assurance, dans le secteur public et la santé. La feuille de style y est de la donnée client, et la transmettre n'est pas indélicat : c'est contractuellement impossible.
Ne joignez donc ni votre feuille de style, ni vos documents XML, ni vos sorties. Nous ne les demanderons pas, et leur absence n'est pas un obstacle.
Si le problème se reproduit sur un document que vous pouvez partager — dix lignes inventées y suffisent souvent — c'est un cadeau. Ce n'est pas une condition.
Si l'application s'est fermée seule
Un arrêt inattendu laisse une trace dans le journal, sur une ligne qui commence par [Crash] et porte un résumé en clair. C'est cette ligne qu'il faut copier, avec les quelques lignes techniques qui la suivent.
[Crash]
Si vous ne trouvez aucune ligne de ce genre, dites-le : cela nous apprend quelque chose aussi.
Où envoyer
Une adresse, pas de formulaire : vous gardez ainsi une trace de ce que vous avez envoyé, dans votre propre messagerie.
Ce qui se passe ensuite, et ce qui ne se passe pas
Une personne lit. Il n'y a pas de file d'attente automatique, pas de numéro de ticket, et aucun délai de réponse n'est promis.
L'application ne cherche aucune mise à jour : un problème corrigé ne vous parviendra donc pas de lui-même. Le seul retour possible est l'adresse depuis laquelle vous écrivez, et l'avertissement part à la main.
Vous pouvez aussi vérifier vous-même, quand vous le voulez :
Signaler un problème ne vous inscrit à aucune liste de diffusion. Votre adresse sert à cet échange, et à rien d'autre.
Ce que cette page n'est pas
- Il n'y a pas de traqueur public. Signaler un défaut sur un outil de travail ne devrait obliger ni à créer un compte, ni à se plaindre en public.
- Rien n'est envoyé automatiquement depuis l'application, ni maintenant ni plus tard : c'est vous qui écrivez, et vous relisez avant d'envoyer.
- Ce n'est pas une assistance téléphonique, et il n'y a pas d'astreinte.