objets de requête : ordre de traitement

[Phil2BPA]

Bonjour à tous.
Je doit "auditer" la bonne conception de rapports conçus par des utilisateurs débrouillés, mais loin d'être expert.
Je ne me considère d'ailleurs pas moi non plus comme expert, mais j'ai un peu d'expérience sur la conception de requêtes/rapports, notament en environnement C8.1.

Je constate que certaines requêtes ont potentiellement mal géré l'ordre séquentiel des objets.
En effet, on m'a toujours mis en garde sur certains objets qui s’expriment de façon qu’ils dépendent d’un ou plusieurs autres objets de la requête, alors ces objets doivent se situer « en dessous » des objets-sources.

Exemple :
Objet1 = <une valeur numérique du package>
Objet2 = <une valeur numérique du package>
Objet3 = SOMME (<Objet1> + <Objet2> ) ... c'est très schématisé.


L’Objet3 doit être placé en dessous des 2 autres, puisque Cognos va lire les objets séquentiellement de haut en bas.

Là, je suis en C8.4, et je voudrais savoir si cet "bug" est toujours d'actualité, ou bien s'il a été géré en C8.2 ou ultérieur. Bref, si je doit donner (ou pas) une "alerte" aux concepteurs C8.

Merci d'avance pour votre réponse.
Cdt,
Philippe

[Sunchaser]

Bonjour,

Je ne suis pas sur de bien comprendre, et plutôt sur que ce que je vais énoncer va faire l'unanimité, mais tant pis... (et en plus je n'ai jamais vraiment connu la 8.1, puisque passé directement au dessus).
Donc, selon moi, l'ordre (apparent) des Query Items (objets de requêtes) dans l'éditeur n'a aucune importance: ce que va regarder notre bon Cognos, c'est quels objets il a a créer et quelle est la source des données dans ses objets (a quels Query Item ils sont liés), avec une hiérarchie qui va des "gros" conteneurs (page) vers les plus imbriqués.
Disons que si il a une page a créer et que celle ci et liée a un Query Item, il commence donc forcement par executer cette requête et lance la création de la page, puis si il a une List a créer, pan ! il lance la requête qui permets d'avoir les données de la liste, et si dans la liste il y a une liste imbriquée (avec par exemple une relation master-detail), il lance ensuite la requête de cette liste, autant de fois que nécessaire pour afficher tous les enregistrements.

Ce qui est important il me semble, c'est de noter que, dans certains cas comme les page-breaks ou l'utilisation de crosstabs qui s'étendent sur plusieurs pages, notre très bon (mais néanmoins perfectible) Cognos n'est pas en mesure de garder "en mémoire" le curseur de la requête, il doit relancer la requête autant de fois que nécessaire (quels que soient les settings d'ailleurs).
Donc très important que dans ce cas les requêtes soient très épurées et donc très rapides, perso de ce fait je segmente autant que nécessaire le travail et j'ai donc plusieurs "petites" requêtes plutôt qu'un "gros machin"* qui me sortirait tout pour plusieurs objets.

@+




*EDIT: et oui, il est des domaines comme ca ou avoir un gros machin n'est pas nécessaire ...

[Phil2BPA]

Bonjour Sunchaser,
et merci pour cette réponse ultra rapide !!

Je ne sais pas si c'est moi qui ai fumé la moquette, ou simplement vous qui n'aviez jamais eu écho de ce "bug" C8, mais je vais attendre d'autres réponses avant d'en tirer des conclusions. ;-D

Je suis d'accord avec votre analyse générale du moteur Cognos à l'execution d'une requête.

Pour votre remarque sur le curseur de la requête, qui lâche, je vous conseillerai bien le paramètre "utiliser l'antémémoire locale" (je ne sais pas comment cette fonction s'appelle, en anglais) qui permet de réutiliser le résultat d'une requete, sans la relancer. Mais je suppose que vous l'avez déjà expérimenté.
Perso, lorsque j'ai un rapport maitre/détail, j'active cette fonction sur la requete maitre, mais très honnetement je n'ai pas mesuré de gain très significatifs.

@bientôt, pour d'autres discussions à propos de ce bel outil

[Sunchaser]

Envoyé par Phil2BPA

Pour votre remarque sur le curseur de la requête, qui lâche, je vous conseillerai bien le paramètre "utiliser l'antémémoire locale" (je ne sais pas comment cette fonction s'appelle, en anglais) qui permet de réutiliser le résultat d'une requete, sans la relancer.

Bonsoir,
Effectivement, je vois la propriété dont tu parles. Mais je suis sur a 99,99% que - jusqu'a la 8.4 au moins - ca ne "tient" pas. Dans le sens ou, du fait de la manière très particulière dont je fais appel aux données, j'ai donc en arrière plan un "système d'audit" perso qui me permets de tout savoir sur ce qui se passe au niveau base de données, qui a appelé quoi, quels paramètres, quels temps d'exécution et donc quel ordre d'appel et d'exécution, etc ...(mais je ne prétends pas que c'est parfait, ca donne tout de même une bonne idée de ce qui se passe)
Je serais curieux d'avoir d'autres avis la dessus, et bien sur sur le thème principal de ta question, qui m'intéresse fortement de fait.

@+



NB: j'utilise la plus part du temps les dénominations en Anglais car tout est installé ainsi pour moi (c'était ca ou Allemand), et surtout parce que le nombre de résultats sur une recherche de notre très Saint Google (je blague évidement) sur un sujet donné dans Cognos renvoie infiniment plus de résultats dans cette langue qu'en Français, rien de plus.
(comme quoi, on est pas encore assez actifs sur le forum Cognos de DVP )

[Nallack]

Bonjour,

Je suis plutôt de l'avis de Sunchaser.

Voici ce que j'ai remarque pour ma part :
Cognos va regarder la spécification du rapport, en fonction des Query Items qu'il a besoin dans les éléments du rapport, il va constituer la (ou les) requête(s) SQL/MDX qui va(ont) bien.
L'ordre des objets dans le Query subject ne va pas avoir d'importance si ces objets sont traités au niveau SGBD/Moteur OLAP.
Si Cognos doit les traiter en local, il gèrera en fonction de l'ordre indiqué dans la propriété Solve Order du Query Item, sinon à défaut dans l'ordre de sa logique.

Pour les Pages Break (et pour les master/details), Cognos relance les requêtes filles à chaque coup, en modifiant les paramètres de filtres. L'utilisation de l'antémémoire locale (Use Local Cache) n'a pas d'effet dans ce cas puisque la requête est toujours différente. Pour la Master, je me suis toujours arrangé pour avoir des requêtes trés légère, donc je ne sais pas si le cache peut apporter quelque chose.
Pour les CrossTabs, j'ai jamais fait attention.


Cognos pousse encore le vice. Si tu crées une Query que tu utilises dans 2 List, mais pour chacune des 2 List, tu n'utilises pas les même Query Item, Cognos va envoyer 2 requêtes Sql. Sauf si tu forces l'utilisation dans les 2 listes des mêmes Query Item via les propriétés des List.


Pour la langue, il vaut mieux bosser en Anglais pour les bonnes raisons évoquer par Sunchaser et pour éviter les problèmes de traduction des messages d'erreur (vieux souvenirs de Cognos 6.5).



En tout cas, j'espère d'autres réponses afin de vraiment savoir à quoi m'en tenir.

Nallack

[Phil2BPA]

Merci à tous les 2 pour vos réponses.
Pour la langue je suis plutôt d'accord avec vous, mais j'ai mis le Français pour rester au même niveau de discussion que mes utilisateurs, qui ont préféré le FR.

@Nallack, ta remarque est intérressante

"L'ordre des objets dans le Query subject ne va pas avoir d'importance si ces objets sont traités au niveau SGBD/Moteur OLAP".

=> les objets auquels je faisais référence esont en effet au niveau local de la Query. Il est plus pratique (dixit un utilisateur) de récupérer un objet de la requete, plutot que de retourner le chercher dans le package.

"Si Cognos doit les traiter en local, il gèrera en fonction de l'ordre indiqué dans la propriété Solve Order du Query Item"

=> OK, j'ai jamais utilisé ce param.

sinon à défaut dans l'ordre de sa logique.

=> et quel est cet ordre ? séquentiel de haut en bas ?

Si tu crées une Query que tu utilises dans 2 List, mais pour chacune des 2 List, tu n'utilises pas les même Query Item, Cognos va envoyer 2 requêtes Sql.

"
=> hmmmm ... très interressant. celà me concerne.

Sauf si tu forces l'utilisation dans les 2 listes des mêmes Query Item via les propriétés des List.

je ne sais pas de quelle propriété précise tu parle, mais je vais rechercher.


Au pire, la réexecution de ma requete maitre n'est pas fatale, car tout comme vous, je l'ai coçu la plus "light" possible.

@+

[ElPoune]

Bonjour,

Je penche vers l'explication de Sunchaser, le tout est envoyer sur le serveur dans l'ordre du plus simple vers le plu complexe c-i-e, d'un item vers l'implication de cet item dans un calcul, de ce calcul dans une ou plusieurs listes ou graphique.
Une façon d'avoir plus de réponses est de voir la liste des requêtes et l'ordre avec lequel elles sont reçues par le serveur . La partie manquante telle que les totaux agrégés dans une liste devrait à ce moment être traité par Cognos.

P.-S. - Sun , j'aimerais bien savoir comment tu fais tes audits pour les requêtes et le temps d'exécution

Merci

[Sunchaser]

Envoyé par ElPoune

Bonjour,
P.-S. - Sun , j'aimerais bien savoir comment tu fais tes audits pour les requêtes et le temps d'exécution

Merci

Bonjour,

Bien volontiers, mais je doute que cela convienne a tout le monde.
-> En effet, cela proviens de la manière particulière dont on travaille avec Cognos, c'est un choix répondant a un cas particulier, dont je ne vais pas m'étendre la dessus.
Bref, je travaille dans Cognos en "SQL Natif", et de plus j'appelle mes données (hormis pour des cas très très simples et rares) au travers de fonctions table (Oracle).
De ce fait, avant même l'envoi des données de Oracle vers Cognos, j'ai tout loisirs de me livrer a toutes sortes d'actions, dont celui de traquer tout un tas d'informations.
Je peut donc placer dans chacune des fonctions tables des insert et autres dans une table dédiée qui me permettent ensuite de regarder qui a demandé quoi, a quel rapport, avec quels paramètres, les temps d'exécution / réponse de tous les objets dans Oracle, les éventuels messages d'erreurs, etc...
Alors certes, je ne joue pas a cela avec tous les SQLs appelés depuis les Query Items des rapports en prod (même si je garde une fonction table par rapport qui enregistre un certain nombre d'infos pour ma sauce interne), mais pour des objectifs de tests de ce genre c'était utile.
On peut toujours se demander si l'ordre d'enregistrement des appels aux fonctions tables, etc, corresponds vraiment a l'ordre dans lequel Cognos a demandé les données a Oracle, car après tout je ne fais que supposer.
Disons que la ressemblance est troublante, lorsque je regarde la structure du rapport qui est en train de tourner, et que je regarde les appels qui sont fait et donc enregistrés dans ma petite table perso, pour tous les rapports cela correspondait tout le temps.
De ce fait, rien qu'en lisant ces enregistrements, je pouvais même savoir que la section X avait produit beaucoup de plus de lignes / pages (rapport PDF uniquement dans mon cas) dans le cas A que le cas B, rien qu'en constatant que l'écart entre l'appel de la fonction 1 et la fonction 2 avait grandit de 30 secondes par exemple; ca marchait tout le temps.

Sous réservé donc que je ne me sois pas fait bluffé par quelque chose que je ne vois ou comprends pas.

@+