Le but de l'entité Dialogue est de développer et de
générer les applications transactionnelles de la fonction Dialogue
ou les applications TUI de la fonction Pacbench/CS.
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, qui implémentent la fonction Dialogue
de Pacbase. Cette
fonction permet d'effectuer les opérations 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 TUI, qui implémentent la fonction Pacbench C/S.
Cette fonction permet d'effectuer les opérations suivantes :
- Décrire les composants client TUI en utilisant l'entité Ecran/CS
du métamodèle Pacbase,
- 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 sSrveur 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/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 Slient. 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