In diesem Beitrag werde ich auf die neuen Features des ACL™ Analytics 10 Script Editors eingehen. Für das Testen und die Screenshots hatte ich die englische Version 10.5.0.172 im Einsatz. Ich werde nicht im Detail auf die Skriptsprache von ACL™ an sich eingehen. Es sei nur kurz betont, dass diese meiner Meinung nach wirklich hilfreich ist. Obwohl es sich „nur“ um eine Skriptsprache handelt und schnell einfache, leicht zu lesende Programme damit erstellt werden können, kann man auch komplexe Fragestellungen damit umsetzen. Im Laufe der Jahre haben wir hunderte von Analysen und Prüfschritte für SAP© Daten damit erstellt, und waren sehr erfolgreich, gerade bei der Auswertung großer Datenmengen (Big data). Einer der Wermutstropfen der Vergangenheit war jedoch in diesem Zusammenhang der etwas altbackene Skripteditor: Weder war dieser sonderlich bedienfreundlich, ganz zu schweigen von fehlender Code-Hervorhebung mittels Farben oder umfangreicher Funktionalitäten. Dies hat sich nun zum Glück geändert. ACL™ Analytics bietet nun Color Coding, Zeilennummerierung und nicht zuletzt die Möglichkeit, mittels Haltepunkten (Break Points) oder via Einzelschritt Skripte zu debuggen.

Ich habe hier einige Screenshots inklusive erläuternden Text zusammengestellt, um Ihnen einen Eindruck davon zu vermitteln. Am Ende des Beitrags ziehe ich dann noch ein kurzes Fazit aus meiner Sicht. Beginnen wir mit dem Skript, das ich zum Testen verwendet habe:

Ich habe betriebswirtschaftliche Fragestellungen außen vor gelassen und mich nur auf die technischen Aspekte beschränkt. Einziger Zweck des Skriptes ist es, die neuen Features, insbesondere die Haltepunkte, zu zeigen. Am Anfang des Skriptes werden zwei Variablen initiiert, eine mit einem numerischen Wert, die zweite mit Datentyp „Text“. Anschließend wird eine Tabelle geöffnet und das STATISTICS-Kommando ausgeführt. Einer der so erzeugten Ergebniswerte (hier ist es die Gesamtzahl der Datensätze) wird der numerischen Variablen zugewiesen. Später verwende ich noch den GROUP Befehl, innerhalb diesen GROUPs wird der Belegtyp einer Variable zugwiesen. Wir starten also das Skript, das sich in unserem ACL™ Projekt befindet. Dies können wir tun, indem wir auf das grüne „Run“ Icon über dem Script klicken:

Wie Ihnen vielleicht schon im ersten Screenshot aufgefallen ist, habe ich – natürlich nur zu Demozwecken ;-) – einen Tippfehler eingebaut im ersten OPEN Befehl. Er lautet fälschlicherweise „OPNE“. Wie erwartet, stoppt ACL an dieser Stelle mit einer Fehlermeldung:

Was im neuen Skripteditor auffällt ist, dass wir sofort sehen, wo der Fehler passiert ist: Wir erhalten einen kleinen roten Pfeil, der uns zeigt, an welcher Stelle das Skript auf Grund eines Problems abgebrochen ist.

Das ist bereits einer der ersten Vorteile. Die umfangreichsten unserer Skripte (dab:FastForwards) bestehen aus zehntausenden Zeilen Codezeilen. Da ist es natürlich sehr nützlich, im Falle eines Abbruches sofort die entsprechende Stelle zu identifizieren. Nachdem ich nun unser Beispielskript entsprechend korrigiert habe, habe ich es erneut ausgeführt und es lief ohne Probleme durch. Was Ihnen vielleicht auch aufgefallen ist, ist der zusätzliche Reiter links unten, der mit “Variables” bezeichnet ist. Der Projektnavigator wurde also erweitert um die Information, welche Variablen gerade aktiv sind und welche Werte ihnen zugewiesen sind.

Nach dem Skriptlauf hat die Variable “v_MyNum_Variable” den Wert “772”; v_MyTxt_Variable beinhaltet den Text “CN”. Dies werde ich als Ausgangspunkt nutzen, um den Debugger zu testen. Dafür habe ich alle Variablen gelöscht, um es besser nachvollziehen zu können. Zuerst verwende ich den Debugger, um Schritt für Schritt das Skript durchgehen zu können. Ein kleiner grüner Pfeil neben dem Code zeigt uns die aktuelle Stelle, an der sich das Skript während der Ausführung gerade befindet; genauer gesagt, welche Codezeile als nächstes ausgeführt werden wird.

Um das schrittweise Debuggen zu starten, klickt man auf “Step”. Mit jedem Klick bewegt sich der Debugger um eine Zeile weiter. Nach Passieren der Zeile “v_MyNum_Variable = DEC (0,0) erscheint die Variable in der Liste auf der linken Seite; ihr Wert wird mit dem Initialwert 0 angegeben.

Der STATISTICS Befehl hat eine ganze Reihe von Variablen erstellt, die alle links angezeigt werden. v_MyNum_Variable hat immer noch den Wert 0, aber nach Abarbeiten der Zeile “v_MyNum_Variable = COUNT1” wird der korrekte Wert 772 zugewiesen.

Nun drücke ich weiter auf “Step”, um auch den GROUP Befehl zu debuggen. Jedoch stoppt ACL™ hier nicht, sondern sobald man die GROUP-Stelle passiert hat, läuft das Skript komplett durch, ohne dass ich die Möglichkeit hatte, bei der Zeile „v_MyTxt_Variable = TYPE“ zu halten.

Aus diesem Grund versuchen wir einen zweiten Ansatz: Statt Schritt für Schritt mittels des „STEP“ Icons uns durch das Skript zu arbeiten, können wir durch einen Klick mit der linken Maustaste einen Haltpunkt (Break Point) dort setzen, wo das Skript während der Ausführung pausieren soll. Das macht natürlich Sinn, denn bei einem umfangreichen Skript will man nicht 10.000 Mal auf „STEP“ klicken, sondern an einer dezidierten Stelle halten. Ein dicker roter Punkt zeigt an, an welcher Stelle der Haltepunkt gesetzt ist (bzw. wo die Haltepunkte gesetzt sind, denn man kann auch mehrere Haltepunkte innerhalb eines Skriptes setzen).

Ich beginne, indem ich einen Haltepunkt in die Zeile vor den GROUP Befehl setze:

Man sieht den oben angesprochenen roten Punkt. Wenn man nun das Skript ausführt, pausiert es an genau dieser Stelle. Ein grüner Pfeil erscheint und man kann auf der linken Seite alle bis dahin erstellten Variablen einsehen inklusive der ihnen zugewiesenen Werte.

Als nächstes möchte ich versuchen, innerhalb des GROUPs zu debuggen, indem ich einen Haltepunkt bei der Zeile “v_MyTxt_Variable = TYPE” setze.

Wenn ich jedoch das Skript weiter ausführe indem ich auf “RUN” drücke, läuft es durch, ohne anzuhalten.

Das Debuggen eines ACL™ Skriptes funktioniert also mittels den Haltepunkten, aber (ebenso wie das schrittweise Debuggen) nicht innerhalb eines GROUP Befehls. Als Randnotiz hatte ich noch versucht, während des Debuggens die Kommandozeile zu benutzen. Dies führte zu folgender Meldung: