Expertises et services

Méthodologie de gestion du risque performance dans le cadre des projets d’implémentation de Business Central

Christophe COURVOISIER11/01/2024

Accéder à la version anglaise

Dans le contexte dynamique des systèmes ERP en constante évolution, garantir des performances optimales durant la mise en place de Business Central représente un défi majeur. Ceci s'avère particulièrement critique dans des projets d'envergure impliquant un nombre considérable d'utilisateurs. Les performances exercent une influence directe sur l'efficacité des processus métiers, et ce risque est amplifié lorsque Business Central est customisé.

Vous êtes chef de projet Business Central ou architecte solution ? Je vous propose des solutions à des problématiques que vous rencontrez certainement chez vos clients, ou en interne, en tant que responsable. Mon expérience chez COSMO CONSULT, et les différentes situations rencontrées, m’ont amené à développer une méthode en quatre parties. J'ai constaté des gains significatifs en termes de charges, de risques, de non-régressions, d’anticipation, d’impacts sur les équipes projets. À chaque étape, j’explique l’impact sur la performance intrinsèque.

Cet article propose le détail de cette méthode pour sécuriser les performances lors de chaque phase d’un projet d’implémentation.

Elle se compose de plusieurs étapes :

  1. Mise en place d’une infrastructure pour lancer les tests de performance de manière automatique
  2. Monitorer la phase de développement avec un ensemble de tests standards
  3. Développer des tests de performance représentatifs de l’activité future de l’entreprise sur Business Central
  4. Tests de performances finaux dans le but de valider la solution

1. Mise en place de l’infrastructure pour lancer les tests de performance de manière automatique

Le lancement des tests de performance sur une sandbox Business Central peut être facilement automatisé avec un pipeline Azure Devops. Voici le schéma de principe :

Ci-dessous un exemple de code yaml sur un pipeline Devops :

 trigger:none
 schedules:
 -cron:"01***"
  displayName:Daily midnight build
  branches:
    include:
    -master
  always:true
 variables:
  -group:'PerformanceTestingAutomate'
 jobs:
 -job:RunPerformance
  pool:
    vmImage:'windows-latest'
  steps:
  -task:PowerShell@2
    displayName:'RunPerformanceTestonTargetSandbox"$(SandboxName)"'
    inputs:
      targetType:filePath
      filePath:$(System.DefaultWorkingDirectory)/RunBCPTTests.ps1
      arguments:'-Environment"$(Environment)"-AuthorizationType"$(AuthorizationType)"-Credential([PSCredential]::new("$(Username)",(ConvertTo-SecureString-String"$(Password)"-AsPlainText-Force)))-SandboxName"$(SandboxName)"-TestRunnerPage"$(TestRunnerPage)"-SuiteCode"$(SuiteCode)"-BCPTTestRunnerInternalFolderPath$(System.DefaultWorkingDirectory)/"$(BCPTTestRunnerInternalFolderPath)"-ClientId"$(ClientId)"'

Définition des variables

Il est aussi possible de lancer des tests de performance en utilisant Al-Go.

L’intérêt de la mise en place de l’automatisation : les tests sont effectués régulièrement, sans que vous ayez à vous en préoccuper.

2. Monitoring pendant la phase de développement

Lors de cette phase, le principal objectif est la détection de dégradations des performances, dues à la mise en place de développements spécifiques sur Business Central.

Le principe est d’utiliser l’outil de test de performance BCPT fourni par Microsoft pour faire les tests de manière hebdomadaire, ou même quotidienne. Périodiquement, les scénarios de test fournis avec l’outil BCPT sont lancés sur les environnements de test. Une analyse des résultats est effectuée régulièrement pour déterminer si les développements mis en place ont un impact sur les performances.

Si des impacts de performance significatifs sont détectés, il est préférable d’effectuer des ajustements immédiatement.

Ci-dessous un exemple de résultats en utilisant les logs BCPT extrait vers Excel :

Dans cet exemple, on peut voir des augmentations des volumes de requêtes SQL sur certains scénarios qui ont nécessité des ajustements.

Depuis quelque temps, il est aussi possible de faire ce type d’analyse directement dans les rapports Power BI fournis par Microsoft pour analyser la télémétrie.

En parallèle de cela, il est nécessaire de commencer à déterminer les scénarios de performance pouvant représenter l’activité réelle des utilisateurs sur Business Central et des volumétries pressenties. (Exemple : nombre de clients, volume du carnet de commande, nombre d’expéditions et factures enregistrées par jour).

À la fin de cette analyse, les caractéristiques du système cible sont identifiées. Exemples ci-dessous (non exhaustif) :

En fin de phase de développement, nous avons un ensemble de développement représentatif du système cible, ainsi qu’un framework de tests automatisés pour tester ces développements (c’est une pratique préférable).

Ces tests automatisés peuvent servir de base au développement des tests de performance. En effet, les tests de performances sont très proches des tests unitaires qui peuvent être développés pour valider le fonctionnement d’un développement de manière automatique. À ce stade, il est possible de commencer le développement des tests de performance finaux.

3. Développement des tests de performance

Sur la base des scénarios de performance définis, l’équipe développe les codeunits afin d’exécuter les scénarios cibles sur Business Central. Il peut être aussi nécessaire de développer des processus pour générer le volume des données nécessaires à l’exécution des tests de performance. En effet, un carnet de commande avec cinq lignes n’est pas la même chose qu’un carnet de commande de 200 000 lignes en termes de performance. Ce type de volumétrie a forcément un impact.

Comme je l’ai dit précédemment, les tests de performance sont très proches des tests unitaires. Par conséquent, il est fortement probable d’avoir besoin des librairies de test fournies par Microsoft. Malheureusement, à l’heure où j’écris cet article, il n’est pas possible d’installer les librairies de test standards sur une sandbox Business Central. La solution est de mettre les librairies nécessaires aux tests de performance sur la plage d’objet 50000..99999.

4. Exécution des tests de performance finaux

Une fois les tests de performance développés et les volumétries de données cibles présentent sur Business Central, vous pouvez lancer les tests de performance.

Ces tests vont vous permettre de :

  • valider l’ensemble de la solution sur le périmètre défini en simulant les activités utilisateurs pendant 30 à 60 minutes.
  • mesurer les performances des flux métiers et les cas possibles de deadlock sans avoir besoin de mobiliser l’ensemble des utilisateurs.

Ci-dessous, quelques exemples de résultats présentant les volumes de deadlock trouvés, ainsi que les temps d’exécution :

Ces résultats peuvent servir de base à l’optimisation des processus spécifiques développés sur Business Central. Cela peut se faire en amont de sa mise en place, et donc sans l’urgence et le stress d’un souci de performance sur un environnement de production.

Conclusion

Cette méthodologie, en tirant parti des outils modernes, minimise les tests manuels et les risques lors du déploiement final de Business Central. Elle garantit une mise en œuvre sécurisée et performante, essentielle dans l’environnement dynamique d’aujourd’hui. Par ailleurs, elle permet d’agir sur 3 axes essentiels :

  • Planet : Optimisation technique des systèmes pour moins de consommation CO2
  • People : Organisation projet permettant de traiter les problématiques performance en avance de phase, sans stress pour les équipes
  • Profit : Assurance de flux métier fonctionnels pour supporter l’activité de l’entreprise

Ci-dessous, une illustration de cette méthodologie mise en parallèle d’un planning d’implémentation du Business Central.

Partager l'article

Contact us
Christophe Courvoisier
Author:
Christophe COURVOISIER
International Project Manager and Team Leader Microsoft Dynamics