Biežāk uzdotie jautājumi saistībā ar API Pārvaldnieku

• Kur serviss šobrīd ir izmitināts – VRAA vai iestādes infrastruktūrā?

  To var pārbaudīt VISS IS servisu kataloga autorizēti lietotāji - https://lvp.viss.gov.lv/VISS.ISSK/ (produkcijas vidēs) / https://epakvisstv.vraa.gov.lv/VISS.ISSK/ (testa vides) – atverot konkrēto IS servisa notāciju. Laukā “Fiziskā URL” ir norādīta servisa atrašanās vieta. VRAA infrastruktūrā izmitinātiem servisiem URL parasti sāksies ar “laura8”, kas norāda uz VRAA serveri.

  
  

  Neskaidrību gadījumā aicinām sazināties ar VRAA, rakstot uz atbalsts@vraa.gov.lv

  1.att. Servisa fiziskā URL piemērs

! Līdz 2023.gada vidum iestādēm, kuru servisi ir izmitināti VRAA infrastruktūrā,  jāveic to pārnešana uz iestādes (vai uzturētāja) infrastruktūru. Lai servisa pārzinis vai tā izstrādātājs saņemtu servisu programmatūru, servisa pārzinim ir jāsazinās ar VRAA.

• Kas jādara, lai datu devējs varētu publicēt savus servisus API Pārvaldniekā?

Ir jāizpilda Programsaskarnes (API) publicēšanas procedūrā aprakstītus soļus.

• Kas jādara, lai datu ņēmējs varētu saņemtu piekļuvi datu devēja servisiem?

Ir jāizpilda Programsaskarnes (API) abonēšanas procedūrā aprakstītus soļus.

• Kāds galapunkts (endpoint) jānorāda, reģistrējot servisu API Pārvaldniekā?

  Servisam, kurš ir izmitināts iestādes infrastruktūrā, jānorāda URL, kas norāda uz servisa atrašanās vietu un ir sasniedzams citiem resursiem.

   



• Vai API Pārvaldniekā ir jāpublicē Integrācijas serviss vai Biznesa serviss?

  Tas ir atkarīgs no konkrētā servisa arhitektūras, tāpēc katrs gadījums ir jāizvērtē. Atsevišķi servisi var būt uzbūvēti tā, ka tos bez integrācijas servisa slāņa nebūs iespējams izsaukt. Detalizētāks apraksts par Integrācijas/Biznesa servisiem. 

• Kā izsaukt API Pārvaldniekā pārreģistrētu SOAP servisu?

  Integrācijas servisu izsaukšana, izmantojot API Pārvaldnieku detalizēti aprakstīta Datu apmaiņas izveides vadlīnijas, kā arī programmatūras piemēros, papildus informācija ir šeit.

  Izstrādājot jaunus e-pakalpojumus uz 2020.gada e-pakalpojumu platformas jāizmanto Pieprasījuma API, jeb RequestAPI. Detalizētāks apraksts Programmētāja rokasgrāmatā.

  
  

  Kā parametra targetUrl vērtība ir jānorāda API Pārvaldniekā reģistrētais servisa konteksts.

2.att. API konteksts / TargetURL vērtības piemērs

Parametru messageBody aizpilda ar pieprasījuma saturu XML formātā, kas veidots atbilstoši xsd shēmai, kas norādīta kā servisa ieejas parametriem.




Kā parametra messageType vērtība ir jānorāda VISS IS servisu katalogā norādītie ieejas parametri:

  3.att. Servisa ieejas parametri, kas jānorāda kā messageType vērtība

API Pārvaldnieka gadījumā IVISRequest aploksne tiek veidota automātiski ar RequestApi mikroservisu.




API Pārvaldniekā publicēta servisa testēšanai var izmantot bezmaksas rīku Postman  https://www.postman.com/downloads/

Lai izprastu integrācijas servisa darbības principus Pieprasījuma servisa gadījumā, var izmantot arī WS test rīku.

• Kā IS katalogā esošos SOAP servisus varēs izmantot API Pārvaldnieka gadījumā?

  Servisa turētājiestādei piederošs SOAP serviss, kas izstrādāts pēc IVIS.Request standarta, jāuzstāda iestādes infrastruktūrā. Lai šo SOAP servisu izmantotu API Pārvaldniekā, tas ir jāpublicē API Publicētājā (API Publisher), norādot end-point adresi, kura norāda uz servisa atrašanos turētājiestādes vidē.

  Jāņem vērā, ka API Pārvaldniekā netiek veikta XML aplokšņu validācija, kā arī dati, kas ir attiecināmi uz IVIS.Request shēmas struktūru API Pārvaldniekā netiek validēti, tāpēc ir jāizvertē, kā datus aizpildīt un apstrādāt iestādes sistēmas pusē, lai serviss neizdotu kļūdas paziņojumus.

  API Pārvaldnieka gadījumā ne REST, ne SOAP servisi nav jāpiegādā uz VRAA vidi, kā arī tiem netiek veikta akcepttestēšana kā tas bija līdz šim.

  Turētāiestādei API Pārvaldniekā jāveic pilnvērtīgs servisa apraksts, jāpievieno servisa dokumentācija, jānorāda kontaktinformācija turētājiestādes pusē, ja potenciālajam datu ņēmējam rodas papildu jautājumi par servisu. Servisa aprakstā var arī norādīt saites uz VRAA sadarbības procedūru VISS portālā.

• Kā esošie un API Pārvaldniekā izmantotie servisi ir salāgoti ar e-pakalpojumu ietvaru?

  Esošie IS katalogā publicētie servisi paralēli darbosies VRAA infrastruktūrā līdz netiks izslēgts Pieprasījumu serviss.

  Tas ir saistīts ar šī brīža tehniskajiem ierobežojamiem, kas neļauj esošiem e-pakalpojumiem izmantot vienlaicīgi gan API Pārvaldnieku, gan Pieprasījumu servisu, kā arī neļauj izsaukt API Pārvaldniekā publicētos ar PFAS operācijām (WSO2 scope) aizsargātos servisus.

  Jaunajā e-pakalpojumu infrastruktūrā būs iespējams izmantot tikai API Pārvaldniekā reģistrētos SOAP un/vai REST servisus.

• Kas jāņem vērā publicējot SOAP integrācijas servisus API Pārvaldniekā?

SOAP servisu izmantošanas ietvaros, API Pārvaldnieka funkcionalitāte neparedz IVISRequest elementu validāciju, bet ja nepieciešams, atsevišķus elementus var validēt izmantojot xsd shēmu.  API Pārvaldniekā biznesa IS izsaukumus nav nepieciešams savienot, kā tas tiek darīts Pieprasījumu servisa gadījumā. Parasti SOAP pieprasījuma elementu vērtības ir aizpildītas ar vērtībām no drošības talona un pieprasījuma galvenes.

Sīkāka informācija par SOAP integrācijas servisu izmantošanu API Pārvaldniekā ir pieejama ŠEIT.

• Vai IS katalogā reģistrētie SOAP servisi tiks pārnesti uz API Pārvaldnieku?

  Nē, IS katalogā šobrīd esošie SOAP servisi netiks pārnesti uz API Pārvaldnieku un reģistrēti API Publicētājā (API Publisher). Servisu turētājiestādēm jāizlemj – vai esošos servisus pārstrādās par REST un publicēs API Pārvaldniekā vai arī publicēs esošos SOAP atbilstoši aprakstītajam punktā “Kā IS katalogā esošos SOAP servisus varēs izmantot API Pārvaldnieka gadījumā?

• Kā datu devējam iespējams reģistrētajiem API ierobežot abonēšanas pieeju?

  API Publicētājā (API Publisher) reģistrētajiem servisiem iespējams ierobežot pieeju izmantojot operācijas/scopes. Reģistrējot SOAP servisu, ir iespējams tam norādīt tikai vienu kopīgu operāciju/scope uz visu servisu, bet reģistrējot REST servisu katrai metodei ir iespējams norādīt savu operāciju/scope.

  Jāņem vērā, ka jebkuram neaizsargātam ar operāciju/scope servisam, kurš ir publicēts API Pārvaldniekā iespējams pieteikties (Subscribe) jebkuram lietotājam, kuram ir Izstrādātāju portāla (API Devportal) autentifikācija.

• Vai iespējams dzēst nopublicēto servisu?

  Servisu ir iespējams dzēst tādā gadījumā, ja tam nav neviena abonementa. Ņemot vērā to, ka nopublicētos API pārvalda pati turētājiestāde, tad par API rediģēšanu, dzēšanu, metožu mainīšanu atbildību nes pati iestāde-datu devējs un veic komunikāciju ar abonementiem.

• Kā veikt atteikšanos no servisiem?

Lai atteiktos no abonētā API, jāveic sekojošas darbības API Izstrādātāju portāls (API Devportal):

4.attēls. API atteikšanās 1. un 2. solis.

5.attēls. API atteikšanās 3. un 4. solis.

6.attēls. API atteikšanās 5. solis.

• Vai ir iespējams veikt izmaiņas nopublicētajā servisā?

  API Publicētājā iestādei-datu devējam ir iespēja labot savu servisu aprakstus, nospiežot ikonu Edit un pēc labošanas pārpublicēt servisu.

• Vai API Pārvaldnieka interfeiss tiks tulkots latviešu valodā?

API Pārvaldnieka interfeisa valoda ir atkarīga no Jūsu interneta pārlūka iestatījumos norādītās noklusējuma valodas.