Des rapports Financial Reporting à la conception inefficace peuvent générer plusieurs demandes MDX ou requêtes Oracle Essbase entraînant une consommation significative des ressources Oracle Enterprise Performance Management Cloud. La consommation excessive des ressources cause une dégradation des performances en cas d'accès simultané des utilisateurs à ces rapports.
La présence de plusieurs segments dans le rapport est la raison principale pour laquelle un grand nombre de demandes MDX est généré. Cette section vous explique comment améliorer l'efficacité des rapports Financial Reporting en réduisant le nombre de segments.
Reconception de rapports : cas d'emploi
Rapport d'origine
L'illustration suivante représente la conception du rapport d'origine :
![Exemple de conception du rapport d'origine Exemple de conception du rapport d'origine](img/8_origial_rep.png)
Cette illustration du rapport montre les éléments de conception suivants :
- Plusieurs lignes pour chaque membre Entity 100, 200, 403 et 500.
- Chaque membre Entity comporte 8 lignes pour différents comptes
Le tableau suivant présente une vue globale de la conception du rapport d'origine et de la conception optimisée :
Rapport optimisé
L'illustration suivante représente la conception du rapport optimisé, réduisant le nombre de segments. La réduction du nombre de segments accélère l'exécution du rapport en réduisant le nombre de demandes MDX :
![Exemple de rapport reconçu Exemple de rapport reconçu](img/8_redesigned_report.png)
Autres remarques importantes sur la conception de rapport
- Concevez les rapports en fonction des cubes ASO, si possible. Concevez les rapports en fonction des cubes BSO uniquement si les cubes ASO ne sont pas disponibles.
- Sélectionnez toujours Blocs manquants sous Suppression pour vous assurer que les blocs manquants ne sont pas inclus dans les rapports.
- Réduisez au maximum le nombre de lignes et de colonnes. Meilleures pratiques : utilisez des dimensions denses pour les colonnes et des dimensions dispersées pour les lignes.
- Concevez des rapports à interroger au niveau enfant requis des membres plutôt qu'au niveau parent.
- Si des membres de niveau 0 sont désignés comme membres de calcul dynamique mais ne disposent pas d'une formule, enlevez la désignation Calcul dynamique ou créez des formules pour eux. Vous ne pouvez pas charger des données vers des membres de niveau 0 désignés comme membres de calcul dynamique. Ils ne peuvent pas afficher de valeurs car ils sont désignés comme membres de calcul dynamique mais ne disposent pas de formule pour calculer des valeurs. Ces membres nuisent aux performances d'extraction.
- Si possible, évitez les rapports de type relationnel (rapports avec plusieurs dimensions de ligne développées à l'aide de fonctions) avec une grande combinaison de membres. L'exécution des rapports volumineux peut prendre beaucoup de temps (voire ne pas fonctionner). Un rapport est considéré comme volumineux lorsque le nombre de cellules dépasse 10 000. Ce comportement est semblable à celui qui consiste à traiter Financial Reporting comme un outil d'extraction de données à grande échelle alors qu'il n'en est pas un.
- Evitez les rapports avec un grand nombre de cellules contenant des fonctions de texte (par exemple,
CellText
, PlanningAnnotations
et ListOfCellDocuments
) qui extraient des métadonnées supplémentaires de la source de données.
- Utilisez les invites, les liasses ou le PDV en cours plutôt que la dimension de page ; tous les membres de page sont extraits en même temps lors de l'exécution du rapport.
- Prenez en compte et testez l'impact du formatage conditionnel et de la suppression conditionnelle, qui peuvent avoir une incidence sur les performances selon la taille du rapport. Les performances dépendent du type des critères et de leur fréquence d'utilisation dans le rapport. Les critères qui font partie de la requête de métadonnées ou de données, par exemple, la valeur de données, le nom de membre, et l'alias ou la description de membre, sont affichés rapidement. Avec les rapports volumineux, minimisez l'utilisation des critères qui ne font pas partie de la requête de métadonnées ou de données standard. Exemples de critères de ce type : génération, niveau, type de compte et valeur d'attribut.
- Réfléchissez à la disposition des dimensions. Par exemple, analysez ce qui peut être déplacé du PDV ou de la page vers le corps du rapport.
- Concevez toujours un rapport symétrique (par opposition au rapport asymétrique). Les requêtes Essbase peuvent être symétriques ou asymétriques. Les requêtes symétriques sont celles où les membres interrogés sur des lignes ou des colonnes sont disposés de manière inter-dimensionnelle. Les requêtes asymétriques sont celles où la disposition inter-dimensionnelle des membres interrogés est modifiée dans les lignes ou les colonnes.
Lorsque le moteur de requête hybride Essbase, qui ne traite que les grilles symétriques, rencontre une requête asymétrique, il la divise automatiquement en plusieurs grilles symétriques. Ces grilles symétriques sont traitées une par une, puis renvoyées dans le formulaire asymétrique d'origine, ce qui rend le processus moins efficace.
Révision des modifications récentes de l'application
Déterminez si les modifications récentes apportées à l'application causent le ralentissement de la génération du rapport. Pour ce faire, comparez les informations de la table Taille de l'application du rapport d'activité actuel avec les informations du rapport d'activité généré à une date à laquelle le rapport fonctionnait bien. Révisez également les modifications récentes de conception et d'utilisation du rapport pour vérifier qu'elles n'ont pas eu d'impact sur le rapport.