bolo by dobre …
1 Like
…pre to mikroobstaravanie sa ponukam ako konzultant pre API…plus budeme vediet na co sa pri popise API primarne zamerat…
1 Like
@peter_k pisal som ti na slacku slovensko digital, ale radsej este takto, verejne… mam otazku:
(bolo povedane) pri zmene stavu objektu (projekt, zonfp…) dany objekt “zmizne” z endpointu
tj. ak bol projekt v “vrealizacii” a nasledne prejde do stavu “ukoncene”, zmeni sa aj jeho ID, alebo ostava nezmenene?
v oboch pripadoch vsak nastava nejaky problem. v prvom pripade, ak by sa ID nemenilo, ako realne stiahnem tuto informaciu k sebe? pri stahovani postupujem inkrementalne, tj. stahujem len to, co sa v nasej DB este nenachadza, vychadzam z informacie “min_id”. napada vas nejake riesenie? v druhom pripade, ak by sa ID menilo, ako zistim, ze dany predchadzajuci objekt, respektive jeho stav nieje nadalej validny?
Dakujem!
bol som mimo netu par dni…dnes vecer na to pozriem a odpisem
caves, sorry, ze az tak neskoro, ale bol som par dni mimo netu a po navrate trocha trvalo, kym som sa prepracoval…slack moc nesledujem 
[quote=“Michal_Macejko, post:103, topic:1140”]
(bolo povedane) pri zmene stavu objektu (projekt, zonfp…) dany objekt “zmizne” z endpointu
tj. ak bol projekt v “vrealizacii” a nasledne prejde do stavu “ukoncene”, zmeni sa aj jeho ID, alebo ostava nezmenene?
[/quote]
…ono to je specificke od endpointu k endpointu…vychadza to z podstaty domeny…ale vseobecne plati, ze ID objektu jeho “prechodom” medzi endpointami sa nemeni…
napr. ZoNFP by sa mala spravat nasledovne ak si dobre pamatam z hlavy:
- endpoint ZoNFP/prijate - obsahuje vsetky ZoNFP. Aj ked ZoNFP prejde do ineho stavu a objavi sa napr. v endpointe ZoNFP/schvalene, tak ta ZoNFP je dohladatelna v endpointe ZoNFP/prijate. V oboch endpointoch sa predmetna ZoNFP nachadza pod rovnakym ID.
napr. Projekty by sa mali spravat nasledovne:
- endpoint Projekty/vrealizacii - obsahuje projekty, ktore su aktualne v raelizacii. Ked sa skonci realizacia projektu, tak prejde do stavu ukonceny a je ho vidiet v endpointe Projekty/ukoncene. V endpointe Projekty/ukoncene ma predmetny prohjekt nachadza s rovnakym ID ake mal v endpointe Projkety/vrealizacii. Po prechode do endpointu Projekty/ukoncene sa predmetny projekt uz nenachadza v endpointe Projekty/vrealizacii.[quote=“Michal_Macejko, post:103, topic:1140”]
v oboch pripadoch vsak nastava nejaky problem. v prvom pripade, ak by sa ID nemenilo, ako realne stiahnem tuto informaciu k sebe? pri stahovani postupujem inkrementalne, tj. stahujem len to, co sa v nasej DB este nenachadza, vychadzam z informacie “min_id”. napada vas nejake riesenie? v druhom pripade, ak by sa ID menilo, ako zistim, ze dany predchadzajuci objekt, respektive jeho stav nieje nadalej validny?
[/quote]
…ako pisem ID objektu sa nemeni…jedine, co sa deje, ze z niektorych endpointov tie objetky “miznu” do inych…ked teraz na rychlo premyslam, tak tym ze postupujes inkrementalne, tak to neobjavis…napr. pri projektoch som uvazoval, ze ci to vsetko nespojit do jedneho endpointu…aktualne struktura dat pre projekt v realizacii a ukonceny projekt je rovnaka, rozdiel je len v stave…cize keby si okrem inkrementu v tomto pripade sledoval aj zmenu, tak by si vedel identifikovat, ze na niektorych objektoch doslo k zmene…rozdelene do dvoch samostatnych endopointov to mame teraz kvoli tomu, ze sa tie datove struktury casom mozu rozist…
…navrhujem sa stretnut, prejst si endpoint za endpointom…pokusim sa pochopit, ze ako sa na to pozerate, co mate za ciel a skusime nieco vymysliet/upravit v API, aby to nejake fitlo…
1 Like
…dik NBS SR za aktivne vyuzivanie API a zasielanie feedbacku…lahsie sa vychytavaju chyby, vznikaju poziadavky na nove datove struktury, lepsie vieme, comu pouzivatelia nerozumeju a comu hej a pod…
v kratkej dobe bude zverejneny novy xmind, kde budu zachytene:
- opravy a rozsirenia API k verzii 9.5 (verzia 9.5 bude uvolnena do PROD buduci tyzden)
- navrh datovych struktur, na ktorych zverejneni sa aktualne pracuje a budu v kratkej buducnosti postupne uvolnovane…inak je sa na co tesit
1 Like
prikladam novy OpenData_ITMS2014 _v9.5.xmind (4.5 MB)
- zelene podfarbenie = rozsirenie, ktore pride vo verzii 9.5
- cervene podfarbenie = odstranenie, ktore bude vo verzii 9.5
- tmavomodre podfarbenie = aktualne rozpracovane struktury v ramci dalsej iteracie rozvoja API
2 Likes
Ahoj @peter_k, niektore URL z API nam nefunguju.
Konkretne:
- https://opendata.itms2014.sk/verejneObstaravania/1040/zmluvyVerejneObstaravanie
- https://opendata.itms2014.sk/verejneObstaravania/984/zmluvyVerejneObstaravanie
vracaju HTTP 500
Potom vacsina IDciek na https://opendata.itms2014.sk/dodavatelia/:id (napr https://opendata.itms2014.sk/dodavatelia/2733) vracia HTTP 404
Vedel by si nam s tym pomoct?
Tie 500ky poriesime. Vyzera to na problem s SQLkom, referencujeme stlpec ktory uz neexistuje. Co sa tyka tych 404 tak niekedy to je spravna odpoved, napr. ked taky dodavatel naozaj neexistuje. Odkial si ziskal href na dodavatela s id 2733 ?
Dik za odpoved. Vsetky tie ID pochadzaju z hrefov z inych odpovedi. Napr vacsina dodatavatelov odtialto
https://opendata.itms2014.sk/uctovneDoklady?minId=623&limit=100
mi nefunguje.
cauko, ja som skusal volat tie VO s ID 1040 a 984 cez swagger a detail som dostal v poho, skus pls este raz…vies mi poslat este dalsie konkretne ID uctovnych dokladov, kde bol href na nasledne “neexistujuceho” dodavatela? dik
Jasne, namatkovo:
https://opendata.itms2014.sk/uctovneDoklady/1283
https://opendata.itms2014.sk/dodavatelia/1360
https://opendata.itms2014.sk/uctovneDoklady/1287
https://opendata.itms2014.sk/dodavatelia/1490
https://opendata.itms2014.sk/uctovneDoklady/1342
https://opendata.itms2014.sk/dodavatelia/1483
ale nevztahuje sa to len na uctovneDoklady, napr aj tu:
https://opendata.itms2014.sk/verejneObstaravania/329/zmluvyVerejneObstaravanie
https://opendata.itms2014.sk/dodavatelia/1766
2 Likes
Jj, mame fix. Nestiham pisat ucelene reakcie. Zajtra by to mohlo byt fixnute v PROD.
Vecer spisem aj dalsie fixy, zmeny a dopad na existujucich konzumentov
3 Likes
Caute,
dnes, 16.6.2017 bola uvolnena verzia 9.5.4, ktora v ramci OpenData API nesie viac zmien a oprav. Strucny zoznam a popis tu:
-
API sme zacali verzionovat, nakolko sme urobili par zmien v strukture a ciel je uvolnenim neovplyvnit/neodrezat uz existujucich konzumentov. Cize na tomto URL https://opendata.itms2014.sk/ je jednoduchy razcestnik na V1 a V2.
V1 by mala fungovat plynulo pre vsetkych doterajsich konzumentov.
Pre novych konzumentov odporucame pouzit uz novu V2. -
Dalsia strategia v ramci verzionovania API je, ze postupne budeme stare verzie API hubit, aby sme nemuseli zivit vela verzii naraz. Cize existujucim konzumentom odporucame postupne prechadzat na vyssie verzie API, nakolko tie prinasaju kvalitativne zmeny, ktore vyplyvaju z rozsirovania API a aj poziadaviek konzumentov. Predosla verzia bude k dispozicii urcity casovy usek (este nevieme ako dlho), aby konzument mal priestor si zmenit veci na svojej strane a prejst na vyssiu verziu API.
-
Obsah V1:
vytvorenie noveho endpointu pre typy aktivit v ramci Programovej struktury
rozsirenie existujucich endpointov o nove atributy, napr. v ramci ZoNFP, Projektu, VO, ZoP, …
oprava chyby nezobrazovania alokacie na jednotlivych urovniach programovej struktury
oprava chyby chybneho hrefu na Uhradenej ZoP
oprava chyby chybneho hrefu na “neexistujucih” Dodavatelov/subjekty
oprava chyby nezobrazovania poloziek dokladu v detaile Uctovneho dokladu -
Obsah V2:
vytvorenie novych endpointov pre intenzitu, aktivity, polozku rozpoctu v ramci Projektov
vytvorenie noveho endpointu pre typy aktivit v ramci Programovej struktury
obohatenie existujucich ednpointov o hrefy na vyssie uvedene nove endpointy
opravy popisane vo V1 -
odporucane kroky:
potahanie nanovo Uctovnych dokladov - kvoli polozkam dokladu a aj kvoli oprave hrefu na subjekty/dodavatelov
potahanie nanovo Uhradenych Zop - kvoli chybnemu hrefu
prechod na V2
3 Likes
…este som zabudol jednu vec spomnut a to, ze novou verziou, teda od 16.6.2017, API bezi realtime voci produkcnej DB…doteraz bezala voci prostrediu, kde boli produkcne data, ale boli aktualizovane raz za 24 hodin…
To, že sa pri op.programoch objavila výška alokácie je skvelé. Tie čísla však zľahka kolíśu - pri Technickej pomoci to za pol roka kleslo o cca 4%. Prečo sa hýbu?
Na projektoch nie sú žiadne zmeny. Ktoré ID je možno považovať za id_projektu, ktoré sa nebude meniť?
Nedalo by sa miesto subjekt_dic, subjekt_id uvádzať meno subjektu, adresu, obec, okres?
Chýba tam aj č. žiadosti o NFP a operačný program.
Na žiadostiach pribudlo zameranie projektu.
Chýba op. program, názov žiadateľa, adresa žiadateľa, obec a okres.
Nebolo by zlé, keby mali vśetky tri datasety rovnaké poradie polí.
Je kód výzvy “1” naozaj kód výzvy, kt. sa nebude meniť?
Treba rozlisovat medzi ID ZoNFP a ID Projektu. Ja som to naparoval cez kod ITMS. Piata pozicia kodu ITMS od konca sa meni nasledovne ZoNFP => Projekt; “0” => “1” .
Pri subjektoch staci ICO, ostatne data si vies dotiahnut napr z datanestu Aliancie Fairplay, alebo aj z inych komercnych zdrojov.
Vacsi problem mam ale s tvorbou mapovych vystupov, kedze neda sa jednoznacne naparovat sidlo ziadatela ani na zaklade nazvu obce (lebo mame viac obci s rovnakym nazvom) ani na zaklade PSC (tu robi problem BA a KE). Nedal by sa k sidlu pridat nejaky jednoznacny lokalizacny udaj napr. ICZUJ - identifikacne cislo zakladnej uzemnej jednotky na urovni NUTS5? (okresy a kraje sa potom daju vyskladat).
1 Like