Il y a plusieurs mois alors que je devais créer un 2° domaine d’administration sur une plateforme existante pour des besoins d’intégration.
Il s’agissait plutôt d’une tâche simple estimée à moins d’une journée pour être très large. Juste le temps de mettre à jour et exécuter le scripts domainutilitycmd avec le fichier CreateDomain.xml.
Go ou noGO
Le jour de l’intervention, je commence par vérifier les préconditions, base de données et TIBCO EMS et ensuite je teste avec succès mon script sur un poste local. Je suis donc confiant et j’annonce la disponibilité du nouveau domaine pour la fin de la matinée. Côté dev, les applications sont prêtes et n’attendent que le GO pour le déploiement.
L’exploitation lance le script d’exécution du domaine. Aussitôt le script lancé, l’exécution se termine avec des erreurs. En ce moment je me dis que alors que l’une des préconditions ne doit pas être vérifiée. La base de données est bien accessible, le schéma prévu pour le nouveau domaine ne contient pas de table, l’instance EMS est démarrée et Running, les utilisateurs ont tous les droits. Les informations du fichier CreateDomain.xml sont OK. Et pourtant la 2° exécution se termine exactement comme la première. Après 5 tentatives avec exactement le même résultat, Je ne tiens pas à ma promesse et obligé de faire décaler les déploiements. Les prérequis sont OK, tous les indicateurs sont OK, on se tourne vers le support TIBCO qui nous demande de désactiver l’autocommit. Chose faite, nouvelle tentative encore KO.
Toutes les suggestions du support ne nous aident pas à avancer. On y passe des heures, des jours et l’erreur ne change pas. Ce qui n’est pas étonnant car tant que tu ne changes pas d’input, ne t’attends pas à ce que l’output soit différente.
On contourne, mais on avance
Finalement on décide d’effectuer manuellement une partie des actions qui sont normalement effectuées par domainutilitycmd, c’est-à-dire la création de l’ensemble des tables du domaine. De fait l’exécution du script s’arrêtait à la création de 14 tables sur une cinquantaine. De cette façon on a pu créer un 2° domaine et installer les applications, seulement j’ai eu le sentiment d’avoir loupé quelque chose et je me suis gardé cela parmi les actions à refaire un jour. Si vous ne faites par la lumière sur un doute que vous avez aujourd’hui, un jour, vous rencontrerez le même problème sur votre chemin.
Hier j’ai donc décidé plusieurs mois après de reprendre le problème que j’avais rencontré sur la création d’un 2° domaine d’administration TIBCO BW5. Pour être certains de ne rien louper cette fois, j’ai configuré un environnement équivalent et effectué une dizaine de tests d’exécution du script. Puis j’ai commencé à procéder par élimination. Je vous épargne tous les détails.
Finalement je comprends
Le problème est lié à l’exécution du script TIBCO domainutilitycmd dans le cas d’une base de données PostgreSQL sur un schéma non public. Dans mon cas, j’avais un 1° domaine qui était déjà créé sur le schéma public. Je souhaitais donc créer le 2° domaine sur le schéma jdbc:postgresql://HOSTNAME:5432/TIBCO?currentSchema=tibcodomain2, cette erreur qui n’est pas très claire lorsque vous l’avez peut vous faire perdre des jours et des jours. Il n’est pourtant mentionné nulle part de ne pas avoir plusieurs schémas par base de données.
