Déclenchement du transfert des données par FTP

Le transfert FTP (ou SFTP) du ou des fichiers peut se faire au choix de l'établissement :

  • soit en FTP sur un serveur localisé dans l'établissement (Méthode « PUT »)

  • soit en SFTP sur un serveur localisé dans l'établissement (Méthode « PUT »). Une documentation spécifique est à demander sur le guichet d'assistance domaine Transferts réguliers

  • soit en FTP sur le serveur intermédiaire de l'ABES où l'établissement doit venir chercher son / ses fichier(s) (Méthode « GET »)

ProcédureTransfert de fichiers par la procédure PUT sur le serveur local

Une fois que le message de fin d'extraction des mises à jour en central (message « status is 9 ») est reçu en local, le processus de transfert des fichiers est déclenché par l'établissement : celui-ci doit envoyer un courriel appelé GET TITLE DATA ou GTD à abes_ftp@carmin.sudoc.abes.fr pour obtenir le transfert du ou des fichier(s) de la journée ou de la semaine.

Ce courriel peut-être envoyé :

  • par le système local (en cas d'automatisation de la procédure par le SIGB et / ou le CRI)

  • par une personne autorisée de l'établissement à partir d'une boîte aux lettres personnelle (si la procédure n'est pas automatisée en local).

Ce message est traité automatiquement au niveau central et déclenche l'exécution du «PUT» FTP du ou des fichiers de la bibliothèque sur son serveur local.

De cette façon, les établissements peuvent contrôler le déclenchement du PUT FTP, et le synchroniser avec les procédures locales telles que le backup, etc.

Procédure
  1. Comment le message GTD est-il « lu » ?

    Dans le système central, un programme scrute sa boîte aux lettres en permanence et quand il reçoit un message GET TITLE DATA, il analyse le « sujet » pour le valider. Le sujet doit contenir les chaînes GTD ou GET TITLE DATA (dans tous les cas).

    Lorsqu'un sujet invalide est détecté, un message est retourné à l'expéditeur, indiquant que la demande est erronée.

    Lorsqu'un sujet valide est détecté, le corps du message est analysé et une autre procédure est activée pour traiter cette demande de transfert de fichier(s).

    Cette procédure a besoin de quelques variables qui lui permettent de localiser les données de catalogage dans le système Sudoc.

  2. Qui demande les mises à jour ?

    La personne ou le mailer automatique à l'origine du message doit posséder une adresse de courrier électronique présente dans le fichier des adresses reconnues ; elle est alors autorisée, pour un ILN, à demander des fichiers de mises à jour de catalogage.

    Cette liste d'adresses autorisées pour un établissement doit être tenue à jour par le coordinateur.

    Si l'adresse de l'expéditeur ne fait pas partie de la liste des adresses reconnues, le message GTD est supprimé et un message d'erreur est retourné à l'expéditeur.

  3. Pour quel ILN les mises à jour sont-elles demandées ?

    Le corps du message doit contenir une ligne avec le nom de la variable GTD_ILN, comme par exemple GTD_ILN=050. Cela indique pour quel ILN les mises à jour sont demandées.

    Si cette variable est absente ou erronée, le message est supprimé et un message d'erreur est retourné à l'expéditeur.

  4. Les mises à jour sont demandées pour quelle année ?

    Le corps du message devra contenir une ligne avec le nom de la variable GTD_YEAR, comme par exemple : GTD_YEAR=AAAA, où 0 <= AAAA <= 9999. Cela indiquera pour quelle année les mises à jour sont demandées.

    Si cette variable est absente, le message est supprimé et un message d'erreur est retourné à l'expéditeur.

  5. A quelle adresse TCP/IP les mises à jour doivent-elles être envoyées ?

    Le corps du message doit contenir une ligne avec le nom de la variable GTD_FILE_TO, comme par exemple : GTD_FILE_TO=node.dummy.fr, où node.dummy.fr est un nom de machine ou une adresse TCP/IP valide. Cela indique sur quel serveur les fichiers de mises à jour devront être déposés.

    L'adresse du serveur ainsi que le nom d'utilisateur et le mot de passe (username/password) sont demandés à chaque établissement avant son démarrage dans le Sudoc. Ces données doivent être tenues à jour par le coordinateur.

    Lorsque cette variable a pour valeur MAIL_ONLY, aucun fichier n'est transféré, mais un message d'information est envoyé à l'expéditeur pour le renseigner sur liste et le contenu du ou des fichiers disponibles en central pour son ILN (nom, taille des fichiers, etc.).

    Si cette variable est absente ou ne correspond pas au nom de serveur communiqué par l'établissement, le message est supprimé et un message d'erreur est retourné à l'expéditeur.

  6. Quel numéro de demande («job») est spécifié ?

    Le corps du message doit contenir une ligne avec le nom de variable GTD_ORDER avec la structure suivante: GTD_ORDER=TRorder*, où order est le numéro de demande de traitement spécifique («job»), un numéro unique étant donné à chaque système local.

    Ce numéro correspond à la valeur du « JobId » indiquée dans le sujet du message : «For JobId = 11 and RunId = 14, status is 9» envoyé par le système central quand la demande de traitement s'est terminée avec succès (voir chapitre précédent).

  7. Quel sous-répertoire doit éventuellement être utilisé ?

    Le corps du message peut contenir une ligne avec le nom de variable GTD_REMOTE_DIR, comme par exemple : GET_REMOTE_DIR=directory, où directory est un [sous] répertoire du système local GTD_FILE_TO où les fichiers de mises à jour seront déposés.

    Si cet identificateur est absent, les fichiers seront déposés sur le répertoire par défaut du login.

    Modèle de message :

    To : abes_ftp@carmin.sudoc.abes.fr

    Adresse du système central

    From : Système_Local@SIGB.univ-XXX.fr

    Adresse autorisée du système local demandeur

    Subject : GET TITLE DATA

    Sujet obligatoire : analysé par le système central

    GTD_ILN = XXX

    Numéro ILN

    GTD_YEAR = 2005

    0 <yyyy < 9999

    GTD_FILE_TO = machine.domaine.fr

    ou = dec.dec.dec.dec

    ou = MAIL_ONLY

    Un nom de machine valide

    Adresse IP valide

    Demande d'envoi de message informatif

    GTD_ORDER = TR11*

    Order 11 : numéro de demande de traitement (=valeur du JobId du message “status is 9“)

    GTD_REMOTE_DIR = /temp/repertoire

    (Sous)-répertoire du système local

    Attention

    Il faut que le message GET TITLE DATA soit envoyé en texte normal, dans les options de la messagerie.

    Truc & astuce

    Avec Eudora, dans menu "Options" et "texte enrichi", il faut vérifier que ce soit bien "N'envoyer que du texte normal".

    Truc & astuce

    Avec Outlook, dans "Outils" puis « Format », il faut cocher "texte brut" et non pas "texte enrichi".

    Truc & astuce

    Avec Thunderbird, dans « Outils » puis « Options », il faut vérifier les paramètres de rédaction des messages.

ProcédureTransfert de fichiers par la procédure GET du serveur intermédiaire

Procédure
  1. Processus

    Une fois que le message de fin d'extraction des mises à jour en central (message « status is 9 ») est reçu en local, le processus de transfert du ou des fichiers sur le serveur intermédiaire est aussi déclenché par l'établissement :

    celui-ci doit envoyer le courriel GET TITLE DATA ou GTD à abes_ftp@carmin.sudoc.abes.fr pour obtenir le transfert du ou des fichier(s) de la journée ou de la semaine.

    Ce courriel a les mêmes contraintes sur l'expéditeur, qui doit posséder une adresse électronique présente dans le fichier des adresses reconnues

    Attention

    Attention, par rapport au GTD précédent, les paramètres GTD_FILE_TO et GTD_REMOTE_DIR sont différents.

    Modèle de message

    To : abes_ftp@carmin.sudoc.abes.fr

    Adresse du système central

    From : Système_Local@SIGB.univ-XXX.fr

    Adresse autorisée du système local demandeur

    Subject : GET TITLE DATA

    Sujet obligatoire : analysé par le système central

    GTD_ILN = XXX

    Numéro ILN

    GTD_YEAR = 2005

    0 <yyyy < 9999

    GTD_FILE_TO = machine.domaine.fr

    Nom du serveur intermédiaire communiqué par l'ABES

    GTD_ORDER = TR11*

    Order 11 : numéro de demande de traitement (=valeur du JobId du message “status is 9“)

    GTD_REMOTE_DIR =

    Aucun nom de sous-répertoire n'est indiqué

    Une fois que le ou les fichiers ont été transférés sur le serveur intermédiaire, le client FTP local rapatrie ensuite le ou les fichiers sur le serveur local par la commande FTP GET puis demande la destruction des fichiers sur le serveur intermédiaire (commande DELETE) une fois que les fichiers sont bien récupérés en local.

    Conseil

    A noter :Dans le cas des établissements utilisant le serveur intermédiaire pour récupérer les fichiers, il est nécessaire de les supprimer régulièrement (commande DELETE) car l'accumulation de fichiers crée des problèmes.

  2. Quelles sont les informations nécessaires à la mise en œuvre de cette procédure ?

    L'établissement doit communiquer à l'ABES l'adresse IP du client FTP qui viendra chercher les fichiers sur le serveur intermédiaire.

    En retour, l'ABES communique à l'établissement :

    • le nom du serveur intermédiaire

    • un login et mot de passe permettant à l'établissement se connecter au serveur intermédiaire pour faire le GET/DELETE.

    ConseilA noter

    Pour des raisons de sécurité, l'Abes tient à jour une liste d'IP autorisées à se connecter au serveur intermédiaire Vermeil, en FTP comme en SFTP . Toute IP doit donc avoir été déclarée préalablement dans la fiche Sudoc SIGB établissement. Par conséquent, seules les adresses IP de l'institution sont autorisées : les adresses IP de particulier ne sont pas susceptibles d'être autorisées.

    En cas de problème d'accès au serveur de fichiers, nous analysons les journaux applicatifs afin d’identifier l'origine du blocage.