TIBCO BW6 debugging step by step
L’objectif de ce tutoriel est de découvrir l’environnement studio et la perspective debug les fonctionnalités offertes par OSGi.
Pour commencer, nous allons considérer un projet TIBCO BW6 sur Studio.
Description du projet
Il s’agit d’un projet qui se déclenche automatiquement par une activité starter, qui lit un fichier XML sur un répertoire dédié et écrit les informations contenues dans ce fichier dans une base de données PostgreSQL. Avant l’écriture en base, une activité ParseXML est utilisée pour extraire le contenu du fichier et validé en même temps les informations à écrire en base. Dans le projet, plusieurs logs sont positionnés pour suivre l’évolution du traitement.
Pour commencer, considérons donc que le projet à peine décrit, qui est représenté par 7 activités et ouvrons dans un premier temps la perspective debug.
Pour commencer, considérons donc le projet ci-dessus représenté par 7 activités et ouvrons la perspective debug.
Contrairement à la perspective Design où on a principalement des informations sur le projet et le process en cours de création, la vue debug nous montre des informations qui permettent de suivre l’exécution du flux étape par étape. C’est exactement le même fonctionnement que Eclipse pour les applications JAVA.
- Breakpoints : ce sont les différents points d’arrêt positionnés dans le flux
- Variables : il s’agit des activités
- Job Data
- Console pour les logs
- La vue Editor montre le flux
Généralement le debug est effectué pour examiner de prêt l’exécution d’un process et pouvoir apprécier le comportement de chaque activité. On peut par exemple observer les données en entrée et sortie de chaque activité dans le cas où c’est prévu. Dans ce processus TIBCO studio tout comme Eclipse permet d’examiner aussi bien les process Père que les sous process ou process enfants.
Avec la vue que nous venons de voir, il est possible d’effectuer un debug tout simple, comme aussi nous pouvons effectuer une analyse complète du comportement de notre flux, et même de l’environnement d’exécution.
Utilisation des points d’arrêt ou breakpoints
Les breakpoints comme son nom l’indique sont des points d’arrêt dans l’application. Ils peuvent être positionnés sur les activités soit avant une activité soit juste après une activité. Pour ce faire il suffit de positionner le curseur sur une activité et de cliquer sur le bouton droit de la sourie, puis sélectionner Breakpoint ==> Set Before ou Set After ou les deux.
Voici les breakpoints que j’ai positionné sur le projet que je vous ai présenté.
Les breakpoints sont positionnés sur les activités comme suit :
- ReadFile : Breakpoint befor et breakpoint after
- ParseXml : breakpoint after
- JDBCUpdate : breakpoint before
Exécution en mode debug
Une fois que nous avons positionné les brekpoints nous pouvons exécuter notre projet en mode debug et observer finement le comportement des activités.
Pour exécuter le projet en mode debug, voici les étapes
- Sur le menu de Studio cliquez sur RUN puis sélectionnez DEBUG CONFIGURATION (vous pouvez utiliser aussi directement le raccourci prévu pour le mode debug)
- Sur le menu à gauche de la fenêtre de debug, selectionner votre application BW qui se trouve juste au-dessous de BusinnessWorks Application.
L’application démarre normalement et attend le premier déclenchement. Dans le cas de notre exemple le déclencheur c’est une activité TIMER. Une fois l’application déclenchée, le traitement reste en attente d’instruction sur le premier breakpoint (activité ReadFile) que nous avons positionné.
Grâce aux les fonctions Step return (F7), Step over (F6), Step into (F5), Resume (F8) vous pouvez continuer le test ou alors aller dans les sous process pour voir les variables et valeurs de ces derniers.
Pour aller plus loin, la console OSGi
Avec TIBCO BusinessWorks 6, il arrive parfois que lors du démarrage d’une application ou lors d’un déploiement, on se retrouve avec une application en statut « Impaired ». Les causes peuvent être nombreuses et surtout lorsque l’application est compilée correctement ne montre aucune erreur. Alors pourquoi on se retrouve dans cette situation ? Rappelez vous le principe du « fail safe » de l’OSGi. Quand le code ne comporte pas d’erreur, le plus simple est d’activer la console OSGi. Pour ce tutoriel, nous allons juste voir les commandes pour naviguer la console sur Studio. les étapes sont donc les suivantes:
- démarrez votre application comme d’habitude.
- sur la console, écrivez <<la>> et tapez ENTREE pour avoir toutes les applications
- <<lr>> liste les ressources de votre application, si une ressource pose problème vous aurez alors l’explication de votre statut « Impaired ».
Liste complète des commandes TIBCO OSGI
Ce tutoriel est maintenant terminé. Merci de l’avoir suivi jusqu’à la fin. N’hésitez pas à me laisser un commentaire pour vos suggestions. Si vous souhaitez obtenir l’archive de ce projet, n’hésitez pas à m’envoyer votre demande. A très bientôt pour un nouveau tutoriel TIBCO BusinessWorks 6.
@Dieudonné MIAFFO – A la base je suis ingénieur informaticien de formation, avec une solide culture générale de l’informatique et un goût très prononcé pour les évolutions des systèmes d’information.
Je suis passionné par l’évolution technologique et c’est tout naturellement que j’exerce mon métier d’Architecte Expert ESB.
Je suis diplômé de SUPELEC et depuis 2012 j’interviens sur différents projets de transformation digitale. Nous accompagnons les entreprises en les aidant à tirer le meilleur de leur système d’information.
Mes sujets d’intérêt concernent principalement les ESB | API et la Cybersécurité.
