Après un premier flux construit de zéro avec Boomi Companion, on l’a confronté à un exercice plus exigeant : reprendre un existant.
Le cas : un job Talend en production depuis des années. Il fait une synchronisation incrémentale entre deux bases, avec curseur delta, gestion d’erreur, suivi d’exécution et contrôle de cohérence.
L’agent n’est pas parti à l’aveugle. On lui a fourni une table de correspondance des composants Talend vers Boomi (tDBInput, tMap, tJavaRow…), un guide de migration en deux phases (comprendre, puis construire) et les conventions du projet : nommage, briques partagées, patterns de process.
Ces documents condensent des années de pratique sur les deux plateformes. Companion les a lui-même rédigés, mais c’est l’équipe qui en a décidé le contenu : quelles correspondances retenir, quels pièges signaler, quels patterns imposer. Et ils se réutilisent : le prochain job Talend partira de la même base, et chaque migration enrichira la table.
Companion a poussé 21 composants sur le tenant, conformes à notre framework : nommage, briques partagées, patterns de process. Ce type de reprise se compte habituellement en jours. Ici, la construction a pris quelques minutes. La relecture, les ajustements et les tests ont ramené l’ensemble sous la journée.
On l’a depuis confronté à une série plus large de jobs : sur chacun, environ 80 % de ce qu’il produit est juste dès la première passe. L’effort de l’équipe se concentre alors là où il compte, sur les tests et les cas complexes.
Le vrai gain n’est pas la vitesse de génération. C’est d’avoir formalisé notre savoir-faire au point qu’un agent puisse l’appliquer.
Deux enseignements concrets :
Traduire n’est pas migrer. Reproduire Talend composant par composant, c’est en reproduire les défauts. Pour savoir s’il fallait insérer ou mettre à jour, le job chargeait toute la table cible en mémoire (LOAD_ONCE). Plus la table grandissait, plus chaque exécution s’alourdissait, même pour quelques lignes modifiées. Dans Boomi, un MERGE SQL laisse la base faire ce travail.
La relecture arbitre. Face à deux logiques de suivi, Companion a d’abord privilégié notre framework, au détriment des tables de suivi historiques du job. Or les équipes les consultent. Elles restent donc alimentées, via des sous-process partagés que les prochains flux migrés réutiliseront. Le framework s’ajoute, il ne remplace pas.