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 305/2013 Z.z. - Zákon o elektronickej podobe výkonu... - SLOV-LEX
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.
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.