AXOPEN

Problème de connexion : le Dispatch renvoie vers un service qui n’existe pas

Introduction

Dans un environnement Planisware Application Server possédant plusieurs Intranet Server (en cluster), le processus Dispatch va renvoyer tout nouvel utilisateur vers l'Intranet Server (IS) le moins chargé. Il peut arriver que la redirection échoue car l'url cible n'est pas disponible (souvent une erreur 500, service indisponible). En général cela arrive lorsque les processus Intranet Server ne sont pas encore totalement démarrés. Si le problème persiste, même après le démarrage complet des IS, il faut vérifier la pertinence de l'URL renvoyée par le Dispatch.

 

Analyse de l'URL de redirection

Pour vérifier quelle est l'URL de redirection il suffit de consulter le fichier de log du processus Dispatch.

Si l'URL renvoyée fait référence à un service (nom de server + port) incohérent cela signifie que la base de données a gardé en mémoire des informations erronnées. La section suivante explique comment le fonctionnement natif des processus Planisware peut être à l'origine de cette anomalie. 

 

Principe de fonctionnement du Dispatch pour la redirection

1) Chaque processus IS, Dispatch ou Timecard lorsqu'il est démarré va le signaler en ajoutant des informations le concernant en base de données dans les tables suivantes :

  • SERVER_URI
  • SERVER_STATUS

Par exempe si un IS est disponible sur le port 8400 du serveur "my_server" on aura une entrée dans la table SERVER_STATUS correspondant à ce service. 

2) Le Dispatch va lire ces informations pour savoir vers quel processus il peut rediriger les connexions utilisateurs. Il va alors envoyer une redirection vers l'un des services disponible. Dans notre exemple ce sera une URL du type "http://my_serveur:8000/BASE_DEV/OPX/my_server:8400/HOME"

3) Lors de l'arrêt d'un processus les informations relatives à ce processus sont purgées dans les tables SERVER_URI et SERVER_STATUS.

 

Problème en cas d'export de la base de données services démarrés

Lorsque l'on exporte la base de données P5 lorsque les services sont démarrés, les tables SERVER_URI et SERVER_STATUS ne sont pas vides. Donc si l'on importe cette base dans un nouvel environnement avec des noms de serveurs ou des numéros de ports différents les informations relatives à l'environnement d'origine ne seront jamais purgées (un processus ne peut purger ou mettre à jour que les informations qui le concernent). Le Dispatch redirigera donc vers des IS "fantômes" puisque pour lui les processus sont bien disponibles selon les informations de la base de données.

Pour s'en assurer il suffit d'arrêter tous les services Planisware (Intranet Server, Dispatch et Timecard) puis de vérifier en base de données que les tables SERVER_URI et SERVER_STATUS sont vides. Si ce n'est pas le cas c'est que l'on a bien des processus "fantomes" en base.

 

Solution rapide pour éviter ce problème

Une solution rapide et efficace pour résoudre ce problème est de forcer la purge des tables SERVER_URI et SERVER_STATUS services Planisware arrêtés (Intranet Server, Dispatch et Timecard). Au redémarrage seuls les processus "vraiment" démarrés apparaitront et le Dispatch ne tentera pas de rediriger des utilisteurs vers des URL erronnés.

Sous Oracle cette purge se traduit par les simples commandes SQL suivantes à exécuter sur le schéma de bases de données de l'application :

SQL> TRUNCATE TABLE SERVER_URI;
SQL> TRUNCATE TABLE SERVER_STATUS;