Příloha č. 4 zadávací dokumentace „VYBUDOVÁNÍ A PROVOZ KOMUNIKAČNÍ INFRASTRUKTURY mzE – aGRIBUS“









Příloha č. 4 zadávací dokumentace

„VYBUDOVÁNÍ A PROVOZ KOMUNIKAČNÍ INFRASTRUKTURY mzE – aGRIBUS“

Technická specifikace předmětu plnění veřejné zakázky

Část: Technická specifikace řešení AgriBus



/



Příloha č. 7 Xxxxxxx

Technická specifikace předmětu plnění veřejné zakázky







Příloha 4: Technická specifikace řešení AgriBus



Obsah:



Seznam obrázků



Seznam tabulek



  1. Účel dokumentu

Tento dokument obsahuje specifikaci řešení a technických požadavků na systém centrální procesní a komunikační platformy AgriBus využité v rámci servisně orientované architektury služeb Ministerstva zemědělství. Dokument tvoří přílohu zadávací dokumentace veřejné zakázky „VYBUDOVÁNÍ A PROVOZ KOMUNIKAČNÍ INFRASTRUKTURY MZE – AGRIBUS“ a obsahuje představení požadovaného konceptu řešení, základní popis poptávaného řešení a požadavky závazné pro všechny potenciální uchazeče o zajištění realizace zakázky.



  1. Přehled základních pojmů



Objednatel, Ministerstvo Česká republika - Ministerstvo zemědělství osoba definovaná jako

zemědělství, MZe Objednatel v záhlaví Smlouvy

Zhotovitel Vítězný uchazeč, realizující projekt Agribus na základě smlouvy uzavřené s Objednatelem, osoba definovaná jako Zhotovitel v záhlaví Smlouvy

AgriBus Nově budovaná centrální procesní a komunikační platforma AgriBus

ESB Komunikační platforma enterprise service bus (obecná technologie pro integraci systémů)

ESB Oracle Původní nahrazovaná komunikační sběrnice Objednatele

ESB AgriBus Nová komunikační sběrnice AgriBus, komponenta řešení AgriBus

BPM AgriBus Funkcionalita řešení AgriBus zajišťující řízení složitých procesů, které mohou zahrnovat lidské vstupy a interakce

Služba V rámci příslušné agendy Ministerstva zemědělství představuje realizaci konkrétní komunikace „dotaz – odpověď“ nebo „podání – potvrzení přijetí“

Proces V rámci příslušné agendy Ministerstva zemědělství představuje systémové řízení sledu aktivit vykonávaných v rámci předem definovaného workflow. V rámci procesu jsou typicky volány Služby

Konzument služby, Partner, který iniciuje komunikaci s cílem získat nebo předat data

Konzument

Poskytovatel služby, Zpravidla serverová aplikace zpracovávající dotazy a podání a poskytující

Poskytovatel příslušné odpovědi

Registr Centrální systém obsahující data obsluhovaná v rámci výkonu agend MZe

Editorský systém Editační systém pro práci s daty v registru

Agendový systém Procesní aplikace MZe podporující výkon dílčí agendy

Zpráva Datový tok mezi Konzumentem a Poskytovatelem služby realizovaný v rámci volání služby

Koncový bod Konzument nebo Poskytovatel služeb v definované verzi rozhraní využívající komunikační platformu AgriBus

ITSM IT service management – řízení úrovně poskytovaných služeb především, nikoliv však výhradně, v rozsahu doporučeném ITIL

Workflow Konfigurovaný postup volání jednotlivých dílčích Poskytovatelů jednoduchých služeb v rámci orchestrovaných Služeb

Případ Instance jednoho běhu Procesu

Transakce Jedna či více operací volaných v rámci Procesu nebo Služby, které mají být v cílovém koncovém bodu potvrzeny a nebo odvolány společně

Kompenzační akce Akce, kterou je třeba automaticky nebo manuálně realizovat pro zajištění konzistence dat v případě odvolání Transakce

SOA Servisně orientovaná architektura

Management síť Dedikovaná síť Objednatele určená pro komunikaci monitoring a management nástrojů Objednatele

Ověřovací provoz Režim řešení AgriBus v délce šesti (6) měsíců, v rámci něhož lze řešit technické problémy vrácením (přepnutím) provozu služby do původního řešení ESB Oracle

Migrační plán Plán migrace služeb z ESB Oracle do AgriBus navržený v rámci odpovědi na technickou specifikaci zadání této veřejné zakázky a rozpracovaný v průběhu analýzy

ETL nástroj Nástroje pro přenosy a transformace velkých objemů dat mezi systémy

ETL úloha Úloha konfigurovaná v ETL nástroji pro zajištění konkrétního přenosu dat

EAR Centrální systém pro řízení architektury MZe

EAM Nástroj pro modelování ICT architektury MZe dle požadavků a standardů definovaných ve směrnici závazné architektury Objednatele





  1. Aktuální stav

MZe spravuje velké množství agend vyžadujících systémovou podporu informačních technologií. V rámci jednotlivých agend jsou MZe provozovány služby realizované jednou či více aplikacemi a systémy. Jedná se zejména o všechny klíčové registry MZe (Evidence využití zemědělské půdy, Integrovaný registr zvířat, Společný zemědělský registr, Evidence zemědělského podnikatele, SR – Speciální registry,…), ale i IS SZIF a i systémy resortních organizačních složek státu (Státní rostlinolékařská zpráva, Ústřední kontrolní a zkušební ústav zemědělský, Státní veterinární správa, Státní zemědělská a potravinářská inspekce, Česká potravinářská inspekce, a další). Mezi hlavní Poskytovatele či Konzumenty služeb patří mimo jiné:

  • LPIS – Land Parcel Identification System (registr/evidence využití zemědělské půdy podle uživatelských vztahů);

  • IS SZIF – Informační systém Státního zemědělského intervenčního fondu;

  • IZR - Integrovaný zemědělský registr;

  • SZR - Společný zemědělský registr;

  • MZK - Mezisklad zpráv o kontrole;

  • SR - Státní rostlinolékařská správa;

  • EPH - Aplikace Evidence přípravků a hnojiv;

  • DMS – Systém pro správu dokumentů;

  • eAGRI – Portál, hlavní přístupový bod k informačním zdrojům Ministerstva zemědělství (MZe) a jeho podřízených organizací;

  • eAGRI APP – Aplikace eAGRI APP jsou miniaplikace vytvořené ve stejných stylech jako portál eAGRI, aby pro uživatele vypadaly jako součást samotného portálu;

  • EPO - Elektronická podatelna.

Rozsah a množství agend zajišťovaných MZe spolu s požadavky na vzájemnou výměnu informací mezi jednotlivými agendami neustále narůstá. Zároveň roste počet externích subjektů využívajících informace poskytované jednotlivými agendami. MZe v reakci na tyto změny buduje či chystá výstavbu nových služeb obsluhujících požadavky jednotlivých agendových systémů či koncových uživatelů. S ohledem na stále se zvyšující objem komunikace a rostoucí nároky na rychlost, kvalitu a bezpečnost komunikace rozhodlo MZe o využití servisně orientovaného přístupu (SOA) při návrhu a výstavbě služeb a vybudování infrastruktury umožňující rychle a efektivně reagovat na nové požadavky.

V rámci rozvoje informatiky Ministerstva zemědělství, projektu Cross - Compliance, vznikl v roce 2008 systém implementující zásady SOA architektury – ESB Server (Dále jen ESB Oracle). Hlavním důvodem pro vznik takto robustního řešení byla existence a současně klíčový požadavek na zachování různorodých datových výměn na bázi XML mezi výše uvedeným množstvím agend. Tato různorodost způsobovala v průběhu času narůstající komplikace v administraci sítě vazeb, spolu s množinou různě se překrývajících anebo duplicitních XML zpráv. Zásadní faktory, které ovlivnily volbu architektury SOA a využití ESB byly definovány v cílech, jichž bylo požadováno dosáhnout:

  • Zastřešení veškerých XML komunikací pomocí robustní a spolehlivé technologie a definovaného formátu pro výměnu dat.

  • Sjednocení způsobu zabezpečení.

  • Zavedení důsledné dokumentace používaných služeb a stanovení přesných procesů pro jejich implementaci.

  • Zabezpečení dlouhodobé archivace datových výměn.

  • Poskytnutí nástroje pro audit komunikace mezi jednotlivými partnery s cílem efektivně řešit vznikající problémy s možností včasné výstrahy.

  • Zamezení ohrožení nebo negativnímu ovlivnění provozu jednotlivých registrů.

  • Stavu, kdy by byly zachovány všechny služby, které MZe smluvně garantuje organizacím prostřednictvím ESB Oracle komunikujícím zejména SZIF (prostřednictvím, kterého dochází k výplatám dotací z národních a evropských fondů v řádech desítek miliard Kč ročně) a všech podřízených organizací rezortu MZe, včetně dalších rezortů Veřejné správy (MV – základní registry, MF – státní pokladna) -v oblasti dotační politiky. V neposlední řadě i odborné zemědělské veřejnosti.

  • Nebyly kladeny jiné nároky na vlastní registry připojené k integrační sběrnici než k otestování provozovaných služeb po provedení jejich migrace.

Postupem času bylo toto řešení rozšiřováno o další funkcionality a podporovaná komunikační schémata. Lze konstatovat, že všechny uvedené cíle, které ovlivnily výběr dané architektury a technologie řešení, byly naplněny a ESB Oracle tvoří spolehlivou a stabilní SOA komponentu IT MZe, kdy za dobu provozu nedošlo k výpadku, nebo omezení dostupnosti, které by ohrozily výměnu informací mezi integrovanými systémy a registry.

V současné době je však nutno konstatovat, že zejména vlivem nepřetržitého nárůstu:

  • počtu implementovaných služeb,

  • četnosti dílčích volání

se stávající řešení dostává na horní hranici své vytíženosti, a to jak z hlediska parametrů výkonnosti, tak z hlediska dostupné diskové kapacity a udržování plynulosti provozu. Toto je kompenzováno cenou omezování počtu verzí implementovaných služeb a zkracováním doby archivace.

Při zavádění ESB Oracle jakožto nástupce XML Serveru se v rámci zpracované analýzy předpokládal denní objem zpráv kolem 20.000 s hraničním potenciálním nárůstem k 50.000. Tyto prognózy vycházely z reality výměny zpráv na XML Serveru, kdy hlavním Konzumentem (volajícím) byl SZIF pro účely kontroly dotací (objem přes 80% všech volání realizoval SZIF).

Od spuštění ESB Oracle v roce 2008, došlo k několika zásadním změnám. Především byla dokončena integrace všech klíčových systémů na SZR v oblasti subjektů, došlo k integraci provozoven do SZR a bylo spuštěno DMS pracující se souborovým typem služeb. Tyto tři skutečnosti, přispěly zásadní měrou ke zvýšení datové výměny přes ESB Server na dnešních 70 – 120.000 zpráv v denní špičce (tedy cca 5x více oproti stavu z roku 2008) a jeho enormnímu zatížení a jsou jedním z důvodů ospravedlňující nutnost nového dimenzování řešení.

Dalším důležitým faktorem je již zmíněná nutnost zajištění kontinuálního rozvoje jednotlivých registrů MZe, splnění požadavků kladených na jejich komunikaci s externími systémy (Informační systém základních registrů, SZIF v oblasti předtisků i vlastních vyhodnocování dotací), kdy provoz výše uvedených systémů (tj. registrů MZe) klade neustále větší komunikační nároky zajišťované prostřednictvím integrační sběrnice.

Lze tedy shrnout, že provozní výkonnost ESB se v současné době blíží svému maximu, který je na vybudované technologii možné dosáhnout a bez řešení této situace mohou nastávat výpadky jednotlivých registrů nebo minimálně jejich příslušných komunikačních rozhraní. Dále je již uvedené řešení technologicky zastaralé a je nutné provést jeho náhradu za zcela nové řešení.

Obrázek 1 - Aktuální stav ESB



    1. Základní architektura řešení

V rámci komunikačního schéma jsou provozovány služby:

  • Proxy - celá datová výměna probíhá v jedné transakci v rámci synchronního volání

  • Kompozitní - komplexní datová výměna, kdy k získání výsledku je nutná informace od více zdrojových systémů.

  • Asynchronní - na zpracování odpovědi je nutný delší časový úsek a není tedy účelné blokovat volajícího Konzumenta služby čekáním na její výsledek v rámci synchronní komunikace.

  • Souborové - umožňují v několika scénářích přenášet velké soubory.

Na začátku roku 2014 byl na ESB Oracle provozován následující počet služeb:

  • Proxy služby: 344

  • Kompozitní služby: 16

  • Asynchronní služby: 9

  • Souborové služby: 14

Přehled aktuálně implementovaných služeb je uveden v Příloze 1 – Dokumentace ESB Oracle.

    1. Aktuálně používané HW a SW technologie

Hardware infrastruktura ESB Oracle je tvořena:

  • 6 produkčními a 2 testovacími aplikačními servery v konfiguraci:

  • 2 x Dual-Core Intel Xeon procesor 5160 (3.0 GHz, 1333FSB).

  • 8 GB RAM.

  • 2 x 72 GB SAS HDD – HW RAID 1.

  • 128 MB Battery-Backed Cache Enabler.

  • předřazeným SSL akcelerátorem a HW balancerem, které zajišťují pro cluster produkčních aplikačních serverů vnější komunikaci vůči ostatním informačním systémům.

Software infrastruktura ESB Oracle je tvořena:

  • operačním systémem RedHat Linux rel. 4 Enterprise (64 bit)

  • databázovým prostředím Oracle RAC Registry – verze 10g

  • Oracle BPEL Process Managerem 10g Release 3

  • Oracle ESB 10g Release 3

  • Oracle Application Serverem 10g Release 3

  • Java ve 32 bitové verzi

Detailní dokumentace stávajícího řešení ESB Oracle je uvedena v „Příloha č. 1 – Dokumentace ESB Oracle“ Technické specifikace .



  1. Požadovaný stav a motivace

S rostoucími nároky na zjištění legislativy vyplývající z rozhodnutí orgánů České republiky anebo orgánů Evropské unie lze v blízké budoucnosti očekávat další nárůst počtu požadavků na implementaci podpůrných agend a služeb MZe. Aby IT infrastruktura MZe byla schopna těmto požadavkům vyhovět, je třeba vybudovat takové IT prostředí, které bude umožňovat rychlou, efektivní a bezpečnou implementaci všech nově požadovaných agend a služeb.

Prostředí a jednotlivé služby zahrnující mimo jiné služby agendových systémů MZe a registrů MZe budou proto i nadále implementovány využitím servisně orientovaného přístupu SOA. Vývojáři a IT oddělení budou podle principů SOA navrhovat, implementovat a provozovat informační systémy složené z opakovaně využitelných atomických komponent, které vykonávají diskrétní servisní funkce. Komponenty služeb bude možné podle potřeby distribuovat přes geografické a organizační hranice, nezávisle škálovat a rekonfigurovat do nových služeb MZe.

Obrázek 2 - Komunikační platforma ESB

Základ IT infrastruktury založené na SOA bude i nadále tvořit informační sběrnice služeb ESB AgriBus (Enterprise Service Bus), která spojuje a zprostředkovává všechny komunikace a interakce mezi Poskytovateli a Konzumenty služeb viz. Obrázek 2 - Komunikační platforma ESB. ESB AgriBus platforma bude umožňovat rychle měnit služby, snadno je připojovat, publikovat a řídit. Řešení AgriBus bude dále poskytovat funkcionality obecné procesní platformy (BPM, dále jen AgriBus BPM) umožňující navrhovat a řídit procesy zahrnující lidské vstupy a interakce. BPM AgriBus se stane jednotnou standardizovanou platformou pro návrh a provoz agendových informačních systémů a editorských systémů registrů MZe. BPM AgriBus bude pro komunikaci s ostatními systému využívat ESB AgriBus. Dodávku jednotlivých procesů či agendových systémů implementovaných v BPM AgriBus mohou zajišťovat různí dodavatelé. Zapojení individuálních dodavatelů neohrozí stabilitu a výkonnost BPM AgriBus ani ESB AgriBus.

Obrázek 3 - BPM AgriBus

Jednotná procesní a komunikační platforma AgriBus spolu s obsaženou komunikační sběrnicí ESB AgriBus:

  • Sjednotí návrh a provoz agendových a editorských systémů

Agendové a editorské systémy jsou aktuálně v prostředí MZe navrhovány a vyvíjeny nezávisle. Koncentrace návrhu a provozu těchto systémů do jedné centrální procesní platformy, BPM AgriBus, zjednoduší a standardizuje návrh, vývoj a provoz systémů, sjednotí základní logiku a uživatelské rozhraní systémů.

  • Umožní jednoduchou integraci systémů, aplikací a služeb

Vývojáři systémů, aplikací a služeb nebudou nuceni individuálně řešit komunikaci mezi komponentami služeb. Jednotná a standardizovaná komunikační platforma jim umožní soustředit se čistě na vývoj kritické business logiky v jim známém prostředí a pro řízení a zabezpečení komunikace využívat standardizovaných služeb AgriBus. V případě požadavku na integraci s jiným systémem bude možné jednoduše využít standardizovaná rozhraní a adaptéry AgriBus. Následování SOA přístupu a využití centrální procesní a komunikační platformy AgriBus bude zárukou, že všechny jednotlivé komponenty služeb tvořící složitější kompozitní služby, bez ohledu na architekturu a vývojové prostředí služeb, spolu budou bezchybně spolupracovat a budou odladěné k optimálnímu výkonu, neboť jejich vzájemná komunikace bude řízena jediným centrálním komunikačním řešením - AgriBus.

  • Sníží nároky na provoz, zabezpečení a monitoring služeb

Konsolidací všech integračních řešení do jediné platformy s jasně definovanou architekturou a se sadou opakovaně použitelných prvků bude provoz mnohem efektivnější než při provozování velmi různorodých integračních prvků a aplikací. Nebude třeba individuálně zabezpečovat komunikační toky mezi jednotlivými komunikujícími stranami. Zabezpečení bude probíhat centrálně na úrovni AgriBus, kde bude řízeno centrálním systémem správy přístupových práv MZe. Koncovými body komunikujícími v rámci AgriBus budou především systémy. Základním autentizačním prvkem pro zabezpečení komunikace bude z těchto důvodů certifikát. Jediný centrální systém, přes který bude probíhat veškerá komunikace, umožní detailně monitorovat probíhající transakce, optimalizovat výkonnost jednotlivých servisních komponent a rychle reagovat na existující či potenciální technické problémy.

  • Přispěje k zjednodušení procesů a organizační struktury

Budou zavedeny jasně definované procesy potřebné pro vývoj a provoz řešení a definována odpovídající organizační struktura. Návrh architektury nových služeb bude probíhat dle definovaných závazných standardů, přičemž všechny změny stávajících služeb budou připraveny ve vývojovém prostředí a následně před nasazením v produkčním prostředí budou otestovány v testovacím prostředí. Realizace všech změn bude probíhat řízeným change management a release management procesem. Současně s řešením AgriBus bude připravena metodika pro využití integračních funkcionalit spolu s metodikou pro vývoj služeb na všech integračních úrovních uvedených dále v dokumentu. Standardizace komunikace a procesní přístup k realizaci změn ve svém důsledku přispějí ke snížení rizika vzniku neplánovaných výpadků a nedostupností služeb způsobených rozvojem řešení.

  • Umožní rychlý vývoj a nasazení nových služeb

AgriBus umožní mnohem rychlejší realizaci implementačních projektů nových služeb a agend díky možnosti naprosto libovolně kombinovat funkcionality již existujících opakovaně využitelných komponent. Dojde ke snížení pracnosti realizovaných projektů, které nebudou nadále zahrnovat aktivity a rezervy související se vzájemným propojením služeb a aplikací. Dále nebude třeba tvořit nové provozní postupy pro integrační adaptéry atd. Vyřešená integrace umožní více se soustředit na business logiku projektu, což bude mít pozitivní dopad na kvalitu výsledného řešení nových služeb.

  • Zabezpečí postupný kontinuální rozvoj

Opakované využití existujících komponent s jasně definovaným rozhraním a zapouzdřenou logikou přinese možnost postupně budovat nové agendy a služby. Vývoj nových služeb ve vývojovém prostředí, testování v testovacím prostředí a standardní postupy pro řízení změn a nasazení změn v produkčním prostředí umožní efektivně vyvíjet a přenášet nové funkcionality do produkčního prostředí při minimalizaci rizika ohrožení existujících služeb a agend.

Závěrem lze konstatovat, že poptávané řešení centrální procesní a komunikační sběrnice AgriBus se pro MZe na mnoho následujících let stane klíčovou komponentou podporující provoz agend a zprostředkovávající komunikaci mezi všemi hlavními systémy MZe. Proto jsou s její implementací, provozem a budoucím využitím spojená nemalá očekávání. Následující kapitoly se věnují základnímu popisu řešení a obsahují přehled požadavků na řešení včetně základních požadavků na výkonnost a dostupnost.

  1. Popis požadovaného řešení

Informace v této kapitole popisují požadované cílové řešení, které bude aplikováno pro nově implementované služby a nezahrnuje tedy architekturu nezbytnou pro migraci stávající implementace služeb do nového řešení AgriBus (pro paralelní souběh XxxxXxx s ESB Oracle, pokud je taková architektura trvale či dočasně vyžadována). Níže uvedená architektura bude doplněna Zhotovitelem tak, aby obsahovala veškeré prvky nezbytné pro migraci všech služeb provozovaných na stávající platformě ESB Oracle. Migrace existujících služeb je požadovanou součástí zadání. Detailní informace o požadované migraci jsou uvedeny v kapitolách 6.2 Detailní specifikace a 6.7 Implementace.

Řešení AgriBus představuje jednotnou komunikační platformu složenou z několika funkčních komponent. Logický model řešení obsahuje grafické znázornění funkčních komponent řešení a jejich vzájemné spolupráce. Jednotlivé funkční komponenty mohou být v rámci řešení předkládaného Zhotovitelem implementovány jedním či více nabízenými systémy. Níže uvedený souhrn řešení popisuje jednotlivé funkční komponenty tak, jak jsou uvedeny na obrázku Obrázek 4 - Logický model AgriBus.

Obrázek 4 - Logický model AgriBus

    1. Komunikační sběrnice ESB AgriBus

Komunikační vrstva ESB AgriBus je centrální komponentou zajišťující přenos zpráv mezi Poskytovateli a Konzumenty služeb. ESB AgriBus zprostředkovává komunikaci a provádí konverzi mezi formáty a protokoly vstupních požadavků vznesených příjemci služby a formáty a protokoly požadovanými Poskytovateli služby. Pro komunikaci mezi jednotlivými příjemci a Poskytovateli služby není třeba individuálně dojednávat komunikační rozhraní. ESB AgriBus zajišťuje transparentnost komunikace poskytnutím univerzálního komunikačního rozhraní. Příjemci služeb nemusí znát adresu komunikačního rozhraní Poskytovatelů služeb. Adresovatelnost požadované služby a směrování zpráv zajišťuje ESB AgriBus.

Komunikační sběrnice ESB AgriBus je připravena nejen na přenos datových zpráv, ale i objemných souborů v řádu stovek MB bez dopadu na probíhající on-line komunikaci. Soubory jsou v průběhu přenosu uloženy v dočasném úložišti ESB AgriBus a vlastní zprávou je přenášen pouze odkaz na umístění souboru. ESB AgriBus dále volitelně zajišťuje bezpečnost a integritu dokumentů. Všichni oprávnění Konzumenti služby, jež obdrželi odpověď s odkazem na soubor (případně jiný autorizační prvek, např. řetězec znaků), mají přístup k souboru v dočasném úložišti. Poskytovatel služby v odpovědi typicky určuje, po jak dlouhou dobu bude soubor v dočasném úložišti uložen. Po uplynutí nastavené doby ESB AgriBus zajistí odmazání souboru z dočasného úložiště. Řešení bude obsahovat funkcionalitu obsluhující případné kolize v podobě současného přístupu k souboru a mazání souboru. Pro obsluhu dočasných souborů je možné nastavit jiné politiky, např. může být soubor odmazán okamžitě po vyzvednutí prvním z příjemců. Funkcionalita přenosu souborů dále umožňuje volitelně zabezpečit přenos souboru SSL šifrováním a volitelně garantovat integritu souborů. Dle specifických požadavků Poskytovatelů a Konzumentů může být šifrování a podepisování dokumentů volitelně řešeno na straně Konzumentů a Poskytovatelů anebo přímo v AgriBus. Požadavky na přenos souborů jsou uvedeny v kapitole 5.1 Komunikační sběrnice ESB AgriBus.

V rámci IT infrastruktury Objednatele dále dochází k přenosům a synchronizacím velkého množství dat mezi jednotlivými systémy. Přenos dat bude realizován využitím ETL nástrojů. ESB AgriBus bude v rámci přenosu zajišťovat vzájemnou komunikaci a doručování řídících zpráv ETL úloh mezi jednotlivými systémy, jak je znázorněno na obrázku Obrázek 5 - Zajištění synchronizace dat. Konzument prostřednictvím volání rozhraní AgriBus požádá o zajištění přenosu dat ze systému Poskytovatele. V rámci řešení AgriBus jsou dostupné ETL nástroje a nakonfigurovány ETL úlohy pro přenos a transformace dat.

Obrázek 5 - Zajištění synchronizace dat

XxxxXxx spustí ETL úlohu, která zajistí přenos dat z Poskytovatelského systému do datové úschovny. Následně informuje Konzumenta služby o existenci připravených dat v datové úschovně. Konzument služby následně volá rozhraní AgriBus s požadavkem na spuštění ETL úlohy pro import dat do systému Konzumenta. Pro spouštění ETL úloh budou v řešení AgriBus připraveny dedikované služby. Systémy Konzumentů a Poskytovatelů nebudou mít přímý přístup k ETL komponentě a ETL úlohám. Jednotlivé ETL úlohy budou volat prostřednictvím služeb AgriBus. Systém AgriBus bude garantovat doručení dat od Poskytovatelů ke Konzumentům.

Obrázek 6 - Přenos objemných souborů - sekvence



ESB AgriBus bude dále poskytovat podporu pro automatizované kontroly integrity a kvality dat zejména v zemědělských registrech, pro jejíž zajištění je v rámci budoucí architektury uvažována samostatná komponenta spouštějící kontrolní úlohy v podobě služeb AgriBus, ETL úloh či funkcionalit dalších nástrojů. Všechny úlohy pro kontrolu integrity a kvality dat budou řízeny prostřednictvím ESB AgriBus podobně, jako tomu je v případě přenosu objemných souborů.

V rámci ESB jsou jednotlivé úlohy zajišťovány komponentami navrženými dle standardů SCA (Service Component Architecture). ESB zprostředkovává vzájemnou komunikaci komponent služeb na několika níže uvedených úrovních. SCA komponenta, evidovaná v registru služeb a opakovatelně využitelná v rámci návrhu služeb, může být dle potřeby volitelně implementována na všech níže uvedených komunikačních úrovních.

Obrázek 7 - Komunikační úrovně ESB AgriBus

      1. Mediace

Komunikace na úrovni mediace zpráv představuje nízko úrovňový přenos a transformaci zpráv mezi komponentami služeb využívajícími ESB AgriBus. Mediační tok zpráv mezi Poskytovatelem a příjemcem služby zahrnuje dynamické určení Poskytovatele služby využitím registru služeb a přenos zpráv mezi jedním Konzumentem a jedním Poskytovatelem. ESB AgriBus v rámci mediačních toků poskytuje všechny funkcionality včetně autentizace, autorizace komunikujících stran a zabezpečení komunikace uvedené v příslušných podkapitolách kapitoly 6 Přehled požadavků. Tento nejnižší stupeň integrace v podstatě představuje publikaci rozhraní (proxy služby) jedné služby v rámci SOA.

      1. Integrace

Komunikace na úrovni integrace představuje přenos zpráv na úrovni mediace, přičemž do komunikace je zapojeno více Poskytovatelů či odběratelů služeb. Poskytovatelé služeb jsou identifikováni jako v případě mediační úrovně využitím registru služeb. Logika přenosu a mapování zpráv mezi Konzumenty a Poskytovateli je z větší míry statická, obsahující pouze jednoduché podmínky (či politiky) a konfigurovaná jako mediační datové toky v ESB. Logika volání jednotlivých komponent neobsahuje transakční zpracování a pokročilou obsluhu chyb.

      1. Orchestrace

Komunikace na úrovni orchestrace služeb představuje nejvyšší stupeň komunikace ESB AgriBus zahrnující jednoho či více Konzumentů služeb a jednoho či více Poskytovatelů služeb přičemž výměna informací, volání jednotlivých rozhraní, transformace zpráv atd. jsou řízeny pokročilou logikou. Služby, nebo také BPEL komponenty, na této komunikační úrovni jsou vytvářeny organizací komponent z nižších vrstev do dynamicky řízených workflow využívajících složité podmínky a politiky pro řízení běhu a rozhodování. V rámci podmínek a politik mohou být využity statické informace o Konzumentech nebo Poskytovatelích zpráv či dynamické informace nesené uvnitř zpráv. Workflow je konfigurovatelné prostřednictvím jazyka BPEL. Podrobnější popis využití jazyka BPEL obsahuje kapitola 6.1.5 Designér služeb.

Přehled požadavků na komunikační vrstvu ESB je uveden v kapitole 6.1.1 ESB AgriBus.

    1. BPM AgriBus

AgriBus bude poskytovat funkcionality a nástroje pro řízení komplexních procesů a pro budování procesně orientovaných agendových nebo editorských aplikací. Součástí řešení bude prostředí zajišťující běh dlouho trvajících procesů zahrnujících uživatelské interakce. Za tímto účelem bude AgriBus obsahovat funkcionalitu pro návrh, vytváření a prezentaci webových formulářů a aplikací zprostředkujících uživatelské vstupy v procesu. Procesy a formuláře bude možné navrhovat v grafickém prostředí a zároveň přímou editací definičních souborů viz. kapitoly 5.2.1 Designér webových formulářů a 5.2.2 Vývoj aplikací. AgriBus bude připraven na postupné přidávání/budování výše zmíněných procesů a procesních aplikací (agendových systémů). Procesní aplikace resp. agendové systémy nejsou předmětem této veřejné zakázky. Běh procesů a aplikací nebude mít negativní dopady, resp. nesmí ovlivnit nebo ohrozit, provoz a výkonnost komunikační sběrnice AgriBus. Uživatelské webové rozhraní procesních aplikací bude integrováno do portálového řešení Objednatele. Řešení bude dále podporovat přístup prostřednictvím mobilních platforem (zejména Android, IOS). Požadavky na podporu procesů a aplikací jsou uvedeny v kapitole 6.1.2 Procesní platforma AgriBus BPM.

      1. Designér webových formulářů

Řešení AgriBus bude obsahovat funkcionalitu pro návrh webových formulářů a aplikací zprostředkujících uživatelské interakce v procesech. Webové formuláře bude možné vytvářet v grafickém editoru formulářů a zároveň přímou editací definičních souborů formulářů. Grafický editor bude umožňovat rychle a efektivně přidávat nové formuláře, editovat stávající formuláře a v důsledku tak umožňovat rychlou reakci na potřeby provozovaných procesů. V grafickém editoru bude možné do formulářů přidávat nové kontrolní (vstupní) prvky zejména níže uvedených typů a pro tyto prvky definovat vhled, rozmístění, zarovnání a chování. Kontrolní prvky bude možné přímo v grafickém editoru napojit na podkladové zdroje dat (data ze zpráv obsluhovaných v rámci procesů). AgriBus bude poskytovat podporu pro minimálně následující datové typy: Text, Date, Number, Boolean. Pro datové typy budou k dispozici minimálně následující kontrolní prvky:

  • Vstupní prvky:

    • Text,

    • TextArea,

    • Date, Time, Date/Time,

    • Number;

  • Prvky výběru:

    • Dropdown,

    • Radio,

    • Checkbox,

    • BooleanCheckbox;

  • Organizace prvků

    • Sekce,

    • Taby,

    • Panely,

    • Tabulky;

  • Ostatní prvky

    • Zprávy,

    • Xxxxxxx,

    • Hypertextové odkazy,

    • Tlačítka.

Chování kontrolních prvků a celých formulářů bude možné ovlivňovat skripty definovanými a provozovanými na pozadí formulářů. Skripty dodají formulářům interaktivitu, která umožní reagovat na dílčí vstupy v kontrolních prvcích a dynamicky měnit podobu formulářů, sekcí či ostatních kontrolních prvků za běhu.

Pro formuláře bude možné nastavit barevné provedení, použité obrázky, loga a zajistit tak soulad vzhledu procesních aplikací AgriBus se standardním vzhledem aplikací Objednatele.

      1. Vývoj aplikací

Aplikace a aplikační komponenty vyvinuté pro potřeby jednotlivých agendových systémů budou mít přístup ke službám poskytovaným webovou prezentační vrstvou BPM AgriBus. Aplikace budou moci využívat okna, vstupní a ovládací prvky a další komponenty poskytované prezentační vrstvou. Prezentační vrstva AgriBus, resp. standardní komponenty prezentační vrstvy, by měla zajistit většinu interakcí s koncovým uživatelem. Prezentační vrstvu BPM AgriBus bude možné doplnit o další kontrolní prvky vyvinuté v rámci vývoje aplikace.

Procesy a formuláře zmíněné v kapitole bude možné doplnit o aplikační komponenty poskytující další požadované funkcionality, které není možné anebo efektivní realizovat čistě využitím formulářů. Konkrétně se může například jednat o složitější aplikace zahrnující složité výpočty, vizuální prezentace dat, složité vstupní prvky atd. Tyto aplikační komponenty bude možné integrovat s procesy a formuláři XxxxXxx tak, že budou tvořit jeden funkční a vizuální celek. Další požadavky na vývoj aplikací jsou uvedeny v kapitole 6.1.2 Procesní platforma AgriBus BPM.

    1. Registr služeb

Registr služeb je komponentou řešení AgriBus poskytující informace o dostupných komponentách SOA architektury. Registr obsahuje katalog služeb a komponent, jejich specifikaci a metadata. Konzument využívá registr služeb k vyhledání jemu dostupných služeb a komponent a k získání specifikace nezbytné pro pochopení jakým způsobem a s jakými parametry je třeba službu volat. Registr obsahuje informace o funkcionalitách poskytovaných jednotlivými službami. Vývojáři nových služeb před návrhem nových služeb mohou jednoduše prohledat registr, zda již neexistuje služba vyhovující jejich požadavkům, čímž je zabráněno nechtěné duplicitě služeb.

Obrázek 8 - Registr služeb

Registr služeb dále podporuje řízení životního cyklu všech evidovaných komponent. O každé evidované komponentě je v rámci metadat možné uchovávat informace v jakém stavu z pohledu nasazení se komponenta nachází (ve vývoji, v testu, v produkci atd.), verze jednotlivých komponent a dynamický odkaz na poslední zveřejněnou verzi komponenty určenou pro využití v rámci implementace služeb. Registr služeb je přístupný nejen samotným servisním komponentám prostřednictvím aplikačního rozhraní, ale i vybraným uživatelům využitím obsaženého webového rozhraní. Oprávnění uživatelé tak mají možnost získat další informace o komponentách, jako jsou přehledy změn komponent, doporučení pro využití komponent, závislosti komponent, informace o využití komponent atd. Katalog služeb je obsahově provázán s EAR (EAR, není předmětem projektu AgriBus) , tzn. ke každé službě v registru služeb bude existovat dokumentace architektury a modely v EAR viz. 6.9 Dokumentace. Katalog služeb společně s informacemi z EAR a CMDB bude možné využít například při plánování změn či odstávek vybraných komponent a určení potenciálního dopadu na nadřazené komponenty či služby, které měněné či odstavované komponenty využívají. Přehled funkčních požadavků na registr služeb je uveden v kapitole 6.1.4 Registr služeb.

Služby budou v rámci přípravy Migračního plánu rozděleny do kategorií dle složitosti a komplexnosti viz. Tabulka 1 - Kategorizace služeb. Informace o kategorii služby bude evidovaná v registru služeb ve formě metadat a přístupná v rámci reportingu za účelem výpočtu a vyhodnocení plnění SLA dle katalogového listu služby (pro monitoring dostupnosti a výpočet SLA budou použity služby S1). Rozdělení služeb provede Zhotovitel, přičemž rozdělení podléhá revizi a schválení Objednatelem.

Tabulka 1 - Kategorizace služeb

Kategorie služby

Popis

Služby S1

Vybrané synchronní služby na mediační nebo integrační vrstvě, jež nezahrnují složité integrace, přenosy souborů či synchronizaci dat a mohou tak být využity jako reprezentativní služby pro monitoring a vyhodnocování plnění SLA dle katalogového listu služby.

Služba S2

Ostatní synchronní a asynchronní služby na mediační, integrační a orchestrační vrstvě nezahrnující přenosy souborů či synchronizaci dat.

Služba S3

Ostatní služby zahrnující přenosy souborů a synchronizaci dat.



    1. Designér služeb

Návrh a definici nových služeb bude možné vytvářet přímou editací zdrojových souborů či využitím specializovaného grafického nástroje. Tímto nástrojem lze vytvářet definice nových služeb či modifikovat definice služeb existujících na všech komunikačních úrovních uvedených v kapitole 5.1 Komunikační sběrnice ESB. V rámci návrhu lze využít existující komponenty služeb evidované v centrálním registru služeb či navrhnout nové komponenty služby dle specifických požadavků implementované služby.

Designér služeb pro nejvyšší komunikační vrstvu podporuje návrh workflow služeb a komponent tzv. BPEL komponenty v jazyce BPEL včetně exportu a importu BPEL modelů viz. Obrázek 9 - Návrh služeb a komponent v designéru služeb.

Obrázek 9 - Návrh služeb a komponent v designéru služeb

Definice služeb či komponent je možné ukládat a zálohovat v různých verzích a moduly či komponenty přenášet mezi vývojovým, produkčním a testovacím prostředím.

Obrázek 10 - Vývoj a synchronizace běhových prostředí

Řešení podporuje snadný přenos nových funkcionalit z vývojového prostředí do testovacího prostředí a z testovacího prostředí do produkčního prostředí. Řešení zároveň podporuje jednoduchou uživatelsky řízenou synchronizaci / replikaci produkčního prostředí do testovacího či vývojového prostředí a testovací prostředí do vývojového prostředí. Způsob výměny funkcionalit mezi běhovými prostředími je uveden na obrázku Obrázek 10 - Vývoj a synchronizace běhových prostředí. Vítanou vlastností řešení je možnost provést snapshot vývojového a testovacího prostředí a možnost kdykoliv tento snapshot vyvolat a použít.

Vývojové a testovací prostředí bude zahrnovat komponenty pro rozdělení zátěže s minimálně dvěma uzly, aby v rámci vývoje a testování bylo možné testovat obsluhu session a funkcionalitu persistence.

Každá služba nebo komponenta bude před vlastním uvedením do produkčního provozu otestována a následně doladěny výkonností parametry. Designér umožňuje provést otestování komponent a simulaci běhu služby za podmínek definovaných návrhářem procesu či podmínek odvozených z historické zkušenosti s produkčním během služby. Permanentní monitoring resp. výstupy tohoto monitoringu umožňují využít zachycených informací pro kvalifikovaný odhad budoucího chování služby a předpovídat dopad plánovaných změn na produkční běh služby. Podrobné informace o monitoringu řešení jsou uvedeny v kapitole 5.5 Monitoring.

Základní požadavky a Informace o provozu vývojového, produkčního a testovacího prostředí, podpoře a odpovědnosti za jednotlivá prostředí spolu se základními informacemi o procesu přenosu funkcionalit mezi prostředími jsou uvedeny v kapitolách 6.8 Testování, 6.10 Metodika a 6.11 Služby provozu a podpory.

    1. Monitoring

Monitoring komponenta zajišťuje dohled běhových prostředí AgriBus, provozní dohled služeb a statistický dohled realizovaných volání služeb resp. přenášených zpráv a souborů. Provozní a statistický dohled je realizován na všech komunikačních úrovních, jak je ilustrováno na obrázku Obrázek 11 - Logický model monitoringu AgriBus.

Obrázek 11 - Logický model monitoringu AgriBus

Neagregované monitoring informace o realizovaných voláních, zprávách, transakcích, procesech na všech komunikačních úrovních jsou přenášeny do komponenty Historický archiv, kde jsou skladovány a zpřístupněny pro následný reporting a analýzy. Přenos neagregovaných informací je realizován minimálně jednou za 12 hodin.

Popis komponenty Historický archiv je uveden v kapitole 5.6 Historický archiv. O každém volání, zprávě, transakci či procesu jsou do historického archivu přenášeny zejména informace:

  • datum a čas (v mls) zahájení volání / zaslání zprávy,

  • datum a čas ukončení volání /obdržení odpovědi,

  • identifikace komunikujících stran,

  • výsledek volání,

  • počet opakovaných volání, výše uvedené parametry pro každé z nich,

  • další volitelné detaily volání včetně informací z hlavičky či těla zpráv.

Nastavení archivace zpráv bude umožňovat omezit i některých elementů velikost tak, aby nebyly přenášeny celé zprávy a nedošlo k zahlcení Historického archivu. Řešení dále bude umožňovat definovat elementy (zejména bezpečnostní povahy), které nebudou do Historického archivu předávány.

Do monitoringu jsou ze všech komunikačních vrstev předávány informace o provozních alarmech, bezpečnostních alarmech a aktuálních dostupnostech a stavech komponent a služeb. Monitoring dále aktivně monitoruje výkonnostní a kapacitní metriky jednotlivých toků nebo služeb a generuje alarmy v případě překročení prahových hodnot. Parametry monitoringu lze pro služby nastavit v grafickém návrháři služby, kde je možné určit měřící body a detailní parametry měření.

Agregovaná data výkonnostních a kapacitních metrik jsou sbírána s následujícími parametry:

Tabulka 2 - ESB parametry provozního monitoringu

Frekvence sběru

5 minut

Agregace

5 min, 1 hod, 1 den, 1 měsíc, 1 rok

Životnost dat

14 dní dní (5 min), 30 dní (1 hod), 6 měsíců (1 den), 4 roky (1 měsíc, 1 rok)

Monitoring předává provozní a archivní alarmy do historického archivu minimálně jednou za 12 hodin.

      1. Dohled běhových prostředí

Dohled běhových prostředí monitoruje funkcionalitu všech infrastrukturních a softwarových komponent tvořících řešení AgriBus, jež jsou pod správou Zhotovitele viz. (Obrázek 11 - Logický model monitoringu AgriBus). Dohled běhových prostředí zajišťuje:

  • detekci chybových stavů všech hardware a software komponent produkčního, testovacího a vývojového běhového prostředí,

  • monitoring a reporting výkonnosti a kapacit komponent běhových prostředí a

  • bezpečnostní monitoring řešení zejména výskyt neoprávněných volání či přihlášení k jednotlivým systémům.

Dohled běhových prostředí je primárně určen pro Zhotovitele, který dohledový systém používá pro zajištění požadované kvality a dostupnosti řešení AgriBus v souladu s katalogovými listy služby. Výstupy monitoringu jsou na vyžádání přístupné zástupcům Objednatele. Zhotovitel dále v případě požadavku Objednatele umožní instalaci monitoring agentů Objednatele na jakýkoliv hostitelský systém AgriBus.

      1. Provozní dohled služeb

Provozní dohled služeb poskytuje informace o provozním stavu celého řešení AgriBus a jednotlivých implementovaných služeb a jejich komponent (Online data dle katalogového listu služby). Provozní dohled služeb zajišťuje mimo jiné:

  • monitoring dostupnosti a funkcionality celého řešení AgriBus;

V řešení AgriBus bude implementována jedna testovací služba ověřující všechny hlavní funkcionality a komponenty řešení AgriBus. Pro zajištění maximální reprezentativnosti monitoringu bude Zhotovitelem vytvořen i testovací Poskytovatel tak, aby v rámci volání monitorovací služby byla ověřena funkcionalita včetně volání Poskytovatelského systému. Služba bude na výstupu poskytovat informaci o aktuálním souhrnném stavu řešení AgriBus. Volání služby bude zajištěno Objednatelem v rámci monitoringu dostupnosti AgriBus pro účely reportingu KPI v rámci katalogového listu služby. Monitorovací službu může volitelně volat i Zhotovitel ze svých monitoring systémů. Volání služby Objednatelem bude probíhat z lokality za posledním hraničním prvkem infrastruktury Zhotovitele (vně VLAN AgriBus viz. Obrázek 12 – Bezpečnostní infrastruktura AgriBus) tak, aby byla ověřena funkcionalita všech požadovaných komponent včetně perimetru z pohledu koncového systémů či uživatele. Událost informující o nedostupnosti služby detekovaná dohledovým systémem Objednatele může být volitelně předávána do dohledového systému Zhotovitele.

  • monitoring dostupnosti a funkcionality jednotlivých služeb;

Každá služba implementovaná v řešení AgriBus bude poskytovat testovací operaci umožňující ověřit dostupnost a funkcionalitu služby. Testovací operace bude volána z monitoringu Zhotovitele a aktuální stav jednotlivých služeb prezentován prostřednictvím grafického dashboard. Události informující o nedostupnosti služeb budou předávány do dohledových systémů Objednatele.

  • monitoring výkonu a zátěže řešení AgriBus;

Monitoring bude poskytovat aktuální informace o souhrnných počtech volání všech služeb za jednotku času a o průměrné, maximální a minimální době obsluhy jednotlivých volání rozdělených na čas AgriBus a čas Poskytovatele nebo Konzumenta služby. Monitoring bude dále prezentovat aktuální procento volání obsloužených řešením AgriBus do požadovaného limitu 2 sekund za jednotku času.

Data bude možné využít online či exportovat za účelem následných reportů a analýz Objednatelem.

  • monitoring výkonu a zátěže jednotlivých služeb;

Monitoring bude poskytovat aktuální informace o počtu realizovaných volání služby za jednotku času (např. za poslední hodinu, den, týden atd.) a o průměrné, maximální a minimální době obsluhy jednotlivých volání rozdělených na čas AgriBus a čas Poskytovatele služby. Data bude možné přímo využít či exportovat za účelem následných reportů a analýz Objednatelem.

  • monitoring délky komunikačních front;

Monitoring bude poskytovat aktuální informace o počtu zpráv v komunikačních frontách ve směru k Poskytovatelům i Konzumentům služeb. Monitoring bude mimo jiné schopen vyhodnotit chybový stav v případě neměnného počtu zpráv ve frontě anebo v případě nepoměrného zvyšování počtu zpráv ve vstupních a výstupních frontách a informace o tomto stavu ve formě události předat do dohledového systému Objednatele.

  • detekce chybových stavů celého řešení AgriBus;

Monitoring bude detekovat, signalizovat a archivovat chybové stavy celého řešení AgriBus a jednotlivých jeho komponent. Monitoring bude poskytovat rozhraní pro předávání informací o těchto chybových stavech (událostí) do dohledů Objednatele viz. kapitola 5.5.5 Integrace monitoringu. Chybové zprávy budou dále přenášeny do historického archivu za účelem následných analýz a reportingu.

  • detekci chybových stavů v rámci volání služeb a přenosu zpráv;

Monitoring bude detekovat, signalizovat a archivovat informace o selhání nebo chybách při volání jednotlivých služeb. Detekované události budou předávány do dohledu Objednatele a zároveň archivovány v historickém archivu za účelem následných analýz a reportingu.

  • monitoring bezpečnostních událostí zejména výskyt neoprávněných volání služeb;

Monitoring bude sledovat využití jednotlivých komponent a volání služeb a detekovat, signalizovat a archivovat události v historickém archivu. Události budou dále předávány do bezpečnostních dohledů Objednatele.



      1. Statistický dohled služeb

Statistický dohled služeb sbírá neagregované informace o každé datové výměně na všech komunikačních úrovních AgriBus viz. 5.1 Komunikační sběrnice ESB a informace (Historická data dle katalogového listu služby) ukládá do Historického archivu, kde jsou přístupné pro následné analýzy a zejména reporting a vyhodnocení plnění KPI definovaných v katalogovém listu služby. Přehled požadavků na statistický dohled je uveden v kapitole 6.1.6 Monitoring.

Statistický monitoring dále umožňuje sledovat počet požadavků vyřízených AgriBus za jednotku času rozdělených dle jednotlivých služeb a informace o počtu požadavků, které skončily chybou.

Informace předávané do historického archivu mimo jiné zahrnují:

  • dotaz/podání od Konzumenta služby,

  • volání Poskytovatele služby (volá-li se v rámci jedné služby více Poskytovatelů, jsou archivována všechna volání),

  • odpověď Poskytovatele služby (odpovídá-li v rámci jedné služby více Poskytovatelů, jsou archivovány všechny odpovědi),

  • odpověď/potvrzení přijetí odcházející Konzumentovi služby.

O každém výše uvedeném volání jsou sledovány a do historického archivu přenášeny mimo jiné následující informace:

  • datum a čas uložení do archivu,

  • datum a čas (s rozlišením ms) zahájení volání,

  • datum a čas (s rozlišením ms) ukončení volání,

  • délka volání (s rozlišením ms),

  • kategorie transakce (S1, S2, S3 viz. 5.3 Registr služeb) v případě, že kategorii transakcí nelze z přehledu transakcí v historickém archivu odvodit jiným způsob (kategorie transakce je využita při reportingu ),

  • směr komunikace (0 – dotaz/podání Konzumenta služby; 1 – volání Poskytovatele služby; 2 – odpověď Poskytovatele služby; 3 – odpověď Konzumentovi služby),

  • identifikace/jméno volané služby,

  • identifikace Poskytovatele nebo Konzumenta služby (lze-li údaj zjistit),

  • identifikace fyzického místa (URL adresy apod.) odkud zpráva přišla nebo kam byla směrována (lze-li údaj zjistit),

  • korelační identifikátor, který provazuje všechny záznamy v archivu, které se vztahují k jedné datové výměně,

  • přenášená data s možností omezit přenos některých zejména bezpečnostních elementů či omezit velikost některých elementů.

Statistický monitoring poskytuje veškerá data nezbytná pro vyhodnocení KPI definovaných v katalogovém listu služby s požadovanou historií uvedenou v kapitole 6.1.7 Historický archiv. Detail monitorovaných a archivovaných dat umožňuje pro každou transakci vyhodnotit, zda byla realizována v povolené zátěži (kalendářní sekundě s počtem požadavků < 60/s) a čas zkonzumovaný pro obsluhu transakce řešením AgriBus (čas nezahrnující dobu obsluhy volání Poskytovatele či Konzumenta služby) byl do povoleného limitu 2s. Jméno volané služby jednoznačně identifikuje službu a je volitelně použito mimo jiné pro výběr služeb kategorie S1 (dle katalogového listu služby), které jsou zahrnuty do monitoringu KPI Maximální odezva IS. Vítanou vlastností je možnost provést kategorizaci služeb jako (S1) v registru služeb a v rámci statistického monitoringu tyto informace využívat.

Monitoring bude umožňovat přímý přístup Objednatele k datům pro výpočet a vyhodnocení SLA, případně bude data poskytovat Zhotovitel v Objednatelem požadované struktuře a frekvenci na sdílené úložiště Zhotovitele odkud je Objednatel může automaticky načítat.

Statistický monitoring bude zaznamenávat a uchovávat i informace o Monitorovacích službách a Monitorovacích operacích.

      1. Bezpečnostní dohled

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.7 Zabezpečení a 6.6 Zabezpečení.

Veškeré aktivity prováděné administrátory, uživateli a napojenými aplikacemi nad systémem AgriBus musí být systémem AgriBus auditovány/logovány v čitelné podobě. Všechny takto logované auditní záznamy musí být možné přenášet real-time do systému pro bezpečnostní monitoring (SIEM) Objednatele - HP ArcSight k jejich vyhodnocení a uložení na centrálním bezpečném místě pro případnou zpětnou analýzu. Preferován je push přenos informací o realizovaných akcích tak, aby akce byla zaznamenána dříve, než případný důsledek akce ovlivní anebo zcela zamezí odeslání informace do SIEM.

Systém AgriBus musí podporovat logování aktivit administrátorů/uživatelů/napojených aplikací pomocí jedné z následujících metod:

  • Syslog zabezpečený TLS/SSL,

  • SNMP TRAP v3,

  • Textový soubor,

  • JDBC,

  • Systémový log (žurnál operačního systému).

      1. Integrace monitoringu

Systémy zajišťující monitoring řešení AgriBus budou přímo připojeny anebo mít přístup do centrální management sítě Objednatele. Od všech systémů je požadováno, aby disponovaly dedikovaným rozhraním pro připojení do management sítě Objednatele. Monitoring bude poskytovat rozhraní pro napojení na externí centrální monitoring systémy Objednatele provozované v management síti. Rozhraní pro externí monitoring systémy:

  • umožňuje předávat chyby a chybové stavy, stavové informace z dohledu běhových prostředí a provozního dohledu služeb do externího monitoring systému Objednatele,

  • poskytuje funkcionalitu pro externí aktivní monitoring formou dotazů s maximální frekvencí 5 min (poskytnutí rozhraní, které je možné zavolat pro obdržení aktuální informace o hodnotách ukazatelů monitorovaných v rámci dohledu běhových prostředí a provozního dohledu služeb.

Objednatel aktuálně provozuje dohledové systémy uvažované pro integraci s dohledem AgriBus uvedené v tabulce Tabulka 3 - Vybrané monitoring systémy Objednatele.



Tabulka 3 - Vybrané monitoring systémy Objednatele

HP Business Service Management (bývalé řešení BAC)

 8.07

Monitoring dostupnosti služeb, výstupy využity pro reporting dostupnosti služeb

HP Operation Manager for UNIX

09.10.240

Monitoring serverů, operačních systémů a aplikací

HP OpenView Performance Manager

9.03

Analýzy výkonnosti serverů a aplikací

HP Systems Insight Manager

6.3

Monitoring hardware serverů

HP Site Scope

 11.22

End-to-end testy, zejména monitoring dostupnosti portů a aplikací ověřením komunikace jednotlivých protokolů.



Monitoring dále disponuje rozhraním do historického archivu:

  • předává informace o chybových stavech detekovaných v rámci dohledu běhových prostředí a provozního dohledu služeb,

  • předává neagregované informace o realizovaných transakcích.

    1. Historický archiv

Historický archiv je centrální úložiště informací:

  • o všech datových výměnách realizovaných řešením AgriBus,

  • o událostech a chybách detekovaných v rámci dohledu běhových prostředí a provozního dohledu služeb.

Centrální archiv tedy poskytuje rozhraní pro záznam informací z ESB a monitoring systémů. Archiv dále poskytuje rozhraní pro externí reporting. Požadavky na historický archiv jsou uvedeny v kapitole 6.1.7 Historický archiv.

    1. Zabezpečení

Zhotovitel ve spolupráci s bezpečnostními specialisty Objednatele připraví návrh zabezpečení řešení AgriBus v rámci analýzy. Hlavní požadavky na zabezpečení řešení jsou dále uvedeny v kapitole 6.6 Zabezpečení. Zabezpečení řešení XxxxXxx je realizováno na několika úrovních:

  • Fyzické zabezpečení řešení AgriBus. Pro systém AgriBus bude Objednatelem vytvořena dedikovaná VLAN viz. VLAN AgriBus na Obrázek 12 – Bezpečnostní infrastruktura AgriBus. VLAN AgriBus bude zabezpečena perimetrem, jež je součástí předmětu tohoto výběrového řízení. Zhotovitel dále v rámci realizace rozdělí VLAN AgriBus na dílčí VLAN pro komponenty poskytující webové služby AgriBus (VLAN WS AgriBus) a dílčí VLAN pro komponenty tvořící back-end AgriBus (VLAN BE AgriBus). Zhotovitel volitelně může rozdělit VLAN WS AgriBus či VLAN BE AgriBus na další dílčí VLAN. Komponenty tvořící externí webové uživatelské rozhraní systému pro obsluhované procesy a aplikace dle popisu v kapitole 5 Popis požadovaného řešení budou umístěny v DMZ 1, v případě externích webových rozhraní, resp. DMZ 2 v případě interních webových rozhraní a chráněny firewall a systémy IPS/IDS Objednatele. Tato webová rozhraní bude dále možné integrovat do externího resp. interního portálového řešení Objednatele. Síťový provoz AgriBus bude realizován v rámci několika výše uvedených VLAN tak, aby byl zajištěn přístup pouze k nezbytně nutným komponentám a systémům.

  • Důvěrnost. Realizace autorizace a autentizace komunikujících stran, zajištění, že každý komunikující subjekt má přístup pouze ke zdrojům, ke kterým je autorizován. Preferovaným řešením je využití předsazených SSL akcelerátorů a Reverse Proxy tak, aby výše uvedenými úlohami nebyla zatěžována komponenta ESB AgriBus.

  • Integrita a nepopiratelnost. Zajištění, že zprávy nemohou být během přenosu pozměněny (např. využitím digitálního podpisu), čímž je protistraně zároveň možné prokázat její odesláni bez možnosti pozdějšího popření. Doporučeným řešením je implementace WS-Security jako rozšíření SOAP. Veškeré aktivity prováděné administrátory, uživateli a napojenými aplikacemi nad systémem AgriBus musí být systémem AgriBus auditovány/logovány v čitelné podobě. Všechny takto logované auditní záznamy musí být možné přenášet, nejlépe real-time, do systému pro bezpečnostní monitoring (SIEM) k jejich vyhodnocení a uložení na centrálním bezpečném místě pro případnou zpětnou analýzu.

  • Dostupnost. Ochrana služeb před DoS a implementace řešení s vysokou dostupností v geografickém clusteru. Zároveň implementace síťových a aplikačních limitů na úrovni Konzumentů, Poskytovatelů nebo služeb jako ochrana před zahlcením (např. počet relací).

Obrázek 12 – Bezpečnostní infrastruktura AgriBus

Od všech Konzumentů a Poskytovatelů služeb se očekává, že akceptují a implementují způsob zabezpečení SSL. V roli Konzumentů a Poskytovatelů služeb vystupují aplikace a systémy. Pro každý komunikující systém by měl být vystaven SSL certifikát. Komunikace mezi dílčími systémy tvořícími řešení AgriBus bude zabezpečena SSL. Požadavky na zabezpečení komunikace mezi komponentami AgriBus jsou ilustrovány na obrázku Obrázek 13 - Zabezpečení AgriBus.

Obrázek 13 - Zabezpečení AgriBus

Uživatelské účty a oprávnění do všech aplikací a systémů tvořících infrastrukturu AgriBus jsou řízeny IDM a ověřovány oproti LDAP.

ESB AgriBus dále umožňuje volitelně nastavit SSL zabezpečení i na datové toky uvnitř ESB AgriBus včetně šifrování přenášených objemných souborů.



  1. Přehled požadavků

Předmětem dodávky je návrh a implementace centrální komunikační platformy AgriBus dle popisu uvedeného v kapitole 5 Popis požadovaného řešení, včetně implementace souvisejících procesů a napojení na externí systémy Objednatele. Součástí dodávky je dále zajištění převodu služeb provozovaných na stávající platformě ESB Oracle do nového řešení AgriBus, jak je požadováno dále v dokumentu. V příloze číslo 15 zadávací dokumentace je uveden přehled závazné struktury odpovědi na technickou část zadání. Nedodržení požadované struktury odpovědi vede k vyřazení nabídky uchazeče.

Tato kapitola obsahuje přehled dalších požadavků na řešení AgriBus rozdělených do několika kategorií a doplňuje tak požadavky vyplývající z kapitoly 5 Popis požadovaného řešení.

    1. Funkční požadavky

Komunikační platforma AgriBus se skládá z několika logických funkčních komponent znázorněných na obrázku Obrázek 4 - Logický model AgriBus. Tato kapitola doplňuje popis požadovaného řešení uvedený v kapitole 5 Popis požadovaného řešení o další funkční požadavky na jednotlivé logické funkční komponenty řešení AgriBus.

Vybrané požadavky (výběr z níže uvedených požadavků uvedených v této kapitole 6.1), které jsou klasifikovány jako mandatorní (nabízené plnění je musí splňovat), jsou uvedeny v Příloze č. 5 zadávací dokumentace.

(pozn.: hodnocení kvality a míry naplnění níže uvedených požadavků se v rámci zadávacího řízení provádí dle přehledu uvedeného v Příloze č. 18 zadávací dokumentace).

      1. ESB AgriBus

Mezi základní požadavky kladené na komunikační vrstvu ESB AgriBus patří:

Konzistentní práci se službami

  • Integrace systémů na bázi webových služeb, umožňujících implementaci SOA;

  • Integrace koncových bodů využívajících různé komunikační protokoly (např. jeden koncový bod vyžaduje JMS a druhý koncový bod podporuje pouze webové služby);

  • Podpora transportů HTTP, JMS, JCA, Enterprise Java Bean, web services (SOAP 1.2, SOAP 1.1, SOAP 1.1 using JAX-RPC, SOAP 1.1/JMS);

  • Podpora orchestrace služeb (řízení workflow služeb modelované v BPEL);

  • Integrace s centrálním registrem služeb, jednotný způsob zveřejnění služby, jehož součástí je i popis služby nezávislý na technologii;

  • Dynamické vyhledávání služeb v centrálním registru;

  • Standardizovaný způsob volání služby (jak synchronními, tak asynchronními protokoly) nezávislý na transportním médiu a technologii služby;

  • Integrace s centrálním registrem služeb, jednotný způsob zveřejnění služby, jehož součástí je i popis služby nezávislý na technologii;

Směrování zpráv

  • Virtualizace koncových bodů. Konzument služby nemusí znát přesnou aktuální adresu koncového bodu Poskytovatele služby. Konzument používá relativní název Poskytovatele služby a ESB AgriBus rozhoduje, jaký koncový bod a adresu použít (ESB AgriBus k tomuto účelu využívá nastavená kritéria a registr služeb);

  • Adresace služeb nezávislá na síťové topologii;

  • Dynamické směrování podle obsahu zpráv či podle QoS kritérií (například zatížení) a politik;

  • Transparentní přepínání cílových bodů za běhu, výběr cílového bodu z registru služeb dle výše uvedených principů;

  • Možnost opakovaného testování využití koncového bodu a volba jiného vhodného bodu z registru služeb v případě selhání volání primárního koncového bodu;

  • Podpora standardizovaných adaptérů a konektorů v podobě SCA komponent (např. email, sftp, JDBC);

  • Logika pro připojení k cílovému prostředí je zapouzdřena v komponentě adaptéru;

  • Standardizovaná rozhraní pro přístup ke sběrnici z různých operačních systémů a technologií;

Mediace a transformace

  • Kanonický formát zpráv, kanonický formát datových typů, podpora a správa verzí kanonických formátů;

  • Podpora mediace a transformace zpráv pro případ, kdy komunikující body reprezentují shodná data rozdílnými datovými strukturami;

  • Obohacování zpráv o dodatečné informace;

  • Podpora mediace zpráv na všech komunikačních úrovních dle popisu v kapitole 5.1 Komunikační sběrnice ESB;

Messaging operace

  • Podpora synchronního i asynchronního volání služeb;

  • Frontování požadavků, práce s frontami;

  • Možnost selektivně zastavit příjem požadavků pro vybrané fronty;

  • Zprostředkování komunikace využívající standardní formáty, jako jsou EDI a odstínění Konzumentů od detailů těchto standardů (zapouzdření datových standardů);

Podpora přenosu souborů

  • Možnost přenosu objemných souborů v řádu 100 MB a více mezi různými systémy a platformami bez dopadu na kvalitu ostatních komunikačních toků (mimo tělo zprávy);

  • Využití datové úschovny pro přenos souborů;

  • Dynamické určení cesty pro uložení souborů;

  • Přenos souborů do určené cesty a předání adresy souboru Konzumentovi v rámci zprávy s tím, že adresa souboru musí být nepredikovatelná (např. obsahují token random 128 bit base64);

  • Monitoring přenosu souborů;

  • Volitelné zajištění end-to-end integrity souborů s možností přidat do řídící zprávy hash anebo podpis souboru a podpora přenosu souborů šifrovaných nebo podepsaných Poskytovateli a Konzumenty;

  • Volitelné potvrzení přenesení souborů zprávou;

  • Oprávnění a zabezpečení na úrovni uživatelských rolí pro přístup k přenášeným souborům;

  • Volitelné end-to-end šifrování přenášených souborů přímo na ESB nebo Poskytovateli a Konzumentovi služeb s možností do řídících zpráv přidat identifikátory klíčů a atributy podpisu (certificate chain podepisujícího, identifikátory algoritmu);

  • Konfigurace přenosů souborů v grafickém prostředí;

  • Možnost rozšířit řešení o funkcionalitu pořizující časová razítka pro soubory a přenášené zprávy.

Podpora řízení ETL úloh

  • Podpora řízení ETL úloh pro synchronizaci velkých objemů dat mezi systémy;

  • Možnost spouštět ETL úlohy a poskytovat služby Konzumentům pro spouštění ETL úloh;

  • Podpora přenosu zpráv o výsledcích ETL úloh;

Zveřejnění služeb a přihlášení k odběru služeb

  • Propagace nových služeb do centrálního registru služeb;

  • Přihlášení k odběru služeb v centrálním registru služeb;

Transakční zpracování a obsluha chyb

  • Podpora transakčního zapracování, transakcí v rámci workflow;

  • Schopnost uložit stav transakce v případě nemožnosti kvalitní a včasné odpovědi jednoho nebo více ze zúčastněných koncových bodů zahrnutých v rámci orchestrace služby a dokončení transakce v okamžiku obnovení dostupnosti koncového bodu (pozastavení a opakované spuštění transakce);

  • Zajištění konzistence dat v zúčastněných koncových bodech v případě pozastavení zpracování transakce. Možnost vykonání automatické či manuální kompenzační akce v ovlivněných bodech;

  • Schopnost provést roll-back transakce (roll-back i v zúčastněných koncových bodech podporujících transakční zpracování);

  • Podpora vlastností ACID (Atomicity , Consistency, Isolation, Durability);

  • Podpora pro dlouho běžící procesy a možnost individuálních odbavení transakcí (commit) v jednotlivých zúčastněných systémech;

  • Možnost opakovaného volání systémů a konfigurace počtu opakovaných volání (po chybě);

  • Přehled běžících transakcí, který bude poskytovat:

    • možnost vyhledat transakci dle kritérií,

    • informace, v jakém stavu se transakce nachází,

    • informace v jakém koncovém bodu, bodech se transakce aktuálně nachází,

    • informace, ve kterém systému transakce selhala,

    • další monitoring informace o transakcích viz. kapitola 5.5 Monitoring;

  • Zajištění proti duplicitě transakcí. Možnost definovat pravidla pro ověření, zda již transakce v systému byla založena či nikoliv (např. zda již byla přijata zpráva příslušného typu ze stejným identifikátorem osoby);

  • Možnost nastavení politik pro obsluhu chyb;

Jednotné řízení

  • Podpora řízení běhu prostřednictvím událostí (event driven architecture);

  • Generování událostí v případě výskytu chyby;

  • Zaručené doručení událostí – podpora „store and forward“ funkcionality;

  • Řízení sekvencí událostí;

  • Možnost zastavení příjmu všech zpráv anebo zpráv pro individuální frontu, přičemž všechny zprávy obdržené před zastavením příjmu budou doručeny a související transakce dokončeny;

  • Podpora řízeného vypnutí systému bez dopadu na rozpracované transakce a konzistenci dat v komunikujících systémech (např. nejprve zastavení příjmu požadavků do vstupních front, dokončení všech rozpracovaných transakcí a poté zastavení systému);

  • Podpora uchování stavů transakcí a procesů („state machine“);

  • Jednotný monitoring, audit, logování, měření, instalace, konfigurace a deployment integračních a dalších ESB komponent napříč celou IT infrastrukturou;

  • Jednotný bezpečnostní management, digitální podpisy a šifrování zpráv;

  • Optimalizace služeb podle zátěže;

  • Orchestrace služeb, volání zúčastněných koncových bodů v rámci definovaného workflow;

  • Schopnost obsluhovat selhání a chyby v rámci workflow;

  • Schopnost iniciace workflow v ESB AgriBus na základě externí události;

Quality of service

  • Zaručené doručení, doručení právě jednou;

  • Možnost řízení priority zpráv dle Poskytovatele služby či dle Konzumenta služby;

  • Mechanismy pro zaručení vysoké dostupnosti (high-availibility, fail-over) a přechod do záložních center (disaster recovery);

  • Inteligentní a přitom transparentní rozložení zátěže pro zaručení škálovatelnosti (load balancing);

  • Nastavení kvality komunikace (timeouty, priorita, způsob přenosu, řízení objemu komunikace) a ochrana koncových prvků před nadměrnou zátěží.

      1. Procesní platforma AgriBus BPM

Řešení XxxxXxx musí poskytovat funkcionality pro podporu běhu dlouho trvajících procesů zahrnujících lidské interakce. Mezi základní požadované funkcionality patří:

  • podpora dlouho trvajících procesů,

  • možnost návrhu procesů v grafickém prostředí a zároveň přímou editací definičních souborů,

  • podpora návrhu, běhu a zobrazení webových formulářů zprostředkujících uživatelské vstupy v rámci procesů,

  • možnost rozšířit standardní funkcionality webových formulářů o nově vyvinuté aplikační komponenty a nové komponenty grafického uživatelského rozhraní,

  • možnost přidávat další procesní aplikace a agendy bez negativních dopadů na provoz řešení AgriBus a zejména na komunikační vrstvu ESB,

  • podpora integrace webových rozhraní procesů a aplikací do portálového řešení Objednatele, zejména podpora Single-sign-on a ověřování oproti LDAP Objednatele a podpora Java Portlet Specification,

  • podpora přístupu prostřednictvím mobilních platforem (zejména Android, IOS),

  • podpora automatické aktualizace dat ve formulářích či aktualizace na žádost v případě změny podkladových zdrojových dat.

      1. Designér webových formulářů

V rámci návrhu a vytváření webových formulářů je požadováno:

  • 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.

      1. 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 v jaké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;

  • 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:

  • 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.

      1. Designér služeb

Základní funkční požadavky na designér služeb jsou:

  • 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);

      1. 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;

  • 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 2s) 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í.

      1. Historický archiv

Pro historický archiv jsou požadovány následují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ů,

  • 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

Historie neagregovaných dat dostupná na vyžádání

10 let



    1. 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 v kapitole 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 v kapitole 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:

    • výpadek jednoho z datových center bez funkce UPS (servery nejsou zastaveny korektně),

    • 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í),

    • flapování napájení (výpadek a neřízené obnovení napájení v jednom datovém centru),

    • 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í.

Detailní požadavky na zálohování jsou dále uvedeny v katalogovém listu služby.

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:

  • 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;

  • posoudí kompatibilitu služeb s novými funkcionalitami XxxxXxx 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;

  • 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;

  • 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:

  • 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;

  • V prů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;

  • 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ů;

  • 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;

  • 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ě;

  • V rá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.

    1. Dodávka

Odběratel v rá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 ř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í:

  • produkční prostředí AgriBus,

  • testovací prostředí AgriBus,

  • 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ů

Počet současně pracujících administrátorů systému

2

Počet současně pracujících designerů a vývojářů služeb a agendových aplikací v AgriBus

20

Počet současně pracujících vývojářů systémů Konzumentů a Poskytovatelů služeb (přístup k informacím v registru služeb a rozhraní AgriBus, případně dalším dle navrhované metodiky)

20

Počet současně pracujících uživatelů procesních aplikací

Odhad 100 – 1000 uživatelů (preferováno 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.

    1. Instalace

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

Datové centrum Nagano

K Červenému dvoru 25/3156

130 00 Xxxxx 0 – Xxxxxxxxx

Datové centrum Chodov

V lomech 2339/1

149 00 Praha 4 – Chodov



    1. 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 v katalogovém listu služby. Monitoring dostupnosti a funkcionality AgriBus bude realizován využitím volání specializované testovací služby, jak je uvedeno v kapitole 5.5 Monitoring. Monitorovací služba musí poskytovat operaci vracející hodnotu 0 nebo 1 (dle aktuálního stavu uzlu AgriBus) , jež může být využita load balancery pro směrování provozu.

Vzhledem k vysoký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í.


    1. Zabezpečení

Zhotovitel v rá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í,

  • 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í,

  • 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,

  • způsob zabezpečení volání jednotlivých služeb AgriBus.

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),

  • aby systém podporoval běh služeb pod neprivilegovanými účty,

  • 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,

  • zabezpečení virtualizační platformy v případě nasazení virtuální infrastruktury,

  • podpora PKCS11 pro kryptografické operace s asymetrickými šiframi,

  • 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ě zapnout a vypnout jednotlivé protokoly až na úrovni listeneru,

  • zapnutí anebo vypnutí kontroly revokace prostřednictvím CRL i OCSP,

  • podpora cipher suites s PFS,

  • v pří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,

  • 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,

  • 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.

    1. 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:

  • 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 v kapitole 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,

  • v rá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,

  • 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.

    1. 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ů.

  • 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í,

  • přípravu návrhu testování a hodnotících kritérií,

  • přípravu testovacích scénářů,

  • 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ů AGB01-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.

    1. 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,

  • popis architektury AgriBus včetně modelů dle standardů Togaf/Archimate pro

  • 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,

  • popis konfigurace řešení pro prostředí Objednatele,

  • 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é:

  • přehled stávajících služeb provozovaných na ESB Oracle s kategorizací do S1, S2 a S3 (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 S3,

  • č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,

  • xxxxxx 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 roll-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 v centrá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 v systé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 v rá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:

  • architektonický model služby dle standardu Togaf/Archimate,

  • definice služby,

  • popis služby,

  • popis logiky služby,

  • způsob volání služby,

  • 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é v modelu 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,

  • 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:

  • popisy,

  • diagramy,

  • tabulky,

  • 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),

  • 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,

  • 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.

    1. 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í XxxxXxx 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í.

  • 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.

    1. 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ě v kompetenci 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ů,

  • zajištění a zprostředkování podpory výrobce všech hardware a software produktů,

  • podporu Zhotovitele řešení,

  • údržbu zahrnující standardní profylaktické aktivity,

  • aplikaci opravných patchů či realizaci upgrade v důsledku chyb řešení,

  • 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,

  • 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),

  • 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.

      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ů

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ů AGB01. Případné reparametrizace, modifikace či rozšíření ESB AgriBus související s nasazením procesních aplikací jsou zajišťovány Zhotovitelem dle parametrů definovaných v katalogovém listu AGB05 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 AGB05 Reparametrizace a optimalizace. Přesná podoba procesů pro návrh, vývoj a nasazení procesních aplikací v BPM 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.

      1. 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.

    1. 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,

    • 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,

  • 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í.

Detailní požadavky na zálohování jsou uvedeny v Katalogovém listu služby.

    1. Š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ě:

Školení architektů a vývojářů služeb XxxxXxx

Úč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 AGB05 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: Xxxxxxxx návrhu služeb v řešení AgriBus navržená dle kapitoly 6.10 Metodika.

Hlavní náplň školení:

  • představení architektury a technického řešení AgriBus;

  • představení funkcionalit řešení AgriBus;

  • 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;

  • 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;

  • 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 organizaci 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í;

  • 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í.

Školení architektů a vývojářů Konzumentů služeb XxxxXxx

Úč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

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í:

  • 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 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ů.

    1. 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šší.

    1. 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ů.

  • 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řipojených subjektů (např. testovat na simulovaných datech a simulovaných prvcích infrastruktury apod.).





Objednatel

V _____________ dne _____________

Zhotovitel

V _____________ dne__________________

________________________________

Česká republika – Ministerstvo zemědělství

[doplní zadavatel]

________________________________

[DOPLNÍ UCHAZEČ]




Příloha č. 1 – Dokumentace ESB Oracle

Tato příloha obsahuje důvěrné informace a bude předána Uchazeči v souladu se zadávací dokumentací na vyžádání po podpisu dohody o ochraně důvěrných informací.

Document Metadata

Filed: March 19th, 2023