Discussion :

[maxoverfred]

Bonjour à tous,

Je me permets d'ouvrir ce poste afin de vous poser mes remarques et quelques questions sur l'usage de B.O. 6.1.

Petite intro:

Mon client a implémenté B.O 6.1 via son fournisseur payroll. Cette application n'est utilisée que pour générer des rapports sur les données du payroll.
Donc, l'univers est déjà défini et non-modifiable car livré par le fournisseur payroll.

Quelques observations:

- l'univers est assez complexe à comprendre et aucune documentation n'est mise à disposition pour en comprendre sa structure dans ses moindres détails, résultats, c'est la méthode "try & error" qui prédomine avec une perte de temps énorme. N'y a t il pas moyen de générer une documentation sur cet univers? Avez vous déjà eu pareil expérience?

- des conditions prédéfinies sont également présentes (exemple: travailler en service actuel, salaire mensuel etc...) mais de nouveau aucun moyen de voir ce que cache ces conditions, pas de documentation.

- lors de la création de rapports, nous avons rencontré plusieurs problèmes:

• Ayant différentes classes prédéfinies dont une est intitulée "Eléments clés", nous sommes censés combinés chaque fois les data provider meme pour des queries basiques. Un exemple: liste des employés avec leur code de transport (voiture, bus etc). Il nous a été dit qu'on doit prendre d'un côté un data provider avec les clés telles que numéro de société, numéro de travailleur et de l'autre côté un autre data provider qui reprend ces clés et évidemment les champs nécessaires comme le code transport.
  Déjà, je suis assez étonné qu'on ne puisse nulle part définir des outer join... gros problèmes pour obtenir les infos complètes.
  Ensuite, ayant une connaissance (je pense suffisante) en base de données relationnelles, j'ai très dur à comprendre ce concept de 2 data providers pour une requete aussi simple... Peux etre avez vous des commentaires sur la chose..
• Nous avons aussi remarquer de gros problèmes avec la définitions de critèes dans nos data providers. Donc imaginons que dans ma requete initiale, je ne veux qu'un certain nombre d'employée que je définis correctement, dans mon résultat, il ne m'affichera jamais l'info correcte tant que je n'aurai pas été copier/coller cette clause dans le deuxième data provider

Je me rends bien compte que mon poste est assez laborieux, mais votre expérience et vos commentaires me seront certainement de grande utilité.

Merci d'avance.

[eryk71]

Bonjour,

l'univers est assez complexe à comprendre et aucune documentation n'est mise à disposition pour en comprendre sa structure dans ses moindres détails, résultats, c'est la méthode "try & error" qui prédomine avec une perte de temps énorme. N'y a t il pas moyen de générer une documentation sur cet univers? Avez vous déjà eu pareil expérience?

La documentation est une tâche fastidueuse, est il est logique que se soit le concepteur de l'univers qui la créee. Normarllement, l'univers est créee selon le métier et lapartie fonctionnelle de l'utilisateur, dans ton cas c'est le contraire, c'est l'utilisateur qui doit s'adapter à l'univers. Néanmoins, sous Designer tu peux faire une impression pour obtenir une visiblité des classes sous classes etc..Si cela peut t'aider.
Fichier-> aperçu avant impression, tu auras déjà une petite idée.

des conditions prédéfinies sont également présentes (exemple: travailler en service actuel, salaire mensuel etc...) mais de nouveau aucun moyen de voir ce que cache ces conditions, pas de documentation.

Le SGBDR qui est relié à l'univers est une base de données fournie également par le fournisseur? Si ce n'est pas le cas, tu dois mieux connaitre les termes du SGBDR.
Dans le Designer, tu fais un double click sur la condition prédéfinie, tu auras le code de la condition.

j'ai très dur à comprendre ce concept de 2 data providers pour une requete aussi simple

Je comprends pas bien, les rapports sont également fourni par l'éditeur?
Si ce n'est pas le cas, pourquoi tu utilises 2 fournisseurs de données si ta requête est simple. Pour un fournisseur de donnée tu fais une requête, a moins que tu n'aies 2 univers, dans ce cas effectivement il faut une 2e requête qui sera liée au 2e univers.

il ne m'affichera jamais l'info correcte tant que je n'aurai pas été copier/coller cette clause dans le deuxième data provider

Si tu possèdes 2 univers, c'est normal que tu dois mettre la clause dans le deuxième data provider pour le calcul soit semblable. Si ce n'est pas le cas, il fera l'opération dans le 1er data provider mais également les information du deuxième data provider, d'ou les résultats érronés.

Déjà, je suis assez étonné qu'on ne puisse nulle part définir des outer join

Tu peux le faire dans les rapports si tu ne peux pas toucher à l'univers.
Tu crées 2 requêtes, et tu utilises l'opérateur ensembliste UNION.
Les objets doivent être identiques dans les 2 requêtes, il n y a que la condition qui change.

[maxoverfred]

Je vous remercie pour toutes ces informations.

On ne dispose malheureusement pas d'Application Designer pour l'instant, je vais en faire la demande de suite

Le SGBDR qui est relié à l'univers est une base de données fournie également par le fournisseur?

Correct

Merci pour les conseils concernant les conditions prédéfinies, on y regardera une fois App Designer installé

Je comprends pas bien, les rapports sont également fourni par l'éditeur?
Si ce n'est pas le cas, pourquoi tu utilises 2 fournisseurs de données si ta requête est simple....

Il n'y a qu'un univers bien défini mais (désolé je ne connais pas la terminologie en francais) ici leur univers a l'air tellement tordu que je dois avouer que j'ai difficile a y comprendre quelque chose mais bon nous chercherons encore un peu car je me rends compte que meme en essayant de l'expliquer c'est nébuleux.

Si tu possèdes 2 univers, .......

Non un seul univers, donc, pas de raison de copier la condition dans 2 data providers provenant du meme universe, donc on fait certainement quelque chose incorrectement (et on nous dirige aussi dans la mauvaise direction)


Merci encore