Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
6.1.3
MINISTERSTVO ZEMĚDĚLSTVÍ
Designér webových formulářů
V rámci návrhu a vytváření webových formulářů je požadováno:
6.1.4
podpora grafického návrhu formulářů s možností vizuálně modifikovat vzhled, rozmístění a
chování kontrolních prvků,
možnost přidání kontrolních prvků, ideálně z palety prvků, uvedených v kapitole 5.2.1
Designér webových formulářů,
podpora modifikace vzhledu formulářů a aplikací, zejména barevného provedení a použitých
symbolů a obrázků,
podpora mapování kontrolních prvků na zdrojová data nesená v záznamech či zprávách
obsluhovaných v rámci procesů,
podpora datových typů uvedených v kapitole 5.2.1 Designér webových formulářů,
možnost ovlivňovat chování formulářů či kontrolních prvků skripty definovanými a běžícími
na pozadí formulářů,
podpora dynamického překreslování formulářů, sekcí či kontrolních prvků na základě změn
jiných kontrolních prvků, možnost řízení dynamického překreslování skripty běžícími na
pozadí formulářů,
možnost kontroly vstupních hodnot oproti definovaným pravidlům, definovatelné chybové
zprávy v případě porušení pravidel,
podpora přidání popisů ke kontrolním prvkům na formulářích,
podpora lokalizace formulářů a všech prvků rozhraní do českého jazyka,
možnost přidat k formulářům a dílčím kontrolním prvkům uživatelskou nápovědu.
Registr služeb
Požadované funkcionality poskytované registrem služeb jsou:
Vyhledávání služeb
Poskytuje katalog s informacemi, jaké služby existují a jsou dostupné pro použití;
Prezentuje vjakém stavu životního cyklu se služba nachází např. implementovaná,
v testování, nedoporučovaná atd.;
Poskytuje informace o verzi služeb;
Poskytuje grafické rozhraní pro prezentaci informací o službách;
Poskytuje katalog s informacemi o službách a jejich metadatech;
Umožňuje evidovat a vyhledávat více verzí shodné služby;
Umožňuje dynamicky odkazovat poslední verzi služby;
Přihlášení ke službám
Eviduje informace, kdo a jaké služby využívá;
Poskytuje informace, které služby jsou opakovaně využívané a které nikoliv;
Registr služeb dále podporuje funkcionality pro následující účely:
určení dopadu změn služby na existující závislé služby;
35
U
LÁ
.
m
-
o
-
hJ
MINISTERSTVO ZEMĚDĚLSTVÍ
L
dá
=.
Ů
'
NY
A
našnče
„
poskytnutí informací Konzumentům služeb o probíhajících nebo plánovaných změnách
služeb;
Registr služeb je integrován s komunikační sběrnicí ESB AgriBus. Integrace mimo jiné umožňuje:
6.1.5
dynamicky za běhu vyhledávat a vybírat end-point volené služby;
automaticky publikovat nové služby přidané do ESB AgriBus v registru služeb.
Designér služeb
Základní funkční požadavky na designér služeb jsou:
6.1.6
možnost grafického návrhu mediačních toků a služeb na všech komunikačních vrstvách dle
popisu v kapitole 5.1 Komunikační sběrnice ESB,
integrace s registrem služeb, možnost využití komponent evidovaných v registru služeb pro
návrh nových mediačních toků či služeb,
možnost uložení a opětovného načtení navrženého designu mediačních, integračních či
orchestračních toků či služeb,
organizace komponent a služeb do opakovaně použitelných knihoven,
podpora integrovaného testování nově navržených mediačních komponent a služeb,
podpora návrhu workflow služeb využitím BPEL,
podpora exportu a importu služeb v BPEL,
podpora simulace běhu služeb a komponent pro účely ladění výkonnosti služeb a
komponent,
nástroje pro nasazení (deployment) vyvinutých funkcionalit do požadovaného prostředí
(produkční, testovací, vývojové) ve funkčně ohraničených celcích (modulech);
Monitoring
Požadavky na monitoring AgriBus jsou následující:
Dohled běhových prostředí
V rámci Dohledu běhových prostředí je mimo popisu uvedeného v kapitole 5.5.1 Dohled běhových
prostředí dále požadováno:
Monitoring funkcionality a dostupnosti komunikačních rozhraní AgriBus;
Monitoring funkcionality a dostupnosti externího rozhraní AgriBus zejména komponent
systému vyrovnávání zátěže a perimetru;
Zajištění přenosu informace o chybě běhového prostředí do historického archivu nejpozději
do 12 hodin od detekce události;
Předání událostí do dohledového systému Poskytovatele nejpozději do 5-ti minut od detekce
události;
Provozní dohled služeb
V rámci Provozního dohledu služeb je mimo popisu uvedeného v kapitole 5.5.2 Provozní dohled
služeb dále požadováno:
Monitoring dostupnosti jednotlivých služeb prezentované graficky v rámci dashboard nebo
(preferované řešení) v rámci registru služeb;
Funkcionalita přenosu zpráv — monitoring změn objemu příchozích a odchozích zpráv;
f MINISTERSTVO ZEMĚDĚLSTVÍ
© © Monitoring délky komunikačních front;
© | Detekci chybových stavů v rámci volání služeb / přenosu zpráv;
© | Monitoring bezpečnostních událostí zejména výskyt neoprávněných volání služeb;
© | Možnost sledování stavu jednotlivých procesů a to jak z pohledu jednotlivých služeb/rozhraní
a konkrétních případů, tak z pohledu celku (průběžné vyhodnocování úspěšnosti konkrétních
procesů i celého systému);
* © Podpora analýzy problémů jednotlivých datových transakcí až na úroveň dílčích procesů
každé služby v nejpodrobnějším členění;
* | Metriky agregované v čase (např. počet transakcí obsloužených do 25) budou přístupné pro
externí monitoring systémy Objednatele dle parametrů uvedených v kapitole 5.5 Monitoring.
* Vítanou vlastností je možnost založení monitoringu nejvyšší komunikační vrstvy služeb
využitím BPEL modelu služby (přímo v BPEL modelu je možné vybrat monitorovací body,
monitorované operace, atd.).
Statistický monitoring
* | zajištění přenosu informací o každé realizované transakci na všech komunikačních úrovních
AgriBus dle požadavků uvedených v kapitole 5.5.3 Statistický dohled služeb nejpozději do 12
hodin od okamžiku dokončení anebo expirování transakce do historického archivu;
Bezpečnostní monitoring
* | Vřešení AgriBus bude monitorován výskyt bezpečnostních událostí a parametrů pro zajištění
bezpečnosti tak, aby bylo možné naplnit požadavky na zabezpečení řešení definované v
kapitolách 5.6 Zabezpečení a 6.5 Zabezpečení.
6.1.7 Historický archiv
Pro historický archiv jsou požadovány násled ující základní vlastnosti:
* | příjem a archivace neagregovaných dat o realizovaných voláních a datových přenosech na
mediační, integrační a orchestrační vrstvě ze Statistického dohledu služeb dle požadavků na
historii dat uvedených v Tabulka 4 - Požadavky na kapacitu historického archivu s možností
zpětného dohledání a reportů,
s příjem a archivace událostí z dohledu běhových prostředí a provozního dohledu služeb,
© | podpora pro externí reporting a analýzy nad archivem zejména pro výpočet KPI parametrů
dle katalogového listu služby,
© | zdokumentovaný datový model,
« © možnost definovat uživatelské účty, skupiny a řídit přístupy individuálně k jednotlivým
informacím, zejména pak možnost definovat read-only oprávnění nad celým historickým
archivem,
© | možnost vytvářet pohledy na data (typicky databázové view) a řídit přístupy k těmto
pohledům,
* zajištění historie neagregovaných dat dle Tabulka 4 - Požadavky na kapacitu historického
archivu.
Tabulka 4 - Požadavky na kapacitu historického archivu
Historie neagregovaných dat dostupná online 2 roky
37
Historie neagregovaných dat dostupná na vyžádání
6.2
“
MINISTERSTVO ZEMĚDĚLSTVÍ
10 let
DETAILNÍ SPECIFIKACE
Zhotovitel provede analýzu nezbytnou pro instalaci, konfiguraci a implementaci všech komponent
řešení AgriBus a připraví analytické dokumenty dle standardů definovaných vkapitole 6.9
Dokumentace. Zhotovitel v rámci detailní specifikace zejména navrhne:
architekturu řešení a rozmístění jednotlivých komponent řešení v souladu s požadavky na
zajištění výkonnosti a dostupnosti uvedenými vkapitole 6.5 Požadavky na výkonnost a
dostupnost,
sizing řešení v souladu s požadavky na výkonnost uvedenými v kapitole 6.5 Požadavky na
výkonnost a dostupnost,
způsob a detaily integrace na systémy Objednatele.
Zhotovitel v rámci detailní specifikace dále provede návrh řízení kontinuity řešení AgriBus a to
zejména,
vypracování závazné metodiky pro sestavení analýzy rizik a posuzování kritičnosti
jednotlivých aktiv řešení AgriBus,
přehled všech klíčových komponent vyžadujících zálohování či jiné zabezpečení,
návrh metod zabezpečení komponent,
detailní plány zálohování všech klíčových komponent,
fyzické zabezpečení klíčových komponent,
návrh plánů a postupů pro obnovu řešení AgriBus v případě havárie a to pro různé případy,
zejména pak:
o. výpadek jednoho z datových center bez funkce UPS (servery nejsou zastaveny
korektně),
o výpadek konektivity s následným neřízeným obnovením konektivity nebo
nestabilitou (flapováním) linky,
výpadek klíčové komponenty v jednom datovém centru,
výpadek obou datových center zároveň,
řízené vypnutí jednoho datového centra,
záměna lokalit (DC1 se zastaví a DC2 ponechá v provozu; DC1 se spustí a DC2 se
zastaví; DC1 se ponechá v provozu a DC2 se spustí),
o flapování napájení (výpadek a neřízené obnovení napájení v jednom datovém
centru),
o. výpadek diskových polí.
vývoj rutin nebo nastavení systémů pro vykonávání zálohovacích úloh,
návrh procesů a postupů pro testování plánů a postupů pro obnovu řešení včetně
zálohování, obnovy záloh a testování záložních médií,
zajištění monitoringu klíčových komponent a úloh systému zálohování.
Oo © O ©
Detailní požadavky na zálohování jsou dále uvedeny v katalogovém listu služby.
u
f MINISTERSTVO ZEMĚDĚLSTVÍ
Zhotovitel dále jako součást dodávky rozpracuje Migrační plán sestavený jako součást nabídky.
Zhotovitel provede detailní analýzu existující implementace ESB Oracle a navrhne řešení a postup
migrace služeb a komponent (všech modulů mediační vrstvy) provozovaných na stávající platformě
ESB Oracle do nového řešení AgriBus. Zhotovitel v rámci analýzy zejména:
e vytvoří přehled aktuálně implementovaných a využívaných služeb v ESB AgriBus;
vytvoří přehled služeb, které nejsou využívány a není proto vhodné realizovat jejich migraci
do nového prostředí;
* posoudí proveditelnost a technickou náročnost migrace jednotlivých služeb a v případě
potřeby doporučí Objednateli odložit migraci některých služeb, objednatel následně
rozhodne o finálním seznamu migrovaných služeb, tento seznam bude mimo jiné využit jako
podklad při akceptaci díla;
e posoudí kompatibilitu služeb s novými funkcionalitami AgriBus ESB a navrhne technický
přenos funkcionalit, rozhodne které služby migrovat ve stávající podobě implementace a
které upravit pro funkcionality podporované novou platformou;
e ověří existující datové přenosy v rámci ESB Oracle, zejména jejich účel a obsah a navrhne
nahrazení integračních vazeb využitých pro dávkové (offline)přenosy velkých dat ETL nástroji
dle popisu uvedeného v kapitole 5.1 Komunikační sběrnice ESB AgriBus;
e navrhne způsob verzování služeb a pravidla pro uchování historických verzí služeb včetně
počtu historických verzí s minimálními dopady na výkonnost systému.
Další požadavky kladené na migrační plán navržený v rámci analýzy jsou:
e Služby musí být migrovány beze změn funkcionalit ovlivňujících existující Konzumenty a
příjemce služeb;
* Migrované služby musí dosahovat minimálně stejných výkonnostních parametrů jako
implementace v původním prostředí ESB Oracle;
* Voprůběhu migrace a následného ověřovacího provozu musí být možné přepínat provoz
individuálních služeb mezi původním řešením ESB Oracle a novým řešením AgriBus bez
dopadu anebo s minimálním dopadem na Konzumenty a Poskytovatelé služeb;
e Zhotovitel v návrhu migrace uvede seznam měřitelných ukazatelů pro ověření původní a
nové výkonnosti služeb a navrhne způsob měření ukazatelů;
e Zhotovitel připraví migrační plán pro každou individuální službu. Migrační plán bude
zahrnovat informace uvedené v kapitole 6.9 Dokumentace;
e Migrační plán bude obsahovat postup migrace jednotlivých služeb. Služby budou v rámci
migrace rozděleny do skupin služeb, které budou migrovány současně;
* Vrámci migrace budou dostupné oba systémy ESB Oracle a nový AgriBus. ESB AgriBus bude
předsazena proxy umožňující směrovat požadavky v rámci služby na staré ESB Oracle a nové
ESB AgriBus a tak se v případě potřeby rychle vrátit k původní verzi ESB;
« Posouzení využívání služeb s cílem identifikovat nepoužívané služby a vyřazení těchto služeb
s migračního plánu;
» Posouzení vhodnosti využití ESB AgriBus pro jednotlivé datové přenosy. Možnosti nahrazení
některých nevhodných přenosů ETL nástroji a řízení ETL úloh prostřednictvím ESB AgriBus.
6.3 DoDÁVKA
Odběratel vrámci výběrového řízení požaduje zajištění kompletní dodávky hardware a software
v poslední dostupné verzi pro realizaci řešení AgriBus odpovídajícího požadavkům na funkcionality,
výkonnost a kontinuitu provozu definovaným v tomto dokumentu. Je požadována dodávka zcela
nového řešení, zcela autonomního systému v oblasti hardware i software, bez závislosti na původním
39
-
MINISTERSTVO ZEMĚDĚLSTVÍ
řešení ESB (mimo sdílených komponent využitých v rámci migrace služeb a ověřovacího provozu). Je
požadováno zajištění hardware a software pro běhová prostředí:
e | produkční prostředí AgriBus,
s | testovací prostředí AgriBus,
e | vývojové prostředí AgriBus,
včetně všech podpůrných systémů, jako jsou systémy pro zálohování, monitoring a testování,
zabezpečení a systémy perimetru, aktivní síťové prvky a infrastruktura pro přímé propojení
komponent řešení.
Výkonnost dodaného hardware a software licence musí umožňovat provoz všech služeb migrovaných
z dosavadního řešení ESB a obsahovat dostatečné rezervy pro implementaci nových služeb v průběhu
3 následujících let. Počet služeb implementovaných ve stávajícím řešení ESB na počátku roku 2014
činil cca. 400 služeb viz. kapitola 3 Aktuální stav. Předpokládaný objem nově implementovaných
služeb je 50 služeb ročně. Skutečný počet služeb se od uvedeného čísla může lišit a upřesnění počtu
služeb včetně detailní analýzy nezbytné pro migraci služeb do nové architektury je součástí tohoto
zadání uvedené v kapitole 6.2 Detailní specifikace. Odhady předpokládané zátěže řešení spolu
s požadavky na výkonnost řešení jsou uvedeny v kapitole 6.5 Požadavky na výkonnost a dostupnost.
Hardware řešení bude instalován ve dvou datových centrech viz kapitola 6.4 Instalace.
Zhotovitel dodá takové množství a typy licencí umožňující rozvoj systému v období třech (3) let od
milníku „Předání a převzetí Systému AgriBus“ bez potřeby dokupování dodatečných licencí.
Zhotovitel může při instalaci využít stávající infrastrukturu datových center Objednatele, pokud tato
bude svými parametry dostačovat potřebám řešení AgriBus, případně předá Objednateli soupis
požadavků na rozšíření infrastruktury. Infrastruktura datových center zahrnuje racky pro umístění
serverů, chlazení, redundantní přívod elektrické energie, zálohování pro případ výpadku napájení a
síťovou konektivitu.
Všechny systémy instalované Zhotovitelem budou vybaveny přípojkami pro minimálně dva nezávislé
přívody napájení a předozadní větrání. Zhotovitel může pro účely síťové komunikace v rámci řešení
AgriBus využít síťovou infrastrukturu Objednatele (zejména propojení datových center) za
předpokladu, že komunikační linky mají pro řešení dostatečnou kapacitu, výkonost a spolehlivost a
navýšení zátěže linek v důsledku přidání komunikačních toků AgriBus nebude mít negativní dopady
na ostatní služby využívající shodnou infrastrukturu, případně předá Objednateli požadavky na
rozšíření kapacit síťové infrastruktury.
Všechny systémy budou disponovat dedikovaným síťovým rozhraním pro připojení do management
sítě Objednatele.
Zhotovitel spolu s řešením dodá, nainstaluje a aktivuje licence včetně licencí pro uživatelský přístup
do systémů, pokud jsou tyto licence výrobcem nebo dodavatelem požadovány a to pro všechny
běhová prostředí. Předpokládaný počet uživatelů je uveden v Tabulka 5 - Počty uživatelů systémů.
Tabulka 5 - Počty uživatelů systémů
—g
Počet současně pracujících © administrátorů 2
systému
Počet současně pracujících designerů a vývojářů 20
služeb a agendových aplikací v AgriBus
40
z
INISTERSTVO ZEMĚDĚLSTVÍ
Počet současně pracujících vývojářů systémů 20
Konzumentů a Poskytovatelů služeb (přístup
kinformacím vregistru služeb a rozhraní
AgriBus, případně dalším dle navrhované
metodiky)
Počet současně pracujících uživatelů procesních Odhad 100 — 1000 uživatelů (preferováno
aplikací nelicencování koncových uživatelů procesních
aplikací AgriBus)
Zhotovitel dodá takové množství a typy licencí umožňující rozvoj systému v období třech (3) let od
milníku „Předání a převzetí Systému AgriBus“ bez potřeby dokupování dodatečných licencí, jak je
uvedeno výše v rámci této kapitoly.
6.4 I|NSTALACE
V rámci zadání je požadováno doručení hardware komponent řešení do místa finálního umístění a
jejich fyzická instalace na místo určení. Fyzickou instalací se rozumí vybalení hardware z přepravních
obalů, umístění do určených prostor nebo osazení do racku a připojení na infrastrukturu datových
center. Objednatel požaduje instalaci všech hardware komponent pro produkční, testovací a
vývojové běhové prostředí.
Zhotovitel v rámci projektu provede instalaci a konfiguraci všech hardware a software komponent
tvořících řešení AgriBus včetně komponent zajišťujících bezpečnost a všech podpůrných software
systémů pro produkční, testovací a vývojové běhové prostředí. Zhotovitel vytvoří dokumentaci
instalačních postupů dle požadavků specifikovaných v kapitole 6.9 Dokumentace. Zhotovitel dále
zajistí nasazení a aktivaci všech licencí a licenčních klíčů. Přehled použitých licencí a licenčních klíčů
bude součástí instalační dokumentace.
Tabulka 6 - Instalační lokality
K Červenému dvoru 25/3156
130 00 Praha 3 — Strašnice
Datové centrum Nagano
Datové centrum Chodov V lomech 2339/1
149 00 Praha 4 — Chodov
6.5 PoŽADAVKY NA VÝKONNOST A DOSTUPNOST
Řešení AgriBus je klíčovou komponentou zajišťující komunikaci mezi mnoha významnými aplikacemi
Objednatele. Na řešení jsou proto kladeny vysoké nároky z pohledu výkonu a dostupnosti.
Tabulka 7 - Požadavky na výkonnost
Předpokládaná zátěž systému 60 požadavků za sekundu
Přehled požadavků na dostupnost, odezvy systému a obnovu služby v případě výpadku jsou uvedeny
vkatalogovém listu služby. Monitoring dostupnosti a funkcionality AgriBus bude realizován využitím
OM
A
=
o
MINISTERSTVO ZEMĚDĚLSTVÍ
volání specializované testovací služby, jak je uvedeno v kapitole 5.5 Monitoring. Monitorovací služba
musí poskytovat operaci vracející hodnotu O nebo 1 (dle aktuálního stavu uzlu AgriBus) , jež může být
využita load balancery pro směrování provozu.
Vzhledem kvysokým požadavkům na dostupnost řešení Objednatel požaduje vybudování řešení
v rámci geografického clusteru v lokalitách HC Nagano a HC Chodov viz. Tabulka 6 - Instalační lokality
a nasazení řešení pro rozložení zátěže v režimu active-active minimálně pro komponenty zajišťující
přístup k řešení AgriBus (např. SSL koncentrátor/load balancer).
Ověření funkcionality systému rozložení zátěže a geografického clusteru bude provedeno v průběhu
zátěžových a DRP testů viz. kapitola 6.8 Testování.
Funkcionalita rozložení zátěže je požadována zároveň pro vývojové a testovací prostředí.
6.6 | ZABEZPEČENÍ
Zhotovitel vrámci detailní specifikace identifikuje hlavní bezpečnostní rizika a připraví návrh
zabezpečení řešení AgriBus a komunikace jednotlivých komponent dle popisu uvedeného v kapitole
5,7 Zabezpečení,
Zhotovitel v rámci analýzy navrhne:
* | postupy pro instalaci a zařazení jednotlivých komponent AgriBus do vhodných síťových
segmentů Objednatele včetně případných DMZ dle popisu uvedeného v kapitole 5.7
Zabezpečení,
e | využití firewall, VPN a VLAN pro zabezpečení komunikací v rámci AgriBus dle základních
požadavků uvedených v kapitole 5.7 Zabezpečení,
s | způsob zabezpečení a šifrování datového provozu uvnitř i vně lokální sítě AgriBus včetně
komunikace prostřednictvím veřejných sítí dle základních požadavků uvedených v kapitole
5.7 Zabezpečení,
© | systém využití certifikátů a zapojení autorit pro zabezpečení řešení AgriBus,
« | řešení pro zabezpečení dat,
« | řešení pro napojení řešení AgriBus na stávající repository uživatelů a zdroje ověření
Objednatele,
e | způsob zabezpečení volání jednotlivých služeb AgriBus.
42
-
MINISTERSTVO ZEMĚDĚLSTVÍ
Pro zabezpečení řešení AgriBus je požadováno/a:
* | provedení zabezpečení řešení dle popisu uvedeného v kapitole 5.7 Zabezpečení a na základě
návrhu vypracovaného dle výše uvedené analýzy,
» | nasazení jednotného systému řízení přístupových práv, ověřování proti LDAP s možností
využití lokální repliky LDAP,
* řízení komunikace centrálním systémem správy přístupových práv a systém podporoval
autentizaci prostřednictvím certifikátu,
© | aby systém podporoval přihlášení k uživatelským rozhraním využitím uživatelského jména a
hesla,
« | řešení musí být připraveno na přístup z nedůvěryhodných sítí (možnost využití WAF),
e | aby systém podporoval běh služeb pod neprivilegovanými účty,
s | zabezpečení na síťových prvcích na úrovni L2 a DNSSec,
« | ochrana příchozích a odchozích požadavků prostřednictvím XML firewall z možností nastavit
parser limity a rate control,
s | zabezpečení virtualizační platformy v případě nasazení virtuální infrastruktury,
s | podpora PKCS11 pro kryptografické operace s asymetrickými šiframi,
s | zabezpečení komunikačních kanálů na úrovni autentizace komunikujících stran a autorizace
pro použití jednotlivých služeb,
© | podpora TLS 1.0/1.2, SSL 3.0 s možností selektivně za pnoutť a vypnout jednotlivé protokoly až
na úrovni listeneru,
* | zapnutí anebo vypnutí kontroly revokace prostřednictvím CRL i OCSP,
s | podpora cipher suites s PFS,
s vpřípadě nezabezpečeného provozu v rámci vnitřní sítě AgriBus zajištění důvěryhodného
předání informací o klientském certifikátu, IP atd. z load balanceru nebo reverse proxy na
autorizační prvek,
© | možnost provozu v IPv6 prostředí, schopnost v překlenovacím období obsluhovat IPv6 i IPv4
jak na listenerech tak na službách poskytovaných externě,
© | schopnost plného provozu pouze na IPv6 nebo IPv4 nejen u serverů ale i síťových prvků,
© | schopnost provozu na systému, který nemá IPv6 aktivován,
s | zabezpečení komunikace mezi Konzumentem a Poskytovatelem služeb prostřednictvím SSL,
(volitelně možnost zakončení SSL zabezpečení na SSL akcelerátoru),
© | volitelná podpora šifrování zpráv a dokumentů uvnitř ESB,
s | volitelné zabezpečení integrity a antivirové kontroly souborů v rámci přenosu ESB,
* | integrace všech komponent řešení s IDM a LDAP Objednatele,
© | zabezpečená komunikace mezi logickými komponentami řešení dle popisu v kapitole 5.7
Zabezpečení,
© | možnost omezit počet požadavků zpracovávaných řešením AgriBus, ochrana systému před
zahlcením.
6.7 | IMPLEMENTACE
Zhotovitel v rámci projektu zajistí implementaci funkcionalit nezbytných pro řádný běh platformy
AgriBus a migraci existujících služeb z původního prostředí ESB do řešení AgriBus.
Zhotovitel:
-
zeje
MINISTERSTVO ZEMĚDĚLSTVÍ
* | připraví a předá objednateli požadavky za součinnost zejména pak požadavky na zajištění
síťové konektivity, nastavení síťových prostupů, vytvoření účtů v LDAP/AD/IDM atd.,
© | provede napojení na systémy Objednatele, zejména na LDAP/AD,
© | provede nastavení a implementaci všech funkcionalit dodávaného hardware a software
nezbytných pro řádnou funkcionalitu řešení AgriBus dle specifikace připravené v rámci
Detailní technické specifikace,
© | provede postupnou migraci služeb ze stávajícího řešení ESB Oracle do nového řešení AgriBus
dle analýzy realizované podle požadavků uvedených v kapitole 6.2 Detailní specifikace,
© zdokumentuje implementaci dle standardů a požadavků uvedených vkapitole 6.9
Dokumentace,
© | navrhne a vytvoří Testovací službu umožňující pravidelně testovat dostupnost a funkcionalitu
řešení AgriBus viz. 5.5.2 Provozní dohled služeb,
| vrámci implementace služeb vytvoří pro každou dílčí službu testovací operaci umožňující
v rámci monitoringu ověřit dostupnost a funkcionalitu služby viz. 5.5.2 Provozní dohled
služeb,
* | zajistí nezbytné systémy pro měření výkonnostních metrik viz. 6.2 Detailní specifikace a
provede vlastní měření před realizací migrace a po realizaci migrace každé individuální
služby,
s | pořídí individuální záznam o migraci každé služby obsahující výše uvedené výsledky
měřených výkonnostních ukazatelů,
© | provede začlenění nových funkcionalit do monitoring systémů.
Migrací první služby do produkčního systému AgriBus a zahájením produkčního provozu první služby
v řešení AgriBus vstupuje systém AgriBus do produkčního režimu. V tomto režimu již bude zajištěn
monitoring celého řešení AgriBus dle katalogového listu služby a požadováno řešení případných
událostí dle reakčních časů příslušných priorit,
6.8 | TESTOVÁNÍ
Zhotovitel provede testování nového řešení AgriBus i dílčích služeb před nasazením do produkčního
provozu. Testování bude realizováno v předem určených časových intervalech dle metodiky navržené
Zhotovitelem a reflektující požadavky uvedené v kapitole 6.10 Metodika tak, aby nedocházelo k
narušení provozu služeb. Podpůrné nástroje a komponenty pro testování zajistí Zhotovitel, jsou
předmětem dodávky viz. kapitola 6.3 Dodávka.
Testování bude provedeno na testovací platformě AgriBus a testovacích službách. Zhotovitel zajistí
přípravu testovacích dat. Zhotovitel provede následující typy testů:
* | Funkční testy;
Jejich úkolem je ověřit, že implementované komponenty AgriBus i všechny migrované služby
poskytují bezchybně všechny požadované funkcionality.
» | Zátěžové testy;
Jejich úkolem je ověřit, že implementované komponenty a migrované služby jsou schopny
provozu při vysoké zátěži. Testy budou realizovány sérií mnoha dotazů generovaných z více
počítačů oproti simulovaným cílovým systémům a dle možnosti dále oproti testovacím
prostředím cílových systémů.
44
*
ki
hJ
MINISTERSTVO ZEMĚDĚLSTVÍ
« | Bezpečnostní testy;
Úlohou bezpečnostních testů je ověřit, že jsou všechny komponenty zabezpečeny dle
požadavků definovaných v zadání a v rámci úvodní analýzy a že jsou všechny systémy řádně
integrovány s centrálním bezpečnostními systémy Objednatele.
« | Testy zajištění kontinuity (DRP testy);
Úlohou testů je zejména ověřit funkcionalitu geografického clusteru a schopnost řešení
přepínat provoz mezi uzly v geografickém clusteru. V rámci testů bude provedeno postupné
vynucené zastavení obou uzlů geografického clusteru a ověřena dostupnost služby.
Zhotovitel v rámci testování zajistí:
« | nástroje a komponenty potřebné pro testování,
s © přípravu návrhu testování a hodnotících kritérií,
e | přípravu testovacích scénářů,
s | přípravu prostředí a testovacích dat (v součinnosti s objednatelem),
« | testovací protokoly s výstupy testů,
© | seznam defektů a způsob a harmonogram jejich odstranění.
Ověřovací provoz
Okamžikem splnění milníku Předání a převzetí Systému AgriBus bude zahájen Ověřovací provoz
v délce 6-ti měsíců, v rámci kterého bude možné přepínat běh individuálních služeb mezi původním
ESB Oracle a novým řešení AgriBus. V průběhu Ověřovacího provozu budou dostupné původní
systémy ESB Oracle i nové řešení AgriBus současně. Po dobu Ověřovacího provozu bude realizován
monitoring řešení AgriBus i jednotlivých služeb, jak je uvedeno v kapitole 5.5 Monitoring a
vyhodnocovány ukazatele definované v katalogovém listu služby. V případě porušení ukazatelů
katalogových listů AGBO1-01 Maximální odezva IS a AGB01-02 Dostupnost IS pro systém AgriBus jako
celek i dílčí služby v průběhu ověřovacího provozu zajistí Zhotovitel obnovu služby AgriBus a nebo
dílčí služby v čase dle příslušné priority definované v katalogovém listu služby a to prostřednictvím
zásahu v řešení AgriBus anebo přepnutím provozu jedné, více nebo všech služeb z nového řešení
AgriBus zpět do původního ESB Oracle.
6.9 DOKUMENTACE
Zhotovitel v rámci analýzy zdokumentuje navrhované řešení a vytvoří migrační plán služeb. Součástí
dokumentace navrhovaného řešení bude mimo jiné:
© | popis současného stavu prostředí Objednatele a připravenost prostředí pro implementaci
řešení AgriBus,
© | popisarchitektury AgriBus včetně modelů dle standardů Togaf/Archimate pro
e | infrastrukturní vrstvu,
| aplikační vrstvu,
© | procesní vrstvu řešení,
© | popis datového modelu včetně diagramu datového modelu,
© | soupis požadavků na součinnost Objednatele včetně případných požadavků na rozšíření
existující nebo budování nové infrastruktury,
s | popis konfigurace řešení pro prostředí Objednatele,
45.
© | popis provozního modelu řešení navazující na architekturu procesní vrstvy (detailní popis a
diagramy procesů pro provoz a rozvoj řešení AgriBus),
© | popis zajištění kontinuity, bezpečnosti, monitoringu a zálohování v návaznosti na popis
architektury,
© | popis očekávaných výkonnostních a kapacitních parametrů řešení,
* | přehled možností pro budoucí škálování a rozšiřování systému zejména pak výkonnostní a
kapacitní limity systému a podmínky, za kterých lze dále navyšovat výkon systému za hranice
plánovaného výkonu (možnosti rozšíření HW a limity např. v podobě volných slotů, možnosti
doplnění software a licencí atd.)
Součástí dokumentace migračního plánu bude mimo jiné:
s | přehled stávajících služeb provozovaných na ESB Oracle s kategorizací do S1, 52 a 53 (viz. 5.3
Registr služeb) obsahující dále mimo jiné název služby, stručný popis služby a další informace
nezbytné pro posouzení začlení anebo vyřazení služby do/z migračního plánu,
* | doporučený postup pro migraci každé individuální služby včetně roll-back plánů, případně
zdůvodnění vyřazení služby z migračního plánu,
* | postup přenesení logiky služby (případně implementace) z ESB Oracle do AgriBus,
© | přehled doporučených optimalizací jednotlivých služeb pro nové prostředí AgriBus zejména
pro služby kategorie 53,
* | časová náročnost a doporučený harmonogram pro migraci každé individuální služby případně
skupiny služeb, počet a délku požadovaných odstávek služby v původním ESB Oracle,
e | rizika související s migrací každé služby,
© | metriky pro porovnání výkonu každé individuální služby před a po migraci,
* prahové hodnoty výše uvedených metrik pro určení způsobilosti služby pro přenos do
produkčního prostředí, případně pro rozhodnutí o roli-back,
© | postup pro otestování služby a způsob pořízení testovacích dat, případně součinnost při
přípravě dat a systémů na testování ze strany objednatele,
Zhotovitel v rámci implementace, migrace služeb a následné podpory vytvoří dále model architektury
migrovaných, nově konfigurovaných či modifikovaných služeb dle standardu Togaf/Archimate a
model uloží a aktualizuje vcentrálním systému pro řízení architektury Objednatele. Detailní
informace o systému pro řízení architektury budou poskytnuty po podpisu smlouvy. Požadovanou
funkcionalitou systému pro řízení architektury je podpora standardu Archimate 2.0 a možnost
exportu a importu modelů vytvořených vsystému EAM. Zhotovitel pro účely dokumentace
architektury může využít dostupnou existující dokumentaci služeb Objednatele provozovaných v ESB
Oracle. Objednatel předá Zhotoviteli po podpisu smlouvy referenční model Archimate pro SOA
architekturu zahrnující ESB AgriBus a popis závazných architektonických standardů spolu s šablonami
dokumentů pro jednotlivé typy komponent. Zhotovitel jako součást přípravy metodiky (viz. kapitola
6.10 Metodika) navrhne doplnění architektonických standardů a šablon dokumentace. Objednatel
návrhy posoudí a vhodné návrhy zapracuje. Zhotovitel bude vrámci návrhu a dokumentace
architektury | následovat referenční model, dodržovat výše uvedené závazné architektonické
standardy a doplňovat informace ve struktuře dle příslušných šablon dokumentace. Součástí
dokumentace (dle výše uvedených šablon) služby bude zejména:
s | architektonický model služby dle standardu Togaf/Archimate,
definice služby,
popis služby,
popis logiky služby,
způsob volání služby,
46
s | vstupní a výstupní parametry a metodika pro použití,
* | chybová hlášení,
© © popis monitorovací operace (testovací scénář).
Zhotovitel dále pro celé řešení a jeho jednotlivé komponenty uvedené vmodelu poskytne
Objednateli dokumentaci implementovaného řešení v detailu umožňujícím:
* | vytvořit hardwarové a infrastrukturní prostředí,
* | vytvořit síťové a komunikační prostředí,
© | vytvořit softwarové prostředí (operační systémy, knihovny, DB systémy, kompilátory
atd.),
© | vytvořit novou instalaci vyvinutého SW produktu,
* | provést vyžadovanou provozní hardwarovou konfiguraci,
s | provést vyžadovanou provozní softwarovou konfiguraci (nastavení rolí, přístupových práv
atd.),
© | provést softwarovou a hardwarovou konfiguraci navazujících systémů (datová
konektivita, dohled, monitoring atd.),
© | provést HW a SW bezpečnostní konfiguraci,
© | poskytovat informace o funkcích a použití SW produktu pro všechny skupiny uživatelů,
© | poskytovat informace o funkcích a použití SW produktu pro podporu a údržbu,
© | poskytovat informace o funkcích a použití SW produktu pro navazující IS,
© | provést postupy obnovy po havárii.
Jako součást dokumentace jsou požadovány nejen textové dokumenty, ale celkově i artefakty
dokumentující postupy ve výše uvedených oblastech:
s | popisy,
e diagramy,
* tabulky,
o
komentované zdrojové kódy ke všem komponentám, které nejsou klasifikovány jako
standardní software (viz. katalogový list služby, v detailu dle závazných architektonický
standardů Objednatele),
e | artefakty k SW příslušenství (operační systémy, knihovny, DB systémy, kompilátory atd.),
* | artefakty k HW, komunikaci, infrastruktuře atd.
V případě následné podpory a rozvoje řešení Zhotovitel řádně zdokumentuje všechny provedené
změny řešení.
Pro každou službu implementovanou v řešení AgriBus je Objednatelem požadována dokumentace
obsahující:
* | definici služby,
s | popis služby,
* | přehled vstupních a výstupních parametrů včetně popisu chybových hlášení,
metodiku plnění vstupních a výstupních parametrů,
popis logiky služby,
popis testovacího scénáře,
případy užití služby.
Objednatel předá Zhotoviteli šablony dokumentů pro záznam výše uvedené dokumentace.
47
o k
FINISTEASTVO ZEMĚDĚLSTVÍ
6.10. METODIKA
Zhotovitel v rámci milníku Metodika a školení navrhne a zdokumentuje metodiku pro design, vývoj,
testování a nasazení nových služeb a integraci nových Poskytovatelů a Konzumentů služeb využitím
řešení AgriBus a metodiku pro návrh, vývoj, testování a nasazení nových procesních aplikací či
agendových systémů v AgriBus BPM. Metodika bude proškolena dle požadavků uvedených v kapitole
6.13 Školení.
Metodika bude v části určené pro vývoj procesů a aplikací v BPM AgriBus:
Reflektovat provozní model uvedený v kapitole 6.11 Služby provozu a podpory zejména pak
rozdělení odpovědností za provoz vývojového, testovacího a produkčního prostředí a
odpovědností za provoz a rozvoj procesních aplikací a agendových systémů;
Obsahovat dokumentaci procesů a pracovních postupů pro návrh, implementaci, testování a
dokumentaci nových funkcionalit;
Obsahovat dokumentaci procesů a pracovních postupů pro předání funkcionality
dodavatelem procesních aplikací provozovateli BPM AgriBus (Zhotoviteli) k testování a
nasazení do produkčního prostředí;
Obsahovat popis a šablony vstupních a výstupních dokumentů a dalších artefaktů využitých
v rámci výše uvedených procesů;
Obsahovat návrh měřících bodů a způsobu měření pro posouzení připravenosti procesních
aplikací pro nasazení v produkčním prostředí;
Zahrnovat podklady pro školení metodiky dle požadavků uvedených v kapitole 6.13 Školení;
Metodika bude v části určené pro podporu vývoje funkcionalit v řešení ESB AgriBus zahrnovat:
Dílčí metodiku pro návrh služeb v řešení AgriBus na všech komunikačních úrovních dle
logického modelu uvedeného v kapitole 5.1 Komunikační sběrnice ESB respektující obecné
závazné architektonické standardy Objednatele. Metodika bude mimo jiné zahrnovat
detailní architektonické standardy (návrhy na rozšíření standardů Objednatele), standardní
postupy pro návrh nových služeb, referenční modely vycházející z obecných referenčních
modelů Objednatele (Archimate) a popis použití referenčních modelů. Závazné
architektonické standardy Objednatele spolu s obecnými referenčními modely Archimate
budou předány Zhotoviteli po podpisu smlouvy.
Dílčí metodiku pro implementaci nových služeb v řešení AgriBus obsahující informace o
standardních programovacích jazycích, použitých frameworků, závazně požadovaném
strukturování kódu, pravidlech pro komentování kódů, šablon pro implementační
dokumentaci a pravidel pro cílové umístění dokumentace.
Dílčí metodiku popisují postupy vývoje a pravidla pro využití vývojového prostředí a
testovacích dat.
Dílčí metodiku pro testování služeb v řešení AgriBus zahrnující návrh postupů, dokumentace
a nástrojů pro funkční, zátěžové a bezpečnostní testování služeb.
Dílčí metodiku pro postupy a popis použití nástrojů pro zajištění konzistence produkčního,
testovacího a vývojového prostředí AgriBus a pro přenos funkcionalit mezi jednotlivými
prostředími, specifikaci standardních testů prováděných před migrací funkcionalit do
produkčního prostředí a postupy pro návrh kritérií určených pro posouzení připravenosti
služeb pro přenos do produkčního prostředí.
=
n.
PV ZEMĚDĚLSTVÍ
* | Dílčí metodiku pro návrh a začlenění nových funkcionalit do dohledových systémů AgriBus.
Metodika bude v části určené pro podporu vývoje Poskytovatelů služeb zahrnovat:
* | Metodiku a postupy pro vývoj integračních komponent nových Poskytovatelů, doporučené
programovací jazyky a framework.
« Architektonické standardy pro návrh integračních komponent Poskytovatelů služeb včetně
referenčních modelů Archimate a seznamu povinně nebo volitelně využitelných sdílených
komponent. Zhotovitel připraví návrh rozšíření existujících architektonických standardů
Objednatele a souvisejících šablon.
* Požadavky na podobu integračních rozhraní zajišťující mimo jiné, že rozhraní bude
dostatečně univerzální pro orchestraci služeb v řešení AgriBus a bude poskytovat všechny
běžně požadované informace bez nutnosti vývoje dodatečných funkcionalit.
© Proces a postupy pro zadání a řízení požadavků na implementaci nové služby AgriBus
z podnětu Poskytovatele služby včetně referenčních modelů Archimate, požadavků na
monitoring, specifikací předpokládané zátěže a požadovaného výkonu a šablon souvisejících
dokumentů nebytných pro technickou specifikaci požadavku. Procesy budou navázány na
existující procesy Objednatele;
Metodika bude v části určené pro podporu vývoje Konzumentů služeb zahrnovat:
© Metodiku a standardy pro použití integračních komponent pro přístup k informacím
v Poskytovatelích služeb.
« Architektonické standardy pro návrh integračních komponent Konzumentů služeb včetně
referenčních modelů Archimate a seznamu povinně nebo volitelně využitelných sdílených
komponent. Zhotovitel připraví návrh rozšíření existujících architektonických standardů
Objednatele a souvisejících šablon.
« Pravidla pro stanovení rámce integrační logiky, která může být implementována
v Konzumentech služeb a která musí být dle závazných standardů implementována jako
služba v řešení AgriBus.
« Proces a postupy pro zadání a řízení požadavků na implementaci nové služby AgriBus
z podnětu Konzumenta služby včetně referenčních modelů Archimate, požadavků na
monitoring, specifikací předpokládané zátěže a požadovaného výkonu, šablon souvisejících
dokumentů nebytných pro technickou specifikaci požadavku. Procesy budou navázány na
existující procesy Objednatele.
6.11 SLUŽBY PROVOZU A PODPORY
Zhotovitel zajistí provoz a podporu řešení AgriBus zahrnujícího vývojové, testovací a produkční
prostředí BPM AgriBus a vývojové, testovací a produkční prostředí ESB AgriBus na období 3 let od
okamžiku předání dílčí části Díla, jmenovitě splnění milníku „Předání a převzetí Systému AgriBus“, dle
požadavků a parametrů uvedených v Katalogovém listu služby. Parametry provozu vývojového
prostředí jsou plně vkompetenci Zhotovitele. Parametry provozu testovacího a produkčního
prostředí se řídí Katalogovými listy. Pro vyloučení pochybností se uvádí, že komponenty BPM AgriBus
spolu s komponentami ESB AgriBus tvoří kompletní řešení AgriBus včetně všech hardware a software
komponent a podpůrných systémů.
Dodávaná úroveň maintenance a podpory výrobce pro řešení AgriBus je plně v kompetenci
Zhotovitele a musí odpovídat požadavků na služby provozu a podpory definovaným v katalogových
listech řešení AgriBus. Podpora dle katalogových listů služby musí zejména zahrnovat:
* | zajištění maintenance všech software a hardware produktů,
49
hJ
k Pk
MINISTERSTVO ZEMĚDĚLSTVÍ
s | zajištění a zprostředkování podpory výrobce všech hardware a software produktů,
© © podporu Zhotovitele řešení,
e | údržbu zahrnující standardní profylaktické aktivity,
e | aplikaci opravných patchů či realizaci upgrade v důsledku chyb řešení,
e | monitoring a údržbu opatření pro zajištění kontinuity řešení dle požadavků definovaných
v kapitole 6.12 Zajištění kontinuity provozu řešení AgriBus,
« | testování a nasazování procesních aplikací vyvinutých třetími stranami,
s | práce pro konfigurace nových služeb řešení AgriBus (reparametrizace).
Zhotovitel dále musí doložit, že nejdéle tři (3) kalendářní měsíce před okamžikem předložení nabídky
nebylo rozhodnuto:
« | o ukončení podpory výrobce jakékoli zahrnuté softwarové nebo hardwarové komponenty
dříve než za 5 let od okamžiku plánovaného předání Díla, jmenovitě milníku „Akceptace
Implementace a migrace“ (tzn. end-of-support všech software a hardware produktů nesmí
být dříve než za 5 let od okamžiku předání Díla),
s | o ukončení prodeje nebo vývoje hardware či software produktu dříve než za 3 roky od od
okamžiku předání Díla, jmenovitě milníku „Předání a převzetí Systému AgriBus“ (tzn. end-of-
sales či end-of-life všech software a hardware produktů nesmí být dříve než za 3 roky od
okamžiku předání Díla).
Podpora Zhotovitele, maintenance výrobce a podpora výrobce všech hardware a software
komponent tvořících řešení AgriBus na období dodávky a implementace, tedy od dokončení milníku
„Dodávka hardware“ do ukončení milníku „Předání a převzetí Systému AgriBus“, musí být zahrnuta
v ceně hardware a software licence, jmenovitě v položkách „Hardware“ a „Standardní SW a instalace
SW" dle rozpočtu projektu.
Podporu Dodavatele a maintenance a podporu výrobce původního řešení Oracle ESB za účelem
souběžného běhu řešení a to do doby ukončení ověřovacího provozu zajistí Objednatel. Zajištění
podpory původního řešení Oracle ESB není součástí plnění této veřejné zakázky.
6.11.1 PROVOZ A PODPORA BPM AGRIBUS
BPM AgriBus je část systému AgriBus zajišťující funkce centrální procesní platformy. Funkcionalita
bude využita pro standardní budování procesních aplikací, zejména pak agendových aplikací,
Objednatele. Budoucí rozvoj BPM AgriBus předpokládá, že návrh, vývoj a správu procesních aplikací
či agendových systémů v BPM AgriBus mohou zajišťovat i jiní dodavatelé rozdílní od Zhotovitele.
Řešení AgriBus proto musí podporovat souběžnou práci více dodavatelů v BPM AgriBus a poskytovat
nástroje pro systematické a řízené nasazení nových funkcionalit do produkčního BPM systému.
Obrázek 14 - AgriBus spolupráce dodavatelů
Dodavatel 2 Dodavatel 4
Rozvoj Provoz | Rozvoj
Zhotovitel
Provoz | Rozvoj
Dodavatel 1
Provoz | Rozvoj
Dodavatel 3
Provoz | Rozvoj
ji Agendový systém 2
-| Agendový systém 3
=
ks
k
dní Agendový systém 1
<| Editorský systém 1
Zhotovitel v rámci provozu a podpory bude zajišťovat nasazení nově vyvinutých či modifikovaných
procesních aplikací Zhotovitelem anebo jiným dodavatelem do testovacího či produkčního prostředí
BPM AgriBus. Před nasazením funkcionality Zhotovitel provede všechny nebytné typy testů ve
vývojovém nebo testovacím prostředí a provede nasazení do testovacího nebo produkčního
prostředí. Otestováním funkcionalit, potvrzením výkonnostních a jiných parametrů a následným
nasazením do testovacího nebo produkčního prostředí Zhotovitel potvrzuje, že akceptoval veškeré
nároky nových nebo měněných procesních aplikací na funkcionalitu, prostředky, výkonnost atd. a
nasazení funkcionality neovlivní jím poskytované služby provozu a podpory AgriBus dle příslušných
katalogových listů AGBO1. Případné reparametrizace, modifikace či rozšíření ESB AgriBus související
snasazením procesních aplikací jsou zajišťovány Zhotovitelem dle parametrů definovaných
v katalogovém listu AGBO5 Reparametrizace a optimalizace. Testování, spolupráce na ladění a
úpravách s dodavateli procesních aplikací je zajištěna také v rámci katalogového listu AGBO5
Reparametrizace a optimalizace. Přesná podoba procesů pro návrh, vývoj a nasazení procesních
aplikací vBPM AgriBus a souvisejících služeb v ESB AgriBus je předmětem návrhu metodiky dle
požadavků definovaných v kapitole 6.10 Metodika.
6.11.2 PROVOZ A PODPORA ESB AGRiBus
Provoz a rozvoj ESB AgriBus bude zajišťovat Zhotovitel dle parametrů definovaných v katalogových
listech AgriBus. Metodika pro rozvoj řešení včetně postupů testování a nasazení nových služeb,
využití vývojového a testovacího prostředí bude navržena Zhotovitelem v rámci dodávky plnění dle
požadavků uvedených v kapitole 6.10 Metodika.
6.12 ZAJIŠTĚNÍ KONTINUITY PROVOZU ŘEŠENÍ AGRIBUS
Je požadováno zajištění pravidelných záloh všech konfigurací a dat, které jsou nezbytné pro řádnou
obnovu řešení Agribus v případě havárie s následkem úplné ztráty produkčního, testovacího nebo
vývojového prostředí. Součástí dodávky jsou veškeré hardware a software komponenty včetně
úložišť dat dimenzovaných na předpokládané objemy záloh. Zhotovitel v rámci dodávky provede:
* | návrh plánů řízení kontinuity řešení Agribus,
o | přehled všech klíčových komponent vyžadujících zálohování či jiné zabezpečení,
o | návrh metod zabezpečení komponent,
o detailní plány zálohování všech klíčových komponent,
« | fyzické zabezpečení klíčových komponent,
s © návrh plánů a postupů pro obnovu řešení Agribus v případě havárie,
l
e © vývojrutin nebo nastavení systémů pro vykonávání zálohovacích úloh,
© návrh procesů a postupů pro testování plánů a postupů pro obnovu řešení včetně
zálohování, obnovy záloh a testování záložních médií,
s © zajištění monitoringu klíčových komponent a úloh systému zálohování.
Detailní požadavky na zálohování jsou uvedeny v Katalogovém listu služby.
6.13 ŠKOLENÍ
V rámci projektu dodávky řešení AgriBus je požadováno vypracování metodiky (viz. kapitola 6.10
Metodika) a veškeré související dokumentace včetně uživatelské dokumentace a podkladů pro
školení. V rámci dodávky je dále požadováno provedení školení následovně:
sva
Školení architektů a vývojářů služeb AgriBus
Účastníci: Zaměstnanci útvarů rozvoje a provozu ICT Objednatele, architekti a vývojáři
Zhotovitele zajišťující konfigurační práce dle katalogového listu služby AGBO5
Reparametrizace a optimalizace nebo se podílející na rozvoji řešení AgriBus
v rámci projektů či změnových požadavků.
Max. počet účastníků: 20 ve dvou cyklech
Téma: Metodika návrhu služeb v řešení AgriBus navržená dle kapitoly 6.10
Metodika.
Hlavní náplň školení:
e © představení architektury a technického řešení AgriBus;
© představení funkcionalit řešení AgriBus;
e | představení uživatelských a administrátorských rozhraní AgriBus;
© © proškolení pro práci se všemi rozhraními a funkcionalitami využitými v rámci návrhu a vývoje
služeb v AgriBus;
© | seznámení s procesem přijmu a obsluhy požadavků na implementaci nebo modifikaci služeb
včetně představení standardních šablon technické specifikace Konzumentů a Poskytovatelů
služeb;
e © proškolení dílčí metodiky pro návrh nových služeb včetně seznámení se závaznými
architektonickými standardy a formáty a úložišti pro dokumentaci architektury;
e © proškolení dílčí metodiky pro implementaci nových služeb včetně doporučení pro využití
jednotlivých programovacích jazyků a framework;
» © proškolení dílčí metodiky pro testování funkcionalit v řešení AgriBus mimo jiné postupy a
šablony pro organizací testování a záznam testovacích scénářů a výsledků testování,
proškolení standardních nástrojů a postupů použitých při testování;
s | proškolení postupů pro využití vývojového a testovacího prostředí AgriBus, pravidel pro
zásahy do jednotlivých prostředí a procesů a postupu pro přenos funkcionalit do produkčního
prostředí.
wo
Školení architektů a vývojářů Konzumentů služeb AgriBus
Účastníci: Zaměstnanci útvarů rozvoje a provozu ICT Objednatele, architekti a vývojáři
dodavatelů Konzumentských systémů a aplikací.
Max. počet účastníků: 40 ve dvou cyklech
52
Téma:
Metodika návrhu a implementace integračních komponent Konzumentů
služeb pro komunikaci prostřednictvím řešení AgriBus navržená dle kapitoly
6.10 Metodika.
Hlavní náplň školení:
e
představení základní architektury a technického řešení AgriBus, zejména úloh Poskytovatelů
služeb, Konzumentů služeb, řešení AgriBus a jejich vzájemné spolupráce;
proškolení dílčí metodiky pro návrh architektury integračních komponent aplikace;
představení závazných architektonických standardů, referenčních modelů a metod pro
modelování a dokumentaci architektury;
představení zdrojů informací, struktury dokumentace a nástrojů pro vyhledávání sdílených
funkcionalit a komponent;
představení pravidel pro stanovení rámce integrační logiky, která může být implementována
v Konzumentech služeb a která musí být dle závazných standardů implementována jako
služba v řešení AgriBus;
představení požadované formy, struktury a obsahu zadání (technické specifikace) na
implementaci nové služby v AgriBus včetně představení dostupných šablon;
seznámení s procesem zadání a obsluhy požadavků na implementaci nebo modifikaci služeb
v AgriBus;
Školení architektů a vývojářů Poskytovatelů služeb AgriBus
Účastníci: Zaměstnanci útvarů rozvoje a provozu ICT Objednatele, architekti a vývojáři
dodavatelů Poskytovatelských systémů a aplikací.
Max. počet účastníků: 40 ve dvou cyklech
Téma:
Metodika návrhu a implementace integračních komponent Poskytovatelů
služeb pro komunikaci prostřednictvím řešení AgriBus navržená dle kapitoly
6.10 Metodika.
Hlavní náplň školení:
představení základní architektury a technického řešení AgriBus, zejména úloh Poskytovatelů
služeb, Konzumentů služeb, řešení AgriBus a jejich vzájemné spolupráce;
proškolení dílčí metodiky pro návrh architektury integračních komponent aplikace;
představení závazných architektonických standardů, referenčních modelů a metod pro
modelování a dokumentaci architektury;
představení zdrojů informací, struktury dokumentace a nástrojů pro vyhledávání sdílených
funkcionalit a komponent;
představení závazných požadavků kladených na integrační rozhraní Poskytovatele zajišťující
mimo jiné dostatečnou univerzálnost rozhraní;
představení požadované formy, struktury a obsahu zadání (technické specifikace) na
implementaci nové služby v AgriBus včetně představení dostupných šablon;
seznámení s procesem zadání a obsluhy požadavků na implementaci nebo modifikaci služeb
v AgriBus;
Školení bude probíhat V prostorách Objednatele. Prezentace, živé ukázky systémů, dokumentů a
dílčích postupů budou realizovány na jednom (1) PC s velkoplošnou projekcí, pro které bude zajištěn
53
e
/ MINMiSTERSTVO ZEMĚDĚLSTVÍ
přístup k požadovaným systémům a zdrojům Objednatele. Každý cyklus bude zakončen písemnou
zkouškou, která na 30 otázkách osvědčí znalost dané problematiky.
Výstupem školení bude individuální písemné osvědčení v listinné podobě o absolvování školení a
zkoušky pro každého z účastníků.
6.14
PLATFORMY
Software komponenty musí podporovat běh na operačních systémech za následujících podmínek:
Serverové komponenty řešení AgriBus je z důvodů kompatibility s již provozovanými systémy
Objednatele možné provozovat na platformách HP-UX verze 11i v3 a vyšší/Red Hat
Enterprise Linux AS release 6 a vyšší (64 bit) nebo Microsoft Windows Server 2008 R2 a vyšší
(64 bit) (postačuje podpora jedné z platforem).
Aplikace tvořící řešení AgriBus s vysokou paměťovou náročností musí podporovat nativní běh
v 64-bitovém režimu bez omezení (např. 32-bit konektory), všechny knihovny musí být
kompatibilní se 64-bit prostředím.
Pro aplikace tvořící řešení AgriBus s nízkou paměťovou náročností je vítána podpora běhu
v 32-bitovém prostředí za účelem úspory paměti, diskových kapacit a výkonu.
Vzhledem k aktuálnímu stavu desktop systémů provozovaných Objednatelem, kdy většina
desktop systémů využívá operační systém Microsoft Windows a níže uvedené internetové
prohlížeče, je požadováno, aby klientské komponenty řešení podporovaly webový přístup
prostřednictvím standardních internetových prohlížečů (zejména Firefox, Internet Explorer,
Chrome, Opera) v posledních vydaných verzích a nebo poskytovaly desktop aplikace
provozovatelné na platformě verze Windows 7 a vyšší.
6.15 OSTATNÍ
Tato kapitola obsahuje ostatní požadavky a informace, které musí uchazeč v rámci realizace díla
respektovat.
Řešení AgriBus představuje podpůrný systém a na jeho spolehlivé činnosti závisí provoz
velkého počtu informačních systémů a aplikací MZe. V řadě případů na řádné funkcionalitě
systémů závisí tisíce uživatelů (především zemědělců). implementace AgriBus systému a
migrace existujících služeb nesmí v žádném případě ovlivnit činnost ostatních informačních
systémů mimo období plánovaných odstávek určených k testování a ladění funkcionalit a
migraci řešení viz. kapitola 6.8 Testování.
Vybrané obsluhované aplikace přímo ovlivňují finanční toky určené pro dotace a v tomto
ohledu musí být informace v rámci AgriBus přenášena nejen spolehlivě, nepřetržitě, ale i
správně, zabezpečeně a auditovaně.
Obsluhované IS budou mít podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o
změně souvisejících zákonů (zákon o kybernetické bezpečnosti), zřejmě statut "významný
informační systém", případně některé IS' mohou být součástí kritické informační
infrastruktury. V tomto ohledu podpůrný systém AgriBus musí splňovat podmínky kladené na
tyto typy systémů.
54
tZ
/ MIN'STERSTVO ZEMĚDĚLSTVÍ
e AgriBus obsluhuje rovněž některé externí systémy, jejichž funkčnost je na tomto systému
plně závislá a případná migrace nesmí ohrozit provoz těchto systémů mimo období
plánovaných odstávek.
* Obsluhované subjekty závisí často velmi významně na legislativě ČR a EU a dalších
předpisech. Změny legislativy musí být možné jednoduše a efektivně promítnout do
funkcionality a konfigurace AgriBus nebo logiky obsluhovaných služeb.
* Vzhledem k uvedené složitosti informačního prostředí je nutné vytvořit speciální testovací
postupy tak, aby byla zvládnuta koordinace přípojených subjektů (např. testovat na
simulovaných datech a simulovaných prvcích infrastruktury apod.).
Objednatel Zhotovitel
v Praze/ - dne 05 -04- 2086 v??_AZE» dno 2A .3. Je d6
NE NAJGEENM
Česká republika — Ministerstvo zer : dělství OKsystem a.s.
Ing. Zdeněk Adamec * Ing. Vítězslav Ciml
Náměstek pro řízení Sekce ekonomiky a Člen představenstva
informačních technologií
MiNISTERSTVO
ZEMĚDPĚLSTVÍ OKsystemC
M v ě | as. U.
1000 Praha 1- Nové Město 40 21 Pra.
Na Pankráci 125, 1 '
je 1Č: 27373665, DIČ: CZ2737 L
TY
Příloha č. 1— Dokumentace ESB Oracle
Tato příloha obsahuje na přiloženém CD důvěrné informace; v souladu se zadávací dokumentací
veřejné zakázky byla Zhotoviteli předána po předchozím podpisu dohody o ochraně důvěrných
informací.
SMLOUVA O DÍLO - 52014-0043, číslo sml. DMS 183-2014-12122
č.sp, 59VD21314/2011-12120, č.j. 8299/2014-MZE-12122, č.sp. pr. 15A14906/2014-13310
Vybudování a provoz komunikační infrastruktury MZE — AgriBus
Příloha č. 8
Přehled závazných požadavků
MINISTERSTVO ZEMĚDĚLSTVÍ
11 PŘEHLED ZÁVAZNÝCH POŽADAVKŮ
PŘEHLED ZÁVAZNÝCH POŽADAVKŮ
Společnost OKsystem a.s., se sídlem Na Pankráci 1690/125, 140 21 Praha 4 - Nusle, IČO: 27373665, zapsaná
v obchodním rejstříku vedeném Městským soudem v Praze, oddíl B, vložka 20326, za kterou jedná ing.
Martin Procházka, předseda představenstva („Uchazeč“), tímto pro účely veřejné zakázky s názvem
„Vybudování a provoz komunikační infrastruktury MZe - AgriBus“ („Veřejná zakázka“), jejímž
zadavatelem je Česká republika — Ministerstvo zemědělství, se sídlem Těšnov 65/17, 110 00 Praha 1 —
Nové Město („Zadavatel“), čestně prohlašuje, že jím nabízené plnění splňuje níže uvedené funkční
požadavky Zadavatele následovně:
službách do centrálního registru
služeb
Požadavek Splňuje Komentář
(ANO/NE)
Enterprise Service Bus (ESB)
Podpora integrace systémů ANO
prostřednictvím webových služeb dle Principy shodné se základní filozofií celého
principů SOA řešení Oracle Soa Suite 12c.
Standardizovaná rozhraní pro přístup ANO Standardizovaná rozhraní jsou zajištěna sadou
k ESB z různých operačních systémů a komponent Service Adapter produktu Oracle
technologií Soa Suite 12c.
Integrace koncových bodů ANO
využívajících různé komunikační Integrace s využitím kompozitních aplikací
protokoly Oracle Soa Suite 12c.
Podpora transportů HTTP, JMS, JCA, ANO Podpora je zajištěna pomocí
Enterprise Java Bean, web services standardních komponent Service Adapter
produktu Oracle Soa Suite 12c.
Podpora synchronního a ANO Volání jsou nativně podporována produktem
asynchronního volání služeb Oracle Soa Suite 12c.
Podpora mediace a transformace ANO Oracle SOA Suite 12c plně podporuje mediace
zpráv a transformace zpráv.
Kompozitní aplikace a BPEL procesy, xpath,
xslt, xguery v rámci produktu Oracle Soa Suite
12c.
Integrace s centrálním registrem ANO Centrální registr GEM Soa Governance se
služeb integruje pomocí komponenty Soa Suite
Adapter.
Propagace služeb a informací o ANO Propagace probíhá v rámci nasazení služeb,
dále je obsah registru automatizovaně
aktualizován z ESB pomocí Soa Suite Adapter.
369
Dynamické vyhledávání služeb za ANO Centrální registr GEM Soa Governance
běhu v centrálním registru poskytuje Governance APi umožňující
dynamické vyhledávání služeb.
Dynamické směrování podle obsahu ANO Směrování dle obsahu zprávy lze řešit mediaci
zpráv či podle OoS kritérií a politik nebo BPEL procesem, Oo0S pomocí
standardních mechanizmů messagingu.
Podpora kanonického formátu zpráv ANO Systém nabízí sdílené úložiště pro definice
zpráv MDS (Metadata Services).
V MDS lze spravovat kanonické formáty zpráv.
Možnost řízení priority zpráv dle ANO
poskytovatele služby či dle Podporováno pomocí nastavení priorit
konzumenta služby messagingu (JMS a Oracle AO).
Frontování požadavků/zpráv ANO Frontování lze zajistit pomocí JMS (Weblogic)
nebo Oracle AO (Oracle db). Řešení podporuje
obě technologie.
Podpora zaručeného doručení nebo ANO Zaručené doručení zpráv je zajištěno pomocí
doručení zpráv právě jednou standardních mechanizmů messagingových
komponent JMS nebo Oracle AO a nastavením
politik,
Přenos zpráv je v případě zaručeného doručení
v každém bodě komunikace perzistentně
uložen v databázi popřípadě souborovém
systému.
Podpora orchestrace služeb, volání ANO
zúčastněných koncových bodů v Systém zajišťuje robustní podporu pro
rámci definovaného workflow orchestraci služeb pomocí BPEL procesů.
Podpora transakčního zapracování ANO Oracle 50a Suite 12c nativně podporuje
transakční zpracování pro procesy, které
využívají komponenty (služby) s podporou
transakčního zpracování. Tam kde transakční
zpracování není možné, lze využít
kompenzačních mechanizmů.
Možnost uložit stav transakce ANO Aktuální stav procesu lze uložit do
perzistentního úložiště (tzv. princip
dehydratace).
Možnost pozastavení a opakovaného ANO Proces lze pozastavit na staticky či dynamicky
spuštění transakce definovaný časový interval, nebo čekáním na
přijetí další zprávy či vynucením manuálního
zásahu uživatele (human task).
Schopnost provést roll-back ANO Služby podporují automatický rollback, pokud
transakce
daná služba skončí v chybovém stavu,
popřípadě dojde k specifikovaným
OkKsystem
370
podmínkám.
Podpora automatických a manuálních ANO Ve službách lze definovat kompenzační
kompenzačních akcí pro případ mechanizmus (tzv. Compensation Handler) či v
selhání transakce případě potřeby manuálně zavolat
kompenzační akci (Compensate) pro
sledovanou oblast (Scope) procesu.
Poskytování přehledu běžících ANO Produkt Oracle Enterprise Manager 12c
transakcí poskytuje přehled všech instancí nasazených
služeb. V instancích lze vyhledávat a filtrovat
běžící procesy.
Schopnost obsluhovat selhání a ANO V rámci rozhraní Oracle Enterprise Manager
chyby v rámci workflow 12c lze spustit akci obnovy (recovery)
chybových (faulted) instancí jednotlivých
služeb. Enterprise Manager pro tyto účely
obsahuje sekci s názvem Error Hospital, kde lze
tyto akce provádět i hromadně (tzv. Bulk
Recovery).
Možnost nastavení politik pro ANO Pro jednotlivé kompozitní aplikace i dílčí
obsluhu chyb procesy lze jednoduše definovat politiky pro
obsluhu chyb, tzv. Fault-policies.
Podpora řízení běhu prostřednictvím ANO Běh událostí lze řídit pomocí komponenty
událostí (Event Driven Architecture) Event Delivery Network v rámci produktu
Oracle Soa Suite 12c.
Možnost přenosu objemných ANO Přenos objemných souborů bude pomocí ESB
souborů v řádu 100 MB a výše mimo pouze řízen, samotné objemné soubory budou
komunikační toky ESB (soubory přenášeny mimo komunikační toky ESB.
nejsou přenášeny zakódované v těle Pro přenos objemných souborů bude využito
zprávy) souborové úložiště.
Procesní platforma (BPM AgriBus)
Podpora pro dlouho běžící procesy ANO BPM Platforma podporuje dlouho běžící
zahrnující lidské vstupy procesy, stavy instancí procesů jsou
perzistentně uloženy v databázi. Procesy
mohou obsahovat automatizované aktivity i
aktivity zpracovávané uživatelem. Uživatelé
pro svůj vstup využívají formuláře agendových
aplikací.
Webové rozhraní pro interakci s ANO Agendové aplikace postavené nad BPM
uživateli platformou poskytují webové rozhraní.
Uživatelé přistupují do aplikace pomací
webového prohlížeče.
Podpora vývoje dynamických ANO BPM platforma podporuje dynamické webové
webových formulářů s možností
formuláře. Formuláře se přizpůsobují
OKsystem
371
modifikace skripty na pozadí
aktuálnímu stavu business procesu, kterého
jsou součástí. Platforma podporuje úpravy
vzhledu i chování formulářů pomocí skriptů.
Podpora integrace webového ANO BPM platforma podporuje integraci webového
rozhraní do portálového řešení a rozhraní do portálového řešení včetně
podpora SSO podpory SSO. BPM platforma v první řadě
podporuje portálová řešení postavená na
technologii Microsoft Sharepoint. BPM
platforma podporuje rovněž portálová řešení
využívající Java portlety, pomocí Java Portlet
adaptéru.
Rozšiřitelnost o další aplikační ANO Řešení postavená na BPM platformě lze
komponenty dle specifických rozšiřovat o specifické validace, kontrolní
požadavků agentových systémů prvky a aktivity dle specifických nároků
jednotlivých agendových systémů.
Registr služeb
Poskytuje katalog s informacemi o ANO Produkt GEM Soa Governance poskytuje
službách a jejich metadatech komplexní informace o službách. Metadata
služeb jsou uložena v komponentě MDS, která
je součástí řešení Registru služeb.
Podporuje řízení životního cyklu ANO Produkt GEM Soa Governance umožňuje řízení
služeb životního cyklu služeb.
Životní cyklus služby lze konfiguračně upravit
dle konkrétních procesů SOA Governance
Zadavatele.
Životní cyklus služeb mohou řídit pouze
uživatelé s příslušným oprávněním. O změně
stavu služby v životním cyklu jsou informováni
přihlášení uživatelé.
Prezentuje v jakém stavu životního ANO Produkt GEM Soa Governance zobrazuje pro
cyklu se služba nachází každou službu informace o aktuálním stavu
životního cyklu,
Poskytuje informace o verzi služeb a ANO Produkt GEM S0a Governance eviduje
doporučeních pro využití jednotlivých jednotlivé verze služeb včetně informací o
verzí příslušné verzi.
Umožňuje dynamicky odkazovat ANO Produkt GEM 50a Governance poskytuje
poslední produkční verzi služby Governance API, kde lze vyhledávat poslední
verzi služby a získat informace o poslední verzi
služby (včetně koncového bodu služby).
Eviduje informace, jak jsou služby ANO Produkt GEM Soa Governance obsahuje
vzájemně využívány
evidenci závislostí mezi službami.
Závislosti jsou přehledně zobrazeny pomocí
tabulek a rovněž graficky grafem závislostí.
OKsystem
372
pre ZE hl TI be) Z hc KURE A od ká] EEMUHCUY/ ea EX NY
Graf závislostí obsahuje vzájemné závislosti
služeb i závislosti na poskytujících systémech.
Umožňuje dynamicky za běhu ANO Produkt GEM Soa Governance poskytuje
vyhledávat a vybírat end-point volené Governance API, kde lze za běhu vyhledávat
služby koncový bod služby podle parametrů zadaných
v požadavku na volané API,
Poskytuje grafické rozhraní pro ANO Produkt GEM Soa Governance je dodáván s
prezentaci informací o službách grafickým rozhraním ve formě webové
aplikace.
Umožňuje prezentovat vzájemné ANO Produkt GEM Soa Governance obsahuje
využití a závislosti služeb informace o vzájemném využití a závislostech
služeb a umožňuje prezentaci v grafické i
tabulkové formě.
Designér služeb
Umožňuje grafický návrh mediačních ANO Návrh mediačních toků a služeb probíha v
toků a služeb na všech grafickém prostředí produktu Oracle
komunikačních vrstvách Jdeveloper 12c. Tento produkt je
předinstalován se všemi potřebnými pluginy.
Využívá komponenty evidované v ANO Designér služeb (Oracle JDeveloper 12c) je
registru služeb pro návrh nových integrován s komponentou registru služeb
mediačních toků či služeb (integrace s MDS (Metadata Services) pro využití
registrem) evidovaných služeb a jejich metadat v rámci
návrhu.
Podporuje uložení a opětovného ANO Jednotlivé služby se ukládají formou projektu
načtení navrženého designu (SOA Project), skupiny služeb se sdružují do
mediačních toků či služeb celků zvaných aplikace (SOA Application).
Podporuje návrh workflow služeb ANO Součástí produktu JDeveloper 12c je editor
využitím BPEL BPEL procesů, ve kterém lze navrhovat
workflow.
Monitoring
Detekce chybových stavů komponent ANO Logika plánování sběru informací je součástí
tvořících řešení AgriBus produktu Nagios. K vyhodnocení a reakci bude
využito jeho API.
Monitoring výkonnostních a ANO Logika plánování sběru informací je součástí
kapacitních parametrů komponent produktu Nagios. K vyhodnocení a reakci bude
tvořících řešení AgriBus využito jeho API.
Detekce a archivace chybových stavů ANO Detekci provádí logika Nagiosu na základě
v rámci volání služeb / přenosu zpráv
informací z rozhraní HA (Oracle AO). Archivace
probíhá přes rozhraní HA.
OkKsystem
373
Detekce a archivace neoprávněných ANO Detekci provádí logika Nagiosu na základě
volání služeb informací z rozhraní HA (Oracle AO). Archivace
probíhá přes rozhraní HA.
Podpora monitoringu délky ANO Monitoring bude periodicky kontrolovat počet
komunikačních front požadavků ve frontách používaných pro
komunikaci.
Podpora odesilání (aktivní, pasivní) ANO S využitím API Nagiosu předáno protokolem
stavových a výkonnostních informací SYSLOG/TLS a pomocí dashboardu Centreonu.
a událostí do externích
monitorovacích systémů
Archivace neagregovaných zpráv na ANO Historický archiv obsahuje rozhraní (Oracle
všech komunikačních úrovních AO), které využije komponenta monitoring pro
zápis informací.
Poskytování dat pro ŠLA monitoring a ANO Zajišťuje grafické rozhraní Centreonu a HA.
reporting
Historický archiv
Příjem a archivace neagregovaných ANO Historický archiv obsahuje rozhraní (Oracle
dat o realizovaných voláních na všech AO), které využijí ESB platforma pro zápis
komunikačních vrstvách AgriBus informací.
Příjem a archivace bezpečnostních a ANO Historický archiv obsahuje rozhraní (Oracle
provozních událostí z monitoring AO), které využije komponenta monitoring pro
komponenty zápis informací.
Podpora pro externí reporting a ANO Data archivu budou uložena v databázi Oracle
analýzy nad historickým archivem Database 12c, která nabízí standardní rozhraní
pro externí reportingové nástroje.
Zdokumentovaný datový model ANO Součástí dokumentace archivu bude kompletní
datový model včetně příslušného popisu.
Místo: Praha
Datum: 24.4.2015
Uchazeč: OKsystem a.s.
Jméno: Ing. Martin Procházka
Funkce: předseda představenstva
OKsystem
Na Pankráci 125, 140 2 -ka
ad
IČ: 27373665, DIČ: CZ27373665
OkKsystem
H m m m m m o m m m m
SMLOUVA O DÍLO - 52014-0043, číslo sml. DMS 183-2014-12122 '
č.sp. 59VD21314/2011-12120, č.j. 8299/2014-MZE-12122, č.sp. pr. 15A14906/2014-13310 .:.. —_.\1—
*
U
*
z l;.
Vybudování a provoz komunikační infrastruktury MZE — AgriBus PL STERATVO ZEMĚDĚLSTVÍ
Příloha č. 9
Zadávací dokumentace
Strana 1 / 1
ZE STERSTVO
FMĚDĚLSTVÍ
Těšnov 65/17
H 00 Pray k Nové Město
O
