FR2683108A1 - Procede de communication reliant un nombre limite ou non limite de sites en une liaison interactive reelle ou virtuelle. - Google Patents

Abstract

Un procédé de communication relie un nombre limité ou non limité de sites en une liaison interactive réelle ou virtuelle, chaque site local (terminal) ou central (serveur) étant conçu sur la même architecture; ceci permet à un site de fonctionner simultanément en tant que site local et site central d'un autre réseau de sites locaux, chaque site local pouvant de même se connecter simultanément ou non avec un nombre limité ou non limité de sites centraux. Le procédé de l'invention 1 comprend un noyau de communication 3 permettant le transfert de données entre deux procédés, une fonction traitement local 2 qui effectue la liaison entre un programme d'application 9 et le noyau de communication 3 par l'intermédiaire de requêtes 7 et qui permet l'exécution de procédures sur le site local commandées par le programme d'application, une fonction traitement central 4 qui interprète et exécute sur le site central les requêtes de type 1, 2 et 3 émises par le programme d'application, ainsi que des bases dénommées réparties de type BLR et BCR (base locale répartie et base central répartie) dans le cadre de la présente invention. L'invention concerne également un procédé de mise à niveau qui permet une mise à jour constante de bases de données réparties de type BLR et BCR.

Description

DESCRIPTION
La présente invention concerne un procédé de communication permettant de relier, au moyen d'une ou plusieurs lignes transmission, en une liaison interactive réelle ou virtuelle un nombre limité ou non limité de sites locaux à un site central. On entend par Site un micro-ordinateur ou un ensemble de micro-ordinateurs reliés en réseau. On entend par Site Local un Site1 pouvant émettre des requêtes vers un
Site serveur et attendre des réponses à ces requêtes de manière intéractive ou non. On entend par Site Central un Site serveur pouvant traiter simultanément les requêtes de plusieurs Sites Locaux.

Chaque site local ou central est conçu sur la même architecture, ceci permettant à un site local de fonctionner simultanément en tant que site local et site central d'un autre réseau de sites locaux, chaque site local pouvant également se connecter simultanément ou non avec un nombre limité ou non limité de sites centraux.

Le procédé permet également à tout terminal "primaire" dépourvu d'unité de calcul et de mémoire d'être connecté.

Des applications hétérogènes installées sur les divers sites peuvent communiquer interactivement avec le site central en écrivant des requêtes sous forme d'enregistrements dans un fichier et recueillir les résultats provenant de l'exécution de ces requêtes dans un autre fichier créé par le système.

Le système fonctionne en multitâches : plusieurs tâches peuvent être lancées simultanément et en tâche de fond soit parallèlement au fonctionnement normal du poste.

Le but de la présente invention est de pallier la carence des moyens de transmission actuels entre ordinateurs où les liaisons entre les différents systèmes sont organisées de manière centralisée et où les fonctions de serveur et de terminal sont rigides. Un serveur reste toujours serveur, un terminal reste toujours un terminal.L'originalité de l'invention consiste dans l'attribution d'une double spécialisation pour chaque site qui peut être simultanément local et central (terminal et serveur), elle consiste également dans les possibilités de liaisons multiples entre un site local et plusieurs sites centraux ainsi que dans la conception d'un système de mise à niveau de bases de données réparties permettant la liaison non simultanée d'un nombre non limité de sites locaux à un site central.

Pour donner une meilleure compréhension des caractéristiques et avantages de l'invention, la description suivante s'appuie sur les dessins annexés dans lequels:
La figure 1 schématise la liaison entre un site local et un site central suivant le procédé de
l'invention.

La figure 2 représente un organigramme de configuration générale du procédé de l'invention.

La figure 3 représente un organigramme de la configuration de la fonction traitement local, appartenant au procédé de l'invention.

La figure 4 représente un organigramme de la configuration de la fonction traitement central, appartenant au procédé de l'invention.

La figure 5 représente un organigramme de la configuration du noyau de communication, appartenant au procédé de l'invention.

La figure 6 représente un schéma de structure de fiches appartenant à une base de données de type BLR et BCR , appartenant au procédé de l'invention.

La figure 7 représente un organigramme de la configuration de mise à jour locale et centrale sur le site local, dans le cadre du fonctionnement de la mise à niveau de bases locales réparties, appartenant au procédé de l'invention.

La figure 8 représente un organigramme de la configuration de mise à jour locale et centrale sur le site central 1, dans le cadre de fonctionnement de la mise à niveau de bases locales réparties appartenant au procédé de l'invention.

Description du principe de fonctionnement - Figures I et 2
Le principe de liaison entre une application installée sur un site local et le procédé de l'invention dit procédé de communication (1) s'effectue en donnant la possibilité au programme d'application (9) d'émettre en groupe des requêtes par l'intermédiaire d'un fichier (étape 7) vers la fonction traitement local (2) appartenant au procédé de l'invention, introduite sur le site local et de se mettre en attente de réception d'un fichier contenant les informations qui résultent des opérations commandées par les requêtes, provenant de cette même fonction: traitement local (étape 8).

Les avantages de ce principe de liaison sont de donner la possibilité à des applications hétérogènes installées sur les divers sites, de pouvoir communiquer interactivement avec le site central.

Les transactions effectuées par l'intermédiaire de fichiers, bien que lentes, sont cependant admissibles dans la mesure ou plusieurs requêtes peuvent être transmises dans une même opération, la nature du programme émetteur de requêtes pouvant optimiser les opérations d'échange d'informations.

Le support fichier peut cependant être remplacé par des zones mémoires partagées par le programme d'application et le procédé de l'invention.

Dans tout ce qui suit ne sera cependant considéré que le support fichier. Les informations qui résultent des opérations commandées par les requêtes sont écrites sur un fichier par la fonction traitement local et lues par le programme d'application. Certaines requêtes, dites de type 1 sont directement exécutées par la fonction traitement local, d'autres sont, par contre, codées et transférées vers le noyau de communication 3 qui émet au moyen d'une ligne de transmission 6 ces codes vers un site central.

Ce dernier réceptionne à partir d'une ligne de transmission 6 les codes émis, correspondants aux différentes requêtes, au moyen d'un noyau de communication 3 qui transfère ces codes vers la fonction traitement central 4 exécutant les opérations commandées par les-dites requêtes.

Les informations provenant de l'exécution de ces requêtes sont transférées vers le noyau de communication et ensuite vers le site local au moyen de cette même ligne de transmission 6 , puis reçues par le noyau de communication 3 présent sur le site local et transférées vers la fonction traitement local 2 qui introduit sur un fichier ces informations qui seront lues par le programme d'application.

Nous allons maintenant décrire, au moyen de la figure 2, les opérations nécessaires au fonctionnement général du procédé de communication.

Le procédé de communication 1 est lancé automatiquement au démarrage du site local ou central. Ce procédé de communication teste la connexion établie lors d'un appel provenant d'un autre site (étape 201).

Dans ce cas, le code émis provenant de l'appel est examiné (étape 204). Si le code est reconnu, la fonction traitement central 4 est lancée (étape 205). Dans le cas contraire les applications destinées aux terminaux "primaires" sans unité de calcul et de mémoire sont lancées (étape 206).

Si aucune demande de connexion n'est effectuée, (étape 201), le procédé vérifie si la tâche lancée est la première tâche exécutée (étape 202). Dans ce cas il y a mise en attente de l'apparition d'un fichier dans un environnement donné (étape 207). Dès l'apparition de ce fichier créé par une application consultante (étape 7), le procédé donne l'autorisation à une tâche annexe de pouvoir être exécutée (étape 208), puis le procédé se met à nouveau en attente de l'apparition d'un nouveau fichier concernant une nouvelle tâche annexe; si un nouveau fichier, appartenant à une tâche en cours de fonctionnement, est créé, ce dernier n'est pas pris en compte.

Si la tâche lancée n'est pas la première exécutée, le procédé vérifie si une autorisation de traitement a été donnée à une tâche annexe (étape 203). Dans ce cas, la fonction traitement local 2 est exécutée (étape 209).

On remarquera sur la figure 2 que le nombre de tâches exécutant simultanément la fonction traitement central est lié au nombre de voies actives sur le site.

On remarquera également que plusieurs tâches exécutant simultanément les fonctions traitement local et traitement central, peuvent être lancées.

Lorsqu'une liaison est établie entre deux sites, le site local échange des informations avec le site central par l'intermédiaire du noyau de communication au niveau de l'étape 209 et le site central échange des informations avec le site local par l'intermédiaire du noyau de communication au niveau de l'étape 205.

On va maintenant définir l'environnement et les opérations nécessaires au fonctionnement des différentes requêtes pouvant être émises par le programme d'application vers le procédé de l'invention.

Les opérations effectuées par les dites requêtes ont une action sur des bases de données propres au serveur et sur des fichiers implantés sur les sites locaux ou centraux. Ces bases sont définies de la manière suivante:
Chaque fiche, appartenant à une base, comporte un nombre non limité de champs.

Chaque champ est un enregistrement limité à 256 caractères. Les 8 premiers champs peuvent être utilisés comme index.

Ces bases se divisent en deux catégories:
La première catégorie se compose de bases dites réparties, c'est à dire, pouvant être 'mises à niveau' dont le mode de fonctionnement est décrit plus loin.

On entend par 'mise à niveau' une mise à jour constante et automatique, s'effectuant en 'tâche de fond' (fonctionnement parallèle à celui d'autres tâches), entre une base Répartie implantée sur un site central et l'ensemble des bases du même type rattachées à cette base et implantées sur différents sites locaux.

On nommera Base Locale Répartie ou BLR, une base de ce type installée sur un site Local et Base Centrale Répartie ou BCR, une base de ce type installée sur un site Central. Ces bases doivent être paramétrées d'une certaine manière, ce paramétrage s'effectuant automatiquement par le procédé lors de l'exécution de requêtes de mises à jour telle que la requête 3 de type 1 décrite plus loin. Le procédé reconnaît le type de base (répartie ou non) lors de la requête 1 (permettant l'ouverture d'une base), décrite plus loin.

La seconde catégorie se compose de bases dites Naturelles qui ne peuvent être mises à niveau et qui ainsi n'exigent pas le paramétrage obligatoire dans le cas des BLR ou des BCR.

On nommera Base Locale Naturelle ou BLN, une base de ce type installée sur un site Local et Base Centrale Naturelle ou BCN, une base de ce type installée sur un site Central.

Les requêtes sont divisées en trois catégories.

La première catégorie est composée de requêtes, dites de type I, permettant à l'utilisateur l'accès aux BLR ou aux BLN, c'est-à-dire, comme nous venons de le voir, à des bases de données propres au procédé et implantées sur le site local.

Comme on peut le voir sur la figure 3, les requêtes de type 1 sont lues sur un fichier créé par l'application consultante (étape 302), puis interprétées (étape 303) et directement exécutées sur le site local (étape 310) par la fonction traitement local (auprès lecture, le fichier est ensuite détruit).

En cas d'erreur de syntaxe (étape 304) le résultat de l'erreur est introduit sur un fichier nommé : fichier des réponses (étape 309) et la fonction traitement local est arrêtée et la tâche désactivée (étape 315).

Après exécution, la fonction traitement local introduit les réponses exigées par ces requêtes sur le-dit fichier des réponses (étape 313). Cette fonction se met ensuite en attente de l'apparition d'un nouveau fichier lié à cette tâche et créé par l'application consultante (étape 301).

La fonction traitement local est arrêtée et la tâche désactivée après réception d'une requête de fin traitement soit la requête 15 définie plus loin (étape 314).

Le second groupe de requêtes est composé de requêtes, dites de type 2, ayant une action en lecture et écriture sur des BOR, des BCN ou sur des fichiers présents sur le site central. Dans ce cas, si la demande de connexion avec ce site n'est pas déjà établie, la première requête de ce groupe doit effectuer cette demande.

Comme on peut le voir sur la figure 3, lorsqu'une demande de connexion avec un site central est effectuée (étape 306) et qu'une ou plusieurs voies sont déjà occupées, le système vérifie si une nouvelle voie est disponible (étape 307). Dans ce cas, toutes les opérations liées à cette connexion, s'effectuent sur cette nouvelle voie. Dans le cas contraire, un message d'erreur est renvoyé sur le-dit fichier des réponses (étape 309), la fonction traitement local est arrêtée et la tâche désactivée (étape 315).

Les requêtes de type 2 sont dites interactives car elles nécessitent le renvoi d'une réponse ou d'une observation vers le site local émetteur.

Celles-ci, après avoir été lues sur un fichier créé par l'application consultante et ce fichier étant ensuite détruit, sont analysées par un module Interpréteur dont la fonction est de détecter les erreurs de syntaxes et de coder les lignes de requêtessous forme compactée (étapes 302 et 303).

Si aucune erreur de syntaxe n'est détectée (étape 304), les lignes de requêtes de type 2 sont codées et émises vers le noyau de communication (étapes 311 et 312).

Ce dernier (figure 5 ) émet les lignes codées en les divisant par paquets, chaque paquet étant précédé de deux octets de contrôle caractérisant le paquet, vers le modem ou la voie du site central connecté à ce site local puis se met en attente d'une réponse du site central (étapes 501, 502, 503 et 504).

Les fonctions d'émission des requêtes par le site local : traitement local et de réponses à ces requêtes par le site central : traitement central coexistent dans le système et peuvent donc être mises en fonction suivant la nature des codes reçus, comme nous l'avons vu figure 2, un site pouvant par exemple, utiliser la fonction traitement local sur une voie et la fonction traitement central sur une autre voie et être ainsi simultanément site local (ou terminal) et site central (ou serveur).

Le site central reçoit le paquet émis dans son noyau de communication (figure 5), vérifie la validité du-dit paquet à partir des deux premiers octets de contrôle (étape 505) et renvoie un caractère de validation de conformité ou d'erreur suivant que la validité du paquet reçu est vérifiée ou non. Si un caractère d'erreur est renvoyé vers le site local, celui-ci renvoie à nouveau le-dit paquet.

Si le paquet transmis est invalidé trois fois, le procédé suit la même procédure produite en cas d'erreur de syntaxe, une demande d'arrêt de traitement étant émise (étapes 506, 313, 314 et 315).

Lorsque le paquet transmis est validé, le site local émet un nouveau paquet suivant la même procédure jusqu'à l'émission de toutes les lignes de codes détenues par le noyau de communication du site local.

Dans ce cas, le site central transfère ces lignes de codes de son noyau de communication vers la fonction traitement central (figure 4) qui exécute les commandes correspondant aux diverses requêtes émises par le site local (étapes 401, 402 et 403) .

Après l'exécution de ces requêtes, la fonction traitement central transfère vers le noyau de communication les observations ou les réponses sollicitées par ces dernières (étapes 404 et 401).

Le transfert des informations entre les noyaux de communication du site central et du site local s'effectue suivant le même protocole que celui décrit précédemment.

Lorsque toutes les réponses ont été émises vers le site local, celui-ci transfère ces informations du noyau de communication vers la fonction traitement local qui crée un fichier dans un environnement donné et introduit les informations dans ce fichier (étapes 312 et 313).

Ce fichier de réponses, dès son écriture terminée, est lu par l'application 9 émettrice des requêtes (étape 8).

Comme nous l'avons vu précédemment, en cas d'erreur de syntaxe (étape 304) le résultat de l'erreur est introduit sur un fichier nommé fichier des réponses (étape 309) et la fonction traitement local est arrêtée et la tâche désactivée (étape 315).

La fonction traitement local se met ensuite en attente de l'apparition d'unnouveau fichier lié à cette tâche et créé par l'application consultante (étape 301). La fonction traitement local est arrêtée et la tâche désactivée après réception d'une requête de fin traitement soit la requête 15 définie plus loin (étape 314).

Le troisième groupe de requêtes est composé de requêtes, dites de type 3, qui déclenchent une action se prolongeant bien après la mise en route de ladite action, celle-ci s'exécutant en multitâche parallèlement au fonctionnement normal du site local.

Plusieurs actions de ce type peuvent s'exécuter simultanément sur le site local. Ces actions effectuent des lectures et écritures sur des bases de données ou sur des fichiers présents sur le site central et le site local, en utilisant le même principe de communication que celui des requêtes dites de type 2, entre les fonctions traitement local, appartenant au site local, noyau de communication, appartenant au site local et au site central, et traitement central appartenant au site central.

Nous allons maintenant définir les requêtes appartenant aux types 1 et 2 et 3. Les requêtes de type I sont les suivantes:
Requête 1: Permet l'ouverture ou la création d'une BLR ou d'une BLN sur le site local en donnant le nombre d'index appartenant à cette base.

Requête 2 : Permet d'introduire ou de recevoir des valeurs numériques ou alphanumériques dans une table appartenant à la fonction traitement local.

Requête 3 : Permet la lecture la modification ou la création d'une fiche appartenant à une
BLR ou une BLN sur le site local, les éléments de la table, introduits par la requête 2, jouant un rôle de transfert des informations vers cette base en cas de modification ou de création, et de réception en cas de lecture.

Requête 4 : Renvoie le contenu d'un champ d'une fiche appartenant à une BLR ou une
BLN.

Requête 5 : Permet de se positionner sur une fiche appartenant à une BLR ou une BLN.

Requête 6 : Permet d'annuler une fiche appartenant à une BLR ou une BLN.

Requête 7: Renvoie le nombre d'enregistrements supprimés dans une BLR ou une BLN.

Requête 8 : Renvoie le nombre d'enregistrements valides dans une BLR ou une
BLN.

Requête 9 : Permet le renvoie de la liste des index d'une BLR ou une BLN.

Requête 10 : Teste l'existence d'une BLR ou une BLN, donc implantée sur le site local.

Requête 11: Permet de fermer une ou plusieurs BLR ou une BLN.

Requête 12 : Renvoie le nombre d'index d'une BLR ou d'une BLN.

Requête 13 : Détruit une BLR ou une BLN dont le nom est donné, donc implantée sur le site local.

Requête 14 : Réinitialise la table dont les éléments ont été introduits par la requête 2.

Requête 15 : Fermeture de toutes les bases de données, désactivation de la tâche en cours de traitement et dans le cas des requêtes de type 2 fermeture de tous les fichiers utilisés et déconnexion avec le site central.

Les requêtes dites de type 2 sont définies de la manière suivante:
Les définitions de toutes les requêtes de type 1 s'appliquent aux requêtes de type 2 mais cette fois ayant une action sur les BCR ou les BCN implantées sur le site central. La requête 3 est définie de la même manière en donnant en plus l'accès à des fichiers présents sur le site central.

A ces requêtes, on rajoute les définitions des requêtes suivantes:
Requête 16 : Demande de connexion avec le site central en donnant le numéro de téléphone du site central, son code d'accès, et les références du site local.

Requête 17: Permet la duplication de fichiers présents sur le site central.

Requête 18 : Teste l'existence d'un fichier présent sur le site central.

Requête 19 : Détruit un fichier dont le nom est donné, sur le site central.

Requête 20 : Création d'un dossier sur le site central.

Requête 21: Renvoie le contenu d'un dossier présent sur le site central.

Requête 22 : Renomme un fichier présent sur le site central.

Les requêtes dites de type 3 sont définies de la manière suivante:
Requête 23 : requête de mise à niveau des bases de type BLR et BCR
Requête 24: téléchargement de dossiers vers un site central ou local.

Requête 25 : compactage de bases.

Nous allons maintenant décrire le procédé de mise à niveau de bases de données réparties
Ce procédé permet, pendant un intervalle de temps géré par le site central, une mise à jour constante entre une base de type BLR installée sur un site local et une base de type
BCR installée sur un site central.

Dans le cadre de l'utilisation de ce procédé, tous les sites locaux travaillent sur des bases de type BLR contenant les mêmes informations, chaque base étant implantée sur chaque site d'où un temps d'accès négligeable et parallèlement, chaque base est mise à niveau avec une base centrale de type BCR implantée sur le site central, pendant le fonctionnement normal du poste local. L'avantage de ce système est de pouvoir relier à un site central un nombre non limité de sites locaux. L'arrêt d'une connexion entre un site local et le site central ne perturbe pas le fonctionnement du système, la mise à niveau pouvant se poursuivre normalement lors d'une prochaine connexion avec le site central.

Le nombre de sites locaux pouvant être reliés de cette manière avec un site central est fonction du nombre de voies du site central, des durées de connexion permises par le site central et de l'intervalle de temps séparant l'arrêt d'une connexion d'une nouvelle connexion donné en tant que paramètre de la procédure de mise à niveau. Le nombre de sites locaux reliés de cette manière peut donc être rapidement supérieur au nombre de voies appartenant au site central.

On nommera Dl ou Date Inverse sur 14 caractères, l'année le mois et le jour en cours sur les six premiers caractères; l'heure, la minute, la seconde et le soixantième de seconde en cours faisant parties des huit caractères suivants.

Nous avons vu précédemment que chaque BLR et BCR devait être paramétrée d'une certaine manière.

Les fiches appartenant aux BLR doivent être paramétrées de la manière suivante (figure 6A)
Le premier champ doit être un index et doit contenir le Dl de la création de la fiche, le deuxième champ doit également être un index et uniquement contenir un indicateur sur un caractère spécifiant la nature locale ou centrale de la fiche (lit), comme décrite ciaprès, suivi du Dl de mise à jour. L'information contenue sur chaque champ de la fiche (en dehors du premier et du second champ ou index) doit être suivie d'un caractère de séparation (Cr) et du Dl de mise à jour du champ.

A chaque BLR doit correspondre un fichier paramètre présent sur le site local contenant le Dl de la dernière mise à jour locale et le Dl de la dernière mise à jour centrale décrites plus loin.

Lors de la mise à jour d'une fiche appartenant à une BLR à l'aide de la requête 3 de type 1, le système positionne sur le mode local l'indicateur présent au début du deuxième index et introduit à sa suite le Dl en cours. Pour chaque champ modifié ou créé, le système introduit à la fin du champ un caractère de séparation (Cr) suivi du Dl en cours.

Lors de la création d'une fiche le Dl en cours est introduit dans le premier champ. Lors de l'annulation d'une fiche à l'aide de la requête 6 de type 1, le système modifie le second champ de cette fiche de la même manière que lors d'une mise à jour. Tous les autres champs, sauf le premier, ayant la fonction d'index sont remplacés par un caractère inférieur à 20H (Hexadécimal) suivi du Dl présent sur le premier champ.

Les fiches appartenant aux BCR figure 6B) doivent être paramétrées de la même manière que les fiches appartenant aux BLR, le Dl dans le deuxième index ne devant pas cette fois être précédé d'un caractère indicateur et devant être suivi du code du site local ayant émis la fiche en cours. Les BCR ne possèdent pas de fichier paramètre associé comme dans le cas des BLR.

Le ou les noms de bases à mettre à jour ainsi que l'intervalle de temps séparant une déconnexion d'une nouvelle connexion en cas de rupture de la liaison demandée par le site central et effectuée par le site local (étape 314), doivent être précisées au procédé de mise à niveau.

Comme nous l'avons vu précédemment (figure 2), le système détecte l'apparition du fichier contenant ces informations.

A ce moment le lancement d'une tâche annexe est autorisé (étape 208) et la fonction traitement local est activée sur cette tâche annexe (étape 209).

Ensuite, comme nous l'avons vu (figure 3), la fonction traitement local lit le contenu de ces informations, vérifie si une voie est disponible (étapes 302, 303, 307), et, dans ce cas, connecte cette voie entre le site local et le site central (étape 308).Toutes les opérations décrites ci-après s'effectuent entre cette nouvelle voie appartenant au site local et une voie d isponible appartenant au site central.

Plusieurs opérations de mise à jour peuvent donc être lancées et s'effectuer simultanément, le système lançant chaque fois une nouvelle tâche liée à l'exécution de cette opération et cherchant à chaque fois la présence de nouvelles voies disponibles.

L'exécution de la procédure de mise à niveau s'effectue de la manière suivante:
Si plusieurs noms de BLR ont été donnés, ces BLR à mettre à jour sont traitées les unes après les autres.

Le traitement de chaque BLR est divisé en deux parties (figures 7 et 8).

La première partie est nommée mise à jour locale (étape 717 sur le site local et 814 sur le site central). Celle-ci consiste à transférer vers la BCR toutes les mises à jour effectuées localement sur la BLR. La seconde partie est nommée mise à jour Centrale (étape 718 sur le site local et 813 sur le site central). Celle-ci consiste à transférer vers la
BLR toutes les mises à jour effectuées sur la BCR. L'exécution de la procédure de mise à niveau est terminée lorsque toutes les BLR données dans cette procédure ont été traitées.

Les opérations liées à la mise à jour locale (étape 717 sur le site local et 814 sur le site central) sont les suivantes:
Comme on peut le voir sur la figure 7, le système lit dans le fichier paramètre, correspondant à la BLR en cours de traitement, le Dl de la dernière mise à jour locale (étape 701) et émet vers le site central les composantes de la fiche dont le deuxième index est directement supérieur au Dl lu, précédé de l'indicateur positionné sur le mode local (étapes 702, 703 et 704).

Comme on peut le voir sur la figure 8, le système sur le site central reçoit les composantes de la fiche et dans l'étape 804, en cas de modification, le Dl sur le premier champ étant trouvé dans la BCR, le système compare les champs de la fiche émise avec ceux de la fiche appartenant à la BCR. Seuls les champs appartenant à la fiche émise dont le
Dl est supérieur à ceux des champs correspondants appartenant à la fiche de la BCR, sont introduits à la place de ces derniers. Ceci permet d'obtenir une information cohérente malgré les conflits d'accès, une même fiche étant modifiée au même instant sur des sites locaux différents contient ainsi après modification la somme des informations introduites.

Le second champ de la fiche appartenant à la BCR est remplacé par le Dl de l'opération en cours, suivi du code d'accès du site local.

Si tous les champs de la fiche appartenant à la BCR ont un Dl de mise à jour inférieur ou égal à celui des champs correspondant appartenant à la fiche émise, le second champ de la fiche appartenant à la BCR est remplacé par le Dl de l'opération en cours, suvi du code d'accès du site local ; dans le cas contraire, le Dl le plus récent de l'opération en cours est suivi d'un code d'accès fictif.

En cas de création de fiche, le Dl sur le premier champ n'étant pas trouvé dans la BCR, l'ensemble des éléments de la fiche émise sont introduits dans une nouvelle fiche sur la BCR, le second champ étant composé du Dl (sans l'identificateur) suivi du code d'accès du site local.

En cas d'annulation de fiche, tous les champs de la fiche émise, sauf le premier et le second, sont composés du Dl du premier champ précédé d'un caractère spécifique inférieur à 20H (Hexadécimal), ce Dl étant trouvé dans la BCR. Dans ce cas la fiche complète appartenant à la BCR est remplacée par la fiche émise, le second champ toujours composé du Dl (sans l'identificateur) suivi du code d'accès du site local.

Après l'opération de mise à jour le système basé sur le site central renvoie une réponse de validation ou d'invalidation, concernant le résultat de cette opération, vers le site local (étape 805), puis se remet en position de réception des composantes d'une nouvelle fiche (étape 802).

Le système basé sur le site local, en cas d'invalidation, introduit les références de la fiche et la nature de l'erreur dans le fichier dit fichier de réponse lié à la tâche en cours d'exécution (étapes 705 et 706).

Le système remplace enfin le Dl de la dernière mise à jour locale présent dans le-dit fichier paramètre de la BLR par le Dl du deuxième index de la fiche traitée (étape 707). Le système se positionne ensuite sur la fiche de la BLR dont le Dl sur le deuxième index est directement supérieur au Dl de la fiche traitée (étape 702) et les opérations décrites cidessus sont à nouveau exécutées, jusqu'à l'introduction, du nouveau Dl dans le dit fichier paramètre (étape 707).

Lorsque l

Ce dernier se positionne ensuite sur la fiche de la BCR dont le Dl sur le deuxième index est directement supérieur au Dl de la fiche traitée (étape 806) et les opérations décrites cidessus sont à nouveau exécutées, jusqu'à l'introduction, du nouveau Dl dans le-dit fichier paramètre sur le site local.

Lorsque la dernière fiche est traitée (aucune autre fiche ne contient un Dl plus élevé dans la BCR) (étapes 807 et 711), les opérations de la mise à jour centrale décrites ci-dessus, consistant à transférer vers la BLR toutes les mises à jour effectuées sur la BCR, sont terminées pour cette BLR. Ensuite une autre BLR peut être traitée jusqu'à la dernière
BLR spécifiée par la procédure de mise à niveau. A ce moment, la liaison entre les deux sites est libérée et la tâche en cours d'exécution est désactivée.

Lorsque le temps de fonctionnement décrit ci-dessus est supérieur à une durée gérée par le site central (étape 801), les opérations en cours sont arrêtées, la liaison entre le site local et le site central est libérée et les tâches en cours de fonctionnement sur les deux sites sont désactivées (étapes 811 et 812).

Dans ce cas, une autorisation de traitement d'une tâche annexe, pour la reprise de l'exécution de cette procédure, ne pourra être donnée, dans l'étape 208 figure 2, qu'après une durée fixée en tant que paramètre de la procédure de mise à niveau.

A l'issue de cette période l'autorisation de traitement d'une tâche annexe, pour la reprise de l'exécution de cette procédure, pourra être donnée et l'exécution de la procédure de mise à niveau, telle que décrite précédemment, pourra être à nouveau lancée à partir de la dernière base traitée.

Claims (2)

REVENDICATIONS

1. procédé de comunication permettant de relier en une liaison interactive réelle ou virtuelle un nombre limité ou non limité de sites locaux à un site central, de sites centraux à un site local, chaque site pouvant fonctionner simultanément en tant que site local et site central d'un autre réseau de sites locaux et caractérisé en ce qu'il comprend les étapes suivantes

- transferer des données entre deux systèmes de communication implantés sur un site central et un site local au moyen d'un noyau de communication (3);

- effectuer la liaison entre un programme d'application (9) fonctionnant sur un site local et le noyau de communication (3) implanté sur ce site local au moyen d'une fonction traitement local (2);

- exécuter les procédures sur le site local commandées par le programme d'application

- sortir les informations sur un fichier spécifique présent sur le site local;

- interpréter et exécuter, sur le site central, les procédures commandées par le programme d'application (9) présent sur le site local, au moyen d'une fonction traitement central (4);

- dialoguer entre le programme d'application (9) fonctionnant sur

un site local et le site central au moyen de requêtes (1,2,3);

- procéder à la mise à niveau de bases de données réparties pour laquelle sont adaptées des bases de données de type BLR et BCR.

2. Procédé de communication conforme à la revendication 1 caractérisé en ce que la mise à niveau des bases de données réparties consiste en:

- une mise à jour locale (étapes 717 et 814) qui permet de transférer vers une BCR toutes les mises à jour effectuées localement sur une BLR;

- une mise à jour Centrale (étapes 718 et 813) qui permet de transférer vers une BLR toutes les mises à jour effectuées sur une BCR.