Essbase Benutzer exportieren mit Groovy (Last Login)

Manchmal stößt man an Stellen auf Schwierigkeiten, an denen man sie nicht für möglich gehalten hat. Der Export von Gruppen und Benutzer-Informationen aus Essbase ist so ein Beispiel. Es war mir nicht möglich, mit Bordmitteln des EAS bzw. Shared-Services die vom Kunden angeforderten Informationen zu liefern.
Auf der Suche nach einer Lösung bin ich bei der Java API in Verbindung mit der Programmier- und Skriptsprache Groovy fündig geworden.

Groovy wird auf der Java Virtual Machine ausgeführt, dadurch ist es für viele Plattformen wie Windows, Linux und Mac OS X verfügbar. Java Archive werden nicht mehr benötigt, der Groovy-Code wird in Skriptdateien abgelegt und direkt ausgeführt. Die Skriptsprache bietet Fähigkeiten, die Java alleine nicht kann und ist zudem leicht les- und erlernbar.
Voraussetzung dafür ist die Installation von Groovy, der Java-Runtime und des Essbase-Clients inklusive API. Weitere Informationen folgen im Groovy-Exkurs weiter unten!

So, genug der Theorie und wieder zurück zu meinem Problem, Informationen zu Essbase-Nutzern in der gewünschten Form bereitstellen zu können.
Geht es um Essbase-Lizenzen in der Form von Named-User-Lizenzen, ist es sehr hilfreich, die exakte Anzahl der aktiven Essbase-Nutzer zu kennen. Wir alle wissen, dass nicht jeder Account, der in einem System angelegt wurde, auch tatsächlich verwendet (= benötigt) wird.

In der EAS-Konsole hilft uns in der Benutzerübersicht die Information in Spalte „Zeitpunkt der letzten Anmeldung“ (Last-Login). Benutzer, die sich schon lange nicht mehr angemeldet haben, benötigen möglicherweise keine Lizenz mehr. Diese Entscheidung muss natürlich jeder Kunde individuell für sich entscheiden.

Ich hatte genau diese Fragestellung zu beantworten:
Wieviele Essbase-Benutzer haben wir angelegt und wieviele davon sind aktiv? Als inaktive Nutzer gelten diejenigen, die sich seit über 12 Monaten nicht mehr angemeldet haben.

Ist doch ganz einfach, steht doch schließlich in dieser Liste:

Ja, aber das ist nur eine klitzekleine Demo-Installation. Was ist bei hunderten Benutzern? Ein Ausdruck ist auch nicht gerade hilfreich, die als „inaktiv“ erkannten Nutzer sollen den betreffenden Fachabteilungen als Excel-Liste zur Validierung übergeben werden. Und was ist mit einer Gruppierung der Nutzer je Applikation? Spätestens hier sind die Möglichkeiten der Konsole erschöpft.

Nächster Versuch ist Datei essbase.sec, sie enthält (nach dem Export) die benötigten Informationen.

Wie man sieht, muss das Format aufwändig bearbeitet werden, bei mehr als nur ein paar Benutzern ein mühsames Unterfangen.

Vielleicht sind die Shared-Services die Lösung? Sehen wir uns an, was sie uns bieten:

Sieht gut aus, es werden Benutzer oder Gruppen angezeigt, diese können je Rolle oder Anwendung gruppiert werden und das Ganze lässt sich noch im CSV-Format exportieren!

Kein Haken?

Doch, die Information, wann sich ein Benutzer zuletzt angemeldet hat, ist in Shared-Services nicht verfügbar.
Da hilft kein Bitten und kein Betteln, der Provision-Report bzw. Zugriffsberechtigungs-Bericht ist für unsere Zwecke nicht geeignet!

Zwischenstand:
Informationen aus Shared-Services oder dessen Repository reichen nicht aus, in Essbase sind die Informationen enthalten, aber für meine Zwecke unbrauchbar formatiert.

Es führt also kein Weg daran vorbei, in irgendeiner Art und Weise Essbase anzuzapfen. Nun kommt Groovy ins Spiel.

EXKURS Groovy
Dieser Beitrag ist keine Einführung in Groovy, er beschreibt die Lösung einer Essbase-Fragestellung. Deshalb beschränke ich mich auf die notwendigsten Erklärungen, um Groovy „zum Laufen zu bringen“. Das von mir erstellte und verwendete Skript emthält kurze Kommentare zu jedem einzelnen Schritt (Anmeldung, Definition der Ausgabedatei etc.). Es kann im Downloadbereich heruntergeladen werden.

Groovy wird installiert, wie andere Skript-Sprachen auch. Download von Codehaus Groovy Download, auch die Installation ist dort ausführlich beschrieben.

Danach kann die Groovy-Shell aufgerufen werden, ich habe damit nur getestet, ob die Installation erfolgreich war. Das Skript selbst habe ich mit der Groovy-Konsole erstellt, es ist sehr praktisch, den Code dort unmittelbar testen zu können.
Ende EXKURS Groovy

Inhaltlich gehe ich an dieser Stelle nicht weiter auf das Skript ein, sondern rufe es mit diesen Parametern auf:
groovy „Batch-Datei“ „Server“ „Benutzer“ „Passwort“ „Anzahl inaktiv-Monate“ „Ausgabedatei“ „APP“ „DB“

In meinem „mit Leben gefüllten“ Beispiel heißt das
groovy user.bat localhost admin passwort 4 E:\groovy_output\benutzer.txt

• Datei user.bat enthält das Groovy-Skript
• Der Essbase-Server lautet localhost
• Der Essbase-Benutzer ist admin (admin-Recht erforderlich) mit Passwort passwort
• Es sollen nur Benutzer ausgegeben werden, die sich in den letzten 3 Monaten angemeldet haben
• Die Ausgabedatei benutzer.txt wird in Verzeichnis E:\groovy_output\ gespeichert
• Optional: Filter für die Applikation (nur in Verbindung mit der Datenbank)
• Optional: Fiter für die Datenbank (nur in Verbindung mit der Applikation)

Ja, natürlich können Servername, Benutzer und Passwort auch in einer Parameterdatei abgelegt und von Groovy ausgelesen werden. Ich beschreibe hier die möglichst einfache Verwendung von Groovy.

Die Eigenschaften der Textdatei habe ich mit Spaltentrenner „Tab“ in 5 Spalten im Skript definiert:

USERID: Essbase Benutzer
Ref. Datum: Referenzdatum, mit dem verglichen wird. (heute – Monate aus dem Skriptaufruf)
LastLogin: Letzer Login des Benutzers
EssAPP: Applikation, wenn als Parameter übergeben, sonst alle Benutzer
EssDB: Datenbank, wenn als Parameter übergeben, sonst alle Benutzer

Die Anordnung der Spalten ist variabel, Spaltentrenner und Abfragezeitraum sind ebenfalls variabel. Es sind auch weitere Spalten mit z.B. der Uhrzeit möglich.

In diesem Beispiel frage ich serverweit alle Benutzer des Systems ab, durch Hinzufügen der Parameter für APP / DB beim Skript-Aufruf können spezifische Applikationen oder Datenbanken denkbar einfach gefiltert werden.

Es ist unerheblich, ob die Benutzer aus dem nativen Shared-Services-Directory oder einem externen Directory (MSAD, LDAP) abgefragt werden, dies wird innerhalb des Skriptes mit einem Groovy-Befehl parametrisiert.

Die Ausführung dauert nicht lange, dann ist die Ausgabedatei am erwarteten Ort erstellt.
Basierend auf den protokollierten Anmeldevorgängen enthält Datei benutzer.txt folgende Einträge:

Falls Sie hier in Spalte „Last Login“ das Datum „01.01.1970“ finden, hat sich dieser Benutzer noch nie am Essbase Server angemeldet.

Das Skript kann regelmäßig automatisiert gestartet und so ein Lizenz-Tracking realisiert werden. Der ein oder andere Software-Hersteller fordert so etwas im Rahmen regelmäßiger Audits 😉

Sinnvolle Erweiterung:
Es sind weitere Verarbeitungs-Schritte denkbar, um beispielsweise eine Benutzerliste, gruppiert nach Zugriffsrecht oder Applikation herzustellen.

Variante A ist eine Schleife für das Groovy-Skript, in der das Skript jeweils für eine Applikation ausgeführt wird und die Ausgaben konkatiniert werden.

Variante B ist die oben beschrieben Ausführung des Groovy-Skriptes für alle Benutzer des Servers. Zusätzlich wird in Shared-Services der Benutzerbericht mit der gewünschten Gruppierung (nach Zugriffsrecht oder Applikation) erzeugt und im CSV-Format exportiert.
Beide Dateien werden dann in Excel importiert und dort miteinander verbunden (Formeln SVERWEIS & Co). Es reicht ja, jedem Benutzer die Spalte mit dem letzten Anmeldedatum zuzuordnen.
Exemplarisch ist das hier dargestellt:

Hinweis:
Bei der Umsetzung und dem Test meines Skriptes hat mir die Tatsache, dass ein Benutzer trotz offensichtlicher Anmeldungen keinen Eintrag bei Last-Login erhielt, Kopfschmerzen bereitet. Dieses „Phänomen“ konnte ich sowohl auf meinem eigenen als auch auf anderen Systemen beobachten.

Ich konnte mir den Grund dafür einfach nicht erklären.

Dabei ist die Erklärung ganz einfach!

In einer 11.1.x.x.-Version (genauer habe ich es nicht geprüft) wurde das Verhalten des Essbase-Security-Files beim Refresh geändert. Seitdem ist ein zusätzlicher Parameter in Datei Essbase.cfg notwendig.

Ist Parameter PERSISTUSERATLOGIN enthalten und auf TRUE gesetzt, werden zuverlässig alle Zugriffe aller Benutzer protokolliert.
Rückwirkend lassen sich fehlende Login-Informationen nicht mehr erzeugen, es empfiehlt sich deshalb, PERSISTUSERATLOGIN schnellstmöglich zu setzen.

FAZIT:
Groovy hat mir in desem Fall mit seiner Funktionalität eine Lösung ermöglicht, die ich sonst nicht hätte liefern können. Und, einmal ein wenig in das Thema eingetaucht, gibt es weitere, interessante Einsatzgebiete, über die ich in Zukunft bestimmt berichten werde.

nach oben