Connexion perdue lors de groupe paramètres en cascade

Hello tout le monde,

J'ai un problème que je n'avais pas avant sur BIRT 2.5 et qui est apparu d'un coup sans que j'en connaisse la raison.

J'ai un rapport (en fait plusieurs) qui est appelé par une page web, celui-ci initialise alors le groupe de paramètres pour se connecter à une base Essbase.

Ce rapport contient un groupe de deux paramètres en cascade de type liste déroulante. Le premier paramètre permet de filtrer la liste du second, les deux paramètres ont deux jeux de données distincts (requêtes MDX).

Jusque là, tout va bien :D

Maintenant lorsqu'on saisit le premier paramètre, il semble que BIRT perde la connexion et la liste qu'affiche le second paramètre n'est pas la bonne. En effet il prend alors les valeurs par défaut d'un groupe de paramètres de connexion (qui permet de se connecter à une autre base).

Je précise que ceux ne comportant pas de groupe de paramètres en cascade marche très bien.

Je planche dessus depuis quelques jours et je n'ai toujours pas de solution à ce problème :(

Est-ce que quelqu'un aurait déjà rencontré ce problème ?

Merci !!!

Bonjour,

Et maintenant tu es dans quelle version ?

Bonjour BiM,

Je me suis mal exprimé, je suis toujours sur 2.5

Je voulais dire que je suis sur 2.5 mais que le problème est apparu d'un coup.

Salut,

pourrais tu aussi préciser comment est établie la connexion avec Essbase? (Un connecteur maison, le connecteur d'actuate, un dataset scripté, openquery,...?). Le jeu de données du deuxième paramètre de la cascade est il défini sur le même cube Essbase que le premier ou sur un autre cube?

Bonsoir donino,

Dans "Source de données", j'ai défini ma connexion Essbase dans "Liaison de propriété" où j'ai mis les paramètres reçus (exemple : dans "olap server name" j'ai "params["essbaseServer"].value").

C'est le seul cube Essbase utilisé.

C'est difficile de cerner le problème. D'après la description tu utilises un connecteur MDX commercial, peut être celui d'Actuate: je ne pense pas que ce soit un problème de connexion car même si BIRT n'arrivait plus à se connecter je ne vois pas pourquoi il mettrait des valeurs par défaut qui n'ont, si j'ai bien compris, rien à voir avec la définition du paramètre :?

Puisque les jeux de données des 2 paramètres sont distincts, l'origine la plus vraisemblable du problème est le lien entre les 2 datasets: est ce que le deuxième dataset est correctement lié au premier par un paramètre en entrée et un filtre dans la requête MDX? Si oui quelle est la valeur par défaut du paramètre en entrée du deuxième dataset, est ce que ça ne serait pas par hasard ces fameuses valeurs par défaut du groupe de connexion? Et vérifie bien si il est lié au premier paramètre de la cascade (Option "Link to report parameters")

Je pense que je me suis mal exprimé :? Je ne suis pas du tout expert en BIRT donc je vais essayer de mieux expliquer ^^

BIRT a des paramètres de connexion définis par défaut dans le groupe de paramètres de connexion. Or afin que BIRT s'exécute sur des environnements différents, le web initialise les paramètres de connexion.

Sur le rapport, les deux paramètres en cascade se basent chacun sur un dataset distinct (et qui a priori utilisent les paramètres de connexion initialisés par le web). Par exemple : pour le premier paramètre, on a la liste "France, US" et en fonction de ce qu'on sélectionne, le second paramètre affiche la liste des régions.

Or quand on sélectionne une valeur dans la première liste, BIRT prend alors les paramètres de connexion par défaut. Le second paramètre n'affiche pas alors la liste voulu, mais celle correspondant à l'environnement par défaut.

J'ai rien compris. Pour moi un paramètre de connexion, c'est utile pour la connexion à une source de données, mais cela n'entre pas en compte dans le détail des données.

Peut être que tu pourrais poster ton rapport sur le forum en prenant le soin d'enlever les informations confidentielles.

BiM tu as raison, mais j'ai quand même une petite idée sur la question, liée au fonctionnement particulier des paramètres en cascade. Je pense que BIRT crée une nouvelle tache à chaque appel ajax pour rafraichir la deuxième liste, en utilisant juste les paramètres de dataset, et c'est très possible qu'il perde les autres paramètres du rapport en chemin. Et donc qu'il retombe sur la connexion par défaut.

Sehes, il y a quelquechose à essayer: il faut ouvrir le dataset du deuxième paramètre en cascade. Dans la section "parameters", il devrait déjà y avoir un paramètre de dataset genre "pays", lié au premier paramètre de la cascade et qui permet de faire le lien entre les régions et le pays choisi. il faut ajouter en plus dans ce lien les paramètres de connexion. Par exemple ajouter un paramètre "essbaseServerInput" et le lier au paramètre de rapport "essbaseServer" que tu as évoqué plus haut.

Fait l'essai et dis nous si il y a du mieux

Tu as bien compris le problème je pense donino.

En fait je ne me sers pas des paramètres du dataset, mais dans le script lié au jeu de données, en beforeOpen je fais un replace des paramètres dont j'ai besoin, y compris ceux du cube et de l'application Essbase (mais il n'y a pas de paramètres "provider" et "olap server name" que l'on retrouve dans la source de données).

J'ai fait un petit test de capture de requête ajax, et je confirme que BIRT ne transmet que le paramètre de la cascade, il ne transmet pas les valeurs des autres paramètres du rapport, donc dans ton cas le serveur Essbase à utiliser. Je pense que ça explique le problème rencontré.

Je me trompe peut être, mais c'est à mon avis une limite de l'utilisation d'un paramètre de rapport pour gérer la connexion. Tu dis dans le premier post que ça marchait en 2.5? Ce n'est pas forcément applicable dans tous les contextes, mais ce problème n'existerait pas par exemple en utilisant un profil de connexion ("connection profile store"), ou une variable système.

Il y a sans doute un moyen de contourner en stockant les informations de connexion dans la session utilisateur, puis en les utilisant dans le script "beforeOpen" du dataset pour modifier la connexion dynamiquement :?

Les rapports ont toujours été en 2.5. Il est par contre possible que ça n'ait en fait jamais marché. Les environnement ont beaucoup changé et peut être que le fait qu'avant les environnements étaient identiques masquait le dysfonctionnement.

Sinon j'avais vu qu'effectivement, Ajax n’envoie pas les paramètres de connexion, j'avais alors essayé ta solution mais ça ne marchait pas. Peut être que je m'y suis mal pris.

A part ça je ne vois pas d'autres solutions.

Je pense avoir compris le problème, mais je reviens sur le message original du topic:

Citation:

---

Je précise que ceux ne comportant pas de groupe de paramètres en cascade marche très bien.

---

Il faudrait refaire un test pour en être certain à 200%, car je mettrais une très grosse pièce sur le fait que ce n'est pas le cas, du moins pour un paramètre de type combobox qui utilise la connexion Essbase. Par exemple, je pense que même le premier paramètre de la cascade (le choix du pays) utilise la connexion par défaut, et pas celle du paramètre. Ce n'est pas évident à voir au premier coup d'oeil si comme tu le précises, les environnements sont très proches.

Si je ne me suis pas trompé, je détaillerai plus car c'est un point très important à connaitre pour tous ceux qui souhaitent paramétrer leurs sources de données.

Je crois que je viens de comprendre le problème :aie:

Il faut noter que l'outil qui permet d'entrer des paramètres sur BIRT est, comme son nom l'indique, un outil. L'outil est passé bien avant les paramètres du rapport, donc si vous sélectionnez un paramètre, il ne sera pris en compte qu'à l'éxécution du rapport. Or quand on en est encore au stade paramétrage, l'éxécution n'est pas encore en cours...

Ce serait plutôt à toi de créer ton propre outil pour changer le paramétrage de la base avant de demander les autres paramètres.

Bonjour tout le monde,

J'ai eu une grosse semaine et je n'ai pas eu trop le temps de chercher une solution de contournement.

Juste que je ne suis pas le seul à avoir le problème.

Apparemment seul un dataset unique marcherait selon le lien...

Citation:

---

Envoyé par sehes

Bonjour tout le monde,

J'ai eu une grosse semaine et je n'ai pas eu trop le temps de chercher une solution de contournement.

Juste que je ne suis pas le seul à avoir le problème.

Apparemment seul un dataset unique marcherait selon le lien...

---

Je pensais pourtant que mon explication avait été claire :)
Ce n'est pas vraiment un bug, c'est un problème d'utilisation.

Oui je ne pense pas que le problème présent puisse être lié au fait qu'il y ait plusieurs datasets, ni même au fait que ce soit un paramètre en cascade.

En créant un paramètre qui affiche directement la liste des régions en dehors du groupe de cascade tu verras qu'il pointera lui aussi toujours sur le serveur Essbase par défaut. Ce serait bien qu'on ait la confirmation de ça, si ce n'est pas le cas il est temps que je parte en WE :?

BiM tu me corriges si je me trompe, je pense dire la même chose que toi sous un autre angle il y a une règle d'or à connaitre:

Les paramètres de rapport sont évalués entièrement indépendamment les uns des autres (sauf si ils sont dans un même groupe de cascade bien sûr...). Cela signifie ici que le params["essbaseServer"] ne sera jamais évalué au moment où les listes de sélection des autres paramètres sont construites, groupe de cascade ou non, et donc que la valeur par défaut de la connexion est utilisée.

Je pense que tu ne m'as pas bien comprise, je n'ai pas parlé de plusieurs DataSet.

Il s'avère que BIRT exécute les paramètres en cascade après que le DataSource ait été chargé. Donc si tu changes un paramètre du DataSource dans l'édition des paramètres, il est trop tard. Où il faut avoir prévu de d'abord choisir le paramètre pour la connexion AVANT l'exécution du rapport.

Si on se met sur le Designer, c'est assez facile à voir puisque les derniers paramètres enregistrés se mettent dans un fichier rptconfig. Il suffit d'éxécuter une première fois le rapport, les données renvoyées par le paramètre en cascade seront celles avec la valeur par défaut. Puis une seconde fois, il prend alors la connexion précédemment choisie et les paramètres dépendront de cette connexion, et ainsi de suite.

C'est un peu compliqué à expliquer à l'oral ;)