La multiplication des annotations

Alors que le langage Java comporte de base peu d'annotations, des apis peuvent en amener une multitudes comme le montre le récent tutoriel Seam, ou celles proposées par Hibernate.

Je suis assez réticent sur la multiplication des annotations qui pour moi ressemblent à première vue à un nouveau dialecte. Voici mes craintes si j'en crée dans mes packages :

• Difficultés de refactoring par les ide
• Difficultés de compréhension par l'équipe par rapport à une api standard
• Est-ce, comme le fut xml, une mode ?
• Quel est la réelle plus-value par rapport à une ligne de code ?

J'étais également réticent à Hibernate par rapport à JDBC, et pourtant utilisant JPA, c'est quand même bien mieux :D (surtout quand Netbeans génère tout ces annotations louches :roll:).

Bref, créez-vous vos propres annotations, et êtes-vous content d'avoir des frameworks pleines d'annotations ?

Pour ma part je trouve que les annotations sont un des points fort du langage.
Hibernate qui est un outil très puissant n'était pas aussi efficace lorsque les annotations n'éxistaient pas encore. Quelle perte de temps que de taper de longs fichier de mapping en xml ...
L'ORM avec JPA est devenu très facile à mettre en place et n'a que peu de rivaux (si ce n'est aucuns), et ceci grâce aux annotations.

Les annotations sont maintenant omniprésentes dans nos codes sources, et je pense que c'est une manière efficace de "marquer" une classe.

Le problème à mon sens n'est pas dans les annotations mais plutôt dans le fait qu'elles n'ont pas de référence (nominative) sur l'outil cible.
Dans le cas que tu cites (Seam), c'est assez flagrant.
On mélange des annotations JPA avec des annotations SEAM, on ne sait plus trop à quoi elles se rapportent.
Bon, on peut toujours regarder l'import pour s'en sortir...

Ceci dit, je ne remets pas en cause les annotations, la proximité avec la propriété ou la méthode cible est un plus par rapport aux fichiers externes.

Un autre avantage, le serveur cible va les interpréter idéalement... on pourrait imaginer la "traduction" d'une annotation différemment d'un serveur à l'autre...

Citation:

---

Quelle perte de temps que de taper de longs fichier de mapping en xml

---

Pour Hibernate, l'argument de kazou sur les fichiers hbm ne tient pas, l'outil les générant également ;)

OK pour le marquage quand il y a une annotation, par exemple @Stateless ou @Id : on comprend vite que c'est spécial.

Mais quand il y a 3 annotations dont certaines "tordues" sur une fonction, en quoi cela remplace t-il une ligne de code dans le constructeur ou la fonction ?

Exemple :
@Logger
private Log logger;


On ne peut pas faire par exemple Log4j.setLogger(this.logger) dans le constructeur ? (oui, je ne connais pas bien log4j :mouarf:).
Si un framework bien particulier propose 3-4 annotations typiques de sa spécifité, ok. Mais je trouve que l'écriture fait un peu blackbox : on sait pas trop ce qu'il y a derrière.

Citation:

---

Envoyé par nicorama

Mais quand il y a 3 annotations dont certaines "tordues" sur une fonction, en quoi cela remplace t-il une ligne de code dans le constructeur ou la fonction ?

---

Autant je suis de l'avis de dire que les annotation sont un réel plus à Java, autant je suis de ton avis sur le point où trop d'annotation nuit à la documentation naturelle du code source. On peut un perdre en visibilité et cela peut compliquer la compréhension du code.

Pour ce qui me concerne, je suis un grand fan des annotations.

J'utilise régulièrement JPA, Hibernate et Spring et je trouve beaucoup plus agréable et fin une configuration par annotation. Par exemple pour une entité JPA, on voit tout de suite dans la classe les propriétés JPA/Hibernate, on a pas besoin d'aller lire un fichier XML imbitable pour comprendre comment est mappé cette classe.

Il m'arrive également de créer mes propres annotations, mais c'est vrai que je n'en utilise pas beaucoup.

Pour ce qui est de la clarté, toutes les annotations que j'utilise (jpa, hibernate, spring, junit et annotations standards) m'ont toujours semblé suffisamment claires. Il est sûr qu'il faut être conscient de ce qui se passe derrière, mais une fois qu'on sait qu'est-ce qui est fait avec une annotation, on ne se pose pas la question.

De même que Baptiste, depuis les annotations, le developpement n'a cesse de simplifier le code et la rapidité de ce dernier.

Le principe d'une annotation, c'est justement de ne pas savoir ce qu'il y a derrière, juste de ce qu'elle peut faire.

Personnellement les annotations, je ne pourrais plus m'en passer. Et n'en utiliser que 3 ou 4 du langage alors qu'il peut y en avoir des milliers, ce serait comme n'utiliser que java.lang alors qu'il existe tous les packages à côté.

Pour ajouter un comportement spécifique via AOP, y'a rien de tel.

Code:

---

1 2 3 4 5 6

@Inject // Guice... Ah que c'est bon. @Log({ENTRY,EXIT,THROWING}) //Log de l'entrée, de la sortie de la méthode et d'une éventuelle exception @Property // Et hop un firePropertyChange. public synchronized void setStatus (@NonNull Status status) { // et pour finir, un peu de validation this.status = status; }

---

Ce genre de code (tiré d'une de mes applications) ne me dérange pas et augmente clairement ma productivité... une fois la fonctionnalité écrite.

Pour moi les annotations apportent d'une part une simplicité de développement, et donc un gain de productivité.
Mais en plus de ça elles facilitent la relecture du code, on voit tout au niveau de l'objet au lieu de devoir aller regarder dans plusieurs fichiers xml à quoi correspond tel attribut de tel objet.

C'est beaucoup plus clair, après c'est comme tout il ne faut pas en abuser.

Difficulté de refactoring ? Les annotations font partie du langage et sont très bien comprises par les grands ide. Je ne vois pas en quoi renommer une méthode diffère de renommer une annotation, par exemple. En comparaison, cela peut être un véritable problème en xml, où on ne peut pas garantir le refactoring dans tous les cas.

Je ne comprends pas trop bien ton argument, "Difficultés de compréhension par l'équipe par rapport à une api standard". Les annotations introduites par une api font partie de l'api, où est le problème ?

Pour ma part, j'utilise les annotations assez fréquemment (JPA, Spring, TestNG/JUnit, ...). Je trouve l'outil fort intéressant et puissant. Comme cela est dit plus haut, les IDEs s'en accommodent très bien (refactoring, etc).

Cependant, je mettrais quand même des bémols : trop d'annotations tuent les annotations. Un fichier source truffé d'annotations (5, 6 voire plus sur un seul élément !) devient assez vite difficilement lisible (avis personnel cependant).

Par ailleurs, contrairement aux fichiers xml, les annotations sont des éléments de code, donc intrusifs par rapport au sens. Il est plus compliqué de modifier un configuration via les annotations que via un fichier xml (et éventuellement de l'aop). Dans le cas par exemple de JPA, cela ne pose pas réellement de problèmes, on ne modifie pas le modèle sans modifier les classes sous-jacentes. Mais dans le cas d'un logger, dont on donne par annotation le niveau (info, debug, etc.), alors le modifier signifie recompiler... Ce qui est fort dommage.

Enfin, en utilisant des annotations, on utilise certes des POJOS mais on devient de fait liés à une API particulière (pour JPA, c'est standard donc par de pb, par contre pour Spring par exemple...).

Pour conclure, je dirais : utilisez les annotations, en prenant en compte les avantages et inconvénients que leur utilisation implique. Si les inconvénients ne vous gênent pas, alors foncez. N'hésitez pas, vous gagnerez du temps, à coup sûr.

Citation:

---

Envoyé par Patriarch24

Cependant, je mettrais quand même des bémols : trop d'annotations tuent les annotations. Un fichier source truffé d'annotations (5, 6 voire plus sur un seul élément !) devient assez vite difficilement lisible (avis personnel cependant).

Par ailleurs, contrairement aux fichiers xml, les annotations sont des éléments de code, donc intrusifs par rapport au sens. Il est plus compliqué de modifier un configuration via les annotations que via un fichier xml (et éventuellement de l'aop).

Enfin, en utilisant des annotations, on utilise certes des POJOS mais on devient de fait liés à une API particulière (pour JPA, c'est standard donc par de pb, par contre pour Spring par exemple...).

---

Personnellement j'essaie d'éviter et je préfère de loin les fichiers XML pour les raisons évoquées par Patriarch24.

Je suis super pour les annotation mais dans la limite ou c'est utilisé avec discernement et pas à tout bout de chant. comme dit plus haut trop d'annotation tu les annotations mais c'est réellement un plus de Java qui est formidable.

Citation:

---

Envoyé par Alesque

Personnellement j'essaie d'éviter et je préfère de loin les fichiers XML pour les raisons évoquées par Patriarch24.

---

Ben moi, c'est l'inverse... On ne parle pas de XM(HELL) pour rien...

les annotations sont, pour ma part clairement un avantage, mais il faut savoir faire la part entre ce qui est fixé dans le code par annotation et ce qui doit nécessiter une configuration plus souple par fichier xterne. Pour reprendre l'exemple d'hibernate. Quand vous développez un api a usage interne, vous fixez une fois pour toutes vos tables et vos noms de colonne. Les seuls changement qui restent possibles sont structurels (ajout d'un champ/ d'une classe et mapping associé). Dans ce cas, oui aux annotations. Par contre, pour les programmes redistribués, ca deviens plus tendancieux. On a chez nous une application JIRA. Pas accès au code source. Cependant, besoin de faire tourner deux versions différentes de JIRA sur la même base de données. Hop, un coup d'oeil sur le fichier de mapping hibernate et on fait un rename des tous les noms de tables. Si JIRA avait été mappé par annotation, on l'aurais eu bien profond :)

Autre exemple, les différentes bases de données. Quand des applications hibernate sont distribuées, il arrive de devoir modifier les fichiers de mapping en fonction du type de base de donnée. Certains noms de colonne ne sont pas autorisés (souvent car trop longs), certaines bases utilisent des sequences, d'autres des autoincrement, il faut donc pouvoir réadapter l'application en fonction de la db sur laquelle elle va tourner, et là, un fichier de mapping, ca deviens indispensable :)

edit partiarch: pour les loggers, il me semble que l'idée est d'injecter le logger (d'ou l'annotation), pas de le configurer dans le code, justement. Il reste le fichier de config qui dit quelle logger est configuré comment. Seuls les points d'injection sont annotés :D

Pour reprendre ton exemple des logs et de leur seuil, il est absurde de définir le niveau d'un log dans une annotation : les annotations, même si elles le permettent, ne devraient pas gérer ce comportement puisqu'il tient plus des préférences de l'utilisateur final. Au pire des cas, elles ne devraient être que des valeurs par défaut.

Tout ce qui doit être recompilé pour être changé est de la mauvaise utilisation des annotations (parmi les annotations runtime, entendons-nous).

Le principal problème, c'est que les annotations sont trop méconnues et qu'elles commencent à suivre une sorte de mode "les annotations, c'est cool, utilisez-les !" à outrance, sans discernement entre la bonne et la mauvaise utilisation. On ajoute des annotations sans comprendre qu'on peut en réutiliser. Dans ce contexte, oui, le pullulement des annotations n'est pas une bonne chose. Dans le cas contraire, c'est tout bon.

En lisant ce sujet, j'ai l'impression que certains pense qu'il est obligatoire de recompiler pour changer un comportement défini par annotation.

Un grand nombre d'annotation supporte une surcharge par XML

Citation:

---

Un grand nombre d'annotation supporte une surcharge par XML

---

Ce n'est pas toujours le cas, même si beaucoup de frameworks proposent en effet ce genre de comportement. Sinon, il faut recompiler :mrgreen:

Citation:

---

pour les loggers, il me semble que l'idée est d'injecter le logger (d'ou l'annotation), pas de le configurer dans le code, justement.

---

Ok, mauvais exemple. Je voulais simplement dire : les annotations, ok, mais pas pour faire n'importe quoi :yaisse2:

Je recommande l'utilisation des annotations.

Cependant, une chose que j'aimerai éclaircir...
J'utilise Spring 2.5 avec les annotations stereotypes (@Repository, @Service, @controller)

Avant cela, l'ensemble des beans gérés par Spring été clairement définit dans un fichier xml. Avec les annotations par contre, nous avons moins de contrôle quant à cela.
Existe-t-il un outil qui permet de généré un fichier xml avec l'ensemble de nos beans annotés? Ceci afin de retrouver notre liste de beans gérés par Spring...

Merci.

Bertrand

Je vais faire office de mouton noir parmis cette foule de : ca simplifi, c'est plus rapide, c'est ...etc...

En fait je suis contre l'usage des annotations, je les vois comme une véritable pollution du code qui marche d'une facon parallele au Java.

Pour moi, avoir recours aux annotations c'est avoir failli dans la bonne conception de l'application.

En fait c'est simple si on regarde une API type utilisant les annotations : JAXB.
Elle enfrain beaucoup des règles de programmations java, acces aux constructeurs, aux variables et aux methodes privées, aucun respect de la portée des classes.
Ce genre de comportement qui consiste à désactivé les sécurités était jusqu'ici réservé à la sérialization d'object.

Je vous renvois sur mon opinion de jaxb dont une partie des critiques sont emputables aux annotations : Pensez vous que JaxB a un avenir dans le monde professionnel ?/

Je ne peux me fier qu'a ce que j'ai expérimenté avec jaxb pour me faire une idée, mais le fait que cette techno soit dans la JVM me fait penser qu'elle utilise tout de même convenablement les annotations.

Actuellement nos projets utilisent enormement jaxb et des memes classes sont presentes sous plusieurs version XML différente (evolution des normes ISO/OGC).
Chaque nouvelle version apporte son lot de classes dupliquées avec des annotations différentes, ce qui est particulierement dramatique en volume, à long terme et en maintenance. Le probleme est surement le meme avec hibernate.

Les annotations ne gerent pas les versions d'annotations ce qui les empeches d'etres viables pour les projets en continuel developpement. Elles ne servent qu'a gagner du temps, et pour les commerciaux le temps c'est de l'argent, ce qui explique l'usage abusif qui en est fait, surtout pour tout ce qui est binding principalement.

Toutefois tout n'est pas noir, quand il n'y a pas de versions a gérer et qu'il ne s'agit que de mecanique interne à l'application alors ca reste un usage raisonnable.

le mouton noir

les versions, pour beaucoup de besoins, sont gérées au niveau du repository de code. Quand tu fait évoluer ta classe et ses annotation vers une situation nouvelle, tu reviens rarement en arrière, sauf pour du legacy, et là tu ressort le vieux code de ton bon vieux svn et tu le recompile. Et comme déjà mentionné, si le meme code doit etre utilisé dans des situation différente, ok pour les annotation a condition que des fichiers puissent préciser ou faire varier ces annotations. Dans le code, on met ce qui change pas, sauf si le code doit aussi changer :D

Citation:

---

Envoyé par tchize_

les versions, pour beaucoup de besoins, sont gérées au niveau du repository de code. Quand tu fait évoluer ta classe et ses annotation vers une situation nouvelle, tu reviens rarement en arrière, sauf pour du legacy, et là tu ressort le vieux code de ton bon vieux svn et tu le recompile. Et comme déjà mentionné, si le meme code doit etre utilisé dans des situation différente, ok pour les annotation a condition que des fichiers puissent préciser ou faire varier ces annotations. Dans le code, on met ce qui change pas, sauf si le code doit aussi changer :D

---

On voit que tu n'as jamais fait d'application intéropérable. essai de communiquer entre 2 applications serveur si elles n'utilisent pas la meme version d'une norme d'echange, bonne chance.

Tu ne geres pas les versions des normes au niveau du code, je suis surpris que tu proposes cette solution. 8O

J'a idéjà du travailler avec des serveur ou fallait balancer mes donnée dans des formats les pluts tordus les uns que les autres, sans annotations. Et même sans annotations, j'ai un template par format d'export. Je vois pas le lien avec les annotation dans l'histoire :)

Et comme je l'ai dit, pour moi vouloir utiliser des annotation pour diriger la manière dont un code se comporte, alors que tu sais pertinement que ce code devra se comporter de manière différente suivant la situation, c'est assez inutile. Autant se passer des annotations dans ces cas là :)

Citation:

---

Envoyé par tchize_

Et comme je l'ai dit, pour moi vouloir utiliser des annotation pour diriger la manière dont un code se comporte, alors que tu sais pertinement que ce code devra se comporter de manière différente suivant la situation, c'est assez inutile. Autant se passer des annotations dans ces cas là :)

---

ca revient a ce que j'avasi dit : ne pas utiliser d'annotation pour ce qui est binding (xml ou autre)

Citation:

---

Envoyé par eclesia

Les annotations ne gerent pas les versions d'annotations

---

Peux-tu expliciter ce point particulier ?

Quand tu annote ta classe avec une api de binding : type jaxb.
les annotations sont faites pour une version particuliere du xml.

Quand on suit des normes, parmis lesquelles ISO et OGC, les normes évoluent avec les années avec une nouvelle version tout les 2/3ans environs et des revisions qui peuvent être quasi annuelle pour les normes très actives.

Donc quand tu as annotée ta classe, tu l'as fait pour une version particulière. seulement il est rare d'avoir deux applications (venant de société différentes) alignée en permanence sur la même version. Par conséquent notre classe doit pouvoir être "marshaller" en différente version d'une même norme pour pouvoir vraiment etre interopérable. Mais il est impossible d'avoir plusieurs annotations faisant référence à différente version ou a différentes normes.

Un exemple : j'ai une série de classes pour faire de la symbologie, il exite une norme OGC et une norme ISO et on peut aussi vouloir quelque chose de plus grand public comme le SVG ou le CSS.
les 4 normes décrivent plus ou moins la meme chose mais de facon differente. Avec des annotations tu es foutu, tu dois faire une interface et N implémentation pour chaque version/norme.

Un bon parser en vrai java et son lot de tests unitaires, c'est la seule solution viable a long terme.

dans ce cas là, bien sur, mais ca n'enlève rien à l'utilité ds annotation si tout ce que tu veux c'est marshaller ta classe pour la récupérer 5 minutes après sur la même version de ton appli, bref quand le format est à usage interne seulement (communication client / server utilsant la même version du protocole par exemple).

Perso il m'est jamais venu à l'idée d'utiliser des annotations pour exporter vers des format étranger à mon appli, j'ai toujours préféré l'utilisation d'un bon vieux template en freemarker ou en jsf (facelet parfois c'est du tout bon pour l'export format XML de données :p) qu'on sais faire évoluer sans toucher au code.

Citation:

---

Envoyé par eclesia

Quand on suit des normes, parmis lesquelles ISO et OGC, les normes évoluent avec les années avec une nouvelle version tout les 2/3ans environs et des revisions qui peuvent être quasi annuelle pour les normes très actives.

---

Tout à fait.

Citation:

---

Envoyé par eclesia

Un exemple : j'ai une série de classes pour faire de la symbologie, il exite une norme OGC et une norme ISO et on peut aussi vouloir quelque chose de plus grand public comme le SVG ou le CSS.
les 4 normes décrivent plus ou moins la meme chose mais de facon differente.

---

Si c'est fait de façon différente, c'est que le modèle qui le capture est également différent (un schema iso est différent d'un schema ogc); Donc il existe plusieurs traductions dans le code, et donc plusieurs jeu d'annotations.

Comment résous-tu ce problème avec une sérialisation classique ?

Citation:

---

Envoyé par tchize_

Perso il m'est jamais venu à l'idée d'utiliser des annotations pour exporter vers des format étranger à mon appli, j'ai toujours préféré l'utilisation d'un bon vieux template en freemarker ou en jsf (facelet parfois c'est du tout bon pour l'export format XML de données :p) qu'on sais faire évoluer sans toucher au code.

---

Ce ne sont pas des formats étranger justement, on doit les gérer pour pouvoir communiquer avec les autres applications. le but de nos applications est en grande partie l'échange d'informations, se sont des applis serveur qui fournissent des services normalisés qui ne communique pas necessairement avec des clients fait par nous.
Un exemple (réel) un client MapFaces qui communique avec les serveurs cartographique de la nasa ou de l'unesco.

Je ne vois pas ce que vient faire jsf et les servlets la dedans :koi:

Citation:

---

Si c'est fait de façon différente, c'est que le modèle qui le capture est également différent (un schema iso est différent d'un schema ogc); Donc il existe plusieurs traductions dans le code, et donc plusieurs jeu d'annotations.

Comment résous-tu ce problème avec une sérialisation classique ?

---

Il n'y a pas plusieurs traduction dans le code, il y a une classe "Style" qui cumule toutes les possibilités des différentes normes, a cause de ca, la structure de la classe ne colle a aucune des normes mais est capable d'en gérer tous les élements.

Comme le modèle ne colle pas a la norme je ne peux pas l'annoter, alors la solution est de transformer ses classes vers des classes annotées pour une norme et une version donné, ce qui peut en faire beaucoup. c'est le choix qu'a fait la société.

Personnellement, j'aurais fait des parseur stax, ce qui serait beaucoup plus performant, moins couteux en mémoire mais qui aurait prit plus de temps a réaliser. malheureusement jaxb est tres a la mode a cause de metro et des autres api, va donc expliquer a un patron non développeur pourquoi il ne devrait pas utiliser une api que tout le monde utilise :aie:

Citation:

---

Envoyé par eclesia

Ce ne sont pas des formats étranger justement

.... qui ne communique pas necessairement avec des clients fait par nous.

---

Perso c'est ma définition de "étranger à mon application", t'as pas le controle absolue sur le lecteur et l'encodeur :)

JSF était juste un exemple. Pour les export j'évite au maximum d'utiliser du code, j'utilise toujours des système de template (freemarker par exemple peu lire un template et y injecter les données :p). par contre, de fait, pour la lecture, il faut souvent passer par du code ^^

On en reviens de toutes facon au final a être d'accord il me semble: les annotation: oui pour ce qui est lié au code :D, sinon c'est pas la peine (logique puisqu'elles sont dans le code :p)

Citation:

---

Envoyé par eclesia

Il n'y a pas plusieurs traduction dans le code, il y a une classe "Style" qui cumule toutes les possibilités des différentes normes, a cause de ca, la structure de la classe ne colle a aucune des normes mais est capable d'en gérer tous les élements.

---

Ok, tu as donc un modèle protéiforme qui ne singularise pas chaque norme.

Citation:

---

Envoyé par eclesia

Comme le modèle ne colle pas a la norme je ne peux pas l'annoter, alors la solution est de transformer ses classes vers des classes annotées pour une norme et une version donné, ce qui peut en faire beaucoup. c'est le choix qu'a fait la société.

---

C'est aussi le choix que nous avons fait. C'est pas que je sois un adorateur de jaxb, mais le choix Jaxb peut se défendre pour plusieurs raisons dont une est qu'il permet une réification du schema xml dans le code, donc de tirer bénéfice du compilateur pour le binding, il est bidirectionnel et il est global (et non séquentiel). Après, effectivement, c'est lourd et consommateur de mémoire.

En outre, avec des outils comme hyperjaxb, il est possible à la fois de créer un maping xml-objet, mais aussi objet-relationnel. Ce qui est très intéressant.

Citation:

---

Envoyé par eclesia

Personnellement, j'aurais fait des parseur stax, ce qui serait beaucoup plus performant, moins couteux en mémoire mais qui aurait prit plus de temps a réaliser.

---

A réaliser, à mettre au point et à maintenir. En outre, il me semble que stax ne gère que les chaines de caractères, ce qui implique de mettre en place des convertisseurs (date, nombres).
Nous, nous travaillons sur les normes iso 19139. Ecrire un parseur stax de cette norme est inimaginable tellement c'est complexe. Les décideurs sont peut-être pro-production, mais les informaticiens sont aussi très faignants.

Citation:

---

Envoyé par tchize_

Pour les export j'évite au maximum d'utiliser du code, j'utilise toujours des système de template (freemarker par exemple peu lire un template et y injecter les données :p).

---

C'est pas à mettre au même niveau que jaxb. Freemarker c'est du rendu, jaxb du mapping;
En outre, avec freemarker, tu n'as aucun controle sur la validité de ce que tu produit (à moins de rajouter une couche). Un export xml ou json peut se retrouver foireux sans que tu t'en apperçoive (c'est du vécu).

Perso, nous utilisons un mapping dozer + jaxb, qui permet l'export/import xml et json sans faute et sans code supplémentaire.

Citation:

---

Envoyé par Tommy31

Perso, nous utilisons un mapping dozer + jaxb, qui permet l'export/import xml et json sans faute et sans code supplémentaire.

---

merci pour le truc ;) de mon coté, pour tous nos format d'export, c'est à chaque fois des formats bidouille a moitié pas documenté exigés par un service externe et, (là aussi c'est du vécu) a la question "vous avez un DTD, un serveur ou n'importe quoi pour pouvoir tester la validité des données par rapport au format approximativement documenté que vous utilisez?" j'ai eu une réponse variant autour de

Citation:

---

vous nous envoyez le fichier, on l'ouvre dans excel pour regarder si il y a des erreur flagrante, ensuite on l'importe dans notre serveur de test pour voir si tout va bien et finalement, on l'importe sur le serveur SAP si ca fonctionne. Si il y a une erreur ou vous rappel

---

Devant ce genre de réponse, je me sens parfois désespéré :D (quand c'est pas des format impossibles à respecter car il y a incohérence entre le format (théorie) et les données réelles (la pratique))