Cognos 8.2 - Framework Manager - Comment renommer un champ sans perturber les rapport

[mansoft92]

Bonjour,

Je débute en C8. Je suis dans une phase de prise main de la C8 et je suis tombé sur ce qui me laisse perplexe. C'est tellement gros que je pense être passé à coté de quelques choses.

Je n'explique :
1) J'ai un créé et publié un package.
2) J'ai crée et enregistré un rapport (avec Query Studio).
3) Retour dans Framework Manager : Je renomme le champ d'un « dossier ».
4) J'ouvre le rapport et j'ai le message d'erreur: "Impossible de trouver l'object ......"

Je ne sais même pas comment agir sur le rapport pour corriger le problème.

J'aimerai pouvoir faire ce que je faisait de temps en temps avec Impromptu en C8. Avec Impromptu et les catalogues ce problème ne ce posait pas.
J’ai exploré sans succès la piste suivante :
En formation il me semble me souvenir qu'il était possible de gérer ce problème en utilisant une astuce au niveau du multi-langues ??????

Un petit coup de main me serait très utile.
Merci

[yphilogene]

Dans un modèle construit avec Framework Manager, les query items sont identifiés par un chemin composé de 3 parties (minimum):

[Namespace].[Query Subject].[Query Item]

Lorsque tu construis un rapport, tu écris un fichier XML qui contient le chemin des data items utilisés.

Si tu changes ton modèle après coup via le renommage d'un des éléments entrant dans l'identifiant, il est donc normal que ton rapport soit invalide. Tu te vois donc dans l'obligation de corriger ton rapport. Dans Query Studio, il faut remplacer le data item introuvable par le "nouveau" data item.

Il faut donc être extrêment prudent avec le renommage. Aucun studio ne va corriger automatiquement le XML des rapports déjà sauvegardés.

Pour réaliser un "renommage" sans impacter les rapports, tu peux effectivement TRADUIRE dans une autre langue, sans renommer quoique ce soit dans le 'Design Language' du modèle (langue utilisée pour construire les rapports également). Cette solution est selon moi totalement insuffisante.

Je n'ai donc qu'un conseil à te donner: Nomme correctement et une bonne fois pour toute les query items de ton modèle avant de commencer le développement de tout rapport.

J'admet que cela manque de souplesse. Voici comment je me débrouille lorsque je décide de développer modèle et rapports en parallèle de façon itérative:

1) Je choisis une langue (peu susceptible d'être utilisée par la suite) comme 'Design Language' pour mon modèle et mes rapports. Par exemple, l'anglais zimbabwe.

2) Dans cette langue, je ne renomme absolument rien dans Framework Manager, ie. que je conserve le nom physique des colonnes de mes tables. Dans Query Studio ou Report Studio, je renomme les entêtes de colonnes comme il se doit. Les expressions des items contiennent donc le nom physique des colonnes des tables.

3) Je traduis au fur et à mesure mon modèle dans une deuxième langue, par exemple en anglais.

Ainsi, les rapports que j'ai développé en même temps que mon modèle sont développés en anglais zimbabwe (le renommage étant fait dans les studios).

Lorsque l'intégralité de mon modèle est correctement traduit en anglais, je permet aux utilisateurs de construire les rapports en anglais.

[brunolf]

+++
Tout à fait d'accord, utilise une langue que tu es sur de ne jamais utiliser comme langue de design de ton modèle, et utilise la traduction du nom de tes colonnes.
En plus, c'est ce qu'ils conseillent de faire en formation il me semble...

[mansoft92]

Merci pour ces bons conseils. Je les ai appliqués dans mes jeux de tests.

Voici mes premières constatations :

Tant que les rapports sont créés avec un utilisateur dont le profil "Langue du contenu" est égal à la "Design language" il n'y a pas de problème, quelque soit la "langue du contenu" des utilisateurs qui les ouvrent.
Pas de problème non plus lorsqu’un utilisateur quelconque qui "ENREGISTRE SOUS" le rapport et qu'il y ajoute des colonnes que l'on renomme par la suite.

Les problèmes de renommage se posent uniquement lorsque les rapports sont CREES par des utilisateurs avec un profil "Langue du contenu" différent de la "Design language" du projet (du package).

 En fait tout semble se jouer au moment de la création du rapport. !

Sachant cela, l'idée qui m’est venu (mais je ne sais pas encore comment faire) serait de faire une manip pour faire comme si le rapport avait été CREE par un utilisateur ayant un profil "Langue du contenu" égal au "Design language"


-->> manip. au niveau du portail ? ? ?
-->> manip. au niveau base de données Content store ? ? ? quelle table ? Quelle colonne ?
-->> manip. au niveau fichier sur le serveur C8 ???


Pour l'instant les seules informations que j'ai trouvé faisant référence au package sont dans le portail au niveau des propriétés du rapport :

"Afficher le chemin d'accès, l'identificateur et l'adresse URL"

Chemin d'accès : /content/package[@name='Mon Package']/query[@name='Mon rapport'


Toutes informations ou pistes à explorer sont les bienvenues.
Merci

[yphilogene]

Effectivement, le 'content language' choisi dans les préférences utilisateurs de la personne connectée a son importance au moment de la création des rapports sous Query Studio et Report Studio car il s'agit de la langue dans laquelle sera présenté le modèle (pour peu qu'il soit publié sous plusieurs langues) et donc tous les items utilisés seront identifiés par leurs chemins écrits DANS CETTE LANGUE.

==> Et le XML d'un rapport sauvegardé ne sera jamais modifié par un processus automatique. Seule une opération manuelle le changera.

A ce propos, amuse-toi à faire le test suivant: modifie après coup la propriété USAGE d'un query item. Par exemple, change un query item qui a le usage "fact" pour le passer en "attribute". Tu constateras qui cela n'a AUCUN effet sur tes spécifications de rapports déjà sauvegardés, pour la simple raison que le USAGE est également inscrit dans le XML.



Il ne me semble pas qu'il y ait un paramétrage forçant le 'content language'. Je te déconseille en général de modifier quoique ce soit directement dans le Content Store (en tout cas, si tu le fais, tu peux dire adieu au support Cognos...).