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.