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ě)