Diagnostic des erreurs de rapports Financial Reporting et des problèmes de performances

Des rapports Financial Reporting à la conception inefficace peuvent générer plusieurs demandes MDX ou requêtes 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.

Remarque :

Si le problème rencontré concerne Reports, reportez-vous à la section Résolution des problèmes de 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
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 :

Conception du rapport d'origine Conception optimisée
Plusieurs lignes pour chaque membre Entity :

100

200

300

400

Combine les membres Entity dans un même segment :

100, 200, 403, 500

Chaque membre Entity comporte 8 lignes pour différents comptes Exemple pour le membre 100 :

100 = Children of 1100

100 = 1100

100= Children of 1200

100=1200

100 = Children of 1300

100 = 1300 100 =Children of 1400

100 = 1400

Combine tous les segments de tous les membres dans un même segment :

Entity members 100,200,403,500=Children of 11

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

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 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.

Accès à l'aide

Après avoir optimisé le rapport afin de réduire le nombre de demandes MDX, si vous ne constatez aucune amélioration des performances, demandez de l'aide au support technique Oracle :

  • Servez-vous de l'utilitaire Fournir des commentaires pour réunir les informations nécessaires à l'identification et à la résolution de votre problème par le service technique Oracle. Veillez à autoriser la soumission de l'instantané à Oracle. Reportez-vous à la section Création d'une soumission Fournir des commentaires.
  • Soumettez une demande de service technique identifiant la référence créée par l'utilitaire Fournir des commentaires. Reportez-vous à la section Soumission d'une demande de service technique.

    Dans la demande de service, répondez aux questions suivantes :

    1. Quand le problème a-t-il été observé pour la première fois ?
    2. Une modification récente de l'application ou de son utilisation a-t-elle pu causer ce problème ?

    Fournissez les informations suivantes avec la demande de service :

    • Un instantané de l'environnement, s'il est disponible, correspondant à la dernière occasion à laquelle le rapport financier a fonctionné ou a été exécuté comme prévu.
    • Le nom du rapport ou de la liasse de rapports. S'il s'agit d'une liasse de rapports, précisez le rapport posant problème.
    • Tous les PDV.
    • Variables utilisateur et de substitution en cours d'utilisation.
    • Les lignes et colonnes qui rencontrent le problème.
    • Durées de génération de rapport attendue et réelle.
    • si vous êtes en phase de production (par opposition à la phase d'implémentation ou de test) ;
    • Si ce problème vous empêche d'effectuer des activités essentielles. Par exemple, il vous empêche de clôturer le cycle financier en cours ou de créer des rapports urgents à des fins de gestion.