03.02.2015
Robert Galetzka
Autor: Robert Galetzka

Ver­gleich von ACL™ Skrip­ten mit SQL (Teil 1)

Der folgende zweiteilige Blogbeitrag stammt von unserem Praktikanten Robert, der sich im Rahmen seines Hochschulpraktikums (er studiert Wirtschaftsinformatik an der Technischen Hochschule Deggendorf) mit einem Vergleich von ACL™ Skriptsprache und SQL auseinandergesetzt hat. Da wir mit unserem Extraktionstool dab:Exporter seit der Version 3 auch SQL als Zielformat anbieten, wollten wir die Gemeinsamkeiten und Unterschiede herausarbeiten. Dies ist Teil 1, die Fortsetzung finden Sie nächste Woche hier an gleicher Stelle.

Die Analysesoftware ACL™ bietet eine eigene (und ziemlich mächtige) Programmier- bzw. Skriptsprache, mit der wiederverwendbare Analysen erstellt werden können. Viele Firmen setzen nicht nur ACL™ sondern auch andere Software für Datenanalysen in ihrem Unternehmen ein. Oft liegen die Daten dabei in Form von SQL Datenbanken vor. Diese können zwar auf einfache Art und Weise in ACL™ importiert und dort analysiert werden. Doch wie sähe es aus, wenn man komplexe Analysen, die in ACL™ ohne weiteres möglich sind, in SQL umsetzen müsste?

Mit genau diesem Thema beschäftige ich mich im Rahmen meines Praktikums bei der dab:GmbH. In diesem Blog Post berichte ich über meine Erfahrungen und gebe einen Einblick in die Herangehensweise, praktische Umsetzung und Unterschiede zwischen SQL und ACL™.

Für meinen Vergleich der ACL™ Skriptsprache und SQL Abfragen habe ich mir eine bereits vorhanden, in ACL™ vorliegende Lösung vorgenommen und begonnen, diese nach SQL zu portieren. Lassen Sie mich kurz die Ausgangslage erläutern:

I. Auf­ga­ben­stel­lung

Bei der dab:GmbH wurde mit dem Produkt „dab:AnalyticSuite“ ein umfangreiches Portfolio an Analysen für SAP® Daten entwickelt. Dieses beantwortet auf Knopfdruck (ad-hoc) betriebswirtschaftliche Fragestellungen mit Schwerpunktthemen aus beispielsweise Revision, Compliance oder Controlling. Die Analysen sind in ACL™ Skriptsprache programmiert und in ACL™ Analytics Desktop or ACL™ Analytics Exchange lauffähig.

Die Basis dafür bilden Informationen, die aus vielen verschiedenen SAP® Rohdaten zusammengestellt und kombiniert werden, und dann als fertig aufbereitete „AnalyticSuite“ in Form von ACL™ Tabellen vorliegen. Diese enthalten alle wesentlichen Informationen, die sofort für eine Vielzahl spannender Analysen verwendet werden können, ohne dass sich der Analyst oder Revisor noch mit der Datenaufbereitung auseinandersetzen muss.

Neben den vollständig aufbereiteten Basistabellen bieten die dab:AnalyticSuite noch das Feature, dass auf jedes Objekt eine Bibliothek von Analyseschritten angewendet werden kann. Aufsetzend auf die Basistabelle können als anschließend Prüffragen gestartet und durchgeführt werden. Dies ermöglicht das Beantworten von analytischen Fragestellungen auf Knopfdruck. Im Einkauf können dies Fragestellungen sein, wie „Rechnung vor Bestellung“, „Preisänderungen“, „Toleranzen“ usw. Mehr Informationen über die dab:AnalyticSuite finden sie hier, und weitere Beispiele für Fragestellungen im Katalog „Standardisierte Analysen für Ihre SAP® Daten“.

Folgende Grafik zeigt beispielhaft die vier Auditobjekte „Einkauf“, „Kreditorenbuchhaltung“, „Vertriebsaufträge“ und „Debitorenbuchhaltung“, und in der oberen Zeile Beispiele für darauf anwendbare Analysen:

Abbildung 1 – (Alte) Architektur der dab:AnalyticSuite

Als Grundlage für den SQL Prototyp in diesem Artikel wird das Auditobjekt „Einkauf“ (Bestellungen) herangezogen. Eine Teilaufgabe war, dass die hier geschilderte Datenaufbereitung, also alle vereinigten Informationen zu den SAP® Einkaufsbelegpositionen zu erstellen, nun auch per SQL erfolgen kann. Zweitens ging es darum, einige der darauf aufsetzenden Analyseschritte ebenfalls zu portieren, und so die Lösung „dab:AnalyticSuite“ für ACL™ prototypisch auch in SQL vorliegen zu haben.

Für meine Aufgabenstellung musste ich mich also in die bestehenden ACL™ Skripte einarbeiten und sie Schritt für Schritt in SQL Statements „übersetzen“. Dabei galt es folgende Bedingungen zu erfüllen:

  • Originaltreue Umsetzung: Möglichst alle Features der dab:AnalyticSuite sollten in SQL umgesetzt werden, ohne Funktionalitäten einzubüßen.
  • Erhaltung der Datenintegrität: Für Analysen im Allgemeinen, aber auch gerade im Bereich der Internen Revision ist die Datenintegrität und Zuverlässigkeit von Analysen eine wichtige Anforderung. Bei der Ausführung der dab:AnalyticSuite mussten die Ergebnisse inhaltlich (z.B. Datensatzzahlen, berechnete Werte, etc.) den in ACL™ realisierten Auswertungen entsprechen.

II. ACL™ vs. SQL - Die wich­tigs­ten Un­ter­schie­de im De­tail

Um das Ergebnis vorwegzunehmen ist es mir gelungen, beide Anforderungen zu erfüllen. Jedoch stellte sich heraus, dass eine 1:1 Umstellung der bestehenden ACL Skripte in SQL nicht immer möglich war. Die wichtigsten Unterschiede möchte ich hier kurz erklären.

  1. Arbeit mit mehreren Tabellen: ACL™ Relationen fehlen in SQL
  2. Trennung von technischen und beschreibenden Spaltentiteln in ACL™
  3. Pivot-Aspekte in SQL vs. ACL mit „Kreuztabelle“
  4. Flexiblere Parametrisierung mittels ACL™ Dialogen

Auf diese Erkenntnisse werde ich nun ausführlicher eingehen, bevor ich ein abschließendes Fazit ziehe.

1. Arbeit mit mehreren Tabellen: ACL™ Relationen fehlen in SQL

Für die Erstellung eines Audit Objekts müssen sehr viele SAP® Tabellen miteinander kombiniert werden, um die Basistabelle mit so vielen Informationen wie möglich anzureichern. Das bedeutet, es wird zu Beginn eine umfangreiche Datenaufbereitung durchgeführt.

Dazu kann man in ACL™ auf „Joins“, aber auch „Relationen“ zurückgreifen. Relationen sind dabei sehr praktisch, denn man kann bis zu 18 Tabellen auf einmal verknüpfen und auf alle Felder in derart verbundenen Tabellen zugreifen. Beim Verknüpfen werden dabei noch keine Daten verarbeitet, so dass die Vorbereitung der Datenaufbereitung schnell und unkompliziert von statten geht, ohne dass große temporäre Datenmengen erzeugt werden müssen.

SQL bietet diese Möglichkeit der „Relationen“ leider nicht. Aus diesem Grund bleibt dort nur der Weg über „Joins“, um die für das Auditobjekt relevanten Tabellen zu kombinieren. Damit beim Auditobjekt ein Datensatz nicht mehrmals vorkommt, muss jeder Join zu den Daten in den Tabellen eindeutig sein. Dazu werden Primär- und Fremdschlüsselfelder miteinander abgeglichen, um dies sicherzustellen.

Das klingt nun vielleicht nicht wie ein wesentlicher Unterschied, allerdings führte es beim Programmieren der Analysen zu wesentlich mehr und komplexeren Code, als beim ACL™ Äquivalent. Es machte meine Arbeit umfangreicher, und entsprechend im Falle von Anpassungen, Fehlersuche oder Erweiterungen zeitaufwändiger und unübersichtlicher als es in ACL™ der Fall gewesen wäre, auch für erfahrene SQL Programmierer.

2. Höhere Benutzerfreundlichkeit in ACL™ durch Trennung von technischen und beschreibenden Spaltentiteln

In SAP®, Tabellenspalten haben technische Namen, aber auch Spaltentitel. Zum Beispiel lauten der Titel für das Feld „Positionsnummer des Einkaufsbelegs“ oder, auf einem englischen System „Purchasing document line item“ und der technische Name in beiden Fällen „EBELP“. Der technische Name ist also weltweit immer derselbe, der Spaltentitel kann in verschiedenen Sprachen existieren. Das macht es sowohl technisch eindeutig, als auch gleichzeitig benutzerfreundlich, denn man kann sofort erkennen, was die Spalte bedeutet. ACL™ bietet ebenfalls dieses Konzept der Trennung zwischen technischem und beschreibendem Spaltentitel, und damit die genannten Vorteile. In ACL™ Skripten greift man immer auf den technischen Namen (also z.B.: EBELP) zu, denn dann ist man unabhängig vom der Sprache oder Version des SAP® Systems aus dem die Daten stammen.

Abbildung 2- Technische und beschreibende Spaltentitel in ACL™

Die Spaltenbezeichnungen im SQL sind jedoch unflexibler, hier kann nur eine Ausprägung angezeigt werden, man muss sich also zwischen „technischem Namen“ und „Spaltentitel“ entscheiden, als sprich zwischen technischer Eindeutigkeit und Benutzerfreundlichkeit. Ursprünglich waren dies in meinem Falle die technischen Feldnamen, mit dem vorangestellten Namen der Quelltabelle, denn für das Programmieren ist die Eindeutigkeit der Spaltenbezeichnungen essentiell. Folgende Tabelle zeigt die einige technischen Spaltennamen aus den Einkaufsbelegen::

Abbildung 3 - Technische Spaltentitel in SQL vor der Umbenennung

Eindeutig also, aber schwer zu interpretieren. Um trotzdem keine Informationen zu verlieren und die in SQL umgesetzten Audit Objekte benutzerfreundlich zu machen, musste ich in SQL technische und sprechende Bezeichnung in einer Zeile vereinigen. Final bedeutet dies, dass ich die technischen Namen durch die sprechenden Namen inklusive der technischen Bezeichnung in Klammern überschrieben habe , was wie folgt aussah:

Abbildung 4 – Spaltentitel in SQL nach der Umbenennung

Die Audit Objekt Basistabellen waren nun also benutzerfreundlich. Die notwendige (zur bessere Interpretation) Umbenennung hatte jedoch wie angedeutet einen entscheidenden Nachteil. Auch auf dem SQL Auditobjekt sollen ja die vordefinierten Analysen ausgeführt werden können. Dazu muss wieder auf Tabellenfelder zugegriffen werden, jedoch können dabei die technischen Namen nicht mehr direkt angesprochen werden auf Grund der Umbenennung. Da jedoch auch unterschiedliche Sprachen möglich müssen (etwa beim Zugriff auf SAP® Systeme in verschiedenen Ländern weltweit), können die gesamten „kombinierten“ Spaltenbezeichnungen nicht weiter verwendet werden, da in diesen Fällen nicht bekannt ist, wie welche Spaltenbezeichnung verwendet werden muss.

Aus diesem Grunde führte ich als nächsten Schritt eine erneute Umbenennung aus zum Zeitpunkt der Ausführung der Analysen, damit diese auf dem technischen Namen basieren konnten. Möchte man also einen Prüfschritt auf das Auditobjekt ausführen, werden zuerst dessen Spalten mit den technischen Namen versehen. Damit hat man wieder eine einheitliche Basis mit der jede Spalte angesprochen werden kann. Am Ende des Prüfschritts werden die technischen Namen wieder mit den sprechenden Namen ergänzt.

Wie man aus der Beschreibung ersehen kann waren also mehrere Schritte in SQL nötig, um die in ACL™ bereits vorhandene Funktionalität der technischen UND beschreibenden Spaltentitel nachzubilden. Zusammenfassend gesagt muss vor der Datenverarbeitung zu technischen Namen gewechselt werden, und für die Anzeige der Ergebnisse für den Benutzer zu den kombinierten Bezeichnungen aus Spaltentitel und sprechendem Titel. Technisch ist das in SQL über diesen Workaround möglich, aber bei weitem nicht so bequem, wie das in ACL™ ohne Umwege möglich ist.

Doch die Unterschiede bei den Spaltentiteln und den Joins bzw. Relationen waren nicht die einzigen Punkte, auf die ich bei meinem Vergleich zwischen ACL™ und SAP® reagieren musste. Auf zwei weitere wichtige Punkte werde ich im zweiten Teil meines Posts eingehen, nächste Woche an gleicher Stelle.

Für Fragen oder Kommentare können Sie sich gerne unter info@dab-gmbh.de an uns wenden.

Um den Autor zu kontaktieren, bieten sich auch LinkedIn oder XING an (möglicherweise müssen Sie sich erst einloggen in das entsprechende Social Network, bevor Sie die folgenden Links nutzen können):

LinkedIn: http://de.linkedin.com/pub/stefan-wenig/54/1b8/b30

XING: https://www.xing.com/profile/Stefan_Wenig2?sc_o=mxb_p


Kommentare (0)
Sei der erste, der diesen Blog-Beitrag kommentiert.
Blog Anmeldung

Sie sind nicht angemeldet. Bitte melden Sie sich an um diesen Blogbeitrag zu kommentieren.

anmelden