> Tech > RDi : Finir notre application

RDi : Finir notre application

Tech - Par Renaud ROSSET - Publié le 06 juin 2012
email

Après avoir mis en place tout le nécessaire pour notre application, le moment est venu de finir.

RDi : Finir notre application

Au lieu de taper tout le code, vous trouverez le source complet à www.remainsoftware.com/en/rdi. Sélectionnez Source3.

Tout d’abord, ouvrez le source du MessageMonitorView que vous trouverez dans le répertoire src de votre projet ou en cliquant sur l’onglet adéquat dans la zone éditeur. Vous ne trouverez l’onglet que si le source est encore ouvert. Assurez-vous que vous avez une référence vers toutes les variables dont vous avez besoin dans notre classe. Remplacez le source de l’éditeur par celui du web. Si vous n’avez pas accès au web, vous pouvez taper les instructions Import de la figure 3. Ces lignes remplacent les lignes “Import” existantes.

Il nous faut aussi nos variables globales (figure 4). Copiez cet ensemble de variables dans votre source juste au-dessous de la définition de classes. Nous utilisons les variables à cet effet : le texte contient nos messages afin que nous puissions les visualiser, la file d’attente est une référence à notre objet de file d’attente de messages AS400 et lastMessage est le dernier message provenant de la file.

La variable currentHost contiendra l’hôte RSE que nous avons sélectionné et monitorThread est une référence à un programme batch que nous soumettrons pour repérer les messages entrants dans la file d’attente. Les champs user, alert, et severityInt contiennent les valeurs permettant d’influencer le comportement de notre moniteur, et oldPart et oldSelection servent à reconstruire la vue après que nous ayons manipulé nos attributs.

À présent créons quelques méthodes d’appui pour remplir notre champ de texte avec des messages provenant du System i. La méthode suivante garantit que vous pouvez accéder à notre widget texte. Cela est spécifique à SWT mais ne vous en souciez pas pour l’instant. « Extending Rdi : Add a View to an Application » traite brièvement de SWT.

private void setText(final String message) {

        getSite().getShell().getDisplay().asyncExec(new Runnable() {

            @Override

            public void run() {

                text.setText(message);

            }

        });

    }

La méthode d’appui ci-dessous arrêtera notre moniteur de files d’attente de messages quand nous voudrons qu’il s’arrête. Copiez cette méthode quelque part dans le source.
private void stopMonitor() { C

        // Stop the monitor thread

        if (monitorThread != null && monitorThread.isAlive()) {

            monitorThread.interrupt();

        }

    }

Puis faisons un appel à cette méthode dans la méthode dispose() afin que le moniteur ne continue pas à travailler quand nous aurons fermé notre vue.
private void stopMonitor() {

    // Stop the monitor thread

    if (monitorThread != null  &&monitorThread

      .isAlive())  {

       monitorThread.interrupt();

    }

}

La méthode createPartControl(..) a aussi besoin d’un peu de nettoyage et de quelques ajouts mineurs. Son code final se trouve dans figure 5. Les écouteurs de sélection en A, B, et C ont changé. Au lieu d’imprimer des messages dans le champ de texte, nous sauvegardons l’attribut modifié et appelons notre méthode selectionChanged() avec la partie et la sélection que nous allons sauvegarder dans cette méthode.
À présent, complétons notre méthode selectionChanged() afin qu’elle réagisse aux objets System i que nous sélectionnons  (figure 6). En A, la partie qui est passée à cette méthode, ainsi que l’objet sélection, est sauvegardée. Nous en aurons besoin pour redémarrer cette méthode si nous changeons les attributs de notre moniteur de messages. En B, une autre vérification vient s’assurer que la partie n’est pas nulle. En C, la sélection est vérifiée pour voir si c’est une sélection provenant d’un arbre.

Si oui, nous obtenons le premier segment du chemin d’arborescence et vérifions si c’est une instance de Host (D). Si la variable firstSegment remplit notre condition de ne pas être l’hôte courant, c’est que l’utilisateur a sélectionné un nouvel hôte. Cela signifie que nous devons arrêter le thread du moniteur en appelant la méthode stopMonitor() décrite précédemment (E). Le code en F est intéressant parce qu’il montre comment se procurer l’objet JTOpen AS400, qui est une classe importante à utiliser si vous voulez accéder à votre System i depuis Java. Une fois l’objet AS400 en notre possession, nous pouvons le passer à la méthode loadMessageQueue() (G). Celle-ci extraira les 50, ou moins, derniers messages de la file d’attente spécifiée et les placera dans notre champ de texte. Puis, en H, nous soumettrons un job qui surveillera les nouvelles arrivées dans la file d’attente de messages.

Pour cela, nous utiliserons un thread Java. Mais créons d’abord le message qui lira les messages dans la file d’attente et les placera dans le champ de texte (figure 7). Cette méthode vous montre comment extraire des messages d’une file d’attente. En A nous vérifions ce qui a été sélectionné et nous créons notre objet MessageQueue en conséquence. Ensuite, nous demandons à la file d’attente de nous donner le message le plus récent en premier, en utilisant sa méthode setListDirection(). En B nous regardons s’il y a des messages dans la file d’attente : s’il n’y en a pas, nous définissons cela en tant que texte et nous sortons. En C nous obtenons d’abord les messages qui ordonneront à la méthode load() de charger ces messages avant que nous puissions réellement atteindre le résultat dans une matrice. En D, tous les messages atteints sont concaténés dans une variable temporaire. Le premier message, qui est en fait le dernier, si vous vous rappelez la méthode setListDirection(), est sauvegardé en E pour analyse ultérieure si de nouveaux messages ont été ajoutés à la file d’attente. En F notre champ de texte est rempli pour nous montrer les résultats. Si quelque chose se passe mal, c’est intercepté (MONMSG) en G et placé dans le champ de texte au lieu de l’information du message.

Vous me suivez toujours ? La méthode waitForMessages() (figure 8) est la dernière. Elle surveillera l’arrivée de nouveaux messages dans la file d’attente. Cela se fera dans un thread Java, un procédé assez semblable à la soumission d’un job (c’est-à-dire que le code qui doit s’exécuter est enveloppé à l’intérieur d’un objet Runnable). En A nous créons une classe interne (inner class), qui met en oeuvre les méthodes requises de l’interface Runnable (la méthode run()). Pour attendre les nouveaux messages, nous avons le choix entre deux méthodes. La méthode A utilise l’une des méthodes receive() de la classe MessageQueue. Cette méthode peut attendre un nouveau message mais elle présente un inconvénient : la file d’attente de messages ne doit pas être verrouillée par un job interactif. C’est pourquoi nous préférerons la méthode B, qui utilisera la méthode getMessages() déjà utilisée. Pour ne pas stresser inutilement le système, en B nous marquons une pause de 10 secondes avant d’essayer de lire de nouveaux messages dans la file d’attente.

Vous pouvez bien sûr faire une pause plus longue mais votre moniteur ne sera pas très réactif. Si des messages se trouvent dans la file d’attente (C), nous atteignons le plus récent. Si son tampon horodateur est différent de celui du message que nous avons sauvegardé en dernier, nous obtenons le texte de messages de premier niveau de ce nouveau message (D).
En E, s’il y a du texte dans le texte de premier niveau, nous rechargerons d’abord notre vue (F). Ensuite, si nous voulons être alertés, nous vérifions si la gravité de ce message est celle que nous souhaitons ou supérieure (G). Si la première et la seconde condition sont vérifiées, nous affichons une boîte qui nous informe du nouveau message.

Le travail étant fait, en H nous pouvons terminer notre job. Mais, avant cela, nous en générons un nouveau en appelant récursivement la méthode qui enveloppe ce Runnable. Un intercepteur (catcher) captera les éventuelles erreurs et nous en informera dans la vue en I. Cette définition du Runnable ne fera rien parce que nous devons d’abord le soumettre. Ce que nous faisons en J.

Pour tester notre application, lancez une application Eclipse à partir de l’éditeur manifest et ouvrez la perspective RSE. Ensuite, ouvrez notre vue (Window/Show View/Other) et ouvrez Other dans l’arbre. Notre vue doit s’y trouver. Ouvrez-la et – ceci est très important – sélectionnez l’un de vos noeuds System i à partir de la vue RSE. Notre vue réagira à une sélection dans la vue RSE.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 06 juin 2012