Unapređenje API infrastrukture za tiketing sistem

TehničkaSpecifikacija Unapređenje API infrastrukture za tiketing sistem.docx TEHNIČKA SPECIFIKACIJA UNAPREĐENJE API INFRASTRUKTURE ZA TIKETING SISTEM R. br. Naziv usluge Opis minimalnih tehničkih zahteva Količina 1. Predmet i cilj nabavke Predmet nabavke je isporuka, implementacija i tehnička podrška za integrisano rešenje za unapređenje API infrastrukture tiketing sistema eKarta. • centralizovano upravljanje API servisima tokom celokupnog životnog ciklusa; • kontrolisano izlaganje servisa web, mobilnim, internim i partnerskim sistemima; • primenu jedinstvenih pravila pristupa, obrade poruka, kontrole saobraćaja i zaštite servisa; • povećanje raspoloživosti, skalabilnosti, sledljivosti i operativne pouzdanosti tiketing sistema. 1 2. Analiza postojećeg stanja i projektovanje rešenja Ponuđač je u obavezi da izvrši snimanje postojeće API i integracione infrastrukture i da izradi predlog ciljne arhitekture. • popis postojećih REST i SOAP servisa, klijentskih aplikacija, partnerskih veza i zavisnosti; • analiza saobraćaja, opterećenja, načina autentikacije, sertifikata, logova i kritičnih tačaka; • izrada logičke i fizičke arhitekture, mrežnih tokova, planova migracije i povratka na prethodno stanje; • definisanje razvojnog/testnog i produkcionog okruženja i plana faznog uvođenja. 1 3. Upravljanje životnim ciklusom API-ja Rešenje mora da sadrži razvojne i upravljačke alate za modelovanje, izradu, testiranje, verzionisanje, objavljivanje i povlačenje API servisa. • kreiranje i izmena REST API definicija u skladu sa OpenAPI v2 i v3 specifikacijom; • uvoz postojećih OpenAPI i WSDL definicija i formiranje kontrolisanih pristupnih tačaka; • podrška za REST i SOAP servise, paralelne verzije i upravljanje zavisnostima; • automatska validacija definicija sa prikazom mesta i opisa neusaglašenosti; • kontrolisana promocija konfiguracije kroz razvojno, testno, prihvatno i produkciono okruženje; • objavljivanje u izolovano sandbox okruženje radi funkcionalnog testiranja. 1 4. Centralni pristupni sloj i upravljanje tokom poruka Rešenje mora da obezbedi centralni pristupni sloj između klijentskih kanala i postojećih aplikativnih servisa, bez potrebe za izmenom poslovne logike postojećih aplikacija. • usmeravanje zahteva ka odgovarajućim servisima, balans opterećenja i kontrolisano preusmeravanje; • web bazirani grafički editor za definisanje redosleda obrade zahteva i odgovora; • uslovna grananja na osnovu URL-a, metoda, zaglavlja, parametara, identiteta klijenta i sadržaja poruke; • dodavanje, uklanjanje i izmena zaglavlja i parametara, transformacija JSON/XML poruka i mapiranje formata; • standardizovano upravljanje greškama, prilagođavanje povratnih poruka, poziv dodatnih servisa i selektivno keširanje odgovora. 1 5. Upravljanje identitetom i pristupom Svi pristupi API servisima moraju biti kontrolisani u skladu sa identitetom klijentske aplikacije, korisnika, partnera i mrežnog izvora. • podrška za OAuth 2.0, OpenID Connect, JWT, API key, HTTP Basic i sertifikatsku autentikaciju; • podrška za obostranu TLS autentikaciju (mTLS) za interne i partnerske integracije; • validacija potpisa, izdavaoca, primaoca, roka važenja i relevantnih atributa tokena; • kontrola pristupa po API-ju, operaciji, HTTP metodi, ulozi, aplikaciji i IP/mrežnom izvoru; • integracija sa postojećim Active Directory/LDAP okruženjem i razdvajanje administrativnih, razvojnih, analitičkih i portalskih uloga. 1 6. Kontrola saobraćaja i otpornost na zloupotrebe Rešenje mora da omogući centralnu primenu pravila kojima se obezbeđuje stabilan rad servisa pri redovnom, naglom ili neželjenom opterećenju. • ograničenje broja poziva po vremenskoj jedinici (rate limiting) i usporavanje prekomernog saobraćaja (throttling); • dnevne i mesečne kvote po klijentu, partneru, API-ju, operaciji ili funkcionalnom paketu; • ograničenje istovremenih veza, veličine poruke, trajanja zahteva i broja ponavljanja; • kontrola naglog porasta saobraćaja i obrazaca koji mogu ugroziti raspoloživost aplikativnih servisa; • prepoznavanje i ograničavanje automatizovanih pokušaja prijave, kupovine, rezervacije, skeniranja i masovnog pozivanja; • liste dozvoljenih i zabranjenih IP adresa, opsega i mrežnih zona. 1 7. Validacija i zaštita API poruka Pre prosleđivanja zahteva ka tiketing servisima mora biti moguća validacija strukture, formata i dozvoljenog sadržaja poruke. • validacija JSON i XML poruka prema unapred definisanim šemama; • provera obaveznih polja, tipa, dužine, formata i dozvoljenih vrednosti podataka; • prepoznavanje i blokiranje obrazaca kao što su SQL injection, command injection, path traversal i srodne zloupotrebe; • kontrola XML pretnji, entiteta, prekomerne dubine i zlonamerno formiranih poruka; • filtriranje neočekivanih HTTP metoda, zaglavlja, tipova sadržaja i nepoznatih parametara; • kreiranje prilagođenih pravila i maskiranje osetljivih podataka u logovima i analitičkim prikazima. 1 8. Katalog API-ja i portal za korisnike Rešenje mora da omogući sistematizaciju dostupnih API servisa i kontrolisanu dodelu prava internim i odobrenim partnerskim aplikacijama. • grupisanje API-ja u funkcionalne celine, proizvode ili pakete sa zajedničkim pravilima; • kreiranje potrebnog broja kataloga ili prostora za razdvajanje okruženja, organizacionih jedinica i grupa korisnika; • registracija klijentskih aplikacija, izdavanje pristupnih podataka i odobravanje pristupa paketima; • definisanje planova korišćenja, kvota i ograničenja; • portal sa automatski ažuriranom dokumentacijom, primerima poziva, uslovima pristupa i statusom API servisa. 1 9. Testiranje API servisa Rešenje mora da sadrži alate za funkcionalno, integraciono i automatizovano testiranje API poziva. • interaktivno pozivanje API-ja iz korisničkog interfejsa uz podešavanje parametara, zaglavlja i tela poruke; • prikaz zahteva, odgovora, HTTP statusa, vremena odziva i primenjenih koraka obrade; • automatizovano spoljno testiranje pomoću klijentskog alata koji je deo ponuđenog rešenja ili se isporučuje bez dodatne naknade; • lokalno testiranje definicija i politika na računaru razvojnog korisnika; • čuvanje, verzionisanje i ponovno izvršavanje test scenarija. 1 10. Nadzor, analitika, alarmiranje i revizijski trag Rešenje mora da obezbedi jedinstven operativni uvid u rad svih objavljenih API servisa i infrastrukturnih komponenti. • prikaz broja poziva, uspešnosti, grešaka, vremena odziva, opterećenja, aktivnih klijenata i statusa komponenti; • analitika po API-ju, operaciji, verziji, klijentu, partneru, kodu odgovora i vremenskom periodu; • praćenje SLA pokazatelja, trendova, najčešćih grešaka i sporih operacija; • konfigurisanje pragova i slanje obaveštenja putem elektronske pošte i integracija sa sistemom za nadzor; • izvoz izveštaja i operativnih podataka u standardnim formatima i slanje događaja ka syslog/SIEM sistemu; • revizijski trag administrativnih izmena sa podacima o korisniku, vremenu i promenjenim vrednostima. 1 11. Arhitektura, instalacija i integracije Sve ključne komponente moraju biti instalirane u infrastrukturi Naručioca (on-premise), tako da produkciona obrada API poruka ne zavisi od javnog cloud servisa. • izvršna komponenta za prihvat spoljnih zahteva mora podržavati bezbedno raspoređivanje u DMZ zoni, kao ojačana virtuelna komponenta ili tehnički ekvivalentno izolovano rešenje; • podrška za visoku raspoloživost bez jedinstvene tačke otkaza i horizontalno proširenje kapaciteta; • podrška za virtuelizovana okruženja, a poželjno i Kubernetes/OpenShift ili ekvivalentne platforme; • integracija najmanje sa AD/LDAP, SMTP, DNS, NTP, PKI, syslog/SIEM i postojećim HTTP(S) servisima; • centralizovano upravljanje TLS sertifikatima, upozorenje pre isteka i integracija sa postojećom PKI infrastrukturom; • dokumentovana izrada rezervnih kopija, oporavak konfiguracije i prelazak na rezervnu instancu. 1 12. Kapacitet, licence i proizvođačka podrška Isporučene licence i prava korišćenja moraju obuhvatiti celokupno rešenje i sve komponente potrebne za ispunjenje ove specifikacije. • kapacitet od najmanje 5.000.000 API poziva mesečno, odnosno 60.000.000 poziva tokom 12 meseci; • mogućnost uspostavljanja razvojnog/testnog i produkcionog okruženja i potrebnog broja instanci za visoku raspoloživost; • dovoljan broj administrativnih, razvojnih, analitičkih i portalskih korisnika bez naknadne nabavke osnovnih korisničkih prava; • trajanje licence i proizvođačke podrške najmanje 12 meseci od produkcionog prihvatanja; • pristup ispravkama, bezbednosnim zakrpama i novim verzijama obuhvaćenim pravom na nadogradnju; • prijem i rešavanje incidenata, udaljena dijagnostika i eskalacija ka proizvođaču. 1 13. Implementacija, pilot migracija i puštanje u rad Ponuđač je u obavezi da obezbedi sve usluge potrebne za stavljanje rešenja u produktivan rad. • instalacija, osnovno ojačavanje i konfiguracija svih ugovorenih komponenti; • integracija sa infrastrukturnim servisima Naručioca i konfiguracija početnog skupa pristupnih, saobraćajnih i validacionih pravila; • migracija i objavljivanje najmanje tri reprezentativna tipa integracije: javni REST API, interni/partnerski servis i servis koji zahteva transformaciju ili posebno upravljanje greškama; • funkcionalno, integraciono, bezbednosno i testiranje opterećenja; • produkciono puštanje u rad uz plan povratka i podršku u stabilizacionom periodu. 1 14. Dokumentacija, obuka i kriterijumi prihvatanja Ponuđač mora da preda kompletnu dokumentaciju i sprovede obuku, a prihvatanje rešenja se vrši na osnovu dokumentovanih funkcionalnih i tehničkih provera. • dokument ciljne arhitekture i mrežnih tokova, instalaciona i konfiguraciona dokumentacija; • opis implementiranih API-ja, pravila, integracija, sertifikata, rezervnih kopija i procedura oporavka; • administratorsko, operativno i razvojno uputstvo i as-built dokumentacija; • obuka administratora/operativnog tima i razvojnog/integracionog tima; • prijemne provere: instalacija, integracije, objavljivanje pilot API-ja, pristup, kontrola saobraćaja, validacija poruka, nadzor, visoka raspoloživost i test opterećenja; • svi uočeni nedostaci moraju biti otklonjeni pre konačnog prihvatanja. 1 Napomena: Svi zahtevi su definisani funkcionalno. Prihvatljivo je svako tehnički ekvivalentno rešenje koje u celosti ispunjava minimalne zahteve, bez obzira na naziv proizvoda, proizvođača ili način pakovanja komponenti. Dodatne usluge: Podrška 24/7 Potpuna usklađenost sa zakonom Mogućnost prilagođavanja aplikacije i povezivanja sa eksternim sistemima na zahtev korisnika Usluga će biti pružana na lokaciji Naručioca, Nemanjina 6, Beograd Obrazac strukture cene-61.docx OBRAZAC STRUKTURE CENEza javnu nabavku unapređenja API infrastrukture za tiketing sistem, u otvorenom postupku JN br. 61/2026 Redni broj Predmet usluge Jed.mere Količina Jedinična cena bez PDV-a u RSD Ukupna vrednost bez PDV-a u RSD 1 2 3 4 5 6 1. Licence i servisi kom 1 2. Implementacija kom 1 3. Tehnička podrška radni sat 1 Ukupna vrednost bez PDV-a u RSD PDV ______ % Ukupna vrednost sa PDV-om u RSD Datum: M.P. Potpis ponuđača Napomena: *Jedinična cena sadrži sve osnovne elemente strukture cene, tako da ponuđena cena pokriva sve troškove koje ponuđač ima u realizaciji nabavke. Obrazac overava i potpisuje ovlašćeno tj. odgovorno lice. * Ukupna vrednost ponude služi samo za ocenu ponuda. Ugovor će se realizovati u okviru procenjene vrednosti nabavke. Kriterijumi za dodelu ugovora.pdf KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE 1 Naručilac: "Srbijavoz" a.d. Beograd 109108438 Naziv postupka: Unapređenje API infrastrukture za tiketing sistem Referentni broj: 61/2026 KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE Deo konkursne dokumentacije koji je generisan putem Portala u slučaju kada je naručilac označio opciju automatskog rangiranja ponuda na Portalu javnih nabavki Naziv predmeta / partije: Unapređenje API infrastrukture za tiketing sistem Naručilac je definisao kriterijume za dodelu ugovora na osnovu: Cene i kriterijuma kvaliteta Izabran način rangiranja prihvatljivih ponuda (formula): Automatsko rangiranje Ukupan broj bodova jednak je zbiru bodova za svaki kriterijum. Formule su navedene dole uz svaki kriterijum. Bu = Bc + ∑ k Bk - ukupan broj bodovaBu - broj bodova ceneBc - kriterijumk - broj bodova kriterijumaBk Cena Cena - ponder (numerička vrednost): 90,00 Formula za izračunavanje bodova za kriterijum cene: Maksimalni broj bodova najboljoj ponuđenoj vrednosti, ostale ponuđene vrednosti boduju se u odnosu na najbolju vrednost B = minC C × P - broj bodova ceneB - cena najniže ponudeminC - ponuđena cenaC - vrednost pondera ceneP Kod relativnog modela ocene, broj bodova koji se dobija za kriterijum za pojedinu ponudu zavisi od vrednosti koje su ponudili drugi ponuđači. Najbolja ponuđena vrednost dobija maksimalan broj bodova (numerička ponderisana vrednost). Ostale ponude dobijaju broj bodova u odnosu na najbolju ponuđenu vrednost. Kriterijumi kvaliteta KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE 2 Naziv: Rok izvršenja Jedinica mere: mesec Ponder (numerička vrednost): 10,00 Vrednost za ovaj kriterijum može da bude samo celi broj. Opis i pojašnjenje kriterijuma i dokazi potrebni za proveru: Rok izvršenja: maksimalno 6 meseci od dana stupanja ugovora na snagu Povoljnija je  veća ponuđena vrednost  manja ponuđena vrednost Formula za izračunavanje bodova za kriterijum: Maksimalni broj bodova najboljoj ponuđenoj vrednosti, ostale ponuđene vrednosti boduju se u odnosu na najbolju vrednost Kod relativnog modela ocene, broj bodova koji se dobija za kriterijum za pojedinu ponudu zavisi od vrednosti koje su ponudili drugi ponuđači. Najbolja ponuđena vrednost dobija maksimalan broj bodova (numerička ponderisana vrednost). Ostale ponude dobijaju broj bodova u odnosu na najbolju ponuđenu vrednost. Ograničenja: Ograničena je minimalna vrednost koju ponuđač može da ponudi Minimalna dozvoljena vrednost: 1,00 Ograničena je maksimalna vrednost koju ponuđač može da ponudi Maksimalna dozvoljena vrednost: 6,00 B = minV V × P - broj bodova kriterijumaB - vrednost pondera kriterijumaP - ponuđena vrednost za kriterijumV - najveća ponuđena vrednost za kriterijumma𝑥V - najmanja ponuđena vrednost za kriterijumminV - maksimalna dozvoljena vrednost za kriterijumVma𝑥 - minimalna dozvoljena vrednost za kriterijumVmin Rezervni kriterijumi Primena žreba Ukoliko nakon rangiranja na osnovu kriterijuma za dodelu i rezervnih kriterijuma (ako su definisani) nije moguće doneti odluku o dodeli ugovora, naručilac će ugovor dodeliti ponuđaču koji bude izvučen putem žreba. Naručilac će obavestiti sve ponuđače koji su podneli ponude o datumu kada će se održati izvlačenje putem žreba. Žrebom će biti obuhvaćene samo one ponude koje su najpovoljnije nakon rangiranja na osnovu kriterijuma za dodelu i rezervnih kriterijuma (ako su definisani). Izvlačenje putem žreba naručilac će izvršiti javno, u prisustvu ponuđača, i to tako što će nazive ponuđača ispisati na odvojenim papirima, koji su iste veličine i boje, te će sve te papire staviti u providnu kutiju odakle će prvo izvući samo KRITERIJUMI ZA DODELU UGOVORA I OSTALI ZAHTEVI NABAVKE 3 jedan papir. Ponuđaču čiji naziv bude na izvučenom papiru će biti dodeljen ugovor. Nakon izvlačenja prvog papira naručilac izvlači preostale papire jedan po jedan te shodno redosledu kojim su izvučeni rangira preostale ponuđače. Ponuđačima koji ne prisustvuju ovom postupku, naručilac će dostaviti zapisnik izvlačenja putem žreba.