ASO Plantyp mit Smart View Essbase Verbindung verwenden

Obwohl die Smart View Essbase-Verbindung und Planning-Verbindung vieles gemeinsam haben, gibt es auch Unterschiede. Einer dieser Unterschiede ist, dass in der Planning-Verbindung keine Attribut Dimensionen verwendet werden können. Nun ist das nicht weiter ein Problem, denn es gibt ja die Essbase-Verbindung…. doch leider nicht für den ASO Plantyp (On-Premise).

Planning Cloud hat eine Option für Attribute Dimensions.

Abbildung 1: Planning Cloud hat eine Option für Attribute Dimensions.

Aber meine On-Premise Version kann keine Attribute Dimensionen verarbeiten.

Abbildung 2: Aber meine On-Premise Version kann keine Attribute Dimensionen verarbeiten.

Der Kontext

Weil die Planning Anwendung starkes Wachstum in dem gewünschten Datenvolumen zeigte, wollte ich die Alt-Daten in einen ASO Plantyp unterbringen. Ich verschiebe dann in diese die Alt-Jahre und Versionen und Szenarien, die nicht mehr so oft abgerufen werden. Dieses würde dann den BSO Planwürfel entlasten und wieder “fit” machen.

Die Planungsanwendung wurde also um einen ASO Plantyp erweitert und alles eingerichtet. Es mussten einige Anpassungen an den Dimensionen vorgenommen werden, um die ASO Spezifikationen zu erfüllen. Auch die Attribut Dimensionen wurden automatisch in dem Plantyp übernommen.

Nachdem ich die Anwendung dann zum ersten Test an einige Planer freigegeben hatte, bemerkten wir, dass wir keine Attribute in der Planning Verbindung verwenden konnten.

Als ich dann der Benutzergruppe den ASO cube im Shared Services zuweisen wollte, konnte ich diesen nicht finden. Der Grund: die ASO Anwendung war Teil von Planning und nicht Essbase. Wenn ich als Admin in Smart View angemeldet bin, sehe ich diese Anwendung und den Cube, ein Planer jedoch nicht.

Es gab keine Diskussion zu den folgenden Punkten:

  • Alle Planer bekommen die Rolle Essbase Admin.
  • Keiner der Planer verwendet Attribute Dimensions

Es musste also eine andere Lösung her.

Ein Patch mit zusätzlicher Funktionalität

Die Rettung war, das wir immer unsere Patches eingespielt hatten. In dem Release 11.1.2.4.007 Patch Set Update (PSU) URL: https://blogs.oracle.com/proactivesupportepm/psu_planning_11124008 gibt es eine neue Planning application property:

ENABLE_ASO_APP_FOR_PROVISIONING_IN_SHARED_SERVICES

…wenn noch jemand einen “seed” für seinen Bitcoin wallet sucht… hier sind schon einmal 8 von 12 Wörtern 😉

In der oben gelinkten readme stehen die folgenden Schritte:

  1. Einen Backup machen, wenn es schon eine ASO Anwendung gibt und noch kein Backup. Praktisch ist es, um die Daten zu exportieren und auch die Anwendungseinstellungen als Bildschirmabdruck zu speichern.
  2. Die Planning Anwendungseigenschaft ENABLE_ASO_APP_FOR_PROVISIONING_IN_SHARED_SERVICES Eintragen.
Die Properties von Planning.

Abbildung 3: Die Properties von Planning.

Der Eintrag wird auf true gesetzt.

Abbildung 4: Der Eintrag wird auf true gesetzt.

  • In EAS die Planning ASO Anwendung entfernen. Hierdurch wird die Registrierung in Shared Services auch entfernt.
Anwendung löschen kommt nicht oft vor.

Abbildung 5: Anwendung löschen kommt nicht oft vor.

  • Den Planning-Dienst wieder neu starten.
  • Die Planning Anwendung wieder neu aktualisieren. Hierdurch wird die ASO Anwendung wieder neu erstellt und als Essbase Anwendung in Shared Services registriert. Diese steht dann wahrscheinlich unter dem Namen EssbaseCluster-1.

Hier kam es dann zu einer Fehlerbotschaft. Der Grund ist, dass die Substitution Variablen auch entfernt wurden, und diese Formel eine verwendet.

Aktualisieren ergibt einen Fehler.

Abbildung 6: Aktualisieren ergibt einen Fehler.

  • Danach alle Objekte aus der ASO Anwendung zurück kopieren, ausser die Outline! Substitution Variablen setzen und den Wert kopieren.
alter application 'N-LIFE_R' add variable 'CurrMonth';
alter application 'N-LIFE_R' add variable 'CurrYear';
alter application 'N-LIFE_R' set variable CurrMonth Apr;
alter application 'N-LIFE_R' set variable CurrYear FY20;
  • Danach die Daten laden.
  • Benutzerrechte setzen. Hierzu schreibe ich etwas mehr im nächsten Absatz.

Benutzerrechte

Weil wir die ASO Planning Anwendung aus der Planning Anwendung teilweise herausgenommen haben, müssen wir die Benutzerrechte separat setzen. Die Tatsache, dass die Planer ja keinen Zugriff hatten, war die Grundlage der ganzen Operation.

Die Planning Benutzergruppen können jetzt der Planning ASO Cube unterhalbx des Essbase Servers berechtigt werden mit Rollen.

Setzen der Rechte für die Gruppe.

Abbildung 7: Setzen der Rechte für die Gruppe.

Mit dieser Berechtigung konnte ich dann schon eine Essbase-Verbindung in Smart View mit der ASO Anwendung ersstellen.

Die Planning-Verbindung.

Abbildung 8: Die Planning-Verbindung.

Und hier auch die Essbase Verbindung auf die ASO Anwendung.

Abbildung 9: Und hier auch die Essbase Verbindung auf die ASO Anwendung.

Die Berechtigungen werden nicht in de Anwendung übertragen. Diese müssen also regelmässig in einer Automatisierung übertragen werden. Hierzu können die folgenden MaxL Befehle helfen.

Mit diesem Befehl bekommt man eine Liste der Filter aus der Planungsanwendung.

display filter on database 'TNONLIFE'.'NONLIFE';

Mit diesem kann das Ergebnis in einen neuen Filter kopiert werden.

create or replace filter 'N-LIFE_R'.'ASO1' .'fNONL_Test' as 'TNONLIFE'.'NONLIFE' .'fNONL_Test';

Fazit

Weil der Kunde auf dem letzten Patchlevel von Planning war, konnte ich eine Funktionalität verwenden, um Planer mit einer Essbase Verbindung auf den ASO Plantyp zu berechtigen. Ohne dieses, wäre ein solches Anwendungsdesign nicht möglich gewesen.

Ihr Philip Hulsebosch 

Veröffentlicht unter Essbase Getagged mit: , , , ,