…vcera sme poslali pripomienky k SU ku API GW SU API Managment pripomienkovaci harok.xlsx (16.8 KB) …vela pripomienok sa vyriesilo v procese vzniku SU, ale radi by sme v SU videli detail, ktory je pokryty pripomienkami…
…plus sme UPVII poskytli navrh pilotnych sluzieb UPVS do API GW Sluzby UPVS_navrh pilotnych sluzieb.docx (7.4 KB)
a reakciu na opodstatnenost/neopodstatnenost navrhovanych sluzieb ITMS2014+ ITMS2014 _OpenAPI.xlsx (11.1 KB) …
UPVII vcera vecer publikoval novu verziu studie, CBA a pod. na MetaIS https://metais.finance.gov.sk/studia/detail/ed6146af-477e-0052-d178-cc75c5dd7876?tab=documents
z dnesnej verejnej prezentacie vyplynulo, ze UPVII ma cas maximalne do konca buduceho tyzdna (1.2.2019) na doladenie studie, vysporiadanie pripomienok, ak chce stihnut termin riadiaceho vyboru vo februari
Slovensko.Digital bude s riesitelom studie/UPVII sediet este tento tyzden, asi piatok a potom aj buduci tyzden, asi stredu
30.1. sme boli s @peter_k v NASES ohladom API GW studie a sluzieb UPVS ktore by bolo dobre vystavit smerom von.
Kratky zapis v odrazkach:
prikladam prezentaciu k OpenAPI, ktoru sme prezentovali na podujati Samosprava pre ludi II OpenAPI_samospráva.pptx (886.6 KB)
Pre transparentnost. NASES sme zaslali navrh na vytvorenie sluzieb, ktore podla nas zacinaju extremne chybat.
V skratke: Ak je naintegrovany na schranku jeden IS, uz ziadny iny system tam NASES nepusti. Toto zacina byt velky problem, kedze to ticho predpoklada, ze napr pre obce/po bude existovat jeden “vseobjimajuci” system, ktory asi zabezpeci uplne vsetky agendy (od ekonomickej - chodia tam spravy o zrazkach na mzdy, cez registraturu, specializovane domenove softvery…). Dovod preco NASES toto nepovoluje povazujem za dizajnovu chybu API. Neexistuje sposob, ako bez manipulacie so spravami v schranke (presuvanie sprav po priecinkoch) ziskat “nove” spravy. Ak by tam takto pristupovali dva systemy naraz, pobiju sa (co sa podla vyjadrenia NASES uz stalo)
Neviem mne sa to zda spravne. Ze schranku riesi iba jeden system. Ktory by mal zabezpecit stahovanie vsetkych sprav a posielanie. A systemy v organizacii nech ih je kolkokolvek si potrebne spravy preberali, resp. davali na odoslanie na jedno miesto. Sice v zakone bolo uvedene ze schranka sluzi na uchovavanie sprav ale v praxi je to len dorucovaci system, preto by nebolo podla mna vhodne aby do nej chodilo viac systemov.
Problemom je iba to ze dodavatel intgracneho riesenia sa postara iba o svoje IS. Jeho povinnostou by malo byt ze ak uz on ako jediny ma pristup do schranky tak dole v organizacii musi poskytnut rozhranie pre prevzatie si sprav do roznych IS a taktiez zabezpecit odoslanie sprav ktore ostatne IS mu daju na odoslanie, ale do schranky by podla mna mal chodit iba jeden co zaisti ze vsetko stiahne do rogranizacie a opacne zaisti odoslanie vstkeho co organizacia vyprodukuje.
Jeto iba dorucovaci system, takze neni treba aby sa do schranky pripajali viacere systemy, To iste sa da zabezpecit po stiahnuti resp. pred odoslanim sprav v samotnej organizacii.
Ano robi nam problemy ze niekam prideme napr. s registratirou a oni uz su integrovani a my musime toho kto im urobil integraciu pekne poprosit aby aj nas system sa vedel k spravam dostat resp. odoslat. Ale to by sa dalo vyriesit po podobnym systemom ako ma Ditek ze spravy su stiahnute na jedno miesto, kde si ich kto potrebuje potom rozoberie, pricom vsetko icde do registratury takze aj zakon sa dodrzi a podobne je to aj s odoslanim ze systemy daju vyprodukovane spravy na urcene miesto odkial si ic h system prevezme a odosle. Ten system je univerzalny a nerobi problemy inym dodavatelom.
Tento problem risit povolenim manipulacie viacerym systemom so schrankou by asi nebolo tym pravym riesenim.
Nesuhlasim. S nastupom OpenAPI budu specializovane softvery, ktore budu v klude aj jednorazove a urcite budu potrebovat pristupit aj do schranky (kedze tam su vsetky relevantne odpovede na podanie napriklad). Urcite nebudem pekne prosit nejake ditecy, aby som si potom cez ich proprietarne API nieco stahoval. Kolko takychto softverov bude? Budu mat rovnake API? Ked sa zmeni dodavatel “hore”, tak budem zase pekne prosit niekoho ineho?
Technicky nie je vobec ziadny problem spravit API tak, aby tam mohlo pristupovat hocikolko technickych uctov. Dokonca aj keby tam nebolo viac systemov, tak API co navrhujeme je ovela jednoduchsie z pohladu integracie aj pre konzumentov.
Iny priklad: Chcem ist do schranky cez GUI (slovensko.sk) a zaroven mam nejaky system co mi trebars riesi automaticku agendu (ekonomicky sw - zrazky zo mzdy). Toto dnes nemozem. Je to povazovane tiez za dualny pristup a NASES to vyslovene zakazuje.
Tam prave nie je ziaden problem lebo to neni o formate on stiahne do jedneho adresara vsettky SKTalk spravy a systemy v organizacii si to potom rozoberu na jednom mieste.
Keby toto urobil kazdy dodavatel integracie tak neni problem.
Ked pustis do shranky viacero systemov jeden vymaze alebo rprlozi spravu niekam a pod. Ale uloha schranky ako takej skoncila ked do nej sprava prisla a bola stiahnuta, Ak by to bol evidencny system alebo system uchovavania sprav tak ano potom by bolo potrebne do neho riesit viacnasobny pristup.
Ano mas pravdu my tento pristup sme na zaciatku pouzivali na riesenie a hladanie problemov, dnes uz je to iba vynimocne, napriek zakazu ina cesta neexistovala lebo pri stahovani velkeho mnozstva sprav a ih prekladani do inej zlozky sa to zo zaciatku nefungovalo ako malo.
Ale z hladiska hromadneho spracovania sprav je idealne vsetko stahovat na jedno miesto v stanovenych intervaloch a aplikacie tretich stran nech si tam beru co potrebuju.
Ano z pohladu ak im chce este niekto dalsi z vonku ponuknut nejaku sluzbu tak ten ma problem sa k jeho spravam dostat.
Aha uz rozumiem.
No to je prave ten pohlad na schranku, sice ona v zakone je ako ulozisko sprav. Ale ona nikdy nebola riesena v zmysle uschova -retention, preservation. Takze sa neda ratat ze tam su vsetky relevantne odpovede. Pokial by bola schranka designovana ako ozajstna uschova v zmysle prislusnych technickych noriem ano potom by bol ako jeden z jej parametrov ze obsahuje vsetky relevantne informacie. Teraz to tak nie je uz z principu ze mas obmedzenu kapacitu a nases moze odmazavat stare spravy takze uz len toto je nieco co robi ustanovenie v zakone ze schranka je akesi ulozisko sprav nepravdivym. Schranka len predňbera a odosiela alebo dorucuje, neuchovava, to ze tam spravy zostavaju aj lpo stiahnuti je len na voli toho kto do nej pristupuje, jeden system precita a zmaze a druhy uz s tou informaciou nemoze ratat a spoliehat sa ze napr. neprisla (ked ona medzicasom mohla prist a iny system ju stiahol a zmazal)
Toto naopak problem je a velky.
Nie je to idealne a ani dobre.
To ani nebolo myslene, ze tam tie udaje na veky vekov najdem, ale skor v zmysle “ze tam pridu”. Samozrejme v klude dajme tvrdu retenciu (ta tam inak uz je).
Inak vsetko toto je v tom dokumente hore tiez spomenute.
To jedno miesto myslim server vo vnutri organizacie toho komu postu stiahli. Cize jeden to stiahne do organizacie a da k dispozicii vsetkym aplikaciam.
Jeden integrator naintegruje organizaciu na UPVS jeho povinnostou by malo byt stiahnut postu “na jedno miesto”, adresar, databaza a pod. A toto miesto dat k dispozicii vsetkym aplikaciam v organizacii ktore spravy potrebuju.
To je dobre iba tam kde mas napr. jednotky alebo desiatky sprav ale ak by si notifikoval system alebo uzivatela s kazdou spravou dorucenou v pripade ak mu chodia napr stovky a sprav tak ho zaspamujem.
Prave z tohoto dovodu je dobre vsetky spravy postupne stahovat do jedneho miesta u uzivatela (adresar, databaza) a az nad tymto miestom robit tie operacie o ktorych hovoris. Lebo tam su skutocne vsetky spravy. Neni su okamzite ale s casovym posunom o dobu, intervalu stahovania sprav. A nad takouto databazou sprav sa daju robit operacie lubovolne, len problemom je ze ten co integroval ju musi spristupnit aj ostatnym aplikaciam v organizacii.
Ale nechcem ta presviedcat. Lebo ty mas asi tu potrebu ze chces ako dalisa strana niekomu poskytnut nejaku funkcnost tak ze sa mu pozries do schranky najdes tam to co potrebujes a spracujes.
A ak uz niekto je naintegrovany na tuto schranku ano uz ta tam nepustia. Ano je taka skupina zakaznikov co nechce do schranky chodit a ked mu to postahujeme tak je rad a ak mu nad tym ponukneme niejake sluzby ttak bude spokojny.
Ja skorej sa na to divam z pohladu tej organizacie ktorej schranku stahujeme. Ze ked ju jeden dodavatel stiahne tak nech si uz nemusim objednavat u neho vyvojarske kapacity, lebo potrebujem napojit na schranku ekonmicky system ineho vyrobcu, za pol roka inu aplikaciu a zakazdym musim kontaktovat dodavatela stahovadla, lebo to ma urobene pre seba. Tieto spravy co stiahne alebo bude odosielat musi dat k dispozicii kazdej aplikacii v tej organizacii. Na to sa zabuda a potom to ide do penazi.
Ak si otvoris ten dokument, tak aj toto je tam riesene. 
Lenze toto ma vyriesit open api. Priklad: Vznikne cloudovy softver co za teba vybavi trebars nejake jednorazove podanie. Budes kvoli tomuto robit integracie na vsetky mozne softvery, ich uloziska? Ako bude vyzerat flow pre koncoveho zakaznika? Kliknem, ze chcem podat to podanie a? Spyta sa ma u koho mam “ulozisko” vyberiem si z dnes uz desiatok moznosti? Kolko bude trvat kym mi tam regnu pristup? Budem musiet mat so vsetkymi zmluvu? …
Ved to je blbost. Alternativa je totiz zrejma, dovolim ti pristup do schranky na citanie a nie manipulaciu so spravami. To, ze tam mas iny softver, ktory ti tie spravy strci aj do registratury/archivu (lebo tak treba) mna ako dodavatela softveru pre uzko specializovanu vec absolutne netrapi. A naopak, ani dodavatela registratury netrapi, ze tam niekto bude robit podania pomimo, lebo bude vediet, ze cokolvek sa posle, tak to v schranke uvidi aj on.
Jasne chapem hovorime o dvoch rozlicnych typoch klienta…