Dans cet article


Offres d'emploi

Tags

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
  • 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 

    Pour s'en assurer il suffit d'arrêter tous les services Planisware 

     

    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 :

    <span >SQL> TRUNCATE TABLE SERVER_URI;
    SQL> TRUNCATE TABLE SERVER_STATUS;</span>

     

    L'équipe AXOPEN

    Voir aussi les articles suivants

    Supervision des processus Planiware sous UNIX

    Supervision des processus Planiware sous UNIX

    Le 18/02/2012 par Thibault Gonin

    Sous UNIX lorsqu’une instance Planisware (PLW) est démarrée un certain nombre de processus système apparaissent. Chaque module Planisware (Connect, Application Server ou Intranet Server, Dispatch, Timecard etc.) possède un certain nombre de processus et sous-processus qui lui est propre. En exploitation il peut être intéressant de superviser ces processus unix pour détecter une éventuelle défaillance de l’un d’eux. Cet article présente d’une part les processus Planisware présent sur un serveur UNIX et d’autre part les stratégies de surveillance que l’on peut mettre en place pour une supervision efficace.
    Lire l'article

    Planisware 5 : gestion des timeouts lors des traitements longs en client léger
    Description du problème Même s'il est en général déconseillé de lancer des traitements trop longs directement en client léger il peut arriver que certaines actions longues (plusieurs minutes) soient quand même réalisées en client léger. Dans certains cas le traitement peut échouer à cause des timeouts. Piste de résolution n°1 : améliorer les performance du traitement C'est la première piste à creuser lorsqu'un traitement est long. Il arrive fréquemment que le traitement réalisé ne soit pas optimisé.
    Lire l'article

    Vérification du modèle physique de données

    Vérification du modèle physique de données

    Le 15/02/2013 par Thibault Gonin

    Objectif : Vérifier le modèle de donnée. Cette action est à faire dans tous les cas où le modèle physique de données est modifié (nouveau champ, nouvelle table …). Il faut passer par cette étape pour que les modifications soient prises en compte.   Procédure de vérification du modèle physique de donnée : Passer en mode « administrateur » (Fichier > Administration > Mode administrateur). Cela permet de débloquer la fonctionnalité de vérification du modèle physique de données.
    Lire l'article