Working Paper Die Abhängigkeiten von Tabellen, Objekten und Berichten erkennen – mit DBOXS impact Abstract Wer SAP BusinessObjects (BO) als Reporting System im Einsatz hat, wird mit der Frage konfrontiert, welche Berichte bei einer Änderung des darunterliegenden DWHs oder eines BO Universums betroffen sind. BO stellt kein Tool zur Beantwortung dieser Frage bereit. Der vorliegenden Artikel erklärt, wie DBOXS impact diese Lücke für DeskI Berichte schliesst. An Hand von konkreten Anwendungsbeispielen zeigen wir, wie DBOXS impact zu einer besseren Übersicht über die Abhängigkeiten innerhalb des Reporting Systems führt. Diese Transparenz senkt den Entwicklungs- und Unterhaltsaufwand beträchtlich. Darüber hinaus erstellt DBOXS impact eine detaillierte Dokumentation, die z.B. beim Umstieg von DeskI auf WebI von grossem Nutzen ist. Working Paper DBOXS impact Wuchernde Universen Ein im Einsatz stehendes Reporting System verändert sich im Laufe der Zeit. Grund dafür sind neue Bedürfnisse der Benutzer, wie beispielsweise der Wunsch nach detaillierteren Berichten. Die benötigten Änderungen können das DWH oder die semantische Schicht zwischen dem DWH und den Berichten – das Universum – betreffen. In diesem Fall ist es wichtig zu wissen, welche Berichte von solchen Änderungen beeinflusst werden. BO liefert keine Standard-Lösung zur Beantwortung dieser Frage. Dies hat zur Folge, dass die Entwickler des Reporting Systems dazu neigen, eher neue Objekte und Filter in einem Universum anzulegen als vorhandene abzuändern. Dies führt zu einem beschleunigten Wachstum des Universums. Unter Zeitdruck kann ein solches Wachstum in ein „Wuchern“ umschlagen, wo mehr oder weniger unkontrolliert Objekte hinzugefügt werden, ohne das ursprüngliche Design-Konzept zu berücksichtigen. Beim dritten Schritt wird die Eindeutigkeit der Klassennamen des Universums ausgenutzt. Deshalb ist es wichtig, dass bei den ersten beiden Schritten auch die den Objekten und Filtern übergeordneten Klassen mit auf die Listen genommen werden. Voraussetzungen DBOXS impact (für DeskI) besteht aus einer einzelnen MS Excel Arbeitsmappe. Es ist in VBA programmiert und benutzt das DeskI COM SDK3. Daher muss einerseits das Ausführen von Excel Macros erlaubt und andererseits die BO Object Library (Version 12) verfügbar, bzw. die entsprechende VBA Referenz aktiviert sein. Letzteres setzt voraus, dass DeskI auf dem Rechner, der DBOXS impact ausführt, installiert ist. Zu wissen, welche Objekte und Filter von welchen Berichten verwendet werden, kann dazu beitragen, diese Design-Erosion1 zu verhindern. Mit Hilfe der BO SDK Bibliotheken ist es möglich, zu dieser Information zu kommen. Im Folgenden wird eine Lösung für DeskI Berichte2 beschrieben und D1 Solutions’ Implementierung dieser Lösung, DBOXS impact, vorgestellt. Funktionsweise der Zuweisung Die Zuweisung zwischen den Universumsobjekten und den Berichten erfolgt im Wesentlichen in drei Schritten: Abbildung 2: Von DBOXS impact erzeugte Pivot Tabelle. Analysiert wurden drei Berichte (Report_1.rep, Report_2.rep und Report_3.rep), die sich alle auf 1. Erstelle eine Liste aller Objekte und Filter des Universums. 2. Erstelle für jeden Bericht eine Liste der Objekte und Filter, die der jeweilige Bericht verwendet. 3. Identifiziere die Objekte und Filter aus den Listen der Berichte mit jenen aus der Liste des Universums. XLS DeskI Berichte Analyse SQL TXT Abbildung 1: Illustration der Funktionsweise von DBOXS impact. Links: die DeskI Berichte als Input; Mitte: die eigentliche Analyse; Rechts: die drei ver- das eFashion Universum beziehen. Funktionsweise Als Eingabe erwartet DBOXS impact eine Liste von Berichten. In Folge wird jeder Bericht aus dem BO Repository importiert und analysiert. Die Ergebnisse dieser Analyse werden in drei verschiedenen Output-Dateien4 geschrieben, wie in Abbildung 1 illustriert ist. Die drei Output-Dateien sind im Einzelnen: 1. XLS (Pivot-Tabelle). Für jeden Bericht wird eine Liste der verwendeten Objekte und Filter erstellt, welche dann mit der Liste aller Objekte des Universums abgeglichen wird. Das Ergebnis wird in eine Tabelle geschrieben und schliesslich in einer übersichtlichen Pivot-Tabelle dargestellt (Abbildung 2). Daraus lässt sich leicht ablesen, welche Objekte in welchen Berichten gebraucht werden und welche nicht (s. Fall 1 der Anwendungsbeispiele). schiedenen Output-Formate. 1 Schleichender Zerfall des ursprünglichen Designs, siehe z.B. van Gurp und Bosch, 2002. 2 Auch wenn hier lediglich DeskI Berichte als Beispiel herangezogen werden, erlaubt DBOXS impact auch die Analyse von WebI Berichten. 3 Für die Analyse von WebI Berichte wird das WebI Java SDK verwendet. 4 Zusätzlich wird noch eine Logdatei erstellt. Working Paper DBOXS impact 2. SQL (Abfragen). Die SQL-Abfragen jedes Data Providers werden gesondert in einer SQL-Datei gespeichert. Daraus wird z.B. ersichtlich, welche Datenbank-Tabellen benutzt werden (s. Fall 2 der Anwendungsbeispiele). 3. TXT (Infos). Alle relevanten Informationen über jeden Bericht werden gesammelt und jeweils in eine eigene Textdatei geschrieben. Dazu gehören: • • • • die verwendeten Objekte und Filter die Beschreibung der Data Provider die benutzerdefinierten Variablen und die zugehörigen Formeln Informationen zur Berichtsstruktur Diese Informationen bieten einen umfassenden Überblick über die Berichte und erlauben eine qualitative Abschätzung ihrer Komplexität. Anwendungsbeispiele Im Folgenden werden zwei typische Fragestellungen und ihre Lösung mit Hilfe von DBOXS impact beschrieben. 1Welche Universumsobjekte und -filter werden in welchen Berichten verwendet? Diese Frage taucht nicht nur bei jeder anstehenden Änderung eines Universums auf, sondern ist auch bei der Migration von Berichten auf ein neues, bzw. neustrukturiertes Universum von zentraler Bedeutung. Zur Beantwortung dieser Frage kann die Pivot-Tabelle (XLSOutput) herangezogen werden. Abbildung 2 zeigt eine Pivot-Tabelle für die Analyse von drei Test-Berichten, die alle auf dem eFashion Universum5 aufbauen. Die Berichte sind horizontal aufgetragen, während die Klassen- und Objektnamen auf der vertikalen Achse stehen. Mit dieser Pivot-Tabelle wird auf den ersten Blick klar, wie viele und welche ... ... ... ... 2Welche Berichte verwenden eine bestimmte Datenbanktabelle? Bei Änderungen auf Ebene des DWH ist es essentiell zu wissen, welche Berichte von einer bestimmten Tabelle abhängen. Diese Information kann aus den SQL Abfragen (SQL-Output) extrahiert werden. Angenommen wir wollen wissen, welcher der drei Test-Berichte die Tabelle Article_Color_Lookup verwendet. Die Frage lässt sich nun umformulieren zu: In welchen SQLOutput-Dateien kommt die Zeichenkette “Article_Color_Lookup“ vor? Unter Windows kann diese Frage mit dem CMDBefehl findstr beantwortet werden6: findstr /I /M /R “\<Article_Color_Lookup\>“ *.sql Mit diesem Befehl werden alle SQL-Dateien, die die besagte Zeichenkette beinhalten, aufgelistet. Da die Dateinamen der SQL-Dateien aus den Berichtsnamen sowie deren Pfade zusammengesetzt sind, wird sofort ersichtlich, welche Berichte auf die Tabelle “Article_Color_Lookup“ verweisen. In unserem Beispiel hier sind es Report_2.rep und Report_3. rep, die – wie wir im Fall 1 gesehen haben – beide das Objekt Color verwenden. Nutzen DBOXS impact findet heraus, welche Universumsobjekte und -filter von welchen Berichten genutzt werden. Es stellt eine Reihe nützlicher Information über jeden Bericht in einfach lesbarer Form bereit und vermittelt auf diese Weise eine Vorstellung der Komplexität jedes Berichtes. DBOXS impact hilft die Übersicht über das Reporting System zu bewahren und erleichtert so Modifikationen der Objekte und Filter der Universen. Es wirkt einem „Wuchern” der Universen entgegen und unterstützt die Planung der Migration von Berichten auf neue, bzw. neustrukturierte Universen. Nicht zuletzt ist DBOXS impact beim Umstieg von DeskI auf WebI von grossem Nutzen. Objekte von einem bestimmten Bericht verwendet werden, Berichte ein bestimmtes Objekt benutzen, Objekte von keinem Bericht verwendet werden. In unserem Beispiel (Abbildung 2) wird das Objekt Sales Revenue der Klasse Measures von allen drei Berichten benutzt; das Objekt Lines der Klasse Product hingegen nur von Bericht Nr. 2. Andererseits wird auch ersichtlich, dass der dritte Bericht neben Sales Revenue auch das Objekt Color der Klasse Product verwendet. 5Das eFashion Universum ist die „Spielwiese“, die mit jeder BO-Installation mitgeliefert wird. Es dient dazu, die wichtigsten Funktionen des Systems zu illustrieren. 6 Unter Unix-basierten Betriebssystemen kann grep verwendet werden. Working Paper DBOXS impact Fazit DBOXS impact legt BO-Entwicklern ein einfach zu bedienendes Werkzeug zur Analyse von Berichten an die Hand. Es erstellt von jedem Bericht eine detaillierte Dokumentation im Textformat und zeigt folgende Zusammenhänge auf: DWH Tabellen DWH Tabellenspalten Universumsobjekte Referenzen • DBOXS im Internet http://www.dboxs.info/ • D1 Solutions Working Paper, http://www.d1-solutions.com/papers/SAP-BO-SKDAdrian-Wyss-D1-Solutions-Zurich.pdf Berichte Berichte Berichte • Diese Information kann in verschiedenen Situationen eingesetzt werden, wie z.B. beim ... • ... Anpassen von Tabellen des DWH ... Anpassen der Objekte der semantischen Schicht (Universum) ... Erfassen der Ist-Situation bei Migrationen DBOXS impact hilft ein übersichtliches und schlankes Reporting System zu bewahren. Auf diese Weise werden Aufwand und Kosten für den Unterhalt sowie die Entwicklung der Reporting Plattform deutlich reduziert. SAP BO SDK Library http://www.sdn.sap.com/irj/boc/sdklibrary • • • SAP BusinessObjects: Software Development Kits DeskI Developer Guide http://help.sap.com/businessobject/product_guides/ boexir31/en/xi3-1_deski_sdk_dg_en.pdf • DeskI SDK Object Model Diagrams http://help.sap.com/businessobject/product_guides/ boexir31/en/deskisdk_com_omd_12.zip • DeskI API Reference http://help.sap.com/businessobject/product_guides/ boexir31/en/deskisdk_com_apiref_12_en.zip • VBA Corner der Firma LITS (VBA Einführung mit BO spezifischen Beispielen) http://www.filipleys.net/VBA/VBAmain.htm • van Gurp, J. und Bosch J., 2002, Design erosion: problems and causes, Journal of Systems and Software, 61, 2 Kontakt /Ansprechpartner Hans Peter Gränicher, Geschäftsführer [email protected], T +41 44 435 10 10 Die Autoren Dr. Marco Longhitano studierte Physik an der Universität Basel und promovierte 2010 im Bereich der Stellarstatistik. Seine Schwerpunkte sind Datenanalyse, Prozessoptimierung und Visualisierung von geschäftsrelevanten Informationen. Er begleitet Projekte im Finanzsektor und in der Energiebranche. Marco Longhitano gehört seit 2010 zum D1 Solutions Team. © D1 Solutions AG Zypressenstrasse 71, Postfach, 8040 Zürich, Switzerland www.d1-solutions.com, [email protected] T +41 44 435 10 10, F +41 44 435 10 15 Philipp Knüsel hat 1997 sein Studium als El. Ingenieur HTL am Technikum in Luzern abgeschlossen und 2010 mit einem NDS FH in Wirtschaftsinformatik von der Hochschule für Wirtschaft in Luzern ergänzt. Seine Themenschwerpunkte sind Datenqualität, DWH Design & Programmierung, SQL Optimierung, ETL-Prozesse und Reporting. Er begleitet Projekte im Finanzsektor, in der Energiewirtschaft, Telecom und in der Versicherungsbranche. Philipp Knüsel gehört seit 2007 zum D1 Solutions Team.