Pourquoi les performances des rapports Business Central se dégradent-elles avec le temps ?
Les performances des rapports Business Central se dégradent à mesure que la base de données s'étoffe. Des rapports qui s'exécutaient en quelques secondes lors de la mise en service prennent plusieurs minutes un an plus tard. Après deux ou trois ans d'accumulation de transactions, les plus lents finissent par expirer. La cause est d'ordre structurel, et aucun réglage au sein de l'ERP ne permet de combler ce retard.
Qu'est-ce qui ralentit les performances des rapports Business Central ?
BC génère des rapports natifs via RDLC, le langage de mise en page de rapports côté serveur de Microsoft. RDLC a été conçu pour les sorties paginées à mise en page fixe. Dans les conseils de dépannage fournis par Microsoft aux développeurs, il est recommandé d'utiliser les mises en page Word pour les rapports documentaires, car les mises en page RDLC offrent des performances moins bonnes. Les équipes financières qui génèrent des comptes de résultat sur douze mois glissants pour plusieurs entités avec des ventilations dimensionnelles personnalisées sollicitent RDLC bien au-delà de ce pour quoi il a été conçu.
Quatre problèmes se cumulent. Les tables « G/L Entry », « Dimension Set Entry » et « Item Ledger Entry » s’enrichissent de millions de lignes chaque année, et la plupart des rapports les parcourent directement plutôt que de s’appuyer sur une couche pré-agrégée. Les dimensions qui ne font pas partie des deux dimensions globales de BC ni des huit dimensions de raccourci ne figurent pas dans les tables de registres sous forme de colonnes indexées ; elles sont résolues via la structure « Dimension Set Entry », ce qui implique une jointure supplémentaire pour chaque filtre. Les extensions AL ajoutent une logique séquentielle aux objets de rapport de base, chaque extension générant une surcharge qui s'accumule tout au long de l'exécution, un schéma que Microsoft documente dans ses conseils de performance destinés aux développeurs. Et le reporting multi-sociétés natif de BC itère à travers les données de chaque société plutôt que de lire à partir d'un agrégat partagé, de sorte que les rapports inter-entités multiplient le travail sous-jacent.
Le serveur SQL sous-jacent à BC est optimisé pour les charges de travail pour lesquelles BC a été conçu : saisie d'écritures, validation de documents, traitement par lots. Un rapport à cinq dimensions sur douze mois couvrant trois entités constitue une charge de travail différente, et la même base de données n'est pas optimisée pour cela.
La plupart des environnements BC se heurtent à ce problème vers le 18e au 24e mois. À ce stade, le grand livre général contient déjà deux exercices complets de données détaillées, le balisage dimensionnel a été étendu à plusieurs reprises et une série de personnalisations ont été intégrées aux rapports de clôture. Les rapports ne s’exécutent plus à temps pour les réunions pour lesquelles ils ont été conçus.
La mise à l'échelle des ressources informatiques présente des rendements décroissants
La première réaction face à un rapport trop lent consiste généralement à demander davantage de ressources de calcul. Microsoft optimise l'infrastructure de BC Online, et la configuration des locataires offre une certaine marge de manœuvre. Les gains s'estompent rapidement. Doubler la capacité de la couche de base de données ne réduit pas de moitié le temps d'exécution, car le goulot d'étranglement réside dans le plan de requête et le pipeline RDLC, et non dans la puissance brute du processeur.
La fonctionnalité « Read Scale-Out » d'Azure SQL, utilisée par BC Online pour acheminer les charges de travail en lecture seule vers une réplique secondaire, s'avère utile pour certaines requêtes. Le hic, c'est qu'elle ne s'applique qu'aux objets explicitement marqués avec la propriété DataAccessIntent définie sur ReadOnly, et même dans ce cas, Microsoft précise que ce paramètre « ne garantit pas que l'accès à vos données s'effectuera sur la réplique secondaire ». Les rapports modifiés par des extensions perdent souvent la classification ReadOnly et reviennent à la réplique principale. L'optimisation des performances au niveau du tenant ne comble que rarement qu'une petite partie de l'écart, et les coûts d'hébergement augmentent au cours du processus.
Les « Analysis Views », fonctionnalité de BC à laquelle les utilisateurs ont souvent recours à ce stade, sont utiles pour des cas d'utilisation spécifiques. Elles précalculent des agrégats par rapport à un ensemble de dimensions défini, ce qui permet aux pages et aux rapports d'analyse de fournir des résultats sans avoir à réexécuter l'analyse du grand livre. Les structures sont fixes, les options de mise en page sont plus limitées que ce dont les équipes financières ont besoin pour les dossiers destinés au conseil d'administration ou les états financiers formatés, et les Analysis Views ne réécrivent pas les données dans BC. Elles gèrent les vues agrégées ; la flexibilité du reporting reste un problème distinct.
Quand les performances des rapports Business Central s'améliorent
L'importation des données dans Excel via l'API REST et les services Web OData de BC permet d'éviter le recours à RDLC. Les tables SQL et les données restent dans BC. Le moteur de calcul d'Excel se charge du rendu localement, sur l'ordinateur de l'utilisateur, à partir des données déjà extraites par l'API.
L'actualisation s'effectue sur le processeur local ; ainsi, une actualisation lente n'entraîne pas de file d'attente pour les autres utilisateurs. La mise en page des rapports n'est plus limitée par les capacités du langage RDLC, ce qui élimine toute une série de solutions de contournement que les équipes financières mettaient en place depuis des années pour rendre les rapports exploitables. Les dimensions sont désormais des formules de cellule, ce qui permet à un contrôleur de créer un tableau croisé dynamique à cinq dimensions sans avoir à envoyer de ticket au partenaire. L'actualisation peut également être planifiée et distribuée: le classeur se met à jour pendant la nuit, le PDF est déposé dans un dossier SharePoint, et le directeur financier ouvre un rapport à jour au lieu d'attendre qu'il s'exécute.
C'est cette même approche que FRx et Management Reporter ont adoptée pendant deux décennies dans l'univers GP. Microsoft a mis fin au support de ces deux produits : FRx 6.7 a atteint la fin de son cycle de vie, suivi par Management Reporter. L'article publié en février sur les solutions de remplacement de FRx expliquait pourquoi les clients GP ressentent un vide lors de la migration. C'est cette même cause architecturale qui est à l'origine du déficit de performances une fois que l'environnement BC arrive à maturité : la couche de reporting native n'a jamais été conçue pour les volumes de données et la complexité des rapports que les équipes financières produisent aujourd'hui.
Diagnostic
Le diagnostic commence par le comptage des lignes. Les entrées du grand livre, les entrées de jeux de dimensions et les entrées du registre des articles sont les principales sources de problèmes, et tout dépassement de quelques millions de lignes alourdit le coût de chaque rapport qui les utilise. Les extensions AL constituent le prochain élément à examiner, car elles s'intègrent successivement aux objets de rapport de base et chacune d'entre elles ajoute une latence proportionnelle à sa complexité. La troisième question porte sur le nombre d'entités regroupées par un seul rapport : le coût de la requête augmente de manière à peu près linéaire avec le nombre de sociétés.
Ne manquez pas notre prochain article, qui abordera la consolidation multi-environnements, où les problèmes de performances s'aggravent et où les outils natifs de BC atteignent leurs limites.
Velixo relie directement Excel à Business Central via l'API v2 et des services Web, gère les jointures de dimensions et les requêtes multi-entités sur l'ordinateur de l'utilisateur, et prend en charge la distribution programmée de rapports par e-mail, SharePoint et Microsoft Teams. Les équipes financières l'utilisent pour maintenir à jour les rapports de clôture et pour répertorier les budgets, les écritures comptables et les prévisions dans Business Central à partir du même classeur, grâce à la fonctionnalité de répertorisation universelle de Velixo. En savoir plus sur Velixo pour Business Central.