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.