Meilleures pratiques en matière de création de rapports
Cette rubrique décrit les coefficients clés à prendre en compte lors de l'utilisation d'Application Studio pour écrire des rapports sur des cubes OLAP.
Considérations sur le front-end
Ce tableau affiche les éléments clés à prendre en compte pour la conception des rapports front-end :
| Considération | Description |
|---|---|
| S'agit-il de rapports qui contiennent des hyperblocks imbriqués ? | Un rapport basé sur un découpage en tranches et dans lequel les hyperblocks sont filtrés pour, par exemple, exclure les valeurs nulles, présente de meilleures performances. L'utilisation des tranches est associée à une courbe d'apprentissage et certaines fonctions souhaitables manquent, mais les fonctions disponibles répondent à 80 % des cas de figure. |
| Les rapports nécessitent-ils un défilement vertical ? | Si oui, incorporer une extension Web de pagination dans les pieds de page des rapports. Cela améliore l'expérience de l'utilisateur et les performances. |
| Les rapports font-ils appel à la mise en forme conditionnelle ? | La mise en forme conditionnelle est une fonctionnalité puissante, mais il faut l'utiliser avec parcimonie en raison de son effet sur les performances lors de l'évaluation des conditions. Il est possible d'éviter la mise en forme conditionnelle lors de l'utilisation du format des nombres et en se basant sur les formats des nombres, définis dans la base de données. Application Studio clusterise les requêtes de données des formules, qui sont envoyées à la base de données OLAP. Le résultat est une requête globale au lieu de plusieurs requêtes portant sur une seule cellule. Les requêtes en cluster sont plus rapides que l'accès à une seule cellule. Les données lues sous forme de formules dans les formats conditionnels et les sauts de rapport ne peuvent pas être mises en cluster et sont toujours interrogées en tant que requête de cellule unique. |
| Les rapports sur les feuilles de style sont-ils trop élaborés ? | Penser à la simplicité lorsque de l'élaboration de nouvelles feuilles de style et résister à l'envie de conserver le contenu des feuilles de style existantes lorsque cela est possible. Le nombre de styles ajoute à la taille d'un rapport. |
| Des sélections initiales pour les entités des rapports ont-elles été spécifiées ? | Les rapports se chargent plus rapidement si la dernière entité visualisée par un utilisateur est mémorisée. Si un rapport est chargé au niveau de toutes les entités par exemple, beaucoup plus de données doivent être récupérées et le rapport prend plus de temps à charger. |
| Des contrôles sans état, tels que des objets de recherche, plutôt que des contrôles basés sur des vues de liste ? | Les contrôles basés sur des vues de liste, tels que les zones de listes déroulantes, récupèrent des listes d'éléments lors du chargement d'un rapport. Les contrôles sans état n'extraient pas de listes d'éléments, ce qui accélère leur chargement. |
| Les rapports sont-ils testés minutieusement ? | Il est possible de créer des rapports qui concatènent des chaînes pour obtenir les ID des éléments, mais envoyer la requête au serveur OLAP pour des éléments qui n'existent pas peut provoquer des erreurs et des dépassements de délai. Les tests doivent toujours tenir compte des paramètres de sécurité de l'utilisateur final. |
| Filtres de liste | Certains types de filtres sont plus lents que d'autres, par exemple les filtres d'attributs sont plus lents que les filtres de valeurs. Les filtres sont en général plus lents que les sélections de structures. Eviter les grandes zones de données dans les filtres. Plus il y a d'éléments sélectionnés par dimension, plus le filtre est lent. |
| Actions globales | Envisager d'utiliser des actions globales pour réduire le temps de calcul des rapports individuels. Les actions globales sont exécutées lors de la connexion de l'utilisateur, après qu'un modèle de référentiel a été créé et avant qu'un moteur ne soit créé. Les valeurs des variables globales sont déjà paramétrées avant qu'un rapport ne démarre. |
| Variable de rapport | Eviter les grandes chaînes dans les variables. |
Considérations sur le backend, l'environnement et les relations interpersonnelles
Dans le cadre d'un projet réussi, il existe une boucle de rétroaction entre les développeurs de rapports et les auteurs des cubes. Une mauvaise conception de cube est probablement la plus grande cause de mauvaise performance. Ce tableau affiche les coefficients importants à prendre en compte :
| Considération | Description |
|---|---|
| Ecriture et test de rapports à l'aide d'un ensemble de données réalistes | Les rapports dont les dimensions comprennent jusqu'à 30 éléments et les cubes plusieurs centaines de points de données peuvent donner de bons résultats, mais sont difficiles à gérer en raison de l'importance de l'ensemble des données. Il est important d'effectuer des tests avec des jeux de données réalistes. |
| Ecrire correctement les règles OLAP. Exemple de règle mal écrite : [Revenu] = [Prix] * [Quantité] ou [Compte1] = [Compte2] + [Compte 3] + [Compte 4] | Se familiariser avec les meilleures pratiques pour l'écriture des règles OLAP. Faire référence à la documentation en ligne pour obtenir des conseils. |
| Dimensions mal structurées | Prenons l'exemple d'une dimension de produit dont l'élément sommet est Tous les produits, mais dont les enfants sont au nombre de 10 000. A un moment donné, l'utilisateur est susceptible de déclencher une requête vers le serveur OLAP qui nécessite que tous les éléments soient extraits et, éventuellement, affichés. Les niveaux hiérarchiques intermédiaires génèrent un rapport basé sur la hiérarchie plus performant. |
| Nombre élevé d'utilisateurs | Eviter de modifier les dimensions pendant les heures de bureau, lorsque le nombre d'utilisateurs en ligne est le plus élevé. |
| Eléments parents manquants dans les dimensions, par exemple, un élément total de l'année | Un rapport qui récupère les données quotidiennes dans des colonnes masquées pour les additionner et les afficher sous la forme d'un total annuel est beaucoup plus lent qu'un rapport où le total est calculé dans la base de données OLAP. |
| Abus des attributs | Les attributs peuvent être définis librement et utilisés pour filtrer les rapports, mais les rapports filtrés sont moins performants qu'une hiérarchie qui regroupe les éléments en fonction des valeurs potentielles des attributs. |
| S'assurer que le serveur OLAP dispose de suffisamment de mémoire vive | OLAP est une base de données en mémoire. Des requêtes mal écrites peuvent consommer une quantité importante de mémoire vive. Si le serveur OLAP est en cours de pagination, on peut s'attendre à de mauvaises performances. |
| Ne pas mettre les données transactionnelles dans les cubes | Infor OLAP est optimisé pour le reporting de niveau de solde Il est possible de créer un rapport qui n'est pas performant, sans en être empêché par l'application. Exemple : il est possible de créer un cube détaillé à partir d'un fichier de lignes de commandes, mais il ne sera probablement pas performant. |
| Ecriture d'un mauvais rapport comme solution à court terme | Résister à la pression du projet pour mener à un rapport non performant. Ecrire ce qui est important par écrit et proposer des alternatives. |
| Ne pas stocker de zéros dans le cube | Un zéro est un nombre qui doit être stocké dans la mémoire d'OLAP et évalué dans les calculs de règles, alors qu'une valeur nulle ne l'est pas. Il est possible de créer un processus Application Engine capable de remplacer les zéros d'un cube par des valeurs nulles. |
| Le meilleur endroit pour effectuer des calculs | Cela dépend de plusieurs coefficients, notamment de la fréquence à laquelle les valeurs calculées sont obligatoires. Voici des exemples de possibilités pour effectuer les calculs, par ordre de préférences :
|
| Définir des éléments par défaut spécifiques | La non-sélection d'éléments spécifiques par défaut pour les dimensions hiérarchiques entraîne la sélection par défaut de l'élément sommet. Cela nécessite plus de temps pour réinitialiser les éléments par défaut. Les paramètres par défaut actuels sont définis dans les propriétés étendues de la dimension. |
| L'utilisation de l'interface XML est plus lente que la communication via l'interface intégrée dans la version 11 | Pour accélérer la communication, il est recommandé de ne pas lire les valeurs par des requêtes sur une seule cellule, mais de les placer dans une ou plusieurs requêtes vers OLAP. Cela peut être fait avec la requête Cube Read, en ajoutant plusieurs balises CellCoordinate. |
| Utiliser la pagination côté serveur pour faire en sorte qu'un rapport n'interroge que les valeurs visibles | La pagination dans les pages hyperblocks se fait du côté du client. Toutes les cellules sont renvoyées par le serveur, mais seule une page est dessinée. Dans les listes OLAP, la fonction de sous-ensemble est utilisée pour la pagination côté serveur. Dans les listes relationnelles, utiliser des méthodes avancées de requête pour créer des sous-ensembles. |
| Filtrer les requêtes afin de ne pas interroger tous les éléments d'une dimension | Utiliser la suppression des valeurs nulles pour n'afficher que les cellules remplies, afficher tous les éléments sous un certain parent au lieu d'une dimension entière. Diminuer le niveau de développement initial dans les tranches et les listes. |
| Eviter de mettre un grand nombre de dimensions sur l'axe | La quantité optimale est de trois dimensions par axe de lignes, une dimension par axe de colonnes. |