Je n’ai aucun document à partager sur ces boucles imbriquées, et je ne fais plus partie de l’équipe de projet, donc tout ce que je peux en dire est hors de ma tête. J’espère donc que vous comprendrez pourquoi je ne peux pas dire trop de détails ici.
Fondamentalement, j’ai dû effectuer trois types de recherche différents sur la même table pour une règle dite personnalisée dans le logiciel de gestion des données de test (TDM). Ces règles personnalisées sont implémentées sous forme de mapplets, et elles doivent contenir uniquement des transformations passives. Pas de routeurs, pas de filtres, pas d’agrégateurs, pas de transformations Java actives, seulement des expressions, des transformations de recherche, etc.
Maintenant, pour les deux règles personnalisées les plus complexes, j’ai dû implémenter plusieurs tables auxiliaires contenant ces données de recherche à différents niveaux d’agrégation. Remplir ces tables à partir de PowerCenter n’était pas trop facile car le fichier source se compose de 4,5 Go de texte (app. 43 millions d’enregistrements); les tables de recherche contiennent des données à trois niveaux d’agrégation différents avec des critères de recherche différents. Et je ne voulais pas diviser la cartographie en trois. J’ai donc dû prendre soin de l’identification de l’enregistrement basé sur « le même » par moi-même, je ne pouvais pas utiliser d’agrégateurs seuls.
Pour autant que je me souvienne, dans un langage de programmation traditionnel comme Java, j’aurais eu besoin de jusqu’à cinq boucles imbriquées pour analyser les données source et créer les enregistrements de recherche respectifs à partir de ces données d’entrée. L’exécution de différents niveaux d’agrégation avec plusieurs ports variables dans un seul EXP n’est pas trop facile à maintenir, mais mes premiers essais ont révélé que c’était toujours le meilleur choix; comme mentionné, j’aurais pu diviser le mappage en trois, mais chaque mappage aurait eu presque le même niveau de complexité que le seul EXP « général », donc je n’ai pas considéré que cela valait la peine de maintenir trois chemins de chargement différents dans ce mappage.
Je suis convaincu que tout le monde ayant une certaine expérience dans PowerCenter peut – après réflexion – proposer une histoire similaire d’exigences de cartographie non triviales de sa propre pratique. Nous ne sommes peut-être même pas conscients d’une telle complexité, mais elle est toujours là.
À titre d’exemple, prenez un thread de 2014 ou 2015 où quelqu’un a demandé comment générer des nombres premiers dans PowerCenter. Pas trop facile. Celui qui construit une telle solution doit penser (et travailler) en dehors des chemins connus. C’est sans aucun doute une réalisation extraordinaire dans PowerCenter. Ce n’est donc peut-être pas un grand exemple, mais cela peut être un bon exemple de logique de mappage plus complexe.
Comme autre exemple, regardez n’importe quel système pour coordonner l’exécution des flux de travail dans un certain ordre. Peut-être avec quelques conditions supplémentaires, telles que « nombre d’enregistrements dont la propriété XYZ est égale à la valeur ABC ». Toutes ces choses peuvent devenir arbitrairement complexes, et – comme mentionné ci-dessus – je suis convaincu que beaucoup de gens ont construit quelque chose de similaire une ou plusieurs fois, même s’ils ne l’ont pas reconnu.