Je travaille avec Oracle EBS depuis plus de 18 ans, ayant connu l'évolution complète de la version 11i à R12. Tout au long de cette longue carrière, le développement de rapports personnalisés a toujours été une responsabilité centrale incontournable. Autour de ce travail, certains problèmes sont apparus année après année sans jamais être fondamentalement résolus.
Je travaille avec Oracle EBS depuis plus de 18 ans, ayant connu l'évolution complète de la version 11i à R12. Tout au long de cette longue carrière, le développement de rapports personnalisés a toujours été une responsabilité centrale incontournable. Autour de ce travail, certains problèmes sont apparus année après année sans jamais être fondamentalement résolus.
Cet article n'a pas pour but de raconter une histoire. Il vise simplement à documenter honnêtement les problèmes que j'ai observés et vécus au fil des ans, ainsi que les tentatives que j'ai faites pour y remédier. J'espère qu'il pourra servir de référence aux professionnels confrontés à des défis similaires.
Dans l'écosystème EBS, il existe un ensemble de procédures fixes entre l'achèvement de l'écriture SQL et le moment où un rapport devient exécutable par les utilisateurs finaux. Ce processus est raisonnable et nécessaire dans le cadre de la conception d'EBS—il garantit la sécurité, l'isolation multi-organisations, la validation des paramètres et la planification des demandes. Cependant, du point de vue de l'efficacité du développement, son coût est effectivement élevé.
Plus précisément, après avoir terminé l'écriture et les tests SQL, les développeurs doivent effectuer séquentiellement les opérations suivantes :
Ces étapes n'impliquent pas de logique métier complexe—ce sont purement des tâches de configuration. Mais pour un rapport simple, probablement ponctuel, le coût de démarrage de ce processus est excessivement élevé. Un rapport dont le SQL ne prendrait que 20 minutes à écrire nécessite souvent plus d'une heure pour parcourir l'ensemble du processus, la majeure partie du temps étant consommée par la navigation dans les menus, le remplissage des champs et l'attente des réponses de la page.
Plus critique encore, si le rapport nécessite des ajustements de la logique SQL ou des définitions de paramètres après les tests, une partie considérable des étapes ci-dessus doit être répétée. Cela représente un goulot d'étranglement significatif pour les scénarios de développement nécessitant une itération rapide.
C'est ce que je considère comme le problème central, et celui qui impacte le plus l'expérience utilisateur.
Le format de sortie natif des programmes concurrents EBS est un fichier texte (généralement .out ou .txt). Qu'il s'agisse d'un rapport .rdf développé avec Report Builder ou de la sortie d'une procédure stockée PL/SQL, ce qui est finalement livré aux utilisateurs est essentiellement un texte à largeur fixe ou délimité par des séparateurs.
Cependant, ce dont les utilisateurs métier ont besoin dans leur travail quotidien est, presque sans exception, des fichiers de données au format Excel. Cela crée une "étape intermédiaire" qui existe depuis longtemps : les utilisateurs doivent copier et coller le contenu du fichier texte dans Excel, puis utiliser la fonction "Convertir" pour le diviser en plusieurs colonnes.
Cette étape implique plusieurs problèmes techniques spécifiques :
Premièrement, les problèmes de largeur de champ. Les développeurs de rapports doivent prédéfinir une largeur d'affichage pour chaque champ de sortie. Si la longueur réelle des données d'un champ dépasse cette largeur prédéfinie (par exemple, les champs de texte libre comme les descriptions d'articles ou les noms de fournisseurs), EBS le traite par un retour à la ligne automatique, insérant un caractère de saut de ligne dans le fichier texte. Ce saut de ligne semble normal dans un visualiseur de texte—le contenu est simplement affiché sur une nouvelle ligne. Mais lorsque les utilisateurs copient l'intégralité du texte dans Excel et effectuent la conversion, Excel reconnaît ce saut de ligne comme un terminateur de ligne, ce qui entraîne la division incorrecte d'un seul enregistrement en deux lignes ou plus. L'alignement des colonnes de tous les enregistrements suivants devient complètement corrompu. Les utilisateurs doivent localiser et corriger manuellement ces erreurs, ou réajuster les largeurs de champ du rapport et soumettre à nouveau la demande.
Deuxièmement, les problèmes d'encodage des caractères. Le format d'encodage par défaut du fichier texte ne correspond souvent pas à l'encodage par défaut d'Excel pour l'ouverture des fichiers. Cela est particulièrement problématique lors du traitement de caractères multi-octets tels que le chinois ou le japonais, ce qui entraîne fréquemment des textes illisibles. Les utilisateurs doivent sélectionner manuellement le bon encodage lors de l'ouverture du fichier texte, ou spécifier le format d'encodage lors de l'importation dans Excel. Pour les utilisateurs métier non techniques, c'est un fardeau supplémentaire et inutile.
Troisièmement, le traitement des formats de nombres et de dates. Les nombres et les dates exportés dans les fichiers texte sont généralement au format texte brut. Après les avoir collés dans Excel, les utilisateurs doivent définir manuellement les formats de cellule avant de pouvoir effectuer des calculs tels que des sommes ou des moyennes. Lorsque des séparateurs de milliers, des précisions décimales ou des formats d'affichage de date sont impliqués, des étapes de réglage manuel supplémentaires sont nécessaires.
Quatrièmement, l'efficacité du traitement avec de grands ensembles de données. Lorsqu'un rapport renvoie un grand volume de données (par exemple, plus de 10 000 lignes), l'opération de copier-coller plus de division manuelle des colonnes devient elle-même très chronophage. De plus, les performances d'Excel lors du collage de grandes quantités de texte ne sont pas toujours stables, entraînant souvent des ralentissements ou des absences de réponse.
Ces problèmes sont répandus à la fois dans les rapports standard d'EBS et dans les rapports personnalisés. Strictement parlant, ce n'est pas un "bug"—c'est un choix de conception de l'époque où EBS a été créé, lorsque la sortie texte était la méthode dominante pour l'échange de données entre plates-formes. Mais dans l'environnement commercial d'aujourd'hui, ce choix de conception est gravement déconnecté des scénarios d'utilisation réels des utilisateurs.
Les services métier génèrent fréquemment des besoins d'analyse de données non périodiques dans leurs opérations quotidiennes. Par exemple :
Les caractéristiques de ces exigences sont : une logique SQL relativement claire, un périmètre de données limité, des exigences de rapidité élevées et une forte probabilité d'utilisation unique sans récurrence.
Dans le chemin de développement standard d'EBS, même un rapport ponctuel doit passer par le processus d'enregistrement complet, de la définition d'un exécutable à son montage dans un groupe de demandes. Cela signifie que les développeurs doivent répéter des tâches de configuration sans rapport avec la logique métier chaque fois qu'ils répondent à de telles demandes ponctuelles.
Une autre solution de contournement courante consiste pour les développeurs à exécuter SQL directement dans des outils de base de données (tels que PL/SQL Developer ou Toad), à copier les résultats et à les envoyer aux utilisateurs dans Excel. Cette approche contourne le processus d'enregistrement d'EBS et est nettement plus rapide, mais elle élude le contrôle d'accès multi-organisations et la validation des autorisations de données d'EBS, introduisant des risques potentiels pour la sécurité des données. Elle ne peut pas non plus tirer parti du gestionnaire concurrent pour une planification et une journalisation unifiées.
Les problèmes décrits ci-dessus ne sont pas nouveaux. En fait, au sein de la communauté des utilisateurs d'EBS et des cercles de praticiens, ces difficultés sont depuis longtemps un secret de polichinelle. Cependant, au fil des ans, les solutions de l'industrie se sont principalement concentrées sur les approches suivantes, toutes d'efficacité limitée :
Aucune de ces approches ne change fondamentalement le modèle de développement des rapports EBS. Les développeurs doivent toujours investir des efforts à la fois au niveau de l'écriture SQL et de la configuration système, et les utilisateurs doivent toujours consacrer du temps supplémentaire à l'acquisition et au nettoyage des données.
Sur la base des problèmes ci-dessus, j'ai tenté de construire une couche d'outil de reporting indépendante, nommée SQLVantage. Son positionnement n'est pas de remplacer le gestionnaire concurrent d'EBS, mais plutôt de servir de couche de réponse rapide complémentaire couvrant les scénarios suivants :
La philosophie de conception centrale de cet outil est : éliminer le travail procédural le plus chronophage et sans rapport avec la logique métier dans le développement de rapports EBS, permettant aux développeurs de se concentrer directement sur les deux éléments essentiels—SQL et la configuration des paramètres.
L'approche spécifique est la suivante :
Du côté du développement, les développeurs n'ont qu'à remplir le nom du rapport, écrire l'instruction SQL et définir les paramètres de requête (nom du paramètre, type de données, libellé d'affichage, valeur par défaut) dans l'outil. Après l'enregistrement, le rapport est immédiatement disponible. Il n'est pas nécessaire de définir un exécutable, d'enregistrer un programme concurrent, de configurer des ensembles de valeurs ou de monter des groupes de demandes. L'ensemble du processus de configuration peut être complété en 3 à 5 minutes.
En matière de sécurité des données, l'outil réutilise le mécanisme d'authentification des utilisateurs d'EBS, garantissant que seuls les utilisateurs disposant des responsabilités EBS appropriées peuvent accéder aux rapports et les exécuter. La logique de contrôle d'accès multi-organisations (MOAC) impliquée dans les requêtes SQL reste dans les instructions SQL elles-mêmes, contrôlée par les développeurs en fonction des exigences métier réelles.
En matière de format de sortie, l'outil génère directement des fichiers Excel .xlsx. Chaque champ de résultat de requête correspond à une colonne Excel, et chaque ligne de données correspond à une ligne Excel. Les largeurs de champ sont automatiquement adaptées au contenu, et les longs textes ne provoquent pas de sauts de ligne qui corrompraient les données. Les nombres, les dates et autres types de données conservent leurs attributs de type d'origine lors de l'exportation, permettant aux utilisateurs de trier, filtrer et effectuer des calculs directement à l'ouverture du fichier Excel.
En matière d'extensibilité, en plus d'Excel, l'outil prend également en charge la sortie au format JSON, facilitant l'intégration avec des plates-formes de données externes ou des systèmes BI.
Après une période d'utilisation interne, cet outil a effectivement apporté des améliorations d'efficacité dans les domaines suivants :
En même temps, je dois également souligner les limites de cet outil :
Depuis 18 ans, EBS est une plate-forme applicative de niveau entreprise dont la stabilité et la rigueur architecturales fondamentales sont indiscutables. Mais précisément à cause de cette stabilité, certains choix de conception qui étaient raisonnables à leur époque semblent lents et encombrants dans les scénarios d'utilisation d'aujourd'hui.
Le coût du processus de développement des rapports, le format de sortie basé sur du texte, le chemin de réponse pour les besoins ponctuels—ces problèmes n'ont pas émergé uniquement aujourd'hui. C'est simplement que dans l'environnement actuel, leurs coûts sont devenus plus évidents. Les rythmes commerciaux s'accélèrent, les exigences des entreprises en matière de réactivité des données augmentent, et les outils et processus que nous utilisons restent figés dans une époque révolue.
SQLVantage est une tentative que j'ai faite sur la base de ces problèmes. Ce n'est pas vraiment une innovation, mais plutôt une simplification et une réorganisation des processus existants. Si cet article peut trouver un écho chez certains professionnels, ou fournir une perspective de référence à ceux qui réfléchissent à des problèmes similaires, il aura atteint son objectif.
En écrivant ceci, je n'ai pas l'intention de le présenter comme une "histoire de réussite". C'est simplement quelqu'un qui a été répétitivement confronté à des problèmes spécifiques dans des scénarios de travail spécifiques, essayant d'améliorer ces problèmes à sa manière. Quant à la distance que cette voie peut parcourir, elle doit encore être continuellement testée dans la pratique. Mais au minimum, la direction est bonne—laisser les développeurs revenir au SQL lui-même, laisser les utilisateurs revenir aux données elles-mêmes, et laisser l'outil gérer les choses inutiles entre les deux.