Uplny suhlas. Toto je neskutocne zlozita a casovo narocna procedura.
Odbocim trochu
ale podla mna stacilo vytvorit sadu kniznic pre pristup k sluzbam upvs pre vsetky najpouzivanejsie vyvojove platformy a tieto poskytnut integratorom. A povolit pristup len cez tieto komponenty.
1 Like
ale zmena IM nie je reforma, toto je normalna exekutiva. Povodcom je NASES a ten svoje pravidla dokaze zmenit, staci chciet. Ale ako priklad je to fajn, mnozstvo problemov je v skutocnosti riesitelnych pracou na skutocnych veciach. Ved aj myslienka integracii bola v podstate logicka, kazda integracia vyzaduje jasne definovat pravidla, poziadavky na jednu aj druhu stranu. Ale ked chyba niekto kto sleduje povodny zamer tak to uradnicky nabobtna a zacne to zit vlastnym zivotom. A to generuje zbytocnu pracu a neprinasa hodnotu. To sa stalo vsetkym dobrym napadom,
Odbocim trochu ale podla mna stacilo vytvorit sadu kniznic pre pristup k sluzbam upvs pre vsetky najpouzivanejsie vyvojove platformy a tieto poskytnut integratorom.
Toto je dobra tema, vytvorme na to asi novy topic. Toto veru nebude taketo jednoduche 
Dovody preco su tie DIZ taketo a preco sa robia UAT nie su len cisto formalne. Problem je ovela hlbsi.
1 Like
Take kniznice su uplne bezne v komercnom svete.(motiviacia je jasna, co najjednoduchsie pouzitie, konkurencna vyhoda) Pri eGOV je to otazka. Na toto nemam vyhraneny nazor. Keby boli tie interfaces ciste a interoperable (SOAP alebo REST/Json programovane stylom contract first(WSDL,JSON Schema)), nie je problem vygenerovat pekneho klienta v comkolvek. OK. Urobis java,.net klienta a ozve sa PHPckar, ze preco nie PHP client. Preco nie? Potom sa ozve iny Javista, ze preco je klient vyrobeny s takou libkou a nie onakou, ked tu onaku pouziva iny eGOV api klient. Plus niekto sa o to musi starat. Ja osobne som radsej za pravidlo a vynucovnie cistych API.(uz to je nadpozemske ocakavanie) A verim, ze sa najde nejaky komercny poskytovatel, ktory urobi nejaky integracny eGOV suite, napr. slovensko digital v ramci ekosystemu 
Blockquote Problem je ovela hlbsi.
Skusme ich pomenovat pre zaciatok (blbe, ze to musime robit my), mozno zistime, ze niektore z tych “dovodov” nema riesit DIZ. Ale nemyslis si, ze ktokolvek by tu spochybnoval nutnost vymeny informacii a vo vybranych pripadoch posudzovania a schvalovania, skor ide o tu formu a realnu prax.
neni to az taka zlozita vec tych platforiem, nie je ich nekonecno prave si ich v podstate vymenoval.
Podla mna by to nebolo take zlozite lebo v podstate kazde rozhranie sa testovalo. Ten isty kod sa v podstate da pouzit ako zaklad takehoto SDK.
Vyhoda je zjednodusenie integracie, lebo ten kto robil rozhranie robil aj SDK a ak sa nebude dat poslat nezmyselne volanie alebo nespravne parametre tak sa zjednodusi aj integracia.
Ten kto pisal rozhranie UPVS napise k nemu aj SDK a uvedie presne priklady spravneho pouzitia. Ostatne moznosti budu zablokovane a vyvolaju vynimku uz na strane vyvojara.
Inak napr. tie lib co pises. To by poriesil otvoreny kod. S tym ze na tu ho mas ak sa ti chce napis to nad inou lib a myto otestujeme a ked to bude robit co ma tak to zverejnime aj pre ostatnych…
uz to nechcem rozmazavat. Vyhody su jasne, napad dobry. Nekonecno nie, ale dost, aj tych bezne pouzivanych (java, .net, python, php, javascript, ruby, .net core, …neexistuje kriterium na zaklade ktoreho by si jeden mohol vylucit) a v ramci niektorych je vela konkurencnych kniznic. To je naozaj taka veda k nejakemu peknemu cistemu API (swagger/wsdl) si vygenerovat klienta? (ze to ma stat platit?) A za predpokladu, ze to vies vygenerovat, vybrane priklady spravneho pouzitia sa daju napisat v 1-2 jazykoch(je jedno asi v akych) aj bez SDK.
A ok, verim, ze ked sa najde nejaka partia z 2-3 firiem a zacnu niekde na git publikovat SDK, tak sa pridaju aj dalsi. Alebo to niekto urobi komercne.(ak to bude viac z komercnej pozicie dostupne)
1 Like
No tak si to skusme rozobrat:
Kedze toto je klient, budes mat staru verziu, nijako nevynutis kontrakt voci UPVS. Sorry, ale toto je uplne opacny smer akym by sa to malo ubrat.
Presne tak, problem je to API, nie to, ze nemame pekneho klienta. Resp. mame, ale teraz naozaj k veci.
Dovody preco sa robi DIZ & UAT:
- NASES chce vediet, na co sa jeho API pouziva (toto je ako tak ok, bezne sa to zakaznikov pytame aj my)
- NASES chce vediet, ake sluzby sa pouzivaju (toto je uplne zbytocne, realne by sa mala monitorovat ziva prevadzka a podla toho vieme co sa pouziva. Chapem, ze do metais vsak su dostat zavislosti, toto sa da vyriesit vyklikavanim, ze tieto sluzby chcem a hotovo.
- NASES potrebuje vynutit nejake kontrakty, ktore nie su na “aplikacnej” urovni spravene dobre.
- rate limiting - toto je zly vtip, ze to vynucuju papierom a nie technicky. Ja v klude papier podpisem, ale ked sa mi niekde zacykli job, tak ich aj tak zahltim.
- prilis “vseobecne” rozhrania. Na g2g receive sa da posielat “kadejaky bordel”, ked sa odpoveda na spravu, tak treba ponastavovat vselijake correlation_id, reference_id… ovalidovat vsemozne vnutro formularov. Toto sa da vyriesit tak, ze sa spravia na strane UPVS poriadne validacie alebo sa obalia existujuce endpointy do menej vseobecnych (napriklad API na vseobecne podanie moze byt v klude nadpis+text+prilohy)
- komplikovana integracia pre bezne pouzitie.
- Napr. ked clovek chce preberat spravy zo schranky, tak musi saskovat s inboxom, presuvanim sprav, mazanim. Akonahle pristupuju do schranky sw dva, tak to nie je mozne. Toto vsetko by sa dalo vyriesit tak, ze sa spravi normalne API na zmeny v schranke a nastavi poriadne retencia sprav (trebars aj pre OVM).
- Napr. odoslanie podania. Namiesto jedneho atomickeho volania (odosli a vloz do outbox) sa toto prenasa na konzumenta API. Pritom je to hlupost, ked mi to failne v strede (kvoli mne, upvs, asteroidu), nemusim to nijako vediet dokoncit (trebars vyprsi OBO token).
- Napr. odoslanie na CUET vyzaduje integraciu na cuet, schranku (lebo inak nezistite, ze to preslo), pripadne este pecatenie. Cele to je asynchronne (g2g receive) namiesto toho, aby som mal synchronne API, ktore to tam bud da alebo failne. Takto musim hladat v schranke, parovat, robit vselijake timeout kontroly, ze dokedy to tam tak bezne pride, kedy to uz mozem zopakovat… no uplne zlo.
- Podpisovanie formularov/dokumentov to cele este viac komplikuje, lebo sa to zabali do nejakeho z mnozstva roznych formatov a tym padom je preberanie sprav uplna zloba, ktora vyzaduje mat parser na stovky specialnych situacii. Zaroven v opacnom smere to komplikuje pripadne validacie (upvs by to muselo rozoberat)
No a samozrejme cele je to strcene do SOAP a WS-* s celkom pokrocilym security nastavenim, co znamena, ze pre niektore jazyky je velky problem uz najst vobec kniznicu, co taketo nieco podporuje.
Ono cele toto schovat za REST/JWT standard bola pointa nasho komponentu, ale niekde proste tie api leakuju komplexitu von a neda sa s tym vela urobit, bez zasahu do UPVS.
1 Like
Ja doslova tazko chapem preco nie je API pre PO, API pre FO, API pre OVM, kde budu len funkcie pristupne pre dany typ klienta. K tomu API 3 sady predpripravených UAT testov. Namiesto toho je akoze dostupné celý gulas funkcií. Si nuteny nastudovat tonu materialov, kde ta este 7 x vratia, ze si nieco nepochopil. Ano nepochopil a ani sa za to nehanbim, zivim sa inym, a tu potrebujem user friendly pristup. Tak by som len z DIZu a UATov vyskrtol tie, ktore nepotrebujem a ostatne mam predpripravene. Pri takom pristupe sa dá prehlltnut aj ten SOAP s WS-
Nehovoriac o tom ze v cechach uz mozu posielat aj firmy firmam a teda mozu aj vyhladavta v schrankach … kym u nas vyhladavt moze iba OVM …
1 Like
Ok v poriadku davam len iny pohlad na tu istu vec.
Toto by ale nebolo treba vynucovat. Jednoducho si stiahnem najnovsiu sdk a a pouzijem.
Ak uz raz mam technickeho uzivatela mozem pouzit kompletny rozsah funkcii urcenych pre PO, FO alebo OVM.
NASES potom ani nemusi zaujimat co ja s dorucenou spravou robim alebo ako ju vyrabam kedze tieto komponenty nas od potreby riesit co klient s danymi sluzbami vo svojom IS robi alebo aby neposlal nespravne vyplnene udaje odtienia (ten bordel co sa da dnes posielat nepustit). ä
Raz im v ziadosti uvediem kto som a pre ake ucely to integrujem a potom uz si len aktualizujem kniznice ak nases vyda nove a nemusim uz nikdy s nasesom komunikovat.
Ak by sa islo cestou ze API ako kolega pise je to samozrejme vyborna vec, ale vsetko to co pises v bode komplikovana integracia plus mnozstvo dalsich veci musi upvs vyriesit este pred tymto rozhranim.
Dnesna integracia je preto taka komplikovana, lebo my musime spolu s NASES vyskladat funkcionalitu tak aby aj na strane integrovanej organizacie aj na strane UPVS vsetko fungovalo. A nases musi povedat ze takto poskladane funkcie maju zmysel a nie su nezpouzitelne alebo rizikove.
Funkcie v integracnych manualoch su “atomicke” a na jednu uzitocnu funkcionalitu v mojom systeme musim pouzit niekolko roznych volani UPVS. Zda sa ze by sa nad to este jedna vrstva orientovana na prakticke pouzitie u FO,PO alebo OVM zisla.
Cize ci uz SDK, alebo API ako pise kolega by malo vystavit akusi uzitocnu sadu funkcii pre FO, PO, OVM. Kde tie problemy ako nespravne uvedene udaje a pod. budu eliminovane a to api bude obsahovat uz hotove prakticky vyuzitelne funkcie.
Je uplne jedno ci to bude api ci sdk. Snaha by mala byt nahradit vyskladavanie jednotlivej funkcionality UPVS do funkcii na strane integrovaneho IS sadou bezne pouzitelnych funkcii s vylucenim rizika volania s nespravnymi parametrami a pod. S ponechanim moznosti si aj nieco vyskladat a vtedy by bola komunikacia s NASES nevyhnutna.
Presne tak a co je najhorsie, ze niektore niekedy ani nevyskladas.
Napriklad odoslanie podania a jeho vlozenie do zlozky Odoslane.
Su to dve samostatne volania. Ale napriklad u rozhodnutia sa to ani neda takto urobit.
A teraz mas napr. problem ze uzivatel vytvara posiela rozhodnutie, ktore sa pecati az v CEP. Aby do svojej registratury mohol ulozit podpisane rozhodnutie bolo by idealne ak by si ho nasiel v zlozke Odoslane od kial si ho do registratury stiahne.
A kedze casto sa stane ze to vratenie znie iba
“je to v dokumentacii” tak tento cyklus vracania nema ziadny ani vychovny ani uciaci ucinok iba vedie k zbytocnej nervozite a uz vobec nezrychli proces integracie…
A toto mna uplne nesmierne vytaca, lebo ta dokumentacia mala davno byt niekde v nejakom confluence, ktory ma aspon fulltext a track changes. Lebo toto stahovat a vyhladavat stale dokola je nieco neuveritelne.
1 Like
ale pre take nieco je jednoduche vysvetlenie - aspon tak sme sa ucili 
= zle nadizajnovane. Chce to refaktoring. Vydať API v.2.0 a pôvodnemu dať rok na dožitie … ako to robia všetci okrem NASESu …
ak si mal už aj inú odpoveď tak to ti gratulujem …
Teraz si trafil klincek po hlavicke.
Dokumentacia tak ako je spracovana a sposob akym je zverejnena je dobry do firmy kde sa v jednej chvili moze integracii venovat tak zo 10 ludi.
V ostatnych pripadoch je to o nervy.
Portal kde je to zverejnene neposkytuje ziadne nastroje aby sa v dokumentacii dalo vyhladavat. Vazba informacii “uvedene v prirucke XY” bez linku na komnkretny odstavec, chybajuce funkcie vyhladavania rozdsah manualov, zverejnene XML priamo v manuali na niekolchych stranach tak ze sa ani neda skopirovat, nemoznost sa dopracovat k niektorym xsd ani po dlhej dobe stravenej na portali a potom pride “nie je podla dokumentacie” a mozes sa aj hodit o zem.
Rad by som dotycneho nasesaka videl ako by si poradil keby bol na nasej strane…
(cest tym pracovnikom ktori sa nam snazia, resp. snazili pomoct niekedy aj nad ramec svojich povinnosti napr. kontaktom na vyvojara, odkazom na zdroj informacii a pod.) Ono vsetko je asi len o ludoch.
… hmmm a novy sef NASESu o tomto asi v svojom programe nema nic …
Zhodou okolnosti sme s nim vcera sedeli a toto ho zaujimalo. 
Uvidime nakolko sa nieco podari presadit. Problemov tam maju dost a toto nie je uplne miesto kde ich to velmi tlaci.
@robert.kuchar ok, Robo este mame fyzicku osobu podnikatela, cize skor OVM vs. zvysok. Ano aj taketo aspekty mali/mohli byt zohladnene, Nesmies zabudnut, ze spristupnenie API mimo OVM sa udialo len relativne prednedavnom a nikdy tam takyto zamer nebol.(nepoznam presnu genezu ale asi tomu silno dopomohlo SDG…).
firma -> firma, nebodaj chces aby museli naviezt dalsi kamion HW, aby to zvladlo takto zvyseny traffic?
@miromr
len v skratke. Kvalitne api poskytuje kvalitnym cisty, jasny kontrakt. Zabezpecuje dve zakladne veci. staticka/strukturalna validacia vstupov a pri commandoch kontextova validacia . K tomu je dobra dokumentacia. Ma to mat nejaku rozumnu encapsulaciu.(nie nekonecnu strudlu metod, ale napr. po domenach, agregatoch…) Ak Ta ma zachranovat SDK, nieco je velmi zle a ak je slaby contract ten sebalepsi klient nezachrani a na mieste NASES sa nan nemozes spoliehat :-).
Aj pri async komunikacii(messaging) musi byt rovnako kvalitne vytvoreny a popisany contract, kazda sprava. (json,xsd) a zase vies generovat kod.
Akademicky, to SDK Ti moze pomoct len so strukturami a tie sa z dobre popisaneho API lahko generuju (specialne ak k tomu API kvalitny popisny DSL)
“vo svojom IS robi alebo aby neposlal nespravne vyplnene udaje odtienia”
cize na toto sa 1. nemozes spoliehat ako poskytovel 2. ma to potencial riesit len strukturalnu stranku
2 Likes
Vycerpavajuce, necakal som, ze sa toho tak zhostis.
Doplnam: Opravnenost/pravny titul pristupu k metodam a udajom
Mozno by na zaciatok stacilo viac ochoty pomoct. Ked uz tam napise ze “nie je to v sulade s dokumentaciou” aspon pol vety ktora cloveka nasmeruje blizsie k rieseniu. Je fakt ze integrator nemoze poznat ten system ako funguje a takato odpoved cely proces zdrzi daleko viac ako by to bolo ak by bola presnejsia informacia.
Pre cloveka ktory to ma v malicku je to casto iba par sekund a par stlaceni klaves.
V podstate inak povedane ak by nam vo firme sa dialo ze stale musime davat zakaznikovi opakovane rovnaku odpoved, tak uz davno sme nechali prehodnotit nasu dokumentaciu. Nieco tam je, co tento proces zdrzuje a komplikuje. Dokumentacia ma byt nielen aktualna ale aj napisana zrozumitelne. Ved na integracii nepracuju zaciatocnici, ale ludia co maju nieco za sebou a mnohokrat vyzeraju ako “malo zorientovani”