Accueil



Contact

FAQ bdfpick
  • bdfpick est-il un 'telnet graphiquement amélioré' ?

  • bdfpick est-il comparable aux autres interfaces pick-web ?

  • Quelle implémentation de Pick pour utiliser bdfpick ?

  • Quelle configuration logicielle pour utiliser bdfpick ?

  • Pourquoi bdfpick et bdfpickm ?

  • Qu'est-ce que le pool et comment le dimensionner ?

  • Qu'elle problématique pour la reprise d'applications "telnet" ?


  • bdfpick est-il un 'telnet graphiquement amélioré' ?
    Non, en fait, bdfpick est une interface http-pick, c'est à dire un programme permettant de transmettre des requêtes de type http à un système pick, et de renvoyer la réponse, c'est à dire la page html élaborée par pick, au serveur http, et, au final, au client qui a fait la demande.
    Le client est donc un 'browser', comme Internet Explorer ou Netscape.
    Le protocole telnet n'est utilisé qu'en interne, pour le transfert de la requète et la lecture de la réponse.
    (réf : faqbpi-01)

    bdfpick est-il comparable aux autres interfaces pick-web ?
    La plupart des interfaces pick-web que nous avons testées, avant de nous lancer dans l'élaboration de bdfpick, sont des interfaces externes, voire étrangère à Pick.
    Un langage de programmation externe (coldfusion, php, ...) est utilisé, et les relations avec Pick se font soit par un connecteur de type ODBC, inadapté aux structures multivaluées, soit par un connecteur spécialement développé, mais limité par le fait de devoir communiquer avec le langage de programmation externe.
    bdfpick utilise les capacités de pick dans le traitement des chaines de caractères afin que la page soit élaborée directement en basic Pick, éventuellement avec l'aide du 'parser' que nous avons développé.
    Donc, aucun nouveau langage à apprendre, et la possibilité de travailler directement sur des structures multivaluées !!!
    (réf : faqbpi-02)

    Quelle implémentation de Pick pour utiliser bdfpick ?
    Nous développons en interne dans des environnements D3 Windows et D3 Linux, notre système de production est de type D3 Linux, et nous avons déjà des clients qui utilisent Universe.
    Au vu du mode de fonctionnement, c'est à dire l'établissement d'un pool de liaison 'telnet' vers Pick, la chaine de connexion à Pick étant complètement paramétrable, bdfpick devrait pouvoir utiliser de la même manière JBase ou tout autre version du système Pick.
    (réf : facbpi-03)

    Quelle configuration logicielle pour utiliser bdfpick ?
    bdfpick se décompose en une partie java et une partie Pick.
    L'environnement que nous utilisons pour faire fonctionner nos servlet est Tomcat, d'apache.org, actuellement en version 3.3. Il s'agit d'un logiciel "libre", qui fonctionne aussi bien sous Windows que sous Linux.
    Comme Tomcat est capable de compiler "juste à temps" un servlet, il est nécessaire d'installer également un environnement Java complet, comme le jdk1.3.1 par exemple, lui aussi "libre" et fourni par Sun.
    Il est à noter que cet environnement ne doit pas être nécessairement installé sur le serveur Pick, et qu'une configuration avec un serveur Pick et un serveur Tomcat est donc possible.
    Tomcat peut fonctionner seul, mais, afin d'améliorer les performances du serveur, notamment pour les pages fixes et les éléments graphiques, il est bon d'installer aussi un serveur web, comme Apache par exemple.
    Le paramétrage est toutefois un peu plus complexe, mais reste abordable.
    (réf : faqbpi-04)

    Pourquoi bdfpick et bdfpickm ?
    bdfpick dispose de deux systèmes de connexion à pick, systèmes qui peuvent être utilisés simultanément, suivant le type de requète à traiter :
  • Si le temps d'exécution de la requète est court (durée inférieure ou très inférieure à la seconde) la requête est soumise au pool, via le servlet BdfPick (le fonctionnement du pool sera détaillé dans un autre chapitre).

  • Pour des temps plus long, pour l'exécution de "select" par exemple, on utilise le servlet BdfPickM, qui ouvre une nouvelle connexion telnet par ip physique, et soumet la requête à cette connexion "privée". Ce système consomme certes plus de voies pick, mais il permet d'éviter un engorgement du pool. Cette voie peut, suivant le paramétrage, soit être libérée immédiatement après l'exécution de la requête, soit être maintenue temporairement active, afin d'éviter le temps de reconnexion pour une seconde reqête du même utilisateur.

  • (réf : faqbpi-05)

    Qu'est-ce que le pool et comment le dimensionner ?
    Au démarrage, bdfpick établit "n" connexions avec pick, "n" étant le nombre de voies du pool.
    Chaque requète est donc acheminée vers la première voie disponible du pool, en scrutant successivement les voies en partant de la première (un système de load-balancing n'aurait aucun sens ici, puisque le système de destination est unique).
    Le pourcentage de requète soumise à la voie "n" du pool, établi sur une période d'exploitation réelle, est donc un bon système pour savoir s'il faut ajouter une voie "n+1" au pool.
    Dans la pratique un pool limité à une voie nous paraît dangereux, puisqu'une requete longue soumise par erreur au pool, ou une voie bloquée suite à une erreur de programme entrainerait un blocage de l'ensemble des utilisateurs (90 secondes en moyenne, pour une erreur, avec un paramétrage standard, avec un controle toute les 60 secondes et la déconnexion des voies occupées pendant 60 secondes, ces paramêtres pouvant être éventuellement modifiés).
    Mais, par expérience, une configuration de 2 voies, avec une programmation adaptée, et en ayant soin passer par BdfPickM pour les traitements de type "batch", suffit dans la grande majorité des cas.
    (réf : faqbpi-06)

    Quelle problématique pour la reprise d'applications texte ?
    En fait, le mode de fonctionnement habituel d'une application texte, en mode telnet, est d'afficher une information, de se positionner sur une zone de saisie, et d'attendre la saisie de l'utilisateur. Le programme est donc en attente sur cette instruction de saisie, classiquement un "input", et ne reprend son exécution qu'ensuite.
    En mode http, cette même séquence se traduira par 2 "appels" programme, même programme ou programmes distincts, l'un pour couvrir les instructions précédant l'instruction "input", et l'autre qui renverra la valeur saisie dans la page et qui continuera l'exécution du programme.
    Le problème qui se pose est donc la "continuité" du programme, c'est à dire la transmission des valeurs des variables affectées avant l'instruction "input" lors de la poursuite de l'exécution du programme.
    Afin de respecter la philosophie du modèle http et du mode de fonctionnement de bdfpick, deux solutions sont possibles :
  • la plus simple à mettre en oeuvre consiste à lancer l'application telnet sur une voie phantom, en remplaçant les "input" par la consultation d'un fichier mis à jour par le sous programme de saisie appelé par bdfpick. Le fonctionnement du programme reste identique au fonctionnement initial, et, si la boucle de lecture fichier est temporisée, avec un intervalle de 0.1 seconde par exemple, afin de ne pas "effondrer" le système, les performances sont bonnes. Mais la gestion d'un grand nombre de phantom, avec les problèmes de blocages dus à des déconnexions "sauvages" ou à d'éventuels bug de programmation ou d'exécution, peut s'avérer complexe.

  • la plus performante consiste à modifier le programme, afin de "poster" le contenu des variables, c'est à dire de sauvegarder ce contenu, de stopper le programme lorsqu'il arrive à une instruction "input", puis de le relancer, en restaurant les variables et en sautant directement à l'instruction suivant l'instruction "input". Comme dans le cas précedent, ces modifications de programmes peuvent se faire par programme.


  • (réf : facbpi-07)