Rebonjour!
je voudrai créer un fichier perl pour pouvoir récupérer des fichiers d'un serveur et les mettre dans un autre.
je vous explique plus en detail:
mon objectif c'est de transférer de maniere automatisée et périodique des fichiers qui se trouvent sous un répértoire donné d'un serveur windows vers un serveur linux ce qui alimentra la base de donnée se trouvant dans celui ci.
Nous disposons dans notre exemple que 4 serveurs, A, B, C, et D.
le serveur A c'est lui qui contient les fichiers en question ( plusiieurs fichiers horodatés par jour ) on utilisera la méthode get FTP pour transmettre ces fichiers au serveur B.
Au sein du serveur B, se trouvera notre script perl qui devra récupérer les fichiers et les fusionner pour pouvoir les transmettre au serveur C qui utilisera un shell nommé "expect" pour transformer les fichiers csv en fichiers sql.
Ensuite grace a un script php que je devrai faire ultérieurement on devra alimenter notre base se trouvant dans le serveur D.
Merci d'avance pour votre aide et vos commentaires!
Forum Programmation.perl script perl de récupération de fichiers
28
déc.
2005
# là n'est pas la question mais 4 serveur pour faire ça ?!
Posté par B. franck . Évalué à 1.
pour la fusion, c'est une banale succession de "cat" vers (>>) le fichier cible que l'on peut compliquer en utilisant la fonction "open" de perl
J'aurais personnellement éliminé le serveur C, puisque le B, dont nos avons le contrôle, peut injecter directement dans le serveur D via quelques modules (CSV ( http://search.cpan.org/search?query=CSV&mode=all ) , SQL ( http://search.cpan.org/search?m=all&q=DBI&s=1&n=(...) ) )
Une foule de possibilités comme d'habitude en perl.
# Je trouve ton idée un peu "usine à gaz"
Posté par totof2000 . Évalué à 2.
Si j'ai bien compris (et surtout bien lu entre les lignes), tu dois récuperer des données du serveur A, B et C?
Un script perl qui récupère les données de A, B et C et qui ensuite integre les données dans la base du sereur D (via le module kidoitexister et kivabien), serait certainement plus judicieux. Tu n'auras pas à te taper trente mille connection si une étape sur l'un des serveurs foire.
[^] # Re: Je trouve ton idée un peu "usine à gaz"
Posté par totof2000 . Évalué à 2.
Peux-tu expliquer?
[^] # Re: Je trouve ton idée un peu "usine à gaz"
Posté par rafikon . Évalué à 1.
avant tout merci pour l'interet!
le probleme pr lequel on ne passe pas de A à D, c'est le fait que la serveur A roule sur du windows "pourri" et que le D sur du linux.
s'il y a moyen d'envoyer cela directement je suis preneur.
merci
# explication
Posté par rafikon . Évalué à 1.
s'il ya moyen de transférer ces fichiers entre deux environnments différents comme ca je suis preneur!!
merci
[^] # Re: explication
Posté par pi6Lohe . Évalué à 1.
nfs, samba, web, ftp, scp, rsync, unison, bittorrent, ... ca depend de ce qu'il est possible d'installer sur A et D.
Sinon si c'est A qui "transmet" à B par FTP, le put fonctionnera mieux. Par contre si il y a un serveur FTP sur A, il suffit d'un client FTP (wget, curl, lftp, ...) sur D pour récupérer les fichiers de A.
# Pourquoi faire simple...
Posté par Arthur Accroc . Évalué à 2.
Il faudrait en ajouter encore, pour être sûr que ça cafouille...
Sinon,
- Au niveau des serveurs :
Le serveur Windows et le serveur du SGBD sont des données de base.
À partir de là, on peut préférer faire le boulot sur le serveur Windows, sur le serveur de SGBD ou sur une machine dédiée qui se connecte aux deux. Pas de raison d'en ajouter plus.
- Au niveau des opérations :
Il y a la récupération des fichiers, leur traitement pour obtenir le code SQL à injecter dans la base, et son injection dans la base.
- Au niveau de l'accès aux fichiers :
Si l'on travaille à partir du serveur Windows (après tout, Perl comme PHP et peut-être même expect existent sous Windows), l'accès est direct; mais il faut par contre disposer d'un module d'accès à la base.
Si l'on travaille à partir d'une autre machine, il faut alors accéder aux fichiers à distance; le plus simple pour ça est d'exporter le répertoire depuis Windows (c'est déjà dedans, alors pourquoi ajouter un serveur FTP ou autre) et d'y accéder directement depuis le script de traitement avec smbmount (et smbumount en fin de script).
- Au niveau des traitements :
expect est une commande basée sur le langage Tcl (note : il existe l'équivalent en module pour Perl), permettant de faire des scripts interagissant avec des commandes qui attendent une entrée interactive. On n'est pas dans ce cas (l'injection de SQL dans une base peut se faire directement depuis Perl, PHP ou d'autres langages avec le module approprié, sans utiliser la commande interactive) et les expressions régulières de Perl suffisent amplement à analyser un format CSV. Donc pas de raison d'utiliser expect.
Pas besoin non plus de fusionner les fichiers, autant les ouvrir directement depuis le script qui effectue le traitement (par exemple en bouclant sur un file globbing (en Perl while (</mnt/smb/*.log>) { open FILE, $_; ... close FILE}).
- Au niveau de l'injection dans la base : comme je l'ai dit, elle peut se faire directement depuis le script avec le module approprié.
Enfin bon, un seul script en Perl peut faire tout le boulot (sinon, ce serait triste pour Perl...). Donc deux ou trois serveurs, un script et un langage suffisent.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # CSV
Posté par Arthur Accroc . Évalué à 2.
Là, j'ai été un peu optimiste : si l'on veut traiter correctement les champs entourés de guillemets contenant une ou plusieurs virgules tout en laissant la possibilité de champs sans guillemets, le traitement est un peu plus compliqué... si ce n'est qu'il existe un module faisant partie de la distribution Perl qui fait déjà tout le boulot : Text::ParseWords, qui s'utilise de la manière suivante :
@champs = quotewords(',', 0, $ligne);
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.