PODMÍNKY PRO PŘIPOJENÍ AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO INFORMAČNÍHO SYSTÉMU ZÁKLADNÍCH REGISTRŮ
PODMÍNKY PRO PŘIPOJENÍ AGENDOVÝCH INFORMAČNÍCH SYSTÉMŮ DO INFORMAČNÍHO SYSTÉMU ZÁKLADNÍCH REGISTRŮ
VERZE 2. 08
OBSAH
1. Úvod 8
1.1 Smysl a účel ZR 9
1.2 Legislativní rámec pro oblast ZR 9
2. Definice základních pojmů 13
2.1 Rozdíl mezi referenčními a informačními údaji 14
2.2 Zkratky 15
3. Základní principy interakce mezi AIS a ISZR 17
3.1 Komunikační schéma pro využívání služeb eGON 17
3.2 Současné IS používané pro výkon agend OVM 18
3.3 Možné způsoby komunikace AIS s ISZR 19
3.3.1 Využití centrálních AIS 19
3.3.2 Zapojení lokálních AIS 20
3.3.3 Autentizace a identifikace uživatelů přiřazených k agendě 24
3.4 Obsah informací na eGON rozhraní 25
3.4.1 Poskytování výstupů 25
3.4.2 Zápis údajů 25
3.5 Přístup k eGON rozhraní ISZR 25
3.5.1 Katalog eGON služeb 26
3.5.2 Identifikace volajícího při volání eGON služeb 26
3.5.3 Přístup z AIS k datům ZR prostřednictvím eGON služeb 26
3.6 Identifikace požadavku ze strany AIS 27
3.6.1 Identifikace požadavku v AIS 28
3.6.2 Identifikace požadavku v ISZR 28
3.7 Režimy eGON služeb 29
3.7.1 Synchronní režim eGON služeb 29
3.7.2 Asynchronní režim eGON služeb 30
3.8 Lokální data AIS 30
3.9 Údaje z RÚIAN 32
3.10 Poskytování dat 32
3.11 Bezpečnost / blokování AIS 33
4. Obecné vlastnosti eGON služeb 34
4.1 Priorizace služeb 34
4.2 Serializace požadavků 34
4.3 Opakované volání služby při omezení dat 35
4.4 AIFO – algoritmus generování 35
5. Obecná definice procesů 35
5.1 Chování AIS pro použití eGON služeb a lokálních dat 35
5.2 Hromadná distribuce změn 36
5.3 Stav AIFO ve výsledku služeb – přidělené a zrušené AIFO 37
5.3.1 Přiděleno nové AIFO 37
5.3.2 Zrušené AIFO 37
6. Specifikace aktivit a postupů při výkonu agend OVM 38
6.1 Činnosti AIS pro čtení informací ze ZR 39
6.1.1 Ověření totožnosti občana dle dokladu (ROB) 39
6.1.2 Ztotožnění občana v AIS s obyvatelem v ROB 41
6.1.3 Dotaz na občana (ROB) 42
6.1.4 Dotaz na osobu (ROS) 43
6.1.5 Dotaz na adresní místo (RÚIAN) 44
6.1.6 Notifikace ROB 45
6.1.7 Přihlášení k notifikacím ROB 46
6.1.8 Vyzvednutí aktuálních údajů dle notifikace ROB 47
6.1.9 Odhlášení z notifikací ROB 47
6.1.10 Vyzvednutí aktuálních údajů dle notifikace ROS 48
6.1.11 Vyzvednutí aktuálních údajů dle notifikace RÚIAN 49
6.1.12 Vyzvednutí aktuálních údajů dle notifikace ORG 49
6.1.13 Vyzvednutí aktuálních údajů dle notifikace RPP 50
6.2 Sdílené funkce AIS pro podporu výkonu agend OVM 52
6.2.1 Práce s číselníky 52
6.2.2 Asynchronní služby a výstupní fronta 52
6.2.3 Nakládání s AIFO po přidělení 55
6.2.4 Nakládání s AIFO po zrušení 56
6.2.5 Nakládání s AIFO při kompromitaci 57
6.2.6 Pravidelná distribuce změn 57
6.2.7 Lokální inicializace dat z RÚIAN 58
6.2.8 Referenční odkazy do RÚIAN 59
6.2.9 Výpis veřejných údajů z RÚIAN 59
6.2.10 Vyslání podnětu k reklamaci údajů 60
7. eGON - webové služby 61
7.1 Principy eGON webových služeb ISZR 61
7.1.1 Společný katalog datových typů 62
7.1.2 Struktura zprávy na eGON rozhraní 62
7.2 Popis rozhraní eGON služeb 62
7.3 Členění eGON služeb 63
7.3.1 eGON služby – editační 63
7.3.2 eGON služby – dotazovací 63
7.3.3 eGON služby – reklamační 64
7.3.4 eGON služby – servisní 65
8. Dodatečné specifikace k eGON službám 66
8.1 E05 - robCtiPodleUdaju 66
8.1.1 Přehled minimálních kombinací povinných parametrů dotazu 66
9. Technický popis 68
9.1 Obecné principy 68
9.1.1 Způsob popisu rozhraní 68
9.1.2 Verzování popisu rozhraní 68
9.2 Společný katalog datových typů – RegTypy.xsd 69
9.2.1 Typ AifoType 71
9.2.2 Typ MapaAifoType 71
9.2.3 Typ SeznamIdAdresType 73
9.3 Struktura zprávy na eGON rozhraní 73
9.3.1 Systémová část dotazu (request AIS -> ISZR) 74
9.3.2 Systémová část odpovědi (response ISZR -> AIS) 79
9.4 Chybové stavy 79
9.4.1 Http chyby 80
9.4.2 Chyby SoapFault 80
9.4.3 Systémové chyby 80
9.4.4 Aplikační chyby 80
9.4.5 Definované chybové stavy 80
9.4.6 Chybové stavy serializace 81
9.4.7 Xxxxx nepovolení přístupu 81
9.5 Asynchronní služba s aktivním režimem odpovědi 82
9.5.1 Žádost o asynchronní eGON službu s aktivním režimem odpovědi 82
9.5.2 Implementace webové služby pro doručení odpovědi 83
10. Závěr 83
A. Příloha – příklady volání služeb 84
Obecná skladba XML volání a odpovědi služby 84
Požadavek 84
Odpověď 84
Vybraná volání služeb 86
Služby S1 86
Služby S2 90
Služby S3 91
Služby S4 92
Služby E 95
HISTORIE DOKUMENTU | ||
Číslo verze | Stav | Datum |
0.0.01 | Šablona dokumentu | 22.6.2011 |
0.0.05 | Rozpracovaný draft | 8.7.2011 |
0.0.07 | Draft | 9.7.2011 |
0.0.09 | Revize ISZR | 10.7.2011 |
0.0.10 | Zpracování připomínek SZR | 11.7.2011 |
0.0.18 | Zpracování připomínek architekt ISZR, architekt XXX, architekt XXX, architekt XXXXX, ISZR, ORG, ROS, RÚIAN | 18.7.2011 |
0.0.21 | Zapracování finálních připomínek | 21.7.2011 |
0.01 | Draft SZR | 21.7.2011 |
0.02 | Zapracovány připomínky RÚIAN, XXX, ORG, ROS | 28.7.2011 |
1.00 | Publikovaný dokument SZR | 31.7.2011 |
1.01 | Revize a aktualizace | 30.1.2012 |
1.02 | Revize a aktualizace | 9.3.2012 |
2.00 | Publikovaný aktualizovaný dokument | 13.4.2012 |
2.01 | Revize a doplnění dokumentu: - doplněna kap. 1.1 Smysl a účel ZR - doplněna kap. 1.2 Legislativní rámec pro oblast ZR - doplněna kap. 2.1 Rozdíl mezi referenčními a informačními údaji | 14.6.2012 |
2.02 | Revize a doplnění dokumentu: - doplněna kap. 3.1 Komunikační schéma pro využívání služeb eGON - doplněna kap. 3.2 Současné IS používané pro výkon agend OVM | 19.6.2012 |
2.03 | Revize a doplnění dokumentu: - doplněna kap. 3.3 Možné způsoby komunikace AIS s ISZR | 22.6.2012 |
2.04 | Revize a doplnění dokumentu: - rozšířena kap. 6.1 Činnosti AIS pro čtení informací ze ZR - doplněna kap. A. Příloha – příklady volání služeb | 9.7.2012 |
2.05 | Revize a doplnění dokumentu: - rozšířena kap. 6 Specifikace aktivit a postupů při výkonu agend OVM | 10.7.2012 |
2.06 | Zpřesněny formulace v kapitolách: - 3.3.1, 3.7.1, 3.7.2, 3.10, - 4.2, - 6.1.2, 6.1.6, 6.2.1, 6.2.2, 6.2.3, - 7.3.1, 7.3.2, 7.3.4, - 9.3.1, 9.4.7 | 1.8.2012 |
2.07 | Úpravy a doplnění v kapitolách: - 6.1.2.1, - 6.1.6, 6.1.6.1, - 6.1.7, - 6.1.12, 6.1.12.1, 6.1.12.2, - 6.2.4, 6.2.4.1, - 6.2.5.1, 6.2.5.2 | 31.10.2013 |
2.08 | Úpravy a doplnění o možnost přístupu AIS neregistrovaných v IS o ISVS v kapitolách: - 3.3.2, - 9.3.1, - zpřesnění v kapitole č. 1 Revize legislativy a formy dokumentu | 13.1.2017 |
1. Úvod
Účelem tohoto dokumentu je poskytnout implementátorům agendových informačních systémů (dále jen „AIS“) základní a ucelený přehled informací, které jsou potřebné pro implementaci připojení AIS k základním registrům (ZR) prostřednictvím informačního systému základních registrů (dále jen „ISZR“), jak je uvedeno v § 5 odst. 3 zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů (dále jen „zákon o základních registrech“).
Smyslem tohoto dokumentu je ozřejmit nejen základní technické principy komunikace s ISZR, ale i popsat základní procesy a funkce AIS, kterými by měl AIS disponovat pro zajištění podpory výkonu činnosti v agendách orgánů veřejné moci (dále jen „OVM“).
Na konci tohoto dokumentu je uveden přehled vybraných dostupných eGON služeb s uvedením praktických příkladů jejich volání.
Dále dokument obsahuje základní principy a postupy pro připojení AIS k ISZR za účelem zajištění podpory výkonu agend OVM, které byly převzaty a zobecněny z dokumentu Dopady spuštění základních registrů na subjekty územní samosprávy, který vydalo Ministerstvo vnitra ČR ve spolupráci s kraji, Zpracovatel: CORTIS Consulting s.r.o., Datum vydání: 11. 4. 2012, Verze dokumentu: 1.00.
Další popisy architektury a jednotlivých komponent systému ZR, mimo rámec tohoto dokumentu, jsou uvedeny na portálu Správy základních registrů (dále jen „SZR“), xxxx://xxx.xxxxx.xx, který se problematice ZR systematicky věnuje. Zde lze nalézt doplňující procesní a technické informace pro implementátory AIS, obsažené v následujících dokumentech:
• Představení principu fungování základních registrů – dokument s popisem Globální architektury ZR a doplněk kapitol: Funkční dekompozice, Technologická a Procesní architektura,
• Katalog eGON služeb – stažitelný balíček obsahující seznam služeb s popisem, kompletní soubory XSD a WSDL detailně popisující strukturu komunikačních dat, postup zpracování služeb a popisy datových typů,
• Procesní postupy pro připojení AIS (Příručka pro obce) – popisující postup OVM při přípravě a zpracování žádosti o připojení k ISZR a postup SZR při vyřizování těchto žádostí,
• Generování certifikátu pro přístup k ISZR – detailní popis kroků nutných pro úspěšné generování asymetrického klíčového páru (který je rozdílný pro testovací a produkční prostředí) s vytvořením souboru k žádosti o připojení a popisem následné instalace certifikátu.
Konkrétní dotazy ohledně ISZR lze odesílat na e-mailovou adresu xxx@xxxxx.xx.
1.1 Smysl a účel ZR
Mezi základní cíle strategie „Efektivní veřejná správa a přátelské veřejné služby“ pro období 2007 – 2015 vyhlášené vládou patří vytvoření centrálních registrů, jejichž pomocí bude možné sdílet data v rámci veřejné správy (VS). Pro naplnění tohoto cíle byl vypracován a schválen zákon o základních registrech, který stanovuje ZR jako jedinečné zdroje údajů využívaných při práci veřejné správy. Prostřednictvím ZR tak dojde k odstranění roztříštěnosti, nejednotnosti a vícenásobného výskytu dat v zásadních informačních systémech (IS) veřejné správy. Nařízení vlády č. 161/2011 Sb., o stanovení harmonogramu a technického způsobu provedení opatření podle § 64 až 68 zákona o základních registrech pak definuje konkrétní technické a procesní podmínky pro úspěšné spuštění ZR.
Pokud shrneme zákon o základních registrech do několika přehledných bodů, dostaneme jednoznačnou odpověď, jaký je smysl a účel tohoto záměru:
• poskytovat bezpečně vybrané právně závazné referenční údaje o definovaných objektech a subjektech,
• propagovat změny v těchto údajích provedené oprávněnými editory do celé veřejné správy,
• zavést kontrolu subjektů údajů nad údaji o nich vedenými,
• zásadně zjednodušit ohlašovací povinnost,
• vytvořit předpoklady pro optimalizaci a sjednocení procesů a IS veřejné správy.
1.2 Legislativní rámec pro oblast ZR
Základní legislativní rámec pro oblast ZR je tvořen následujícími právními předpisy:
• Zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů
Tento zákon vymezuje obsah ZR, ISZR a informačního systému územní identifikace a stanoví práva a povinnosti, které souvisejí s jejich vytvářením, užíváním a provozem. Rovněž zřizuje SZR a vymezuje její základní kompetence.
• Nařízení vlády č. 161/2011 Sb., o stanovení harmonogramu a technického způsobu provedení opatření podle § 64 až 68 zákona o základních registrech
Tímto nařízením vláda ČR definuje harmonogram plnění povinností vyplývajících z § 64 až 68 zákona o základních registrech, a to na straně SZR, správců ZR, ústředních správních úřadů (dále jen „ÚSÚ“) a OVM územní samosprávy.
• Zákon č. 365/2000 Sb., o informačních systémech veřejné správy, ve znění pozdějších předpisů
Zákon č. 365/2000 Sb., o informačních systémech veřejné správy, ve znění pozdějších předpisů (dále jen „zákon o informačních systémech veřejné správy“) stanoví práva a
povinnosti správců informačních systémů veřejné správy (dále jen „ISVS“) a dalších subjektů, jež souvisejí
s vytvářením, užíváním, provozem a rozvojem ISVS. Upravuje působnost Ministerstva vnitra jako ÚSÚ pro tvorbu a rozvoj ISVS.
• Vyhláška č. 528/2006 Sb., o formě a technických náležitostech předávání údajů do IS, který obsahuje základní informace o dostupnosti a obsahu zpřístupněných ISVS (vyhláška o IS o ISVS)
Obsahuje základní informace o dostupnosti a obsahu zpřístupněných ISVS. Tato vyhláška je klíčovým dokumentem, který upravuje formu a technické náležitosti předávání údajů do veřejného IS. Pokud OVM předpokládá využití IS, kterých je správcem, pro komunikaci se ZR, je podmínkou pro získání příslušného certifikátu jejich registrace v IS o ISVS. Existují však ISVS, které v IS o ISVS nemusejí být registrovány, protože se na ně nevztahuje zákon o informačních systémech veřejné správy (o které ISVS se jedná, je stanoveno v § 3 odst. 3 tohoto zákona).
• Vyhláška č. 529/2006 Sb., o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality ISVS (vyhláška o dlouhodobém řízení ISVS)
Stanoví požadavky na strukturu a obsah informační koncepce, postupy OVM při jejím vytváření, vydávání, při vyhodnocování jejího dodržování a požadavky na řízení bezpečnosti a kvality ISVS. Dále stanoví požadavky na strukturu a obsah provozní dokumentace ISVS a na rozsah provozní dokumentace předkládané při atestaci.
• Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů
Tento zákon upravuje práva a povinnosti osob a působnost a pravomoci OVM v oblasti kybernetické bezpečnosti. Nevztahuje se na informační nebo komunikační systémy, které nakládají s utajovanými informacemi.
• Vyhláška č. 316/2014 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních a o stanovení náležitostí podání v oblasti kybernetické bezpečnosti (vyhláška o kybernetické bezpečnosti)
Stanoví obsah a strukturu bezpečnostní dokumentace pro IS kritické informační infrastruktury, komunikační systém kritické informační infrastruktury nebo významný IS, obsah bezpečnostních opatření, rozsah jejich zavedení, typy a kategorie kybernetických bezpečnostních incidentů, náležitosti a způsob hlášení kybernetického bezpečnostního incidentu, náležitosti oznámení o provedení reaktivního opatření a o jeho výsledku a vzor oznámení kontaktních údajů a jeho formu.
• Vyhláška č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích
Touto vyhláškou se stanoví významné IS a jejich určující kritéria.
• Nařízení vlády č. 315/2014 Sb., kterým se mění nařízení vlády č. 432/2010 Sb., o kritériích pro určení prvku kritické infrastruktury
Nařízení vlády č. 315/2014 Sb. mění odvětvová kritéria pro určení prvku kritické infrastruktury, uvedené v příloze k nařízení vlády č. 432/2010 Sb.
• Nařízení eIDAS, tj. nařízení Evropského parlamentu a Rady (EU) č. 910/2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES
Nařízení eIDAS je použitelné od 1. 7. 2016 s tím, že jeho jednotlivá ustanovení budou, s ohledem na nutnost předložení souvisejících prováděcích aktů a na potřebu přizpůsobení členských států, nabývat účinnosti postupně v období let 2016 – 2018. Úkoly orgánu dohledu podle nařízení eIDAS a dále podle zákona č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů, plní Ministerstvo vnitra. Zpracovává také návrhy právních předpisů týkajících se elektronického podpisu a v jeho působnosti je rovněž zajištění mezinárodní spolupráce v této oblasti a plnění úkolů plynoucích z členství České republiky v mezinárodních organizacích.
• Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce
V návaznosti na nařízení eIDAS tento zákon upravuje některé postupy poskytovatelů služeb vytvářejících důvěru, některé požadavky na tyto služby a pravidla elektronického podepisování, elektronického pečetění a opatřování dokumentů elektronickými časovými razítky. Xxxxx dále stanovuje působnost Ministerstva vnitra v oblasti služeb vytvářejících důvěru a sankce za porušení povinností v této oblasti. Neupravuje elektronickou identifikaci.
• Zákon č. 298/2016 Sb., kterým se mění některé zákony v souvislosti s přijetím zákona o službách vytvářejících důvěru pro elektronické transakce, zákon č. 106/1999 Sb.,
o svobodném přístupu k informacím, ve znění pozdějších předpisů, a zákon č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, ve znění pozdějších předpisů
Jedná se o změnový zákon k zákonu č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů. Zde obsažené novely zákona o svobodném přístupu k informacím a autorského zákona byly připraveny v souvislosti s plněním úkolu Ministerstva vnitra stanovit jednotící pravidla pro poskytování informací povinnými subjekty ve formě otevřených dat, který vzešel z Akčního plánu České republiky Partnerství pro otevřené vládnutí na období let 2014 až 2016.
• Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů
Tento zákon upravuje doručování dokumentů OVM fyzickým a právnickým osobám, provádění úkonů fyzických a právnických osob vůči OVM a vzájemnou komunikaci OVM prostřednictvím datových schránek. Dále je předmětem zákona problematika informačního
systému datových schránek (dále jen „ISDS“), osobního čísla, jež se přidělují výše uvedeným subjektům,
a autorizovaná konverze dokumentů, tj. konverze dokumentu v podobě datové zprávy do dokumentu v listinné podobě a naopak. Podle § 15 tohoto zákona Ministerstvo vnitra za účelem správy ISDS a zřizování a správy datových schránek využívá stanovené údaje ze základního registru obyvatel, informačního systému evidence obyvatel a informačního systému cizinců.
• Zákon č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů
Správní řád upravuje postup orgánů moci výkonné, orgánů územních samosprávných celků a jiných orgánů, právnických a fyzických osob, pokud vykonávají působnost v oblasti veřejné správy. Takto vymezený okruh subjektů označuje za správní orgány. Zákon o základních registrech tyto definované postupy rozšiřuje o povinnost OVM využívat při své činnosti referenční údaje obsažené v příslušném ZR, viz § 5 odst. 1 zákona o základních registrech.
• Nařízení GDPR 2016/679, tj. nařízení Evropského parlamentu a Rady (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů)
Ke dni 25. května 2018 jako k datu účinnosti tohoto nařízení musí OVM a poskytovatel provozu jeho AIS zajistit zpracování osobních údajů v souladu s tímto nařízením. Cílem nařízení je stanovit pravidla pro ochranu osobních údajů a pravidla týkající se jejich volného pohybu v rámci Evropské unie; vztahuje se na většinu oblastí zpracování osobních údajů v působnosti práva Evropské unie, s výjimkou potírání a prevence trestné činnosti a ochrany veřejné bezpečnosti a s výjimkou výlučně osobního a domácího zpracování.
• Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů
Základním účelem tohoto zákona je úprava práv a povinností při zpracování osobních údajů a stanovení podmínek, za nichž se uskutečňuje předání osobních údajů do jiných států. Z pohledu implementace dopadů zákona o základních registrech je podstatný zejména § 5 zákona o ochraně osobních údajů, který definuje hlavní povinnosti správce a zpracovatele osobních údajů a § 13, stanovující povinnosti osob při zabezpečení osobních údajů. OVM jako správci a zpracovatelé osobních údajů jsou tedy povinny např. zabránit sdružování osobních údajů, které může nastat při nevhodném způsobu zajištění výkonu agend lokálními IS/AIS. Dále jsou OVM povinny přijmout a řádně zdokumentovat taková opatření, aby nemohlo dojít k neoprávněnému či nahodilému přístupu k osobním údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování, jakož i k jinému zneužití osobních údajů. Tato povinnost platí i po ukončení zpracování osobních údajů.
2. Definice základních pojmů
Kapitola obsahuje popis základních pojmů uvedených v dokumentu.
Zákon - pokud tento dokument hovoří o pojmu „zákon“ bez další specifikace, je tím míněn zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů.
ZIFO - zdrojový identifikátor fyzické osoby, je neveřejným identifikátorem. Ze zdrojového identifikátoru fyzické osoby nelze dovodit osobní ani jiné údaje o fyzické osobě, jíž byl přiřazen. Je bezpečně uložen v převodníku ORG.
AIFO - agendový identifikátor fyzické osoby podle § 9 zákona. Tento identifikátor slouží pro identifikaci konkrétní fyzické osoby v rámci agendy a ZR nebo AIS, při volání eGON služby i interně v systému ZR, přičemž tento identifikátor je různý pro různé systémy (agendy / AIS / ZR). Z agendového identifikátoru fyzické osoby nelze odvodit zdrojový identifikátor fyzické osoby a nelze z něj ani dovodit osobní nebo jiné údaje o fyzické osobě, jíž byl přiřazen.
Identifikátor OVM - jedinečný identifikátor orgánu veřejné moci přidělený konkrétnímu OVM. Identifikátorem OVM je IČO.
Registrace - zkrácený název procesu, v rámci kterého získává AIS přístup k vnějšímu rozhraní ZR. Jde o proces zabezpečovaný SZR. Postup registrace je popsán v samostatném dokumentu na webu SZR (Příručka pro obce).
AIS - agendový informační systém, jedinečně se identifikující oproti systému ZR.
Lokální data AIS - jednotlivé AIS pracují se svými lokálními daty. V systému ZR jsou uloženy referenční údaje. Pod pojmem lokální data AIS se v tomto dokumentu rozumí hodnoty údajů v AIS, jejichž referenční hodnoty jsou vedeny v ZR. Pojem lokální data se tedy nijak nevztahuje na ostatní data AIS.
ZR - základní registr je ISVS, který obsahuje referenční údaje a představuje základní kámen pro rozšiřování služeb pro občany v rámci strategie rozvoje projektů eGovernmentu. ZR představují soubor dat a údajů, které sdílí celá veřejná správa. Ostatní registry čerpají údaje ze ZR.
ISZR - ISVS, který je součástí referenčního, sdíleného a bezpečného rozhraní ISVS a jehož prostřednictvím je zajišťováno sdílení dat mezi jednotlivými ZR navzájem, ZR a AIS a AIS navzájem, správa oprávnění přístupu k datům a další činnosti podle zákona o základních registrech (viz § 2 písm. g) tohoto zákona).
eGON rozhraní, vnější rozhraní ISZR - rozhraní, na kterém je technickými prostředky poskytován přístup k ISZR prostřednictvím AIS podle § 5 odst. 3 zákona.
eGON služba - webová služba poskytovaná na eGON rozhraní. eGON služba je poskytována podle jejího popisu v katalogu eGON služeb, který spravuje, aktualizuje a publikuje SZR. Jsou to tedy všechny schválené a provozované služby, které jsou dostupné na vnějším rozhraní
ISZR
a slouží OVM pro podporu výkonu činností v jejich agendách, tedy:
• K získávání referenčních údajů pro účely výkonu veřejné moci ze strany OVM v rámci výkonu jejich agend.
• K aktualizaci referenčních údajů pro naplnění odpovědnosti vyplývající pro OVM z role editora, který je oprávněn zapisovat referenční údaje do ZR a provádět změny zapsaných referenčních údajů.
Do skupiny eGON služeb patří i služby poskytující zprostředkované údaje z jiných registrovaných AIS. Tyto služby ale pracují pouze s informačními údaji.
2.1 Rozdíl mezi referenčními a informačními údaji
Zákon o základních registrech zavádí pojem referenční údaje, které jsou považovány za správné a právně závazné, pokud není prokázán opak nebo pokud nevznikne oprávněná pochybnost
o jejich správnosti. Pouze referenční údaje s těmito vlastnostmi jsou vedeny v ZR – jedná se
o údaje o:
• fyzických osobách, vedené v Registru obyvatel (ROB),
• právnických osobách, vedené v Registru osob (ROS),
• územních prvcích, adresách a nemovitostech, vedené v Registru územní identifikace (RÚIAN),
• OVM a jejich rozhodnutích, vedené v Registru práv a povinností (RPP).
Přístup OVM k referenčním údajům je možný pouze:
• registrovaným agendovým IS, který volá eGON služby publikované na vnějším rozhraní ISZR,
• systémem Czech POINT (na základě formuláře žádosti a formuláře odpovědi),
• prostřednictvím datových schránek (na základě formuláře žádosti a formuláře odpovědi).
Na druhé straně, informační údaje jsou všechny údaje poskytované ISVS. Zásadní rozdíl mezi referenčními a informačními údaji je tedy následující:
• Referenční údaje jsou uloženy jen a pouze v ZR.
• Referenční údaje se získávají voláním množiny eGON služeb ZR a jsou platné v okamžiku vytvoření odpovědi na požadavek.
• Zpracování eGON služeb řídí ISZR, který plní roli prostředníka při získávání referenčních údajů. Některé OVM mají výjimku přímého přístupu k údajům v ZR ke
konkrétním účelům podle § 5a zákona o základních registrech; i tyto OVM však musí údaje v ZR využívat prostřednictvím AIS.
• Správnost a aktuálnost referenčních údajů v ZR garantuje stát zákonem o základních registrech.
Informační údaje o subjektech údajů jsou údaje vedené v AIS. Při komunikaci s ISZR se získává kopie referenčních údajů s potvrzením o provedení služby, která tyto údaje poskytla. Jakmile je tato kopie referenčních údajů uložena v agendovém IS OVM nebo jiném ISVS, získávají referenční údaje statut informačních údajů. Množina informačních údajů o subjektech údajů, uložená v agendových IS, může být mnohem širší, neboť to vyžadují procesy OVM, který řeší rozličné životní situace občanů a firem.
2.2 Zkratky
Zkratka | Význam |
AIS | Agendový informační systém |
AIFO | Agendový identifikátor fyzické osoby vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
ASCII | American Standard Code – kódová tabulka, která definuje znaky anglické abecedy, a jiné znaky používané v informatice |
BOK | Bezpečnostní osobní kód podle zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
CIS | Cizinecký informační systém |
CRC | Cyclic redundancy check – hašovací funkce, používaná k detekci chyb během přenosu nebo ukládání dat |
ESB | Integrační platforma |
FAIS | Formulářový AIS |
FTP(S) | File Transfer Protocol – komunikační protokol, resp. jeho zabezpečená varianta |
http(s) | Hypertext Transfer Protocol – komunikační protokol, resp. jeho zabezpečená varianta |
IČO | Identifikační číslo |
ID | Obecná zkratka pro „Identifikátor“ |
IDM | Internet Download Manager – počítačový program sloužící ke stahování souborů z internetu, případně k jejich nahrávání |
IOP | Integrovaný operační program |
ISDS | Informační systém datových schránek |
ISEO | Informační systém evidence obyvatel |
ISVS | Informační systém veřejné správy |
ISZR | Informační systém základních registrů vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
JIP | Jednotný identitní prostor |
XXXX | Katalog autentizačních a autorizačních služeb |
KIVS | Komunikační infrastruktura veřejné správy |
LDAP | Lightweight Directory Access Protocol – definovaný protokol pro ukládání a přístup k datům na adresářovém serveru |
MEP | Message Exchange Pattern – vzor výměny zpráv |
MTOM | Message Transmission Optimization Mechanism – komunikační protokol |
ORG | Převodník identifikátorů fyzických osob |
OVM | Orgán veřejné moci |
QoS | Quality of Service – pravidla poskytování služby |
ROB | Registr obyvatel (základní registr obyvatel) vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
ROS | Registr osob (základní registr právnických osob, podnikajících fyzických osob a orgánů veřejné moci) vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
ROS - IAIS | Integrovaný agendový informační systém pro editaci ROS |
RPP | Registr práv a povinností (základní registr agend, orgánů veřejné moci a některých práv a povinností) vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
RÚIAN | Registr územní identifikace (základní registr územní identifikace, adres a nemovitostí) vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
SOAP | Simple Object Access Protocol – komunikační protokol |
SOAP payload | Užitečné zatížení SOAP komunikačního protokolu |
SZR | Správa základních registrů – správní úřad vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
URL | Uniform Resource Locator – standardizovaný řetězec pro specifikaci umístění |
ÚSÚ | Ústřední správní úřad |
UUID | Universaly Unique Identifier – jednoznačný identifikátor – obecný standard |
W3C | World Wide Web Consortium |
WF | Internetová doména |
WS | Web Service – webová služba |
WS-* | Standardy pracovní skupiny W3C |
WSDL | Web Services Description Language – standardizovaný popis webové služby |
XML | eXtensible Markup Language – standardizovaný značkovací jazyk |
XOP | XML-binary Optimized Packaging – doporučení W3C pro vkládání binárních dat do XML |
XSD | XML Schema Definition – schéma popisující strukturu XML dokumentu |
ZIFO | Základní identifikátor fyzické osoby vzniklý na základě zákona č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů |
ZR | Základní registr |
3. Základní principy interakce mezi AIS a ISZR
V této kapitole jsou popsány základní principy fungování ISZR jako rozhraní, prostřednictvím kterého přistupují AIS ke zpřístupněným informacím ze ZR.
3.1 Komunikační schéma pro využívání služeb xXXX
xXXX služby jsou publikovány na vnějším eGON rozhraní ISZR (na schématu níže – červeně označené rozhraní). Po předchozím ohlášení OVM k výkonu agendy mohou pracovníci zařazení do agend OVM tyto služby používat na základě oprávnění, prostřednictvím:
• centrálních AIS - sdílený přístup je většinou realizován formou portálového řešení.
• lokálních AIS - jedná se o AIS, které OVM používají pro podporu výkonu svých agend. Tyto lokální AIS mohou být dále poskytnuty pro podporu výkonu činností v agendách zřizovaných organizací a příspěvkových organizací.
Obr.: Komunikační schéma využívání eGON služeb lokálními AIS
V rámci agend OVM mohou být nasazeny prostředky pro zpřehlednění a zefektivnění toku práce uvnitř i vně agend úřadu (workflow), tyto prostředky mohou ale být i sdíleny vně úřadu s cílem zajištění efektivní součinnosti agend zřizovaných organizací a příspěvkových organizací.
Rovněž může být v rámci OVM implementována tzv. integrační platforma (ESB), která může zefektivnit výměnu informací mezi jednotlivými AIS a dalšími IS úřadu v rámci OVM, může hladce napojit místní IDM na centrální JIP/XXXX a v neposlední řadě může zajistit jeden logický kanál pro komunikaci lokálních AIS OVM s ISZR, které pak mohou využívat této komunikační sběrnice a využívat eGON služby bez toho, aby bylo nutné pro každý lokální AIS nákladně budovat komunikační rozhraní s logováním.
Tyto dvě komponenty (WF a ESB) mohou být implementovány v rámci části výzev IOP pro krajské úřady a statutární města, kdy na základě předchozí dohody mohou obce s rozšířenou působností, zřizované organizace a příspěvkové organizace využívat takto vytvořená kooperující prostředí pro spolupráci.
3.2 Současné IS používané pro výkon agend OVM
Se ZR, resp. s ISZR je možné (kromě komunikačních kanálů Czech POINT a datových schránek) komunikovat pouze prostřednictvím AIS.
V případech, kdy OVM působí v roli editora, musí k ZR vždy přistupovat prostřednictvím AIS, které jsou ve velké většině provozované centrálně. V ostatních případech však budou OVM přistupovat k ZR zpravidla prostřednictvím lokálních AIS integrovaných s rozhraním ISZR. Mohou však nastat situace, kdy OVM v rámci výkonu působnosti v agendě potřebuje využívat referenční údaje ze ZR, ale:
• pro výkon agendy nepoužívá žádný informační systém – není vedena jakákoli elektronická evidence a data jsou uložena v papírové podobě, např. v sešitě, do kterého jsou zapisovány např. údaje o platbách místního poplatku (poplatek za psa),
• pro výkon agendy používá jednoduchý kancelářský program, např. tabulku v prostředí MS Excel,
• pro výkon agendy využívá lokální specializovaný ISVS, který není integrovaný s rozhraním ISZR. Jeho integrace není možná z důvodu technologického omezení nebo neúměrných finančních nákladů, které integrace vyžaduje ve srovnání s potenciálními přínosy (např. nízká frekvence výkonu agendy, malé zefektivnění práce) a je tedy výrazně neekonomická.
Doporučuje se provést alespoň jednoduchou úvahu/analýzu ekonomické vhodnosti integrace jednotlivých ISVS. V těchto případech je možné využít pro přístup k ZR:
• Formuláře (FAIS - Formulářový AIS) - v prostředí Czech POINT, které umožňují online komunikaci se ZR.
• Datovou schránku - prostřednictvím které zašle OVM formulář se žádostí o referenční údaje na SZR.
• Centrální AIS jiného správce (pokud je k dispozici, např. ROS - IAIS).
3.3 Možné způsoby komunikace AIS s ISZR
Jak již bylo zmíněno výše, komunikovat s ISZR lze prostřednictvím volání eGON služeb vnějšího rozhraní. Pro tuto komunikaci je možné využít dvou základních konceptů:
• Použití centrálních AIS, které byly budovány současně se ZR a jsou koncipovány tak, že umožňují kromě volání publikačních služeb (získávání referenčních údajů) také volání editačních služeb (aktualizace referenčních údajů).
• Budování lokálních AIS, které se zaměřují spíše na procesní část výkonu činností v agendách OVM, ve kterých je třeba volat eGON služby pro získávání referenčních údajů a provádět záznam rozhodnutí OVM v agendě (typicky zápis rozhodnutí do RPP).
V následujících subkapitolách jsou oba koncepty detailně popsány.
3.3.1 Využití centrálních AIS
Centrální AIS jsou využívány zejména u agend, kde OVM působí v roli editora. Podmínkou zajištění přístupu je provedení oznámení o vykonávání působnosti v agendě. Všechny činnosti spojené s připraveností AIS na komunikaci s ISZR zajišťuje správce příslušného centrálního AIS, OVM je pouze uživatelem systému.
Jako uživatel systému musí OVM provést přiřazení úředních osob k jednotlivým agendám, které jsou příslušným centrálním AIS podporovány a provést zaevidování uživatelů do JIP nebo zřízení přístupových práv dle pravidel stanovených správcem AIS.
Podmínkou pro získání uživatelských přístupů do centrálních AIS je oznámení vykonávání působnosti v agendě, včetně dodání počtu úředních osob, podílejících se na výkonu agendy a jednotlivých činnostních rolí.
Ke každému ze ZR je k dispozici více centrálních AIS. Příklady takových centrálních a editačních AIS jsou uvedeny v následující tabulce:
ZR | Centrální AIS |
ROX | XXXX - Informační systém evidence obyvatel (občanské průkazy a pasy) |
CIS - Cizinecký informační systém | |
ROX | Xxxxxxx xejstřík |
Živnostenský rejstřík | |
ROS - IAIS - Integrovaný agendový informační systém pro malé agendy | |
RÚIAN | ISKN - Informační systém katastru nemovitostí |
ISÚI - Informační systém územní identifikace | |
RPP | RPP AIS Působnostní - působnost OVM |
RPP AIS Modelovací - procesní modely agend | |
RPP AIS Editační - zapisující údaje o rozhodnutí OVM |
Kromě výše uvedených editačních AIS existuje Formulářový agendový informační systém (FAIS), který umožňuje dotazy do ZR s využitím interaktivních formulářových řešení. Jeho vstupním rozhraním je prostředí Czech POINT, CzechPOINT@office nebo datová schránka.
3.3.2 Zapojení lokálních AIS
V případě, že chce OVM pro komunikaci se ZR využít vlastní AIS, je základní podmínkou provedení registrace každého takového AIS ze strany OVM do IS o ISVS. Pouze AIS, na které se nevztahuje zákon o informačních systémech veřejné správy, a zároveň podle jiných právních předpisů jsou oprávněny využívat údaje ze ZR, nemusí být registrovány v IS o ISVS. AIS je možné následně (po získání certifikátu pro komunikaci s ISZR a po provedení příslušných úprav) připojit k rozhraní ISZR.
Rozhodnutí o identifikaci (a členění) jednotlivých ISVS je plně v kompetenci správce ISVS. Existují následující základní přístupy ke způsobu registrace jednotlivých AIS do IS o ISVS:
1. Agendový – jednotlivé AIS jsou do IS o ISVS zaregistrovány tak, že i v případě integrovaných softwarových řešení činí poměr AIS k vykonávaným agendám 1:1. Pokud tedy aplikace zajišťuje podporu výkonu více agend, budou do IS o ISVS zaregistrovány jednotlivé moduly (modul = agenda).
2. Aplikační – jednotlivé AIS jsou do IS o ISVS zaregistrovány jako samostatné celky. V případě integrovaných softwarových řešení, které zajišťují podporu výkonu více agend, bude činit vztah mezi AIS v IS o ISVS k agendám 1:n.
3. a 4. Kombinace – výše uvedených způsobů, kdy mohou být některé moduly integrovaných řešení zaregistrovány společně jako jeden AIS do IS o ISVS (jedná se o velice podobné či vzájemně provázané agendy), zbylé pak samostatně pro každou jednotlivou agendu.
Způsob, jakým OVM zaregistrují AIS do IS o ISVS, nesmí ovlivnit obecný princip při používání AIFO v rámci výkonu jednotlivých agend – v souladu s výkladem zákona o základních registrech musí být každé agendě přiděleno unikátní AIFO, a to i v případě, kdy se jedná o integrovaný software (tento požadavek musí v rámci úpravy aplikace zajistit dodavatelé).
Pokud OVM využívá pro komunikaci se ZR také lokální AIS, mohou tyto AIS přistupovat k ZR odlišným způsobem:
• prostřednictvím jednoagendového lokálního AIS (tj. 1 AIS = výkon 1 agendy),
• prostřednictvím integrovaného lokálního AIS (tj. 1 AIS = výkon více agend),
• prostřednictvím integrační platformy (integrující různé AIS).
V praxi pak může nastat libovolná kombinace těchto způsobů, kdy OVM bude mít část AIS integrovánu pomocí integrační platformy, zbylé budou komunikaci s ISZR zajišťovat přímo.
Následují popisy jednotlivých variant, které byly společně zobrazeny na výše uvedeném obrázku: Komunikační schéma využívání eGON služeb lokálními AIS.
(1) Přístup k referenčním údajům ZR prostřednictvím jednoagendového lokálního AIS
Pro podporu výkonu jedné konkrétní agendy je určen právě jeden lokální AIS. Pro podporu výkonu jiné agendy zase jiný lokální AIS. Správcem těchto lokálních AIS jsou jednotlivé OVM.
Jednoagendové AIS mají zpravidla různou architekturu a pocházejí od různých dodavatelů. Ve většině případů nedisponují společným aplikačním základem, nemají jednotnou správu uživatelů
a aplikačních oprávnění. Nastavení aplikace je v rámci každého AIS různé a každý systém má své vlastní číselníky a kmenová data. Za kmenová data jsou, v kontextu tohoto dokumentu, považována data o subjektu (fyzické a právnické osobě), místě – adrese a o rozhodnutí.
V případě používání jednoagendového lokálního AIS je třeba realizovat úpravy pro komunikaci s ISZR pro každý AIS zvlášť. Jelikož je každý AIS určen pro podporu činností právě jedné agendy, mají evidované fyzické osoby vždy přidělené jedno AIFO. Tím odpadá řešení problematiky práce s více AIFO pro fyzickou osobu v případech, že AIS řeší životní cyklus více agend.
(2) Přístup k referenčním údajům ZR prostřednictvím integrovaného lokálního AIS
Oproti předchozímu popsanému způsobu přístupu k referenčním údajům ZR se jedná o situaci, kdy jeden AIS aplikačně podporuje životní cyklus více agend. Ve většině případů je takovýto integrovaný AIS vytvořen na společném aplikačním jádře v rámci jedné technologie. Zpravidla má jednotnou správu uživatelů a aplikačních oprávnění, která může být integrována na lokální, nebo centrální adresářové služby. Ve většině případů má společnou funkcionalitu administrace aplikace, jednu evidenci číselníků a kmenových dat.
Kromě výše popsané základní funkcionality, kterou se integrovaný lokální AIS liší od jednotlivých dílčích lokálních AIS popsaných v předešlém odstavci, bývá navíc implementován integrační modul sloužící pro komunikaci zejména s externími aplikacemi. Je na zvážení OVM, zda bude do IS o ISVS registrovat integrovaný lokální AIS jako celek (a tedy pro komunikaci s ISZR bude potřebný pouze jeden technický certifikát) nebo tzv. agendově, tedy pro každý modul integrovaného informačního systému následně získá technický certifikát. Doporučuje se první varianta, tedy tzv. aplikační přístup, přičemž dodavatel musí zajistit, aby pro každou integrovanou agendu bylo v rámci komunikace se ZR používáno odlišné AIFO jedné fyzické osoby.
Výhody řešení
• Výkon několika agend je zajištěn pomocí 1 lokálního integrovaného AIS, jehož integrace s externími aplikacemi (ISZR) se řeší zpravidla v rámci jednoho modulu,
včetně jednotného logování a zajištění jednotné bezpečnosti. To může vést v důsledku
ke snížení nákladů na tvorbu jednotlivých rozhraní.
• V případě aplikačního přístupu je nutné zajistit pouze jeden technický certifikát pro zajištění přístupu integrovaných agend k referenčním údajům v ZR.
• Při specifikaci řešení úprav lokálního integrovaného AIS se zpravidla vedou jednání s jedním dodavatelem, který by měl být na problematiku komunikace se systémem ZR připraven a všem zákazníkům nabízet své řešení, které je v souladu s platnou legislativou.
Nevýhody řešení
Komplikací tohoto řešení může být požadavek na přiřazování AIFO fyzické osobě v rámci 1 agendy, tj. pro každou z agend, které jsou v takovémto řešení integrovány, musí mít fyzická osoba přiřazené jiné AIFO. Zásadním požadavkem je pak v tomto případě zajištění takové míry zabezpečení aplikace, aby nemohlo dojít k účelovému sdružování údajů o fyzické osobě napříč případy integrovaných agend v aplikaci. To může klást vyšší nároky na úpravu aplikační architektury, nicméně dodavatel integrovaného lokálního AIS by měl garantovat shodu s legislativními předpisy a měl by být připraven tento problém vyřešit.
(3, 4) Přístup k referenčním údajům ZR prostřednictvím integrační platformy AIS
V případě, že se jedná o větší OVM, který má několik integrovaných či jednoagendových lokálních AIS, může být komunikace s ISZR realizována prostřednictvím integrační platformy. Tato platforma je klíčovým prvkem komunikace lokálních AIS s okolními (zejména externími) aplikacemi. Co se týče aplikační architektury, je tento způsob řešení obdobný, jako případ komunikace lokálního integrovaného AIS. Na obrázku jsou znázorněny dva způsoby komunikace prostřednictvím integrační platformy.
Rozdíl v implementaci je následující:
Řešení (3) představuje integrační platformu a jednotlivé lokální AIS jako jeden ISVS. Jde o registraci tohoto jednoho lokálního AIS jako lokálního integrovaného AIS podporujícího výkon více agend. S tím souvisí i podání žádosti na jeden technický certifikát pro komunikaci s ISZR.
Řešení (4) představuje každý lokální AIS jako samostatný ISVS, tj. samostatně by měly být i tyto lokální AIS registrovány v ISVS a každý z těchto lokálních AIS by měl získat svůj vlastní technický certifikát. V tomto případě bude úloha integrační platformy „pouze“ jako zprostředkovatel komunikace s ISZR, který však bude zároveň představovat jedno místo pro centrální logování komunikace a řízení integračních procesů.
Výhody řešení
• Řešení typu 3 a 4 lze kombinovat,
• realizace jednoho centrálního místa integrace pro komunikaci se systémem ZR,
• jednotný způsob logování, včetně zajištění jednotné úrovně zabezpečení komunikace,
• existence velkého rozsahu komunikačních protokolů a adaptérů (adresářové služby, webové služby, databázová konektivita pro různé databázové systémy, zpracování souborů, logů apod.),
• nižší náklady na zprovoznění nového, popř. na výměnu stávajícího lokálního AIS v případě jeho napojení na ISZR.
Nevýhody řešení
• Dodavatel integrační platformy je obvykle další subjekt, jehož úkolem je implementovat sofistikovanou integrační úlohu a spolupracovat s dodavateli jednotlivých lokálních AIS. To může vést k vysokým finančním a případně i kapacitním nárokům,
• vysoké nároky na zajištění součinnosti všech zúčastněných stran,
• zajištění provozu dalšího aplikačního vybavení, včetně získání poměrně značných technických kompetencí pro správce systému,
• nutnost řešení přiřazení více AIFO k jedné fyzické osobě, pokud se tato osoba vyskytuje v případech různých agend. V tomto případě je nezbytné zajistit takovou míru zabezpečení aplikace, aby nemohlo dojít k účelovému sdružování údajů o fyzické osobě napříč agendami.
3.3.3 Autentizace a identifikace uživatelů přiřazených k agendě
V rámci naplnění požadavku na zajištění evidence přístupů k údajům v ZR musí OVM přiřadit konkrétní zaměstnance k jednotlivým agendám a jejich činnostním rolím. Pro většinu centrálních AIS platí pravidlo: aby uživatel mohl pracovat s centrálním AIS, musí být zaveden v JIP.
Editaci údajů v JIP, včetně správy lokálních administrátorů a lokálních uživatelů, je možné realizovat dvěma způsoby:
Pro lokální AIS existují následující možnosti zajištění životního cyklu identity:
1. Využití služeb JIP/XXXX - tato možnost řešení využívá služeb katalogu autentizačních a autorizačních služeb pro správu identit potřebných pro práci s lokálním AIS. Implementace této možnosti řešení spočívá buď v úpravě lokálního AIS, který bude komunikovat prostřednictvím webových služeb s JIP/XXXX za účelem autentizace uživatele, nebo v synchronizaci vybraných identit s lokálními adresářovými službami
2. Zajištění životního cyklu identity vlastními prostředky - lokální AIS řeší správu identit buď ve svém vlastním – nativním prostředí (v rámci daného IS), nebo prostřednictvím lokálních adresářových služeb (LDAP), které nejsou synchronizovány s JIP.
3.4 Obsah informací na eGON rozhraní
eGON rozhraní vystavené prostřednictvím ISZR přenáší následující informace:
- referenční údaje vedené v jednotlivých ZR,
- ostatní údaje vedené v jednotlivých ZR,
- provozní údaje související se systémem ZR,
- údaje vedené ve spolupracujících AIS.
3.4.1 Poskytování výstupů
Prostřednictvím eGON rozhraní jsou data poskytována těmito způsoby:
- s použitím eGON webových služeb,
- prostřednictvím souborů vystavovaných protokoly http(s) / FTP(S). Popis je uveden v kapitole Poskytování dat.
3.4.2 Zápis údajů
Prostřednictvím eGON rozhraní jsou informace zapisovány s použitím eGON webových služeb.
3.5 Přístup k eGON rozhraní ISZR
eGON rozhraní ISZR je dostupné prostřednictvím KIVS případně internetu. Informace o přístupu k rozhraní jsou uvedeny v samostatném dokumentu umístěném na webu SZR. URL jednotlivých rozhraní jsou uvedena v Katalogu eGON služeb, který je dostupný na stejném místě.
K eGON rozhraní ISZR přistupují jednotlivé AIS. Přístup k tomuto rozhraní je omezen a zabezpečen na několika úrovních:
- AIS musí být připojen na příslušný přístupový bod (KIVS nebo internet). Způsob a proces připojení AIS na KIVS je mimo oblast systému ZR.
- AIS musí být certifikován pro přístup k eGON rozhraní. Certifikace je proces v kompetenci SZR. V rámci tohoto procesu je vymezena působnost AIS – agenda, agendové role a OVM. Tento proces je popsán v samostatném dokumentu dostupném na webu SZR.
- AIS musí mít vydán elektronický klientský certifikát. Vydání klientského certifikátu je poslední krok v procesu certifikace AIS, který provádí SZR.
- AIS musí mít povolen přístup ke konkrétním eGON službám. Povolení je definováno na základě kombinace OVM / agenda / agendová role, a vyplývá z registrace příslušné agendy a agendové činnosti v RPP
3.5.1 Katalog eGON služeb
Katalog eGON služeb je dostupný jako samostatný dokument. Tento dokument popisuje jednotlivé eGON služby poskytované na eGON rozhraní.
Katalog eGON služeb je dostupný na webových stránkách SZR.
3.5.2 Identifikace volajícího při volání eGON služeb
Voláním eGON služeb se rozumí volání webových služeb eGON rozhraní ISZR. V rámci volání musí AIS provést svoji identifikaci na dvou úrovních:
- prostřednictvím elektronického klientského certifikátu vystaveného pro AIS. AIS musí tento certifikát použít při volání eGON služby, jde o SSL klientský certifikát.
- prostřednictvím parametrů volání eGON služby. Součástí parametrů volání každé webové služby jsou informace identifikující agendu, agendovou roli, OVM, uživatele atd. Tyto informace musí AIS při volání eGON služby poskytnout. Podrobnější popis těchto parametrů je uveden v kapitole Přístup z AIS k datům ZR prostřednictvím eGON služeb.
3.5.3 Přístup z AIS k datům ZR prostřednictvím eGON služeb
AIS musí zajistit, aby eGON služby využívané jeho prostřednictvím byly využívány pouze osobami a procesy, které jsou k využívání těchto služeb oprávněny. Tedy AIS musí zabezpečit podle § 57 zákona:
- Autentizaci uživatele do AIS, pokud je v rámci činnosti uživatele v AIS volána eGON služba.
- V případě automatického procesu AIS musí AIS zajistit evidenci vlastníka business procesu, který eGON službu využívá a identifikaci tohoto vlastníka uvést ve volání eGON služby.
- Přiřazení uživatele do agendové role.
- Identifikaci AIS jako OVM, tedy za jaký OVM AIS při volání služby vystupuje.
Při volání eGON služby je tedy AIS povinen předat informace:
- o identifikaci uživatele, který službu přímo či nepřímo inicioval – uživatelský identifikátor,
- o důvodu a konkrétním účelu využití služby, pokud to zákon požaduje,
- o subjektu, pro jehož účely se údaje využívají nebo poskytují, pokud to zákon požaduje,
- o OVM, pro který je služba vykonávána,
- o agendě, na základě které volání probíhá,
- o agendové roli, která službu využívá.
Identifikací uživatele se rozumí technický identifikátor – identifikátor úřední osoby použitý pro přístup z AIS. Tento identifikátor nemusí být nijak čitelný a srozumitelný pro systém ZR. AIS je povinen vést vazbu tohoto identifikátoru ke konkrétní osobě včetně historie podle § 57 zákona tak, aby bylo možné zpětně tyto informace dohledat na základě oprávněného požadavku podle § 57 odst. 4 zákona.
Důvodem a konkrétním účelem využití služby se rozumí uvedení důvodu, pokud to vyplývá z příslušných ustanovení zákona.
Subjektem údajů se rozumí subjekt, pro jehož účely se údaje využívají nebo poskytují, pokud to zákon požaduje.
OVM se rozumí přidělený identifikátor OVM, kterým je eGON služba vyvolána. U AIS používaných pro více OVM musí být uveden právě jeden identifikátor OVM.
Agendou se rozumí kód agendy, tento kód je OVM přidělen v rámci procesu registrace OVM pro výkon agendy podle § 55 zákona.
Agendovou rolí se rozumí kód agendové činnosti. Tento kód je OVM přidělen v rámci procesu registrace OVM pro výkon agendy dle § 55 odst. 2 písm. c) zákona. Agendová role nemusí být přímo role definovaná v AIS, nicméně AIS musí případně toto mapování zabezpečit. AIS musí současně zabezpečit, aby na základě tohoto jeho mapování nemohlo dojít ke zneužití údajů tak, že by jako důsledek tohoto mapování získal uživatel přístup k údajům, na něž nemá právo.
3.6 Identifikace požadavku ze strany AIS
Každé volání eGON služby je v kontextu této kapitoly považováno za požadavek. Každý požadavek na eGON službu musí být nějakým způsobem identifikován.
Identifikace požadavku je řešena na dvou úrovních. První úroveň je identifikace požadavku v AIS, druhá úroveň je identifikace požadavku v ISZR.
Obecným typem pro identifikaci požadavku, jak na straně AIS, tak na straně ISZR, je
„Universally unique identifier“ - UUID. Jde o prvek standardizovaný nadací „Open software Foundation“ jako součást distribuovaného počítačového prostředí. Současně je tento prvek součástí norem ISO/IEC 11578:1996, ITU-T Rec. X.667 | ISO/IEC 9834-8:2005. Jde o 128 bitové číslo, které je interpretováno jako 32 hexadecimálních číslic v pěti skupinách oddělených pomlčkou ve tvaru: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.
3.6.1 Identifikace požadavku v AIS
Každý požadavek AIS na eGON službu musí obsahovat ID požadavku AIS typu UUID. Tento identifikátor se nazývá „Identifikátor AIS“ a je typu UUID. Tento identifikátor musí být pro každé volání AIS jedinečný. Nutnost plyne především z důvodu identifikace duplicitního požadavku
v systému ZR. Každý AIS volající eGON službu musí tedy při každém volání vygenerovat UUID požadavku a použít je při volání služby.
Poznámka: jde o xml element žádosti AgendaZadostId
3.6.1.1 Identifikace předchozího požadavku
Obecně mohou nastat případy, kdy je třeba zabezpečit zpracování požadavků v definovaném pořadí, které určuje AIS. Systém ZR v tomto bodě poskytuje nástroje k tomu, aby část této činnosti mohla být řešena přímo v systému ZR a nemusela být zabezpečována AIS. Tento proces se nazývá serializace požadavků, jeho popis je uveden v kapitole Serializace požadavků a pro účely tohoto procesu je zaveden „Identifikátor předchozího požadavku AIS“.
3.6.2 Identifikace požadavku v ISZR
Každému požadavku na eGON službu je po přijetí v ISZR přiřazen „Identifikátor ISZR“ typu UUID. Primárním účelem tohoto identifikátoru je jednoznačná identifikace požadavku v systému ZR globálně přes požadavky doručené ze všech AIS.
Pro identifikátor požadavku v ISZR platí:
- Identifikátor požadavku v ISZR je vždy vrácen i volajícímu AIS.
- Identifikátor požadavku v ISZR je vrácen i při chybném volání, pokud je systém ISZR schopen požadavek ošetřit.
- Identifikátor požadavku ISZR musí AIS následně použít v případě, že jím požadovaná služba je asynchronní. V tom případě použije tento identifikátor při dotazu na stav zpracování. Podrobnější popis je uveden v kapitole Asynchronní služby a výstupní fronta.
Poznámka: jde o xml element žádosti IszrZadostId
3.7 Režimy eGON služeb
Režimem služby se rozumí, jakým způsobem získá AIS odpověď na požadovanou eGON službu. eGON služby jsou poskytovány ve dvou režimech:
- v synchronním režimu,
- v asynchronním režimu.
Rozdíl v těchto režimech spočívá ve způsobu, jakým AIS obdrží výsledek volání služby.
Režim, ve kterém jsou jednotlivé služby poskytovány, je definován v Katalogu eGON služeb. Z pohledu volajícího AIS je vstupní požadavek pro oba režimy totožný. AIS může předpokládat, že zpracování služby bude provedeno podle definice režimu služby v Katalogu eGON služeb a současně podle požadavku AIS. Nicméně AIS musí umět reagovat na chybové stavy, které mohou v souvislosti s vybraným režimem služby nastat.
V případě definovaných služeb je volba režimu na straně AIS. Nicméně možnost volby režimu není pro ISZR závazná ve smyslu, že příslušné zpracování v uvedeném režimu úspěšně provede. Požadovaný režim ISZR bere v úvahu při přijetí žádosti současně s dalšími okolnostmi, jako je aktuální zátěž systému, stav komunikace, stav zúčastněných poskytovatelů (ZR) a podobně. Pokud není možné službu v požadovaném režimu poskytnout, obdrží AIS chybu informující o nedostupnosti služby v daném režimu. Je na volbě AIS, zda volání služby odloží do doby, než bude dostupná v daném režimu, nebo zda provede volání ve druhém režimu.
Rozlišení režimu volání je realizováno pomocí URL, které je použito pro volání eGON služby. Přesný popis konstrukce URL je uveden v dokumentu Katalog eGON služeb, který je dostupný na webu SZR.
3.7.1 Synchronní režim eGON služeb
Synchronní režim eGON služby je režim, kdy žadatel jako odpověď na svůj požadavek obdrží ve výsledku volání přímo data obsahující výsledek tohoto dotazu.
Pravidla pro služby v synchronním režimu jsou následující:
- Každá synchronní služba má definovaný maximální čas pro zpracování. Je definován pro každou službu v Katalogu eGON služeb.
- Volajícímu AIS je vždy vrácen výsledek v odpovědi na volání eGON služby.
- Může dojít k situaci, kdy není možné odpověď na služby poskytnout v synchronním režimu, například některý ZR nutný ke zpracování neposkytuje dočasně službu. V tom případě je v odpovědi uveden kód chyby, který tuto situaci pro AIS vystavuje.
- Může dojít k situaci, kdy není možné odpověď na službu poskytnout v definovaném maximálním čase. V tom případě je v odpovědi uveden kód chyby, který tuto situaci pro AIS vystavuje.
- Vzhledem k tomu, že synchronní požadavek není zařazován do fronty ke zpracování, ale je vyřizován okamžitě, není v synchronním režimu dostupná serializace požadavků.
Pokud není možné službu zpracovat v synchronním režimu a pokud chce přesto AIS získat odpověď na tuto službu bez čekání na dostupnost synchronního režimu, musí AIS použít asynchronní režim téže služby. Pokud AIS odpověď získat nepotřebuje, pak může vyčkat na dostupnost synchronní varianty.
Výše uvedené se samozřejmě netýká případů, kdy není dostupný příslušný ZR, pak výsledek nemůže být připraven ani v asynchronním režimu.
3.7.2 Asynchronní režim eGON služeb
Asynchronní režim eGON služby je režim, kdy žadatel jako odpověď na svůj požadavek obdrží ve výsledku volání pouze informaci o přijetí požadavku ke zpracování a „Identifikátor ISZR“. Pro získání odpovědi musí AIS volat další eGON službu, která poskytuje přístup k výsledkům volání asynchronních eGON služeb. Proces při zpracování volání asynchronní služby je popsán v kapitole Asynchronní služby a výstupní fronta.
Pravidla pro služby v asynchronním režimu jsou následující:
- Každá asynchronní služba má definovaný maximální čas na zpracování. Je definován pro každou službu v Katalogu eGON služeb.
- Volajícímu AIS je v odpovědi vrácen identifikátor požadavku v ISZR.
- AIS musí zabezpečit zpracování odpovědi.
- U některých eGON služeb může být definován způsob doručení odpovědi: pasivní a aktivní.
- U asynchronních volání je možné použít serializaci požadavků, kdy je požadavek zpracován až po dokončení jiného předcházejícího požadavku.
3.8 Lokální data AIS
Jednotlivé AIS pracují se svými lokálními daty. V systému ZR jsou uloženy referenční údaje. Pod pojmem lokální data se zde rozumí hodnoty údajů, jejichž referenční hodnoty jsou vedeny v ZR. Pojem lokální data se tedy nijak nevztahuje na ostatní data AIS.
AIS používá referenční data ze ZR. AIS musí současně zajistit, aby lokální data byla v souladu s referenčními údaji v ZR. Základní principy použití dat ZR v souvislosti s AIS jsou následující:
- AIS primárně pracuje se svými lokálními daty.
- AIS si pravidelně aktualizuje svá data podle obsahu ZR.
- Online dotazy do ZR používá AIS pouze v případech, kdy to nezbytně potřebuje.
- AIS si aktualizuje pouze ta data, která eviduje a která pro svoji činnost potřebuje.
Jednotlivé principy jsou detailněji popsány níže:
- AIS pro svoji činnost primárně používá svá lokální data. U těchto dat by měl mít informaci, kdy byla konkrétní informace aktualizována ze systému ZR. Na základě této informace a podstaty business procesu realizovaného v AIS může nebo musí, buď AIS automaticky, nebo uživatel manuálně, rozhodnout o případné aktualizaci lokálních dat, a to podle případu užití, buď jako celku nebo konkrétního jednotlivého údaje.
- AIS si pravidelně aktualizuje svá data podle obsahu ZR. AIS by měl implementovat proces hromadné distribuce změn (viz kapitola Pravidelná distribuce změn). V rámci tohoto procesu AIS pravidelně v nočních hodinách získává aktuální informace o změnách v referenčních údajích. AIS ukládá informaci o posledním datu a čase aktualizace. Časování procesu je součástí popisu procesu ve výše odkazované kapitole. AIS může, buď na základě požadavku uživatele, nebo automaticky, provést aktualizaci dat pomocí procesu hromadné distribuce změn i mimo preferovaný pravidelný čas, v této době je však tento proces v rámci ISZR zpracováván s nižší prioritou.
- Online dotazy do ZR používá AIS pouze v případech, kdy to nezbytně potřebuje, nebo je to důsledek plynoucí z právních předpisů. Pro případy jako například běžná tabulka se seznamem údajů evidovaných v AIS by měl AIS pracovat s informací získanou v procesu pravidelné aktualizace (tedy AIS se při zobrazení každého jednotlivého záznamu v tabulce nedotazuje do ZR na osobu apod.). V případech plynoucích z právních předpisů, z obsahu lokálních dat nebo při on-line transakcích, kdy je komunikace se ZR nezbytná, použije AIS on-line dotazy. Příkladem může být ověření dle elektronického identifikačního průkazu, kdy občan musí zadat svůj BOK. BOK není součástí dat poskytovaných pro AIS, AIS tedy musí provést validaci přímo proti systému ZR voláním příslušné eGON služby.
- AIS si aktualizuje pouze data, která eviduje a která pro svoji činnost potřebuje. V rámci hromadné distribuce změn jsou poskytovány identifikátory údajů vedených v ZR, u kterých došlo ke změně. Pro data z ROB jsou tyto identifikátory omezeny přihlášením notifikací, pro ROS, RÚIAN a RPP jde o všechny identifikátory. AIS by měl ze seznamů, které nejsou omezeny (tj. ROS, RÚIAN, RPP), vybrat pouze objekty, které používá. Po určení identifikátorů pro aktualizaci provede AIS aktualizaci podle obsahu ZR.
3.9 Údaje z RÚIAN
Informace z RÚIAN jsou veřejné a relativně velmi statické informace. Z toho důvody by měl AIS v maximální možné míře využívat lokální data AIS v oblasti dat RÚIAN. V rámci volání eGON služeb existují služby, které umožňují jako součást odpovědi z ROS, ROB a RPP získat i detailní údaje z RÚIAN. Nicméně tyto informace by měl AIS primárně získávat ze svých lokálních dat.
AIS by měl respektovat následující doporučení:
- Pravidelně aktualizovat lokální data z RÚIAN.
- Před zápisem do ZR ověřit v lokálních datech existenci prvku v RÚIAN podle jeho identifikátoru.
- Pokud to specifikace eGON služby umožňuje, pak při volání eGON služby požadovat pouze referenční odkaz na RÚIAN, nepožadovat přímo data z RÚIAN. Následně informace vyhledat v lokální kopii dat RÚIAN.
3.10 Poskytování dat
Vybrané informace ze systému ZR jsou poskytovány prostřednictvím protokolů http / FTP. Přístup k těmto datům může být podle jejich povahy podmíněn použitím klientského certifikátu AIS. Data jsou poskytována jak na prostředcích ISZR, tak mohou být některá specifická data ze systému ZR poskytována na prostředcích mimo ISZR (tj. například na serveru mimo infrastrukturu systému ZR, například změnové soubory RÚIAN).
Princip poskytování dat je následující: existuje eGON služba, pomocí které může AIS získat informace o způsobu získání poskytovaných dat. V rámci této informace získává AIS jednak informaci o umístění a jednak informaci o zabezpečení přístupu k těmto datům. AIS tedy obdrží relevantní informace, které mohou obsahovat:
- Použitý protokol (http / FTP).
- Způsob přístupu (soubor / webová služba).
- URL.
- Vyžadování klientského certifikátu.
- Přístupové údaje.
AIS může následně tyto informace použít a příslušným způsobem data získat. V rámci tohoto způsobu mohou být poskytovány především:
- Data pro noční notifikace (hromadná distribuce změn).
- Veřejná data.
- Číselníky.
Přesná specifikace takto poskytovaných dat je součástí dokumentace poskytovatele dat. Příklad: eGON služba ruianSouboryDat
3.11 Bezpečnost / blokování AIS
Systém ISZR obsahuje mechanismus, který umožňuje detekovat různé problematické stavy. Příkladem takového problematického stavu může být opakované volání služby, na kterou volající nemá právo nebo volání, které není formálně správné. Při překročení určitého prahu těchto problémů, může být volající AIS zablokován na síťové úrovni a tedy ISZR se bude tomuto AIS jevit jako nedostupný. Tento práh je definován v aktuálně platné verzi Katalogu eGON služeb.
4. Obecné vlastnosti eGON služeb
V této kapitole jsou uvedeny společné vlastnosti eGON služeb poskytovaných ISZR.
4.1 Priorizace služeb
ISZR poskytuje pro AIS možnost upřednostňovat vykonávání eGON služeb. Upřednostňování vykonávání služeb je možné pouze v rámci služeb iniciovaných jedním AIS a současně v rámci shodné třídy služeb (třída služby je součástí definice eGON služby v katalogu služeb). Mechanismus upřednostňování na straně AIS není specifikován. Zda a jakým způsobem tento poskytnutý mechanismus AIS využije, závisí pouze na něm.
Technicky je pro nastavení priority vyhrazen konkrétní parametr eGON služby. Priorita je kladné celé číslo větší než nula, čím nižší číslo, tím vyšší priorita. Upřednostňování se týká pouze eGON služeb editačních a dotazovacích – viz rozdělení služeb v kapitole Členění eGON služeb.
Uvedení hodnoty priority nezaručuje, že upřednostněný požadavek bude zpracován dříve. Zda bude požadavek brán v potaz, závisí na aktuálním stavu, ve kterém je zpracování požadavků s vyšší prioritou.
Poznámka: jde o xml element žádosti PrioritaAis
4.2 Serializace požadavků
Serializace požadavku je mechanismus, který umožňuje AIS nastavit pořadí zpracování požadavků v systému ZR. Tento mechanismus je realizován pomocí identifikátoru požadavku AIS. Každý požadavek ze strany AIS musí obsahovat jedinečný (v rámci AIS) identifikátor jeho požadavku. Pokud chce AIS využít mechanismu serializace, musí v požadavku uvést i identifikátor předchozího požadavku AIS, tedy jeden identifikátor požadavku, na který má být zpracování vázáno. Tento požadavek zabezpečuje ISZR.
Pokud je v požadavku uveden identifikátor předchozího požadavku AIS, jsou pravidla pro serializaci následující:
- Požadavek může být zpracován pouze tehdy, pokud již byl úspěšně zpracován předchozí požadavek.
o Pokud nebyl předchozí požadavek dosud zpracován, je požadavek zařazen do fronty ke zpracování.
o Pokud byl předchozí požadavek dokončen s chybou, je zpracování tohoto požadavku ukončeno chybou „nelze serializovat“.
- Na jeden požadavek může být navázán pouze jeden následující požadavek.
o Pokud je detekováno, že byl zaslán druhý a další požadavek s jiným identifikátorem požadavku AIS a shodným identifikátorem předchozího
požadavku AIS, je zpracování tohoto požadavku ukončeno chybou „duplicita serializace“.
- Požadavky, které mají být serializovány, jsou z principu věci asynchronní (synchronní požadavek se zpracovává okamžitě, nezařazuje se do fronty).
- Systém přijímá i požadavky, u kterých v okamžiku přijetí nedokáže ověřit existenci předchozího požadavku (například mohlo dojít k výpadku komunikace při odesílání předchůdce z AIS, čili předchozí požadavek nebyl do ISZR doručen). Pokud je detekováno, že požadavek nemá předchůdce déle, než je maximální povolená doba pro doručení předchůdce, je zpracování požadavku ukončeno chybou „chybí předchůdce
v serializaci“.
- Zpracované požadavky mají definovanou dobu, po kterou jsou udržovány v systému. Po této době jsou ze systému odstraněny a není možné provést serializaci tak, že nový požadavek bude navázán na takto odstraněný požadavek. Doba pro udržování je definována v Katalogu eGON služeb.
Popis implementace chybových stavů serializace je uveden v technické části v kapitole Chybové stavy serializace.
4.3 Opakované volání služby při omezení dat
U vybraných eGON služeb může existovat omezení ZR na výdej dat (například služba rosCtiZmeny nebo orgCtiZmenyAIFO). Chování takových služeb je pak u služby specifikováno. Například u rosCtiZmeny se jako součást výstupu vrací pro každou změnu (každé IČO) i identifikátor změny. Pokud nejsou změny vydány všechny, musí AIS volat službu opakovaně s uvedením identifikátoru poslední změny. Jako odpověď jsou mu pak vydána data navazující na tuto změnu. V případě orgCtiZmenyAIFO se volá samostatná služba na poskytnutí další části změn.
4.4 AIFO – algoritmus generování
V dalším textu je v definovaných případech uveden termín algoritmus generování AIFO. Tento termín je použit z důvodu obecnosti dokumentu a z důvodu budoucího možného rozvoje celého systému ZR.
5. Obecná definice procesů
V této kapitole jsou popsány některé obecné situace z pohledu AIS. Způsob řešení těchto a dalších situací a způsob zpracování dalších procesů je popsán v následující kapitole.
5.1 Chování AIS pro použití eGON služeb a lokálních dat
Pro chování AIS z pohledu použití volání eGON služeb a použití lokálních dat platí:
- AIS provádí aktualizaci lokálních údajů; tím zajistí, že stav lokálních dat v AIS odpovídá stavu referenčních údajů k datu a času poslední aktualizace. Viz obecný proces v kapitole Hromadná distribuce změn.
- AIS u aktualizovaných údajů zaznamená čas poslední aktualizace údajů ze ZR, tj. uživatel vidí, kolik času uběhlo od poslední aktualizace dat ze ZR do AIS.
- AIS při práci s údajem poskytuje uživateli informaci o poslední aktualizaci údajů, tj. kdy AIS provedl aktualizaci údaje. Data může AIS podle potřeby aktualizovat selektivně. V případě požadavku uživatele na hromadnou aktualizaci údajů i během pracovního dne spustí AIS proces pro hromadnou distribuci změn.
- Čtení v reálném čase použije AIS pro následující situace:
o identifikace fyzické osoby (podle čísla elektronicky čitelného dokladu, případně s použitím BOK). Tato operace musí být vždy prováděna pomocí okamžitého čtení údaje v ZR,
o úřední proces vyžaduje naprostou jistotu, že se pracuje s aktuálními údaji,
o jde o on-line čtení jednoho nebo několika základních údajů ze ZR,
o vzniká pochybnost o správnosti údaje, pak se postupuje ve dvou krocích:
▪ okamžitá aktualizace údaje ze ZR,
▪ v případě, že hodnota referenčního údaje je nadále nesprávná, spouští se proces zpochybnění,
o do AIS je zaváděn nový subjekt a dochází k jeho vyhledání (ztotožnění) v ZR.
Tedy principiálně AIS používá dotazy do systému ZR pro operace s jedním údajem, pro hromadné operace (hromadná zobrazení) používá lokální data.
5.2 Hromadná distribuce změn
Základní pravidla pro práci se systémem ZR v oblasti aktuálnosti dat jsou:
- Existuje proces hromadné distribuce změn, který zajišťuje stav, kdy údaje v AIS odpovídají referenčním údajům v ZR k datu a času definovanému tímto procesem.
- Kdykoli během dne je možné získat notifikace o změnách, které nastaly během tohoto dne do okamžiku dotazu a stav údajů v AIS synchronizovat se stavem referenčních údajů.
- Je možné požádat o notifikace zpětně za delší časové období pro případ delšího výpadku AIS nebo hromadné distribuce změn.
Hromadná distribuce změn je proces, ve kterém AIS může získat informace o změnách provedených v systému ZR, a tím aktualizovat lokální data AIS.
Na základě těchto pravidel lze definovat dva procesy hromadné distribuce změn:
- Pravidelná – ISZR připravuje každý den sadu informací, v rámci které jsou pro AIS vystavovány změny za poslední kalendářní den, AIS musí tento proces spouštět v definovaném časovém rozmezí s definovanými parametry.
- Nepravidelná – AIS může sám zažádat o zaslání změn v libovolný okamžik, v tomto případě určuje počáteční (a případně koncový) okamžik změn.
Distribuce změn zahrnuje obecně následující detailní procesy:
- notifikace RÚIAN – v rámci této notifikace získává AIS informace o změnách v RÚIAN,
- notifikace ORG – v rámci této notifikace získává AIS informace o změnách AIFO,
- notifikace ROB – v rámci této notifikace získává AIS informace o změnách v XXX,
- notifikace ROS – v rámci této notifikace získává AIS informace o změnách v ROS.
Jednotlivé výše uvedené procesy z pohledu AIS jsou popsány níže. Pokud AIS tyto procesy realizuje, je doporučeno výše uvedené pořadí, vzhledem k referenčním vazbám mezi jednotlivými ZR (pokud AIS referenční integritu nevyřeší jiným způsobem).
5.3 Stav AIFO ve výsledku služeb – přidělené a zrušené AIFO
Při volání eGON služeb vracejících AIFO mohou nastat následující situace:
- Je vráceno AIFO, které AIS nezná - je přiděleno nové AIFO pro volající AIS,
- Je vráceno platné AIFO, které má AIS ve své evidenci,
- Již dříve přidělené AIFO pro volající AIS je zrušené.
5.3.1 Přiděleno nové AIFO
Jako výsledek volání eGON služby může AIS v odpovědi obdržet AIFOAIS přidělené fyzické osobě pro AIS. Jednou přidělené AIFOAIS pro tento AIS zůstává až do výskytu specifických případů (jako například kompromitace AIFO) identifikátorem fyzické osoby pro daný AIS. Chování AIS v případě přidělení AIFO je popsáno v kapitole Nakládání s AIFO po přidělení.
5.3.2 Zrušené AIFO
V definovaných případech může AIS v odpovědi na dotaz do ZR obdržet ve výsledku informaci o zrušení některého AIFO. Tato situace může nastat v případě, že:
- dojde ke sloučení osoby,
- dojde k rozdělení osoby,
- dojde ke kompromitaci AIFOAIS.
Sloučení osoby je situace, kdy je identifikováno, že jedna „fyzická“ osoba se v ROB vyskytuje vícekrát a tedy má přiděleno dvě nebo více AIFO. Výchozí stav tedy může být, že existuje
AIFO1 a AIFO2 a dva záznamy v ROB. Po jejich sloučení jsou AIFO1 i AIFO2 označeny jako neplatné. Současně vzniká nové AIFO3 a nový záznam v ROB.
Rozdělení osoby je situace, kdy je identifikováno, že pod jednou osobou v ROB jsou dvě nebo více „fyzických“ osob. Výchozí stav je, že existuje AIFO4. Po rozdělení je AIFO4 označeno jako neplatné a současně vznikají AIFO5, AIFO6, …a více příslušné záznamy v ROB.
Kompromitace AIFO je situace, kdy dojde k úniku informace vazby konkrétního občana a jeho AIFO7 v některém AIS. V tom případě je AIFO7 označeno jako zrušené a je nahrazeno novým AIFO8.
Specifickou situací je kompromitace všech AIFO v AIS. V tom případě jsou všechna AIFO (nejen ve všech AIS, ale ve všech agendách, ve kterých AIS vystupuje) označena jako zrušená a jsou nahrazena novými AIFO. Jsou tedy nahrazena i AIFO, které AIS nezpracovává, ale jsou evidovány jinými AIS ve stejné skupině agend.
Obě situace zrušení AIFO jsou standardně řešeny v rámci pravidelného procesu popsaného v kapitole Pravidelná distribuce změn, respektive jednotlivě Notifikace ORG.
6. Specifikace aktivit a postupů při výkonu agend OVM
Tato kapitola popisuje procesy správního řízení s důrazem na popis klíčových aktivit, které agenda OVM vykonává, a jejich vazby na funkce AIS zajišťující komunikaci se systémem ZR prostřednictvím volání eGON služeb.
Výše uvedený hrubý procesní model agendy ukazuje činnosti běžné v agendě z pohledu jednotlivých fází jejího životního cyklu: příjem, ověření, výkon a rozhodnutí. Příklady vybraných činností agendy, které jsou prováděny prostřednictvím AIS, představují základní naplnění legislativní povinnosti dané zákonem o základních registrech. Tyto činnosti jsou na schématu označeny zelenou barvou a jsou i s dalšími příklady, které využívají volání eGON služeb ZR, v následujících kapitolách detailně popsány.
6.1 Činnosti AIS pro čtení informací ze ZR
Činnosti agend OVM v roli čtenář realizované pomocí funkcí AIS žádným způsobem nemění existující referenční údaje v ZR, pouze prostřednictvím volání needitačních eGON služeb (S1, S2, S3 a S4) získávají referenční údaje.
6.1.1 Ověření totožnosti občana dle dokladu (ROB)
Jde o proces, kdy chce agenda OVM provést ověření totožnosti občana dle ROB. Východiskem pro tento proces je, že AIS zná číslo dokladu, druh dokladu a BOK.
6.1.1.1 Popis procesu
- AIS volá službu robAutentizace
o Vyplňuje parametry druh dokladu, číslo dokladu a BOK
o BOK AIS šifruje podle algoritmu šifrování BOK, používá k tomu příslušný veřejný klíč
- Předpoklady
o Lokální čas AIS musí být správný. Čas AIS se smí lišit od času ROB maximálně
o 60 vteřin.
o AIS má k dispozici klíč pro šifrování BOK
- Šifrování BOK
o Šifruje se následující řetězec (označujeme jako hlavní řetězec, HR):
<Čas><Agenda><Operace><ID žádosti><Typ dokladu><Číslo dokladu><rezerva><BOK>
Položka | Popis | Velikost | Formát/hodnota |
Čas | Jedná se o čas v UTC identifikující okamžik, kdy editorský AIS vytvořil zašifrovanou zprávu (a odeslal jí); za tímto účelem je vyžadována synchronizace hodin AIS se zdrojem přesného času | 14B ASCII text | YYYYMMDDHHMMSS |
Agenda | Kód agendy, která volá služby ROB | 36B ASCII text | V případě kratšího BOKu je blok doplněn znakem mezera zleva. |
Operace | Příznak určující, zdali je tento zašifrovaný blok dat ve volání služby ověřující nebo nastavující BOK | 1B | ‚0‘ … ověřování BOK ‚1‘ … nastavování BOK |
Položka | Popis | Velikost | Formát/hodnota |
ID žádosti | UUID žádosti, který byl vygenerován v AIS (v případě EOP pokud v době zašifrování dat není dostupný, tak je nahrazen řetězcem znaků mezera o délce 36B) | 36B ASCII text | AAAAAAAA-BBBB-CCCC-DDDD- EEEEEEEEEEEE |
Typ dokladu | Druh elektronicky čitelného dokladu (zatím pouze občanský průkaz s MRZ). | 2B ASCII text | hodnota 'ID' |
Číslo dokladu | Číslo dokladu, ke kterému je nastavován BOK | 9B ASCII text | |
Rezerva | 10B | ||
BOK | Samotná hodnota BOKu | 10B ASCII text | V případě kratšího BOKu je blok doplněn znakem mezera zleva. |
Pro šifrování vytvořeného řetězce HŘ je použité schéma založeno na hybridním šifrování, které pro šifrování řetězce HŘ používá symetrický algoritmus AES s náhodně voleným symetrickým klíčem a nulovým IV a pro zašifrování tohoto symetrického klíče je použit asymetrický algoritmus RSA s veřejným klíčem ROB (ROB zveřejní svůj certifikát). Struktura zprávy odpovídá standardu PKCS#7 (PKCS#7 enveloped message, lze použít i CMS/PKCS#7). Jsou uplatňovány následující vstupní předpoklady:
Symetrický šifrovací algoritmus: | AES-128 v CBC módu |
Použití AES: | šifrování řetězce HŘ s BOK |
Délka vstupního bloku AES: | 16 B (128 bitů) |
Délka výstupního bloku AES: | 16 B (128 bitů) |
Schéma šifrování AES: | AES128/CBC/PKCS7Padding |
Velikost IV pro AES: | 16B nulový IV |
Délka vstupního textu: | 128 B (14B čas v AIS + 36B kód agendy + 1B příznak operace + 36B ID žádosti + 2B typ dokladu + 9B číslo dokladu + 10B rezerva + 10B BOK + 10B PKCS7Padding) |
Asymetrický šifrovací algoritmus: | RSA s délkou klíče 2048 bitů |
Použití RSA: | šifrování symetrického klíče pro AES |
Délka vstupního bloku RSA: | 256B (2048 bitů) |
Délka výstupního bloku RSA: | 256B (2048 bitů) |
Schéma šifrování RSA: | RSA/ECB/PKCS1Padding |
Délka vstupního textu: | 256B (16B délka AES klíče + 240B PKCS1Padding) |
Formátování zprávy: | PKCS #7 Enveloped message (lze použít i CMS/PKCS7) |
Velikost encMSG: | 560 B (odhad, reálně velikost mezi 400 B a 1000 B) |
Při šifrování jsou použity následující předpoklady:
▪ Klíč AES je generován náhodně pro každý řetězec HŘ. Jeho generování (a tím i jeho náhodnost) zajišťuje AIS volající služby ROB. AIS je odpovědný za to, že nebude používat stejný klíč AES pro šifrování různých volání služeb ROB.
▪ Pro šifrování algoritmem AES je použit nulový IV, který následně není se zašifrovaným řetězcem HŘ přenášen z AIS do ROB.
▪ Pro šifrování náhodně generovaného klíče AES je použit veřejný RSA klíč certifikátu ROB, který poskytne ROB všem AIS. Pro všechny AIS bude používán jeden certifikát ROB. Generování, uchovávání (zejména ochranu soukromého
klíče) a správu tohoto certifikátu včetně jeho parametrů zajistí ROB (certifikát bude vydaný pravděpodobně CA ISZR a privátní klíč certifikátu bude uložený v ROB).
▪ Některé položky obsažené v řetězci HŘ jsou duplicitní s parametry volání webové služby, a to z důvodu jejich následné kontroly v ROB, která je prováděna při zpracování zprávy. Tento přístup zamezuje použití vytvořeného řetězce HŘ v jiném volání služby.
▪ Při kontrole v ROB proto musí položky HŘ souhlasit s aktuálním časem přijetí volání služby v ROB (v rámci definovaného časového okna) a s hodnotami uvedenými ve vlastním volání WS (tedy mimo řetězec HŘ).
Výsledná zpráva je pak vytvořena následovně:
encMSG = PKCS#7 (RSA ( AES klíč ), AES ( HŘ ))
6.1.1.2 Využité eGON služby
Služba | Popis |
robAutentizace | Služba zprostředkuje zjištění identity fyzické osoby prostřednictvím elektronického identifikačního dokladu. V případě, že číslo elektronického dokladu a případně BOK jsou ověřeny, vrací služba AIFO, v opačném případě je vydán chybový status. |
6.1.2 Ztotožnění občana v AIS s obyvatelem v ROB
Jde o proces, kdy chce agenda OVM provést ztotožnění občana vedeného v jejím AIS s občanem vedeným v XXX. Východiskem pro tento proces je, že AIS nezná AIFO občana, proto jej chce ztotožnit.
6.1.2.1 Popis procesu
- AIS volá službu robCtiPodleUdaju:
o Při zpracování v systému ZR je prováděno „přesné“ hledání. Nelze použít žádné zástupné znaky. Použití diakritiky je definováno parametrem služby s výchozí hodnotou definovanou v XSD (včetně diakritiky).
o Pokud nemají vstupní parametry dostatečnou selektivitu, služba vrací chybu.
o Je třeba použít definované minimální kombinace vstupních údajů, viz Přehled minimálních kombinací povinných parametrů dotazu.
o Služba vrací seznam občanů v definované struktuře podle požadovaných údajů včetně jejich AIFO.
- AIS by měl jednoznačně identifikovat ztotožňovaného občana:
o Pokud je AIS schopen provést jednoznačné ztotožnění, ukládá ve své databázi AIFO občana.
o Pokud AIS není schopen jednoznačného ztotožnění, AIFO nezakládá, a může dotaz opakovat s upravenými údaji. Případně se AIS dotáže ISEO nebo CIS podle údajů, které nejsou v ROB vedeny, např. rodného příjmení nebo rodného čísla.
- Pokud chce AIS získávat notifikace o změnách tohoto občana, musí zavolat i eGON službu orgPrihlasAIFO. Nově přidělené AIFO implicitně není k odběru notifikací ROB přihlášeno.
6.1.2.2 Využité eGON služby
Služba | Popis |
robCtiPodleUdaju | Služba zprostředkuje čtení referenčních údajů z ROB na základě vyhledání občana (fyzické osoby) podle kombinace údajů. Dotaz je omezen jen na ty údaje, které jsou vedeny přímo v ROB (adresa musí být zadána formou referenčního odkazu do RÚIAN). Výstupní formát služby je definován vstupním seznamem požadovaných referenčních údajů a právy podle RPP. Služba skládá údaje ze ZR ROB a RÚIAN. Služba podle výsledku dotazu vrací 0, 1, nebo více záznamů. |
orgPrihlasAIFO | Služba provede zaevidování AIFO k notifikaci změn v ROB pro volající AIS / agendu. |
6.1.3 Dotaz na občana (ROB)
Jde o proces, kdy chce agenda OVM vyhledat občana v XXX. Východiskem pro tento proces je, že AIS nezná AIFO občana.
6.1.3.1 Popis procesu
- AIS volá službu robCtiPodleUdaju:
o Při zpracování v systému ZR je prováděno „přesné“ hledání. Nelze použít žádné zástupné znaky. Použití diakritiky je definováno parametrem služby s výchozí hodnotou definovanou v XSD (včetně diakritiky).
o Pokud nemají vstupní parametry dostatečnou selektivitu, služba vrací chybu.
o Je třeba použít definované minimální kombinace vstupních údajů, viz Přehled minimálních kombinací povinných parametrů dotazu.
o Služba vrací seznam občanů v definované struktuře podle požadovaných údajů včetně jejich AIFO.
- AIS by měl jednoznačně identifikovat ztotožňovaného občana:
o Podle účelu vyhledání pak AIS může výsledek uložit ve své lokální databázi pro další použití.
Služba | Popis |
robCtiPodleUdaju | Služba zprostředkuje čtení referenčních údajů z ROB na základě vyhledání občana (fyzické osoby) podle kombinace údajů. Dotaz je omezen jen na ty údaje, které jsou vedeny přímo v ROB (adresa musí být zadána formou referenčního odkazu do RÚIAN). Výstupní formát služby je definován vstupním seznamem požadovaných referenčních údajů a právy podle RPP. Služba skládá údaje ze ZR ROB a RÚIAN. Služba podle výsledku dotazu vrací 0, 1, nebo více záznamů. |
6.1.4 Dotaz na osobu (ROS)
Jde o proces, kdy chce agenda OVM:
- Načíst informace o osobě v ROS podle XXX
- Načíst informace o osobě v ROS podle AIFO
- Vyhledat informace o osobě v ROS podle dalších údajů
6.1.4.1 Popis procesu
- Čtení informací o osobě v ROS dle XXX – AIS volá službu rosCtiIco – tuto službu lze volat pouze v případě, že má volající povolen přístup ke všem atributům osoby v ROS
o Pokud nemá volající povolen přístup ke všem atributům, volání skončí chybou.
o Služba vrací právě jeden záznam nebo informaci o nenalezení.
o Služba vrací kompletní údaje o osobě v ROS.
- Čtení informace o osobě v ROS dle AIFO – AIS volá službu rosCtiAifo – tuto službu lze volat pouze v případě, že má volající povolen přístup ke všem atributům osoby v ROS
o Pokud nemá volající povolen přístup ke všem atributům, volání skončí chybou.
o Služba vrací právě jeden záznam nebo informaci o nenalezení.
o Služba vrací kompletní údaje o osobě v ROS.
- Vyhledání informací o osobě v ROS – AIS volá službu rosCtiPodleUdaju
o AIS musí specifikovat údaje pro hledání. Hledání může proběhnout i podle XXX nebo AIFO.
o AIS by měl specifikovat, které údaje mají být při vyhledání vráceny.
o AIS může specifikovat počet vracených záznamů. Pokud je překročen interní parametr ZR nebo zadaný počet, služba vrátí informaci o překročení počtu. AIS by měl upřesnit parametry hledání nebo rozdělit dotaz na poddotazy (dotaz na základní údaje, dotaz na provozovny, dotaz na statutární zástupce).
Podle účelu vyhledání pak AIS může výsledek uložit ve své lokální databázi pro další použití.
Služba | Popis |
rosCtiIco | Služba na základě identifikace osoby pomocí IČO vrací referenční údaje. Služba skládá údaje ze ZR ROS, ROB a RÚIAN. |
rosCtiAifo | Služba umožňuje čtení referenčních údajů osoby identifikované pomocí AIFO (fyzická osoba podnikatele). Služba skládá údaje ze ZR ROS, ROB a RÚIAN. |
rosCtiPodleUdaju | Služba provádí vyhledání podle zadaných referenčních údajů a výdej údajů osob, které zadaným podmínkám odpovídají. Lze vyhledávat pouze podle údajů vedených přímo v ZR, tedy nikoli podle údajů adresy, s výjimkou hodnoty referenčního odkazu a nikoli údaje fyzických osob, s výjimkou jména, příjmení a XXXX. Služba skládá výstupní údaje ze ZR ROS, ROB a RÚIAN. Parametr maximální počet záznamů je omezen interním parametrem ZR. |
6.1.5 Dotaz na adresní místo (RÚIAN)
Jde o proces, kdy chce agenda OVM vyhledat nebo číst adresní místo.
6.1.5.1 Popis procesu
- AIS volá službu ruainVyhledejPrvekAdresniMisto. Tato služba slouží pro vyhledání dle parametrů.
o AIS specifikuje podmínku pro hledání.
o AIS specifikuje požadované údaje ve výsledku volání.
o Služba vrací informace o adresním místě. Služba může vracet jeden nebo více záznamů. Počet výsledků je omezen interním parametrem ZR. Při překročení počtu vrací služba chybu o překročení počtu a AIS musí upřesnit parametry pro vyhledávání.
- AIS volá službu ruianCtiPrvekAdresniMisto. Služba slouží pro čtení adresního místa podle jeho kódu. Na výstupu jsou informace o prvku včetně geografických informací v GML.
o AIS specifikuje kód adresního místa.
o AIS specifikuje požadované údaje ve výsledku volání.
o Služba vrací informace o adresním místě. Služba vrací maximálně jeden záznam.
6.1.5.2 Využité eGON služby
Služba | Popis |
ruainVyhledejPrvekAdresniMisto | Služba pro vyhledání prvků podle kritérií; vrací jeden či více prvků. Prvek je možno vyhledávat podle hodnot atributů daného prvku, nebo hodnot atributů |
nadřazených prvků. Služba vrací hodnoty požadovaných atributů daného prvku či nadřazených prvků. | |
ruianCtiPrvekAdresniMisto | Služba pro získání atributů prvku podle jeho ID. Služba vrací hodnoty požadovaných atributů daného prvku či nadřazených prvků. |
6.1.6 Notifikace ROB
Každý AIS, který eviduje fyzické osoby, může individuálně konfigurovat systém notifikací ze ZR pro své účely. AIS může nastavit, zda má být při změně referenčních údajů vedených v ROB, u osoby vedené i v AIS, notifikován o změně údajů této osoby (viz následující kapitola Přihlášení k notifikacím ROB).
Při přidělení AIFO pro konkrétní AIS je tato automatická notifikace vypnuta. Pokud AIS nemá notifikace nastaveny, neobdrží tuto změnu ve výsledku volání služby robCtiZmeny.
Jde o proces, který musí iniciovat AIS. Tedy AIS může tento proces provádět buď automaticky
– jde o doporučený způsob, postup a časování jsou popsány v kapitole Pravidelná distribuce změn, nebo jej AIS může provádět ručně či automaticky v jiném časování.
Počet změn vydaných v rámci volání služby je jednak omezen interním parametrem ZR, jednak může být omezen parametrem služby.
Vzhledem k filtrování AIFO v ORG dle přihlášení k notifikacím může AIS obdržet i menší než specifikovaný maximální počet záznamů. V tom případě musí, pokud chce obdržet všechny změny, provést opakované volání s uvedením identifikátoru poslední vydané změny z ROB.
ORG rovněž v notifikaci ROB vrací i zrušená AIFO. Jde zejména o osoby zaniklé zrušením ZIFO, sloučením více osob do jedné identity nebo naopak rozdělené. Při následném pokusu o aktualizaci údajů z ROB může dojít u těchto AIFO k navrácení chyby NEEXISTUJÍCÍ AIFO.
Možné způsoby řešení situace neplatného AIFO:
• Před spuštěním robCtiZmeny se informovat o změnách AIFO prostřednictvím
orgCtiZmenyAIFO.
• Nebo při obdržení chyby NEEXISTUJÍCÍ AIFO zjistit příčinu pomocí orgZkontrolujAIFO, pro zjištění následníků AIFO lze použít orgRodokmenAIFO.
• Nebo provést ručně opětovné ztotožnění osoby z ROB.
Upozornění: pokud AIS zpracovává notifikace mimo doporučený časový rámec, mají tyto procesy v ISZR nastavenu nižší prioritu pro zpracování než v případě použití doporučeného postupu.
Doporučený způsob je popsán v kapitole Pravidelná distribuce změn. Mimo toto doporučení je popis procesu následující:
- AIS volá eGON službu robCtiZmeny. Uvádí počáteční datum nebo identifikátor změny, od kterého požaduje údaje poskytnout a typy údajů, pro které chce získat seznam změn, typicky tedy všechny údaje, které AIS eviduje, i když může chtít pouze vybrané.
- ISZR vrací seznam AIFO přihlášených k notifikacím pro daný AIS, u nichž došlo v zadaném časovém intervalu ke změně některého požadovaného údaje. Tento seznam je omezen na maximální počet definovaný vnitřním parametrem ZR.
- Pokud AIS detekuje ve výsledku volání služby robCtiZmeny, že nebyl vydán celý seznam, musí opakovaně i několikrát provést volání robCtiZmeny s parametrem posledního vydaného identifikátoru změny. Dílčí předaný seznam může být i prázdný, což znamená, že ze vstupního souboru z ROB žádné AIFOAIS nevyhovělo v ORG podmínce pro zařazení do notifikace.
- AIS pro získaný seznam volá eGON službu robCtiHromadneAIFO. Výstup této služby je omezen interním parametrem na maximální počet záznamů. AIS tedy v případě, že je požadovaný počet změn větší než definovaný parametr, musí zajistit rozložení všech získaných AIFO do více skupin a pro každou skupinu volat samostatně službu robCtiHromadneAIFO.
6.1.6.2 Využité eGON služby
Služba | Popis |
robCtiZmeny | Služba vydá seznam přihlášených AIFO, ve kterých došlo ke změně referenčních údajů požadovaného typu od okamžiku definovaného časovým údajem nebo identifikátorem změny uvedeným ve vstupním parametru služby. |
robCtiHromadneAIFO | Služba vydává požadované údaje osob z XXX ve formě opakované struktury požadovaných dat podle předaného seznamu AIFO. Služba skládá údaje ze ZR ROB a RÚIAN. |
6.1.7 Přihlášení k notifikacím ROB
Systém notifikací ROB je v okamžiku přidělení každého jednotlivého AIFO pro AIS ve výchozím stavu vypnutý. Aby byl AIS při změně referenčních údajů o osobě notifikován, musí explicitně notifikace pro konkrétní osobu povolit.
Povolení příjmu notifikací může AIS provést kdykoliv. Z procesního hlediska, pokud má AIS o tyto notifikace zájem, se jako nejvhodnější okamžik pro přihlášení k notifikacím jeví navázání této akce na proces ztotožnění osoby v ROB. Tento proces je popsán v kapitole Ztotožnění osoby v AIS s osobou v XXX. V případě pochybností o stavu nastavení může AIS volání služby kdykoliv opakovat.
- AIS volá eGON službu orgPrihlasAIFO s parametrem AIFO.
6.1.7.2 Využité eGON služby
Služba | Popis |
orgPrihlasAIFO | Služba provede zaevidování AIFO k notifikaci změn v ROB pro volající AIS / agendu. |
6.1.8 Vyzvednutí aktuálních údajů dle notifikace XXX
Vyzvednutí aktuálních údajů dle notifikace ROB provádí AIS pomocí volání služby
robCtiHromadneAifo. Kompletní proces notifikací je popsán v kapitolách:
- Pravidelná distribuce změn
- Přihlášení k notifikacím ROB
6.1.8.1 Popis procesu
- AIS volá eGON službu robCtiHromadneAifo se seznamem AIFO, o kterých chce načíst informace.
- AIS by měl specifikovat, které údaje chce načíst. Musí uvést pouze takové údaje, ke kterým má oprávnění.
- Pokud je překročen interní parametr pro počet záznamů, vrací se chyba a AIS musí omezit počet vstupních AIFO.
6.1.8.2 Využité eGON služby
Služba | Popis |
robCtiHromadneAIFO | Služba vydává požadované údaje osob z XXX ve formě opakované struktury požadovaných dat podle předaného seznamu AIFO. Služba skládá údaje ze ZR ROB a RÚIAN. |
6.1.9 Odhlášení z notifikací ROB
V případě, že má AIS zapnutý příjem notifikací z ROB a již dále nechce změny v ZR u osoby evidovat (například osoba z nějakého důvodu není v působnosti daného AIS), může AIS odhlásit osobu ze systému notifikací.
Odhlášení příjmu notifikací může AIS provést kdykoliv. Pokud je osoba vyřazena z evidence agend v rámci AIS, pak je AIS povinen odhlásit osobu ze systému notifikací.
- AIS volá eGON službu orgOdhlasAIFO s parametrem AIFO.
6.1.9.2 Využité eGON služby
Služba | Popis |
orgOdhlasAIFO | Služba provede odhlášení AIFO od notifikace změn v ROB pro volající AIS / agendu. |
6.1.10Vyzvednutí aktuálních údajů dle notifikace ROS
Proces umožňuje získat informace o změnách v ROS. Proces musí iniciovat AIS. AIS může tento proces provádět buď automaticky – jde o doporučený způsob, postup a časování jsou popsány v kapitole Pravidelná distribuce změn, nebo jej může AIS provádět ručně či automaticky v jiném časování.
Upozornění: pokud AIS zpracovává notifikace mimo doporučený časový rámec, mají tyto procesy v ISZR nastavenu nižší prioritu pro zpracování, než v případě použití doporučeného postupu.
6.1.10.1 Popis procesu
Doporučený způsob je popsán v kapitole Pravidelná distribuce změn. Mimo toto doporučení je popis procesu následující:
- AIS volá eGON službu rosCtiZmeny.
o AIS ve výsledku služby získá odkaz na seznam IČO, u kterých došlo ke změně.
- AIS volá eGON službu rosCtiSeznamICO pro čtení informací z XXX podle XXX pro vybrané XXX (vedené ve své evidenci – filtruje si před voláním získaný seznam) a aktualizuje svá lokální data.
6.1.10.2 Využité eGON služby
Služba | Popis |
rosCtiZmeny | Služba umožňuje pravidelnou aktualizaci datové základny AIS. Vydává seznam IČO všech záznamů, ve kterých došlo ke změně referenčních údajů od okamžiku uvedeného ve vstupním parametru služby, případně v rámci zadaného časového úseku. Seznam IČO je množstevně omezen interním parametrem ZR, v případě potřeby je nutno službu volat několikrát. |
rosCtiSeznamICO | Podle předaného seznamu IČO ZR vydá požadované údaje osob ve formě opakované struktury požadovaných údajů. |
6.1.11Vyzvednutí aktuálních údajů dle notifikace RÚIAN
Proces umožňuje získat informace o změnách v RÚIAN. Proces musí iniciovat AIS. AIS může tento proces provádět buď automaticky – jde o doporučený způsob, postup a časování jsou popsány v kapitole Pravidelná distribuce změn, nebo jej může AIS provádět ručně či automaticky v jiném časování.
Upozornění: pokud AIS zpracovává notifikace mimo doporučený časový rámec, mají tyto procesy v ISZR nastavenu nižší prioritu pro zpracování, než v případě použití doporučeného postupu.
6.1.11.1 Popis procesu
Doporučený způsob je popsán v kapitole Pravidelná distribuce změn. Mimo toto doporučení je popis procesu následující:
- AIS volá eGON službu ruianCtiSeznamZmen.
o AIS ve výsledku volání služby získá seznam typů prvků a jejich ID.
- AIS volá eGON službu ruianCtiPrvek pro čtení informací z RÚIAN dle ID prvku pro vybrané prvky (vedené ve své evidenci – filtruje si před voláním získaný seznam) a aktualizuje svá lokální data.
6.1.11.2 Využité eGON služby
Služba | Popis |
ruianCtiSeznamZmen | Služba pro získání seznamu identifikátorů a typů prvků, které se v zadaném časovém intervalu od minulosti do přítomnosti jakkoli změnily (změna, oprava, vznik, zánik). |
ruianCtiPrvek | Služba pro získání atributů prvku podle jeho ID. Služba vrací hodnoty požadovaných atributů daného prvku či nadřazených prvků. |
6.1.12Vyzvednutí aktuálních údajů dle notifikace ORG
Proces umožňuje získat informace o změnách AIFO v ORG. Tyto notifikace se týkají operací nad AIFO, jehož důsledkem je jeho zneplatnění a nahrazení. Proces musí iniciovat AIS. AIS může tento proces provádět buď automaticky – jde o doporučený způsob, postup a časování jsou popsány v kapitole Pravidelná distribuce změn, nebo jej může AIS provádět ručně či automaticky v jiném časování.
Upozornění: pokud AIS zpracovává notifikace mimo doporučený časový rámec, mají tyto procesy v ISZR nastavenu nižší prioritu pro zpracování, než v případě použití doporučeného postupu.
6.1.12.1 Popis procesu
Doporučený způsob je popsán v kapitole Pravidelná distribuce změn. Mimo toto doporučení je popis procesu následující:
- AIS volá službu orgCtiZmenyAIFO.
- AIS ve výsledku dostává první část seznamu zneplatněných AIFO (díky kompromitaci, sloučení, rozdělení nebo změně algoritmu generování AIFO) a seznam AIFO, která je nahrazují a aktualizuje si svá lokální data. Parametrem na vstupu může AIS ovlivnit velikost notifikačního seznamu. Max. horní limit je však v ORG omezen na 1000 záznamů, min. 500. Na testovacím prostředí je rozsah 50-100. Dále AIS obdrží informace o čísle dávky a celkovém počtu dávek ke stažení.
- AIS opakovaně volá službu orgCtiDavkuAIFO pro získání zbývajících dávek notifikací AIFO.
- Po stažení poslední dávky nebo do 24 hod od volání orgCtiDavkuAIFO jsou na straně ORG soubory smazány.
- Aktualizaci provede dle postupu popsaného v kapitole Nakládání s AIFO po zrušení.
6.1.12.2 Využité eGON služby
Služba | Popis |
orgCtiZmenyAIFO | Služba umožňuje vrátit první dávku seznamu zneplatněných AIFO (díky kompromitaci, sloučení, rozdělení nebo změně algoritmu generování AIFO) a seznam AIFO, které je nahrazují. (Seznam je dodán ve formě dvojic AIFO s indexy, které definují hrany orientovaného grafu). |
orgCtiDavkuAIFO | Služba poskytne další dávku notifikací dle specifikace v parametrech na vstupu. |
6.1.13Vyzvednutí aktuálních údajů dle notifikace RPP
RPP poskytuje službu pro zjištění změn v referenčních údajích uložených v RPP. Jde o službu
rppCtiZmeny.
6.1.13.1 Popis procesu
- AIS volá službu rppCtiZmeny. Jako parametr udává počátek intervalu nebo definované období (od, do) a typy změn, které chce ve výsledku získat.
- Na výstupu služby jsou definované změny.
- Pokud je překročen limit pro výpis, je tato informace na výstupu služby uvedena. AIS může volat službu znovu s tím, že jako počátek uvede identifikaci změny, která byla obsažena ve výstupu služby, která skončila oznámením o překročení seznamu.
- Podle naplnění parametru typu změny lze získat informace o změnách v agendách, působnostech nebo rozhodnutích. Na výstupu je vždy příslušný identifikátor. Podle typu změny a identifikátoru může AIS volat příslušnou službu pro načtení detailní informace o agendě, působnosti nebo rozhodnutí – rppVypisAgendu, rppVypisPusobnostOvm
a rppVypisRozhodnuti.
6.1.13.2 Využité eGON služby
Služba | Popis |
rppCtiZmeny | Poskytnutí informací o změnách v referenčních údajích (agenda, působnost, rozhodnutí) v RPP za určený časový interval. |
rppVypisAgendu | Služba na základě vstupních parametrů (kód a platnost od) poskytne kompletní informace o dané agendě z RPP. Parametr výpis za budoucí platnost umožní v defaultním stavu výpis jen aktuálně platných záznamů, při nastavení na true se vypisují agendy aktuálně platné i platné v budoucnu. |
rppVypisPusobnostOvm | Poskytnutí detailních informací o působnosti OVM v agendě, definovaných v katalogu působností na základě vstupních parametrů (agenda, OVM). |
rppVypisRozhodnuti | Služba na základě vstupních parametrů poskytne kompletní informace o rozhodnutí z RPP v požadované struktuře. |
6.2 Sdílené funkce AIS pro podporu výkonu agend OVM
6.2.1 Práce s číselníky
Prostřednictvím systému ZR mohou být distribuovány centrální číselníky. ISZR poskytuje obecný mechanismus pro distribuci číselníků.
6.2.1.1 Popis procesu
- AIS si načte seznam poskytovaných číselníků pomocí služby iszrCtiSeznamCiselniku.
- AIS si zaeviduje, které z poskytovaných číselníků chce získávat.
- AIS volá opakovaně pro každý požadovaný číselník službu iszrCtiSouborCiselniku.
- ISZR vrací informace o způsobu distribuce číselníku, podle popisu v kapitole Poskytování dat.
- AIS podle získané informace o umístění a způsobu přístupu načítá definovaný číselník. Není zaručeno, že veškeré takto distribuované informace lze automaticky zpracovávat.
6.2.1.2 Využité eGON služby
Služba | Popis |
iszrCtiSeznamCiselniku | služba vrací seznam poskytovaných číselníků včetně popisů a kódů číselníků a jejich verzi. |
iszrCtiSouborCiselniku | služba na základě kódu číselníku vrací odkaz na poskytovaný číselník, informace o jeho struktuře a jeho verzi. |
6.2.2 Asynchronní služby a výstupní fronta
Definovaná část eGON služeb je poskytována v asynchronním režimu. Základní popis asynchronního režimu je uveden v kapitole Asynchronní režim eGON služeb.
Asynchronní eGON služba je tedy služba, kdy jako odpověď na volání eGON služby je volajícímu AIS doručena informace o identifikátoru požadavku AIS v ISZR.
Popis chování a služeb výstupní fronty je uveden v samostatné kapitole Výstupní fronta pro výsledky asynchronních eGON služeb.
AIS může navíc u některých služeb definovat způsob doručení odpovědi. Existují následující režimy pro doručení odpovědi:
- pasivní režim odpovědi,
- aktivní režim odpovědi.
Pojem aktivity je chápán z pohledu chování ISZR.
6.2.2.1 Pasivní režim odpovědi (POP)
V případě pasivní odpovědi ISZR je odpověď zařazena do výstupní fronty. AIS musí výsledek z této fronty sám vyzvednout. Výstupní fronty jsou pro jednotlivé AIS odděleny, AIS tedy může číst pouze odpovědi určené pro tento AIS.
6.2.2.1.1 Popis procesu
- AIS volá eGON službu,
- AIS v odpovědi získá identifikátor požadavku ISZR.
AIS může pracovat dvěma způsoby, buď ověřuje existenci konkrétního výsledku:
- AIS v definovaných intervalech kontroluje existenci konkrétního výsledku pomocí služby iszrAsyncOdpovedZFronty:
o pokud výsledek existuje, AIS jej obdrží,
o pokud výsledek dosud není připraven, dostává AIS informaci o nedokončeném zpracování,
o AIS po určité době (řádově doporučeno několik minut) opakuje dotaz na výsledek služby,
nebo si nechává vypsat seznam připravených odpovědí, které vyzvedává:
- AIS opakovaně po uplynutí časového intervalu (řádově doporučeno několik minut) čte obsah výstupní fronty pomocí služby iszrAsyncVypisFronty. Všechny identifikátory vrácené ve volání této služby mají připravenu odpověď, AIS může individuálně jednotlivé odpovědi vyzvednout voláním služby iszrAsyncOdpovedZFronty,
- délka výstupu z fronty je omezena interním parametrem ISZR, v odpovědi je příznak existence pokračování seznamu odpovědi. V tom případě může AIS získat pokračování výpisu opakovaným voláním služby iszrAsyncVypisFronty s uvedením počátečního identifikátoru odpovědi.
Po vyzvednutí odpovědi by měl AIS vyzvednutou odpověď z jeho fronty smazat. Toto je doporučeno z důvodu, že si tím AIS omezí velikost jeho výstupní fronty a omezí případnou nutnost opakovaného volání seznamu zpracovaných odpovědí, pokud délka tohoto seznamu překročí interní limit pro délku odpovědi této služby.
- AIS po vyzvednutí výsledku z fronty volá službu iszrAsyncSmazatFrontu s identifikací požadavků, které chce z fronty smazat. Pokud AIS tuto službu nepoužije, jsou po definované době výsledky z fronty automaticky odstraněny. Doba je definována v katalogu eGON služeb.
6.2.2.1.2 Využité eGON služby
Služba | Popis |
iszrAsyncVypisFronty | Služba umožňuje získat seznam identifikátorů zpracovaných odpovědí z výstupní fronty. |
iszrAsyncOdpovedZFronty | Služba umožňuje vyzvednout odpověď z výstupní fronty. |
iszrAsyncSmazatFrontu | Služba umožňuje smazat odpovědi z fronty. |
6.2.2.2 Aktivní režim odpovědi (PUSH)
V případě aktivní odpovědi ISZR může AIS specifikovat URL, na který má být odpověď z ISZR doručena. Aby byl tento způsob doručení možný, musí AIS splňovat definovaná kritéria. Tato kritéria jsou uvedena v kapitole Podmínky pro aktivní doručení odpovědi do AIS.
6.2.2.2.1 Popis procesu
- AIS volá eGON službu a uvádí URL pro odpověď.
- AIS v odpovědi získá Identifikátor požadavku ISZR.
- ISZR po zpracování výsledku odesílá výsledek na webovou službu AIS:
o Pokud není možné odeslání provést, provádí ISZR definovaný počet pokusů
o odeslání po definované době. Aktuální hodnoty jsou uvedeny v katalogu eGON služeb.
o Pokud ISZR nedokáže výsledek odeslat ani po stanoveném počtu pokusů, další pokus neprovádí. AIS může sám výsledek vyzvednout z výstupní fronty pomocí služeb pro čtení fronty v pasivním režimu odpovědi.
- Po aktivním odeslání výsledku do AIS zůstává odeslaný požadavek ve frontě výsledků ISZR, dokud jej AIS nesmaže nebo dokud nevyprší doba pro jeho platnost ve výstupní frontě.
- V případě aktivního režimu může AIS použít stejný postup pro získání odpovědi jako v případě pasivního režimu.
- AIS musí sám ošetřit, že v případě kombinace pasivního a aktivního režimu nedojde k nekonzistenci vzhledem k tomu, že AIS může stejný výsledek získat několikrát (aktivně i pasivně).
- AIS by po získání výsledku měl odstranit výsledek z fronty. AIS může volat službu iszrAsyncSmazatFrontu s identifikací požadavků, které chce z fronty smazat. Pokud AIS tuto službu nepoužije, jsou po definované době výsledky z fronty automaticky odstraněny. Viz také popis v kapitole Pasivní režim odpovědi (POP).
6.2.2.2.2 Využité eGON služby
Služba | Popis |
iszrAsyncSmazatFrontu | Služba umožňuje smazat odpovědi z fronty. |
6.2.2.3 Podmínky pro aktivní doručení odpovědi do AIS
Aby bylo možné provádět doručení odpovědi na asynchronní eGON službu do AIS v aktivním režimu (PUSH), musí být splněno několik podmínek:
- AIS musí implementovat mechanismus pro zaslání požadavku na eGON službu s aktivním režimem odpovědi.
- AIS musí mít vystavenu přesně definovanou webovou službu pro zasílání odpovědí.
Specifikace je součástí XSD / WSDL specifikace eGON rozhraní ISZR.
- Přístup ke službě musí být poskytován pomocí protokolu https na portu 443.
- Serverový certifikát použitý pro protokol https musí být důvěryhodný, vydaný obecně uznávaným vydavatelem certifikátů (vzhledem k tomu, že jde o serverový certifikát AIS).
- Přístup k webové službě AIS musí být možný prostřednictvím KIVS.
Technický popis implementace je uveden v technické části v kapitole Asynchronní služba s aktivním režimem odpovědi.
Poznámka: webová služba AIS pro příjem asynchronní odpovědi musí být implementována tak, aby odpovídala jejímu technickému popisu – Popis datových typů – soubory /egon/wsdl/ IszrAsyncPushOdpovedZFronty.wsdl a /egon/xsd/ IszrAsyncPushOdpovedZFronty.xsd
6.2.3 Nakládání s AIFO po přidělení
AIS může ve výsledku služby obdržet AIFO, které nemá ve své evidenci.
6.2.3.1 Popis procesu
- AIS se musí rozhodnout, zda osobu uložit do svých lokálních dat.
- Pokud chce osobu uložit a ve výsledku nebyly údaje osoby, volá eGON službu pro čtení dat z ROB robCtiAIFO, případně robCtiHromadneAIFO. Získané údaje ukládá do svých lokálních dat.
- Pokud osobu uložil a chce o ní získávat notifikace z ROB, volá službu orgPrihlasAIFO.
6.2.3.2 Využité eGON služby
Služba | Popis |
robCtiAIFO | Služba zprostředkuje čtení referenčních údajů ze ZR ROB. |
robCtiHromadneAIFO | Služba zprostředkuje hromadné čtení referenčních údajů ze ZR ROB. |
orgPrihlasAIFO | Služba provede zaevidování AIFO k notifikaci změn v ROB pro volající AIS. |
6.2.4 Nakládání s AIFO po zrušení
AIS může ve výsledku služby obdržet informaci o zrušení AIFO. Při zrušení v rámci výsledku obdrží i informaci o důvodu zrušení.
Informace o zrušení AIFO a podklady pro vyřešení této situace se promítají do výsledků eGON služby orgCtiZmenyAIFO. Pomocí této služby může AIS získat informace o neplatných AIFO ve své evidenci a o nových AIFO, která je nahrazují. Tyto informace získává v podobě orientovaného grafu (seznam dvojic původní AIFO – nové AIFO). Provedením této služby jsou nová AIFO považována za použitá v AIS. Služba orgCtiZmenyAIFO se obecně používá v procesu notifikací, který je popsán v kapitole Notifikace ORG.
Pro detailnější informace může dále AIS využít funkce:
- orgZkontrolujAIFO – vrací důvod zrušení AIFO
- orgRodokmenAIFO – vrací seznam dvojic původní AIFO – nové AIFO
- orgPredchudciAIFO – vrací seznam předchůdců AIFO
6.2.4.1 Popis procesu
- AIS volá eGON službu orgCtiZmenyAIFO.
- Ve výsledku obdrží seznam původních AIFO a AIFO, kterými byla AIFO nahrazena. Ve zcela obecném teoretickém případě může být n AIFO nahrazeno m novými AIFO.
- AIS podle výsledku musí rozhodnout, jak se zachová pro jednotlivé případy změn:
o Pokud AIS dokáže jednoznačně rozhodnout, jakým způsobem bylo provedeno nahrazení, může provést opravu / změnu AIFO ve svých lokálních datech.
o Pokud AIS nedokáže jednoznačně identifikovat nahrazení, musí opravu vazeb nechat na proces ztotožnění, viz popis v kapitole Ztotožnění osoby v AIS s osobou v XXX.
V souvislosti se zrušením AIFO platí následující pravidla pro nastavení notifikací ROB:
- U nahrazení jednoho AIFO jedním AIFO (kompromitace, změna algoritmu) je nastavení notifikace zachováno.
- Při sloučení nebo rozdělení je u nových AIFO notifikace ve výchozím stavu vypnuta. Pokud AIS opravu provede, může pro nové AIFO volat službu orgPrihlasAIFO pro příjem notifikací z ROB.
6.2.4.2 Využité eGON služby
Služba | Popis |
orgCtiZmenyAIFO | Služba umožňuje vrátit seznam zneplatněných AIFO (díky kompromitaci, sloučení, rozdělení nebo změně algoritmu generování AIFO) a seznam AIFO, které je nahrazují. |
6.2.5 Nakládání s AIFO při kompromitaci
Kompromitace AIFO je zvláštním případem zrušení AIFO. V tomto případě je provedena náhrada AIFO jedna k jedné. Ve výsledku služby je pro AIFO uveden důvod kompromitace AIFO.
6.2.5.1 Popis procesu
Ošetření kompromitace prakticky odpovídá procesu zrušení AIFO a lze je sloučit do jednoho procesu:
- AIS volá eGON službu orgCtiZmenyAIFO, případně službu orgCtiDavkuAIFO,
- AIS ve výsledku identifikuje kompromitovaná AIFO,
- AIS provede náhradu kompromitovaných AIFO za nově přidělená AIFO.
6.2.5.2 Využité eGON služby
Služba | Popis | ||||
orgCtiZmenyAIFO | Služba umožňuje vrátit první dávku seznamu zneplatněných AIFO (díky kompromitaci, sloučení, rozdělení nebo změně algoritmu generování AIFO) a seznam AIFO, které je nahrazují. | ||||
orgCtiDavkuAIFO | Služba poskytne další v parametrech na vstupu. | dávku | notifikací | dle | specifikace |
6.2.6 Pravidelná distribuce změn
Jde o proces, při kterém AIS získává pravidelné aktualizace ze systému ZR za účelem jejich synchronizace se svými lokálními daty. Proces musí AIS provádět pravidelně na denní bázi. Při jeho přerušení (například z důvodu chyby komunikace, odstávky AIS) musí AIS provést synchronizaci, která zajistí, že bude moci v tomto procesu založeném na denní bázi pokračovat.
Celý proces pravidelné distribuce změn musí AIS provést v období mezi 0:30 a 6:00 běžného dne, aby získal změny za předešlý kalendářní den.
V jednotlivých krocích procesu v ideálním případě použije AIS u všech služeb jako rozsah pro omezení data aktualizací předešlý kalendářní den.
Pokud AIS nepoužije pro omezení čtení změn předešlý kalendářní den, bude operace provedena, nebude ovšem optimalizována a bude potenciálně trvat déle.
6.2.6.1 Popis procesu
- Krok 1 - viz popis procesu Notifikace ORG
- Krok 2 - viz popis procesu Notifikace RÚIAN
- Krok 3 - viz popis procesu Notifikace ROB
- Krok 4 - viz popis procesu Notifikace ROS
6.2.6.2 Využité eGON služby
Viz využité služby u jednotlivých procesů.
Poznámka: je potřeba brát v úvahu možnost rozdělení odpovědí při omezení počtu vydávaných údajů ze ZR, viz kapitola Opakované volání služby při omezení dat.
6.2.7 Lokální inicializace dat z RÚIAN
Doporučeným způsobem evidence údajů z RÚIAN jsou lokální data AIS. AIS může provést inicializaci těchto dat.
6.2.7.1 Popis procesu
- AIS volá eGON službu ruianSouboryDat.
- Výsledkem služby jsou odkazy na kompletní soubory dat RÚIAN.
- AIS stahuje soubory z uvedených adres a plní jimi své lokální datové úložiště.
- Aktualizaci dat může AIS provádět těmito způsoby:
o Pomocí procesu popsaného v kapitole Notifikace RÚIAN. AIS použije eGON službu ruianCtiSeznamZmen, která vrátí seznam změn a následně službu ruianCtiPrvek pro načtení změněných prvků.
o Pomocí eGON služby ruianSouboryZmen, která vrátí odkazy na změnové soubory od zadaného data. AIS musí následně tyto soubory načíst a interpretovat.
6.2.7.2 Využité eGON služby
Služba | Popis |
ruianSouboryDat | Služba pro poskytnutí odkazů na soubory s kompletními daty RÚIAN. |
ruianCtiSeznamZmen | Služba pro získání seznamu identifikátorů a typů prvků, které se v zadaném časovém intervalu od minulosti do přítomnosti jakkoli změnily (změna, oprava, vznik, zánik). |
ruianCtiPrvek | Služba pro získání atributů prvku podle jeho ID. Služba vrací hodnoty požadovaných atributů daného prvku či nadřazených prvků. |
ruianSouboryZmen | Služba pro poskytnutí odkazů na soubory se změnovými větami od zadaného data do současnosti. |
6.2.8 Referenční odkazy do RÚIAN
Identifikátor adresního místa je vázán na jednoznačnou kombinaci územních prvků obec, část obce, ulice, číslo popisné, číslo evidenční, číslo orientační, přičemž některé z těchto prvků nemusí být vyplněny. Doporučeným způsobem evidence údajů z RÚIAN jsou lokální data. Na základě toho je tedy doporučený postup pro získání identifikátoru adresního místa v popisu níže.
6.2.8.1 Popis procesu
- AIS hledá ID adresního místa ve svých lokálních datech.
- Nalezené ID AIS použije ve volání eGON služby vyžadující odkaz na adresní místo.
- AIS provádí pravidelnou aktualizaci lokálních dat z RÚIAN podle popisu procesu Notifikace RÚIAN.
6.2.8.2 Využité eGON služby
V ideálním případě AIS volání eGON služby nepoužívá. AIS může použít eGON službu
ruianVyhledejAdresu.
Služba | Popis |
ruianVyhledejAdresu | Služba pro vyhledání adresy na základě předaných adresních údajů. |
6.2.9 Výpis veřejných údajů z RÚIAN
RÚIAN poskytuje veřejná data prostřednictvím souborů. Tyto soubory jsou uloženy mimo systém ZR. Pro zjištění místa jejich uložení jsou na eGON rozhraní vystaveny webové služby.
6.2.9.1 Popis procesu
- AIS volá službu ruainSouboryDat. V odpovědi získává URL adresu, na které je k dispozici příslušný soubor dat.
- AIS může příslušným protokolem patrným z URL adresy ve výsledku eGON služby stáhnout poskytovaný soubor dat a využít jej pro naplnění nebo aktualizaci své lokální databáze.
6.2.9.2 Využité eGON služby
Služba | Popis |
ruainSouboryDat | Služba pro poskytnutí odkazů na soubory s kompletními daty RÚIAN. |
6.2.10Vyslání podnětu k reklamaci údajů
Na eGON rozhraní jsou vystaveny služby, které umožňují iniciovat proces zpochybnění údajů. Prostřednictvím těchto služeb je zpochybnění doručováno k editorům jednotlivých údajů v ZR.
6.2.10.1 Popis procesu
- AIS volá podle objektu zpochybnění příslušnou službu. Prostřednictvím systému ZR je odpověď služby odeslána k příslušnému editorovi.
- Pro reklamaci údaje v ROB je vystavena služba iszrReklamujUdajeROB.
- Pro reklamaci údaje v ROS je vystavena služba iszrReklamujUdajeROS.
- Pro reklamaci údaje v RÚIAN jsou vystaveny služby isuiReklamujPrvek
a isknReklamujPrvek.
- Reklamace údaje v RPP se neprovádí webovou službou, provádí se podáním do příslušné datové schránky.
6.2.10.2 Využité eGON služby
Služba | Popis |
iszrReklamujUdajeROB | Služba realizuje zaslání avíza o nesprávném údaji v ZR ROB příslušnému editorovi údaje. |
iszrReklamujUdajeROS | Služba realizuje zaslání avíza o nesprávném údaji v ZR ROS příslušnému editorovi údaje. |
isuiReklamujPrvek | Služba, prostřednictvím které AIS reklamuje údaje v ISÚI. |
isknReklamujPrvek | Služba, prostřednictvím které AIS reklamuje údaje v ISKN. |
7. eGON - webové služby
Tato kapitola poskytuje informace k webovým službám vystaveným na eGON rozhraní.
7.1 Principy eGON webových služeb ISZR
Základním principem eGON služeb je nastavení společných norem, respektive standardů:
- použití WSDL 1.1,
- použití SOAP 1.1,
- použití WS-I Basic Profile 1.1,
- použití SOAP/HTTP binding (komunikační protokol mezi systémy je HTTP),
- použití soapAction pro všechny operace (nad požadavek WS-I Basic Profile 1.1),
- použití scénáře pro výměnu zpráv, MEP: In-Out,
- všechny QoS v separátním Policy dokumentu, na který se odkazuje z WSDL dokumentu,
- pro přenos binárních dat použití MTOM/XOP (nad požadavek WS-I Basic Profile 1.1),
- XSD schéma pro popis katalogů, jednotný katalog pro společné struktury,
- jednotná metodologie pro tvorbu názvů WSDL elementů,
- jednotný systém verzování webových služeb,
- zabezpečení webových služeb pomocí komunikační vrstvy (nepoužívá se WS-Security, XML-Signature a XML-Encryption, atd.).
Dalšími základními principy eGON služeb jsou:
- společný katalog datových typů,
- obecná struktura eGON služeb.
Společný katalog datových typů má následující vlastnosti:
- Ve společném katalogu datových typů jsou uvedeny pouze vybrané společné datové typy.
- Ve společném katalogu datových typů jsou uloženy typy pro řízení vykonávání eGON služeb.
- Ve společném katalogu datových typů jsou uloženy obecné datové typy společné pro více ZR nebo služeb.
- Správu společného katalogu datových typů zajišťuje ISZR.
- Ve společném katalogu datových typů pouze vznikají nové typy, nejsou upravovány existující typy.
- Požadavky na doplnění společného katalogu datových typů individuálně posuzuje z pohledu konzistence s existujícím stavem ISZR.
Pro strukturu zprávy eGON služby platí, že je logicky rozdělena na dvě části:
- systémová část (elementy ZadostInfo a AutorizaceInfo),
- aplikační část (element Dotaz).
Systémová část eGON služby:
- slouží pro přenos řídících informací mezi zúčastněnými systémy,
- systémová část je definována ve společném katalogu typů,
- v systémové části jsou uloženy informace:
o identifikace požadované služby,
o popis žádosti o službu (např. agenda, AIS, subjekt, uživatel, důvod),
o autorizační omezení,
o mapování AIFO,
o seznam adres a prvků.
Aplikační část eGON služby:
- slouží pro přenos aplikačně specifických dat,
- obsah aplikační části je pro většinu služeb pro ISZR transparentní,
- obsah aplikační části vzniká zřetězením jednotlivých odpovědí ze ZR.
7.1.1 Společný katalog datových typů
Systémy napojené na systém ZR pracují s některými datovými prvky, které jsou pro všechny systémy společné. Definice těchto prvků je proto umístěna ve společném katalogu vybraných datových typů s centrální správou, včetně následného verzování. Fyzické umístění je ve schématu RegTypy.xsd. Jmenným prostorem tohoto katalogu je urn:cz:isvs:reg:schemas:RegTypy:v1. Vychází z notace urn a respektuje zásady doporučené ISVS pro tvorbu jmenných prostorů.
Společný katalog vybraných datových typů je vytvořen hierarchicky. V nejnižší úrovni definuje základní datové typy, od nich se pak odvozují další datové typy. Technická dokumentace je tvořena XSD souborem RegTypy.xsd. Detaily jsou uvedeny v kapitole Společný katalog datových typů – RegTypy.xsd.
7.1.2 Struktura zprávy na eGON rozhraní
U každé poskytované eGON webové služby je zpráva rozdělena do dvou částí, systémové a aplikační. Systémová část je u všech eGON služeb stejná. Aplikační část je specifická pro jednotlivé volané služby. Technický popis struktury zprávy je uveden v technické části v kapitole Struktura zprávy na eGON rozhraní.
7.2 Popis rozhraní eGON služeb
Rozhraní eGON služeb ISZR je popsáno prostřednictvím sady dokumentů. Pro každou vystavenou webovou službu jsou k dispozici následující dokumenty:
- WSDL – technický popis rozhraní webové služby,
- sada XSD dokumentů – technický popis zprávy,
- dokumentace služby v „Katalogu eGON služeb”.
Dokumenty jsou dostupné na webu SZR na adrese xxxx://xxx.xxxxx.xx.
7.3 Členění eGON služeb
eGON služby je možné logicky členit do několika skupin:
- eGON služby – editační,
- eGON služby – dotazovací,
- eGON služby – reklamační,
- eGON služby – servisní.
7.3.1 eGON služby – editační
Editační eGON služby poskytují editační funkce, kdy editoři ZR prostřednictvím editačních AIS mohou modifikovat referenční údaje obsažené v jednotlivých ZR.
U editačních eGON služeb jsou na eGON rozhraní vystaveny služby tak, aby přímo poskytovaly přístup k definovaným skupinám atributů jednotlivých ZR na základě oprávnění. Tj. pokud je vystavena editační eGON služba a k této eGON službě je povolen přístup editačnímu AIS, má editační AIS obvykle právo pracovat se všemi atributy, které tato služba vystavuje. Tato obecnost může být v některých případech interně v systému ZR více omezena na základě dalších logických pravidel implementovaných jednotlivými ZR, v takovém případě jsou takové informace komunikovány přímo mezi konkrétním editorem a správcem konkrétního ZR.
Přístup k jednotlivým záznamům a atributům vystaveným na úrovni eGON služby může být dále ještě logicky ověřován přímo na úrovni interní logiky konkrétního ZR z pohledu členění editorů registru.
Při využití editačních služeb musí AIS implementovat procesy tak, aby odpovídaly požadavkům zákona. Jde například o implementaci zápisu rozhodnutí do RPP, na jehož základě došlo
ke změně referenčního údaje v ROB, ROS nebo RÚIAN (§ 52 zákona). V tom případě musí být editorem údajů proveden zápis změny jak do příslušného registru (ROX, ROX, RÚIAN), tak do příslušného rozhodnutí do RPP.
7.3.2 eGON služby – dotazovací
Dotazovací eGON služby poskytují funkce pro čtení údajů ze ZR. Dotazovací služby lze členit z několika hledisek.
Z hlediska poskytovaných údajů:
- dotazovací eGON služby referenční – služby umožňující čtení referenčních údajů z jednoho nebo kombinující údaje z více ZR,
- dotazovací eGON služby informační – pro přístup ke službám spolupracujících AIS – služby umožňující čtení informací z jiných AIS napojených na ISZR jako poskytovatele služby.
Z hlediska způsobu odpovědi:
- synchronní eGON dotazovací služby,
- asynchronní eGON dotazovací služby.
Podrobný popis z pohledu způsobu odpovědi je uveden v kapitole Režimy služeb.
Z hlediska dostupnosti služby:
- S1 – služby poskytující pouze individuální referenční údaje či logické odpovědi na základě jednoznačného identifikátoru prvku (AIFO, IČO, adresní bod),
- S2 – služby poskytující hromadné referenční údaje či logické odpovědi,
- S3 – služby poskytující výběrové informace nebo vyhledání podle souboru atributů,
- S4 – služby poskytující informační nebo provozní údaje.
Přístup ke službám, a tedy i údajům ZR je omezen na základě OVM, agendy a agendové role. Na této úrovni se omezuje přístup k jednotlivým atributům ZR. Definice přístupných údajů plyne z procesu registrace agendy a jejích agendových rolí.
Obvykle jako součást volání vybraných eGON služeb může AIS specifikovat referenční údaje, které chce na základě volání služby získat. Mohou však existovat zvláštní případy konkrétních eGON služeb, kdy je specifikace referenčních údajů nutná.
V případě, že u eGON služby není specifikace požadovaných referenčních údajů nutná, lze zvolit dva přístupy:
- AIS nemusí požadované referenční údaje specifikovat. V tom případě jsou vráceny AIS všechny referenční údaje, na které má AIS (podle kombinace oprávnění agenda / agendová role) právo. AIS by měl však respektovat to, že by měl žádat pouze o údaje, které jsou pro konkrétní proces nutné, což tento přístup nezaručuje, přestože, z pohledu agendy, práva na údaje existují.
- AIS uvede požadované referenční údaje. Pokud je mezi těmito údaji údaj, ke kterému nemá AIS (agenda / role) přístup, je poskytnutí služby odmítnuto.
7.3.3 eGON služby – reklamační
Reklamační eGON služby jsou služby, které se využívají při procesu zpochybnění referenčního údaje, reklamace chybějících subjektů nebo prvků a podobně. V rámci tohoto procesu může uživatel AIS provést reklamaci konkrétního údaje. Tato reklamace je prostřednictvím volání eGON služby doručena k editorovi příslušného referenčního údaje. Editor pak na základě této
skutečnosti označí reklamovaný referenční údaj jako nesprávný. Takovýto údaj vydávaný ze ZR má do zrušení tohoto označení pouze informativní povahu. Editor následně proces takto označeného údaje řeší.
Reklamační eGON služby slouží pro reklamaci údaje z pohledu uživatele AIS, na základě volání služby je reklamace doručena přímo příslušnému editorovi konkrétního údaje v ZR.
7.3.4 eGON služby – servisní
Servisní služby jsou služby, které samy o sobě neiniciují komunikaci se systémy ZR, nebo které poskytují doplňující informace neuložené v ZR nebo spolupracujících AIS.
7.3.4.1 Výstupní fronta pro výsledky asynchronních eGON služeb
Výstupní fronta ISZR je určena pro uložení odpovědí na asynchronní eGON služby. AIS k této frontě přistupuje a čte tyto odpovědi. Identifikace položek v této frontě a jejich vazba na volání služeb je realizována prostřednictvím identifikátoru přiděleného ISZR a vráceného v odpovědi na volání eGON služby.
7.3.4.1.1 Chování výstupní fronty
Z pohledu AIS jde o frontu s náhodným přístupem, tedy AIS může přistupovat k libovolné položce v této frontě bez ohledu na to, kdy byl výsledek do fronty zařazen. Z pohledu ISZR jde o frontu, ze které jsou po definované době položky odstraňovány podle data vzniku.
Po přijetí žádosti o službu a před umístěním odpovědi do výstupní fronty odpovídá ISZR, že žádost není dosud zpracována (výsledek je CHYBA / PROBIHA ZPRACOVANI).
Umísťování výsledků do fronty probíhá po zpracování odpovědi na asynchronní žádost v ISZR. Od tohoto okamžiku může AIS odpověď z fronty získat.
Odstraňování výsledků z fronty probíhá buď na základě explicitní žádosti AIS nebo po uplynutí doby zastarání výsledku ve frontě automatickým procesem ISZR.
Po odstranění výsledku z výstupní fronty nebo při nenalezení ID žádosti odpovídá ISZR, že výsledek neexistuje (výsledek je CHYBA / NENALEZENO).
7.3.4.1.2 Přístup k výstupní frontě z AIS
AIS přistupuje do výstupní fronty na základě toho, že očekává v této frontě výsledek. Pokud požadovaný výsledek není k dispozici, může AIS po nějaké době (řádově minuty) opakovat volání pro ověření dostupnosti daného výsledku.
7.3.4.1.3 Operace s výstupní frontou
Operace | Popis |
Čtení obsahu fronty | Pomocí této operace může AIS získat výpis obsahu fronty. V tomto výpisu je obsažen seznam ID všech výsledků (identifikátory požadavků ISZR), které jsou v daný okamžik připraveny ve výstupní frontě k vyzvednutí. Pro čtení obsahu fronty je vystavena na eGON rozhraní eGON služba iszrAsyncVypisFronty. |
Čtení výsledku z fronty | Pomocí této služby může AIS získat výsledek z výstupní fronty. Na základě ID (identifikátoru požadavku ISZR), předaného jako vstupní parametr služby, dostává AIS v odpovědi příslušný výsledek. Pro čtení konkrétního výsledku z fronty je na eGON rozhraní vystavena eGON služba iszrAsyncOdpovedZFronty. |
Mazání fronty | Pomocí této operace může AIS mazat obsah své fronty. AIS může specifikovat pomocí ID, které položky ve své frontě chce smazat. Pro mazání fronty je na eGON rozhraní vystavena eGON služba iszrAsyncSmazatFrontu. |
8. Dodatečné specifikace k eGON službám
8.1 E05 - robCtiPodleUdaju
8.1.1 Přehled minimálních kombinací povinných parametrů dotazu
Na vstupu vyžaduje služba použití minimální kombinace údajů, kterou lze doplnit o ostatní údaje osoby.
Přehled minimálních kombinací povinných parametrů dotazu:
Název parametru | RegTypy | I. | II. | III. | IV. | V. |
příjmení | Prijmeni | x | x | x | ||
jméno | Jmeno | x | x | x | ||
adresa pobytu | AdresaPobytu | x | ||||
datum narození | DatumNarozeni | x | ||||
datum úmrtí | DatumUmrti | x | ||||
číslo id dokladu | Doklad | x | ||||
druh dokladu | Doklad | x | ||||
datová schránka | DatovaSchranka | x |
Přehled možných doplňkových parametrů dotazu:
Název parametru | RegTypy | I. | II. | III. | IV. | V. |
místo narození | MistoNarozeni | x | x | x |
Název parametru | RegTypy | I. | II. | III. | IV. | V. |
místo úmrtí | MistoUmrti | x | x | x | ||
státní občanství | Obcanstvi | x | x | x | ||
datum nabytí právní moci rozhodnutí soudu o úmrtí | DatumPravniMociUmrti | x | x | x |
9. Technický popis
9.1 Obecné principy
9.1.1 Způsob popisu rozhraní
Systém ZR je systém postavený na obecně uznávaných standardech. Primárními standardy jsou v tomto systému standard XML a standardy webových služeb. Na jejich základě jsou pro technický popis ISZR použity následující typy dokumentů:
- XSD – schémata popisující jednotlivé datové typy, struktury a datové zprávy,
- WSDL – popis rozhraní webové služby.
Pro popis rozhraní tedy platí:
- Struktura popisu rozhraní je přesně definována.
- Pro každou webovou eGON službu je k dispozici samostatný WSDL soubor odkazující na související XSD dokumenty.
Struktura popisu rozhraní je následující:
Graf struktury | Složka | Popis |
_ws | kořen popisu rozhraní. Zde je umístěn katalog společných datových typů RegTypy.xsd a související dokumenty | |
eGON | kořen popisu eGON služeb | |
eGON/wsdl | wsdl eGON služeb | |
eGON/xsd | xsd eGON služeb | |
ISZR/xsd | xsd specifické pro ISZR | |
ORG/xsd | xsd specifické pro ORG | |
ROB/xsd | xsd specifické pro ROB | |
ROS/xsd | xsd specifické pro ROS | |
RPP/xsd | xsd specifické pro RPP | |
RÚIAN/xsd | xsd specifické pro RÚIAN | |
???/xsd | V budoucnu budou poskytovány služby AIS. Každý AIS bude mít vlastní složku pro jeho specifické typy. |
9.1.2 Verzování popisu rozhraní
Vzhledem k předpokládanému využití systému ZR lze očekávat průběžné rozšiřování rozsahu poskytovaných služeb. Toto rozšiřování poskytovaných služeb s sebou přináší potenciální možnost rozšiřování a změn popisu rozhraní.
V souvislosti s verzováním jsou stanovena následující pravidla, ze kterých je nutné při implementaci vycházet:
- V každém souboru (XSD i WSDL) je uvedena jeho verze.
- Namespace pro jednotlivá schémata zahrnují identifikaci verze.
- Změna, která může ovlivnit implementaci AIS je změnou majoritní.
- Změna, která nemůže ovlivnit implementaci AIS je změnou minoritní.
Z uvedeného tedy vyplývá:
- Majoritní změna znamená vytvoření nového popisu. Majoritní změna se nikdy nedotkne stávající implementace takovým způsobem, že by bylo třeba provádět změny do stávající implementace. To platí jak na úrovni popisu eGON služeb, tak na úrovni faktického volání eGON služeb. V případě majoritní změny vzniká:
o nová verze popisu (nové definice v nových souborech),
o nová verze služby (poskytována na nové adrese).
- Minoritní změna značí zpětnou kompatibilitu s existující funkčností. Tedy minoritní změna nikdy neovlivní volající AIS a AIS na tuto změnu nemusí žádným způsobem reagovat.
Příkladem majoritní změny je například:
- přidání povinného vstupního parametru do volání služby nebo přidání elementu do výstupu služby,
- přidání výstupního parametru. Příkladem minoritní změny je například:
- přidání nepovinného vstupního parametru do volání služby. Zabezpečení korektního chování je pak na straně logiky zpracování v systému ZR.
9.2 Společný katalog datových typů – RegTypy.xsd
Společný katalog datových typů obsahuje datové typy společné pro ZR, AIS a ISZR. Definice katalogu je v souboru RegTypy.xsd, který je spolu s ostatními soubory v samostatné části dokumentace.
Legenda tabulky:
- Název – název typu,
- Popis – popis typu.
Komplexní datové typy:
Název | Struktura | Popis |
AsyncDotazDataResponseType | Univerzální asynchronní odpověď na dotaz. |
AutorizaceType | Společná hlavička autorizačních omezení, AIS používá pro definici požadovaných údajů, RPP na základě role vrací povolený přístup. | |
BinarniDataTYpe | Binární data MTOM/XOP. | |
DatovaSchrankaType | Identifikátor datové schránky s příznakem typu datové schránky. | |
IdentifikatorRuianType | Typ referenčního údaje RÚIAN | |
KomprimovanaDataType | Komprimovaná data MTOM/XOP. | |
LokalniAifoType | Lokální identifikátor AIFO. Klíč typu integer. | |
MapaAifoType | Seznam všech AIFO převodníků. | |
OdpovedInfoType | Společná hlavička všech odpovědí (webových služeb). | |
PrevodAifoType | Převodník mezi lokálními a globálními AIFO. Slouží pro: převod v ORG, kontrolu existence v ROB a načtení dat z ROB. Atributy se obvykle nevyplňují, pokud to nespecifikuje popis konkrétní služby. | |
SeznamIcoType | Seznam všech identifikátorů osob, slouží pro kontrolu existence v ROS. | |
SeznamIdAdresType | Seznam všech identifikátorů adres. Slouží pro: kontrolu existence v RÚIAN a načtení dat z RÚIAN. | |
SeznamPrvkuType | Seznam identifikátorů RÚIAN neuvedených v SeznamIdAdres. Slouží pro kontrolu existence prvku v RÚIAN. | |
StatusType | Systémový status provedení požadované operace (volání webové služby). | |
SystemType | Původce nebo příjemce zprávy: ISZR, ZR, agendy, AIS. | |
ZadostInfoType | Společná hlavička všech žádostí nebo dotazů (webových služeb). |
Jednoduché datové typy:
Název | Popis |
AdresniLokalitaType | Identifikátor adresní jednotky (obec nebo pražský obvod) v RÚIAN. |
AgendaZadostIdType | UUID žádosti, který byl vygenerován v AIS. |
AgendovaRoleType | Identifikátor činnostní role RPP. Case sensitive. |
AifoType | Agendový identifikátor fyzické osoby. |
AisSeznamUdajuType | Seznam názvů datových položek, jež jsou uloženy v AIS. |
AidUdajType | Názvy datových položek, jež jsou uloženy v AIS. |
CasovaZnackaType | Agendový identifikátor fyzické osoby. |
DatovaSchrankaIdType | Identifikátor datové schránky. |
DuvodUcelType | Důvod a účel dotazu nebo žádosti (většinou jenom ROB). |
GlobalniAifoType | Agendový identifikátor fyzické osoby. UUID doplněné o potřebné atributy. |
IcoType | Identifikační číslo organizace. |
IcpType | Identifikační číslo provozovny. |
IdentifikatorType | Neprázdný řetězec - token jako základ dalších identifikátorů. |
IszrZadostIdType | UUID žádosti, který byl vygenerován v ISZR, zatím UUID. |
KladneCeleCisloType | Kladné celé číslo. |
KodAdresniMistoType | Identifikátor adresního místa v RÚIAN. |
KodAgendyType | Kód agendy. Case sensitive. |
KodAisType | Kód AIS. |
KodOvmType | Kód OVM. |
KodSluzbyType | Kód služby, obecný, v jednotlivých ZR je to výčtový typ. |
KodStatType | Kód státu dle číselníku zemí. |
MaximalniPocetType | Maximální počet záznamů, jež je možno poskytnout. |
MetodaKompreseType | Metoda komprese dat. |
NazevSluzbyType | Název služby, obecný, v jednotlivých ZR je to výčtový typ. |
NonEmptyLineStringType | Neprázdný řetězec (i víceřádkový) jako základ dat, kde není akceptován prázdný údaj. |
NonEmptyNormStringType | Neprázdný řetězec jako základ dat, kde není akceptován prázdný údaj a nejsou akceptovány prázdné znaky na začátku a konci. |
NonEmptyStringType | Neprázdný řetězec jako základ dat, kde není akceptován prázdný údaj. |
PrevodAifoStatusType | Chyby převodu AIFO v ORG při překladu v ORG. |
RegOdpovedIdType | UUID odpovědi (zejména pro asynchronní služby), který byl vygenerován v ZR. |
RobSeznamUdajuType | Seznam názvů datových položek, jež jsou uloženy v ROB. |
RobUdajType | Názvy datových položek, jež jsou uloženy v ROB. |
RosSeznamUdajuType | Seznam názvů datových položek, jež jsou uloženy v ROS. |
RosUdajType | Názvy datových položek, jež jsou uloženy v ROS. |
RppSeznamUdajuAgendyType | Seznam názvů datových položek agendy, jež jsou uloženy v RPP. |
RppSeznamUdajuPravaType | Seznam názvů datových položek údajů, jež jsou uloženy v RPP. |
RppUdajAgendyType | Názvy datových položek agendy, jež jsou uloženy v RPP. |
RppUdajPravaType | Názvy datových položek údajů, jež jsou uloženy v RPP. |
StavOvereniPrvkuRuianType | Stav adresního místa v RÚIAN pro ověření / načtení z RÚIAN. |
StavType | Stav indikující správnost nebo nesprávnost údaje. |
SubjektType | Označení subjektu, pro jehož účely se údaje využívají (zpravidla OVM). |
TypAdresniLokalityType | Typ adresní lokality (obec nebo pražský obvod). |
TypDatoveSchrankyType | Typ datové schránky. |
TypPrvkuRuianType | Typy referenčního údaje RÚIAN. |
UuidType | UUID - 36 znaku, AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE - základ dalších identifikátorů. |
UzivatelType | Uživatelské jméno fyzické osoby vykonávající agendu. |
VerzeType | Verze XML dokumentu (SOAP zprávy, tedy žádosti nebo dotazu a odpovědi). |
VysledekKodType | Kód výsledku, výčtový typ indikující v zásadě OK a CHYBA. |
VysledekPopisType | Aplikační status provedení požadované operace - upřesnění. |
VysledekSubKodType | Detailní kód výsledku, výčtový typ nebo odkaz na popis. |
9.2.1 Typ AifoType
AIFO v AIS je 17 bytový identifikátor. Pro účely přenosu prostřednictvím WS se kóduje prostřednictvím algoritmu Base64. Pro účely lokálního uchování v AIS je možné principiálně použít jak zakódovanou, tak i nezakódovanou variantu. Poslední 1 byte v nezakódované podobě slouží pro ověření integrity pomocí CRC8.
9.2.2 Typ MapaAifoType
9.2.2.1 Skupina
Kombinace agenda a AIS určuje skupinu, ze které se této kombinaci přiděluje a čte AIFO. AIS se na vstupu eGON služby identifikuje právě touto kombinací, skupina se odvozuje interně v systému ZR. Dále má každý ZR přidělenu samostatnou skupinu.
9.2.2.2 Obyvatel
Obyvatel má ve skupině přiděleno právě jedno AIFO. Nikde (kromě ORG) neexistuje informace, která umožňuje spárovat AIFO z různých skupin. Procesy ISZR provádí překlad AIFO na vstupu/výstupu do/z ISZR podle příjemce (ZR nebo AIS).
Příklad: Na vstupu eGON služby pro čtení z ROB je AIFOAIS. ISZR provede pomocí ORG překlad AIFOAIS na AIFOROB a následně může být zavolána služba ROB. Pokud je na výstupu služby ROB AIFOROB, musí ISZR provést pomocí ORG překlad na AIFOAIS, které může vrátit na výstup. AIS tedy pracuje vždy se „svým“ AIFO.
9.2.2.3 Typ MapaAifoType
Datový typ MapaAifoType umožňuje transparentní překlad AIFO při zachování maximální výkonnosti eGON služeb. Datový typ MapaAifoType je založen na seznamu položek typu PrevodAifoType. PrevodAifoType pak obsahuje:
- Globální AIFO – AIFO, které je uloženo v AIS, ROB, ROS a podobně.
- Lokální AIFO – odkaz používaný při předávání zpráv mezi systémy.
Každá zpráva, která pracuje na vstupu s AIFO, má na vstupu strukturovaná data typu MapaAifoType. V části aplikačních dat SOAP payloadu je AIFO reprezentováno jednoznačným klíčem (typu xs:integer), který nazýváme LokalniAifo. MapaAifoType tvoří překladovou tabulku, kde jsou k těmto lokálním identifikátorům přiřazeny skutečné AIFO.
Struktura MapaAifoType obsahuje:
- PrevodAifo (seznam typů PrevodAifoType),
- nacistData (atribut řídící čtení dat z ROB pro služby primárně založené na ROB).
Přičemž PrevodAifoType obsahuje:
- LokalniAifo (typ LokalniAifoType) – technický identifikátor AIFO v datové části zprávy.
ORG tuto hodnotu ve zprávě zachovává, interně ji nijak nepoužívá.
- GlobalniAifo (typ AifoType) – AIFO, jak ho registruje ORG a AIS / ZR. Při překladu v ORG je AIFO zaměněno.
Tento princip lze demonstrovat na příkladu zápisu osoby do ROS (pro čitelnost zjednodušeno):
<MapaAifo>
<PrevodAifo>
<LokalniAifo>1</LokalniAifo>
<GlobalniAifo>1234567890ABCDEF1234567</GlobalniAifo>
</PrevodAifo>
</MapaAifo>
..
<ROSOsoba>
<ICO>11111122</ICO>
<AIFO>1</AIFO>
<Nazev>Jan Novák, s.r.o</Nazev>
...
</ROSOsoba>
AIS chce provést změnu fyzické podnikající osoby v ROS – chce provést její navázání na osobu v ROB a upravit její název. Bude tedy volat službu rosZmenOsobu. Musí specifikovat IČO, a dále údaje pro změnu, tedy AIFO a Název.
AIFO osoby v AIS je 1234567890ABCDEF1234567. AIS musí vytvořit strukturu MapaAifo, kde uvede AIFO a nadefinuje lokální AIFO, zde je lokální AIFO = 1. V aplikační části zprávy uvede odkaz na osobu pomocí lokálního identifikátoru AIFO.
Je-li výstupem služby AIFO, je na výstupu přítomná i struktura MapaAifo, která je vyplněna stejným způsobem.
9.2.3 Typ SeznamIdAdresType
Základní koncept referenčních odkazů na RÚIAN spočívá v tom, že všechny AIS a ZR kromě RÚIAN pracují pouze s identifikátory adresních míst a identifikátory adresních lokalit (obec nebo pražský obvod). Z toho důvodu, pokud je na vstupu/výstupu do/z ISZR identifikátor RÚIAN, vzniká potřeba ověřit a/nebo načíst příslušná data z tohoto ZR. Pro tento účel slouží struktura SeznamIdAdresType, kterou každá zpráva, pokud je to z její povahy třeba, obsahuje.
Z uvedeného vyplývá, že pokud zpráva strukturu obsahuje, volá se příslušná služba RÚIAN. Pokud strukturu neobsahuje, RÚIAN není nutné volat. AIS musí zajistit přítomnost této struktury, pokud se na vstupu v datové části pracuje s adresou nebo adresní lokalitou RÚIAN.
Struktura SeznamIdAdresType obsahuje informace pro čtení a kontrolu dat z RÚIAN:
- AdresniMisto (seznam typů AdresniMistoType)
- AdresniLokalita (seznam typů AdresniLokalitaType)
Pro obě struktury, pokud obsahují identifikátory adres, se tyto adresy načítají z RÚIAN, což je standardní operace. Pokud se při načítání zjistí, že adresa neexistuje, vrací se chyba „ADRESA NEEXISTUJE“.
Je-li výstupem služby adresa, je na výstupu přítomná i struktura SeznamIdAdres, která je vyplněna stejným způsobem.
9.3 Struktura zprávy na eGON rozhraní
Pro každou eGON službu je definována struktura vstupní (In, Request) a výstupní (Out, Response zprávy). Protože je komunikace realizována prostřednictvím webových služeb, jsou všechny zprávy založeny na SOAP protokolu.
SOAP obálka definuje SOAP hlavičku a SOAP tělo. SOAP hlavička je v komunikaci se systémem ZR vyhrazena pro speciální účely, v aktuální verzi pro implementaci aktivního režimu odpovědi na asynchronní eGON službu – viz kapitola Aktivní režim odpovědi a související Asynchronní služba s aktivním režimem odpovědi. SOAP tělo pak slouží pro samotný přenos informací.
Na úrovni těla SOAP bylo provedeno další sjednocení vnitřních struktur, a to tak, že SOAP tělo se vždy skládá ze:
- systémové části,
- aplikační části.
Systémová část obsahuje řídící data, stavová data, data pro omezení přístupu a data pro podporu procesu interního zpracování. Aplikační část pak obsahuje samotná aplikační data.
Systémová část je ve zprávě obsažena vždy. Aplikační část zprávy nemusí ve zprávě za jistých podmínek existovat. Jde především o systémové stavy a vybrané eGON služby, kdy je možné odpověď poskytnout přímo v systémové části zprávy.
9.3.1 Systémová část dotazu (request AIS -> ISZR)
Systémová část dotazu slouží pro specifikaci systémových záležitostí ze strany AIS směrem k ISZR. Struktura systémové části hlavičky je znázorněna na následujícím obrázku:
ZadostInfo | Struktura pro identifikaci žádosti | |
CasZadosti | Datum a čas žádosti z AIS | |
Agenda | Kód agendy – přidělený agendě | |
Kód přidělený agendě v rámci registrace nebo, pro testovací prostředí, dočasný kód vygenerovaný na SZR při přidělení certifikátu. Hodnota je case sensitive. | ||
AgendovaRole | Kód agendové role – kód agendové role přidělený činnosti, ve které vystupuje uživatel inicializující volání služby. | |
Kód přidělený agendové činnosti v rámci registrace nebo, pro testovací prostředí, dočasný kód vygenerovaný na SZR při přidělení certifikátu. Hodnota je case sensitive. | ||
Ovm | Identifikace OVM, který provozuje AIS volající službu. | |
Identifikátorem OVM je IČO. | ||
Ais | Identifikace AIS | |
Identifikátor AIS je přidělován SZR v rámci generování certifikátu. Pokud je to možné, přidělí SZR tento identifikátor podle identifikace AIS v IS o ISVS. Jestliže se však na AIS nevztahuje zákon o informačních systémech veřejné správy (viz § 3 odst. 3 tohoto zákona), pak AIS nepodléhá registraci v IS o ISVS a SZR mu přidělí vlastní identifikátor. | ||
Subjekt | Označení subjektu, pro jehož účely se údaje využívají (zpravidla OVM). | |
Identifikace je povinná u služeb, které čtou údaje z ROB. | ||
Uzivatel | Identifikace fyzické osoby vykonávající agendu. | |
Identifikace je povinná u služeb, jejichž součástí je volání ROB. U některých služeb závisí to, zda proběhne čtení z ROB, na kontextu. | ||
AIS musí předat takovou informaci, aby byl schopen při auditu identifikovat uživatele, který do systému ZR přistupoval, tj. identifikace uživatele v rámci použitého systému Identity Managementu. Například, pokud AIS autentizuje uživatele v JIP, může zde být uvedena identifikace uživatele v JIP. | ||
DuvodUcel | Důvod a účel dotazu nebo žádosti (většinou jenom ROB). | |
Naplnění je povinné v případě, že bude provedeno čtení ROB. | ||
AgendaZadostId | Identifikace žádosti v agendě. Používá se |
především pro detekci duplicit v ZR. | ||||
Jedinečný identifikátor žádosti v rámci AIS. | ||||
PredchoziZados | Identifikace předchozí žádosti v případě, že | |||
tId | AIS požaduje serializaci požadavků. | |||
Nepovinný identifikátor (AgendaZadostId) | ||||
použitý v minulosti při volání eGON služby. | ||||
IszrZadostId | Rezervováno - identifikace žádosti v ISZR. | |||
PrioritaAis | Priorita, kterou AIS požaduje při vykonání služby. | |||
AutorizaceInfo | Struktura řídící výdej údajů a zpracování | |||
žádosti v systému ZR. Jde o řetězec | ||||
mezerou oddělených identifikátorů, jejich | ||||
popis je uveden v samostatné kapitole. | ||||
MaximalniPocet | Pro definované služby umožňuje omezit | |||
Zaznamu | počet hodnot na výstupu. | |||
SeznamUdaju | V této struktuře může (nebo musí) AIS | |||
u definovaných služeb uvést, které položky | ||||
ZR v odpovědi požaduje a jak má být | ||||
zpracování v ISZR realizováno (pokud to | ||||
služba umožňuje, podrobněji viz dále). | ||||
MapaAifo | Struktura pro převod AIFO | |||
PrevodAifo | Struktura pro převod AIFO, používá nedynamizovaná forma. | pokud | se | |
LokalniAifo | Lokální identifikátor AIFO | |||
GlobalniAifo | AIFO | |||
SeznamIco | Seznam IČO pro ověření | |||
SeznamPrvku | Seznam prvků RÚIAN pro ověření | |||
KodPrvku | Kód prvku v RÚIAN | |||
TypPrvku | Typ prvku v RÚIAN | |||
SeznamIdAdres | Struktura pro seznam adres | |||
AdresniMisto | Seznam adresních míst | |||
AdresniLokalita | Seznam adresních lokalit |
9.3.1.1 Element AutorizaceInfo
V tomto elementu AIS specifikuje požadavky na chování služby (workflow zpracování) a její výstup (údaje požadované ze ZR). Účel tohoto elementu je tedy, především u publikačních služeb, specifikace požadovaných referenčních údajů ve výstupu a současně specifikace dotahování hodnot referenčních odkazů, pokud služba takové dotahování umožňuje. V případě vyplnění může ovlivňovat chování i jiných než publikačních služeb.
Technicky je obsahem elementu AutorizaceInfo textový řetězec, ve kterém jsou jednotlivé hodnoty odděleny mezerou.
Povolené hodnoty v seznamu AutorizaceInfo jsou logicky rozděleny do kategorií:
- hodnoty, které řídí workflow zpracování služby
- hodnoty, které specifikují údaje požadované ze ZR Seznam definovaných hodnot je v níže uvedených tabulkách.
V případě referenčních odkazů a údajů vydávaných na základě referenčního odkazu z primárního ZR závisí obsah výstupu z odkazovaného ZR na implementaci konkrétní služby (například, zda je obsah výstupu z odkazovaného ZR pevný, nebo zda je jeho obsah závislý na obsahu elementu AutorizaceInfo).
Hodnoty řídící workflow zpracování
Služba vracející data ZR je obvykle postavena tak, že čte data z jednoho ZR a k ní mohou být načteny informace dle referenčních odkazů na jiné ZR. Hodnoty řídící workflow definují, jak se chovat k těmto referenčním odkazům, což nemá vliv na primární službu ZR.
Hodnoty v AutorizaceInfo se tedy berou v úvahu, pokud je to u dané služby relevantní (tj. pokud je služba definována tak, že vrací údaje doplněné o data z referenčních odkazů na jiné ZR). Pokud jsou hodnoty uvedeny a pro službu nejsou relevantní, ignorují se.
Pokud je pro jeden ZR uvedeno více řídících hodnot, nebo není uvedena žádná, bere se v úvahu ta, která má nejvyšší prioritu.
Konstanta | Priorita | ZR | Výchozí | Popis chování služby v ISZR |
ROSNecti | 1 | ROS | X | Služba nebude volat služby ROS pro načtení údajů dle referenční vazby na ROS. |
ROSOver | 2 | ROS | Služba bude volat službu ROS - rosOverIco, která provede ověření existence IČO v ROS, pokud je to relevantní. | |
ROSCti | 3 | ROS | Služba načte data referenční vazby na ROS. Služba bude volat službu ROS - rosCtiSeznamIco, která provede doplnění dat pro jednotlivé odkazy (IČO) z ROS. | |
ROBNecti | 1 | ROB | X | Služba nebude volat služby ROB pro načtení údajů dle referenční vazby na ROB. |
ROBOver | 2 | ROB | Služba bude volat službu ROB - robCtiHromadneAIFO s nastavením pouze pro ověření existence AIFO v ROB. | |
ROBCti | 3 | ROB | Služba načte data referenční vazby na ROB. Služba bude volat službu ROB - robCtiHromadneAIFO, která provede doplnění dat pro jednotlivé odkazy (AIFO) z ROB. | |
RUIANNecti | 1 | RÚIAN | X | Služba nebude volat služby RÚIAN pro načtení údajů dle referenční vazby na RÚIAN. |
RUIANOver | 2 | RÚIAN | Služba bude volat službu RÚIAN – ruianCtiPrvek, nebo ruianCtiProROB, která provede ověření existence odkazu v RÚIAN, pokud je to relevantní. | |
RUIANCti | 3 | RÚIAN | Služba načte data referenční vazby na RÚIAN. Služba bude volat službu RÚIAN – ruianCtiPrvek, nebo ruainCtiProROB, která provede doplnění dat pro jednotlivé odkazy (IdPrvku, IdAdresy) z RÚIAN. |
Příklad: AIS chce v rámci volání služby ROS - rosCtiIco doplnit údaje z ROB a kontrolovat existenci v RÚIAN. AIS tedy naplní do AutorizaceInfo konstanty ROBCti a RUIANOver.
Hodnoty definující údaje požadované ze ZR
V případě nevyplnění tohoto elementu v kategorii požadovaných údajů probíhá obvykle základní zpracování tak, že:
- Na výstup jsou předány všechny údaje ZR definované v matici oprávnění dle agendy a agendové role.
- Je provedeno standardní zpracování služby (obvykle to znamená vrácení přístupných údajů ze ZR daného referenčním odkazem).
- Mohou existovat služby, u kterých je explicitní naplnění tohoto elementu nutné, protože nelze použít kompletní oprávnění definovaná v RPP.
V případě explicitní specifikace hodnoty v elementu AutorizaceInfo při volání AIS je seznam uvedených referenčních údajů kontrolován oproti oprávnění agendy a agendové role. Pokud AIS požaduje pro zadanou agendu a agendovou roli nepovolené atributy, je služba ukončena s chybou.
Konstanta eGON rozhraní | Hodnota ZR | ZR |
AdresaPobytu | AdresaPobytu | ROB |
Aifo | Aifo | ROB |
Bok | Bok | ROB |
DatovaSchrankaROB | DatovaSchranka | ROB |
DatumNarozeni | DatumNarozeni | ROB |
DatumUmrti | DatumUmrti | ROB |
DatumPravniMociUmrti | DatumPravniMociUmrti | ROB |
Doklad | Doklad | ROB |
DorucovaciAdresa | DorucovaciAdresa | ROB |
Editor | Editor | ROB |
Jmeno | Jmeno | ROB |
MistoNarozeni | MistoNarozeni | ROB |
MistoUmrti | MistoUmrti | ROB |
Obcanstvi | Obcanstvi | ROB |
VyuzitiPoskytnuti | VyuzitiPoskytnuti | ROB |
Prijmeni | Prijmeni | ROB |
TypOsoby | TypOsoby | ROB |
Zmeny | Zmeny | ROB |
Znepristupneni | Znepristupneni | ROB |
PoskytnutiVyuziti | PoskytnutiVyuziti | ROB |
PoskytnutiPoskytnuti | PoskytnutiPoskytnuti | ROB |
PotlaceniZnepristupneni | PotlaceniZnepristupneni | ROB |
ZnepristupniLog | ZnepristupniLog | ROB |
ZmenyProDS | ZmenyProDS | ROB |
DatovaSchrankaROS | DatovaSchranka | ROS |
ObchodniNazev | ObchodniNazev | ROS |
PravniForma | PravniForma | ROS |
PravniStav | PravniStav | ROS |
FyzickaOsoba | FyzickaOsoba | ROS |
AdresaSidla | AdresaSidla | ROS |
Provozovny | Provozovny | ROS |
StatutarniOrgany | StatutarniOrgany | ROS |
DatumVznikuOpravneni | DatumVznikuOpravneni | ROS |
DatumZanikuOpravneni | DatumZanikuOpravneni | ROS |
Ico | Ico | ROS |
Ovm | Ovm | RPP |
PravniPredpis | PravniPredpis | RPP |
IdentifikatorOsob | IdentifikatorOsob | RPP |
IdentifikatorObjektu | IdentifikatorObjektu | RPP |
Agenda | Agenda | RPP |
VymezeniPravaPovinnosti | VymezeniPravaPovinnosti | RPP |
DatumNabyti | DatumNabyti | RPP |
OpravneneRole | OpravneneRole | RPP |
NazevAgendy | NazevAgendy | RPP |
KodAgendy | KodAgendy | RPP |
PravniPredpisAgendy | PravniPredpisAgendy | RPP |
Cinnosti | Cinnosti | RPP |
OhlasenaOvm | OhlasenaOvm | RPP |
Ohlasovatel | Ohlasovatel | RPP |
RegistrovanaOvm | RegistrovanaOvm | RPP |
VycetZrAis | VycetZrAis | RPP |
VycetRoli | VycetRoli | RPP |
RozsahOpravneniZr | RozsahOpravneniZr | RPP |
RozsahOpravneniAis | RozsahOpravneniAis | RPP |
PravniPredpisyOpravneni | PravniPredpisyOpravneni | RPP |
9.3.2 Systémová část odpovědi (response ISZR -> AIS)
Systémová část odpovědi slouží pro přenos stavu výsledku na systémové úrovni. Systémovou úrovní se rozumí informace, které obsahují řídící informace pro zpracování odpovědi v AIS. Struktura systémové části odpovědi je znázorněna na následujícím obrázku:
CasOdpovedi | Čas vygenerování odpovědi | |
Status | Výsledek požadavku | |
VysledekKod | Kód výsledku (OK / CHYBA / VAROVANI) | |
VysledekDetail | Podrobnosti výsledku | |
VysledekSubKod | Detailní kód výsledku. Může: - přímo definovat příčinu – definovaný výčet - obsahovat informaci, že detailní kód je uveden v poli VysledekPopis - obsahovat informaci, že detaily jsou uvedeny v aplikační části zprávy | |
VysledekPopis | Detailní popis výsledku nebo detailní kód nespecifikovaný ve VysledekSubKodType | |
Puvodce | Systém, ve kterém událost nastala. Může jít o jednu z hodnot: - Agenda - Ais - Registr | |
Prijemce | Systém, pro který je událost určena. Může jít o jednu z hodnot: - Agenda - Ais - Registr | |
AgendaZadostId | Id žádosti vygenerované při volání služby agendou. | |
IszrZadostId | Id přiřazené volání služby v ISZR. Při volání asynchronní služby musí AIS toto Id použít pro vyzvednutí odpovědi na službu z fronty odpovědí. | |
RegOdpovedId | Id přiřazené volání služby v primárním ZR. | |
MapaAifo | Struktura MapaAifo obsahující převod mezi lokálním id a AIFO. | |
SeznamIco | Seznam IČO | |
SeznamIdAdres | Seznam ID adresních míst a adresních lokalit | |
SeznamPrvku | Seznam prvků RÚIAN |
9.4 Chybové stavy
Volání eGON služeb může být ukončeno chybou. Chyby mohou být následujícího charakteru:
- http chyby,
- chyby SoapFault,
- systémové chyby,
- aplikační chyby.
9.4.1 Http chyby
Http chyby se mohou vyskytnout při chybném volání služeb ISZR v následujících případech:
- chyba ověření, přístup nepovolen – 401:
o součástí volání není klientský certifikát AIS, nebo tento certifikát není platný,
- chyba adresy – 404:
o chybné URL.
9.4.2 Chyby SoapFault
Chyby typu SoapFault jsou vráceny v případě chybné formální validace obsahu zprávy. V detailu chyby jsou specifikovány podrobnosti.
9.4.3 Systémové chyby
Systémové chyby vyplývají z interního zpracování požadavku v ISZR. Informace o systémové chybě je vrácena v těle odpovědi na eGON službu v její systémové části v elementu Status (viz Systémová část odpovědi (response ISZR -> AIS)).
9.4.4 Aplikační chyby
Aplikační chyby plynou z interního zpracování požadavku v systému, který službu poskytuje. Aplikační chybu lze detekovat v hlavičce odpovědi na eGON službu v elementu Status (viz Systémová část odpovědi (response ISZR -> AIS)). Detailní informace k aplikační chybě lze pak nalézt buď přímo v hlavičce odpovědi, nebo v aplikační části odpovědi. Informace o umístění aplikační chyby a možné aplikační chyby jsou definovány přímo u konkrétní služby.
9.4.5 Definované chybové stavy
Následující stavy se mohou vyskytnout v elementu VysledekKod:
Hodnota | Popis |
OK | Služba byla zpracována v pořádku. |
VAROVANI | V průběhu zpracování se vyskytly problémové stavy, které ale nebrání zpracování služby. Detailní informace jsou specifikovány v elementu VysledekDetail. Příkladem může být služba robCtiHromadneAifo. AIS specifikuje seznam 4 AIFO, z nich 2 jsou v ZR nalezena, 2 nalezena nejsou. Potom je výsledkem stav VAROVANI. |
CHYBA | V průběhu zpracování se vyskytla chyba, služba nebyla zpracována. Detailní informace jsou specifikovány v elementu VysledekDetail. |
Následující stavy se mohou vyskytnout v elementu VysledekSubKod:
Hodnota | Popis |
PREKROCEN CAS | Je překročen čas pro zpracování (podle konfigurace nebo autorizačního omezení). |
PREKROCEN SEZNAM | Je překročena velikost výstupního seznamu (podle konfigurace nebo autorizačního omezení). |
NENI OPRAVNENI EGON | Není oprávnění k požadované eGON službě. |
NENI OPRAVNENI | Není oprávnění k požadované službě, rozhodnutí ZR. |
AIFO NEEXISTUJE | AIFO není k dispozici (neexistuje, nebo byl odepřen přístup). |
AIFO ZRUSENO | AIFO není k dispozici (je zrušeno). |
ZIFO ZRUSENO | ZIFO není k dispozici (je zrušeno). |
ADRESA NEEXISTUJE | Adresa (adresní místo nebo lokalita) není k dispozici. |
ADRESA SMAZANA | Adresa (adresní místo nebo lokalita) je smazána. |
JENOM ASYNC | Služba je implementována jenom / provozována dočasně asynchronně. |
MIMO PORADI | Chyba serializace zpracování (chybí / chybové předešlé zpracování). |
NEPLATNY CAS | Čas dotazu je mimo povolenou toleranci (podle konfigurace), nebo mimo rozsah vstupní fronty. |
STARSI VERZE | Verze (SOAP) dotazu/žádosti se liší minoritně od současné verze služeb. |
NEPLATNA VERZE | Verze (SOAP) dotazu/žádosti se liší majoritně od současné verze služeb. |
DUPLICITNI ZADOST | Identifikátor žádosti (AIS nebo ISZR) byl přiřazen žádosti v minulosti. |
NENI IMPLEMENTOVANO | Služba není implementována. |
NENI K DISPOZICI | Služba není dočasně k dispozici. |
NENALEZENO | Při dotazu do výstupní fronty asynchronních požadavků nebyl výsledek nalezen. |
PROBIHA ZPRACOVANI | Při dotazu do výstupní fronty asynchronních požadavků dosud nebyl výsledek zpracován. |
NEVALIDNI DATA | Data nejsou validní podle XSD dokumentů. |
NEVALIDNI ZADOST | Kód služby neodpovídá XML struktuře žádosti. |
APLIKACNI CHYBA | V průběhu aplikačního zpracování se vyskytla chyba. Chyba je blíže specifikována v aplikační části webové zprávy. |
SPECIFIKACE V POPISU | Chyba je blíže specifikována v popisu. |
CHYBA VOLANI REGISTRU | Nebylo možné zavolat požadovanou službu ZR. |
CHYBA VOLANI AIS | Nebylo možné zavolat požadovanou službu spolupracujícího AIS. |
9.4.6 Chybové stavy serializace
V procesu serializace (viz popis v kapitole Serializace požadavků) může dojít k chybám. V tom případě jsou chyby serializace vráceny následujícím způsobem – struktura Status odpovědi:
VysledekKod=CHYBA VysledekDetail[0] =
{
VysledekSubKod=MIMO PORADI
}
VysledekDetail[1] =
{
VysledekSubKod=SPECIFIKACE V POPISU
VysledekPopis=NELZE SERAILIZOVAT|DUPLICITA SERIALIZACE|CHYBI PREDCHUDCE
}
9.4.7 Chyby nepovolení přístupu
Pro přístup na eGON rozhraní musí být AIS patřičným způsobem zaregistrován. V případě, kdy AIS při přístupu použije nepovolené kombinace, je výstupem volání služby chyba. Ve struktuře Status odpovědi je:
VysledekKod=CHYBA VysledekDetail[0] =
{
VysledekSubKod=NENI OPRAVNENI EGON
}
VysledekDetail[1] =
{
VysledekSubKod=SPECIFIKACE V POPISU VysledekPopis=
SEC_000 : Nespecifikovaná chyba ({0}) SEC_001 : Agenda není registrována SEC_002 : Agenda není platná
SEC_003 : Agendová role není registrována SEC_004 : Agendová role není platná SEC_005 : Certifikát není zaregistrovaný SEC_006 : Certifikát je registrován pro jiný AIS SEC_007 : Certifikát není platný
SEC_008 : OVM není registrován SEC_009 : OVM není platný SEC_010 : AIS není zaregistrovaný SEC_011 : AIS není platný
SEC_012 : Vazba pro činnost (OVM x AGENDA_ROLES) není registrována SEC_013 : Vazba služby na činnost není registrována
SEC_014 : Vazba pro činnost (OVM x AGENDA_ROLES) není platná SEC_015 : Vazba AGENDA a AGENDA_ROLE není registrována SEC_020 : Služba není registrována
SEC_021 : Vazba služby na činnost je registrována pro jinou verzi služby SEC_022 : AIS je na blacklistu
SEC_023 : Vazba AGENDA a AGENDA_ROLE není platná SEC_024 : Vazba OVM a činnosti není platná
SEC_025 : Vazba agendy, role a činnosti není platná SEC_026 : OVM není registrován pro daný AIS SEC_027 : Agenda není registrována pro daný AIS
SEC_028 : Agendová role není registrována pro daný AIS SEC_029 : Kombinace AIS a AGENDA nemá bezpečnostní profil
SEC_030 : Služba není zaregistrovaná v bezpečnostním profilu pro AIS SEC_031 : Bezpečnostní profil není platný
SEC_032 : Služba není platná SEC_033 : Služba je pozastavena }
Poznámka: V produkčním prostředí může být detailní popis chyby z důvodu bezpečnosti systému vypnut.
9.5 Asynchronní služba s aktivním režimem odpovědi
Pro definované případy je k dispozici varianta, kdy je AIS schopen získat odpověď na asynchronní službu v aktivním režimu, tedy odpověď není nutné vyzvedávat procesem v AIS, ale ISZR zajistí poslání odpovědi na AIS prostřednictvím webové služby vystavené na straně AIS.
Za tímto účelem musí AIS splnit definované podmínky – viz kapitola Podmínky pro aktivní doručení odpovědi do AIS. Základní požadavky na technickou implementaci webových služeb pro odeslání a příjem jsou uvedeny v následujících kapitolách.
9.5.1 Žádost o asynchronní eGON službu s aktivním režimem odpovědi
Pokud chce AIS obdržet odpověď v aktivním režimu, musí při volání eGON služby definovat cíl pro odpověď. Tato definice je založena na standardu WS-Addressing a modelu Message Information Headers.
Je třeba zmínit, že definice cíle pro odpověď se týká cíle pro doručení výsledné odpovědi po zpracování v systému ZR, nikoliv odpovědi ohledně přijetí služby ke zpracování v ISZR. Volání každé eGON služby je založeno na vzoru dotaz-odpověď, tedy informace o přijetí ke zpracování je součástí synchronní odpovědi na dotaz.
V rámci definice cíle musí být nastaveny následující vlastnosti:
Vlastnost | Element | Popis |
[destination] | wsa:To | adresa předpokládaného příjemce zprávy (tj. adresa ISZR) |
[message id] | wsa:MessageID | identifikace zprávy v AIS |
[reply endpoint] | wsa:ReplyTo | cílový bod pro doručení odpovědi na eGON službu |
[action] | wsa:Action | identifikátor sémantiky zprávy (urn:cz:isvs:iszr:services:IszrAsyncOdpovedZFronty:v1/ IszrAsyncOdpovedZFrontyResponse) |
9.5.2 Implementace webové služby pro doručení odpovědi
Webová služba pro příjem odpovědi musí být založena na společných datových typech a typech definovaných pro výstupní frontu ISZR. Na URL definovaném ze strany AIS musí být vystavena webová služba schopná přijmout zprávu definovanou jako:
tns:IszrAsyncOdpovedZFrontyResponse
kde
- xmlns:tns="urn:cz:isvs:iszr:services:IszrAsyncOdpovedZFronty:v1"
- namespace="urn:cz:isvs:iszr:schemas:IszrAsyncOdpovedZFronty:v1" schemaLocation="../xsd/IszrAsyncOdpovedZFronty.xsd"
Pro účely implementace na straně AIS jsou součástí popisu datových typů popisujících požadovanou službu na straně AIS:
- /egon/wsdl/IszrAsyncPushOdpovedZFronty.wsdl
- /egon/xsd/ IszrAsyncPushOdpovedZFronty.xsd
10. Závěr
V tomto dokumentu byly popsány principy, požadavky a datové struktury nutné pro komunikaci s ISZR. Nedílnou součástí celkové dokumentace je technická definice rozhraní prostřednictvím WSDL a XSD souborů, na které musí být implementace komunikace postavena.
A. Příloha – příklady volání služeb
V této kapitole jsou uvedeny příklady volání a odpovědí eGON služeb.
Obecná skladba XML volání a odpovědi služby
Požadavek
Požadavek se obecně skládá ze systémové hlavičky a aplikačních dat. Tyto informace jsou zabaleny v SOAP obálce definované standardem webových služeb.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Header> <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRosCtiIco</Action> </s:Header> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> | SOAP obálka |
<RosCtiIco xmlns="urn:cz:isvs:iszr:schemas:IszrRosCtiIco:v1"> | Kořenový element |
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1"> <CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-03-11T17:46:46.6307696+01:00</CasZadosti> <Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">A999</Agenda> <AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">CR9999</AgendovaRole> <Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm> <Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">99001</Ais> <Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt</Subjekt> <Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel156</Uzivatel> <DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel> <AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">1ffa6c28-a392-4b2b-a0e6-82c0682ef4e5</AgendaZadostId> </ZadostInfo> | Systémová hlavička: informace o žadateli. Informace o žadateli (agenda, agendová role, OVM, AIS). Bude se číst z ROB, je třeba vyplnit informace ke čten z ROB (subjekt, uživatel, důvod a účel) Hodnoty Agenda a AgendovaRole jsou case sensitive. |
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1"> <SeznamUdaju>ROBCti RUAINCti<SeznamUdaju /> </AutorizaceInfo> | Autorizační informace. Služba rosCtiIco vrací všechny údaje z ROS, požaduje se vrácení dat z ROB a RUAIN |
<Zadost> <RosCtiIcoData> <Ico xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">838420</Ico> </RosCtiIcoData> </Zadost> | Aplikančí data / datová část, vlatní dotaz. Čtení IČO 838420. |
</RosCtiIco> | Konec kořenového elelemtu |
</s:Body> </s:Envelope> | Konec SOAP obálky |
Odpověď
Odpověď se obecně skládá ze systémové hlavičky a aplikačních dat. Tyto informace jsou zabaleny v SOAP obálce definované standardem webových služeb.
<autocont1:Envelope xmlns:autocont1="http://schemas.xmlsoap.org/soap/envelope/" xmlns:autocont2="urn:cz:isvs:iszr:services:IszrRobCtiAifo:v1" xmlns:abs="urn:cz:isvs:iszr:schemas:IszrAbstract:v1" xmlns:e20="urn:cz:isvs:iszr:schemas:IszrRosCtiIco:v1" xmlns:reg="urn:cz:isvs:reg:schemas:RegTypy:v1" xmlns:xlinl="http://www.w3.org/1999/xlink" xmlns:sdo="urn:cz:isvs:ros:schemas:RosDotazyData:v2" xmlns:ros="urn:cz:isvs:ros:schemas:RosTypy:v2" xmlns:dot="urn:cz:isvs:ros:schemas:RosDotazyTypy:v1" xmlns:rod="urn:cz:isvs:rob:schemas:RobDotazyData:v1" xmlns:rob="urn:cz:isvs:rob:schemas:RobTypy:v1" xmlns:autocont3="urn:cz:isvs:ruian:schemas:CtiProRob:v1" xmlns:autocont4="urn:cz:isvs:ruian:schemas:CtiAdresa:v1"> <autocont1:Header /> <autocont1:Body> | SOAP obálka |
<e20:RosCtiIcoResponse> | Kořenový element |
<abs:OdpovedInfo> <reg:CasOdpovedi>2012-03-11T17:51:29.7729548+01:00</reg:CasOdpovedi> <reg:Status> <reg:VysledekKod>OK</reg:VysledekKod> </reg:Status> <reg:AgendaZadostId>dbdeef27-4a42-4494-a467-839b66a0eb72</reg:AgendaZadostId> <reg:IszrZadostId>1cdda624-96eb-11b2-9189-0901d7e3f144</reg:IszrZadostId> </abs:OdpovedInfo> | Systémová hlavička: výsledek zpracování, přidelěný identifikátor ISZR. |
<abs:MapaAifo lokalniAifoOd="2"> <reg:PrevodAifo> <reg:LokalniAifo stavOvereniAifo="true">1</reg:LokalniAifo> <reg:GlobalniAifo>wJGBBKL7MAADBsomIFTiqTI=</reg:GlobalniAifo> </reg:PrevodAifo> </abs:MapaAifo> | V odpovědi se vrací AIFO, je tedy obsažena struktura MapaAifo |
<abs:SeznamIdAdres> <reg:AdresniMisto stavOvereniPrvku="existuje">22251057</reg:AdresniMisto> <reg:AdresniMisto stavOvereniPrvku="existuje">1759</reg:AdresniMisto> </abs:SeznamIdAdres> | Seznam adresních míst z RUAIN na základě čtení ROS (adresa sídla) a ROB (adresa pobytu) |
<e20:RosOdpoved> |
<e20:RosCtiIcoDataResponse> <sdo:AplikacniStatus> <ros:VysledekKod>OK</ros:VysledekKod> </sdo:AplikacniStatus> <sdo:FyzickaOsoba> <dot:Ico>838420</dot:Ico> <dot:IdZmeny>18</dot:IdZmeny> <dot:PravniForma> <dot:KodPravniFormy>100</dot:KodPravniFormy> <dot:NazevPravniFormy>Podnikající fyzická osoba tuzemská</dot:NazevPravniFormy> </dot:PravniForma> <dot:OsobyAgendy> <dot:OsobaAgendy> <dot:KodAgendy>c8-00056b59bd0f</dot:KodAgendy> <dot:KodOvm>d45814c2-832a-42b9-bcc8-00056b59bdok</dot:KodOvm> <dot:NazevOsoby>Jan Jirsa</dot:NazevOsoby> <dot:DatumVznikuOpravneni>1991-07-11+02:00</dot:DatumVznikuOpravneni> <dot:AdresaSidla> <ros:OdkazRuian>22251057</ros:OdkazRuian> </dot:AdresaSidla> </dot:OsobaAgendy> </dot:OsobyAgendy> <dot:Fo> <ros:Aifo>1</ros:Aifo> </dot:Fo> </sdo:FyzickaOsoba> </e20:RosCtiIcoDataResponse> </e20:RosOdpoved> | Aplikační odpověď – informace z ROS |
<e20:RobOdpoved> <e20:RobCtiHromadneAifoDataResponse> <rod:RobAplikacniStatus> <rob:VysledekRobKodType>OK</rob:VysledekRobKodType> </rod:RobAplikacniStatus> <rod:Osoba> <rod:AdresaPobytu stav="spravny">1759</rod:AdresaPobytu> <rod:Aifo stav="spravny">1</rod:Aifo> <rod:AifoKontrolaType>Ba89bVHZEx9BeTzCN6yXOW18tvZ/jpu/oNzUI1diNMBeV0HBreMyWbaGAQq1utOpLpJUJF14no/MSd73GDFzCA==</r od:AifoKontrolaType> <rod:Jmeno stav="spravny">JAN MATĚJ VÁCLAV</rod:Jmeno> <rod:Prijmeni stav="spravny">ČERNOKOSTELECKÝ</rod:Prijmeni> </rod:Osoba> </e20:RobCtiHromadneAifoDataResponse> </e20:RobOdpoved> | Aplikační odpověď – čtení z ROB |
<e20:RuianOdpoved> <e20:RuianCtiProRobDataResponse> <autocont3:SeznamAdres> <autocont3:PolozkovaAdresa> <autocont4:OkresKod>3100</autocont4:OkresKod> <autocont4:ObecKod>554782</autocont4:ObecKod> <autocont4:ObecNazev>Praha</autocont4:ObecNazev> <autocont4:CastObceKod>400483</autocont4:CastObceKod> <autocont4:CastObceNazev>Řepy</autocont4:CastObceNazev> <autocont4:UliceKod>501492</autocont4:UliceKod> <autocont4:UliceNazev>Bazovského</autocont4:UliceNazev> <autocont4:PostaKod>16300</autocont4:PostaKod> <autocont4:PostaNazev>Praha 618</autocont4:PostaNazev> <autocont4:StavebniObjektKod>22109382</autocont4:StavebniObjektKod> <autocont4:AdresniMistoKod>22251057</autocont4:AdresniMistoKod> <autocont4:TypCislaDomovnihoKod>1</autocont4:TypCislaDomovnihoKod> <autocont4:CisloDomovni>1117</autocont4:CisloDomovni> <autocont4:CisloOrientacni>7</autocont4:CisloOrientacni> </autocont3:PolozkovaAdresa> <autocont3:PolozkovaAdresa> <autocont4:OkresKod>3502</autocont4:OkresKod> <autocont4:ObecKod>562343</autocont4:ObecKod> <autocont4:ObecNazev>Arnoltice</autocont4:ObecNazev> <autocont4:CastObceKod>434</autocont4:CastObceKod> <autocont4:CastObceNazev>Arnoltice</autocont4:CastObceNazev> <autocont4:PostaKod>40714</autocont4:PostaKod> <autocont4:PostaNazev>Arnoltice u Děčína</autocont4:PostaNazev> <autocont4:StavebniObjektKod>1759</autocont4:StavebniObjektKod> <autocont4:AdresniMistoKod>1759</autocont4:AdresniMistoKod> <autocont4:TypCislaDomovnihoKod>2</autocont4:TypCislaDomovnihoKod> <autocont4:CisloDomovni>116</autocont4:CisloDomovni> </autocont3:PolozkovaAdresa> </autocont3:SeznamAdres> <autocont3:SeznamLokalit /> </e20:RuianCtiProRobDataResponse> </e20:RuianOdpoved> | Aplikační odpověď – čtení z RUAIN |
</e20:RosCtiIcoResponse> | Konec kořenového elelemtu |
</autocont1:Body> </autocont1:Envelope> | Konec SOAP obálky |
Vybraná volání služeb
V této kapitole jsou příklady XML realizujících volání služeb na eGON rozhraní.
XML je pouze ilustrativní a principiálně se může lišit v závislosti na způsobu jeho tvorby, respektive na prostředcích použitých pro serializaci objektů do XML. Podstatným hlediskem je pak pouze to, že výsledné XML musí být formálně validní podle příslušné definice konkrétní služby (tj., odpovídat WSDL a XSD příslušné služby).
Služby S1
Služby poskytující pouze individuální referenční údaje či logické odpovědi na základě jednoznačného identifikátoru prvku (S1).
E03 / robCtiAIFO
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRobCtiAifo</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RobCtiAifo xmlns="urn:cz:isvs:iszr:schemas:IszrRobCtiAifo:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:12:40.6731672+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">05f5c46d-453a-4dbd-ac63- 2ed83a61638b</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>Aifo Prijmeni Jmeno AdresaPobytu DorucovaciAdresa DatumNarozeni MistoNarozeni DatumUmrti DatumPravniMociUmrti MistoUmrti DatovaSchrankaROB Doklad Obcanstvi ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<MapaAifo nacistData="true" xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<PrevodAifo xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">
<LokalniAifo>1</LokalniAifo>
<GlobalniAifo>pO2W98scWEFieEPtfOPQEt4=</GlobalniAifo>
</PrevodAifo>
</MapaAifo>
<Zadost>
<RobCtiAifoData>
<Aifo xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1">1</Aifo>
<VyuzitiPoskytnuti xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1">vyuziti</VyuzitiPoskytnuti>
</RobCtiAifoData>
</Zadost>
</RobCtiAifo>
</s:Body>
</s:Envelope>
E05 / robCtiPodleUdaju
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRobCtiPodleUdaju</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RobCtiPodleUdaju xmlns="urn:cz:isvs:iszr:schemas:IszrRobCtiPodleUdaju:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">0001-01-01T00:00:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">99e48363-3805-453b-a6e0- 582bbd52647a</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>Aifo Prijmeni Jmeno AdresaPobytu DorucovaciAdresa DatumNarozeni MistoNarozeni DatumUmrti DatumPravniMociUmrti MistoUmrti DatovaSchrankaROB Doklad Obcanstvi ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<Zadost>
<RobCtiPodleUdajuData>
<AdresaPobytu xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1">10014</AdresaPobytu>
<DatovaSchrankaId xsi:nil="true" xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1" />
<Jmeno xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1">ANDREA</Jmeno>
<MistoNarozeni xsi:nil="true" xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1" />
<MistoUmrti xsi:nil="true" xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1" />
<Prijmeni xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1">Bloomberg</Prijmeni>
</RobCtiPodleUdajuData>
</Zadost>
</RobCtiPodleUdaju>
</s:Body>
</s:Envelope>
E20 / rosCtiIco
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRosCtiIco</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RosCtiIco xmlns="urn:cz:isvs:iszr:schemas:IszrRosCtiIco:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:15:58.2211549+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">5f9cc633-ddf7-4327-b2cb- a9c7fa5c96b6</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>Aifo Prijmeni Jmeno AdresaPobytu DorucovaciAdresa DatumNarozeni MistoNarozeni DatumUmrti DatumPravniMociUmrti MistoUmrti DatovaSchrankaROB Doklad Obcanstvi ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<Zadost>
<RosCtiIcoData>
<Ico xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">828963</Ico>
</RosCtiIcoData>
</Zadost>
</RosCtiIco>
</s:Body>
</s:Envelope>
E21 / rosCtiAifo
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRosCtiAifo</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RosCtiAifo xmlns="urn:cz:isvs:iszr:schemas:IszrRosCtiAifo:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:45:48.9995816+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">13c281d2-3e56-4aa8-b45e- 3f4bc138eae0</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>DatovaSchrankaROS ObchodniNazev PravniForma PravniStav FyzickaOsoba AdresaSidla Provozovny StatutarniOrgany DatumVznikuOpravneni DatumZanikuOpravneni Ico ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<MapaAifo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<PrevodAifo xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">
<LokalniAifo>1</LokalniAifo>
<GlobalniAifo>pO2W98scWEFieEPtfOPQEt4=</GlobalniAifo>
</PrevodAifo>
</MapaAifo>
<Zadost>
<RosCtiAifoData>
<Aifo xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">1</Aifo>
</RosCtiAifoData>
</Zadost>
</RosCtiAifo>
</s:Body>
</s:Envelope>
E107 / rppVypisAgendu
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRppVypisAgendu</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RppVypisAgendu xmlns="urn:cz:isvs:iszr:schemas:IszrRppVypisAgendu:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:47:07.1780531+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">db8f2b5f-e0cc-4ebe-817a- 6d714206b5a9</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju />
</AutorizaceInfo>
<Zadost>
<RppVypisAgenduData>
<KodAgendy xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">A11</KodAgendy>
<DatumPlatnostiOd xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">2011-11-16</DatumPlatnostiOd>
</RppVypisAgenduData>
</Zadost>
</RppVypisAgendu>
</s:Body>
</s:Envelope>
E112 / rppVypisRozhodnuti
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1"
xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRppVypisRozhodnuti</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RppVypisRozhodnuti xmlns="urn:cz:isvs:iszr:schemas:IszrRppVypisRozhodnuti:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:48:08.717573+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">b61c63c3-e9eb-4ec7-856b- 894a0aac2666</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju />
</AutorizaceInfo>
<Zadost>
<RppVypisRozhodnutiData>
<IdentifikatorRozhodnuti xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">48136450</IdentifikatorRozhodnuti>
<KodProvadejiciAgendy xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">A11</KodProvadejiciAgendy>
<KodRozhodujicihoOvm xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">48136450</KodRozhodujicihoOvm>
</RppVypisRozhodnutiData>
</Zadost>
</RppVypisRozhodnuti>
</s:Body>
</s:Envelope>
E130 / rppVypisPusobnostOVM
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRppVypisPusobnostOvm</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RppVypisPusobnostOvm xmlns="urn:cz:isvs:iszr:schemas:IszrRppVypisPusobnostOvm:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:49:36.9886218+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">cf16cdf2-fd6f-4dda-88e5- e62e3c7ce498</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju />
</AutorizaceInfo>
<Zadost>
<RppVypisPusobnostOvmData>
<KompletniIdentifikace xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">
<KodAgendy xmlns="urn:cz:isvs:rpp:schemas:RppTypy:v1">A11</KodAgendy>
<DatumPlatnostiAgendyOd xmlns="urn:cz:isvs:rpp:schemas:RppTypy:v1">2011-11-16</DatumPlatnostiAgendyOd>
<KodOvm xmlns="urn:cz:isvs:rpp:schemas:RppTypy:v1">48136450</KodOvm>
</KompletniIdentifikace>
</RppVypisPusobnostOvmData>
</Zadost>
</RppVypisPusobnostOvm>
</s:Body>
</s:Envelope>
E99 / iszrAsyncVypisFronty
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrAsyncVypisFronty</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<IszrAsyncVypisFronty xmlns="urn:cz:isvs:iszr:schemas:IszrAsyncVypisFronty:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:42:55.6126644+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">07eaabdc-8541-4d59-8391- c1e0db0bc53d</AgendaZadostId>
</ZadostInfo>
<Zadost>
<IszrAsyncVypisFrontyData />
</Zadost>
</IszrAsyncVypisFronty>
</s:Body>
</s:Envelope>
E100 / iszrAsyncOdpovedZFronty
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrAsyncOdpovedZFronty</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<IszrAsyncOdpovedZFronty xmlns="urn:cz:isvs:iszr:schemas:IszrAsyncOdpovedZFronty:v1">
<KodAsyncSluzby>X</KodAsyncSluzby>
<ZadostInfo>
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:43:45.4085126+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">421d3210-6340-43da-84d3- 208e809322e8</AgendaZadostId>
</ZadostInfo>
<Zadost>
<IszrAsyncOdpovedZFrontyData>
<IszrZadostId>89ef7b54-97a2-11b2-9643-0901d7e42204</IszrZadostId>
</IszrAsyncOdpovedZFrontyData>
</Zadost>
</IszrAsyncOdpovedZFronty>
</s:Body>
</s:Envelope>
Služby S2
Služby poskytující hromadné referenční údaje či logické odpovědi (S2).
E37 / ruianVyhledejAdresu
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRuianVyhledejAdresu</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RuianVyhledejAdresu xmlns="urn:cz:isvs:iszr:schemas:IszrRuianVyhledejAdresu:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:40:40.3289266+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">ca25d805-d8d1-4397-a194- 91b572bd3cbe</AgendaZadostId>
</ZadostInfo>
<Zadost>
<RuianVyhledejAdresuData>
<Podminka xmlns="urn:cz:isvs:ruian:schemas:VyhledejAdresa:v1">
<UliceNazev>Úvoz</UliceNazev>
<Obec>Brno</Obec>
</Podminka>
</RuianVyhledejAdresuData>
</Zadost>
</RuianVyhledejAdresu>
</s:Body>
</s:Envelope>
E106 / rppVypisSeznamAgend
E113 / rppVypisSeznamRozhodnuti
Služby S3
Služby poskytující výběrové informace nebo vyhledání podle souboru atributů (S3).
E34q / ruianVyhledejPrvekUlice
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRuianVyhledejPrvekUlice</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RuianVyhledejPrvekUlice xmlns="urn:cz:isvs:iszr:schemas:IszrRuianVyhledejPrvekUlice:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:39:33.6661137+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">270bcba4-2eb1-4fb0-b356- 752a175c9a39</AgendaZadostId>
</ZadostInfo>
<Zadost>
<RuianVyhledejPrvekUliceData>
<Podminka xmlns="urn:cz:isvs:ruian:schemas:VyhledejUlice:v1">
<Nazev xmlns="urn:cz:isvs:ruian:schemas:UlicePodminka:v1">Úvoz</Nazev>
</Podminka>
<PozadovaneUdaje xmlns="urn:cz:isvs:ruian:schemas:VyhledejUlice:v1">
<VsechnyInformace xmlns="urn:cz:isvs:ruian:schemas:UlicePolozkyBase:v1">true</VsechnyInformace>
</PozadovaneUdaje>
</RuianVyhledejPrvekUliceData>
</Zadost>
</RuianVyhledejPrvekUlice>
</s:Body>
</s:Envelope>
Služby S4
Služby poskytující informační nebo provozní údaje (S4).
E07 / robCtiZmeny
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRobCtiZmeny</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RobCtiZmeny xmlns="urn:cz:isvs:iszr:schemas:IszrRobCtiZmeny:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:36:45.4924948+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">bc1c33e7-5213-403f-8f96- b83da1d31ddd</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>Aifo Prijmeni Jmeno AdresaPobytu DorucovaciAdresa DatumNarozeni MistoNarozeni DatumUmrti DatumPravniMociUmrti MistoUmrti DatovaSchrankaROB Doklad Obcanstvi ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<Zadost>
<RobCtiZmenyData>
<CasOd xmlns="urn:cz:isvs:rob:schemas:RobDotazyData:v1">2012-07-09T00:00:00</CasOd>
</RobCtiZmenyData>
</Zadost>
</RobCtiZmeny>
</s:Body>
</s:Envelope>
E08 / robCtiHromadneAIFO
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRobCtiHromadneAifo</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RobCtiHromadneAifo xmlns="urn:cz:isvs:iszr:schemas:IszrRobCtiHromadneAifo:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:35:53.3695135+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">20c4f10c-85d9-45b3-b1ae- e64b8607a8e8</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>Aifo Prijmeni Jmeno AdresaPobytu DorucovaciAdresa DatumNarozeni MistoNarozeni DatumUmrti DatumPravniMociUmrti MistoUmrti DatovaSchrankaROB Doklad Obcanstvi ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<MapaAifo nacistData="true" xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<PrevodAifo xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">
<LokalniAifo>1</LokalniAifo>
<GlobalniAifo>pO2W98scWEFieEPtfOPQEt4=</GlobalniAifo>
</PrevodAifo>
</MapaAifo>
<Zadost>
<RobCtiHromadneAifoData />
</Zadost>
</RobCtiHromadneAifo>
</s:Body>
</s:Envelope>
E22 / rosCtiPodleUdaju
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRosCtiPodleUdaju</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RosCtiPodleUdaju xmlns="urn:cz:isvs:iszr:schemas:IszrRosCtiPodleUdaju:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:34:31.6378387+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">506a7642-8fbf-4dee-908d- 7872257ca3c6</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>DatovaSchrankaROS ObchodniNazev PravniForma PravniStav FyzickaOsoba AdresaSidla Provozovny StatutarniOrgany DatumVznikuOpravneni DatumZanikuOpravneni Ico ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<Zadost>
<RosCtiPodleUdajuData>
<Ico xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">839281</Ico>
</RosCtiPodleUdajuData>
</Zadost>
</RosCtiPodleUdaju>
</s:Body>
</s:Envelope>
E28 / rosCtiZmeny
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRosCtiZmeny</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RosCtiZmeny xmlns="urn:cz:isvs:iszr:schemas:IszrRosCtiZmeny:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:32:24.0425407+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">b3be6b10-c743-447f-8406- e5a0c3a59dac</AgendaZadostId>
</ZadostInfo>
<Zadost>
<RosCtiZmenyData>
<CasZmenyOd xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">2012-07-09T00:00:00</CasZmenyOd>
<TypZmeny xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">U</TypZmeny>
</RosCtiZmenyData>
</Zadost>
</RosCtiZmeny>
</s:Body>
</s:Envelope>
E29 / rosCtiSeznamIco
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRosCtiSeznamIco</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RosCtiSeznamIco xmlns="urn:cz:isvs:iszr:schemas:IszrRosCtiSeznamIco:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:21:44.7509753+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">7dccbf7d-e70c-4fb9-8b9b- 94f8af3c9199</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju>Aifo Prijmeni Jmeno AdresaPobytu DorucovaciAdresa DatumNarozeni MistoNarozeni DatumUmrti DatumPravniMociUmrti MistoUmrti DatovaSchrankaROB Doklad Obcanstvi ROBCti ROSCti RUIANCti</SeznamUdaju>
</AutorizaceInfo>
<Zadost>
<RosCtiSeznamIcoData>
<NacistProvozniUdaje xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">true</NacistProvozniUdaje>
<Ico xmlns="urn:cz:isvs:ros:schemas:RosDotazyData:v2">828963</Ico>
</RosCtiSeznamIcoData>
</Zadost>
</RosCtiSeznamIco>
</s:Body>
</s:Envelope>
E105 / rppCtiZmeny
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrRppCtiZmeny</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<RppCtiZmeny xmlns="urn:cz:isvs:iszr:schemas:IszrRppCtiZmeny:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:20:50.1508523+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">ee80f8ff-23b2-4cf3-a3e4- c7153a2d6a89</AgendaZadostId>
</ZadostInfo>
<AutorizaceInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<SeznamUdaju />
</AutorizaceInfo>
<Zadost>
<RppCtiZmenyData>
<CasZmenyOd xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">2012-07-08T00:00:00+02:00</CasZmenyOd>
<TypVypisu xmlns="urn:cz:isvs:rpp:schemas:RppDotazyData:v1">R</TypVypisu>
</RppCtiZmenyData>
</Zadost>
</RppCtiZmeny>
</s:Body>
</s:Envelope>
Služby E
Seznam služeb realizujících zápis, změnu či výmaz (E).
E45 / orgPrihlasAIFO
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrOrgPrihlasAifo</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<OrgPrihlasAifo xmlns="urn:cz:isvs:iszr:schemas:IszrOrgPrihlasAifo:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:19:46.8382311+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2bef2546-497c-49b9-a272- ac4818509cda</AgendaZadostId>
</ZadostInfo>
<MapaAifo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<PrevodAifo xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">
<LokalniAifo>1</LokalniAifo>
<GlobalniAifo>pO2W98scWEFieEPtfOPQEt4=</GlobalniAifo>
</PrevodAifo>
</MapaAifo>
</OrgPrihlasAifo>
</s:Body>
</s:Envelope>
E46 / orgOdhlasAIFO
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">IszrOrgOdhlasAifo</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<OrgOdhlasAifo xmlns="urn:cz:isvs:iszr:schemas:IszrOrgOdhlasAifo:v1">
<ZadostInfo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<CasZadosti xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">2012-07-09T21:19:07.1699622+02:00</CasZadosti>
<Agenda xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">X999</Agenda>
<AgendovaRole xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">XR1</AgendovaRole>
<Ovm xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">12345678</Ovm>
<Ais xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">999001</Ais>
<Subjekt xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Subjekt F5klient</Subjekt>
<Uzivatel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Uzivatel</Uzivatel>
<DuvodUcel xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">Duvod a ucel</DuvodUcel>
<AgendaZadostId xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">e6ff699c-8f76-4fb4-9254- 89e3f80232da</AgendaZadostId>
</ZadostInfo>
<MapaAifo xmlns="urn:cz:isvs:iszr:schemas:IszrAbstract:v1">
<PrevodAifo xmlns="urn:cz:isvs:reg:schemas:RegTypy:v1">
<LokalniAifo>1</LokalniAifo>
<GlobalniAifo>pO2W98scWEFieEPtfOPQEt4=</GlobalniAifo>
</PrevodAifo>
</MapaAifo>
</OrgOdhlasAifo>
</s:Body>
</s:Envelope>