Details

Geschrieben von Steffen Thorn

Kategorie: ORACLE BI EE Praxis

Veröffentlicht: 11. Juli 2018

Zugriffe: 307

In ORACLE BI EE gibt es zwei sehr nützliche Zeitreihen-Funktionen (AGO & ToDate), um z.B. den aufgelaufenden Umsatz (Year to Date YTD) vom 01.01. bis 01.03. mit dem Umsatz im gleichen Zeitraum vom Vorjahr zu vergleichen.

Bei einem Vergleich in dem ein Schaltjahr enthalten ist, führt dies jedoch zu einem Versatz von einem Tag.

Beispiel:

Ich habe in 2012 einen YTD Umsatz von 60T€ zum 01.02. und 70T€ zum 02.03.

Ich habe in 2012 einen YTD Umsatz von 90T€ zum 29.02. und 100T€ zum 01.03.

Ich habe in 2013 einen YTD Umsatz von 80T€ zum 28.02. und 110T€ zum 01.03.

Bericht 1

Auswertungsdatum 01.03.2013

YTD 2013: 110T€

YTD 2012: 90T€

Bericht 2

Auswertungsdatum 01.03.2012

YTD 2012: 100T€

YTD 2011: 70T€

Lege ich die Berichte nebeneinander erhalte ich für den gleichen Auswertungszeitraum zwei unterschiedliche YTD Umsatz Werte für 2012.

Wie ermittelt ORACLE BI EE die Werte?

Bei der YTD Ermittlung nummeriert ORACLE die Tage bis zum angegebenen Datum von 1 bis 365 bzw. 366 durch und merkt sich die Tagesnummer. Bei der Funktion AGO geht dann ORACLE ein Jahr zurück bis zur ermittelten Tagesnummer. Dies führt bei einem Schaltjahr in Verbindung mit einem Vorjahresvergleich zur zur Abweichung von einem Tag.

Lösung

Um das Problem zu lösen, muss die Zeitdimension geändert werden. Jedes Jahr hat nun 366 Tage, dass bedeutet für nicht Schaltjahre wird ein DUMMY-Datensatz eingeführt!

In der Zeittabelle DT_TIMES gibt es die Spalten

DT_DATE vom Typ DATE,

DT_ID vom Typ NUMBER als Primäschlüssel

DT_NOT_USED vom Typ VARCHAR2(1)

Für ein nicht Schaltjahr wird nun der 28.02. doppelt angelegt, dabei erhält der Primärschllüssel  20NN0229 (NN-Jahr) und die Spalte DT_NOT_USED den Wert = Y. Die Spalte DT_NOT_USED markiert diesen Datensatz als DUMMY-Datensatz, dies ist notwendig für den ETL-Prozess und für die Filterung im BI z.B. bei den Dashboards-Prompts.

Einstellungen im DWH

Beim ETL-Prozess in einem Data Warehouse wird in der Regel der Primärschlüssel der Dimension in die Faktentabelle geschrieben. Da der 28.02. bei nicht Schaltjahren doppelt vorkommt, muss bei der Ermittlung des Dimension-Keys die Spalte DT_NOT_USED = 'N' mit geprüft werden. Es wird verhindert, dass die Fakten des 28.02. nicht auf zwei Datensätze verteilt werden!

Einstellungen im BI

Im BI Metamodell muss die Spalte DT_NOT_USED (Bez.: ungültiges Datum) in der Präsentationsschicht mit aufgenommen werden. Bei der Zeitdimension sollte der Primärschlüssel der untersten Ebene (Tagesebene) auf die ID umgestellt werden.

Damit das DUMMY- Datum bei den Berichten & Prompts nicht erscheint, macht es Sinn einen Filter in die Berichte bzw. Prompts mit aufzunehmen.

Einen Filter anlegen und in die Berichte zu referenzieren vereinfacht die Arbeit.

Hinweis

Da im DWH die Fakten-Daten immer nur die gültige ID des 28.02. zugewiesen bekommen haben, kann es nicht zu doppelten Daten kommen.

Details

Geschrieben von Steffen Thorn

Kategorie: ORACLE BI EE Praxis

Veröffentlicht: 11. Juli 2018

Zugriffe: 146

In dem Themenbereich ORACLE BI EE Praxis stelle ich einige Praxis-Tipps bei der Konfiguration von ORACLE BI EE vor. Für die Korrektheit der Inhalte übernehme ich keine Haftung, daher bitte immer vorher sicherstellen, dass ein aktuelles Backup existiert.

Details

Geschrieben von Steffen Thorn

Kategorie: ORACLE BI EE Praxis

Veröffentlicht: 11. Juli 2018

Zugriffe: 112

In ORACLE BI EE erlaubt es in einem Dashboard Javascript mit einzubinden. Dies ermöglicht viele zusätzliche Funktionalitäten.

Button - Dashboard öffnen

Eine nützliche Funktion ist es einen Button hinzuzufügen, der einen anderes Dashboard aufruft.

Um dies zu erreichen wird ein neuer Abschnitt in das Dashboard gelegt. Dies hat den Vorteil, dass es möglich ist Berechtigungen auf den Abschnitt zu legen.

In den Abschnitt wird das Dashboard-Text-Objekt gezogen.

In den Text-Eigenschaften wird HTML-Markup markiert und der Javascript-Code eingetragen.

Beispiel:

öffnet das Dashboard "Geschäftsleitung".

<input type="button" onclick="location.href='http://BI-Server:7001/analytics/saw.dll?dashboard&amp;PortalPath=%2Fshared%2FDashboard%2F_portal%2FGesch%C3%A4ftsleitung'" " value="Geschäftsleitung">

Button - Berichte refreshen

Ein weiteres Beispiel ist der Refresh von Berichten.

Um dies zu erreichen wird ein neuer Abschnitt in das Dashboard gelegt. Dies hat den Vorteil, dass es möglich ist Berechtigungen auf den Abschnitt zu legen.

In den Abschnitt wird das Dashboard-Text-Objekt gezogen.

In den Text-Eigenschaften wird HTML-Markup markiert und der Javascript-Code eingetragen.

Beispiel:

führt einen Refresh für rep1 und rep2 durch.

 <script type="text/javascript">
function refreshReport(idResultsDiv){
                var refreshObj, indexOfId;
                refreshObj = document.getElementById(idResultsDiv);
                if(!refreshObj) return;  
                while ( !refreshObj.parentNode.getAttribute('vid'))       
                               refreshObj = refreshObj.parentNode;
                refreshID=refreshObj.parentNode.getAttribute('vid');
                indexOfId=refreshID.indexOf('~v:');
                if (indexOfId>-1) refreshID = refreshID.substring(0,indexOfId);
                refFunction = "HereLink('" + refreshID + "','Refresh')";
                eval(refFunction);
}
</script>

Damit der Bericht darauf reagiert, muss dem Bericht noch ein statischer Text hinzugefügt werden. Der Bericht wird im Bearbeitungsmodus in Answer geöffnet und die Ansicht statischer Text hinzugefügt.

Der statische Text enthält dann folgenden Eintrag und HTML-Markup muss markiert sein:

Der statische Text wird dem zusammengesetzten Layout hinzugefügt und im Dashboard unter Ansicht zusamengestztes Layout eingebunden.

Details

Geschrieben von Steffen Thorn

Kategorie: ORACLE BI EE Praxis

Veröffentlicht: 11. Juli 2018

Zugriffe: 127

Dieser Beitrag stellt einige wichtige Hinweise für eine Neuinstallation, das Patchen oder den Releasewechsel zur Verfügung.

Für weitere Details gibt es die ORACLE Dokumentation oder einige gute Blogs im Internet.

Neuinstallation

ORACLE Repository Creation Utility (RCU)

Vor der ORACLE BI EE Installtion muss das ORACLE BI Metadaten-Repository über den RCU Installer auf einer Datenbank installiert werden. 
Wird das Repository in eine ORACLE DB mit 8K Blöcken installiert, so kann das RCU zwei Indizes nicht anlegen.
Dies kann man bedenkenlos im Assistent igonorieren oder im SQL-Skript auskommentieren. Eine Installation auf einer ORACLE DB mit 16K 
Blöcken funktioniert ohne Fehler.

ORACLE BI Setup

Die Installation der ORACLE BI EE Suite ist eine relativ einfache Angelegenheit. 
Nach dem Aufruf der Setup Datei leitet ein Assistent durch die Installation.

Bei der Auswahl der Komponenten (z.B. Real-Time Decision), Lizenzen beachten!

Eine wichtige Entscheidung die bei der Installation getroffen werden muss ist, ob man sich für eine Einfache Installation (Simple Install) oder 
eine Enterprise(Enterprise Install) entscheidet.

Enterprise(Enterprise Install)
Sieht die Planung ein für die Zukunft skaliebares ORACLE BI EE Landschaft vor, empfiehlt sich die Enterprise Installation. Bei der Enterprise Installation wird im Weblogic-Server für die Anwendung ein 
eigener Managed Server angelegt. In Weblogic gibt es dann den Administration Server (der ja auch wie ein Managed Server behandet wird) und für die ORACLE BI EE Domäne einen Managed Server. Der Vorteil ist, 
dass es leichter möglich ist die ORACLE BI Domäne zu Clustern. Ein zweiter Vorteil liegt beim Versions-Upgrade. ORACLE liefert nur für die Enterise Installation eine Upgrade Dokumentation.

Einfache Installation (Simple Install)
Die einfache Installation sollte für single Server mit wenig Ressourcen verwendet werden, z.B. zur Demonstration (PC's und Notebooks) oder für die Entwicklung. In Weblogic wird die ORACLE BI Domäne in den Administrations Server installiert.
Das hat für die Funktionalität und Stabilität keinen Nachteil. Beim Versions-Upgrade ist es am einfachsten eine Neu-Installation durchzuführen und den Katalog, Messages (Mehrsprachigkeit), das Repository in die neue 
Installation zu kopieren, die Konfigurationseinträge (z.B. NQSConfig.ini und instanceconfig.xml) manuell nachtragen und ggf. das Custom Layout neu zu deployen. Das hört sich sehr aufwendig an, dauert bei 
guter Dokumention genauso lange wie der Upgrade bei einer Enterprise Installation und man hat erstmal ein sauberes System.

Patch (11.1.1.7 -> 11.1.1.7.131017)

Ein Patch beinhaltet Fehlerkorrekturen, kleinere Verbesserungen und Funktionalitäten.

Das einspielen eines Patchset ist doch relativ unkompliziert. In der mitgelieferten Readme Datei steht detailiert drin wie das Patch eingespielt werden muss.

Da ein Patchset in der Regel auf mehreren Patches besteht, empfielt sich zur Vereinfachung folgendes Vorgehen:

1) Patch Install Verzeichnis anlegen, z.B. C:\Install_Files_OBI\OBIEE_11.1.1.7\PATCH\17530796 für Patchset 17530796

2) Umgebungsvariablen setzen, das ORACLE_HOME ist individuell zu setzen

set PATCH_FOLDER=C:\Install_Files_OBI\OBIEE_11.1.1.7\PATCH\17530796
set ORACLE_HOME=D:\oracle\middleware\Oracle_BI1
set JAVA_HOME=%ORACLE_HOME%\jdk
set PATH=%ORACLE_HOME%\OPatch;%JAVA_HOME%\bin;%ORACLE_HOME\bin%;%PATH%

3) mit OPATCH alle PAtches auf einmal einspielen

opatch napply -silent %PATCH_FOLDER% -id 16913445,17463314,17300417,17463395,17463376,17300045,16997936,17463403

4) mit OPATCH lsinventory die korrekte Installation prüfen

5) entsprechend der Redme Datei die manuellen Post-Installation Schritte durchführen

Releasewechsel (11.1.1.6 -> 11.1.1.7)

Ein neues Release beinhaltet Fehlerkorrekturen und viele neuen Features. Das Einspielen eines neuen Release lohnt sich in der Regel, stellt aber auch eine größere Herausforderung da.

Es gibt zwei Möglichkeiten für eine Enterprise Installation einen Release-Wechsel durchzuführen

1) komplette Neu-Installation (für eine Simple Installation zwingend erforderlich)

Vorgehen:

1) Dienste alle runterfahren

2) altes Middleware Verzeichnis umbenennen, z.B. middelware_save

3) Deinstallation

4) Neuinstallation

5) Katalog, Repository aus dem Sicherungsverzeichnis zurückkopieren

6) Konfigurationsdateien basierend auf den Ursprünglichen Konfig-Dateien manuell anpassen (nicht kopieren)

7) Deployments neu durchführen

2) Upgrade bzw. Migration

Vorgehen:

siehe Dokumentation ORACLE

Vom zeitlichen Aufwand liegen beide auf gleicher Höhe, allerdings kommt es schon darauf an wieviel manuelle Änderungen und Deployments gibt es und sind diese gut dokumentiert.

Für eine im Cluster betriebene Installation ist die Migration der beste Weg, für eine single Node Installation muss man abwägen und für eine Simple Installation ist eine Neu-Installation ein muß.

Wichtig: Es sollte immer sichergestellt werden, dass eine Backup und ein Fallback-Plan existiert.