Co přesně znamená Restricted Use Licence?

Řada produktů, které dodává Oracle, má ve skutečnosti formu suity, tj. jedná se o fakticky o několik produktů najednou, které dostane zákazník právo užívat v rámci jedné licence. Např. u produktu zvaného UCM je možné využívat (na konverze z jednoho formátu do druhého) produkt Content Conversion Server, který se jinak prodává samostatně (např. při spolupráci s jinými ECM produkty od dalších dodavatelů). Výhodou tohoto přístupu je i to, že produkty jsou automaticky předintegrovány (tj. vše spolu začne fungovat automaticky, často po nainstalování a provedení jakési minimální konfigurace, což je otestováno a někdy i zdokumentováno samotnou korporací).

Velmi často je však u dalších produktů poznámka, že se jedná o Restricted Use, přičemž už nebývá tak snadné dohledat, co přesně která restrikce znamená.

Z E2.0 produktů je licenčně nejsložitější asi WebCenter Suite, který obsahuje hned 3 takovéto produkty:

• Secure Enterprise Search ("firemní Google") - zde je omezení poměrně přímočaré, jedná se o možnost vyhledávat obsah (dokumenty, stránky atp.), který je dodáván buď v rámci WebCentra, nebo je uložen v příslušném úložišti (UCM)
• Universal Content Management - zde je omezení popsáno naopak poměrně složitě: UCM může být využito k ukládání veškerého obsahu, který je dodáván jako jakákoliv stránka, aplikace či portál WebCentra. To zahrnuje základní funkce pro správu obsahu, jako jsou verzování, zobrazování různých rozlišení, stejně jako indexování obsahu pro hledání uvnitř site, portálu či aplikace. To také zahrnuje plné využití funkcí Web Content Managementu (WCM), Digital Asset Managementu (DAM) a dalších UCM component dodávaných v rámci WebCentra. Všechny interakce mohou být vykonávány buď přes rozhraní WebCenter Suite, vlastní aplikace, Desktop Integration, či UCM GUI, a to včetně administrace. Ergo, přes pojmenování žádné omezení fakticky neexistuje (jediná oblast, která není explicitně vyjmenována, je Records Management, ale možná se skrývá v těch "dalších UCM komponentách"), což při porovnání cen UCM a WebCenter Suite nabízí velmi zajímavou variantu, že za trochu víc peněz může zákazník dostat kromě úložiště i robustní portálovou infrastrukturu.
• BPEL Process Manager - toto omezení je naopak velmi citlivé: všechny koncové body procesů (tj. např. volané webové služby) musí být výhradně v rámci produktů dodávaných v rámci WebCenter Suite. To znamená, že při integraci s aplikacemi (EBS, Siebel) by se při využití BPEL musela dokoupit plná licence BPEL PM. Pro dokumentační procesy, s portálovým rozhraním ve WebCenter, je však omezená licence plně postačující (což je dobře, protože podobně laděné omezené licenci BPEL PM v rámci UCM chyběl právě článek GUI pro pracovní plochu BPEL procesů).

U UCM pak najdeme obdobně laděnou omezenou licenci na BPEL PM.

U IPM pak najdeme omezené licence na:

• BPM Suite - pro budování screenflows procesů v rámci zpracování naskenovaných dokumentů
• iAS - na jehož základech je od verze 11g IPM nově postaveno

V obou případech se tedy jedná o využití produktů na podporu vlastního IPM.

Texty pro WebCenter Suite jsou převzaty z této stránky. Všechny výše uvedená fakta mohou být v budoucnu dále předmětem změn.

Bude u vás nádraží?

Dnešní téma jsem převzal z přednášky, kterou jsem měl tu čest slyšet 4.2.2010 v Českých Budějovicích a jejímiž autory jsou pánové Dvořáci ze společnosti AutoCont ("duo Dvořák a Dvořák z cirkusu AutoCont", jak se sami titulují).

Ve své přednášce se oba pánové pokusili velmi přitažlivou formou dodat argumenty pro realizaci výzev (TC ORP, TC K, o kterých jsme informavali v tomto a tomto článku), což bývá často (zejména na úrovni ORP) problém v první řadě interního řádu - jak pro myšlenku získat "management".

Když se za Rakouska-Uherska stavěly první železnice, byly vytyčeny plány, kudy povedou koleje a každá obec pak měla možnost si odhlasovat, zda se na jejím teritoriu bude stavět nádraží, kde bude zastavovat vlak. Na samotnou stavbu nádraží (nikoliv však už na provoz - tj. na přednostu stanice či uklízečky) C.K. mocnářství přispělo - obce však měly právo se rozhodnout, zda o nabídku stojí a pokud ano, jak honosné nádraží (nadstandard už za obecní peníze) chtějí. Někdo nabídku využil, někdo ne. V budoucnu se pak ukázalo, že nádraží bylo dobrá investice do budoucnosti (kolega Jihočech vzpomínal, že mezi blízkými městy Soběslaví a Veselí n. Lužnicí byla vždy považována úřady, a tedy v jistém smyslu preferována Soběslav. A důvod - dříve měli nádraží...)

Jak to souvisí s výzvami?
Probíhající elektronizace a zprůhledňování státní správy (jehož nejviditelnější stránkou jsou prozatím datové schránky - kterými by však ve skutečnosti mělo vše jen začínat!) má ambice být podobnou revolucí, jakou bylo zavedení železnice. Stát (s významnou pomocí díky penězům z Evropské unie) buduje infrastrukturu a stanovuje pravidla pro její využívání - na rozdíl od C.K. mocnářství nedává výběr (zákon o spisové službě se vztahuje bez výjimky).
Otázka výzev tedy ve skutečnosti nestojí, zda do nich jít či ne, ale zda do nich jít nyní s jakous-takous finanční pomocí od státu (EU) či někdy v budoucnu stavět nádraží plně za své.
A variantou k této možnosti je, že obec přijde o "licenci" na poskytování služeb (prý výklad někoho z ministerstva vnitra).

Jinými slovy, ve svém důsledku se jedná o politické rozhodnutí, jaké služby bude místní samospráva na ORP poskytovat svým občanům.

Sizing Oracle UCM

Tato otázka se objevuje neustále. Vlastně je až skoro zarážející, že jsem tento článek nenapsal mezi prvními: jak správně určit počet CPU produktu Oracle UCM, tj. "nasizovat" řešení za určitých podmínek (nejčastěji se objevují počty uživatelů, dokumentů atd.)?

Předně budiž řešeno evidentní:
1) Oracle UCM se prodává ve dvou licenčních modelech:

• per NUP (Named Users Plus), tj na počet uživatelů užívajících produkt (i kdyby to mělo být jen jednou za čas!!!); u tohoto způsobu je irelevantní, na jaké "železo" se produkt nainstaluje, protože však jedna CPU licence cenově odpovídá 50 NUP, dá se předpokládat, že NUP model bude spíše jen pro opravdu malé projekty či prostředí specificky zaměřené (vývojové, testovací apod.)
• per CPU

2) metriky zaměřené na obsah (počty dokumentů, jejich celková velikost apod.) rovněž nemají vliv na počet CPU Oracle UCM - mohou (a nejspíš budou) však mít vliv na počet CPU podpůrné databáze (o roli databáze v ECM řešení viz tento článek), velikost úložného prostoru apod.

K této oblasti přeci pár poznámek:

• při počítání nutného prostoru pro úložiště nesmíme zapomínat na verzování; pokud se tedy nejedná o řešení převážně pro dále neměnné dokumenty (skeny, datové zprávy apod.), musíme velikost vynásobit ještě koeficientem počtu verzí ke každému dokumentu. Pokud nebudete mít lepší odhad, užijte konstantu 2,5.
• při konfiguraci databáze (zejména v modelu, kdy db neslouží k ukládání obsahu) bychom neměli zapomenout na přidělení prostoru (tablespace). Pro objekty v db (kterými může být cokoli - od definice metadat či struktury folia, přes uživatele, po specifikaci konfigurace přenášené komponentou CMU) pak užijte pravidlo, že na každých 50.000 objektů by databáze měla mít přiděleno 100 MB tablespace

Jak to je tedy s těmi CPU?
UCM má v podstatě roli aplikačního serveru. Jeho výkon se tedy určuje dle počtu transakcí, které musí zvládnout za nějaký časový údaj (zpravidla za sekundu). Už v této větě se skrývá určité riziko, protože některé z transakcí jsou "dražší" (mezi "drahé" transakce patří např. vyvolání konverzí, zejména pokud běží online, jak to dovoluje např. komponenta Dynamic Converter; ještě dražší transakcí je pak např. spuštění Batch Loaderu pro hromadné nahrávání většího množství položek obsahu najednou).
Nicméně, pokud opět nemáte lepší odhad, počítejte, že jeden CPU zvládne 5-25 transakcí za sekundu za GHz výkonu.

Př. organizace vlastní quadcore o 3GHz - celkem tedy má výpočetní kapacitu 12 GHz, což nám dává až optimistických 300 transakcí za sekundu (pokud je primárním vyhledávání či přímý přístup na dokumenty v úložišti)

Co s tím dál? Počet transakcí za sekundu nám asi nikdo do požadavků nedá - pokud se nedá zjistit z nějakého existujícího řešení - nejbližší použitelnou metrikou je počet současně pracujících aktivních uživatelů, což už je zpravidla dohledatelný údaj. Za aktivního uživatele se považuje ten, kdo dokáže udělat zhruba 5 transakcí (kliknutí) za minutu.

Př. výše uvedená organizace odhaduje, že systém bude užívat max. 200 současně pracujících aktivních uživatelů (celkové číslo NUP může být klidně až o řád větší!) - tito uživatelé tedy vygenerují odhadem 200 už. x 5 trans/min / 60 sec = 17 transakcí/sec, jinými slovy, tuto zátěž zvládne 1 CPU UCM (pokud by se ovšem nejednalo o UCM SE, počítal by se licenční počet CPU dle jader, což by u většině typů fakticky znamenalo 2 "licenční" CPU) na výše uvedeném serveru s prstem v nose (s rezervou na 4-18x větší zátěž).

Tyto úvahy také odpovídají na otázku co dělat, když potřebujeme zvýšit výkon. Metoda první volby je samozřejmě (surprise, surprise) - posílit hardware...

V českých podmínkách bude primární motivací pro nákup většího počtu CPU spíše požadavek na dostupnost.

Poznámka k active-active clusteringu
Při sběru materiálů na dnešní článek jsem narazil ještě na jednu docela zajímavou poznámku týkající se active-active clusteringu. Jedná se o čistě empirický poznatek, že u operačního systému Windows bere na clusteru se 2 nody režie clusteringu zhruba 5% výkonu a na clusteru se 4 nody dokonce celých 20%. Naopak při realizaci clusteru na Solarisu byl pokles výkonu řešení až se 128 nody někde na hranici 2%.

Jinak, rovněž jsem našel informaci, že s verzí 11g přijde i metodický dokument, který bude problematiku sizingu popisovat s mnohem větší mírou detailu. Tak se budeme těšit...

Výzva č. 08 k předkládání žádosti o finanční podporu v rámci Integrovaného operačního programu na Rozvoj služeb eGovernmentu v krajích

Koncem minulého týdne, resp. začátkem tohoto na www.egoncentrum.cz, vyšla dlouho očekávaná výzva na rozvoj služeb eGovernmentu v krajích. Obsahově je tato výzva (v jistém smyslu) rozšířením obdobné výzvy pro Obce s rozšířenou pravomocí (viz tento článek), přesto jsou mezi výzvami některé významné rozdíly.

Předně, výzva pro kraje obsahuje více částí:

1. část (max. 10 mil.): Elektronická spisová služba - vč. negarantovaného úložiště; určena pro ukládání neuzavřených spisů
2. část (max. 50 mil.): Digitální mapa - účelová katastrální mapa, digitálně technická mapa, nástroje pro tvorbu a údržbu
3. část (max. 75 mil.): Digitalizace a ukládání dat - krajská digitální spisovna, repozitář, úložiště, krajská digitalizační jednotka a digitalizace a uložení dokumentů
4. část (max. 40 mil.): Vnitřní integrace úřadu - vnitřní organizace i vazba na centrální projekty, zejm. pak základní registry a integrace s Portálem veřejné správy, dále pak řešení uživatelské identity
5. část (max. 30 mil.): Datové sklady - základní datový sklad, budování datamartů, transformace dat, analytiky, prezentační vrstva, BI
6. část (max. 80 mil.): Vybudování technologického centra kraje, vč. zajištění povinných služeb - realizace typového projektu TCK, resp. TCK a TC ORP, síťová, serverová infrastruktura atp., datové úložiště vč. garantovaného úložiště, virtualizace, replikace dat, zálohování, dodávka el. energie

Další změnou je drobný posun ve financování. Zatímco u ORP byly rozpočty na jednotlivé části poměrně jasně vyspecifikovány, u krajů je sice taktéž dána maximální částka na danou kapitolu, součet všech maximálních částek na jednotlivé kapitoly však výrazně převyšuje celkovou výšku dotace na kraj (135 mil. korun), proto se v jistém smyslu očekává "přelévání" prostředků mezi kapitolami (např. pokud by se části 6 a 2 implementovaly v plné maximální výši, na všechny ostatní kapitoly zbyde už jen 5 mil.). Každý kraj proto bude nutně stanovit priority, které z kapitol bude chtít řešit a v jaké výši nákladů, což je v souladu se zkušenostmi z ORP - byla-li některá z kapitol již vyřešena, nemohla obec využít "ušetřené" prostředky jinde.

Časové období pro podávání žádostí je do konce září roku 2010.