Přehled vlastností Oracle UCM, část 8.

V dnešním článku zvolna dokončíme přehled vlastností Oracle UCM. Posledním modulem, kterým jsme se doposud nezabývali, je modul Digital Asset Management (DAM), jehož úkolem je správa multimediálních souborů (obrázků a videí. Modul sám má dvě vlastnosti:

• Image Manager
• Video Manager)

Při práci s těmito formáty (k nimž by bylo možné přidat ještě zvukové záznamy) existuje jeden specifický problém: jak správně poskytnout obsah koncovému uživateli.

Tento problém souvisí s velikostí multimediálních souborů a jejich využíváním - v poslední době si např. marketingová oddělení oblíbila možnost tvorby krátkých videí, které představují produkty společnosti. Tato videa jsou nabízena na internetových stránkách a aby si je návštěvník stránek chtěl prohlédnout, musí se stáhnout dostatečně rychle. Na druhou stranu, má-li návštěvník dostatečně rychlé připojení, bylo by škoda mu poskytovat video či obrázky v menších rozlišeních. Zejména u společností nabízející luxusní produkty (nejznámější evropskou referencí na DAM je firma Rolex) musí řešení poskytovat nejvyšší možnou kvalitu, protože nic jiného zákazníci neočekávají.

Oba moduly nabízejí možnost vytvářet ke zdrojovému souboru více rozlišení (např. k fotce ve vysokém rozlišení může existovat menší rozlišení pro web či prezentace, černobílé rozlišení pro tisk na černobílých tiskárnách a thumbnail pro rychlý náhled). Videa je pak možné streamovat.

UCM, ani žádný z jeho modulů, nenabízí konverzi multimédií ani streaming. Dokáže spravovat obsah a při žádosti o jeho poskytnutí jej poskytovat (např.) prostřednictvím streamingového serveru. Tuto funkcionalitu je možné zajistit pomocí komerčních či bezplatných produktů třetích stran (Image Alchemy či ImageMagick pro konverze obrázků, Telestream Flip Factory Index Manager a Flip Factory Publish pro videa).

HowToComponents pro UCM 11g

Tento týden si dáme jako bonus jeden krátký článek navíc. Bex Huff, autor knihy The Definitive Guide to Stellent, spoluautor řady dalších knih na téma ECM a dlouholetý konzultant v oblasti ECM či produktu Stellent, zveřejnil na svých stránkách HowToComponents pro release 11g.

Zejména pro ty z vás, kteří se chystají upravovat GUI, to může být velmi cenný zdroj informací (v ostatních částech "starší" komponenty moc měnit třeba nebylo).

Přehled vlastností Oracle UCM, část 7., pár slov k URM

Dnes budeme pokračovat tam, kde jsme minule skončili. Máme již tedy hotovo:

• odlišení 'records' a 'non-records'
  
• přiřazení dispozičních pravidel

Samozřejmě, jelikož z každého pravidla existují výjimky, nabízí modul records management (RM) způsob, jak se s nimi vyrovnat - takovou výjimkou může být např. vedení soudního procesu, které může být značně nezávislé na skartačních lhůtách a jistě by zákazníka nepotěšilo, kdyby systém uprostřed procesu smazal důležité svědecké důkazy. Tyto výjimky (angl. disposition holds, nebo 'freezes') umožňují vytvořit nad každou položkou jakýsi 'zámek', který ji vyloučí z provedení dispozičních pravidel.

Poslední vlastností, o které se z modulu RM zmíním detailně je audit. Vzhledem k tom, že records management reaguje často na požadavky dané zákonem, nezřídka musí pro případný audit doložit nejen položku a obsah, ale také to, kdo s položkou jak pracoval - včetně seznamu uživatelů, kteří na položku nahlíželi. Samozřejmě, audit v RM je rozšířením standardní funkcionality nabízené Content Trackerem. Jedná se hlavně o tvorbu reportů zaměřených na úlohy spojené s modulem RM.

UCM RM vs URM?
Nyní uděláme malou odbočku na Universal Records Management (URM) - máme-li modul RM v UCM, k čemu ještě potřebujeme produkt Universal Records Management?

1. federovaný records management
URM je schopno provádět centrální nastavení RM politik a díky technologii adaptérů (které je třeba každý zalicencovat!) vynucovat tyto politiky nad řadou úložišť. K dnešnímu dni existují adaptéry pro:

• UCM
• filesystem
• SharePoint
• Documentum
• FileNet
• Symantec Enterprise Vault
• a pak generický adaptér pro .NET a Java umožňující napojení na další úložiště

2. správa fyzického obsahu
URM má také modul pro správu fyzického obsahu. Při práci s fyzickým obsahem (listinné dokumenty či jejich celky jako šanony, ale také fyzická média jako CD-DVD obsahující elektronický obsah, atd.) je třeba podporovat některé další scénáře: obsah je buď 'někde uložen' nebo si jej 'někdo vypůjčil', bylo by vhodné, aby systém uměl sledovat naplněnost skladovacích prostor, atd. Základní myšlenkou je však to, aby hlavní vlastnosti RM, tj. dodržování skartačních lhůt a audit bylo možné nastavit a monitorovat na jediném místě, a to bez ohledu na typ položky.

3. licenční omezení
Aby vše nebylo tak jednoduché, připravil nám product management URM ještě jeden rébus - UCM RM je totiž možné použít v konfiguraci RM modulu 'Minimal' nebo 'Typical'. Bohužel však není nikde specifikováno, které features jsou součástí těchto konfigurací a které nejsou. Věřím, že se jedná zejména o speciální vlastnosti nutné pro DoD certifikace (např. tzv. "klasifikace", což je rozšíření standardních bezpečnostních mechanismů).

V zásadě bych se proto při výběru zda na records management použít URM či jen UCM RM držel hlavně prvních dvou výše zmínených kritérií.

Přehled vlastností Oracle UCM, část 6.

V dnešním článku budeme pokračovat popisem vlastností Oracle UCM a tentokrát se podíváme na oblast, ve které (a asi právem) vládnou určité nejasnosti kolem funkcionality i licencování - records management.

Sám výčet 'vlastností' modulu records management je poměrně strohý:

• records management; to si zaslouží další míru detailu
  
• URM content server adapter; tzn. pokud byste se rozhodli implementovat UCM i URM (k důvodům se také dostaneme - pravděpodobně ve speciálním článku o URM), adaptér, jehož úkolem je napojení URM do UCM a vynucování politik nastavených v URM na úrovni UCM, je součástí licence UCM

Jen pro připomenutí, hlavní požadavky na jakýkoliv ERMS systém jsou dva:

1. zaručit, že položky (na toto téma viz. zde), u kterých je k tomu nějaký důvod (zpravidla zákonný), se nesmažou
2. zaručit, že položky, u kterých k tomu důvod naopak je, se smažou, a to kontrolovaným způsobem dle významu položky

Příkladem z první kategorie mohou být došlé či vydané faktury, které mají skartační lhůtu 10 let; příkladem z druhé kategorie mohou být některé záznamy o zaměstancích, které ze zákona o ochraně osobnosti smí firma držet maximálně 2 roky po rozvázání pracovného poměru; jiným příkladem může být snaha smazat nepotřebný obsah (např. emaily).

V systému, ale vlastně i v metodice, se o splnění těchto požadavků stará spisový plán (angl. file plan či retention schedule), což je hierarchická struktura, zpravidla má podobu stromu, kde je možné uzlům přiřadit různé vlastnosti; zejména pak

• jedná-li se o položky, které nesmí uživatel ad-hoc smazat (viz faktury z našeho příkladu); v UCM/URM je tento požadavek implementován pomocí 3 metadatových 'flagů': isDeletable, isEditable, isRevisionable; mimochodem,všimnětě si, že s 'non-records' položkami je možné pracovat dále jako s živými, tj. vytvářet nové verze, měnit je, dokonce i mazat (v rámci bezpečnostních pravidel), ale přesto je možné na ně aplikovat pravidla jako na 'records'
  
• jaký je životní cyklus položky, resp. jaká dispoziční pravidla se na položku vztahují

Pozn. dispoziční pravidlo je vlastně definicí události a reakce na ni (např. na konci měsíce, v němž vyprší k ukončení pracovní smlouvy se zaměstnancem, počkej 2 roky a pak smaž obsah, včetně metadat). Událostí i možných reakcí je celá řada - události mohou být dané jak časem (př. 10 let po ukončení fiskálního roku), tak nějakou stavovou logikou závislou na vnějších faktorech (př. po dobu 1 roku nikdo položku nepřečetl); reakce pak kromě základních dvou, tj. 'smaž položku i metadata' nebo 'smaž položku, ale ponech metadata', umí pracovat s položkou na mnohem jemnější úrovni metadat či stavů - stavy jako 'Expired', 'Archived', 'Canceled' apod., což se velmi často používá pro přesun položky v rámci fyzického úložiště (s rychlého na pomalý disk či na pásku - samozřejmě, o přesun se stará HSM fyzického úložiště nebo databáze Oracle, nikoliv ERMS). V neposlední řadě je pak třeba zmínit, že jak události, tak reakce mohou být customizovány a že dispozičních pravidel může být přiřazeno hned několik (samozřejmě, každé z nich bude mít trochu jiný úkol - jedno může zaručovat přesun v úložišti, druhé zákonné povinnosti a třetí třeba migraci formátu).

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

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

Vyzbrojeni obecnými informacemi na téma Web Content Management se nyní můžeme podívat detailně na vlastnosti WCM modulu v UCM.

• Site Studio - nejdůležitější prvek modulu WCM. Ve skutečnosti se jedná minimálně o 4 různé přístupy:
  
  • přístup Čtenáře (neuatorizovaného nebo autorizovaného, který toho může vidět víc - zde se využívají principy Zabezpečení)
    
  • přístup Contributora (autor, redaktor apod.), který může modifikovat předem definovaným způsobem obsah stránky
  • přístup Managera Site, který může měnit strukturu site (navigaci apod.)
  • přístup Designera/Vývojáře, který vytváří šablony, resp. layout stránek
    
  
  Pokud jde o konkrétní nástroje, pak první tři role pracují přímo v internet browseru (využívá se hodně javascript, proto si zkontrolujte, jaký typ browseru a v jaké verzi je podporován). Poslední role pak pracuje s vývojovým IDE. Od verze 10gR4 je možné vybrat si ze dvou způsobů:
  
  
  • Site Studio Designer, což je dřívější způsob, kdy šablony vznikají především jako .hcsp soubory a vývojářským jazykem pro vývoj atomických fragmentů je iDocScript. Designer je Windows desktop aplikace.
    
  • Site Studio for External Application (SSXA), což je nový způsob, kdy šablony vznikají jako .jsp(x) a vývojářským jazykem je Java. IDE pro tento způsob je JDeveloper.
    
  
  
• Site Studio Publishing Utility, což je utilita umožňující vypublikovat site navrženou pomocí Site Studia na obyčejný web server (samozřejmě, jen pro čtenáře bez možnosti se autorizovat)
• Content Publisher, technologie umožňující tvorbu site na základě šablon při využítí obsahu jako jsou MS Office ad. formáty (předchůdce Site Studia)
• Connection Server, technologie pro synchronizaci více prostředí. Podporuje tři základní scénáře:
  
  • synchronizaci produkčního a staging prostředí (staging může být vnitřní systém, do kterého píší autoři svoje změny, na kterém probíhá schvalování apod.)
  • podpora push či pull modelu pro synchronizaci mezi Oracle Content Serverem a systémy třetí strany (např. SSXA sites mohou bežet na aplikačním serveru s několika knihovnami pro přístup k obsahu)
  • agregaci obsahu ze starších systémů do Oracle Content Serveru, pokud mají tyto běžet souběžně
    
  
  
• Content Portlet Suite - přístup k funkcím Content Serveru (check-in, vyhledávání, zobrazení obsahu) z portálových prostředí.

Pokud bychom vzali gartnerovký výčet požadavků na WCM (viz minulý článek) a doplnili výše uvedený seznam o funkce Content Serveru a možná Content Tracker, pak na pokrytí celého seznamu zbývá zmínit toto:

1. v rámci definice šablony stránek je možné vytvořit tzv. placeholdery, což jsou části stránky, ve kterých je zobrazován další obsah. Tím mohou být buď webové datové soubory (což jsou specifická XML editovatelná přes WYSIWYG editor), nebo konvertované nativní soubory (MS Office, ale i obrázky či např. flashe). Autor šablony či manažer site pak může omezit takové parametry jako, ze kterých souborů může contributor pro konkrétní placeholder vybírat (kriteria jsou dána přes metadata) či jaký stylesheet je možné užít při finální konverzi (barva nadpisů, velikosti písem apod.)
2. kromě placeholderů mohou být na stránce zobrazeny i statické a dynamické seznamy (seznamem je přehled položek z úložiště podobný seznamu, který se objeví při vyhledávání; statický seznam je dán přesně výčtem, dynamický vzniká jako dotaz na úložiště)
3. WCM také podporuje tvorbu stránek typu formulář, tj. možnost zadat několik vstupních údajů a odeslat je na server (metodou POST); výsledkem je XML obsahující vstupní údaje
4. externí aplikace je možné zobrazovat pomocí iframe
5. všechen obsah, tj. texty, obrázky, videa, ale i šablony stránek, či atomické snippety a pagelety užité v šablonách jsou uloženy jako položky obsahu v úložišti - je na ně tedy možné aplikovat metadata, zabezpečení, workflows, atd.
6. kromě jiného však tento přístup podporuje správu více site či více jazykových verzí (zejména scénář typu: změní-li se obsah na jedné site, propaguj změny do dalších)
   

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

V dnešním článku se vrátíme k výčtu vlastnosti UCM, tentokrát modulu DocumentManagement:

• Content Integration Suite: integrační knihovny pro Java API přístup k funkcím UCM.
  
• Desktop Integration Suite: klientská aplikace (pro MS Windows), která umožňuje (přes WebDAV protokol) přímou integraci desktop aplikací (Word, Excel, Outlook, Windows Explorer, PowerPoint, Lotus Notes, Word Perfect) s UCM. UCM se jeví jako virtuální síťový disk (vyžaduje implementaci Folders)
• Dynamic Converter: ad-hoc konverze nativních souborů do HTML či wireless formátů (WAP apod.). Umí konvertovat 225 souborových formátů - pozor! neplést s perzistentními konverzemi pomocí Conversion Serveru. Dynamic Converter slouží pro jednorázové zobrazení nativního obsahu přes web. Využívá se hojně i při WCM (na různých sites je možné užít různé styly).
• Kofax Release Script - integrace se skenovacími produkty Kofax (integrace se skenovacími produkty Oracle je součástí těchto produktů)
• Content Tracker: komponenta pro sledování přístupu k obsahu - data jsou kumulována v databázové tabulce, nad kterou je možné pouštět standardní či custom reporty
• Content Categorizer: vytěžování metadat z textového obsahu. Content Categorizer umí pracovat buď s exaktními pravidly (prefixy či označení jako style ve Wordu), či heuristikou (dostatečný výskyt klíčových slov v dokumentu). Velmi často se rovněž využívají kategorizační stroje třetích stran, zde je možné kategorizovat i netextové informace. Jak je zřejmé, kategorizace je poměrně výkonostně náročné řešení.
• Report Parser: řešení pro konverzi reportů (myšleno: textových, XML, HTML, či PDF výstupů produktů třetích stran) do web-prohližitelných formátů
• PDF Watermark: přidání watermarků do PDF (buď perzistetních nebo on-the-fly generovaných)
• Web parts for SharePoint: umožňují převézt dokumenty z MSSO do UCM a na úrovni MSSO přistupovat přes portlety ke službám jako je vyhledávání, workflow, apod.
  

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

Vlastnosti modulu Content Server (pokračování):

• Automatické notifikace: umožňuje uživateli resp. administrátorovi zadat kritéria na položky, o jejichž nových verzích chce být uživatel informován. Tento mechanismus je zcela nezávislý na workflows (k zaslání notifikace typicky dochází až po ukončení workflow)
• Folia: folia nabízejí logické groupování ostatních položek. Pokud se někdy pracuje s rozsáhlým objektem (kniha s více autory), mohou folia pomoci s problémem, kdy má jeden z autorů 'zamknut' celý dokument a ostatní nemohou ukládat svoje změny. Obdobně, jindy bývá žádoucí, aby schválením prošlo najednou hned několik položek, které spolu tvoří logický celek (např. dokumentace pro výběrové řízení). Folia také umožňují pohled na celé fólio pomocí tzv. renderers - standardně se dodává ZIPRenderer, PDFRenderer a MSWordRenderer.
• Link Management: Link je vazba mezi dvěma položkami, jejíž interpretace muže být různá. UCM v zásadě nabízí dva typy vazeb: volné (peer-peer, parent-child) nebo těsné (attachments - položka v příloze nemůže existovat bez své 'hlavní' položky). Link management se používá kromě jiného jako prevence HTTP 404 (File Not Found Error)
• Folders: umožňují logické uspořádání (části) do hierarchické struktury připomínající rozvržení dokumentu na disku (zejména, jsou-li na to tak uživatelé zvyklí). Na rozdíl od jiných DMS je toto členění v UCM zcela dobrovolné a pro zákazníky, kteří vyžadují různý pohled na své úložiště je možné použít spíše logické členění pomocí metadat.
• WebDAV: v případě užití Folders, je možné využít k přístupu do úložiště přímo z Office (Lotus Notes či Windows Exploreru) aplikací WebDAV protokol. Podmínkou je nainstalování klientské aplikace Desktop Integration Suite na pracovní stanici koncového uživatele
• Workflows: kolem workflows v UCM panuje spousta nedorozumnění. Workflow představuje obchodní proces (typicky: schvalování, tvorba či zpracování dokumentu), při němž dokument obíhá po organizaci mezi pro daný krok relevantními uživateli. Workflow také podporují stavovou logiku, která zaručí, že položka či verze obíhající ve workflows není k dispozici uživatelům vně workflow. UCM podporuje 2 typy workflow: tzv. nativní, které umí pracovat s jednou položkou, nemají grafické rozhraní, za to však podporují stavovou logiku a možnost 'dopsat si' workflows dle potřeby pomocí jazyka iDocScript. Kromě toho obsahuje licence UCM omezenou licenci na produkt BPEL Process Manager, který umí vytvářet workflows podle standardu BPEL, v grafické prostředí (JDeveloper), za to však bez spolupráce s nativními workflows nedokáže podporovat stavovou logiku.
• Administrace: umožňuje z webového rozhraní administrovat řadu úloh jako: archivace položek do offline archivu, migrace konfigurace, nahlížení do auditních logů, systémové reporty, backup/recovery ad.
• Konfigurace: umožňuje z webového rozhraní nastavovat chování systému, metadatový model, vzhled některých stránek ad.
• Komponenty na míru: toto je jedna z velmi silných vlastností UCM - možnost dotvořit chování systému přesně dle požadavků zákazníka, a to v prostředí, které je na to připraveno.
• User Interface: k službám UCM je možné napřímo přistupovat buď přes webové rozhraní, WebDAV, web sites vytvořených pomocí Site Studia (viz část Web Content Management někdy v budoucnu) nebo z portálových prostředí přes portlety
• Integrace: možnost přistupovat ke službám UCM na pozadí přes: web services (protokol SOAP), Java API (RIDC či CIS/CPS), adaptéry (existují pro integraci se Siebelem, EBS, URM, SES, SAP, ad.), JCR adaptér či REST-like http/s requesty
• Škálování: i při využití clusterování Weblogicu nabídnout zákazníkovi optimální poměr cena/výkon

Tímto jsme zakončili výčet vlastností základního modulu UCM, tzv. Content Serveru. Někdy v budoucnu se budeme věnovat vlastnostem dalších modulů, jako jsou DMS, WCM, DAM, RM.

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

Vlastnosti modulu Content Server:

• Check-in/Check-out: Check-in (vkládání) je událost, při níž dochází k vložení nového dokumentu či nové verze dokumentu. Jejími vstupními parametry je sám soubor a jeho metadata. Operace vkládání je podřízena bezpečnostnímu modelu (jen uživatel s patřičnými oprávněními smí vkládat nové položky určitého typu). Událost vkládání představuje možnost provádět další kontroly (zpravidla pomocí vlastních komponent) a může vyvolat další operace (indexování, konverze, spustit workflow apod.)
  
  Nejčastěji se vkládá jediný soubor. Je však možné i vkládat několik souborů najednou (UCM z nich vytvoří .zip) a nebo mít "hlavní položku" a "přílohy".
  
  Check-out (rezervace) je událost, při které si uživatel (dočasně) rezervuje položku proto, aby mohl vložit novou verzi. Rezervace je zrušena vložením nové verze, na žádost uživatele nebo zásahem administrátora.
  
  
• Verzování: verze je instance položky v čase (metadat i obsahu). Číslo verze je povinným metadatovým atributem položky, který je možné využít v nejrůznějších systémových operacích (např. "uchovávej jen X posledních verzí", "odmigruj starší verze do offline archívu", ale i např. "nedovol více verzí tohoto typu dokumentu"). Velmi často se využívá jen poslední verze - systém však uchovává i ostatní (minulé i budoucí), a to včetně historie.
  
  
• Aktualizuj metadata: umožňuje aktualizovat či doplňovat hodnoty metadatových atributů; často se děje v rámci workflows
  
  
• Diskuze: které umožňují připisovat k položkám perzistentní komentáře, ve kterých je možné vyhledávat, ale nevytvářejí nové verze
  
  
• Zveřejnění/Stažení (Expirace) obsahu: stavově orientovaná logika, která je základním nástrojem pro implementaci životního cyklu položky ("v přípravě" - "aktuální" - "expirovaná" - "smazaná")
  
  
• Indexování: správa fulltextových a metadatových indexů pro rychlejší a funkčně bohatší vyhledávání
  
  
• Zabezpečení: na toto téma seriál příspěvků začínající zde
  
  
• Vyhledávání: schopnost systému přijmout vyhledávací kritéria a vrátit správně naformátovaný seznam položek nebo samu položku (buď tzv. nativní soubor, nebo jeho webově prohližitelnou podobu - vizte Dynamic Convertor, konverze nebo i Digital Asset Management)

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

UCM - Patch Set 3

Podobně jako u Webcentra (viz tento článek; už je též k dispozici) byl pro UCM v nedávných dnech uvolněn ke stažení na OTN Patch Set 3. UCM PS 3 je zaměřen především na opravy chyb v releasu 11g, obsahuje však také některé novinky či drobná vylepšení:

• v komunitě vznikl drobný zmatek, kam se poděla komponenta Collaboration Manager, která je kromě jiného odpovědná za bezpečnostní seznamy přístupů (či ACL, detaily zde). Část funkcionality (collaboration spaces) již nebude dále rozvíjena (je převzato právě WebCentrem), další část (zmíněné ACL) je plně převedena do základní komponenty Content Server
• dalším drobným vylepšením je úprava administrativních interface pro komponentu File Store Provider (které se využívají především při ukládání souborů obsahu do databáze), které nyní při definici tzv. storage rules (definujících přesné umístění v rámci storage) nabízí je relevantní pole
• jednou z největších uživatelských novinek v 11g byly úpravy v aplikaci Desktop Integration Suite; ve starší verzi tato aplikace nefungovala pro 64bitové systémy Windows a MS Office 2010 - nová verze je s nimi již plně kompatibilní
• poslední funkční novinkou PS3 je pak Site Studio Manager, který doplňuje Site Studio for External Applications (SSXA, tj. web content management založený na JSP) o možnost provádět některé úkony (zejména definovat navigaci a rozvržení stránek) přímo z webové prohlížeče
• nakonec je jistě zajímavé zmínit i to, že v blízké budoucnosti vznikne na OTN sada příkladů pro SSXA, na kterých si bude možné zjistit, jak podobnou funkcionalitu dodat do vlastních sites
  

Přehled vlastností Oracle UCM, část 1.

Předmětem tohoto seriálu článků bude téma, které se objevuje v požadavcích poměrně často: tak nám řekněte, co to vaše řešení vlastně všechno umí. Osobně mám s tímto požadavkem "výčtu fíčurek" docela problém - jednak asi neexistuje člověk, který by dokázal vyjmenovat všechno; hlavně mám ale zkušenost, že otázka je velmi často účelově zneužívána, aby si adresát našel něco, na čem nás nakonec potopí (bez ohledu na to, že to nejspíš jen nebylo zmíněno, nebo se to dá udělat zpravidla jinak a nebo to vůbec nebude potřeba).

V poslední době jsem však našel jeden důvod, který vytvoření takovéhoto seznamu přinejmenším ospravedlňuje: řada našich partnerů, zejména z oblasti spisových služeb, má produkty, jejichž funkcionalita se částečně překrývá s UCM. Seznam vlastností, např. při implementaci konceptu spisová služba s UCM jako úložištěm, by jim umožnil vybrat si co chtějí z UCM využít.

Jak seznam číst? Rozhodně nikoliv jako kompletní přehled - jedná se spíše o přehled na úrovni modulů a jejich nejdůležitějších vlastností, který má sloužit k základní orientaci.

Seznam vznikl s velkou pomocí dokumentu vytvořeného Consulting Services (kupodivu, nikoliv, Project Managementem) a do značné míry kopíruje dřívější členění dokumentace (např. zde); rovněž vám může pomoci pochopit některé body z licenčních dokumentů (jako např. eSupplement). Základní členění obsahu licence Universal Content Management je toto:

• produkt Universal Content Management obsahuje
• modul Content Server
• modul Document Management
  
• modul Web Content Management
• modul Digital Asset Management
• modul Records Management
• produkt JRockit - což je "celosvětově nejrychlejší Java Virtual Machine (UCM je Java aplikace) dle benchmarků jako např. SPECjbb2005"
• produkt Content Conversion Server
• omezená licence na produkt BPEL Process Manager - detaily na toto téma vizte v tomto článku
  
• omezená licence na produkt Weblogic Enterprise Edition - více zde

Modulům UCM a krátce i Content Conversion Serveru se budeme věnovat v dalších dílech detailněji.

Deployment aplikace Site Studio for External Applications

Vraťme se naposledy k problematice WCM v releasu 11g. V minulých článcích jsme si postupně představili základní koncepty a změny oproti 10g (užití JSP a Jdeveloperu jako IDE). Jak se ale bude chovat aplikace v produkčním prostředí?

Odpověď je, možná, nepřekvapující: jako J2EE aplikace

Aplikace se na aplikační server dodává v .EAR souboru, který má tuto strukturu:

+ -- My Application.ear
+ -- MySites.war
+ -- adf/META-INF/
+ -- connections.xml
+ -- META-INF/
+ application.xml
+ weblogic-application.xml


MySites.war obsahuje reference na jeden content server a sites (které jsou uloženy na něm jako obsahové položky, tj. soubory .xml; jinak je najdete podle kritéria "WebSiteObject matches Project")
connections.xml obsahuje odkaz na URL Content Serveru, který obsahuje užité položky obsahu (dokumenty, obrázky, multimédia); bez autentizace je možné přistupovat jen na položky z bezp. skupiny 'Public', které jsou navíc přiřazeny danému site (při výběrech)
weblogic-application.xml obsahuje odkazy na sdílené knihovny Site Studia (a RIDC) na daném Weblogic serveru

Soubor MySites.war má pak tuto strukturu:

+ -- MySites.war
+ -- wcm/templates/
+ -- WEB-INF/
+ web.xml
+ wcm-config.xml
+ weblogic.xml

/templates/ je adresář obsahující všechny JSP/JSPX registrované ve wcm-config.xml
wcm-config.xml je hlavní konfigurační soubor pro Site Studio
weblogic.xml obsahuje reference na sdílené WAR knihovny Site Studia
web.xml je standardní konfigurační soubor pro J2EE aplikace

Jak je vidět z popisu, v architektuře existují 2 servery, aplikační server, který provozuje WCM aplikaci (a má k dispozici některé knihovny) a UCM server, který slouží čistě jako poskytovatel obsahu. I toto je vlastně změna oproti 10g, kdy se UCM server "staral o všechno". Bohužel, i kdyby se jednalo o skutečně dva různé servery, neplatí, že na provozním aplikačním serveru nemusí být licence UCM - vzhledem k instalaci knihoven musí být i tento server licencován pro UCM. Na druhé straně je ale možné využít mechanismus cachování obsahu na provozním aplikačním serveru, čímž je možné dále optimalizovat jak rychlost odezvy, tak zátěž poskytovatele obsahu.
A stále pak existuje možnost vypublikovat statické stránky (což se často využívá u internetových stránek, kde žádná autorizace uživatele pro přístup k dalším sekcím nedává smysl) na web server, kde samozřejmě žádné licence potřeba nejsou.

Dekompozice stránky ve WCM - odshora dolů (část 2.)

Schéma "prostřední" části definice stránky, tj. placeholderů a regionů, je opět nejlépe možné pochopit ze schématu:

Pokud budeme prozatím ignorovat nejnižší vrstvu, tj. elementy, a ponecháme stranou i subtemplates, zbydou nám 4 vzájemně úzce spojené objekty. Přibližme si je nejprve opět pomocí dalšího schématu:


Nejjednodušším objektem je placeholder. Vytváří se na úrovni stránky (tj. její šablony) buď přetažením příslušné ikony do designu stránky, nebo přidáním takovéhoto kódu:

Ke každému placeholderu musí existovat tři další objekty. Jeden, placeholder definition, určuje, jaké operace bude možné s daným placeholderem v přispěvovatelském módu provádět:


Druhým je pak Region Definition, která definuje "obsah" příslušného regionu - v našem příkladě z druhého obrázku má region 5 oblastí: Title, Subtitle, Intro Text, Body Text a Image. Na následujícím obrázku bude příklad regionu se dvěma oblastmi (elementy).


Aby to celé mohlo fungovat, je ještě nezbytné, aby bylo určeno, které oblasti regionu a v jaké podobě budou uživateli zobrazeny. K tomu pak slouží poslední objekt, Region Template, což je opět JSP definující podobu výstupu (při jeho definici je možné použít subtemplates, které opět mohou obsahovat další placeholdery).

Jak je také vidět z druhého obrázku, je teoreticky možné, že by k jedné existovalo více zobrazovacích šablon. V rámci definice definici placeholderu se pak určuje, která z nich se v dané situaci použije.

Poslední nutný link, mezi placeholderem a jeho definicí, se poněkud nelogicky provádí na úrovni site (tam, kde se příslušným stránkám přiřazují jejich primární a sekundární šablony), a to pomocí tlačítka s názvem Placeholder Definition Mappings.

Pro srovnání: dříve se v aplikaci SiteStudio prováděly všechny tyto operace na jednom místě. To je zřejmě daň za rozdělení formy (JSP) a pravidel chování/mapování mezi objekty (což je v podstatě XML).

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

Dekompozice stránky ve WCM - odshora dolů (část 1.)

Podívejme se nyní trochu detailněji na to, z čeho se skládá stránka, resp. její šablona (Page Template)



Jak je vidět, šablona stránky se kromě statického textu (který většinou bývá minimální) skládá z tzv.

• fragmentů, což jsou menší znovupoužitelné celky, které podobně jako šablona stránky definují "šablonu" pro nějakou konkrétní část stránky (viz příklad: fragment pro navigaci či footer stránky)
• regionů, reprezentovaných placeholdery, kterým je naopak možné přiřadit obsah z úložiště, resp. tento v nich aktualizovat
• kromě těchto dvou konceptů je možné v definici stránky využít i obsah spravovaný třetí stranou; často se jedná o reklamní bannery či výstupy webových aplikací. Pro tento typ zadání se používá HTML tag iframe. WCM však v tomto případě nemá žádnou kontrolu nad obsahem. Pokud by byla kontrola vyžadována, je možné použít technologii mashup, která je k dispozici v rámci produktu WebCenter.

Co je v release 11g nového, je to, že šablony stránek či fragmentů je možné nyní psát také pomocí notace JSP (v 10g to bylo možné výhradně pomocí proprietárního jazyka iDocScript). Vývojovým nástrojem pro psaní (či grafický design pomocí drag&drop) je nástroj JDeveloper. "Starý" způsob přes iDocScript se ani náhodou neruší. Naopak, produkt management do budoucna slibuje, že způsobů, pomocí kterých bude možné šablony vytvářet, bude neustále přibývat. Tak uvidíme...

Primární a sekundární stránky
Aby se snížil počet vytvářených šablon, nabízí WCM (i v 10g) koncept tzv. primárních a sekundárních stránek.
Primární stránka je definice stránky tak, jak ji návštěvník vidí, když se na stránku dívá poprvé. Obsah (tj. i provázání na položky, které vyplňují jednotlivé regiony) je na ní definován staticky. Představme si ovšem, že obsah přestavuje výpis odkazů na dokumenty dle určitého kritéria, např. tisková prohlášení (pozor! Nenechte se zmást - statická je zde definice dotazu, seznam se samozřejmě bude dynamicky měnit podle aktuálního obsahu úložiště). Nyní bychom ale chtěli na jeden klik zobrazit obsah jednotlivých dokumentů.
A přesně k tomuto jsou určeny sekundární stránky, které provádějí provázání dynamicky, a to až v okamžiku kliknutí na příslušný odkaz.
Bývá dobrou praxí, že primární a sekundární stránky využívají stejnou, nebo alespoň podobnou šablonu (v našem příkladu bychom nejspíš chtěli, aby sekundární stránka obsahovala přinejmenším sekce Banner Image, Side Nav Fragment a Footer Fragment).

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

Koncept oddělení formy a obsahu webových stránek v Oracle UCM

Chtěl bych věnovat několik článků oblasti Web Content Managementu, který je v release 11g jednou z hlavních novinek - a od předchozího release je zde opravdový posun vpřed.

Abychom se mohli věnovat detailům, je nejprve třeba vysvětlit některé základní koncepty, které jsou vlastně stejné už po několik let, ale které je nyní možné využít ještě s větší efektivitou.

Prvním z nich je oddělení formy a obsahu, které ve svém důsledku znamená oddělení rolí při správě webového obsahu:

• designer/vývojář, se starají o formu stránek
• přispěvovatelé, se starají o obsah

Vše bude více evidentní z následujícího obrázku:


Jak je vidět, šablona stránky (kromě jiného) obsahuje tzv. regiony, což je oblast, do které designer/vývojář stránek dovoluje přiřadit obsah. Samotný region je opět možné dál rozdělit na tzv. elementy (v uvedeném příkladě má region tři části: nadpis, podtitulek a vlastní text) a těmto elementům je pak možné přidělit obsah, což je ve skutečnosti položka obsahu z úložiště.

Co vše může být obsahem, který je možné přiřadit k elementu?

• contributor data files - jednoduchá XML obsahující krátké texty; tyto texty je možné editovat v rámci WYSIWYG editoru přímo na stránkách
• native files - v podstatě jakýkoliv "dokument", který je možné konvertovat do HTML. Konverze probíhá (zpravidla) online a využívá se při ní DynamicConverter. Tyto soubory je možné editovat ve svých nativních aplikacích (MS Word, Excel, atp.)
• obrázky a další multimediální obsah (např. Flash animace, videa apod.) - i pro tento obsah se velmi často využívají nejrůznější konverze či streaming. Pro tyto konverze se využívá modul Digital Assets Management.

(pokračování někdy v budoucnu)

Odkaz na popis procesu upgrade z 10g na 11g

Ještě krátká informace ke článku z minulého týdne: guideline pro upgrade z verze 10g na 11g je k dispozici na tomto linku http://download.oracle.com/docs/cd/E14571_01/doc.1111/e16451/toc.htm

Ukládání nestrukturovaného obsahu do databáze

V dnešním článku se pokusím zaměřit na téma, o kterém stále koluje řada dezinformací. Protože se budu pouštět spíše na led databázistů (dokonce nejen oraclovských), dovoluji si požádat o benevolenci při technických detailech - v hlavních argumentech bych se ale plést neměl.

Jak je to tedy s tím ukládáním do databáze:
- první nezvratné tvrzení je, že je to možné, a to jak pro databáze Oracle (min. od verze 10g), tak pro Microsoft SQL Server (podle informací, které jsem našel, nejspíš od verze MS SQL 2005)
- druhé tvrzení je, že UCM 11g je certifikováno na oba výše zmíněné databázové servery. Ukládání se však neděje přímo do databáze, ale přes jakési dočasné úložiště na filesystému, a to pomocí komponent FileStore Provider (což jsou jakési speciální adaptéry, které umí ukládat obsah prakticky kamkoliv). Důvodem pro meziúložiště je to, že některé části systému (např. konverzní server) zatím neumí pracovat s ničím jiným, než soubory na disku
- třetí tvrzení je, že ukládání do databáze je pomalejší a méně efektivní (o režii, kterou databáze má). Nevím jak pro Microsoft, ale pro Oracle toto tvrzení (pro některé typy úloh) již neplatí. Od verze 11g obsahuje databáze technologii SecureFiles, která je optimalizovaná takovým způsobem, že
a) dokáže "mnoho malých souboru" načítat v dávce tak, že dokonce porazí ve výkonu filesystem. Toto řešení bylo optimalizováno především na ukládání emailů, což jsou velmi často poměrně krátké zprávy.
b) dokáže nad ukládáným obsahem provozovat kompresi, deduplikaci a šifrování, takže dokáže na některých operacích "ušetřit"
- čtvrtým tvrzením je, že pro mnohé ECM projekty je ukládání souborů do databáze sňatkem z rozumu. Kvůli metadatům je databáze tak jako tak nutnou částí projektu, takže možností ukládat i nestrukturovaná data je možné jednou ranou vyřešit zálohování/obnovy, disaster recovery scénáře a v konečném důsledku mít jednoho administrátora na všechno. Při využití vhodném využití technologií jako je partitioning, je možné jeden velký soubor rozdělit na přijatelné množství (vyhnout se druhému extrému: spoustu malých souborů) - byť vybrat vhodné kritérium pro partitioning může být u obecných dokumentových projektů poměrně obtížné. A v neposlední řadě je možné využít Automatic Storage Management, který se na základě metadat (UCM) postará o uložení na správné médium (HW) v rámci životního cyklu informace (ILC).

Upgrade z verze UCM 10g na verzi 11g

Byť je to zřejmě ještě trochu předčasné, pokusme se zastavit nad tím, co by se muselo stát, aby se zákazník provozující verzi 10g zupgradoval na 11g.

Nejprve si položme otázku, co vlastně představuje běžící řešení (toto je poměrně obecná úvaha, která se ani zdaleka netýká jen Oracle UCM): řešení beží na nějakém hardware, na kterém je nainstalován nějaký běžící kód (software), další důležitou částí je pak konfigurace řešení a nakonec v tom celém jsou uložena nějaká data. Software bychom si pak mohli ještě rozdělit na standardní programy (např. balíková řešení, ale i třeba operační systém) a specifické programy (customizace - v UCM jsou to komponenty vyvíjené na míru potřebám konkrétního klienta).

Těchto pět částí, tj. hardware, standardní software, specifický software, konfigurace a data, představuje problém, se kterým se musíme vypořádat při upgradech, ale i třeba při budování záložního řešení, či obnově při výpadku.

a) hardware
Je smutnou pravdou, že při aktualizaci software, zejména jedná-li se o aktualizaci generační, bývá zpravidla nezbytné plně zaměnit hardware. Navíc vzhledem k tomu, že velmi často je prostě technicky nemožné "otočením klíčku" jedno řešení nahradit druhým, bývá nutné, aby po nějakou dobu běžela "staré" a "nové" řešení paralelně vedle sebe. Dnes může být řešením aplikační grid (či přímo "cloud"), pro zákazníky se skromnější infrastrukturou mohou vypomoci testovací či školící prostředí. S jistou mírou redundance je však třeba počítat vždy.

b) standardní software
Je-li řešení psáno jako vícevrstvé a dovolí-li to nároky na výkon a na bezpečnost, je možné při upgrade dosáhnout jisté synergie. Bohužel, díky zásadním změnám v architektuře mezi verzemi 10g a 11g existují v podstatě jen dvě komponenty, které jsou oběma společné - databáze a LDAP.

c) specifický software (v UCM custom komponenty)
Toto je samozřejmě šedá množina, o které se a priori nedá říct nic, než že je vše potřeba řádně otestovat, popř. opravit. V UCM je výhoda, že oba releases jsou minimálně psané v Javě, která je (teoreticky) plně přenositelná. Většina komponent je proto buď rovnou přenositelná nebo vyžaduje jen drobné úpravy. Existují výjimky, které se týkají změn v architektuře. Hlavní body jsou popsány v tomto příspěvku na fóru.
V ČR je využití custom komponent (s výjimkou jediného projektu, který je však ještě na starší verzi Stellentu) zatím minimální. Proto by s tímto bodem neměly být problémy.

d) konfigurace
Problém přenosu či uchování konfigurace se týká samozřejmě i např. přenosu mezi testovacími a produkčními prostředími. V UCM je k tomuto účelu určena komponenta Configuration Migration Utility (CMU), která umí exportovat či importovat většinu standardní konfigurace. Výjimku tvoří nastavení vytvořená v .cfg souborech (které je možné přenést jako takové) a pak konfigurace vytvořená pomocí některých komponent (např. i Folders; tj. definice hierarchie virtuálních adresářů).

e) data
I pro data, tj. vložené dokumenty a jejich metadata, existuje administrační aplikace zvaná Archiver. Původní využití této aplikace, jak možná napovídá název, bylo pro ukládání starších dokumentů do offline archivu. Již za časů Stellentu se však aplikace začala využívat i pro synchronizaci obsahu mezi servery, tedy potenciálně i pro migrace z jedné verze na další. V některých specifických případech (např. aktualizace metadat) je možné aplikaci využít i pro export a import dat ze stejného systému.

Pro verzi 11gR2 již existují specifikace, jak různé nástroje pro migraci konfigurace a dat sjednotit do jedné aplikace; rovněž bude implementována mnohem rozsáhlejší podpora pro hromadné operace nad více dokumenty.

Uživatelské účty a role v UCM

V poslední době se objevilo několik otázek na téma uživatelských účtů (v UCM 11g manuálu je užit termín "login") a rolí. Jak jsme psali v tomto článku, je mezi verzemi 10g a 11g určitý rozdíl. Pojďme se však na celou problematiku podívat detailně.

Typově nejstarší jsou tzv. lokální uživatelé. Jedná se o uživatele definované v interní databázi content serveru (tabulka Users) a k jejich správě se užívá administrátorský applet UserAdmin.
Ve stejné aplikaci jsou pak vytvářeny, administrovány (tabulka RoleDefinition) a přiřazovány (tabulka UserSecurityAttributes) jejich role. Vztah mezi uživateli, rolemi a metadaty dokumentů je vysvětlen v tomto článku.
Pro každého nově vytvořeného uživatele se automaticky přiřazuje role guest, která jej opravňuje ke čtení veřejných dokumentů (tj. těch klasifikovaných do bezpečnostní skupiny Public).

Obdobou lokálních jsou tzv. globální uživatelé. Liší se pouze tím, že globální uživatelé slouží k přístupu na několik content serverů najednou - což se velmi často využívá (či spíše využívalo) při clusterovém řešení. Pro globální uživatele je vždy jeden server 'master' a ostatní si identitu uživatelů přebírají z něj.

Naopak poslední typ, tj. externí uživatelé, se plně přebírá odjinud - možnostmi jsou Windows Doména, Active Directory či LDAP Server. Jakkoli se data o externích uživatelích ukládají do databáze, samotného uživatele a jak nedávno všiml jeden z partnerů (podobně jako autor této otázky na fóru Oracle UCM) přiřazení rolí takovýmto uživatelům není možné v rámci appletu UserAdmin administrovat.

Ještě k vzájemnému vztahu obou světů: při autentikaci uživatele se nejprve prověřují externí a teprve následně lokální či globální uživatelé. Externí uživatelé tedy "mají přednost".

Nyní, vše výše uvedené platí pro svět 10g. V 11g se pracuje prakticky výhradně s externími uživateli. Release sice stále obsahuje UserAdmin a jednoho definovaného lokálního uživatele, ten je však využit výhradně pro přihlášení k administrátorským aplikacím jako SystemProperties ve stand-alone módu.

Dalším rozdílem oproti 10g je, že 11g běží na WebLogic Serveru (WLS), který obsahuje tzv. Embedded LDAP Server (více na toto téma zde), který je alternativně možné využít pro menší instalace (uvádí se do 10 000 uživatelských účtů). Tento server se spravuje pomocí administrátorské konzole Enterprise Manager for FMW Control. V případě využití jiného LDAP serveru se pak doporučuje integrovat LDAP spíše na úrovni WLS než UCM - důvody jsou jednak výkon, jednak možnost využít uživatelské identity pro ostatní FMW produkty, než jen pro samotné UCM.

Na závěr k využití LDAP ještě poznamenejme, že u tohoto řešení jsou uživatelská hesla mimo UCM a kromě uživatelů a rolí je možné LDAP využít ještě na další objekty - velmi často se z LDAP přebírají účty (bezpečnostní mechanismus mající hierarchickou strukturu často vycházející z hierarchie organizace, popsáno zde).

Přenositelnost komponent do 11g

Pokud bychom se podívali detailně na problém přenositelnosti komponent speciálně optikou releasu 11g, pak zjistíme přibližně toto:

• pro Custom Components budete stále využívat Component Wizard nebo link Component Manager v části Admin Server
• kromě faktu, že komponenty nově běží v prostředí WLS, je třeba se vyrovnat i s jistou "restrukturalizací" instalace. Zatímco dříve byly všechny soubory instalovány (pro jednu instanci content serveru) do jednoho adresáře, v 11g existuje "obecný ECM adresář" (na mé instalaci to bylo C:\Oracle\Middleware\Oracle_ECM1\ucm) a pak jednotlivé adresáře pro instance (např. C:\Oracle\ucm_instances\ecm1\ucm).
  
• pokud budete hledat standardní zdroje (např. std_page obsahující většinu includes), určitě je hledejte v "obecném" adresáři. Možná se pak bude hodit i informace, že na rozdíl od starších releasů, kdy byly všechny zdroje v souborech s příponami .htm, maximálně .hda, nyní již tomu tak být nemusí - např. zmíněný soubor std_page má příponu .idoc, zdroje obsahující překlady v komponentě Localization pak příponu .xlf apod.
• ze změn souvisejících s přechodem na WLS pak připomeňme vše týkající se administrace uživatelů (která je nově zcela v režii WLS)
• některé komponenty pak byly v 11g zcela přepsány. Jedná se zejména o Folia a FileStoreProvider (komponentu, která má na starosti zápis dokumentů do fyzického úložiště - tyto změny jsou důvodem výrazného zrychlení zápisu na disk či do databáze)
• kromě celých komponent pak byly ještě přepsány některé jednotlivé služby. Jejich seznam najdete zde.

Vzhledem k projektům implementovaným v České republice věřím, že se tyto změny nikoho nedoktnou. Berte proto prosím tento článek spíše jako dokreslení, jak složité (či jednoduché) může být udržování komponent, o kterém jsme psali minule. Ostatně, dá se očekávat, že při upgrade na 11gR2 už bude komponent, které bude třeba oprášit, více, protože řada implementovaných customizací se týkala GUI, které bude podle všeho značně pozměněno.

Přenositelnost komponent, možnosti vzájemných kolizí

Pokud se pustíte do vývoje vlastních komponent v UCM, měli byste pamatovat, že tato jistě bohulibá činnost v sobě skrývá 2 úskalí:

• problém přenositelnosti, tj. zajištění, že komponenta fungující ve verzi n bude fungovat i ve verzi n+1
• problém možného konfliktu mezi komponentami (dvě či více komponent spolu nemohou fungovat najednou na jednom systému)
  

Konflikty
Jak může dojít ke konfliktu? Nejčastějším důvodem je přepsání standardní služby, které je sice kompatibilní se základním content serverem, ale není kompatibilní s jinou custom service. V 10g byly takovým příkladem modul Records Management a UCM adaptér pro URM - systém tedy mohl buď sám poskytovat records management funkce a nebo mohl být klientem pro URM, nikoliv však obojí najednou. V 11g je tento konflikt již vyřešen (UCM modul byl přepsán tak, že nabízí URM kód).
Mechanismem pro řešení případných konfliktů je loadOrder, což je hodnota, která je povinným parametrem každého zdroje. Content Server nahrává zdroje podle jejich hodnoty loadOrder (vyšší později) - pokud tedy chcete mít jistotu, že bude váš kód užit, nastavte tuto hodnotu na dostatečně vysokou hodnotu (obvykle stačí tak 100).
Dalším pomocníkem může být mechanismus dědičnosti. Byť to není (možná bohužel) nezbytné, jak iDocScript, tak Java umožňují nejen zcela předefinovat chování služby, ale při psaní využít i existující kód, který se tak ve vhodný okamžik převolává. Užitím dědičnosti se výrazně snižuje riziko konfliktů i podporuje přenositelnost.

Přenositelnost
U nekonfliktních komponent je riziko problémů při migraci na další verzi minimální. Přesto existuje a občas bude třeba do kódu sáhnout. Jedním z takových příkladů byl například přechod z verze 7.5 (ještě Stellent) na 10g (již Oracle), kde došlo k zásahům do GUI (místo combo boxu nabízejícího funkce proveditelné nad položkou byly tyto rozdistribuovány do jakési lišty na hodním menu - starší komponenty, které "natvrdo" přidávaly své funkce na známé místo na to samozřejmě nebyly připraveny).
Tím, že je 11gR1 velmi podobný (snad s výjimkou práce s uživatelskými účty) starší verzi, dá se předpokládat, že by tyto verze neměly mít na úrovni komponent vážné problémy.