Pripomienkovanie CSRU


#1

Kratky uvod do CSRU
Je to implementacia casti Modulu Uradnej Komunikacie (MUK) definovanej v 305/2013 Z.z

(11) Modul úradnej komunikácie zabezpečuje prostredie pre elektronickú komunikáciumedzi agendovými systémami a inými informačnými systémami pri výkone verejnej moci elektronicky…

MUK ako taky je rozdeleny medzi MVSR, MFSR a UVSR, z coho momentalne implementovana je cast spadajuca pod MFSR ako projekt CSRU. Implementacne sa jedna o ESB platformu a DB na zabezpecenie konsolidacie dat.

Aktualny stav prezentovany na ITAPA http://www.itapa.sk/data/att/3531.pdf.

Navyse, pristup k referencnym registrom je nevyhnutne vykonavat cez modul uradnej komunikacie, teda pristup k RPO je mozny len cez CSRU. Viac tu https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2013/305/20151101#paragraf-10.odsek-2

Pripomienky k aktualnemu stavu

  • Nestandardne protokoly Na zaklade paragrafu 11 vynosu 55/2014 MF SR sa ako standardny middleware protokol odporuca pouzivat protokol SOAP v1.2 pre komunikaciu medzi serverami. SFTP rozhranie pre ziskavanie odpovede z asynchronnej sluzby je preto v rozpore s tymto vynosom. Z integracneho manualu CSRU:

  • Chybajuce sluzby CSRU uz teraz vystupuje v roli jednotneho pristupoveho bodu pre komunikaciu medzi OVM (mimo MVSR), mal by sa preto klast vacsi doraz na kvalitu poskytovanych sluzieb. Ako problematicke vnimam neposkytnutie sluzieb referencnych registrov, menovite RPO, v rovnakej kvalite a rozsahu. Niektore sluzby, napriklad sluzby vyhladania absentuju uplne, ine povodne synchronne sluzby su poskytovane len v “asynchronnom” rezime, vid. popisany princip vyssie vymykajuci sa akymkolvek zauzivanym standardom aj vynosu 55/2014 MF SR.

  • Obmedzeny pocet poskytovatelov sluzieb a ich kvality Sluzby momentalne poskytuju len vybrane OVM a nie vsetky sluzby funguju podla ocakavania. Ako priklad uvadzam aktualny stav poskytnutia danoveho nedoplatku subjektu z FSSR, ktore je riesene ako asynchronna webova sluzba, kde su volania sluzby raz tyzdenne transformovane na email odoslany uradnicke financnej spravy, ktora poziadavky manualne spracuje a nasledne v stanoveny den v tyzdni odpoved odosiela naspat. Tu je potom mozne ziskat dalsim volanim WS. Celkovo tak od zavolania sluzby po prijatie odpovede moze v najhorsom moznom scenari uplynut viac ako tyzden. :ok_hand:

CSRU z pohladu NKIVS2
Nemal som moznost este precitat cely strategicku prioritu integracie a orchestracie, z toho mala som si vsak vsimol nasledovne. Tym, ze cela NKIVS sa rozhodla budovat cloud, tlaci sa na pouzitie as a service infrastruktury, platformy alebo softverovych sluzieb. Rovnako sa pocita s vyuzitim iPaaS, teda integracnej platformy ako sluzby - rozumej ESB a orchestracna platforma ako sluzba.

Co sa da urcite vnimat pozitivne je vynucovanie pouzitia cloudovej infrastruktury namiesto nakupovania noveho HW, avsak vynucovanie pouzitia PaaS a SaaS vnimam u uz existujucich projektov ako nerealne z hladiska migracie. Co sa vsak tyka samotneho iPaaS, tak to vnimam ako absolutne nepotrebne.

Dovod je jednoduchy a to je samotna existencia Modulu uradnej komunikacie, ktory sam riesi prave komunikacnu a pristupovu cast pre ISVS, teda jednotnu integracnu platformu, inak povedane ESB, vramci statu. Nie je teda nevyhnutne nutne poskytovat ESB ako cloudovu sluzbu. Nehovoriac o nevyzretosti celeho iPaaS a absencie jeho pouzita aj v komercnom svete. Usilie by som skor sustredil na dobudovanie samotneho MUK ako jeho migracie na cloud based integracnu platformu.


Dátová integrácia (Konsolidácia nosnej údajovej základne pre sprístupnenie formou otvorených údajov)
#2

Jaký máte názor na používání SOAP + XML?

Dle mého názoru to je většinou kanón na vrabce a témeř všechny use-case zastane lépe RESTful + JSON, což je dnes i standardem u API v komerční sféře.


Pouzitie SOAP a XML medzi IS VS
#3

SOAP so vsetkymi WS-* extensnami je zbytocne prekomplikovany, az akademicky, avsak ja to z pohladu cielov vnimam len ako implementacny detail. Pouziva sa historicky.