Bon, ça fait quelques semaines que je cherche la solution à cette problèmatique (dans plusieurs direction) et là je crois avoir trouvé une bonne piste.
Ce que je voudrais, c'est récupérer des fichiers plats (structurés ou pas) avec des données. Ces fichiers seraient issues de factures générées dans plusieurs applications sous différents OS et issus de différentes sources.
A partir de ces fichiers de données brutes, on recrérait les documents (surtout des factures) mais on ajoutant simplement un code barre calculé sur certains champs (nom, code postal, montant,...)
Ces fichiers seraient dans le même temps indéxés sur quelques champs.
Leur utilisation sera double :  
1-impression pour mise sous pli automatique (d'où code barre)
  Les impressions devant pouvoir être sélective  
ex impresion     de ts les docs avec un certain code postal)  
2-archivage de ces documents sur CDRom avec recherche sur certains champs.
 
Si j'ai bien tout compris...
Il faudrait que je créé un fond de document pour chaque source (avec quel logiciel?)
Que dans ce fond de page il y ait une zone avec une police code barre qui fasse une concaténation de ceratins champs...  
Que j'alimente ces fonds de pages avec les fichiers plats.
J'aurais alors des doublettes données brutes-fond de page : le duo correspondant au document.
Ces informations seraient stockées sur une base de donnée qui gérerait les appels sélectifs.  
Je pourrais lancé les impression avec les critères que je souhaite d'une part.
Je pourrais créer des CDRom indépendant (consultable sur un autre ordinateur) avec un menu permettant d'appeler les documents que je veuux et le cas échéant l'imprimer...
 
Ma question est donc de savoir si le language XML et ses composants peuvent servir de base à ce processus...
Si non, qu'est-ce qui serait adapté?
Si oui, quels sont les différents logiciels a utiliser?
 
Dans les deux cas, merci beaucoup d'avoir eu le courage de me lire jusqu'au bout !!!!

XML n'est pas si utile pour le stockage d'info mais plutot pour la COMMUNICATION entre processus d'info.
 
En fait XML est parfiat pour ce que tu veux faire jusqu'à ce que tu parles de stockage de l'information + indexation.
 
Selon moi XML n'est pas fait pour ca bien que de très grosses boites font des produits spécifiques.
 
Voir nottament software AG qui a fait un Serveur XML que j'ai eu l'occasion de tester et qui lui assure l'archivage et l'indexation de documents XML

par contre utiliser XML comme version unifiée de ton processus est un excellent choix. En gros tu as un plugin pour chaque application qui, au lieu de recracher une structure plate, recrache un document XML unifié.
 
Ensuite tu as ton application BD qui elle lis uniquement des documents XML.
 
Avantage:  si tu dois ajouter une nouvelle application il te suffit d'écrire le plugin format de sortie de cette appli -> XML pour que ca fonctionne.
 
Est ce clair?

Merci pour ta réponse très clair !!!
Si je te suis, je créé un plugin correspondant à chaque application qui convertit le document au format XML.
Rien ne m'empêche dans ce plugin d'introduire la génération du code barre à un certain endroit de la facture.  
Ainsi je reçois des fichiers au format XML prêt à être imprimés ou traités.
Ces documents sont alors entrés dans une base de donnée...
Mais est-ce que dans ce cas, je peut faire des appels selectifs des documents (ex: tous les docs adressés à un code postal particulier pour les imprimer?)(Tous les documents générés à partir de telle application...)  
Pour l'archivage, je pense qu'il ne doit pas être très dur de faire des conversion en pdf indexés (l'avantage du xml était d'avoir à stocker un seul fond de page qui serait appelé pour chaque doc ce qui permettrait d'économiser de la place)
Pour les plugs-in quel est à ton avis le degré de difficulté de leur développement et quel language serait adapté?
J'avais pensé à la récup de simple fichiers plat car il n'y aurait qu'un fond de page à créer et à compléter, dans une application hébergée en interne, le plug-in étant utilisé en interne...
Qu'en pense-tu?
 
C'est vraiment sympa de répondre à toutes mes questions néophyte !!!

 
Ca depend. Si tu as une base documentaire en XML, que tu indexe regulierement, ca te permet de faire des interrogations complexes portant a la fois sur la semantique des tags et la contenu textuel desdit tags.
Par exemple, si tu as un dico saisi en XML (3/4 mois pour un operateur de saisie specialisé), ca te permet de chercher une entrée avec le tag mammifere et ayant un a comme seconde lettre.
[Cet exemple est pas choisi au hasard, c'est ce qui se faisait il y a 10 ans en SGML. Depuis, ca a progressé].
Donc, ca depend de ce que tu veux faire de tes données.
A+,

En fait ce sera des recherches très simple et sur des champs entiers.  Ce seront des factures donc les champs seront les noms, les codes postaux, les montant, les dates,...
Rien de bien puissant
Merci en tt cas

Est-ce que quelqu'un connais le soft escapeE de Red Titan...
Il permet à partir d'un fichier PCL d'exporter les données sous forme de pdf, xml, csv, ...
Je pense que si il s'avère être fiable je vais récupérer les documents sous formes pcl et me faire mes conversions peinard!!! d'autant plus que le soft permet d'automatiser les taches...

 
C'est bien ce que je disais avec des produits tels que le serveur XML de Software A.G.
 
On a eu une démo de cette boite et ils nous ont montré comment ils archivaient des articles de presse au format XML. Bien entendu le point majeur de la démo était de montrer a quel point l'outil de recherche qui était derrière est puissant.
 
Donc oui tu peux stocker/indexer/recercher des docs XML mais à la base ce n'est pas fait pour ca (je veux dire ce n'est pas XML en soi qui fournit ce genre de fonctionnalités).
 
Maintenant dans son cas, ca peut etre un très bonne solution.

OK...
Pour EscapeE..est-ce que ça vous parle ?

 
moi non mais je fais le forcing avec Software AG. Va voir leur serveur XML ca vaut la peine.

J'y cours...
Si je t'ai bien compris Software AG c'est pour traiter l'aspect base de donnée des docs...
EscapeE c'est plutot pour convertir les sources en XML,XSL,DTD le cas échéant.
Je pense que l'aspect le plus chiant pour moi sera de convertir les docs (différentes sources, différentes plateformes) en XML exploitable.
Après faudra juste lier les docs avec une BDD.
En tout cas merci pour ton tuyau sur Software AG, j'y vais de ce click !!!

C'est vrai que ça à l'air pas mal...
Là la grande question c'est comment obtenir du xml exploitable le plus simplement possible?
 
Je resume...Le but du jeu c'est de récupérer dans un format XML valide plusieurs sortes de docs.
Ces documents sont des factures générées par différents logiciels et sous différents environnement (Windows, AS400, Unix, ..)
Comment donc faire partant de toutes ces sources pour obtenir des docs xml le plus simplement possible?
Conserver la mise en forme de ces docs n'est pas obligatoire mais ce serait mieux.
 
Merci pour vos lumières parce que moi, même si ça parait simple à vue de nez, j'y vois rien !!!!

Je ne comprend pas trop cette utilisaton de XML comme support de stockage ?
J'ai déjà un SGBD ou sont stockées toutes les infos. A partir de cette base, je génère des fichiers XML transitoires lorsque quelqu'un veut télécharger un document et ce fichier XML est associé à des XSL permettant de convertir dans le format voulu, comme ça je peux générer des fichiers personnalisés transitant sur le réseau et récupérable dans un format choisi par l'utilisateur ?
Ais je tout bien compris ou c'est pas comme ça qu'on se sert d'XML... j'entend autour de moi des choses assez contradictoires : par exemple, je ne vois pas trop l'intérêt de faire un forum basé sur du XML si on a déjà un SGBD derrière... C'est plus rapide ?

 
Bon déjà une chose. XML offre pas mal de librairies dans pas mal de languages. Voici comment je vois les choses:
 
Pour chaque format "propriétaire" que tu as en entrée, tu crées un plugin (un soft, une classe, un bazar) qui transforme ce document en un document XML. Ce document XML a une syntaxe identique pour TOUT LES FORMATS (cela signifie que tu n'auraus plus qu'un seul type de document, quel que soit le nombre de programmes propriétaires autour).
 
Tu peux définir la syntaxte de ton document via DTD (mouais) ou Xschema (mieux mais plus compliqué).
 
La transformation structure plate -> XML te viendra petit à petit mais il faut prendre sur toi et te documenter un peu.
 
Ensuite lorsque tu as tes documents XML qui ont tous la même syntaxe tu peux les mettre en style via XSL. Tu peux les transformer en une page HTML, un document PDF, etc ...
 
Donc je t'assure que XML semble vraiment etre un cas d'école pour ce que tu veux faire. Maintenant c'est normal que tu ne comprennes rien si tu ne te renseignes pas un minimum.
 
Si tu es convaincu, potasses XML (www.w3schools.org est une bonne référence pour commencer).
 
C'est en quel language ta solution au fait ?

chocoboy >>> le truc c'est que XML est bien vu ici pour les différents format propriétaires des applis. Ensuite il pourrait très bien stocker ces fichier XML dans une BD sous une forme quelconque mais pq faire?
 
Les requetes de recherches sont simple et XML peut très bien s'en sortir tout seul, sans SGBD.

pour des infos supplémentaires sur XML je te renvoie vers un post de gilou
 
http://forum.hardware.fr/forum2.php3?post=20578&cat=10

Je te remercie beaucoup pour ta réponse Darklord !!!!
Effectivement, je vais me faire une cure de XML carabinée...C'est juste qu'avant je voulais être sur que ce langage était adapté à mon besoin, ce qui semble être le cas.
Tu me demande quel est le langage de ma solution...(???)  
Si tu fais référence à EScapeE je n'en ai aucune idée...en revanche je peux te filer le lien (ce que je j'aurais du faire, désolé)
http://www.redtitan.fr/escapee.htm
Grosso modo, ce progr permet à partir d'un flot PCL de le visualiser ou le convertir vers à peu près n'importe quoi...
Ce qui est chouette c que des automatisations peuvent être faite.
Pour ce qui nous concerne, les balise XML sont créées par zone graphique (ex:pour une source donnée on selectionne une zone du doc qui deviendra la balise <nom>zone</nom> )  
Le seul truc génant c'est qu'il faut que les infos en question soient toujours au même endroit, ce qui est qd même moins souple que la méthode du plugin !
A propos, quel langage de programmation pour ces plug-in te semble le mieux? Delphi ou du C++ ça te parait bien?
 
Encore merci pour tes précieuses réponses et promis je vais potasser !!!

escapee etant un programme, ce n'est donc pas un langage
et Delphic poa trop un langage non pu.
 
CT la minute culturelle d'un ignare qui essaye qd meme d'apprendre.

Merci de m'avoir corrigé sur ces 2 points...
Voilà...tu viens d'avoir ta minute de gloire !!!
Serieusement...
Pour EscapeE ce que je voulais dire c que je ne sais pas dans quel langage c'est programmé...
Enfin merci quand même.

mais ce n'était pas la question non plus
 
Ma question étant de savoir avec quel language tu comptais développer cette solution. Peut etre que Escape fait tout mais bon ca m'étonnerait ...

OK...
Pour l'acquisition des données (le plug in) à priori ce serait en C++ même si le java serait peut-être mieux adapté (qu'est-ce que tu en pense?)
Pour la mise en forme je ne sais pas encore comment on procedera...Disons que disposant d'une base XML on devrait pas trop être limités. A voir. Disons qu'on retiendra la solution la plus économe en espace stockage et surtout celle qui nous permettra la mise en forme la plus puissante (ex:insertion code barre calculé à partir de certains champs)
Pour la gestion des données, ta suite à l'air pas mal du tout...La c'est pareil on devrait pas être trop limités...On retiendra simplement la solution la plus facile d'utilisation sachant que nos besoins seront simples (appels selectifs des docs avec 3-4 champs comme critère (ex: no facture, code departemental, nom, date) , pas de recherche plein texte, marquage des documents ayant été imprimés, centralisation en fonction de la source d'origine,...) Comme tu vois rien de méchant !
 
En fait, ce qui me parait le plus urgent c'est de trouver la meilleuir soluce pour convertir une source lambda en un fichir XML structuré comme nous l'entendons...
C'est la simple fonction que remplirait escapeE même si la solution du plug-in est pas mal non plus (plug in en C++ à priori...sauf si tu penses qu'il y a mieux)
 
Merci beaucoup Darklord pour toutes tes infos précieuses...n'étant pas à la base informaticien, c'est vraiment chouette de pouvoir bénéficier de tes conseils...
ET BONNE CHANCE POUR DEMAIN CONTRE LA RUSSIE !!!

bin pour le moment on mène 1-0 mais tu sais je suis pas un fana de foot
 
Sinon pour répondre à ta question de manière plus précise, voici ce que je moi je te conseille:
 
1. Définis clairement et de manière très précise le format de tes documents (en d'autres termes le format du document XML). Un exemple pourrait etre un texte en francais tel que "chaque document a un et un seul barcode. Le barcode est de type EAN128 et a une longueur minimale de ... etc etc"
 
2. Avec ce texte tu peux via un consultant ou un gars de ta boite  creer le DTD ou via XSchema définir la structure que ton document va avoir. Chaque document XML aura une référence vers cette structure t'assurant que tout document XML est conforme à ta spécification définie au point 1.
 
3. Pour chacune de tes applications propriétaires, écrire un plugin qui transforme cette structure plate en un document XML conforme a 1. Je n'ai pas de religion concernant le language. C++ peut très bien faire l'affaire, Java a bcp d'API ici. A mon sens tu dois plus voir ce qui t'intéresse le plus: portabilité, performance, rapidité de développement, etc etc. Là enconre un consultant pourra t'aider.
 
4. Pour la base de données et vu le peu de ce que je sais de ton système, je ne stockerai pas les documents dans une BD. J'utilisaerai un serveur XML tel que celui de Software AG ou pq pas je développerait ma propre appli qui structurerait les documents XML produit lui même  .... Une remarque cependant: XML n'est certainement pas le format le plus économe au niveau stockage ! Je ne suis pas persuadé que ce genre d'aspect soit important (enfin je ne connais pas la taille des documents que tu dois gérer aussi).
 
Voici mes conseils mais n'oublie pas qu'ils se basent sur une connaissance incomplète de ton environnement.  
 
Bonne journée

Merci beaucoup une fois de plus Darklord...et même si tu ne suis pas la foot...FELICITATION POUR LA BELGIQUE
1-Pour la définition du format du document j'ai commencé a y bosser...Comme ce seront des factures ce sera du genre
<facture>
<numero>xxxxxx</numero>
<client>notre_client</client>
<destinataire>destinataire_facture</destinataire>
etc...
</facture>
Est-ce que c'est ici que doit être généré le code barre?
En créant une balise dont l'élément sera une concaténation d'autres éléments et qui s'écrira dans une police code barre.
J'étais persuadé que le code barre était créé lors de la mise en page....
2-Je pense que l'on passera par du XSchema sur tes conseils et ceux de quasi toutes les personnes à qui j'en ai parlé.
3-Pour le plug in, à priori ce sera du C++...
En fait, ce qui serait extra ce serait d'arriver à créer une imprimante virtuelle qui à la manière d'un pdf maker sorte le document dans notre format XML...C'est la manière la plus simple pour les utilisateurs (imprimante XML configurée par défaut)
4-Le système qui sera utilisé est très très light (...)
On sea sous environnement Windows 2000 avec des capacités de stockage d'une centaine de Go...Les docs seront des factures classiques qui au format PDF font 100-150Ko...Ces factures seront conservées chez nous 3 mois...
En fait je te pose toutes ces questions car il s'agit d'un projet de création d'entreprise dont je vérifie la faisabilité technique, commerciale, ....
Pour l'aspect technique c'est réglé...ce sera le XML...j'ai été sur ton site de formation, il est extra et n'a fait que me conforter dans ce choix...
 
Merci beaucoup...tu n'imagines pas à quel point tu as éclairé les choses pour moi !!!!

you're welcome. Si tu as d'autres questions n'hésite pas à me contacter.
 
A+

C'est vraiment très sympa !!!
Juste 2 petites questions...
1-Pour le code barre, il est donc créé dans le doc XML, pas dans la mise en page?
2-Pour le plug-in, cela te parait-il possible de créer une imprimanate virtuelle, style xml maker à la pdf maker...
Merci encore et bon week end !!!

1. Le code barre. Si j'ai bien compris le code bare est l'identifiant de ton document XML. Tu dois déjà choisir une norme. Personnellement je prendrais EAN128 ou CODE 128 pour ce genre de problèmes. Ensuite l'identifiant (ou code barre) ne vas pas se créer tout seul !!! Il faut le générer. Une fois que tu l'as généré tu as des outils qui te permettent de transformer un id en sa représentation code barre (en d'autre termes, transformer <codebarre>JOK12342576546</codebarre> en une image symolisant cet id.  
 
2. L'imprimante pdf. A priori aucune idée mais tu peux très bien développer un logiciel qui prend un document XML en entrée et qui recrache un document PDF. Basé là dessus il est très facile de l'imprimer automatiquement.
 
A+

et le logiciel du point 2 mettra les infos du doc XML en page et générera l'image de ton code barre. Il y a des librairies gratuites sur le net pour cela.

Merci.
Pour le pdf je me suis mal exprimé. En fait ce que je voudrais faire c un prog qui emule une imprimante, cette imprimante crachant du xml à la manière d'un pdf maker par exemple.
Thanks

 
crachant du PDF a partir du XML tu veux dire?

J'ai trouvé une API java qui te permet de recracher du PDF depuis Java
 
 
http://sourceforge.net/projects/itext/

En fait, les documents seront générés par des logiciels de gestion commerciale (style Ciel, EBP,...) ou par des progiciels développés en interne...
Par exemple un logiciel sous ciel génére ses factures depuis une base de donnée.
Du coup, il n'existe pas de fichier pour chaque document.
Dans le cas du progiciel, chaque facture peut être associée à un fichier ou alors être générée depuis une BDD...
Du coup, en plus d'avoir un OS de source différent, un format différent, les documents (des factures) ne sont jamais généré sur la même architecture.
L'avantage d'une imprimante virtuelle, serait double.
J'entend par là, une imprimante configurable comme l'imprimante par défaut, sauf que cette imprimante aura un driver qui ne dira pas "imprime sur tel matos" mais "convertit ce document au format xml et sors ça dans un fichier à tel endroit"
Quand je te parlais de pdf maker c'est parce que ça marche sur le même modèle...quand on a un doc (ouvert sous n'importe quel OS, logiciel,...)on imprime avec pdf maker et un format pdf du doc est généré...
 
L'avantage serait ainsi de ne pas avoir à s'occuper de la source ou du logiciel...et le deuxième sera surtout que ce soit très simple pour l'utilisateur puisqu'il n'aura rien du tout à changer dans ses habitudes...Quand il est près à imprimer son doc il le fait sur notre imprimante et voilà !!!
 
Est-ce que tu penses à la lumière de ces précisions, que ce fameux driver pourrait être programmé en C++
Il y aurait une grosse partie commune à toutes les sources (librairies, etc) et un développement spécifique pour chaque source.
 
Je ne sais plus comment de dire merci sans me répéter mais vraiment tu es en train de devenir une sorte de gourou pour moi (LOL)

stoppons les flatteries veux tu
 
pour ton PDF maker je n'ai aucune idée quand à la procédure pour déclarer un tel driver. Ton idée est excellente en tout cas. Cependant je ne pense pas que ce soit viable.
 
En effet, comment veux tu au départ d'une source générique (l'imprimante XML maker) sortir un document XML. La seule chose que tu as a ta disposition c'est une "page" d'un logiciel propriéataire.
 
Non définitivement cela ne va pas. Tu dois pour tout tes logiciels, trouver une parade. Cette parade peut consister à décoder le format de chaque apppli et de le transformer en XML. Chaque appli peut peut etre exporter la facture en RTF, HTML ou autre. A toi devoir
 
Mais une imprimante XML communue poru chaque appli, ca ne marchera jamais (sachant que PDF ne fait que transformer la représentaiton de la page en un documnet PDF, ce qui est assez facile a faire. Toi au contraitre tu dois retrouver les champs nom du client, date, etc ce qui est bcp moins trivial).

C'est malheureusement ce que je craignais...
C'est sur que générer un pdf c bcp plus simple....grosso modo c'est une photo, non détaillée d'un doc...
Alors que là il y a des champs à récupérer ce qui est déjà moins trivial comme tu dis !
Bon, je suis donc bon pour faire un plug in qui ira directement dans l'application chercher les éléments dont j'ai besoin !!!
Merci beaucoup.

exact

Bon, ben merci beaucoup pour tout.
Je te ferais parvenir les différents développements de cet applicatif (d'ici sept-oct) des fois que ça te serve, qui sait???
A+ et merci encore pour tout.

 
ok. Si t'as besoin d'autres détails, fais signe

ça marche...thanks

 
Comment les documents XML sont ils stockés avec software AG ?
La BD reste relationnelle ?
le documents XML sont juste indexés ?
Ou la base elle même est structurée XML ?

les documents XML sont stockées tel quel (je veux dire ce sont des fichiers XML du moins je suppose). Il n'y aucune bd relationnelle derrière. Ceci dit, il y a moulte index qui te permettent de faire des recherches aussi bien sur les docs XML proprement dit mais aussi sur leur contenu.
 
Une application typique a laquelle j'ai eu  droit pendant la démo est un journal qui indexait ses articles de presses au format XML dans ce server. Ensuite des pages ASP allait pomper les fichiers xml à la demande du client et, via XSLT, une page html était générée (toujours basé sur les préférences du cliet)
 
c'était très rapide et au niveau mondial, ce server est très très bien coté (voir le site).