Publication d’Urungi, tableaux de bord, statistiques, Business Intelligence

Posté par  (site web personnel, Mastodon) . Édité par ZeroHeure, bubar🦥, palm123, Benoît Sibaud, Nils Ratusznik, Xavier Teyssier et Davy Defaud. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
32
13
mar.
2019
Bureautique

Nous sommes fiers et heureux d’annoncer la publication d’Urungi, application Web permettant de créer des états, des rapports, des graphiques, des tableaux de bord.

Urungi est destiné à être utilisé par des personnes ne sachant pas — ou ne pouvant pas — faire de requêtes SQL, mais ayant besoin de réaliser des tableaux et des rapports. Urungi est publié sous licence GNU/GPL et pour être complet, il s’agit de la fourche d’un logiciel en déshérence, Widestage. Il reste encore quelques références à cette base qui nous a semblé suffisamment chouette pour que l’on investisse dessus.

Sommaire

Pour arriver à son objectif, Urungi utilise trois concepts :

  • la source de données (data source) ;
  • le calque (layer) : la « vue » qui permet de définir ce qui pourra être utilisé dans les rapports ; cette étape est critique : un calque bien construit permet ensuite de générer très facilement tout rapport et tableau de bord ;
  • les rapports / tableaux de bord (report/dashboard), qui s’appuient sur un ou plusieurs calques.

Tableau de bord

Côté technologie

Urungi est codé en Node.js (Express), MongoDB, AngularJS (1.x), les graphiques sont générés avec c3js. Côté source de données, ça se connecte à des bases MariaDB/MySQL, mais aussi d’autres. N’hésitez pas à les tester, nous nous concentrons sur MariaDB pour notre part.
Pour les curieux qui voudraient savoir d’où vient ce nom « Urungi », qu’ils sachent qu’ils viennent d’apprendre un mot Maori.

Côté fonctionnalités

Connexion à une base de données

Avant de construire nos tableaux de bord, il faut se connecter à une base de données. Urungi propose des connecteurs vers MariaDB, PostgreSQL, MSSQL et Oracle. Un connecteur vers mongoDB est aussi disponible, mais à cette heure il ne fonctionne plus ; nous l’avons désactivé.

Création de calques

Un calque, c’est une couche intermédiaire entre la base de données et l’utilisateur final. On peut le voir comme une vue. Un informaticien (généralement) va construire un (ou plusieurs) calques, qui permettront ensuite à l’utilisateur final de construire ses rapports, graphiques et tableaux de bord.

Un calque contient :

  • des champs de la base (issus de n’importe quelle table de la base de données) ; chaque champ a son libellé Urungi et quelques paramètres additionnels comme le format, le groupement par défaut, le type (numérique, alphabétique) ;
  • des dossiers : on peut regrouper les champs dans des blocs fonctionnellement cohérents, pour organiser la vue ; par exemple, dans une base « fournisseur, commande, lignes de commande, produit », on pourrait avoir un dossier « Fournisseur » et un groupe « Commande » ; on peut avoir des sous‐dossiers sur autant de niveaux que l’on veut, celui qui construit le calque peut organiser les choses comme il le souhaite ;
  • des champs calculés : il s’agit de champs qui ne sont pas directement issus de la base de données, mais calculés à partir de ses champs, les formules disponibles sont celles de la base de données sous‐jacente — par exemple, si l’on a un champ date_cmde, on peut créer un YEAR(date_cmde).

Création de rapports

Urungi permet la création de listes, de tableaux, de graphiques en quelques clics, une fois votre calque défini.
Selon le type de rapport à créer, il suffit de glisser/déposer les champs sur lesquels vous souhaitez faire votre rapport, préciser quelques paramètres additionnels, cliquer sur Refresh, et vous avez une première ébauche de votre rapport (calculé par défaut sur les cinq cents premières données renvoyées par la base de données).
Il est également possible de :

  • définir des paramètres à sélectionner au moment de l’exécution du rapport ;
  • publier le rapport pour le rendre accessible aux autres utilisateurs d’Urungi (et bientôt le rendre public)

Création rapport

Création de tableaux de bord

Urungi vous permet de définir des tableaux de bord comportant plusieurs rapports, avec une mise en page libre. Le système est d’ores et déjà très souple et sera encore amélioré dans les mois qui viennent. Un mécanisme de « boîtes » définissent les lignes de votre tableau de bord. Chaque ligne comporte une, deux, trois ou quatre boîtes, qui peuvent à leur tour contenir des sous‐boîtes. Dans chaque boîte, du texte, un rapport, une image, etc. Tout est modifiable, c’est du HTML avec une surcouche graphique.

Look tableau de bord

Importation et exportation

Il est possible d’exporter (en JSON) calques, rapports et tableaux de bord, ce qui permet de déployer très facilement des lots chez des utilisateurs aux besoins multiples.
Dans le cas de BibLibre : nos clients (environ 200) sont exclusivement des bibliothèques, qui utilisent des logiciels que nous avons déployés chez eux. Les besoins sont très similaires d’un établissement à l’autre. Nous avons une instance interne sur laquelle nous créons nos rapports, un coup d’exportation et d’importation, et on déploie très simplement !

La feuille de route

Nous commençons à déployer Urungi chez nos clients, nous considérons donc que c’est assez stable. Mais il reste encore de nombreuses choses à faire :

  • ajouter des types de graphiques (timeline et map, par exemple) ;
  • exporter un tableau de bord en PDF ;
  • programmer l’envoi d’un tableau de bord en PDF par courriel ;
  • définir des feuilles de style pour changer l’apparence des tableaux de bord très simplement ;
  • historiser les tableaux de bord (cas d’usage : je veux mémoriser les statistiques que je sors tous les ans et envoie au ministère) ;
  • permettre au constructeur de tableaux de bord de définir des durées de mise en cache des résultats (certains tableaux ne n’évoluent que très peu, il est inutile de tout recalculer à chaque fois, une fois par jour, semaine ou mois, ça suffit) ;
  • faire en sorte qu’un calque puisse attaquer plusieurs sources de données.

Contribuer

Nous serons ravis de tester et intégrer toute demande d’intégration Git (pull request), nous souhaitons vraiment qu’une communauté puisse se construire autour de cet outil !
Pour les curieux : « nous », c’est la société BibLibre, spécialisée dans les logiciels libres à destination des bibliothèques. Nous sommes une vingtaine de collaborateurs, et allons déployer Urungi chez nos clients.

Aller plus loin

  • # Layers Mantis

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Nous utilisons Mantis en interne, nous sommes actuellement en train de préparer des layers et des tableaux de bord pour cet outil. Si ça vous intéresse, me contacter.

  • # Base infocentre ?

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Vous attaquez directement les données de la base de prod’ (ou une réplication à l’identique), ou alors vos calques constituent une base intermédiaire dénormalisée ?

    • [^] # Re: Base infocentre ?

      Posté par  (site web personnel) . Évalué à 1.

      Vu le pré-requis MongoDB je suppose qu'ils stockent le résultat d'un rapport jusqu'à ça mise à jour ?

      Born to Kill EndUser !

      • [^] # Re: Base infocentre ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Fail ;)

        La base mongoDB, c'est pour stocker les rapports, pas les résultats des rapports et les données que l'on interroge. Ca pourra(it) évoluer à l'avenir, mais pour l'instant, ce pré-requis ne sert pas à faire un intermédiaire entre Urungi et les sources de données.

    • [^] # Re: Base infocentre ?

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Pour l'instant, Urungi attaque directement la base à laquelle on connecte le layer. Pas d'intermédiaire transparent et géré par Urungi.
      Donc la base de prod ou une réplication. Pour nos clients petits, on va attaquer la base de prod, pour les gros, on va monter un serveur de réplication de la base. On n'a pas besoin de traiter des données "chaudes", quasi que du "froid" (voire tiède).
      Dans une bibliothèque, le catalogue ne bouge pas fondamentalement d'un jour à l'autre, ni les engagements budgétaires ou les inscriptions. Donc c'est acceptable d'avoir des données "de la veille".
      Ou bien on fera un master/slave et on interrogera le slave.

      Et dans la roadmap il y a "mise en cache des résultats", qui permettra d'alléger encore la charge des serveurs de prod.
      On a conscience que c'est une limite d'Urungi à ce jour, et que c'est ce qui fait que ça ne peut pas (encore) rivaliser avec des outils de BI.
      Autre limitation du même accabit : on ne peut pas agréger de manière transparente plusieurs sources de données.

      Mais bon c'est le début, ça va évoluer avec les 15 000 développeurs qui vont rejoindre le projet ;)

  • # User friendly

    Posté par  (site web personnel) . Évalué à 2.

    Interessant, depuis le temps que je cherche une solution pour permettre à mes utilisateurs de créer leurs propres requêtes sur notre ERP et non plus devoir faire appel à moi pour créer un état Crystal Report.

    Reste plus qu'à monter un ptit container pour tester la bête.

    Born to Kill EndUser !

    • [^] # Re: User friendly

      Posté par  (site web personnel) . Évalué à 2.

      Crystal report o_O en 2019 ?! Je croyais que cela avait été intégré à BusinessObject^W BOXI^W SAP BI ?

      C'est toujours un client lourd ?

  • # La concurrence

    Posté par  . Évalué à 4.

    Vous vous lancer sur un sujet très intéressant.

    Avez vous fait l'état des lieux ?

    Moi j'ai noté

    https://redash.io

    et

    https://github.com/apache/incubator-superset/blob/master/README.md

    Le premier a ma préférence

    Pourquoi pas plutôt contribuer à ceux-ci.

    Car sinon la pente va être raide

    Bon courage

    • [^] # Re: La concurrence

      Posté par  (site web personnel) . Évalué à 2.

      Les deux que tu cite semble très bien mais bien plus complexe à installer, du coups c'est peut être pas la même cible.

      Born to Kill EndUser !

    • [^] # Re: La concurrence

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Hello,
      J'ai jeté un oeil à redash et un demi-oeil à superset.

      redash.io

      Ca ne répond pas à la première contrainte : pas de SQL, il faut qu'un simple bibliothécaire (nos clients) puissent faire ses propres rapports avec du drag and drop.
      Si j'ai bien vu redash, il y a du SQL 'visible'.
      Dans Urungi, la couche SQL est "cachée" dans le layer. Pour faire un layer, il faut bien maîtriser la structure des données, mais une fois que c'est fait l'utilisateur lambda fait ses rapports & tableaux en quelques clics. Ça présente quelques limites, notamment la requête générée n'est pas toujours optimale, mais l'avantage "utilisateur final" est plus important pour nous. En tous cas, ça répond à ce que l'on voulait proposer à nos clients !

      superset

      Là, clairement, on ne joue pas dans la même cour…
      Que ce soit en terme de fonctionnalités, de complexité d'installation. Rien que la liste des graphes disponibles dans superset le montre clairement : Urungi propose 5-6 types de graphes, superset … 47
      La liste des utilisateurs est tout aussi claire de A comme Airbnb à Z comme Zalando…

      C'est cool, ça fait de la variété et ça couvre des besoins différents.

      Vive le libre !

  • # Sympa comme tout

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 14 mars 2019 à 13:18.

    C'est sympa et facile d'accès de ce coté rien à dire

    Vous avez testé avec du volume quelques millions de lignes par exemple …

    Sinon beau travail

    • [^] # Re: Sympa comme tout

      Posté par  (site web personnel) . Évalué à 1.

      J'dois avoir de quoi charger la bête au boulot ;)

      Une fois le connecteur Oracle paramétré, si tu veux venir faire des tests c'est avec plaisir.

      Born to Kill EndUser !

    • [^] # Re: Sympa comme tout

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      En sous-main, ça génère des requêtes natives. Donc les perfs seront celles de la requête.
      Avec, selon le graphique généré, le surcoût "dessin c3js". Lorsqu'on a beaucoup de valeurs à grapher, ça peut être long, mais ce n'est pas à cause de la BD, c'est le coût du dessin.

      Et sur le plan produit :
      - stocker (et afficher) la durée d'exécution d'un rapport (la dernière fois qu'on l'a exécuté) pour que l'utilisateur puisse voir combien de temps ça prendra d'avoir une réponse
      - améliorer quelques comportements pas idéaux (par exemple : un tdb, même s'il a des paramètres, se trace dès qu'on l'ouvre. Il faudrait qu'il ne se trace que lorsque l'utilisateur lui demande, après avoir saisi les paramètres -ou validé sans paramètre-)
      - ajouter un "cache résultat", que le créateur du rapport peut activer, en précisant la durée du dit cache. Qui permettra de soulager encore le serveur.

      • [^] # Re: Sympa comme tout

        Posté par  (site web personnel) . Évalué à 3.

        En sous-main, ça génère des requêtes natives. Donc les perfs seront celles de la requête.

        Donc en cas de requete complexes il vaut mieux paramètrer des vues, de toute façon IMHO une base BI doit être différente (copie ou MAJ regulière) de la base de PROD

        Il vaut mieux bosser sur l'ergonomie et la facilité d'utilisation et laisser l'optimisation BDD pour l'instant

  • # Cubes ?

    Posté par  (site web personnel) . Évalué à 2.

    Bravo à vous c'est courageux comme démarche.
    Juste une petite question quand même: je ne vois que des SGBD-R dans la liste (ce qui est déjà très bien), avez-vous prévu de vous connecter à des bases multi-dimensionnelles aussi ? Quand on a une volumétrie importante on passe souvent par des agrégations préalables pour les calculs i.e des cubes même si le monde de l'oss n'est pas la cible préférée de ces outils souvent propriétaires hélas.

    • [^] # Re: Cubes ?

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Urungi répond à une problématique qui est la notre : on l'a développé pour nos besoins. La question des cubes OLAP ne fait pas partie de nos besoins.
      Après, l'idée étant que d'autres adoptent le produit et montent dans la barque du dev, on ne peut rien exclure ;)
      Mais pour les besoins que nous voulons couvrir, pas d'OLAP.
      PS: pas d'Oracle non plus, pourtant on a déjà eu notre premier ticket à ce sujet : https://github.com/biblibre/urungi/issues/15 :D

      Vive le libre !

  • # Atelier Urungi à ELAG2019

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Pour les lecteurs tardifs de ce billet : j'animerai un atelier Urungi à ELAG2019, Berlin, le 7 mai : https://www.elag2019.de/bootcamps.html#urungi (en anglais)

    Welcome onboard.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.