Унапређење АПИ инфраструктуре за тикетинг систем

TehničkaSpecifikacija Unapređenje API infrastrukture za tiketing sistem.docx ТЕХНИЧКА СПЕЦИФИКАЦИЈА УНАПРЕЂЕЊЕ АПИ ИНФРАСТРУКТУРЕ ЗА ТИКЕТИНГ СИСТЕМ Р. бр. Назив услуге Опис минималних техничких захтева Количина 1. Предмет и циљ набавке Предмет набавке је испорука, имплементација и техничка подршка за интегрисано решење за унапређење АПИ инфраструктуре тикетинг система еКарта. • централизовано управљање АПИ сервисима током целокупног животног циклуса; • контролисано излагање сервиса web, мобилним, интерним и партнерским системима; • примену јединствених правила приступа, обраде порука, контроле саобраћаја и заштите сервиса; • повећање расположивости, скалабилности, следљивости и оперативне поузданости тикетинг система. 1 2. Анализа постојећег стања и пројектовање решења Понуђач је у обавези да изврши снимање постојеће АПИ и интеграционе инфраструктуре и да изради предлог циљне архитектуре. • попис постојећих REST и SOAP сервиса, клијентских апликација, партнерских веза и зависности; • анализа саобраћаја, оптерећења, начина аутентикације, сертификата, логова и критичних тачака; • израда логичке и физичке архитектуре, мрежних токова, планова миграције и повратка на претходно стање; • дефинисање развојног/тестног и продукционог окружења и плана фазног увођења. 1 3. Управљање животним циклусом АПИ-ја Решење мора да садржи развојне и управљачке алате за моделовање, израду, тестирање, верзионисање, објављивање и повлачење АПИ сервиса. • креирање и измена REST АПИ дефиниција у складу са OpenAPI v2 и v3 спецификацијом; • увоз постојећих OpenAPI и WSDL дефиниција и формирање контролисаних приступних тачака; • подршка за REST и SOAP сервисе, паралелне верзије и управљање зависностима; • аутоматска валидација дефиниција са приказом места и описа неусаглашености; • контролисана промоција конфигурације кроз развојно, тестно, прихватно и продукционо окружење; • објављивање у изоловано sandbox окружење ради функционалног тестирања. 1 4. Централни приступни слој и управљање током порука Решење мора да обезбеди централни приступни слој између клијентских канала и постојећих апликативних сервиса, без потребе за изменом пословне логике постојећих апликација. • усмеравање захтева ка одговарајућим сервисима, баланс оптерећења и контролисано преусмеравање; • web базирани графички editor за дефинисање редоследа обраде захтева и одговора; • условна гранања на основу URL-а, метода, заглавља, параметара, идентитета клијента и садржаја поруке; • додавање, уклањање и измена заглавља и параметара, трансформација JSON/XML порука и мапирање формата; • стандардизовано управљање грешкама, прилагођавање повратних порука, позив додатних сервиса и селективно кеширање одговора. 1 5. Управљање идентитетом и приступом Сви приступи АПИ сервисима морају бити контролисани у складу са идентитетом клијентске апликације, корисника, партнера и мрежног извора. • подршка за OAuth 2.0, OpenID Connect, JWT, API key, HTTP Basic и сертификатску аутентикацију; • подршка за обострану TLS аутентикацију (mTLS) за интерне и партнерске интеграције; • валидација потписа, издаваоца, примаоца, рока важења и релевантних атрибута токена; • контрола приступа по АПИ-ју, операцији, HTTP методи, улози, апликацији и IP/мрежном извору; • интеграција са постојећим Active Directory/LDAP окружењем и раздвајање административних, развојних, аналитичких и порталских улога. 1 6. Контрола саобраћаја и отпорност на злоупотребе Решење мора да омогући централну примену правила којима се обезбеђује стабилан рад сервиса при редовном, наглом или нежељеном оптерећењу. • ограничење броја позива по временској јединици (rate limiting) и успоравање прекомерног саобраћаја (throttling); • дневне и месечне квоте по клијенту, партнеру, АПИ-ју, операцији или функционалном пакету; • ограничење истовремених веза, величине поруке, трајања захтева и броја понављања; • контрола наглог пораста саобраћаја и образаца који могу угрозити расположивост апликативних сервиса; • препознавање и ограничавање аутоматизованих покушаја пријаве, куповине, резервације, скенирања и масовног позивања; • листе дозвољених и забрањених IP адреса, опсега и мрежних зона. 1 7. Валидација и заштита АПИ порука Пре прослеђивања захтева ка тикетинг сервисима мора бити могућа валидација структуре, формата и дозвољеног садржаја поруке. • валидација JSON и XML порука према унапред дефинисаним шемама; • провера обавезних поља, типа, дужине, формата и дозвољених вредности података; • препознавање и блокирање образаца као што су SQL injection, command injection, path traversal и сродне злоупотребе; • контрола XML претњи, ентитета, прекомерне дубине и злонамерно формираних порука; • филтрирање неочекиваних HTTP метода, заглавља, типова садржаја и непознатих параметара; • креирање прилагођених правила и маскирање осетљивих података у логовима и аналитичким приказима. 1 8. Каталог АПИ-ја и портал за кориснике Решење мора да омогући систематизацију доступних АПИ сервиса и контролисану доделу права интерним и одобреним партнерским апликацијама. • груписање АПИ-ја у функционалне целине, производе или пакете са заједничким правилима; • креирање потребног броја каталога или простора за раздвајање окружења, организационих јединица и група корисника; • регистрација клијентских апликација, издавање приступних података и одобравање приступа пакетима; • дефинисање планова коришћења, квота и ограничења; • портал са аутоматски ажурираном документацијом, примерима позива, условима приступа и статусом АПИ сервиса. 1 9. Тестирање АПИ сервиса Решење мора да садржи алате за функционално, интеграционо и аутоматизовано тестирање АПИ позива. • интерактивно позивање АПИ-ја из корисничког интерфејса уз подешавање параметара, заглавља и тела поруке; • приказ захтева, одговора, HTTP статуса, времена одзива и примењених корака обраде; • аутоматизовано спољно тестирање помоћу клијентског алата који је део понуђеног решења или се испоручује без додатне накнаде; • локално тестирање дефиниција и политика на рачунару развојног корисника; • чување, верзионисање и поновно извршавање тест сценарија. 1 10. Надзор, аналитика, алармирање и ревизијски траг Решење мора да обезбеди јединствен оперативни увид у рад свих објављених АПИ сервиса и инфраструктурних компоненти. • приказ броја позива, успешности, грешака, времена одзива, оптерећења, активних клијената и статуса компоненти; • аналитика по АПИ-ју, операцији, верзији, клијенту, партнеру, коду одговора и временском периоду; • праћење SLA показатеља, трендова, најчешћих грешака и спорих операција; • конфигурисање прагова и слање обавештења путем електронске поште и интеграција са системом за надзор; • извоз извештаја и оперативних података у стандардним форматима и слање догађаја ка syslog/SIEM систему; • ревизијски траг административних измена са подацима о кориснику, времену и промењеним вредностима. 1 11. Архитектура, инсталација и интеграције Све кључне компоненте морају бити инсталиране у инфраструктури Наручиоца (on-premise), тако да продукциона обрада АПИ порука не зависи од јавног cloud сервиса. • извршна компонента за прихват спољних захтева мора подржавати безбедно распоређивање у ДМЗ зони, као ојачана виртуелна компонента или технички еквивалентно изоловано решење; • подршка за високу расположивост без јединствене тачке отказа и хоризонтално проширење капацитета; • подршка за виртуелизована окружења, а пожељно и Kubernetes/OpenShift или еквивалентне платформе; • интеграција најмање са AD/LDAP, SMTP, DNS, NTP, PKI, syslog/SIEM и постојећим HTTP(S) сервисима; • централизовано управљање TLS сертификатима, упозорење пре истека и интеграција са постојећом PKI инфраструктуром; • документована израда резервних копија, опоравак конфигурације и прелазак на резервну инстанцу. 1 12. Капацитет, лиценце и произвођачка подршка Испоручене лиценце и права коришћења морају обухватити целокупно решење и све компоненте потребне за испуњење ове спецификације. • капацитет од најмање 5.000.000 АПИ позива месечно, односно 60.000.000 позива током 12 месеци; • могућност успостављања развојног/тестног и продукционог окружења и потребног броја инстанци за високу расположивост; • довољан број административних, развојних, аналитичких и порталских корисника без накнадне набавке основних корисничких права; • трајање лиценце и произвођачке подршке најмање 12 месеци од продукционог прихватања; • приступ исправкама, безбедносним закрпама и новим верзијама обухваћеним правом на надоградњу; • пријем и решавање инцидената, удаљена дијагностика и ескалација ка произвођачу. 1 13. Имплементација, пилот миграција и пуштање у рад Понуђач је у обавези да обезбеди све услуге потребне за стављање решења у продуктиван рад. • инсталација, основно ојачавање и конфигурација свих уговорених компоненти; • интеграција са инфраструктурним сервисима Наручиоца и конфигурација почетног скупа приступних, саобраћајних и валидационих правила; • миграција и објављивање најмање три репрезентативна типа интеграције: јавни REST АПИ, интерни/партнерски сервис и сервис који захтева трансформацију или посебно управљање грешкама; • функционално, интеграционо, безбедносно и тестирање оптерећења; • продукционо пуштање у рад уз план повратка и подршку у стабилизационом периоду. 1 14. Документација, обука и критеријуми прихватања Понуђач мора да преда комплетну документацију и спроведе обуку, а прихватање решења се врши на основу документованих функционалних и техничких провера. • документ циљне архитектуре и мрежних токова, инсталациона и конфигурациона документација; • опис имплементираних АПИ-ја, правила, интеграција, сертификата, резервних копија и процедура опоравка; • администраторско, оперативно и развојно упутство и as-built документација; • обука администратора/оперативног тима и развојног/интеграционог тима; • пријемне провере: инсталација, интеграције, објављивање пилот АПИ-ја, приступ, контрола саобраћаја, валидација порука, надзор, висока расположивост и тест оптерећења; • сви уочени недостаци морају бити отклоњени пре коначног прихватања. 1 Напомена: Сви захтеви су дефинисани функционално. Прихватљиво је свако технички еквивалентно решење које у целости испуњава минималне захтеве, без обзира на назив производа, произвођача или начин паковања компоненти. Додатне услуге: Подршка 24/7 Потпуна усклађеност са законом Могућност прилагођавања апликације и повезивања са екстерним системима на захтев корисника Услуга ће бити пружана на локацији Наручиоца, Немањина 6, Београд Obrazac strukture cene-61.docx ОБРАЗАЦ СТРУКТУРЕ ЦЕНЕза јавну набавку унапређења АПИ инфраструктуре за тикетинг систем, у отвореном поступку ЈН бр. 61/2026 Редни број Предмет услуге Јед.мере Количина Јединична цена без ПДВ-а у РСД Укупна вредност без ПДВ-а у РСД 1 2 3 4 5 6 1. Лиценце и сервиси ком 1 2. Имплементација ком 1 3. Техничка подршка радни сат 1 Укупна вредност без ПДВ-а у РСД ПДВ ______ % Укупна вредност са ПДВ-ом у РСД Датум: М.П. Потпис понуђача Напомена: *Јединична цена садржи све основне елементе структуре цене, тако да понуђена цена покрива све трошкове које понуђач има у реализацији набавке. Образац оверава и потписује овлашћено тј. одговорно лице. * Укупна вредност понуде служи само за оцену понуда. Уговор ће се реализовати у оквиру процењене вредности набавке. Kriterijumi za dodelu ugovora.pdf КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ 1 Наручилац: "Србијавоз" а.д. Београд 109108438 Назив поступка: Унапређење АПИ инфраструктуре за тикетинг систем Референтни број: 61/2026 КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ Део конкурсне документације који је генерисан путем Портала у случају када је наручилац означио опцију аутоматског рангирања понуда на Порталу јавних набавки Назив предмета / партије: Унапређење АПИ инфраструктуре за тикетинг систем Наручилац је дефинисао критеријуме за доделу уговора на основу: Цене и критеријума квалитета Изабран начин рангирања прихватљивих понуда (формула): Аутоматско рангирање Укупан број бодова једнак је збиру бодова за сваки критеријум. Формуле су наведене доле уз сваки критеријум. Бу = Бц + ∑ к Бк - укупан број бодоваБу - број бодова ценеБц - критеријумк - број бодова критеријумаБк Цена Цена - пондер (нумеричка вредност): 90,00 Формула за израчунавање бодова за критеријум цене: Максимални број бодова најбољој понуђеној вредности, остале понуђене вредности бодују се у односу на најбољу вредност Б = минЦ Ц × П - број бодова ценеБ - цена најниже понудеминЦ - понуђена ценаЦ - вредност пондера ценеП Код релативног модела оцене, број бодова који се добија за критеријум за поједину понуду зависи од вредности које су понудили други понуђачи. Најбоља понуђена вредност добија максималан број бодова (нумеричка пондерисана вредност). Остале понуде добијају број бодова у односу на најбољу понуђену вредност. Критеријуми квалитета КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ 2 Назив: Рок извршења Јединица мере: месец Пондер (нумеричка вредност): 10,00 Вредност за овај критеријум може да буде само цели број. Опис и појашњење критеријума и докази потребни за проверу: Рок извршења: максимално 6 месеци од дана ступања уговора на снагу Повољнија је  већа понуђена вредност  мања понуђена вредност Формула за израчунавање бодова за критеријум: Максимални број бодова најбољој понуђеној вредности, остале понуђене вредности бодују се у односу на најбољу вредност Код релативног модела оцене, број бодова који се добија за критеријум за поједину понуду зависи од вредности које су понудили други понуђачи. Најбоља понуђена вредност добија максималан број бодова (нумеричка пондерисана вредност). Остале понуде добијају број бодова у односу на најбољу понуђену вредност. Ограничења: Ограничена је минимална вредност коју понуђач може да понуди Минимална дозвољена вредност: 1,00 Ограничена је максимална вредност коју понуђач може да понуди Максимална дозвољена вредност: 6,00 Б = минВ В × П - број бодова критеријумаБ - вредност пондера критеријумаП - понуђена вредност за критеријумВ - највећа понуђена вредност за критеријумма𝑥В - најмања понуђена вредност за критеријумминВ - максимална дозвољена вредност за критеријумВма𝑥 - минимална дозвољена вредност за критеријумВмин Резервни критеријуми Примена жреба Уколико након рангирања на основу критеријума за доделу и резервних критеријума (ако су дефинисани) није могуће донети одлуку о додели уговора, наручилац ће уговор доделити понуђачу који буде извучен путем жреба. Наручилац ће обавестити све понуђаче који су поднели понуде о датуму када ће се одржати извлачење путем жреба. Жребом ће бити обухваћене само оне понуде које су најповољније након рангирања на основу критеријума за доделу и резервних критеријума (ако су дефинисани). Извлачење путем жреба наручилац ће извршити јавно, у присуству понуђача, и то тако што ће називе понуђача исписати на одвојеним папирима, који су исте величине и боје, те ће све те папире ставити у провидну кутију одакле ће прво извући само КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ 3 један папир. Понуђачу чији назив буде на извученом папиру ће бити додељен уговор. Након извлачења првог папира наручилац извлачи преостале папире један по један те сходно редоследу којим су извучени рангира преостале понуђаче. Понуђачима који не присуствују овом поступку, наручилац ће доставити записник извлачења путем жреба.