BI Publisher a ověřování oproti MS AD

V dokumentaci BI Publisheru můžete najít kapitolu popisující jeho připojení k Oracle Internet Directory (OID) jako LDAP serveru. V mnoha případech se ale setkávám s tím, že zákazník jako LDAP Server používá MS AD. Potřebujete-li propojit BIP s MS AD, pak postup je podobný jako u OID:

1. V MS AD založte systémové role BI Publisheru (role s prefixem XMLP_)


2. V BI Publisheru na záložce Konfigurace kontroly přístupu aktivujte lokálního superuživatele


3. Na stejné záložce (Konfigurace kontroly přístupu) změňte Model kontroly přístupu na LDAP a nastavte parametry pro MS AD viz. screenshot (ip adresu a hodnoty pro CN= a DC= zadejte dle svého prostředí):


Výsledkem je ověřování uživatelů oproti MS AD a přidělování práv na BIP složky přes skupiny definované v MS AD.




Erik Eckhardt

Výběr Top N hodnot s dynamickým zadáním hodnoty N

Výběr N hodnot, které splňují nějaké Top kriterium, je pro Oracle BI velmi triviální úlohou. Řešíme ji obvykle zadáním fitru nad sloupcem, který slouží jako kriterium pro Top výběr. Filtr zadáme takto:


Omezením tohoto řešení je skutečnost, že budoucí uživatel takto vytvořeného pohledu na data nutně uvidí právě 20 Top hodnot. Můžeme do filtru zadat i jiné číslo, ale setkal jsem se ovšem s případem, že zákazník chtěl počet řádků vě výběru – tedy hodnotu N – určovat sám – tedy dynamicky.

Řešením, které mně napadlo, je použití proměnné prezentace.


Jak si proměnnou prezentace zadefinujeme a naplníme, se pokusím popsat na následujícím příkladu, kdy jsem k tomu použil Dashboard Prompt (omezený na stránku).

Ukázkový standardní business model znázorňuje obvyklé vazby mezi faktovou tabulkou a dimenzemi.

Protože budeme potřebovat nějaký logický sloupec pro zadání hodnoty „N“, doplnil jsem do logické tabulky Facts logický sloupec N a vložil do něj hodnotu 1.


Tím se zajistila hodnota Data Type implicitně jako Int. Sloupec N jsem přidal do prezentační vrstvy.


Logický sloupec N nyní lze použít v dashboard promptu. Ověříme si konzistenci a repository uložíme.
Přihlásíme se do Answers a vytvoříme Dasboard prompt. Jeho význam omezíme na Page:


Do promptu přidáme sloupec N.


Vhodně zvolíme hodnotu sloupců Operator, Control, Default to (zvolil jsem Specific Value =1), Set Variable (variable jsem pojmenoval X01) a do kolonky Label napíšeme text: Select value of N in TopN. Default value is 1.

Prompt graficky dotvoříme:

Uložíme jej jako např. Page_prompt1.

Ještě připravíme vhodný dotaz. Nesmíme v něm zapomenout na sloupec Rank(Facts.Units), který udává pořadí řádku ve výběru a bude slouži jako filtr, protože uživatel si bude zadávat právě hodnotu počtu řádků. Nejvyšší pořadí pak bude vlastně udávat počet vrácených řádků.


Filtrovací podmínka pro sloupec Rank(Facts.Units) byla vytvořena takto:


Defaultní hodnota 1 slouží k tomu, aby se v případě, že není zadána žádná hodnota proměnné X01, zobrazil právě jediný řádek.
Dotaz uložíme jako Select01 a spolu s promptem umístíme na dashboard.


Výsledek by měl být následující:
1)Nezadáme-li do promptu žádnou hodnotu, implicitně se do filtru nastaví hodnota 1 a vybere se jediný řádek.


2) Naopak, zadáme-li např. hodnotu 17, pak se do proměnné prezentace (Presentation Variable) pojmenované X01 nastaví hodnota 17 a vybere se 17 řádků .


Takto si uživatel může výbírat libovolný počet Top N řádků.

Jiří Doubravský (PIKE ELECTRONIC)

Pořadí položek dimenze v sestavě při drillování

Při použití hierarchické dimenze se v sestavě při kliknutí na drill down hyperlink provede zobrazení položek – sloupců, které jsou pro danou úroveň nastaveny. Pokud je na jedné úrovni více položek s informacemi, které chceme v sestavě zobrazit, nedá se jednoduše ovlivnit pořadí zobrazení položek.


Původní pořadí sloupců v sestavě po kliknutí na drill down hyperlink:



Pro požadované pořadí zobrazení položek je nutné již při vytváření Logické vrstvy (dimenzní tabulky) přenést tyto položky z Fyzické vrstvy přesně v opačném pořadí, než je pořadí, jak je chceme v sestavě. Je tím ovlivněno přiřazení ID těmto položkám v repozitory. Podle těchto ID se pak provádí interní vyhodnocení zobrazení pořadí.

Požadované pořadí sloupců v sestavě po kliknutí na drill down hyperlink:



ID v repozitory pro zmíněné položky v původním pořadí:


ID v repozitory pro zmíněné položky v požadovaném pořadí:

Petr Jurászek, Věra Hubačová (IT Systems)

Oracle Data Integrator a Oracle Warehouse Builder

Na OTN jsou k dispozici nové dokumenty popisující roadmapu Oracle Data Integratoru a Oracle Warehouse Builderu, využívání ODI KM v OWB a co vše je nového v OWB11gR2. Linky na dokumenty najdete zde:

• Statement of Direction ODI a OWB
• OWB 11gR2 používání ODI Knowledge Modules
• OWB 11gR2 New Features

eec.

Jak na porovnání dvou verzí plánů v Oracle BI

Článek ukazuje, jak lze poměrně „jednoduše“ zajistit porovnání záznamů v tabulce faktů a zobrazit rozdíly mezi nimi.

Datový model (zjednodušeně):
Tabulka faktů: sloupce leden, unor, … prosinec, na úrovni business modelu dodělány součty po kvartálech ( Q1 až Q4) a celkový součet.

Dimenze: Verze plánu

Plán se vytváří na rok, jednotlivé verze ho zpřesňují na základě nových skutečností, případně již existujíc skutečnosti.

Základní report má následující tvar:

Úkolem je vytvořit velmi podobný report, který zobrazí data ze 2 verzí, které uživatel vybere a zobrazí mezi nimi rozdíly. Nejlépe bez nutnosti zasahovat do business vrstvy a vystačit pouze s klientskou částí aplikace Oracle BI. Takto vypadá výsledek:


Jak to udělat:
Prompt: po výběru hodnoty obou verzí nastavíme proměnné ( např. v1, v2)


Answer: uděláme jako kombinaci 2 dotazů


První dotaz uděláme standardně (vpodstatě kopie základního anter – viz první obrázek). Jediné nestandardní je omezení dotazu pomocí proměnných v1 a v2)


Druhý dotaz uděláme podobně jako první, vynecháme v něm sloupec Verze, místo něj dáme konstantu (např.) ‘Změna‘, tedy text, který se bude zobrazovat. Podmínky pro výběr zůstávají stejné jako u předchozího:


Místo původní hodnoty sloupce leden, unor, … je nyní vzorec, např pro leden:

SUM(CASE WHEN tB_form_Consol.Verze = '@{v2}{xx}' THEN -tB_form_Consol.leden/1000 ELSE tB_form_Consol.leden/1000 END)

(jinak řečeno, když verze = v2, pak otočím znaménko a pak celé sečtu, tedy dostanu rozdíl mezi hodnotou pro v1 a pro v2)

Grafická úprava: obarvení a zvýraznění rozdílových hodnot – např. takto (Vlastnosti sloupce -> podmíněné formátování)


Nakonec ještě pár fint, které se při tvorbě reportu využily:
1. Answer: obsahuje 17 sloupců, které mají velmi podobný vzorec – dá se snadno editovat ve formátu XML v záložce Pokročilé. Pozor – po úpravě nezapomenout zaškrtnout Vynechat mezipaměť a stisknout Nastavit XML


2. Dashboard: umístíme hotový report na dashboard. Po vstupu na něj je prompt prázdný a vytvořený Answer hlásí chyby, kterým běžný uživatel nerozumí. Proto byla nastavena vlastnost oddílu - řízená navigace, která zobrazí Answer jen tehdy, pokud vrací data.


3. Prompt: abych zabránil, aby se mi hodnota z promptu (verze) použila jako výzva pro omezení dotazu (protože z tohoto základního Answer jsem volal další Answer formou interakce sloupce/hodnoty a potřeboval jsem předávat hodnoty a verze se předávaly pomocí proměnných), dal jsem v promptu hodnotu do funkce, např: CONCAT(tVerze_csl_0.Verze, '')

Výše uvedení finty jsou popsány v jiných článcích.

Jan Jůza (CCA)

Fixace záhlaví tabulky na BI Dashboardu

OBIEE neumožňuje u tabulky a pivot tabulky zafixovat záhlaví tak, aby bylo vždy vidět. To se hodí zejména v případě dlouhých tabulek, kde při scrollování může uživatel snadno ztratit přehled o tom, co který sloupec obsahuje za data. Toto omezení lze částečně překonat s použitím malého workaroundu za pomocí Javascriptu a DHTML.


Aby se nemuselo vše psát a vymýšlet od začátku, lze použít již hotové Javascriptové knihovny dostupné na webu (samozřejmě si před jejich použitím pozorně přečtěte licenční ujednání). Zatím se mi nejvíce osvědčila knihovna jQuery (http://jquery.com) a její plugin Fixedtableheader (http://plugins.jquery.com/project/fixedtableheader).

Postup pro zafixování záhlaví tabulky je pak následující:

I. Online napojení na jQuery
1/ Na dashboardu, kde je dlouhá tabulka s nutností fixovat záhlaví se přidá textový objekt, zatrhne se že obsahuje HTML a vloží se odkaz na obě knihovny:


II. Stáhnout jQuery na váš server
1/ Stáhnout aktuální jQuery knihovnu (např. http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js) a pro snadnější použití přejmenovat na „jquery.min.js“ a stejně tak stáhnout Fixedtableheader plugin (např. http://plugins.jquery.com/files/jquery.fixedtableheader-1-0-2.min.js.txt) a pro snadnější použití přejmenovat na „jquery.fixedtableheader.min.js“.

2/ Přesunout obě knihovny přesuňte do adresáře [BI_HOME]\oc4j_bi\j2ee\home\default-web-app\ (root webového serveru).

3/ Restart OC4J (nebo jiný Java Container) a BI Presentation Server

4/ Na dashboardu, kde je dlouhá tabulka s nutností fixovat záhlaví se přidá textový objekt, zatrhne se že obsahuje HTML a vloží se odkaz na obě knihovny:


Dále je pak nutné do stejného nebo do nového textového objektu (obsahující HTML) přidat řádky, které určí objekt(y) typu tabulka na stránce, u kterých je nutno fixovat záhlaví. Na objekt(y) na stránce se lze odkazovat různým způsobem (viz. dokumentace na http://jquery.com). Já jsem použil pro identifikaci tabulky název její třídy (v HTML kódu class=“....“). OBIEE dává tabulkám třídu „ResultsTable“ a pivot tabulkám „PivotTable“.
Takže pokud je na dashboardu tabulka s jedním řádkem záhlaví, pak přidáme následující kód:

Pokud má tabulka dva řádky záhlaví, pak se přidá parametr určující počet řádek záhlaví:


Pro pivot tabulku se čtyřmi řádky záhlaví se použije následující kód (pozor, pro pivot tabulku je i jiná identifikace třídy!):


To je celý postup. V Internet Exploreru i Mozille se to chová zcela korektně u tabulek (pokud je v prohlížeči nastavena velikost písma na „normalní“ nebo menší). Pokud je v prohlížeči nastavena větší velikost písma potom u pivot tabulek fixované záhlaví malinko nesedí. Jedná se ale o milimetry a na rozpoznání toho, ke kterému sloupci popis v záhlaví patří to nemá vliv.

Petr Podbraný (Oracle)

PS: Než začnete jQuery zkoušet ve svém prostředí, podívejte se na náš Demo server jak Fixed table header funguje.

eec.

Rychlost načítání závislého promptu

Na úvod – tento příspěvek neobsahuje žádný „how-to“ postup, který (zatím) neexistuje (?!). V rámci snahy dosáhnout komfortního prostředí pro uživatele reportů jsem se snažil zrychlit načítání obsahu závislého promptu.

Problém - spočívající v dlouhé době odezvy způsobený generováním seznamu hodnot pro závislý prompt - je tím palčivější, čím „větší“ jsou dimenze, které mají být promptovány. Problém budu ilustrovat na objektech defaultního schématu Oracle databáze – schématu oe.

Použitá metadata:



Report + prompt:


Popis problému:
V případě výběru konkrétního EMPLOYEE_ID (např. 153) se v CUST_LAST_NAME závislém (Constrain = yes) promptu zobrazí pouze příslušní zákazníci (Welles, Pacino, Martin, Landis, Fawcett). Nastavení závislostí mezi prompty je určitě dobrá věc, neb koncový uživatel není obtěžován nerelevantními možnostmi. Každé takovéto přegenerování závislého promptu však trvá. Snažil jsem se promtu pomoci v rychlosti použitím cache.

Ačkoliv se však následující dotaz uloží do cache:


Při změně promtu EMPLOYEE_ID (a vygenerování „podobného“ dotazu)se Cache nepoužije:


Druhý dotaz reprezentuje podmnožinu dotazu prvního. Podle aktuální dokumentace by jednoznačně měl nastat tzv. cache-hit. Obrátil jsem se tedy na Oracle support. Popisovat vývoj celé komunikace by zabralo mnoho řádek - alespoň zkratkovitě: Nejprve jsem dostal informaci , že se jedná o žádoucí chování. Při poukazu na rozpor s dokumentací nakonec připustili, že se jedná o chybu, ale pouze dokumentační - při „dimension-only“ requestech je pro cache hit nutný tzv. „exact-match“ (v projekční i restrikční části dotazů). Reakcí tedy měla být změněná dokumentace.
Dalším krokem bylo poukázaní na zajímavý fakt: použije-li se stejný scénář oproti XML datům, cache hit nastane podle očekávání – najednou „exact-match“ potřeba není. Nakonec byl tento request uznán jako Bug 8541767 a byl zařazen do vývoje release 11. Dokumentační Bug byl také vytvořen.

Pořád mám ale pochybnost. Že bych byl první (ve skutečnosti jeden podobný zapadlý request existoval a byl zamítnout … ale i tak – druhý a nikdo jiný?), kdo se s tímto problémem setkal? Takže třeba něco přehlížím, neznám nebo se v něčem velmi pletu?

Václav Bíba (konzultant společnosti NESS)

Využití zobrazení SQL pro tvorbu filtrů ve výběru sloupce

Postup lze snadno demonstrovat na příkladu. Mějme pohled na data podle následujících kriterií:


Nad tímto dotazem je třeba vytvořit prompt sloupce Month, kdy je požadavek, že mají nabízeny pouze hodnoty měsíců splňující tato kriteria:
2006/01 <= Month <= zp_mesic_max (zp_mesic_max je proměnná repository) Nesmí se však nabízet měsíce 2006/04, 2007/01 a 2008/02 a pořadí v jakém se měsíce do výběru nabízí musí být odshora dolů. Je zřejmé, že řešením je zařazení SQL dotazu. Aby nebylo nad tím to SQL nutno moc přemýšlet, lze používat velmi rychlou a na přemýšlení nenáročnou metodu. Vytvoříme výběr obsahující pouze sloupec Period.Month, nad ním vytvoříme příslušný filtr a upravíme pořadí zobrazení odshora dolů.


Na záložce „Pokročilé“ si zobrazíme kód SQL tohoto zobrazení.


Text
dáme do clipboardu a pak jej vložíme do okna SQL příkaz v promptu.


Výsledkem je:


Nabízené hodnoty jsou skutečně seřazeny odshora dolů a chybí v nich 2008/02 (i ostatní zakázané hodnoty).

Jiří Doubravský (PIKE ELECTRONIC)