Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Outils de restitution et d'analyse Discussion :

Reporting à temps réel


Sujet :

Outils de restitution et d'analyse

  1. #1
    Candidat au Club
    Reporting à temps réel
    Bonjour,

    J'ai comme projet un système de reporting à temps réel, je suis vraiment perdue, je n'ai aucune idée sur les étapes de ce type de reporting.

    S'agit-il des mêmes étapes du reporting périodique? ou y a-t-il une différence?

    Merci d'avance de votre aide.

  2. #2
    Membre émérite
    Bonjour, ce qui serait bien ce serait d'avoir plus de 3 lignes pour décrire le contexte, le besoin, les contraintes. J'ai l'impression que plus le sujet est complexe, moins les gens donnent d'information.

    Sinon, le temps réel implique, normalement, une latence extrêmement faible. L'idée c'est que quand le reporting est réalisé, les données ramenées soient représentatives de ce qu'il y avait dans la BDD à l'instant exact du lancement du rapport. Donc si un utilisateur vient de saisir une facture dans le système, il s'attend à la voir apparaître tout de suite dans son rapport. Par contre si par "temps réel" vous entendez "une latence de l'ordre du 1/4h", vous pouvez oublier tout le contenu de ce post.

    Donc qui dit temps réel dit (en principe)
    - pas d'ETL, éventuellement un EAI par contre
    - pas de modélisation en étoile
    - pas de technologie in memory (du moins pas que je connaisse) ou de cube (à cause de la latence induite par la montée en RAM du modèle commun, mais on peut trouver des solutions avancées)

    On va plutôt être sur de la génération de requête, du BO, du Cognos ou simplement une application web. C'est à dire qu'une action utilisateur va déclencher une requête SQL, exécutée immédiatement, et qui va ramener les données présentes dans la BDD à ce moment-là. La solution consiste donc à préparer des requêtes SQL (ou un modèle de données pour BO/Cognos) et à permettre à l'utilisateur de choisir des filtres à appliquer puis de cliquer sur un bouton. Le clic va générer une requête SQL à la volée, incluant les filtres choisis par l'utilisateur, qui va être exécutée sur le champ dans la BDD et renvoyer les résultats. Charge à vous de les afficher à l'utilisateur.

    Une autre solution consiste à faire du Complex Event Processing (CEP): un outil va recevoir des messages au fur et à mesure de l'activité sur la source (base de données, site web) et va accumuler ces messages pour une utilisation ultérieure. Exemple: on veut détecter si plus de 3 connexions ratées ont eu lieu en 15mn, et envoyer un mail d'alerte si c'est le cas.
    A la 1ere connexion ratée, un message "connexion ratée" est envoyé au CEP (je simplifie) qui déclenche un chronomètre.
    A la 2e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 2e ratée d'affilé".
    A la 3e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 3e ratée d'affilé", il regarde son chronomètre et constate que c'est la 3e en moins de 15mn, donc il déclenche une alerte.
    Pour faire la même chose sans CEP il faudrait faire des requêtes en boucle toutes les 15 mn qui vérifient si 3 connexions ont raté dans les 15 dernières minutes. C'est très lourd.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  3. #3
    Candidat au Club
    Bonjour,

    Merci beaucoup pour cette explication.

    Il s'agit d'un reporting à temps réel (pas vraiment temps réel), où on va créer des vues (SQL) qui vont nous permettre de générer des KPIs, le problème est comment transformer les "tables" générées par ces vues en modèles graphiques?

    Vaut-il mieux d'utiliser un outil de reporting (Reporting services...) ou créer une application Web (VS...) pour gérer ça?

    Merci beaucoup!!




    Citation Envoyé par nuke_y Voir le message
    Bonjour, ce qui serait bien ce serait d'avoir plus de 3 lignes pour décrire le contexte, le besoin, les contraintes. J'ai l'impression que plus le sujet est complexe, moins les gens donnent d'information.

    Sinon, le temps réel implique, normalement, une latence extrêmement faible. L'idée c'est que quand le reporting est réalisé, les données ramenées soient représentatives de ce qu'il y avait dans la BDD à l'instant exact du lancement du rapport. Donc si un utilisateur vient de saisir une facture dans le système, il s'attend à la voir apparaître tout de suite dans son rapport. Par contre si par "temps réel" vous entendez "une latence de l'ordre du 1/4h", vous pouvez oublier tout le contenu de ce post.

    Donc qui dit temps réel dit (en principe)
    - pas d'ETL, éventuellement un EAI par contre
    - pas de modélisation en étoile
    - pas de technologie in memory (du moins pas que je connaisse) ou de cube (à cause de la latence induite par la montée en RAM du modèle commun, mais on peut trouver des solutions avancées)

    On va plutôt être sur de la génération de requête, du BO, du Cognos ou simplement une application web. C'est à dire qu'une action utilisateur va déclencher une requête SQL, exécutée immédiatement, et qui va ramener les données présentes dans la BDD à ce moment-là. La solution consiste donc à préparer des requêtes SQL (ou un modèle de données pour BO/Cognos) et à permettre à l'utilisateur de choisir des filtres à appliquer puis de cliquer sur un bouton. Le clic va générer une requête SQL à la volée, incluant les filtres choisis par l'utilisateur, qui va être exécutée sur le champ dans la BDD et renvoyer les résultats. Charge à vous de les afficher à l'utilisateur.

    Une autre solution consiste à faire du Complex Event Processing (CEP): un outil va recevoir des messages au fur et à mesure de l'activité sur la source (base de données, site web) et va accumuler ces messages pour une utilisation ultérieure. Exemple: on veut détecter si plus de 3 connexions ratées ont eu lieu en 15mn, et envoyer un mail d'alerte si c'est le cas.
    A la 1ere connexion ratée, un message "connexion ratée" est envoyé au CEP (je simplifie) qui déclenche un chronomètre.
    A la 2e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 2e ratée d'affilé".
    A la 3e connexion ratée un message "connexion ratée" est envoyée au CEP qui se dit "Tiens c'est la 3e ratée d'affilé", il regarde son chronomètre et constate que c'est la 3e en moins de 15mn, donc il déclenche une alerte.
    Pour faire la même chose sans CEP il faudrait faire des requêtes en boucle toutes les 15 mn qui vérifient si 3 connexions ont raté dans les 15 dernières minutes. C'est très lourd.

  4. #4
    Membre émérite
    Donc ce n'est pas du temps réel, mais en plus vous avez déjà une partie de la solution.

    Alors si la base de données est SQLServer, l'idéal est sûrement de partir sur du Reporting Services (SSRS) effectivement. Le seul intérêt de faire du Web serait d'avoir une meilleure intégration web : responsive design, mobile, intégration dans un portail, ce genre de choses.

    Mais s'il s'agit de produire un petit tableau, un graphique camembert, un graphique en bâtons à partir de données dans une table (ou via une vue, aucune différence), SSRS sera très bien.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  5. #5
    Candidat au Club
    Je devrais avoir à la fin des vues graphiques très élégantes et très significatives, autrement dit, pour certains KPIs, je devrais avoir des jauges, pour d'autres, des bâtons..., en plus, j'ai la contrainte du coût...

    Je ne sais pas quoi faire?





    Citation Envoyé par nuke_y Voir le message
    Donc ce n'est pas du temps réel, mais en plus vous avez déjà une partie de la solution.

    Alors si la base de données est SQLServer, l'idéal est sûrement de partir sur du Reporting Services (SSRS) effectivement. Le seul intérêt de faire du Web serait d'avoir une meilleure intégration web : responsive design, mobile, intégration dans un portail, ce genre de choses.

    Mais s'il s'agit de produire un petit tableau, un graphique camembert, un graphique en bâtons à partir de données dans une table (ou via une vue, aucune différence), SSRS sera très bien.

  6. #6
    Membre émérite
    Citation Envoyé par nuke_y Voir le message
    [...]SSRS sera très bien.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  7. #7
    Membre averti
    SSRS comme l'a dit Nuke_y, ou PowerBI.
    https://powerbi.microsoft.com

  8. #8
    Candidat au Club
    Citation Envoyé par thibault974 Voir le message
    SSRS comme l'a dit Nuke_y, ou PowerBI.
    https://powerbi.microsoft.com
    Merci pour l'idée.
    Pour résoudre à mon problème, je suis actuellement entrain de faire une étude comparative entre SSRS et d'autres alternatives en prenant en considération
    le coût et d'autres critères.
    Veuillez me donner des idées sur les alternatives que je peux prendre en considération (Open source ou coût faible).

    Merci d'avance.

  9. #9
    Membre régulier
    Bonjour,

    Tu as différents logiciels de reporting.
    Comme dit au dessus SSRS et PowerBI sont des solutions viables si tu utilise SQL Server.

    Après il faut voir ce que tu entends derrière faible coût, mais il existe beaucoup de solutions de reporting et de construction de tableau de bords.
    - Qlik View
    - Tableau
    - Penthao (open source et... gratuit si je ne m'abuse)
    - Bi Board
    - Dig Dash
    etc...

    Mais un outils gratuit et non lié à un système de base de données... bon courage pour trouver.

    Cordialement,

    Slaveak