Files
SCRIPTS-ReportingPBIGenerique/README.md
2025-12-10 17:33:33 +00:00

143 lines
8.0 KiB
Markdown

***<ins> Vous souhaitez deployez un reporting generique powerBI sur un nouveau compte client? </ins>***
Vous êtes au bon endroit.
# Etape 1
La première chose sera d'effectuer les actions necessaires en base de données pour que toute les données soient disponible sur le compte du client
Pour se faire rendez vous sur dbeaver, sur l'IP qui heberge la base de donnée et une fois connecté lancé le script disponible dans le fichier SQL ici présent.
Plusieurs tables + vues vont être alors générés, notamment :
- _f_contact_v2_
- _f_task_v2_
- _f_dossier_v2_
et les colonnes Domaine et Univers qui serviront de filtres.
Voici un déroulé :
### <ins>1. Avec le conseil définir les éléments pour :</ins>
- domaine
- univers
- enseigne
Afin de modifier les requêtes en fonction
### <ins>2. Mise à jour des fonctions, puis passer le SQL (fichier REPORTING_script_generique_TACHES_QUALIFICATIONS_DOSSIERS.sql) :</ins>
/* Création de la table CONTACT */
/* Création de la table TACHE */
/* Création de la table dossier */
/* Création d'une table de logs afin d'historiser les eventuelles erreurs et les lancements */
/* Fonction d'écriture de logs*/
/* Fonction de mise à jour des contacts */ => /!\\ ATTENTION à mettre à jour avec le point 1.
/* Fonction de mise à jour des taches */ => /!\\ ATTENTION à mettre à jour avec le point 1.
/* Fonction de mise à jour des dossiers */ => /!\\ ATTENTION à mettre à jour avec le point 1.
/*
/!\\ ATTENTION à mettre à jour avec le point 1.
Création des fonctions pour definir domaine, univers, enseigne et ceic pour le 3 types de rapport:
- dossier
- tache
- contact
/!\\ ATTENTION à mettre à jour avec le point 1.
Création table de mapping domaine/univers - a remplir selon le besoin par l'AMOA pour avior le libelle univers
*/
### <ins>3. Mise en place des fichiers SH (des fichiers exemples sont disponibles dans le répertoire "SH" afin de visualiser les lancement des vues avec un nombre de jours)</ins>
![relation_active_inactive](https://repolake.alc-crm.com/aurelien.prevost/Reporting_Generique_PowerBI/raw/branch/main/illustrations/Fichiers_SH.png)
```
cd /home/socleng-[COMPTE]/exploit_bacth/REPORTING/PBI
touch Import_Donnees_Task_For_PBI.sh
chmod +x Import_Donnees_Task_For_PBI.sh
vi Import_Donnees_Task_For_PBI.sh
touch Import_Donnees_Contact_For_PBI.sh
chmod +x Import_Donnees_Contact_For_PBI.sh
vi Import_Donnees_Contact_For_PBI.sh
touch Import_Donnees_Dossier_For_PBI.sh
chmod +x Import_Donnees_Dossier_For_PBI.sh
vi Import_Donnees_Dossier_For_PBI.sh
```
### <ins>4. Mise en place dans la crontabs(exemple)</ins>
Epineux sujet, à placer au moment le plus oportun selon les compte, voici les exempls pour monoprix :
```
1 0 * * * bash --login -c "/home/socleng-monoprix/exploit_batch/REPORTING/PBI/Import_Donnees_Dossier_For_PBI.sh" 2>&1 >/dev/null
20 0 * * * bash --login -c "/home/socleng-monoprix/exploit_batch/REPORTING/PBI/Import_Donnees_Contact_For_PBI.sh" 2>&1 >/dev/null
40 0 * * * bash --login -c "/home/socleng-monoprix/exploit_batch/REPORTING/PBI/Import_Donnees_Task_For_PBI.sh" 2>&1 >/dev/null
```
# Etape 2
Une fois ceci fait suivez le mode operatoire disponible dans le fichier PDF disponible dans ce repertoire
## /!\\ ATTENTION
Lors de la création du rapport tâches nous nous sommes heurtés à ce que certains appele des bugs, d'autres des features... Toujours est-il que lorsqu'on le sait ca fonctionne, si on ne le sait pas on peu rapidement y perdre beaucoup de temps en recette pour obtenir les bons KPI.
Voici donc les infos importantes à savoir très succintements.
PowerBI utilise un schema de relation de données (appelé schema en etoile)
On peut allouer des relations active ou inactive notamment ici pour les champs de date. Car parfois certains KPI remontés dans les widgets doivent se référés à tel ou tel colonnes de date.
![relation_active_inactive](https://repolake.alc-crm.com/aurelien.prevost/Reporting_Generique_PowerBI/raw/branch/main/illustrations/relation_active_inactive.png)
Le probleme est que pour l'utilisateur du rapport ce n'est pas très limpide. Lui visuellement n'a qu'un seul selecteur de date dans le volet déroulant (en haut a gauche ici).
![input_date_relations](https://repolake.alc-crm.com/aurelien.prevost/Reporting_Generique_PowerBI/raw/branch/main/illustrations/input_date_relations.png)
Il va donc falloir au niveau des "mesures" utilisées dans PowerBI appliquer parfois des "annulation de relation" et des "activation temporaire" de relation", le temps que le widget calcul les valeurs à retournés visuellement.
N'oubliez jamais que ces relations modifiées sont là dans les mesures.
Selon le client et le rapport dit "generique", ces colonnes peuvent evoluées et être amenées à être modifiées.
Soyez egalement prudent sur quelle relation est réellement active.
On s'est apercu à nos depend que selon comment les table été juxtaposés visuellement dans le schema en etoile, au survol avec la souris, la relation "active" changé! J'ai deplacé la table...depuis plus de probleme.
Mais soyez prudent.
Les "USERELATIONSHIP" et "CROSSFILTER" sont là pour invalider ou valider temporairement une relation.
Référez vous à la doc officiel powerBI pour comprendre ou demandez a quelqu'un qui utilise PowerBI.
Autre point plus delicat. Il existe plusieurs logiciels POWERBI et plusieurs version de ces logiciels.
Sur le pc distant cogrdpabc, nous avons powerbi server et powerbi desktop.
Utilisez celui avec le logo "RS"!
![correct_pbi](https://repolake.alc-crm.com/aurelien.prevost/Reporting_Generique_PowerBI/raw/branch/main/illustrations/correct_pbi.png)
Lorsque l'on clic sur "à propos" pour obtenir la version, qu'importe celui que l'on lance on nous indique qu'il s'agit de powerbi desktop car le report server à pour nom complet "powerbi desktop report server".
Cependant ne sont pas tout à fait les mêmes logiciels bien qu'ayant une interface identique.
En effet Microsoft fait évoluer le moteur DAX et le moteur de requête interne VertiPaq.
Si bien que pour un même widget généré avec une version supérieur ou anterieur on peut se retrouver avec des KPIs qui divergent ou juste ne veulent plus s'afficher.
Force est de constaté que la retrocompatibilité n'est pas total.
Prenez donc soin d'utiliser la version de PBI avec laquelle le rapport a été édité précédemment.
Parfois il y a un avertissement au demarrage parfois pas.
Cependant même si avertissement, rien ne vous empêche de continuer...C'est insidieux mais bref il faut le savoir!
Dans notre cas pour illustrer nous avons remis dans le constructeur visuel le même widget, avec la même mesure qu'un widget déja. Et l'un nous affiché 7 tandis que l'autre 8. Le même widget...
une fois supprimé l'ancien widget et remis tel qu'il été supposé être et les KPI sont revenus d'aplomb.
![version_app_desktop_report_server](https://repolake.alc-crm.com/aurelien.prevost/Reporting_Generique_PowerBI/raw/branch/main/illustrations/version_app_desktop_report_server.png)
Enfin n'oubliez pas que la table que vous importez peut dès son entré dans powerbi avoir subit des modifications de légère à lourde, à même la query SQL ou a posteriori dans le traitement via POWER QUERY.
Ne pensez donc pas que ce que vous voyez dans DBEAVER est ce que POWERBI a.
Les données peuvent avoir été manipulées entre votre table que vous voyez en base, et le visuel powerBI.
Le typage peut aussi avoir été modifié pour des raisons de compatibilitées (exemple date avec ou sans heure), le nom des colonnes, des filtrages additionels etc...
Egalement parfois l'import de la table n'est pas le seul import et des tables de dimensions faisant references à des vues de la base de données sont egalement importé puis relié via des relations à même PBI. D'où le nom de schema en étoile.
![import_donnees](https://repolake.alc-crm.com/aurelien.prevost/Reporting_Generique_PowerBI/raw/branch/main/illustrations/import_donn%C3%A9es.png)
_Fait le 23/09/2025_
_Réalisé par PREVOST Aurelien & FUSEAU Cédric_