Mam tu nejake resty takze podme na to:
To najdolezitejsie najprv - mame dokument k multikanalovemu pristupu. Treba spisat pripomienky do 4.1. K9.5 - Pripomienkovanie Strategická priorita Multikanálový prístup
Stretnutie 15.12.2017
- multikanal - dovod je, ze EU nas nuti transparentne informovat obcana o stave vybavenia podani
Integracia a Orchestracia
-
diskusia - synchronna vs asynchronna komunikacia - striktne synchronna integracia moze mat problem v peakoch
-
co maju byt klucove standardy? spravit analyzu
-
otazka ci - byrokracia nie je vacsi problem ako nedodrzane standardy
-
kto bude mat zodpovednost a kompetenciu za ZS - kto bude mat bic na rezorty aby bola sucinnost?
-
ak niekto vie, ze jeho sluzba bude potrebna, vie vydierat
-
standardy boli vyprodukovane neskoro - az po implementacii - vznikali problemy
-
diskusia
- datova integracia - operativne datove ulozisko a vedla toho dwh.
- centralizacia - sanca odlahcit od zbytocnych orchestracii
-
MUK
- historia - nemali by fungovat len cez schranky
- datova cast - synchronizacia do inych systemov (toto bol povodny zamer), povodne to bolo chapanie ako rura nie ako storage
- diskusia k SIFO - poskytnut data mimo rezortu, ktory ich ma na starosti je problem
-
EVS - potrebujeme vstupy od nich
- mozno nejake veci budu uplne inak (napriklad riesenie poplatkov)
- jedna cesta asi nebude nikdy spravna
-
webapi gateway nad tym vsetkym
-
diskusia - ak padne ESB co potom? = “centralny vypinac egovu”
Za ulohu sme dostali doniest k OPEN API poziadavku na integraciu.
Stretnutie 20.12.2017
- velmi dlha (a podla mna zbytocna) diskusia k aktualnemu stavu MUK (komunikacna, pristupova, datova, datova2)
- bolo povedane, ze IS CSRU je dnes akasi platforma datovej integracie az na to, ze tam treba dalsie veci dorobit.
- opat otazka k ZS - kto bude gestorom, ake bude mat paky na gestorov roznych potrebnych sluzieb, aby ho nesabotovali/nevydierali ale spolupracovali.
- linked data - bol navrh aby boli datove prvky a sluzby popisane cez linked data na urovni schemy. k tomuto neboli namietky.
- k open api
- upozornil som, ze pokial budu rozne zbernice pre externy a interny svet, tak moze nastat podobna situacia ako v open data (register adries na data.gov.sk nefungoval mesiace a nikoho to velmi netrapilo). idealna by bolo zjednotit zbernica/gateway pre interny a externy svet (nie nutne na urovni 1 centralny projekt). na urovni web api gateway taky plan je.
- povedal som zakladnu predstavu toho ako si to predstavujeme. nejde o nejaku extra novu vec. schranky dnes tak podobne funguju. viete dat niekomu splnomocnenie, aby tam pristupoval za vas.
- potrebujeme z pohladu integracie:
- umoznit jednoducho dat splnomocnenie tretej strane.
- umoznit pristup k api v zastupeni. aj offline
- umoznit pristip tretim stranam k api ktore reaguju callbackom - napr. zmena trvaleho bydliska (vyleti domenovy event niekde na zbernicu, a tretia strana to bude vediet odchytit - napriklad banka)
- bola vznesena namietka, ze ked sa centralne budu uchovavat nastavenia o permissions tak to bude vela dat a zataz. z nasho pohladu to nie je problem, komercia takto funguje na vacsej skale.
- bola vznesena namietka, ze toto by sa malo diat na klientovi a ten by mal toto posielat kam treba. z nasho pohladu nie, ten domenovy event moze vyletiet aj bez interkacie s pouzivatelom (napr. periodicke eventy resp. naviazane na cas) a podruhe, nesmie sa stat, aby znalost o x dalsich systemoch, ktore mozu pocuvat bola v agendovy systemoch. toto je dratovanie. (bolo to spomenute z viacerych stran)
Ako ulohu sme dostali zaslat poziadavky k open api veducemu PS na email.