Asi největší novinkou prezentovanou na Oracle Open World 2011 z naší oblasti je Oracle Social Network. Pro ty z vás, kteří již měli příležitost si o tom něco vyslechnout, se jedná o využití nástroje OnTrack pro řadu zajímavých scénářů.

Oracle Social Network byla uvedena skutečně impozantně - ve své keynote ji přestavil Larry Ellison a věnoval ji skoro půl hodiny; dokonce v rámci prezentace předvedl simulované demo na jeden obchodní scénář!

Prezentace je již k dispozici (zde, Social Network je věnována druhá polovina) a pokud vás téma zaujalo, rozhodně doporučuji se na ni podívat - produkt není dále představovat, v podstatě se prodává sám.

Pokud bychom přeci jen chtěli docílit nějakého shrnutí:

• jakkoli je možnost uchování veškeré komunikace v perzistentní podobě, s možností kontextových komentářů a spoustou dalších "vychytávek" zajímavá, její hlavní hodnota (jedná se o způsob komunikace a cesta zde rozhodně není cíl) je v návaznosti na obchodní proces (v ukázce se jedná o obohacení CRM systému při řízení obchodní příležitosti). Chcete-li, hodnota nasazení Oracle Social Network je rozdíl, o kolik se zlepší proces v dané aplikaci.

Osobně si myslím, že v tom spočívá i hlavní rozdíl mezi tímto nástrojem a jinými sociálními sítěmi (i když takový LinkedIn se může dost dobře stát součástí procesů HR) - zde je počítáno s jeho využitím v rámci jiných obchodních aplikací. Samozřejmostí je integrace do prostředí Oracle Fusion Applications (mimochodem, další zásadní novinka Open Worldu), ale stejným způsobem je možno postupovat i např. u aplikací třetí strany (zejména, jsou-li tyto napsány v technologii, která umí konzumovat portlety).

Novinkou je také to, že Social Network nebude prodáván na CPU a uživatele, ale spíše modelem čerpání služeb cloudu (tj. na jakési bázi měsíčních plateb za skutečně zkonzumované zdroje). Prozatím jsem k tomuto tvrzení nenašel žádné detaily, ale budu pátrat dále.

ADF vs. WebCenter Framework

Svět píše o Steve Jobsovi, v Americe probíhá Oracle OpenWorld, ale my se po určité odmlce způsobené svátky a mojí osobní situací podíváme na velmi technické téma, které, jak se zdá, vzbuzuje otázky nejen u nás.

Pro správné pozicování ADF a WebCenter (zde se omezíme jen na základní komponentu, tzv. WebCenter Framework) je třeba nejprve napsat pár slov o ADF.

ADF je jeden z frameworků pro vývoj webových aplikací v jazyce Java. Jak se píše v záhlaví na jeho domovské stránce na oracle.com, usnadňuje vývoj těchto aplikací tím, že poskytuje služby out-of-the-box a aplikace je možné psát vizuálně a deklarativně; tj. místo psaní řádek kódu se do aplikací "přetahují" myší komponenty, které framework nabízí a které se pak konfigurují (buď v GUI vývojového prostředí, nebo editací XML souborů).

Hlavním přínosem však nejsou ani hotové objekty, ze kterých je možné aplikaci rychle poskládat, ani "programování myší", jako důsledné dodržování architektonického patternu Model-View-Controller, zejména pak oddělení business či doménové logiky (Model) od uživatelského rozhraní (View), a to vše provozovatelné v běžném webovém prohlížeči (Controller).

WebCenter Framework je určen pro psaní portálových aplikací -pro popis vlastností portálu viz. tento dřívější článek. Pokud ponecháme stranou personalizaci obsahu za běhu a podporu formálních norem (portletový kontejner či framework pro psaní portletů dle JSR 168 či JSR 286), je možné řadu cílů (např. "spojení lidí, informací a procesů") dosáhnout i jen za pomocí ADF, či jiného podobného frameworku.

Otázkou však je, jak moc je to efektivní. WebCenter Framework samozřejmě přináší další hotové komponenty určené právě pro portálové aplikace. Jeho síla se pak projeví zejména, když se využijí další produkty suite WebCenter Portal, nebo (teoreticky) produkty podobného zaměření třetích stran (např. BPM procesy mohou běžet i na jiném produktu, než je BPEL PM obsažený ve suitě; podmínkou je užití normy BPEL pro procesy). Jedním takovým příkladem budiž Content Presenter, který umí v portálovém prostředí zobrazovat dokumenty uložené v UCM (k dnešnímu dni, pokud je mi známo, to mohou být HTML dokumenty či obrázky, nikoliv "nativní dokumenty" a jejich PDF konverze).

Jinak, WebCenter Framework je postaven nad ADF a budete-li aplikace psát (druhou možností je konfigurovat hotovou aplikaci WebCenter Spaces), bez znalosti ADF se určitě neobejdete.

Anotace - jak okomentovat dokumenty, které nelze editovat

Při revizi "officovských" dokumentů se často využívá funkce sledování změn (Track Changes), která umožňuje při posílání mezi různými účastníky procesu sledovat, kdo má k jaké části jakí připomínky.

Co však dělat, když je předmětem revize dokument, který se edituje obtížně (PDF), či nejde editovat vůbec (TIFF ze skeneru nebo dokonce zvukový záznam)?

Touto otázkou se zabývají anotace, resp. přesněji anotace v kontextu - resp. anotace v kontextu, protože stejně tak lze vytvořit anotace mimo kontext (př. "Na stránce 5, řádce 16, změňte font na Times, 16pt.").

Kontextové anotace mají tu výhodu, že ukazují, často ve WYSIWYG podobě, na co přesně připomínka reaguje. Navíc nejsou součástí dokumentu - nehrozí tedy, že je omylem pošlete s finální verzí, je možné je dále škálovat (kdo má kterou vidět apod.)

Už poměrně dávno vyšel na tomto blogu článek o AutoVue.

Dnes má Oracle v portfoliu už dvě další technologie, které jsou schopny téhož. Jedna se jmenuje WebCenter Imaging (dříve Imaging and Process Management). Druhá zatím oficiální název nemá - do konce srpna byla známa pod jménem OnTrack.

Imaging pracuje, jak název napovídá, především s naskenovaným obsahem. Anotace umožňují vytvořit textovou poznámku, či highlighting, popř. "sticky notes" (žluté nálepky). Další funkcí je pak možnost vytvoření výstupu (TIFF), který obsahuje anotace viditelné pro daného uživatele.

OnTrack je produkt, který byl uvolněn teprve letos. Jeho schopnosti anotací jdou ještě dál - umí dokonce anotovat i multimediální obsah (zvukový záznam konferenčního hovoru). Tomuto produktu se v blízké budoucnosti určitě ještě budeme věnovat detailněji.

Změny v ceníku v oblasti WebCenter

Se začátkem nového školního roku se do ceníku začaly promítat první změny související se zavedením marketingové značky WebCenter a akvizicí FatWire (viz dřívější články na tomto blogu).

Asi největší novinkou je vyjasnění, za jakých podmínek budou nabízeny produkty FatWire (jejich přehled najdete zde). V podstatě jsou nabízeny v souhrnné suitě, pod názvem WebCenter Sites. Jedinými produkty, které se nadále prodávají odděleně, jsou WebCenter Sites Satellite Server, což je řešení pro cachování stránek, které je možné dokoupit jako option pro podporu výkonu, a WebCenter Sites Mobility Server pro možnost provozování stránek i na mobilních zařízeních typu iPhone.

Další novou položkou je super suite WebCenter Suite Plus, která (dnes) obsahuje v podstatě kompletní portfolio (WebCenter, ECM Suite, FatWire).

Zajímavé je ale sledovat i to, co ubylo. Produkty pro sociální sítě zatím v přehledu spíše chybí - prý se očekává jejich představení na Oracle Open World. Kromě nich však v přehledu chybí i Oracle UCM (jedinou licencí, která jej obsahuje, je WebCenter Content, což je obsahově licence shodná s dřívější ECM Suite), Oracle UCM Standard Edition, Oracle URM, WebCenter Services a WebLogic Portal. Osobně jsem zvědav, zda se na tomto stavu do budoucna něco změní.

Webcenter: zaměřeno na Resource Catalog

Resource Catalog (katalog zdrojů) nabízí konsolidovaný pohled na jinak odlišné zdroje informací (databáze, web services, MDS repository).

Jak je vidět z obrázku, je možné jej užívat jak prostřednictvím aplikací, tak z prostředí vývojového IDE JDeveloper (při tvorbě WebCenter aplikací).

Při užití v JDev je pak možné katalog užít dvěma způsoby:

• při návrhu aplikací
• za běhu aplikací (tento způsob je shodný s užitím z aplikací - Oracle Composer, viz starší článek na toto téma)

Při návrhu se zdroje z katalogu objevují v paletě nástrojů (podobně jako jiné zdroje z palet frameworku ADF). Při využití za běhu je třeba mít na paměti, že se změny ukládají do MDS repository, která není součástí vyvíjené aplikace - při vývoji WebCenter aplikací se proto doporučuje mít zapnutu volbu, aby se při spuštění aplikace vždy MDS vyprázdnila, aby pak po přesunutí na jiný server nedošlo ke, zdánlivě neočekávané, ztrátě nastavení.

Od verze PS 3 je možné vytvářet i uživatelské katalogy a migrovat katalogy z jednoho serveru na druhý. Uživatelský katalog může pro danou aplikaci či space předefinovat, které zdroje se budou uživatelům nabízet.

Práce s číselníky, definice vazeb mezi metadaty

Pokud chceme v UCM (WebCenter Content) pracovat s číselníky, tj. omezenými seznamy, ze kterých se vybírá hodnota příslušného metadatového pole, máme několik možností.

Option List
Je-li hodnot jen několik a jsou-li v podstatě neměnné povahy, je možné využít tzv. Option Lists. Jak napovídá název, jedná se o objekt, který v sobě má na jednotlivých řádcích uvedeny hodnoty. Option List je možné vytvořit v Configuration Manageru.

Tree
Speciálním případem Option Listu je tzv. tree, strom, který umožní hodnoty v seznamu seřadit hierarchicky. Na dané úrovni jsou vždy vidět jen předci, přímí sourozenci a přímí potomci daného uzlu (seznam může být přehlednější).

Custom Tables, Views
V případě, že je třeba hodnoty v čase periodicky aktualizovat, je lepší použít tabulky a pohledy (views). Pokud se v Configuration Manageru vytvoří tabulka, znamená to fakticky, že se vytvoří nová tabulka v datovém modelu aplikace a přidá se její záznam mezi tabulky, které je možné v rámci definice metadat využívat.
Pohled umožňuje z tabulky vybrat některá data (sloupce i řádky). Na rozdíl od zvyklostí z databáze, obsahuje pohled, nikoliv tabulka, volbu Edit Values (Změň hodnoty), která umožní měnit hodnoty v tabulce uložené. Dalším důležitým polem je Visible Column, kterým umožní z pohledu vybrat jeden sloupec, jehož hodnoty je pak možné asociovat s vybraným metadatovým polem.

Představme si následující příklad:

Vytvoříme tedy 2 tabulky (Dodavatel, Dodavatel_detail) s příslušnými sloupci. Dále vytvoříme 3 pohledy (jeden nad tabulkou Dodavatel s viditelným sloupcem supplier_name a dva nad tabulkou Dodavatel_detail se sloupci country resp. city).

Pokud jsme tak ještě neučinili, vytvoříme příslušná metadatová pole. Dále pak můžeme asociovat pole s příslušným pohledem (v rámci Add/Edit Metadata Field vybereme Enable Option List a v rámci dalšího dialogu pak příslušný view).

Pokud bychom ponechali konfiguraci v tomto stavu, zobrazovaly by se pro country a city všechny 4 hodnoty z tabulky Dodavatel_detail.

Žádoucí je však, aby se nejprve vybral dodavatel (dle jména) a v detailních hodnotách se pak vybíralo jen mezi hodnotami příslušným tomuto dodavateli.

Relationship
Aby toto bylo možné, je třeba nejprve vytvořit další objekt, tzv. relationship (vztah). V řeči databáze se jedná o odkaz pomocí cizího klíče - opět v Configuration Manageru vytvoříme vztah mezi našimi dvěma tabulkami a sloupcem supplier_id jako cizím klíčem.

Relationship je pak třeba ještě použít v definici závislých metadatových položek (zaškrtne se Dependent Field a pak vybere Depends on Field - supplier_name při využití právě vytvořeného relationship)

Dvě upozornění:

• pokud smažete tabulku vytvořenou v Configuration Manageru, zmizí ze seznamu, ale nebude odstraněna z databáze (musí se smazat administrátorskými prostředky databáze)
• pokud v rámci definice tabulky nevyberete primární klíč, bude se automaticky brát jako primární klíč první sloupec
  

Webcenter: zaměřeno na Business Mashup

Jakkoli využití termínu mashup není úplně nepřesné, mnohem trefnější nazvání pro to, co business mashupy dělají, by bylo implementace patternu Model-View-Controller, přičemž hlavním přínosem části dodané Web Centerem oproti témuž v "prostém" ADF je možnost změn v runtime režimu.

Vrstvu Model bude měnit administrátor. Zde se nejčastěji využívá SQL pro získání dat z databáze (Pozor! Webcenter využívá databázová spojení definovaná na úrovni Weblogic Serveru - pro jejich vytvoření je tedy třeba spolupracovat i s administrátorem WLS), nebo web services.

Vrstvu View mění uživatel, popř. power-user pro celou skupinu. Jejím úkolem, jak napovídá anglický termín, je zobrazit data v požadované formě uživateli. Uživatel si může vybrat z řady vizuálních komponent (jedná se o ADF Visualization Components), které jsou standardně dodávány - typicky, tabulkové přehledy, grafy apod, popř. z custom komponent vytvořených vývojáři na míru.

Business Mashups jsou mashupy v tom smyslu, že na jedné stránce umožní zobrazit data z více zdrojů. Každý z nich však pracuje s jedním zdrojem.

eGovernment 2.0

V jednom příspěvku na české Web 2.0 skupině na LinkedIn si kdysi kdosi postěžoval, že o Web 2.0 spousta lidí mluví, ale nikdo nepoužívá. Zkusme se nyní podívat na jeden site, kde by se tyto technologie užívat mohly a k čemu by to vedlo.

Ten site se jmenuje Portál Veřejné Správy České Republiky. Není asi jeho chybou, že na české wikipedii byl pod tímto heslem dlouho obsah související s kauzou Vladimíra Mlynáře (viz též zde).

Jak portál funguje? V zásadě se jedná o rozcestník informací o tzv. životních situacích (např. chci nový občanský průkaz), kdy se dostává stát a občan do vzájemné interakce. Portál má (zřejmě) na pozadí i redakční systém, kdy příslušné sekce smí aktualizovat jen příslušný orgán státní správy.

V čem jsou rezervy? Především, portál je neadresný - při výměně občanky se dozvím, co musí ze zákona udělat všichni, ale už ne kam a kdy mám jít (např. na základě adresy v mém uživatelském profilu), neřku-li, má-li daný úřad nějaké svoje specifika (není asi tajemstvím, že stejný úkon na různých úřadech může mít různý průběh).

Tím, že redakce probíhá výhradně centralizovaně, tvoří se klasické úzké hrdlo - některé úřady jsou aktivní, jiné to berou spíš jako svoji nevítanou povinnost. Navíc, místní úřady ani nemají možnost do procesu vstupovat (pokud by nějaký osvícený starosta nebo vedoucí úřadu chtěl např. umístit na stránky elektronický formulář, abych pro něj nemusel na úřad, nemá možnost).

Z klasických 2.0 vlastností bych uvítal možnost diskuzí - občan by měl možnost vyjádřit názor (vůči úřadu) nebo dát doporučení (vůči dalším užvatelům). Zajímavé by mohly být zejména názory odborné veřejnosti. Pro vyhledávání bych určitě uvítal tagging - portál má sice vyhledávání, ale opět definované shůry, tagging by umožnil upravit vyhledávání dle preference uživatelů.

Poslední oblastí, která by určitě stála za zlepšení, je lokalizace do cizích jazyků. Portál sice nabízí verzi v angličtině, tzv. pro cizince, informací je tam však výrazně méně než v české verzi. Asi není možné chtít po státu, aby sám obstaral překlady do cizích jazyků - zde by však mohl být prostor pro krajanská sdružení. Myslím, že pro řadu cizinců by bylo lepší mít státem neautorizovaný překlad, než státem autorizovanou verzi v češtině.

Toto jsou příklady, které se jistě dají aplikovat na řadu dalších portálů, a to nejen ve státní správě.

My jsme všichni WebCenter

Minulý týden jsem se účastnil školení na téma WebCenter PS3. Na toto téma jsme si už na blogu psali dříve. Co mě přišlo jako zajímavý údaj, který trochu souvisí i s minulým článkem, tj. akvizicí FatWire, je změna značky celého portfolia v oblasti (dříve) E2.0.


Abych parafrázoval hlášku z oblíbené české komedie Čtyři vraždy stačí, drahoušku, odteď už platí: my jsme všichni WebCenter. Např. UCM se od nynějška bude jmenovat WebCenter Content.

Proč dochází k této změně? Jeden důvod je marketingový - WebCenter představuje značku, pod kterou bude Oracle nabízet všechna řešení na správu elektronického obsahu, budování portálových aplikací, webových stránek, či týmovou spolupráci.

Druhý, méně viditelný, ale o to důležitější důvod je vnitřní restrukturalizace vývojářských týmů, které nyní budou podláhat jednomu vedení, tudíž bude minimalizována šance, že by se některé věci dělaly dvakrát či vícekrát.

Pokud tak nedojde do zveřejnění tohoto článku, měl by se v nejbližší době upravit i ceník. Uvidíme, zda změna názvu bude jedinou, či zda dojde i k jiným změnám.

Připojení IRM Desktop na IRM 11g

Poslední dobou se několik odvážlivů pokusilo na vlastní pěst zprovoznit demo na IRM 11g. Protože ne všechny potřebné kroky jsou úplně intuitivní, pokusme si v dnešním článku sepsat vše popořádku.

Předpoklad: stále platí, že na klientském počítači musí být nainstalovány Microsoft Internet Explorer (prozatím ve verzi 7 nebo 8) a klientská aplikace IRM Desktop

Krok 1 - konfigurace serveru: tato část se oproti 10g příliš nezměnila. Jediné, na co je třeba si dát pozor, je, že IRM Desktop aplikace vždy po úspěšném spojení se serverem 'přeloží' IP adresu na jméno web serveru, proto je vždy třeba mít dostup k DNS serveru, který zná jméno, nebo si jej explicitně přidat do souboru host na Windows (to se bude týkat zejména situací, kdy server provozujete lokálně ve virtuálním image, tj. při demonstracích)

Krok 2 - instalace certifikátu: IRM 11g je J2EE aplikace provozovaná na Weblogic serveru. Aby nebylo možné odposlouchávat komunikaci se serverem, využívá se protokol HTTPS. Při instalaci serveru je tedy, kromě jiného, potřeba nainstalovat i certifikát pro HTTPS komunikaci. Pokud se objeví tento dialog:


je třeba certifikát nainstalovat (pro testovací účely mezi Trusted Root). Je na Vašem administrátorovi, aby server používal ověřený certifikát.

Krok 3 - deaktivace proxy (v IE): posledním nutným krokem je deaktivace proxy při komunikaci s IRM serverem, pokud je IRM před proxy nebo dokonce na lokálním virtuálním image.

Pokud se přes tyto kroky dostanete, zadejte adresu https://irm_server_URL/irm_desktop do Internet Exploreru. Na zobrazené stránce by se měla objevit záložka Test a v ní obrázek zlatých rybiček.

Ještě jeden tip: v IRM Desktop, na záložce Update Rights najdete volbu Check in. Ta umí odstranit data přihlášeného uživatele (pokud v rámci demonstrace chcete ukazovat práci více uživatelů z jednoho počítače).

Oracle zakoupil FatWire

Minulý týden se objevila zpráva, že Oracle zakoupil firmu FatWire. Pro vás, kteří tuto firmu neznáte, FatWire dodává řešení v oblasti Web Content (resp. Web Experience) Management. Z tohoto pohledu bude tedy zajímavé sledovat, jak se do budoucna bude vyvíjet produktové portfolio v této oblasti.

Jak rozumět akvizici?
Hlavními důvody pro nákup, aspoň dle komentářů na nezávislých serverech, se zdají být:

1. korelace s předchozí akvizicí produktu ATG (platforma pro eCommerce) - řada zákazníků ATG již vlastnila i FatWire, zejména pro podporu kampaní přes web
2. zvýšení market presence v některých segmentech
3. zkušenosti s provozováním řešení v public cloudu

FatWire bude prozatím fungovat jako nezávislá firma - dokončení akvizice se očekává v průběhu roku 2011. Uvidímě, jak se bude situace dále vyvíjet.

Java Filter Events - událostmi řízené programování v UCM

V návaznosti na minulý článek se dnes zaměříme na poněkud vyšší školu programování v souvislosti s Oracle UCM - změny chování Java Custom komponent. Jednou z možností je samozřejmě přepis služeb (ať už voláním jiných metod, či změnou kódu volaných standardních metod). Existuje však ještě jiný způsob - využití standardních událostí a dopsání reakce na ně.

Např. extraBeforeCacheLoadInit je událost, která se vyvolá poté, co je z UCM navázáno spojení do databáze, ale před tím, než se data z databáze přenesou do cache. Z tohoto titulu se hodí pro propagaci změn do datového modelu (např. přidání nové tabulky či sloupce z javovské komponenty).

Třída, jejíž metody se tímto způsobem mohou zavolat musí implementovat interface intradoc.shared.FilterImplementor, tj. mít metodu doFilter, která se zavolá.

Výhoda filtrů oproti přepsání je zřejmá - jsou volány v okamžiku, kdy aplikace "předpokládá", že do běhu bude zasahováno - nemění se tedy standardní kód, jako spíše doplňuje, což může výrazně zjednodušit údržbu celé komponenty. Navíc je možné filtry za sebou řetězit.

Pro nasazení je tedy důležité především umět vybrat správnou událost, na kterou se filter "pověsí". Bohužel se mi nikde ve standardní dokumentaci nepodařilo najít jejich popis (celkem jich je ke dvěma stům) - nejlepším zdrojem proto asi bude stále kniha B. Huffa, kapitola Appendix H.

Tip dne: zadejte termín extraBeforeCacheLoadInit do Google. Kdo bude mít trpělivost, možná najde poklad.

Pár zásad pro psaní UCM komponent

I při psaní komponent pro Oracle UCM je třeba dodržovat základní návyky z programování.

Zásada 1: pište kód na urovni, na kterou patří
Komponenty UCM mají v podstatě několik logických úrovní:
- HTML - v případě, že budete modifikovat GUI, začnete nejspíše na úrovni HTML. Na této úrovni je možné měnit statický obsah stránek nebo jejich layout (pro změnu layoutu se nejčastěji používá HTML tag TABLE).
- IDOCSCRIPT - je pokračováním úrovně HTML. Na úrovni GUI dodává do komponent dynamický charakter - na místo pevných textů umožňuje do layoutu stránky vyplnit proměnlivý text, jako je třeba název položky. IDOCSCRIPT také užívejte, pokud chcete přistupovat ze stránky k datům či službám UCM. IDOCSCRIPT je samozřejmě možné využít nejen pro změny GUI, ale i na dalších místech - např. custom události nativních workflows či podmínky pro aktivaci pravidla (rules) v rámci zobrazovacích profilů jsou také psány v tomto jazyce.
- JavaScript, VBScript - jedná se o jinou úroveň dynamiky - o změnu stránky či jinou činnost (např. validaci, že zadaný obsah je číslo nebo datum), aniž by bylo nutné kontaktovat server.
- SQL - databáze se využívá pro perzistentní uložení dat - minimálně metadat, volitelně též obsahu či pomocných proměnných.
- Java - metody javovských tříd mohou být volány z definice služeb UCM. Proto se využívají pro back-end logiku. Javadoc (bohužel neúplný) najdete v balíčku HowToComponents(v adresáři Documentation)

Zásada 2: používejte komentáře
IDOCSCRIPT není objektový jazyk - není schopen polymorfismu, je však schopen přetížení - jedním ze základních konstruktů jazyka jsou tzv. includes, což jsou v podstatě ekvivalenty procedur a funkcí ze strukturovaného programování. Při definici metody se každému zdroji, který obsahuje includes, přiřazuje parametr loadOrder, který rozhoduje, jaký kód bude při zavolání includes nakonec proveden (vítězí "vyšší" loadOrder). Jazyk ještě obsahuje konstrukt super, který umožňuje (zpravidla v rámci nového include) volání kódu přetíženého include - velmi efektivně jej můžete využít, pokud nový kód něco "předřazuje" nebo naopak "doplňuje za" starý kód. Přesto si myslím, že častěji budete prostě "přepisovat" kód, přičemž původní kód bude sloužit jako základní verze. A protože nemůžete vyloučit možnost, že se někdy v budoucnu tento základní změní (Oracle vydá patch nebo novou verzi), je vhodné psát váš kód tak, aby bylo zřejmé, co jsou vaše změny a co je původní.
Komentáře v IDOCSCRIPTu se vkládájí mezi [[% a %]].
V rámci komponenty je pak slušnost napsat a aktualizovat readme (txt nebo html).

Zásada 3: využívejte jména zdrojů, includes, proměnných pro větší čitelnost a srozumitelnost kódu

DB Options - vylepšení celého řešení na úrovni databázové vrstvy, část 2.

Dnes dokončíme přehled options a další vlastnosti databáze, které mohou pomoci při práci s dokumenty.

SecureFiles jsou vlastností databáze 11g pro práci s nestrukturovaným obsahem ("dokumenty"). Při jejich užití je možné uložené dokumenty: deduplikovat (v případě vkládání stejného dokumentu se ukládá jen jednou), komprimovat a šifrovat (na rozdíl od Security Option se šifrují jen samotné dokumenty).

Oracle Text dokáže vytvářet fulltextové indexy. Pro jeho využití není nezbytné, aby se dokument ukládal do databáze (indexace probíhá proti souboru na disku). Při jeho využití není potřeba dokupovat index servery třetích stran (v dřívějších verzích Stellent spolupracoval s nástrojem Verity).

Oracle Data Guard je řešení pro synchronizaci mezi primární a záložní lokalitou. V případě ukládání dokumentů do databáze je možné dokumenty i metadata synchronizovat čistě touto technologií. Co zatím není možné, je využít option Active Data Guard, který dokáže záložní lokalitu využívat pro read-only dotazy. V současném nasazení je možné záložní lokalitu využít pro testovací či školicí prostředí (využívá "volný" výkon zbylý po synchronizaci).

Advanced Compression option umožňuje zmenšit obsah, který zabírají na disku - opět se vztahuje jak na dokumenty, tak na metadata. Její využití na dokumenty závisí do značné míry na ukládaném obsahu (MS Office dokumenty se komprimují dobře, PDF už mnoho neušetří), komprimace metadat může mít vliv při opravdu velkých projektech (desítky miliónů záznamů a více). Při těchto objemech už může být zajímavé i nasazení Hybrid Columnar Compression, která je k dispozici v Exadatě.

Co říci závěrem?
Databáze je jednou z vrstev ECM řešení a zejména u velkých řešení je dobré se zamyslet na celkovou architekturou a požadavky a nastavit využití databáze dle potřeb. Jedno ideální řešení určitě neexistuje, ale vždy je možné najít optimum pro konkrétní danou situaci.

DB Options - vylepšení celého řešení na úrovni databázové vrstvy, část 1.

V návaznosti na článek z minulého týdne, kdy jsme se dotkli tématu databázových options, pojďme si udělat kompletní přehled, které z nich a jiných vlastností databáze Oracle mohou a jakým způsobem přispět k celkovému řešení pro správu dokumentů.

Real Application Clusters (RAC): jedná se o option, který má na starosti škálování (při přidání dalšího databázového uzlu-serveru se výkony všech sčítají) a vysokou dostupnost (při výpadku jednoho uzlu-serveru běží řešení na zbývajících) na úrovni databáze. Její funkce je transparentní pro běh podporovaných aplikací.

Partitioning: partitioning dokáže rozdělit velké tabulky na několik částí (partitions). Tato vlastnost může mít pozitivní vliv na výkon (běží-li dotaz v rámci jediné nebo několika partitions, může běžet rychleji). Z pohledu řešení UCM je však mnohem důležitější, že při využití další vlastnosti databáze, Automatic Storage Management, mohou být jednotlivé partitions uloženy na různých fyzických médiích, což může vést k výrazným úsporám na úložném prostoru. Další využití partitioningu může být při backupu či obnově ze zálohy - při vhodném návrhu kritérií partitioningu je možné urychlit backup (mění se jen 'nejnovější' partitions), či spustit řešení nad ne zcela obnovenou databází (např. se obnoví jen data za poslední měsíc či rok, které jsou pro uživatele nejdůležitější a starší budou do systému dodávány teprve postupně). Zde už je třeba trochu znát, jaký je datový model. V zásadě ale platí, že dokumenty (tabulka FileStorage) či historické záznamy (SCTAccessLog či např. WorkflowHistory) je možné partitionovat hierarchicky, naopak metadata (např. Revisions) je sice možné partitionovat, při obnově však musí být tabulka obnovena celá.

U některých projektů (zejména v oblasti Records Managementu) se někdy zavádí koncept 'životně důležitých dokumentů', kdy jsou takto označené dokumenty obnoveny prioritně - kritérium pro partitioning je tedy řízeno metadaty.

V zásadě platí, že přesáhne-li velikost databáze 1 TB, nejspíš byste měli partitioning v architektuře využít.

Advanced Security (ASO), Database Vault, Label Security: jak napovídá název, tyto options jsou zaměřeny na zabezpečení - v tomto případě se jedná o zabezpečení před útoky "zevnitř" (ze strany administrátorů). ASO umožňuje zašifrování citlivých údajů - ať už ve metadatech, nebo především pak vložené dokumenty, a to buď přímo v databázi, nebo i v dalších užití - v backupech, při posílání po síti apod. Ostatní dvě technologie pak mohou zajistit, že ani administrátor databáze nebude mít možnost dané nastavení měnit - jeho oprávnění budou dána nastavením v systému pro správu identit.

Nasazení těchto komponent je na místě, pokud systém bude spravovat citlivá data. Víceúrovňová správa přístupu pak může být zajímavá i pro hostovaná řešení (správce prostředí se bude starat o chod prostředí, nebude mít však žádný přístup ke spravovaným datům).

(pokračování někdy příště)

Ukládat, či neukládat (dokumenty do databáze)

Nedávno jsem byl svědkem dvou, poměrně vášnivých, diskuzí na téma zda ukládat dokumenty do databáze, či nikoliv. Osobně se nekloním ani na jednu stranu. Trefně to však vystihl kolega, který prohlásil, že každý preferuje to, co zná. Pojďme se však podívat na věc pokud možno objektivně.

Rychlost (zejména vkládání dokumentu)
Častým argumentem odpůrců vkládání je tvrzení, že vkládání dokumentu na databáze trvá výrazně déle než vkládání na filesystem. Toto (minimálně pro databáze Oracle) byla pravda někdy, dnes již dost dávno. Obecně trvá vkládání do databáze o něco déle, rozdíl je však v jednotkách procent. A pro některé speciální případy (vkládání mnoha krátkých souborů najednou) dokáže být databáze dokonce rychlejší. Stejně tak může být rychlejší, pokud je systém synchronizován (např. z důvodů disaster recovery - databáze synchronizuje celý commit, filesystem každou změnu).

Komprese, deduplikace, šifrování dokumentů
Argumentem zastánců databáze naopak bývá možnost využití databázových options, a to zejména na kompresi vkládaných dokumentů (zmenšení obsahu na disku), deduplikaci (vkládá-li se stejný soubor vícekrát, je uložen fyzicky jen jednou a z dalších míst existuje odkaz) a zašifrování (ani pro db administrátora nebude soubor čitelný, pokud si jej vyhledá prostředky databáze).
Předně, tyto options často bývají k dispozici i na úrovni filesystému (zpravidla taktéž za příplatek). Navíc, jejich přínos je velmi závislý na tom, co se bude do úložiště ukládat (dokumenty MS Office se budou komprimovat dobře, PDF, TIFF či JPEG formátům asi komprese moc neubere), či jak je projekt implementován (přílohy emailů po firmě by se neměly posílat jako soubory, ale jako odkazy do úložiště).

Synchronizace active a stand-by lokality
Podobně je na tom využití technologie DataGuard pro synchronizaci active a stand-by lokality u řešení v rámci disaster recovery. UCM bohužel "odkládá" některá provozní data na filesystem (z těch nejznámějších: stavy položek ve workflows), a tak je podporována jen instalace, kde je synchronizována databáze i filesystem.

Fulltext indexace
Databáze umí (kromě engines třetí strany) indexovat soubory pro fulltextové vyhledávání. Pro využití této vlastnosti však není nezbytně nutné, aby zdrojové soubory byly uloženy v databázi (v databázi je v každém případě výsledný index).

Jednotná správa
Pokud nebudete implementovat model OAIS, který vyžaduje, aby i v případě ukládání dat na "otevřenou platformu" byla data i metadata u sebe, dá se očekávat, že při ukládání na filesystem budou metadata v databázi, tj. při případné ztrátě či chybě, která oba celky od sebe rozpojí, budete mít problémy spojit, co k sobě patří (po pravdě řečeno, i s metadaty rozházenými na disku to nebude o moc snazší). Toto je tedy argument pro databázi. Na druhou stranu, k jeho uplatnění dojde jen v opravdu krizových situacích a v případě správné politiky zálohování lze dopady minimalizovat.

Hierarchical Storage Management
To jest, ukládání starších dat s možnou delší vybavovací dobou na levnější fyzická úložiště lze dosáhnout jak prostředky databáze, tak filesystému - při využití partitioningu bude databáze pracovat s několika málo většími soubory, zatímco na filesystému bude základní jednotkou nejspíš jednotlivý soubor, což opět může být mírný agrument pro databázi.

V souhrnu je tedy vidět, že obě metody jsou srovnatelné s mírnou převahou pro ukládání v databázi. Při výběru metody je tedy třeba zvážit i to, na co jsou zvyklí administrátoři zákazníka či zda zákazník neinvestovat do jedné či druhé metody a očekává zhodnocení svých investic v rámci projektu.

Přehled vlastností Oracle WebCenter Suite, část 5.

Při hledání informací do dnešního článku jsem našel přehled vlastností WebCentra vytvořený jedním z product managerů. Je k nahlédnutí zde (a pokračování na stránkách přes link v záhlaví hlavního dokumentu).

To, co nám ještě zbylo, jsou vlastnosti schované pod hlavičkou WebCenter Anywhere, což jsou služby, které slouží k propojení WebCentra s "jinými zdroji podobného charakteru" v organizaci.

Pagelet Producer (dřívě též Ensemble)
V předminulém článku jsme psali o portletech. Co když ale má zákazník řešení, které se do portálových technologií transformovat nedá (nebo jen za cenu úplného přepsání) - např. v ČR populární řešení psaná v PHP? Pro tyto zákazníky by mohl být řešením Pagelet Producer.
Ten totiž umí vytvořit pagelet, což je kus html kódu, který je pomocí jednoduchého javascriptu možné přidat do jakékoliv stránky. A protože je jedna ukázka mnohem lepší než tisíc slov, podívejte se na to lépe sami - v ukázce vytvoří jednoduchá ADF aplikace a pak se pomocí (v té době ještě) Ensemble přidá do iGoogle gadgets.

WSRP Producer for .NET (dříve též .NET Accelerator)
Z podobného světa je WSRP Producer for .NET. Ten, jednoduše řečeno, umožňuje vyvíjet v .NETu (včetně vývojového IDE Visual Studio); výsledný kód je však možné provozovat v prostředí WebCenter.
Výhodou tohoto přístupu je, že organizace zvyklá vyvíjet v .NETu může využívat další vlastnosti a služby WebCenter Suite, aniž by musela měnit vývojovou platformu.
I pro tuto vlastnost máme k dispozici ukázku.

Business Mashup
I k tomuto tématu existuje ukázka. Business Mashups jsou technologií, která umožňuje využít data z aplikací a prezentovat je v uživatelsky přívětivé formě na portálu. Skládají se ze dvou technologií, tzv. Data Controls, které definují datový zdroj, a Mashups či Taskflows, které definují, jak se bude obsah zobrazovat. Samozřejmě, při zobrazení je možné využít více zdrojů a "promixovat" tak různá data do jednoho výstupu. Navíc toto je možné vše vytvářet za běhu (byť definici data controls stejně většinou provádí vývojář).

WebCenter Analytics
Na rozdíl od předchozích vlastností jsou Analytics určeny hlavně k tomu, aby umožňovaly sledovat nejrůznější statistiky (nejčastěji sledovanost či dobu odezvy), které mohou být nezbytnou částí k dosažení úspěšnosti řešení.

REST API
Poslední vlastností z balíku Anywhere je REST API. To zajišťuje přístup k funkcím velmi efektivním způsobem. Jeho ukázkou je pak aplikace pro iPhone dodávaná přímo Oraclem, ale i pro další zařízení (např. Blackberry) dodávané partnery.

Tímto jsme uzavřeli představování vlastností WebCenter. Suite samozřejmě obsahuje i některé další produkty (UCM, SES), které jsou nutnou součástí pro některé specifické úlohy, a jiné (Weblogic Portal, Aqualogic Interaction), které jsou ve suitě pro zákazníky, kteří již mají tento produkt zakoupený, chtějí jej ještě nějakou dobu provozovat, ale licenčně již chtějí přejít na WebCenter.

Přehled vlastností Oracle WebCenter Suite, část 4.

V dnešním článku se zaměříme na téma, které obvykle posluchače napadne, když slyší o "2.0" tématech - social computing (všimněte si, že až doposud jsme se tomuto tématu věnovali jen okrajově).

WebCenter obsahuje řadu služeb provozovaných v prostředí portálu (samy služby, jak jsme si uvedli minule, jsou často portlety). Pokud zákazníka zajímá výhradně rozšíření možností již existujícího portálu o tyto služby, je možné místo WebCenter Suite pořídit jen produkt zvaný WebCenter Services, který právě tyto služby obsahuje.

Přehled služeb:

• Wiki & Blog: od PS3 se ukládají članky na Wiki a příspěvky do blogů jako dokumenty (html) v UCM. Byl změněn i front-end (WYSIWYG editor).
• Diskuze: (též miniblogs) - krátké příspěvky, zpravidla k danému hlavnímu tématu
• Oznámení (Announcements) - podobná diskuzím - krátké příspěvky; na rozdíl od diskuzních příspěvků však mohou obsahovat datum a čas (např. do kdy jsou aktuální či do kdy je potřeba přečíst)
• Tagy (štítky) - krátké, zpravidla uživatelem či autorem definované, označení subjektu; obdoba klíčových slov, pomáhají při vyhledávání
• Odkazy (Links) - propojení mezi dvěma libovolnými subjekty (diskuzní příspěvek - oznámení, uživatel - dokument apod.), které usnadňuje dohledání souvislostí
• Hlasování - 'Líbí'/'Nelíbí'
• Ankety - volba otázek, časování-cílení ankety, vyhodnocení výsledků
• Sociální sítě (Activity Stream, Activity Graph) - sledování dění v sociální síti (co, kdo, kdy)
• Osobní profil - stránka s nastavením osobních údajů; ty je pak možné využít jako vstup i do aplikací (např. preferovaný jazyk, 'Mám zájem o:', apod.)
• RSS - publikace z často měněných zdroje na internetu (např. titulky novin)

Kromě těchto služeb obsahuje WebCenter i rozhraní na další často využívané služby:

• Mail
• Poznámky (notes)
  
• Kalendář
• Workflow worklist
  

Přehled vlastností Oracle WebCenter Suite, část 3.

Práce s portlety

Od patch setu 3 (PS 3) podporuje WebCenter plně standardy JSR 286 a WSRP 2.0 (normy JSR 168 a WSRP 1.0 byly podporovány již dříve). Portlety je možné vytvářet i konzumovat.
V případě konzumace portletů třetích stran - je možné využívat i vzdálené portlety, viz podpora WSRP - je vzájemné propojení (wiring) těchto portletů do prakticky automatické - portlety přebírají kontext, pouze při výměně událostí je třeba někdy specifikovat zdroj a cíl (což je možné při designu v prostředí JDeveloper, nebo za běhu pomocí Oracle Composer).
Kromě výše zmíněných podporuje WebCenter i standardy JSR 301, JSR 329 (JSF Portlet Bridge for Portlet 1.0 resp. 2.0 Apps).
K portletům na závěr ještě jednu poznámku: většina standardních Web 2.0 služeb (Oznámení, Tagging, Profily, Worklisty ad.) jsou fakticky implementovány jako portlety.

WebCenter Spaces
Spaces jsou hotová portálová aplikace, která je zaměřena na dva scénáře:

• vývojový projekt
• zájmové komunity

(třetím scénářem je pak 'generický scénář', který je možné 'naklikat' do žádané podoby - nevyžaduje však nutně žádný vývoj).
Jako takové nabízejí Spaces všechny výhody portálové aplikace, jak jsme si je uvedli v minulém článku. Oproti dřívějším verzím se od PS 3 jedná zejména o:

• hierarchii stránek spaces vč. navigace
  
• delegovanou administraci a
• zabezpečení na úrovni položky (souboru)

V podstatě se jedná o zjemnění úrovně již dříve přístupných funkcí.

Přehled vlastností Oracle WebCenter Suite, část 2.

V dnešním článku se konečně dostaneme k detailům. Konkrétně výstavbě portálů či aplikací s prvky portálu.

• Tvorba a úprava vzhledu stránek - stránku je možné vytvářet buď v IDE prostředí (JDeveloper aj.) nebo v runtime módu (této vlastnosti se říká Oracle Composer); přičemž v runtime módu je pak možné specifikovat role či skupiny uživatelů, kteří mohou obsah měnit předem definovaným způsobem. Při designu stránek je možné používat tyto komponenty:
• šablony stránek, skins a navigace
• tzv. resources - zdroji může být statický obsah (dokumenty, obrázky, videa - proto je součástí suity ECM úložiště), ale také výstupy či interface aplikací (portlety, vyvíjené aplikace, mashups apod.); portál sám obsahuje také řadu standardních resources, jako je náhled do mailové schránky, workflow task list apod.


• Resource Manager - vzhledem k výše uvedenému je klíčovou komponentou pro dotváření konečného vzhledu zdrojů (a tedy i stránek a celého portálu) manažerská konzole, která umožňuje správci portálu rozhodnout které zdroje a kterým uživatelům dá k dispozici, stejně tak se ale využívá pro podporu iterativního vývoje zdrojů (tj. je možné "poslat zdroj zpět do vývoje").


• Delegovaná administrace - umožňuje rozdělit administraci tak, aby za konkrétní části byly zodpovědní různí lidé - to odpovídá konceptu, že portál představuje tvář celé organizace, je dán jednotný branding, za svoji část jsou však zodpovědná jednotlivá oddělení


• Zobrazení portletů - portál je schopen konzumovat portlety dle standardů JSR 168, JSR 286, WSRP 1.0, WSRP 2.0 a dokonce "portletizovat" zdroje, které neodpovídají žádné specifikaci WSRP (o tomto více v některém z přístích článků)


• Analýzy (návštěvnosti apod.) - pro úspěšný provoz portálu je také nezbytné neustále sledovat, zda je portál navštěvován, popř. které stránky jsou oblíbené a o které naopak není zájem. Za tímto účelem je obsažen modul pro sledování událostí a tvorbu reportů (jedná se o původní modul AquaLogic Analytics, který byl převzat a patřičně upraven).