Brevet FR2760307A1 — publié le 19980904

La présente invention concerne de façon générale le domaine de la gestion et de la commande téléphoniques et, en particulier, elle concerne une architecture et un procédé d'accès, de configuration et de modification de tables et de bases de données de configuration dans un commutateur téléphonique, à partir d'une station locale ou distante de travail ou de gestion. En outre, l'invention concerne une architecture et un procédé destinés à permettre à des applications locales et en réseau d'avoir accès à la base de données du commutateur téléphonique. L'architecture actuellement préférée pour l'environne- ment de traitement est appelée "traitement client-serveur". Dans ce modèle, l'utilisateur bénéficie de l'utilisation d'un terminal intelligent et est connecté à diverses appli- cations et divers services par un réseau local (LAN). Le réseau local permet l'accès à des ressources et périphé- riques coûteux. Le modèle client-serveur s'étend au partage des fichiers, des bases de données et des applications ainsi que des ressources matérielles. A cet effet, chaque ordinateur de bureau a accès à un serveur en fonction de ses besoins. Lorsque l'utilisateur remet à jour un enregis- trement, c'est habituellement la base de données du serveur qui est remise à jour, si bien que toute personne d'un groupe de travail partage les informations remises à jour. La réalisation des applications client-serveur permet aux utilisateurs d'établir leurs écrans en fonction de leurs préférences et besoins particuliers, tout en ayant les avantages des informations partagées. Le modèle client-serveur est particulièrement puissant dans son aptitude à mélanger et adapter des machines provenant de vendeurs différents. L'utilisateur peut sélec- tionner le serveur le mieux adapté à une tâche particulière, mais il choisit des machines clientes et des appareils de natures différentes parmi différents vendeurs d'après l'interface graphique préférée par l'utilisateur ou d'autres paramètres personnels, tels qu'une utilisation multimédia, etc. De nouveaux serveurs qui ont du succès sont les serveurs de télécopie, les serveurs de courrier électro- nique, les serveurs de messagerie vocale, etc. Les commutateurs téléphoniques ne sont habituellement pas réalisés pour s'adapter au modèle client-serveur. Le matériel utilisé aussi bien sur la station de travail et sur le serveur est commandé par une couche logi- cielle appelée "système d'exploitation". Le système d'exploitation isole l'application qui n'a pas à connaître les détails du matériel, et constitue une infrastructure fiable à l'aide de laquelle toutes les applications sont exécutées. L'un des éléments primordiaux de la réalisation et du développement modernes d'applications est le principe de l'interface du programmeur de l'application (API). Cette interface API constitue une interface déterminée entre divers dispositifs ou couches logicielles dans le modèle de calcul, si bien que les développeurs de logiciels peuvent se focaliser sur leur application. Pour qu'ils puissent ainsi se focaliser, ils sont munis des commandes nécessaires à l'appareil ou à d'autres applications, sans avoir à connaître leur fonctionnement. Les interfaces API sont appliquées à la fois aux ordinateurs de bureau et aux serveurs. Les interfaces API sont aussi un principe impor- tant pour la programmation des serveurs téléphoniques. La plupart des autocommutateurs supportent actuellement une forme quelconque d'interface de programmation d'application logicielle (API) Dans les entreprises moyennes et importantes, les appels téléphoniques internes sont gérés par un commutateur téléphonique privé ou autocommutateur. Bien que l'auto- commutateur soit essentiellement un dispositif électronique numérique, une évolution naturelle vers l'intégration de la téléphonie et de l'ordinateur (CTI) a conduit à imposer la connexion des autocommutateurs aux réseaux locaux afin qu'ils fonctionnent comme appareil accessible par réseau. Le modèle utilisé pour la description des architectures des réseaux téléphoniques est très simple. Les utilisateurs ayant un dispositif terminal (c'est-à-dire un téléphone) sont connectés à un commutateur téléphonique qui offre un certain nombre de services. Le téléphone est le dispositif terminal certainement le plus reconnaissable. Il peut être analogique ou numé- rique, il peut comporter des boutons, des dispositifs d'affichage et peut aussi être sans fil. Les dispositifs terminaux comprennent aussi des télécopieurs, des modems, des "vidéophones", des systèmes d'alarme, des appareillages de réseaux locaux et des cartes multimédia pour ordinateurs personnels. Un dispositif terminal est un élément matériel quelconque qui peut être relié au réseau et peut avoir accès à l'autocommutateur. De nouveaux terminaux peuvent être ajoutés au réseau à un moment quelconque et ont accès immédiatement à toute la gamme des services avec lesquels ils sont compatibles. De nouveaux services sont habituel- lement introduits avec une réalisation de terminaux qui facilite l'utilisation des appareils. Le matériel de l'autocommutateur est aussi commandé par une couche logicielle de système d'exploitation. L'environ- nement des télécommunications a des besoins particuliers nécessitant des systèmes d'exploitation multitâches, en temps réel et à tolérance de panne. Même les téléphones commerciaux les plus modernes ne constituent qu'un élément "passif", assurant simplement un relais vers un dispositif hôte en fonction du bouton poussé et commandant des dispositifs d'affichage suivant les indications reçues. Le coeur d'un système moderne de commutation est un ensemble d'applications logicielles appelées collectivement "traitement des appels". Ce logiciel donne toutes les fonctionnalités apparaissant à l'utilisateur, depuis le lancement fondamental d'un appel jusqu'à la transmission de l'identité de la personne appelante. Le logiciel donne aussi à l'utilisateur des caractéristiques telles que le lancement des appels, des services élaborés de réseau tels que le routage du dernier appel, et une gestion spécialisée des appels telle la gestion des distributeurs automatiques d'appels destinés aux centres d'appels. Le traitement des appels est l'élément primordial pour la réalisation de réseaux de communications souples, configurables et faciles à entretenir. Il est donc nécessaire qu'un logiciel soit exécuté à l'intérieur du commutateur ou de l'autocommutateur afin qu'il donne à une application externe une certaine commande sur les opérations exécutées. Les systèmes à autocommu- tateurs modernes donnent plus de deux cents propriétés destinées à améliorer la gestion des appels, bien que la majorité des utilisateurs n'utilise jamais plus de quatre de ces propriétés. Pour que ces propriétés soient offertes, il existe des commandes qui assurent l'activation, la suspen- sion ou l'arrêt de la mise en oeuvre de propriétés dans le commutateur. Les propriétés comprennent notamment une réponse vocale intégrée (IVR), la gestion automatique du courrier vocal, ainsi que d'autres propriétés. Les modifications et changements du profil d'un commu- tateur téléphonique du fait des déplacements des personnes dans une organisation restent difficiles à gérer. L'adres- sage est complexe, chaque élément du réseau devant être déconnecté et reprogrammé afin que sa catégorie de services et sa catégorie de restrictions soient modifiées. L'un des buts des télécommunications modernes est la réalisation d'un système à autocommutateur qui ne nécessite pas un "arrêt" chaque mois pour l'exécution de ces changements. Dans la plupart des organisations ayant des sites complexes ou des environnements sur une zone étendue, l'architecture habituellement utilisée met en oeuvre plu- sieurs composants à autocommutateur répartis dans le site ou campus. Ces composants à autocommutateur peuvent être munis de cartes d'adaptateur de réseau et peuvent être connectés mutuellement par une infrastructure sous forme d'une ossature de réseau local. L'un des problèmes existant dans les sites importants contenant plusieurs autocommutateurs est la gestion des différents composants. De nombreux autocommutateurs ont des langages et systèmes d'exploitation qui sont personnalisés. De nombreux commutateurs téléphoniques ne sont pas connectés au réseau de l'ordinateur, même ceux qui ne sont pas faciles à gérer. Ils ne sont pas destinés à s'adapter au modèle client-serveur. Il faut qu'un administrateur connaisse le commutateur et l'interface de gestion de commutateur pour exécuter la maintenance des propriétés utilisées sur le commutateur. En outre, il est courant que des autocom- mutateurs aient une configuration permettant un fonction- nement interne à l'aide de tables contenant des informations relatives aux propriétés et opérations particulières du commutateur (c'est-à-dire des numéros de postes, des pro- priétés des postes particuliers, le routage). Un administrateur doit connaître l'établissement de ces caractéristiques non seulement pour différentes versions du même commutateur, mais aussi pour des types différents de commutateurs. Les personnes qui se déplacent et les modifications des propriétés d'un commutateur à un autre nécessitent une nouvelle programmation et, dans de nombreux cas, une visite physique du commutateur ou le rejet d'infor- mations relatives à ce commutateur. L'exécution des sauvegardes pour le commutateur présente aussi des difficultés. Dans un premier aspect, l'invention concerne une architecture de gestion et de commande d'un ou plusieurs commutateurs téléphoniques, et elle autorise et exécute les fonctions nécessaires au déplacement des personnes et aux changements des informations conservées dans les commu- tateurs téléphoniques. Selon un aspect supplémentaire de l'invention, celle-ci concerne une architecture permettant le support des applications ultérieures et des utilisations d'informations dans un commutateur téléphonique. L'invention concerne aussi l'obtention d'un accès générique à des bases de données de commutateur téléphonique et à des vues d'une manière compatible avec des versions précédentes des commutateurs téléphoniques. L'invention concerne aussi l'obtention d'un accès à un commutateur téléphonique d'une manière indépendante du protocole. Dans un autre aspect, l'accès est donné de manière générique pour permettre des opérations de recherche, de lecture, d'écriture, d'addition, de suppression et de gestion d'une première opération, d'une opération suivante, d'une opération précédente et d'une dernière opération. Dans un autre aspect de l'invention, l'accès à un commutateur téléphonique est réalisé d'une manière qui permet une gestion des transactions. Dans un autre aspect, l'invention concerne un mécanisme destiné à un commutateur téléphonique et permettant une communication par retour avec d'autres appareils du réseau, y compris d'autres commutateurs téléphoniques. Dans un autre aspect de l'invention, la vérification de la programmation de la base de données de commutateur est réalisée et des règles de mise en oeuvre de base de données de commutation sont suivies. En conséquence, dans un mode de réalisation préféré de l'invention, une interface de programmation d'application (API) est réalisée et est indépendante des différentes versions des systèmes d'exploitation et des commutateurs, ces versions pouvant être utilisées dans le commutateur pour assurer la communication avec une station de gestion de serveur et de commande de réseau. La station de gestion de serveur et de commande de réseau peut avoir accès aux informations d'une base de données personnalisée et peut supprimer ces informations, dans le commutateur, et elle permet une installation de ces informations dans une autre base de données. Cette propriété simplifie l'addition de nouvelles propriétés dans le commutateur. Dans un premier aspect, l'invention concerne un configurateur de commutateur téléphonique destiné à gérer et commander au moins un commutateur téléphonique à partir d'un dispositif d'un réseau, le commutateur téléphonique contenant un support de mémorisation qui peut être lu et écrit pour la mémorisation d'une configuration du commu- tateur téléphonique et qui peut être accessible à partir d'un réseau d'ordinateur par l'intermédiaire d'un premier gestionnaire de protocole de transport de données, le dispositif du réseau communiquant avec le réseau par un second gestionnaire de protocole de transport de données, le configurateur comprenant: (a) un générateur de commandes placé dans le dispositif du réseau et qui transmet les commandes à exécuter par le commutateur téléphonique, (b) un premier serveur d'accès incorporé au dispositif du réseau et destiné à gérer une connexion au commutateur téléphonique, (c) une première interface placée entre le générateur de commandes et le premier serveur d'accès et destinée à transformer les commandes entre le générateur de commandes et le premier serveur d'accès, (d) une seconde interface placée entre le premier serveur d'accès et le gestionnaire de protocole de transport de données pour la transformation des commandes entre le premier serveur d'accès et le gestionnaire de protocole de transport de données, (e) un second serveur d'accès incorporé au commutateur téléphonique et destiné à gérer une connexion au dispositif du réseau, (f) une troisième interface placée entre le second serveur d'accès et le second gestionnaire de protocole de transport de données pour la transformation des commandes entre le second gestionnaire de transport de données et le second serveur d'accès, (g) un organe d'exécution de commandes incorporé au commutateur téléphonique et qui exécute les commandes pour changer la configuration du commutateur téléphonique, et (h) une quatrième interface placée entre le second serveur d'accès et l'organe d'exécution de commandes afin qu'elle transforme les commandes entre le second serveur d'accès et l'organe d'exécution des commandes. Dans un autre aspect, l'invention concerne un procédé de gestion et de commande d'un commutateur téléphonique à partir d'un dispositif de réseau, le commutateur télépho- nique communiquant avec un réseau d'ordinateur par un protocole de transport de données, le dispositif de réseau communiquant avec le réseau par le protocole de transport de données, comprenant les étapes suivantes: a) le lancement d'une commande de connexion d'un commutateur téléphonique choisi à partir du dispositif de réseau, b) la transformation de la commande en un format compris par un premier serveur d'accès, c) la transmission de la commande au premier serveur d'accès, d) l'ouverture d'un canal de communications avec le commutateur téléphonique choisi, e) le conditionnement de la commande afin qu'elle soit transportée à l'aide du protocole de transport de données, f) la transmission de la commande au mécanisme à protocole de transport de données, g) le transport de la commande par le réseau au commutateur téléphonique spécifié à l'aide du protocole de transport de données, h) le déconditionnement de la commande reçue par le commutateur téléphonique à l'aide du mécanisme à protocole de transport de données, i) la transmission de la commande à un second serveur d'accès, j) la transformation de la commande en une forme qui peut être exécutée par le commutateur téléphonique, et k) l'exécution de la commande sur le commutateur téléphonique pour le changement de la configuration du commutateur téléphonique. D'autres caractéristiques et avantages de l'invention seront mieux compris à la lecture de la description qui va suivre d'exemples de réalisation, faite en référence aux dessins annexés sur lesquels: la figure 1 est un diagramme synoptique représentant un environnement de configuration de réseau utilisé selon la présente invention; les figures 2A et 2B constituent ensemble un diagramme synoptique de l'architecture selon l'invention mise en oeuvre avec des stations de gestion téléphonique et des architectures de commutateurs téléphoniques existantes; les figures 3A à 3D sont un schéma représentant la circulation des messages entre un utilisateur et un commutateur téléphonique selon la présente invention; la figure 4 est un diagramme synoptique détaillé d'un gestionnaire dans un mode de réalisation préféré, installé dans une station de gestion téléphonique; et la figure 5 est un diagramme synoptique détaillé d'un élément de réseau dans un mode de réalisation préféré, installé dans un commutateur téléphonique. On se réfère à la figure 1 qui représente une vue générale illustrant l'utilisation de la présente invention dans une configuration de réseau. L'invention est mise en oeuvre afin qu'elle assure des connexions qui peuvent être effectuées directement ou indirectement par l'intermédiaire d'un réseau "Ethernet". L'utilisation d'autres protocoles de réseau (par exemple à jetons, FDDI, etc.) entre aussi dans le cadre de l'invention. Des connexions en série peuvent aussi être utilisées, bien que des considérations relatives aux performances doivent être envisagées. Dans le mode de réalisation préféré, la station 10 de gestion obtient l'accès au commutateur téléphonique 20 par un réseau local 30. Dans le mode de réalisation préféré, le réseau local 30 est un réseau "Ethernet" mettant en oeuvre le protocole TCP/IP, mais l'invention peut aussi mettre en oeuvre d'autres topologies et protocoles de réseau. Dans un autre mode de réalisation de l'invention, la station 10 de gestion peut former l'interface avec un ou plusieurs commutateurs téléphoniques 42, disposés dans des réseaux distants 44 par l'intermédiaire de réseaux locaux interconnectés et de réseaux de grande étendue 46, de manière connue dans la technique. Dans un autre mode de réalisation, la station 10 de gestion peut former l'interface avec le commutateur téléphonique 52 par utilisation de routeurs 48 connectés à un réseau privé ou public 50. On se réfère maintenant à la figure 2 qui représente une vue générale de l'architecture selon l'invention. Alors que les figures 2 à 5 concernent le mode de réalisation préféré de l'invention dans le contexte du fonctionnement d'un réseau local, il est évident pour l'homme du métier de modifier l'invention et de la mettre en oeuvre avec d'autres procédés et structures d'interconnexion de réseaux, y compris ceux qui sont décrits en référence à la figure 1. L'invention est mise en oeuvre facilement par combinaison de composants logiciels en couches. Les composants coopèrent avec le logiciel existant dans la station de gestion 10 et le commutateur téléphonique 20 pour donner accès à des opérations spécifiques du commutateur téléphonique 20. Dans le mode de réalisation préféré et afin que cet accès soit assuré, une couche d'accès à la base de données est créée à la fois dans la station de gestion 10 et le commutateur téléphonique 20. La couche d'accès à la base de données est facilitée par un serveur 116 d'accès à la base de données DP résidant dans la station de gestion 10 et un serveur 118 de base de données de commutateur résidant dans le commutateur téléphonique 20. En conséquence, on décrit dans la suite six aspects principaux pour faciliter la compréhension de l'invention: (1) l'interface entre l'application et la couche d'accès aux données dans la station de gestion, (2) la couche d'accès à la base de données dans la station de gestion, (3) l'interface entre la couche d'accès à la base de données et la couche de transport de données dans la station de gestion, (4) l'interface entre la couche de transport de données et la couche d'accès à la base de données dans le commutateur téléphonique, (5) la couche d'accès à la base de données dans le commutateur téléphonique, et (6) l'interface entre la couche d'accès à la base de données et la couche d'application dans le commutateur téléphonique. Dans la station 10 de gestion, la couche d'application est constituée d'une application 114 qui doit avoir accès aux informations conservées dans le commutateur téléphonique 20. L'application 114 crée des commandes destinées au commutateur téléphonique 20. Dans le mode de réalisation préféré de l'invention, la station de gestion 10 se connecte au commutateur téléphonique 20 par le réseau local 30. La station 10 de gestion, dans un mode de réalisation préféré, est une station à base du système d'exploitation "Unix" ou "Windows", mais des stations de travail d'ordinateur mettant en oeuvre d'autres systèmes d'exploitation peuvent être utilisées. Dans le mode de réalisation préféré, la station de gestion 10 est connectée à la région 30 d'un réseau local par une carte "Ethernet" 110. De manière analogue, le commu- tateur téléphonique 20 est connecté au réseau local 30 par la carte "Ethernet" 112. Bien qu'on décrive l'application 114 comme application d'une base de données, l'utilisation de l'invention n'est pas limitée à l'application à une base de données. Toute application qui peut être exécutée sur une station de gestion 10 ou une station de travail d'ordinateur qui nécessite l'accès aux informations du commutateur téléphonique 20 peut utiliser de telles opérations par mise en oeuvre des principes de la présente invention. Dans un autre mode de réalisation, l'invention peut être exécutée afin qu'une application exécutée sur un appareil quelconque connecté au réseau ait accès aux informations conservées dans le commutateur téléphonique 20. Dans un tel mode de réalisation, l'application et l'architecture selon l'invention peuvent résider totalement dans le matériel ou être exécutées par le matériel. La base de données 120 conserve des informations de divers types, modèles et propriétés de commutateur télépho- nique 20 accessibles par un réseau 30. Divers réglages peuvent être téléchargés dans la base de données 120 exécutée sur la station de gestion 10 à l'aide de l'application 114. Dans la station de gestion, les réglages peuvent être manipulés, modifiés ou changés et renvoyés au commutateur téléphonique 20 pour sa remise à jour. De cette manière, l'administrateur peut être isolé du langage complexe et des paramètres nécessaires à la mise à jour des réglages dans le commutateur téléphonique. En outre, les déplacements de personnes et changements de configuration peuvent être facilement exécutés par téléchargement de la caractéristique à partir du commutateur téléphonique à partir duquel est réalisé le déplacement, avec rechargement de la même propriété dans le commutateur téléphonique vers lequel a lieu le déplacement. En outre, la transformation des propriétés, lorsque les paramètres d'une propriété peuvent varier d'un commutateur à un autre, peut être réalisée automatiquement, sans que l'administrateur doive connaître les différents paramètres correspondant à une propriété d'un commutateur à un autre. Une liste de propriétés supportées peut aussi être conservée dans la base de données 120 et transformée pour l'utilisateur afin qu'une interface universelle d'utilisateur soit présentée. Dans le mode de réalisation préféré, l'application 114 de la base de données est écrite en langage de programmation "C", et la base de données 120 est gérée par le système de gestion de base de données "Oracle" (DBMS) L'invention n'est pas limitée à un tel système DBMS "Oracle", car elle peut être adaptée à tout système DBMS connu dans la technique. L'application 114 de base de données communique avec le serveur 116 d'accès à la base de données par une interface 115. Celle-ci est décrite plus en détail en référence à la figure 4. Le serveur 116 d'accès à la base de données incorporé à la couche d'accès à la base de données communique avec un tube 122 de communications de la couche de transport de données par l'interface 117 afin que les communications avec le commutateur 20 soient plus faciles. L'interface 117 donne à la couche d'accès à la base de données un mécanisme et un protocole de gestion et de transport des commandes et des données vers le commutateur 20. L'interface 117 est décrite plus en détail dans la suite en référence à la figure 4. Le tube 122 de communications par l'interface 119 avec la carte "Ethernet" 110 pour le transfert des informations au commutateur 20. Dans le mode de réalisation préféré, le tube 122 de communications et l'interface 119 sont des processus existants qui gèrent les connexions avec les appareils individuels du réseau. On considère à nouveau le commutateur téléphonique 20 de la figure 2; le fonctionnement du commutateur télépho- nique 20 est obtenu, commandé et exécuté en fonction des réglages conservés dans la base de données 124. Le commutateur téléphonique 20 est en général un appareil électronique ayant un dispositif de mémorisation, un système d'exploitation et un langage de commande. Les informations relatives à la configuration du commutateur 20 sont conservées dans des tables de la base de données, chaque ligne d'une table étant accessible sous forme d'un nuplet, appelé "ligne" par raison de simplicité dans la suite, d'une manière directe ou indirecte par l'intermédiaire d'une vue. Une ligne est une vue composite d'un enregistrement d'une base de données ou de parties de plusieurs enregistrements et représente la plus petite granularité des données dans une base de données. Les lignes sont constituées d'un ou plusieurs champs qui peuvent être accessibles par des noms de champ. Les informations (ou les lignes) de la table peuvent être atteintes par l'application 126 d'accès à la base de données du commutateur et les commandes transmises au commutateur 20 sont traitées et exécutées par l'application 126 de la base de données du commutateur. Dans l'exemple qui suit, la structure de la base de données 124 correspond à celle de l'autocommutateur "Mitel" "SX-2000" à titre d'exemple. Il est cependant évident pour l'homme du métier que l'invention peut être modifiée afin qu'elle travaille avec des tables à d'autres formats, par exemple suivant le système décrit dans les brevets des Etats-Unis d'Amérique n 4 615 028 délivré le 30 septembre 1986 et 4 616 360 délivré le 7 octobre 1986. L'application 126 d'accès à la base de données du commutateur est un programme qui réglemente l'accès à la base de données 124. L'application 126 et la base de données 124 se trouvent dans la couche d'application du commutateur 20. L'application 126 de la couche d'application communique avec un serveur 118 de base de données de commutateur par l'interface 123. L'interface 123 est décrite plus en détail en référence à la figure 5. Le serveur 118 de la couche d'accès à la base de données communique avec le tube 128 de communications du commutateur 20 par l'interface 121. L'interface 121 donne à la couche d'accès à la base de données incorporée au commutateur 20 un mécanisme et un protocole de transport des commandes et des données vers la station de gestion 10. L'interface 121 est décrite plus en détail en référence à la figure 5. Le tube 128 de communications communique avec la carte "Ethernet" 112 et transmet les informations au réseau local 30 afin qu'elles soient reçues par la station de gestion 10. Le tube 128 de communications est une biblio- thèque existante de fonctions qui gère la transformation entre les représentations des données utilisées pour le transport de données et celles qui sont nécessaires à la couche d'accès à la base de données. Le tube 128 de communications, dans le mode de réalisation préféré de l'invention, est sous forme d'un mécanisme existant de transport, par exemple le mécanisme "Opsman" MNMS qui est fourni par "Mitel". Cependant, d'autres mécanismes de trans- port peuvent être utilisés dans le cadre de l'invention. L'une des propriétés obtenues selon l'invention est que les appareils du réseau peuvent communiquer avec le commutateur téléphonique 20 si bien que celui-ci peut être intégré aux applications du réseau. Les utilisateurs peuvent commander leurs propres réglages téléphonique à partir de l'ordinateur de bureau. En outre, les propriétés du commutateur télépho- nique 20 peuvent être offertes pour tirer avantage du commu- tateur téléphonique constituant un dispositif du réseau qui permet la communication des applications 114 par l'intermé- diaire de l'invention avec le commutateur téléphonique 20 et son intégration dans l'environnement de travail. Circulation des messages On considère maintenant la figure 3 qui représente un exemple de mise en oeuvre de la présente invention. La figure 3 représente la circulation des informations rela- tives à une transaction de lecture d'une ligne et d'écriture d'une ligne par une application 114. L'application 114 est présentée à un utilisateur sur un écran d'affichage vidéo, du type couramment utilisé sur une station de travail d'ordinateur. Un utilisateur communique avec l'application exécutée dans la station de gestion 10 par l'interface 131 d'utilisateur. L'application 114 communique avec le serveur 116 d'accès à la base de données par l'interface 115. Ce serveur 116 communique avec le mécanisme 130 de transport par l'interface 117. Le mécanisme de transport 130 communique avec le serveur 118 de la base de données du commutateur par l'interface 121. Le serveur 118 communique avec l'application 126 d'accès à la base de données du commutateur par l'interface 123. A partir du coin supérieur gauche de la figure 3, au pas 132a et à l'aide d'une interface 131 d'utilisateur, un dispositif d'entrée-sortie tel qu'un écran ou un clavier ouvre ou lance l'application 114 qui provoque l'exécution d'un profil d'utilisateur. Au pas 132b, l'application 114 lance une session dans le cadre de ce document et communique le message par l'interface 115 au serveur 116. Au pas 132c, le serveur 116 établit la connexion et transmet le message de début de session par l'interface 117 au mécanisme 130 de transport. Au pas 132d, le mécanisme 130 transporte le message vers le serveur 118 de la base de données du commutateur 20 par l'interface 121. Au pas 133a, après réception du message au pas 132d, le serveur 118 affecte une identité ID de session et transmet celle-ci par l'interface 121 au mécanisme 130 de transport. Au pas 133b, le mécanisme 130 transmet le message par l'interface 117 au serveur 116. Au pas 133c, le serveur 116 enregistre l'identité de la session et transmet le message à l'application 114 par l'interface 115. Après réception du message, l'application 114 soumet la demande de lecture d'une ligne au pas 134a. Cette demande est renvoyée par l'interface 115 au serveur 116. Au pas 134b, le serveur 116 prépare la demande et la transmet par l'interface 117 au mécanisme 130 de transport. Au pas 134c, le mécanisme 130 transfère le message au serveur 118 de la base de données du commutateur 20 par l'interface 121. Au pas 134d, le serveur 118 vérifie l'identité de la session et reconditionne la demande, puis transmet le message par l'interface 123 à l'application 126. Au pas 135, après réception de la demande, l'application 126 effectue la lecture et, au pas 136a, elle renvoie une ligne par l'interface 123 vers la base de données 118 du commutateur. Au pas 136b, le serveur 118 reconditionne la demande et la transmet au mécanisme 130 de transport par l'interface 121. Au pas 136c, le mécanisme transmet la réponse par l'interface 117 au serveur 116. Au pas 136d, le serveur 116 transforme les données de texte au format convenable et transmet les données à l'application 114 par l'interface 115. Au pas 136e, l'application 114 présente l'information à l'utilisateur par l'interface 131. Au pas 137, l'utilisateur édite les informations. Lorsque l'édition est terminée, l'utilisateur, au pas 138a, transmet la commande d'engagement par l'interface 131 d'utilisateur à l'application 114. Au pas 138b, l'application 114 transmet un message de transaction de début et transmet le message par l'interface 115 au serveur 116 d'accès à la base de données. Au pas 138c, le serveur 116 transmet le message de transaction de début par l'interface 117 au mécanisme 130. Au pas 138d, le mécanisme 130 transmet le message par l'interface 121 au serveur 118. Au pas 138e, le serveur 118 reconditionne ce message et le transmet par l'interface 123 à l'application 126. Au pas 139, l'application 126 lance la transaction. Lorsque la transaction est prête à être exécutée au pas 140a, l'application 126 renvoie une confirmation par l'interface 123 au serveur 118. Au pas b, le serveur 118 reconditionne la confirmation et la transmet par l'interface 121 au mécanisme 130. Au pas 140c, le mécanisme 130 transmet la confirmation par l'interface 117 au serveur 116. Au pas 140d, le serveur 116 transmet le message de confirmation par l'interface 115 à l'application 114. Au pas 141a, après réception de la confirmation, l'application 114 transmet la commande d'écriture de la ligne par l'interface 115 au serveur 116 d'accès à la base de données. Au pas 141b, ce serveur 116 reconditionne la demande et la transmet par l'interface 117 au mécanisme 130 de transport. Au pas 141c, ce mécanisme 130 transmet la demande par l'interface 121 au serveur 118. Au pas 141d, le serveur 118 vérifie l'identité de la session et recon- ditionne la demande "d'écriture" destinée à être transmise par l'interface 123 à l'application 126. Au pas 142, l'application 126 exécute la commande d'écriture. Après l'exécution satisfaisante de l'écriture, au pas 143a, l'application 126 renvoie la confirmation d'une écriture satisfaisante par l'interface 123 au serveur 118. Au pas 143b, le serveur 118 reconditionne la confirmation et la transmet par l'interface 121 au mécanisme 130. Au pas 143c, le mécanisme 130 transmet la demande par l'interface 117 au serveur 116. Au pas 143d, le serveur 116 transmet la confirmation par l'interface 115 à l'application 114. Au pas 144a, après réception de la confirmation, l'application 114 renvoie la commande de fin de transaction par l'interface au serveur 116. Au pas 144b, le serveur 116 reconditionne la demande et la transmet par l'interface 117 au mécanisme 130. Au pas 144c, le mécanisme 130 transmet la demande par l'interface 121 au serveur 118. Au pas 144d, le serveur 118 reconditionne la demande et la transmet par l'interface 123 à l'application 126. Au pas 145, après réception de la demande, l'application 126 soumet les changements au dispositif d'entraînement de disque dur et termine la session. Au pas 146a, après la conclusion satisfaisante de la session, l'application 126 renvoie une confirmation par l'interface 123 au serveur 118. Au pas 146b, le serveur 118 reconditionne la confirmation de fin de session et la transmet par l'interface 121 au mécanisme 130. Au pas 146c, le mécanisme 130 transmet la confirmation par l'interface 117 au serveur 116. Au pas 146d, le serveur 116 transmet la confirmation par l'interface 115 à l'application 114. Au pas 146e, l'application 114 informe l'utilisateur du succès de la transaction par l'interface 131. Au pas 147a, l'utilisateur, lorsqu'il est informé du succès, ferme l'application qui a provoqué le renvoi du message par l'interface 131 à l'application 114. Au pas 147b, l'application 114 transmet le message de fin de session par l'interface 115 au serveur 116. Au pas 147c, le serveur 116 transmet le message de fin de session par l'interface 117 au mécanisme 130. Au pas 147d, le mécanisme 130 transmet le message de fin de session par l'interface 121 vers le serveur 118. Au pas 148a, après du réception du message de fin de session, le serveur 118 désaffecte l'identité ID de session et transmet la confirmation par l'interface 121 au mécanisme 130. Au pas 148b, le mécanisme 130 transmet la confirmation par l'interface 117 au serveur 116. Au pas 148c, le serveur 116 transmet le message de connexion de fermeture par l'interface 115 à l'application 114. Au pas 148d, après réception du message de confirmation de la fermeture de la connexion, l'application 114 se termine. 1) INTERFACE ENTRE LES COUCHES D'APPLICATION ET D'ACCES A LA BASE DE DONNEES DANS LA STATION DE GESTION On se réfère à la figure 4; pour la mise en oeuvre de l'invention, une application 114 établit une session d'accès à la base de données avec le commutateur téléphonique 20. Dans la session, l'application 114 peut rechercher, lire et écrire les lignes de la base de données 124 du commutateur. Plusieurs commutateurs téléphoniques peuvent être atteints simultanément par l'application 114 par des sessions indépendantes d'accès à la base de données. L'invention permet le support d'un ensemble d'opérations qui donne à l'application 114 accès par l'application d'accès à la base de données du commutateur à la base 124 de données du commutateur. Un support supplé- mentaire est décrit pour la récupération des défaillances et pour l'obtention de la compatibilité en sens inverse. Dans la description qui suit, on utilise de façon interchangeable le mot "commutateur" et l'expression "élément du réseau". La structure de l'interface entre la couche d'application et la couche d'accès à la base de données dans la station de gestion est donnée par les fonctions décrites (appelées fonctions "API"). Toutes les fonctions précédentes, sauf les fonctions de gestion de ligne, du côté de la station de gestion, ont une fonction miroir ou symétrique du côté du commutateur téléphonique 20. Lorsque l'application 114 exécute l'une des fonctions précitées, la fonction est préparée et transportée vers le commutateur téléphonique dans lequel elle est reçue, déconditionnée et transmise à un format compris par l'application d'accès à la base de données du commutateur pour être exécutée. De cette manière, l'utilisateur qui exécute l'application 114 sur la station de gestion 10 est isolé des éléments particuliers du commutateur, car l'application 114 peut effectuer toutes les transformations de format des structures de données s'appliquant à un type, version ou modèle particulier du commutateur. Chacune de ces fonctions est appelée par la couche d'application et est transmise à la couche d'accès à la base de données pour un traitement supplémentaire. Les résultats sont renvoyés de la couche d'accès à la base de données par l'intermédiaire de la fonction appelante à la couche d'application. On peut se référer au chapitre "serveur d'accès de base de données incorporé à la station de gestion" pour des informations plus importantes relatives au type de données. Description détaillée des fonctions (a) Identification d'erreur. Dans le cas o un indicateur de succès n'est pas renvoyé, un code d'erreur est renvoyé et est éventuellement transmis comme variable à l'application 114, indiquant qu'une erreur a été rencontrée. L'application 114 peut éventuellement se référer à une table de consultation pour déterminer le texte du code d'erreur et renvoyer le texte de l'erreur à l'utilisateur. (b) Enregistrement de l'application. L'opération nécessite l'enregistrement de l'application 114 dans le serveur 116 d'accès à la base de données avant l'exécution des opérations. Ce groupe de fonctions est exécuté dans la station de gestion 10. L'enregistrement est un élément important dans la communication entre l'application 114 et le serveur 116 d'accès à la base de données. L'application 114 est réalisée afin qu'elle comprenne certaines versions et niveaux de révision du commutateur téléphonique 20. Lorsque l'enregistrement se produit, l'application 114 transmet au serveur 116 les informations de version et de niveau de révision que l'application est destinée à gérer. Dans le cas o l'application cherche à communiquer avec un commutateur 20 d'une version de numéro plus petit que celle peut comprendre l'application, le serveur d'accès à la base de données transforme les données de la version comprise par l'application en version comprise par le commutateur 20. Ce mécanisme peut aussi être utilisé afin qu'il travaille dans le sens opposé. Lorsqu'une application communique avec un commutateur téléphonique de numéro de version supérieur à celui de l'application, le serveur 116 peut effectuer la transformation nécessaire des données pour la communication avec le commutateur 20. Lorsqu'une transformation des données est nécessaire, le serveur 116 ajoute les données, les transforme ou les omet le cas échéant pour faciliter les communications avec le commutateur 20. L'application 114 doit se désenregistrer pour libérer l'utilisation des ressources du système. Les opérations d'enregistrement sont les suivantes: (i) enregistrement (ii) désenregistrement Une application 114 ne doit être enregistrée qu'une fois. Les enregistrements ultérieurs donnent comme résultat un succès et utilisent les canaux de communications établis auparavant pour le serveur 116. (i) Enregistrement. Pour utiliser le serveur 116, une application doit d'abord s'enregistrer par appel de la fonction d'enregistrement. Une application 114 est enregistrée par appel de la fonction d'enregistrement et indication du nom de l'application ainsi que de la version de la base de données du commutateur qui peut être comprise, sous forme de variables. La fonction d'enregistrement établit une connexion avec le serveur 116 qui gère toutes les demandes ultérieures d'accès à la base de données. La fonction renvoie une valeur indiquant le succès ou la défaillance de l'opération. Dans le cas o le lancement de la session présente une défaillance, l'accès à la base de données n'est pas disponible. Lorsqu'une session d'accès à la base de données existe déjà, un indicateur de succès est renvoyé. (ii) Désenregistrement. Lorsqu'une application 114 veut terminer l'accès, la fonction de désenregistrement est appe- lée. La communication avec le serveur 116 est terminée. La fonction renvoie une valeur indiquant le succès ou la défaillance de l'opération. Si la communication avec le serveur 116 a été terminée auparavant ou n'existe pas ou lorsqu'une session est active ou une transaction est active, une indication de défaillance est renvoyée. Toutes les sessions et transactions doivent être terminées explici- tement par l'application 114 avant un désenregistrement. (c) Gestion de session. Les opérations d'accès à chaque base de données 124 sont réalisées dans les limites d'une "session". Une application 114 lance une session, effectue une série d'opérations d'accès à la base de données, et termine la session. La gestion de la session est réalisée par la couche sous-jacente d'accès aux données et la couche sous-jacente de transport de données qui effectuent des opérations telles que l'ouverture et la fermeture du tube 122 de communications vers le commutateur 20, le conditionnement des demandes des applications et le renvoi au commutateur 20, et la présentation des résultats des demandes à l'application 114. Les opérations de gestion de session sont simplement: (i) le lancement d'une session (ii) la terminaison d'une session Une session est cataloguée et identifiée par une identité unique de session. Le commutateur 20 est respon- sable de l'affectation et de la présentation de l'identité ID de session au serveur 116. Cette réalisation est décrite plus en détail dans la suite. Une application 114 peut avoir une seule session ouverte par commutateur téléphonique. Toute tentative de lancement d'une autre session pour le même commutateur téléphonique est rejetée. Les sessions ne peuvent être lancées que dans le plan actif le cas échéant, et sont supprimées en cas d'activité du commutateur. (i) Lancement d'une session. Pour que la base de données du commutateur téléphonique 20 puisse être atteinte, l'application 114 doit lancer une session d'accès à la base de données. Une session est lancée par appel de la fonction de lancement de session et transmet, comme variable, l'identificateur du commutateur spécifique 20 que souhaite atteindre l'application 114 et le plan de destination. L'identité du commutateur est saisie par l'application 114. La fonction de lancement de session établit une connexion avec le commutateur spécifié 20 par le réseau ou un mécanisme de connexion et affecte une identité ID de session à cette connexion. La fonction renvoie une valeur indiquant le succès ou la défaillance de l'opération. L'identité de la session est renvoyée à l'application appelante 114 sous forme d'un paramètre d'identité Session_ID. L'application doit utiliser cette identité pour les demandes ultérieures d'accès pendant la durée de la session. Si le lancement de la session présente une défaillance, l'accès à la base de données 124 n'est pas disponible pour le commutateur 20. Si la session d'accès à la base de données existe déjà ou une communication avec le commutateur 20 ne peut pas être établie, un indicateur de défaillance est renvoyé. Dans le cas de commutateur ayant plusieurs plans (redondance avec tolérance de panne), le plan voulu peut être identifié pour être atteint. (ii) Terminaison de session. Lorsqu'une application 114 veut terminer la session actuelle, la fonction de termi- naison de session est appelée. L'identité actuelle SessionID est transmise comme paramètre à la fonction. Le tube 122 de communications avec le commutateur 20 est fermé. La fonction renvoie une valeur indiquant le succès de l'opération ou sa défaillance. Si la session a déjà été terminée ou existe ou lorsqu'une transaction est active, une défaillance est indiquée. La transaction doit être terminée explicitement par l'application 114 avant la terminaison d'une session. (d) Gestion de transaction. Comme décrit précédemment, l'invention est décrite en référence à un commutateur "Mitel" "SX-2000". Dans un tel commutateur, l'accès à la base de données est donné par une couche de vues, les tables 124 de la base de données étant manipulées sous forme d'un ensemble de vues faisant partie de l'application 126 d'accès à la base de données du commutateur. Il est évident que l'homme du métier peut effectuer les modifications néces- saires afin que l'invention soit adaptée à un commutateur téléphonique de réalisation et de fabrication différentes dans lequel des ensembles de vues ne sont pas utilisés. Les opérations des bases de données qui modifient la base de données 124 doivent être exécutées dans les limites d'une transaction. Trois fonctions de transaction sont utilisées: (i) lancement d'une transaction (ii) soumission d'une transaction (iii) suppression d'une transaction Une application 114 ne peut avoir qu'une seule transaction active par commutateur téléphonique 20. Toute demande ultérieure de lancement de transaction sur le même commutateur 20 est rejetée. (i) Lancement d'une transaction. Pour qu'une applica- tion 114 exécute des demandes de modification de base de données, il faut qu'une transaction soit lancée. L'appli- cation 114 lance une transaction par appel de la fonction de lancement de transaction et par transmission de l'identité de session affectée lorsque la fonction de début de session a été appelée. Lors de la communication avec un commutateur "SX-2000", l'application 114 doit aussi spécifier l'ensemble de vues, le cas échéant, de l'application 126 qui doit être ouverte pendant la transaction. L'ensemble convenable de vues pour chaque version du commutateur est soit préala- blement chargé, soit contenu dans la base de données 120 de la station de gestion 10, soit saisi par l'interface d'application. L'ensemble de vues d'application est utilisé suivant l'opération choisie par l'application 114. L'iden- tité de la session est validée et une demande est transmise au commutateur 20 pour l'ouverture de l'ensemble spécifié de vues. La fonction renvoie une valeur indiquant le succès ou non de l'opération. Si le lancement de la transaction présente une défaillance, l'ensemble de vues de la base de données 124 n'est pas ouvert pour l'accès en écriture. Si une ou plusieurs vues d'une base de données 124 ont déjà été ouvertes par une autre application 114, une défaillance est indiquée. Seules les vues spécifiées sont disponibles pour être modifiées. L'ensemble de vues ouvert ne peut pas être changé pendant une transaction. Toute tentative de modifi- cation d'autres vues de la transaction actuelle est rejetée. Cependant, les opérations de lecture GET et de localisation FIND sont permises pour d'autres vues dans la transaction actuelle. (ii) Soumission d'une transaction. Lorsqu'une applica- tion 114 veut soumettre la transaction actuelle, il appelle la fonction de soumission de transaction et spécifie l'identité de la session actuelle. La fonction de soumission transmet une demande de soumission au commutateur 20 et ferme la transaction indépendamment de son succès. La fonc- tion renvoie le succès ou non de l'opération. Si une transaction n'est pas en cours, une défaillance est indiquée. (iii) Suppression d'une transaction. Lorsqu'une appli- cation 114 veut supprimer des changements réalisés à la base de données 124, il appelle la fonction de suppression de transaction avec l'identité de la session actuelle. La fonction de suppression transmet une demande de suppression de transaction au commutateur 20 et termine la transaction. La fonction renvoie le succès ou non de l'opération. Si une transaction n'est pas en cours, une défaillance est renvoyée. (e) Fonctions de lecture-écriture. Une ligne est une vue composite d'un enregistrement d'une base de données ou de parties de plusieurs enregistrements qui représentent la plus petite granularité des données dans une base de don- nées. Les lignes sont constituées d'un ou plusieurs champs accessibles par des noms de champ. Toutes les lignes analogues sont contenues dans une vue de la base de données. Quatre fonctions essentielles de manipulation de lignes sont les suivantes: (i) lecture de ligne (ii) addition de ligne (iii) suppression de ligne (iv) modification de ligne A l'exception des opérations de lecture et de localisa- tion GET et FIND, toutes les opérations doivent être réalisées dans le contexte d'une transaction. Toutes ces opérations doivent être appelées dans le contexte d'une session. (i) Lecture de ligne. Une application 114 peut lire le contenu d'une ligne unique à partir du commutateur 20 pour une vue particulière et une clé de ligne par appel de la fonction de lecture de ligne. L'application 114 doit donner l'identité de la session actuelle, l'identité de la vue ou les noms des tables de la ligne demandée, et une structure de ligne dans laquelle la partie de clé est remplie. L'identité de vue, la structure de ligne et le masque de ligne dépendent du fabricant, du modèle et de la version du commutateur téléphonique auquel l'accès est réalisé, la structure étant conservée dans la base de données 120 pour être utilisée par l'application 114. Eventuellement, des informations relatives aux lignes peuvent être obtenues par appel de la fonction de définition de lecture de ligne décrite dans la suite. La fonction de lecture de ligne renvoie une valeur indiquant le succès de l'opération ou non. Le contenu de la ligne est renvoyé dans les paramètres de la ligne. Si la ligne n'existe pas ou ne peut pas être lue, une défaillance est renvoyée. Cette fonction doit être appelée dans le contexte d'une session mais ne nécessite pas une transaction. (ii) Addition de ligne. Une application 114 peut ajouter une ligne à un commutateur 20 par appel de la fonction d'addition de ligne. L'application 114 doit donner l'identité de la session actuelle, l'identité de la vue et le contenu de la ligne. L'identité de la vue, la structure de la ligne et le masque de ligne dépendent de la fabri- cation, du modèle et de la version du commutateur concerné, la structure étant conservée dans la base de données 120 pour être utilisée par l'application 114. Eventuellement, les informations sur les lignes peuvent être obtenues par appel de la fonction de lecture de définition de ligne décrite dans la suite. Le succès ou non de l'opération est * indiqué. En cas de défaillance, la ligne n'est pas ajoutée. Lorsqu'une transaction contenant la vue à modifier n'est pas ouverte, une défaillance est indiquée. (iii) Suppression de ligne. Une application 114 peut supprimer une ligne d'une base de données 124 par appel de la fonction de suppression de ligne. L'application 114 doit donner l'identité de la session actuelle, l'identité de la vue et la ligne. L'identité de la vue, la structure de ligne et le masque de ligne dépendent de la fabrication, du modèle et de la version du commutateur 20 concerné, la structure étant conservée dans la base de données 120 pour être utilisée par l'application 114. Eventuellement, des infor- mations relatives aux lignes peuvent être obtenues par appel de la fonction de lecture de la définition de ligne décrite dans la suite. Le succès ou non de l'opération est indiqué. Si une défaillance est indiquée, la ligne n'est pas suppri- mée. Lorsqu'une transaction contenant la vue à modifier n'est pas ouverte, une défaillance est indiquée. (iv) Modification de ligne. L'application 114 doit donner l'identité de la session actuelle, l'identité de la vue, et les contenus de l'ancienne ligne et de la nouvelle ligne. L'identité de la vue, la structure de la ligne et le masque de ligne dépendent de la fabrication, du modèle et de la version du commutateur concerné 20, la structure étant conservée dans la base de données 120 pour être utilisée par l'application 114. Les informations relatives aux lignes peuvent éventuellement être obtenues par appel de la fonction de lecture de définition de ligne décrite dans la suite. Le succès ou non de l'opération est indiqué. En cas de défaillance, la ligne n'est pas modifiée. Lorsqu'une transaction contenant la vue à modifier n'est pas ouverte, une défaillance est indiquée. (f) Lecture des fonctions "premier-suivant". Deux fonctions lecture sont prévues: (i) lire première ligne (ii) lire ligne suivante (i) Lire première ligne. L'application 114 peut déter- miner la première ligne destinée à une vue particulière dans la base de données 124 du commutateur par appel de la fonc- tion de lecture de première ligne. L'application 114 doit spécifier l'identité de la session actuelle, l'identité de la vue et une structure de données de ligne. L'identité de la vue, la structure de ligne et le masque de ligne dépendent de la fabrication, du modèle et de la version du commutateur téléphonique concerné, la structure étant conservée dans la base de données 120 pour être utilisée par l'application 114. Eventuellement, des informations rela- tives aux lignes peuvent être obtenues par appel de la fonction de lecture de définition de ligne décrite dans la suite. Le succès de l'opération est indiqué et la ligne est incorporée aux paramètres de ligne. Cette fonction doit être appelée dans le contexte d'une session mais elle ne nécessite pas l'acceptation d'une transaction. (ii) Lire ligne suivante. Cette fonction est analogue à la fonction de lecture de la première ligne, mis à part le fait que l'application 114 doit donner une ligne de départ startTuple pour commencer. La fonction ramène la ligne suivante de cette ligne dans la vue spécifiée. Le succès de l'opération est renvoyé et le contenu de la ligne corres- pondante est incorporé aux paramètres de ligne. Cette fonction doit être appelée dans le contexte d'une session mais elle ne nécessite pas l'acceptation d'une transaction. (g) Fonctions de gestion de ligne. Un certain nombre de fonctions de gestion de ligne est utilisé. L'application 114 peut lire la définition d'une ligne pour une vue parti- culière d'après la version du logiciel chargé dans le commutateur 20, par appel de la fonction de lecture de définition de ligne. L'application 114 doit spécifier l'identité de la vue et la version de chargement du commu- tateur qui est soit conservée dans la base de données 120, soit obtenue par l'application 114. Le succès de l'opération est renvoyé et la définition de ligne est donnée dans le paramètre de dimension de ligne. La version chargée dans le commutateur doit être donnée pour assurer la compatibilité ascendante. Ceci ne représente pas obligatoirement la version chargée d'un commutateur 20 avec lequel l'appli- cation 114 veut communiquer. La définition de ligne comprend des informations relatives aux articles suivants, mais sans être limitée à ces articles: dimension de la ligne identification de clé décalage des champs individuels dans la ligne dimension des champs individuels type des données des champs plage des données des champs Cette fonction peut être appelée en dehors du contexte d'une session car la communication avec un commutateur télé- phonique 20 n'est pas nécessaire. (a) Malloctuple (b) Inituple (c) Freetuple (d) Getupletype (e) Getuplename (f) Getuplesize (g) Getuplenumfields (h) Getfieldnameptr (i) Getfieldkind (j) Getfieldtype (k) Getfieldsize (1) Getfieldxlationtbl (m) Setfield (n) Getfield (o) Copytuple Toutes les fonctions précitées sont particulières à la station de gestion 10 et sont destinées à permettre à l'application 114 d'obtenir les informations relatives à la structure de la table de la base de données dans le commutateur 20. Dans la discussion qui suit, la mise en oeuvre des fonctions est illustrée dans le cas du commu- tateur "Mitel" "SX-2000", bien que l'invention puisse aussi autoriser la modification des fonctions d'après les particu- larités des différents fabricants, modèles et versions de commutateurs téléphoniques. Toutes les fonctions précitées sont mises en oeuvre dans une couche d'accès d'application et une couche d'accès à la base de données de la station 10 de gestion. Les fonctions permettent à l'application d'obte- nir des informations relatives aux structures de base de données et de tables particulières utilisées dans le commu- tateur 20. Ces fonctions doivent être appelées lorsque l'application a besoin de telles informations. Il est possible que l'application 114 soit écrite afin qu'elle utilise les autres aspects de l'invention sans avoir recours à ces fonctions lorsque l'application sait déjà quelle est la structure de tables de la base de données et lorsque le commutateur choisi a été défini. Cependant, l'addition de cette fonctionnalité selon l'invention permet une augmen- tation de la compatibilité entre les différentes versions des applications 114, du serveur 116 d'accès à la base de données et du commutateur téléphonique 20, car l'application peut demander la structure de la base de données du commuta- teur avec lequel elle veut communiquer. Les données significatives concernant la structure des diverses tables de la base de données, des vues, etc. pour différents fabricants, modèles, versions et révisions du commutateur téléphonique 20 sont toutes contenues dans le serveur 116 d'accès à la base de données qui permet le découplage de l'application 114 des versions particulières du commutateur téléphonique 20. Chacune des fonctions précitées est décrite plus en détail dans la suite. a) Malloctuple. Cette fonction obtient les éléments des vues de base de données contenant les paramètres et affecte un circuit tampon de ligne (zone de mémoire) qui peut contenir efficacement toute ligne gérée et manipulée par l'application 114 et le serveur 116. b) Inituple. Cette fonction utilise l'identité de la vue de la base de données et un pointeur sur la ligne comme paramètres et initialise le circuit tampon de ligne pour supprimer le contenu actuel. c) Freetuple. Cette fonction lit le circuit tampon affecté par la fonction Malloctuple et renvoie le contenu lorsqu'il n'est plus utilisé pour la récupération des ressources du système. d) Getupletype. Cette fonction lit l'identité de la vue et renvoie le type de ligne, c'est-à-dire indique les opérations supportées par cette vue particulière de la base de données. Les différents types de vues peuvent supporter ou non l'addition, la suppression, la modification ou la lecture des données. e) Getuplename. Cette fonction lit l'identité de la vue voulue et renvoie le nom de la ligne. f) Getuplesize. Cette fonction lit l'identité de la vue et renvoie la dimension de la ligne. g) Getuplenumfields. Cette fonction lit l'identité de vue et l'addition de version et renvoie le nombre de champs dans la ligne. h) Getfieldnameptr. Cette fonction lit l'identité de vue et l'identité de champ et renvoie le nom d'un champ donné dans la ligne. i) Getfieldkind. Cette fonction lit l'identité du champ et l'identité de la vue et renvoie le type d'un champ donné dans la ligne (par exemple un entier, une énumération ou une chaîne). j) Getfieldtype. Cette fonction lit l'identité de la vue et l'identité du champ et renvoie le type d'un champ donné dans la ligne (par exemple un entier, une énumération ou une chaîne). k) Getfieldsize. Cette fonction lit l'identité de la vue et l'identité du champ et renvoie la dimension d'un champ donné dans la ligne. 1) Getfieldxlationtbl. Cette fonction lit l'identité de la vue et l'identité du champ et renvoie une table utilisée pour la transformation d'une énumération en chaîne correspondante dans un champ donné de la ligne. m) Setfield. Cette fonction lit l'addition de version, l'identité de la vue, l'identité du champ, la valeur du champ et la ligne et établit une valeur d'un champ donné dans la ligne. n) Getfield. Cette fonction lit l'addition de version, l'identité de vue, l'identité de champ, le pointeur sur la valeur du champ et une ligne et lit la valeur d'un champ donné dans la ligne. o) Copytuple. Cette fonction lit l'identité de la vue, la ligne de destination et la ligne source et copie le contenu de la ligne source dans le circuit tampon de ligne de destination. On peut se référer au chapitre qui suit sur le format des données communes pour d'autres informations relatives à des exemples de structure de type de données qui peuvent être utilisés dans les opérations précitées. 2) COUCHE D'ACCES A LA BASE DE DONNEES DANS LA STATION DE GESTION On se réfère à la figure 4; les propriétés de la couche d'accès à la base de données dans la station 10 de gestion téléphonique selon l'invention sont maintenant décrites. Comme indiqué précédemment, l'application 114 exécutée sur la station 10 de gestion communique avec le serveur 116 d'accès à la base de données par une couche 150 de redirection d'interface API. Dans un autre mode de réalisation, d'autres clients DBA ou d'autres applications de routage peuvent utiliser la couche 150 de redirection d'interface API pour communiquer avec le serveur 116. Ce serveur 116 communique par un serveur 152 de communications de base de données qui communique lui-même avec une couche 154 de redirection de communications. Cette couche 154 communique alors avec la couche de transport de données par le tube 122 de communications. Ce tube de communications 122 appelle le service 156 de couche de présentation pour placer les données à un format qui peut être communiqué à la carte "Ethernet" 110 et placé dans le réseau local 30. L'architecture selon l'invention permet le support de plusieurs applications indépendantes. Les composants logiciels individuels nécessaires pour le support des demandes d'accès à la base de données dans la station de gestion 10 sont les suivants: (a) couche de redirection API, (b) format des données de paramètres API, (c) format commun de données, (d) serveur d'accès à la base de données (e) serveur de communications avec la base de données. On décrit maintenant un bref résumé de chaque composant logiciel dans les paragraphes qui suivent. (a) Couche de redirection API. La couche 154 de redirection API réside dans la station de travail 10 de gestion sous forme d'une bibliothèque de fonctions avec lesquelles l'application 114 peut effectuer la compilation et la liaison. La couche 154 de redirection API transforme les fonctions d'application 114 décrites précédemment en une forme qui peut être traitée par le serveur 116. Ces fonctions permettent à l'application 114 d'établir une connexion par prise avec le serveur 116 et émet des demandes d'accès à la base de données pour l'action sur le commu- tateur 20. La couche de redirection API isole les applica- tions, telles que l'application 114, de la réalisation du serveur 116. Cet isolement permet au serveur 116 d'être changé sans impact sur les applications individuelles (c'est-à-dire qu'il n'est pas nécessaire de recompiler ou de reconstruire les liens des anciennes applications qui doivent travailler avec un nouveau serveur d'accès à la base de données). Les appels aux fonctions de l'interface API par l'application 114, comme décrit dans le chapitre "interface entre les couches d'accès à l'application et à la base de données dans la station de gestion" qui précède, sont transformés en messages associés par utilisation d'une simple connexion par prise et d'un format commun de données. Les messages sont émis et reçus de manière synchrone (blocage dans l'attente d'une réponse). Comme décrit précédemment, l'application 114 effectue la demande de fonction API et la transmet à la couche 150 de redirection. Cette couche 150 reçoit la demande API de l'application 114, transforme cette demande API en une demande au format commun de données, puis transmet cette demande au format commun au serveur 116. Le serveur 116 traite alors la demande et, après traitement, renvoie une réponse au format commun de données à la couche 150 de redirection. La réponse au format commun est alors formatée par la couche 150 de redirection à un format qui peut être reçu par la fonction API appelante et renvoyé à l'appli- cation 114. Chaque application 114 communique avec une couche indépendante 150 de redirection API pour gérer l'accès au serveur 116. La couche de redirection API transmet un message de demande de format commun de données au serveur 116 et se bloque dans l'attente d'une réponse. Les appels API suivants sont gérés par cette couche. Gestion d'ensembles de vues OrderViewSet Identification d'erreur GetErrorText Enregistrement d'application Register Deregister Gestion de session StartSession EndSession Gestion de transaction StartTransaction SubmitTransaction CancelTransaction Fonctions de lecture-écriture GetTuple AddTuple DeleteTuple ModifyTuple Fonctions de lecture premier- suivant FindTuple GetNextTuple Pour plus d'informations sur ces appels à des fonc- tions, on peut se référer au chapitre précédent "interface entre les couches d'accès à l'application et à la base de données dans la station de gestion". (b) Format des données de paramètres API. Le format des données de paramètres API est le format des données et variables transmis par les fonctions décrites précédemment en référence à la figure 4 et utilisé par l'application 114 et la couche 150 de redirection. Cette couche 150 transforme les données reçues de l'application 114 au format des données de paramètres en format commun de données et trans- met les informations au serveur 116. Ces formats peuvent être propres à l'application, mais ils contiennent des informations nécessaires à la transformation des informa- tions au format commun de données. Ce format commun est décrit plus en détail dans la suite. L'exemple qui suit concerne le commutateur "Mitel" "SX-2000". Des modifications évidentes peuvent être apportées pour d'autres réalisations de commutateurs. (c) Format commun de données. Le format commun de données est utilisé uniquement par la couche 150 de redi- rection API, le serveur 116 d'accès à la base de données, le serveur 152 de communications DBA et la couche 154 de redirection de communications. Les structures des données sont utilisées par chaque composant pour la composition ou l'interprétation des messages transmis entre eux sous forme de données sans type. La couche 150 lit les données reçues de l'application 114 au format de données de paramètres API et les transforme au format commun de données. La transformation particulière dépend du fabricant, du modèle et de la version de commutateur téléphonique utilisé à cet effet. La structure correspondant à un exemple de commu- tateur "Mitel"' "SX-2000" est utilisée comme exemple. Le format commun de données comprend une identification de la version destinée à assurer le support de la compatibilité ascendante à l'avenir au cas o des perfectionnements seraient apportés au format commun de données. Ce format est caché à l'application 114. Les changements du format commun peuvent être introduits indépendamment, si bien que les versions de chaque composant peuvent être différentes sans perte de communications. Le serveur 116 d'accès à la base de données garde un enregistrement client pour chaque client (associé à la connexion par prise). Cet enregistrement client contient le type, l'état, le nom, la version, le numéro de session et l'enregistrement de connexion par prise du client. La couche 154 de redirection API et le serveur 152 de communications de base de données distinguent les clients par un type client CLIENT_APPLIC et CLIENTNE respectivement. Types de données au format commun de données Les types de données au format commun de données sont transmis entre la couche 154 de redirection API, le serveur 116 d'accès à la base de données et le serveur 152 de communications de base de données. On décrit dans la suite la définition des types de demandes qui sont supportés par le serveur 116 et le serveur 118 selon l'invention. Ils correspondent aux codes d'action supportés par le commutateur téléphonique 20. typedef enum { DBAREQNIL = DBA FIRST ENUM DBA_REQ_CLIENT_REGISTER DBA_REQCLIENT DEREGISTER DBA_REQASYNCERROR DBAREQSESSIONSTART DBA_REQ_SESSION_END DBA_REQ_TRANS_START DBA_REQTRANS_SUBMIT DBA_REQ_TRANS_CANCEL DBAREQADDTUPLE DBA_REQMODIFYTUPLE DBA_REQGETTUPLE DBA_REQ GETFIRST DBA_REQ GETNEXT DBAREQ LAST DBA_REQEND = DBA LASTENUM }dba2kRequest La suite concerne un exemple de définition de la structure de données pour la partie des données d'un message à transmettre au commutateur 20 pour l'exécution de l'une des transactions précitées. typedef struct { dba2kViewIdsett dba2kViewIdSet; //Ensemble de vues (ou tables) à verrouiller au début d'une transaction. dba2kViewIdt dba2kViewId; //Vue (ou table) traitée (pour addition, modifica- tion, suppression, etc.) dba2kRTuple_t dba2kKeyTuple; //Clé de ligne à utiliser pour la transaction. dba2kTuplet dba2kFullTuple; //Ligne à utiliser pour la transaction. } dba2kData_t; La suite est un exemple des définitions de la structure des données correspondant au nom de client et à l'édition de version ou la version du commutateur ainsi que la structure destinée à contenir la partie des données d'un message à transmettre au commutateur téléphonique 20. typedef char dbaClientName t [DBA NAME STR LEN +1] typedef char dbaRealeaseEditiont [DBARELEASESTRLEN +1] typedef dba2Kdatat *dba2kDataPtrt; /* Cette structure peut avoir une dimension qui grandit pour assurer la compatibilité ascendante */ typedef struct { int dbaHeaderSize; int dba2kDataSize; dbaRequest_t dbaRequest; dbaError t dbaError; //Gestion des erreurs à la transaction dbaClientName t dbaClientName; //Nom de client pour demande d'enregistrement client dba2kEdition t dbaReleaseEdition; //Version du commutateur concerné dbaClientName t dbaAssociateName; dbaPlace t dbaAssociatePlane; //Nom associé de commutateur et d'organe de commande d'une transaction (lorsque le commutateur redondant éventuel est concerné) int dbaSessionId; //Identificateur unique de la transaction dba2kDataPtrt dba2kDataPtr; //Données accompagnant la transaction pour exécution par l'opérateur }dbaCdfMessage_t La suite est un exemple des définitions de la struc- ture des données de support d'un commutateur téléphonique 20 qui possède plusieurs plans (redondance à tolérance de panne). typedef enum DBA_PLANENIL = DBA FIRSTENUM, DBA_PLANE_A, DBA PLANE B, DBA_PLANEACTIVE, DBA_PLANEINACTIVE, DBAPLANEEND = DBA LAST ENUM }dbaPlane_t; typedef int dbaErrort; La suite est un exemple de la définition de la nature des champs qui peuvent apparaître dans une ligne. DBA2KFIELDKINDNIL = DBA FIRST ENUM DBA2KFIELDKIND KBY DBA2KFIELDKINDREADWRITE DBA2KFIELDKIND READONLY DBA2KFIELDKINDSECONDARYKEY DBA2KFIELDKINDEND = DBA LASTENUM } dba2kFieldKind_t; La suite est un exemple de la définition du type des champs qui peuvent apparaître dans une ligne. typedef enum { DBA2KFIELDTYPENIL = DBA FIRSTENUM DBA2KFIELDTYPE INTEGER DBA2KFIELDTYPEENUM DBA2KFIELDTYPESTRING DBA2KFIELDTYPE-END = DBA LASTENUM } dba2kFieldType_t; 15. La suite est un exemple de définition de type de vues qui peuvent apparaître dans un commutateur téléphonique. typedef enum { DBA2KVIEWTYPENIL = DBAFIRSTENUM DBA2K VIEWTYPE FULL FUNCTION SUPPORT WITH BLANTUPLES DBA2KVIEWTYPEFULLFUNCTIONSUPPORTNOBLANKTUPLES DBA2KVIEWTYPENOSUPPORTFORADDORDELETE DBA2KVIEWTYPE VIEW HAS COMPRESSED MEMBER LIST DBA2KVIEWTYPEHEADONLY DBA2K VIEWTYPE END = DBA LAST ENUM } dba2KViewType_t La suite est un exemple de la définition indiquant comment peut apparaître un champ qui peut être présent dans une ligne. type def struct { char *fieldName; int offset; int size; dba2kFieldKind t kind; dba2kFieldType_t type; int minValue; int maxValue; strToEnum {*xlationTbl} []; strToEnum {apiXlationTbl} []; La suite est un exemple des définitions de la nature des champs qui peuvent apparaître dans des lignes pour différentes versions du commutateur 20. typedefdba2kFieldDesc_t {*dab2kFFieldTblPtr_t} [] typedefstruct { dba2kFieldTblPtrt tupleFieldTblPtr; const dba2kEdition_c releaseEdition; const int numFields; Idba2kTupleVersiont; typedef dba2kTupleVersiont {*dba2kTupleVersionTblPtrt}[]; typedef struct { dba2kTupleVersionTblPtrt tupleVerTblPtr; int tupleSize; char *tupleName; dba2kViewTypet viewType; }dba2kTupleDesc_t; La suite est un exemple des définitions de structure de données pour divers types de vues ou tables qui peuvent être supportées dans le commutateur 20. typedef enum {/*from viewidentifer/dbviewid.typ*/ VIDNIL, VID_COR, VID_COS, VID_FAC, VIDREMOTE DN, VIDEND = DBALASTENUM }ViewId; Types de données de base de données de commutateur. Lors de la mise en oeuvre sur des commutateurs "Mitel" "SX-2000"1, des types des données de la base de données de commutateur sont transmis à la couche de redirection API qui reflète directement la base de données 124 de commutateur. Ces types sont les suivants. typedef enum { CLIENTNIL = DBAFIRSTENUM, CLIENT_APPLIC, CLIENTNE, CLIENT END = DBA LAST ENUM }clientType_t; typedef struct { dbaError t dbaError; boolean dbaErrStrPresentt; char dbaErrStr[ DBASTR LENL 300]; }dbaLongError_t; Types de données d'identification de session. Les types de données d'identification de session sont aussi transmis dans tous les messages et ne peuvent pas être changés, et ils sont les suivants. typedef struct { int dbaSysId; long int dbaTaskId; char dbaPlaneId; }dbaSessionId_t; Ces types de formats communs de données sont utilisés à l'intérieur de la couche d'accès à la base de données pour la gestion interne, et varient d'une réalisation à une autre. Par exemple, ils peuvent comprendre des éléments suivants. #define ABS_MAX_CLIENTS 8 /*doit dépasser nombre de clients autorisés*/ #define ABSMAXSESSIONCOUNT4 typedefenum { STATUS_NIL, STATUS_OK, STATUSNEW, STATUS_AWAITING_NE, STATUSEND } clientStatus_t; typedef struct { char clientSessionAssociateName[DBANAMELEN]; int clientSessionAssociated; int clientSessionSqNbr; } clientSession_t; typedef struct { int clientNbr; clientType_t clientType; clientStatus t clientStatus; char clientClientName[DBANAMELEN]; char clientRelease[DBARELEASEINFOLEN]; int clientSessionCount; clientSessiont clientSessionRec[ABSMAXSESSIONCOUNT]; ssuconnectRect clientConnectRec; } clientRec_t; (d) Serveur d'accès à la base de données. Le serveur 116 d'accès à la base de données est exécuté sous forme d'une opération séparée simultanée exécutée sur la station de gestion 10 qui assure les services pour les applications clientes 114. L'invention assure le support par multiplexage entre plusieurs applications et plusieurs commutateurs téléphoniques. De simples connexions par prise sont utili- sées pour la communication avec les applications par l'intermédiaire de la couche 154 de redirection API et du serveur 152 de communications de base de données, appelés collectivement "clients". Le support de compatibilité ascen- dante est assuré avec un format commun de données pour les messages transmis par la connexion par prise comme décrit plus en détail dans la suite. Les messages sont émis et reçus de manière asynchrone (sans blocage). Les opérations par prise et les messages au format commun de données sont gérés par le serveur 116 d'accès à la base de données exclusivement par prise de service DBAService. Le cas échéant, une conversion est réalisée entre les versions du message au format commun de données et aussi entre diverses versions de la base de données 124. Pour que la communication de la station 10 au commu- tateur 20 soit plus facile, la version du serveur 116 doit avoir un numéro supérieur ou égal à la version du commu- tateur 20. Le serveur 116 a une connaissance relative à divers modèles, versions et révisions du commutateur 20 afin qu'il puisse transformer les commandes et données reçues de l'application 114 en un format qui peut être compris par le commutateur 20. La compatibilité ascendante est ainsi auto- risée. Le serveur 116 connaît les divers formats de données et de commandes nécessaires pour la commande et la gestion du commutateur 20. Il peut transformer, transmettre et omettre des éléments de la manière nécessaire au condi- tionnement des commandes et présenter des réponses à un format qui peut être compris à la fois par le commutateur 20 et l'application 114. L'un des avantages de cette réali- sation est que l'application ne doit pas connaître à l'avance les changements réalisés dans les différents modèles, versions et révisions du commutateur 20. Grâce à la fonction d'enregistrement décrite précédemment, l'appli- cation 114 stipule au serveur 116 la version, le modèle et la révision du commutateur qu'il peut comprendre et le serveur 116 peut exécuter la transformation nécessaire pour présenter à l'application 114 des réponses que celle-ci peut attendre. Caractéristiques de performances La liaison de communications et les couches associées selon l'invention ont un impact sur les performances de l'autocommutateur. Cet impact dépend des caractéristiques de la liaison de communications. Le mécanisme de transaction permet à une application d'ouvrir simultanément plusieurs vues de la base de données. Plus le nombre de vues de base de données modifiées est élevé et plus une action de soumis- sion est longue à exécuter. Si un commutateur d'activité apparaît à un moment quelconque pendant la transaction avant la fin satisfaisante d'une soumission, tous les changements sont défaits. Pour cette raison, il est recommandé de limi- ter l'étendue des changements exécutés dans une seule transaction. Le serveur 116 gère les demandes de connexion des clients et prépare l'enregistrement client associé. Les messages ultérieurs de la connexion par prise sont gérés dans le contexte de l'enregistrement client associé au format commun des données. * Chaque message est desservi indépendamment et est transmis ou traité le cas échéant. Les conversions entre les niveaux des messages au format commun de données et entre les niveaux de version de commutateur sont aussi réalisées de la manière nécessaire. Initialisation. Le serveur 116 d'accès à la base de données est lancé lors de la mise en fonctionnement du système lorsque la fonctionnalité d'accès à la base de données est autorisée. Chaque enregistrement client est initialisé à des valeurs nulles et le service par prise de service DBA est établi. Chaque fonction donnée par la couche 154 de redirection API lance une demande de fonction et bloque le résultat de la demande. Une erreur dbaError est renvoyée et représente soit un succès soit un code de défaillance. Le cas échéant, la demande est transformée en une demande au format commun de données, et transmise au serveur 116 et la réponse associée au format commun de données est transformée pour être renvoyée à l'application 114. Les demandes qui suivent sont communiquées au serveur 116 et traitées par celui-ci. Connecte client. L'identificateur (appelé "handle") "connecte client" est invoqué lorsqu'une connexion est éta- blie par le client par la prise de service DBA. Un enregis- trement client est obtenu et l'enregistrement de la connexion estinitialisé. La connexion par prise est repoussée lorsqu'un enregistrement client n'est pas dispo- nible à cause du dépassement du nombre maximal de connexions simultanées par prise. Déconnecte client. L'identificateur "déconnecte client" est invoqué lorsqu'une déconnexion du client est reconnue par la prise de service DBA. La connexion est fermée et l'enregistrement client associé est vidé le cas échéant. Enregistre client. L'identificateur "enregistre client" est marqué par le client et détermine le type de client qui se connecte au serveur 116. Ce dernier initialise l'enre- gistrement client associé en conséquence. L'enregistrement est supprimé lorsque le nombre de clients permis pour le type déterminé est dépassé. Désenregistrement client. Après réception d'une demande de désenregistrement de client provenant du serveur 152 de communications, une vérification effectuée par le serveur 116 indique le nombre de sessions en cours. Si aucune session n'est active, la connexion par prise associée est fermée et aucune notification n'est donnée aux clients associés. Début de session. Après réception d'une demande de début de session provenant de la couche 150, les enregistre- ments clients sont lus pour qu'une communication existante du serveur 152 avec le commutateur 20 soit déterminée. S'il n'existe pas déjà une telle communication, le serveur 152 est autorisé par le serveur 116. L'identité de session DBA est initialisée et est partiellement établie à l'aide des identificateurs de l'enregistrement client associé, et le serveur associé 152 transmet la demande de début de session. Après réception d'une demande de début de session provenant du serveur 152, le client associé est déterminé d'après l'identité de session DBA. Un accusé de réception est alors transmis à l'opération de la couche 154 de redirection API qui a lancé la demande. A ce moment, l'identité de session DBA a été pleinement établie. Fin de session. Après la réception d'une demande de fin de session provenant de la couche 150 de redirection API, une vérification détermine le nombre de sessions en cours. Lorsqu'aucune session n'est active, la connexion par prise associée est fermée. La demande de fin de session n'est pas utilisée par le serveur 152. Demande et réponse. L'identificateur "demande et réponse" gère les demandes provenant des opérations de la base de données du commutateur et les réponses associées (début de transaction, soumission de transaction, sup- pression de transaction, lecture de ligne, lire premier, lire suivant, localiser premier, localiser suivant, etc.). La validation de l'identité de session DBA est réalisée et le message au format commun de données est transmis au client associé. La conversion de compatibilité est aussi appliquée le cas échéant. Contraintes. Les restrictions relatives au nombre de clients simultanés sont imposées pour la gestion des contraintes relatives aux ressources. Le nombre maximal de toutes les connexions par prise est spécifié avec les limites du nombre de clients pour chaque type de client. Gestion d'erreur. Si une défaillance de transmission de message se produit à une connexion par prise, le client associé est désenregistré et la connexion par prise est déconnectée. Aucun impact ne porte sur une autre connexion établie. Les messages reçus destinés à des clients qui n'existent plus sont négligés. Une erreur de message imprévu est enregistrée dans le cas o le type du client n'est pas autorisé. Caractéristiques supplémentaires de support. Les caractéristiques suivantes de support sont utili- sées dans le serveur d'accès à la base de données 116: (i) vérification de programmation de base de données du commutateur (ii) support de plusieurs sessions de la station de gestion (iii) support de plusieurs sessions du commutateur téléphonique (iv) décomptage d'inactivité dans les transactions (v) gestion de plans actif et inactif (vi) gestion de commutateur d'activité (vii) versions de la base de données (viii) rétablissement après défaillance (ix) compatibilité ascendante. On décrit plus en détail ces caractéristiques dans la suite. (i) Vérification de la programmation de la base de données du commutateur. Pendant les opérations qui changent le contenu de la vue de la base de données dans le commu- tateur 20, une procédure de validation est exécutée et toute erreur est indiquée. Si une erreur se produit, la défail- lance de validation est alors communiquée à l'application 114 par la fonction d'identification d'erreur décrite précédemment afin que les actions convenables soient prises. (ii) Support de plusieurs sessions de la station de gestion. L'architecture selon la présente invention est exécutée pour le support de plusieurs sessions. Ainsi, plusieurs stations de gestion 10 ou plusieurs stations de travail d'utilisateur peuvent avoir accès à un commutateur déterminé 20 avec l'architecture selon la présente inven- tion. Grâce à cet aspect, le commutateur peut être intégré plus intimement à un environnement en réseau, car l'état des diverses caractéristiques du commutateur téléphonique peut être indiqué à plusieurs utilisateurs et peut être changé par les utilisateurs individuels à la demande. (iii) Support de plusieurs sessions de commutateur téléphonique. L'architecture selon l'invention assure le support de plusieurs sessions pour le seul commutateur 20 à partir de différentes applications 114. De cette manière, plusieurs applications peuvent demander et ajuster diffé- rentes propriétés du commutateur téléphonique simultanément. (iv) Décomptage d'inactivité relatif aux transactions. Un décomptage d'inactivité programmable, avec une valeur par défaut égale à 20 min, est incorporé. Elle permet une termi- naison convenable des sessions inactives ou en attente. (v) Gestion des plans actif et inactif. L'architecture est réalisée pour le support à la fois des plans actif et inactif d'un commutateur téléphonique qui a une seule partition, et seules les sessions d'accès à la base de données du plan actif sont autorisées pour l'écriture des changements dans la base de données 124 du commutateur. (vi) Gestion du commutateur d'activité. Après l'appari- tion d'un commutateur d'activité, toute session établie est interrompue sans raison particulière donnée à l'application 114. (vii) Version de la base de données. Dans l'exemple considéré du commutateur "Mitel" "SX-2000", l'homme du métier peut apporter les modifications permettant la récupé- ration de la version du logiciel à partir des commutateurs de tous les modèles ou tous les fabricants. Dans le mode de réalisation considéré, le mécanisme existant de récupération de la version chargée par l'organe de commande principal de la structure MNMS est utilisé pour les commutateurs "SX-2000". Pour d'autres commutateurs ou modèles, le méca- nisme convenant à la détermination de la version du logiciel chargé peut être utilisé. Une table de la base de données identifie les changements de forme de la base de données pour les différentes versions. (viii) Rétablissement à la suite d'une défaillance. En cas de défaillance, toute transaction en cours est supprimée et l'application 114 est informée de la nature de la défaillance. Il existe un problème lorsque la soumission de transaction a été demandée par l'application 114. Dans ces conditions, la soumission peut avoir donné satisfaction ou non avant la défaillance. Une action supplémentaire peut être nécessaire pour la vérification du succès de l'opé- ration de soumission. Les défaillances particulières suivantes sont gérées: décomptage d'inactivité, commutation d'activité, manque de liaison, piégeage du serveur d'accès à la base de données, perte de message, compatibilité ascendante, désaccord entre les versions. Décomptage d'inactivité. A l'expiration du décomptage d'inactivité de la session, toute transaction en cours est interrompue et la session de l'application est fermée. Commutation d'activité. Lors de la notification du passage du commutateur d'activité de l'état actif à l'état inactif, toute transaction en cours est interrompue. Manque de liaison. En cas de défaillance à la communi- cation, le serveur 116 fait échouer toute transaction en cours et ferme la session établie. Piégeage du serveur d'accès à la base de données. Dans le cas improbable o le serveur 116 rencontre un piégeage dans son exécution, il est recréé et fait échouer toutes les transactions en cours. Perte de message. La couche de liaison existante sup- porte plusieurs retransmissions et l'intégrité des messages. Ces opérations sont réalisées dans les deux sens. (ix) Compatibilité ascendante. Lors de la mise en oeuvre de l'invention, la version d'accès à la base de don- nées équivaut toujours à la version de numéro le plus élevé du logiciel du commutateur 20 auquel elle est connectée ou est supérieure. Les demandes et réponses associées à une version plus ancienne du logiciel du commutateur 20 sont gérées dans le serveur 116. Pour que la communication de la station 10 de gestion au commutateur 20 soit plus facile, la version du serveur 116 doit avoir un numéro supérieur ou égal à celui de la version du commutateur téléphonique 20. Le serveur 116 a une connaissance des divers modèles, versions et révisions du commutateur 20 afin qu'il puisse transformer les commandes et données reçues de l'application 114 en un format qui peut être compris par le commutateur 20. Une compatabilité ascendante est ainsi autorisée. Comme le serveur 116 connaît les divers formats de commande et de données nécessaires à la commande et à la gestion du commutateur 20, il peut transformer, transmettre et omettre des éléments le cas échéant pour le conditionnement des commandes et des réponses actuelles à un format qui peut être compris à la fois par le commutateur 20 et l'application 114. L'un des avantages de cette réalisation est que l'application ne doit pas connaître les changements réalisés par différents modèles, versions ou révisions du commutateur 20. Grâce à la fonction d'enregistrement décrite précédemment, l'application 114 stipule au serveur 116 la version, le modèle et la révision du commutateur qui peut être compris, et le serveur d'accès à la base de données peut exécuter la transformation nécessaire pour présenter à l'application les réponses qu'elle peut attendre. L'application 114 doit être recompilée avec la version du serveur 116 pour assurer la compatibilité. Par exemple, les changement suivants sont supportés par le serveur 116: - addition d'une nouvelle vue ou table, une table ou vue n'est pas prévue dans le commutateur 20 jusqu'à ce que l'application 114 la demande, - suppression d'une ancienne vue, la demande de l'application 114 est rejetée lorsqu'une table ou vue n'est pas supportée par le commutateur 20, - addition d'un nouveau champ (jusqu'à la fin), l'indicateur de présence est incorporé dans le support de la couche de redirection API pour le nouveau champ. Si le champ n'est pas prévu dans le commutateur 20, l'indicateur de présence de ce champ est baissé. Le champ n'est pas transmis à un commutateur d'une version plus ancienne, lors de la transmission par l'application, - addition d'une nouvelle énumération (jusqu'à la fin), la valeur d'énumération étant rejetée par le commutateur lorsqu'elle est transmise par l'application et n'est pas supportée. Désaccord entre les versions Dans le cas o la version du logiciel du commutateur n'est pas reconnue, le commutateur téléphonique n'est pas disponible pour les sessions DBA. Une erreur est aussi renvoyée à l'application 114 par la demande de lancement de session. (e) Serveur de communications de la base de données. Le serveur 152 de communications de la base de données isole le serveur 116 d'accès à la base de données des mécanismes de communication avec le réseau. Il comprend le service 156 de couche de présentation et le tube de communications 122. Cet isolement permet au service 156 et au tube 122 d'être changés sans aucun effet sur le serveur 116 ou les applications 114. Le traitement dans le serveur 152 établit une connexion par prise avec le serveur 116 et écoute aussi les messages provenant de la couche 154 de redirection de communications. Chaque message est traité indépendamment et est soit transmis, soit traité de la manière nécessaire. Les messages sont transmis et reçus de manière asynchrone (sans blocage) à partir du commutateur 20 et du serveur 116. Le serveur 152 a un traitement séparé exécuté dans la station de gestion 10 et agit comme client du serveur 116. Un serveur 152 de communications avec la base de données est utilisé pour chaque commutateur téléphonique 20 par le serveur 116 d'accès à la suite des demandes de l'application 114. La destruction des opérations du serveur 152 est aussi gérée par le serveur 116. Le serveur 152 traite alors la demande et renvoie une réponse de données communes au serveur 116. Ce dernier exécute alors la transformation nécessaire pour assurer la compatibilité ascendante et transfère les résultats sous forme des données communes à la couche 150 de redirection API. Initialisation. Le serveur 152 est associé au serveur 116 par des paramètres de ligne de commande, comprenant l'identité du commutateur téléphonique 20 auquel il est connecté. Un canal de communications est établi avec le commutateur 20 et les informations de version concernant le commutateur sont obtenues. Un gestionnaire de message est alors fixé pour l'écoute de la connexion du tube 122 de communications. A la fin satisfaisante de ces opérations, le serveur 152 s'enregistre dans le serveur 116. Interfaces. Le serveur 152 de communications de la base de données reçoit une demande commune de données du serveur 116. Ce serveur 152 établit alors une identité de session de communication. Le serveur 152 transmet alors la demande commune de données à la couche 154 de redirection de communications et attend une réponse. Lorsqu'une réponse est reçue, la couche 154 transmet une réponse commune de données au serveur 152. Le serveur 152 détermine alors l'identité de la session de communication d'après la réponse et transmet la demande commune de données au serveur 116. Les opérations de prise et les messages au format commun de données sont gérés par le serveur 152 par l'intermédiaire de la prise de service DBA. Les fonctions de la couche 154 de redirection de communications sont utili- sées pour la gestion de la communication avec le commutateur téléphonique 20. MESSAGES GERES PAR LE SERVEUR DE COMMUNICATIONS DE BASE DE DONNEES Il existe deux types de messages qui sont reçus par le serveur de communications de la base de données, les messages provenant du serveur 116 et les messages provenant du commutateur 20. Le serveur de communications reçoit les messages du serveur d'accès à la base de données 116 à un format commun de données et les transmet à la couche 154 de redirection de communications afin qu'ils parviennent au commutateur 20. Le message est alors transformé en un message à un format commun de données et est transmis au serveur 116 pour subir une redirection ultérieure d'après l'identité de la session. Lancement de session. Après réception d'une demande de lancement de session du serveur 116, le numéro de session progresse et la demande est transmise à la couche 154. Après réception d'une réponse à un lancement de session de la couche 154, le client associé est déterminé d'après l'iden- tité de session de communication. Le message est transmis au serveur 116. Fin de session. Une demande de fin de session provenant du serveur 116 est transmise au commutateur téléphonique 20 par la couche 154 et le numéro de session diminue. Dans le cas o aucune session supplémentaire n'est établie avec le commutateur 20, un décomptage est destiné à attendre pendant le temps de maintien de la configuration. Décomptage. L'expiration de la minuterie indique l'écoulement du temps de maintien. Le serveur 152 de commu- nications s'assure qu'une nouvelle session n'est pas établie et déconnecte le commutateur 20 et assure la terminaison. Si une session a été établie, la fin de minutage est supprimée. Gestion d'erreur. Dans le cas o une connexion ne peut pas être établie ou est perdue, la gestion existante d'erreur est utilisée. Les erreurs sévères sont enregis- trées, à l'aide d'un mécanisme existant d'enregistrement de la manière convenable. La connexion par prise au serveur 116 d'accès à la base de données est aussi fermée. 3. INTERFACE ENTRE LA COUCHE D'ACCES A LA BASE DE DONNEES ET LA COUCHE DE TRANSPORT DE DONNEES DANS LA STATION DE GESTION L'interface entre la couche d'accès à la base de données et la couche de transport de données est assurée par les propriétés suivantes: (a) couche 154 de redirection de communications (b) tube 122 de communications et (c) service 156 de la couche de présentation. On décrit plus en détail ces éléments dans la suite. (a) Couche de redirection de communications. La couche 154 de redirection de communications isole le serveur 152 de communications d'accès à la base de données de la réalisation effective du mécanisme de transport spécifique du réseau. La couche 154 réside dans l'environnement de la station de gestion 10 sous forme d'une bibliothèque de fonctions qui compile et lit les programmes. La couche 154 a des fonctions d'utilisation des services du tube de communications. Ces fonctions gèrent l'ouverture et la fermeture de la connexion avec le commutateur 20, et l'échange des messages. Une fonction est aussi prévue pour la demande de la version du logiciel du commutateur 20. La couche de redirection des communications reçoit une demande commune de données du serveur 152 de communications de la base de données. La couche 154 de redirection transforme la demande commune de données en une forme utilisée par le mécanisme de transport de données et transmet la demande au tube 122 de communications. Le tube 122 communique alors la demande au commutateur 20. Lorsqu'une réponse est reçue du commutateur 20, sous forme d'une réponse du mécanisme de transport, le tube 122 transmet la réponse à la couche 154. La couche 154 transforme la réponse en une demande commune de données et transmet cette demande au serveur 152. La couche de redirection de communications transforme les messages du format commun de données reçues du serveur 152 au format voulu du message utilisé par la couche de transport de données pour communiquer avec le commutateur 20. L'invention peut être mise en oeuvre avec n'importe quel mécanisme de transport de données ou format de message, mais, à titre illustratif, on utilise le format de données MNMS utilisé par "Mitel" et le format de données Z.300. Le format Z.300 est une norme internationale bien connue décrite dans le document du CITT volume X, fascicule X, Rec. Z301-Z341. Lorsque l'invention est mise en oeuvre avec un autre mécanisme de transport de données, la couche 154 doit être reprogrammée afin qu'elle accepte les messages dans cet autre format de données pour les transformer au format commun de données utilisé par le serveur 152. Le commutateur téléphonique 20, lorsqu'il reçoit les données, déconditionne celles-ci du format de transport de messages pour leur traitement final. Le commutateur 20 et la station 10 de gestion doivent donc utiliser un mécanisme compatible de transport de messages. Format de données de message MNMS. Le format de données de message MNMS est un exemple de protocole de mécanisme de transport de messages qui peut être utilisé par la couche 154 et le tube 122 de communications pour communiquer avec le commutateur téléphonique 20 par l'intermédiaire du service 156 de couche de présentation. Les messages sont transformés de ce format au format commun de données pour être gérés par le serveur 152. Ces données sont transmises comme structures de données à type au protocole de transport qui assure le transport. Les types de données MNMS ne sont pas un aspect de l'invention, mais on les décrit plus en détail à titre d'information. Le cas échéant, la demande est transformée du format commun de données en un message de protocole de transport et parvient au tube 122. La transformation est aussi appliquée dans le sens inverse. Les messages suivants, ainsi que les données transmises à la couche de redirection de commu- nications, parviennent au tube 122 pour être communiqués au commutateur 20. (i) Transmission d'une demande au format commun de données. L'émission d'une demande au format commun de don- nées transforme le message au format commun de données en message au protocole de transport et le transmet au tube de communications. Un numéro de séquence est utilisé dans le message d'après un identificateur original. (ii) Réception d'une réponse au format commun de données. La réception de la réponse au format commun de données donne un message MNMS provenant du tube 122 de communications et le transforme en un message au format commun de données. Le numéro de séquence du message est utilisé pour la détermination de l'identificateur original. (iii) Connexion au commutateur téléphonique. La connexion au commutateur téléphonique établit un canal de communications avec le commutateur téléphonique spécifié 20. Le nom du commutateur est validé à l'aide de la base de données, et une tentative d'ouverture d'une connexion est exécutée. Si cette tentative initiale donne une défaillance, un nouvel essai est effectué après un retard qui dépend de la raison de la défaillance. Lors d'une connexion satis- faisante, l'identité appliquée est utilisée pour l'enregistrement permettant la réception des messages. (iv) Déconnexion du commutateur téléphonique. La déconnexion de l'élément du réseau ferme un canal existant de communications MNMS avec l'élément spécifié du réseau. (v) Lecture de l'information de version du commu- tateur. La lecture d'information de version du commutateur donne l'information de version du logiciel provenant du commutateur téléphonique. (b) Service de la couche de présentation. Le service 156 de la couche de présentation est une bibliothèque existante de fonctions qui gère la transformation et la conversion entre un format de message ou de transport de données et des représentations spécifiques de données Z.300. Le service 156 est exécuté dans l'environnement de la station de gestion 10 sous forme d'une bibliothèque de fonctions avec laquelle le serveur 152 est compilé et lié. (c) Tube de communications. Le tube 122 de commu- nications est placé dans la couche de transport de données et constitue une opération simultanée existante qui gère les connexions avec des commutateurs téléphoniques individuels. Il existe sous forme d'une bibliothèque de fonctions à l'aide de laquelle le serveur 152 est compilé et lié. Le tube de communications gère les communications avec le commutateur téléphonique connecté 20. Les fonctions sont prévues pour connecter et déconnecter le canal de commu- nications et pour faciliter la circulation de messages. Le format de données Z.300 est utilisé par le tube 122 et la couche existante de transport pour la communication avec le commutateur téléphonique 20 par l'intermédiaire du service 156. L'invention ne dépend pas de ce format de données. D'autres formats de données peuvent être utilisés. ARCHITECTURE A L'INTÉRIEUR DU COMMUTATEUR TÉLÉPHONIQUE On se réfère à la figure 5 pour la description détaillée des propriétés de l'architecture d'un commutateur téléphonique selon l'invention. L'architecture interne du commutateur téléphonique 20 mettant en oeuvre l'invention est dans une grande mesure une reproduction de celle qui existe dans la station de gestion 10 déjà décrite. Les transformations exécutées sont simplement le décondition- nement des informations préparées dans la station de gestion 10. Ainsi, des directives relatives aux opérations exécutées dans le commutateur téléphonique peuvent être tirées des opérations exécutées dans la station de gestion 10, comme décrit précédemment. En résumé, le message transmis par la station de gestion 10 est reçu par le commutateur 20 par l'intermé- diaire de la carte "Ethernet" 112. Le message est alors transféré par le tube 128 de communications au gestionnaire de messages. Ce gestionnaire 180 transforme le message de son format en un format d'enregistrement de demande DBA pour assurer l'interface avec le serveur 118 de la base de données du commutateur. La transformation réalisée par le tube 128 de communications et le gestionnaire 180 de messages est décrite plus en détail dans la suite. Le gestionnaire 180 de messages transforme le message de son format de transport de données en format d'enregistrement de demande DBA si bien qu'il peut être géré par le serveur 118 de la base de données du commutateur. Ce serveur 118 crée alors un serveur 182 de tâches de base de données (un par session). Le serveur 118 transmet alors un enregistrement de demande DBA au serveur 182 afin qu'il subisse un traitement supplémentaire. Le serveur 182 transforme alors l'enregis- trement de demande DBA en un format qui convient à l'acceptation par une application 126 d'accès à la base de données du commutateur et transmet la demande à l'appli- cation 126 pour qu'elle assure le traitement. L'application 126 traite alors la demande par accès à la base de données 124 du commutateur et renvoie le résultat au serveur 182. La réponse est alors transformée par le serveur 182 au format d'enregistrement de demande DBA et l'enregistrement est alors transmis au serveur 118 afin qu'il subisse un traitement supplémentaire. La réponse est alors transmise par le serveur 118 et la couche d'accès à la base de données jusqu'à la couche de transport et au gestionnaire 180 de messages. Ce gestionnaire 180 effectue la transformation du tube de communications 128 et transmet le message transformé au tube 128. Le tube 128 transmet alors le message à la carte "Ethernet" 112 qui assure l'interface avec le réseau local 30 avant renvoi à l'appareil ou à la station de gestion d'origine. 4. INTERFACE ENTRE LA COUCHE DE TRANSPORT DE DONNEES ET LA COUCHE D'ACCES A LA BASE DE DONNEES DANS LE COMMUTATEUR TELEPHONIQUE Les données arrivent du réseau 30 et passent dans la carte "Ethernet" 112 vers le tube de communications 128. Le gestionnaire 180 de messages affecte alors un enregistrement de demande DBA, transforme le format des données reçues au format d'enregistrement de demande DBA, puis transmet ce format d'enregistrement de demande DBA au serveur 118 de base de données du commutateur. Le serveur 118, qui reçoit cet enregistrement, affecte desressources pour le service des données et transmet les données de service par l'interface au gestionnaire 180. Le gestionnaire 180 transforme alors les enregistrements de demande DBA au format convenant au tube 128 de communications et transmet les données formatées au tube 128 pour assurer leur transport. Le gestionnaire de messages désaffecte aussi l'espace de l'enregistrement de demande DBA le cas échéant. Il existe trois aspects de l'interface placée entre la couche de transport de données et la couche d'accès à la base de données dans le commutateur téléphonique 20: (a) tube de communications (b) gestionnaire de messages, (c) enregistrement de demande d'accès à la base de données. Les aspects suivants de l'interface entre la couche de transport de données et la couche d'accès à la base de données dans le commutateur téléphonique 20 sont maintenant décrits plus en détail. (a) Tube de communications. Le tube 128 de communi- cations est responsable de la gestion de l'entrée-sortie des données pour un mécanisme particulier de transport. Le tube 128 déconditionne les données préparées dans le tube de communications et le mécanisme de la station 10 de gestion. Dans un mode de réalisation préféré, le tube "OPSMAN MNMS" est décrit à titre illustratif, bien que d'autres mécanismes de transport de données puissent être utilisés. Le tube 128 est responsable de la transformation du format des données de la couche de transport Z.300 avec le format de données MNMS et les transmet au gestionnaire 180. Le tube 128 transforme alors le message en enregistrement de demande DBA utilisé par le serveur 118 et les serveurs 182 de tâches de base de données. Il analyse les données de texte en les mettant en structure de ligne en langage "Pascal". (b) Gestionnaire de messages. Chaque gestionnaire de messages 180 est identifié par une identité originale. De nouvelles identités de gestionnaire sont ajoutées le cas échéant. Lorsqu'un gestionnaire de messages est initialisé, habituellement au lancement du système, il doit s'enregis- trer dans le serveur 118 de base de données de commutateur afin de pouvoir transmettre des messages d'accès à la base de données. L'opération d'enregistrement comprend l'identi- fication d'une fonction de rappel exécutée avec le serveur 118 pour le gestionnaire 180. Le serveur 118 utilise la fonction de rappel pour envoyer les résultats d'accès à la base de données au gestionnaire 180. Le fonctionnement de l'interface placée entre le ges- tionnaire 180 de messages et le serveur 118 est le suivant. Le gestionnaire 180 transmet l'enregistrement de demande DBA au serveur 118. Le serveur 118 crée le serveur 182 de tâches de base de données et utilise des références croisées de sa table de ressources pour transmettre les messages au nouveau serveur 182 de tâches de base de données lorsqu'une nouvelle session est nécessaire. Dans une variante, si une nouvelle session n'est pas nécessaire, le serveur 118 transmet simplement le message par le serveur existant 182. Ce serveur 182 reçoit l'enregistrement de demande d'accès à la base de données qui dessert la demande. Lorsque la demande a été desservie, le serveur 182 renvoie les données de service au serveur 118. Après réception, le serveur 118 transmet les données de service à l'interface avec le gestionnaire 180 de messages d'après la table des ressources. Le gestionnaire 180 de messages est divisé en un traitement d'entrée et un traitement de sortie. Le traite- ment d'entrée est lié au tube de communications et écoute un message provenant de la station de gestion 10. Lorsqu'un message est reçu par le tube 128, le gestionnaire 180 obtient un enregistrement de demande DBA d'un ensemble d'enregistrement de demande DBA, analyse les données de texte, remplit l'enregistrement de demande DBA et transmet un message de demande DBA au serveur 118. La fonction de rappel destinée au gestionnaire 180 de messages est un sous-programme qui transmet un message de réponse au gestionnaire 180. L'opération de sortie écoute un message de réponse provenant du serveur 118. Les données de message contiennent l'index d'une ressource d'enregistrement de demande DBA. Le gestionnaire 180 transforme les données au format destiné au tube de communications 128 et transmet le message à la station de gestion. Pour la transformation des messages au format d'enre- gistrement de demande de la base de données, le gestionnaire obtient une ressource d'enregistrement de demande DBA de l'ensemble des enregistrements de demande DBA. Les parties de texte de ligne du message sont analysées et copiées dans l'enregistrement de demande DBA. Un message est alors transmis au serveur 118 avec l'index de ressource incorporé au message. Eventuellement, le gestionnaire de messages 180 peut enregistrer certaines informations du message reçu dans un enregistrement de transport. Cet enregistrement de transport est obtenu dans une liste libre gérée par l'ensemble des ressources. L'enregistrement contient les informations nécessaires au traitement de sortie du gestionnaire, mais il ne peut pas être transporté dans l'enregistrement de demande DBA. Un champ de l'enregistrement de demande DBA est utilisé pour l'enregistrement du numéro de ressource de l'enregis- trement de transport. Le numéro de séquence du message du gestionnaire de messages est enregistré dans l'enregis- trement de transport et la ressource d'enregistrement de transport est conservée dans l'enregistrement de demande DBA. Lorsqu'un message est reçu du tube de communications, le gestionnaire 180 détermine quel message est transmis et effectue les opérations suivantes sur les données de message: obtention d'une ressource d'enregistrement de demande DBA, analyse des données de texte de clé ou de ligne pour l'insertion dans l'enregistrement de demande DBA, 25. analyse des données de texte de l'ensemble de vues afin qu'elles soient introduites dans l'enregistrement de demande DBA, analyse des données de masque de ligne destinées à être introduites dans l'enregistrement de demande DBA, 30. remplissage de l'enregistrement de demande DBA par les données analysées, obtention d'une ressource d'enregistrement de trans- port dans l'ensemble d'enregistrement de transport, remplissage de l'enregistrement de transport et la mémorisation du numéro de ressource dans l'enregistrement de demande DBA, et émission d'un message au serveur 118 de base de données de commutateur par l'index de ressource des données de message. Les actions de soumission et de suppression de tran- saction nécessitent un paramètre contenant une identité de session. L'action de début de transaction nécessite un paramètre qui contient une identité de session et les informations de jeu de vues. Le gestionnaire 180 de messages reçoit les messages de réponse d'accès à la base de données du serveur 118 en fonction des messages de demande d'accès à la base de données. Ces messages de réponse contiennent des numéros de ressource pour les ressources d'enregistrement de demande DBA. La même ressource affectée lorsque la demande est arrivée initialement de la station de gestion 10 est utilisée. Le gestionnaire 180 transforme alors les données de ligne contenues dans les enregistrements de demande DBA au format des messages du tube de communications. Il transmet alors le message au tube 128 de communications. La ressource d'enregistrement de demande DBA est alors rendue à l'ensemble des ressources. Lorsque le serveur 118 de base de données du commuta- teur est prêt à renvoyer une réponse au gestionnaire 180, il transmet l'index d'un enregistrement de demande DBA pour lire les données du message. * (c) Format d'enregistrement de demande DBA. L'appari- tion d'un enregistrement de demande DBA permet au serveur 118 de base de données de commutateur de ne plus se référer à une représentation de données particulières du tube de communications. De cette manière, un nouveau tube de commu- nications et un nouveau procédé de support des connexions à différentes natures de commutateur peuvent être ajoutés sans qu'il soit nécessaire de modifier le serveur 118. Tout tube 128 de communications peut être utilisé du moment qu'il peut transférer les données au gestionnaire 180. Ce gestionnaire nécessite alors une modification évidente pour l'homme du métier afin qu'il reçoive les données et les transforme au format d'enregistrement de demande d'accès à la base de données. L'enregistrement de demande DBA contient toutes les informations de ligne, de vue, d'ensemble de vues et autres nécessaires pour l'accès à la base de données 124 du commutateur. Alors que la plupart des informations proviennent de l'application 114 et de la couche d'accès à la base de données de la station de gestion 10, certaines informations sont remplies par le gestionnaire 180 de messages. Les résultats de l'accès à la base de données sont aussi conservés dans cette structure. dba_request_recordtype = RECORD dba session id: dba session id type; dbaactioncode: dbserveraction_codetype; dba view id: view identifier; dbaoldtuple: viewtuple; dbaviewtuple: viewtuple; dba viewset: view identifierset; dba_tuplemask: tuple_string_type; dba_errorref: db_error_msg_reference; dba_transport_hdlrid: dba_transport id_type; transport_hdlr_resource: resource_range; {OPTIONAL} ENDREC Un enregistrement de ce type est affecté à la demande d'accès à la base de données et revient à l'ensemble des ressources lorsque la demande a été terminée. dbasession id. L'identité de session est affectée par le serveur 118 lorsqu'une demande de lancement de session est reçue. dbaaction code. Ce champ est rempli par le gestion de message 180 afin qu'il indique l'action demandée par l'application 114. dbaviewid. Ce champ est rempli par le gestionnaire 180 à partir des données fournies par l'application. Il s'agit de l'identité de la vue sur laquelle l'action est exécutée. dba_old-tuple. Ce champ est rempli par le gestionnaire 180 avec des données provenant de l'application 114, ce champ n'est nécessaire que pour l'action de modification d'une ligne. 5. dbaviewtuple. Ce champ est un champ d'entrée et de sortie. Il est rempli par le gestionnaire 180 par des données provenant de l'application 114 pour l'écriture dans la base de données et il est rempli par le serveur 118 par les résultats d'une action demandée. 10. dbaview_set. Ce champ est rempli par le gestionnaire par les données provenant de l'application 114. dba_tuple_mask. Ce champ est rempli par le gestion- naire 180 à l'aide de données provenant de l'application 11. Il n'est utilisé que pour les actions de recherche d'accès à la base de données. Il constitue le masque qui décrit les critères de recherche des lignes. dbaerror ref. Ce champ est rempli par le serveur 118 de la base de données afin qu'il indique les conditions éventuelles d'erreur provenant de la demande d'accès à la base de données. dba_transport_hdlrid. Ce champ est rempli par le gestionnaire 180 par l'identité originale du gestionnaire 180. Cette valeur est utilisée ultérieurement pour la fonc- tion de rappel destinée au gestionnaire 180. 25. transport_hdlrresource. Ce champ est éventuel, il peut être utilisé par le gestionnaire 180 pour enregistrer l'identité d'une ressource à partir de la ressource qui est nécessaire en plus des données conservées dans l'enregis- trement de demande DBA. Ainsi, le gestionnaire 180 peut superposer les données à l'enregistrement de demande DBA. Pour d'autres détails relatifs aux informations gérées par l'enregistrement de demande DBA, on peut se référer au chapitre relatif au format commun de données considéré précédemment. 5. COUCHE D'ACCES A LA BASE DE DONNEES INCORPOREE AU COMMU- TATEUR TELEPHONIQUE Le serveur 118 de la base de données du commutateur constitue le foyer de déplacement des demandes dans le commutateur. Il reçoit les demandes d'accès de la base de données des divers gestionnaires au format d'enregistrement de demande DBA, il affecte les ressources pour le service de la demande, et il renvoie les données obtenues aux gestion- naires de messages. Le serveur d'accès de base de données crée un nouveau serveur 182 de tâche de base de données chaque fois qu'un message de lancement de session est reçu à partir du gestionnaire 180. Pour tous les autres types de messages, il examine l'identité de la session pour identifier un serveur existant de tâche de base de données auquel transmettre le message. Le serveur 118 garde une table de ressources qui garde trace des gestionnaires qui communiquent avec ces serveurs 182. Le serveur 118 valide l'identité de session et transmet les messages au serveur 182 identifié par l'identité de session. Le serveur 118 de base de données de commutateur reçoit des messages de demande d'accès à la base de données et des messages de minuterie d'inactivité, et il peut transmettre un message de réponse d'accès à la base de données. Le serveur 118 de base de données de commutateur est constitué d'un traitement permanent habituellement créé au lancement du système. Lorsqu'un gestionnaire 180 de messages a reçu une demande d'accès à la base de données, il transmet au serveur 118 un message d'accès à la base de données après avoir préparé les données demandées au format d'enregistrement d'accès à la base de données. Les données de message contiennent un numéro de ressource correspondant à une structure de données d'accès à la base de données affectée par le gestionnaire. Le serveur 118 examine la structure des données pour déterminer l'action à exécuter. Il existe deux articles, l'identité de le session et l'action de la base de données. Si l'identité de la session est vide et l'action de la base de données est "lancement de session", le serveur 118 affecte un traitement de tâche de base de données dans un ensemble de processus et transmet le message d'accès à la base de données au processus correspondant à la tâche suivante. Si l'identité de session n'est pas vide, le serveur vérifie que cette identité contient l'identité du système nécessaire au commutateur, et que l'identité du traitement est celle d'un processus existant 182 de tâche de base de données. Lorsque toutes les vérifications ont donné un résultat convenable, le message d'accès à la base de données est transmis à l'opération de tâche 182. Enfin, la table de références croisées est remise à jour avec l'identité de la session et l'identité du gestionnaire. Lorsque le serveur 118 reçoit un message d'accès à la base de données du serveur 182, il transmet le message à un gestionnaire convenable 180 par vérification de la table des références croisées. 6. INTERFACE ENTRE LA COUCHE D'ACCES A LA BASE DE DONNEES ET LE COUCHE D'APPLICATION DANS LE COMMUTATEUR TELEPHONIQUE Le serveur de tâche reçoit les commandes fondamentales transmises à l'origine par l'application 114 et les trans- forme en un format qui peut être transmis à l'application 126 d'accès à la base de données du commutateur et exécuté par cette application. La transformation exacte qui doit être réalisée dépend des propriétés de l'application ainsi que du fabricant, du modèle et de la version exacts du commutateur téléphonique 20. La transformation nécessaire pour l'exécution peut être réalisée par tout homme du métier connaissant la programmation des commutateurs télépho- niques 20. Le serveur de tâche 182 est destiné à traiter les demandes d'accès à la base de données. Il est créé lorsque le serveur 118 de base de données de commutateur reçoit un message de lancement de session et se termine lors de la réception d'un message de fin de session. Initialisation. Le traitement par le serveur de tâche est créé par le serveur 118 de base de données de commuta- teur à chaque session et constitue un traitement permanent. Il est responsable de l'affectation d'une identité de session au moment du lancement de la session et des demandes ultérieures de traitement pour cette identité de session. Le serveur 182 affecte une identité de session lorsqu'il reçoit une demande de lancement de session dans un message de demande d'accès à la base de données. L'identité de session contient l'identité de processus du serveur 182, l'identité du système du commutateur et l'identité du plan. L'identité de session est renvoyée au serveur 118 dans un message de réponse d'accès à la base de données. La première tâche exécutée par le serveur 182 est l'affectation d'une identité de session et son renvoi au serveur de la base de données. Toutes les demandes ulté- rieures d'accès à la base de données sont vérifiées d'après l'identité de session par le serveur 118. Le serveur 182 exécute des vérifications supplémentaires sur la partie d'identification de processus de l'identité de la session. Le serveur 182 reçoit un enregistrement de demande d'accès à la base de données qui contient toutes les données nécessaires pour l'exécution de l'action demandée. Il appelle les fonctions convenables (par exemple les fonctions DBVIEW "Mitel") pour l'exécution de l'action et place les résultats obtenus dans l'enregistrement de demande DBA. Les réponses et données résultantes sont renvoyées au serveur 118 qui les transmet au gestionnaire convenable 180 de messages. Un traitement par le serveur 182 de tâche est affecté à chaque session. Le serveur 182 de tâche de base de données supporte les fonctions suivantes. (i) Identification d'erreur Lit texte d'erreur (ii) Fonctions de service de session Lancement de session 30. Terminaison de session (iii) Fonctions de service de transformation (gestion de transformation) Lancement de transaction Soumission de transaction 35. Suppression de transaction (iv) Lit les demandes "premier-suivant" Lit première ligne Lit ligne suivante (v) Demandes de lecture-écriture Lit ligne Ajoute ligne Supprime ligne 5. Modifie ligne Ces fonctions constituent l'interface API et corres- pondent aux appels des fonctions effectués par l'application 114 exécutée sur la station de gestion 10. Le serveur 182 transforme alors la demande en une forme particulière et la transmet à l'application 126 d'accès à la base de données du commutateur. (i) Identification d'erreur (ii) Fonctions de service de session. Le serveur 182 exécute les deux fonctions de service de lancement et de fin de session. Lancement de session. Le serveur 182 affecte une identité de session. Fin de session. Le serveur 182 vérifie que l'iden- tité de session est convenable et vérifie qu'aucune transaction n'est en cours. Si une transaction est en cours, un message d'erreur est renvoyé et indique que la tran- saction doit être soumise ou supprimée avant que la session ne puisse se termine. Lorsqu'aucune transaction n'est active, le serveur 182 transmet simplement un message de réponse dba_reply indiquant l'absence d'erreur. (iii) Fonctions de service de transaction (gestion de transaction). Le serveur 182 exécute les trois fonctions de transaction, lancement, soumission et suppression. (a) Lancement de transaction. Lorsque le serveur de tâche reçoit une demande de lancement de transaction, il examine l'enregistrement de demande DBA pour lire les paramètres textuels d'ensemble de vues. Le texte est transmis à un analyseur de texte d'ensemble de vues. Lorsqu'il est mis en oeuvre dans le commutateur "SX-2000", l'ensemble résultant de vues est ouvert pour l'accès en écriture par le serveur 182 par appel de la fonction DBVIEW openview_set. Les vues sont ouvertes et verrouillées. Le succès ou l'absence de succès de l'opération d'ouverture est enregistré dans l'enregistrement de demande DBA et le serveur 182 transmet un message de réponse à l'accès à la base de données au serveur 118, indiquant la ressource de l'enregistrement de demande DBA. (b) Soumission de transaction. Lorsque le serveur de tâche reçoit une demande de soumission de transaction, il transforme et transmet la demande à l'application 126 d'accès à la base de données du commutateur. Par exemple, dans le cas d'un commutateur "Mitel" "SX-2000", il appelle la fonction DBVIEW close_view_set à partir du paramètre db_mode qui est mis sous la forme dbcommit. Les changements des tables sous-jacentes de la base de données de l'ensemble de vues ouvert sont transmis au dispositif d'entraînement du disque dur et l'ensemble de vues est fermé et déverrouillé. Le succès ou l'absence de succès de l'opération de soumission est enregistré dans l'enregistrement de demande DBA, et le serveur 182 transmet un message de réponse d'accès à la base de données au serveur de base de données du commutateur, indiquant une ressource d'enregistrement de demande DBA. (c) Suppression de transaction. Lorsque le serveur de tâche 182 reçoit une demande de suppression de transac- tion, il transforme et transmet la demande à l'application 126. Par exemple, dans le cas d'un commutateur "Mitel" "SX-2000", il appelle la fonction DBVIEW closeviewset avec le paramètre dbmode mis à dbabort. Les changements dans les tables sous-jacentes de la base de données pour l'ensemble de vues qui est ouvert sont rétablis à partir du dispositif d'entraînement du disque dur et l'ensemble des vues est fermé et déverrouillé. Le succès ou l'absence de succès de l'opération de suppression est enregistré dans l'enregistrement de demande DBA, et le serveur de tâche 182 transmet un message de réponse d'accès à la base de données au serveur 118, indiquant une ressource d'enregistrement de demande DBA. (iv) Demande de lecture de "premier-dernier" Le serveur 182 de tâche de base de données exécute les fonctions sur les vues de données. (a) Lit première ligne. Lorsque le serveur 182 reçoit une demande de lecture de la première ligne, il exa- mine l'enregistrement de demande DBA pour obtenir l'identité de la vue. Cette identité est transmise à l'application 126. Par exemple, dans le cas d'un commutateur "Mitel" "SX-2000", il appelle la fonction DBVIEW firstview_key. La première clé pour l'identité de la vue spécifiée est renvoyée et le serveur 182 transmet la clé à la fonction DBVIEW read_view_tuple. Le contenu de la ligne ou les codes résultant d'erreur sont conservés dans l'enregistrement de demande DBA. Le serveur 182 transmet alors un message de réponse à l'accès à la base de données au serveur 118, indiquant la ressource d'enregistrement de demande DBA. (b) Lire ligne suivante. Lorsque le serveur 182 reçoit une demande de lecture de la ligne suivante, il examine l'enregistrement de demande DBA pour obtenir l'identité de la vue et le paramètre textuel de ligne de la vue. Le texte est transmis par un analyseur de texte de ligne de vue. Les données de la clé sont extraites des données de la ligne et la demande est transformée et transmise à l'application 126. Par exemple, dans le cas d'un commutateur "Mitel" "SX-2000", la fonction DBVIEW nextview_key est appelée avec les données de clé. La clé suivante pour l'identité spécifiée de vue est renvoyée et le serveur 182 passe la nouvelle clé à la fonction DBVIEW readviewtuple. Le contenu de la ligne ou les codes résultant d'erreur sont conservés dans l'enregistrement de demande DBA. Le serveur 182 transmet alors un message de réponse à la suite de l'accès à la base de données au serveur 118, indiquant la ressource d'enregistrement de demande DBA. (v) Demandes de lecture-écriture (a) Lecture de ligne. Lorsque le serveur 182 reçoit une demande de lecture de ligne, il examine l'enregistrement de demande DBA pour obtenir l'identité de la vue et le paramètre textuel de la ligne de la vue. Le texte est transmis par un analyseur de texte de ligne de vue. Les données de clé sont extraites des données de ligne et le serveur de tâche de base de données transforme et transmet la demande à l'application 126. Par exemple, dans le cas d'un commutateur "Mitel "SX-2000", la fonction DBVIEW read_viewtuple est appelée avec les données de clé et de ligne. Le contenu de la ligne ou les codes résultant d'erreur éventuelle sont conservés dans l'enregistrement de demande DBA. Le serveur 182 transmet alors un message de réponse à l'accès à la base de données au serveur 118, indiquant la ressource d'enregistrement de demande DBA. (b) Addition de ligne. Lorsque le serveur 182 reçoit une demande d'addition d'une ligne, il examine l'enregistrement de demande DBA pour obtenir l'identité de la vue et le paramètre textuel de la ligne de vue. Les données de clé sont extraites des données de la ligne et la demande est transformée et transmise à l'application 126. Par exemple, dans le cas d'un commutateur "Mitel "SX-2000", la fonction DBVIEW writeviewtuple est appelée avec les données de clé et de ligne des paramètres. Les codes éventuels d'erreur sont conservés dans l'enregistrement de demande DBA. Le serveur 182 transmet alors un message de réponse à l'accès à la base de données au serveur 118, indiquant la ressource d'enregistrement de demande DBA. (c) Suppression de ligne. Lorsque le serveur 182 reçoit une demande de suppression de ligne, il examine l'enregistrement de demande DBA pour obtenir l'identité de la vue et le paramètre textuel de la ligne de la vue. Les données de clé sont extraites des données de ligne et la demande est transformée et transmise à l'application 126. Par exemple, dans le cas d'un commutateur "Mitel" "SX-2000", la fonction convenable DBVIEW est appelée. Les codes résultant d'erreur éventuelle sont conservés dans l'enregis- trement de demande DBA. Le serveur 182 les transmet sous forme d'un message de réponse à l'accès à la base de données au serveur 118, indiquant la ressource d'enregistrement de demande DBA. (d) Modification de ligne. Lorsque le serveur 182 reçoit une demande de modification de ligne, il examine l'enregistrement de demande DBA pour obtenir l'identité de la vue et les paramètres textuels de ligne de la vue. Dans ce cas, il existe des paramètres anciens et des paramètres nouveaux de ligne. Il compare les clés et appelle la fonc- tion convenable parmi les fonctions DBVIEW write_view_tuple, replace_view_tuple et delete_view_tuple le cas échéant. Un code éventuel d'erreur est conservé dans l'enregistrement de demande DBA. Le serveur 182 transmet alors un message de réponse d'accès à la base de données au serveur 118, indiquant la ressource de l'enregistrement de demande DBA. Bien entendu, diverses modifications peuvent être apportées par l'homme de l'art aux configurateur et procédé qui viennent d'être décrits uniquement à titre d'exemple non limitatif sans sortir du cadre de l'invention. REVENDICATIONS 1. Configurateur de commutateur téléphonique destiné à gérer et commander au moins un commutateur téléphonique (20) à partir d'un dispositif (10) de réseau, le commutateur téléphonique (20) contenant un support de mémorisation qui peut être lu et écrit pour la mémorisation d'une confi- guration du commutateur téléphonique (20) et qui peut être accessible à partir d'un réseau (30) d'ordinateur par l'intermédiaire d'un premier gestionnaire (128) de protocole de transport de données, le dispositif (10) de réseau commu- niquant avec le réseau (30) par un second gestionnaire (122) de protocole de transport de données, le configurateur étant caractérisé en ce qu'il comprend: (a) un générateur de commandes placé dans le dispositif (10) de réseau et qui transmet les commandes à exécuter par le commutateur téléphonique (20), (b) un premier serveur (116) d'accès incorporé au dispositif (10) de réseau et destiné à gérer une connexion au commutateur téléphonique (20), (c) une première interface (115) placée entre le générateur de commandes et le premier serveur (116) d'accès et destinée à transformer les commandes entre le générateur de commandes et le premier serveur (116) d'accès, (d) une seconde interface (117) placée entre le premier serveur (116) d'accès et le gestionnaire (128) de protocole de transport de données pour la transformation des commandes entre le premier serveur (116) d'accès et le gestionnaire (128) de protocole de transport de données, (e) un second serveur (118) d'accès incorporé au commutateur téléphonique (20) et destiné à gérer une connexion au dispositif (10) de réseau, (f) une troisième interface (121) placée entre le second serveur (118) d'accès et le second gestionnaire (122) de protocole de transport de données pour la transformation des commandes entre le second gestionnaire (122) de transport de données et le second serveur (118) d'accès, (g) un organe d'exécution de commandes incorporé au commutateur téléphonique (20) et qui exécute les commandes pour changer la configuration du commutateur téléphonique (20), et (h) une quatrième interface (123) placée entre le second serveur (118) d'accès et l'organe d'exécution de commandes afin qu'elle transforme les commandes entre le second serveur (118) d'accès et l'organe d'exécution des commandes. 2. Configurateur selon la revendication 1, caractérisé en ce que la première application est un système de gestion de base de données, une application d'accès à la base de données et une interface d'utilisateur. 3. Configurateur selon la revendication 2, caractérisé en ce que l'application d'accès à la base de données est composée de tables de base de données ayant une structure de base de données identique à celle du commutateur téléphonique (20). 4. Configurateur selon la revendication 3, caractérisé en ce que le premier serveur (116) d'accès entretient des connexions simultanément avec plusieurs commutateurs téléphoniques (20). 5. Configurateur selon la revendication 3, caractérisé en ce que le commutateur téléphonique (20) a une version différente de celle du configurateur. 6. Procédé de gestion et de commande d'un commutateur téléphonique à partir d'un dispositif (10) de réseau, le commutateur téléphonique (20) communiquant avec un réseau (30) d'ordinateur par un protocole de transport de données, le dispositif (10) de réseau communiquant avec le réseau (30) par le protocole de transport de données, caractérisé en ce qu'il comprend les étapes suivantes: a) le lancement d'une commande de connexion d'un commutateur téléphonique (20) choisi à partir du dispositif (10) de réseau, b) la transformation de la commande en un format compris par un premier serveur (116) d'accès, c) la transmission de la commande au premier serveur (116) d'accès, d) l'ouverture d'un canal de communications avec le commutateur téléphonique (20) choisi, e) le conditionnement de la commande afin qu'elle soit transportée à l'aide du protocole de transport de données, f) la transmission de la commande au mécanisme à protocole de transport de données, g) le transport de la commande par le réseau (30) au commutateur téléphonique spécifié (20) à l'aide du protocole de transport de données, h) le déconditionnement de la commande reçue par le commutateur téléphonique (20) à l'aide du mécanisme à protocole de transport de données, i) la transmission de la commande à un second serveur (118) d'accès, j) la transformation de la commande en une forme qui peut être exécutée par le commutateur téléphonique (20), et k) l'exécution de la commande sur le commutateur téléphonique (20) pour le changement de la configuration du commutateur téléphonique (20). 7. Procédé de configuration d'un réseau de commutateurs téléphoniques à partir d'un dispositif (10) de réseau, les commutateurs téléphoniques (20) communiquant avec un réseau (30) d'ordinateur par un protocole de transport de données et le dispositif (10) de réseau communiquant avec le réseau (30) par l'intermédiaire du protocole de transport de données, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes: a) le lancement d'une commande de connexion d'un pre- mier commutateur téléphonique (20) à partir d'un dispositif (10) de réseau, b) le téléchargement d'informations de configuration du premier commutateur téléphonique (20) au dispositif (10) de réseau, c) le lancement d'une commande de connexion d'un second commutateur téléphonique choisi (20) au dispositif (10) de réseau, et d) le téléchargement des informations du dispositif (10) de réseau au second commutateur téléphonique choisi (20).