UCM 11g, 3. část: Změny v GUI

Pokud se poprvé přihlásíte do webového rozhraní UCM 11g, zjistíte - že je skoro stejné jako UCM 10g. To je na jednu stranu dobře, protože není problém se v něm okamžitě vyznat - na druhou stranu by člověk po 3 letech přeci jen čekal nějaký posun. Release 11gR1 tyto změny bohužel nepřináší (na rozdíl např. od I/PM 11g) a budeme si na ně muset počkat nejméně do 11gR2. Ono je to ale na druhou stranu pochopitelné - UCM se čím dál víc posouvá do pozice backend systému a zejména díky produktu WebCenter, s nímž je velmi úzce spojeno, pak potřeby na úpravy GUI jsou potlačeny do pozadí.

Release 11gR1 přesto přináší změny v GUI, a to tam, kde se nejvíce dostává do kontaktu s koncovými uživateli - v komponentě Desktop Integration Suite (která se stará o přístup do úložiště z desktop aplikací jako jsou aplikace balíku MS Office, ale také např. z Lotus Notes či Windows Exploreru). Zásadní novinkou je možnost přímo z těchto aplikací vkládat dokumenty s pomocí profilů:

Dřívější způsob, tj. vydefinovat metadata na úrovni adresáře a vložit dokument "bez ohledu na metadata" zůstal zachován, takže je opravdu jen a jen na uživateli, který způsob mu bude bližší.
Kromě této změny upravuje Desktop Integration Suite ještě rozhraní pro Windows Explorer, a to tak, že umožňuje přímý přístup na položky ve workflow resp. na vložené dotazy - jinými slovy nabízí základní vyhledávání a práci s workflows přímo z Exploreru.

Další skupinou, kterou 11gR1 potěší, jsou administrátoři. V čem se produkt výrazně posunul, že místo nastavení rozmístěných na zanořených stránkách, nabízí jakési "standardní konfigurace", které může administrátor jednoduše zapnout a o víc se nestarat. Jako příklad si uveďme Records Management nebo komponenty - u těch navíc platí, že všechny komponenty podporované Oraclem jsou automaticky nainstalovány a administrátor jen řekne, o které případně má či nemá zájem. Pro custom komponenty je stále možné využít Component Wizard.

UCM 11g, 2. část: škálování a výkon

Minulý článek jsme zakončili tvrzením, že jedním z největším přínosů verze 11g je velký posun ve výkonu a možnostech škálování celého řešení.

Co se tím přesně míní? Pro výkon ECM řešení jsou důležité především 2 operace:

• vkládání nového obsahu
• schopnost zobrazit požadovaný obsah

Při vkládání je výzvou zejména jednorázové vkládání mnoha, relativně krátkých položek, které je třeba stejně rychle dát k dispozici uživatelům (opačný extrém, tj. vkládání velkých položek se moc optimalizovat nedá, protože závisí primárně na průtoku sítě). Typickým případem ze skutečného života může být zpracování emailů či např. vydaných faktur (na toto téma např. tento článek).
Pro poskytování obsahu je náročné zvládnout zejména scénář obsluhy dynamických webových stránek pro velkou komunitu uživatelů (public web).

Detailní výsledky je možné najít v tomto dokumentu a jsou skutečně impozantní. Např. na poměrně běžném hardware (2 CPU 2.33 GHz Xenon, 16 GB RAM) dosahuje UCM 11g pro soubory o velikostech 4-200 kB rychlosti vkládání 270, resp. 128 souborů za sekundu, to je 11-23 miliónů dokumentů denně na jednom uzlu UCM 11g!

Čím jsou takové rychlosti dosahovány? Hlavními přispěvovateli jsou databáze Oracle 11g (zejména technologie Oracle SecureFiles) a pak Fast Checkin mechanismus UCM, který umožňuje některé generické funkce (konverze, zahájení workflow, indexace na fulltextové vyhledávání) vypínat pro ty dokumenty, pro které to nemá smysl - např. TIFF vytvořený skenovací linkou nemá smysl ani konvertovat, ani indexovat.

A pokud by Vám dosahované hodnoty stále nestačily, je možné nasadit Sun Oracle Database Machine (Exadatu), na které je možné se dobrat až takových hodnot jako 1060 dok./sec (91 mil. denně) na 1/4 Exadaty, resp. 2070 dok./sec (179 mil. denně) na 1/2 Exadaty - testy byly prováděny se 100kB soubory.

Při poskytování webového obsahu se plně využívá Weblogic Server. Technologie "Open WCM" využívá tzv. smart caching - tj. webový objekt je z UCM přenesen přímo na Weblogic Server, kde setrvává, dokud jej UCM neprohlásí za neplatný. V jiném modelu je možné proaktivně vyspecifikovat, které objekty se takto mají cachovat přímo v rámci implementace site.
Tyto mechanismy lze ještě doplnit o cachování na proxy, kde se ukládají celé stránky.
V testech se kombinací dosahovalo výsledků až 124 stránek za sekundu (na komoditním hardware).

Při škálování, čímž se zde míní provozování na více uzlech clusteru, je pak žádoucí, aby režie clusteru byla co nejnižší, tj. aby byla investice do dalšího hardware co nejvíce využita. V tomto ohledu dokument příliš specifický není - jen zmiňuje, že UCM 11g dosahuje průměrného poměru kolem 95% (tj. 5% výkonu je spotřebováno režií clusteru). Zde záleží především na výběru operačního systému - pro Windows je režie větší, např. pro 128 uzlů Solaris byla režie jen kolem 2%.

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

UCM 11g, 1. část: změny v architektuře a jejich dopad

První a velkou změnou v UCM 11g je přebudování celé aplikace tak, že se (na rozdíl od 10g) jedná o J2EE aplikaci. Pro její běh je tudíž třeba aplikační server - v 11gR1 musí být tímto serverem Weblogic Server; v dalších releasech je očekávána i verze pro další aplikační servery (prozatím se mluví o Websphere a JBossu).

Pokud si stáhnete instalační balík na tomto linku a nahlédnete do dokumentace (nejlépe např. Quick Installation Guide), zjistíte, že instalační proces je na první pohled výrazně složitější. Např. datové schéma se vytváří pomocí aplikace RCU (Repository Creation Utility) a vlastní instalace pak jako deployment J2EE aplikace do prostředí Weblogic. Ve skutečnosti však šlo o to, aby se instalace všech produktů z balíku ECM prováděla více-méně stejně, a to i z důvodu následné vzájemné provázanosti těchto produktů mezi sebou, která už je prakticky bez jakéhokoliv dalšího úsilí.

Dalším důsledkem přechodu na Weblogic (resp. aplikační server) jsou dopady na správu uživatelů. Jakkoli stále ještě najdeme v administraci známý User Administration applet, uživatelé zde vytvoření (dříve se nazývali lokální) již nebudou mít do systému právo přístupu. Jedinou výjimkou (kvůli které je ještě tento artefakt zachován) jsou některé standalone aplikace (System Properties, Component Wizard), kam se stále přihlašuje "postaru" - i to ale časem zmizí a pak už všichni uživatelé budou výhradně externí, tj. definováni v LDAP resp. v security realmu aplikačního serveru. Hlavní výhodou je konsolidace správy uživatelů a mnohem lepší podpora standardních mechanismů jako Single Sign-On, správa webových služeb, jejich zabezpečení (standard SAML) apod.

Přechodem na Weblogic pak UCM také automaticky získává silný nástroj pro správu zdrojů, Enterprise Manager, ve kterém je zároveň možné sledovat vytížení, predikovat případné problémy s výkonem či dostupností, konfigurovat recovery management a v neposlední řadě tvořit nejrůznější reporty. Starý nástroj, Admin Server, zůstává (už není třeba jej startovat explicitně od Content Serveru), ale slouží výhradně pro správu UCM-specific úloh (správu komponent, editaci config souborů apod.)

Nejdůležitějším dopadem přechodu na Weblogic jsou však dopady na výkon a potenciál pro škálování celého řešení.

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

Verze UCM 11g je venku!

Tento týden došlo konečně k uvolnění informačního embarga na oznámení o existenci verze 11g - konkrétně se týká o produkty

• Universal Content Management
• Universal Records Management

(pro Imaging and Process Management je verze 11g k dispozici už od začátku kalendářního roku)

Pokud byste měli zájem o informace z první ruky, registrujte se na webcast, který bude zítra 10.6.2010 ve 20 hodin na tomto linku.

Jinak budeme samozřejmě o novinkách spojených s novou verzí informovat na tomto blogu či na lokálně organizovaných akcích.

Novinky z Oracle CZ

Po velmi úspěšném působení Milana Sameše se ujímá vedení české pobočky Oracle Zdeněk Pilz, který donedávna stál v čele české pobočky Sun Microsystems.

S jeho názory se můžete seznámit i v interview nedávno poskytnutém Americké komoře, ze kterého jsou fotografie i video.

Jak možná někteyří vědí, v Oracle začíná v červnu nový fiskální rok, který bude kromě jiného také ve znamení stěhování české pobočky na novou adresu (zatím není definitivně potvrzena), takže se zdá, že se s novinkami skutečně roztrhl pytel.

Zabezpečení přístupu k dokumentům v Oracle UCM, část 4

4. Stavy položky v UCM
Kromě dříve zmíněných mechanismů může být přístup k položce omezen také díky interní stavové logice (reprezentované interním atributem Status, kterou není možné aktualizovat jako ostatní metadata). V podstatě platí, že není-li položka ve stavu Released, je buď něco špatně a nebo čeká na dokončení nějakého interního tasku.

Které akce mohou měnit stav položky?
a) nastavení ReleaseDate či ExpirationDate - položka je ve stavu Done či Expired a zobrazuje se výhradně v administrátorské aplikaci Repository Manager
b) vstup položky (nové verze položky) do workflow - položka je ve stavu Review resp. Edit resp. Pending a kromě Repository Manageru ji mohou vidět i účastníci workflow, kterým je přiřazena
c) konverze nativního dokumentu do web-viewable formátu (je-li užíváno) - položka je ve stavu GenWWW, tento stav by měl mít krátké trvání
d) smazání položky - položka je ve stavu Deleted

O změně hodnoty stavu položky viz. tento manuál, str. 1-16.

5. Speciální komponenty
Není asi překvapením, že kromě těchto standardních mechanismů existuje i nespočet bezpečnostních mechanismů dodávaných komponentami. Jako příklad uveďme rozšíření vyplývající ze standardní komponenty RecordsManager (DoD Edition) - viz zde. Zde se jedná o tzv. klasifikaci položky ('Důvěrné', 'Tajné', 'Supertajné'). Tato konkrétní implementace je velmi podobná bezpečnostním třídám - kromě nastavení atributu položky je však vyžádováno, aby si položka s sebou nesla i základní informace o klasifikaci resp. deklasifikaci položky; fakticky se tedy jedná o doplnění dalších metadat, které se základním atributem souvisí.
Jiným případem z oblasti RecordsManageru jsou tzv. doplňující označení (supplemental markings). Jedná se opět o textovou klasifikaci položky, na základě je možné přiřadit přístup k položce uživatelům. Na rozdíl od bezpečnostních skupin, či účtů, může být jedné položce přiřazeno více označení a uživatel má přístup k položce jen tehdy, má-li definováno oprávnění ke všem přiřazeným označením.