Évaluer l’impact sur les performances
Power BI peut se connecter aux services web publiés par Business Central. Ces services web sont basés sur des objets de page ou de requête. La principale différence entre un service web de page et un service web de requête est la suivante :
Page
Peut utiliser une seule table source
Peut contenir une logique AL et des colonnes calculées
Peut contenir des champs de flux
Est mise en cache sur le niveau de service
Exécute toujours une instruction SELECT * sur la table source sous-jacente, indépendamment des colonnes définies dans l’objet de page
Requête
Peut joindre plusieurs tables source
Peut calculer des agrégations
Peut contenir toute logique AL ou des colonnes calculées
Peut contenir des champs de flux
N’est pas mise en cache sur le niveau de service
Exécute une instruction SELECT uniquement sur les colonnes définies comme colonnes dans l’objet de requête
Requête API
Peut joindre plusieurs tables source (plus rapide que la page API)
Peut calculer des agrégations
Peut contenir toute logique AL ou des colonnes calculées
Peut contenir des champs de flux
N’est pas mise en cache sur le niveau de service
Exécute une instruction SELECT uniquement sur les colonnes définies comme colonnes dans l’objet de requête
N’a pas besoin d’être publié dans la table des services Web
Comme vous l’avez peut-être constaté, les performances des objets de requête sont généralement meilleures que celles des objets de page. Voilà pourquoi il est recommandé de créer ou d’utiliser des objets de requête comme sources de données pour Power BI. Même lorsque vous avez besoin de colonnes calculées, il s’agit d’un élément que vous pouvez également définir dans Power BI Desktop. Pour ce faire, créez des colonnes ou des mesures calculées après avoir importé les données. Il est recommandé d’utiliser uniquement des objets de page comme jeux de données pour Power BI si vous avez besoin d’un certain calcul ou d’une certaine exécution de la logique métier à l’aide du code AL que vous ne pouvez pas effectuer dans Power BI Desktop après l’importation des données.
Extractions efficaces vers des lacs de données ou des entrepôts de données
Lors de la création d’un lac de données ou d’un entrepôt de données, vous devez généralement effectuer deux types d’extraction de données :
Un chargement historique (toutes les données provenant d’un point donné dans le temps)
Chargements delta (ce qui a changé depuis le chargement historique)
Le moyen le plus rapide (et le moins perturbateur) d’obtenir un chargement historique à partir de Business Central Online est d’obtenir une exportation de base de données sous forme de fichier BACPAC (à l’aide du centre d’administration Business Central) et de le restaurer dans une base de données Azure SQL Database ou sur un serveur SQL Server. Pour les installations locales, vous pouvez simplement effectuer une sauvegarde de la base de données des abonnés.
Le moyen le plus rapide (et le moins perturbateur) d’obtenir des chargements delta à partir de Business Central Online consiste à configurer des requêtes d’API configurées avec une échelle en lecture et à utiliser le champ d’audit de données LastModifiedOn (introduit dans la version 17.0) sur les filtres.
Écriture de services web efficaces
Business Central prend en charge les services web pour faciliter l’intégration aux systèmes externes. En tant que développeur, vous devez prendre en compte les performances des services web pour Business Central Server (le point de terminaison) et le consommateur (le client).
Évitez d’utiliser des pages d’IU standard pour une exposition en tant que points de terminaison de service web. De nombreux éléments tels que les récapitulatifs ne sont pas exposés dans OData, mais effectuent des calculs à l’aide de ressources.
Voici les éléments ayant historiquement entraîné des problèmes de performance sur les pages exposées en tant que points de terminaison :
Logique lourde dans OnAfterGetCurrRecord
Nombreux champs SIFT
Récapitulatifs
Utilisation de l’échelle horizontale en lecture
Business Central prend en charge la fonctionnalité Échelle horizontale en lecture dans Azure SQL Database et SQL Server. L’échelle horizontale en lecture permet d’équilibrer la charge des charges de travail analytiques dans la base de données qui lisent les données uniquement. L’échelle horizontale en lecture est intégrée dans le cadre de Business Central Online, mais elle peut également être activée pour les versions locales.
L’échelle horizontale en lecture s’applique aux requêtes, aux états ou aux pages API. Avec ces objets, au lieu de partager la base de données primaire, ils peuvent être configurés pour s’exécuter sur un réplica en lecture seule. Cette configuration les isole essentiellement de la charge de travail principale en lecture-écriture afin qu’ils n’affectent pas les performances des processus métier.
En tant que développeur, vous contrôlez l’Échelle horizontale en lecture sur les états, les pages API et les objets de requête à l’aide de la propriété DataAccessControl.
La propriété DataAccessIntent définit si les données doivent être obtenues pour l’objet à partir d’un réplica de la base de données en lecture seule ou de la base de données primaire.
La propriété a les valeurs suivantes :
ReadOnly : indique que les données doivent être obtenues à partir d’un réplica en lecture seule.
ReadWrite : indique que les données doivent être obtenues à partir de la base de données primaire. ReadWrite est la valeur par défaut.
Pour les états, les pages API et les requêtes, Business Central Server peut utiliser des réplicas de base de données en lecture seule sur Azure SQL Database et SQL Server. Si les réplicas sont activés, utilisez cette propriété pour réduire la charge sur la base de données primaire.
Le recours à l’option ReadOnly peut également améliorer les performances lors de l’affichage des objets. L’option ReadOnly sert de conseil pour indiquer au serveur d’acheminer la connexion vers un réplica secondaire (en lecture seule), le cas échéant. Lorsqu’une charge de travail est exécutée sur le réplica, les opérations d’insertion/de suppression/de modification ne sont pas possibles. Si l’une de ces opérations est exécutée sur le réplica, une exception est levée lors de l’exécution.
Depuis le client, la valeur de la propriété peut être remplacée à l’aide de la page 9880 Liste des intentions d’accès à la base de données.
Conseils sur les performances lors de l’utilisation de Power BI et de Business Central
En gardant à l’esprit les informations précédentes, vous comprenez probablement qu’il est important de garder un œil sur les performances, en particulier lors de la création d’états Power BI dans Business Central. Voici quelques éléments à prendre en considération :
Il est préférable de créer une requête ou une page et de l’utiliser comme source de données dédiée pour Power BI au lieu d’utiliser des pages ou requêtes existantes qui servent également à d’autres fins. En adaptant votre jeu de données (page/requête) à votre état Power BI, il vous suffit d’inclure les champs dont vous avez besoin, rien de plus.
Dans la mesure du possible, vous devez choisir des requêtes plutôt que des pages comme sources de données pour Power BI. Les objets de requête génèrent une instruction SELECT meilleure et plus rapide sur la base de données SQL et les objets de requête peuvent également agréger des données. Vous devez créer les requêtes afin qu’elles ne renvoient que les données nécessaires pour l’état Power BI, rien de plus. Par exemple, si votre état nécessite des données de vente par jour, créez un objet de requête dans lequel vous extrayez les données de vente et les agrégez par jour, au lieu d’extraire plusieurs enregistrements pour un jour spécifique, puis de laisser Power BI agréger les enregistrements après importation.
Implémentez des filtres dans les requêtes et les pages. Si des enregistrements dans les tables source sous-jacentes ne sont pas requis dans votre état, vous devez les filtrer dès que possible.
N’incluez aucun champ, ni aucune colonne non requis dans votre jeu de données. Vous pourrez toujours les ajouter ultérieurement, le cas échéant, et le service web se mettra automatiquement à jour.
Si vous avez besoin d’informations provenant des tables d’écritures comptables, veillez à agréger les enregistrements. Les tables d’écritures comptables comportent de nombreux enregistrements et continuent généralement de croître. Il est très peu probable que vous ayez besoin d’importer et de visualiser chaque écriture comptable dans un état Power BI. Créez donc la requête avec le niveau d’agrégation répondant aux besoins de l’état.
À titre de recommandation, je vous suggère d’utiliser des objets de requête plutôt que des objets de page. En effet, les objets de requête génèrent généralement des instructions SQL plus rapides et peuvent joindre plusieurs tables et agréger des données.
Les objets de page vous permettent de calculer des champs à l’aide du langage de programmation AL, alors que les objets de requête ne peuvent pas le faire. Cependant, sachez que Power BI est également capable de créer des colonnes et des mesures calculées à l’aide du langage DAX. Ainsi, au lieu de créer un objet de page avec des calculs complexes en code AL, il est probablement préférable de créer un objet de requête et de laisser Power BI effectuer les calculs complexes, une fois les données importées.