Bonjour,

Un peu de background:
- nous avons un serveur applicatif qui tourne sur WebSphere 6.1
- tous les services sont basés sur des message XML qui arrivent sortent par des files (queues) MQ (IBM)
- le serveur prend en entrée un message, se connecte au middleware (Tuxedo 9) pour effectuer des modifications dans la base de donnees (Oracle 11gR2) selon le contenu du message
- Tuxedo, les services Tuxedo et une API Java qui fourni une interface Java pour les services Tuxedo est fournie par un 3rd party.

Nous avons une suite de tests qui consistent a injecter directement le message XML dans le code du serveur d'application (ie on peu executer les tests localement sans server d'application), valident les modifications dans la base de donnees (via les service Tuxedo via API Java), et rollback la transaction, de facon a ce que les tests soient repetables.

On est en train d'upgrader WebSphere vers v8.5, et on voudrais re-utiliser toute cette collection de tests pour etre sur que le changement de server d'application n'a rien cassé au passage... mais comme dis dans le paragraphe précédent, les tests sont executés hors du serveur WebSphere (seul notre code est testé). C'est pas trop compliqué de changer le code pour envoyer le message vers MQ a la place de l'injecter directement, mais le probleme est alors de valider que le message a bien fait ce qu'il est censé faire car soit:

- la transaction sur le serveur d'application est "commit" et alors le client test peut voir ce que le serveur a fait et valider, mais les tests ne sont pas repetables
- la transaction sur le serveur d'application est "rollback" et alors le client test n'a aucune visibilite sur ce qu'a fait l'appserveur et ne peut donc rien valider.

Mon idée est d'une facon ou d'une autre d'utiliser des transaction distribuées (XA?) qui permettraient a plusieurs "clients" de rejoindre la meme transaction... mais je ne suis pas sur que cela soit possible!

L'API Java qui interface avec Tuxedo nous fourni seulement un objet qui implemente javax.resource.cci.LocalTransaction, qui ne fourni que start() commit() et rollback(); je ne vois donc pas trop comment, a partir de la, le forcer a rejoindre une transaction commencée ailleurs...

Remettre les donnees dans leur etat initial apres chaque test n'est pas vraiment une option vu que le seul moyen est de tout recharger ce qui prend 20-30 min; on ne sais pas exactement ce que modifie chaque test, et avec plusieurs milliers ca prendrais un temps fou a analyser/coder!

Je suis ouvert a toutes suggestions pour resoudre ce probleme