Tivoli Service Desk 6.0 Developer's Toolkit - Guide du concepteur d'interface (Interface Designer)

Chapitre 2 : Concepts de l'interface EHLLAPI

Retour à la table des matières


Introduction

Généralités

La présente section concerne les thèmes suivants :

Initialisation des connexions

Avant que votre application TSD Script ne puisse entrer en interaction avec l'hôte, il est nécessaire d'initialiser l'application. L'interface EHLLAPI emploie un descripteur pour désigner la référence à la connexion établie et déclare une variable de type EHLLAPI, telle que :

conn:EMUCONNECTION;

Ensuite, il est nécessaire d'associer le descripteur à une session de terminal spécifique. La commande EHLLAPI qui sert à définir l'association avec la session est :

EMUConnect(conn, 'A');

Dans cette commande, le descripteur "conn" est associé à la session de terminal A.

Applications d'interface pour les connexions multiples

Etant donné que toutes les commandes EHLLAPI nécessitent la spécification de connexions, il est nécessaire de définir ces dernières par l'intermédiaire de l'application d'interface.

L'interface EHLLAPI permet la prise en charge de plusieurs connexions à des sessions de terminal, de sorte qu'une application d'interface peut s'apparenter à l'exemple ci-après :

VARIABLES
 conn1:EMUCONNECTION;
 conn2:EMUCONNECTION;
ACTIONS
 EMUConnect(conn1, 'A');
 EMUConnect(conn2, 'B');
END;

L'interpréteur de TSD Script associe différents attributs à ces connexions. Par exemple, sur l'une des connexions, la durée limite de surveillance peut être fixée à une seconde, tandis que cette durée peut être égale à dix secondes pour une autre connexion. TSD Script Interpreter utilise la valeur de durée limite appropriée en extrayant cette valeur du descripteur de connexion défini lors de l'exécution de la commande de surveillance.

Touches de commande

Les touches du clavier servent à demander à l'hôte d'exécuter une action. Supposons par exemple que, durant une édition de données, vous souhaitiez effacer le contenu d'une zone. Pour cela, vous appuyez sur la touche intitulée ERASE_EOF (effacer jusqu'à la fin de la zone).

Quel que soit le niveau de complexité du processus requis par l'hôte, la validation de données s'effectue aussi simplement qu'en appuyant sur la touche ENTREE.
L'interface EHLLAPI dispose d'une commande permettant de transférer des données vers l'hôte à l'aide de touches de contrôle. Elle reconnaît les codes entiers qui correspondent à des touches de contrôle. TSD Script intègre également des constantes servant de raccourcis pour les nombres entiers. Le code qui permet d'appuyer sur la touche ENTREE est illustré ci-après :

EMUPressKey(conn, $EMUEnter);

Programmes de surveillance

Définition

Chaque fois qu'une application soumet des données à l'hôte en vue de leur traitement, une durée s'écoule pendant laquelle l'application attend que l'hôte renvoie une réponse. Une interface doit obligatoirement permettre de définir des pauses et des temps d'expiration pour ces périodes. Ces dernières sont désignées par le terme de programmes de surveillance.

Commandes des programmes de surveillance

Il existe plusieurs commandes TSD Script conçues pour attribuer aux applications le droit d'exécuter les programmes de surveillance. Lorsque l'une de ces commandes est émise, l'application marque une pause jusqu'à ce que la condition soit satisfaite, ou jusqu'à l'expiration de la durée limite de surveillance. Les codes retour envoyés par les commandes des programmes de surveillance indiquent la liste des actions exécutées.

Les conditions qui déterminent la mise en attente d'une application dépendent du contexte. En règle générale, l'application attend la disparition de l'indicateur de verrouillage d'entrée système. Les autres programmes de surveillance peuvent porter sur :

Si vous souhaitez par exemple qu'une application reste en attente jusqu'à la disparition de l'indicateur de verrouillage d'entrée, vous pouvez entrer la commande suivante :

EMUWaitForNoX(conn);

Temps d'établissement

Si vous utilisez la commande EMUWaitForNoX, vous devez particulièrement surveiller l'indicateur X corespondant à l'activité de l'application sur l'ordinateur principal. Avec certaines applications, le symbole X peut "clignoter,", c'est-à-dire que le X disparaît momentanément, puis réapparaît pendant quelques secondes.

La commande EMUWaitForNoX permet de définir le paramètre complémentaire du temps d'établissement. Ce temps d'établissement définit la durée pendant laquelle l'indicateur X doit disparaître, jusqu'à ce que TSD Script Interpreter estime que la correspondance a été établie avec succès. Lorsqu'aucun temps d'établissement n'est défini, la valeur par défaut est de 500 millisecondes.

La commande précédente, complétée par une valeur optionnelle de temps d'établissement, aurait l'aspect suivant :

EMUWaitForNoX(conn, 1000);

Définition des conditions de surveillance effectives

Pour définir une commande de surveillance, il convient de faire en sorte que celle-ci délivre à l'utilisateur la plus grande quantité d'informations possible. Supposez par exemple que vous utilisiez une application centrale effectuant des demandes de noms et d'adresses, qui attend que vous appuyiez sur la touche ENTREE pour lancer le traitement des données.

La commande de surveillance utilisée dans un cas de ce type pourrait donc être :

rc := EMUWaitForStringAt(conn, 'ADD OPERATION
                         SUCCESSFUL',11,11);

Après avoir appuyé sur la touche ENTREE, le symbole X s'affiche pendant un certain temps dans la zone d'informations utilisateur, puis un message s'affiche à l'emplacement 11,11 pour signifier que l'opération d'entrée a été réalisée avec succès, par exemple :

MSG000695 ADD OPERATION SUCCESSFUL

Le code retour qui précède indique que l'opération est terminée et que l'insertion a bien été réalisée. Si le code retour indique l'échec de l'opération de surveillance, il est nécessaire de contrôler le code afin de savoir si le processus central est toujours actif, ou si l'insertion a réellement échoué. Ce code complémentaire s'exécute uniquement dans des conditions d'erreur.

Si vous lancez la commande :

rc :=EMUWaitForNoX(conn);

vous êtes uniquement averti que l'opération s'est achevée sur l'hôte. Le code doit continuer de rechercher un message d'exécution réussie et le contrôle doit être poursuivi pour toutes les instances de la commande.

Bien que les deux segments de code requièrent un niveau de contrôle égal, la première méthode permet d'accomplir le traitement avec succès.

Aucun contrôle supplémentaire n'est effectué, sauf en cas d'erreur. Les actions dont l'exécution est satisfaisante (cas le plus courant) prennent donc moins de temps que les actions qui se soldent par un échec.

Envoi de données

Généralités

L'interface EHLLAPI dispose d'un grand nombre d'outils permettant la saisie et l'édition de données, et qui comprennent les commandes suivantes :

Déplacement du curseur de l'hôte

L'exemple suivant illustre une commande type correspondant à une situation où l'utilisateur tape une chaîne de caractères à l'emplacement du curseur de l'hôte :

EMUTypeIn(conn, 'HELLO WORLD'); 

Il est important de noter que la commande TypeIn ne peut en aucun cas être exécutée lorsque le curseur de l'hôte se situe dans une zone qui ne reconnaît pas les entrées au clavier.

Effacement de zones

L'usage très fréquent d'une séquence de commandes a rendu indispensable la mise en oeuvre d'une commande TSD Script spécialement destinée à remplacer cette séquence. Cette commande revient à taper ERASE_EOF avant d'entrer la chaîne de caractères indiquée. Elle se présente comme suit :

EMUClrTypeIn(conn, 'HELLO WORLD');

Déplacement d'une zone à l'autre

La plupart des applications vous permettent de passer d'une zone à l'autre en utilisant la touche de tabulation ou les flèches. L'usage de la touche de tabulation est généralement plus rapide, sauf si vous ne renseignez pas toutes les zones. Dans ce cas, préférez l'usage des flèches de direction pour positionner directement le curseur sur les zones recherchées.

Vous devez vérifier la longueur maximale de chaque zone. Si l'interface EHLLAPI tente de saisir des informations alors que le curseur se trouve à un emplacement incorrect sur l'écran de l'hôte, ce dernier bloque le clavier jusqu'à ce que la commande de réinitialisation soit activée. Pour éviter ce problème, assuurez-vous que les données que vous saisissez sont moins longues que la zone de saisie, ou bien vérifiez que vous avez défini une longueur de troncature dans les commandes EMUTypeIn ou EMUClrTypeIn.

Fonctions de mappage

Comme la plupart des applications centrales consistent à saisir des informations, de nombreux scripts EHLLAPI consistent à répéter des opérations simples :

Compte tenu de la fréquence d'utilisation élevée de ces séquences, des fonctions de haut niveau ont été mises en oeuvre afin d'effectuer les opérations répétitives. Ces fonctions s'appellent des mappes. Les mappes, ou fonctions de mappage, vous permettent de relier des points de l'hôte à des zones d'enregistrement de TSD Script.

Une application peut appeler une commande TSD Script unique, EMUMapUpload, pour renseigner toutes les zones. TSD Script Interpreter procède plus rapidement au traitement des entrées de fichiers de mappe qu'à celui de séquences de commandes EHLLAPI plus simples. Le traitement des fichiers de mappe nécessite bien entendu l'emploi d'un certain temps système. En règle générale, vous devez envisager la création d'un fichier de mappe chaque fois qu'un écran comporte plus de cinq ou six zones. Pour plus d'informations, reportez-vous à la section"Fichiers de mappe et utilitaire de mappage."

Lecture de données

Introduction

L'usage des commandes de lecture est plus simple que celui des commandes d'envoi. En effet, d'une part, la position du curseur de l'hôte n'est pas pertinente pour une opération de lecture, d'autre part une application peut lire des données depuis n'importe quel point de l'écran de l'hôte.

Une commande de lecture, sous sa forme la plus simple, se présente par exemple comme suit :

EMUFillBuffer(conn, inString, row, column, length);

Cette commande lit les caractères de longueur en commençant par la lignes, puis les colonnes, et place la valeur résultante dans la variable inString.

Lecture des champs de données

Si vous avez l'intention de lire des champs de données à partir d'un écran, vous devez connaître la longueur maximale de chaque champ à consulter. Pour lire la longueur totale des champs, l'application hôte doit effacer tous les champs de données en vue de recevoir des données nouvelles. En général, les champs vides sont remplis par des traits de soulignement, vous permettant de visualiser la longueur maximale de chaque zone.

Fonctions de mappage

De même que pour les commandes d'envoi, il existe des commandes de mappage destinées au téléchargement d'un écran de données.

Avec la commande EMUMapDownload, vous avez la possibilité de lire plusieurs champs d'un écran d'hôte et de transférer les valeurs qu'ils contiennent vers les champs d'une variable d'enregistrement de TSD Script.

Capture d'un écran de l'hôte

Dans certaines situations, vous pouvez avoir besoin de capturer un écran entier de l'hôte (ou bien quelques portions rectangulaires de celui-ci), puis de le sauvegarder dans un fichier de texte. Ce scénario se rencontre le plus souvent lorsque l'écran n'est pas reconnu par votre application.

Pour comptabiliser le plus grand nombre possible d'occurrences, l'application effectue une capture de l'écran en cours et envoie une alerte relative au problème rencontré. La personne chargée de rechercher les causes de l'erreur utilise ce fichier pour rassembler les instructions liées à l'incident et déterminer la façon dont cet écran est parvenu jusqu'à l'application. TSD Script comporte une commande EMUOutFile qui permet de découper l'écran et de le placer dans un fichier.

Ecriture d'une interface

Introduction

D'une manière générale, vous avez toujours une idée de ce qu'une interface doit réaliser pour vous. La présente section a pour objet de vous aider à élargir ses spécifications, avant même de commencer son écriture.

Aspects liés à la conception

La première étape de conception d'une interface consiste à vérifier que vous maîtrisez suffisamment l'application pour laquelle l'interface est écrite.

Il convient que vous vous exerciez à travailler sur l'application cible, sauf si vous connaissez exactement les procédures pour :

En outre, vous devez connaître quelques "ficelles" particulières de votre application :

Conservez toujours, durant votre travail, des notes sur les étapes nécessaires à l'exécution d'actions précises. Ces étapes peuvent finalement servir à définir le code de votre interface.

Exigences

Essayez de déterminer les exigences "cachées". Analysez le type de données avec lesquelles votre application doit fonctionner. Dans le cas des applications Call Management et Problem management, vous pouvez demander à l'interface de traiter les incidents dont la priorité est la plus élevée, en préférant assigner aux incidents clos une priorité moindre.

Règles internes de l'entreprise

Assimilez les règles internes de votre entreprise ou du service dans lequel vous travaillez : avant de figer ces règles dans le code de l'interface, il convient que vous déterminiez si elles s'appliquent encore à la situation présente. Déterminez et solutionnez ces problèmes avant de procéder à la conception de l'interface.

Identificateurs d'écran

Assurez-vous que vous disposez d'un moyen de retrouver les écrans que vous utilisez. Dans le cas des applications centrales, il existe souvent un indicateur visible à l'écran. Le code de l'interface doit contrôler que l'écran affiché est le bon (en appelant une routine d'erreur, ou en déclenchant la sortie dans le cas contraire), avant d'autoriser la saisie de données. Cette méthode simple et efficace permet de garantir une bonne traçabilité des problèmes rencontrés par la suite.

Concurrence des données

La concurrence des données est un autre problème à résoudre avant de concevoir une interface. Pour toute situation dans laquelle deux systèmes contiennent les "mêmes" données, il est possible de modifier le même objet de données simultanément dans ces deux systèmes.

Vous devez en premier lieu déterminer de quelle manière votre système sera amené à détecter ce type d'occurrence. La méthode habituelle consiste à vérifier l'heure et la date d'un enregistrement sur le point d'être écrasé.

La deuxième étape a pour objet de déterminer l'opération censée se produire lors de la détection d'une "collision". Il peut s'agir d'une action aussi simple que la capture d'un enregistrement cible vers un fichier à plat ou l'envoi d'une alarme destinée à un administrateur quelconque. Parfois, une règle interne à l'entreprise peut stipuler que le "propriétaire" de l'enregistrement possède un droit prioritaire sur tout autre utilisateur amené à apporter des modifications.

Encodage et test

Lorsque vous concevez une interface, il est en général plus efficace de recourir à une méthode qui va du général au particulier. Toutefois, lors de son implémentation, il est souvent préférable d'adopter la méthode inverse. Ainsi, vous pouvez identifier et mettre en oeuvre les plus petites unités de travail de l'interface. Ensuite, vous pouvez procéder à la mise à l'essai individuelle de chaque élément. Ces éléments peuvent devenir les composants d'un module exécutant une fonction évoluée.

La procédure suivante a pour objet de vous familiariser avec le test d'une fonction :

  1. Créez une routine simple permettant :
  2. Lancez l'écran d'hôte approprié sur votre session de terminal.
  3. Exécutez la routine.
  4. Assurez-vous que la fonction cesse de s'exécuter à l'écran dans lequel elle a été lancée.

Il convient de tester toutes les routines séparément. Lorsqu'elles ne comportent aucune sortie visible, leur résultat peut être visualisé dans l'outil de débogage de TSD Script. Dans les autres cas, vous devez définir un groupe d'événements pour afficher ces résultats.

Lorsque le test porte sur des routines liées à des requêtes de données, il est conseillé de limiter autant que possible le verrouillage des tables SQL. L'utilisation de la commande SQLSelect, qui crée une boucle entre les cycles d'extraction et de téléchargement vers l'amont, provoque un verrouillage des tables dont la durée n'est ni nécessaire, ni acceptable.

Une fois que vous avez testé toutes les routines, vous pouvez procéder à la mise à l'essai de la routine principale. Il est probable que la routine principale nécessitera certaines opérations d'initialisation telles que :

Attention : Les points de raccordement entre les différents composants des routines doivent être déterminés avec précision. Vous devez impérativement vous assurer que ces composants permettent toujours de quitter l'application hôte sur un écran connu.

Définissez la structure des routines principales en faisant en sorte qu'une erreur de clé dans un composant de routine donne lieu à des implications appropriées dans le traitement. En d'autres termes, il convient que la routine principale ne tente jamais de poursuivre son exécution si le composant de routine signale une erreur irrécupérable.

Traitement des erreurs

Les applications d'interface doivent toujours être écrites dans une optique permettant le traitement des erreurs. De nombreux événements peuvent en effet se produire durant le fonctionnement de l'interface :

Le traitement des erreurs peut être accompli selon différentes options, en fonction du type d'erreur détectée. Ces options comprennent :

La meilleure approche consiste à combiner les options précédentes. Vous pouvez installer une routine de traitement général des erreurs, qui envoie une notification à un utilisateur et lance la journalisation des informations correspondantes. La routine peut être modifiée ultérieurement en vue de traiter les erreurs irrécupérables graves. Ces erreurs renvoient toujours une alarme destinée à l'utilisateur.


Tivoli Service Desk 6.0 Developer's Toolkit - Guide des API existantes

Retour à la table des matières

Copyright