Specifikace služby IS CEDR pro automatické zasílání aktualizačních dávek s výsledky kontrol

Transkript

1 PRO INTERNÍ POTŘEBU Specifikace služby IS CEDR pro automatické zasílání aktualizačních dávek s výsledky kontrol vypracovala společnost ASD Software, s.r.o. dokument ze dne , verze 1.0.0

2 Specifikace služby IS CEDR pro automatické zasílání aktualizačních dávek s výsledky kontrol Počet stran v dokumentu celkem : 21 Rozdělovník : Číslo Počet výtisků Předáno Převzal 1 1 x MF, odbor 38 Ing. Hana Domínová 2 1x MF, odbor 43 Ing. Miroslav Mrklovský

3 OBSAH 1. ÚVOD PROCESNÍ POSTUPY AKTIVACE SLUŽBY PŘENOS INFORMACÍ TECHNICKÉ ŘEŠENÍ PŘENOSOVÝ FORMÁT DAT VALIDACE A POPIS XML DOKUMENTŮ XML Schema Jmenné prostory RDDL TRANSPORTNÍ PROTOKOLY Základní transportní protokol SOAP protokol Použití protokolu BizTalk MODEL PŘENOSU ZPRÁV ŘEŠENÍ BEZPEČNOSTI Integrita přenosu dat Důvěrnost přenosu dat Nepopíratelnost odesílatele POJMENOVÁVACÍ KONVENCE ZPRACOVÁNÍ CHYB Chyby na úrovni validace pomocí XML Schema Chyby na úrovni aplikační POPIS PŘEDÁVANÝCH DAT USTANOVENÍ PRO DEFINICI PLATNOSTI ELEMENTŮ PŘEDÁVÁNÍ DAT O KONTROLÁCH Z IS CEDR Popis schémat Aktualizační dávka PODROBNÝ POPIS ŽIVOTNÍHO CYKLU ZPRÁV AUTOMATICKÉ VYTVÁŘENI AKTUALIZAČNÍCH DÁVEK NA DATABÁZI IS CEDR PŘÍLOHY Struktura v XML pro aktualizační dávku SCHÉMATA PRO SLUŽBU Schéma cedr_aa_datatypes.xsd Schéma cedr_aa_batch.xsd STRUKTURA SMTP KOMUNIKACE Příklad aktualizační dávky REFERENCE

4 1. Úvod Tato dokumentace obsahuje popis služby IS CEDR, která v pravidelných intervalech vytváří a následně zasílá aktualizační dávku (ve formátu XML) na kontaktní ovou adresu. Aktualizační dávka obsahuje informace o kontrolách (a jejich aktualizacích) prováděných FÚ v rámci správy odvodu za porušení rozpočtové kázně. Poskytovatelem této služby je Ministerstvo financí, v jehož plné kompetenci je také definice popisované služby. Předpokladem je, že dávký budou zpracovávány řadou klientských aplikací; proto jsou zvoleny taková architektonická řešení a technologie, které umožní relativně jednoduché dosažení interoperability (XML formát dat). 4

5 2. Procesní postupy 2.1 Aktivace služby Služba je automaticky aktivována na základě aktivace služby CEDR-VK. 2.2 Přenos informací Služba na straně IS CEDR bude automaticky vytvářet aktualizační dávky, které budou odeslány pomocí protokolu SMTP na adresu klientů tak, jak je uvedeno na obr. 1: Aktualizační dávka IS CEDR Klient služby Obr. 1 Zasílání aktualizačních dávek z databáze IS CEDR Poznámka: Předpokladem zasílání informací ze služby CEDR AA je provedení tzv. Hromadného dožádání viz popis web-službyx CEDR-HD. V tomto případě (obr. 1) probíhají globální procesy následujícícm způsobem: 1. Na straně serveru (IS CEDR) je vygenerována elektronická dávky (ve formátu XML). K vygenrování dávky dochází vždy 1x za 24 hod a to pouze za předpokladu, že existují informace (viz dále), které mají být příslušnému příjemci doručeny. 2. Dávka je opatřena všemi náležitostmi dle této specifikace a je odeslána prostřednictvím SMTP na ovou adresu příslušného příjemce (jedná se o adresu, která byla předána MF v rámci žádosti o zpřístupnění výsledků kontropl). 5

6 3. Technické řešení Pokud není explicitně uvedeno jinak, specifikace této služby přebírá zásady technického řešení, uváděné v dokumentu [3]. 3.1 Přenosový formát dat Jako formát pro přenos dat bude použit standard XML 1.0, Second Edition [4]. Přenášené XML dokumenty musejí splňovat všechny požadavky standardu. 3.2 Validace a popis XML dokumentů XML Schema Veškeré přenášené XML dokumenty budou mít pro účely validace vytvořen popis formátu dokumentu dle standardu XML Schema [5]. Validace XML dokumentů bude prováděna vždy před odesláním dávky službou. Dávky XML budou mít v kořenovém elementu dokumentu deklarován jmenný prostor schématu daného dokumentu. Pomocí atributu xsi:schemalocation bude také uvedena fyzická lokalizace schématu. Všechna schémata budou obsahovat dokumentaci schématu. Formát RDF dokumentace bude odpovídat dle [3]. Všechna schémata budou verzována v souladu se zásadami, uvedenými v [3]. Cílové jmenné prostory všech schémat budou podporovat specifikaci RDDL dle [3] Jmenné prostory Jmenné prostory schémat, popisujících přenášené XML dokumenty popisované služby, budou ve formátu URL nebo URN RDDL RDDL slouží ke snadnému přístupu ke zdrojům, spojeným se službou. RDDL soubory budou splňovat požadavky dokumentu [3]. 3.3 Transportní protokoly Základní transportní protokol Základním transportním protokolem pro popisovanou službu bude protokol SMTP SOAP protokol Nad protokolem SMTP bude použit rozšiřující XML protokol SOAP ve verzi 1.1 [2]. Protokol SOAP bude mít implementováno jak záhlaví SOAP (element <Header>), tak tělo SOAP (element <Body>). V záhlaví SOAP budou v BizTalk elementech neseny administrativní informace (bližší viz 3.3.3). 6

7 Všechny elementy SOAP budou mít nastaven atribut MustUnderstand na hodnotu Použití protokolu BizTalk Pro administraci zpráv bude použito elementů specifikace BizTalk [1]. Zprávy přenášející data (dotazy i odpovědi) budou povinně obsahovat elementy: <endpoints> s indikací odesílatele a adresáta zprávy <properties> popisující vlastní přenášený dokument v souladu s pravidly dle [3]. Element <expiresat> Exspirace dávky bude nastavena na jedn měsíc. Elementy <address> specifikace BizTalk budou používat prosté řetězce pro označení účastníka komunikace. Elementy <topic> budou uvádět jmenný prostor schématu, odpovídajícího přenášené dávce. Pro jednoznačnou identifikaci dokumentu slouží subelement <identity> elementu <properties>. Platí následující pravidlo : Naplnění elementu <identity> zajistí odesílající strana. Doporučeno je použití takového identifikátoru, které bude dokument jednoznačně identifikovat (generování UUID některým z vhodných nástrojů). Všechny elementy BizTalk, které mohou nést atribut MustUnderstand, musejí mít pro účely této služby tento atribut přítomen a nastaven na hodnotu Model přenosu zpráv Jako model pro přenos zpráv bude použit model message passing dle [3], kap Řešení bezpečnosti Služba ve verzi, odpovídající tomuto dokumentu, bude mít implementovány následující bezpečnostní funkce (viz též [3], kap ) Integrita přenosu dat Integritou dat se rozumí zabezpečení citlivých dat před jejich změnou během transportu.. K zabezpečení integrity přenosu dat (viz [3], kap ) bude v této službě použit certifikát poskytovatele služby, kterým bude podepsáná aktualizační dávka Důvěrnost přenosu dat Důvěrností přenosu dat rozumíme zabezpečení dat proti odposlechu během transportu. Aktualizační dávky budou šifrovány veřejným klíčem certifikátu klienta služby Nepopíratelnost odesílatele Nepopíratelnost odesílatele bude implementována v souladu s [3], kap a Pro účely zajištění nepopíratelnosti odesílatele bude podepisován celý element <Body> zprávy SOAP a BizTalk elementy <endpoints>, <properties>. Pro podpis bude použit certifikát identity. Element <Signature> 7

8 bude mít atribut Id s hodnotou Signature. Pro podpis bude použita kanonická transformace dle na uir a ares 110.doc 3.6 Pojmenovávací konvence RDDL soubory, umístěné na URL jmenných prostorů, budou mít příponu.html. Všechny soubory, dostupné pomocí RDDL, budou mít názvy souborů vytvořené pouze malými písmeny. Tyto pravidla nemají vliv na uživatelské pojmenovávání souborů služeb, vztahují se pouze na soubory RDDL zdrojů a slouží pouze pro informaci. 3.7 Zpracování chyb Chyby na úrovni validace pomocí XML Schema Při výskytu chyby na úrovni validace pomocí XML Schema nebude aktualizační dávka na klienta odeslána. V tomto případě bude o výskytu chyby informován zřizovatel služby Chyby na úrovni aplikační Tyto chyby se týkají např. selhání aplikační databáze CEDR, narušení referenční integrity či primárních klíčů aplikační databáze. V tomto případě bude o výskytu chyby informován zřizovatel služby. 8

9 4. Popis předávaných dat 4.1 Ustanovení pro definici platnosti elementů Zkratka Význam I Nebere se v úvahu (ignore) P Povinné N Nepovinné Označení povinnosti předávání jednotlivých elementů a v nich předávaných dat je uvedeno v následující tabulce. První znak v použité zkratce udává povinnost elementu, druhý udává platnost dat nebo-li hodnotu elementu. Zkratka Význam Podrobný popis PP Povinný Element Povinná Data Element i data jsou povinná NP Nepovinný Element Povinná Data Element je volitelný ale pokud je uveden jsou povinná i data. NN Nepovinný Element Nepovinná Data Pokud je element uveden není nutné uvádět data. To je vhodné např. pro UPDATE kdy je zapotřebí hodnotu přepsat. Nejsou-li data u elementu uvedena je nutné nastavit atribut null na hodnotu true. NI Nepovinný Element Ignorují se Data Element je nepovinný, ale pokud bude uveden data budou ignorována. Např. při operaci DELETE je nutný pouze primární klíč a ostatní hodnoty jsou ignorovány. 9

10 4.2 Předávání dat o kontrolách z IS CEDR Datové typy podléhající standardu UVIS jsou specifikovány v souboru cedr_aa_datatypes.xsd (viz. Kapitola Chyba! Nenalezen zdroj odkazů..1). Jména typů jsou odvozeny z názvu položky tím způsobem, že před jméno položky je přidán prefix typ_ Popis schémat Pro aktualizační dávku je taktéž definováno schéma (viz. Kapitola Chyba! Nenalezen zdroj odkazů..2) Aktualizační dávka Aktualizační dávky budou vytvářeny v centrální databázi automaticky při každém rozhrání dat s výsledky kontrolních činností (tj. 1x za 24 hodin). Rozhodné podmínky pro generování aktualizačních dávek budou následující: 1) Ukončení/odstranění ukončení/změna ukončení kontrolní činnosti, resp. vyplnění/odstranění/změna data ukončení/projednání, nebo odstranění kontrolovaného rozhodnutí z již ukončené kontrolní činnosti 2) Odeslání platebního výměru finančním úřadem 3) změna platebního výměru na odvod(zvýšení/snížení odvodové povinnosti apod.) 4) zaplacení/vydobytí zneužitých prostředků Podmínky, které nebudou důvodem pro generování aktualizačních dávek budou následující: vytvoření, resp. odeslání posečkání/plátkování (protože neovlivňuje výši odvodu) vytvoření, resp. odeslání prominutí (protože není zohledněno ani v rámci služby CEDR- VK) Na základě těchto rozhodných podmínek bude vytvořen následující číselník aktualizačních podmínek. Informace o podmínkách, na základě kterých bude aktualizační dávka vytvořena, budou součástí aktualizační dávky, více viz níže. Aktualizační dávka bude obsahovat pouze základní informace o příjemci dotace (odvozeno z odpovědi na hromadné dožádání). Aktuální stav dat si uživatel zjistí následným dotazem na web službu Služba VK. A) Základní informace Poř č. Položka Povinnost Poznámka 1. Odesláno dne PP Datum odeslání aktualizační dávky z centra k poskytovateli. B) Podkategorie příjemce dotace V aktualizační dávce bude uveden seznam s informacemi o příjemci dotace (odvozeno z odpovědi na hromadné dožádání) Poř č. Položka Povinnost Poznámka 1. Identifikace příjemce PP Jednoznačná identifikace(klíč) příjemce dotace v IS CEDR II, ke 10

11 dotace kterému se vztahuje aktualizační dávka 2. IČ NP 1,3 Identifikační číslo příjemce dotace, u kterého došlo k aktualizaci dat 3. Obchodní jméno NP 1,3 Obchodní jméno se vyplňuje u právnické osoby(po) a fyzické osoby podnikající(fop) - obchodní jméno podle Obchodního zákoníku 9 4. RČ NP 2,3 Rodné číslo příjemce dotace, u kterého došlo k aktualizaci dat 5. Titul před jménem NN 2,3 Vědecké a akademické tituly uvedené před jménem fyzické osoby (FO) nebo FOP 6. Příjmení NP 2,3 Příjmení FO nebo FOP 7. Jméno NP 2,3 Jméno FO nebo FOP 8. Titul za jménem NN 2,3 Vědecké a akademické tituly uvedené před jménem FO nebo FOP 9. Změněno dne (od**) PP Datum provedení změny, tj. k tomuto datu byla data naposledy/poprvé * aktualizována na zdrojovém FÚ před odesláním do centrální databáze 10. Změněno dne do ** NP Datum provedení změny, tj. k tomuto datu byla data naposledy aktualizována na zdrojovém FÚ před odesláním do centrální databáze Vysvětlivky: NP 1,3,NP 2,3 - Identifikační číslo/rodné číslo bude mít formát, který stanovují standardy SIS ČR ke dni odsouhlasení tohoto rozhraní. ** - vyplněno, pouze pokud platí následující podmínka: protože je v aktualizační dávce zasílána globální informace o aktualizaci příjemce dotace, může existovat interval datumů od do (minimální* a maximální datum ze všech změnových dávek, doručených do centra z FU, ze kterých je generována aktualizační dávka) => v této položce bude maximální datum ze všech změnových dávek Např. u příjemce dotace byla aktualizována data ve dvou kontrolních činnostech(každá v jiný den) a tyto informace byly postoupeny do centra v jedné dávce => obě informace budou zahrnuty do aktualizační dávky C) Podkategorie k příjemci dotace Podmínky aktualizace Doplňkovou informací k podkategorii příjemce dotace bude seznam splněných rozhodných podmínek, na základě kterých byla aktualizační dávka vytvořena : Poř č. Položka Povinnost Poznámka 1. Kód podmínky PP Kód rozhodná podmínky aktualizace dle číselníku aktualizace 2. Název podmínky PP Název rozhodné podmínka aktualizace dle číselníku aktualizace Poznámka:Aktualizační podmínky budou zahrnuty do seznamu proto, že jedna aktualizační dávka může splňovat více splněných aktualizačních podmínek, např. ukončení kontrolní činnosti(podmínka č.1) a odeslání PVO(tj. změna PVO, podmínka č.4). Poznámka 1/2 1 Ukončení/změna ukončení kontrolní činnosti, resp. vyplnění/změna data ukončení/projednání 11

12 2 Odstranění ukončení kontrolní činnosti, resp. odstranění data ukončení/projednání 3 - Odstranění zkontrolovaného rozhodnutí z již ukončené kontrolní činnosti 4 - Změna výše odvodu(předpis/změna odvodové povinnosti po odeslání příslušného rozhodnutí finančním úřadem, apod.) 5 Zaplacení zneužitých prostředků(dílčí změna zaplacené částky odvodu) 6 Vydobytí zneužitých prostředků(zaplacení celého odvodu) Princip bude pro každého příjemce dotace(pd), obsaženého v datech s výsledky kontrol, následující: a) Systém zjistí, zda bude pro daného PD vytvářet aktualizační dávku(tj. zda byly splněny podmínky pro automatickou aktualizaci, tj. zda byl na dané RČ/IČ proveden jednoduchý dotaz, případně hromadné dožádání). b) Pokud bude splněna podmínka pro vytvoření aktualizační dávky, zjistí se seznam poskytovatelů, kteří splňují bod a), pokud nebude splněna podmínka v bodu a), aktualizační dávka se pro daného PD vytvářet nebude. c) Pro každého poskytovatele, splňujícího bod b)) a pokud budou splněny rozhodné podmínky pro generování aktualizační dávky, bude provedena kontrola, zda má poskytovatel přístup na aktualizované rozhodnutí.pokud ano, bude vytvořena aktualizační dávka, obsahující informace dle výše uvedeného schématu.pokud poskytovatel nemá přístup na aktualizované rozhodnutí, nebude aktualizační dávka vytvořena. d) Po vytvoření všech dávek budou tyto odeslány na kontaktní ové adresy založený v rámci přístupu na službu CEDR-VK. 12

13 5. Podrobný popis životního cyklu zpráv 5.1 Automatické vytvářeni aktualizačních dávek na databázi IS CEDR Tato kapitola je zpřesněním kapitoly 2. tohoto dokumentu Popisuje detailně procesy při vytváření dávek. Řešení je možno popsat následujícím blokovým schématem: Obr.2 Podrobný popis životního cyklu generování aktualizačních dávek na databázi IS CEDR 13

14 6. Přílohy Struktura v XML pro aktualizační dávku Název elementu v XML 1. <batch batch_count="m" batch_datetime=" t10:55:01"> 2. <data_batch> 3. <identifikace_prijemce>hodnota</identifikace_prijemce> 4. <IC>hodnota</IC> 5. <obchodni_jmeno>hodnota</obchodni_jmeno> 6. <rodne_cislo>hodnota</rodne_cislo> 7. <titul_pred>hodnota</titul_pred> 8. <prijmeni>hodnota</prijmeni> 9. <jmeno>hodnota</jmeno> 10. <titul_za>hodnota</titul_za> 11. <zmena_ke_dni> hodnota</zmena_ke_dni> 12. <seznam_aktualizaci> 13. <aktualizace> 14. <kod_podminky_aktualizace>hodnota</kod_podminky_aktualizace> 15. <nazev_podminky_aktualizace>hodnota</nazev_podminky_aktualizace> 16. </aktualizace> </seznam_aktualizaci> 19. </data_batch> </batch> 6.2 Schémata pro službu Schéma cedr_aa_datatypes.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:dc=" xmlns="urn:cz:isvs:mfcr:schemas:cedrii:aa:datatypes:v100" xmlns:xs=" xmlns:rdf=" xmlns:dcterm=" targetnamespace="urn:cz:isvs:mfcr:schemas:cedrii:aa:datatypes:v100" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:documentation xml:lang="cs">návrh XML schématu datových typů aktualizačních dávek v IS CEDR II ASD Software s.r.o., </xs:documentation> <xs:appinfo> <rdf:rdf> <rdf:description rdf:about="urn:cz:isvs:mfcr:schemas:cedrii:aa:datatypes:v100" xml:lang="cs"> <dc:creator>aleš Janíček (janicek@asd-software.cz)</dc:creator> <dc:description>návrh XML schématu datových typů pro aktualizační dávky zasílané z CEDR AA verze Toto schéma obsahuje definice datových typů aktualizační dávky v CEDR AA.</dc:description> <dc:identifier>urn:cz:isvs:mfcr:schemas:cedrii:aa:datatypes:v100</dc:identifier> <dc:publisher>ministerstvo financí ČR</dc:publisher> <dc:rights> ASD Software s.r.o., </dc:rights> <dc:source> <dc:type>xml Schema</dc:type> <dcterm:created> </dcterm:created> <dcterm:valid> </dcterm:valid> <dc:subject>cedr AA datové typy</dc:subject> <dc:format>text/xml</dc:format> </rdf:description> </rdf:rdf> </xs:appinfo> 14

15 <xs:simpletype name="typ_batch_count"> <xs:documentation>typ počet záznamů v aktualizační dávce</xs:documentation> <xs:restriction base="xs:int"/> <xs:simpletype name="typ_batch_datetime"> <xs:documentation>typ datum čas pro dávku</xs:documentation> <xs:restriction base="xs:datetime"/> <xs:simpletype name="typ_datum_cas"> <xs:documentation>datum a čas</xs:documentation> <xs:restriction base="xs:datetime"/> <xs:simpletype name="typ_ic"> <xs:documentation>identifikační číslo</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="8"/> <xs:maxlength value="8"/> <xs:pattern value="\d\d\d\d\d\d\d\d"/> </xs:restriction> <xs:simpletype name="typ_id_prijd"> <xs:documentation>identifikace příjemce dotace v IS CEDR II</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="11"/> <xs:maxlength value="11"/> <xs:pattern value="[1-9] [1-9][0-9]{10}"/> </xs:restriction> <xs:simpletype name="typ_jmeno"> <xs:documentation>jméno fyzické osoby nebo fyzické osoby podnikající</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="24"/> </xs:restriction> <xs:simpletype name="typ_obchodni_jmeno"> <xs:documentation>obchodní jméno u právnické osoby(po) a fyzické osoby podnikající(fop) - obchodní jméno podle Obchodního zákoníku 9</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="255"/> </xs:restriction> <xs:simpletype name="typ_prijmeni"> <xs:documentation>příjmení fyzické osoby nebo fyzické osoby podnikající</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="35"/> </xs:restriction> <xs:simpletype name="typ_question_count"> <xs:documentation>typ počet dotazu</xs:documentation> <xs:restriction base="xs:int"/> 15

16 <xs:simpletype name="typ_question_datetime"> <xs:documentation>typ datum čas pro dotaz</xs:documentation> <xs:restriction base="xs:datetime"/> <xs:simpletype name="typ_question_number"> <xs:documentation>číslo dotazu</xs:documentation> <xs:restriction base="xs:int"/> <xs:simpletype name="typ_rodne_cislo"> <xs:documentation>rodné číslo</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="9"/> <xs:maxlength value="10"/> <xs:pattern value="\d\d( )\d\d\d\d\d\d?"/> </xs:restriction> <xs:simpletype name="typ_titul_pred"> <xs:documentation>titul před jménem osoby</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="2"/> <xs:maxlength value="35"/> </xs:restriction> <xs:simpletype name="typ_titul_za"> <xs:documentation>titul za jménem osoby</xs:documentation> <xs:restriction base="xs:string"> <xs:minlength value="2"/> <xs:maxlength value="10"/> </xs:restriction> </xs:schema> Schéma cedr_aa_batch.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:dcterm=" xmlns:rdf=" xmlns:dtt="urn:cz:isvs:mfcr:schemas:cedrii:aa:datatypes:v100" xmlns:xs=" xmlns="urn:cz:isvs:mfcr:schemas:cedrii:aa:batch:v100" xmlns:dc=" targetnamespace="urn:cz:isvs:mfcr:schemas:cedrii:aa:batch:v100" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:documentation xml:lang="cs">návrh XML schématu aktualizační dávky zasílané z IS CEDR II ASD Software s.r.o., </xs:documentation> <xs:appinfo> <rdf:rdf> <rdf:description rdf:about="urn:cz:isvs:mfcr:schemas:cedrii:aa:batch:v100" xml:lang="cs"> <dc:creator>aleš Janíček (janicek@asd-software.cz)</dc:creator> <dc:description>návrh XML schématu zprávy s aktualizační dávkou zaslanou z IS CEDR II verze Toto schéma obsahuje definice aktualizační dávky v IS CEDR II</dc:description> <dc:identifier>urn:cz:isvs:mfcr:schemas:cedrii:aa:batch:v100</dc:identifier> <dc:publisher>ministerstvo financí ČR</dc:publisher> <dc:rights> ASD Software s.r.o., </dc:rights> <dc:source> <dc:type>xml Schema</dc:type> <dcterm:created> </dcterm:created> <dcterm:valid> </dcterm:valid> <dc:subject>cedr AA aktualizační dávka</dc:subject> <dc:format>text/xml</dc:format> 16

17 </rdf:description> </rdf:rdf> </xs:appinfo> <xs:import namespace="urn:cz:isvs:mfcr:schemas:cedrii:aa:datatypes:v100" schemalocation=" <xs:element name="data_batch"> <xs:documentation>element jedné věty</xs:documentation> <xs:complextype> <xs:sequence> <xs:element name="identifikace_prijemce" type="dtt:typ_id_prijd"/> <xs:element name="ic" type="dtt:typ_ic" minoccurs="0"/> <xs:element name="obchodni_jmeno" type="dtt:typ_obchodni_jmeno" minoccurs="0"/> <xs:element name="rodne_cislo" type="dtt:typ_rodne_cislo" minoccurs="0"/> <xs:element name="titul_pred" type="dtt:typ_titul_pred" minoccurs="0"/> <xs:element name="prijmeni" type="dtt:typ_prijmeni" minoccurs="0"/> <xs:element name="jmeno" type="dtt:typ_jmeno" minoccurs="0"/> <xs:element name="titul_za" type="dtt:typ_titul_za" minoccurs="0"/> <xs:choice> <xs:element name="zmena_ke_dni" type="dtt:typ_datum_cas"/> <xs:element name="zmena_ke_dni_interval"> <xs:complextype> <xs:sequence> <xs:element name="od" type="dtt:typ_datum_cas"/> <xs:element name="do" type="dtt:typ_datum_cas"/> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> <xs:sequence> <xs:element name="seznam_aktualizaci"> <xs:complextype> <xs:sequence> <xs:element name="aktualizace" maxoccurs="unbounded"> <xs:documentation>element jedné aktualizace</xs:documentation> <xs:complextype> <xs:sequence> <xs:element name="kod_podminky_aktualizace" type="xs:short"/> <xs:element name="nazev_podminky_aktualizace" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="batch"> <xs:documentation>kořenový element dávky</xs:documentation> <xs:complextype> <xs:sequence> <xs:element ref="data_batch" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="batch_datetime" type="dtt:typ_batch_datetime" use="required"/> <xs:attribute name="batch_count" type="dtt:typ_batch_count" use="required"/> </xs:complextype> </xs:element> </xs:schema> 17

18 6.3 Struktura smtp komunikace Příklad aktualizační dávky <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" <SOAP-ENV:Header> <eps:endpoints xmlns:eps=" SOAP-ENV:mustUnderstand="1" Id="idEndpoints"> <eps:to> </eps:to> <eps:from> </eps:from> </eps:endpoints> <prop:properties SOAP-ENV:mustUnderstand="1" xmlns:prop=" Id="idProperties"> <prop:identity>2c30fc8c f-ebf824fc59be</prop:identity> <prop:sentat> t11:14:37</prop:sentat> <prop:expiresat> t11:14:37</prop:expiresat> <prop:topic>urn:cz:isvs:mfcr:schemas:cedrii:aa:batch:v100</prop:topic> </prop:properties> <dsig:signature xmlns:dsig=" Id="idSignature"> <dsig:signedinfo> <dsig:canonicalizationmethod Algorithm=" "/> <dsig:signaturemethod Algorithm=" <dsig:reference URI="#idBody"> <dsig:transforms> <dsig:transform Algorithm=" "/> </dsig:transforms> <dsig:digestmethod Algorithm=" <dsig:digestvalue>wdar2umvdhezpwie4jtgqtjfv60=</dsig:digestvalue> </dsig:reference> <dsig:reference URI="#idKeyInfo"> <dsig:transforms> <dsig:transform Algorithm=" "/> </dsig:transforms> <dsig:digestmethod Algorithm=" <dsig:digestvalue>kzkq/bh2nz0kma1c4mkahwkaw/c=</dsig:digestvalue> </dsig:reference> <dsig:reference URI="#idEndpoints"> <dsig:transforms> <dsig:transform Algorithm=" "/> </dsig:transforms> <dsig:digestmethod Algorithm=" <dsig:digestvalue>yqqins9c+d7g1qabjv5iob0tlq0=</dsig:digestvalue> </dsig:reference> <dsig:reference URI="#idProperties"> <dsig:transforms> <dsig:transform Algorithm=" "/> </dsig:transforms> <dsig:digestmethod Algorithm=" <dsig:digestvalue>afycaydvtq95wg6nwmv3nz1oik0=</dsig:digestvalue> </dsig:reference> </dsig:signedinfo> <dsig:signaturevalue>msmjzkgztiqd41cdmavmj0zhx2qxhj7gn2s1bolzq+tb7msj21fhcjoq+j+6jila0lviwzd9nngdk9 wxi/dfkdlyagqjqj/dctuhuplcomnxbrjz9xpbuckm9tzx6pkp+b+abme/idlmmsw+o/srimqdcvy=</dsig:signaturevalue> <dsig:keyinfo Id="idKeyInfo"> <dsig:x509data> <dsig:x509issuerserial> 18

19 C=CZ, L=Praha, O=Ministerstvo financi, CN=CA Ministerstva financi - aplikace</dsig:x509issuername> <dsig:x509serialnumber>1139e </dsig:x509serialnumber> </dsig:x509issuerserial> <dsig:x509subjectname>e=hot-line@asd-software.cz, C=CZ, L=Praha, O=Ministerstvo financi, CN=CEDRVK</dsig:X509SubjectName> <dsig:x509certificate>miid5tcca4+gawibagiketnlfaaaaabjbtanbgkqhkig9w0baqufadcbizegmb4gcsqgsib3dqe JVibWFzdGVyQG1mY3IuY3oxCzAJBgNVBAYTAkNaMQ4wDAYDVQQHEwVQcmFoYTEdMBsGA1UZXJzdHZvIGZpbmFuY2kxKzApB gnvbamtiknbie1pbmlzdgvyc3r2ysbmaw5hbmgyxbsawthy2uwhhcnmduwota4mtiynde0whcnmdywota4mtiznde0wjb2m ScwJQYJKoZIhQtbGluZUBhc2Qtc29mdHdhcmUuY3oxCzAJBgNVBAYTAkNaMQ4wDAYDVQQHEwVQUEChMUTWluaXN0ZXJzdHZvI GZpbmFuY2kxDzANBgNVBAMTBkNFRFJWSzCBnzAw0BAQEFAAOBjQAwgYkCgYEAo+OiwjyjABDwn44WMWl2umQpsimcfcIHNXcP LbOo1p P5Rk531dEkn7Ji9kunPPOeBsWYSjLvKxj1ocRGDYGA/JUxbwG0P/God1klkaE6G6UUH8yv43Fqa3mkrTCfCafn8FmeanRtQt3sn5sk6sc kxo2iclmvpo2mr0hzccaweaaaocaamwgggfma4guddweb/wqeawie8datbgnvhsueddakbggrbgefbqcdajadbgnvhq4efg QUYtrGDYTtMZwHNuh//sLi0wgccGA1UdIwSBvzCBvIAUb2fdHufoJnCHUVTp4sHpFWFwcO+hgZGkgY4wgYsxIDw0BCQEWEXdlYm1h c3rlckbtzmnylmn6mqswcqydvqqgewjdwjeomawga1uebxmfupbmlzdgvyc3r2bybmaw5hbmnpmsswkqydvqqdeyjdqs BNaW5pc3RldmEgZmluYW5jaSAtIGFwbGlrYWNlghBVPDF7W4jRt01z02TLlZwtMEEGA1UdHwQ6MDgwNqA odkgmgh0dha6ly9hchaubwzjci5jei9dzxj0rw5yb2xsl0nbx01gx2fwbglrywnllmnybdbmbgwpayikwybbquhmakgmgh0dh A6Ly9hcHAubWZjci5jei9DZXJ0RW5yb2xsL NBX01GX2FwbGlrYWNlLmNydDANBgkqhkiG9w0BAQUFAANBAFy1pneFX36XGhF+KGVuFKpCdQiH+1l69uHMlK+4lsJVkLDfZyw8W HfpuDE3NK+RiuCEeeILVwg=</dsig:X509Certificate> </dsig:x509data> </dsig:keyinfo> </dsig:signature> </SOAP-ENV:Header> <SOAP-ENV:Body Id="idBody"> <batch xmlns="urn:cz:isvs:mfcr:schemas:cedrii:aa:batch:v100" xmlns:xsi=" xsi:schemalocation="urn:cz:isvs:mfcr:schemas:cedrii:aa:batch:v100 batch_count="3" batch_datetime=" T11:14:36"> <data_batch> <identifikace_prijemce> </identifikace_prijemce> <rodne_cislo> </rodne_cislo> <prijmeni>šlahařová</prijmeni> <jmeno>petra</jmeno> <zmena_ke_dni> t15:38:47</zmena_ke_dni> <seznam_aktualizaci> <aktualizace> <kod_podminky_aktualizace>2</kod_podminky_aktualizace> <nazev_podminky_aktualizace>odstranění ukončení kontrolní činnosti</nazev_podminky_aktualizace> </aktualizace> </seznam_aktualizaci> </data_batch> <data_batch> <identifikace_prijemce> </identifikace_prijemce> <IC> </IC> <obchodni_jmeno>david Kukleta</obchodni_jmeno> <rodne_cislo> </rodne_cislo> <prijmeni>kukleta</prijmeni> <jmeno>david</jmeno> <zmena_ke_dni> t08:36:24</zmena_ke_dni> <seznam_aktualizaci> <aktualizace> <kod_podminky_aktualizace>6</kod_podminky_aktualizace> <nazev_podminky_aktualizace>vydobytí zneužitých prostředků</nazev_podminky_aktualizace> </aktualizace> </seznam_aktualizaci> </data_batch> <data_batch> <identifikace_prijemce> </identifikace_prijemce> <rodne_cislo> </rodne_cislo> <prijmeni>čikasová</prijmeni> <jmeno>veronika</jmeno> <zmena_ke_dni> t14:45:02</zmena_ke_dni> <seznam_aktualizaci> <aktualizace> <kod_podminky_aktualizace>5</kod_podminky_aktualizace> 19

20 <nazev_podminky_aktualizace>zaplacení zneužitých prostředků </nazev_podminky_aktualizace> </aktualizace> </seznam_aktualizaci> </data_batch> </batch> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 20

21 7. Reference [1] BizTalk BizTalk TM Framework 2.0. Document and Message Specification. Microsoft Corporation, 12-December [2] SOAP Simple Object Access Protocol (SOAP) 1.1 W3C Note 08 May Viz [3] Standardy komunikace na bázi XML XML - Standardy komunikace na bázi XML - Použití ve finančních a podpůrných informačních systémech. Verze 1.05 ASD Software, s.r.o Viz. [4] XML Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October Viz [5] XML Schema XML Schema Part 0: Primer. W3C Recommendation, 2 May 2001 Viz [6] XSLT XSL Transformations (XSLT) Version 1.1. W3C Working Draft 24 August 2001 Viz 21