Keine Frage: Berichte sollten beim Öffnen stets die aktuellen Werte zeigen. Was aber sind die aktuellen Werte? Ist der Aktualisierungsstand von Bericht zu Bericht überhaupt identisch? Und vielleicht möchte der ein oder andere Anwender einen Bericht dann doch noch einmal auf eine beliebige Vorperiode umschalten. Diese Überlegungen können Berichtentwickler ganz schön ins Schleudern bringen, denn die Lösung des ganzen Themenkomplexes rund um die Berichtsaktualisierung ist alles andere als selbstverständlich. Welche technischen Probleme hierbei entstehen und wie man ihnen erfolgreich begegnet, erfahren Sie in vorliegendem Blogbeitrag.

Berichtsfilter statt Aktualisierungslauf

In einem unserer Projekte enthielt die DeltaMaster-Anwendung Daten aus vier Vorsystemen zu vier unterschiedlichen Themenblöcken. Hierbei handelte es sich um Personaldaten aus einem individuellen Personalsystem, operative Absatzdaten aus Navision, Monatsabschlussdaten aus SAP sowie GuV und Bilanzdaten aus IDL. Problematisch war in diesem Zusammenhang die zeitliche Aktualisierung der Berichte im Hinblick auf die jeweiligen Themenblöcke, da die Daten aus den unterschiedlichen Vorsystemen einen völlig unterschiedlichen Periodenbezug aufwiesen. Die Daten aus Navision wurden beispielsweise täglich geladen, während die Bilanzdaten erst drei Wochen nach Monatswechsel zur Verfügung standen. Folglich mussten die Berichte je nach Thema mit unterschiedlichen Berichtsperioden aufgerufen werden. Dies stellte aber ein Problem dar, denn die sonst übliche Art zur Aktualisierung einer Berichtsmappe durch eine einzige Periode, die beispielsweise im DeltaMaster Berichtsserver definiert wird, war hier nicht praktikabel. Auf der Suche nach einer Lösung entschieden wir, jeden Bericht durch eine Abfrage, die als Filtereinstellung in der zugrunde liegenden Pivottabelle verankert wird, mit seiner individuellen Periode voreinzustellen. In unserem Projekt wurden hierzu die spezifischen Berichtsperioden zu jedem der vier Themen in vier Attributen einer Dimension Berichtsjahr hinterlegt.

Abb. 1: Dimension Berichtsjahr mit Attributen und Periodeneinträgen je Thema

Die Attribute wurden im Data Warehouse befüllt, entweder automatisch – sofern dies möglich war – oder im Fall der sog. Kompass_Periode_GuV durch manuelle Eingabe im Sinne einer formalen Freischaltung durch den Controllingleiter. Durch einen MDX-Befehl wurde der Attributeintrag als Text abgefragt und dann mittels der StrToMember-Funktion in die entsprechende Berichtsperiode überführt. Dieses MDX wurde als Filter der Periodendimension in jeder Pivottabelle ausgeführt:

StrToMember(
"[Periode].[Periode].[Monat].&[" + <view_Berichtsjahr>.Properties("Kompass_Periode_GuV")+ "]")

Jede Pivottabelle stand nun fest auf ihrer gültigen und aktuellen Berichtsperiode. Durch diesen kleinen aber feinen Kniff schlugen wir gleich zwei Fliegen mit einer Klappe: Zum einen ermöglichte uns dieser Ansatz die notwendige individuelle Sichteinstellung der Berichte, zum anderen – und das stellte sich als überaus nützlich heraus – gab es fortan keine Notwendigkeit mehr, die Berichtsmappen für die Empfänger durch nächtliche Verarbeitungsläufe auf den aktuellen Stand zu bringen. Damit sparten wir jeden Tag stundenlange Laufzeiten zur Aktualisierung von mehr als 60 Berichtsmappen. Denn mit unserem Ansatz erledigte der Filter, der in der Pivottabelle verankert war, die Aktualisierung der Berichte – automatisch und bei jedem Aufruf durch den Berichtsempfänger.

Flexibilität ist gefragt

Obiges Konzept hatte sich bestens bewährt. Bis zu dem Tag, an dem ein Anwender den Wunsch äußerte, einen Bericht auf einen beliebigen Vormonat zurückzuschalten. Normalerweise bräuchten wir für den Viewer-Modus nur die Periodendimension in der Berichtssicht freizugeben, sodass die gewünschte Periode im Dimensionsbrowser ausgewählt werden kann. Da aber die Periodendimension in unseren Berichten schon als aktiver Filter in der zugrunde liegenden Pivottabelle eingesetzt wurde, griff die Sichteinstellung nicht mehr. Sie wurde durch die Filterabfrage einfach übersteuert. Folglich war kein nachträgliches Umschalten über die Sicht mehr möglich. Jetzt waren Ideen gefragt, ob und wie sich beides – Voreinstellung und nachträgliches Umschalten der Berichtsperiode – realisieren ließe.

Gesucht und gefunden

Ideen hatten wir dann reichlich. Jedoch waren diese alles andere als einfach zu implementieren. Also machten wir uns auf die Suche nach weiteren Alternativen und stießen hierbei auf eine Standardfunktion in den Berichtseigenschaften, die genau unsere Anforderung abbildete. Jeder kennt die Möglichkeit, den Sichtkontext eines Berichts über die entsprechende Option in den Berichtseigenschaften zu definieren. Als wir in diesem Dialog dann mehr oder weniger unbeabsichtigt einen rechten Mausklick auf einem Hierarchienamen (Achtung: nicht Dimensions- oder Ebenenname) machten, war sie da: die Option zur Definition einer „Default-Auswahl“ eines Berichts.

Abb. 2: Berichtseigenschaften – Sichtkontext – Default-Auswahl definieren …

Default-Auswahl definieren

Die Default-Auswahl eines Berichts ermöglicht es, ein beliebiges Element der betrachteten Dimension unter Verwendung eines beliebigen MDX-Ausdrucks als Startsicht des Berichts zu definieren. Hierbei erfolgt die Auswahl der Startsicht direkt in der Sicht der jeweiligen Dimension, weswegen diese nicht als Filter in der zugrunde liegenden Pivottabelle definiert werden muss. Somit ist auch das nachträgliche Ändern der Berichtssicht über den Dimensionsbrowser gewährleistet. Wir mussten also nichts weiter tun, als den Filter zur Abfrage der Periode aus der Pivottabelle zu entfernen und das im Filter enthaltene MDX-Statement in die Default-Auswahl des Berichts zu kopieren. Durch die Definition einer Default-Auswahl eines Berichts gelingt es also, dessen Aktualisierung nicht nur zu individualisieren und zu automatisieren, sondern gleichzeitig noch die Filterfunktion in der Dimensionssicht beizubehalten. Großartig!

NamedSets zur Default-Auswahl verwenden

Sollten Sie das oben beschriebene Prinzip zur Sichteinstellung für Ihre eigenen Berichte verwenden, so empfehlen wir zur Definition der Default-Auswahl die Verwendung von NamedSets anstelle von direkt hinterlegtem MDX. Dadurch wird bei späteren Änderungen von Startsichten der Wartungsaufwand dramatisch reduziert.