Que vous envisagiez de passer à IBM Cognos Analytics on the Cloud, que vous souhaitiez utiliser des pilotes JDBC au lieu d'un client de base de données natif, ou que vous souhaitiez simplement une meilleure visibilité sur les caractéristiques liées aux performances des requêtes, l'adoption du mode de requête dynamique est une excellente idée.
Lorsque Performance Food Group, l'un des leaders les plus fiables du secteur de la restauration, est récemment passé de Cognos 10.2.1 à 11.0.12 dans le cadre de son processus d'amélioration continue, il a décidé de mettre à jour ses packages de CQM à DQM également. Sumit Kumar, le responsable informatique de PFG chargé de superviser les rapports, les analyses et les conseils, était en charge de la migration de leurs packages et chargé de surmonter tous les défis qu'ils pourraient rencontrer au cours de ce processus.
Avantages de la conversion de CQM en DQM
Les raisons de la migration de Performance Food Group étaient nombreuses. L'un des principaux avantages de la conversion pour Sumit et PFG dans son ensemble était la possibilité d'utiliser des rapports contenant des données de plusieurs packages dans ce même rapport. Le mode de requête dynamique permettrait à Sumit d'utiliser des rapports contenant des données de plusieurs domaines tels que les ventes, les achats et les stocks, même s'ils se trouvent dans trois packages complètement différents. Le mode de requête compatible n'a pas cette capacité, le choix était donc évident.
La conversion du mode de requête compatible au mode de requête dynamique leur permettrait également de réduire considérablement le temps d'exécution des rapports en tirant parti de l'exécution des requêtes sur une architecture 64 bits. En migrant, Sumit savait qu'ils ne mettaient pas seulement en place l'infrastructure pour faciliter les futures mises à niveau, mais qu'ils donnaient également à Performance Food Group la possibilité d'initier des analyses prédictives dans leur automatisation.
Les avantages de la conversion étaient évidents, mais quels défis nous attendaient ?
Après avoir choisi 13 packages Cognos à convertir, Sumit a rencontré ses premiers obstacles lors de la phase de planification et d'exécution du projet.
Défis de planification et d'exécution de projet
La première roadle blocage auquel Sumit était confronté était de choisir entre Waterfall ou Agile Delivery. Sumit a choisi ce dernier pour sa conversion CQM en DQM car il lui a permis de déployer chaque package de manière indépendante. Les packages étaient déployés lorsque tous les rapports importants étaient exécutés avec succès et si certains rapports de faible priorité comportaient des erreurs, ils déployaient quand même le package et corrigeaient les rapports ultérieurement. Cela leur a permis de fournir une valeur commerciale en amont sans perdre de temps, mais pour ne pas perdre de temps, ils ont conservé un délai d'un mois au cas où ils auraient besoin d'une aide supplémentaire de la part de l'équipe de support produit d'IBM.
Maintenant que Sumit et Performance Food Group avaient surmonté la phase de planification et d'exécution du projet, il était temps pour eux de s'attaquer au problème suivant : les défis techniques et d'infrastructure dus au comportement des packages en mode de requête dynamique.
« Selon Sumit, la conversion de CQM en DQM a été du temps et des efforts très bien dépensés. Après la conversion, le temps d'exécution des rapports a été réduit de 60 % en moyenne !
Défis techniques et infrastructurels
Le mode de requête dynamique applique les meilleures pratiques qui étaient facultatives dans le mode de requête compatible. Un exemple de ceci serait l'utilisation de tirets et d'astérisques avec une barre oblique comme ligne commentée, par exemple, '-' vs '/*'. CQM accepte tout cela alors que DQM l'accepte parfois et parfois non, selon le placement. Ces problèmes apparemment mineurs peuvent entraîner des erreurs sporadiques ou même l'échec de rapports entiers. Les commentaires dans les filtres avancés, les requêtes SQL et les calculs personnalisés étaient également connus pour provoquer des erreurs. UNE Comparer la requête SQL L'outil a été considéré pour formater le placement et réduire l'occurrence d'erreurs de cette zone, mais l'enquête est allée plus loin afin de voir toutes les occurrences d'erreur. L'inclusion d'une fonction de somme dans le modèle de données ou la définition de package a également créé des erreurs, mais cela peut être corrigé en la remplaçant par la fonction de total, ou Sum() vs Total().
Le mode de requête dynamique fait également certaines hypothèses que le mode de requête compatible ne fait pas, ce qui entraîne des sorties de rapport différentes. L'exécution de rapports dans CQM vs DQM peut vous donner des résultats différents uniquement en fonction de la façon dont ils interprètent la fonction. Par exemple, le Total(Total(Sales)) dans CQM vous donnera un résultat équivalent au total des ventes et ignore le total en double alors que dans DQM, il n'ignore pas le total en double, vous donnant une sortie de rapport différente. De même, la façon dont les options d'agrégation sont implémentées dans CQM vs DQM varie également. Les filtres sur les colonnes Calculé/Agrégé peuvent conduire à des résultats différents en fonction de la sélection de la propriété d'agrégat, telle que « Avant l'agrégation » ou « Après l'agrégation ».
Autres défis
Le mode de requête dynamique peut appliquer un ordre d'opérations différent qui peut entraîner des modifications dans la sortie du rapport.
- La définition de la cardinalité au niveau du rapport entraîne des modifications dans la sortie du rapport.
- La validation du rapport peut toujours afficher des erreurs critiques même après la résolution des messages d'avertissement. Tous les messages d'avertissement doivent être corrigés avant que le compilateur de rapports puisse vous montrer l'erreur réelle. Si un rapport n'est pas en cours d'exécution et n'affiche qu'un message d'avertissement, vous devez d'abord corriger le message d'avertissement avant que le rapport ne révèle l'erreur critique et vous permette de la corriger.
- Le rendu de rapports avec d'énormes quantités de données peut échouer avec des problèmes de "Java à court de mémoire", mais peut être résolu en désactivant la propriété de mise en cache locale dans les propriétés de rapport pour ces rapports, et peut également être facilité en augmentant la mémoire configurée pour le service de requête
- La configuration JVM doit être affinée conformément aux meilleures pratiques afin d'éviter de futurs problèmes.
En conclusion
Selon Sumit, le processus de migration a été un temps et des efforts très bien dépensés. Après la conversion, le temps d'exécution des rapports a été réduit de 60% en moyenne ! Il recommande vivement de convertir les packages de CQM en DQM et votre environnement de 32 bits à 64 bits.
Envisagez-vous de passer du mode de requête compatible au mode de requête dynamique ou avez-vous récemment été converti ? Nous serions ravis que vous partagiez votre expérience avec nous ou des trucs et astuces que vous pourriez avoir !
Vous voulez en savoir plus ? Nous avons accueilli un en direct où nous avons discuté des défis rencontrés par Performance Group dans leur migration vers le mode de requête dynamique. Répondez au webinaire en cliquant ici.
