Technicko-technologická charakteristika Národního elektronického nástroje (NEN)

Transkript

1 Technicko-technologická charakteristika Národního elektronického nástroje (NEN) Dokument: NEN Technická specifikace Strana 1 z 73

2 Obsah 1 Úvod Účel dokumentu Informační zdroje Definice NEN Záměry a cíle spojené s vytvořením a provozem NEN Role NEN v rámci NIPEZ Popis a obsahové vymezení NEN Požadavky na architekturu Národního elektronického nástroje Klíčové požadavky na SW architekturu Klíčové požadavky na HW architekturu Další požadavky s významným dopadem na architekturu NEN Architektura NEN SW architektura Konceptuální model NEN Logické komponenty SW architektury NEN Technologické komponenty SW architektury NEN SW produkty použité v rámci SW architektury NEN HW architektura Charakteristika produkčního prostředí Charakteristika vývojového prostředí Charakteristika testovacího prostředí Dokument: NEN Technická specifikace Strana 2 z 73

3 1 Úvod 1.1 Účel dokumentu Účelem tohoto dokumentu je revize a aktualizace architektury řešení NEN (resp. požadavků na architekturu řešení) dopracované na konkrétní technologickou platformu nabídnutou vybraným systémovým integrátorem NEN (dále též SI NEN ). Tento dokument představuje stručné představení NEN, přehled klíčových požadavků na architekturu řešení a způsob jejich realizace ze strany SI NEN, tj. představení SW a HW technologií, které budou využity při implementaci NEN. 1.2 Informační zdroje Klíčovými zdroji pro zpracování tohoto dokumentu jsou především: Technická specifikace Národního elektronického nástroje (dále též TS NEN ), Detailní analýza a design Národního elektronického nástroje zpracován SI NEN. Dokument: NEN Technická specifikace Strana 3 z 73

4 2 Definice NEN Tato kapitola obsahuje zejména základní představení a obsahové vymezení NEN spolu s popisem záměrů a cílů spojených s vytvářením a provozem NEN. 2.1 Záměry a cíle spojené s vytvořením a provozem NEN Realizace projektu Národního elektronického nástroje v rámci infrastruktury NIPEZ je v souladu se Strategií elektronizace reakcí MMR na pomalý postup v rozvoji elektronizace zadávání veřejných zakázek způsobený absencí robustního nástroje pro elektronické zadávání v ČR, resp. chybějící infrastrukturou pro elektronické zadávání a finanční náročností zavádění elektronizace pro jednotlivé zadavatele. Z pravidelných šetření mezi zadavateli prováděných MMR vyplývá, že zadavatelé využívají informační podporu procesů zadávání VZ pouze pro provádění vybraných úkonů v zadávacím řízení (tj. není elektronizován celý zadávací proces). Tato skutečnost přináší zadavatelům dílčí výhody (např. možnost zkrátit lhůty v zadávacím řízení), nicméně celkové přínosy takové praxe se projeví v minimálním či nulovém poklesu transakčních nákladů spojených s realizací zadávacího řízení. Hlavním cílem dodávky Národního elektronického nástroje je dosáhnout finančních úspor elektronizací zadávání veřejných zakázek v ČR, a to: snížením cen nakupovaných komodit, snížením transakčních nákladů spojených s procesy zadávání VZ na straně zadavatelů i dodavatelů. 2.2 Role NEN v rámci NIPEZ NEN představuje v rámci infrastruktury NIPEZ klíčový modul pro elektronické zadávání veřejných zakázek (dále též zadávací modul ). Vedle NEN budou v NIPEZ sloužit pro elektronické zadávání veřejných zakázek dále e-tržiště pro veřejnou správu. Modul Národní elektronický nástroj a modul E-tržiště jsou v NIPEZ každý zaměřen na jiný segment trhu VZ, neboť každý odpovídá jiné zadávací strategii. NIPEZ bude podporovat dvě základní zadávací strategie: Rychlé operativní nákupy dle aktuálních potřeb zadavatelů s minimalizací transakčních nákladů u komodit, které jsou opakovaně nakupovány a umožňují plně elektronické zadávání (zaměření e-tržišť). Komplexní (strategické) nákupy (investice) s rozsáhlou metodickou a procesní podporou zadavatele u komodit, které umožňují využití elektronického zadávání, ale kombinovanou formou, tj. část úkonů bude v listinné podobě (zaměření NEN). Dokument: NEN Technická specifikace Strana 4 z 73

5 Národní infrastruktura pro elektronické zadávání VZ (NIPEZ) Uveřejňovací subsystém informačního systému o veřejných zakázkách (IS VZ US) (provozuje NESS Czech, s.r.o.) Národní centrální uveřejňovací místo pro všechny zadávací postupy s povinností uveřejnění dle ZVZ a KZ. Zajištění uveřejnění vyhlášení na evropské úrovni v TED (Tenders Electronic Daily). Národní elektronický nástroj (NEN) Komplexní funkcionalita pro všechny kategorie zadávacích postupů a zadavatelů Podpora všech rozsahů elektronizace E-tržiště (5 provozovatelů) Prostor pro rychlé střetávání nabídky a poptávky při minimalizaci transakčních nákladů na straně zadavatelů i dodavatelů Ostatní moduly IS VZ (provozuje MMR) Seznam kvalifikovaných dodavatelů Seznam systémů certifikovaných dodavatelů Rejstřík osob se zákazem plnění veřejných zakázek Statistické výstupy o veřejných zakázkách Individuální elektronické nástroje (IEN) Nástroje provozované zadavateli/resorty, které nechtějí využívat NIPEZ u povinných komodit a zadávacích postupů mimo tuto povinnost. IEN musí splnit požadavky technické specifikace e- tržišť či NEN (dle rozsahu, ve kterém mají být zadavatelem/resortem využívány). Schéma 1: Národní infrastruktura pro elektronické zadávání VZ (NIPEZ) Podrobná role e-tržišť, NEN a dalších modulů NIPEZ, tj. informačního systému o veřejných zakázkách (dále též IS VZ ) a individuálních elektronických nástrojů (dále též IEN ) je podrobně charakterizována v následující tabulce. E-TRŽIŠTĚ (pro operativní nákupy dle aktuálních potřeb) Hlavní role v rámci NIPEZ Prostor pro rychlé střetávání nabídky a poptávky při minimalizaci transakčních nákladů na straně zadavatelů i dodavatelů Plně elektronické zadávání VZ na vybrané komodity ve vybraných zadávacích řízeních Omezení E-tržiště jsou vhodná pouze pro standardizovatelné komodity (z důvodu využití plně elektronického zadávacího řízení) E-tržiště podporují pouze rychlá zadávací řízení a proto zasahují pouze do podlimitních veřejných Dokument: NEN Technická specifikace Strana 5 z 73

6 NÁRODNÍ ELEKTRONIC KÝ NÁSTROJ (zejména pro komplexní nákupy) Důraz na používání automatizované metody hodnocení nabídek, elektronických katalogů, eaukce Vytvoření a provoz zafinancují provozovatelé, kteří budou státu fakturovat poplatky za používání Typové komodity (např. kancelářské potřeby, nábytek, spotřební zdravotnický materiál, standardizovatelné služby atd.) Komplexní funkcionalita pro všechny kategorie zadávacích postupů a všechny kategorie zadavatelů (vč. sektorových) Podpora všech rozsahů elektronizace (od evidence po plně elektronické postupy) lze využít i u VZ, u kterých není možné použít automatizovanou metodu hodnocení (např. stavební práce) Možnost provázání na interní systémy zadavatelů i dodavatelů, či systémy egovernmentu v ČR Podpora plánovacích aktivit (často půjde o VZ realizované v rámci dlouhodobých investičních projektů) Důraz na používání elektronických katalogů, eaukce Typové komodity (např. komplexní služby, stavební práce, vč. stavby dálnic či jiných rozsáhlých staveb, dodávky technologických celků atd.) zakázek Pro řadu předmětů VZ e-tržiště nabízí příliš úzkou funkcionalitu E-tržiště obsahují postupy pouze pro veřejné zadavatele Vyšší investiční náročnost z tohoto důvodu má NEN pouze 1 provozovatele (u e-tržišť je navrženo 5 provozovatelů) Delší doba pro uvedení do provozu (plánováno od 2013) Dokument: NEN Technická specifikace Strana 6 z 73

7 Individuální nástroje 1 IS VZ Individuální nástroje budou používat ti zadavatelé/resorty, kteří nechtějí využívat NIPEZ u komodit a zadávacích postupů, kde je používání NIPEZ povinné Individuální nástroje lze plně integrovat s interními IS zadavatele Individuální nástroje mohou převzít vybrané funkce interních IS zadavatele (např. spisové služby) Představuje modul s funkcionalitou pro plnění zákonné povinnosti: zadavatelů v oblasti uveřejňování informací o veřejných zakázkách (viz ustanovení 146 ZVZ), MMR v oblastech o vedení seznamu kvalifikovaných dodavatelů (viz ustanovení 125 a násl. ZVZ), o vedení rejstříku osob se zákazem plnění veřejných zakázek (tzv. black list), o vedení seznamu systémů certifikovaných dodavatelů (viz ustanovení 135 odst. 5 ZVZ), o zajištění statistických výstupů o veřejných zakázkách (zejména dle ustanovení zadávacích směrnic ES) Náklady spojené s vytvořením a provozováním individuálních elektronických nástrojů ponese každý ze zadavatelů/resortů samostatně Bude docházet k duplicitám ve funkcionalitě u jednotlivých elektronických systémů ve veřejné správě Omezení u tohoto modulu NIPEZ nejsou, neboť je již řadu let v provozu, má vytvořena standardizovaná rozhraní pro sdílení dat, která byla zohledněna při zpracování technické specifikace e-tržišť a NEN Tabulka 1: Účel a role jednotlivých modulů v rámci NIPEZ 1 Individuální nástroje používají ti zadavatelé, kteří nechtějí používat NIPEZ (zadavatel například již zainvestoval do vlastního IS např. SEPO Ministerstva obrany). I tito zadavatelé musí dodržet technickou specifikaci pro NEN. Dokument: NEN Technická specifikace Strana 7 z 73

8 2.3 Popis a obsahové vymezení NEN NEN je nástroj určený pro zadávání veřejných zakázek (VZ) na obtížně standardizovatelné komodity. Jeho spuštění podpoří zadavatele při administraci zadávacích postupů VZ, soutěží o návrh, koncesních řízení, výběru subdodavatele podle obranné směrnice (DEFENCE) a výběru subdodavatele podle koncesního zákona. Vzhledem k tomu, že NEN bude umožňovat kombinované zadávání veřejných zakázek (tedy elektronické i listinné), bude z pohledu finančního objemu přes NEN zadáváno nejvíce zakázek. Prostřednictvím NEN bude totiž možné zadávat i VZ související s komplexními investičními akcemi, u nichž není z objektivních důvodů možný plně elektronický zadávací postup. Jedním z klíčových záměrů MMR ČR je, aby implementace NEN přispěla ke zkvalitnění postupů zadávání veřejných zakázek v organizacích zadavatelů, a to s cílem podpořit dodržování principů ZVZ a principů 3E (hospodárnosti, efektivnosti a účelnosti). Zadavatelé by se při vynakládání finančních prostředků z veřejných zdrojů neměli řídit pouze formálním dodržením pravidel obsažených v ZVZ, ale měli by neustále hledat hospodárnější a efektivnější způsoby pořizování služeb, dodávek a stavebních prací. NEN jim umožní tzv. principy 3E posilovat tím, že nabídne funkce pro provádění výdajových analýz zadaných VZ (předpokládá se, že zadavatel bude strukturovaně popisovat předmět VZ a že bude využívat standardizační parametry komodit), hodnotit zadané VZ z pohledu, zda není příliš nezneužíváno výjimek a uzavřených postupů zadávání VZ, a používat optimalizační instituty ZVZ (např. centralizované zadávání, elektronické aukce, dynamický nákupní systém atd.) a další. Jedním z cílů NEN je pak také zajištění proveditelnosti centralizovaného zadávání VZ (viz kapitola Resortní systémy centralizovaného zadávání) ve veřejné správě, kdy zadavatelům nabídne ucelenou informační podporu pro resortní systémy centralizovaného zadávání VZ. NEN je určen zejména pro ty zadavatele, kteří nechtějí investovat do vlastního řešení elektronického nástroje a zároveň chtějí používat robustní řešení garantované státem. Klíčové funkcionality a vlastnosti NEN: Podpora zadávacích postupů u: o veřejných zakázek, o soutěže o návrh, o koncesních smluv, o výběru subdodavatele DEFENCE, o výběru subdodavatele dle koncesního zákona. Dokument: NEN Technická specifikace Strana 8 z 73

9 NEN obsahuje postupy pro všechny kategorie zadavatelů včetně sektorových. NEN obsahuje procesní podporu zadavatele při zadávacím řízení, ucelenou evidenci zadávacích řízení v organizaci/resortu zadavatele pro účely řízení, monitoringu, statistických rozborů, analýz o skladbě prováděných nákupů a další podpůrné funkce (např. možnost generování výstupních dokumentů veřejné zakázky do přednastavených šablon, podporu oběhu dokumentů atd.). Prostřednictvím NEN lze zadávat veškeré komodity, a to i ty, u kterých není možné použít automatizovanou metodu hodnocení (např. stavební práce). V rámci NEN lze provádět tzv. kombinované zadávací řízení (úkony v zadávacím řízení lze provádět částečně elektronicky a částečně v listinné podobě). NEN Podporuje plánovací aktivity. NEN obsahuje komplexní funkcionalitu pro centralizované zadávání VZ. NEN bude moci používat jakýkoli centrální zadavatel ustavený ve veřejné správě v ČR. NEN zajistí proveditelnost centralizovaného zadávání VZ ve veřejné správě. NEN lze díky jeho ucelené funkcionalitě pro zadávání VZ považovat za zcela samostatný (tj. samostatně provozuschopný) informační systém. Pokud má však přispět k úspoře transakčních nákladů souvisejících se zadáváním VZ, je nutné jej napojit na řadu informačních systémů (viz Rozhraní NEN). Elektronizace zadávacích agend naplní cíle stanovené ve Strategii elektronizace až v okamžiku, kdy bude zajištěna plná informační podpora v průběhu celé zakázky. Zadávací řízení je pouze dílčí fází a předchází mu řada procesů v organizaci zadavatele (např. plánování investic a nákupu) a řada procesů na ukončené zadávací řízení navazuje (např. objednávky a fakturace). Rozhraní lze kategorizovat do tří základních skupin. V první skupině jsou vazby NEN na ostatní moduly NIPEZ, především na již funkční IS VZ US (za účelem uveřejňování vyhlášení) a IS VZ (za účelem předávání statistických dat), e- tržiště pro veřejnou správu (za účelem zajištění jednotné evidence VZ zadávaných prostřednictvím NIPEZ), a na individuální elektronické nástroje (IEN). Ve druhé skupině to jsou vazby NEN na systémy egovernmentu (základní registry, informační systém státní pokladny, datové schránky atd.). Třetí skupinou jsou vazby NEN na vnitřní systémy zadavatelů a dodavatelů (zejména spisové služby). Dokument: NEN Technická specifikace Strana 9 z 73

10 3 Požadavky na architekturu Národního elektronického nástroje Tato kapitola obsahuje přehled klíčových požadavků na SW a HW architekturu NEN. Úplný výčet požadavků na NEN je obsažen v Technické specifikaci NEN. 3.1 Klíčové požadavky na SW architekturu Architektura systému Architektura systému MUSÍ být navržena jako třívrstvá, s oddělenou databázovou, aplikační a prezentační vrstvou, vycházející ze zásad a principů servisně orientované architektury (SOA) s důrazem na portálové řešení se silnou podporou tvorby a řízení oběhu dokumentů. Systém musí mít otevřené API pro integraci s jinými systémy. Prezentační vrstva Prezentační vrstva MUSÍ být s ohledem na nutnost zajištění jednotného přístupu celé řady zadavatelů a dodavatelů realizována formou portálového řešení přístupného následujícími způsoby: Tenký klient - Systém MUSÍ být uživatelům přístupný a plně funkční prostřednictvím internetových prohlížečů. Klienti musí být schopni v případě potřeby aktualizovat bezpečnostní software stahovaný ze serverů zadavatele na podporu speciálních spojovacích a autentizačních postupů. Klienti budou do systému přistupovat ze zařízení typu standardně vybaveného PC a informačního kiosku. Webové služby (výměna dat a informací ve formátu XML) v souladu s vyhláškou č. 53/2007 Sb. Aplikační vrstva Jednotlivé úkony uživatelů MUSÍ být realizovány jednotlivými funkcionalitami (1 n web services), které budou parametrizovatelné tak, aby opět bylo možné bez složitých a zdlouhavých analytických a vývojových činností: Reagovat na změny v legislativě. Uživatelsky parametrizovat vybrané úkony (funkcionality). Veškerá funkcionalita (webové služby, sběrnice, workflow, identita, data, parametry, algoritmy) musí zachovávat historii, tj. v každém okamžiku musí mít NEN schopnost modelovat procesy platné v době, kdy byly realizovány. Dokument: NEN Technická specifikace Strana 10 z 73

11 Aplikační vrstva musí disponovat funkcionalitou, která zahrnuje vlastnosti: Spolupráce s Enterprise service bus (ESB) Procesní podpora Back-end systémy Spolupráce s Enterprise service bus (ESB) Enterprise Service Bus (ESB) plní integrační funkci mezi NEN a ostatními komponentami NIPEZ, případně též dalšími externími systémy, jako jsou například datové schránky, IS zadavatelů a dodavatelů apod. Bude disponovat těmito vlastnostmi a parametry: Standardizovaná integrační aplikace, která podporuje všechny hlavní komunikační scénáře, včetně žádost/odpověď, jednosměrné přenosy zpráv s garantovaným doručením a vice komplexní přenosy událostí a zpráv. Musí využívat standardizované formáty, protokoly a přístupy, např. XML, HTTP, SOAP, WSDL, a JAX-RPC, JBI, JMS a SCA. Musí využívat standardizované konektory a možnost vytváření dalších konektorů. Musí umožnit rozšiřitelnost a modularizaci. Procesní podpora Procesní podpora musí umožnit centrální implementaci procesů s využitím standardního jazyka. Jejím využitím bude relizován: Centrální vývoj procesů s využitím služeb systémů vystavených na ESB. Centrální přehled o průběhu instancí jednotlivých procesů. Standardní změnové řízení při požadavku na změnu procesu (verzování a dokumentace). Systém musí obsahovat jako integrální součást nástroj na dynamickou tvorbu, správu a využití business rules (Business Rules BR a Business Rules Engine BRE). Je požadováno, aby změny provedené v subprocesu, který je využíván v rámci více procesů, byly promítnuty do všech těchto procesů bez nutnosti jejich opakování. Je doporučeno, aby systém umožnil zobrazit procesy NEN ve vizuální pobobě pro potřeby revize a posouzení souladu se zákonem, a to tak, aby bylo možné do procesů v této formě i zapracovat případné změny. Je preferována otevřenost takového řešení pro práci auditora procesů v externím nástroji pro design procesů. Back-end systémy Na úrovni back-end systémů budou v rámci NEN implementovány minimálně následující okruhy služeb: správa obsahu a dokumentů (Document Management System), řízení procesů (Business Process Management), využití ad-hoc procesů a úkolů (Case Management), Dokument: NEN Technická specifikace Strana 11 z 73

12 archivace souborů (Archiving) při dodržování předpisů v oblasti zákona č. 499/2004 Sb., o archivnictví a spisové službě, centrální identifikace a autentizace uživatelů (Identity Access Manager), dohledové nástroje, viz požadavek Dohledové nástroje. Funkcionalita poskytovaná back-end systémy bude skládána z tzv. atomické funkce (jednotlivé kroky business procesů) tak, aby byla zajištěna co nejvyšší znovu použitelnost již hotových funkcí a zároveň jednoduchá možnost implementace nových business procesů složením atomických funkcí bez nutnosti vyvíjet funkce nové. Všechny atomické funkce budou verzovány a budou mít zajištěnu volitelnost hodnot klíčových parametrů. Změna klíčového parametru nesmí vyvolat vývoj nové funkce. Systém musí umožnit uživatelům vysokou variabilitu pro řešení výjimečných případů v rámci VZ (management případů), automatické spuštění aplikační a procesní logiky v závislosti na stavu VZ a zařazovat do VZ také specifické, tzv. ad-hoc procesy a úkoly. Back-end systémy budou poskytovat služby výhradně na základě údajů o roli a přístupových právech obsažených v jednotlivých dotazech. Tyto údaje budou verifikovány proti IAM (uživatelské jméno + role), bez jejich verifikace nebude služba poskytnuta. Vlastní back-end systémy nebudou mít žádné role a přístupová práva, tato budou obsažena výhradně v IAM, tedy každá atomická funkce bude v IAM registrována s příslušnými právy, kombinací atomických funkcí a jejich práv budou na úrovni IAM vytvářeny role. Každá atomická funkce bude zároveň při volání zajišťovat zápis do centrálního úložiště logů. Budou zaznamenány následující operace: ID a znění dotazu, identita a role volajícího, čas volání (start, konec operace), výsledek volání (úspěch/neúspěch, návratové hodnoty). Datová vrstva Návrh architektury systému MUSÍ zajistit vysokou dostupnost (HA High Availability) na úrovni datové vrstvy SW prostředky nástroje pro uchování dat tak, aby jej bylo možné provozovat v módu active-active. Identifikace/autorizace MUSÍ být zajištěna na všech vrstvách systému, tj. až na úroveň datové vrstvy tak, aby u každého záznamu bylo možno jednoznačně identifikovat, kdo a kdy údaj vytvořil, změnil nebo zneplatnil. K datům nesmí být povolen přímý uživatelský přístup (kterým by se mohla data modifikovat, mazat) musí být povolen pouze prostřednictvím aplikační vrstvy identifikovaným a autorizovaným uživatelům. Systém MUSÍ umožnit zajištění dělby rolí při správě databáze v rozsahu, který by znemožňoval administrátorům provozovatele NEN neomezitelný přístup k citlivým datům v databázi, tj. ani databázový administrátor s Dokument: NEN Technická specifikace Strana 12 z 73

13 nejvyššími právy nesmí být schopen bez koordinace s jiným uživatelem získat přístup k citlivým datům. Datová vrstva MUSÍ podporovat rychlou obnovu dat logicky poškozených činností uživatele bez nutnosti obnovy z plné zálohy. Systém MUSÍ podporovat přístup k dokumentům pomocí standardizovaného rozhraní CMIS (Content Management Interoperability Services). Dokumenty musí být ukládány a spravovány podle OAIS (Open Archival Information System). 3.2 Klíčové požadavky na HW architekturu Prostředí systému Dodávka systému MUSÍ obsahovat oddělené vývojové, testovací a provozní prostředí. Provozní prostředí Provozní prostředí MUSÍ umožnit provoz ve 2 nezávislých, geograficky oddělených lokalitách a redundanci HW a SW komponent v primární lokalitě. Prostředí MUSÍ být navrženo s odděleným prezentačním, aplikačním a databázovým serverem. S ohledem na požadovanou dostupnost systému musí být systém provozován v primární lokalitě v režimu vysoké dostupnosti (active/active). V sekundární lokalitě musí být provozován záložní systém. Primární lokalita je proti sekundární lokalitě provozována v režimu active/passive. Vysoká dostupnost v rámci primární lokality MUSÍ mít alespoň následující vlastnosti: Active-Active clustering na všech vrstvách (prezentační/aplikační/databázová). Vzhledem k očekávané zátěži systému musí být řešení horizontálně škálovatelné. Řešení se musí umět vypořádat s výraznou špičkovou zátěží, která je spojena s provozem elektronických aukcí (při jejich ukončení uživatelé budou vkládat nové nabídky se zvýšenou frekvencí). V systému běží a končí aukce paralelně (minimálně proběhne 100 aukcí za jeden pracovní den). Výpadek jednoho HW prostředku (serveru, síťového prvku, SAN infrastruktury) nesmí znamenat výpadek systému v primární lokalitě. V případě výpadku jedné komponenty výkon z pohledu uživatelů nesmí být významně omezen (dodržení dohodnutého SLA). V případě výpadku jedné komponenty kontext uživatele nesmí být ztracen (např. bude-li systém realizován jako standardní J2EE webová aplikace využívající koncept HttpSession, je třeba propagovat HttpSession mezi nódy clusteru); výpadek systému nesmí ovlivnit např. proces elektronické aukce, aby jeden uživatel nebyl v případě výpadku nódu nucen Dokument: NEN Technická specifikace Strana 13 z 73

14 se po přesměrování na fungující nód znovu přihlásit a navigovat se až do okna probíhající akukce. V případě výpadku aplikační komponenty musí systém uvolnit automaticky všechny zdroje (např. zámky na objektech ve spojení s rozběhnutými transakcemi) a to tak, aby tyto zdroje bylo možno vyžít z druhé (redundantní) komponenty tak, aby nemohlo docházet k deadlockům (např. aby nebyl blokován průběh aukce před svým koncem). V případě výpadku či odstávky primární databáze MUSÍ být možné přesměrovat provoz do záložní lokality v jednotkách až desítkách minut. Data na záložní server MUSÍ být přenášena průběžně. Řešení musí podporovat replikaci dat v plném rozsahu do záložní lokality, záložní lokalita musí z výkonového pohledu mít stejný výkon jako lokalita primární. Replikace dat do záložní lokality nenahrazuje zálohování systému a vhodný zálohovací mechanismus musí být navržen s ohledem na objem zálohovaných dat v 5 letém horizontu udržitelnosti řešení s tím, že kompletní systém je nutno obnovit na připravený HW do 3 kalendářních dnů. Testovací prostředí Testovací prostředí MUSÍ být konfiguračně shodné s provozním prostředím. Testovací prostředí nemusí splňovat výkonnostní požadavky kladené na provozní prostředí. Vývojové prostředí Vývojové prostředí nemusí být konfiguračně shodné s provozním prostředím a nemusí splňovat výkonnostní požadavky kladené na provozní prostředí. Plánovaný výkon a kapacita systému Systém MUSÍ být navržen tak, aby respektoval následující očekávané provozní parametry (zdroj: Studie proveditelnosti - Národní infrastruktura pro elektronické zadávání veřejných zakázek): Počet zadavatelů 545 subjektů. Počet dodavatelů subjektů. Počet registrovaných uživatelů zadavatelé uživatelů. Počet registrovaných uživatelů dodavatelé uživatelů. Počet současně pracujících uživatelů v předpokládané špičce (tj. uživatelů, kteří se systémem budou pracovat mezi 8:00 a 10:00 v pracovní dny) uživatelů. Počet zrealizovaných VZ VZ/rok. Datový objem zadávací dokumentace 10 TB/rok. Počet aukcí 100/den. Dokument: NEN Technická specifikace Strana 14 z 73

15 Délka doby odezvy systému MUSÍ při uvedeném zatížení odpovídat běžným zvyklostem obdobných informačních systémů. Rychlost zpracování byznys aktivit Systém MUSÍ zajistit měření byznys aktivit. Doba zpracování byznys aktivit (doba odezvy end-to-end transakcí) nebude měřena a signalizována on-line. Délka zpracování byznys aktivit bude zaznamenávána v provozním logu. Ten musí být správci NEN dostupný po dobu 3 měsíců zpětně (provozovatel bude muset být schopen sestavit statistiku za správcem stanovený časový úsek). Součástí systému MUSÍ být uživatelsky ovladatelný nástroj na analýzu logů, resp. analýzu časů pro zpracování byznys aktivit. Doba zpracování byznys aktivit MUSÍ odpovídat běžným standardům obdobných informačních systémů. Škálovatelnost systému Systém a jeho HW infrastruktura MUSÍ být navržen a vytvořen tak, že zvýšení výkonu a kapacity systému může být realizováno výhradně přidáním kompatibilních komponent, nikoli prostou výměnou stávajících. 3.3 Další požadavky s významným dopadem na architekturu NEN Dostupnost systému Systém MUSÍ být, včetně HW infrastruktury a provozních postupů, navržen a vytvořen tak, aby umožnil zajištění následujících parametrů dostupnosti: Dostupnost produkčního prostředí MUSÍ být v obvyklé pracovní době (pracovní dny od 9:00 do 20:00) 99,5%. Dostupnost produkčního prostředí MUSÍ být mimo obvyklou pracovní dobu 98%. Dostupnost bude měřena a vyhodnocována v periodě jeden měsíc. Systém bude považován za nedostupný v době trvání systémového stavu "mimo provoz" a "omezení funkcionality" od okamžiku: oprávněné identifikace nedostupnosti pomocí automatické kontroly dostupnosti systému až do okamžiku obnovení provozu, oprávněného nahlášení nedostupnosti či nesprávné funkčnosti uživatelem systému provozovateli až do okamžiku obnovení provozu nebo nabídnutí náhradního řešení pro nedostupnou či nesprávně fungující funkcionalitu systému. Dokument: NEN Technická specifikace Strana 15 z 73

16 Provozovatel je povinen evidovat každé uživatelské hlášení nedostupnosti systému s informací, zda se jednalo o oprávněné či neoprávněné hlášení. Provozovatel je povinen tyto informace zpřístupnit správci systému. Celková plánovaná doba dostupnosti je definována jako počet hodin v daném kalendářním měsíci bez počtu hodin, který je správcem systému odsouhlasen pro provedení plánované provozní odstávky systému. Plánované odstávky systému Plánované servisní odstávky MUSÍ být plánovány na dny pracovního klidu. Plánovaná servisní odstávka MUSÍ být oznámena správci systému nejméně 40 dní před její realizací. Správce systému musí o realizaci plánované servisní odstávky rozhodnout nejpozději 30 dní před její realizací. Zálohování dat Data systému MUSÍ být pravidelně zálohovaná takovým způsobem, aby i v případě havárie nedošlo po obnovení provozu systému ke ztrátě dat vložených do systému 2 hodiny před havárií. Archivace dat Systém musí archivovat uživatelská data po dobu minimálně 10 let. Doba odezvy při práci s archivovanými daty nemusí odpovídat požadavkům na dobu odezvy systému. Systém může přesunout do archivu data týkající se VZ po 2 letech od jejího uzamknutí. Dohledové nástroje Součástí systému MUSÍ být dohledové nástroje minimálně v následujícím rozsahu: dohledové nástroje pro stavový monitoring HW komponent, dohledové nástroje pro stavový monitoring SW komponent, dohledové nástroje na End to End monitoring, dohledové nástroje na sledování bussines požadavků a procesů, dohledové nástroje na SLA monitoring, bezpečnostní dohledové nástroje, bezpečné úložiště logů. Dokument: NEN Technická specifikace Strana 16 z 73

17 Identifikace a autorizace přístupů Pro identifikaci a autorizaci přístupů uživatelů MUSÍ systém využívat služeb Identity a Access Managementu (IAM), který bude databází všech identit uživatelů a jejich autorizačních informací pro účely užívání služeb systému. Systém MUSÍ prostřednictvím IAM podporovat následující metody identifikace a autentizace uživatelů: Identifikace a autorizace fyzických osob (v různých rolích, které budou přistupovat k NEN přes internetový prohlížeč) použití kombinace jméno a heslo nebo kombinace jméno a uživatelský certifikát. Identifikace a autorizace okolních informačních systémů použití kombinace serverový certifikát a IP adresa. Po přihlášení jsou uživateli přidělena přístupová práva na základě rolí z IAM. Důvěrnost a integrita výměny dat Řešení MUSÍ být navrženo s ohledem na vysokou míru zabezpečení celého řešení. Systém bude připojen přímo na Internet. Řešení proto MUSÍ obsahovat minimálně firewally pro vytvoření demilitarizované zóny (DMZ). Síťový firewall MUSÍ poskytovat stavovou inspekci protokolu http. Žádný neprověřený provoz NESMÍ být vpuštěn na aplikační servery, kde bude prováděn přístup do datové vrstvy. Systém MUSÍ zajistit, že: Systémem uchovávaná data nesmí být zpřístupněna neautorizovaným osobám. Přístup a veškerá manipulace s daty MUSÍ být zaznamenávaná. Data nemohou být během komunikace odposlouchávána či pozměněna neautorizovanou stranou. Pro komunikaci mezi uživatelem a systémem musí být použit zabezpečený komunikační protokol (SSL verze 3 nebo TLS verze 1). Systémem uchovávaná data nesmí být možné změnit nebo poškodit neautorizovanou stranou, či administrátory správce nebo provozovatele NEN. Antivirová ochrana Systém pracuje s dokumenty (pojem dokument je vnímán z pohledu bezpečnosti jako obecný soubor vkládaný nebo získávaný ze systému) třetích stran, kde není možno jakýmkoliv způsobem vynucovat politiky zabezpečení pracovních stanic (např. lokální antivirus nebo personální firewall). Systém proto musí obsahovat řešení antivirové kontroly dokumentů (minimálně těch, které jsou v systému uloženy v nezašifrované podobě a má k nim tak přístup). Dokument: NEN Technická specifikace Strana 17 z 73

18 Pokud systém identifikuje, že vkládané soubory obsahují škodlivé údaje, nebo obsah, který by mohl poškodit systém, či koncová zařízení uživatelů pracujících s těmito soubory, tak: Zobrazí uživateli vkládajícímu tyto soubory upozornění na tuto skutečnost a vyzve jej k potvrzení přání vložit takovéto soubory do systému. Tato operace, včetně potvrzení uživatele MUSÍ být zaznamenána. Tyto soubory MUSÍ být uloženy na fyzicky odděleném úložišti, bez možnosti negativně ovlyvnit chod systému (v tzv. karanténě). O umístění souboru do karantény MUSÍ být informováni příslušní administrátoři provozovatele NEN. Všem uživatelům, kteří budou chtít manipulovat s těmito soubory bude před provedením jakékoliv operace zobrazena informace o tom, že soubory mohou obsahovat škodlivý obsah, nebo mohou poškodit koncové zařízení uživatele a vyzve uživatele k potvrzení svého záměru manipulovat s těmito soubory. Tato operace, včetně potvrzení uživatele MUSÍ být zaznamenána. Antivirová ochrana nesmí zhoršovat dobu odezvy systému. Přístup do systému a jeho použití Veškeré části systému, se kterými budou pracovat koncoví uživatelé, MUSÍ být přístupny prostřednictvím následujících webových prohlížečů: Internet Explorer (verze 7 a novější), Mozilla Firefox (verze 3 a novější), Google Chrome (verze 9 a novější), Safari (verze 3.1 a novější), Opera (verze 11 a novější). Práce se systémem SMÍ být podmíněna instalací aplikací a doplňků webových prohlížečů, které jsou bezplatně dostupné, či běžné. Uživatelské rozhraní systému Uživatelské rozhraní systému MUSÍ být navrženo s ohledem na ergonomii, snadnost a intuitivnost ovládání, a to zejména v následujících parametrech: Dodržování běžných zvyklostí uživatelské rozhraní musí být navrženo v souladu s aktuálními trendy a standardy a jeho struktura i jednotlivé prvky musí odpovídat běžným zvyklostem obdobných řešení. Orientace v aplikaci uživateli musí být vždy jasně prezentováno, v které části systému se nachází a v jaké fázi je provádění procesu, který provádí. Rozfázování složitějších operací v případě komplexnějších operací musí být uživatel systémem veden po jednotlivých krocích. Dokument: NEN Technická specifikace Strana 18 z 73

19 Dostupnost funkcí s ohledem na četnost jejich používání nejčastěji používané funkce musí být nejsnadněji dostupné. Dostupnost nápovědy nápověda musí být dostupná z každého místa systému. Konzistentnost uživatelského rozhraní stejné či podobné funkcionality se napříč celým systémem musí chovat stejně či podobně. Uživatelské rozhraní MUSÍ v maximální možné míře seskupovat ovládací prvky na základě jejich určení (např. obecné funkcionality, funkcionality spojené s konkrétní VZ, funkcionality spojené s obsluhou interního mailboxu atd.). Uživatelské rozhraní MUSÍ používat výhradně terminologii stanovenou v technické specifikaci, zejména v rámci procesního modelu. V případech, které nejsou pokryty technickou specifikací, musí systém používat terminologii používanou v ZVZ a souvisejících právních předpisech. V případě nejasnosti MUSÍ být respektováno rozhodnutí správce NEN. Uživatelské rozhraní MUSÍ být postaveno s ohledem na přístupnost pro osoby se zdravotním postižením a v souladu s: Vyhláškou č. 64/2008 Sb., o formě uveřejňování informací souvisejících s výkonem veřejné správy prostřednictvím webových stránek pro osoby se zdravotním postižením. Doporučením Web Content Accessibility Guidelines (WCAG) 2.0 úrovně AA od konsorcia W3C s výjimkou odůvodněných případů, které akceptuje také správce systému. Systémový čas Časová informace poskytovaná systémem MUSÍ být navázána na zdroj reprodukující světový koordinovaný čas UTC, například na státní etalon času a frekvence. Zdroj časové informace MUSÍ být kalibrován v souladu se zákonem č. 505/1990 Sb., o metrologii, v platném znění, případně musí být na tento zdroj prokazatelně navázán. Synchronizace času měřeného systémem s koordinovaným světovým časem se provádí alespoň jedenkrát za 24 hodin. Systém MUSÍ být navržen tak, aby odchylka časové informace v době mezi dvěma synchronizacemi nepřekročila 0,1 sekundy. Synchronizace podle předešlého odstavce musí být zajištěna i v případě výskytu přestupné sekundy. Dokument: NEN Technická specifikace Strana 19 z 73

20 4 Architektura NEN 4.1 SW architektura V následujících kapitolách je uveden popis SW architektury, který vychází z SI NEN provedené analýzy požadavků vyplývajících z Technické specifikace NEN. Vzhledem k rozsáhlosti a komplexnosti řešené problematiky je popis SW architektury rozdělen do několika úrovní seřazených v logickém sledu od úrovně chápání problematiky z pohledu běžného života až po ryze technickou úroveň využitých SW produktů a jejich vlastností. Následující obrázek znázorňuje úrovně popisu SW architektury tak, jak jsou v dalších kapitolách podrobně popsány. Konceptuální model systému NEN Východiskem navržené SW architektury je Konceptuální model. Logické komponenty SW architektury Funkční a podpůrné požadavky dané Technickou specifikací NEN jsou z hlediska logického uspořádání SW architektury pokryty logickými komponentami. Technologické komponenty SW architektury Funkčnosti logických komponent jsou zabezpečeny prostřednictvím technologických komponent SW architektury. Schéma 2 Úrovně SV architektury Technologické komponenty SW architektury Funkčnosti logických komponent jsou zabezpečeny prostřednictvím technologických komponent SW architektury. Dokument: NEN Technická specifikace Strana 20 z 73

21 4.1.1 Konceptuální model NEN Východiskem navržené SW architektury řešení NEN je Konceptuální model uvedený v Technické specifikaci NEN: NIPEZ IS VZ US SKD, SCD, Black list Statistický a analytický modul IS VZ E-tržiště Individuální elektronické nástroje Národní elektronický nástroj (NEN) Hlavní funcionality Podpora životního cyklu zadávacích postupů Podpora dalších institutů ZVZ a KZ Průřezové funkcionality zadávacích postupů Podpůrné funkcionality Registrace a správa subjektů Registrace a správa uživatelů Řízení přístupových oprávnění Práce s dokumenty Správa šablon pro generování dokumentů Práce s formuláři Uživatelské pohledy PKI Komunikace Klasifikace a číselníky Záznamové soubory IS zadavatelů/dodavatelů egovernment ARES Notifikace prostřednictvím u Akreditovaný poskytovatel certifikačních služeb Spisová služba Poskytovatel kvalifikovaných časových razítek Objednávkové systémy Základní registry Fakturační systémy Informační systém státní pokladny Schéma 3 Konceptuální model systému NEN Dokument: NEN Technická specifikace Strana 21 z 73

22 V rámci následující tabulky jsou uvedeny hlavní funkční požadavky na systém jednotlivé komponenty systému. Komponenta systému Podpora životního cyklu zadávacích postupů Podpora dalších institutů ZVZ a KZ Průřezové funkcionality zadávacích postupů Registrace a správa subjektů Registrace a správa uživatelů Řízení oprávnění přístupových Hlavní funkční požadavky na systém NEN bude informačně podporovat celý životní cyklus jednotlivých zadávacích postupů v rozsahu uvedeném v procesním modelu a v požadavcích na funkcionality NEN a požadavcích na vlastnosti NEN. 2.3 Popis a obsahové vymezení NEN. NEN bude obsahovat komplexní podporu jednotlivých institutů upravených v ZVZ a KZ (či daných obecnou zadavatelskou praxí). Mezi tyto instituty patří např. dělení VZ na části, výhrada a využití opčního práva, zvýhodnění dodavatelů zaměstnávajících osoby se zdravotním postižením, připuštění variant nabídky atd. Tyto instituty může a nemusí zadavatel zařadit do životního cyklu příslušného zadávacího postupu. NEN rovněž zadavatelům umožní omezenou parametrizaci funkcionality NEN tak, aby zadavatelé mohli jednotlivé instituty automaticky zařadit do průběhu zadávacího postupu či naopak znemožnit jejich využívání v organizaci zadavatele. Rozsah podpory jednotlivých institutů ZVZ a KZ je uveden v kapitole Podporované zadávací postupy. NEN bude obsahovat sadu funkcionalit, která bude konzistentní pro všechny zadávací postupy, spočívající zejména ve vedení evidenčních čísel zadávacích postupů; správě zadávacích postupů; vedení registrů smluv, objednávek a plnění; uveřejňování informací apod. Systém musí poskytnout funkcionalitu pro registraci subjektů (zadavatelů/dodavatelů) prostřednictvím veřejně přístupné části systému, následné zpracování žádostí o registraci na straně provozovatele systému a registraci subjektu do systému. Součástí systému musí být rovněž robustní podpora modelování organizační struktury instituce umožňující přenesení hierarchicky uspořádaných organizačních struktur zadavatelů a dodavatelů do NEN. Systém musí umožnit odpovědným osobám jednotlivých subjektů registraci dalších uživatelů systému a správu základních informací o uživatelích. Systém nabídne robustní nastavení přístupových oprávnění umožňující: určit přístup uživatele k určitým datům, umožnit uživateli použití určité funkcionality. Dokument: NEN Technická specifikace Strana 22 z 73

23 Každý z uživatelů systému bude v rámci systému vystupovat prostřednictvím uživatelských rolí zařazených v organizační struktuře zadavatele/dodavatele. Systém tedy vyhodnotí uživatele jako oprávněného provést určitou operaci pokud: jeho role smí provést danou operaci a zároveň uživatel smí manipulovat s daty zasaženými operací v požadovaném rozsahu. Právo provést danou funkcionalitu bude dáno taxativním výčtem pro jednotlivé uživatelské role v systému. Právo manipulovat s daty bude odvozeno od: umístění role v rámci organizační struktury a volby, zda se práva vztahují pouze na organizační útvar, ke kterému je role přidělená uživateli umístěna, nebo i na podřízené organizační útvary, omezení na data, tj. zda smí uživatel přistupovat pouze k datům aktivních veřejných zakázek, zda smí přistupovat také k datům uzamčených veřejných zakázek nebo pouze k datům jedné konkrétně určené veřejné zakázky. Práce s dokumenty Správa šablon pro generování dokumentů Práce s formuláři Systém umožní uchovávání nestrukturovaných informací týkajících se zadávacích postupů prostřednictvím přiřazení dokumentů (souborů) k danému zadávacímu postupu. Součástí uchovávání dokumentů bude rovněž podpora pro správu jejich verzí, konverze do formátu pdf/a. Pro efektivnější práci s dokumenty (např. při vyhledávání či popisování jejich obsahu) bude ke každému z dokumentů přiřazena sada strukturovaných metadat, případně volitelně také klíčových slov. Systém nabídne svým uživatelům robustní podporu pro generování dokumentů (v podobě následně upravitelné standardními textovými editory), jejichž obsah bude založen na informacích uchovávaných systémem. Uživatelé budou moci jak přejímat šablony vytvořené správcem systému, tak tvořit dle předepsaných pravidel vlastní. Systém umožní vkládat data rovněž ve strukturované podobě prostřednictvím formulářů. Součástí logiky každého formuláře bude validace vkládaných dat mj. i ve vztahu k jejich správnosti s ohledem na příslušné právní předpisy. Dokument: NEN Technická specifikace Strana 23 z 73

24 Uživatelské pohledy PKI Komunikace Klasifikace a číselníky Uživatelské pohledy umožní zobrazení sady předdefinovaných náhledů na systémem evidované informace vážící se k uživatelem zvolenému zadávacímu postupu. Systém umožní použití a ověření elektronických podpisů, elektronických značek a kvalifikovaného časového razítka všude tam, kde je to pro daný úkon vyžadováno zákonem, případně vhodné ve vztahu k vyšší míře ověření identity subjektu či osoby zadavatele/dodavatele. Systém umožní vzájemnou komunikaci mezi uživateli systémů prostřednictvím interního mailboxu. Ten nabídne funkcionalitu známou ze standardních ových klientů. Umožní však zajištění nepopiratelnosti a integrity vyměňovaných správ ve vztahu k systému. Komunikace bude umožněna rovněž s kontaktními osobami tzv. předběžně registrovaných subjektů, a to prostřednictvím jejich zavedení do systému, na základě kterého jim bude zřízen dočasný mailbox (do momentu registrace subjektu, pod který spadají). Systém musí umožnit administraci a použití následujících kategorií číselníků a klasifikací: Číselníky a klasifikace spravované správcem systému Klasifikace CPV Doplňkový slovník CPV Číselník NIPEZ Fáze životního cyklu Číselník úkonů, uživatelských operací a činností nástroje Číselník nestandardních stavů Číselníky a klasifikace provozované ČSU (jejichž aktualizace bude úkolem provozovatele systému) Číselník měn a fondů Číselník zemí Právní forma organizace Klasifikace územních statistických jednotek Číselník základních územních jednotek Číselníky spravované zadavatelem Číselník zadavatele Pro administraci číselníků, které mohou být spravovány i v jiných systémech, bude možné číselník importovat případně exportovat z/do strukturovaného souboru. Dokument: NEN Technická specifikace Strana 24 z 73

25 Záznamové soubory Veškeré změny v číselnících budou verzovány a bude možné zrekonstruovat číselník k požadovanému datu. Pro zajištění vysoké míry transparentnosti a prokazatelnosti všeho, co se odehraje v systému, budou vznikat záznamové soubory o všech provedených elektronických úkonech, uživatelských operacích a činnostech nástroje. Uživatelskou operací je chápána každá funkcionalita systému, která je: přímo iniciovaná uživatelem systému a vede k vytvoření, zobrazení, importu, exportu, úpravě, smazání, vyhledání či zobrazení seznamu dat. Činností nástroje je chápana každá činnost, která: není přímo iniciovaná uživatelem systému a je vyvolaná systémem (např. ová notifikace, automatické ověření elektronického podpisu atd.) a vede k vytvoření, importu, exportu, úpravě, smazání, vyhledání či zobrazení seznamu dat. Elektronickými úkony jsou chápány úkony učiněné dodavateli vůči zadavatelům a zadavateli vůči dodavatelům při zadávaní veřejných zakázek prostřednictvím systému, úkony jednající osoby provedené v zadávacím řízení prostřednictvím elektronického nástroje, nebo úkony učiněné systémem v rámci zadávaní veřejných zakázek prostřednictvím systému. Provedení uživatelské operace nebo činnosti nástroje často vede k provedení elektronického úkonu. V tom případě je zaznamenána jak uživatelská operace, nebo činnost nástroje, tak elektronický úkon. Systém zajistí přístup k těmto záznamovým souborům vybraným uživatelům zadavatele/dodavatele. Tabulka 2:Vymezení komponent systému Logické komponenty SW architektury NEN Systémový integrátor bude systém NEN realizovat ve funkčních blocích logických komponentách, které pokrývají požadovanou funkcionalitu. Uspořádání navržených logických komponent (modulů) je zachyceno na následujícím obrázku. Dokument: NEN Technická specifikace Strana 25 z 73

26 Schéma 4 Vazby mezi logickými komponentami SW architektury Legenda k obrázku: Základní logická komponenta SW architektury Základní komponenta poskytující služby uživatelům nebo ostatním komponentám systému. Komponenta už se dále skládá z technologických artefaktů řešení jako je kód aplikační a prezentační logiky. Podpůrná logická komponenta SW architektury Komponenta řešení poskytující technické služby ostatním komponentám. Komponenta už se dále skládá z technologických artefaktů řešení, jako je kód aplikační logiky. Závislost mezi komponentami Závislost mezi komponentami. Např. komponenta Řízení Zadávacích Postupů používá v Zadávacím Postupu elektronickou aukci. Tuto funkcionalitu poskytuje komponenta eaukce. Proto je komponenta Řízení Zadávacích Postupů závislá na komponentě eaukce Funkčním srdcem systému je komponenta Řízení Zadávacích Postupů, kde probíhají vlastní procesy Zadávacích Postupů. Na tuto komponentu jsou navázány další logické komponenty, které přímo interagují s uživateli: Informační deska veřejný web řešení Dokument: NEN Technická specifikace Strana 26 z 73

27 Správa profilů komponenta pro registraci subjektů a organizací, administraci uživatelů, správu organizační struktury, správu číselníkových hodnot vázaných na organizace, správu šablon a podobné eaukce komponenta pro běh aukcí (aukční síně) Webové formuláře komponenta pro návrh a běh webových formulářů pro automatické a poloautomatické hodnocení nabídek Komunikace systém pro off-line komunikaci mezi uživateli systému NEN Číselníky systém centrálních číselníků Kromě komponent, které poskytují služby pro uživatele, jsou v řešení i významné podpůrné komponenty: Notifikace systém odesílání ů dle uživatelských preferencí (z komponenty Správa profilů), sledování lhůt Integrační služby vazba mezi systémy a zejména vazba okolní systémy (IS VZ, IS VZ US, ARES, Spisové služby, etržiště ) Reporting zpracování statistických údajů NEN analýzou uložených dat Generátor dokumentů komponenta pro generování dokumentů v systému NEN Client PKIa Server PKI- komponenty pro zajišťování služeb v oblasti podepisování a šifrování Řízení Zadávacích Postupů Stěžejní role hlavní komponenty Řízení Zadávacích Postupů je v přímé podpoře životního cyklu zadávacích postupů. V oblasti přípravy zadávacích postupů zajišťuje jejich plánování a specifikaci. V průběhu vyhlášení a příprav nabídek dodavateli poskytuje funkcionalitu poskytování zadávací dokumentace a pro příjem a zpracování žádostí o dodatečné informace včetně jejich publikace. Dále umožňuje přípravu a podání nabídek elektronickými prostředky a podporu návazné práce s přijatými nabídkami na straně zadavatele evidence přijatých nabídek, jejich otevírání, posuzování a hodnocení, přičemž zohledňuje míru elektronizace, která byla při konkrétním zadávacím postupu zvolena. Z průřezových funkcionalit zajišťuje mimo jiné implementaci ad-hoc procesů vázaných na body návratu nestandardní situace. Pro podporu VZMR je v komponentě Řízení Zadávacích Postupů realizován aparát, který zadavateli umožňuje nastavit parametry, na základě kterých budou VZMR individuálně zpracovávány. V oblasti podpory dalších institutů ZVZ a KZ zajišťuje komponenta Řízení Zadávacích Postupů podporu pro centralizované zadávání, realizuje se v něm Dynamický nákupní systém a vazbu na případné aukce realizované komponentou eaukce. Komponenta Řízení Zadávacích Postupů dale obsahuje registr smluv, objednávek a plnění. Protože je komponenta Řízení Zadávacích Postupů postavena na robustním Document Management Systému, realizuje take komplexní podporu práce s dokumenty jejich vkládání včetně generování ze šablon a jejich správa, mazání a obnovování, vkládání editace a mazání Dokument: NEN Technická specifikace Strana 27 z 73

28 metadata a klíčových slov, uchovávání a zobrazování jejich verzí a vyhledávání v nich. Zároveň komponenta Řízení Zadávacích Postupů využívá formulářový systém, pomocí kterého zajišťuje požadované fukcionality v souvislost s formuláři. Konkrétně se jedná o tvorbu formulářů, jejich správu, verzování, předvyplňování a validaci. Pro realizaci komponenty byly vybrány technologické komponenty SW architektury: IBM Case Manager IBM Forms Informační deska Jednou z hlavních logických komponent řešení je Informační deska, která zajišťuje požadavky kladené na Uveřejňování a zpřístupňování informací, tedy publikaci veřejných informací, které nevyžadují přihlášení uživatele. Bude tedy zajišťovat Věstník NEN zobrazující chronologicky seřazené veřejné informace z NEN, informace o zadávacích postupech realizovaných v NEN, publikaci všech veřejných informací o registrovaných subjektech včetně předběžně registrovaných. Dále bude zobrazovat souhrnné statistické informace o zadávacích postupech s možností exportu dat a informace o provozu systému NEN. Kromě toho bude Informační deska zajišťovat publikaci Profilu zadavatele včetně jeho veřejných dokumentů a informací o jeho zadávacích postupech. Provoz komponenty Informační deska je zajištěn pomocí standardní technologické komponenty: IBM WAS runtime infrastruktura IBM WebSphere Application Server ND Komponenta je technologicky realizována jako standardní webová aplikace sloužící jako vstupní bod pro přístup uživatelů k systému. Jak je patrné již z názvu, aplikace řeší funkcionalitu Informační deska NEN a také zobrazování profilů zadavatelů. Komponenta je pro uživatele vstupním bodem do systému (úvodní stránka bude mapována na hlavní webovou adresu systému NEN). Z uživatelského rozhraní této komponenty je dále možný přístup na uživatelské rozhraní následujících komponent: Řízení Zadávacích Postupů dříve popsaná hlavní komponenta řešení, kterou uživatelé používají v rámci procesů Zadávacích Postupů Správa profilů komponenta pro registraci subjektů a organizací, administraci uživatelů, správu organizační struktury, správu číselníkových hodnot vázaných na organizace, správu šablon a podobné Komponenta Informační deska získává data z komponent: Dokument: NEN Technická specifikace Strana 28 z 73

29 Řízení Zadávacích Postupů publikace informací o ZP v kontextu procesů např. uveřejnění Veřejné Zakázky, dodatečné informace Publikace je řízena procesy v komponentě Řízení Zadávacích Postupů (tak je zajištěna publikace informací ve správný okamžik podle typu ZP) Reporting veřejné statistické informace o provozu systému NEN Správa profilů získání informací do veřejného profilu zadavatele, registru subjektů Kromě vazby na výše zmíněné komponenty obsahuje komponenta Informační deska redakční systém, který umožňuje publikaci informací spadajících do oblasti Informace týkající se provozu NEN. Správa profilů Komponenta Správa profilů integruje veškeré informace o subjektech a jejich uživatelích, které se systémem NEN pracují. Prostřednictvím komponenty Správa profilů je řízena registrace a správa subjektů i registrace a správa uživatelů včetně kompletní a komplexní správy přístupových oprávnění, organizační struktury a uživatelských preferencí. Kromě toho je pak komponenta Správa profilů zdrojem informací o subjektech. Tyto informace jsou parametry, jež ovlivňují funkce vykonávané jinými komponentami. Proto jsou díky komponentě Správa profilů podpořeny funkcionality v oblastech předvyplňování formulářů, správy šablon nebo podpory životního cyklu zadávacích postupů. Součástí komponenty Správa profilů je také administrátorské rozhraní systému NEN (nejedná se o administrační rozhraní technologických komponent jako např. IBM WebSphere Application Server). Přes administrátorské rozhraní administrátoři systému mohou vkládat např. informace o stavu systému. Z technického pohledu komponenta Správa profilů v návaznosti na pokrývané funkční oblasti zajišťuje komplexně problematiku identity managementu (správu uživatelů v systému a jejich role) a to jak uživatelů v podobě osob, tak uživatelů technologických jako jsou navázané systémy typu IEN, etržiště nebo ESS. Provoz komponenty je zajištěn pomocí standardních technologických komponent: IBM WAS runtime infrastruktura IBM WebSphere Appliaction Server ND IBM Case Manager např. pro správu šablon dokumentů, které jsou uloženy v profilu organizace LDAP Server Technicky je komponenta realizována jako webová aplikace s tím, že je těsně schopna spolupracovat s komponentou Řízení Zadávacích Postupů a to včetně přenosu identity uživatele bez nutnosti přihlašování tzv. SingleSign On). Pro interní komponenty řešení je vystaveno rozhraní na principu Servisně Orientované Architektury (SOA). Dokument: NEN Technická specifikace Strana 29 z 73

30 eaukce Komponenta eaukce zajišťuje běh elektronických aukcí v systému NEN. V zásadě komponenta realizuje funkcionalitu aukční síňě s tím, že konfigurace aukce je přenášena do komponenty z komponenty Řízení Zadávacích Postupů ve vazbě na použití e-aukce v Zadávacím Postupu. V rámci této komponenty dodavatelé mění své nabídky, komponenta po každé změně nabídky přepočítá pořadí a ihned o změněném pořadí informuje všechny účastníky aukce. Kromě změn nabídek zajišťuje komponenta také on-line komunikaci mezi zadavateli a dodavateli formou dotazů a odpovědí. Vzhledem ke složitosti uživatelského rozhraní aukčních systémů a možnosti účastnit se více aukcí současně se předpokládá, že se aukční síň bude otevírat jako nové okno internetového prohlížeče (tento mechanismus umožňuje sdílení odkazu na aukční síň ve formě webové adresy). Technicky je proto komponenta realizována jako samostatná webová aplikace s tím, že je těsně schopna těsně spolupracovat s komponentou Řízení Zadávacích Postupů (včetně přenosu identity uživatele bez nutnosti přihlašování tzv. SingleSign On). Výměna dat mezi komponentou eaukce a komponentou Řízení Zadávacích Postupů probíhá prostřednictvím služeb, které si komponenty navzájem vystavují. Provoz komponenty je zajištěn pomocí standardní technologické komponenty: IBM WAS runtime infrastruktura IBM WebSphere Appliaction Server ND Při návrhu a realizaci komponenty se bere v potaz důraz na maximální rovnou šanci všech dodavatelů. Bude využit princip Comet programování (long polling), který zajistí maximálně současnou informaci všech uživatelů aukční sítě v okamžiku, kdy je dokončena důležitá změna (např. přepočet pořadí po zaslání nové nabídky nebo zaslání odpovědi na dosah). Tento systém přináší výrazně lepší výsledky než často používaný intervalem řízený refresh (obnova) stránky a to nejen v rychlosti notifikace uživatelů, ale také přináší lepší ergonomii (nedochází k blikání při překreslování) a v neposlední řadě klesá počet požadavků, které musí obsloužit aplikační server (s poklesem počtu zpracovávných požadavků klesá zátěž systému a při zachování výkonnosti HW může klesat doba odezvy, která je jedním z klíčových faktorů spokojenosti uživatelů). Princip long pollingu a Comet programování používají pro své on-line služby společnosti jako např. Google (např. googletalk pro chat nebo v portálu igoogle) nebo Facebook, které pracují s velkým množstvím současně připojených uživatelů. Webové formuláře Komponenta Webové formuláře zajišťuje podporu elektronického podávaní nabídek prostřednictvím webového formuláře pro tvorbu nabídky a webového formuláře pro účely hodnocení, jejich přípravu, generování. Funkčnosti této komponenty jsou spuštěny a tím i využívány z komponenty Řízení Zadávacích Postupů podporují tím specifikaci zadávacího postupu, práci s nabídkami a hodnocení nabídek v rámci podpory životního cyklu zadávacích postupů. Komponenta Webové formuláře umožňuje vytvářet a využívat formuláře (dotazníky) koncovým uživatelům systému (na rozdíl od fomulářů nad technologií IBM Forms, které jsou spravovány vývojáři). Takto vytvořené formuláře jsou následně počítačem zpracovatelné a umožňují tak automatické nebo případně poloautomatické vyhodnocení nabídek. Nedílnou Dokument: NEN Technická specifikace Strana 30 z 73

31 součástí webových formulářů pro podávání nabídek je také podpora šifrování a jejich digitální podpis pomocí privátního klíče C1 dodavatele (s podporou komponenty Client PKI). Komponenta Webové formuláře pokrývá následující funkcionalitu: Návrh formuláře komponenta umožňuje návrh formuláře koncovým uživatelem systému v procesu specifikace Zadávacího Postupu o Sekce obsahující jednotlivé položky dodavatele (formou tabulky) včetně konfigurace algoritmu hodnocení Použití formuláře komponenta pro běh formuláře o Zobrazení formuláře v kontextu podávání nabídky Dodavatel (nebo Zadavatel v případě manuálního přenosu dat po otevření obálek) odpovídá na otázky v dotazníku Přikládání příloh Šifrování a digitální podpis nabídky a vložení do systému (do složky dodavatele) o Zobrazení formuláře v kontextu otevírání obálek Dešifrování nabídek na klientské stanici oprávněného člena komise pro otevírání obálek Dešifrované formuláře se vkládají zpět do systému pro jejich následné hodnocení v systému Manuální přenos dat z nabídky v nestrukturované podobě (elektronický dokument nebo papírová forma, je-li připuštěna) o Zobrazení formuláře v režimu hodnocení při poloautomatické metoda hodnocení Doplnění honocení u položek, které není možno zpracovat automaticky (např. textové položky) o Automatické vyhodnocení vložených informací (na základě všech platných vložených vyplněných formulářů) včetně uložení výsledku automatického hodnocení Provoz serverové části komponenty je zajištěn pomocí standardních technologických komponent: IBM WAS runtime infrastruktura IBM WebSphere Appliaction Server ND IBM Case Manager ukládání definice formulářů, vyplňených dotazníků a nabídek a jejich zpřístupnění v kontextu procesů Zadávacího Postupu Provoz klientské části komponenty je podporován pomocí Java Runtime Environment formou Java Appletu integrovaného do webových stránek komponenty Řízení Zadávacích Postupů. Řešení postavené na Java Appletu umožňuje využití komponenty Client PKI pro realizaci šifrování, dešifrování a digitálního podepisování na pracovní stanici uživatele. Pro práci Dokument: NEN Technická specifikace Strana 31 z 73

32 se soubory se využívají standardní služby poskytované komponentou Řízení Zadávacích Postupů. Definice formulářů a stejně tak jako vyplněná data jsou spravovány jako dokumenty přes technologickou komponentu IBM Case Manager (včetně podpory verzování). Práce s formuláři jako s dokumenty poskytuje zvýšenou ochranu datům díky jejich uložením do komponenty IBM Information Archive, která představuje jeden z klíčových bezpečnostních prvků řešení pro ochranu dat a to jak před neoprávněnými uživateli, tak před pracovníky provozovatele. Reporting Komponenta Reporting pokrývá požadavky v oblasti sběru dat o událostech zejména v probíhajících Zadávacích Postupech, a to ze všech komponent řešení. Pro sběr událostí bude použita služba komponenty Řízení Zadávacích Postupů, kterou ostatní komponenty/moduly budou využívat. Tyto informace se zde dále zpracovávají a komponenta se tak stává důležitým zdrojem statistických informací a to jak pro systém NEN (např. informace poskytované na Informační desce NEN) tak např. pro systém IS VZ. Provoz komponenty je zajištěn pomocí standardní technologické komponenty: IBM Case Manager kde se využívají nástroje auditu pro sběr dat událostí a následně pro jejich statistické zpracování Komponenta Reporting poskytuje data pro následující komponenty: Informační deska publikace statistických informací pro veřejnost Integrační služby - statistické informace do integrovaného systému IS VZ Integrační služby Komponenta Integrační služby pokrývá oblast požadavků výměny dat s navazujícími systémy. Jedná se např. o rozhraní s IS VZ, kam se poskytují různé statistické informace, vazby na systémy organizací (spisová služba), vazba na IS VZ US pro uveřejňování Zadávacích Postupů, použití systému ARES, vazby na systémy ESS nebo IEN Provoz komponenty je zajištěn pomocí standardní technologické komponenty: IBM ESB Integrace probíhá na principu Servisně Orientované Architektury (SOA) s využitím vhodných EAI návrhových vzorů např. využití asynchronního přenosu zpráv pomocí spolehlivého přenosu zpráv na principu MOM (Message Oriented Middleware). Je navrhováno využití asynchronních přístupů snižujících riziko technologické závislosti systému NEN na okolních systémech (např. dočasná nedostupnost systému IS VZ US nemůže přerušit činnost nástroje NEN). Technologicky Dokument: NEN Technická specifikace Strana 32 z 73

33 bude využit standard JMS (Java Messaging Service) zajištěný pomocí technologické komponenty IBM ESB. Integrační rozhraní systému NEN je otevřeno do Internetu. Proto je z bezpečnostních důvodů navrženo posílení zabezpečení integračních rozhraní pomocí bezpečnostní brány tzv. Service Gateway, která bude analyzovat provoz na vrstě aplikačního protokolu (např. XML a SOAP), kde standardní síťové firewally nepřináší přidanou hodnotu (např. ochrana před útoky spojenýmy s XML jak např billion laughs attack či SQL Injection). Navrhované řešení také zajistí vynucení Service Level Management politik (např. omezení max. počet requestů za minutu tzv. traffic shaping) a bude tak chránit tak NEN infrastrukturu před přetížením nevhodným použitím. Komunikace Komponenta Komunikace pokrývá oblast požadavků off-line komunikace mezi uživateli systému (včetně uživatelů neregistrovaných). Každý uživatel systému bude mít vytvořenou virtuální poštovní schránku. Technicky je komponenta realizována jako webová aplikace, která je těsně spojena s komponentou Řízení Zadávacích Postupů a to včetně přenosu identity uživatele bez nutnosti přihlašování tzv. SingleSign On. Provoz komponenty je zajištěn pomocí standardních technologických komponent: IBM WAS runtime infrastruktura IBM WebSphere Appliaction Server ND pro běh aplikační logiky IBM Case Manager ukládání zpráv do složek a zobrazení uživatelského prostředí Notifikace Komponenta Notifikace zajišťuje požadavky v oblasti informování uživatelů o relevantních aktivitách systému NEN. Informování uživatelů bude realizováno formou odesílání ů ze systému NEN a to buď ve vazbě na procesy Zadávacích Postupů, nebo jejich lhůty. Jedná se o centrální komponentu, která může zajistit správnou distribuci informací o událostech v souladu s preferencemi uživatele. Provoz komponenty je zajištěn pomocí technologických komponent: IBM WAS runtime infrastruktura IBM WebSphere Application Server ND SMTP Server Z hlediska způsobu implementace komponenty Notifikace se jedná o vývoj v JEE s využitím Java Mail API. Dokument: NEN Technická specifikace Strana 33 z 73

34 Číselníky Komponenta Číselníky poskytuje functionality nezbytné pro vytvoření, editaci a správu všech sdílených číselníků systému NEN (Klasifikace CPV včetně doplňkového slovníku, číselník NIPEZ, e-tržišť, IEN, číselník nestandardních stavů, číselník měn a fondů, apod.). Komponenta dále zabezpečuje export a import číselníků. Komponenta Číselníky zpřístupní číselníkové hodnoty pro použití v uživatelském rozhraní systému: Poskytnutím tzv. pickerů dialogová okna, která umožní uživateli výběr chodné hodnoty a zajistí její vložení do formulářového pole Poskytnutím služeb pro dotahování hodnot Číselníky budou v systému realizovány tak, že historické hodnoty budou v číselníku zachovány. Budou pouze zneplatněny tak, aby si je uživatel již nemohl dále vybírat přes výše zmíněné pickery (dialogová okna). Systém stanovení platnosti umožní ne jen historizaci hodnot číselníků, ale také možnost definování číselníkových hodnot do budoucna (hodnoty platné od nastaveného data). Tento mechanismus zvyšuje flexibilitu řešení a usnadňuje mechanismus řízení změn (např. po změně legislativy, která je vždy vázána k určitému datu v budoucnosti). Provoz komponenty je zajištěn pomocí standardní technologické komponenty: IBM WAS runtime infrastruktura IBM WebSphere Appliaction Server ND Generátor dokumentů Komponenta Generátor dokumentů zajišťuje generování dokumentů a formulářů do různých formátů (včetně případné konverzi do PDF-A nebo editovatelného formátu u uživatelských dokumentů). Pro generování dokumentů bude použit mechanismus šablony (template). Úkolem volající komponenty (např. Řízení Zadávacích Postupů) bude: Připravit business data, načíst šablonu a zaslat šablonu a data na komponetu Generátor dokumentů. Komponenta zajistí aplikaci šablony na zaslaná data (tzv. merge). Šablona obsahuje reference na business data. Jsou-li business data nalezena nalezena na vstupu do komponenty, jsou tato dosazena na místa těchto referencí. Šablony budou definovány pomocí formátu rtf, který může koncový uživatel připravit v nejrůznějších textových editorech (MS Office, OpenOffice, IBM Lotus Symphony ). Provoz hlavní části komponenty je zajištěn pomocí speciální komponenty vyvinuté nad aplikačním rozhraním OpenOffice. Pro doplňkovou funkcionalitu konverze interních formulářů do PDF-A realizovaných nad technologií IBM Forms bude realizováno pomocí vestavěné funkcionality poskytované touto technologií Dokument: NEN Technická specifikace Strana 34 z 73

35 Konverze a generování dokumentů jsou výkonově náročné operace, proto budou v komponentě realizovány jako asynchronní a budou provozovany tak, aby negativně neovlivňovaly chování uživatelského interface. Funkčnost komponenty Generátor dokumentů se z ostatních komponent využívá přes komponentu Integrační služby. Client PKI Podpůrná komponenta, která pokrývá požadavky v oblasti digitálního podepisování a šifrování na klientské straně a umožňuje: Digitální podpis dokumentů a souborů (včetně klientského podpisu dokumentů typu PDF-A) Šifrování souborů (např. nabídek) před jejich vložením na serverovou část systému NEN Dešifrování stažených souborů (např. nabídek při otevírání obálek) Tato komponenta musí běžet na klientské stanici tak, aby šifrováním byla skutečně ochráněna uživatelská data (zejména nabídky). Stejně tak klientský digitální podpis musí proběhnout na straně klientské pracovní stanice, protože uživatel nesvěří žádnému řešení svůj privátní klíč, který je k realizaci systému nutný. Běh komponenty na klientské stanici přesahuje standardní možnosti internetového prohlížeče. Proto bude realizována speciální komponenta, která tuto funkcionalitu zajistí. Server PKI Podpůrná komponenta, která pokrývá požadavky v oblasti digitálního podepisování a šifrování na straně serveru a umožňuje: Verifikaci digitálních podpisů (např. verifikace podpisu nabídky) Digitální podpis dokumentů a souborů (značka) Časové razítkování dokumentů a souborů Technologické komponenty SW architektury NEN Technologické komponenty SW architektury představují další úroveň SW architektury, která zajištuje potřebnou technologickou podporu pro funkčnosti logických komponent SW architektury. Na následujícím obrázku je uvedeno schéma technologických komponent SW architektury včetně vzájemných vazeb. Dokument: NEN Technická specifikace Strana 35 z 73

36 Schéma 5 Vazby mezi technologickými komponentami SW architektury Legenda k obrázku: Komplexní technologická komponenta SW architektury Komplexní komponentu je možno dále rozdělit na další dílčí komponenty. Technologická komponenta SW architektury Klíčové technologické SW komponenty řešení. Infrastrukturní technologická komponenta SW architektury Obecná SW komponenta. Nespecifická komponenta řešení IBM Case Manager může pracovat s různými relačními databázemi, celé řešení může používat různé LDAP server a podobně. HW komponenta HW komponenta ovlivňující koncept SW architektury řešení. Např. IBM Information Archive je vhodný pro bezpečné ukládání dokumentů a není nutno díky použití této komponenty řešit SW ochranu dokumentů (např. šifrování). Závislost mezi komponentami Závislost mezi komponentami. Např. komponenta IBM Forms používá pro svůj běh komponentu IBM WAS. Dokument: NEN Technická specifikace Strana 36 z 73

37 Storage není SW komponenta, jedná se o komponentu HW, která ale ovlivňuje výsledný design SW architektury. Ve schématu je zaneseno zejména z důvodu vysvětlení, jak jsou ukládánan data a také celkové konzistence s vysvětlením použití specializovaného zařízení IBM Information Archive použitého pro ochranu dokumentů. Spolehlivé (redundantní) a zálohované diskové pole, kde jsou umístěna data systému (zejména runtime image operačních prostředí komponent, data relační databáze a transakční logy). V popisech jednotlivých technologických komponent jsou mimo jiné uvedeny SW produkty, pomocí kterých je běh a funkcionalita technoligických komponent zajišťována. IBM Case Manager IBM Case Manager je technologická komponenta, která podporuje realizaci a běh komponenty Řízení Zadávacích Postupů. Schéma 6 Vnitřní struktura technologické komponenty IBM Case Manager Technologická komponenta IBM Case Manager je založená na platformě IBM Case Management, která představuje vývojové a runtime (běhové) nástroje řešení a zastřešuje následující SW produkty: IBM FileNet P8 CE DMS systém pro správu dokumentů a dat IBM FileNet P8 PE procesní nástroj pro běh business procesů spojených se zadáváním Veřejných Zakázek (tasků) IBM jrules business pravidla, která umožňují, jsou-li použita modifikovat chování systému bez změny kódu IBM Case Analyzer nástroj pro vytváření statistických informací z průběhu případů Dokument: NEN Technická specifikace Strana 37 z 73

38 IBM WAS Technologická komponenta IBM WAS představuje runtime infrastrukturu pro různé komponenty řešení tzv. Aplikační server. IBM WAS umožňuje Active-Active clustering, který zajišťuje vysokou dostupnost z pohledu koncových uživatelů. Aplikační server WAS poskytuje: Webový kontejner EJB kontejner Komponenty pro loadbalancing Spolehlivý Java Messaging Service (JMS) Resource adaptéry pro přístup k dalším komponentám (např. RDBMS nebo SMTP server) IBM WAS umožňuje Active-Active clustering (včetně replikace stavu např. HttpSession). Technologická komponenta IBM WAS využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM WebSphere Application Server Network Deployment (IBM WASND)- spolehlivý a výkonný JEE (Java Enterprise Edition) aplikační server, který umoňuje spolehlivý běh aplikací ve vysoce dostupném prostředí IBM Forms Runtime komponenta IBM Forms zajišťuje platformu pro běh části uživatelského prostředí formulářů. Technologie IBM Forms umožňuje RAD (Rapid Application Development rychlý vývoj) přístup k vývoji uživatelského prostředí pro zadávání a prohlížení dat pomocí nástroje IBM Forms Designer. Za provozu pak zajišťuje běh formulářů, zejména rendering (neboli vykreslení v požadované formě) a obsluhu událostí tzv. IBM Forms Server. Na Forms serveru je udržován odraz formuláře (k propagaci změněných hodnot je využit asynchronní JavaScript). IBM Forms Server je plně integrován do prostředí IBM Case Manager a formuláře se tak mohou stát nedílnou součástí uživatelského prostředí. Kromě validací hodnot na serveru, což je zásadní z pohledu bezpečnosti (klient není schopen na server protlačit nevalidní data rozklíčováním kontrolních mechanismů), server zajistí také případnou změnu uživatelského prostředí (např. řízení toku stránek v průvodcích) nebo komunikaci s backend službou. Princip práce komponenty IBM Forms při práci uživatelů s formuláři je naznačen na následujícím obrázku, kde je příklad fungování ilustrován na dotažení informací ze systému ARES: Dokument: NEN Technická specifikace Strana 38 z 73

39 Schéma 7 Princip práce komponenty IBM Forms při práci uživatelů s formuláři Runtime platforma IBM Forms umožňuje nejen zobrazení formulářů jako formulář v HTML pro vyplnění uživatelem, ale zároveň je schopna přeložit formulář i do formátu PDF nebo PDF-A. Jak šablony (zdrojové formuláře), tak jejich konkrétní instance (instancí se rozumí formulář naplněný daty v kontextu konkrétního Zadávacího Postupu) jsou ukládány v systému jako IBM Case Manager jako dokumenty ve formátu XML. Tento přístup přináší již dříve zmíněnou možnost využití verzování (a to jak dat, tak formulářů) což usnadňuje změnové řízení i proto, že systém si sám udržuje vazbu mezi daty a správnou verzí formuláře pro jejich následní zobrazení. Technologická komponenta IBM Forms využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM Forms Server serverová komponenta zajišťující využívání formulářů při vlastním běhu systému NEN IBM Forms Designer nástroj pro návrh, customizaci, otestování a deploy jednotlivých formulářů využívaných především logickou komponentou Řízení Zadávacích Postupů IBM ESB Komponenta ESB je klíčovou komponentou pro podporu běhu komponenty Integračních služeb, která zajišťuje jednak propojení systému NEN s okoními systémy (např. IS VZ a IS VZ US nebo spisovými službami organizací) a také případné propojení komponent uvnitř systému (např. práce s logickou komponentou Generátor dokumentů). Pro návrh IBM ESB byl zvolen přístup federované ESB, kdy do demilitarizované zóny řešení bude umístěna Security Gateway, která bude chránit vnitřní ESB (realizující integrační logiku) a návazné systémy. Security Gateway zaručí, že žádný neprověřený provoz na integrační rozhraní systému neopustí demilitarizovanou zónu. Vzhledem k tomu, že systém NEN je otevřený a může se na něj připojovat celá řada navazujících systémů (zejména spisové služby dodavatelů) bude Security Gateway také vynucovat nastavená SLA tak, aby nedocházelo k přetěžování vnitřních komponent, které by mohlo vést na snížení užitné hodnoty řešení pro koncové uživatele. Dokument: NEN Technická specifikace Strana 39 z 73

40 Schéma 8 Vnitřní uspořádání technologické komponenty IBM ESB Vlastní ESB je založeno na standardním produktu IBM WebSphere ESB. Na této komponentě budou ralizovány vhodné mediace zajišťující potřebné informační scénáře. Komponenta ESB také zajistí spolehlivou platformu pro výměnu zpráv. Technologicky se bude jednat o Java Messaging Service (JMS). Technologická komponenta IBM ESB využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM WebSphere ESB IBM WebSphere DataPower špičková WebService Security Gateway (bezpečnostní brána s podporou authenikace a autorizace, filtrování obsahu, validace XML obsahu ) IT Monitoring Technoloigická komponenta IT Monitoring je složena z dílčích komponent, které umožňují sledování chování celého systému včetně monitoringu HW a SW vybavení. Komponenta IT Monitoring obsahuje: Transakční monitoring o Transakční monitoring umožňuje sledování chování systému z pohledu koncových uživatelů a vypovídá jednak o tzv. end-user-experience, která je dána z velké části rychlostí odezvy systému (je zdrojem informací o SLA z pohledu koncových uživatelů) a jednak sledováním trendů v oblasti vývoje doby odezvy či zvýšení poměru chybovosti může s předstihem informovat pracovníky provozovatele o problémech systému, které je tak možno proaktivně řešit. o Řešení poskytuje možnost robotického testování dostupnosti systému pro potřeby generování SLA reportů. Monitoring SW a HW vybavení o Diagnostika příčiny problému například v případě, kdy uživatelé nebo transakční monitoring zaznamenají zhoršení doby odezvy Provozovatel začne provádět sledování s využití drill-down principu na jednotlivách komponentách a je tak schopen najít různé příčiny nestandardního chování systému: Dokument: NEN Technická specifikace Strana 40 z 73

41 zhoršení doby odezvy může vycházet ze swappingu (odkládání paměti na disky má zásadní vliv na výkon libovolného systému) na jedné z image; Následně provozovatel může pro image přidat paměť. zhoršení doby odezvy může vycházet z nedostatku threadů v aplikačním serveru; následně může provozovatel přenastavit thread pool 2 v aplikačním serveru a pomocí monitoringu provést kontrolu, zda řešení chybu odstranilo (událost v monitoringovém nástroji je ukončena) zhoršení doby odezvy může vycházet z nedostatku připojení na relační databázi v aplikačním serveru; následně může provozovatel přenastavit connection pool v aplikační server a pomocí monitoringu provést kontrolu, zda řešení chybu odstranilo (událost v monitoringovém nástroji je ukončena) zhoršení doby odezvy může vycházet z výpadku HW databázové nebo aplikační vrstvy o Kapacitní plánování Monitoring průběžně sleduje využití prostředků systému a získaná data agreguje a ukládá do interní databáze. Na takto získaná data se aplikují statistické algoritmy a stanoví se trendy využití aplikační infrastruktury. Následně je pak pomocí reportů možné získat informaci o trendu využití HW a SW prostředků (RAM, CPU, kapacita úložišť), které umožňují provozovateli reagovat včas (proaktivně) na vzniklé situace. Bezpečnostní monitoring zahrnující o Sledování logů, jejich bezpečné úložiště, korelace událostí a vyhodnocování (Security Information and Event Management - SIEM) o Sledování a analýza síťového provozu na vstupu do aplikační logiky Technologická komponenta IT Monitoring využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM ITCAM for Transactions IBM ITCAM for Applications QRadar 2100 All-In-One Appliance IT Backup Technologická komponenta IT Backup zajišťuje zálohování a případnou obnovu pomocí páskové jednotky a knihovny. Zálohují se: Data relační databáze všech komponent Dokumenty 2 Aplikační servery IBM WebSphere Application Server využívají Thready (vlákna) pro zpracování aplikační logiky. Vytvoření a start vlákna jsou náročné operace, proto se využívá tzv. thread pooling, kde jsou thready předpřipraveny a za běhu přidělovány ke zpracování aplikační logiky. Dokument: NEN Technická specifikace Strana 41 z 73

42 Konfigurace aplikačních komponent Image virtuálních serverů aplikačních komponent pro jejich rychlou obnovu v případě výpadku Technologická komponenta IT Backup využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM Tivoli Storage Manager RDBMS Server Technologická komponenta RDBMS Server je definovaná jako relační databázový server pro ukládání vybraných relačních dat systému: Data případů, metadata složek a dokumentů, audit, úkoly, instance procesů Data komponent (např. eaukce, Informační deska, Integrační služby, statistická data komponenty Reporting ) Data technologických komponent (úložiště zpráv pro systém JMS) Technologická komponenta RDBMS Server využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM DB2 AESE SMTP Server Tato technologická komponenta představuje server pro odesílání elektronické pošty (standardní mailový server) podporující odesílání elektronické pošty pomocí protokolu SMTP (Simple Mail Transfer Protocol). Technologická komponenta SMTP Server využívá pro zajištění svého běhu a funkčnost následující SW produkty: Sendmail LDAP Server Komponenta LDAP server slouží jako nástroj pro authentikaci a autorizaci uživatelů pro přístup do systému NEN a jeho datům. Technologická komponenta LDAP Server využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM Tivoli Directory Server Dokument: NEN Technická specifikace Strana 42 z 73

43 IBM Information Archive Klíčová technologická komponenta pro bezpečné ukládání dokumentů. V navrhovaném řešení může být ukládána celá řada citlivých informací (včetně formulářů a nabídek). Je proto potřeba ochránit tato data před neoprávněným přístupem. K tomuto účelu je právě určen IBM Information Archive, který zajišťuje certifikované dlouhodobé a bezpečné uložení dat. Spojení IBM Information Archive jako bezpečné HW platformy s IBM Filenet P8 Content Managerem jako bezpečné SW platformy představuje implementaci důvěryhodného úložiště, které je certifikováno jako řešení, které splňuje požadavky úložiště dat pro spisové služby v těchto oblastech: Vyhlášky č. 191/2009 Sb. (16) Zákon č. 499/2004 Sb. (68, 69a) ČSN ISO/IEC Softwarové inženýrství, jakost produktu ČSN ISO/IEC Informační technologie, softwarové produkty Národní standard pro vedení elektronického systému spisové služby Technologická komponenta IBM Information Archive využívá pro zajištění svého běhu a funkčnost následující SW produkty: IBM Tivoli Storage Manager (TSM) - je však nedílnou součástí komponenty (i licenčně). IBM TSM je již z výroby nainstalován, předkonfigurován a obohacen o specializované nástroje jako např. průvodce pro nastavení systému SW produkty použité v rámci SW architektury NEN V této kapitole jsou popsané jednotlivé SW produkty, které budou použité v rámci systému NEN. IBM Advanced Case Management IBM Advanced Case Management integruje jednotlivé komponenty pro správu dokumentů, automatizaci procesů, správu komplexních podnikových pravidel, analytických nástrojů business intelligence a komunikaci do jednoduchého uživatelského prostředí. Hlavním stavebním kamenem platformy je IBM Case Manager, který dovoluje uživatelům spravovat strukturované a nestrukturované procesy a obsah dynamickým, flexibilním způsobem s vysokým stupněm spolupráce. Case Manager podporuje agilní metodologii pomocí poskytnutí prostředí, ve kterém může uživatel navrhovat, vyvíjet, validovat a testovat case solutions iterativně. Dokument: NEN Technická specifikace Strana 43 z 73

44 Schéma 9 IBM Advanced Case Management Obsah Umístěním modelu případu do úložiště obsahu mohou být informace a další artefakty související s případem nejenom prohlíženy, ale také řízeny v kontextu celého životního cyklu, což zahrnuje nejen dokumenty, ale také komunikaci, procesní kroky a další součásti případu. Proces (Workflow a události) V některých situacích mohou případy korespondovat se statickými procesy, zároveň ale mohou podporovat dynamické postupy, které se vyvíjí v závislosti na změnách, ke kterým dochází v průběhu zpracování případu. Obě varianty jsou IBM ACM podporovány. Monitoring a Analýza Analytické možnosti platformy IBM ACM pomáhají řešitelům přijímat správná rozhodnutí např. v případech neoprávněných nároků žadatelů sociálních dávek, zneužívání zdravotního pojištění, apod. Kromě toho je možné v reálném čase měřit a následně analyzovat průběhy zpracování případů a optimalizovat je na základě takto získaných výstupů. Dokument: NEN Technická specifikace Strana 44 z 73

45 Pravidla Mnohá rozhodnutí ovlivňující následné zpracování případu jsou závislá na konkrétních hodnotách, jako jsou čistý měsíční příjem žadatele, stupeň postižení, apod. Vyčleněním pravidel mimo zpracování případu a jejich jednotná správa pomocí business-rules enginu přináší možnost rychleji a pružněji reagovat na jejich změny. Integrace V mnoha situacích je vhodné v průběhu zpracování případu získávat relevantní data z externích zdrojů (např. z elektronické spisové služby, ekonomických nebo agendových informačních systémů, z portálu, apod.) Stejně tak je třeba určité údaje vzniklé v průběhu zpracování případu předávat vytvořené nebo zachycené údaje externím aplikacím. Platforma IBM ACM může být díky otevřenýn rozhraním integrována s jakýmkoli informačním systémem a eliminovat tak duplicitní zadávaní dat, zkrátitt dobu vyřízení či zvyšovat kvalitu dat. IBM FileNet P8 Platform Platforma IBM FileNet P8 je vysoce interoperabilní systém, který lze snadno integrovat do IT prostředí zadavatele. Systém je postaven na servisně orientované architektuře (SOA) a kombinuje v sobě Content Management (správa obsahu) a Process Management (procesy) s možnou konektivitou na jiné externí (produkční) systémy. Tato úzce integrovaná množina služeb umožňuje uživatelům rychlý přístup k důležitým obchodním informacím v bezpečném a škálovatelném prostředí. Architektura systému je flexibilní a široce škálovatelná, čímž umožňuje snadné rozšiřování kapacit pro ukládání dokumentů, počtu procesů a množství uživatelů systému. Systém poskytuje unikátní prostředí, připravené pro rychlé a jednoduché rozšiřování funkcionality existujícího řešení. Následující blokové schéma představuje pohled na celou platformu IBM FileNet P8 s logickým rozdělením do jednotlivých funkčních bloků a modulů. Dokument: NEN Technická specifikace Strana 45 z 73

46 Schéma 10 IBM FileNet P8 Platform ECM Platforma IBM Filenet P8 disponuje následujícími klíčovými vlastnostmi: Robustnost škálovatelnost a flexibilita jako základ integrovaného řešení pro správu obsahu a procesů Servisně orientovaná architektura (SOA) Řešení pro snazší dodržení shody s legislativou Sjednocení obsahu z různých zdrojů Podpora řady standardů a velké možnosti integrace Možnost využití nástrojů pro monitorování systému a výkonu v reálném čase IBM FileNet P8 Process Engine IBM FileNet P8 Business Process Engine (dále jen BPM) představuje samostatný modul, který rozšiřuje funkcionalitu CE (IBM FileNet P8 Content Engine). Vychází z jádra platformy IBM FileNet P8 a je navržen pro zajištění robustního systému určeného pro automatizaci, integraci a optimalizaci podnikových procesů, dále pak pro urychlení zásadních podnikových rozhodování, zvýšení organizační vnímavosti a efektivity a snížení celkových nákladů společnosti. Rozhraní pro definici procesu kombinovaného s událostmi řízenou (event-driven) architekturou Business Dokument: NEN Technická specifikace Strana 46 z 73

47 Process Management znamená schopnost vytvářet rychlé a současně robustní obchodní procesy rozvinuté v prostředí, které zahrnuje veškeré možné změny. BPM poskytuje unifikované procesní prostředí pro maximalizaci využití obchodních příležitostí, automatizaci a zjednodušení uživatelské práce, vše vyúsťující ve výrazné zvýšení produktivity. Schopnost opakovaně využít procesy umožňuje významnou úsporu času a nákladů spojených s vytvářením nových procesů nebo s úpravou procesů stávajících. V dnešním rychle se měnícím tržním prostředí je nesmírně důležité, aby společnosti vyhodnocovaly svou výkonnost nejen po etapách, ale také pomocí stále trvající aktivity umožňující proces úpravy, aniž by bylo přerušeno zpracovávání úkolu. Možnost plnohodnotné simulace procesů v prostředí BPM zvyšuje míru předvídatelnosti tzv. bottle-neck míst, které mohou významně ovlivnit včasné splnění úkolů (např. SLA) a zajišťuje prostředky pro neustálé zlepšování procesu. BPM poskytuje řešení určené jak malým tak i velkým podnikům a je schopno zvládat vysoce komplexní provázaný systém procesů a spravovat miliony transakcí i tisíce uživatelů v rámci robustní infrastruktury, jež může být včleněna do vysoce dostupných konfigurací poskytujících 24 hodinový a 7 dnů v týdnu trvající obchodní proces přes více časových pásem. Hlavní cílem modulu je řízení workflow, efektivní automatizace a optimalizace podnikových procesů. K plnění těchto cílů disponuje řešení sadou funkcionalit, primárně: Snadné modelování procesů ve vizuálním uživatelské prostředí Process Designer bez nutnosti znalostí z programování (předchozí obrázek), nebo pomocí MS Visio ve standardu BPMN Větvení a logické rozhodování pomocí velkého množství logických a matematických funkcí a možná integrace na systém správy pravidel IBM ILog JRules (není součástí nabídky). Sériové a paralelní zpracování úkolů Ruční uživateli zpracovávané úkoly a plně automatizované úkoly zpracovávané IT systémy (integrace pomocí WS). Nativní podpora pro integraci externích systémů do workflow pomocí rozhraní WebServices a zabudovanou integraci JMS pro předávání informací z procesu do externích systémů. Podpora pro vývoj (Java) vlastních komponent-automatických úkolů Přímá integrace s modulem Content Manager pro přístup k dokumentům a složkám ové notifikace uživatelům při příchodu úkolu ve workflow včetně eskalace při nedodržení termínu zpracování Přidělování úkolu ve workflow pro jednotlivé role anebo uživatele Robustní platforma rozšířitelná pomocí sady API a webového frameworku pro prezentační vrstvu Reporting a monitoring s možností exportu do BI nebo do souboru jako např. xls. Dokument: NEN Technická specifikace Strana 47 z 73

48 Kromě těchto možností pro práci s workflow, platforma obsahuje i nástroje pro simulaci a analýzu procesů. Process Analyzer a Simulator umožňují provádět zpětné analýzy ukončených workflow anebo simulovat průběh namodelovaného workflow v zrychleném módu pro vyhledání úzkých míst, tzv. bottle neck-ů. Tyto a mnohé další jsou vlastnosti a funkce platformy IBM FileNet P8. Tyto informace lze využít a reportovat například pro potřeby billingu. IBM jrules Business Rule Management System (BRMS) je softwarový systém určený na definování, nasazení, provádění, monitorování a údržbu komplexní rozhodovací logiky, která je následně využívána dalšími systémy v organizaci. Hlavní myšlenka implementace BRM systému je jednoduchá rozhodovací logika, která je v tradičním řešení bez BRMS nástroje "zadrátovaná" (hard-coded) v aplikacích, business procesech, tabulkových procesorech, ale i ve znalostech zaměstnanců, by měla být centralizovaná a umístěna do BRM systému ve formě tzv. business pravidel (někdy označovaných také jako obchodní pravidla). Rozhodovací logika založená na pravidlech má pak vlastní životní cyklus a aplikace nebo business procesy, které tuto logiku využívají, se nemusí vždy znovu sestavovat a nasazovat s každou změnou business pravidel. Namísto toho využívají možnosti BRM systému a v případě, že potřebují rozhodnutí, dotáží se právě BRMS. Základním prvkem každého BRM systému je business pravidlo, které popisuje nějakou skutečnost. Například: "Pokud je objem veřejné zakázky nižší než Kč bez DPH a je to zakázka na dodávky nebo služby, jedná sa o zakázku malého rozsahu". Takové pravidlo se může často měnit dle potřeby může se změnit částka, může přibýt podmínka, že musí jít zároveň o specifické organizace atd. Před každým rozhodnutím v aplikaci nebo business procesu se zavolá služba založená na business pravidlech, která rozhodne o klasifikaci zákazky. Z pohledu volající aplikace se jedná o klasickou službu se známým kontraktem (rozhraním). Po volání pravidel aplikace už jen použije výstup z této služby a podle něho pokračuje ve výpočtě, případně jinak využívá hodnoty získané voláním služby. Každé pravidlo má formálně tvar: if <podmínky> then <akce> else <akce>. Takových v podstatě elementárních pravidel může být v systému velké množství v praxi existují systémy s více než sto tisíc pravidly. Pravidla mohou být reprezentovány i jinými způsoby - například rozhodovacími tabulkami, nebo rozhodovacími stormy. Dokument: NEN Technická specifikace Strana 48 z 73

49 Schéma 11 Práce s pravidly U pokročilých BRMS řešení je snadné dosáhnout, aby byly business pravidla srozumitelné pro tzv. business uživatele, tj. experty a analytiky se znalostí řešené problematiky, ale často bez IT vzdělání. IBM Case Analyzer IBM Case Analyzer se využívá k monitorování a analyzování případů a business procesů. IBM Case Analyzer shromažďuje události z logu Process Enginu a audit logu Content Enginu platformy IBM Filenet P8. IBM Case Analyzer generuje a zobrazuje číslené a grafické výstupy z právě probíhajících i historických případů a workflow. IBM Case Analyzer využívá OLAP (On-Line Analytical Processing) technologii pro rychlou analýzu více rozměrných informací, která Vám dovolí se dynamicky přecházet z jednoduchého přehledu až k důležitým detailům a umožní interaktivně prozkoumat případy a data business procesů z různých úhlů pohledu. Následující diagram ukazuje architekturu IBM Case Analyzeru a způsob, jak data získaná z Process Enginu a Content Enginu procházejí IBM Case Analyzerem. Dokument: NEN Technická specifikace Strana 49 z 73

50 IBM FileNet Process Engine IBM FileNet Process Engine event logs IBM Filenet Case Analyzer IBM FileNet Content Engine IBM FileNet Content Engine audit log Event dispatchers Publishers Events IBM FileNet Case Analyzer OLAP database SQL Server Build OLAP cubes Application data IBM FileNet Case Analyzer database Report data IBM Cognos Business Ingelligence reports and Microsoft Excel charts Report and dashboards Report data IBM FileNet Case Monitor dashboards Schéma 12 Architektura IBM Case Analyzeru včetně uvedení způsobu, jak data získaná z Process Enginu a Content Enginu procházejí IBM Case Analyzerem Komponenta Event dispatchers zachytí událost zevent logu Process Enginu a audit logu Content Enginu. Komponenta Publisher zpracovává události z logů a výstupy do IBM Case Analyzer databáze. Data uložená v databázi jsou periodicky zpracovávána a je z nich sestavena OLAP krychle v IBM Case Analyzer OLAP databázi. OLAP krychle poskytují data potřebná pro generování Cognos Business Intelligence sestav nebo Excelových grafů pro koncové uživatele. IBM Forms Server IBM Forms nabízí řešení elektronických formulářů, které automatizuje firemní procesy založené na formulářích, a je možno je integrovat s existující infrastrukturou IT. Obsahují zdokonalenou tvorbu formulářů i jejich vyplňování, bezpečnost a digitální podpisy a modul pro rychlou a snadnou tvorbu jednoduchých formulářů pro netechnické uživatele. IBM Forms jsou založeny na otevřených standardech a pomáhají společnostem v mnoha odvětvích vybudovat bezpečný systém pro elektronické formuláře. Dokument: NEN Technická specifikace Strana 50 z 73

51 Přehled Řada podnikových procesů je založena na vyplňování formulářů příslušnými uživateli. Nicméně i tato jednoduchá činnost může zahrnovat chyby, časové ztráty a zbytečné náklady. Nástroj IBM Forms automatizuje podnikové procesy založené na formulářích, a tím pomáhá zvyšovat efektivitu, zlepšovat kvalitu zákaznických služeb a zkracovat dobu potřebnou k dosažení výsledku. Pomocí produktu IBM Forms je možné: Zvýšit efektivitu, zkrátit čas potřebný k dosažení výsledku a zlepšit zákaznické služby automatizací procesů zahrnujících práci s tištěnými dokumenty. Snížit náklady omezením tisku, distribuce, zpracování a ukládání papírových dokumentů. Zkrátit dobu zpracování transakcí a snížit chybovost. Zkrátit náklady na vývoj pomocí znovupoužitelných komponent formulářů. Umožnit přístup odkudkoliv a kdykoliv pomocí mobilních zařízení, jako je Apple ipad. Získat auditovatelné záznamy splňující předpisy. Minimalizovat dopady na životní prostředí a budovat "ekologický image" díky elektronickým formulářům. IBM WebSphere Application Server WebSphere Application Server (WAS) verze 7 je klíčovou komponentou aplikační infrastrutktury IBM. WAS je agilní základnou pro provoz servisně orientovaných aplikací (SOA) a služeb, která poskytuje nejvyšší úroveň spolehlivosti, stability, zabezpečení a škálovatelnosti provozního prostředí. Platforma aplikačního serveru & Programovací modely Feature Packs WebSphere Application Server Foundation IBM Java Virtual Machine (JVM) Schéma 13 IBM WebSphere Application Server WebSphere Application Server Network Deployment (WASND) edice poskytuje výkonný JEE aplikační server, který je určen pro nasazení v enterprise prostředí pro provoz kritických aplikací, poskytuje vysoký výkon, pokročilé možnosti centrální správy komplexního clustrovaného prostředí s vysokou dostupností a zabezpečením. Dokument: NEN Technická specifikace Strana 51 z 73

52 WebSphere Application Server poskytuje širokou paletu standardizovaných programovacích modelů, které umožňují vývojářům lépe sladit potřeby projektu s jejich vlastními dovednostmi a umožní tak rychlý vývoj a doručení samotných aplikací. Mezi zásadní vlastni WASND patří: Java EE 5 - WAS verze 7 je plně podporuje specifikaci Java EE 5, která přináší zjednodušení programovacích modelů, zvýšení produktivity a zlepšení iterativního vývoje aplikací a testování, široká škála programovacích modelů a otevřených standardů jako EJB 3.0, JPA, JAX-WS 2.1, JSP 2.1, Servlet 2.5, JSF 1.2, WSRP 2.0 podpora standardů webových služeb o WS-I Basic Profile 1.2, 2.0, Reliable Secure Profile 1.0, Basic Security Profile 1.1 o OSASIS WS-ReliableMessaging(WS-RM), WS-SecureExchange (WS-Trust, WS- SecureConversation), WS-DistributedManagement (WSDM), WS-Policy, SAML o W3C SOAP 1.2, MTOM, XOP, WS-Security 1.1, WS-Addressing Bezpečnostní politiky WAS pro webové služby podporují LTPA WSSecurity, Kerberos V5 HTTPS, SSL WSTransaction, Username SecureConversation, Username WSSecurity default, WS-Addressing default, WSHTTPS default, WS-I RSP ND, WS-ReliableMessaging persistent podpora široké sady programovacích modelů formou rozšiřitelných feature pack balíčku - WEB 2.0 Mobile, SCA, CEA, XML, OSGI-JPA 2.0, Dynamic scripting podpora messaging komunikačních protokolů JMS, MQ formou JCA 1.5 adaptéru realizace clusterové topologie a prostředí s vysokou dostupností (High Availability), centrální správa celého prostředí, a to i v rámci heterogenního prostředí, jehož součástí jsou různé verze aplikačního serveru WAS (5.1, 6.0, 6.1 a 7.0), integrace s directory services (TDS, Active Directory) možnost propojení s databázovými systémy jako jsou IBM DB2, IBM Informix, Microsoft SQL Server, Oracle Database, Sybase Database a DataDirect Connect pomocí Java Database Connectivity (JDBC), možnost rozšíření o adaptéry pro enterprise systémy jako SAP Software, Siebel Business Applications, Oracle E-Business Suite, JD Edwards EnterpriseOne a PeopleSoft Enterprise. Dokument: NEN Technická specifikace Strana 52 z 73

53 V7 Deployment Manager Node Agent Node Agent Node Agent ND V5.1 Nodes ND V6.1 Nodes ND V7.0 Nodes Schéma 14 IBM WebSphere Application Server Deployment manager IBM WebSphere ESB WebSphere Enterprise Service Bus (WESB) naplňuje implementaci architektury ESB a SOA. Zároveň poskytuje širokou paletu podporovaných komunikačních protokolů a formátů přenášených zpráv. WESB představuje řešení určené pro klienty, kteří potřebují sběrnici ESB zajišťující konektivitu a transformace v rámci heterogenního IT prostředí. WESB přináší klíčové funkce pro transformaci a směrování podnikových dat mezi aplikacemi. Je schopen plnit funkci přepínače zpráv a protokolů, a umožňuje tak propojování vzájemně oddělených aplikací provozovaných na různých platformách či operačních systémech. WESB poskytuje flexibilní a dynamickou infrastrukturu, jež usnadňuje integraci aplikací. Díky jeho robustnímu návrhu, rozšiřitelné architektuře, vysokému výkonu a snadnému použití můžete celopodnikovou architekturu SOA implementovat v oddělených fázích. WebSphere ESB je plně postaven na platformě JEE, kde základem běhového prostředí je výkonný a osvědčený JEE aplikační server WebSphere Application Server (WAS). Prostředí infrastruktury postavené na WAS tak poskytuje vysokou dostupnost, škálovatelnost, monitoring, zabezpečení a administraci celé platformy. Integrační logika, resp. mediační moduly implementované nad WESB jsou realizovány jako standardizované SCA moduly (Service Component Architecture), využivající standard SDO (Service Data Objects) pro datový model. WESB vycházející z JEE platformy plně podporuje a umožňuje znovupoužitelnost již existujících Dokument: NEN Technická specifikace Strana 53 z 73

54 JEE artefaktů, dalé přináší podporu WebService komunikace, JMS i MQ messagingu a mnoho dalších komunikačních rozhraní a adaptérů. WebSphere ESB WebSphere Application Server ND WebSphere Application Server Schéma 15 IBM WebSphere ESB Pro vývoj nad integrační platformou WESB jsou k dispozici grafické nástroje pro implementaci integrační logiky v podobě mediačních SCA modulů, a to i bez znalosti konkrétního programovacího jazyka. Díky JEE platformě IBM WebSphere Application Serveru, která je vlastní i IBM Business Process Manageru, je možné integrační moduly implementované na platformě WESB provozovat i na platformě IBM Business Process Manageru (Advanced edition). Mezi signifikantní přínosy WESB patří: široké spektrum podporovaných přenosových protokolů (např. MQ, JMS, SOAP, HTTP, FTP) a datových formátů, možnosti transformace datových formátů počínaje grafickým mapováním, či pomocí programovému kódu, standardizace integrační platformy, jejich artefaktů a rozhraní, jednotná integrační platforma, přesun řešení nekompatibilit mezi systémy na ESB, redukce integrační logiky v aplikacích, redukce počtu a druhů rozhraní na straně aplikací, Dokument: NEN Technická specifikace Strana 54 z 73

55 kompozitní služby, implementace integračních scénářu pomocí předdefinovaných návrhových vzorů integrace nových konzumentů služeb bez zásahů do poskytovatelů, tzn. bez nákladných diskuzí, vícenákladů, redeploymentu a testů, zásadní možnosti v oblastech monitoringu a bezpečnosti, dynamické směrovaní dle aktuální situace a požadavků na SLA, integrace s registrem služeb redukce času potřebného pro integraci služeb prostřednictvím komfortního nástroje IBM WebSphere Integration Developer, který umožňuje snadnou integraci bez znalosti konkrétního programovacího jazyka či technologie. IBM WebSphere ESB je plnohodnotnou integrační platformou vycházející z JEE architektury. WESB je zejména vhodný pro nasazení do rozsáhlejšího JEE prostředí, kde může těžit z existence již existujících JEE artefaktů (SCA, POJO) a případných zkušeností stávajících administrátorů JEE aplikačních serverů či JEE vývojářů. IBM WebSphere DataPower IBM DataPower je specializované HW zařízení appliance, které je možné jednoduše zasadit do existující infrastruktury, jako síťový prvek, a zpřístupnit tak pokročilé funkce jako: Firewalling na úrovni aplikačních protokolů nejvyšší úrovně (např. SOAP over HTTP) a obsahu zpráv. Provoz XML a WebServices má celou řadu bezpečnostních aspektů zejména v okamžiku jejich zpřístupnění přes Internet Vynucení politiky použití služeb (Service Level Management) Šifrování, dešifrování obsahu zpráv Digitální podpisy zpráv a jejich validace Routing na úrovni aplikačních protokolů (např. s využitím WS-Addressing) nebo na základě obsahu zpráv (Content Based Routing) Transformace přenosových protokolů Transformaci obsahu zpráv WebSphere DataPower Service Gateway XG45 je modelem, který v sobě nese silné bezpečnostní prvky, díky kterým se nejčastěji využívá v demilitarizované zóně jako vstupní brána a XML Firewall, který zabezpečuje a řídí vystavené webové služby. Tento model dále obsahuje technologie pro podporu zpracování XML a jeho transformace, funkce pro podporu kryptografie na úrovni zprávy (šifrování a digitální podpis dle XML standardů w3.org). Dokument: NEN Technická specifikace Strana 55 z 73

56 Internet DMZ Zabezpečená interní síť Back-end DataPower XG45 Secure Gateway Enterprise Service Bus Back-end Konzument Schéma 16 WebSphere DataPower v roli Secure Gateway Mezi signifikatní přínosy WebSphere DataPower XG45 patří: XML Firewalling - ochrana proti všem standardním rizikům spojeným s využitím XML při přenosu informací (např. XML DoS) REST Firewalling - umožňuje inspekci a zpracování objektů JSON (JavaScript Object Notation) Service Level Management umožňující ochránit vnitřní systémy před přetěžováním neadekvátním použitím rozhraní klienty nebo před útoky z rodiny Denial of Service tzv. DoS (zařízení může efektivně omezovat počet zaslaných požadavků klientem za nastavený časový úsek) Content Based Routing - směrování požadavků na základě business dat uvnitř SOAP/XML zprávy na vhodného poskytovatele služby Akcelerace XSL transformací Loadbalancing - umožňuje nejen loadbalancing backend systémů, ale také tzv. selfbalancing uvnitř clusteru DataPower zařízení (není tak vyžadován dodatečný loadbalancer v síťové infrastruktuře) Service Level Management - vynucení politiky použití služby klientem na základě runtime statistik využití služby Automatická konfigurace s využitím standardu WS-Policy (případně ve spojení s registrem služeb) Silný AAA framework (Autentizace, Autorizace a Audit) pro řízení přístupu ke službě, možno použít LDAP, SAML and WS-Security Podpora pokročilých standardů WebServices WS-Security, WS-SecureConversation, WS-Addressing, WS-ReliableMessaging Dokument: NEN Technická specifikace Strana 56 z 73

57 Výkonný engine pro zpracování XML, který odlehčí zátěži back-end systému (např. XML engine aplikační ESB) a který pokrývá zejména XML kryptování, el.podpis, WS-Security, či validaci XML schémat Podpora protokolů HTTP, HTTPS, FTP, FTPS, MQ, JMS WebSphere DataPower Service Gateway XG45 je rozšířen o Data Integration Module, který umožňuje transformaci datových formátů pokrývající i binární data, flat files, XML zprávy, EDI, COBOL Copybook, ISO 8583, CSV, ASN.1 a ebxml. Data Integration Module dále poskytuje možnosti SQL přístupu k relačním databázím a PKCS7 kryptování. IBM DB2 Advanced Enterprise Server Edition (AESE) IBM DB2 je výkonný relační databázový server (RDBMS) sloužící k ukládání relačních dat v systému NEN. Databázový server poskytuje vysokou míru zabezpečení uložených dat včetně podpory šifrování a modulu Label-Based Access Control (zkráceně LBAC), který umožňuje definovat oprávnění uživatelů až na úroveň řádků a sloupců tabulek a doplňuje tak standardní bezpečnostní model databáze, kde se řídí přístup uživatelů k objektůb databáze jako např. tabulka. Modul LBAC bude použit pro ochranu uložených dat před pracovníky provozovatele. Z pohledu výkonnosti poskytuje relační databáze nástroje pro tzv. partitioning, kdy na jednom fyzickém (virtuálním) serveru běží jen část databázové instance s tím, že další části (instance) běží na jiných nódech clusteru. Zvyšuje se tak celkový výkon databázového systému, protože je výrazně lépe využita infrastruktura (proti standardnímu Active-Passive clusteringu). Pro zajištění vysoké dostupnosti v primární lokalitě databáze se nabízí následující prostředky: IBM Tivoli System Automation for Multiplatforms (SA MP) o Tradiční přístup ke clusteringu kdy tato komponenta zajistí po detekci výpadku služby (instance nebo partition) její migraci a její zprovoznění na druhém serveru o Z pohledu klienta je takový výpadek zakryt aplikační vrstvou realizovanou pomocí clusteru aplikačního serveru IBM WebSphere Application Server s využitím rozšířených možností JDBC DataSource a JDBC driveru pro IBM DB2 o Při návrhu databáze je potřeba správně navrhnout instance a jejich partitions (časti) tak, aby případná doba obnovy byla co nejratší a byl tak minimálně ovlivněn koncový uživatel systému. o HW sizing nódů clusteru musí být přizpůsoben souběhu více částí databáze (partitions) nebo databázových instancí (jedná se o počet procesorů a operační paměť) Q-Repliacation o Možnost vytvoření active-active clusteru s velmi rychlou detekcí a přepnutím systému po výpadku jednoho nódu o Poskytuje rychlou obousměrnou replikaci dat mezi servery v clusteru Dokument: NEN Technická specifikace Strana 57 z 73

58 o Nevýhodou je duplikace objemu uložených dat (vzhledem k předpokládanému objemu dat v systému tato varianta pro systém NEN nebyla navržena) Pro systém NEN je navrženo využití interní databázové komponenty IBM Tivoli System Automation for Multiplatforms (SA MP) v kombinaci s partitioningem na úrovni databáze (nikoliv jen tabulek) a podporou failover chování DB2 na úrovni aplikačního serveru IBM WebSphere Application Server. Tak bude zásadně minimalizován výpadek primární lokality, bude maximálně udržena konzistence dat uložených v systému a bude minimalizován vliv výpadku komponent na uživatele a jeho rozpracované business transakce. Systém se z výpadku zotaví po výpadku komponenty (instance nebo server) sám bez zásahu pracovníků provozovatele. Navržený clustering umožňuje optimální využití obou serverů v době, kdy jsou servery nastartovány a funkční. V případě výpadku nástroj umožňuje: Detekovat výpadek HW Detekovat výpadek instance databáze Přesunout vyžadované zdroje dle nastavených politik (jedná se o cluster IP a příslušnou MAC adresu DB2 clusteru a příslušnou diskovou kapacitu) Nastartovat instanci databáze na druhém serveru Po dobu startu instance Aplikační server čeká na start instance. Po obnovení síťového spojení provede ještě zotavení dvoufázový transakcí (dle transakčního logu). Zjednodušený princip práce navrhovaného mechanismu clusteru pro vysokou dostupnosti a škálování systému NEN z pohledu koncového uživatele je naznačen na obr. 1 - Clustering databáze DB2 v primární lokalitě. Dokument: NEN Technická specifikace Strana 58 z 73

59 V době přesunu instance uživatelské požadavky čekají na zpracování v aplikačním serveru. Uživatel AppServer Nód1 AppServer Nód 2 IBM WebSphere Application Server ND Cluster interconnect IBM WebSphere Application Server ND Connection Pool XA manager XA manager Connection Pool 1.Výpadek serveru 2. ztráta spojení 6. automatické obnovení spojení 7. uvolnění transakcí a zámků (XA) Transaction RDBMS Nód 1 log RDBMS Nód 2 IBM DB2 (Instance 1) 3.detekce výpadku 4.přesun zdrojů (IP, MAC a disková kapacita) 5. start instance 2. ztráta spojení 6. automatické obnovení spojení 7. uvolnění transakcí a zámků (XA) IBM DB2 (Instance 2) Realizováno pomocí IBM Tivoli System Automation for Multiplatform detekce IBM DB2 (Instance 1) Tivoli System Automation Cluster interconnect Tivoli System Automation Data Schéma 17 Clustering databáze DB2 v primární lokalitě Databáze IBM DB2 Advanced Enterprise Server Edition obsahuje kromě výše zmíněného clusteringu také podporu DR (disaster recovery) scénářů, kdy jsou data z primární lokality propagována (replikována) do lokality záložní. Jedná se o tzv. Hi availability and Dizaster Recovery (HADR) option. Pro systém NEN se předpokládá využití právě této option pro replikaci dat dokončených transakcí z primárního datového centra do centra záložního. Princip replikace je naznačen na následujícím obrázku: Dokument: NEN Technická specifikace Strana 59 z 73

60 Schéma 18 Princip replikace Využití HADR mechanismu přináší: Krátké doby nutné na přechod mezi primární a skeundární lokalitou (standby databáze je v konzistentním stavu proti replikaci diskového prostoru nástroji diskových polí) Minimální ztrátu případných uživatelských transakcí Menší nároky na provozovatele a to zejména na propojení mezi lokalitami Kromě již popsaných vlastností databáze je potřeba zmínit nástroj Optim Performance Manager, který je součástí nabízené licence. Tento nástroj nabízí databázovým administrátorům, technické podpoře, ale také vývojářům náhled do chování relační databáze pro usnadnění ladění výkonnosti celého systému. QRadar 2100 All-In-One Appliance QRadar 2100 je specializované HW zařízení appliance - realizující all-inclusive bezpečnostněanalytické řešení okamžitě aplikovatelné do zákaznické podnikové sítě. Produkt vyniká rychlostí Dokument: NEN Technická specifikace Strana 60 z 73

61 deploymentu a díky velice intuitivnímu uživatelskému rozhraní je úvodní konfigurace otázkou jen zlomku času potřebného ke konfiguraci konkurenčních produktů. Produkt QRadar 2100 v sobě kombinuje funkce a služby: Log Management pro zabezpečené uložení logů Security Information and Event Management (SIEM) pro korelaci a analýzu událostí QFlow collector Onboard uložiště Vzhledem k tomu, že SIEM řešení QRadar 2100 je realizováno formou appliance, jedná se kompletní řešení připravené pro okamžité nasazení do celého řešení. Pro základní nastavení postačuje konfigurace síťového připojení a napojení na jednotlivé zdroje událostí. Není nutné ani uvažovat o externí uložiště nebo databázi a ani o následné ochraně těchto úložišť např. před pracovníky provozovatele (tento problém mají některá SW řešení). Řešení již obsahuje vše potřebné, aby bylo možno zajistit dostatečnou úroveň zabezpečení téměř okamžitě. V případě, že má zákazník v plánu rozšíření stávající infrastruktury dovolují produkty QRadar velice rychlý a výhodný upgrade do podoby, která zákazníkovi vyhovuje nejvíce bez dodatečných nákladů. Appliance QRadar 2100 All-In-One Appliance: Základní technické parametry appliance: QFlow kolektor (50Mbps) 10/100/1000 BASE-T pro monitoring 10/100/1000 BASE-T pro management 25,000 až 50,000 flows za minutu (50,000 to 100,000 NetFlows) 1000 eventů za sekundu Uložiště 1,5TB Podpora až 750 zařízení Duální zdroj napájení RAID 10 pro úložiště dat Dokument: NEN Technická specifikace Strana 61 z 73

62 IBM Tivoli Storage Manager Základní filosofie zálohovacího řešení IBM Tivoli Storage Manager: Snadná záloha, rychlá obnova Zálohovací řešení s co nejmenším dopadem na stávající funkci IT infrastruktury Online zálohování otevřených souborů, databází či operačního systému Centrální plně automatizované řešení s možností reportování o své činnosti Z pohledu systému NEN je navrhováno využití progresivního inkrementálního zálohování pro souborový systém tak, aby nebylo nutné provádět full backup všech souborových systémů a výrazně snižuje nároky na objem dat zálohy společně s časem nutným na obnovu. Princip práce se změněnými soubory v TSM (odmazání příliš starých verzí dle nastavené politiky): Schéma 19 Proces zálohování Kromě vlastního využití progresivního inkrementálního zálohování je velmi důležitá fuknce deduplikace. Deduplikaci souborů může TSM provádět na klientu nebo na serveru. Deduplikace na serveru TSM přináší výraznou úsporu místa, protože je schopen rozpoznat stejné soubory napříč více servery. Další důležitou vlatností IBM TSM je automatické šifrování záloh na pásky. Data jsou tak chráněna před pracovníky provozovatele. IBM Tivoli Storage Manager je shopen zálohovat souborové systémy jak přes SAN tak LAN infrastrukturu. IBM Tivoli Storage Manager je out-of-box připraven pro zálohování databáze IBM DB2 Advanced Enterprise Server Edition v online režimu (systém záloh, který se předpokládá použít pro zálohování relační databáze v systému NEN). IBM ITCAM for Transactions IBM Tivoli Composite Application Manager for Transactions je balíček pro monitoring aplikací, který detailně sleduje, notifikuje a reportuje dostupnost a dobu odezvy zákaznických business aplikací. Jedná se o produkt založený na řešení Tivoli Enterprise Portal (TEP), který monitoruje Dokument: NEN Technická specifikace Strana 62 z 73

63 odezvy aplikací z hlediska uživatele. Používá jak robotickou simulaci uživatelských aktivit, tak sledování odezev reálných uživatelů. Rychle identifikuje překročení definovaných limitů a tak může předcházet významným problémům. ITCAM for Transasctions využívá jeden uživatelský interface pro monitoring reálných i syntetických (roborických) transakcí a hladce se integruje s dalšími ITCAM moduly (zejména IBM Tivoli ITCAM for Appications pro hlobkovou diagnostiku). ITCAM for Transacrions nabízí jak reálné tak robotické (referenční) sledování odezev transakcí/aplikací pro rychlou analýzu a identifikaci problémů odezev a dostupností. Pro sběr potřebných dat je možné využít celou řadu předpřipravených nástrojů, které ITCAM for Transactions obsahuje. Například pro nahrávání a spouštění syntetických (referenčních) transakcí je možné použít IBM Rational Functional Tester nebo IBM Rational Performance Tester. ITCAM for Transactions nabízí dva základní monitorovací mechanizmy: Real-time monitoring o Web Aplikací (Web Response Time agent - WRT) o Windows Aplikací (Client Response Time agent CRT) Robotic Response Time Monitoring (RRT agent) o Rational Performance Tester o Rational Functional Tester o Command Line Interface (CLI) spuštění libovolného skriptu o Mercury LoadRunner V rámci nasazení systému NEN se předpokládá zejména využití real-time monitoringu webových aplikací pomocí WRT agentu na Webovém serveru IHS. IBM ITCAM for Applications IBM ITCAM for Applications je balíček složený z agentů na monitoring operačních systémů (ITM), virtuálních serverů (Monitoring for Virtual Servers), databází (Monitoring for Databases), webových serverů (ITCAM for HTTP servers), aplikačních serverů (ITCAM for J2EE), messaging infrastruktury (Omegamon for XE messaging) a aplikací (SAP, Siebel, PeopleSoft, Lotus Domino, MS Exchange). Každý fyzický server v infrastruktuře, každý LPAR (virtuální server), každý aplikační server a každý webový server budou obsahovat agent pro sběr monitorovacích hodnot. Tyto hodnoty se budou přenášet přes management síť na Tivoli Enterprise Management Server a následně si bude moci oprávněný pracovník prohlížet události a dashboardy nad Tivoli Enterprise Portal Serverem. Dokument: NEN Technická specifikace Strana 63 z 73

64 4.2 HW architektura Z důvodu vysokých nároků na výkon a zejména na škálovatelnost a prostupnost systému je návrh založen na páteřním systému serverů IBM Power7. Tyto servery mají důležité technické vlastnosti díky kterým je možné navržené řešení realizovat: vysoká vnitřní průchonost systému (vnitřní sběrnice ) umožňující realizovat souběžné výpočetní prostředí serverů s vysokou schopností přenosu dat mezi sebou. Možnost realokace technických zdrojů jako jsou lokální disky, paměť případně síťové rozhraní. Členění systémů na logické díly, které mají po technické stránce vlastnost nezávislých serverů (logický partitioning, LPAR) škálovatelnost co do výkonu, tak modularitě (jednotlivé části dílů LPAR je možné realokovat za provozu, je možné upgradovat systém spuštěním dalších již připravených procesorů systému a podobně capacity on demand). Modulární architektura serverů umožňuje při požadavku zvýšení výpočetní kapacity serveru jej výkonově škálovat - využitím skutečnosti, kterou je přibližná linearita výkonu serverů (širokopásmová sběrnice flex mezi jednotlivými částmi serveru). Mezi hlavní charakteristiku systémů Power7 patří vysoká rychlost jádra a větší propustnost pro správu masivně paralelních transakcí: Systémy používají více jader, neboli centrálních procesorových jednotek a nabízejí více vláken, tedy virtuálních jader, jež na každém čipu spravují výpočetní úlohy. Díky kontrolním systémovým nástrojům je možné v rámci serveru predikovat a detekovat chyby, kdy je možné v případě chyby v kritické části část realokovat do méně kritické a souběžně tuto chybu řešit korekčními opatřeními. Každý server je mimo samozřejmou vzdálenou správu možné spravovat lokálně pomocí konzole HMC hardware management console. Administrátor systému je oprávněn aministrovat systém po technické stránce serveru, avšak nemusí být oprávněn zasahovat do provozu serveru z úrovně software (systém řízení hardware serveru je zcela odříznut od provozního prostředí. Administrátor tak nemá možnost manipulace se zpracovávanými daty). V provozních doporučeních je hodné uvažovat o oddělených pravomocí správy subsystémů: sítí, harware, aplikačního a databázového software, diskových polí atp. K dispozici je také konzole Systems Director Management Console, která kombinuje možnosti administrace jak serverů Power, tak zapojených stohovatelných serverů blades (jednotné intuitivní rozhraním pro fyzické i virtualizované řízení zdrojů). Nezanedbatelným parametrem při volbě systémů na bázi IBM Power7 byl celkový vysoký výkon serverů a celkově nízká energetická náročnost systémů. (požadovaný prostor ve výpočetním středisku je menší, stejně tak jako požadovaný elektrický příkon a s ním úzce související výkon klimatizace). Dokument: NEN Technická specifikace Strana 64 z 73

65 HW architektura vychází z požadavků na vlastnosti a funkcionality systému a zvolené SW architektury řešení. Jako klíčové, byly brány v potaz požadavky technické specifikace NEN. Vzhledem ke zvolené HW platformě se bude využívat operační systém AIX postavené na VIOS umožňuje plnou virtualizaci s maximální možností využití zdrojů jednotlivých systémů. Architektura systému jako celku se skládá z vícevrstvého modelu částí prezentační, aplikační, databázové. Ke společné podpůrné vrstvě pro systém jako celek patří samotná infrastruktura. Do této vrstvy patří subsystémy, jako jsou: řízení a monitoring jednotlivých technických komponent, zálohovací systém, systém sítí LAN/WAN, systém firewallů. Uživatelé Řídicí vrstva ACM, infrastruktura Prezentační vrstva http https Aplikační vrstva ACM Databázová vrstva Databáze, zálohy Schéma 20 Architektura systému Z logické vrstvy uživatelů je systém dostupný pouze jako internetový server poskytující aplikační služby a ostatní prvky systému jsou skryty. Vrstva uživatelé reprezentuje buď koncová přípojná zařízení (tj. Internetový prohlížeč, živého uživatele ), aneb napojené další systémy jiných správních agent připojených na NEN. Dokument: NEN Technická specifikace Strana 65 z 73

66 Takto vrstvený systém je granulován do jednotlivých funkčních bloků, které pracují na sobě nezávisle a z hlediska navrhovaného software a hardware je možné hovořit o nezávislém propojení zcela odlišných částí systému. Funkčnost celku jako vzájemně spolupracujících vrstev netvoří jeden celistvý software, ale více programů běžících na oddělené výpočetní infrastruktuře. Sousedící vrstvy spolupracují přes definovaná rozhraní (zde Java, sokety, webové služby) a mohou proto být navrženy téměř nezávisle na ostatních vrstvách, aniž by to mělo dopad na funkčnost celé aplikace. Návrh založený na standardních protokolech přenosu dat mezi vrstvami je dán architekturou. Hardwarová infrastruktura NEN je rozdělena z důvodu bezpečnosti do dvou lokalit. V primární lokalitě je umístěna hlavní provozní infrastruktura (produkční prostředí), včetně zálohovacích knihoven. Sekundární lokalita řeší DR (Disaster and Recovery) v případě výpadku primární lokality a je zde umístěno vývojové a testovací prostředí projektu. Lokalizace vývojového, testovacího a produkčního prostředí s popisem jednotlivých komponent v rámci Primární a Sekundární lokality je znázorněno na následujícím obrázku. Uživatelé Topologie serverů hlavní a záložní lokality FWall FWall FWall FWall Vývojový test HTTP HTTP HTTP HTTP HTTP WAS WAS WAS WAS WAS DB DB DB DB DB DS DS DS DS DOC DOC DOC TSM Produkční prostředí Testovací prostředí Vývojové prostředí Administrace Primární lokalita Záložní lokalita Schéma 21 Topologie serverů NEN Dokument: NEN Technická specifikace Strana 66 z 73

67 Většina technologie je postavena na IBM pseries[5] s virtualizací na bázi LPAR a VIOS. Modře označené bloky značí přístup k systému. Je to buď uživatelský (systémy a lidé), nebo přístup operátorský vývojáři, testeři, administrátoři, auditoři apod. Boxy, které v případě vývojového prostředí jsou na dotyk sousedící, mohou být provozovány současně (paralelně). Konkrétně v případě vývojového prostředí je možné provozovat intranetový HTTP server spolu se serverem na zpracování dokumentů. Naopak oddělené servery jasně dokládají nutnost hardwarového oddělení tak, aby případný výpadek nebo odstávka serveru neměla vliv na své okolí a nezpůsobila případný kolaps systému NEN jako celku. Toto je diskutováno v kapitole vysoké dostupnosti, kdy v názorném příkladu výpadku, nebo odstávce databázového nodu nebude systém jako celek výrazně ovlivněn a z hlediska funkce a pohledu uživatele tato odstávka ani nebude patrná. Pouze se prodlouží reakční doba databázové vrstvy směrem k aplikační vrstvě, což bude pro další vrstvy pouze nepatrné. FWall ochranný firewall. Fyzicky velikost PC serveru. HTTP je server pro přímý kontakt s uživateli. WAS je aplikační server hostující provozní aplikace správy dokumentů, řízení formulářů (Forms), řízení pracovních procesů (workflow). Nod DB je dedikovaný databázový server. Nod DS (data storage) zde reprezentuje dvě nezávislé jednotky. Diskový subsystém a páskovou mechaniku s páskami. Další speciální nody (na platformě Intel) jsou DOC (stroje správy dokumentů Document Magement), který zajišťuje asynchronní zpracování a konverze dokumentů a další interní činnosti týkající se podepisování. Server TSM je odpovědný za hostování aplikace IBM Tivoli. Ta slouží pro monitoring celého systému NEN a též pro řízení ukládání (není v klastrovém vysoce dostupném prostředí, protože její provoz není kritický z hlediska provozu celého systému). V případě žádoucího výpadku TSM není celkový systém NEN nijak ovlivněn. Samozřejmě je však nutné nastartovat záložní funkce TSM a monitoringu na jiném serveru a provozně se postarat o výměnu serveru TSM. Na předešlém obrázku topologie serverů NEN není z důvodu udržení přehlednosti zakreslena detailně síťová infrastruktura. Každý výpočetní nod je připojen hlavní a vedlejší síťovou (ethernetovou) větví a další nezávislou větví pro monitoring a správu. Stejně tak je zdvojeno propojení databázových strojů mezi sebou (interlink) a též je zdvojena optická infrastruktura SAN spolu s přepínači. Toto je zjednodušeně naznačeno dalšími schématy 22 a 23.: Dokument: NEN Technická specifikace Strana 67 z 73

68 Provozní nód x Provozní nód... Data Přepínaná síť Eth Přepínaná síť Eth Přepínaná síť Eth Fwall... DS... Management Řízení Schéma 22 Síťová infrastruktura přepínané sítě Ehternet části primární lokality Schéma 22 demonstruje topologii více nezávislých síťových větví mezi komponentami zajišťující propojení do Ethernetové sítě. Celým systémem prochází dvě fyzicky nezávislé větve pro datově/aplikační spojení jednotlivých serverů. Další segment je dedikován ryze pro správu serverů a není určen pro aplikační data. Ovládání (Management) systému je dokonce fyzicky odděleno od dat! Oddělení řídící sítě ke všem aktivním prvkům typu síťové přepínače, zálohovací systémy, vlastní servery má veliký význam z hlediska bezpečnosti. Jako provozovatel, nebo osoba odpovědná za bezpečnost dat a aplikací uvnitř systému můžeme pověřit třetí osobu řízením a dozorem systému bez možnosti neoprávněného přístupu k datům prostřednictvím této sítě. Toto je běžná praxe např. návrhu infrastruktury bankovních systémů. Logická adresace VLAN (virtuálních sítí) zde uvedena není, neboť je závislá na finální realizaci. Není ji tudíž možné mít k dispozici nyní. Bude doplněna v průběhu projektu NEN. Dokument: NEN Technická specifikace Strana 68 z 73

69 LTO SAN DS LTO DS SRV1 SRVn Schéma 23 Infrastruktura SAN (primární lokalita) Na schématu 23 je patrné zdvojení všech propojek mezi zařízeními. Tím je zajištěna vysoká dostupnost na hardwarové úrovni prakticky ve všech možných uzlech. Takto konfigurovaná síť SAN má výtečnou vlastnost ve své univerzálnosti: především je plně odolná proti selhání (fault tolerant[6]) a také umožňuje do budoucna rozšiřování systému bez nutnosti zásadní rekonfigurace celého systému. Lze předpokládat scénář, během kterého je technicky možné takovou síť za provozu rozdělit a ke každé oddělené optické síti přidat další duplikát. U systémů, ve kterých má zařízení ještě více nežli dvě přípojná místa k síti SAN je možné uvažovat o budoucím rozšiřování tj. o dedikování určitého dílu datového skladu pro separátní virtuální síť SAN. Tato architektura dává uživateli velmi pružné (flexibilní) možnosti rozšiřování a rekonfigurace v omezené míře i za provozu systému. Optická Fibre Channel[7] síť SAN totiž stejně jako páteřní přístupová a aplikační Ethernet síť patří mezi nejkritičtější oblasti celého řešení komunikací uvnitř systému NEN. Primární a sekundární lokalita je v první fázi připojena pouze do internetu pomocí 100 MB (metalické kabely nikoliv sklo, zkráceně metalika). Propojení primární a záložní (sekundární) lokality je zajištěno pomocí VPN tunelu zajišťovanému CISCO technologií. Ve finálním stavu bude propojení zajištěno vyhrazeným datovým spojem a každá lokalita bude mít 2 konektivity 100MB do Internetu. Na požádání je možno zajistit vyšší konektivitu. Dokument: NEN Technická specifikace Strana 69 z 73

70 4.2.1 Charakteristika produkčního prostředí Produkční prostředí je instalováno ve dvou lokalitách. Tato kapitola obsahuje popis primární a sekundární lokality, ve kterých je umístěna HW infrastruktura NEN. Primární lokalita V primární lokalitě umístěné je nainstalováno produkční prostředí včetně zálohovacích knihoven. Jedná se o dva standardizované systémy umožňující přehlednou montáž a propojování různých elektrických a elektronických zařízení spolu s vyústěním kabelových rozvodů do sloupců nad sebe v ocelovém rámu - RACK[8]. Tyto RACKy o zástavné velikosti 42 jednotek (42Units) v kterých je celková infrastruktura umístěna. Viz schéma 24. Primární lokalita FWall FWall HTTP HTTP WAS WAS DB DB DS DS DOC DOC TSM Schéma 24 Primární lokalita Do každého RACKu jsou přivedeny 4 zdroje napájení ze dvou nezávislých zdrojů. Zdroje napájení jsou jištěny systémem proti výpadku elektrické energie záložními zdroji UPS[9] a motorgenerátory. Stojany mají zajištěno chlazení a hasící systém s čidly ve stojanu a i sále. Systém hašení je plně automatizován. Dokument: NEN Technická specifikace Strana 70 z 73

71 Přístup do sálu mají vyjmenovaní lidé pomocí čipové karty a klíče ke stojanům 365/24. Sál je elektronicky zabezpečen a střežen pomocí kamerového systému. Detailní propojení LAN a SAN bude doplněno, protože předpokládáme dílčí změny během fyzického nasazení řešení NEN do provozu. Pak bude popis LAN a SAN finalizován a fixován. Sekundární lokalita Sekundární lokalita slouží pro vývojové a testovací prostředí a zároveň jako DR (Disaster and Recovery) pro případ výpadku primární lokality. Zde je umístěn jeden RACK v systému chlazení Studená/Teplá. Druhý RACK, v kterém je systém IBM Information Archive, je umístěn na shodném sále v originálním RACKu, v kterém byl dodán. Schéma rozmístění: Sekundární lokalita 42 U LAN SW LAN SW SAN SW SAN SW CISCO CISCO Datapower XG45 QRadar 1 U HMC 4 U PWR U PWR U EXP PWR U EXP PWR 740 FWall HTTP WAS DB FWall HTTP WAS DB HTTP WAS DB 27 U 1 U Conver x-series Conver x-series 2 U Web PWR U Web PWR U TSM/nim PWR U SAN pole v U EXP SAN v7000 DS TSM DS DOS 25 U IBM Information Archive 4 U Pásková knihovna DR Vývojový test Schéma 25 Sekundární lokalita Software Komponenty V současné době je první RACK plně kompletovaný. Do každého RACKu jsou přivedeny 4 zdroje napájení ze dvou nezávislých zdrojů. Zdroje napájení jsou jištěny z UPS a motorgenerátory. Stojany mají zajištěno chlazení a hasící systém s čidly ve stojanu a i sále. Systém hašení je plně automatizován. Přístup do sálu mají vyjmenovaní lidé pomocí čipové karty, otisku prstu a klíče ke stojanům 365/24. Sál je elektronicky zabezpečen a střežen pomocí kamerového systému. Do sálu je přístup prostřednictvím stanoviště bezpečnostní agentury. Dokument: NEN Technická specifikace Strana 71 z 73

72 4.2.2 Charakteristika vývojového prostředí Vývojové prostředí je autonomní výpočetní systém a jeho hlavní funkcí je vyvíjet softwarové moduly, spravovat vývojové a provozní verze jednotlivých systémů řešení NEN. Z hlediska umístění není nutné, aby bylo v bezprostřední blízkosti u provozní nebo záložní lokality. Jedinou podmínkou je však možnost přenosu již hotových aplikací do testovacího prostředí a možnost práce s existujícími daty. Simulační nástroje vývojářů jak je patrné na obrázku topologie systémů dávají vývojářům a analytikům možnost práce nad prostředím, které je prakticky identické s provozním prostředím. Tj. vývojáři mají k dispozici aplikační systém, kompletní instalaci aplikačního systému WebSphere a s ní souvisejících komponent. Mezi další charakteristiky vývojového pracoviště patří: Architekturou kopíruje produkční a testovací prostředí, avšak z hlediska infrastruktury je v něm využito jednoduššího řešení. Nepřistupuje se přímo k datovým polím (předmětem vývoje není podílet se na vývoji infrastruktury. Datové úložiště a připojení k páskovým jednotkám je pod úrovní aplikačního a databázového vývoje). Vývojové prostředí není zdvojeno do dvou lokalit tak, jako hlavní a záložní prostředí. Je to dáno tím, že aplikační vývoj je kompetentní za vývoj aplikací nezávislých na prostředí, ve kterém pracují. Tuto Virtuální vrstvu odstiňuje právě vrstva infrastruktury. Nicméně vyvinuté aplikace, upravené moduly atp. jsou v každém případě před vlastním uvedením do provozu otestovány v testovacím prostředí, kde může být chování aplikací při pádu jednoho prostředí nasimulováno. Jednou z funkcí vývojového prostředí je udržovat zdrojové kódy aplikací, aktuální dokumentaci a především veškeré technické znalosti týkající se projektu NEN a tudíž bude v rámci implementace projektu doporučeno, aby se vývojové prostředí současně zastávalo funkci centra pro uchovávání vývojářských a dokumentačních dat. Technicky je počítáno s tím, že i přes izolovanost od produkčního prostředí bude realizována možnost vytvořit úplné zálohy dat tak, že v definovaných intervalech, nebo před a po významných upgradech systému budou vývojová data a dokumentace součástí záloh, tzn., k určitému aktuálnímu datu dojde ke kompletní záloze datové části systému a nezávisle na ní kompletní záloze provozního systému včetně celé provozní dokumentace a vývojových souborů k aktuálnímu stavu systému. Schéma 26 Znázornění vývojového prostředí NEN Dokument: NEN Technická specifikace Strana 72 z 73