OpenAPI / Otvorené API - plánované a realizované aktivity Slovensko.Digital

Na toto by mala sluzit GetEdeskInfo2 sluzba na UPVS. Ale predpokladam, ze na nejaky velmi rychly autocomplete alebo tak mozeme zabudnut. Tuto sluzbu by mozno stalo za to vystavit von cez open api tiez.

1 Like

A post was split to a new topic: Voľné pracovné miesta ako Open Data

Prikladam reakciu UPVII na koncepcne pripomienky S.D k SU SD_Koncepcne pripomienky_API GW_Odpoved_v04.docx (22.1 KB)

Nasledne sme 18.12.2018 mali osobne stretnutie, kde sme si presli za kazdu stranu vnimanie API GW, jeho casti/modulov a ich priority a moznosti nakupu/implementacie, otvoreni urcitych tem v pracovnych skupinach, atd. Zaroven sme za S.D prislubili, ze v prvom januarovom tyzdni posleme dalsiu reackiu na SU. UPVII sa zaviazal poskytnut aktualnu verziu SU.

1 Like

V zmysle dohody s UPVII nam bola poskytnuta nova verzia SU k API GW SU OPII API_GW_v1.4.docx (950 KB) co ocenujeme a sme radi, ze sa vedie dialog s vybranym externym prostredim pocas vzniku SU.

Cez vikend sme v zmsle dohody s UPVII zaslali nase agregovane najdolezitejsie pripomienky Pripomienky_API GW.rtf (523.7 KB) Pripomienky vychadzali z jednotlivych komentov a postrehov priamo v ramci novej verzie SU SU OPII API_GW_v1.4_pripo SD.docx (1.2 MB) Aj tuto SU s pripomienkami sme poskytli UPVII, aby malo k dispozicii kompletnu reakciu S.D s menej dolezitymi pripomeinkami, podla nasho nazoru idenzifikovanymi nepresnostami, a pod.

CBA sme nepripomienkovali, nakolko len v piatok 4.1.2019 sme ziskali jej novsiu verziu. Zaroven sme poziadali UPVII o info, ze ci ide o verziu, ktora je uz odobrena UHP a pod., aby sme zbytocne nepalili kapacity. Na zaklade nasich pripomienok by sme radi videli videli CBA, ktore by porovnavala viacero aletarnativ sucasne…tieto zavery si myslim su jasne z dokumentu Pripomienky_API GW

UPVII sme pripomenuli, ze by bolo vhodne zvolat PS, aby sa v ramci nej prerokovali poziadavky:

  • monetizacie otvorenych API,
  • poskytovania API GW ako PaaS,

ktore sa objavuju v SU a myslime si, ze su hodne sirsej debaty a deklarovania realnych poziadaviek.

K pripomienkam sme sa snazili pristupit konstruktivne a aby sme podporili vahu alternativy budovania riesenia nad existujucimi produktami na trhu, tak @jsuchal oslovil vyrobcov produktov Kong a Tyk a ziskal od nich cenove ponuky, ktore sme zahrnuli do pripomienok (velke dik Jano). Vyrobcovia pre dalsi dialog by uz radi hovorili so statom/relevantnym subjektom ku konkretnym cenovym ponukam, zlavam a pod.

p.s. @ITAS mohlo by vas zaujimat

…len pre info…zistujeme ceny produktov na trhu vhodnych pre riesenie API GW…aktualne mame cenove ponuky na Kong, Tyk (tieto su zahrnute v dokumente Pripomienky_API GW a teda boli distribuovane aj UPVII)…cakame na cenovu ponuku este k produktu APIgee…

…k studii uskutocnitelnosti k API GW UPVII vyhlasilo oficialne pripomienkove konanie…tu je par dolezitych info:

ÚPVII - Centrálna API manažment platforma (API GateWay)

Web:

https://www.vicepremier.gov.sk/aktuality/informatizacia/oznam-verejne-pripomienkovanie-studie-uskutocnitelnosti-centralna-api-manazment-platforma/index.html

MetaIS dokumenty:

https://metais.finance.gov.sk/studia/detail/ed6146af-477e-0052-d178-cc75c5dd7876?tab=documents

Termín na pripomienky: 21.1.2019 do 16:00

Emailový kontakt na pripomienky: jan.backo@vicepremier.gov.sk

Termín verejného prerokovania štúdie: 23. januára 2019 o 13:00 hod. v priestoroch Úradu podpredsedu vlády SR pre investície a informatizáciu, Westend, Dúbravská cesta 4, 9. poschodie

Termín nahlásenia účasti na prerokovaní: 21.1.2019 do 16:00

Emailový kontakt na nahlásene účasti: pozvanky@vicepremier.gov.sk

…mam info, ze dnes, zajtra by mohla byt publikovana aj novsia verzia studie na MetaIS…

…vcera vecer nam UPVII poskytlo najnovsiu verziu studie SU OPII API_GW_v1.10.docx (1.2 MB)
a CBA CBA_OPEN_API_Variant_80-20 - Agendove IS 0.13.xlsx (400.8 KB) …predpokladam, ze dnes by sa tie dokumenty mali obajvit aj na MetaIS https://metais.finance.gov.sk/studia/detail/ed6146af-477e-0052-d178-cc75c5dd7876?tab=documents ale pre kratkost casu na pripomienky do pondelka, to davam sem na platformu uz teraz…

…pre inspiraciu a pochopenie nasho pohladu prikladam aj nase pripomienky a vyjadrenie k nim zo strany UPVII, ktore sme tiez dostali vcera vecer a dnes sa snimi budeme zaoberat PRIPOMIENKOVACI FORMULAR_v03_SD.xlsx (25.9 KB)
SU OPII API_GW_v1.4_pripo SD_Vyjadrenie.docx (1.2 MB)

2 Likes

…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:

  • IAM modul momentalne ma role, splnomocnenia, zastupovania, taraz do tohto prichadzaju este scopes (oauth2). dlha diskusia o tom ako to upratat a ci sa to da.
  • z nasho pohladu by bolo ziaduce, aby sa dali splnomocnenia evidovat niekde centralne, je to bezna poziadavka zo stran OVM. (napr. FS riesi splnomocnenia pre uctovnikov, vszp podobne…) zda sa, ze centralne to ma zmysel aj preto, aby to end-user videl na jednom mieste. logicke miesto je IAM.
  • prechadzali sme jednotlive sluzby UPVS. Ako kriticke vidime pokrytie end-to-end scenara na podania aj s moznostou vidiet odpovede (ale len tie ktore sa tykali daneho podania). ak by sa daval pausalne pristup do schranky tretim stranam je tam velky problem s GDPR (nutnost ohlasovat vsetkym zakaznikom, ze spracovavatelom osobnych udajov je nejaka dalsia tretia strana - realne sme tento problem zazili)
  • nie je zrejme z coho sa budu financovat zmeny sluzieb, ktore su potrebne. pravdepodobne to v budgete centralne API GW nie je, MUK-P nevieme…
  • konstruktor sprav na slovensko.sk by mal podporovat jednoduchy POST na zobrazenie predvyplnenej ziadosti. Toto by sa mohlo rozsirit na podanie-ako-sluzba na strane slovensko.sk
1 Like

prikladam prezentaciu k OpenAPI, ktoru sme prezentovali na podujati Samosprava pre ludi II OpenAPI_samospráva.pptx (886.6 KB)

1 Like

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)

Návrh na nové integračné rozhrania UPVS (1).odt (22.1 KB)

1 Like

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.

1 Like

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.

  1. Ako sa na to “jedno miesto” dostanem? Kde aky kluc musim zaregistrovat? Kolko to bude trvat? Maju to vsetci dodavatelia rovnako (ani omylom)
  2. Ako zistim, ze kto tam pristup ma? Toto uz dnes je problem. NASES sa k tomu stavia asi takto “ved statutar musi vediet, co podpisal”. Formalne pravda, realisticky netusi a nema preco nejaky starosta vediet ako sa technicky do schranky chodi, ci to je na org. zlozku alebo ako to funguje.

Nie je to idealne a ani dobre.

  1. Idealne by bolo mat webhook ktory da IS vediet, ked tam nejaka sprava pride. Nebudu sa potom stavat take veci, ze “pristup do schranky, najdi dorucenku, posli zakaznikovi, zakaznik preberie, pocka dve hodiny aby sw mohol podla pravidiel pristupit do schranky znova”. Planovana “synchronna dorucenka” riesi len podmnozinu tohto problemu.
  2. Preco by to “jedno miesto” nemala byt prave schranka? Ako mam zabezpecit SLA, ked “nado mnou” bude nejake diteky, ktore maju ktovieaku SLA. Zakaznik bude volat mne, ja nechcem toto riesit s niekym, kto sedi na datach. Plus mi tu krici riziko vendor locku.

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. :smiley:

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…

1 Like