WebCenter - kompozitní aplikace, 1. část

Abychom si na chvíli odpočinuli od UCM 11g, pojďme se věnovat jinému produktu, který by v fiskálním roce 2011 mohl mít úspěch - WebCentru.

Jedním z konceptů, na které se tento produkt velmi dobře hodí, jsou tzv. kompozitní aplikace (viz. např. definice na Wikipedii). O co jde? Zejména ve větších organizacích platí, že uživatelé přistupují v rámci svých pracovních povinností ke mnoha systémům. Zpravidla však ne všichni ke všem. Navíc, zde jako nikde jinde v IT může platit, že hodnota celku je výrazně větší než součet jednotlivých komponent.

Samozřejmě, to už tu jednou bylo - a říkalo se tomu Enterprise Resource Planning (ERP), což je termín, který se zdá v současnosti spíše na ústupu ze slávy. Proč?

V jednom speciálním Zverimexu prodávali opice. Opice byly poměrně drahé a tak to jednomu zákazníkovi nedalo a zeptal se, proč jedna opice stojí celých 5000 dolarů. "No tahle umí programovat v jazyce C," dostalo se mu odpovědi od prodavače. "A co umí tahle za 10000?" nedal se odradit zákazník. "No ta umí ještě C++." "A co tahle za 50000?" ptal se s úžasem zákazník. "No, to nevíme, ale říká, že je to konzultant na SAP."

Pokud se to někoho dotýká, nechť si klidně dosadí Oracle EBS či Siebel. V době, kdy jsem vtip poprvé viděl, jsem byl zaměstnán ve Walldorfu, tak mám na tuto verzi morální právo.

Kromě ceny však mají ERP systémy ještě několik dalších problémů, které by se daly shrnout pod termín nedostatek agility, tj. neschopnost dostatečně reagovat na měnící se podmínky či požadavky zákazníků, neschopnost integrace s okolím, pokud někdo jiný nabízí něco zajímavého a pak vysoké nároky na pracovníky obsluhující řešení díky značnému využití proprietárních technologií či know-how.

Jakkoli jistě ani v Oracle není vše ideální, přeci jen byl Larry Ellison jedním z prvních pionýrů, který nastínil nový trend (viz např. Fusion Application).

Kompozitní aplikace stojí na třech pilířích:

• znovupoužitelnost služeb a zdrojů
• standardizace
• de-coupling (což by šlo přeložit jako "rozlámání na menší kousky")

Příkladem znovupoužitelnosti může být například to, co se děje za poslední tři roky s Oracle UCM nebo workflow engine BPEL - prakticky každá aplikace pracuje s dokumenty (např. v Siebelu se tomuto modul říká Siebel Files) či obsahuje nějaké workflow. Pro technologického dodavatele to pak znamená buď udržovat to samé vícekrát (např. v jednom okamžiku prý měl Oracle 17 různých workflows) a nebo v rámci možností říznout do živého a sjednotit požadavky na nějaké jedné platformě. Ani ta druhá cesta není nijak jednoduchá a jen budoucnost ukáže, kdo měl pravdu (první cesty se drží např. IBM).
Pokud jde o standardizaci, to je velmi vstřícný krok směrem k zákazníkům - máte-li již nějaké řešení, které podporuje standardy, nebo zdá-li se vám v nějaké oblasti jiné řešení lákavější, budeme vás rádi podporovat tam, kde si nás vyberete. Pod standardizaci patří hesla jako XML, XSLT, web services, SOAP, UDDI, BPEL, či BPMN, tedy něco, co Oracle podporuje, ale zdaleka nekontroluje.
A de-coupling? Některé v současnosti velmi úspěšné produkty (např. Oracle Business Intelligence SE1 či EE) vznikly odštěpením (zde od balíku Siebel). Ještě zajímavější je tento koncept však z pohledu samotných aplikací, které jsou psány modulárně (např. správa uživatelských účtů se bere skutečně jako nezavislý modul, takže je v zásadě jedno, kdo jej dodává).

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

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.

Definování vazeb mezi dokumenty v UCM

Definování vazeb mezi dokumenty je jedním ze základních nároků na každý systém pracující s dokumenty.

Spisy
Po formální stránce jsou v definování vazeb nejdále asi Spisy - tak jak jsou definovány např. v Národním standardu pro spisové služby. Logicky tvoří spis skupinu dokumentů, se kterou se pracuje v jistých operacích (např. uzavírání, přesun, skartace) najednou. Tato problematika je pokryta v UCM modulem Records Management a při popisu spisových služeb jsme se mu věnovali již několikrát.

Méně formální vazby
Pokud bychom nechali ale zákon 499/2004 Sb. stranou, bude pořád stále mnoho případů, kdy je třeba definovat vazbu mezi dokumenty. V UCM vznikla za tímto účelem řada komponent:

• ZipRenditionManagement - komponenta, která umožní ke každé položce vytvořit tzv. přílohy. Tyto přílohy, kterých může být libovolný počet (byť na vstupní masce je možné najendou jich přidat jen maximálně 5), nemají vlastní metadata a jsou zcela závislé na své mateřské položce.
  
  Př. užití: jakákoliv položka ve workflow, ke které jsou přikládány dodatečné informace (třeba i naskenované), které se primárně užity právě pro rozhodování ve workflow, či nesou historii.


• RelatedContent - tato komponenta naopak umožňuje vytvořit naprosto volné vazby mezi jakýmikoliv existujícími nezávislými položkami. Komponenta umí vytvářet vztahy typu: rodič - potomek či sourozenecké (peer-to-peer)
  
  Př. užití: informační vazby, rejstříky - bohužel se jedná o vazbu na úrovni metadat
  
  
• Folios - stojí někde uprostřed mezi dvěma výše zmíněnými způsoby. Položky ve Fóliu jsou na jednu stranu nezávislé (např. vstoupí-li do workflow Folio, neznamená to automaticky, že by do workflow vstoupila sama položka - uvědomme si navíc, že položka může být najednou ve více fóliích), na druhou stranu Fólio umožňuje vytvořit strukturovaný vztah mezi svými položkami
  
  Př. užití: dokumentace pro výběrové řízení, které musí mít určité povinné položky
  Př. užití 2: Fólio je možné využít i na koncept tzv. kompozitního dokumentu, kdy na jednom dokumentu (např. knize) pracuje najednou více autorů, kteří se tak navzájem neblokují v práci (každý na své kapitole). Fólio mj. podporuje funkci "zobraz jako celek".