| Poslední revizeObě strany příští revize |
| znalostni_baze:predavani_datoveho_fondu [2022/04/26 15:58] – vytvořeno Tomáš Šedivec | znalostni_baze:predavani_datoveho_fondu [2022/04/26 16:00] – Tomáš Šedivec |
|---|
| 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". | 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ě:==== | CIS připraví a vystaví webovou službu č.1, která pracuje následovně: |
| |
| |
| -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 | -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 |
| -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 | -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 |
| -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: | -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: |
| -požadavek ještě není vyřízen | -požadavek ještě není vyřízen |
| -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 | -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 |
| |
| |
| ====Způsob vyřizování požadavků na straně CIS==== | 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: | 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: |
| |
| |
| ====Vyřízení odpovědi na straně HUMPO==== | Vyřízení odpovědi na straně HUMPO |
| | |
| -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 [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E176_iszrPodejMapaAifo.pdf|E176 - iszrPodejMapaAifo.pdf]], výsledkem je obdržený seznam AIFO, přeložený pro cílovou agendu, zde konkrétně A338 Krizové řízení | -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 [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E176_iszrPodejMapaAifo.pdf|E176 - iszrPodejMapaAifo.pdf]], výsledkem je obdržený seznam AIFO, přeložený pro cílovou agendu, zde konkrétně A338 Krizové řízení |
| -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ě | -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ě |
| -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ů [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E276_robCtiAifo2_1_00_v1_r0.pdf|E276_robCtiAifo2.pdf]] pro ROB a [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E173_aiscCtiAifo2.pdf|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. | -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ů [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E276_robCtiAifo2_1_00_v1_r0.pdf|E276_robCtiAifo2.pdf]] pro ROB a [[https://www.szrcr.cz/images/dokumenty/v%C3%BDvoj%C3%A1%C5%99i/detailn%C3%AD_popisy_eGon_slu%C5%BEeb/SZR_popis_eGON_sluz%CC%8Ceb_E173_aiscCtiAifo2.pdf|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. |
| |
| </hidden> | </hidden> |