Překlady této stránky:

Toto je starší verze dokumentu!


Předávání obsahu datového fondu

Předávání údajů mezi informačními systém veřejné správy (a agendami, které se v systémech vykonávají) se má vždy dít pomocí referenčního rozhraní veřejné správy a systémů, které jej realizují, tedy ISZR a eGSB/ISSS. Pro některé typy výměny však nemusí stačit v současné době definované služby a je nutné spojit dohromady úkony mezi dotčenými systémy a službami referenčního rozhraní. Jedním z těchto příkladů je předávání údajů o subjektech, o kterých požadující systém neví, že existují.

Postup je navržen jako asynchronní, protože se předpokládá, že výběr AIFO ze zdrojové agendy a jejich překlad na AIFO cílové agendy může u stovek tisíc záznamů trvat déle než desítky sekund a synchronní volání by mohlo často končit chybou "timeout".

Obecná pravidla předpokládají následující situaci:

  • ISVS 1 má údaje, které je nutné poskytnout ISVS 2.
  • ISVS 1 i ISVS 2 jsou řádně napojeny na referenční rozhraní a mají ztotožněný datový kmen proti základním registrům.
  • Předávání údajů klasickým dotazováním na jeden subjekt je zde nedostatečné z hlediska kapacity a transakční náročnosti, ale i z důvodu, že ISVS 2 neví, jaké subjekty vede ISVS 1 a nemůže se tedy na ně zeptat.
  1. Webová služba 1 přijme požadavek na předání seznamu AIFO osob dle zadaných výběrových podmínek (definovány správcem ISVS 1 – např. typ víza/dokladu/pobytu, národnost, datumy (od do) kdy byl záznam o dané osobě v ISVS 1 vytvořen, atp). Pro obecnost doporučujeme možnost správy oprávnění na danou kombinaci vstupních podmínek.
  2. Jako odpověď na volání webové služby 1 vrátí ISVS 1 číslo požadavku, které bude možné dále použít jako vstup do webové služby 2 viz dále. Číslo požadavku přiděluje ISVS 1 podle vlastních pravidel, například jednoduché pořadové číslo ve spojité řadě, nebo náhodné číslo doplněné datem a časem volání jako string či jiná schémata
  1. Pro vlastní předávání výsledků (požadovaného seznamu AIFO) ISVS 1 připraví a vystaví webovou službu 2. Jejím voláním v doporučených intervalech (např. 15 minut) původní tazatel ISVS 2 zjišťuje, zda požadavek s konkrétním číslem viz. výše již byl zpracován a může obdržet výsledek. Webová služba 2 tedy k zadanému číslu požadavku vrací následující odpovědi:
    1. požadavek ještě není vyřízen
    2. požadavek je vyřízen, v tom případě je zpět předán seznam (jedné či více) úložek AIFO, což jsou čísla pro volání příslušné funkce ISZR, vracející seznam konkrétních AIFO přeložených pro cílovou agendu. Vrácen je tedy seznam ID úložek AIFO viz dále
    3. požadavek nebyl nalezen, pravděpodobně již splnil podmínky expirace a byl odstraněn
  2. Doporučujeme implementaci standardních procesů pro správu asynchronní fronty (mazaní požadavků po stanovené době, volitelně s ohledem na to, zda již proběhlo volání webové služby 2 a seznam ID úložek AIFO byl předán či naopak neproběhlo a původní žadatel se zapomněl zeptat na výsledek svého původního dotazu atd.)

ISVS 1 vede evidenci (tzv. frontu) požadavků, do které z jedné strany webová služba 1 přidává nové požadavky s nově přidělovanými čísly a z druhé strany jsou ještě nevyřízené požadavky postupně zpracovávány (připravován jejich datový výstup) tak, aby při volání služby č.2 bylo co vrátit a současně po stanovené době bylo možné požadavek vyřadit z evidence jako vyřízený, případně po ještě delší době jako vyřízený ale nikým nepřevzatý.

Postup na straně ISVS 1:

  1. ISVS 1 aplikuje výběrové podmínky z přijatého požadavku na svůj datový kmen. Výsledkem je seznam AIFO osob, které vyhovují výběrové podmínce
  2. ISVS 1 rozdělí vybraná AIFO po 10 000 záznamech, což je doporučená hodnota získaná empiricky pro optimální provoz překladových funkcí ISZR viz dále
  3. Pro každých nejvýše 10 000 záznamů ISVS 1 volá službu ISZR  E175 - iszrUlozMapaAifo.pdf s uvedením ISVS 2 jako příjemce úložky. Výsledkem volání služby je ID úložky AIFO
  4. ISVS 1 shromáždí u každého vyřízeného požadavku všechna získaná ID úložky a čeká na zavolání webové služby 2, aby je předal původnímu zájemci o data
  1. ISVS 2 cyklicky volá na svá čísla požadavků, která obdržel voláním webové služby 1, webovou službu 2, aby se dozvěděl seznam ID úložek AIFO. Na každou takovou úložku následně musí zavolat službu ISZR  E176 - iszrPodejMapaAifo.pdf, výsledkem je obdržený seznam AIFO, přeložený pro cílovou agendu
  2. Zpravidla několika voláními funkce E176 (na každé dodané ID úložky AIFO) ISVS 2 získá celkovou množinu AIFO jako odpověď na svůj původní požadavek. Tuto množinu následně řízeně přidá do datového fondu ISVS 2, typicky jako přírůstek za příslušné období od do. Řízené přidání znamená brát ohled na fakt, že osoba s konkrétním AIFO již v ISVS 2 může existovat a není žádoucí jí mít v evidenci vícenásobně
  3. Pro získání konkrétních údajů k osobám, ke kterým ISVS 2 získalo AIFO a ještě nevede žádné další údaje, slouží standardní služby základních registrů E276_robCtiAifo2.pdf pro ROB a E173 - aiscCtiAifo2.pdf) pro AISC, případně dalších publikací v rámci agendových kontextů v systému eGSB/ISSS - např. řidičská oprávnění vydaná ČR, zdravotnická problematika očkování proti infekčním nemocem atd. Pokud systém ISVS 2 ke konkrétnímu AIFO již nějaké údaje z ROB vede, není vhodné, aby si opakovaně četl výše uvedenými funkcemi data z ROB, protože data se nemění tak často a jednalo by se o nadužívání čtecích funkcí a přetěžování tohoto registru. Pro tento účel jsou určeny funkce ISZR pro tzv. notifikaci o změnách údajů, které automaticky reportují jen ty AIFO u kterých došlo v zadaném období k nějaké změně údaje, čímž k přetěžování ROB nedochází. Detailní popis mechanismu notifikací není předmětem tohoto materiálu.

původní textace

původní textace

Doporučený postup pro konstituční předávání obsahu datového fondu dle omezujících podmínek, v tomto případě z CIS do AIS KŘ za podmínek vízum dočasné ochrany od 24.2.2022.

Postup je navržen jako asynchronní, protože výběr AIFO ze zdrojové agendy a jejich překlad na AIFO cílové agendy může u stovek tisíc záznamů trvat déle než desítky sekund a synchronní volání by mohlo často končit chybou "timeout".

CIS připraví a vystaví webovou službu č.1, která pracuje následovně:

  1. Přijme požadavek na předání seznamu AIFO osob dle zadaných výběrových podmínek (definovány CIS – např. typ víza/dokladu/pobytu, národnost cizince, datumy (od do) kdy byl záznam o dané osobě v CISu vytvořen, atp). Pro obecnost doporučujeme možnost správy oprávnění na danou kombinaci vstupních podmínek (HUMPO může volat nějakou kombinaci, do budoucna jiný AIS třeba jinou kombinaci). V případě časového tlaku je samozřejmě  možné tento požadavek řešit až v další fázi
  2. Jako odpověď na volání uvedené služby č.1 CIS vrátí číslo požadavku, které bude možné dále použít jako vstup do služby č.2 viz dále. Číslo požadavku přiděluje CIS podle vlastních pravidel, například jednoduché pořadové číslo ve spojité řadě, nebo náhodné číslo doplněné datem a časem volání jako string či jiná schémata
  3. Pro vlastní předávání výsledků (požadovaného seznamu AIFO) CIS připraví a vystaví webovou službu č.2. Jejím voláním v doporučených intervalech (např. 15 minut) původní tazatel HUMPO zjišťuje, zda požadavek s konkrétním číslem viz. výše již byl zpracován a může obdržet výsledek. Služba č.2 tedy k zadanému číslu požadavku vrací následující odpovědi:
    1. požadavek ještě není vyřízen
    2. požadavek je vyřízen, v tom případě je zpět předán seznam (jedné či více) úložek AIFO, což jsou čísla pro volání příslušné funkce ISZR, vracející seznam konkrétních AIFO přeložených pro cílovou agendu.  Vrácen je tedy seznam ID úložek AIFO viz dále
    3. požadavek nebyl nalezen, pravděpodobně již splnil podmínky expirace a byl odstraněn
  4. Doporučujeme implementaci standardních procesů pro správu asynchronní fronty (mazaní požadavků po stanovené době, volitelně s ohledem na to, zda již proběhlo volání služby č.2 a seznam ID úložek AIFO byl předán či naopak neproběhlo a původní žadatel se zapomněl zeptat na výsledek svého původního dotazu atd.)

Způsob vyřizování požadavků na straně CIS

CIS vede evidenci (tzv. frontu) požadavků, do které z jedné strany služba č.1 přidává nové požadavky s nově přidělovanými čísly a z druhé strany jsou ještě nevyřízené požadavky postupně zpracovávány (připravován jejich datový výstup) tak, aby při volání služby č.2 bylo co vrátit a současně po stanovené době bylo možné požadavek vyřadit z evidence jako vyřízený, případně po ještě delší době jako vyřízený ale nikým nepřevzatý. Postup na straně CIS:

  1. CIS aplikuje výběrové podmínky z přijatého požadavku na svůj datový kmen. Výsledkem je seznam AIFO osob, které vyhovují výběrové podmínce
  2. CIS rozdělí vybraná AIFO po 10 000 záznamech, což je doporučená hodnota získaná empiricky pro optimální provoz překladových funkcí ISZR viz. dále
  3. Pro každých nejvýše 10 000 záznamů CIS volá službu ISZR  E175 - iszrUlozMapaAifo.pdf s uvedením AIS HUMPO jako příjemce úložky. Výsledkem volání služby je ID úložky AIFO
  4. CIS shromáždí u každého vyřízeného požadavku všechna získaná ID úložky a čeká na zavolání služby č.2, aby je předal původnímu zájemci o data

Vyřízení odpovědi na straně HUMPO

  1. Systém HUMPO cyklicky volá na svá čísla požadavků, která obdržel voláním služby č.1, službu č.2, aby se dozvěděl seznam ID úložek AIFO. Na každou takovou úložku následně musí zavolat službu ISZR  E176 - iszrPodejMapaAifo.pdf, výsledkem je obdržený seznam AIFO, přeložený pro cílovou agendu, zde konkrétně A338 Krizové řízení
  2. Zpravidla několika voláními funkce E176 (na každé dodané ID úložky AIFO) HUMPO získá celkovou množinu AIFO jako odpověď na svůj původní požadavek. Tuto množinu následně řízeně přidá do datového fondu HUMPO, typicky jako přírůstek za příslušné období od do. Řízené přidání znamená brát ohled na fakt, že osoba s konkrétním AIFO již v HUMPO může existovat, díky předchzímu požadavku dané osoby na ubytování, a není žádoucí jí mít v evidenci vícenásobně
  3. Pro získání konkrétních údajů k osobám, ke kterým HUMPO získalo AIFO a ještě nevede žádné další údaje, slouží standardní služby základních registrů E276_robCtiAifo2.pdf pro ROB a E173 - aiscCtiAifo2.pdf) pro CIS, případně dalších publikací v rámci agendových kontextů v systému ISSS (původní název eGSB) - např. řidičská oprávnění vydaná ČR, zdravotnická problematika očkování proti infekčním nemocem atd. Pokud systém HUMPO ke konkrétnímu AIFO již nějaké údaje z ROB vede, není vhodné, aby si opakovaně četl výše uvedenými funkcemi data z ROB, protože data se nemění tak často a jednalo by se o nadužívání čtecích funkcí a přetěžování tohoto registru. Pro tento účel jsou určeny funkce ISZR pro tzv. notifikaci o změnách údajů, které automaticky reportují jen ty AIFO u kterých došlo v zadaném období k nějaké změně údaje, čímž k přetěžování ROB nedochází. Detailní popis mechanismu notifikací není předmětem tohoto materiálu.
Vložte svůj komentář: