Architektura. Upgradované diskové pole musí být modulární, minimálně dvouřadičové pole založené na 12Gbit SAS architektuře. Řešení musí být koncipováno jako HW, SW a FW 100% kompatibilní entita, s blokovým a souborovým přístupem k datům (FC, FCoE, iSCSI, NFS, CIFS současně). Řešení pomocí externích např. NAS „head“ není přípustné. Řešení musí minimálně splňovat stávající funkcionalitu NetApp MetroClusteru. Toto řešení musí poskytovat samotné kontrolery diskového pole (řešení pomocí externího zařízení není přípustné). Řešení musí umožňovat rozšíření storage clusteru až na 4 nody (kontroléry) v každé lokalitě celkem tedy 8x kontrolér. Požadavkem je také to, aby případné další 2 a 2 kontroléry nemusely být stejného typu.
Architektura. Jedná se o třívrstvou architekturu (klient, aplikační server, databáze). V případě mapových podkladů pak lze k datové vrstvě připojit i rastrová data, která jsou v souborovém systému. Pro starší moduly je nutno mít na klientské stanici nainstalován MapGuide ActiveX komponentu, která komunikuje s MapGuide Agentem a ten následně s MapGuide Serverem. Aplikační logika je pak řešena pomocí ColdFusion skriptů. Nově implementované řešení je postaveno na open source technologiích – JAVA a MapSource serverem. Obě technologie zpracovávají vektorová data uložená v Oracle Spatial databázi a rastrová data dostupná z SAN sítě. Pro zobrazení 3D modelu terénu je implementován AutoDesk MAP 3D 2005. Vazby na jiné systémy a aplikace Závisí na: LPIS jako základní registr pracující s geografickou informací je provázán na veškerou funkcionalitu, které vyžaduje prostorovou lokalizaci. LPIS závisí na datech z Meziskladu zpráv o kontrole pro účely stanovení rizikové analýzy. LPIS je integrová na SZR a registr zvířat (v oblasti modulu kontrol ÚKZÚZ. Modul evidence umístění provozoven je skrze webové služby integrován s DMS. Poskytuje služby: Registr poskytuje „lokalizační“ funkcionalitu všem ostatním registrům, které to vyžadují. Tuto funkcionalitu poskytuje i příslušným systémům OSS organizací. Prostředí Servery Viz dokumentace. Databáze Databáze LPIS v rámci RAC registrů. Čtení z databáze CODEL. Čtení pomocí databázových linků z RVIN, EPH, IZR, SZR. Sumární přehled vazeb systému Typ vazby Počet DB Link Konzument 32 DB Link Zdroj 31 DB Query (SELECT) Konzument 1 ESB / EPO Konzument 3 ESB / EPO Konzument - VVD 2 ESB / EPO Zdroj 6 ESB Konzument 15 ESB Konzument - VVD 8 ESB Zdroj 42 ESB Zdroj - VVD 4 Celkem 144 Zkratka VVD znamená „Ve volání jsou data“. Odlišení služeb typu VVD se uvádí proto, že v dotaze jsou zasílána data, která zdrojový systém přijímá a následně s nimi pracuje. Běžná služba v dotazu obsahuje parametry a zdrojový systém vrací data dle parametrů z dotazu. Název služby Provoz produkčního prostředí Speciálních Registrů (SR)
Architektura. Architektura ePortálu bude řešena jako modulární s realizovanými integracemi mezi moduly, čímž umožní přebírání dat mezi moduly a jejich další práci s nimi v jiném modulu. Architektura bude navržena jako otevřená s možností rozšíření o další moduly v rámci rozvoje řešení. ePortál ZK Integrace Integrace Pro všechna prostředí platí, že frontend bude konfigurovatelný přes administraci ePortálu, bude tedy možné měnit strukturu a zobrazení frontendu administrátorem s využitím grafického rozhraní ePortálu přes WYSIWYG editor, jenž bude součástí ePortálu. • modul aktuality, • modul články, • modul elektronické formuláře, • modul platby, • modul sledování podání, • modul historie plateb, • modul uživatelská statistika, • modul výstupy z datového skladu, • modul dokumenty, • modul uživatelská administrace. K těmto modulům budou přiřazeny oprávnění v rámci rolí, které budou navrženy v implementační analýze Dodavatelem. Neveřejné prostředí bude dále obsahovat chatbota s instancí pro neveřejnou část ePortálu. Integrace mezi Backoffice prostředím a dalšími prostředími ePortálu musí být realizované jako zabezpečené logované integrace s šifrovaným přenosem dat. Integraci a přenos dat nebude možné odposlechnout, nebude možné údaje změnit, ani zaslat integračním rozhraním škodlivý SW či jiná než schválená data. Backoffice prostředí bude zobrazovat moduly: • modul aktuality, • modul články, • modul administrace dotací, • modul uživatelská statistika, • modul výstupy z datového skladu, • modul výstupy z digitálního repozitáře, • modul dokumenty, • modul uživatelská administrace, • modul administrace modularity, • modul administrace ePortálu. K modulům bude v jednotlivých prostředích přístup přes menu. ePortál bude obsahovat integrační rozhraní, skrze které bude možné realizovat integrace mezi částmi ePortálu a rovněž s externími informačními systémy a aplikacemi. Více k integracím je uvedeno v subkapitole integrace. Zadavatell PPřřííssppěěvvkkoovvéé oorrggaanniizzaaccee ZZaaddaavvaatteellee Obbččaann Fiirma NIA/ISDS IDM/AD ePortál ZK
Architektura. Systém předávání zpráv TACHOnet se skládá z následujících částí:
2.1. Centrální uzel, který je schopen přijmout žádost od žádající strany, potvrdit ji a zpracovat ji přeposláním odpoví dajícím stranám. Centrální uzel vyčká, než každá odpovídající strana odpoví, shromáždí všechny odpovědi a zašle souhrnnou odpověď žádající straně.
2.2. Vnitrostátní systémy stran vybavené rozhraním schopným posílat žádosti do centrálního uzlu a přijímat příslušné odpovědi. Vnitrostátní systémy mohou k předávání a přijímání zpráv do/z centrálního uzlu využívat proprietární nebo komerční software.
Architektura. Obr 2 . GUI – obrazovky
Architektura. Vzhledem k tomu, že je pravděpodobné, že se aplikace bude využívat ve větší míře než doposud, a je požadována dlouhodobá udržitelnost, musí mít některé architektonické charakteristiky, které zajistí, že ji bude možné přizpůsobit změnám zátěže, změnám HW prostředí i podkladových operačních systémů, SW výbavy a změnám na úrovni integrovaných systémů. Aplikace musí splňovat tyto požadavky: Uživatelská i serverová část aplikace je spustitelná minimálně na OS Windows a Linux. Uživatelské webové rozhraní, které lze spustit v běžně používaných webových prohlížečích Chrome, Firefox MS Edge v aktuálních verzích operačních systémů Microsoft Windows, MacOS a Linux. Centrální konfigurace funkcionalit je dostupná z uživatelského rozhraní. Serverová aplikační část disponuje aplikačním rozhraním REST nebo SOAP. Správce má možnost zobrazit dokumentaci aplikačního rozhraní přímo z uživatelského rozhraní. Serverovou aplikační část lze spouštět ve více instancích a na více serverech a lze tak přizpůsobovat výkon aplikace. Zátěž mezi těmito instancemi je rovnoměrně rozdělována přímo aplikací. Systémové záznamy o běhu aplikace jsou dostupné administrátorovi z uživatelského rozhraní. Aplikace umí zobrazit systémové statistické informace o svém běhu. Veškerý spravovaný obsah je fulltextově dohledatelný. Aplikace podporuje technologie autentizace uživatele (MS AD a Azure ID) a splňuje požadavky na kybernetickou bezpečnost (ochrana před neoprávněnou změnou a zneužitím informací). Aplikace podporuje nativně nebo přes specifikované rozhraní integraci na cloud technologie MS O365 v oblasti ukládání a synchronizace obsahu a správy uživatelů. Aplikace musí být připravena na budoucí požadavek více faktorové autentizace. Aplikace je spustitelná v plně virtualizovaném prostředí. Aplikace umožnuje integraci se systémem správy identit, který je využíván na ÚMČ Praha 2 (IDM systém, MS AD, Azure ID).
Architektura. Řešení IP telefonního systému umožní nasazení řešení komunikační infrastruktury s centralizovaným zpracováním hovorů v prostředí více lokalit, propojených IP WAN sítí CamelNet s využitím prostupů do veřejné telefonní sítě. Řešení musí umožnit nasazení centralizovaného modelu pro celé prostředí zadavatele formou jediného společného aplikačního clusteru, zajišťujícího: • jednotnou sadu služeb dostupnou uživatelům v rámci celého prostředí zadavatele; • přenositelnost čísla a uživatelských služeb v rámci prostředí zadavatele; • centralizovanou správu systému v rámci celého prostředí zadavatele;
Architektura. Jedná se o cílovou architekturu řešení Geoportál, a to včetně architektury infrastruktury. Architektura má vždy aplikační i infrastrukturní část. Autorizace Proces získávání souhlasu s provedením operace, povolení přístupu, někomu nebo něčemu. csv Comma-separated values, způsob uložení tabulkových záznamů do textového souboru Datový sklad Souhrnné pojmenování celé oblasti datového skladu, tj. oblasti Input, Stage, Warehouse, Marts. Input Oblast (Data input) Stage Oblast (Data Stage) Jádro (Data Warehouse) Prostor Datového skladu pro vstupní syrová data. Transformovaná data do cílového datového modelu (aktuální snímek primárních dat). Historizovaná data v cílovém modelu dána přírůstky dat ze Stage oblasti. Data Marts Vybraná podmnožina historizovaných dat v cílovém modelu. Například za účelem omezení přístupu / zabezpečení při sdílení dat, nebo zjednodušení konzumace dat odběratele omezením pouze na potřebné množství dat.
Architektura. Plná integrace s dodávaným síťovým managementem (zařízení není nutno zadávat zařízení vícekrát, informace jsou automaticky sdíleny) ANO ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxxxx/xxxxxx_xxxxxxx/xxxx/x_xx_xx_xx_xxx_xxxxxx_xxxxxx.xxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxxxxxXxxxxxXXXxxxxxxxxx ANO Vmware; xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxxxxxXxxxxxXXXx ANO/ 500 Viz Priloha_kompletni_konfigurace_dodavky_v1.xlsx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxxxxxXxxxxxXXXxxxxxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxx/xx_xx_xxxxxx_xxxx.xxxx#XxxxxxXxxxxxxxxxxXxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxx/xxxx/xx_xxxxx_xxxxx.xxxx#XxxxxxxxxxxxxxXxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxx/xxxx/xx_xxxxx_xxxxx.xxxx#XxxxxxxxxxxxxXxxxxxXxxxxxxxxx://xxx.xxxxxxxxxxxxxxx.xxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxx/xxxxxxxxxxxx/xxxxx_xxxxxxx_xxxxx.xxxx#XxxxxxxXxxxxxxxxxXxxxxxXxxxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxxxx/xxxxxx_xxxxxxx/xxxx/xx_xx_xx_xx_xxxxxxx.xxxx ANO xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx/xxxx/xxxxxxx/xxxx/x_xx_xxxxxxx_xxxxxxxx.xxxx Klient - Server ANO Požadovaný formát zařízení VMware či HW Appliance ANO Požadovaný počet spravovaných zařízení 500 Plnohodnotná klientská část podporovaná na operačních systémech Linux, Windows i OS X ANO Plnohodnotný přístup přes HTML pomocí webového prohlížeče (minimálně Edge, Firefox, Chrome) ANO Víceúrovňová práva přístupu, podpora paralelní práce více uživatelů ANO Podpora autentizace pomocí LDAP, Radius ANO RBAC (rozdílní uživatelé mají práva k rozdílným prvkům a rozdílným funkcionalitám) ANO Konfigurace, monitoring i reporting systému přes HTTPs rozhraní ve standardním webovém prohlížeči (minimálně Edge, Firefox, Chrome) ANO Možnost systém rozšířit o služby agentového skenování (assessmentu) pouze aplikací licenčního klíče ANO Systém musí být schopen výměny informací s dalšími systémy (otevřené a dokumentované API). API musí poskytnout minimálně následující funkce: ANO 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1-3 1 1 1 1 1 1 1 1 1...
Architektura. Základní charakteristika: Role vykonávající službu: Konkrétní obsah služby: