Generell gilt: Gut geschriebener Computer Code ergibt das richtige Ergebnis, ist schnell in der Ausführung und ist für eine „mit der Materie bekannten“ Person verständlich geschrieben. Dieses gilt natürlich auch für Essbase Calc Scripts. In diesem Beitrag möchte ich mich auf die Struktur von Essbase Calc Scripts fokussieren und einige Tipps geben. Also nicht, wann ein FIX oder ein IF besser wäre, sondern die Gestaltung besprechen.

Wie oben schon beschrieben, ist die Reihenfolge der Eigenschaften eines Scripts ist wie folgt:

1. Korrekt
2. Schnell
3. Verständlich

Kosten

Aber warum ist das so? Nun, kurz gesagt: Effizienz. Ein Calc Skript hat verschiedene Kostenaspekte: So gibt es Entwickelkosten um ein Skript zu entwerfen, schreiben und testen. Aber auch jedes mal wenn das Skript ausgeführt wird, gibt es Kosten in der Wartezeit und Rechenleistung. Ferner gibt es natürlich auch noch Unterhaltskosten.

Wenn eine Berechnung falsch ist, dann ist diese wertlos, das versteht jeder. Es muss also in erster Linie korrekt sein.

Wenn eine Berechnung sehr lange dauert, dann sprechen wir Entwickler oft von „teuer“. Warten und Rechenleistung kosten Geld. Es könnten Investitionen in kräftigere Hardware gemacht werden und jede Minute die Mitarbeiter warten, kostet Geld. Es muss also auch schnell sein.

Die Eigenschaft „verständlich“ hat Einfluss auf die Entwickel- und Unterhaltskosten. Auf dieser Welt gibt es viele Skripte, die niemand mehr versteht und darum nicht angefasst werden. Ein grosses Risiko und damit Problem. Mit besserer Struktur und Dokumentation wäre dieses nicht so schnell zu einem Problem geworden.

Design, Lesbarkeit und Stil

In Essbase und Planning stehen die Berechnungen nicht allein im Raum, denn sie haben immer bezug auf die Struktur der Dimensionen (Outline), wie und wo die Daten im Cube abgelegt sind (BSO, ASO, Hybrid) und auf ein gutes Verständnis des Problems, welches berechnet werden sollte.

So ist auch ein Buch dem Leser nur verständlich, wenn dieses strukturiert geschrieben und den Leser in das Thema mitnimmt und nicht wenn die Kapitel durcheinander geworfen sind. So ist es auch mit Computer Code.

Wenn die Skripte in einem einheitlichen Stil geschrieben sind, z.B. wie Variablen verwendet werden oder wie Funktionen dargestellt sind, wird sich immer schneller zurecht finden. Wieviel Zeit wird nicht verschwendet, um sich in dem Code zurecht zu finden?

Einen guten Editor

Es fängt oft an mit einem guten Editor, denn dieser hilft Übersicht und Struktur zu bewaren. Manchmal sind es auch persönlicher Geschmack und Arbeitsweise, aber vorallem Funktionalität zeichnet einen guten Editor aus. Ich möchte nicht tief einsteigen in was ein Editor haben muss – das alleine wäre schon ein langer Beitrag. Aber der Editor sollte mindstens eine Farbcodierung für Objekttypen haben und Einrücken unterstützen.

Es gibt auch andere Designaspekte die den Unterschied machen. Erstellt man die Anwendung mit Business Rules oder Calc Skripte? Meistens werden Calc Skripte mit MaxL eingesetzt um automatisierte Prozesse zu steuern und Business Rules, wo die Benutzer selbst die Berechnungen in der Anwendung starten.

Konkrete Tipps

Eine Organisation sollte seine Gestaltungsrichtlinien (Style Guide) oder zumindest einen Leitfaden haben. Dieses gilt natürlich für die Namenskonvention von Dateien, sollte sich aber auch auf den Stil innerhalb von Skripte beziehen. Diese sollten konsistent, deutlich, praktikabel und wiederverwendbar sein.

Einfache Beispiele:

• Verwenden von Member Namen und nicht Alias im Code. De Alias kann in dem Kommentar verwendet werden.
• Member Namen in Anführungszeichen.
• Namen von Funktionen und Calc Commands immer in Grossbuchstaben.
• Einrücken von Befehle.
• Extra leere Zeilen einfügen.
• Nicht breiter als 80 Zeichen.

Namenskonvention für Variabelen

Substitutionsvariablen können auf die Datenbank, Anwendung oder Serverweit gestellt werden. Je nach Anforderung können diese verwendet werden. Wenn diese auf verschiedene Ebenen eingesetzt werden, sollten diese im Namen gekennzeichnet werden.

Runtime Prompts und Runtime Substitution Variablen sollten auch logische Namen bekommen, um die Lesbarkeit zu verbessern.

Abbildung 1: Beispiele einer Namenskonvention für Skriptnamen

Housekeeping

Der obere Block in Calc Skripte wird of Housekeeping genannt. Hier sollte der Skriptname und in einem Satz stehen was in dem Skript berechnet wird.

Dann gibt es einen Teil wo die Anpassungen beschrieben sind. Datum, Name und eine Beschreibung was die Änderung war. Dieses ist sehr praktisch, wenn es Fragen oder Fehler gibt.

Abbildung 2: Beispiel von einem Housekeeping.

Der lezte Teil sind die Settings. Hier gibt es 2 Strategien: entweder immer setzen, denn dann weiss man welche Setting wie steht, oder nie setzen, aber dann strikte dezentral in der Essbase.cfg steuern und die Settings dort für die jeweilige Applikation/Datenbank einstellen.

Der Vorteil von dezentral einstellen ist, dass diese Settings dann entsprechend schnell auch wieder angepasst werden können. Der Nachteil, einige Settings gelten für alle Skripte, grosse oder kleine, wichtige oder weniger wichtige.

Wenn Business Rules verwendet werden, können auch Scripts verwendet werden wie in diesem Beitrag auch beschrieben. https://www.hyperionimklartext.de/business-rules-in-planning-und-essbase/ Hierin können die Settings an einer Stelle verwaltet werden.

FIX und IF

Bei den beiden Calc Kommando’s FIX und IF gibt es noch weitere Tipps. Beim FIX ist es ratsam, immer alle Dimensionen in einer festen Reihenfolge zu benennen. Auch wenn alle Elemente einer Dimension berechnet werden sollen, dann sollte dieses auch im FIX benannt werden mit z.B. einem @IDESCENDANTS.

Beim FIX gibt es die beiden Denkrichtungen – einen FIX pro Dimension oder alle notwendigen Dimensionen in einem FIX. Hier unten ist ein Beispiel dieser beiden Methoden dargestellt.

Oder ein FIX statement mit allen Dimensionen.

Bei verschiedene IF-Filter, sollte wo möglich, auch eine gleiche Reihenfolge eingehalten werden. Dieses fördert die Lesbarkeit in einem hohen Masse.

Kommentarfunktion

Als letztes kommt fast das wichtigste: die Kommentare. Es muss sicherlich nicht ein kunstvoll geschriebener Text zu sein, sondern eine kurze Darstellung in Pseudo Code über das was berechnet reicht oft schon aus. Wenn besondere Berechnungen oder Rechenweisen verwendet werden, dann sollte dieses näher beschrieben werden, denn nicht jeder hat viel Erfahrung mit Calc Scripte oder die Zeit sich in die letzte Feinheit einzuarbeiten.

Fazit

Die Binsenweisheit „Never touch a running system“ verhindert oft die Erneuerung einer Applikation. Dieses kommt oft, weil die Anwendung und die Business Logik nicht (mehr) verstanden wird. Um nicht auch in dieser Situation zu enden sollte gehandelt werden: eine Organisation sollte Gestaltungsrichtlinien (Style Guide) haben und die Entwickler sollten professionell diese Richtlinien anwenden.

Ihr Philip Hulsebosch