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.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.