WebCenter - kompozitní aplikace, 2. část

A jak do toho celého zapadá WebCenter?

Před zodpovězením této otázky je ještě na chvíli zastavme u termínu integrace. Máme-li připravené moduly, propojitelné pomocí otevřených standardů, pořád ještě někdo tyto stavební kostky pospojovat. Zůstanete-li v oraclovském světě, uděláme to za vás, pro některé neoraclovské systémy, se kterými se setkáváme často to uděláme také, pro jiné však budete potřebovat systémového integrátora či pár vlastních architektů a vývojářů.

Pokud bychom šli odspodu, pro kompozitní aplikace může být zajímavá i datová integrace, tj. sloučení mnoho, často heterogenních zdrojů, aby uživatel mohl dostat jednotný pohled na data organizace. To jsme ve světě BI, DWH či data miningu a na toto téma najdete spoustu zajímavého čtení na blogu kolegů.

Další vrstvou integrace je integrace na úrovni aplikací, což dnes zpravidla znamená využití web services, SOAP či XML messages. Pokud se jedná o orchestrované systémy, tady samozřejmě musí přiložit ruku k dílu jejich tvůrci. O backend processing se však už dokáží postarat komponenty middleware (u Oracle to je Oracle BPEL Process Manager). Kromě backendu je však potřeba občas interagovat i s uživatelem - a to je přesně místo pro WebCenter. Tím, že součástí licence WebCenter Suite je limitovaná licence BPEL PM, jsou v rámci WebCentra dodávány i hotové komponenty pro tzv. "human workflows", tj. pracovní seznamy apod.

Poslední vrstvou, kdy je možné integraci provést, je prezentační vrstva. Zde může WebCenter přispět dvěma způsoby:
1. pro již hotové aplikace je možné využít produkt Ensemble, který umí na úrovni proxy "smíchat" výstupy z několika výstupu (mashup) a dosáhnout tak efektu kompozitní aplikace tak říkajíc ad-hoc. Tento přístup se dá použít i při přechodu z existujících aplikací na nový framework (umí nejen Java a .NET aplikace, ale i skriptovací jazyky jako Perl či PHP). Jeho evidentním nedostatkem bude výkonnost. Výhodou je naopak to, že "smíchání" může provést zkušenější uživatel - vůbec tedy na něj nepotřebujete vývojáře!
2. pro vytvářené aplikace je možné využít WebCenter Framework a tím připravit aplikaci, aby jak uměla začlenit zdroje třetích stran (portlety či jiné zdroje), ale také aby se sama prakticky bezpracně stala takovýmto zdrojem. Není asi tajemstvím, že tímto způsobem jsou či budou upraveny i aplikace Oracle jako je Siebel, Peoplesoft či EBS. Postranním efektem je pak obohacení těchto aplikací o Web2.0 funkce jako je tagging, diskuze, online messaging apod.

Základní myšlenkou kompozitních aplikací je poskytnout uživatelům takovou funkcionalitu, jakou měli či mají ERP systémy, ale při zachování uživatelského komfortu a flexibility, na kterou jsou uživatelé zvyklí z portálových řešení a WebCenter je produkt, který pro tento požadavek nabízí unikátní výhody.

Tím, že odjíždím na dovolenou, se s Vámi až do září loučím. Užijte si konec prázdnin.

Změny v licenční politice E2.0 produktů verze 11g

2. srpna byla konečně dořešena otázka licencování aplikačního serveru WebLogic pro E2.0 produkty. Jelikož jsou všechny produkty verze 11g instalovány jako J2EE aplikace na WebLogic server, byla dlouho ve vzduchu otázka, zda bude nezbytné licencovat aplikační server odděleně, či zda bude (podobně jako u IDM produktů) součástí licence na "hlavní produkt" i omezená licence na aplikační server.

Hlavní zpráva je, že b) je správně, tj. produkty obsahují omezenou licenci i na aplikační server.

V detailu to znamená:

• UCM Standard Edition obsahuje omezenou licenci Weblogic Server Standard Edition
• UCM obsahuje omezenou licenci Weblogic Server Enterprise Edition (z důvodu clusterování)
• URM neobsahuje žádnou omezenou licenci
• I/PM obsahuje omezenou licenci Weblogic Server Enterprise Edition
• ECM Suite omezenou licenci Weblogic Server Enterprise Edition
• WebCenter - nic se nemění, tj. neobsahuje žádnou omezenou licenci

"omezená licence" aplikačního serveru ve výše zmíněném textu znamená možnost provozovat na aplikačním serveru výhradně produkt (-y), které jsou součástí licence.

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".
  
  

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.