Ganz gleich, ob Sie den Wechsel zu IBM Cognos Analytics on the Cloud erwägen, JDBC-Treiber anstelle eines nativen Datenbankclients verwenden möchten oder einfach nur einen besseren Einblick in leistungsbezogene Merkmale von Abfragen wünschen, die Einführung des dynamischen Abfragemodus ist eine gute Idee.
Als die Performance Food Group, einer der vertrauenswürdigsten Marktführer in der Foodservice-Branche, kürzlich im Rahmen ihres kontinuierlichen Verbesserungsprozesses von Cognos 10.2.1 auf 11.0.12 aufgerüstet hat, beschlossen sie, auch ihre Pakete von CQM auf DQM zu aktualisieren. Sumit Kumar, der für die Überwachung von Berichten, Analysen und Beratung zuständige IT-Manager bei PFG, war für die Paketmigration verantwortlich und hatte die Aufgabe, alle Herausforderungen zu meistern, die während dieses Prozesses auftreten können.
Vorteile der Umstellung von CQM auf DQM
Die Gründe für die Migration der Performance Food Group waren vielfältig. Einer der Hauptvorteile der Konvertierung für Sumit und PFG insgesamt war die Möglichkeit, Berichte zu verwenden, die Daten aus mehreren Paketen innerhalb desselben Berichts enthalten. Der dynamische Abfragemodus würde es Sumit ermöglichen, Berichte zu verwenden, die Daten aus mehreren Themenbereichen wie Verkauf, Beschaffung und Inventar enthalten, obwohl sie sich in drei völlig unterschiedlichen Paketen befinden. Der kompatible Abfragemodus verfügt nicht über diese Funktion, daher lag die Wahl auf der Hand.
Die Umstellung vom kompatiblen Abfragemodus in den dynamischen Abfragemodus würde ihnen auch die Möglichkeit geben, die Berichtsausführungszeit durch die Nutzung der Abfrageausführung auf einer 64-Bit-Architektur erheblich zu verkürzen. Durch die Migration wusste Sumit, dass nicht nur die Infrastruktur geschaffen wurde, um zukünftige Upgrades zu erleichtern, sondern auch der Performance Food Group die Möglichkeit gab, prädiktive Analysen in ihre Automatisierung einzuleiten.
Die Vorteile der Konvertierung waren offensichtlich, aber welche Herausforderungen standen bevor?
Nachdem Sumit 13 zu konvertierende Cognos-Pakete ausgewählt hatte, stieß er in der Projektplanungs- und Ausführungsphase auf seine ersten Hindernisse.
Herausforderungen bei der Projektplanung und -durchführung
Der Erste roadBlock Sumit stand vor der Wahl zwischen Waterfall oder Agile Delivery. Sumit wählte letzteres für seine CQM-zu-DQM-Konvertierung, weil es ihm ermöglichte, jedes Paket unabhängig bereitzustellen. Pakete wurden bereitgestellt, wenn alle wichtigen Berichte erfolgreich ausgeführt wurden und wenn einige Berichte mit niedriger Priorität Fehler aufwiesen, wurde das Paket trotzdem bereitgestellt und die Berichte später korrigiert. Dies ermöglichte es ihnen, im Voraus ohne Zeitverlust einen Geschäftswert zu liefern, aber um auf Nummer sicher zu gehen, hielten sie einen Puffer von einem Monat für den Fall bereit, dass sie zusätzliche Hilfe vom IBM Produktsupport-Team benötigten.
Nachdem Sumit und Performance Food Group nun die Projektplanungs- und Ausführungsphase überstanden hatten, war es an der Zeit, das nächste Thema anzugehen: technische und infrastrukturelle Herausforderungen aufgrund des Verhaltens der Pakete im dynamischen Abfragemodus.
„Laut Sumit war die Umstellung von CQM auf DQM sehr gut investierte Zeit und Mühe. Nach der Konvertierung wurde die Berichtsausführungszeit im Durchschnitt um 60 % verkürzt!“
Technische und infrastrukturelle Herausforderungen
Der dynamische Abfragemodus erzwingt Best Practices, die im kompatiblen Abfragemodus optional waren. Ein Beispiel hierfür wäre die Verwendung von Bindestrichen und Sternchen mit einem Schrägstrich als kommentierte Zeile, zum Beispiel '-' vs '/*'. CQM akzeptiert all dies, während DQM dies manchmal akzeptiert und manchmal nicht, je nach Platzierung. Diese scheinbar kleinen Probleme können dazu führen, dass sporadische Fehler oder sogar ganze Berichte fehlschlagen. Es war auch bekannt, dass Kommentare in erweiterten Filtern, SQL-Abfragen und benutzerdefinierten Berechnungen Fehler verursachten. EIN SQL-Abfrage vergleichen wurde in Erwägung gezogen, die Platzierung zu formatieren und das Auftreten von Fehlern aus diesem Bereich zu reduzieren, aber die Untersuchung ging noch weiter, um alle aufgetretenen Fehler zu sehen. Die Einbeziehung einer Summenfunktion in das Datenmodell oder die Paketdefinition führte ebenfalls zu Fehlern, dies kann jedoch behoben werden, indem sie stattdessen durch die Gesamtfunktion oder Sum() vs Total() ersetzt wird.
Der dynamische Abfragemodus macht auch bestimmte Annahmen, die der kompatible Abfragemodus nicht trifft, was dazu führt, dass sich die Berichtsausgaben unterscheiden. Das Ausführen von Berichten in CQM und DQM kann zu unterschiedlichen Ergebnissen führen, die nur darauf basieren, wie sie die Funktion interpretieren. Beispielsweise erhalten Sie mit Total(Total(Sales)) in CQM ein Ergebnis, das dem Gesamtumsatz entspricht und die doppelte Gesamtsumme ignoriert, während es in DQM die doppelte Gesamtsumme nicht ignoriert, wodurch Sie eine andere Berichtsausgabe erhalten. In ähnlicher Weise variiert auch die Art und Weise, wie Aggregationsoptionen in CQM und DQM implementiert werden. Die Filter für berechnete/aggregierte Spalten können je nach Auswahl der Aggregateigenschaften zu unterschiedlichen Ergebnissen führen, z. B. „Vor der Aggregation“ oder „Nach der Aggregation“.
Andere Herausforderungen
Der dynamische Abfragemodus wendet möglicherweise eine andere Reihenfolge von Vorgängen an, die zu Änderungen in der Berichtsausgabe führen können.
- Die Kardinalitätsdefinition auf Berichtsebene führt zu Änderungen in der Berichtsausgabe.
- Die Berichtsvalidierung kann auch dann noch kritische Fehler anzeigen, nachdem die Warnmeldungen behoben wurden. Alle Warnmeldungen müssen behoben werden, bevor der Berichtscompiler Ihnen den tatsächlichen Fehler anzeigen kann. Wenn ein Bericht nicht ausgeführt wird und nur eine Warnmeldung anzeigt, müssen Sie zuerst die Warnmeldung korrigieren, bevor der Bericht den kritischen Fehler aufdeckt und Ihnen ermöglicht, ihn zu beheben.
- Das Rendern von Berichten mit großen Datenmengen kann mit „Java nicht genügend Arbeitsspeicher“ fehlschlagen, kann aber durch Deaktivieren der lokalen Caching-Eigenschaft in den Berichtseigenschaften für diese Berichte behoben werden
- Die JVM-Konfiguration muss gemäß Best Practices optimiert werden, um zukünftige Probleme zu vermeiden.
Fazit
Laut Sumit war der Migrationsprozess sehr gut investiert. Nach der Konvertierung wurde die Berichtsausführungszeit im Durchschnitt um 60 % reduziert! Er empfiehlt auf jeden Fall, Pakete von CQM in DQM und Ihre Umgebung von 32-Bit auf 64-Bit zu konvertieren.
Ziehen Sie eine Konvertierung vom kompatiblen Abfragemodus in den dynamischen Abfragemodus in Betracht oder wurden Sie kürzlich konvertiert? Wir würden uns freuen, wenn Sie Ihre Erfahrungen oder Tipps und Tricks mit uns teilen!
Möchten Sie mehr erfahren? Wir haben gehostet Webinar wo wir die Herausforderungen diskutierten, mit denen die Performance Group bei ihrer Migration zum dynamischen Abfragemodus konfrontiert war. Antworten Sie auf das Webinar, indem Sie hier klicken.
