Informácie o úpadcoch z Registra úpadcov

vojtob · November 19, 2015, 7:33am

Informačný systém Register úpadcov (ďalej len “register”) je v pilotnej prevádzke. Podľa platného harmonogramu projektu má byť do produkčnej prevádzky spustený dňa 14.12.2015. Na adrese ru.justice.sk beží verejná webová stránka registra do ktorej sú postupne dopĺňané dáta z jednotlivých konkurzných súdov.
Register úpadcov okrem webovej stránky vystavuje aj webové služby, cez ktoré sú dáta registra poskytované, pre všetky subjekty, ktoré majú záujem ich využiť. V ďalšej časti popíšeme, sekcie verejnej časti registra úpadcov, ich pokrytie webovými službami a harmonogram ich nasadzovania.

Časť konkurzy a reštrukturalizácie umožňuje zobrazovať a vyhľadávať v zozname úpadcov. Údaje vznikajú kombináciou dát z informačných systémov konkurzných súdov, Obchodného vestníka a Registra správcov. Už dnes register obsahuje približne 80% konaní začatých podľa zákona č. 7/2005 Z. z. o konkurze a reštrukturalizácii a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon o konkurze a reštrukturalizácii“). Intenzívne dopĺňame aj zvyšné konania a zároveň pracujeme aj na importovaní informácií o neukončených konaniach, ktoré začali podľa legislatívy platnej pred platnosťou aktuálneho zákona o konkurze a reštrukturalizácii.
V pilotnej prevádzke sú aj webové služby pokrývajú časť pre konkurzné a reštrukturalizačné konania presne v rozsahu, ako sú publikované na webovej stránke. Služby umožňujú vyhľadanie konania rovnakým spôsobom ako vyhľadávanie na stránke a pre každé konanie poskytnú aj informácie zobrazované na stránke v časti detail konania. Definícia rozhrania je na adrese https://ru-ws.justice.sk/ru-verejnost-ws/konanieService.wsdl . Snahou bolo urobiť služby jednoducho, takže pre programátorov nebude problém wsdl pochopiť. Ak bude treba, nie je problém poskytnúť konzultáciu priamo od programátorov, či analytikov.
Zoznam majetku a zoznam obstarávaných služieb zatiaľ vystavené nie sú. Tieto údaje budú zadávané správcami konkurznej podstaty. Pre úspešný nábeh systému je potrebné, aby si správcovia zabezpečili napr. elektronický občiansky preukaz, aby bol dokončený súvisiaci legislatívny proces a aby bola celá komunita správcov s týmto systémom oboznámená. Predpokladáme, v závislosti od prijatia príslušnej právnej úpravy, že správcovia budú povinne zadávať údaje elektronicky od 1.7.2016 o konaniach začatých po 30. 6. 2016. Vtedy sa objavia aj prvé dáta o majetku a obstarávaných službách.
Pre majetok vystavíme aj webové služby. Pre obstarávané služby to nepredpokladáme, jednak ich bude podstatne menej a nemyslíme, že bude o tieto webové služby až tak veľký záujem.
Zoznam správcov konkurznej podstaty obsahuje kompletný zoznam správcov konkurznej podstaty a zoznam konaní, na ktoré bol správca priradený. Tento zoznam nie je vystavený cez webservices. Register správcov je samostatný projekt, register úpadcov z neho preberá iba časť údajov, napr. nemáme otváracie hodiny kancelárií. Ak sa ukáže ako užitočné, aby sme vystavili aj našu obmedzenú množinu údajov, môžeme tak po dohode s MS SR urobiť.
Po nábehu správcov konkurznej podstaty pribudnú aj ďalšie informácie zadávané správcami konkurznej podstaty (napr. pohľadávky, rozvrhy a podobne). Tie budú určite dostupné pre účastníkov konania (na webovej stránke). Ak bude právne možné (a to dúfame) zverejniť tieto informácie aj pre širokú verejnosť, tak budú určite vystavené aj vo forme webových služieb.
Zoznam konkurzných súdov nevystavujeme cez webové služby. Vzhľadom na to, že je to pevne definovaných osem súdov a tri odvolacie, nemá to zmysel.

Budeme radi, ak integráciu na tieto verejné služby vyskúšate, radi si vypočujeme aj Vaše pripomienky, či námety na vylepšenia. Ako už bolo spomenuté, je to jeden z cieľov registra, aby údaje v ňom obsiahnuté boli využívané každým, kto má o ne záujem.

Okrem týchto popísaných služieb určených pre verejnosť, bude zverejnená samostatná sada webových služieb pre správcov. Tie umožňujú úplnú integráciu správcovských systémov na register. V tomto prípade je nutné riešiť bezpečnosť prístupu, prihlasovať sa môžu iba správcovia, celkovo je táto integrácia podstatne náročnejšia aj rozsahom dátového modelu. Tieto webové služby sú určené pre úzku komunitu, informačné systémy budú musieť získať súhlas MS SR. Ak máte záujem o vývoj IS pre správcov, kontaktujte prosím MS SR a radi budeme spolupracovať aj na tejto integrácii.

miso · November 19, 2015, 9:58am

Jedna technicka pripomienka:

operacia webovej sluzby vyhladajKonanie ma vstupny parameter query. Zo stretnutia viem, ze tento parameter urcitym sposobom vstupuje priamo do query nad ElasticSearch - jedna sa o query string query? Je potrebne sa zamysliet, ci tento sposob dopytu nemoze odhalit urcite interne nalezitosti registra a pokial nie, tak je potrebne vysvetlit, aka je syntax tohto parametra.

jsuchal · November 19, 2015, 10:33am

Tak som to trosku prevetral cez http://wsdlbrowser.com/soapclient?wsdl_url=https%3A%2F%2Fru-ws.justice.sk%2Fru-verejnost-ws%2FkonanieService.wsdl

V prvom rade, velmi si cenim, ze ste sa na toto odhodlali a dufam, ze to pomoze obom stranam.

Pripomienky:

Pre getKonaniePreObdobie ma prekvapilo, ze strankovanie je od nuly. Taktiez ma prekvapilo, ze su parametre datumov povinne

      <ns1:DatumOd>?</ns1:DatumOd>
      <ns1:DatumDo>?</ns1:DatumDo>
      <ns1:Stranka>0</ns1:Stranka>
      <ns1:VysledkovNaStranku>0</ns1:VysledkovNaStranku>

Ocakaval som, ze ked nedam ziadny parameter, tak mi to vrati zoradene vysledky podla id (rastuco) od zaciatku / respektive zoradene podla casu poslednej zmeny. Neviem ci sa tieto zaznamy menia - podla toho zalezi ako sa k tomu postavit. Ak sa zaznamy aj mazu, tak ich treba riesit specialne, a pridat priznak zmazania.

Z pohladu realnej pouzitelnosti je toto kriticke a z mojej praxe na viacerych projektoch bolo vzdy potrebne taketo sychronizacne api. Je to dane tym, ze pouzivatelia potrebuju udrziavat vacsinou aktualnu “repliku” dat. V principe ide o formu publikovania transakcneho logu.

Tu je minimalisticka referencna implementacia. - dokonca ju v produkcii pouzivaju napriklad www.otvorenesudy.sk vid ich kod na githube.

Strankovanie je sice fajn, avsak po case mozete narazit aj na vykonnostne problemy. Viac na We need tool support for keyset pagination. Taktiez pri synchronizacii strankovanim moze dost ku kritickym subehom - update vo vasej db a moj read sposobi, ze preskocim strankou nejaky zmeneny zaznam / resp. budem naciatavat opakovane.

Osetrite si tam hranicne podmienky (napr. zaporne stranky) a velky pocet vysledkov na stranke (> 1000) inak vam to moze zacat robit load a je to pekny ciel na utok.

V samotnom konani ma trosku prekvapuje nekonzistentny format datumov zacatia konania a datumu narodenia. Taktiez nerozumiem preco ma datum narodenia format casu s casovou zonou.

 <ns2:KonanieInfo>
  <ns2:Id>19</ns2:Id>
  <ns2:SpisovaZnackaSudu>25K/12/2012</ns2:SpisovaZnackaSudu>
  <ns2:Typ>KONKURZ</ns2:Typ>
  <ns2:DatumZacatiaKonania>2012-04-13+02:00</ns2:DatumZacatiaKonania>
  <ns2:Dlznik>Delinčák Roman</ns2:Dlznik>
  <ns2:DlznikDatumNarodenia>1969-11-12T00:00:00.000+01:00</ns2:DlznikDatumNarodenia>
  <ns2:Sud>110</ns2:Sud>
  <ns2:Spravca>S1572</ns2:Spravca>
</ns2:KonanieInfo>

Trochu nesikovne z pohladu pouzivania bude asi to, ze getKonanieDetail vracia viac informacii ako getKonaniePreObdobie. Toto bude mat za nasledok to, ze namiesto 1 requestu na getKonaniePreObdobie to bude znamenat 1 + N volani na getKonanieDetail. Nevidim dovod preco by to nemalo vracat rovnake struktury.

        <ns2:getKonanieDetailResponse
            xmlns:ns2="datatypes.konanie.verejnost.ru.sk.hp.com">
            <ns2:Konanie>
                <ns2:Id>19</ns2:Id>
                <ns2:SpisovaZnackaSudu>25K/12/2012</ns2:SpisovaZnackaSudu>
                <ns2:Navrhovatel
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:FyzickaOsoba">
                    <ns2:Adresa>
                        <ns2:Ulica>Koniarekova 5865/6</ns2:Ulica>
                        <ns2:SupisneCislo>0</ns2:SupisneCislo>
                        <ns2:OrientacneCislo>0</ns2:OrientacneCislo>
                        <ns2:Obec>Trnava</ns2:Obec>
                        <ns2:Psc>91702</ns2:Psc>
                        <ns2:Krajina>SVK</ns2:Krajina>
                    </ns2:Adresa>
                    <ns2:Email/>
                    <ns2:Meno>Roman</ns2:Meno>
                    <ns2:Priezvisko>Delinčák</ns2:Priezvisko>
                    <ns2:TitulPredMenom/>
                    <ns2:DatumNarodenia>1969-11-12+01:00</ns2:DatumNarodenia>
                </ns2:Navrhovatel>
                <ns2:Dlznik
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:FyzickaOsoba">
                    <ns2:Adresa>
                        <ns2:Ulica>Koniarekova 5865/6</ns2:Ulica>
                        <ns2:SupisneCislo>0</ns2:SupisneCislo>
                        <ns2:OrientacneCislo>0</ns2:OrientacneCislo>
                        <ns2:Obec>Trnava</ns2:Obec>
                        <ns2:Psc>91702</ns2:Psc>
                        <ns2:Krajina>SVK</ns2:Krajina>
                    </ns2:Adresa>
                    <ns2:Email/>
                    <ns2:Meno>Roman</ns2:Meno>
                    <ns2:Priezvisko>Delinčák</ns2:Priezvisko>
                    <ns2:TitulPredMenom/>
                    <ns2:DatumNarodenia>1969-11-12+01:00</ns2:DatumNarodenia>
                </ns2:Dlznik>
                <ns2:Spravca>
                    <ns2:Znacka>S1572</ns2:Znacka>
                    <ns2:DatumZapisu>2011-12-20+01:00</ns2:DatumZapisu>
                    <ns2:Meno>Peter                                             </ns2:Meno>
                    <ns2:Priezvisko>Veselovský                                        </ns2:Priezvisko>
                    <ns2:TitulPredMenom>Ing.                </ns2:TitulPredMenom>
                    <ns2:DatumNarodenia>1983-08-23+02:00</ns2:DatumNarodenia>
                    <ns2:ObchodneMeno>Veselovský                                        </ns2:ObchodneMeno>
                    <ns2:Ico></ns2:Ico>
                </ns2:Spravca>
                <ns2:DatumZacatiaKonania>2012-04-13T00:00:00.000+02:00</ns2:DatumZacatiaKonania>
            </ns2:Konanie>
        </ns2:getKonanieDetailResponse>

Taktiez tam vidiet nejaky problem s whitespacom pri niektorych atributoch. (Neviem nakolko to je problem zobrazovatka wsdl online alebo u vas v db alebo kde.)

vyhladajKonanie by som v praxi asi nevyuzil, kedze online ide do open data registrov malokto - z roznych dovodov.

Ale v principe az na to synchronizacne API su to dost kozmeticke chyby a aj v tomto stave to je celkom pouzitelne a programator si z toho skor ci neskor vyseka co potrebuje.

Ak mate nejake doplnujuce otazky, tak sem s nimi.

crutch · November 19, 2015, 2:20pm

Ak je to spravene tak, ze sa query rovno posuva do elasticu, tak to by to urcite bolo dobre oddelit. Teda, aby sa tymto sposobom pouzivatelia nestali zavislymi na konkretnom mappingu a nazvoch fieldov, ktore ked niekto v elasticu zmeni, tak sa klientom rozbije integracia - ak by teda niekto isiel cestou integracie live vyhladavania a nerobil si lokalnu kopiu dat.

Ak je to len nejaka fulltextova query, tak by sa hodilo mat aj moznost poslat aj strukturovany dopyt - napr. chcem vsetky otvorene konania konkretneho spravcu.

vojtob · November 19, 2015, 8:00pm

fíha, celkom podrobné zhodnotenie, vďaka. Pozrieme a odpovieme.

Aspoň trochu z filozofie, ktorou sme k api pristúpili. Rozhodli sme sa pre MVP stratégiu. Nechceli sme vymýšľať hypotetické scenáre za iných, dlho analyzovať a budovať api podľa nás.
Predpokladáme, že veľmi jednoduché requesty idú cez query na elastic (posúvame ho priamo do elasticu, tak ako príde, nechceme aby klient poznal naše fieldy a písal elastic query). Komplikované vyhľadávanie si bude riešiť klient budovaním vlastnej db s vlastným vyhľadávaním. A určite bude šedá zóna medzi tým, napr. sme dostali požiadavku na vyhľadávanie podľa ičo. To je dobrá služba, chce ju konkrétny projekt, nasadíme ju budúci týždeň. Ak budú ďalšie námety, s reálnym využitím, a ktoré vieme rozumne realizovať, určite rozšírime aj ďalej.

Ešte raz vďaka za pripo, pozrieme a napíšeme.

jsuchal · November 19, 2015, 8:11pm

Inak MVP sa da potiahnut este dalej cez sluzby ako https://getsandbox.com/ a https://apiary.io/

Mathewst · November 19, 2015, 10:41pm

Ahoj,

Ako SIGP sme technicky sa podielali na vyvoji Registra updacov. Vedel by som na tie otazky odpovedat avsak vidno z toho reply Jana Suchala, ze konverzacia o technickych zalezitostiach hlavne ak ich je vela sa na forum nehodi. Mozno by bolo dobre keby ste spravili v ramci Vasich aktivit na realnu pomoc informatizacii slovenska verejnu JIRU alebo nieco podobne kde by ste projekty, ktore o pripomienky maju zaujem ako napriklad ten nas zalozili a pripadne technicke pripomienky by sa mohli evidovat tam? (Mozem s realizaciou tohoto pomoct ak mate zaujem)

Co sa tyka tych technickych vysvetleni jedno ako demo dam:
Detail konania vracia viac udajov preto lebo ide z internej databazy pricom vysledky vyhladavania su naplnane iba z odpovede elastic search, pricom komplexnejsie struktury je problem a nie uplne ziadane ukladat do fulltext search enginu. Konanie detail bude mozno neskor po legislativnych upravach vracat este viac udajov, povedzme aj pohladavky.

jsuchal · November 19, 2015, 10:51pm

Da sa pouzit quote. Staci oznacit text. Potom sa s tym da robit. Skusme a uvidime.

Toto je v poriadku. Netvrdim, ze to treba strkat do ES. Ja som bol napriklad v tom, ze tie odpovede vobec nejdu z elasticu (okrem fulltextu). Inak celkom zaujimave riesenie je tu https://stormpath.com/blog/linking-and-resource-expansion-rest-api-tips/ cast Resource Expansion. Je to sice REST, ale napad slusny.

Toto nie je zly napad, nieco podobne sme skusali. Na frontendy tu http://lepsie.statneweby.sk/ alebo na open data tu GitHub - OpenDataSk/data-requests. S velkym ohlasom sa to nestretlo. V principe vsak suhlasim, ze stat by mal mat jednu velku verejnu JIRU vyriesilo by to vela problemov s trackovanim, zodpovednostami a v konecnom dosledku aj vyhodnocovanim, kde co kolko stoji. Toto by mozno stalo aj za navrh do https://platforma.slovensko.digital/c/transparentnost-a-participacia date to tam ci pridam ja?

Mathewst · November 19, 2015, 11:29pm

Skor som myslel, ze v ramci konverzacie viac ako 2 ludi o viacerych problemoch sa v tom stratime. ISRU je velky projekt >megabajt zdrojoveho kodu, tych problemov je tam urcite vela na jeden thread pri najlepsej voli a intenzivnej spolupraci to nebude.

Ja som si to tiez povodne predstavoval inac, ale takto je to elegantne vyriesene, elastic je omnoho rychlejsi ako databazove dotazy.

Uplne nerozumiem vztahu tohoto k nasmu API, co konkretne by sme mali linkovat a preco? Toto skor vyplyva z povahy RESTu do SOAPu sa mi to uplne nehodi.

Pridaj ty. Skutocne asi bude lepsie keby ste to dokazali nejako integrovat do tejto webstranky.

jsuchal · November 20, 2015, 6:17am

V pohode, miesta tu je dost. Mozeme tu na to otvorit aj dalsi thread. Ak to zacne byt problem. Nejdeme robit audit zdrojakov, vyjadrujeme sa k Open Data API co ma 3 endpointy, to by sme mohli zvladnut nie?

Tymto si nie som uplne isty. Je omnoho rychlejsi na fulltext, analytiku, ale na bezny lookup cez primarny kluc je rel DB uplne porovnatelna. Naozaj je pre toto API pre 3K zaznamov toto problem?

Cast Resource Expansion. Ide o tu o to, aby sa zabranilo 1 + N problemu.

Pridam ja a zvazime ako k tomuto prirobit nejaky issue tracker. Mohli by sme sa medzicasom vratit k tej diskusii o tom API alebo je to tak velky problem, ze bez toho to nezvladneme?

Mathewst · November 20, 2015, 9:24am

Resource expansion som si presiel, mne osobne sa to az tak nepaci, nevidim v tom ani realne vyhody, je to skoro to iste ako vrat detail, akurat s lepsiou navigaciou. Pre SOAP s automatickou serializaciou objektov a pevnymi schemami sa mi to az tak nehodi, v kazdom pripade to urcite pri dalsich projektoch ja osobne (nehovorim za RU, nemam ziadne prava na projekte hovorit co kto bude robit) budem zvazovat aj RESTom.

1+N interne nezabranis, pretoze top vyhladavanie v prvom rade zavola elastic a potom docita detaily konani z db. Bolo by to mozno prijemnejsie pre uzivatela WS aby to mal rovno vsetko, ale to mozno skor pri tom synchronizacnom API, tie metody co tam vidis myslim nemali sluzit ako synchronizacne API. Mozno @vojtob zvazi a synchronizacne API prida.

K ostatnym veciam:
Strankovanie v tom co pises vyssie to poskytuje elastic search, performance problemy s databazou elasticu su mozno porovnatelne s performance problemami pokial tam strankovanie nebude a bude tam prilis vela zaznamov na vystupe.
Co sa tyka synchronizacneho API to je podla mna realna a zmysluplna poziadavka vid co som pisal vyssie.
Hranicne podmienky -> bug, to opravime vrati to Illegal Argument Exception.
Pocet vysledkov na stranku tam hadam ani nemusi byt, podla mna by stacil default a nedavat uzivatelovi moznost to nastavit.
Format datumov -> bug, to tiez budeme opravovat.
Whitespace -> bug, opravime

V kazdom pripade dakujem za pripomienky a kludne piste dalej, skusim nejako odpovedat na vsetko co viem.

jsuchal · November 20, 2015, 11:09am

Ale ano, toto sa da vytiahnut na 1 dopyt do elasticu a 1 do db (cez zoznam id). Co je vyrazne rychlejsie a sikovnejsie ako 1 + N dopytov na SOAP WS. Ale ako vravim, aj tak aj tak si to programator vie vytiahnut len to robi zbytocny load u vas.

Mathewst · November 20, 2015, 11:12am

WHERE (id IN :collection) myslis? To neni zrovna performance dobra query, dokonca ma limity v pocte id, ktore do nej mozes dat.
Ale konstruktivne, ak bude sync API, pojde rovno z DB a moze v nom byt vsetko. Toto API co je, je vyplyvajuce zo zakona aby niekto mohol naprogramovat komercnu implementaciu statneho webu, takze simuluje funckionalitu toho co robi web. Alebo myslim, ze taka bola za tym uvaha.

jsuchal · November 20, 2015, 11:58am

Zalezi od query planu a toho poctu id, ale z mojej skusenosti sa to da vyladit velmi v pohode. Pocet vies limitovat - limitom na strankovani (ktory tam podla mna ani netreba).

Suhlasim, ze sync API by mal byt zaklad a potom je vsetko ostatne taky bonus navyse.

jsuchal · November 20, 2015, 4:41pm

A post was split to a new topic: Register úpadcov

Lubor · November 21, 2015, 1:16am

Môj pohľad - za OpenData prístup - nadviažem na to čo písal @jsuchal :

možnosť efektívne zistiť zmenené údaje (aka. synchronizačné API) je ozaj dôležitá a aj je vyžadovaná §53.g.2 štandardov ISVS pre OpenData
za MVP by som považoval API k elementárnym entitám, t.j. v konaní dať iba ID-čka súvisiaceho navrhovateľa, správcu, dlžníkov tak ako je to previazané v relačnom modeli - čiže mať niečo ako getKonanie, getNavrhovatel atď. (veď aj v GUI je spravcaDetail.xhtml …)
aj SOAP je použiteľný ale zbytočný, keďže všetko sú to bezstavové synchrónne volania - pre budúcnosť radšej REST, ten aj navádza na správne paterny, napr. linking
“konania presne v rozsahu, ako sú publikované na webovej stránke” nie sú ani náhodou - napr. cez API nevidno typ správcu, typ pridelenia správcu, oznamy z OV…
toto nie je ani tak o API, ale skôr o prepojení údajov: očakával by som, že entity budú reprezentované primárne svojím (oficiálnym) identifikátorom, napr. adresa ID čkom z registra adries, optimálne ref.id. atď. - potom ani netreba deklarovať typ

Ale v zásade na prvý pokus celkom fajn.

vojtob · November 21, 2015, 8:28am

synchronizačné API - ok, bolo to spomenuté viackrát, aj náš programátorsky tím tomu bol naklonený. A aj táto diskusia tomu zvyšuje prioritu.
čo je MVP je filozofická otázka. Zatiaľ viem o jednom systéme, ktorý sa reálne chce integrovať, a tomu postačuje aj toto minimal. Chápem, že Vaše návrhy vylepšujú api, ale investovať do toho energiu len aby to bolo krajšie, bez reálneho používateľa … . Nie že by nemalo zmysel vylepšovať. Naopak, vďaka za pripomienky, verím, že väčšinu časom zapracujeme. Len keď sa bavíme o MVP, tak diskusia je o tom čo postačí - nemusí byť pekné.
O niečo vyššie bola diskusia, koľko volaní by malo byť (1+N). Zvyšovanie granularity (getSprávca, getNavrhovateľ, …) bude zvyšovať počet requestov. Vždy je niečo za niečo. Koncept, ktorý popisujete, sme použili v api pre synchronizáciu správcovských systémov. V tomto verejnom api sme uprednostnili jednoduchosť volaní. Časom sa api pre verejnosť bude rozširovať o ďalšie koncepty, napr. pohľadávky (po schválení legislatívy). Je dosť pravdepodobné, že budeme musieť použiť koncept, ktorý popisujete. A možné by bolo lepšie zväčšiť veľkosť údajov v konaní a ponechať iba málo služieb. Ideálne by bolo to prebrať s niekým, kto to chce reálne využiť. Nech riešime biznis, na ktorý to potrebuje a nie dizajnérsky koncept. Nech opäť urobíme najmenej čo treba, ale aby fungovalo.
SAOP vs REST - nemám nič proti restu, akurát vo verejnej správe soap ľahšie akceptujú. Uvítam, keď napíšete viac argumentov, prečo by Vám ako klientovi vyhovovalo používať rest. Posunieme ďalej a možno to bude stačiť na preklopenie
doplnenie atribútov, aby sme pokryli všetky údaje zobrazované na webe. Očividne bug, to nám uniklo. Skontrolujeme a doplníme.
referenčné registre, jo, svet by bol krásny. Tu som trochu skeptik, prakticky by sme potom nasadzovali v roku 2500. Toto je smer, ktorým chce slovenský egov ísť (myslím referenčné registre, nie rok 2500 ). Takže určite budeme držať krok a upgradovať.

A vďaka za pripomienky, každá by sa dala zapracovať. Ak aj píšem na niektoré nie, je to skôr otázka priorít, verím, že časom sa dostane na všetky. A ak nie v tomto projekte, tak v nejakom ďalšom. Už len to, že si ich prečítame, nás posúva. Vďaka.

ius · November 21, 2015, 12:31pm

hlavne si skontrolujte prepojenia na OV, niekedy vam to generuje nespravne prepojenia na nesuvisiace zaznamy.

vojtob · November 21, 2015, 5:06pm

Tak ako píšete, o tomto už vieme, našťastie aj vieme v čom je problém. Budúci týždeň nás čaká “veľká čistka” keď nanovo naplníme dáta. Navyše OV je v tejto dobe pre nás odstavený (nejaké konfiguračné zmeny v datacentre), takže ten budeme dohrávať a pri tom opravíme zle namapované záznamy. Aj tak vďaka za upozornenie.

Lubor · November 21, 2015, 11:36pm

“Urobiť najmenej čo treba” - jasné. Túto diskusiu beriem aj trocha akademicky, že čo by bolo ideálne, chápem že v tomto projekte to už nejako spravené je.

Avšak je čím diaľ jasnejšie, že pre API by bolo treba mať naprieč celým eGov oveľa lepší manažment ako doteraz. Situácia že každý projekt si “vymyslí” vlastné API, a potom majú všetky spolu fungovať, je vlastne tak trocha smiešna zdroj mnohých neefektívností.

Ad ref. registre: v tom futurizme som sa ešte celkom krotil. V skutočnosti by pre dátovú komunikáciu z nového registra mali byť najskôr vytvorené (štandardizované) dátové prvky a template pre referencovateľné identifikátory a API postaviť nad nimi. V dátovom prvku by sa nemalo prenášať nič, na čo už je iný dátový prvok (v tomto prípade zjavne fyzická osoba, právnická osoba, adresa…), t.j. na príslušnom mieste by mal v ňom byť len id. Či tieto “súvisiace entitiy” poskytuje iba nejaký referenčný register, alebo samostatne primárny register, alebo oboje (to je technická úroveň, na sémantickej úrovni: či sú údaje stotožnené s ref.reg.) je podružná otázka, systém treba mať nastavený tak, aby prechod z vlastnej evidencie na ref.reg. neznamenal aj prerábanie integrácií. Toto sa práve z veľkej časti dá vyriešiť používaním referencovateľných identifikátorov a službou ktorá dokáže pre ref.id. vrátiť obsah príslušného prvku. Keďže ref.id. sú vlastne URL, táto magická “služba” môže skrátka byť jeho volanie (čo je REST API). Keď takto spravený projekt raz prejde z vlastnej evidencie na ref.reg., t.j. dôjde k “stotožneniu” lokálnych údajov a ich náhrade za údaje z ref.reg., v API sa to prejaví iba zmenou identifikátora, technické riešenie celé zostáva rovnaké.