Kupní smlouva

Kupní smlouva

na dodání INTEGRAČNÍ PLATFORMY

v souladu s ustanovením § 2079 a § 2358 následující zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů

(dále jen „zákon“)

Smluvní strany:

1. Univerzita Hradec Králové

sídlem: Xxxxxxxxxxxx 00, 000 00 Xxxxxx Králové zastoupen: prof. Ing. Xxxxxxx Xxxxx, Ph.X., rektorem

IČO: 62690094

DIČ: CZ62690094

veřejná vysoká škola podle zákona č. 111/1998 Sb., nezapsaná v obchodním rejstříku

ID datové schránky: k3xj9dz bankovní spojení: 2733582/0800

kontaktní osoba: Xxx. Xxxxxx Xxxxxxxxx, e-mail: xxxxxx.xxxxxxxxx@xxx.xx, tel.: 000 000 000 dále jen „kupující“,

a

2. PHYSTER TECHNOLOGY, a.s.

se sídlem: Xxxxxxxxxxx 000/00, Xxxxx, 000 00 Xxxxx 0

zastoupen: Ing. Xxxxxx Xxxxxxxxxx, místopředsedou představenstva

zapsána: v Obchodním rejstříku, vedeném Městským soudem v Praze, pod spis. zn. B 8937 IČO: 27091937

DIČ: CZ27091937

ID datové schránky: 7g7fnx3

bankovní spojení: 51-1771150247/0100

kontaktní osoba: Xx. Xxxxx Xxxxxxx, e-mail: xxxxx.xxxxxxx@xxxxxxx.xxx, tel.: x000 000 000 000 dále jen „prodávající“,

uzavírají tuto kupní smlouvu na dodání nového informačního systému integrační platformy a nasazení prodávajícím v prostředí kupujícího (dále jen „smlouva“).

Preambule

Tato smlouva se uzavírá mezi kupujícím, který rozhodl o vítězi ve veřejné zakázce „Integrační platforma“, a prodávajícím, který se stal vítězem v této zakázce. Tato smlouva vymezuje práva a povinnosti obou smluvních stran při výkonu plnění prodávajícího v rámci této smlouvy.

I. Účel smlouvy

Účelem smlouvy je dodání a implementace nového informačního systému integrační platformy, která jako integrační middleware zajišťuje komunikaci mezi jednotlivými systémy a komponentami kupujícího, komunikaci jednotlivých systémů a komponent kupujícího se systémy a komponentami externích subjektů.

II. Úvodní ustanovení

1) Kupující prohlašuje, že splňuje veškeré podmínky a požadavky v této smlouvě stanovené a je oprávněn tuto smlouvu uzavřít a řádně plnit závazky v ní obsažené.

2) Prodávající prohlašuje, že:

a) je právnickou osobou řádně založenou a existující podle českého právního řádu, a

b) splňuje veškeré podmínky a požadavky v této smlouvě stanovené a je oprávněn tuto smlouvu uzavřít a řádně plnit závazky v ní obsažené, a

c) ke dni uzavření této smlouvy vůči němu není vedeno řízení dle zákona č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů, a zároveň se zavazuje kupujícího o všech skutečnostech o hrozícím úpadku bezodkladně informovat, a

d) se detailně seznámil s rozsahem a povahou předmětu veřejné zakázky, že jsou mu známy veškeré technické, kvalitativní a jiné podmínky nezbytné k její realizaci, těmto podmínkám rozumí a je schopný je dodržet, a

e) disponuje veškerými profesními znalostmi a dovednostmi k řádnému splnění předmětu veřejné zakázky a že všechny osoby, které použije k plnění této smlouvy, mají potřebné vzdělání, zkušenosti či jinou profesní způsobilost k plnění, které má prodávající dle této smlouvy poskytovat.

III. Předmět smlouvy

Předmětem smlouvy je závazek prodávajícího dodat informační systém integrační platformy s časově a věcně neomezenou licencí, který je blíže specifikován v přílohách této smlouvy (a sice v přílohách Technická specifikace, Požadavky na informační systém a Katalog služeb), včetně jeho implementace a poskytování bezplatné licenční podpory do 31.12.2024 a provedení aktualizace všech komponent integrační platformy k datu uvedení do provozu první funkční služby/propojení analogickým způsobem jako v případě poskytování podpory (vše dále jako “předmět smlouvy”) a závazek kupujícího uhradit prodávajícímu za předmět smlouvy cenu sjednanou v čl. VI. této smlouvy.

IV. Doba platnosti a účinnost smlouvy

Smlouva nabývá platnosti dnem jejího podpisu poslední smluvní stranou a účinnosti dnem jejího uveřejnění v registru smluv.

V. Předání předmětu smlouvy

1) Prodávající poskytne plnění dle této smlouvy v místě stanoveném kupujícím.

2) Prodávající zahájí dodání předmětu smlouvy neprodleně po nabytí účinnosti smlouvy ve lhůtách uvedených v příloze „Technická specifikace – Integrační platforma. docx“ s termínem předání předmětu smlouvy nejpozději do 8 týdnů ode dne nabytí účinnosti smlouvy.

3) Po úspěšném dokončení implementace informačního systému integrační platformy je kupujícím vypracován akceptační protokol, který dokládá souhlas kupujícího s akceptací dodávky informačního

systému integrační platformy. Protokol obsahuje seznam akceptačních kritérií a jejich vyhodnocení, seznam vad a nedodělků, které nebrání provozu integrační platformy a lze je odstranit po akceptaci dodávky.

4) Akceptaci a zpracování akceptačního protokolu dodávky lze kupujícím provést pouze v případě, že nebyla zjištěna chyba bránící správnému fungování integrační platformy a platformu lze plně provozovat na testovacím i produkčním prostředí, bylo provedeno školení administrátorů a předána kompletní dokumentace.

5) Akceptační protokol musí být podepsán kupujícím i prodávajícím s tím, že datum podpisu akceptačního protokolu je klíčový pro určení, kdy bylo předání informačního systému integrační platformy skutečně provedeno.

6) V případě, kdy nebude možné převzít předmět smlouvy do užívání (nebude možné provést akceptaci) do stanoveného termínu a nedojde-li k uvedení integrační platformy do funkčního stavu nejpozději do 1 kalendářního měsíce po stanoveném termínu data předání, považuje se to za podstatné porušení smlouvy prodávajícím.

VI. Cena

1) Xxxxxxx cena za předmět smlouvy se stanovuje dle přílohy „Specifikace nabídkové ceny.xlsx“ této smlouvy (buňka E8):

cena v Kč bez DPH	cena v Kč s DPH	tj. DPH ve výši:
1 100 000,-	1 331 000,-	231 000,-

2) Sazba a výše DPH bude prodávajícím vypočtena v souladu se zákonnými předpisy ČR (zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů).

3) Dohodnutá cena zahrnuje:

a) veškeré náklady prodávajícího související s plněním předmětu této smlouvy,

b) odměnu za všechny poskytnuté licence potřebné pro provozování systému integrační platformy včetně souvisejících komponent.

Tato cena je stanovena jako cena nejvýše přípustná pro plnění předmětu této smlouvy.

4) Celková cena za předmět smlouvy může být změněna pouze v případě změny sazby DPH, která podléhá změnám zákona č. 235/2004 Sb., o dani z přidané hodnoty.

VII. Platební podmínky

1) Prodávající vystaví daňový doklad za předaný předmět smlouvy, uvedený v článku 1), v souladu s článkem VI a VII této smlouvy, do 10 dnů od podepsání akceptačního protokolu o dodání bezvadného předmětu smlouvy kupujícím.

2) Daňový doklad bude obsahovat náležitosti daňového a účetního dokladu podle zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů, zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů. V případě, že daňový doklad tyto náležitosti nebude splňovat, bude kupujícím vrácen do dne splatnosti daňového dokladu k opravení bez jeho proplacení. V takovém případě lhůta splatnosti počíná běžet znovu ode dne doručení opraveného či nově vyhotoveného

daňového dokladu. Prodávající je povinen nový řádně vystavený daňový doklad doručit kupujícímu do 10 dnů ode dne doručení vráceného vadného daňového dokladu prodávajícímu.

3) Smluvní strany se dohodly na úhradě formou bankovního převodu na bankovní účet prodávajícího uvedený výše ve smlouvě.

4) Řádně vystavený daňový doklad bude prodávajícím zaslán kupujícímu elektronickou formou na adresu xxxxxx.xxxxxx@xxx.xx.

5) Kupující uhradí fakturovanou částku prodávajícímu do 30 dnů ode dne doručení řádně vystaveného daňového dokladu. Daňový doklad se považuje za uhrazený okamžikem odepsání platby z účtu kupujícího.

VIII. Záruční doba a odpovědnost za vady

1) Prodávající poskytuje na předmět smlouvy záruku v délce 2 let, která běží ode dne bezvadného předání a převzetí předmětu smlouvy, tj. ode dne podpisu akceptačního protokolu.

2) Po dobu, kdy kupující nemůže předmět smlouvy užívat pro shledané vady, záruční doba neběží.

3) Kupující bez zbytečného odkladu oznámí prodávajícímu vady zjištěné v průběhu užívání předmětu smlouvy stejným způsobem jako v případě provozních požadavků uvedených v příloze „Katalog služeb – Integrační platforma.docx“.

4) Odstranění vad a nedodělků z akceptačního protokolu i vad a nedodělků zjištěných v průběhu užívání předmětu smlouvy bude prodávajícím provedeno bez zbytečného prodlení stejným způsobem, za stejných podmínek a termínů jako v případě provozních požadavků uvedených v příloze „Katalog služeb – Integrační platforma.docx“. Pokud nedojde k odstranění vad a nedodělků nejpozději do dvojnásobku stanovené doby vyřešení, považuje se to za podstatné porušení smlouvy prodávajícím.

IX. Kybernetická bezpečnost

1) Prodávající je povinen zajistit, aby plnění podle předmětu této smlouvy bylo v souladu se zákonem č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), v platném znění (dále jako “ZoKB”) a vyhláškou č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), v platném znění (dále jako “VoKB”).

2) Prodávající se zavazuje poskytnout kupujícímu veškerou součinnost nezbytnou k tomu, aby kupující řádně naplňoval právní povinnosti stanovené ZoKB. Zejména se prodávající zavazuje poskytnout kupujícímu součinnost směřující k zavedení a provádění bezpečnostních opatření podle uvedených právních předpisů. Kupující má právo, u plnění, které je předmětem této smlouvy, na pravidelné provádění auditů a kontrol bezpečnostních opatření uvedených v § 3 a násl. VoKB, které je povinen provádět podle § 8 odst. (2) písm. c) VoKB. V takovém případě je kupující povinen oznámit prodávajícímu svůj záměr audit provést, a to nejpozději do 30 dnů před plánovaným zahájením auditu.

X. Smluvní pokuty

1) V případě nedodržení termínů stanovených na odstranění vad a nedodělků z akceptačního protokolu i vad a nedodělků zjištěných v průběhu užívání předmětu smlouvy má kupující nárok na smluvní pokutu za každý započatý den prodlení, a to až do data vyřešení a dodání servisního požadavku pro každou neodstraněnou vadu a nedodělek v prodlení dle priority řešení požadavku:

Sankce plynoucí z nedodržení termínů řešení požadavků
Priority *	Výše sankce za požadavek v Kč (za každý započatý den prodlení)
1 - Kritická	1000 Kč/den
2 - Vysoká	500 Kč/den
3 - Střední	300 Kč/den
4 - Nízká	100 Kč/den

* Definice priorit v příloze „Katalog služeb – Integrační platforma.docx“

V případě prodlení s řešením více požadavků je pokuta počítána jako kumulace jednotlivých pokut za dny prodlení za každý požadavek, u kterého k prodlení došlo.

2) V případě nedodržení termínu pro dodání a převzetí předmětu smlouvy do užívání (nebude možné provést akceptaci) má kupující nárok na smluvní pokutu ve výši 1000 Kč za každý započatý den prodlení.

3) Dále prodávající zaplatí kupujícímu jednorázovou smluvní pokutu ve výši 5 000 Kč za každé jednotlivé porušení postupu dle čl. XII odst. 11 této smlouvy při změně člena realizačního týmu uvedeného v příloze „Realizační tým“.

4) V případě prodlení s úhradou jednotlivých řádně vystaveného daňového dokladu je prodávající oprávněn kupujícího sankcionovat smluvní pokutou ve výši 0,05 % z fakturované částky za každý započatý den po splatnosti.

5) Smluvní pokuty a úroky z prodlení jsou splatné do 30 dnů ode dne doručení vyúčtování povinné straně.

6) Smluvní pokuty a úrok z prodlení vzniklé na základě této smlouvy hradí povinná smluvní strana bez ohledu na to, zda a v jaké výši vznikla druhé smluvní straně v této souvislosti škoda.

7) Uplatněním nároku na smluvní pokutu není dotčen nárok kupujícího na náhradu škody způsobené mu prodávajícím, a to do výše 10 000 000 Kč, zejména nárok na náhradu škody vzniklou v souvislosti s únikem dat a informací z předaných materiálů, respektive jejich obsahu, která by objednateli způsobila vznik dodatečných nákladů. Ustanovení § 2050 občanského zákoníku se tak nepoužije.

8) Kupující je oprávněn smluvní pokuty jednostranně započíst oproti jakékoliv pohledávce prodávajícího.

XI. Odpovědnost za škody

1) Prodávající se zavazuje mít po dobu poskytování servisu podle této smlouvy uzavřené pojištění odpovědnosti za škodu způsobenou prodávajícím třetí osobě s limitem pojistného plnění ve výši min. 10 000 000 Kč a tuto skutečnost na základě výzvy kupujícího kdykoliv prokázat předložením kopie dokladu o uzavřeném pojištění.

2) Prodávající plně odpovídá kupujícímu za veškeré škody jím způsobené v důsledku porušení závazků dle této smlouvy nebo škody, které vzniknou porušením kázně pracovníků prodávajícího či z nedbalosti.

3) Prodávající odpovídá za případné porušení práv z průmyslového nebo jiného duševního vlastnictví třetích osob.

XII. Zvláštní ujednání

1) Jednacím jazykem při ústním či písemném styku, souvisejícím s plněním této smlouvy, je český nebo slovenský jazyk.

2) Smluvní strany se dohodly, že si bezodkladně písemně sdělí skutečnosti, které se týkají změn některého z jejich základních identifikačních údajů, včetně právního nástupnictví, anebo kontaktních údajů, jednostranným písemným oznámením doručeným jednou smluvní stranou druhé smluvní straně.

3) Veškerá smluvní komunikace mezi smluvními stranami týkající se této smlouvy musí být učiněna v písemné formě, není-li v textu smlouvy uvedeno výslovně jinak, a musí být doručena datovou schránkou nebo osobně nebo prostřednictvím doporučené poštovní zásilky s dodejkou mezi kontaktními osobami smluvních stran, na adresy uvedené v záhlaví této smlouvy, nebo prostřednictvím e-mailových adres uvedených v této smlouvě, a to s potvrzením o přijetí, které si jsou smluvní strany povinny poskytnout.

4) Veškerá provozní komunikace mezi smluvními stranami týkající se této smlouvy bude probíhat způsobem uvedeným v příloze „Katalog služeb – Integrační platforma.docx“.

5) Pokud předmět smlouvy zahrnuje i díla ve smyslu autorského zákona a nestanoví-li odstavec 7 tohoto článku jinak, prodávající uděluje kupujícímu licence k věcně i časově neomezenému používání díla. Prodávající zároveň prohlašuje, že je oprávněn tyto licence udělit, neboť příslušnými majetkovými právy k dílům i všem jejich částem disponuje.

6) Pro předmět smlouvy, uvedený v článku III. této smlouvy, prodávající uděluje licence k dílům i ke všem jejich jednotlivým částem v rozsahu níže uvedeném:

a) pro informační systém integrační platformy jako nevýhradní časově a věcně neomezené;

b) pro integrační služby/propojení systémů jako výhradní (vlastníkem se po úhradě dle článků VI a VII této smlouvy stává kupující), časově a věcně neomezené a prodávající není v tomto případě oprávněn poskytnout licence k těmto částem třetím osobám bez souhlasu kupujícího.

7) Veškerá data kupujícího uložená v databázi nebo v jakémkoliv jiném uložišti nestrukturovaných dat jsou vždy ve vlastnictví kupujícího, a to i v případě jejich úpravy, a kupující má s nimi právo jakkoliv nakládat včetně exportu, přenosu, importu, transformace a jiných operací s daty v rámci běžného provozu systému a připojených externích aplikací.

8) Prodávající současně prohlašuje, že k dodanému informačnímu systému integrační platformy je možné v prostředí kupujícího zajišťovat:

a) licenční podporu včetně L3 technické podpory výrobcem,

b) provozní podporu,

c) vývoj a úpravu integrační služby/propojení, těmito subjekty:

i. prodávajícím informačního systému,

ii. kupujícím,

iii. kupujícím v součinnosti s výrobcem nebo prodávajícím informačního systému,

iv. kupujícím určeným smluvním partnerem,

v. kupujícím v součinnosti s kupujícím určeným smluvním partnerem.

9) Prodávající není oprávněn zcela ani zčásti postoupit na třetí osobu žádné ze svých práv, ani žádný ze svých závazků plynoucích z této smlouvy ani tuto smlouvu jako celek.

10) Prodávající je povinen při realizaci zakázky využívat osoby uvedené v příloze „Realizační tým“. Osoby v realizačním týmu jsou zároveň kontaktními osobami prodávajícího pro konzultace ohledně plnění smlouvy. Prodávající je povinen neprodleně vyrozumět kupujícího o zamýšlené změně členů realizačního týmu, nebo subdodavatelů, kteří jsou uvedeni v této smlouvě, nebo subdodavatelů, kterými byla prokazována kvalifikace v rámci zadání podmínek veřejné zakázky. Provedení změny osob uvedených v předchozí větě je možné jen po předchozím schválení kupujícím, přičemž vždy všechny změněné osoby musejí splňovat všechny relevantní podmínky (zejména kvalifikační požadavky) stanovené v dokumentaci související veřejné zakázky, z níž prodávající vzešel jako vítěz. Tuto skutečnost je povinen prodávající doložit obdobnými doklady, jaké byl povinen doložit k osobám v obdobném postavení (např. členům realizačního týmu, subdodavatelům při prokazování kvalifikace apod.) v průběhu veřejné zakázky. Žádost o změnu osob uvedených v tomto odstavci a schválení této změny musejí mít písemnou formu a změna může být provedena až v případě souhlasu kupujícího s touto změnou.

XIII. Zánik závazků

1) Smluvní strany se dohodly, že závazek ze smluvního vztahu zaniká v těchto případech:

a) splněním smlouvy;

b) dohodou smluvních stran při vzájemném vyrovnání účelně vynaložených a prokazatelně doložených nákladů ke dni zániku smlouvy;

c) jednostranným odstoupením kupujícího od smlouvy pro její podstatné porušení prodávajícím;

d) jednostranným odstoupením kupujícího od smlouvy v případě, že prodávající uvedl v nabídce informace nebo doklady, které neodpovídají skutečnosti a měly nebo mohly mít vliv na výsledek veřejné zakázky;

e) pokud na majetek prodávajícího probíhá insolvenční řízení, v němž bylo vydáno rozhodnutí o úpadku nebo návrh na insolvenční řízení byl zamítnut, z důvodů, že majetek společnosti nepostačuje k úhradě nákladů insolvenčního řízení.

2) Odstoupení od této smlouvy musí mít písemnou formu s uvedením důvodu, přičemž písemný projev vůle odstoupit od této smlouvy musí být druhé smluvní straně doručen datovou schránkou nebo doporučeným dopisem s dodejkou na adresu sídla uvedenou v záhlaví této smlouvy.

3) Pokud dojde k odstoupení od smlouvy z důvodu nemožnosti převzetí předmětu smlouvy (nebude možné provést akceptaci), tak prodávající převezme zpět provedené plnění, pokud již bylo plněno, a v takovém případě ztrácí právo na peněžité plnění za dodání předmětu smlouvy i na jakoukoliv jinou požadovanou náhradu od kupujícího. Právo kupujícího požadovat úhradu smluvních pokut a případné jemu vzniklé škody tímto není dotčeno.

XIV. Rozhodné právo a řešení sporů

1) Práva a povinnosti smluvních stran touto smlouvou výslovně neupravené se řídí občanským zákoníkem a dalšími právními předpisy České republiky.

2) Veškeré spory vyplývající ze smlouvy nebo s ní související budou rozhodovány věcně a místně příslušnými soudy České republiky.

XV. Závěrečná ustanovení

1) Smlouva se uzavírá písemně za použití elektronických prostředků.

2) Smlouva může být měněna či doplňována vzájemně odsouhlasenými a podepsanými písemnými a vzestupně očíslovanými dodatky, které se stávají její nedílnou součástí.

3) Smlouva nabývá platnosti po podepsání oběma smluvními stranami a účinnosti dnem uveřejnění v registru smluv podle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv), ve znění pozdějších předpisů. Prodávající prohlašuje, že souhlasí se zveřejněním dokumentů a údajů, které musí být ze zákona zveřejněny. Prodávající souhlasí se zveřejněním obsahu smlouvy. To neplatí v případě, že smlouva obsahuje informace, které se kvalifikují jako obchodní tajemství. Obsahuje-li smlouva obchodní tajemství, prodávající je povinen toto obchodní tajemství předem označit. Uveřejnění zabezpečí kupující bez zbytečného prodlení a současně se zavazuje informovat druhou smluvní stranu o provedení registrace tak, že zašle druhé smluvní straně kopii potvrzení správce registru smluv o uveřejnění dokumentů bez zbytečného odkladu po obdržení potvrzení, popřípadě již v průvodním formuláři vyplní příslušnou kolonku s ID datové schránky druhé smluvní strany.

4) Prodávající bere na vědomí, že je osobou povinou spolupůsobit při výkonu finanční kontroly dle § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě, v platném znění. Prodávající se zavazuje, že umožní všem subjektům oprávněným k výkonu kontroly projektu, z jehož prostředků je dodávka hrazena, provést kontrolu dokladů souvisejících s plněním zakázky, a to po dobu danou právními předpisy ČR k jejich archivaci (zákon č. 563/1991 Sb., o účetnictví, a zákon č. 235/2004 Sb., o dani z přidané hodnoty). Prodávající se zavazuje povinností uchovávat doklady související s plněním této zakázky nejméně do 31. 12. 2033.

5) Prodávající potvrzuje, že se na zpracování jeho nabídky nepodílel zaměstnanec kupujícího, člen statutárního orgánu kupujícího, statutární orgán, člen správní rady kupujícího, člen realizačního týmu projektu či osoba, která se na základě smluvního vztahu podílela na přípravě nebo zadání souvisejícího řízení, dále že není dodavatelem či dodavatelem ve sdružení s osobou, která je zaměstnancem kupujícího či členem realizačního týmu či osobou, která se na základě smluvního vztahu podílela na přípravě nebo zadání předmětného řízení, nebo poddodavatelem dodavatele není zaměstnanec kupujícího, člen realizačního týmu či osoba, která se na základě smluvního vztahu podílela na přípravě nebo zadání předmětného řízení.

6) Prodávající rovněž činí čestné prohlášení ve vztahu k situaci ohledně sankcí přijatých EU vůči Rusku a Bělorusku (např. nařízení Rady č. 269/2014 či 208/2014 či 765/2014); poskytovatel tímto prohlašuje, že nefiguruje na jmenném seznamu osob v přílohách těchto nařízení ani není jinak sankcionovanou osobou, a totéž prohlašuje o svých příp. poddodavatelích.

7) Nedílnou součástí této smlouvy jsou následující přílohy: Příloha – „Technická specifikace – Integrační platforma.docx“

Příloha – „Požadavky na informační systém – Integrační platforma.xlsx“

Příloha – „Katalog služeb – Integrační platforma.docx“ Příloha – „Specifikace nabídkové ceny.xlsx“

Příloha – „Realizační tým“

V případě, že by došlo k rozporu mezi smlouvou a přílohou, platí ustanovení smlouvy.

Mravinač

8) Na důkaz souhlasu s obsahem této smlouvy připojují smluvní strany podpisy svých statutárních zástupců.

Kuča, Ph.D.

prof. Ing. Xxxxx

Digitálně podepsal xxxx. Xxx. Xxxxx Xxxx, Ph.D. Datum: 2023.12.20

09:20:28 +01'00'

Xxxxx

Digitálně podepsal Xxxxx Xxxxxxxx Datum: 2023.12.15

16:00:35 +01'00'

……………………………………………………. ……………………………………………………. za kupujícího za prodávajícího

Technická specifikace pro informační systém

„Integrační platforma“

Obsah

1. Úvod 3

2. Technické požadavky na systém a jeho implementaci 3

3. Dodání a implementace systému 4

3.1. Analýza prostředí a tvorba cílového konceptu implementace 4

3.2. Zprovoznění integrační platformy 4

3.3. Implementace ověřovací úlohy, testování 5

3.4. Licenční maintenance včetně provedení aktualizace 5

4. Provozní infrastruktura 5

5. Požadavky na podporu systému 6

6. Lhůty pro dodání jednotlivých částí zakázky 6

7. Exit strategie 7

1. Úvod

Řešení informačního systému integrační platformy bude sloužit na integraci interních i externích systémů, kdy se primárně bude řešit propojení systému spisové a archivní služby, dle podmínek národního standardu, minimálně se systémy, které zajišťují systémovou podporu pro:

- studijní agendu,

- celoživotní vzdělávání,

- praxe,

- studenty se specifickými potřebami,

- koleje,

- veřejné zakázky,

- účetní a personální agendu,

- manažerské rozhodování,

- granty,

- projekty,

- a podobně.

V rámci dodání řešení informačního systému integrační platformy je:

- dodávka informačního systému a jeho implementace,

- zajištění podpory:

o licenčních servisních služeb,

o provozních servisních služeb,

o vývojových služeb zejména na tvorbu propojení mezi systémy,

o konzultačních služeb.

Zadavatel (kupující, objednavatel) požadovaného řešení je Univerzita Hradec Králové.

Dodavatel (prodávající, poskytovatel) je firma nabízející své řešení požadované integrační platformy a souvisejících služeb.

2. Technické požadavky na systém a jeho implementaci

Informační systém integrační platformy bude splňovat všechny parametry funkčních a nefunkčních požadavků uvedených v souboru „Požadavky na informační systém – IntegracniPlatforma.xlsx“ v rozpadu po jednotlivých oblastech.

V rámci implementace informačního systému dodavatel:

• zpracuje analýzu prostředí a cílový koncept implementace integrační platformy v prostředí zadavatele;

• dodá všechny komponenty a licence potřebné pro provoz řešení integrační platformy jako Enterprise Service Bus integrace, umožňující integraci webových služeb, souborových přenosů, datových přenosů, podporující real-time přenosy i dávkové proudové přenosy (streaming), obsahující API Gateway, naplňující infrastrukturní a architekturní požadavky, řešící bezpečnost a provozovatelnost platformy, umožňující modelování služeb, poskytující vývojové prostředí služeb, prostředí repositáře služeb a jejich dokumentace; tzn. kompletní dodávku všech softwarových komponent, aplikačních softwarových modulů a licencí, které zaručují odstranění veškerých případných limitů na využití všech funkcionalit dodávaného řešení;

• dodá další potřebné systémové a softwarové vybavení či komponenty, včetně všech souvisejících licencí a služeb potřebných k zavedení integrační platformy v prostředí zadavatele, které nejsou součástí provozního prostředí zadavatele (Zadavatelem poskytovaná provozní infrastruktura je uvedena v kapitole 4. Provozní infrastruktura.) tak, aby dodávka tvořila funkční celek (např. databázový systém a další případné specifické systémové komponenty);

• provede instalaci řešení v prostředí zadavatele, a to jak na testovací prostředí, tak na produkční prostředí;

• naimplementuje ověřovací úlohu (jedno funkční propojení, specifikované v rámci zpracování analýzy prostředí a cílového konceptu implementace);

• otestuje řešení a zajistí podporu při akceptačním testování;

• provede úvodní technické konzultace pro pracovníky zadavatele (školení administrátorů);

• vypracuje a dodá kompletní dokumentaci;

• zajistí do stanoveného termínu bezplatnou licenční maintenance dodanou jako součást licence.

3. Dodání a implementace systému

3.1. Analýza prostředí a tvorba cílového konceptu implementace

Dodavatel provede analýzu prostředí zadavatele a zpracuje cílový koncept implementace, který bude součástí dokumentace skutečného provedení.

Zadavatel poskytne dodavateli potřebnou součinnost. Dodavatel zohlední při zpracování veškeré připomínky zadavatele.

Součástí analýzy bude specifikace ověřovací úlohy v součinnosti dodavatele a zadavatele (jedno funkční propojení).

Vytvořený cílový koncept implementace bude odsouhlasen zadavatelem.

3.2. Zprovoznění integrační platformy

Po odsouhlasení cílového konceptu zadavatelem provede dodavatel vlastní implementaci řešení – dodá všechny licence a komponenty (softwarové komponenty, aplikačních softwarové moduly) potřebné pro provoz řešení s využitím všech funkcionalit dodávaného řešení, provede instalace včetně konfigurace a zprovozní integrační platformu v prostředí zadavatele.

Provozní infrastrukturu poskytuje zadavatel.

Dodávku, instalaci a konfiguraci komponent integrační platformy zajišťuje dodavatel.

Součástí zprovoznění je i dodavatelem provedené školení administrátorů a předání kompletní dokumentace k informačnímu systému dle specifikace v souboru „Požadavky na informační systém – IntegracniPlatforma.xlsx“

Zadavatelem bude potvrzeno zprovoznění integrační platformy na základě předvedení funkčnosti komponent integrační platformy s tím, že již musí být provedeno zaškolení administrátorů a předána kompletní dokumentace.

3.3. Implementace ověřovací úlohy, testování

Po potvrzení zprovoznění integrační platformy zadavatelem bude ověřena funkčnost integrační platformy jako middleware.

Dodavatel realizuje na testovacím prostředí implementaci API rozhraní pro vybrané aplikace a jeho otestování v celém rozsahu (jednoho funkčního propojení, specifikovaného v rámci analýzy prostředí a tvorby cílového konceptu implementace) a dodá testovací scénáře pro akceptační testování s tím, že realizaci smoke testů provede dodavatel v součinnosti se zadavatelem.

Po úspěšném akceptačním testování dodavatele ve spolupráci se zadavatelem bude vše dodavatelem nasazeno na produkční prostředí zadavatele.

Zadavatelem bude provedena akceptace na základě vyhodnocení funkční živé ukázky realizované integrace a realizovaných smoke testů; nebude-li zadavatelem uvedeno jinak, tak nad živými daty bez jejich mockování (na základě výsledku ověřovací úlohy).

3.4. Licenční maintenance včetně provedení aktualizace

Dodavatel zajistí do stanoveného termínu bezplatnou licenční maintenance (Service Pack, Patch, Hot Fix, Update, Upgrade) do stanoveného termínu jako součást licence.

K datu uvedení do provozu první funkční služby/propojení dodavatel informuje zadavatele o uvolnění programových oprav a úprav; aktuální, nové verze výrobcem a provede aktualizaci (implementace a instalace) všech komponent integrační platformy, analogickým způsobem jako v případě poskytování podpory, která je specifikována v souboru „Katalog služeb – Integrační platforma.docx“.

4. Provozní infrastruktura

Řešení musí být postavené na virtuálních serverech v on-premise prostředí a musí fungovat za následujících podmínek:

Virtualizační platforma: VMWare (není součástí předmětu plnění, poskytne zadavatel)

Operační systémy: MS Windows Server nebo Linux (Debian/Ubuntu) v aktuálních a podporovaných verzích (není součástí předmětu plnění, poskytne zadavatel)

Preferovaná databáze: MS SQL Server v aktuální a podporované verzi (uvedená databáze není součástí předmětu plnění, poskytne zadavatel)

V případě, že řešení bude vyžadovat jiný typ databáze, je dodavatel povinen ji zahrnout jako součást předmětu plnění, dodat a naimplementovat spolu s informačním systémem integrační platformy, blíže specifikovat a zahrnout do nabídkové ceny řešení (položka „Související systémové softwarové vybavení či komponenty, včetně všech souvisejících licencí a služeb potřebných k zavedení a provozu IP“), a to včetně školení zaměstnanců zadavatele a zajištění plné provozní podpory L2, L3 úrovně dodavatelem.

V případě, že řešení bude vyžadovat jakékoliv jiné související systémové softwarové vybavení či komponenty včetně licencí a služeb potřebných k zavedení a provozu integrační platformy (např. verzovací nástroj, …), je dodavatel povinen je zahrnout jako součást předmětu plnění, dodat a naimplementovat spolu s informačním systémem integrační platformy, blíže specifikovat a zahrnout do nabídkové ceny řešení (položka „Související systémové softwarové vybavení či komponenty, včetně všech souvisejících licencí a služeb potřebných k zavedení a provozu IP“), a to včetně školení zaměstnanců zadavatele a zajištění plné provozní podpory L2, L3 úrovně dodavatelem.

Maximální dostupné systémové prostředky (provozní servery, včetně testovacích serverů):

RAM: max 92 GB

vCPU: max 24

diskové úložiště: max 700 GB

Dodavatel definuje ve své nabídce požadavky na systémy a požadavky na zdroje virtuálních serverů

provozovaných ve virtuální infrastruktuře zadavatele:

• velikost paměti,

• počet virtuálních procesorů,

• velikost a strukturu diskového uložiště pro ukládání dat.

5. Požadavky na podporu systému

Požadavky na podporu naimplementovaného informačního systému integrační platformy jsou definovány v souboru „Katalog služeb – Integrační platforma.docx“.

Dodavatel, pokud není výrobcem, musí být oprávněn poskytnout licenční podporu včetně L3 technické podpory zajištěné výrobcem software.

6. Lhůty pro dodání jednotlivých částí zakázky

Lhůty pro dodání zakázky jsou definovány formou začátku, doby trvání a konce jednotlivých částí takto:

Části zakázky	Začátek	Doba trvání	Konec
Dodání informačního systému integrační platformy
Analýza prostředí a tvorba cílového konceptu implementace	T1 datum nabytí účinnosti smlouvy	D1 2 týdny	T1 + D1
Zprovoznění integrační platformy (dodání, instalace, zprovoznění integrační platformy splňující všechny požadavky v prostředí zadavatele)	T2 = T1 + D1 datum odsouhlasení cílového konceptu implementace	D2 4 týdny	T2 + D2
Implementace ověřovací úlohy (jednoho funkčního propojení, specifikovaného v rámci analýzy prostředí a zpracování cílového konceptu implementace), akceptační testování, školení a dodání kompletní dokumentace	T3 = T2 + D2 datum potvrzení zprovoznění integrační platformy	D3 2 týdny	T3 + D3 datum akceptace implementace
Bezplatná licenční podpora a L3 technická podpora výrobcem dodaná jako součást licence	T4 = T3 + D3 datum akceptace implementace (tj. dodání informačního systému)	D4 od T4 do konce následujícího kalendářní roku	31.12.2024
Vývoj integračních služeb/propojení a technické konzultace k dodanému informačnímu systému
Vývoj integračních služeb/propojení a technické konzultace	T5 do 30 dní od data akceptace	D5 dle pracnosti	T5 + D5

	jednotlivých objednávek zadavatele	objednaných služeb
Servisní podpora k dodanému informačnímu systému integrační platformy
Pilotní provoz (provozní podpora k dodanému informačnímu systému integrační platformy)	T6 datum akceptace uvedení do provozu prvního funkčního propojení	D6 12 měsíců	T6 + D6
Licenční podpora a L3 technická podpora výrobcem (po ukončení bezplatné licenční podpory)	01.01.2025	kalendářní rok	31.12.2025

7. Exit strategie

Dodavatel je povinen předat kompletní elektronickou kopii veškeré dokumentace, kterou vytvořil v rámci svého plnění s tím, že bude zaktualizována tak, aby odrážela stav k termínu ukončení plnění. Součástí dokumentace musí být i informace nutné k prodloužení licence, provádění aktualizací a dalších činností, které v rámci servisu zajišťoval dodavatel.

Dodavatel předá všechna hesla, šifrovací klíče, certifikáty a další autentizační prostředky, které umožňují administrátorský přístup k veškerým datům, databázím, systémům a aplikaci, případně k dalším technickým prostředkům využívaným pro potřeby plnění jeho služeb, nejpozději k datu ukončení plnění.

Dodavatel do 1 měsíce od doručení požadavku zadavatele zpracuje dokument s plánem ukončení plnění, který bude popisovat dopady ukončení plnění na zadavatele, a identifikaci a zhodnocení souvisejících rizik, jejich zhodnocení a návrh jejich eliminace a harmonogram činností ukončení či přechodu systému.

Součástí dokumentu bude i popis způsobu předání kompletní elektronické kopie veškeré dokumentace a způsob předání všech hesel, šifrovacích klíčů, certifikátů a dalších autentizačních prostředků.

Dodavatel na vyžádání poskytne školení pro administrátory na straně objednatele a pro administrátory nového poskytovatele služeb.

Dále je dodavatel povinen protokolárně vymazat nebo jinak zlikvidovat veškerá data či uživatelské údaje, které mu byly předány, a to dle zadavatelem písemně stanovených pokynů a lhůt.

Veškerá výše uvedená součinnost v rámci exitu bude poskytnuta bezúplatně.

Dodavatel se zavazuje poskytnout veškerou vyžádanou potřebnou součinnost a informace:

• při přechodu na jiný informační systém;

• při ukončení provozu, případně při jeho dalším obnovení;

• při jednání za účelem plynulého a řádného převedení všech činností spojených s poskytováním servisních služeb nebo vývoje na nového poskytovatele těchto služeb

s tím, že tato vyžádaná součinnost v rámci exitu bude poskytnuta oproti objednávce zadavatele s částkou vypočítanou na základě požadovaného součtu člověkodní součinnosti a ceny za MD v max. výši jednotkové ceny za MD, kterou dodavatel uvedl v nabídce k dodání informačního systému integrační platformy za

„Vývoj integračních služeb/propojení a technické konzultace“.

Specifikace požadavků na dodávku "Integrační platformy"
Specifikace požadavků						Povinné informace na doplnění od účastníků veřejné zakázky		Hodnocení			Povinné informace na doplnění od vybraného účastníka veřejné zakázky (do nabídky se nevyplňuje; až vybraný uchazeč na písemnou výzvu doloží - viz dikce bodu 10 ve Výzvě k podání nabídek
ID	Typ požadavku	Oblast	Požadavek	Požadováno v DEMO	Priorita	Způsob vypořádání (výběr z hodnot)	Způsob ověření pokrytí požadavku (výběr z hodnot)	Bodování požadavků	Prověření splnění požadavků v DEMO/v dokumentaci	Poznámky k hodnocení	Detailní popis řešení požadavku (jak přesně je v nabízeném produktu řešeno)
Req_001	Funkční	Api gateway	Z hlediska API gateway musí řešení obsahovat komponentu pro centrální vystavení mikroslužebních endpointů.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení obsahuje API management integrovaný nástroj WSO2 API Management, který umožňuje centrální vystavení mikroslužebních endpointů (z dokumentace 1.1 Základní architektonické overview, 1.2 Technolgický stack platformy), detail xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxx-xxxxxxx/xxxx- architecture/ - API Manager, API Gateway Layer	Dodána dokumentace k nabízenému systému.
Req_002	Funkční	Api gateway	Z hlediska API gateway se komponenta chová jako reverzní proxy.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Standardní funkcionalita API managementu (integrovaný nástroj WSO2 API Management) - příjímá všechna volání rozhraní (z dokumentace 1.1 Základní architektonické overview, 1.2 Technolgický stack platformy) Choreo Connect uses the Envoy Proxy as the core component for traffic routing. xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxx-xxxxxxx/xxxx-xxxxxxxxxxxx/#xxx-xxxxxxx	Dodána dokumentace k nabízenému systému.
Req_003	Funkční	Api gateway	Z hlediska API gateway komponenta obsahuje/podporuje funkčnosti jako: - routování komunikace mezi vystavenou službou a mikroslužebním endpointem, - authentifikace a autorizace žadatele o konzumaci služby, - katalog služeb (service repository), - konfigurace služeb (service configuration).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Funkcionalita API management integrovaného nástroje WS02 API Management (z dokumentace 1.2 Technolgický stack platformy, 1.3 Service Designer, 1.4 Service Repository): xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxx-xxxxxxx/xxxx-xxxxxxxxxxxx/#xxx-xxxxxxx xxxxx://xxx.xxxxxxx.xx/xxx/xxx.xxxxxx.xxxxx/xxxxx-xxx/xxxxxx/xxxxx.xxxx - Choreo Connect comprises three components: Router, Enforcer, and Adapter. The Router is the component in charge of directing traffic from various clients to the intended destination (service). - The API Gateway does the JWT token validation by validating the signature, issuer, expiry time, and subscription. The Key Manager is the identity provider for WSO2 API Manager and acts as the Secure Token Service (STS). WSO2 API Manager supports OAuth 2.0, Basic Auth, Mutual SSL as well as API-Key based authentication mechanisms. - Jako katalog služeb v řešení slouží komponenta Service Repository. - Na konfiguraci služeb je komponenta Service Designer, která využívá API komponenty Apache Camel.	Dodána dokumentace k nabízenému systému.
Req_004	Funkční	Api gateway	Z hlediska API gateway komponenta musí umožňovat pracovat v centrálním i distribuovaném režimu: - centrální režim pro vystavení mikroslužebních endpointů/služeb dalším konzumentům/systémům, - distribuovaný model pro použití instancí Api gateway jako orchestrátorů vnitřní komunikace konkrétního systémů/řešení.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Standardní funkcionalita API managementu integrovaného nástroje WS02 API Management (z dokumentace 1.2 Technolgický stack platformy, 1.3 Service Designer, 1.4 Service Repository) xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxx-xxxxxxx/xxxx-xxxxxxxxxxxx/#xxx-xxxxxxx - Choreo Connect comprises three components: Router, Enforcer, and Adapter. The Router is the component in charge of directing traffic from various clients to the intended destination (service). - Micro Integrator is an event-driven, standards-based messaging engine that can work like an Enterprise Service Bus. Micro Integrator supports message routing, message transformations, and other types of messaging use cases.	Dodána dokumentace k nabízenému systému.
Req_005	Nefunkční	Architektura	Řešení je koncipováno jako integrační middleware.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Jádro integrační platformy jako integračního midleware tvoří Apache Camel, který slouží jako integrační framework, který obsahuje velké množství komponent, pro integrace využívá "Enterprise Integration Patterns" - design, build a deploy integračních služeb (z dokumentace 1.1 Základní architektonické overview, 1.2 Technolgický stack platformy) a umožňuje vytváření custom component pro vytváření integračních scénářů. xxxxx://xxxxx.xxxxxx.xxx/xxxxx-xxxx/ xxxxx://xxxxx.xxxxxx.xxx/xxxxx-xxxx/xxxxxxxxx/xxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_006	Nefunkční	Architektura	Řešení je centrálním orchestračním prvkem cílové aplikační architektury a možňuje orchestraci služeb.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Jako komponenta pro orchestraci služeb vrámci řešení slouží Service Designer, který umožňuje design workflow služeb, deploy služeb, testování služeb. Service Designer je nadstavbou nad Apache Karavan, který poskytuje všechny komponenty Apache Camel - viz Req_005 (z dokumentace 1.1 Základní architektonické overview, 1.2 Technolgický stack platformy, 1.3 Service Designer).	Dodána dokumentace k nabízenému systému.
Req_007	Nefunkční	Architektura	Řešení obsahuje master systémy pro komunikační patterny mezi aplikačními doménami a jejich systémy.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponent WSO2 API Management a Apache Camel umožňuje komunikaci přes standardní adaptéry protokolů a různý charakter integrace (synchronní a asynchronní, request a response, …). V rámci modulu Service Designer je možné nastavovat protokol interfacu, interní APIM, ... (v dokumentaci 5 Services).	Dodána dokumentace k nabízenému systému.
Req_008	Nefunkční	Architektura	Řešení obsahuje vzorové definice integračních scénářů, obsahu zpráv a jejich struktur.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Řešení s použitím komponent Apache Camel umožňuje využití např. RouteTemplates pro definici struktur pro plnění parametrů pro integrace (Ze šablony a parametrů je vytvořená integrace.). xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxx-xxxxxxxx.xxxx PŘEDVEDENO v rámci DEMO: ANO Předvedeno v rámci ukázky komponenty pro design služeb - modelování integračního scénáře (tvorba routy, možnost kopírování routy a následné úpravy).	Ukázka v DEMO
Req_009	Nefunkční	Architektura	Řešení by mělo být založeno na loosely coupled architektuře	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Služby jsou postavené jako samostatné komponenty (z dokumentace 5 Services).	Dodána dokumentace k nabízenému systému.
Req_010	Nefunkční	Architektura	Součástí řešení je i dokumentace obsahující logické, komponentní i fyzické architektury jednotlivých částí a architektonických vrstev integrační platformy.	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	V dokumentaci nalezena ukázka, ve které je pouze základní architektonické overview a technologický stack platformy. Lze ověřit až při akceptaci!!!: V rámci předvedení DEMO verze k ověření bylo potvrzeno, že toto skutečně bude dodáno v rámci implementace jako součást dokumentace.	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_011	Nefunkční	Architektura	Řešení musí zajistit dohodnuté komunikační mapování mezi dvěma a více integračními stranami.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Předvedeno v DEMO verzi v rámci ukázky komponenty pro design služeb - modelování integračního scénáře (možnost mít ve scénáři více poskytovatelů, více consumerů) včetně ukázky nastavení poskytovatelů a consumerů v administraci - modul "Systems".	Ukázka v DEMO
Req_012	Nefunkční	Architektura	Architektura musí být modulární s oddělitelným plně samostatně funkčním základem řešení a vyvíjených funkcionalit (jednotlivé komponenty musí být nezávislé např. vystavené služby, logování, tvorba služeb, … tak, aby byl zajištěn provozní běh/funkčnost integrační platformy i v případě, že se vyskytne chyba na některé komponentě).	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	Architektura je modulární: tvorba služeb je v modulu "Service Designer", deployment je v modulu "Service Repository", logování a monitoring je zaintegrováno v systému Grafana, správa a zabezpečení secrets je v systému HashiCorp Vault, … (průřez z celé dokumentace "Uživatelská dokumentace").	Dodána dokumentace k nabízenému systému.
Req_013	Nefunkční	Architektura	Komponentní architektura řešení musí být koncipována modulárně, popř. mikroservisně tak, aby jednotlivé komponenty byly samostatně deployovatelné, škálovatelné a testovatelné.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponenty Apache Camel, využívá "Enterprise Integration Patterns" - design, build a deploy integračních služeb (z dokumentace 1.1 Základní architektonické overview, 1.2 Technolgický stack platformy) a funkčnosti komponenty Service Repository je postavená tak, že z jednotlivých integračních scénářů vytváři samostatné služby, které umožňuje samostatně deployovat, škálovat a testovat (z dokumentace 1.4 Service Repository, 5.1 Modul "Service Repository"). xxxxx://xxxxx.xxxxxx.xxx/xxxxx-xxxx/	Dodána dokumentace k nabízenému systému.
Req_014	Nefunkční	Architektura	Funkční celky jsou v samostatných komponentách (popište).	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Řešení obsahuje tyto funkční celky: Service Designer, Service Repository, API Management, Integrační služba, Nofification engine, EFG Elastic Search Fluented Grafana (z dokumentace 1.1 Základní architektonické overview).	Dodána dokumentace k nabízenému systému.
Req_015	Nefunkční	Architektura	Řešení umožňuje integrační služby samostatně deployovat, škálovat (možnost spustit současně více instancí jedné služby) a testovat.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Řešení umožňuje v rámci komponenty Service Repository validaci údajů služby, validaci syntaxy služby, sestavit balíček služby, vybrat prostředí pro deploy, provést deploy, nastavit způsob testování, otestovat službu (z dokumentace 1.4 Service Repository). Dále by nastavování počtu běhu instancí mělo být možné na základě řešení postaveného na kuberneties přímo ve vybraném nástroji pro správu Kuberneties. PŘEDVEDENO v rámci DEMO: ANO/NE V rámci požadavku na předvedení "Komponenty pro automatický build a nasazení (deployment)" bylo ukázáno řešení v rámci komponenty Service Repository pro automatický build a následný deployment na vybrané prostředí včetně otestování služby přes SoapUI s následným zobrazením výsledku v logu, který se zobrazuje v systému Grafana. V rámci deploymentu se v rámci Integration Service Deployment v parametrech nastavuje počet PODs (počet běhů instací jedné služby).	Ukázka v DEMO

Req_016	Nefunkční	Architektura	Architektura umožňuje budoucí rozšiřování jednotlivých integračních kompetencí/funkcionalit a integraci nových modulů a funkcionalit.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Architektura je postavena na Integration Microservice Technology (Apache Camel, …), která umožňuje integrovat externí moduly dle potřeb. xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxx-xxxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_017	Nefunkční	Architektura	Řešení musí splňovat pravidla autentizace koncového uživatele ale i systému.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Funkcionalita API management integrovaného nástroje WS02 API Management má komponetu Key Manager, který poskytuje úkony jako Secure Token Service (STS) - podporuje: OAuth 2.0, Basic Auth, Mutual SSL i API-Key based authentication mechanisms. Dále je v řešení použitá komponenta HashiCorp Vault pro správu a zabezpečení citlivých dat a informací. (z dokumentace 1.2 Technologický stack platformy, 4 Administration) PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Konfigurace (prostředí, uživatelů)" byl ukázan modul „Users“ v administraci s možností nastavení rolí pro uživatele (leader, analyst, deployer, admin) s doplňující informací, že autentizace se nastavuje v Keycloak (ukázáno pouze přihlášení), při ověřování Req_032 v dokumentaci ke Kecloak zjištěno, že součástí je nastavení autentizace (ověřování napojení na AD, LDAP). A dále bylo předvedeno nastavení zabezpečení, s výběrem typu volání služby: zabezpečené, basic (user + heslo), certifikáty, předvedení vytvoření basic certifikátu, ukázání sdílených secrets pro více služeb.	Ukázka v DEMO
Req_018	Nefunkční	Architektura	Řešení musí podporovat autorizační skupiny, řešené externím identity managementem.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení PHinTegra obsahuje správu uživatelů, pro zakládání uživatelů se využívá systém Keycloak, kde musí být nejprve vytvořen uživatelský přístup a přidělena příslušná oprávnění (z dokumentace 4.2 Modul "Users").	Dodána dokumentace k nabízenému systému.
Req_019	Nefunkční	Architektura	Součástí řešení je i dokumentace designu tak, aby byl zřejmý vztah jednotlivých komponent včetně komponent infrastruktury (frontend servery, backend servery, loadballancery, databáze atd.).	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	V dokumentaci nalezena ukázka, ve které je pouze základní architektonické overview a technologický stack platformy. Lze ověřit až při akceptaci!!!: V rámci předvedení DEMO verze k ověření bylo potvrzeno, že toto skutečně bude dodáno v rámci implementace jako součást dokumentace.	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_020	Nefunkční	Architektura	Součástí řešení je i dokumentace designu tak, aby byl zřejmý způsob řešení high availability, disaster recovery a datové architektury.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V dokumentaci nalezena ukázka, ve které je pouze základní architektonické overview a technologický stack platformy. Lze ověřit až při akceptaci!!!: V rámci předvedení DEMO verze k ověření bylo potvrzeno, že toto skutečně bude dodáno v rámci implementace jako součást dokumentace.	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_021	Nefunkční	Architektura	Součástí řešení je i dokumentace designu tak, aby byl zřejmý design infrastrukturních komponent a umístění aplikačních komponent v ní.	NE	Nízká	Nativní součást	Ověření v DEMO	3	Splňuje	V dokumentaci nalezena ukázka, ve které je pouze základní architektonické overview a technologický stack platformy. Lze ověřit až při akceptaci!!!: V rámci předvedení DEMO verze k ověření bylo potvrzeno, že toto skutečně bude dodáno v rámci implementace jako součást dokumentace.	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_022	Nefunkční	Architektura	Součástí řešení je i dokumentace designu tak, aby byly zřejmé protokoly a porty pro komunikaci mezi jednotlivými aplikačními komponentami.	NE	Nízká	Nativní součást	Ověření v DEMO	3	Splňuje	V dokumentaci nalezena ukázka, ve které je pouze základní architektonické overview a technologický stack platformy. Lze ověřit až při akceptaci!!!: V rámci předvedení DEMO verze k ověření bylo potvrzeno, že toto skutečně bude dodáno v rámci implementace jako součást dokumentace.	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_023	Nefunkční	Architektura	Součástí řešení je i dokumentace designu tak, aby bylo zřejmé, jak vypadají topologie jednotlivých prostředí.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_024	Nefunkční	Architektura	Síťové bezpečnostní prvky zajistí infrastruktura zadavatele a je nutné uvést požadavky dodavatele na tyto prvky a uvést je v dokumentaci designu jako infrastrukturní topologii.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_025	Nefunkční	Architektura	High Availability - Multi-tenancy Řešení musí umožňovat funkci jako multi-tenant řešení. Primárně míříme na oddělení interního/externího provozu, chceme počet tenantů/kontextů udržet na spravovatelné míře.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Je podporováno - definice interní APIM, externí APIM (v dokumentaci 5 Services), definice zákazníků (v dokumentaci 4. Administration). PŘEDVEDENO v rámci DEMO: ANO Předvedeno v rámci ukázky konfigurace v administraci - modul Customers, Environment configuration.	Ukázka v DEMO
Req_026	Nefunkční	Architektura	Řešení je připraveno na service mesh. Řešení by mělo podporovat integraci např. s Istio pro propojení a komunikaci mezi kontejnerovým prostředím/distribovanými aplikacemi založenými na mikroslužbách a API managementem.	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	Řešení je "kontejnerizační platforma", založená na Kubernetes, kde by mělo být podporováno. Z dodané popisu: Architektura PHinTegra je navržena na kontejnerovém řešení, tedy je možno propojit na například ISTIO, které zajistí možnost provozovat integrační platformu v plněhodnotném service mesh přístupu.	Dodána dokumentace k nabízenému systému.
Req_027	Nefunkční	Architektura	Systém dodávaný dodavatelem bude navržen tak, že nemá tzv. "single point of failure".	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	Tím, že jde o "kontejnerizační platformu", tak je SPoF minimalizován. Nemělo by dojít k tomu, že selhání jedné komponenty způsobý selhání celého systému. (z dokumentace 1.1 Základní architektonické overview).	Dodána dokumentace k nabízenému systému.
Req_028	Funkční	Bezpečnost	Řešení musí splňovat zabezpečenou integrační komunikaci pro všechny druhy komunikací (tls, ssl, certifikáty authentifikace/autorizace, šifrování zpráv).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Funkcionalita API management integrovaného nástroje WS02 API Management (z dokumentace 1.2 Technolgický stack platformy) podporuje zabezpečenou integrační komunikaci: xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxx-xxxxxxx/xxxx-xxxxxxxxxxxx/#xxx-xxxxxxx xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxxxxxx-xxx-xxxxx/xxxxx/xx- setup/security/securing_management_api/ xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxxxxxx-xxx-xxxxx/xxxxx/xx- setup/security/importing_ssl_certificate/ xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxxxxxxxx/xxxxxxx-xxxx/xxxxxxx-xxxxxxx-xxxx/xxxxxxx-xxxxxxx- v1/service-catalog-v1/#section/Authentication The API Gateway does the JWT token validation by validating the signature, issuer, expiry time, and subscription. The Key Manager is the identity provider for WSO2 API Manager and acts as the Secure Token Service (STS). WSO2 API Manager supports OAuth 2.0, Basic Auth, Mutual SSL as well as API-Key based authentication mechanisms.	Dodána dokumentace k nabízenému systému.
Req_029	Funkční	Bezpečnost	Řešení musí splňovat jednoznačně identifikovatelné a trasovatelné zprávy v rámci jednotlivých kroků zpracování na integrační platformě (id zprávy, business id dotčeného procesu, poskytovatel(é), konzument(i), transparentní mapování).	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Logování volání služeb je v Grafana. PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Logování (transakční log) a journaling (auditní log)" byl v rámci předvedení testování ukázán transakčního log integrační služby včetně jednotlivých kroků (zpracován request, vrácen responce, trasování) v nástroji Grafana.	Ukázka v DEMO
Req_030	Funkční	Bezpečnost	Řešení musí splňovat auditní log pro zpětné dohledání citlivých zpráv až na úroveň obsahu zprávy.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Logování volání služeb je v Grafana. PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Logování (transakční log) a journaling (auditní log)" byla ze Service Repository ukázána možnost zobrazení auditního logu ke službám a následně z administrace ukázána možnost zobrazení auditního logu k vybranému uživateli. Dále pak rámci předvedení auditního logu byl ukázán i detail obsahující všechny požadované atributy včetně dalších (prostředí, …).	Ukázka v DEMO
Req_031	Funkční	Bezpečnost	Z pohledu bezpečnosti musí řešení striktně oddělovat interní komunikaci/integraci směrem do/z interní sítě zadavatele a externí komunikaci směrem do/z public internetu tak, aby bylo minimalizováno riziko vnějšího útoku přes vystavené služby a komponenty do public internetu.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci modulu Service Designer se pro služby vždy nastavuje interní APIM nebo externí APIM (v dokumentaci 5 Services).	Dodána dokumentace k nabízenému systému.
Req_032	Funkční	Bezpečnost	Řešení musí podporovat jednoznačnou autentifikaci a autorizaci koncových uživatelů, ale i systémů včetně možnosti napojení na AD, LDAP.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Řešení PHinTegra obsahuje správu uživatelů, pro zakládání uživatelů se využívá systém Keycloak, kde musí být nejprve vytvořen uživatelský přístup a přidělena příslušná oprávnění (z dokumentace 4.2 Modul "Users"). PŘEDVEDENO v rámci DEMO: ANO Použití řešení Keycloak (ukázáno přihlášení do Keycloak) , které by mělo podporovat propojení s AD, LDAP. (User Federation - Sync users from LDAP and Active Directory servers.) DOPROVĚŘENO v dokumentaci – Keycloak podporuje od verze 23.0.1 xxxxx://xxx.xxxxxxxx.xxx/xxxx/xxxxxx/xxxxxx_xxxxx/	Ukázka v DEMO

Req_033	Funkční	Bezpečnost	SSO podpora Řešení musí umožňovat autentizaci (ověření identity uživatele služeb nebo původce zprávy) uživatele pomocí SAML tokenu (SAML je standard založený na XML poskytující mechanismus pro výměnu autentizačních a autorizačních dat mezi zúčastněnými stranami, tj. poskytovatelem služeb a poskytovatelem identity. Funguje na principu „prosazení“ důvěry, tedy aplikace může prosadit, že jde o určitého uživatele a ten má určitá privilegia.) a také Oauth 2.0. Podpora: - XML/SOAP - HTTP	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení Keycloak podporuje Single-Sign On. Keycloak is based on standard protocols and provides support for OpenID Connect, OAuth 2.0, and SAML. (z dokumentace 4.2 Modul "Users"). xxxxx://xxx.xxxxxxxx.xxx/ xxxxx://xxx.xxxxxxxx.xxx/xxxxxxxxxxxxx xxxxx://xxx.xxxxxxxx.xxx/xxxx/xxxxxx/xxxxxxxx_xxxx/xxxxx.xxxx xxxxx://xxx.xxxxxxxx.xxx/xxxxxx/xxxxx	Dodána dokumentace k nabízenému systému.
Req_034	Funkční	Bezpečnost	SSO Oauth 2.0 podpora Řešení musí umožňovat autentizaci uživatele pomocí Oauth 2.0 tokenu nebo vyšší. Podpora: - JSON - HTTP - HTTPS	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení Keycloak podporuje SSO Oauth 2.0. Keycloak is based on standard protocols and provides support for OpenID Connect, OAuth 2.0, and SAML. (z dokumentace 4.2 Modul "Users"). xxxxx://xxx.xxxxxxxx.xxx/ xxxxx://xxx.xxxxxxxx.xxx/xxxxxxxxxxxxx xxxxx://xxx.xxxxxxxx.xxx/xxxx/xxxxxx/xxxxxxxx_xxxx/xxxxx.xxxx xxxxx://xxx.xxxxxxxx.xxx/xxxxxx/xxxxx	Dodána dokumentace k nabízenému systému.
Req_035	Funkční	Bezpečnost	TLS - HTTP, HTTPS Spojení je možné zabezpečit pomocí HTTP autentizace (označení pro jednoduchou autentizaci při přístupu na webové stránky). Webový server vyzve pomocí protokolu HTTP přistupujícího klienta (typicky webový prohlížeč), aby poslal v rámci požadavku na stránku také autentizační informace (tj. jméno a heslo), včetně vynucení Podpora: - TLS/SSL HTTP , HTTPS - Basic/Digest/…	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Funkcionalita API management integrovaného nástroje WS02 API Management má komponetu Key Manager, který poskytuje úkony jako Secure Token Service (STS) - podporuje: OAuth 2.0, Basic Auth, Mutual SSL i API-Key based authentication mechanisms. Dále je v řešení použitá komponenta HashiCorp Vault pro správu a zabezpečení citlivých dat a informací. (z dokumentace 1.2 Technologický stack platformy, 4 Administration - Konfigurace prostředí, Nastavení zabezpečení systému, Modul "Vault", 5 Services - Internal/External APIM). xxxxx://xxxxxxxxx.xxxxxxxxx.xxx/xxxxx/xxxx/xxxx-xx-xxxxx xxxxx://xxxxxxxxx.xxxxxxxxx.xxx/xxxxx/xxxx/xxxxxxx/xxxxxxxxxx Note: This engine can use external X.509 certificates as part of TLS or signature validation. Verifying signatures against X.509 certificates that use SHA-1 is deprecated and is no longer usable without a workaround starting in Vault 1.12. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx- component.html#_component_option_sslCipherSuites (options)	Dodána dokumentace k nabízenému systému.
Req_036	Funkční	Bezpečnost	TLS - Certifikáty Spojení je možné zabezpečit pomocí certifikátů. Podpora: - X.509 Certifikaty (SSL/TLS) - CRL - OCSP - XKMS - mSSL (mutual 2-way SSL)	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Funkcionalita API management integrovaného nástroje WS02 API Management má komponetu Key Manager, který poskytuje úkony jako Secure Token Service (STS) - podporuje: OAuth 2.0, Basic Auth, Mutual SSL i API-Key based authentication mechanisms. Dále je v řešení použitá komponenta HashiCorp Vault pro správu a zabezpečení citlivých dat a informací. (z dokumentace 1.2 Technologický stack platformy, 4 Administration - Konfigurace prostředí, Nastavení zabezpečení systému, Modul "Vault", 5 Services - Internal/External APIM). xxxxx://xxxxxxxxx.xxxxxxxxx.xxx/xxxxx/xxxx/xxxx-xx-xxxxx xxxxx://xxxxxxxxx.xxxxxxxxx.xxx/xxxxx/xxxx/xxxxxxx/xxxxxxxxxx Note: This engine can use external X.509 certificates as part of TLS or signature validation. Verifying signatures against X.509 certificates that use SHA-1 is deprecated and is no longer usable without a workaround starting in Vault 1.12. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx- component.html#_component_option_sslCipherSuites (options)	Dodána dokumentace k nabízenému systému.
Req_037	Funkční	Bezpečnost	TLS - Session Tickets Spojení je možné zabezpečit pomocí session ticketů Podpora: - Session tickets přes Kerberos atd.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Funkcionalita API management integrovaného nástroje WS02 API Management má komponetu Key Manager, který poskytuje úkony jako Secure Token Service (STS) - podporuje: OAuth 2.0, Basic Auth, Mutual SSL i API-Key based authentication mechanisms. Dále je v řešení použitá komponenta HashiCorp Vault pro správu a zabezpečení citlivých dat a informací. (z dokumentace 1.2 Technologický stack platformy, 4 Administration - Konfigurace prostředí, Nastavení zabezpečení systému, Modul "Vault", 5 Services - Internal/External APIM). xxxxx://xxx.xxxxxxxxx.xxx/xxxxxxxx/xxxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx- component.html#_component_option_sslCipherSuites (options)	Dodána dokumentace k nabízenému systému.
Req_038	Funkční	Bezpečnost	Message level security - WS-Security Zprávy obsahující WS-Security (rozšíření protokolu SOAP pro použití zabezpečení na webové služby) mohou být dále zpracovány. Myšleno např. validace, parsing, atd.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponenty Apache Camel umožňuje rozšíření protokolu SOAP a zpracování zpráv i při použití WS-Security. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx-xxxxxxxxx.xxxx However, there are cases where streaming may not be appropriate or desired. Due to the streaming nature, invalid incoming XML may not be caught until later in the processing chain. Also, certain actions may require the message to be DOM parsed anyway (like WS-Security or message tracing and such) in which case the advantages of the streaming is limited. At this point, there are two ways to control the streaming: - Endpoint property: you can add "allowStreaming=false" as an endpoint property to turn the streaming on/off. - Component property: the CxfComponent object also has an allowStreaming property that can set the default for endpoints created from that component. xxxxx://xxxxx.xxxxxx.xxx/xxxxx-xxxxxxx/0.0.x/xxxxxxxxx/xxxxxxxxxx/xxx-xxxx.xxxx#xxxxxxxxxx-xxx- soap-usage-ws-specifications	Dodána dokumentace k nabízenému systému.
Req_039	Funkční	Bezpečnost	Message level security - XML Encryption Zprávy obsahující XML Encryption (specifikace, která se řídí doporučením W3C a která definuje, jak šifrovat obsah prvku XML) je možné dále zpracovávat (např. validace, transformace, parsing atd.). Podpora: - Encryption/Decryption	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponenty Apache Camel umožňuje generovat a validovat Xml signatures dle W3C standardu. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxxx-xxxxxx-xxxxxxxxx.xxxx xxxxx://xxx.x0.xxx/XX/xxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxx-0-xxxxxxxxx-xxxxx.xxxx#_xxx_xxxxxxxx_xxxxxxxxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxxxxxxxxxx/xxxxxxXXX-xxxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_040	Funkční	Bezpečnost	Message level security - XML Signatures Zprávy obsahující XML Signatures (syntaxe XML pro digitální podpisy) je možné dále zpracovávat (např. validace atd.). Podpora: - Creation/Validation - Encryption/Decryption	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponenty Apache Camel umožňuje generovat a validovat Xml signatures dle W3C standardu. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxxx-xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxxx-xxxxxx-xxxxxxxxx.xxxx xxxxx://xxx.x0.xxx/XX/xxxxxxx-xxxx/ xxxxx://xxx.x0.xxx/XX/xxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxx-0-xxxxxxxxx-xxxxx.xxxx#_xxx_xxxxxxxx_xxxxxxxxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxxxxxxxxxx/xxxxxxXXX-xxxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_041	Funkční	Bezpečnost	Session Management Řešení musí být schopné řídit platnost session. Bez platné session musí dojít k odmítnutí spojení daného uživatele. Podpora: - Validate - Create/Prolong/Terminate - Unauthorized/Unauthenticated Request/Access	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Komponenty v rámci Apache Camel mohou používat http včetně transportního protokolu. xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxx-xxxxxxx-xxxxxxxx.xxxx In this case the route could e.g. first do a login call, then some update calls and finally a logout call. If the session handling would be defined on route or CamelContext scopes this would seem to run, however under load parallel invocations of the route would share a single session, which could cause issues. If the session is defined on exchange scope, each invocation of the route will get a separate session, and the server can maintain a separate state for the different parallel invocations. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_042	Funkční	Bezpečnost	Session Management - JWT tokeny Řešení musí podporovat JWT tokeny (internetový standard pro vytváření dat s volitelným podpisem a / nebo volitelným šifrováním, zahrnující tzv. JSON, který uplatňuje určitý počet požadavků).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponenty Apache Camel podporuje JSON Web Tokens. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx- component.html#_component_option_authenticationType	Dodána dokumentace k nabízenému systému.

Req_043	Funkční	Bezpečnost	Pass-through forwarding a HTTP headers Řešení musí umožňovat předání požadavku do cílového systému (backendu) včetně potřebných činností jako je práce s hlavičkami, content-type a další.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponenty Apache Camel, funguje na principech "Enterprise Integration Patterns", které umožňuje posílání zpráv včetně jejich hlaviček až na koncový systém. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxx- component.html#_sending_messages_tofrom_a_sip_endpoint (z dokumentace 1.2 Technologický stack platformy) xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxx/xxxxxx-xxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_044	Funkční	Bezpečnost	IP address limitation Řešení musí umožnit omezit spojení na zadaný IP rozsah, případně musí umožňovat filtrovat spojení pomocí DNS filteringu.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci použití řešení API managementu (WSO2) lze provést omezení v rámci whitelistu. xxxxx://xxxx.xxxx.xxx0.xxx/xx/0.0.0/xxxxx/xxxx-xxxxxxxx/xxxxxxxxxxxx-xxxxxxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_045	Funkční	Bezpečnost	HTTP - Encoding Řešení musí umožňovat kontrolu obsahu zprávy pomocí specifikovaného kódování. Podpora: - Kontrola kódování - Vynucení specifického kódování	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení s použitím komponenty HTTP v rámci Apache Camel podporuje Content-Encoding, Encoding. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx-xxxx- component.html#_endpoint_query_option_bridgeEndpoint	Dodána dokumentace k nabízenému systému.
Req_046	Funkční	Bezpečnost	HTTP - Content Type Řešení musí umožňovat kontrolu a vynucení vráceného typu obsahu, Content Type.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Řešení s použitím komponenty HTTP v rámci Apache Camel podporuje Content-Type xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx-xxxx- component.html#_endpoint_query_option_bridgeEndpoint	Dodána dokumentace k nabízenému systému.
Req_047	Funkční	Bezpečnost	XML - Format Check Řešení musí umožňovat kontrolu formátu XML zpráv Podpora: - XML Schema - DTD - RELAX NG	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Popsáno v dokumentaci komponent Apache Camel. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxx-xxxxxxxxx.xxxx The Validation component performs XML validation of the message body using the JAXP Validation API and based on any of the supported XML schema languages, which defaults to XML Schema. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_048	Funkční	Bezpečnost	XML - Parsing Řešení musí umožnit ověření, zda zaslané XML může být validně parsováno.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Komponenty Apache Camel umožňují parsování xml. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxxx/xxxxxxxXxx-xxxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx/xxxx-xxx-xx-xxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_049	Funkční	Bezpečnost	XML - Limits Řešení musí umožňovat ověření existence smyček, velikosti elementů, hloubky zanoření, cyklických nebo nevalidních odkazů atd.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Použitá funkcionalita API managementu (integrovaný nástroj WSO2 API Management) má integrovaný Rate Limit včetně Throttling Limits pro API, Blacklisting a Whitelinsting Requests, Také v rámci řesení Apache Camel je v rámci Enterprise Integration Patterns umožněno nastavení throttlingu, dále je možnost využít komponenty pro circuit brake, využití custom validací, error handlers, komponenta pro validaci xml. xxxxx://xxxx.xxxx.xxx0.xxx/xx/0.0.0/xxxxx/xxxx-xxxxxxxx/xxxxxxx-xxxxxxxxxx-xxxxxx/ xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxxx-xxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxxXxxxxxx-xxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxx-xxxxxxx/0.0.x/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxx.xxxx#xxxxxxxxxx- bean-validator-usage-custom-validation-groups-in-native-mode xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxx- clause.html#_global_exception_policies_and_nested_error_handlers xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_050	Funkční	Bezpečnost	Threat protection - OWASP Řešení musí umožňovat ochranu proti typům útoků dle OWASP. Popište, vůči jakým útokům a v jakém rozsahu umožňuje řešení zajistit ochranu.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Bezpečnost použitého řešení Apache Camel zajišťuje tým ASF SECURITY TEAM, který řeší projekty na provni bezpečnosti. Vydává opravné patche, poskytuje informace, spolupracuje z pohledu bezpečnosti s třetími stranami, které dodávají komponenty. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxx/ xxxxx://xxxxxxxx.xxxxxx.xxx/xxxxxxxx/ xxxxx://xxxxx.xxxxxx.xxx/xxx-xxxx	Dodána dokumentace k nabízenému systému.
Req_051	Funkční	Bezpečnost	Passwords Řešení musí podporovat bezpečné/šifrované uložení hesel do bezpečných úložišť autentizačních tajemství (tzv. kryptografická úložiště).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V řešení je použita komponenta HashiCorp Vault pro správu a zabezpečení citlivých dat a informací (z dokumentace 1.2 Technologický stack platformy, 4.4 Modul "Vault").	Dodána dokumentace k nabízenému systému.
Req_052	Funkční	Bezpečnost	DoS prevention - Rate Throttling Řešení musí umožňovat omezení přístupu ke službě, pokud dojde k překročení stanovené kvóty. Podpora: - Počet požadavků - Objem komunikace - Nastavení na úrovni služby nebo množiny rozhraní	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Použitá funkcionalita API managementu (integrovaný nástroj WSO2 API Management) má integrovaný Rate Limit včetně Throttling Limits pro API. Také v rámci řesení Apache Camel je v rámci Enterprise Integration Patterns umožněno nastavení throttlingu. PHinTegra má v sobě integrován modul pro throttling pro vytváření kvót a jejich nasazení na vybraná prostředí, současně lze v rámci designu služeb nastavovat kvóty pro APIM s omezením na prostředí v rámci nasazování integrační služby (v dokumentaci 4.5 Modul "Throttling", 5.2 Modul "Service Designer" - APIM Quota). xxxxx://xxxx.xxxx.xxx0.xxx/xx/0.0.0/xxxxx/xxxx-xxxxxxxx/xxxxxxx-xxxxxxxxxx-xxxxxx/ xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxxx-xxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_053	Funkční	Bezpečnost	DoS prevention - Conditional Throttling Řešení musí umožňovat omezení přístupu ke službě, pokud dojde k překročení stanovené kvóty zvláštních událostí/kategorie (samostatně): Podpora: - Good/Invalid/Unauthorized Requests - Good/Invalid/Unauthorized Responses	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	V rámci použití řešení API managementu (WSO2) lze provést omezení v nastavení throttlingu. xxxxx://xxxx.xxxx.xxx0.xxx/xx/0.0.0/xxxxx/xxxx-xxxxxxxx/xxxxxxx-xxxxxxxxxx-xxxxxx/ xxxxx://xxxx.xxxx.xxx0.xxx/xx/0.0.0/xxxxx/xxxx-xxxxxxxx/xxxxxx-xxx-xxxxxxxxxx-xxxxxxxx/ xxxxx://xxxx.xxxx.xxx0.xxx/xx/0.0.0/xxxxx/xxxx-xxxxxxxx/xxxxxxxx-xxxxxx/xxxxxx-xxxxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_054	Funkční	Bezpečnost	Authorization - Assert Credentials Řešení musí umožňovat ověření, zda zaslaná zpráva patří uživateli, který prošel předchozí autentizací, případně jiné předpoklady z pohledu autorizace.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V řešení je použita komponenta HashiCorp Vault pro správu a zabezpečení citlivých dat a informací. Vytvořené secrets je pak možné nastavovat na jednotlivé customers, systems - providers, consumers i s vazbou na vybrané prostředí (z dokumentace 1.2 Technologický stack platformy, 4.1 Modul "Customers", 4.3 Modul "Systems", 4.4 Modul "Vault"). Vše se builduje v nadesignované integrační službě do výsledného API.	Dodána dokumentace k nabízenému systému.
Req_055	Funkční	Bezpečnost	API Access Control Řešení musí umožnit každé vystavené službě poskytnout konzumentovi vlastní individuální pár key/secret API.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	V rámci aplikace se pro konsumera nastavují secrets (v dokumentaci 4.3 Modul "Systems", Nastavení zabezpečení systému) PŘEDVEDENO v rámci DEMO: ANO Předvedeno v rámci ukázky API Managementu v administraci – modul Systems (nastavení „Consumer secrets“).	Ukázka v DEMO
Req_056	Funkční	Datové přenosy	Z hlediska datových přenosů řešení musí umožňovat řízené datové přenosy mezi poskytovatelem a konzumentem.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Funkčnost je podpořená komponentou "Service Designer" s podporou Apache Camel Routes (v dokumentaci 5.2 Modul "Service Designer" xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxx-xxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxx.xxxx PŘEDVEDENO v rámci DEMO: ANO Předvedeno v rámci ukázky komponenty pro design služeb v rámci modelování integračního scénáře.	Ukázka v DEMO
Req_057	Funkční	Datové přenosy	Z hlediska datových přenosů komponenta datových přenosů pracuje na principu ETL a případně ELT.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Bylo ukázáno v rámci komponenty pro design služeb v rámci modelování integračního scénáře v rámci nastavování routy s možností využití komponenty SFTP Source. Současně v Apache Camel je komponenta Quartz (Scheduler pro plánování datových přenosů). DOPROVĚŘENO v dokumentaci: The Quartz component provides a scheduled delivery of messages using the Quartz Scheduler 2.x. Each endpoint represents a different timer (in Quartz terms, a Trigger and JobDetail). xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx-xxxxxxxxx.xxxx	Ukázka v DEMO
Req_058	Funkční	Datové přenosy	Z hlediska datových přenosů komponenta umožňuje paralelní běhy zpracování	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Předvedeno v rámci konfigurace prostředí – ukázáno nastavení customers (multitenancy) a nastavení prostředí, nasazení různých verzí služeb na více prostředí.	Ukázka v DEMO

Req_059	Funkční	Datové přenosy	Z hlediska datových přenosů komponenta umožňuje dávkové zpracování a plánování dávkových úloh (scheduler) vč. definice a správy závislostí jednotlivých jobů. - Minimální takt běhu datových jobů je 5 minut	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Bylo ukázáno v rámci komponenty pro design služeb v rámci modelování integračního scénáře v rámci nastavování routy s možností využití komponenty SFTP Source. Současně v Apache Camel je komponenta Quartz (Scheduler pro plánování datových přenosů). DOPROVĚŘENO v dokumentaci: Pro časování (nastavní běhu) je definovaný parametr "cron". xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx-xxxxxxxxx.xxxx	Ukázka v DEMO
Req_060	Funkční	Datové přenosy	Z hlediska datových přenosů komponenta umožňuje vizuální modelování datových přenosů a transformací.	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty pro design služeb – nástroj pro návrh integračních služeb principem „drag & drop“ bylo předvedeno modelování služeb formou drag and drop modelování a nastavování v rámci detailů komponent.	Ukázka v DEMO
Req_061	Funkční	Datové přenosy	Z hlediska datových přenosů komponenta umožňuje rozšířené mapování a transformace pomocí vložení customly developed logiky/Java třídy/pseudokódu.	NE	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Předvedeno v rámci ukázky komponenty pro design služeb v rámci modelování integračního scénáře a přidávání route, kde lze na detailu využít okno se zdrojovým kódem a to editovat.	Ukázka v DEMO
Req_062	Funkční	Datové přenosy	Z hlediska datových přenosů musí být zajištěny konektory a technologie: - Datové vrstvy/RDBMS: Oracle DB, MSSQL, Postgre, MySQL, SAP XXXX DB - NonSQL: MongoDB, Cassandra - Web Services: SOAP, REST, Api GW endpoint - Application layer: JDBC, ODBC - File adaptery: SFTP storage	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty pro design služeb – nástroj pro návrh integračních služeb principem „drag & drop“ byla předvedena možnost přidání komponent, ověřeny všechny uvedené komponenty (pozn. pro SOAP komponenty CXF) a v ukázce nebyla k dispozici komponenta pro ODBC, DOPROVĚŘENO v dokumentaci: Pro načítání dat např. z excelu by měla místo ODBC být možné využít i komponentu JDBC nebo použít komponentu UNIVOCITY CSV (xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxxxxxxxxxx/xxxxxxxxx-xxx-xxxxxxxxxx.xxxx) nebo Apache POI library (xxxxx://xxx.xxxxxx.xxx/xxxxxxx/0.0/), dále je pravděpodobné, že se bude nabízet i jiné řešení.	Ukázka v DEMO
Req_063	Nefunkční	Dokumentace	Součástí dodávky je dodání provozní dokumentace popisující provádění nutných provozních činností.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_064	Nefunkční	Dokumentace	Součástí dodávky je dodání administrátorské dokumentace a příručka administrátora.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_065	Nefunkční	Dokumentace	Součástí dodávky je dodání dokumentace způsobu vývoje a zajištění bezpečnosti.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_066	Nefunkční	Dokumentace	Součástí dodávky je vypracování dokumentace skutečného provedení na základě šablony cílového konceptu.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_067	Nefunkční	Dokumentace	Součástí dodávky je vytvoření dokumentu enterprise architectury dodavatelem s tím, že zadavatel poskytne potřebnou součinnost.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_068	Nefunkční	Dokumentace	Součástí dodávky je příručka vývojáře řešení.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_069	Nefunkční	Dokumentace	Součástí dodávky jsou školící materiály.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_070	Nefunkční	Dokumentace	Součástí dodávky jsou testovací scénáře.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_071	Nefunkční	Dokumentace	Součástí dodávky je autorizační koncept řešení.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_072	Nefunkční	Dokumentace	S řešením je vypracován a předán Dokument Governance Integrační platformy.	NE	Nízká	Nativní součást	Dokumentace skutečného stavu implementace (lze ověřit až při akceptaci)	3	Splňuje	Lze prověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_073	Nefunkční	Infrastruktura	Hlavní části řešení Integrační platformy zejména pro integraci interních systémů musí být provozovatelné v on- premise prostředí zadavatele.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Část ukázky (služba na zjištění počasí k zadanému datu) byla realizována v systému jiného zákazníka, kde mají nasazeno v on-premise.	Ukázka v DEMO
Req_074	Nefunkční	Infrastruktura	Řešení umožňuje provoz na fyzické infrastruktuře.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Část ukázky (služba na zjištění počasí k zadanému datu) byla realizována v systému jiného zákazníka, kde mají nasazeno v on-premise.	Ukázka v DEMO
Req_075	Nefunkční	Infrastruktura	Řešení umožňuje infrastrukturní i aplikační škálování jednotlivých komponent přidáváním nových provozních nodů/uzlů/serverů.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Bylo ukázáno detailní architektonické overview, kdy je celé řešení kontejnerové. V rámci kontejnerového prostředí je nativní vlastností možnost škálovat (tzn. že je dáno použitou technologií řešení).	Ukázka v DEMO
Req_076	Nefunkční	Infrastruktura	Řešení umožňuje infrastrukturní i aplikační škálování jednotlivých komponent posilováním infrastrukturálních výpočetních kapacit (cpu, ram, storage, ...).	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO/NE Bylo ukázáno detailní architektonické overview, kdy je celé řešení kontejnerové. Díky kontejnerovému řešení a možnosti škálování, lze posilovat infrastrukturu potřebných způsobem (tzn. že je dáno použitou technologií řešení) - rozšiřování virtuálních serverů.	Ukázka v DEMO
Req_077	Nefunkční	Infrastruktura	Popište podporované infrastrukturní a aplikační komponenty.	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	Aplikační komponenty jsou popsány v dodatečně dodaném architekturním obrázku. Detailní infrastruktura virtualizace bude řešena v rámci analytické fáze při implementaci. Lze plně prověřit až při akceptaci v rámci dodané dokumentace!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_078	Nefunkční	Infrastruktura	Popište iniciační návrh sizingu infrastrukturních komponent (cpu, ram, storage, požadavky na iops, ...).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Bylo dodáno v rámci doplňujících informací k řešení v extra záložce "doporučený sizing": DNS názov RAM GB CPU DISK Jump host Load balancer Registry registry 8 4 300 Master nody master1 4 2 40 master2 4 2 40 master3 4 2 40 Worker nody worker1 16 4 120 worker2 16 4 120 worker3 16 4 120 worker4 16 4 120 worker5 16 4 120 worker6 16 4 120 worker7 16 4 120 worker8 16 4 120 DB nody db1 8 4 100 db2 8 4 100 db Virtuálna IP adresa pre prístup do DB	Dodána dokumentace k nabízenému systému.
Req_079	Nefunkční	Infrastruktura	Popište iniciační sizing a požadavky na aplikační vrstvu (operační systém, aplikační technologie, aplikační frameworky atd.).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V tuto chvilku je používána tato Linuxová distribuce: xxxxx://xxxxxxxxxx.xxx/xxxx/xxxxx-xxxxx-0-0-xx- release/ Vše ostatní si doinstaluje dodavatel.	Dodána dokumentace k nabízenému systému.
Req_080	Nefunkční	Infrastruktura	Uveďte jaké DB řešení integrační platforma podporuje (nejlépe MS SQL DB nebo případně OpenSource DB či jiné). V případě, že podporuje jiné DB než MS SQL DB, tak musí být licence, zaškolení administrátorů zadavatele a L3 podpora dodavatele DB řešení součástí nacenění a dodávky.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V dokumentaci je uvedeno PostgreSQL (v dokumentaci 1.1 základní architektonické overview). xxxxx://xxx.xxxxxxxxxx.xxx/xxxx/xxxxxxx/ Školení bude řešeno v rámci implementace a předání předmětu smlouvy.	Dodána dokumentace k nabízenému systému.
Req_081	Nefunkční	Infrastruktura	Řešení podporuje high availaibility provoz.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Jde o řešení "kontenerizační platformy", kdy dostupnost kontejnerového prostředí je obecně definované jako řešení možné s HA.	Dodána dokumentace k nabízenému systému.

Req_082	Nefunkční	Infrastruktura	Řešení podporuje DR provoz (Disaster Recovery model), včetně provozu ve více lokalitách.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci kuberneties by mělo být obecně podporováno. Záleží na provedení implementace. Dle doplňující informace, pokud je v rámci zákazníka nainstalován geo cluster je podpora DR zajištěna. xxxxx://xxx.xxxxxxxx.xxx/xxxx/xxxxxxxx-xxxxxxxx-xxx-xxxxxxxxxx-xxxx-xxxxxxxxx-xxx-xxxx-xxxxxxxxxxxx NUTNO si pohlídat v rámci analytické fáze pro implementaci!!!	Dodána dokumentace k nabízenému systému.
Req_083	Nefunkční	Infrastruktura	Řešení podporuje redundanci na úrovní datové vrstvy (Active-Passive, Active-Active, Databázový cluster).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Postgre, které je v řešení použito redundanci umožňuje. Dle doplňující informace, pokud je v rámci zákazníka nainstalován geo cluster je podpora redundance zajištěna. xxxxx://xxx.xxxxxxxxxx.xxx/xxxx/00/xxxx-xxxxxxxxxxxx.xxxx xxxxx://xxx.xxxxxxxxxxxx.xxx/xxxxxxxx-xxxxxxxxx/xxxxxxxxxx-xxxxxxxxxxx-xxx-xxxxxxxxx-xxxxxxxx-xxxxxxxx NUTNO si pohlídat v rámci analytické fáze pro implementaci!!!	Dodána dokumentace k nabízenému systému.
Req_084	Funkční	Integrační platforma/ middleware core	Z hlediska throttlingu řešení musí umožnit nastavovat limity průtoku zpráv jednotlivými technologiemi, ale hlavně na úrovni služeb.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	Řešení obsahuje modul "Throttling" pro nastavení kvót na jednotlivá prostředí, aplikace, consumera, API a dále je možné přímo v rámci designu služeb definovat nastavení APIM Quota (v dokumentaci 4.5 Modul "Throttling", 5.2 Modul "Service Designer"). PŘEDVEDENO v rámci DEMO: ANO Bylo ukázáno v rámci ukázky API managementu, kdy lze kvóty nastavovat nejen pro consumera, ale i pro API jak v rámci administrace, tak i v rámci tvorby designu služeb.	Ukázka v DEMO
Req_085	Funkční	Integrační platforma/ middleware core	Throttling musí být plně konfigurovatelný, jako součástí konfigurace dané služby.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	V rámci designu služeb je možné definovat nastavení APIM Quota: Quota policy (počet požadavků/objem dat), Quota např. "100 request per 1 MIN", Status, Zóna, ... (v dokumentaci 5.2 Modul "Service Designer"). PŘEDVEDENO v rámci DEMO: ANO Bylo ukázáno v rámci ukázky API managementu, kdy lze kvóty nastavovat nejen pro consumera, ale i pro API jak v rámci administrace, tak i v rámci tvorby designu služeb.	Ukázka v DEMO
Req_086	Funkční	Integrační platforma/ middleware core	Throttling je možné omezit na úrovni: - Velikosti zprávy - Velikosti streamu za čas - Počtu zpráv za čas (sec/min/hod/den) - Počtu konzumentů - apod.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	V rámci nastavení kvót je možné definovat nastavení APIM Quota: Quota policy (počet požadavků/objem dat), Quota např. "100 request per 1 MIN" (v dokumentaci4.5 Modul "Throttling", 5.2 Modul "Service Designer"). PŘEDVEDENO v rámci DEMO: ANO Bylo ukázáno v rámci ukázky API managementu i v rámci tvorby designu služeb, kdy lze kvóty nastavovat pro consumery, pro prostředí, pro API na počet požadavků (zpráv) nebo objem dat s nastavením data unit, time quantity, time unit, zóny.	Ukázka v DEMO
Req_087	Funkční	Integrační platforma/ middleware core	Součástí message queues (asynchronního zpracování front) je i zpracování front zpráv dle priorit.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci použitého řešení na Apache Camel jsou komponenty JMS, AMQP (pozn. byly zmíněny i v rámci ukázky DEMO), které umožňují prioritizaci zpráv dle nastavení priorit na consumera. (v dokumentaci 1.2 Technologický stack platformy) xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx- component.html#_component_option_artemisConsumerPriority xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_088	Funkční	Integrační platforma/ middleware core	Message queues (assynchronní zpracování front) obsahuje historii, detailní log i nástroje pro správu front.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Je podporováno řešení Elastic Search (monitoring pro log, metriky, …), Grafana (dashboard) a zobrazení logů volání služeb v "Service Repository" (v dokumentaci 1.1. Základní architektonické overview, 5.2. Modul "Service Repository"). Současně lze v rámci designu integrační služby v rámci komponenty pro zpracování front provádět parametrizaci/nastavení fronty. xxxxx://xxx.xxxxxxx.xx/xxxxx/xxxxx.xxxx xxxxx://xxx.xxxxxxx.xxx/xxxxxxxxxxxx xxxxx://xxxxxxx.xxx/xxxx/ xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_089	Funkční	Integrační platforma/ middleware core	Z hlediska journalingu (sledování a záznamenávání událostí) musí být řešen journaling přenášených zpráv. Tuto funkčnost musí platforma podporovat u všech integračních technologií.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Logování volání služeb je v Grafana. Součástí prezentace DEMO verze v rámci požadavku na předvedení "Logování (transakční log) a journaling (auditní log)" byl v rámci předvedení testování ukázán transakčního log integrační služby včetně jednotlivých kroků (zpracován request, vrácen responce, trasování) v nástroji Grafana.	Dodána dokumentace k nabízenému systému.
Req_090	Funkční	Integrační platforma/ middleware core	Journaling (sledování a zaznamenávání událostí) podporuje správce řešení v administrator cockpitu pomocí visuálního zobrazení journalu konkrétní komunikace konkrétní služby.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Auditní logování je integrováno v nabízeném řešení PHinTegra (v celé dokumentaci - např. audit log zákazníka, audit log systému, audit log služby, ...) , logování volání služeb je v Grafana (v dokumentaci 1.2 Technologický stack platformy, 5. Services v části Grafana - zobrazení logů volání verze IS).	Dodána dokumentace k nabízenému systému.
Req_091	Funkční	Integrační platforma/ middleware core	Journaling (sledování a zaznamenávání událostí) v případě asynchronního zpracování zohledňuje korelační atributy (korelační ID, process ID), jež spojují více integračních služeb v jednu business službu.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Logování volání služeb je v Grafana. xxxxx://xxxxxxx.xxx/xxxx/xxxxxxx/xxxxxx/ Součástí prezentace DEMO verze v rámci požadavku na předvedení "Logování (transakční log) a journaling (auditní log)" byl v rámci předvedení testování ukázán transakčního log integrační služby včetně jednotlivých kroků (zpracován request, vrácen responce, trasování) v nástroji Grafana. Jde o logování v rámci integrační hlavičky, které je podporováno (v ukázce sloupce MsQ Id, Header).	Dodána dokumentace k nabízenému systému.
Req_092	Funkční	Integrační platforma/ middleware core	Journaling (sledování a zaznamenávání událostí) umožňuje vyhledávání v obsahu zprávy (message payload) a vyhledávání v journalu (např. vyhledávání změn atributů)..	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Logování volání služeb je v Grafana. V Grafana lze v logu fultextově vyhledávat. xxxxx://xxxxxxx.xxx/xxxx/xxxxxxx/xxxxxx/xxxxxxx/xxxx-xxxxxxxxxxx/ Součástí prezentace DEMO verze v rámci požadavku na předvedení "Logování (transakční log) a journaling (auditní log)" byl v rámci předvedení testování ukázán transakčního log integrační služby včetně jednotlivých kroků (zpracován request, vrácen responce, trasování) v nástroji Grafana. Jde o logování v rámci payloadu.	Dodána dokumentace k nabízenému systému.
Req_093	Funkční	Integrační platforma/ middleware core	Z hlediska runtime konfigurace řešení musí striktně oddělovat konfigurace běhových proměnných pro jednotlivá prostředí. Tyto konfigurace musejí být zabezpečeny a ošetřeny proti útoku a úniku dat.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V řešení PHinTegra v rámci definování komponenty APIM lze nastavit, zda chci nebo nechci auditovat payload, při deploy na produkční prostředí vypnout a nelogovat. Dále je možné nastavit anonymizace payloadu. Tyto dvě možnosti zajišťují ochranu proti úniku citlivých dat.	Dodána dokumentace k nabízenému systému.
Req_094	Funkční	Integrační platforma/ middleware core	Z hlediska runtime konfigurace citlivé údaje jako přístupy, ssl hashe apod. musejí být uloženy odděleně v zabezpečené části řešení.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V řešení je použita komponenta HashiCorp Vault pro správu a zabezpečení citlivých dat a informací (z dokumentace 1.2 Technologický stack platformy, 4.4 Modul "Vault"). xxxxx://xxxxxxxxx.xxxxxxxxx.xxx/xxxxx/xxxx/xxxx-xx-xxxxx	Dodána dokumentace k nabízenému systému.
Req_095	Funkční	Integrační platforma/ middleware core	Runtime konfigurace služeb/částí služeb musejí umožňovat automatizovaný provoz a deployment platformy.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Physter Technologies pro svoje instalace poiužívá DEVOPS/GITOPS přístup k instalaci svých produktů. V dokumentaci je postup pro instalace a hlavní výhody /přínosy tohoto principu (dokument GITOPS_blueprint.docx). Dále v řešení PHinTegra je deploy integračních služeb postavený tak, že z jednotlivých integračních scénářů vytvořené samostatné služby je možné automaticky buildovat a deployovat (z dokumentace 1.4 Service Repository, 5.1 Modul "Service Repository").	Dodána dokumentace k nabízenému systému.
Req_096	Funkční	Integrační platforma/ middleware core	Z hlediska alertingu umožňuje řešení nastavit varování/alerting pro různé typy úloh.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V řešení PHinTegra je kontrola pro nasazování služeb na jednotlivá prostředí. Je řešeno formou zpráv se zobrazováním počtu zpráv na ikoně zvonečku (po přečtení zpráva zmizí) a dále je možné nastavit kontrolu v rámci designu služeb (např. lze mezi komponenty REST přidat komponentu pro posílání e-mailu - v rámci předvedení demo jsme viděli komponentu SMTP). A dále je řešen monitoring v Prometheu. (5.2 Modul "Service Designer" - část pro Route Designer) xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxx/xxxxxx/xxxxxxxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_097	Funkční	Integrační platforma/ middleware core	Alert je sestavován pomocí business rule engine (umožňuje nastavení parametrů) a to pro jednotlivé integrační i provozní komponenty.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V řešení PHinTegra je možné nastavit kontrolu v rámci designu služeb (např. lze mezi komponenty REST přidat komponentu pro posílání e-mailu včetně parametrizace - v rámci předvedení demo jsme viděli komponentu SMTP). A dále je řešen monitoring v Prometheu. (v dokumentaci 4.3 Modul "Systems" - část Nasazení systému na dané prostředí, 5.2 Modul "Service Designer" - část pro Route Designer) xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxx/xxxxxx/xxxxxxxx/ xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxx/xxxxxx/xxxxxxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_098	Funkční	Integrační platforma/ middleware core	Alerty je možné zobrazit a konfigurovat v Administrator Grafic User Interface nebo přes notifikační engine (předdefinované šablony) umět zasílat notifikace skupinám nadefinovaným v konfiguraci.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci řešení je podporováno v Prometheu na základě nastavené konfigurace. xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxx/xxxxxx/xxxxxxxx/ xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxx/xxxxxx/xxxxxxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_099	Funkční	Integrační platforma/ middleware core	Alerting zajišťuje deduplikaci alertů při notifikaci na koncového uživatele.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci řešení je podporováno v Prometheu na základě nastavené konfigurace. xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxx/xxxxxx/xxxxxxxxxxxxx/	Dodána dokumentace k nabízenému systému.

Req_100	Funkční	Integrační platforma/ middleware core	Komponenta orchestrace umožňuje jednotné zobrazení aktuálního stavu platformy ve smyslu: - vizuálního zobrazení aktivovaných komponent, jejich parametrů, škálování s možností prokliku do konfigurace konkrétní komponenty, - monitoring provozu integrační platformy, - dashboarding zátěže a objemů, jež realizují jednotlivé integrační komponenty, - dashboard aktuálně čerpaných licencí.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci řešení je podporováno řešením Grafana s podporou Prometheus. xxxxx://xxxxxxx.xxx/xxxx/xxxxxxx/xxxxxx/xxxxxxxxxx/ xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxxxxxx/xxxxxxxx/#xxxx-xxxx-xx-xxx	Dodána dokumentace k nabízenému systému.
Req_101	Funkční	Integrační platforma/ middleware core	XML - XSD validace Řešení musí umožnit validaci zprávy vůči XSD schématu (XSD - W3C doporučení, definující, jak formálně popisovat elementy XML dokumentu, a jeden z jazyků pro popis XML).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci řesení Apache Camel je v rámci Enterprise Integration Patterns je podporována validace pro obsah zprávy a současně možnost využití komponenty pro validaci xml. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxxx-xxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_102	Funkční	Integrační platforma/ middleware core	XML - Uploading Multiple XSD Řešení musí umožnit správci hromadné nahrání XSD souborů.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci designu služby a detailu interfacu komponenty lze provést akce Download, Delete, Upload (v Dokumentaci 5.2 Modul "Service Designer" - část Microservice artefacts ). Je tedy možné mít uložistě xsd souborů, že kterého lze vybrat a nahrát/načíst do interfacu kompomenty odpovídající soubor.	Dodána dokumentace k nabízenému systému.
Req_103	Funkční	Integrační platforma/ middleware core	SOAP - WSDL Validation Řešení musí být schopné validovat zprávy vůči WSDL schématu.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci řesení Apache Camel je v rámci Enterprise Integration Patterns je podporována validace pro obsah zprávy a současně možnost v rámci jednotlivých komponent nastavit Object Mapper s podporou odpovídajícího datového typu. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxxx-xxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxx-xxx.xxxx V rámci použitého řešení na Apache Camel je možné v rámci Service Designeru použití různých komponent, které podporují datové formáty - i soap. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxxxxxxxxxx/xxxxxxxx-xxxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_104	Funkční	Integrační platforma/ middleware core	SOAP - Uploading Multiple WSDL Řešení musí umožnit správci hromadné nahrání WSDL souborů	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci designu služby a detailu interfacu komponenty lze provést akce Download, Delete, Upload (v Dokumentaci 5.2 Modul "Service Designer" - část Microservice artefacts ). Je tedy možné mít uložistě xsd souborů, že kterého lze vybrat a nahrát/načíst do interfacu komponenty odpovídající soubor.	Dodána dokumentace k nabízenému systému.
Req_105	Funkční	Integrační platforma/ middleware core	Custom validations Řešení musí umožňovat mechanizmus vytváření vlastních validací.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci řesení Apache Camel je v rámci Enterprise Integration Patterns je podporována možnost přidat vlastní java komponenty nebo validace na vybrané komponenty např. interfaces (Upload file na artefaktu mikroslužby nebo editace). Dále lze v rámci použitého API managementu kontrolovat request i response a vytvářet custom validátory. xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxxxxx/xxx-xxxxxxxx/xxx-xxxxxxxxxx/xxxxxxxx/#xxx-xx-xxx-xxx- for-request-validation xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxxxxxxxx/xxxxxxx/xxxxxxxx-xxxxxxxxx/xxxx-xxxxxxxx/xxxxxxxx- input-validators/#creating-a-new-custom-validator	Dodána dokumentace k nabízenému systému.
Req_106	Funkční	Integrační platforma/ middleware core	Request Parameters Validation Řešení musí být schopné validace vstupních parametrů.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Parametry se nastavují v rámci designu služeb v rámci routy např. na SOAP rozhranní (request), u REST je metoda GET, která vrací POST obsah (definice v rámci URL adresy) Obecně je podpořeno použitým API managementem, který umožňuje kontrolovat request i response a vytvářet custom validátory. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx-xxxxxxxxx.xxxx#_xxxxxxxx_xxxxx_xxxxxx_xxxxXXX xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxx-xxxxx/xxxxxx-xxxxxxxxxx/XXXXXX.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxx-xxxxx/xxxxxx-xxxx/ xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxxxxx/xxx-xxxxxxxx/xxx-xxxxxxxxxx/xxxxxxxx/#xxx-xx-xxx-xxx- for-request-validation xxxxx://xxxx.xxxx.xxx0.xxx/xx/xxxxxx/xxxxxxxxx/xxxxxxx/xxxxxxxx-xxxxxxxxx/xxxx-xxxxxxxx/xxxxxxxx- input-validators/#creating-a-new-custom-validator	Dodána dokumentace k nabízenému systému.
Req_107	Funkční	Integrační platforma/ middleware core	Attachment Řešení musí umožňovat detekci, blokaci, nastavení typu zaslané přílohy (kontroly).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci použitého řešení Appache Camel jsou řešeny i Attachments a jsou podporovány v rámci komponent jako např. web services a řešení validace s MTOM(attachments) s využitím processoru nebo využití komponenty file a možnost validace názvu. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx/xxxxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx-xx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx-xx- component.html#_how_to_use_mtom_attachments xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxx.xxxx#_xxxxx_x_xxxxxxxxx_xx_x_xxxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx- component.html#_endpoint_query_option_mtomEnabled xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxx/xxxx-xxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_108	Funkční	Integrační platforma/ middleware core	JSON - Validations Řešení musí umožňovat JSON validace zpráv (Schéma JSON se používá k ověření struktury a datových typů části JSON, podobně jako schéma XML pro XML).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení na Apache Camel podporuje validace formou komponenty, kterou je možné přidat ve PHinTegra v rámci designu služeb. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxxx/xxxx-xxxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_109	Funkční	Integrační platforma/ middleware core	Scheduling jobs Řešení musí být schopné vytvářet a spouštět plánované úlohy.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci použitého řešení na Apache Camel je možné v rámci Service Designeru použití různých komponent. Současně bylo v rámci předvedení DEMO verze ukázáno v rámci komponenty pro design služeb v rámci modelování integračního scénáře v rámci nastavování routy s možností využití komponenty SFTP Sourcea a komponenty Quartz (Scheduler pro plánování datových přenosů). xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx-xxxxxxxxx.xxxx The Quartz component provides a scheduled delivery of messages using the Quartz Scheduler 2.x. Each endpoint represents a different timer (in Quartz terms, a Trigger and JobDetail).	Dodána dokumentace k nabízenému systému.
Req_110	Funkční	Integrační platforma/ middleware core	Protocol support - MUST Řešení musí podporovat JSON a SOAP zprávy pomocí http Podpora: - SOAP 1.1/SOAP 1.2· - JSON	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci použitého řešení na Apache Camel je možné v rámci Service Designeru použití různých komponent. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx Podporují datové formáty: xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxxxxx/xxxxx-xxxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxxxxxxxxxx/xxxxxxxx-xxxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_111	Funkční	Integrační platforma/ middleware core	Protocol support - VARIABLE Řešení musí být schopné podporovat připojení za použití dalších protokolů. Pokud řešení nepodporuje standardně uvedený protokol, uveďte, jak je možné implementovat napojení za použití tohoto protokolu. Podpora: - JDBC - JMS - MQTT - AMQP - Apache Xxxxx	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci použitého řešení na Apache Camel je možné v rámci Service Designeru použití různých komponent. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxx0-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_112	Funkční	Integrační platforma/ middleware core	Protocol support - SAP, podpora BAPI a IDOC Řešení umožňuje úzkou integraci se SAP XI/PI/PO. Pokud řešení nepodporuje integraci na SAP za pomoci BAPI, uveďte, jak je možné se integrovat s prostředím SAP.	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	V rámci použitého řešení na Apache Camel je možné v rámci Service Designeru použití různých komponent. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx-xxxxxxxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.

Req_113	Funkční	Integrační platforma/ middleware core	API Orchestration Řešení umožňuje vytvářet orchestrované služby, kde výstupem je jedno API.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V Servise Designeru jsou modelovány integrační služby s následnou podporou v Route designeru, kde lze vytvářet routy (sekvence zpracování). Současně bylo ukázáno v rámci DEMO verze na ukázkách s více konzumenty, poskytovateli a následně ukázce transformace Xxxxx --> Rest a také buildování vytvořené integrační služby jako jeden build s následným nasazením takto vytvořené služby na vybrané prostředí jako výsledného jednotného výstupu.	Dodána dokumentace k nabízenému systému.
Req_114	Funkční	Integrační platforma/ middleware core	Error Handling Řešení podporuje jak built-in error handling, tak možnost vlastního error handlingu na neočekávané události.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V řešení je možné v rámci Service Designera v rámci routy řešit exceptions, a to pomocí ošetření v java code routy. xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxx-xxxxxxx.xxxx#_xxxxxxxxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxx-xxxxx-xxxxxxx.xxxx#_xxxxx_xxxxx_xxxxxxx_xxxxxxxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxx-xxxxxx.xxxx#_xxxxxxx_xxxxx_xxxxxxxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxx-xxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_115	Funkční	Integrační platforma/ middleware core	Configuration Import/Export Veškeré konfigurace služeb (flow, objektů, mapování, transformace atd.) musí jít exportovat do textového formátu. Takto exportovaný zdroj musí být přenositelný na jinou instanci/prostředí.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V aplikaci PHinTegra umožňuje k vybrané službě ze seznamu exportovat dokumentaci ve formátu PDF (.phtex) včetně nastavení parametrů exportu a importovat dokumentaci včetně nastavení parametrů s využitím POM šablon (v dokumentaci 5.3. Modul "Export/Import").	Dodána dokumentace k nabízenému systému.
Req_116	Funkční	Integrační platforma/ middleware core	Consumption of 3rd party APIs Řešení musí umožňovat integraci se službami třetích stran.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Kontejnerová architektura řešení umožňuje přes API volat např. z PHinTegra Grafanu, ... možnost přidat jakoukoliv komponentu/modul do řešení integrační platformy. (v dokumentaci 5.1 Modul "Service Repository" - část Grafana - zobrazení logů) xxxxx://xxxxxxx.xxx/xxxx/xxxxxxx-xxxxx/xxxxxxxxx-xxxxxxxxx/xxx-xxxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_117	Funkční	Integrační platforma/ middleware core	Analytics Metrics Řešení musí umožnit zachycení metrik volané služby: čas volání, název služby, metoda volání, Consumer key, Status Code, atd.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	PHinTegra umožňuje zobrazení monitoringu v Grafana, která je navíc dle dodaného obrázku architektury z pohledu monitoringu podpořena systémem Prometheus, který umožňuje sběr různých metrik a mělo by tedy být podporováno. xxxxx://xxxxxxx.xxx/xxx/xxxxxxx/ xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxxxxxx/xxxxxxxx/	Dodána dokumentace k nabízenému systému.
Req_118	Funkční	Integrační platforma/ middleware core	Service Consumer Filtration Řešení umožňuje filtraci/seskupení služeb a umožňuje následně zobrazit jejich konzumenty.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci řešení je možné si k existujícím poskytovatelům zobrazit seznam poskytovaných služeb a dále v rámci katalogu služeb si lze zobrazit seznam služeb, který je možný filtrovat. Následně je možné si ze zobrazených služeb zobrazit detail služby v Service Designeru včetně jejich konzumentů. (v dokumentaci 4.3 Modul "Systems" - zobrazení služeb daného systému, obrazovka "Applied" a následné zobrazení detailů konzumentů, 5.1 Modul "Service Repository" - zobrazení existujících služeb)	Dodána dokumentace k nabízenému systému.
Req_119	Funkční	Integrační platforma/ middleware core	API Call Rate Limiting Řešení umožňuje měření propustnosti a je možné omezit funkčnost na základě počtu požadavků odeslaných do API GW během časového období nebo na základě objemu dat přenesených prostřednictvím API GW. Limit je možno nastavit pro konkrétního konzumenta.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci řešení je podporováno v rámci Apache Camel omezení na počet requestů. xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxxx-xxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxxxxxxxx-xxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_120	Funkční	Integrační platforma/ middleware core	API Mock Creation Řešení musí být schopné na základě definic služeb vytvořit mock služby (typ zástupného objektu, který simuluje chování určitého objektu, v tomto případě webové služby) a umožnit jejich publikaci konzumentům.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci řešení je podporováno použitím komponent Apache Camel. xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx (generování response pro request pomosí použití šablon)	Dodána dokumentace k nabízenému systému.
Req_121	Funkční	Integrační platforma/ middleware core	Řešení musí umožnit správci generování WSDL souborů.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci dodávky integrační platformy zákazník obdrží XSLT transformaci, která zajistí převod XSD na WSDL soubor. Dokumentace k řešení je zde: xxxxx://xxxx.xxxxxx.xxx/xxx0xx/0000000 V rámci nového releasu PHinTegra bude funkcionalita automatického převodu XSD na WSDL.	Dodána dokumentace k nabízenému systému.
Req_122	Funkční	Integrační technologie	Řešení musí umožnit jednoznačné verzování jednotlivých vyvíjených i provozovaných integračních služeb v rámci integrační platformy.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Nabízené řešení umožňuje vytváření verzí i revizí (v dokumentaci 5. Servises části Verze IS, Revize IS). Práce s revizemi byla předvedena i v rámci DEMO verze.	Dodána dokumentace k nabízenému systému.
Req_123	Funkční	Integrační technologie	Každá integrační služba/technologie podléhá vlastnímu životnímu cyklu v minimálním rozsahu: - Designing - Prototyping - Operate/Stable - To Be Decommisioned - Deprecated	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci nabízeného řešení se životní cyklus sleduje jak u služeb, tak u dalších komponent (systémy, kvóty, ...) je popsán formou akcí a hlavně stavů v rámci celé dokumentace. Stav pro deployment u integračních služeb, u kvót, komponent služby, ...: NOT_STARTED, DEPLOYED, DIRTY (DIRTY_CONFIG, DIRTY_SECRET, DIRTY_QUOTA), IN_PROGRESS, FAILURE, UNDEPLOY_IN_PROGRESS, UNDEPLOYED (UNDEPLOY_FAILURE) Stav pro build integrační služby (verzi): NOT_STARTED, COMPLETED, DIRTY, IN_PROGRESS, FAILURE, FINAL	Dodána dokumentace k nabízenému systému.
Req_124	Funkční	Integrační technologie	Jednotlivé integrační technologie/komponenty, jež realizují integrační služby, musejí umožnit striktně oddělenou komunikaci mezi interní sítí zadavatele a public internetem.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci konfigurace integračních služeb je nastavováno, zda jde o Internal nebo External APIM a tím i možnost oddělit interní a externí provoz formou nastavením zóny, kdy externí provoz služeb probíhá v DMZ; zóna se dále nastavuje pro consumera (v dokumentaci 5.2 Modul "Service Designer", část Internal APIM, External APIM IN/OUT, Design IS - nastavení "External APIM", IoDesign IS - nastavení "External APIM Interface", 4.3 Modul "Systems" - část vytvoření nového systému). V rámci řešení postavení na Kuberneties umožní oddělit celý API management na extra komponenty pro interní a externí.	Dodána dokumentace k nabízenému systému.
Req_125	Funkční	Integrační technologie	Je požadováno, aby všechny komponenty, jež zajišťují integrační komunikaci, umožňovaly fungovat nejen v módu interní komunikace, ale i v módu brány/Gateway pro oddělenou, zabezpečenou komunikaci do/z public internetu.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci konfigurace integračních služeb je nastavováno, zda jde o Internal nebo External APIM a tím i možnost oddělit interní a externí provoz formou nastavením zóny, kdy externí provoz služeb probíhá v DMZ; zóna se dále nastavuje pro consumera (v dokumentaci 5.2 Modul "Service Designer", část Internal APIM, External APIM IN/OUT, Design IS - nastavení "External APIM", IoDesign IS - nastavení "External APIM Interface", 4.3 Modul "Systems" - část vytvoření nového systému).	Dodána dokumentace k nabízenému systému.
Req_126	Funkční	Integrační technologie	Authorization - Allow Anonymous Users Řešení musí umožňovat anonymní přístup k vybraným službám.	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	V rámci konfigurace služby řešení umožňuje nastavení "UNTRUSTED", které zajistí, že nebude u providera kontrolována platnost certifikátu, tzn. že služba nebude zabezpečena (v dokumentaci 4.3 Modul "Systems" - část Konfigurace verze služby).	Dodána dokumentace k nabízenému systému.
Req_127	Funkční	Modelování služeb	Řešení musí umožnit model-driven přístup k vývoji integračních služeb pomocí vytvoření komunikačního modelu, struktury služeb a operací; mapování v grafickém nástroji (Enterprise Architect, ETL cockpit, ...) pro vygenerování vývojových a dokumentačních artefaktů.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty pro design služeb – nástroj pro návrh integračních služeb principem „drag & drop“ byl ukázán k již vytvořené službě kompoenentní diagram, sekvenční diagram formou designu route včetně směrování a časování. Bylo předvedeno modelování služeb, ukázáno jednoduché "klonování" proxy služby v rámci verzování v Service Repository, předveden pohled na konzumenty v modulu Systems, předveden pohled na providery a jejich služby v administray v modulu Systems.	Ukázka v DEMO
Req_128	Funkční	Modelování služeb	Řešení musí realizovat pomocné wizzardy pro přípravu modelů „standardních služeb“. Tyto wizzardy musejí být rozšiřitelné na programové úrovni.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty pro design služeb – nástroj pro návrh integračních služeb principem „drag & drop“ bylo v rámci modelování služeb ukázáno přidávání komponent v Route designeru, možnost úprav generovaného kódu dle potřebného použití v routě (úpravy podmínek pro volání různých služeb dle data – zavolání služby počasí pro aktuální den vs. pro historický datum).	Ukázka v DEMO
Req_129	Funkční	Modelování služeb	Komponenta obsahuje potřebné nástroje a funkčnosti pro vytvoření modelu standardní služby a její propagace do vývojových nástrojů řešení.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Je dáno řešením postaveném na Apache Camel, které poskytuje velké množství existujících prvků (typů konektorů, …). Současně bylo ukázáno přidávání prvků v rámci modelování služeb v Service Designeru. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_130	Funkční	Modelování služeb	Komponenta obsahuje repositář již vytvořených služeb.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty katalogu služeb (service repository)" byl ukázán přehled vytvořených služeb.	Ukázka v DEMO
Req_131	Funkční	Modelování služeb	Komponenta zajišťuje verzovanou tvorbu modelu přes centrální versioning systém.	ANO	Nízká	Nativní součást	Ověření v DEMO	3	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty katalogu služeb (service repository)" bylo předvedeno vytváření verzí, revizí a ukázána práce s verzemi.	Ukázka v DEMO
Req_132	Funkční	Modelování služeb	Komponenta umožňuje řídit vznik nových verzí integračních služeb.	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty katalogu služeb (service repository)" byla ukázána práce s verzemi včetně řízení vzniku verzí a revizí, kdy je na každém prostředí hlídáno, že je vždy nasazená maximálně jedna verze dané služby.	Ukázka v DEMO

Req_133	Funkční	Modelování služeb	Designer/modeller služeb generuje část dokumentace do service repository.	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty katalogu služeb (service repository)" bylo ukázáno pořizování dat do katalogu služeb s provázáním na Service Designer, kdy komponenta Service Repository spravuje seznam všech služeb, které vznikají/upravují se v Service Designeru (ukázána vzájemná provázanost obou modulů).	Ukázka v DEMO
Req_134	Funkční	Notifikace	Z hlediska notifikací musí řešení obsahovat notifikační engine (rozhraní pro nastavení odesílání notifikací nejen s alerty, ale i odesílání notifikací k událostem, pro definici šablon notifikací, nastavení deduplikace, …).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci modelování integračních služeb v Service Designeru si lze přidat komponenty v rámci routy po zavolání end-pointu na posílání e-mailů, sms. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xx-xxx-xxxxxxxxx.xxxx V rámci předvedení DEMO verze byla i představena komponenta SMTP (pravděpodobně custom komponenta, nebylo nalezeno v dokumentaci Apache Camel.	Dodána dokumentace k nabízenému systému.
Req_135	Funkční	Notifikace	Z hlediska notifikací komponenta musí umožňovat notifikace: - emailem, - SMS.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci modelování integračních služeb v Service Designeru si lze přidat komponenty v rámci routy po zavolání end-pointu na posílání e-mailů, sms. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xx-xxx-xxxxxxxxx.xxxx V rámci předvedení DEMO verze byla i představena komponenta SMTP (pravděpodobně custom komponenta, nebylo nalezeno v dokumentaci Apache Camel.	Dodána dokumentace k nabízenému systému.
Req_136	Funkční	Notifikace	Z hlediska notifikací komponenta musí umožňovat notifikace do sociálních sítí typu facebooku, Instagram a Socal messagerů WatsUp, Signal, Messagger, Viber.	NE	Nízká	Nativní součást	Ukázka v dokumentací	3	Splňuje	V rámci modelování integračních služeb v Service Designeru si lze přidat komponenty v rámci routy po zavolání end-pointu pro komunikaci se sociálními sítěmi buď přímo z komponent Apache Camel nebo integrací komponent třetích stran - např: xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxxxx-xxxxxxxxx.xxxx xxxxx://xxx.xxxxx.xxx/xx/xxxx/xxxxxxxxx-xxxx-xxxxxx-xxxxx.xxx	Dodána dokumentace k nabízenému systému.
Req_137	Funkční	Notifikace	Z hlediska notifikací komponenta musí vystavovat notifikační rozhraní mimo jiné jako webovou službu.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Lze např. vytvořit integrační službu, kde v rámci definice routy lze použít pouze komponentu Apache Camel na posílání e-mailů, sms s nastavením pouze vybraných parametrů (např. v detailu komponenty mail lze nastavit jen to, bcc, cc) a tuto integrační službu pak lze jako komponentu použít do jiných integračních služeb.	Dodána dokumentace k nabízenému systému.
Req_138	Funkční	Notifikace	Z hlediska notifikací komponenta musí umožňovat hromadné notifikace.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci Apache Camel komponent nebo uživatelské komponenty (v rámci Demo verze předvedená komponenta SMTP) bude možné nastavit více příjemců notifikace - např. pro komponentu mail lze nastavit parametry to, cc, bcc, u kterých je v dokumentaci uvedeno: "Separate multiple email addresses with comma." xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_139	Funkční	Notifikace	Z hlediska notifikací komponenta musí umožňovat využití šablon cílové notifikace a to v rozsahu: - správa visuálních šablon (HTML předpis), - využití datových proměnných a mapování v žádosti o notifikaci z backend systému.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci modelování integrační služby v Service Repository lze v rámci routy definovat kontextuální výrazy/dynamické proměnné v Contextual Dynamic Expression, které mohou být použity v rámci routy (v dokumentaci 5.2 Modul "Service Designer" - část "Route Designer" - "Service Configuration"). Dále je možnost využít komponenty Apache Camel pro šablony notifikací. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxxxx-xxxxxxxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_140	Nefunkční	Provozní požadavky	Řešení umožňuje logovat provoz a nastavit úroveň logování pro jednotlivé typy událostí.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Logování provozu je podpořeno pomocí nástroje Elastic Search (v dokumentaci 1.2 Technologický stack platformy). xxxxx://xxx.xxxxxxx.xx/xxxxxxxxxxxxx xxxxx://xxx.xxxxxxx.xx/xxxxxxxxxx-xxxxxx/xxxxxx-xxxxxxxxxxxx	Dodána dokumentace k nabízenému systému.
Req_141	Nefunkční	Provozní požadavky	Řešení umožňuje generovat systémový log pro atomické záznamy všech systémových událostí.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Auditní logování je integrováno v nabízeném řešení PHinTegra (v celé dokumentaci - např. audit log zákazníka, audit log systému, audit log služby, ...) s podporou pomocí nástroje Xxxx. xxxxx://xxxxxxx.xxx/xxx/xxxx/	Dodána dokumentace k nabízenému systému.
Req_142	Nefunkční	Provozní požadavky	Řešení umožňuje generovat aplikační log pro toky jednotlivých integračních zpráv a to až na úroveň obsahu zprávy.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Logování volání služeb je v Grafana s podporou pomocí nástrojů Prometheus, Fluent D (v dokumentaci 1.2 Technologický stack platformy, 5. Services v části Grafana - zobrazení logů volání verze IS). Dále rámci DEMO verze při testování buildu a nasazení integrační služby byl v uvedeném nástroji předveden transakční log integrační služby včetně jednotlivých kroků (zpracován request, vrácen responce, trasování). xxxxx://xxxxxxx.xxx/xxx/xxxxxxx/ xxxxx://xxxxxxxxxx.xx/xxxx/xxxxxxxxxxxx/xxxxxxxx/ xxxxx://xxx.xxxxxxx.xxx/xxxxxxxxxxxx	Dodána dokumentace k nabízenému systému.
Req_143	Nefunkční	Provozní požadavky	Řešení podporuje architekturu Elastic Stacku (ELK/EFG) pro sbírání distribuovaných logů.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení využívá Elastic Search (v dokumentaci 1.1 Základní architektonické overview, 1.2 Technologický stack platformy). xxxxx://xxx.xxxxxxx.xx/xxxxxxxxxxxxx xxxxx://xxx.xxxxxxx.xx/xxxxxxxxxx-xxxxxx/xxxxxx-xxxxxxxxxxxx	Dodána dokumentace k nabízenému systému.
Req_144	Nefunkční	Provozní požadavky	Řešení podporuje architekturu Fluentd pro sbírání distribuovaných logů.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení využívá Fluent D (v dokumentaci 1.1 Základní architektonické overview, 1.2 Technologický stack platformy). xxxxx://xxx.xxxxxxx.xxx/xxxxxxxxxxxx	Dodána dokumentace k nabízenému systému.
Req_145	Nefunkční	Provozní požadavky	Řešení poskytuje prostředí pro administrátory, kde mohou provádět správu obsahu logů, filtrování, vyhledávání (parametricky i fulltextově).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Logování volání služeb je v Grafana s podporou pomocí Prometheus (v dokumentaci 5. Services v části Grafana - zobrazení logů volání verze IS). Dále rámci DEMO verze při testování buildu a nasazení integrační služby byl v uvedeném nástroji předveden transakční log integrační služby včetně jednotlivých kroků (zpracován request, vrácen responce, trasování). xxxxx://xxxxxxx.xxx/xxx/xxxxxxx/ xxxxx://xxxxxxxxxx.xx/	Dodána dokumentace k nabízenému systému.
Req_146	Nefunkční	Provozní požadavky	Řešení poskytuje prostředí pro administrátory, kde mohou provádět správu prostředí z pohledu monitoringu prostředí, stavu komponent, instancí, konzumace výkonu, stavu prostředí.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Je dáno řešením na kubernetes, kdy v rámci správy prostředí kubernetes lze použít jakékoliv OpenSource řešení pro zobrazení stavu prostředí (kubernetes GUI). Výběr řešení bude vyřešen v rámci implementační analýzy. NUTNO si pohlídat v rámci analytické fáze pro implementaci!!! xxxxx://xxxxxx.xxx/xxxxxx/xxxxxxxxxx-xxx-xxxxxxx-xx-0000-xxxx-xxxxxxxxx-xxxx-xxxxxx-xxx-xxxxxxx- ce28df9bb0f0	Dodána dokumentace k nabízenému systému.
Req_147	Nefunkční	Provozní požadavky	Řešení umožňuje napojení na centrální monitoring zadavatele a to na úrovni infrastruktury (konzumace infrastrukturních kapacit v čase) i na úrovni aplikace. - napojení událostí (servis infrastruktury --> servery, komponenty --> integrační platforma).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	PHinTegra umožňuje zobrazení monitoringu v Grafana, která je navíc dle dodaného obrázku architektury z pohledu monitoringu podpořena systémem Prometheus. xxxxx://xxxxxxx.xxx/xxx/xxxxxxx/ xxxxx://xxxxxxxxxx.xx/ V rámci doplnění dokumentace bylo uvedeno, že je i možnost propojení řešení např. se Zabbix.	Dodána dokumentace k nabízenému systému.
Req_148	Nefunkční	Provozní požadavky	Administrátor pracuje pod speciálním účtem.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci řešení je i nastavování uživatelů, při předvedení DEMO verze bylo zmíněno přiřazení rolí uživatelům ze 4 možných nastavených rolí, kdy jedna role je role admin, který má možnost spravovat v rámci řešení users, customers (v dokumentaci 4.2 Modul "Users").	Dodána dokumentace k nabízenému systému.
Req_149	Nefunkční	Provozní požadavky	Administrátorský účet nemá plná systémová oprávnění (root).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci řešení je i nastavování uživatelů, při předvedení DEMO verze bylo zmíněno přiřazení rolí uživatelům ze 4 možných nastavených rolí, kdy jedna role je role admin, který má možnost spravovat v rámci řešení users, customers. Současně lze uživatele nastavovat s omezením na jednotlivá prostředí a ne na celé řešení a v rámci nastavení není žádná vazba na administraci celé kontejnerové platformy (v dokumentaci 4.2 Modul "Users").	Dodána dokumentace k nabízenému systému.
Req_150	Nefunkční	Provozní požadavky	Řešení musí umožnit upgrade/update komponent systému se zpětnou kompatibilitou minimálně 1 master verze s tím, že upgrade/update nesmí ovlivnit customizace (loose coupled princip).	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení PHinTegra je postaveno na kontejnerovém řešení. Tedy výměna komponent by měla být bez dopadu a výpadku. Vyměňuje se pouze jeden kontejner = jedna funkcionalita. Customizace ve formě integračních služeb by také měli být řešeny v rámci kontejnerizace, tudíž "nezávisle" na ostatních komponentách.	Dodána dokumentace k nabízenému systému.

Req_151	Nefunkční	Provozní požadavky	Řešení musí podporovat základní principy automatizace - kontinuální implementace (vývojový princip, build, integrace se source code i binary repositories), součástí dodávky je základní set automatizovaných sys a unit testů.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Nabízené řešení umožňuje automatický build vybrané verze integrační služby včetně kontrol a následného nasazení na vybrané prostředí (v dokumentaci zejména 5 Services, část Build - vytvoření image k nasazení IS a část Deplolyment - nasazení IS). Současně bylo řešení automatizace vytváření verzí včetně buildu, souvisejících kontrol a nasazení na vybrané prostředí předvedeno v rámci DEMO verze i se souvisejícím testováním přes aplikaci SoapUI a zobrazením výsledků v Grafana.	Dodána dokumentace k nabízenému systému.
Req_152	Nefunkční	Provozní požadavky	Řešení musí podporovat základní principy automatizace - kontinuání nasazení/delivery (automatizovaný deployment zejména vyvíjených služeb z binary repositářů do jednotlivých prostředí).	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Nabízené řešení umožňuje automatický build vybrané verze integrační služby včetně kontrol a následného nasazení na vybrané prostředí (v dokumentaci zejména 5 Services, část Build - vytvoření image k nasazení IS a část Deplolyment - nasazení IS). Současně bylo předvedeno v rámci DEMO verze.	Dodána dokumentace k nabízenému systému.
Req_153	Nefunkční	Provozní požadavky	Řešení podporuje centrální řízení, správu a monitorovaní fungování jednotlivých komponent. Pro monitoring je možno použít například řešení Zabbix, Netdata, Nagios, ....	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V dodaném obrázku architektury je uvedeno použití systému Prometheus na monitoring. xxxxx://xxxxxxxxxx.xx/	Dodána dokumentace k nabízenému systému.
Req_154	Nefunkční	Provozní požadavky	Self-care portal - User management Řešení umožňuje registraci, úpravu, mazání, blokování uživatelů v Self-care portálu. Veškeré uživatelské aktivity jsou logovány. Základní údaje jsou řízené Identity Managementem.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Nabízené řešení umožňuje správu uživatelů včetně přiřazování rolí: leader - pro čtení, analyst - pro design služeb, deployer - pro build a nasazování služeb, admin pro administraci systému (v dokumentaci 4.2 Modul "Users"). Současně byla správa uživatelů předvedena v rámci DEMO verze.	Dodána dokumentace k nabízenému systému.
Req_155	Nefunkční	Provozní požadavky	Self-care portal - Services consumption Řešení umožňuje přihlášenému uživateli zobrazit statistiky a detail o konzumovaných službách.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	PHinTegra umožňuje zobrazit logy volání integračních služeb v Grafana, která je navíc dle dodaného obrázku architektury podpořena systémem Prometheus na monitoring a systémem Loki na logování (v dokumentaci 4.3 Systems - část Seznam existujích služeb). Současně bylo předvedeno i v rámci prezentace DEMO verze (v Grafana informace ConsumerID). xxxxx://xxxxxxx.xxx/xxx/xxxxxxx/ xxxxx://xxxxxxx.xxx/xxx/xxxx/ xxxxx://xxxxxxxxxx.xx/	Dodána dokumentace k nabízenému systému.
Req_156	Nefunkční	Provozní požadavky	Self-care portal - Localization Řešení musí umožňovat lokalizaci self-care portálu.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	PHinTegra umožňuje v rámci základního nastavení vybrat ze dvou jazyků - angličtiny a češtiny (v dokumentaci 3.1 Základní obrazovka PTH).	Dodána dokumentace k nabízenému systému.
Req_157	Nefunkční	Provozní požadavky	Self-care portal - Documentation Řešení poskytuje informace o publikovaných službách, prostřednictvím možnosti poskytování dokumentace třetím stranám.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V aplikaci PHinTegra umožňuje exportovat k vybrané službě ze seznamu dokumentaci ve formátu PDF (v dokumentaci 5.3. Modul "Export/Import").	Dodána dokumentace k nabízenému systému.
Req_158	Nefunkční	Provozní požadavky	Nabízené řešení musí být na českém trhu prokazatelně podporovatelné (provozovatelné) minimálně 3 partnery.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci doplnění dokumentace byly uvedeni tito partneři: O2 IT Services, Asseco, Konica Minolta	Dodána dokumentace k nabízenému systému.
Req_159	Nefunkční	Provozní požadavky	Nabízené řešení musí být na českém trhu prokazatelně rozvíjitelné minimálně 3 partnery.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci doplnění dokumentace byly uvedeni tyto partneři: O2 IT Services, Asseco, Konica Minolta	Dodána dokumentace k nabízenému systému.
Req_160	Nefunkční	Provozní požadavky	U neprodukčních prostředí neočekáváme potřebu licencování neprodukčně používaných licencí.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Bylo definováno v rámci zadávací dokumentace, v cenové nabídce uvedena potřeba pouze jedné licence na PHinTegra a dále byla potřeba pouze jedné nainstalované aplikace PHinTegra zmíněna i v rámci prezentace DEMO verze (pro produkční i testovací prostředí). Dle obrázku technologie je zbytek Open Source (v dokumentaci 1.2 Technologický stack platformy).	Dodána dokumentace k nabízenému systému.
Req_161	Nefunkční	Provozní požadavky	Systém v případě poruchy jednoho či více modulů/komponent musí být schopný nadále fungovat a to i za předpokladu případného omezení dostupné funkcionality (tzv. nouzový režim).	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Řešení PHinTegra je postaveno na kontejnerovém řešení. Tedy výměna komponment je bez dopadu a výpadku. Vyměňuje se pouze jeden kontejner = jedna funkcionalita.	Dodána dokumentace k nabízenému systému.
Req_162	Nefunkční	Provozní požadavky	U neprodukčních prostředí neočekáváme potřebu licencování neprodukčně používaných licencí.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Duplicitní požadavek s Req_160.	Dodána dokumentace k nabízenému systému.
Req_163	Nefunkční	Provozní požadavky	Zadavatel očekává, že součástí plnění poskytnutého jako “krabicové” řešení je udělení nevýhradní, teritoriálně neomezené licence na dobu neurčitou. Licenci je možno užívat a přesouvat mezi společnostmi zadavatele bez ohledu na lokalitu nebo společnost a bez jakýchkoliv dalších omezení. Zadavatel, případně jím určený smluvní partner jsou oprávněni tento produkt upravovat a měnit pouze pro sovu potřebu.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Bylo definováno v rámci zadávací dokumentace a je uvedeno v podepsané smluvní dokumentaci (kupní smlouva, servisní smlouva).	Dodána dokumentace k nabízenému systému.
Req_164	Nefunkční	Provozní požadavky	Poskytovatel specifikuje typy licencí, jejich metriky a způsoby užití integrační platformy.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Bylo definováno v rámci zadávací dokumentace, v cenové nabídce uvedena potřeba pouze jedné licence na PHinTegra a dále byla potřeba pouze jedné nainstalované aplikace PHinTegra zmíněna i v rámci prezentace DEMO verze (pro produkční i testovací prostředí). Dle obrázku technologie je zbytek Open Source (v dokumentaci 1.2 Technologický stack platformy).	Dodána dokumentace k nabízenému systému.
Req_165	Nefunkční	Provozní požadavky	Příprava exit strategie Dodavatel popíše plán ukončení plnění, který bude popisovat dopady ukončení plnění na zadavatele, a identifikaci a zhodnocení souvisejících rizik, jejich zhodnocení a návrh jejich eliminace a harmonogram činností ukončení či přechodu systému. Dokument bude předložen zadavateli do 1 měsíce od doručení požadavku zadavatele.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Bude dodáno v rámci implementace produktu. Obecně je produkt postaven na open technologiích. Nevzniká tedy vendor lock in. Lze ověřit až při akceptaci!!!: V rámci předvedení DEMO verze k ověření bylo potvrzeno, že toto skutečně bude dodáno v rámci implementace jako součást dokumentace.	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_166	Nefunkční	Provozní požadavky	Příprava exit strategie - dodavatel popíše způsob předání kompletní elektronické kopie veškeré dokumentace, kterou vytvořil v rámci svého plnění s tím, že dokumentace bude aktualizována tak, aby odrážela stav integrační platformy a poskytovaných služeb k termínu ukončení plnění.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Bude dodáno v rámci implementace produktu. Obecně je produkt postaven na open technologiích. Nevzniká tedy vendor lock in. Lze ověřit až při akceptaci!!!: V rámci předvedení DEMO verze k ověření bylo potvrzeno, že toto skutečně bude dodáno v rámci implementace jako součást dokumentace.	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_167	Nefunkční	Provozní požadavky	Dodavatel popíše zadavateli způsob předání všech hesel, šifrovacích klíčů, certifikátů a dalších autentizačních prostředků, které zadavateli umožní administrátorský přístup k veškerým datům, databázím, systémům, případně k dalším technickým prostředkům.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Bude dodáno v rámci implementace. Bude dodán dokument jako součást dokumentace projektu. Lze ověřit až při akceptaci!!!	Ověření až po dokončení implementace v rámci předání dokumentace skutečného stavu; viz budoucí smluvní vztah.
Req_168	Nefunkční	Provozní požadavky	Předmět plnění jako celek i jeho veškeré dílčí části musí být vždy plně v souladu s aktuálně platnou legislativou, tj. musí splňovat veškeré zákonné normy, podzákonné normy, včetně vnitřní řídící dokumentace zadavatele.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci nabídky byla dodána podepsaná smluvní dokumentace. Mimo jiné je např. v katalogu služeb uvedeno řešení zákonných požadavků.	Dodána dokumentace k nabízenému systému.
Req_169	Nefunkční	Provozní požadavky	Verze systému v jednotlivých prostředích budou výrazně graficky odlišitelná nastavením parametru.	ANO	Nízká	Nativní součást	Ověření v DEMO	3	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Konfigurace (prostředí, uživatelů)" bylo ukázáno nastavení prostředí (výběr barvy pro podbarvení názvu prostředí v celém systému) v administraci v modulu Customers.	Ukázka v DEMO
Req_170	Nefunkční	Provozní požadavky	Auditní záznamy budou obsahovat: - ID uživatele - Datum a čas události - Popis události (přihlášení, odhlášení, neoprávněný přístup, změna nastavení) - Identifikátor rozhraní (název rozhraní a message ID)	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Logování (transakční log) a journaling (auditní log)" byla ukázána možnost ze Service Repository pro zobrazení auditního logu ke službám a následně i ukázána možnost z administrace na zobrazení auditního logu k vybranému uživateli. Současně byl ukázán i detal obsahující všechny požadované atributy včetně dalších (prostředí, ...).	Ukázka v DEMO
Req_171	Funkční	Service repository and documentation	Řešení musí obsahovat komponentu Enterprise Service Repository jako nástroj pro grafické zobrazení dokumentace integračních služeb.	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty katalogu služeb (service repository)" bylo ukázáno zobrazení provázaného detailu v Service Designeru s grafickým modelem.	Ukázka v DEMO
Req_172	Funkční	Service repository and documentation	Komponenta zobrazuje aktuální stav vygenerované dokumentace (service designer/modeller): - Servisní specifikace služby - Interface agreementy poskytovatel-konzument - Odkazy na definiční artefakty (wsdl, swagger, …)	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty katalogu služeb (service repository)" bylo ukázáno zobrazení provázaného detailu v Service Designeru s grafickým modelem a při ukázce komponentního diagramu vše ukázáno v rámci vybraných komponent v designu již vytvořené služby.	Ukázka v DEMO
Req_173	Funkční	Service repository and documentation	Komponenta graficky zobrazuje vztahy mezi jednotlivými službami, jejich propojení/relace s drilldown - proklikem na detailní informace	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci požadavku na předvedení "Komponenty katalogu služeb (service repository)"bylo ukázáno zobrazení verzí služby a následně ukázáno v provázaném detailu v Service Designeru s grafickým modelem.	Ukázka v DEMO
Req_174	Funkční	Service repository and documentation	Komponenta obsahuje pro každou takto konfigurovanou službu komunikační prvek/rozhraní, jež poskytuje aktuální běhové informace o konkrétní službě (existuje, neexistuje, verze, název, ...).	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Pro běh služeb se používá monitorovací nástroj Grafana (v dokumentaci nastavení nástroje u definice prostředí, přístup do Grafana pro danou verzi na daném prostředí je v menu záznamu verze IS). Současně byl tento nástroj předveden v rámci DEMO verze.	Dodána dokumentace k nabízenému systému.
Req_175	Funkční	Service repository and documentation	Komponenta umožňuje fulltextové i parametrické vyhledávání napříč dokumentační bází Enterprise Services Registry a integračními službami, které jsou řešením realizovány.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Přednastavené filtry jsou použité v rámci celé aplikace PHinTegra pro zobrazení změn v auditním logu, dále textové filtry pro výběr dle zadaného názvu, verze a stavu služby (v dokumentaci jsou uvedené u audit logů, v kapitole 6. Dashboard). V rámci DEMO bylo předvedeno v rámci obrazovky "Dashboard - Build" zobrazení filtru s poli Name (textové vyhledávání), Version, Status (parametrické vyhledávání).	Dodána dokumentace k nabízenému systému.
Req_176	Funkční	Service repository and documentation	Komponenta umožňuje export vybrané dokumentace konkrétní služby jako celistvé informace do strukturovaného formátu čitelného běžným uživatelem (např. PDF formátu, DOCX formátu).	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V aplikaci PHinTegra umožňuje exportovat k vybrané službě ze seznamu dokumentaci ve formátu PDF (v dokumentaci 5.3. Modul "Export/Import").	Dodána dokumentace k nabízenému systému.

Req_177	Funkční	Service repository and documentation	Komponenta specificky definuje oprávnění zobrazení jednotlivých služeb z důvodu poskytnutí dat třetím stranám (např. wsdl definicím poskytovaného rozhraní dodavateli/konzumentovi služby): - integrační technologie, - služba, - operace, - dokumenty a artefakty, - relace mezi konzumentem, integrační platformou a poskytovatelem.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Modul v administraci "Users" umožňuje nastavovat role jednotlivým uživatelům a uživatel je vždy definován s vazbou na "Customers" (v dokumentaci 4.2 Modul "Users"). V rámci předvedení DEMOVERZE pak byla prezentována možnost nastavit i roli leader (pro čtení) a je tedy pro tuto roli kromě přístupu do katalogu služeb a zobrazení služeb např. možnost si u vybraných verzí služby stáhnout potřebné artefakty.	Dodána dokumentace k nabízenému systému.
Req_178	Funkční	Souborové přenosy	Z hlediska souborových přenosů řešení musí umožnit zabezpečený přenos datových souborů. Přenos datových souborů se typicky odehrává asynchronně kvůli objemným přenosům od poskytovatele ke konzumentům.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Přenos datových souborů je zabezpečení stejně jako jakýkoliv jiný přenos, kdy se u jednotlivých integračních služeby nastavují i consumers a k nim je možné v administraci nastavit secrets (v dokumentaci 5.2 Service Designer - část Internal APIM, External APIM, APIM Configuration, 4.2 Modul "Systems" - část Nastavení zabezpečení systému).	Dodána dokumentace k nabízenému systému.
Req_179	Funkční	Souborové přenosy	Z hlediska souborových přenosů komponenta musí umožnit konfiguraci, provoz a monitoring jednotlivých souborových přenosů.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci Apache Camel je pro souborové přenosy k dispozici i komponenta, která pro konfiguraci používá konfigurační soubor pom.xml. Pro monitoring souborových přenosů je nutné v rámci modelování služby v Service Designeru přidat ještě komponentu pro logování a dále je možné provádět úpravy v rámci java code. Nalezeno jen sftp - xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxxxxx/xxxxxxxxxxxx-xx-xxx-xxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxx-xxxxxxxxx.xxxx	Dodána dokumentace k nabízenému systému.
Req_180	Funkční	Souborové přenosy	Z hlediska souborových přenosů komponenta musí umožnit připojit se na sdílené úložiště poskytovatele i konzumenta: - Souborové přenosy musejí být zabezpečeny pomocí SFTP protokolu - Sdílené úložiště může být typově NFS, FS, mounted storage, ...	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci předvedení designeru služeb a modelování integračních služeb byla ukázána i komponenta SFTP, kterou je v řešení souborový přenos zajišťován. V rámci předvedení designeru služeb a modelování integračních služeb byla ukázána i komponenta SFTP, kterou je v řešení souborový přenos zajišťován. DOPROVĚŘENO v dokumentaci: This component provides access to remote file systems over the FTP and SFTP protocols. (podporuje jak pro consumera, tak pro poskytovatele) xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx	Ukázka v DEMO
Req_181	Funkční	Souborové přenosy	Souborové přenosy logují specificky verzi přenášeného souboru.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	V rámci designu integrační služby lze ke komponentě určené na zpracování souborů nastavit i požadované logování na základě specifikace, kde daná informace k logování je např. přidáním další komponenty s vytvořeným java kódem s využitím existující komponenty třetí strany. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx/xxx-xxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxx/xxxx-xxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxxx.xxx/xxxxxxxx/xxxx-xxxxxxx-xxxx-xxxx-xxxxxx	Dodána dokumentace k nabízenému systému.
Req_182	Funkční	Vývoj služeb	Komponenta umožňuje grafické modelování vazeb a atributů jednotlivých bloků služby/operací.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	V rámci předvedení DEMO verze a Service Designeru pro modelování bylo předvedeno modelování vazeb. Záložka “Integration Pattern“ umožňuje v grafické podobě vytvářet a zobrazovat vazby jednotlivých komponent IS, systémů(Consumer) a služeb systémů(Provider) a následně jednotlivé komponenty konfigurovat s tím, že dále je ještě možné nastavovat sekvence v rámci Route Designeru (v dokumentaci 5.2 Modul "Service Designer" - část Integration Pattern - Design IS, Route Designer).	Dodána dokumentace k nabízenému systému.
Req_183	Funkční	Vývoj služeb	Komponenta SDK (software development kit) umožňuje rozšířit vývoj služby o komplexnější úlohy voláním custom javacode třídy.	NE	Vysoká	Nativní součást	Ukázka v dokumentací	10	Splňuje	Řešení umožňuje volání java kódu v rámci routy, kdy je možné provádět editaci přímo v souboru routy, lze si i načíst již vytvořený kód z uložiště a upravit např. z pohledu odkazů na java knihovny, ... (5.2 Modul "Service Designer" - část "Route designer" - Change file).	Dodána dokumentace k nabízenému systému.
Req_184	Funkční	Vývoj služeb	Komponenta SDK (software development kit) se integruje s centrálním source code repository zadavatele a je možné ji napojit na automatizované IT delivery nástroje (kontinuální integrace, build).	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Komponenta pro automatický buil a nasazení řešena v rámci Service Repository (katalogu služeb), ukázáno vytvoření image (verze) včetně automatických kontrol (varování, chyby ve službě), vysvětlení stavů, verze služby lze nasadit pouze ve stavu final, kdy není v integrační službě žádná nepropustná chyba.	Ukázka v DEMO
Req_185	Funkční	Vývoj služeb	Řešení podporuje model-driven development s cílem výrazně snížit primární zátěž na vývojáře.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci předvedení designeru služeb bylo ukázáno modelování integračního scénáře jako komponentního diagramu s celým integračním flow formou drag and drop a následnou konfigurací jednotlivých komponent v rámci obrazovek s detaily.	Ukázka v DEMO
Req_186	Funkční	Vývoj služeb	Komponenta umožňuje distribuovaný vývoj služeb.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Komponenta pro automatický buil a nasazení řešena v rámci Service Repository (katalogu služeb), ukázka vytváření nejen nových verzí, ale i nových revizí, ukázána práce s verzemi (správa verzí a revizí).	Ukázka v DEMO
Req_187	Funkční	Vývoj služeb	Komponenta musí zajistit validaci veškerých artefaktů a konfigurací, jež reprezentují vývoj služby tak, aby byla zajištěna normalizace a stabilita vývoje.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Komponenta pro automatický buil a nasazení řešena v rámci Service Repository (katalogu služeb), ukázka provedení automatického buildu a následné zobrazení provedených kontrol na službě během buildu (varování - propustné chyby, výstraha - nepropustné chyby).	Ukázka v DEMO
Req_188	Funkční	Vývoj služeb	Komponenta umožňuje přehledný reporting změn nad konkrétními službami (development journal/auditní logování vývoje).	ANO	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci ukázky testování služby byl předveden nástroj Grafana pro journaling. Bylo ukázáno trasování běhu služby (jednotlivé části trasování), zpracován request, vrácen response. Dále byla předvedena ze Service Repository (katalogu služeb) možnost zobrazení auditního logu ke službám.	Ukázka v DEMO
Req_189	Funkční	Vývoj služeb	Service Deployment - Management Řešení musí umožňovat práci se službami bez nadbytečné a složité konfigurace, aby bylo možné například opravy chyb nasazovat v co nejkratším čase.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci ukázky Service Repository (katalogu služeb) a automatického buildu předvedeno vytváření nové verze s provázáním na Service Designer, s možností úprav služby, nového buildu včetně nasazení na požadované prostředí.	Ukázka v DEMO
Req_190	Funkční	Vývoj služeb	APIs Versioning Řešení podporuje transparentní verzování služeb.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci ukázky Service Repository (katalogu služeb) byl předveden přehled vytvořených služeb včetně jejich verzí, detaily k verzování služeb včetně předvedení práce s verzemi. V rámci ukázky API managementu bylo v administraci Consumer Secrets ukázáno verzování a hlídání nasazení pouze jedné verze na prostředí.	Ukázka v DEMO
Req_191	Funkční	Vývoj služeb	New APIs Version Notification Řešení podporuje mechanizmus notifikací uživatelů o nových verzích rozhraní.	NE	Střední	Nativní součást	Ověření v DEMO	8	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Předvedeno nasazování služeb na jednotlivá prostředí. Je řešeno formou zpráv se zobrazováním počtu zpráv na ikoně zvonečku. Po přečtení zpráva zmizí.	Ukázka v DEMO
Req_192	Funkční	Vývoj služeb	API Testing Řešení musí poskytovat možnost k podpoře testování vystavených služeb proti backendům, popř. vystaveným mockům.	NE	Střední	Nativní součást	Ukázka v dokumentací	8	Splňuje	Bylo předvedeno v rámci DEMO a testování (nastavení v aplikaci SoapUI).	Ukázka v DEMO
Req_193	Funkční	Webové služby	Z hlediska webových služeb řešení musí podporovat komunikaci na webových technologiích - SOAP v 1.1, 1.2 definice pomocí xml/wsdl artefaktů.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Ukázáno v rámci předvedení demo v dokumentaci Apache Camel, že je SOAP podporován, využití komponent CXF. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.00.x/xxxxxxxxxxx/xxxxxxxx-xxxxxxxxxx.xxxx	Ukázka v DEMO
Req_194	Funkční	Webové služby	Z hlediska webovych služeb řešení musí podporovat komunikaci na webových technologiích - REST definice pomocí json/openApi či swagger	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Ukázáno v rámci předvedení demo v dokumentaci Apache Camel, že je REST podporován. xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxx-xxxxxxxxx.xxxx xxxxx://xxxxx.xxxxxx.xxx/xxxxxxxxxx/0.0.x/xxxx-xxxxxxx-xxxxxxxxx.xxxx	Ukázka v DEMO

Req_195	Funkční	Webové služby	Z hlediska webovych služeb musí řešení umožňovat typy webových služeb - Proxy služby = 1 poskytovatel, N konzumentů, unifikace služby, validace.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Předvedeno v designeru služeb, kde bylo ukázáno modelování integračního scénáře s 1 poskytovatelem a více konzumenty, ukázána možnost kopírování kódu existující služby pro vznik nových proxy služeb. Validace byla předvedena v rámci buildu a nasazování integrační služby.	Ukázka v DEMO
Req_196	Funkční	Webové služby	Z hlediska webovych služeb musí řešení umožňovat typy webových služeb - Kompozitní služby = N poskytovatelů, M konzumentů, překlady, transformace, mapování, není doporučováno do kompozitních služeb implementovat business logiku.	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Předvedeno v designeru služeb, kde bylo ukázáno modelování integračního scénáře i s více poskytovateli a upozorněno, že jde o složitější logiku – i ukázka v kódu v rámci kódu routy. Překlady vysvětleny v rámci použití různých typů volání na straně konzumentů. Transformace ukázána v rámci ověření požadavku Req_198 Xxxxx –> REST.	Ukázka v DEMO
Req_197	Funkční	Webové služby	Z hlediska webových služeb musí řešení umožňovat typy webových služeb - Service bus = integrační sběrnici, kde mohou poskytovatelé vystavovat služby a konzumenty libovolně konzumovat.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO V rámci předvedení API Managementu byl ukázán přehled vystavených služeb v administraci Consumer Secrets včetně nastavení pro jednotlivá prostředí a detailu. Dále bylo ukázáno související nastavení paramentrů pro throttling na consumery a v katalogu služeb na API.	Ukázka v DEMO
Req_198	Funkční	Webové služby	Z hlediska webových služeb řešení musí umožňovat typy transakcí přes webové služby: - Synchronních přenos (sekvenční Request --> Response), - Asynchronní přenos (Request, zpracování, Response).	NE	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: ANO Ukázáno použití dostupných komponent v rámci Apache Camel: - Xxxxx (synchronní přenos), - AMQP (asynchronní přenos).	Ukázka v DEMO
Req_199	Funkční	Webové služby	Z hlediska webových služeb řešení musí obsahovat komponenty pro vnější komunikaci typu ESB B2B, B2C gateway.	ANO	Vysoká	Nativní součást	Ověření v DEMO	10	Splňuje	PŘEDVEDENO v rámci DEMO: Předvedeno v rámci Service Designeru v konfiguraci komponenty APIM (využití DMZ - nastavení externí API).	Ukázka v DEMO
Celkové hodnocení								1704

Katalog služeb pro informační systém

„Integrační platforma“

Obsah

1. Úvod 3

2. Základní parametry poskytování služeb 3

2.1. Způsob poskytování služeb 3

2.2. Způsob zadávání požadavků, implementace aktualizací a vývoje 3

2.3. Priority řešení požadavků z poskytovaných služeb 5

3. Popis služeb 6

3.1. Servisní služby 6

3.2. Vývojové a konzultační služby (podpora na objednání) 7

1. Úvod

Dokument obsahuje konkrétní popis jednotlivých servisních služeb podpory (licenční i provozní), vývojových a konzultačních služeb pro informační systém integrační platformy v prostředí implementace, jejich nastavení, pravidla provozu a způsobu hodnocení.

Zadavatel (objednatel) a současně provozovatel integrační platformy je Univerzita Hradec Králové.

Poskytovatel je firma zajišťující služby související s provozem integrační platformy, které vyžadují větší míru odbornosti.

2. Základní parametry poskytování služeb

2.1. Způsob poskytování služeb

Pro servisní služby související s provozováním a rozvojem informačního systému integrační platformy jsou definovány následující úrovně podpory se stanovením strany, která danou úroveň zajišťuje:

Úroveň podpory	Popis	Zajištění
L1	Komunikace s koncovými uživateli (sběr požadavků různých typů: incident, problém, požadavek na změny, požadavek na informaci apod.) a řešení jednoduchých problémů, které zvládnou zajistit zaškolení administrátoři systému. Prověřené požadavky, které nejsou vyřešeny na této úrovni, předá odpovědná osoba na straně zadavatele k řešení úroveň L2.	Zadavatel (Oddělení informačních technologií)
L2	Řešení složitějších problémů nevyřešených na úrovni L1 a poskytování podpory administrátorům systému. Pravidelná údržba systému, instalace aktualizací a nových verzí (Service Pack, Patch, Hot Fix, Update, Upgrade) dodaného softwarového řešení. Řešení problémů nevyřešených na úrovni L2 s výrobcem softwaru a s výrobci souvisejících softwarových komponent.	Poskytovatel služeb
Licenční a L3 technická podpora	Rozvoj a aktualizace informačního systému a všech souvisejících softwarových komponent, řešení incidentů a závad na úrovni L3 (problémů nevyřešených na úrovni L2).	Poskytovatel služeb
Na objednání	Požadavky na rozvoj dodaného řešení, zejména na vývoj integračních služeb/propojení a požadavky na odborné konzultace.	Poskytovatel služeb

2.2. Způsob zadávání požadavků, implementace aktualizací a vývoje Požadavky zadává jak zadavatel, tak poskytovatel s ohledem na poskytovanou službu. Poskytovatel je v rámci reakční doby na zahájení řešení požadavku vždy povinen v reakci:

• uvést osoby zodpovědné za řešení požadavku, aby zadavatel věděl, s kým komunikuje;

• nastavit termín plnění dle zadané priority požadavku s tím, že v případě nesrovnalostí je možné prioritu se souhlasem zadavatele změnit (např. bude existovat náhradní dočasný způsob řešení, o kterém zadavatel nevěděl).

Podle jednotlivých poskytovaných služeb jsou požadavky zadávány následujícím způsobem:

Služba	Vznik požadavku a způsob zadání	Reakční doba na zahájení řešení
Licenční podpora a L3 technická podpora	Poskytovatel informuje zadavatele o uvolnění programových oprav a úprav; aktuální, nové verze výrobcem k instalaci jedním z těchto způsobů: - zadáním požadavku do aplikace poskytovatele typu „Service Desk“, která je zadavateli zpřístupněna, preferovaný způsob zadávání požadavků; - e-mailem na adresu: xxxxxx.xxxxxxxxx@xxx.xx - telefonicky na: 735 702 314 V případě jak zadání požadavku, tak jeho změny budou zadavateli chodit mailové notifikace.	Do konce následujícího pracovního dne ode dne uvolnění výrobcem softwaru (Service Pack, Patch, Hot Fix, Update, Upgrade) nebo do konce následujícího pracovního dne ode dne uvedení do provozu první funkční služby/propojení
Provozní L2 podpora	Zadavatel nahlásí provozní požadavek jedním z těchto způsobů: - zadáním požadavku do aplikace poskytovatele typu „Service Desk“, která je zadavateli zpřístupněna, preferovaný způsob zadávání požadavků; - e-mailem na adresu: xxxxxxx@xxxxxxx.xxx - telefonicky na: 724 167 110 V případě jak zadání požadavku, tak jeho změny budou zadavateli chodit mailové notifikace.	Do konce následujícího pracovního dne od nahlášení požadavku
Vývojové a konzultační služby (podpora na objednání)	Zadavatel poptá vývojové nebo konzultační služby jedním z těchto způsobů: - zadáním požadavku do aplikace poskytovatele typu „Service Desk“, která je zadavateli zpřístupněna, preferovaný způsob zadávání požadavků; - e-mailem na adresu: xxxxxxx@xxxxxxx.xxx - telefonicky na: 724 167 110 Poskytovatel v součinnosti se zadavatelem stanoví rozsah člověkodní. Zadavatel vystaví objednávku a odešle jedním z těchto způsobů: - datovou schránkou; - e-mailem na adresu: xxxxxx@xxxxxxx.xxx, - v tištěné podobě na adresu poskytovatele uvedenou v servisní smlouvě. Poskytovatel zadavatele informuje o akceptaci objednávky.	30 pracovních dní od data akceptace objednávky

2.3. Priority řešení požadavků z poskytovaných služeb

Podle dopadu na provozování systému integrační platformy jsou pro poskytování služeb stanoveny následující termíny plnění, které běží od konce reakční doby na zahájení řešení:

Priorita	Popis požadavku	Termín plnění (doba vyřešení)
1 - Kritická	• Provozní požadavek s typem závady, která brání provozu integrační platformy (bezpečnostní hrozby, chyby komponent, nefunkční auditní nebo transakční logování, chyby poškozující data atp.), pro kterou není systém integrační platformy použitelný ve svých základních funkcích. Není možné pokračovat ve standardním používání a neexistuje dostupný náhradní způsob. • Implementace programových oprav a úprav, aktuálních, nových verzí obsahující úpravy pro kritické funkce systému, pro řešení bezpečnostních hrozeb a pro včasné naplnění legislativních podmínek (Service Pack, Patch, Hot Fix, Update, Upgrade).	3 pracovní dny
2 - Vysoká	• Provozní požadavek s typem závada, která omezuje běžný provoz integrační platformy, tuto situaci je však možné řešit nebo zmírnit dostupným náhradním způsobem. Nebo závada, která způsobuje vážné zhoršení výkonnosti integrační platformy. • Implementace programových oprav a úprav, aktuálních, nových verzí s uvedeným typem závady.	7 pracovních dní
3 - Střední	• Provozní požadavek s typem závada, která svým charakterem neovlivňuje významným způsobem běžný provoz integrační platformy, nepoškozuje data, omezuje některé uživatelské funkce systému, které jsou ale dosažitelné jinými uživatelskými funkcemi nebo brání realizaci nových nebo úpravě existujících integračních služeb/propojení. • Implementace programových oprav a úprav, aktuálních, nových verzí s uvedeným typem závady.	15 pracovních dní
4 - Nízká	• Provozní požadavek bez vlivu na funkčnost systému v rámci provozní podpory, který nebrání provozování integrační platformy - např. chyby v dokumentaci, žádost o poradenství k implementaci integrační platformy, žádost o poskytnutí odborné konzultace v souvislosti se změnami a rozvojem podnikové architektury zadavatele v rozsahu poskytování servisních služeb. • Implementace aktuálních, nových verzí obsahující vylepšení a aktualizace.	30 pracovních dní
5 - Vývoj	• Vývojové a konzultační služby.	objednávkou stanovený počet člověkodní
6 - Bez vlivu	• Návrhy, připomínky nebo náměty na zlepšení či rozvoj.	-

Pro servisní služby (požadavky s prioritou 1 až 4) do 5. pracovního dne ukončení fakturačního období předá poskytovatel plnění formou výkazu služeb, ve kterém budou uvedeny provedené služby se stanovenou prioritou a s daty, ze kterých bude vyplývat plnění reakční doby a doby vyřešení.

3. Popis služeb

3.1. Servisní služby

Podpora k dodanému informačnímu systému integrační platformy včetně dodaných souvisejících komponent (mimo jiné i dodaného databázového systému, pokud nebyl součástí poskytnuté provozní infrastruktury objednatele) v prostředí zadavatele, musí minimálně zahrnovat:

a) licenční podporu včetně L3 technické podpory výrobce software a výrobců souvisejících softwarových komponent (tzn. údržbu systému/maintenance):

o průběžné a bezodkladné opravy chyb, opravné kódy pro informační systém integrační platformy i související softwarové komponenty;

o průběžné a bezodkladné poskytování programových korekcí a aktualizací (Service Pack, Patch, Hot Fix) pro informační systém integrační platformy i související softwarové komponenty;

o průběžné poskytování aktuálních, nových verzí (Update i Upgrade) informačního systému integrační platformy i souvisejících softwarových komponent;

o poskytování přístupu k dokumentaci systému integrační platformy i souvisejících komponent;

Všechny programové korekce, aktualizace, aktuální i nové verze musí být provedeny tak, aby byla vždy zajištěna plná kompatibilita všech komponent potřebných pro provozování integrační platformy i plná kompatibilita s integrovanými systémy zadavatele na straně systému integrační platformy.

b) L2 provozní podporu v pracovní dny od 8 do 16 hodin,

s reakcí do konce následujícího pracovního dne (tj. reakční doba) od zadání požadavku zadavatelem nebo od uvolnění programových korekcí a aktualizací, nové verze integrační platformy a souvisejících komponent, anebo do konce následujícího pracovního dne ode dne aktivace servisních služeb podpory,

s vynaložením maximálního možného úsilí a učiněním všech možných opatření, která povedou k nejlepšímu možnému výsledku a předejdou zbytečným škodám:

o vedení evidence požadavků/incidentů;

o specializovaná podpora zpracování požadavků/incidentů z provozu integrační platformy (tj. odstranění chyb a mimořádných stavů) na úrovni L2:

• přebírání požadavků z provozní úrovně L1,

• řešení problémů naimplementovaného informačního systému integrační platformy a souvisejících softwarových komponent,

• kontrola běhu provozovaných služeb,

o zpracování požadavků na úrovni L3 (nevyřešených na úrovni L2) a zajištění potřebných oprav na straně výrobce softwaru s tím, že zadavatel bude informován o řešených incidentech a o hlášených chybách na L3 technickou podporu výrobce;

o odborné poradenství ve vztahu k implementaci integrační platformy;

o sledování výrobcem uvolněných programových korekcí a aktualizací, aktuálních nových verzí systému integrační platformy i souvisejících softwarových komponent;

o implementace uvolněných programových korekcí a aktualizací, aktuálních nových verzí systému integrační platformy i souvisejících softwarových komponent v prostředí zadavatele, kterou poskytovatel zajistí následujícím způsobem:

1. Poskytovatel bezodkladně informuje zadavatele o uvolnění nové/nových verze/verzí nebo programové/programových korekce/korekcí a upozorní na možná rizika instalace (poskytovatel zpracuje informační dokument s informacemi o provedených změnách včetně popisů dopadů zavedení změn); navrhne možné termíny instalace do testovacího prostředí zadavatele a časový harmonogram.

2. Zadavatel potvrdí nebo s poskytovatelem dohodne jiný pro obě strany akceptovatelný termín pro instalaci a poskytne nezbytnou nutnou součinnost.

3. Poskytovatel provede instalaci do testovacího prostředí zadavatele a dodá testovací scénáře pro akceptační testování.

4. Poskytovatel otestuje ve spolupráci se zadavatelem funkčnost systému integrační platformy (fungování nasazené nové verze nebo programových korekcí) včetně ověření funkčnosti integračních služeb pro integrované systémy zadavatele.

5. Po provedení úspěšného akceptačního testování dohodne poskytovatel se zadavatelem datum a čas instalace na produkční prostředí.

6. Poskytovatel zajistí doplnění související dokumentace a proškolí uživatele (administrátory).

7. Poskytovatel provede instalaci na produkční prostředí zadavatele, ověří funkčnost systému a informuje zadavatele o provedení úspěšné instalace (notifikace o provedených změnách).

3.2. Vývojové a konzultační služby (podpora na objednání)

Vývoj integračních služeb a technické konzultace je realizováno formou objednávek od zadavatele, zadaných na základě poptávky od zadavatele a poskytovatelem dodaného závazného nacenění v člověkodnech pro v poptávce zadaný rozsah prací včetně návrhu časového harmonogramu realizace.

Po dodání nacenění a návrhu časového harmonogramu realizace zadavatel potvrdí nebo s poskytovatelem dohodne jiné pro obě strany akceptovatelné podmínky a vystaví objednávku. Poskytovatel potvrdí přijetí objednávky a objednávku akceptuje.

Realizace vývoje integračních služeb bude zajištěna následujícím způsobem:

1. Poskytovatel zahájí vývojové práce (analýza, design, vývoj služeb) dle časového harmonogramu a zadavatel poskytne nezbytnou nutnou součinnost.

2. Po dokončení vývojových prací provede poskytovatel nasazení služeb do testovacího prostředí zadavatele a dodá testovací scénáře pro akceptační testování.

3. Poskytovatel otestuje ve spolupráci se zadavatelem funkčnost dodaných integračních služeb včetně ověření funkčnosti pro dotčené integrované systémy zadavatele.

4. Po provedení úspěšného akceptačního testování dohodne poskytovatel se zadavatelem datum a čas nasazení na produkční prostředí.

5. Poskytovatel zajistí aktualizaci integračního modelu a doplnění související dokumentace, dodá informační dokument o změnách a proškolí uživatele (administrátory).

6. Poskytovatel provede nasazení na produkční prostředí zadavatele, ověří funkčnost integračních služeb a informuje zadavatele o provedení úspěšné instalace (notifikace o provedených změnách).

7. Zadavatel podepíše akceptační protokol o dokončení objednaných vývojových služeb.

Pro technické konzultace poskytovatel zrealizuje objednané služby dle dohodnutého harmonogramu a odpovědná osoba mu potvrdí jejich realizaci (notifikace o provedení konzultací).

Podpora vývoje integračních služeb/propojení a s tím souvisejících technických konzultací k dodanému informačnímu systému integrační platformy v prostředí zadavatele, musí být poskytovatelem zajištěna minimálně v těchto oblastech:

a) vývoj a úprava integračních služeb/propojení systémů, kdy poskytovatel zajistí:

o analýzu business požadavků a zpracování návrhu řešení,

o tvorbu detailního designu,

o vývoj služeb,

o součinnost při tvorbě testovacích scénářů,

o nasazení služeb do testovacího prostředí,

o testování služeb a provedení akceptačního testování v součinnosti se zadavatelem,

o poskytnutí součinnosti pro testování zajištěných třetími stranami či zadavatelem (např. bezpečnostní testování, výkonnostní testování),

o aktualizaci integračního modelu a tvorbu související dokumentace,

o zpracování informačního dokumentu s informacemi o provedených změnách včetně popisů dopadů zavedení změn na integrované systémy dotčené změnami,

o předání zdrojových kódů,

o nasazení služeb do produkčního prostředí.

b) technických konzultací pro tvorbu integračních propojení zadavatelem, pro úpravy nastavení a správu integrační platformy zahrnují:

o architektonické konzultace,

o služby integračního architekta,

o služby posouzení designu integrací a plánovaných změn v informačním prostředí zadavatele včetně jejich dopadu na integrační platformu.

Maximální možná pracnost v člověkodnech na tvorbu nových integračních služeb, zahrnující všechny činnosti poskytované služby „vývoje a úprav integračních služeb/propojení systémů“, je pro nacenění dána touto kategorizací integračních služeb (Maximální pracnost je stanovena na základě „Specifikace nabídkové ceny.xlsx“ v části „Tvorba/vývoj integračních služeb“.):

Kategorie integračních služeb		Max. pracnost	Definice kategorie integračních služeb
1.	Jednoduchá integrační služba	3	Integrační služba bez složitých struktur a datových transformací, která se obvykle označuje jako "proxy služba". Tato služba je zpravidla synchronní a je většinou postavena na technologiích REST a SOAP. Obvykle jedna služba s jednou operací.
2.	Středně složitá integrační služba	5	Integrační služba, která obsahuje základní datové transformace nebo technologické transformace (např. REST to SOAP). Dále v ní je zahrnuto routování zpráv na různé konzumenty dle atributu v hlavičce zprávy (zpráva může obsahovat integrační hlavičku).

3.	Složitá integrační služba	8	Integrační služba, která vždy obsahuje integrační hlavičku, lze ji dynamicky routovat dle obsahu nebo payloadu služby. Dále v ní jsou zahrnuty datové a technologické transformace složitějších typů (například mapování konstant ze systému KeyManagementSystem). Případně se může jednat o službu s větším množství operací.
4.	Kompozitní/ komplexní integrační služba	10	Integrační služba, která obsahuje kompozitní služby, které jsou založeny na patternu agregace dat, podmíněného volání, opakovaného volání nebo výlučného volání. Dále se může jednat o asynchronní službu postavené na messagingu (Apache Xxxxx, AMQ) a ETL procesy pro batchové zpracování.
5.	Procesní integrační služba	20	Integrační služba, která realizuje state-full BPM procesy, které využívají persistentní vrstvu pro ukládání stavu procesu a jeho obsahu. V rámci této služby lze také implementovat rozhodovací pravidla pro průchod procesem a jejich podmínky.

Specifikace nabídkové ceny
1. Licence pro integrační platformu, implementace a instalace (pro testovací i produkční prostředí)
Software - licence, implementace a instalace		Počet jednotek potřebných pro provoz (testovací a produkční prostředí) doplněný dodavatelem	Cena za jednotku nabídnutá dodavatelem (v Kč bez DPH)	Cena celkem (v Kč bez DPH)
1.	Věcně a časově neomezená licence pro integrační platformu (včetně bezplatné licenční podpory do 31.12.2024)	1	700 000 Kč	700 000 Kč
2.	Implementace systému infrastruktury a instalace IP, poskytnutí školení administrátorům a zpracování kompletní dokumentace (včetně následné aktualizace všech komponent k datu uvedení do provozu první funkční služby/propojení)	1	400 000 Kč	400 000 Kč
3.	Související systémové softwarové vybavení či komponenty, včetně všech souvisejících licencí a služeb potřebných k zavedení a provozu IP (nad rámec poskytnuté infrastruktury zadavatele) - popis komponent doplněný dodavatelem.	1	0 Kč	0 Kč
	Náklady celkem			1 100 000 Kč
2. Podpora integrační platformy (licenční a provozní)
Podpora		Počet měsíců	Cena za měsíc nabídnutá dodavatelem (v Kč bez DPH)	Cena celkem (v Kč bez DPH)
1.	Licenční podpora a L3 technická podpora výrobce za měsíc	12	10 417 Kč	125 004 Kč
2.	L2 provozní podpora dodavatelem - paušál za měsíc	12	12 500 Kč	150 000 Kč
3.	L2 provozní podpora dodavatelem - pro jednu funkční integrační službu provozovanou na produkčním prostředí za měsíc	12	660 Kč	7 920 Kč
	Náklady celkem		23 577 Kč	282 924 Kč
3. Vývoj integračních služeb/propojení a technické konzultace
Rozvoj		Předpokládaný počet MD	Jednotková cena (člověkoden) nabídnutá dodavatelem (v Kč bez DPH)	Cena celkem (v Kč bez DPH)
1.	Vývoj integračních služeb/propojení a technické konzultace	45	12 500 Kč	562 500 Kč
	Náklady celkem			562 500 Kč
CELKOVÁ NABÍDKOVÁ CENA (v Kč bez DPH)				1 945 424 Kč
Tvorba/vývoj integračních služeb - závazné počty člověkodní (MD) pro jednotlivé kategorie služeb
Pracnost v MD udává max. pracnost na vývoj služby v dané kategorii a zahrnuje: analýzu business požadavků a zpracování návrhu řešení, tvorbu detailního designu, vývoj služeb, tvorbu testovacích scénářů, testování služeb a provedení akceptačního testování v součinnosti se zadavatelem, poskytnutí součinnosti pro zajištění testování třetími stranami, aktualizaci integračního modelu a tvorbu související dokumentace, zpracování "release notes" a nasazení nové služby do testovacího prostředí i do produkčního prostředí.
Kategorie integračních služeb		Počet služeb "Modelový příklad"	Max. pracnost za jednu službu dané kategorie nabídnutá dodavatelem v MD	Pracnost celkem "Modelový příklad"	Definice kategorie integračních služeb
1.	Jednoduchá integrační služba	20	3	60	Integrační služba bez složitých struktur a datových transformací, která se obvykle označuje jako "proxy služba". Tato služba je zpravidla synchronní a je většinou postavena na technologiích REST a SOAP. Obvykle jedna služba s jednou operací.
2.	Středně složitá integrační služba	7	5	35	Integrační služba, která obsahuje základní datové transformace nebo technologické transformace (např. REST to SOAP). Dále v ní je zahrnuto routování zpráv na různé konzumenty dle atributu v hlavičce zprávy (zpráva může obsahovat integrační hlavičku).
3.	Složitá integrační služba	5	8	40	Integrační služba, která vždy obsahuje integrační hlavičku, lze ji dynamicky routovat dle obsahu nebo payloadu služby. Dále v ní jsou zahrnuty datové a technologické transformace složitějších typů (například mapování konstant ze systému KeyManagementSystem). Případně se může jednat o službu s větším množství operací.
4.	Kompozitní/ komplexní integrační služba	2	10	20	Integrační služba, která obsahuje kompozitní služby, které jsou založeny na patternu agregace dat, podmíněného volání, opakovaného volání nebo výlučného volání. Dále se může jednat o asynchronní službu postavené na messagingu (Apache Xxxxx, AMQ) a ETL procesy pro batchové zpracování.
5.	Procesní integrační služba	1	20	20	Integrační služba, která realizuje state-full BPM procesy, které využívají persistentní vrstvu pro ukládání stavu procesu a jeho obsahu. V rámci této služby lze také implementovat rozhodovací pravidla pro průchod procesem a jejich podmínky.
Součty pro "Modelový příklad"		35		175

Hodnoty vstupující do jednotlivých hodnocení kritéria "HODNOTA"

i) Hodnota za licence, implementaci a instalaci integrační platformy

Celková hodnota (v Kč bez DPH)

1 100 000 Kč

ii) Hodnota za podporu (licenční a provozní)

Celková měsíční hodnota (bez DPH) se zohledněním počtu propojení/služeb z "modelového příkladu"

(tzn. cena za měsíční licenční podporu + paušál za provozní podporu + cena za provozní podporu pro jednu integrační službu vynásobenou celkovým počtem služeb z "modelového příkladu" )

46 017 Kč

iii) Hodnota za vývoj integračních služeb/propojení a technické konzultace

Celková hodnota (bez DPH) pro "modelový příklad"

(tzn. jednotková cena za MD vynásobená celkovou pracností z "modelového příkladu" )

2 187 500 Kč

Realizační tým

Role	Člen týmu Dodavatele	Tel. kontakt	Email
Infrastrukturní architekt	Xxx. Xxxxx Xxxxxxxxxx	x000 000 000 000	Xxxxx.xxxxxxxxxx@physter. com
Infrastrukturní specialista	Xxx. Xxxxx Xxxxxx	x000 000 000 000	Xxxxx.xxxxxx@xxxxxxx.xxx
Integrační specialista/vývojář	Xxx. Xxxxxx Xxxxx	x000 000 000 000	Xxxxxx.xxxxx@xxxxxxx.xxx