MIRRI Pracovná podskupina - API GW/API Manažment

Pracovné skupiny
1

Na UPVII znikla pracovna podskupina k API GW, nominovali sme @jsuchal a @peter_k za Slovensko.Digital.

Tu budeme informovat o diani.

2

Posielam materialy, ktore sa prezentovali na minulom stretnuti.

sluzbyUPVS.pdf (368.2 KB)

PSLepsieSluzbyAArchi2019.pdf (2.6 MB)

201904 PS sluzbyINTEGRACNE.xlsx (59.4 KB)

20190328_Zaznam z PS Lepsie sluzby.doc (68.5 KB)

Este pridavam za SD nasu prezentaciu. PS Lepšie služby (1).pdf (62.4 KB)

Navrhli sme, ze end-to-end scenar ako maju pridelenia upravneni z pohladu koncoveho pouzivatela vypracujeme my, kedze tam uz mame dost jasnu predstavu.

Z prezentovanych sluzieb som upozornil na to, ze vypublikovane sluzby by sa mali riesit podla dopytu a nie len podla pocetnosti. Je klucove, aby sluzby, ktore sa budu publikovat mali odberatelov/konzumentov a nerobilo sa API len na to co ma najvacsiu pocetnost. Toto sa tykalo najma planovanych API rozhrani projektu ITMS2014+, ale plati to vseobecne. Podobne ako pri open data mame prioritne datasety, tak tu by mal vzniknut backlog prioritnych API. Taketo nieco sa uz zbieralo viac krat, napriklad v ramci OGP. Staci to teda zobrat.

3

Dobrý deň,

dovoľte mi pozvať vás na stretnutie podskupiny API Manažment.

Ohľadom tém zatiaľ by som rád riešil:

Úpravy dokumentu Pravidlá publikovania služieb

Oprávnenie tretích strán pristupovať na API a konať v mene občana - proces a ISVS

Ak máte ďalšie témy, ktoré by ste chceli prediskutovať na stretnutí, prosím o ich nahlásenie.

Stretnutie je planovane na Jun 6, 2019 10:00 – 12:00

4

Za nas sme navrhli toto

  • monetizacia a API GW ako PaaS
  • zavislosti projektu API GW na inych projektoch (napr. MOU), aby bol podporeny end-to-end scenar
  • priebezne informovanie a odpocet harmonogramu zo strany Nases o progrese na pilote API GW
  • identifikacia pozadovanych API, ich prioritizacia, komunikacia s externym prostredim,
  • riesenie technickych problemov, otazok OVM k open API
  • priprava dopytovych vyziev pre publikovanie API, vytvaranie novych otvorenych API
  • komplexna roadmapa s aktivitami, zodpovednostami a terminmi
5

…strucny zapis zo zasadnutia podskupiny dna 6.6.2019, pripadne ma doplni @jsuchal :

Zapis:

  • malo ucastnikov

Organizacne zalezitosti:

  • periodicita zatial kazde 2 tyzdne, kym budu temy

Obsahova stranka stretnutia:

  • do 305ky isla povinnost publikovania sluzieb ako OpenAPI - 07/2020 pre nove sluzby a do 2022 ostatne existujuce sluzby
  • za S.D sa budeme podielat na e2e scenari pre pouzitie OpenAPI
  • za S.D sa budeme podielat na identifikacii pozadovanych API - zapojime clenov Kros, Stormware, HOUR v danovo-odvodovej domene
  • bola poskytnuta info, ze sa aktualizoval dokument Pravidla publikovania sluzieb do multikanaloveho prostredia o nove error kody vo vzthau k API GW
  • Monetizaciu a PaaS sme otvorili ako temy na PS prostrednictvom strucnych prezentacii - UPVII pripravi priklady zo zahranicia k monetizacii + Nases ma nejake skusenosti/aktivity v oblastmi monetizacie, tak on by mal predstavit ich modely/uvahy
  • Nases pripravil prezentaciu MUK-P ako prototypu pre API GW - prezentovane info boli high level a vznikli otazky ku scope - PS nema jasnu info o MUK-P - Nases pripravi detailnejsiu informaciu na dalsie stretnutie

Dalsie zasadnutie:

  • 20 juna 2019 dalsie zasadnutie - temy - e2e scenar (S.D), detailnejsie info o MUK-P (Nases)
6

Ja doplnim, ze ma pomerne prekvapila info, ze projekt MUK-P ma byt hlavne “platforma” na spristupnenie sluzieb a sluzby UPVS sa maju publikovat az ako posledna vec. Neriesi sa udelovanie/manazment opravneni, neriesi sa vlastne nic podstatne. Neviem kolko to bude stat (rozpravaju sa off record rozne 6 ciferne sumy), ale pride mi to zufalo malo na to, ze by vlastne len niekto mohol zobrat nas opensource komponent a dodrotovat tam dalsie UPVS sluzby a oficialne ho rozbehnut.

Ja som toho nazoru, ze sluzbami treba zacat, oslovit co najviac stakeholderov a riesi kriticke veci potrebne veci pre e2e scenar a vypublikovat tam prioritne API.

2 Likes
7

len pre update…zasadnutie minuly tyzden nebolo a bolo zo strany UPVII posunute na tento tyzden, t.j. na 27.6.2019…program stretnutia sa nemeni (teda aspon zatial nemame ine info)

8

Dna 27.6.2019 bolo dalsie zasadnutie podskupiny.

Ucast:

  • 1x zastupca UPVII,
  • 3x zastupca Nases
  • 2x zastupca S.D
  • 1x zastupca DEUS

Predmetom stretnutia bola:

9

Dodam zopar detailov za nas:

Vidime ako dolezite brat cely end2end proces. Od udelenia opravnenia az po podanie. Vidime tam dva scenare: 1) clovek autorizuje ukony sam za seba, pouziva pri tom nejaku aplikaciu (mobilnu, krabicovu ci cloudovu) 2) clovek splnomocni tretiu stranu a ta ukon autorizuje za neho.

Z da sa, ze MUK-P bude do istej (velkej) miery pokryvat prvy scenar. Druhy scenar sa zda, ze zahrna register splnomocneni, ktory je na MV, ale vlastne nikto poriadne nevie co s nim bude (vraj sa pouziva len interne - lol).

Co vidime ako riziko je, ze odrazu z MUK-P nie je pilot (ako sa tvrdilo pri studii), ale uz nejake jadro a mame velke obavy, ze si sucasny dodavatel betonuje pozicie vo viacerych projektoch. Opatovne chcem upozornit, ze o com sa tu uz niekolko stretnuti rozpravame a riesime siahodlhe debaty, je nieco co sa da kupit v Amazone/Azure ako sluzba za “pat korun” na milion requestov alebo opensource/free projekty zadarmo (plus samozrejme udrzba). Tuto sa nieco zase stava na zelenej luke, lebo … drzte si klobuky … dodavatel (!) sa boji vendor locku.

Napriek vsetkemu vyzera, ze ked sa podari splni plan tak Q4 alebo Q1’20 by mali nejake API byt vonku. Dolezite je teraz podchytit producentov prioritnych API, aby to stalo za to.

1 Like
10

doplnena prezentacia Nases k MUK-P k casti autentifikacie a autorizacie opravneni

11

v septembri by malo byt zasadnutie PS…poslal som tieto temy, ktore by sa mohli v dohaldnej dobe riesit:

oosbne by som navrhoval, aby sme sa vratili a pokusili sa uzavriet temy, ktore boli rozdiskutovane alebo na ne nezostal priestor. Plus prikladam aj ine temy, ktore ma napadaju a mozu byt predmetom dalsich stretnuti:

  • Register splnomocneni

  • vratil by som sa k monetizacii a PaaS - pri monetizacii bola uloha na UPVII, ze sa pokusi najst modely, pripadne inspiracia od Nasesu

  • vratil by som sa k MUK-P, ktore bolo naposledy prezentovane - ostali tam otvorene body, napr. za mna nepovazujem koncept centralizovanych roli (advokat, lekar, a pod.) za uzavrety

  • bolo by fajn pocut aktualny stav MUK-P po lete - ci je nejak zmena v harmonograme, scope a pod.

  • pre OVM bude potrebne pripravit vyklad zakona a teda ake povinnosti ich cakaju a kedy

  • bude sa pripravovat dopytova vyzva - v inych PS boli tieto vyzvy diskutovane (opravnene aktivity, ukazovatele a pod.)

  • zoznam prioritnych OpenAPI

1 Like
12

plus

To je zial konzistentne s tym, ako vnimam MUK ja. MUK s tym ci inym nazvom je tu uz dlhe dlhe roky a vzdy som mal z dostunych informacii rovnaky zaver ako vyssie spomenute dva citaty.

13

Evidujem u samosprav zaujem o integraciu na CUET. Aktualne je “integracia” na CUET (asi iba) cez el. schranku, t.j. obec/mesto si napr. VZN-ko najprv 1) nahodi na svoj web a potom 2) posle cez el. schranku na CUET. Ergo zle to skaluje uz aj pri malych obciach, plus to ma rizika “reace conditions” (kedze zakon kaze oboje “v ten isty den” ale el. schranky uz par krat vypadli aj na viac nez hodiny a … NASES sa neponahla s preberanim pravnej zodpovednosti, cize co s tym potom obec/mesto, ked sa el. schranka oneskori?).

Potom by asi urcite poniektori (opat v samosprave, ale asi aj obcania ci firmy) radi videli OpenAPI aj na el. schranky. Tot uz z velkej casti pokryva Integrácia na slovensko.sk · slovensko.sk API .

No a potom OpenAPI na dlhodobe ulozisko el. dokumentov. Tu je problem, ze taka sluzba zrejme na UPVS ci gov cloude este neexistuje, pricom sa uz roky vydavaju el. dokumenty a skladuju sa “len tak”.

14

UPVII ako gestorovi pracovnej skupiny sme zaslali nasledujuci navrh tem, ktore by podla nas mohli byt diskutovane na zasadnuti PS:

OpenAPI - body na PS:

  1. zoznam prioritných OpenAPI:
  • čo sa udialo od posledného stretnutia PS?
  • ktoré OVM ÚPVII kontaktovalo?
  • ktoré OVM ÚPVII plánuje kontaktovať?
  • ako motivovať OVM k publikovaniu API (hlavne existujúcich)
  1. MUK-P:
  • aktuálny stav implementácie - čo už je? na čom sa aktuálne robí? a čo je pláne?
  • odpočet harmonogramu
  • scope služieb ÚPVS v pilote
  • info o VO na API GW
  1. dopytová výzva na OpenAPI:
  • kedy sa plánuje vyhlásenie?
  • alokácia? min. výška NFP?
  • oprávnené aktivity?
  • hodnotiace kritériá?
  1. moje dáta/MOU:
  • info o projekte?
  • sú plánované pilotné služby pre MUK-P?
  • koordinácia s projektom MUK-P a API GW?
15

Tak najnovsi dodatok dava aj odpoved na to, kolko tento MUK-P stoji.

image
image992×495 75.4 KB

https://www.crz.gov.sk/index.php?ID=4343949&l=sk

Smutne.

16

Inak, aj tie licky vyzeraju “zaujimavo”, tusi niekto co je to “GT object storage”, “GT performance package MQ” a “GT performance package Logger”?

17

Tipujem ze GT=global transaction a MQ=message queue.

18

GT je verzia auta, ktoré niekto za toto dostane pod stromček

1 Like
19

To GT ma nenapadlo vysvetlovat inak ako GlobalTel … Aj preto sa pytam, lebo by ma zaujimalo, ze ci je to “na zelenej luke” alebo “prebaleny Open Source” (ci nieco take).

20

Asi to bude GlobalTel, ja som myslel ze je to vo vseobecnosti distribuovana databaza.