Brevet FR2816416A1 — publié le 20020510

Titre Procédé d'obtention de données par lots. Domaine technique. L'invention concerne un procédé d'obtention de données par lots au moyen d'un système informatique. Elle s'applique aux données accessibles par un premier protocole permettant l'obtention de données par lots mais qui ne peuvent être obtenues qu'en utilisant un second protocole selon lequel les données sont demandées en une seule fois et peuvent recevoir l'application d'un filtre. Le type ainsi défini de second protocole n'est pas adapté à l'obtention de données par lots. Parmi ce type de protocole est le protocole CMIP (Common Management Information Protocol) reposant sur la norme ISO définissant des services pour le transfert des informations d'administration, appelés services OMIS (Common Management Information Services). Le premier protocole peut permettre directement ou implicitement le traitement de données par lots, comme c'est le cas par exemple du protocole de type HTTP (HyperText Transfert Protocol) mis en oeuvre dans le modèle commun d'informations CIM (Common Information model). Ce modèle normalisé est défini par le consortium DMTF (Desktop Management Task Force). Le protocole mis en oeuvre se conforme au langage XML (Extensible Markup Language) élaboré par le groupe de travail ERB (Editorial Review Board) du consortium W3C (World Wide Web Consortium) et se nomme protocole CIMXML/HTTP. Le premier protocole peut permettre aussi indirectement le traitement de données par lots, comme c'est le cas par exemple du protocole SNMP (Simple Network Management Protocol). Ce protocole est du type selon lequel les données sont demandées et obtenues paquet par paquet. Les paquets correspondent à des requêtes respectives successivement faites et à leurs réponses. L'expression paquet par paquet signifie donc que les données désirées sont définies dans une requête, qui est décomposée en sous-requêtes successives pour demander une à une les données dans des paquets respectifs et obtenir une à une les données dans des paquets respectifs constituant les réponses aux sous-requêtes. De ce fait, il est possible de faire avec un tel protocole du traitement de données par lots. L'invention a aussi pour objet un système informatique mettant en oeuvre le procédé de l'invention, et en particulier un système d'administration d'au moins une ressource informatique, telle que celles disponibles dans un système d'information et pouvant être une ressource de système, de réseau et/ou d'application. Elle a aussi pour objets un programme d'ordinateur pour la mise en oeuvre du procédé de l'invention et un support d'enregistrement du programme, tel qu'un cédérom. L'art antérieur. L'administration de systèmes, réseaux et applications informatiques peut utiliser plusieurs types de protocoles. Différents types peuvent être utilisés par un même système d'administration et poser des problèmes à cause de fonctions fournies par certains types et non utilisables ou transmissibles par d'autres. Par exemple, le protocole SNMP est très répandu sur le marché. Il utilise des interfaces connues sous le nom d'agents SNMP. Ils contiennent des tables de plus en plus grandes, pouvant contenir des milliers d'entrées. Dans ce cas, ces entrées forment les données que l'on veut obtenir par lots. Un lot est constitué d'un nombre quelconque de paquets de données. L'obtention se fait par une commande de type générique GET, appelée GETNEXT pour un protocole de type SNMP. Cette commande demande les données paquet par paquet et l'obtention des données a aussi lieu paquet par paquet. L'obtention peut se faire par lots successifs, en triant les données de façon que chaque lot contienne une partie désirée plus ou moins grande d'une table, une centaine par exemple. Les lots récupérés peuvent être traités séparément et successivement, par exemple pour afficher les données qu'ils contiennent. On peut ainsi demander les cent premières entrées, mémoriser la dernière parce que le protocole SNMP ne mémorise pas les requêtes précédentes, et demander la seconde centaine qui suit le dernier numéro, et ainsi de suite. L'utilisateur peut ainsi à son gré choisir la taille de chaque lot, exploiter les données obtenues et arrêter l'obtention des données par lots. D'autre part, le protocole CMIP est aussi très répandu dans le domaine de l'administration. L'obtention des données par l'intermédiaire d'une interface CMIS se fait par une commande de type générique GET et appelée GET CMIS. Elle offre à l'utilisateur l'avantage de pouvoir filtrer les données et sélectionner les niveaux des données au moyen d'une portée (scope). Cependant, selon ce protocole les données sont demandées en une seule fois et obtenues paquet par paquet. Par conséquent, un utilisateur direct de ce protocole ne peut pas obtenir les données par lots. Ce problème est particulièrement pénalisant lorsque les données sont issues d'un protocole qui permet l'obtention de données par lots mais qui sont gérées par un protocole ne le permettant pas. L'utilisateur sait qu'il dispose d'une fonction très avantageuse mais qu'il ne peut pas s'en servir pour trier les données de façon à les obtenir par lots. Or, les protocoles SNMP et CMIP sont courants et sont fréquemment utilisés dans un même système d'administration. Le problème est donc fréquent. Un des principaux inconvénients de ne pas pouvoir obtenir les données par lots se présente lorsque les résultats d'une requête sont imprévisibles. On suppose par exemple qu'un utilisateur d'une grande base de données accessible par le protocole SNMP interroge par l'intermédiaire du protocole CMIP pour connaître un état donné imprévisible, pour avoir seulement un aperçu de l'impact de l'état demandé dans la base ou une valeur indicative. Si le résultat contient un très grand nombre de réponses, des milliers par exemple, l'utilisateur reçoit paquet par paquet l'ensemble des réponses. Le temps de traitement de la requête et de la réponse diminue fortement les performances du système d'administration. En tel cas, l'analyse de toutes les réponses demande plus de temps que de recommencer une requête mieux ciblée et plus sélective, mais qui s'ajoute à celle déjà faite. En outre, les résultats obtenus n'ont aucune utilité en tant que tels et font perdre du temps à l'utilisateur. Sommaire de l'invention. Un premier but de l'invention est de présenter un procédé d'obtention de données par lots en utilisant un protocole non adapté au tri de données par lots mais ayant accès à un protocole permettant le tri des données par lots. Un second but est de pouvoir sélectionner le nombre de réponses à partir d'une valeur quelconque désirée. Un troisième but est d'avoir sur demande ou automatiquement dans le lot demandé les numéros d'ordre des réponses à une requête. Un quatrième but est d'avoir un procédé efficace et fiable et dont la mise en oeuvre est simple et peu coûteuse. L'invention a pour objet un procédé d'obtention, dans un système informatique incluant au moins un processeur et des moyens de mémoire, d'un lot comprenant au moins une donnée accessible dans les moyens de mémoire par un premier protocole permettant un traitement par lot, le procédé étant caractérisé en ce qu'il se fait par l'intermédiaire d'un second protocole, du type selon lequel les données sont demandées en une seule fois et peuvent recevoir l'application d'un filtre, et en ce qu'il comprend la définition d'un attribut contenu dans les moyens de mémoire et relatif à chaque donnée accessible par le premier protocole et l'émission d'une requête faite selon le second protocole et demandant en réponse le lot, le filtre de la requête incluant au moins une condition ( =) sur une valeur respective de l'attribut. L'invention a pour objet corollaire un système comprenant au moins un processeur, des moyens de mémoire contenant des données accessibles par un premier protocole permettant un traitement par lot et un moyen lanceur de requêtes selon un second protocole, du type selon lequel les données sont demandées en une seule fois et peuvent être filtrées, caractérisé en ce qu'il met en oeuvre le procédé défini précédemment. Le système informatique peut être un système d'administration selon le second protocole pour l'administration d'au moins une ressource incluant lesdites données accessibles selon le premier protocole. Présentation des dessins. * La figure 1 est une vue synoptique d'un exemple de système d'administration d'au moins une ressource, en l'occurrence un système d'information, le système d'administration mettant en oeuvre un exemple de procédé conforme à l'invention d'obtention de données par lots. 'La figure 2 est un diagramme illustrant de façon synoptique et partielle un exemple de base d'informations d'administration mis en oeuvre par le système d'administration représenté sur la figure 1. gi, Et la figure 3 est un diagramme illustrant des étapes et leurs liens dans le procédé conforme à l'invention pour l'obtention de données par lots. Description détaillée d'exemples illustrant l'invention. La figure 1 représente un système d'administration 10 d'un système d'information 11. L'exemple qui suit se rapporte au système d'administration et de sécurité connu sous le nom de marque déposée OpenMaster du demandeur. Sa conception est conforme aux normes ISO de l'administration de systèmes et réseaux. Dans ces conditions, les termes utilisés seront conformes à cette norme, qui sont de langue anglaise, notamment les sigles et acronymes. D'autre part, les verbes"administrer"et "gérer"et leurs dérivés qui seront employés ici traduisent tous deux indifféremment le verbe anglais"manage"et ses dérivés. L'homme du métier connaît bien ces normes. Compte tenu de leur masse informative, on ne donnera ici que les éléments nécessaires à la compréhension de l'invention. Le système d'information illustré 11 est distribué et se compose de machines 12, en l'occurrence trois machines 12a-12c, organisées en un ou plusieurs réseaux 13. Une machine est une unité conceptuelle très large, de nature matérielle et logicielle, pouvant être les moyens impliqués pour exécuter une application donnée, des moyens pour exécuter une fonction donnée, un ordinateur, ainsi qu'un système informatique dans une architecture à systèmes en cascade. Les machines 12 peuvent être donc très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées et passerelles entre réseaux. Le système d'information 11 est ordinairement un système comprenant plusieurs processeurs 14, un processeur 14 étant par exemple illustré dans chaque machine 12, des moyens de mémoire 15 pour contenir les logiciels et les données du système, et des moyens d'entrée-sortie (non illustrés) servant pour la communication entre machines par l'intermédiaire du réseau 13 à l'aide de protocoles divers, ainsi que pour une ou plusieurs communications extérieures, par exemple pour l'impression, la télécopie, etc. Un tel système peut par exemple gérer des données à distance, distribuer des données dans le cas d'un système de réservation, commander l'exécution de programmes à distance sur des machines spécialisées, partager localement des ressources physiques ou logicielles, et communiquer. Plus généralement, le système 11 se compose de ressources matérielles et/ou logicielles, réelles ou virtuelles, telles que machines, imprimantes, circuits virtuels, réseaux et applications. Le système d'administration 10 utilise au moins l'une de ces ressources selon un modèle de données orienté objets, dont on connaît les principales caractéristiques : classes, objets, héritage, encapsulation, méthodes et événements. Le système d'administration 10 choisi a une architecture de type client-serveur. Dans l'exemple illustré, un gestionnaire 16 forme un serveur d'administration inclus dans la machine 12a, dite machine gestionnaire, tandis que les clients d'administration 17a et 17b sont appelés agents et sont inclus dans les machines respectives 12b et 12c, dites machines gérées. Le gestionnaire 16 analyse et agit sur l'environnement à gérer selon la technologie orientée objets. Dans l'exemple choisi, tous les objets sont hiérarchisés dans un arbre correspondant à une base d'information d'administration plus connue sous le nom de MIB (Management Information Base). Les agents 17a et 17b permettent l'accès aux ressources à gérer dans les machines respectives 12b et 12c. Les ressources gérées dans les machines 12b et 12c sont identifiées sous forme d'objets organisés dans des sous-arbres (sous-MIB) respectifs 18a et 18b de la base MIB (voir aussi la figure 2). Selon une option courante et avantageuse du système d'administration 10, le gestionnaire 16 gère aussi la machine gestionnaire 12a correspondante ou peut gérer tout ou partie d'autres machines gestionnaires possibles. Cela peut se faire de façon similaire à celle illustrée avec une machine gérée, plus ou moins adaptée à cette option. L'exemple illustré offre le double avantage de faciliter la lecture des dessins tout en permettant à l'homme du métier de faire aisément une généralisation du système décrit et illustré. Le gestionnaire 16 constitue une plate-forme d'administration, entièrement contenue dans la machine 12a dans l'exemple illustré, mais pouvant être partagée dans d'autres machines. Le gestionnaire 16 inclut un module applicatif 20 contenant un ensemble d'applications 21 connectées à un tableau de bord 22. Le tableau de bord 22 est classique et inclut une partie graphique et un lanceur de requêtes 23. Une station graphique 24, extérieure à la plate-forme 16, est reliée au tableau de bord 22 pour visualiser les applications 21, lancer des requêtes et visualiser les résultats contenus dans les réponses aux requêtes. Elle permet à un utilisateur de se connecter à la machine 12a pour démarrer et arrêter comme il le désire ses propres copies des applications 21. L'ensemble du module 20 et de la station 24 peut constituer une station d'administration, séparée du reste du gestionnaire qui forme ainsi un serveur d'administration. Le serveur d'administration illustré utilise le protocole CMIP et comprend trois blocs fonctionnels : un module de services CMIS 25 incluant notamment une base CMIS-DB 26 de données CMIS et un service 27 de schémas d'informations d'administration, appelé MISS (Management Information Schema Service) contenant les schémas, aussi appelées classes, des objets gérés par la plate-forme 16 ; un courtier CMIP 28 aussi appelé bloc de communication ou distributeur de services CMIS (CMIS Dispatcher) contenant l'objet racine ROOT de tous les objets gérés par la plate-forme 16 ; et un module 29 intégrateur d'agents SNMP. L'intégrateur 29 d'agents SNMP constitue une interface entre le protocole CMIP utilisé par le gestionnaire et l'utilisateur de la station graphique 24 et le protocole SNMP utilisé par les ressources contenues dans les machines gérées 12b et 12c. L'intégrateur 29 est donc une interface commune entre le gestionnaire et les agents SNMP 17a et 17b. En pratique, le module 29 contient d'autres intégrateurs d'agents adaptés à d'autres protocoles. La figure 2 illustre de façon schématique et très partielle un exemple de structure d'une base MIB des objets qui sont gérés par la plate- forme constituant le gestionnaire 16 du système d'administration 10 et qui sont représentatifs d'au moins une ressource du système d'information 11. Les ressources gérées sont converties en classes d'objets organisées hiérarchiquement dans une base d'informations d'administration MIB (Management Information Base). Cette base n'est pas une base de données proprement dite, mais est assimilable à un catalogue de caractéristiques puisqu'elle contient la description et le contenu de toutes les classes gérées par le système d'administration 10. L'organisation des classes dans l'exemple choisi du système d'administration 10 est hiérarchique. On distingue l'arbre des classes, une classe étant définie en subordination à une ou plusieurs classes mères, et l'arbre des instances, une instance étant attachée à une ou plusieurs instances mères. L'arbre des classes est contenu dans le service MISS 27, tandis que l'arbre des instances est l'arbre correspondant à la base MIB telle que représentée sur la figure 2. Dans la base MIB, les objets sont divisés en classes d'objets gérés, dites classes MOC (Managed Object Class). Un objet géré est une vue abstraite, définie pour les besoins de la gestion, d'une ressource logique ou physique d'un système. Chaque classe MOC représente un type donné desdits moyens du système 11. À chaque classe MOC peuvent être attachées une ou plusieurs instances d'objets gérés, appelées instances MOI (Managed Object Instance) et représentant des occurrences actuelles desdits moyens. Tous les objets de la base MIB dans la figure 2 sont placés sous la racine ROOT et sont répartis en sous-MIB appelées par la suite modules de MIB. La racine ROOT est contenue dans le courtier 28 et les racines des modules de MIB sont appelées sous-racines (rootlets). La figure 2 illustre deux modules de MIB représentatifs des deux machines gérées 12b et 12c par le gestionnaire 16 et ayant comme sous-racines les sous-arbres respectifs 18a et 18b. On suppose que les sous-arbres 18a et 18b incluent des tables 19, celles illustrées étant des tables ayant un grand nombre d'entrées, par exemple supérieur à plusieurs milliers ou dizaines de milliers, telles que des tables relatives au parc informatique d'une grande société. On suppose aussi qu'un utilisateur du système d'administration 10, en l'occurrence un administrateur du parc informatique de la société, veuille interroger les tables 19 pour connaître une situation particulière. Le procédé de l'invention va lui permettre d'interroger les tables 19 pour obtenir l'information recherchée dans au moins un lot dont la taille, le début et la fin peuvent être définis sans contrainte par l'administrateur. La figure 3 est un diagramme illustrant des étapes du procédé conforme à l'invention pour l'obtention d'au moins un lot de données accessibles par le protocole SNMP et demandées avec le protocole CMIP. Le procédé est activé à l'étape SO et commence par une étape SI de définition d'un attribut A relatif à toute donnée accessible par le protocole SNMP. Cette définition peut être faite dans une interface avec le protocole CMIP pour accéder au protocole SNMP. En l'occurrence, cette interface est la base MIB représentée sur la figure 2. Le procédé continue par une étape S2 d'émission d'une requête R faite selon le protocole CMIP et demandant un lot L d'au moins une donnée désirée. La requête R est faite par l'administrateur avec le lanceur 23 de requêtes par l'intermédiaire du tableau de bord 22 et de la station graphique 24. On suppose qu'elle concerne comme objet géré une table SNMP 19 contenue dans une ressource de la machine 12b. La requête R est envoyée par le lanceur 23 au courtier CMIP 28, qui l'envoie à l'intégrateur 29. L'intégrateur 29 consulte l'arbre de MIB représenté sur la figure 2 pour connaître où est l'objet demandé 19 et l'adresser en l'occurrence à l'agent SNMP 17a. D'autre part, le protocole CMIP est du type selon lequel les données demandées par la requête peuvent être filtrées par l'ajout d'un filtre dans la requête. Le filtre de la requête inclut une condition sur une valeur de l'attribut A. La valeur correspond à un numéro d'ordre des données dans le lot demandé L. En fait, la possibilité offerte par le protocole SNMP d'un traitement par lots de données suppose que les données sont ordonnées selon un ordre prédéterminé. L'ordre peut être quelconque, alphabétique, numérique ou autre. Dans la requête R demandant un lot de données, la valeur de l'attribut correspond au plus grand numéro d'ordre de données du lot demandé. La valeur est donc définie par un entier strictement positif. Quand l'administrateur veut un lot de plusieurs données successives, la valeur de l'attribut correspond au nombre maximal de données du lot demandé et la condition fait alors correspondre cette valeur avec le numéro d'ordre supérieur des données du lot, indiquée par le symbole On rappelle que le protocole CMIP est organisé selon un langage de description des informations d'administration appelé langage GDMO/ASN. l issu de directives pour la définition d'objets gérés (Guidelines for the Definition of Managed Objects) selon le modèle d'interconnexion connu sous le nom de marque déposée OSI (Open Systems Interconnection) de l'organisme international de normalisation ISO (International Standards Organisation), et de syntaxe ASN1 (Application Syntax Notation One). Pour des raisons de commodité, ce langage sera appelé simplement GDMO. L'attribut A de l'exemple choisi est donc un attribut de langage GDMO et est ajouté à la représentation GDMO des tables SNMP 19, comme illustré schématiquement dans la figure 2. La représentation des tables SNMP est disponible dans l'intégrateur 19 et l'ajout de l'attribut A permet à l'intégrateur 19 d'obtenir de l'agent SNMP concerné 17a le lot demandé. L'attribut A appartient ainsi à chacune des classes CMIS représentant une table SNMP 19. À la fin de l'étape S2, l'administrateur peut reprendre le procédé à l'étape SI pour faire une nouvelle requête et demander un autre lot. En annexe est présenté un exemple concret de requête R et d'attribut A mis en oeuvre pour obtenir d'une table 19 relative à un parc informatique et nommée park. L'accès aux entrées de la table est représenté par une classe nommée parkEntry. L'entrée choisie concerne les ordinateurs identifiés par pc. L'attribut A est nommé responselndex. La requête R est du type GET CMIS filtrée, contenant dans son filtre l'attribut responselndex, la valeur de l'attribut et la condition sur cette valeur avec les données désirées. La première requête RI qui est formulée par l'administrateur du parc et présentée en annexe demande les cent premières réponses. Dans le lot LI reçu en réponse, chacune des entrées est identifiée par un numéro d'ordinateur (AAA, AAC, etc.) et par l'attribut A. La valeur de l'attribut est le numéro d'ordre, qui va de 1 à 100 dans l'exemple illustré, de la donnée correspondante dans le lot et la condition est l'égalité (=) de la valeur avec la donnée. L'exemple suppose que l'administrateur désire obtenir ensuite les cinquante réponses suivantes. Il fait donc une seconde requête R2, dont l'attribut a pour valeur 50. Il ajoute aussi au filtre le dernier objet de la réponse précédente RI, parce que le protocole SNMP est du type sans état (stateless) qui traduit le fait qu'il ne mémorise pas les réponses qu'il a déjà faites à une même requête précédente. Les réponses présentées en annexe sont au nombre de cinquante et se présentent successivement sous les numéros d'ordre de 1 à 50. L'exemple suppose que l'administrateur fait une troisième requête R3 pour connaître les cinquante réponses suivantes. La requête R3 ne change de la précédente R2 que par l'identification de l'objet de la dernière réponse à la requête R2. On voit que seules quatre réponses à la requête R3 ont été reçues, de sorte que la réponse globale comprend 154 objets. L'exemple en annexe démontre que si des requêtes sont faites successivement sur la même classe, les valeurs de l'attribut responselndex indiquées dans les réponses à l'une des requêtes sont indépendantes de celles d'une autre requête. Il en est évidemment de même si les requêtes sont simultanées. Dans tous les cas, la valeur de l'attribut commence par l'unité et augmente d'une unité à chaque réponse suivante. Il est à noter que la présence de l'attribut A dans les réponses est une option possible, qui a l'avantage de bien faire comprendre le mécanisme de l'invention mais qui n'est pas nécessaire. Cette option peut donc constituer une étape additionnelle 83 du procédé, selon laquelle on ajoute l'attribut A aux données respectives de la réponse à la requête R correspondante et la valeur de l'attribut, qui correspond au numéro d'ordre des données dans le lot. D'autre part, deux lots reçus en réponse à deux requêtes identiques successives peuvent avoir des contenus différents, du fait que dans la période de temps séparant les deux requêtes des objets ont pu être créés et d'autres supprimés. À partir des exemples illustrés, l'homme du métier peut bien sûr apporter de nombreuses modifications qui sont à sa portée. Par exemple, on a vu que les filtres des requêtes R2 et R3 ont, en plus de l'attribut et de sa valeur, le dernier objet du lot LI de la requête RI. Plus généralement, l'homme du métier peut combiner le filtre sur l'attribut responselndex avec des filtres sur d'autres attributs, comme il est courant dans les protocoles tels que CMIP. Il pourrait ainsi ajouter un filtre conditionnel pour ne demander par exemple que les objets ne commençant que par la lettre B dans l'exemple décrit en annexe. En outre, une limite possible du procédé est d'utiliser la requête avec un filtre pour n'avoir qu'une seule donnée dans le lot. Par exemple, dans la requête RI de l'annexe, un filtre tel que (responseIndex---100) ne fournirait comme lot que la donnée d'ordre 100 du lot Ll, représentative de la donnée pc BFG. Ce cas peut servir d'échantillonnage, pour savoir s'il existe une valeur pouvant dépasser un nombre donné. Dans ce filtre, la valeur de l'attribut A correspond au plus grand numéro d'ordre du lot demandé et la condition se limite au signe d'égalité =. Mais on pourrait faire usage d'une valeur correspondant au plus petit numéro d'ordre du lot et d'une correspondance de cette valeur avec les données demandées représentative d'une limite supérieure ou égale représentée par le symbole > = (supérieur ou égal). Par exemple, un filtre tel que (responselndex > = 91) ET (responselndex ) pourrait être utilisée. Certaines autres modifications ont déjà été présentées. En outre, il est clair que le procédé n'est pas limité aux deux protocoles SNMP et CMIP, qui ont été présentés comme un cas fréquent. D'autres protocoles Pl que SNMP sont possibles, tels que le protocole CIMXML/HTTP du modèle CIM qui a été présenté au début de la présente description, qui offre l'avantage sur le protocole SNMP de pouvoir traiter directement les données par lots. Le modèle CIM est orienté objets et permet de définir des schémas conceptuels et des objets du monde réel destinés à l'administration. Il utilise un langage unifié de modélisation connu sous le nom de langage UML (Unified Modelling Language). Ce modèle reçoit actuellement un succès grandissant grâce à son adaptation aux échanges sur la Toile mondiale (World Wide Web) et les réseaux de type internet. Il est ainsi utilisé pour l'administration d'entreprise par la Toile, connue actuellement sous l'acronyme WBEM (Web-Based Enterprise Management). En particulier, le modèle CIM offre le double avantage de pouvoir utiliser, d'une part, un navigateur pour chercher des données d'administration et, d'autre part, les technologies d'internet pour l'administration. Ce modèle offre encore l'avantage d'être bien adapté à des ressources incluant une architecture d'objets distribués. En outre, d'autres protocoles P2 que CMIP sont possibles, dont le type commun est que les données sont demandées en une seule fois et peuvent être filtrées. D'autre part, les données peuvent être de toute sorte, notamment autres que des entrées des tables de l'exemple décrit. D'une manière générale, le procédé de l'invention pour l'obtention d'un lot L comprenant au moins une donnée 19 accessible par un premier protocole Pl permettant un traitement par lot se fait par l'intermédiaire d'un second protocole P2, du type selon lequel les données sont demandées en une seule fois et peuvent recevoir l'application d'un filtre. Le procédé comprend la définition d'un attribut A relatif à chaque donnée accessible par le premier protocole et l'émission d'une requête R faite selon le second protocole P2 et demandant en réponse le lot L, le filtre de la requête incluant au moins une condition ( =) sur une valeur respective de l'attribut. On a vu que dans l'exemple illustré, la définition de l'attribut a été faite dans la base MIB. Plus généralement, la définition de l'attribut peut être faite dans une interface avec le second protocole pour accéder au premier protocole. Dans le cas particulier de l'exemple choisi, l'interface est la base MIB, qui est accessible à partir de l'intégrateur 29. En plus du procédé, l'invention a aussi pour objet un système informatique (10, 11) mettant en oeuvre le procédé, le système comprenant des données 19 accessibles par un premier protocole Pl permettant un traitement par lot et un moyen lanceur 23 de requêtes R selon un second protocole P2, du type selon lequel les données sont demandées en une seule fois et peuvent être filtrées. Dans l'exemple choisi et réalisé, le procédé est mis en oeuvre par l'intégrateur 29 d'agents constitutif d'un moyen d'interface entre les deux protocoles Pl et P2. Cependant, cette forme de mise en oeuvre n'est pas nécessaire. En outre, bien qu'accessoire, l'invention s'applique avantageusement à un système d'administration 10 selon le second protocole P2 pour l'administration d'au moins une ressource, telle que le système d'information 11, incluant les données 19 accessibles selon le premier protocole PI. Dans ce cas, si le protocole P2 utilise une base MIB, on a vu que l'attribut peut être avantageusement contenu dans cette base. ANNEXE Requête RI : GET classe=parkEntry, filtre= (responseIndex parkEntryId ="pc AAA", responseindex = 1 - > parkEntryId ="pc AAC", responseindex = 2 - > parkEntryId = "pc AAN", responseindex = 3 - > parkEntryId = "pc ABA", responseindex = 4 - > parkEntryId = "pc BFF", responseindex = 99 - > parkEntryId "pc BFG", responseindex = 100 - > (plus de réponse) Requête R2 : GET classe=parkEntry, filtre= (responseIndex "pc BFG") Lot L2 : - > parkEntryId ="pc BFH", responseindex = 1 - > parkEntryId ="pc BFJ", responseindex = 2 - > parkEntryld ="pc BGE", responseindex = 3 - > parkEntryld ="pc BGF", responseindex = 4 - > parkEntryId ="pc DOD", responseindex = 49 - > parkEntryId ="pc DOE", responseindex = 50 - > (plus de réponse) Requête R3 : GET classe=parkEntry, filtre= (responseIndex "pc DOE") Lot L3 : - > parkEntryId ="pc DOH", responseindex = 1 - > parkEntryId ="pc DOI", responseindex = 2 - > parkEntryId ="pc DOJ", responseindex = 3 - > parkEntryId ="pc DPA", responseindex = 4 - > (plus de réponse) Revendications : 1. Procédé d'obtention, dans un système informatique (10, 11) incluant au moins un processeur (14) et des moyens de mémoire (15), d'un lot (L) comprenant au moins une donnée (19) accessible dans les moyens de mémoire par un premier protocole (pal) permettant un traitement par lot, le procédé étant caractérisé en ce qu'il se fait par l'intermédiaire d'un second protocole (P2), du type selon lequel les données sont demandées en une seule fois et peuvent recevoir l'application d'un filtre, et en ce qu'il comprend la définition d'un attribut (A) contenu dans les moyens de mémoire et relatif à chaque donnée accessible par le premier protocole et l'émission d'une requête (R) faite selon le second protocole (P2) et demandant en réponse le lot (L), le filtre de la requête incluant au moins une condition ( =) sur une valeur respective de l'attribut. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend, dans le lot (L) de données de la réponse à la requête (R), l'ajout de l'attribut (A) aux données respectives et d'une valeur correspondant au numéro d'ordre des données dans le lot. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la définition de l'attribut est faite dans une interface (MIB) avec le second protocole pour accéder au premier protocole. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que les données demandées sont des entrées d'une table appartenant au premier protocole (PI). 5. Procédé selon la revendication 4, caractérisé en ce que l'attribut appartient à chacune des classes conformes au second protocole et représentatives de la table. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que le premier protocole (pal) est du type selon lequel les données sont demandées et obtenues paquet par paquet. 7. Système informatique (10, 11) comprenant au moins un processeur (14), des moyens de mémoire contenant des données (19) accessibles par un premier protocole (pal) permettant un traitement par lot et un moyen lanceur (23) de requêtes (R) selon un second protocole (P2), du type selon lequel les données sont demandées en une seule fois et peuvent être filtrées, caractérisé en ce qu'il met en oeuvre le procédé défini par l'une des revendications 1 à 6. 8. Système selon la revendication 7 incluant un moyen d'interface (29) entre les deux protocoles (pal, P2), caractérisé en ce que le procédé est mis en oeuvre par le moyen d'interface. 9. Système selon la revendication 7 ou 8, caractérisé en ce qu'il forme un système d'administration (10) selon le second protocole (P2) pour l'administration d'au moins une ressource (11) incluant lesdites données (19) accessibles selon le premier protocole (P1). 10. Système selon la revendication 9, caractérisé en ce que l'attribut est contenu dans une base d'informations d'administration (MIB).