L'entité Dialogue (standard ou client TUI)

Le but de l'entité Dialogue est de développer et de générer les applications transactionnelles ou les clients TUI des applications client-serveur.

Un Dialogue représente l'interaction entre des Ecrans qui sont logiquement reliés entre eux. Un Dialogue est donc constitué d'une famille logique d'Ecrans. Tout Dialogue est décrit indépendamment des caractéristiques du matériel et du moniteur de temps réel qui sont utilisés.

Les éléments communs aux Ecrans du Dialogue sont définis au niveau de celui-ci pour homogénéiser la présentation et le fonctionnement des Ecrans. Ces éléments sont les suivants :
  • Les options de présentation, indiquées dans l'onglet Définition du Dialogue :
    • Le nombre de lignes et de colonnes dans l'Ecran,
    • Le type de libellé retenu pour les Rubriques (long, court, relationnel, colonne),
    • La présentation générale de ces Rubriques (nombre de Rubriques par ligne, type de cadrage par exemple),
    • Les attributs de présentation (brillance, couleur) selon la nature des informations (Rubriques affichées, saisies, libellés, messages d'erreur par exemple).
  • Les fichiers communs (zone de conversation, fichier libellés d'erreur), ainsi que certaines options de traitement, au niveau de l'onglet Complément du Dialogue.
Ces valeurs par défaut, définies au niveau du Dialogue, peuvent être modifiées pour chaque Ecran.

Vous ne pouvez pas générer un Dialogue entier mais vous pouvez générer chacun de ses Ecrans, l'un après l'autre.

Il existe deux types de Dialogue :
  • Les Dialogues standard des applications transactionnelles permettent d'effectuer les tâches suivantes :
    • Décrire les Ecrans,
    • Générer automatiquement des masques d'Ecrans,
    • Générer les programmes assurant les traitements décrits pour chaque Ecran, ainsi que la cinématique du Dialogue.
  • Les Dialogues client TUI des applications client-serveur permettent d'effectuer les tâches suivantes :
    • Décrire les Ecrans client TUI,
    • Générer automatiquement les masques d'Ecrans TUI,
    • Générer les composants client ainsi que la cinématique des Ecrans TUI et celle de l'échange entre composants client et composants serveur.
    Deux types d'architectures sont possibles : avec ou sans moniteur.
    • Dans une architecture sans moniteur, les composants client appellent directement les composants serveur (un Moniteur Serveur ou un Composant Applicatif).

      Les traitements d'appel sont indiqués directement dans chaque composant client.

      Suivant le mode de communication, chaque client gère l'envoi de ses données au service. Le retour est fait juste après la fonction d'appel et les traitements sont effectués en séquence.

      Vous avez toujours la possibilité de rajouter vos propres traitements en vous insérant avant ou après l'appel du service.

    • Dans une architecture avec moniteur, le Moniteur Client appelle un Moniteur Serveur ou le Composant Applicatif concerné. Le Moniteur Serveur appelle le service demandé et rend la main soit au Moniteur Client, soit directement au Client.

      Le moniteur permet de regrouper les informations et les traitements communs (gestion des communications, compactage, trace, COMMIT ou ROLLBACK, particularités du site). Pour certains environnements tels que Microfocus et Tuxedo, il s'agit d'une obligation.

      De plus, l'utilisation d'un moniteur peut être justifiée par des contraintes applicatives (confidentialité, encryptage des données) ou techniques (protocoles de communication). Les options moniteur permettent à l'utilisateur de s'interfacer plus facilement avec sa propre méthode de communication et d'insérer ses traitements de sécurité et d'encryptage et de décryptage des données.

L'Ecran C/S ou Client TUI

Cette entité est réservée aux applications TUI.

Le composant client permet d'émettre des demandes de service au composant serveur et gère l'interface avec l'utilisateur.

Il reçoit les données saisies, les contrôle et gère les erreurs détectées, puis appelle les services d'accès aux données ou de traitements de calcul, avant de mettre en forme et d'afficher les données applicatives.

Le Moniteur Client TUI

Ce moniteur est réservé aux applications TUI. Il effectue les opérations suivantes :
  • Initialise la conversation,
  • Assure la liaison entre les différents composants clients,
  • Appelle le service demandé ou le Moniteur Serveur correspondant à ce service.
Le passage des informations entre le moniteur et les clients se fait par l'intermédiaire d'une zone de communication qui contient les données suivantes :
  • Informations technologiques propres aux clients,
  • Informations nécessaires à l'appel et au retour du Composant Applicatif, telles que :
    • Le nom du service à appeler,
    • Le nom du moniteur serveur,
    • La Vue Logique traitée par le client,
    • La fonction d'aiguillage qui permet le retour en séquence sur les traitements client.

Le Sous-Moniteur Client TUI

Ce moniteur est réservé aux applications TUI. Il assure les fonctions suivantes :
  • La liaison entre les composants clients de ce sous-moniteur,
  • La liaison à un autre sous-moniteur pour l'appel d'un composant client n'appartenant pas à ce sous-moniteur,
  • L'appel du service demandé ou du Moniteur Serveur correspondant à ce service.

Chaque composant client dépendant d'un Moniteur Client peut être défini au sein d'un Sous-Moniteur Client. Un sous-moniteur est donc un ensemble de composants clients dont le choix peut dépendre de considérations logiques (composants clients travaillant dans le même domaine) ou systèmes (division en fonction de tâches de consultation ou mises à jour, de priorité d'exécution par exemple).

L'utilisation de sous-moniteurs et de la liste des composants client qui les composent est déterminée dans la WORKING-STORAGE SECTION.

Le moniteur pour le web

Ce moniteur est réservé aux applications Dialog web revamping. Cette fonction permet l'habillage d'applications développées avec le module Dialogue sous forme de pages HTML.

La description du Dialogue doit contenir certaines informations liées à la communication.

Dans la partie site central, il faut générer un message logique qui permettra de gérer l'affichage d'écran ou l'envoi du message au moniteur de communication web.

Lors de la première communication, le moniteur web appelle le premier Ecran et crée sous forme de fichier, une zone de sauvegarde de la partie commune du Dialogue. Les fois suivantes, la partie commune du Dialogue sera récupérée puis l'Ecran sera appelé.

A chaque retour, le moniteur envoie le message au web et sauvegarde la partie commune du Dialogue en utilisant l'identifiant. Chaque Ecran est un sous-programme du moniteur.

Génération

Pour des explications sur le généré d'un Ecran, reportez-vous à Description du COBOL généré à partir d'un Ecran.

Remarque : Pour les instances importées depuis Pacbase, la langue du squelette de la génération locale est identique à celle de Pacbase. En effet, cette information est reprise lors de l'extraction des modèles Pacbase et de l'import. Elle est stockée au niveau de la Bibliothèque

Vos commentaires