IBM Tivoli Monitoring Agent Builder, version 6.3.0

Application Java générée à titre d'échantillon

Informations de référence décrivant le code généré par Agent Builder et le code que vous devez ajouter ou remplacer pour les ressources à surveiller.

Lorsque vous créez un agent avec une ou plusieurs sources de données d'interface de programme d'application Java™, Agent Builder génère le code source de l'application Java. Ce code est généré dans le projet de l'agent et suit la structure de ce dernier. Vous devez ajouter votre propre code Java à l'application générée. Il collecte des données pour des groupes d'attributs échantillonnés, gère les événements à envoyer à des groupes d'attributs basés sur des événements, signale les incidents détectés, et exécute les tâches. L'application générée fournit des données à l'agent mais il s'agit d'échantillons à remplacer par les données issues des ressources à surveiller.

Un exemple d'agent est supposé avoir les caractéristiques suivantes :

Code produit : K91
Classe principale d'interface de programme d'application Java : agent.client.MainClass
Structure de la source de données de l'agent illustrée à la (Figure 1) :
Figure 1. Structure de l'exemple d'agent
Propriété de configuration de certains sous-noeuds : K91_INSTANCE_KEY

Structure des classes

L'application Java générée sépare, dans une proportion importante, le code qui sert d'interface avec l'agent du code d'interface avec les ressources surveillées. Il contient des fichiers que vous modifiez et d'autres que vous ne modifiez pas.

Les classes Java suivantes sont créées par Agent Builder :

MainClass (package agent.client): Classe indiquée sur la page Informations globales relatives à la source de données de l'API Java. Elle contient une méthode principale et une méthode pour la gestion des requêtes de commande Action. Cette classe hérite de la classe auxiliaire décrite ci-après. Vous devez modifier cette classe pour l'interface avec les ressources à surveiller et les actions à exécuter.
MainClassBase (package agent.client): Classe auxiliaire qui initialise la connexion au serveur, enregistre les groupes d'attributs et attend les requêtes provenant du serveur. Ne modifiez pas cette classe.
Classes Sampled_Data, Sampled_Subnode, Event_Data et Event_Subnode (package agent.client.attributeGroups): Il existe une classe pour chaque groupe d'attributs de l'API Java qui gère des requêtes de collecte de données ou qui génère des événements pour le groupe d'attributs. Ces classes héritent chacune de l'une des classes auxiliaires décrites ci-après. Vous devez modifier ces classes pour regrouper les données issues des ressources à surveiller.
Classes Sampled_DataBase, Sampled_SubnodeBase, Event_DataBase et Event_SubnodeBase (package agent.client.attributeGroups): Classes auxiliaires, une pour chaque groupe d'attributs de l'API Java, qui définissent la structure des attributs du groupe dans une classe interne. Ne modifiez pas ces classes.
Interface ICustomAttributeGroup (package agent.client.attributeGroups): Interface qui définit les méthodes publiques de chaque classe de groupe d'attributs. Ne modifiez pas cette interface.

Agent Builder n'écrase jamais les classes que vous pouvez modifier. Il se contente de les créer si elles n'existent pas.

Les classes auxiliaires et l'interface sont écrasées à chaque sauvegarde d'Agent Builder. A mesure que vous modifiez et sauvegardez l'agent, les classes auxiliaires sont mises à jour afin de refléter tous les changements structurels apportés aux groupes d'attributs de l'API Java. L'interface et les classes auxiliaires contiennent un avertissement dans leur en-tête pour vous rappeler que vous devez modifier le fichier.

Initialisation et nettoyage

La méthode principale de la classe MainClass est appelée au démarrage de l'agent. Elle crée une instance MainClass puis lance la méthode à exécution longue pour recevoir et gérer les requêtes d'agent.

La majeure partie du code d'initialisation et de nettoyage doit être ajoutée à MainClass. Dans le constructeur, ajoutez le code d'initialisation requis pour créer vos ressources ou y accéder. Vous pouvez, si vous le souhaitez, ouvrir des connexions à des ressources distantes, créer des descripteurs ou initialiser des structures de données.

Avant l'arrêt de l'agent, la méthode stopDataCollection est appelée. Si vous devez fermer des connexions ou effectuer un nettoyage avant l'arrêt de l'application Java, ajoutez ce code à la méthode stopDataCollection.

Si une initialisation n'est requise que pour un groupe d'attributs particulier, vous pouvez ajouter cette initialisation au constructeur de la classe du groupe d'attributs. De même, si un nettoyage n'est requis que pour un groupe d'attributs particulier, vous pouvez ajouter ce code de nettoyage à la méthode stopDataCollection du groupe d'attributs.

Tout code de l'application Java peut utiliser l'objet consignateur pour inscrire des entrées de journal. (La classe auxiliaire principale crée un objet consignateur protégé dans son constructeur. Les objets auxiliaires de groupe d'attributs créent une référence protégée à ce consignateur dans leurs constructeurs). L'objet consignateur fait appel à l'utilitaire de consignation de trace de Java. Des informations détaillées relatives aux erreurs et aux traces sont accessibles dans le journal de trace que crée le consignateur. Ces informations sont essentielles pour l'identification des incidents avec le fournisseur.

Lors de l'appel de stopDataCollection, si vous transmettez la tâche de nettoyage à une autre unité d'exécution, attendez que cette unité d'exécution soit terminée avant le retour à la méthode stopDataCollection. Sinon, la tâche de nettoyage risque de s'arrêter brutalement lors de l'arrêt du processus suite à la fin de l'unité d'exécution.

L'un des paramètres de configuration de l'agent est réservé au niveau de trace Java. Le tableau suivant indique les valeurs que vous pouvez définir dans la propriété de configuration JAVA_TRACE_LEVEL. Si l'API a créé le consignateur à votre intention, le tableau affiche le niveau qu'utilise ce consignateur.

Tableau 1. Options de niveau de trace Java
Niveau de trace configuré	Niveau de trace de consignation Java	Description
Arrêt	HORS FONCTION	Pas de consignation.
Erreur	GRAVE	Suivi des problèmes survenus dans l'application Java.
Avertissement	WARNING	Suivi des erreurs et des erreurs potentielles.
Informations	INFORMATION	Suivi des informations importantes concernant l'application Java.
Débogage minimum	FIN	Suivi des détails de niveau supérieur nécessaires à l'analyse du comportement de l'application Java.
Débogage moyen	PLUS FIN	Suivi des détails relatifs au flux du programme de l'application Java.
Débogage maximum	TRES FIN	Suivi de tous les détails concernant l'application Java.
Tous	TOUS	Suivi de tous les messages.

Dans cet exemple, l'application Java crée le fichier journal nommé k91_trace0.log. Si l'agent est multi-instance, le nom d'instance doit être inclus dans le nom du fichier journal.

Remarque : Ne pas écrire de messages vers une erreur ou une sortie standard. Sur les systèmes Windows, ces messages sont perdus. Sur les systèmes UNIX et Linux, ces données sont écrites dans un fichier sans boucle.

Collecte de données échantillonnées de groupe d'attributs

La classe d'un groupe d'attributs échantillonnés (qui collecte une ou plusieurs lignes de données) contient une méthode collectData, par exemple Sampled_Data.collectData. Cette méthode est appelée chaque fois que l'agent demande des données.

La classe auxiliaire du groupe d'attributs définit une classe interne nommée Attributs. Cette classe comporte une zone pour chaque attribut qui est défini dans votre groupe d'attributs. Les attributs dérivés ne sont pas inclus car ils sont calculés par l'agent. Les types de données des zones d'attribut sont des équivalents Java des types d'attributs Tivoli Monitoring, comme indiqué dans le (Tableau 2).

Tableau 2. Types de données des zones d'attributs et leurs types d'attribut IBM® Tivoli Monitoring équivalents
Type Tivoli Monitoring	Type de données de la zone d'attribut
Chaîne	Chaîne
Numérique, 32 bits, sans ajustement décimal	entier
Numérique, 64 bits, sans ajustement décimal	long
Numérique, ajustement décimal différent de zéro	double
Horodatage	Planification calendaire

La méthode collectData doit :

Collecter les données appropriées à partir de la ressource surveillée.
Créer un objet Attributs.
Ajouter les données aux zones de l'objet Attributs.
Appeler la méthode Attributes.setAttributeValues pour copier les données dans une mémoire tampon interne.
Répéter les étapes 1 à 4 pour chaque ligne de données. (Vous pouvez sauter les étapes 1 à 4 et ne renvoyer aucune ligne. Dans ce cas, la colonne Code d'erreur de la table Statut de l'objet de performances contient la valeur NO_INSTANCES_RETURNED. Pour plus d'informations sur les codes d'erreur, voir (Codes d'erreur).
Appelez AgentConnection.sendData pour envoyer les données à l'agent ou appeler sendError pour supprimer les données copiées de tous les appels de setAttributeValues et envoyez à la place un code d'erreur.

Vous devez collecter les données à partir de votre ressource (étape 1), en remplaçant les données échantillonnées utilisées dans l'application générée.

Pour renseigner l'objet Attributs, vous pouvez transmettre les données à l'aide du constructeur d'attributs (comme dans l'application générée). Vous pouvez également utiliser le constructeur à zéro argument pour créer un objet Attributs puis affecter les zones de l'objet aux valeurs d'attribut collectées. Les zones portent le même nom que les attributs, mais commencent par une lettre en minuscule.

Collecte de données échantillonnées pour un sous-noeud

Lorsqu'un groupe d'attributs échantillonnés se trouve dans un sous-noeud, il est probable que vous surveilliez plusieurs ressources (une pour chaque sous-noeud). Vous devez déterminer les ressources à partir desquelles les données doivent être collectées. Une ou plusieurs propriétés de configuration doivent identifier la ressource surveillée.

Cet exemple part du principe qu'une propriété de configuration, K91_INSTANCE_KEY, contient une valeur qui identifie la ressource à partir de laquelle collecter des données.

Pour trouver la ressource appropriée, procédez comme suit :

Extrayez l'ID instance de tous les sous-noeuds configurés en appelant AgentConnection.getConfiguredSubnodeInstanceIDs. A chaque sous-noeud configuré correspond un ID instance unique.
Extrayez la propriété de configuration K91_INSTANCE_KEY de chaque ID instance en appelant AgentConnection.getSubnodeConfigurationProperty.
Recherchez la ressource représentée par la valeur de K91_INSTANCE_KEY.

Cette procédure peut être effectuée dans la méthode collectData avant les procédures détaillées dans (Collecte de données échantillonnées de groupe d'attributs).

Vous pouvez également exécuter cette procédure dans le constructeur de classe de groupe d'attributs et effectuer un mappage direct de l'ID instance sur la ressource. Le constructeur Sampled_Subnode est un exemple de constructeur de classe de groupe d'attributs. Cette procédure vous donne également la possibilité de créer des descripteurs ou d'ouvrir des connexions qui peuvent être utilisés dans toute la durée de vie de l'agent. La création de descripteurs ou l'ouverture de connexions peut optimiser l'accès à vos ressources.

Le code généré crée des exemples d'objet ressource de type MonitoredEntity dans le constructeur et les ajoute dans une mappe configurationLookup. Vous devez supprimer la classe interne MonitoredEntity et remplacer les objets MonitoredEntity qui accèdent à vos propres ressources. Si vous choisissez d'effectuer intégralement la procédure de recherche dans la méthode collectData, vous pouvez supprimer la mappe configurationLookup de la classe.

Si vous choisissez de faire appel au constructeur, avec mappage de l'ID instance de sous-noeud à votre ressource, les étapes à suivre dans la méthode collectData sont les suivantes :

Extraction de l'ID instance du sous-noeud à partir du paramètre de demande, par appel de Request.getSubnodeInstanceID.
Extraction de l'objet ressource à partir de la mappe créée dans le constructeur.
Exécution de la procédure décrite dans Collecte de données échantillonnées de groupe d'attributs pour envoyer des données à l'agent.

Une propriété de sous-noeud est choisie arbitrairement dans l'exemple d'Agent Builder, iciK91_INSTANCE_KEY. Si la propriété est incorrecte, ou si plusieurs propriétés sont nécessaires pour identifier la ressource adéquate, vous devez choisir les propriétés correctes pour identifier la ressource.

Envoi d'événements

Pour les groupes d'attributs qui génèrent des événements, la méthode collectData n'est pas appelée régulièrement. Votre application envoie des événements à mesure que la ressource les transmet.

Ainsi, le code généré pour un groupe d'attributs basé sur des événements crée et démarre une unité d'exécution qui s'exécute à partir d'une classe interne nommée SampleEventClass. Le groupe d'attributs basé sur des événements, utilisé dans l'exemple, est la classe Event_Data. L'unité d'exécution se réveille régulièrement et envoie un événement. Si vous devez interroger périodiquement la ressource concernant des événements, vous pouvez utiliser la structure de la classe Event_Data qui a été générée :

Créez et démarrez une unité d'exécution à partir du constructeur Event_Data.
Dans la méthode d'exécution de l'unité d'exécution, générez une boucle jusqu'à ce que l'agent se termine.
Procédez à une mise en sommeil pendant un certain temps avant de vérifier la présence d'événements. Vous pouvez modifier l'intervalle d'interrogation de 5 000 millisecondes en une valeur plus adaptée à votre agent.
Déterminez si un ou plusieurs événements se sont produits. L'application générée n'effectue pas cette vérification et transmet toujours un seul événement.
Pour chaque événement à envoyer, extrayez les données à transmettre.
Créez et renseignez l'objet Attributs (comme l'a fait la méthode collectData pour un groupe d'attributs échantillonnés).
Appelez la méthode Attributes.sendEventData. Les événements constituant une ligne unique, vous ne pouvez envoyer qu'une seule ligne à la fois.

Par ailleurs, si vous travaillez avec une API Java qui signale les événements issus de sa propre unité d'exécution, vous pouvez initialiser cette unité d'exécution dans le constructeur Event_Data. Vous pouvez également enregistrer votre propre objet de gestion d'événement à l'aide du mécanisme de gestion des événements de votre ressource. Dans votre gestionnaire d'événements, procédez comme suit :

Extrayez les données d'événements à envoyer.
Créez et remplissez l'objet Attributs.
Appelez la méthode Attributes.sendEventData.

Dans ce cas, vous n'avez pas à créer votre propre unité d'exécution dans la classe Event_Data et vous n'avez pas besoin de la classe SampleEventClass.

Envoi d'événements dans un sous-noeud

Lorsqu'un événement est détecté pour un groupe d'attributs de sous-noeud, l'application Java doit envoyer l'événement au sous-noeud approprié.

Cet exemple part du principe qu'une propriété de configuration, K91_INSTANCE_KEY, contient une valeur qui identifie une instance de ressource pouvant générer des événements. Il présume également que la valeur de la propriété K91_INSTANCE_KEY est extraite avec les données à envoyer dans l'événement. Pour extraire la propriété et les données, l'application Java effectue les étapes suivantes :

Extraction des données d'événements à envoyer, ainsi que la “clé d'instance”.
Création et remplissage de l'objet Attributs.
Extraction de la liste de tous les ID d'instance de sous-noeud configurés par appel de AgentConnection.getConfiguredSubnodeInstanceIDs.
Pour chaque instance de sous-noeud, extraction de la valeur de K91_INSTANCE_KEY par appel de AgentConnection.getSubnodeConfigurationProperty.
A la détection d'une correspondance entre la valeur de K91_INSTANCE_KEY et la valeur obtenue avec les données d'événement, mémorisation de l'ID d'instance de sous-noeud correspondant.
Appel de Attributes.sendSubnodeEventData, avec transmission de l'ID d'instance de sous-noeud mémorisé.

L'application générée n'effectue pas la recherche décrite aux étapes 4 et 5, mais envoie un événement au groupe d'attributs de chaque sous-noeud. Ce comportement n'est probablement pas approprié pour un agent de production.

Commandes Action

Les commandes Action sont définies dans Tivoli Enterprise Portal ou à l'aide de la commande tacmd createaction. Les actions peuvent être importées dans le projet Agent Builder de l'agent de sorte qu'elles sont créées lors de l'installation de l'agent. Pour plus d'informations sur l'importation des commandes Action, voir (Importation des fichiers de prise en charge de l'application).

L'application Java générée s'enregistre pour toutes les actions qui commencent par le code produit de l'agent, par exemple, K91Refresh. Cet enregistrement s'effectue dans la classe auxiliaire principale (MainClassBase) à partir de la méthode registerActionPrefix. Si vous souhaitez enregistrer d'autres préfixes ou ne pas vous enregistrer du tout pour les actions, redéfinissez registerActionPrefix dans (MainClassBase).

Lorsque l'agent doit exécuter une action qui commence par un préfixe que votre agent a enregistré, la méthode MainClass.takeAction est appelée. Ajoutez du code pour appeler Request.getAction(), effectuez l'action appropriée, puis appelez AgentConnection.sendActionReturnCode pour envoyer le code retour de votre action. Le code retour 0 indique que l'action a abouti, tout autre code retour indique que l'action a échoué.

Gestion des exceptions

Les méthodes collectData et takeAction peuvent émettre n'importe quelle exception Java, vous pouvez donc autoriser votre code de collecte à émettre des exceptions sans les intercepter. La méthode handleException (pour collectData) ou la méthode handleActionException (pour takeAction) est appelée lorsque la classe auxiliaire reçoit l'exception.

Pour les exceptions collectData, vous devez appeler AgentConnection.sendError lorsqu'une exception se produit ou en cas de problème de collecte de données. L'application générée transmet un code d'erreur GENERAL_ERROR. Vous devez toutefois remplacer ce code d'erreur par un code défini par votre agent et qui décrit mieux l'incident qui s'est produit. Pour plus d'informations sur l'ajout de codes d'erreur, voir l'étape (13).

Pour les exceptions takeAction, vous devez appeler AgentConnection.sendActionReturnCode avec un code retour différent de zéro.

Certaines méthodes AgentConnection émettent des exceptions dérivées de com.ibm.tivoli.monitoring.agentFactory.customProvider.CpciException. La méthode handleException n'est pas appelée si une exception CpciException est émise lors de la collecte de données car la classe auxiliaire gère l'exception.

Remarque : Si vous choisissez d'intercepter vos exceptions dans la méthode collectData au lieu d'utiliser la méthode handleException, assurez-vous que toutes les exceptions CpciException sont renvoyées. Vous vérifiez le renvoi de l'exception CpciException pour qu'elle soit traitée par la classe de base.

Codes d'erreur

En réponse à une exception ou à toute autre erreur liée aux ressources, un code d'erreur est généralement transmis à l'agent par appel de la méthode AgentConnection.sendError. Une erreur liée à un groupe d'attributs basé sur des événements peut être envoyée à tout moment. Une erreur liée à un groupe d'attributs échantillonnés ne peut être envoyée qu'en réponse à une demande de collecte de données et à la place d'un appel sendData.

Lorsque vous envoyez une erreur à l'agent, les opérations suivantes s'exécutent :

Un message d'erreur est consigné dans le journal de trace de l'agent. Ce message d'erreur contient le code d'erreur et le message défini pour ce code d'erreur.
Une requête de statut d'objet de performances permettant d'obtenir des informations relatives au statut des groupes d'attributs s'affiche. La colonne Code d'erreur indique le type de code d'erreur défini pour l'erreur envoyée. Le statut d'erreur est effacé une fois que l'agent a correctement reçu les données du groupe d'attributs. Si vous répondez à une requête de collecte de données par un appel sendData sans avoir inclus de ligne de données, la colonne Code d'erreur affiche NO_INSTANCES_RETURNED.

Le tableau suivant décrit certains de codes d'erreur internes à l'agent que vous pouvez obtenir dans certaines situations :

Tableau 3. Codes d'erreur internes de l'agent
Code d'erreur	Description
`NO_ERROR`	Indique que le groupe d'attributs ne présente pas de problèmes.
`NO_INSTANCES_RETURNED`	L'application Java a répondu à une demande de collecte de données mais n'a fourni aucune donnée. Le fait de ne pas fournir de données ne constitue pas une erreur. Cela indique généralement qu'il n'existe aucune instance de la ressource que surveille le groupe d'attributs.
`OBJECT_NOT_FOUND`	L'agent a tenté de collecter des données pour un groupe d'attributs qui n'est pas enregistré via l'API client. Cette erreur peut signifier que l'application n'a pas réussi à démarrer ou n'a pas initié l'enregistrement du groupe d'attributs au moment où l'agent a tenté de collecter des données.
`OBJECT_CURRENTLY_UNAVAILABLE`	L'application a envoyé à l'agent un code d'erreur non défini dans la liste globale des codes d'erreur.
`GENERAL_ERROR`	Un incident s'est produit lors de la collecte de données à partir de l'application, généralement parce que l'application n'a pas répondu à la requête dans le délai imparti. Consultez le journal de trace de l'agent pour plus de détails. L'application peut également spécifier `GENERAL_ERROR` comme code d'erreur, mais il est préférable de définir un code d'erreur plus détaillé.

Changements au niveau de l'agent

Certains des changements apportés à l'agent nécessitent les changements correspondants au niveau de l'application Java. Si les changements structurels sont complexes, vous pouvez supprimer certains ou la totalité des fichiers source Java avant de sauvegarder l'agent. Vous pouvez également supprimer les fichiers si vous souhaitez recommencer sans les personnalisations que vous avez apportées.

Le tableau suivant décrit les modifications à apporter aux fichiers source de l'application Java après certains changements dans Agent Builder lors de la sauvegarde de l'agent.

Tableau 4. Changements au niveau d'un agent nécessitant des modifications de la source Java
Changement au niveau de l'agent	Action d'Agent Builder	Modifications manuelles nécessaires au niveau du source Java
Changement du nom du package de la classe principale	Génère toutes les classes dans la nouvelle structure de package Supprime toutes les classes auxiliaires de l'ancien package	Portez le contenu de la classe principale et de la classe des groupes d'attributs depuis les classes de l'ancien package vers les classes du nouveau package. Supprimez les classes de l'ancien package une fois la migration terminée.
Changement du nom de la classe principale	Crée de nouvelles classes principales. Supprime l'ancienne classe auxiliaire principale.	Portez le contenu de la classe principale vers la nouvelle classe. Mettez à jour les références au nom de la classe à partir des classes des groupes d'attributs.
Ajout d'un groupe d'attributs de l'API Java	Crée des classes pour le nouveau groupe d'attributs. Ajoute un enregistrement pour le nouveau groupe d'attributs dans la classe auxiliaire principale.	Remplacez l'exemple de code par la logique personnalisée dans la classe du groupe d'attributs.
Suppression d'un groupe d'attributs de l'API Java	Supprime l'enregistrement de la classe auxiliaire principale.	Supprimez la classe du groupe d'attributs ou portez la logique personnalisée vers une autre classe. Supprimez la classe auxiliaire du groupe d'attributs.
Changement de nom d'un groupe d'attributs de l'API Java	Crée des classes pour le nouveau nom du groupe d'attributs. Met à jour l'enregistrement pour le groupe d'attributs renommé dans la classe auxiliaire principale.	Portez la logique personnalisée dans la classe du groupe d'attributs portant l'ancien nom vers la classe du groupe d'attributs portant le nouveau nom. Supprimez la classe du groupe d'attributs portant l'ancien nom. Supprimez la classe auxiliaire du groupe d'attributs portant l'ancien nom.
Ajout d'un attribut à un groupe d'attributs de l'API Java	Met à jour la classe interne Attributs dans la classe auxiliaire du groupe d'attributs.	Collectez des données pour le nouvel attribut dans la classe du groupe d'attributs.
Suppression d'un attribut d'un groupe d'attributs de l'API Java	Met à jour la classe Attributs dans la classe auxiliaire du groupe d'attributs.	Supprimez la collecte de données de l'ancien attribut dans la classe du groupe d'attributs.
Changement du nom d'un attribut d'un groupe d'attributs de l'API Java	Met à jour le nom d'attribut de la classe Attributs dans la classe auxiliaire du groupe d'attributs.	Mettez à jour toutes les références au nom de l'attribut dans la classe Attributs (généralement, ces références n'existent pas du fait de l'utilisation du constructeur d'attributs, avec arguments positionnels).
Réorganisation des attributs d'un groupe d'attributs de l'API Java	Met à jour l'ordre des attributs dans la classe Attributs dans la classe auxiliaire du groupe d'attributs.	Mettez à jour l'ordre des arguments dans tous les appels au constructeur d'attributs.

Certains des changements mentionnés dans le tableau précédent peuvent être rationalisés si vous utilisez l'action Rename d'Eclipse Refactor. Appliquez cette action sur tous les noms affectés (y compris les noms de classe auxiliaire) avant de sauvegarder l'agent modifié.

Utilisation de l'API Java

L'interface de programme d'application Java est utilisée dans l'ensemble de l'application Java générée pour communiquer avec l'agent. Le plus souvent, votre seule interaction directe avec l'API Java consiste à modifier un paramètre d'un appel de méthode existant. Par exemple, la modification d'un code d'erreur GENERAL_ERROR envoyé par un code d'erreur défini dans votre agent.

Si vous avez besoin d'effectuer une codification plus étendue avec l'API Java, vous pouvez afficher Javadoc depuis l'éditeur de texte Eclipse. Vous pouvez afficher Javadoc pendant l'édition du code Java en procédant comme suit :

Mettez en évidence un nom de package, de classe ou de méthode à partir de l'interface de programme d'application.
Appuyez sur F1 pour ouvrir l'aide Eclipse.
Sélectionnez le lien Javadoc.

Vous pouvez également afficher une brève description issue de Javadoc en survolant un nom de classe ou de méthode. Le Javadoc de l'interface de programme d'application est également accessible dans le Centre de documentation Tivoli Monitoring et OMEGAMON XE à l'adresse Javadoc.

Les classes de l'interface de programme d'application Java figurent dans le fichier cpci.jar. Le fichier cpci.jar est automatiquement ajouté au chemin de génération Java du projet lorsqu'un agent qui contient un groupe d'attributs d'interface de programme d'application Java est créé. Ce fichier est également ajouté lors de l'importation d'un agent contenant un groupe d'attributs de l'API Java, et lorsqu'un groupe d'attributs de l'API Java est ajouté à un agent existant. Le fichier cpci.jar est également automatiquement ajouté à chaque agent contenant un groupe d'attributs d'interface de programme d'application Java et au chemin CLASSPATH de l'application Java.

Commentaires en retour