Utilisation basique#

Configuration avec des variables d’environnement#

Nom de la variable

Description

Valeur par défaut

RABBIT_BLOCKED_CONNECTION_TIMEOUT

Valeur du timeout appliqué aux connexions synchrones en secondes

60 (valeur par défaut de l’instance RabbitMQ)

RABBIT_CONNECTION_ATTEMPTS

Nombre de tentatives de connexion

3 (valeur par défaut de l’instance RabbitMQ)

RABBIT_HEARTBEAT

Valeur du heartbeat en secondes

60 (valeur par défaut de l’instance RabbitMQ)

RABBIT_RETRY_DELAY

Valeur de l’intervalle entre chaque nouvelle tentative de connexion en secondes

60

Faire hériter son agent de PublishAgent#

Le module gpf_pyroger contient une classe PublishAgent qui définit le comportement d’un agent générique tel que décrit dans les spécifications.

N’importe quel agent de publication spécifique (agent de téléchargement, agent GeoServer, agent ROK4, etc.) héritera donc de la classe PublishAgent pour bénéficier des méthodes déjà implémentées par la classe mère.

Initialiser un agent spécifique#

Un agent spécifique devra reprendre les mêmes attributs que ceux de l’agent générique en plus de ses éventuels attributs spécifiques.

En reprenant le constructeur de la fonction mère (super().__init__(.)), l’agent va reproduire directement dans son constructeur les tâches qu’il doit produire de mnanière générale, à savoir :

  • La connexion à l’entrepôt (appel à la fonction connect_to_entrepot)

  • L’attente du démarrage du service (appel à la fonction _wait_geoservice_up)

  • La gestion des configurations initiales (appel aux fonctions supply_service et process_message)

  • Le traitement des offres reçues sur le bus au fil de l’eau (start_consuming_received_offers)

  • La gestion du contrôle de cohérence au fil de l’eau (consistency_control)

L’agent spécifique n’a plus qu’à surcharger ces 4 méthodes abstraites de PublishAgent :

  • get_published_offerings() : pour récupérer la liste des offres publiées sur un serveur (exemple : le serveur GeoServer) ;

  • is_offering_published() : pour vérifier si une offre a déjà été publiée sur un serveur spécifique de données (exemple : le serveur GeoServer) ;

  • publish_offering() : pour effectuer les actions spécifiques pour publier une offre.

  • synchronize_offering() : pour effectuer les actions spécifiques pour synchroniser une offre.

  • unpublish_offering() : pour effectuer les actions spécifiques pour dépublier une offre.

Traiter une offre#

La classe PublishAgent gère les comportements particuliers qui renvoient des statuts WARN. En effet, depuis la version 1.0.0 de pyroger, à chaque offre reçue sur le bus, deux étapes sont effectuées dans la fonction start_consuming_received_offers :

  • Un pré-traitement permet de vérifier qu’une offre existe sur le serveur de données. Si la demande est une publication d’une offre existante, ou bien une synchronisation d’une offre non-existante ou encore une dépublication d’une offre inexistante, alors le statut de l’offre est modifié. (appel à la fonction preprocessing_offer)

  • Le traitement est alors effectué sur le message de l’offre éventuellement modifié par l’étape de prétraitement dans ces cas particuliers.

Ainsi, puisque les cas particuliers sont déjà gérés dans pyroger, l’agent spécifique ne doit implémenter la fonction process_message que dans des cas “normaux”, à savoir publier l’offre si son statut est “PUBLISHING” ou “PUBLISHED”, la synchroniser si son statut est “SYNCRHONIZING” ou “MODIFYING” et la supprimer si son statut est “UNPUBLISHING” ou “UNPUBLISHED”.

Toutefois, l’agent spécifique doit gérer les cas d’erreur divers.