Designing RESTful API for the e-procurement system in private sector

The software for the e-procurement system was developed based on .NET Core RESTful API with Open API specifications. The server side uses RESTful API which ensures compatibility with the majority of clients and enables them to exchange information in JSON format. The authentication and authorization...

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2021
Автори:	Doroshenko, А.Yu., Bodak, B.V.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	Інститут програмних систем НАН України 2021
Теми:	e-procurement RESTful API OpenAPI v3.0 API architecture scalable software systems UDC 004.4'24
Онлайн доступ:	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/447
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Problems in programming
Завантажити файл:

Репозитарії

Problems in programming

id	pp_isofts_kiev_ua-article-447
record_format	ojs
resource_txt_mv	ppisoftskievua/bb/8a31d78be2c0ad52432b79697add67bb.pdf
spelling	pp_isofts_kiev_ua-article-4472024-04-26T22:25:01Z Designing RESTful API for the e-procurement system in private sector Моделювання RESTFUL API для системи автоматизації приватних електронних закупівель Doroshenko, А.Yu. Bodak, B.V. e-procurement; RESTful API; OpenAPI v3.0; API architecture; scalable software systems UDC 004.4'24 електронні закупівлі; RESTful API; OpenAPI v3.0; архітектура API; масштабовані системи автоматизації УДК 004.4'24 The software for the e-procurement system was developed based on .NET Core RESTful API with Open API specifications. The server side uses RESTful API which ensures compatibility with the majority of clients and enables them to exchange information in JSON format. The authentication and authorization flow was implemented using OAuth open standard paired with Microsoft Identity Service. User roles and functionality were handled with a standalone service for authentication and registration that made our system efficient and scalable. Business logic was designed to be split into micro-services accessible through routing controllers. This approach allowed us to separate the responsibilities between the server and the client side. Special authorization headers passed during modification queries allowed us to control and restrict access to particular resources for unauthorized users. The distributed cache mechanism inside the data repository level was used in order to increase the responsiveness of the system. The state handling subsystem was designed utilizing Finite State Machine concepts. The developed system was verified using unit and integration tests.Prombles in programming 2021; 1: 03-15 Розроблено програмний засіб для автоматизації електронних закупівель на основі .NET Core RESTful API з використанням специфікацій OpenAPI v3.0. Реалізовано авторизацію користувачів системи, постачальників та замовників, за допомогою відкритого стандарту OAuth та Microsoft Identity Server. Для скорочення часу відгуку системи здійснено кешування даних на рівні репозиторію за підтримки розподіленного кешу. Створено підсистему для обробки та переходу між станами закупівель на основі скінченного автомату станів. Проведено випробування розробленого програмного засобу з використанням модульних та інтеграційних тестів.Prombles in programming 2021; 1: 03-15 Інститут програмних систем НАН України 2021-04-23 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/447 10.15407/pp2021.01.003 PROBLEMS IN PROGRAMMING; No 1 (2021); 3-15 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2021); 3-15 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2021); 3-15 1727-4907 10.15407/pp2021.01 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/447/451 Copyright (c) 2021 PROBLEMS IN PROGRAMMING
institution	Problems in programming
baseUrl_str	https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date	2024-04-26T22:25:01Z
collection	OJS
language	Ukrainian
topic	e-procurement RESTful API OpenAPI v3.0 API architecture scalable software systems UDC 004.4'24
spellingShingle	e-procurement RESTful API OpenAPI v3.0 API architecture scalable software systems UDC 004.4'24 Doroshenko, А.Yu. Bodak, B.V. Designing RESTful API for the e-procurement system in private sector
topic_facet	e-procurement RESTful API OpenAPI v3.0 API architecture scalable software systems UDC 004.4'24 електронні закупівлі RESTful API OpenAPI v3.0 архітектура API масштабовані системи автоматизації УДК 004.4'24
format	Article
author	Doroshenko, А.Yu. Bodak, B.V.
author_facet	Doroshenko, А.Yu. Bodak, B.V.
author_sort	Doroshenko, А.Yu.
title	Designing RESTful API for the e-procurement system in private sector
title_short	Designing RESTful API for the e-procurement system in private sector
title_full	Designing RESTful API for the e-procurement system in private sector
title_fullStr	Designing RESTful API for the e-procurement system in private sector
title_full_unstemmed	Designing RESTful API for the e-procurement system in private sector
title_sort	designing restful api for the e-procurement system in private sector
title_alt	Моделювання RESTFUL API для системи автоматизації приватних електронних закупівель
description	The software for the e-procurement system was developed based on .NET Core RESTful API with Open API specifications. The server side uses RESTful API which ensures compatibility with the majority of clients and enables them to exchange information in JSON format. The authentication and authorization flow was implemented using OAuth open standard paired with Microsoft Identity Service. User roles and functionality were handled with a standalone service for authentication and registration that made our system efficient and scalable. Business logic was designed to be split into micro-services accessible through routing controllers. This approach allowed us to separate the responsibilities between the server and the client side. Special authorization headers passed during modification queries allowed us to control and restrict access to particular resources for unauthorized users. The distributed cache mechanism inside the data repository level was used in order to increase the responsiveness of the system. The state handling subsystem was designed utilizing Finite State Machine concepts. The developed system was verified using unit and integration tests.Prombles in programming 2021; 1: 03-15
publisher	Інститут програмних систем НАН України
publishDate	2021
url	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/447
work_keys_str_mv	AT doroshenkoayu designingrestfulapifortheeprocurementsysteminprivatesector AT bodakbv designingrestfulapifortheeprocurementsysteminprivatesector AT doroshenkoayu modelûvannârestfulapidlâsistemiavtomatizacííprivatnihelektronnihzakupívelʹ AT bodakbv modelûvannârestfulapidlâsistemiavtomatizacííprivatnihelektronnihzakupívelʹ
first_indexed	2024-09-16T04:08:42Z
last_indexed	2024-09-16T04:08:42Z
_version_	1818568480944816128
fulltext	Інструментальні засоби та середовища програмування © А.Ю. Дорошенко, Б.В. Бодак, 2021 ISSN 1727-4907. Проблеми програмування. 2021. № 10 3 УДК 004.4'24 https://doi.org/10.15407/pp2021.01.003 А.Ю. Дорошенко, Б.В. Бодак МОДЕЛЮВАННЯ RESTFUL API ДЛЯ СИСТЕМИ АВТОМАТИЗАЦІЇ ПРИВАТНИХ ЕЛЕКТРОННИХ ЗАКУПІВЕЛЬ Розроблено програмний засіб для автоматизації електронних закупівель на основі .NET Core RESTful API з використанням специфікацій OpenAPI v3.0. Реалізовано авторизацію користувачів системи, пос- тачальників та замовників, за допомогою відкритого стандарту OAuth та Microsoft Identity Server. Для скорочення часу відгуку системи здійснено кешування даних на рівні репозиторію за підтримки розпо- діленного кешу. Створено підсистему для обробки та переходу між станами закупівель на основі скін- ченного автомату станів. Проведено випробування розробленого програмного засобу з використанням модульних та інтеграційних тестів. Ключові слова: електронні закупівлі, RESTful API, OpenAPI v3.0, архітектура API, масштабовані сис- теми автоматизації. Вступ Автоматизація процесів у системах закупівель набула широкого використання в багатьох країнах Європи та світу [1]. Як свідчить досвід європейських країн ство- рення системи електронних торгів дозво- ляє суттєво зменшити витрати державних коштів замовниками торгів на придбання предметів закупівлі, організацію та прове- дення закупівельного процесу; дає змогу безперешкодного, щодобового он-лайн до- ступу до інформації всіх зацікавлених осіб; забезпечує відкритість та прозорість на всіх стадіях закупівель; скорочує паперо- вий документообіг у цій сфері; створює рі- вний доступ до накопичуваної інформації та рівні умови конкуренції між постачаль- никами; полегшує роботу контролюючих та правоохоронних органів; попереджує зловживання та корупційні прояви у сфері закупівель тощо. Зазвичай, подібні систе- ми автоматизації тендерних закупівель складаються з декількох модулів, серед яких можна виділити кабінет замовника, постачальника, та модуль аукціону. Мета даної роботи – створення серверної части- ни системи автоматизації електронних за- купівель для приватного бізнесу. Основний фактор у системі елект- ронних закупівель – аукціон, а точніше йо- го зворотня форма. Подібний тип прийня- то називати «редукціоном», оскільки це аукціон, у якому перемагає найбільш еко- номічно вигідна пропозиція. Згідно сайту Business Dictionary, зворотній аукціон – це «Тип аукціону, у якому декілька постача- льників пропонують свої товари та змага- ються за ціну, яка буде прийнятою для за- мовника. Замовник зазвичай має можли- вість прийняти будь-яку пропозицію або відхилити всі пропозиції» [2]. Наявність даного типу аукціону головний критерій при аналізі існуючих рішень на ринку. Станом на даний момент існує декі- лька систем, які пропонують готові рішен- ня для веб-сайтів пов’язаних з аукціоном. На прикладі існуючих систем PHP Pro Bid [3] та iLance [4], ми порівняємо розробле- ний модуль аукціону та виділим переваги нашої системи автоматизації для елект- ронних закупівель. PHP Pro Bid – це ком- плексна система, яка пропонує повноцін- ний функціонал для роботи з користувача- ми, аукціонами та різними методами опла- ти товарів чи послуг. При створенні аукці- ону користувачу надається можливість вказувати деталі, такі як назва товару, опис, ціна, зображення, мінімальна ставка та інше. Також аукціон автоматично про- довжується якщо ставку зроблено в остан- ній момент перед закриттям. Створення нового аукціону відбувається через панель адміністратора, що являється недоліком, оскільки у електронних закупівлях аукціо- ни створюються замовником. У PHP Pro Bid не існує функціоналу для реєстрації користувачів різних ролей – замовник та Інструментальні засоби та середовища програмування 4 постачальник, що було реалізовано у нашій системі автоматизації електронних закупі- вель. Виділення ролей користувачів з пев- ним функціоналом, створення єдиного сер- вісу для авторизації та реєстрації, дозволи- ло зробити нашу систему масштабованою. У свою чергу система iLance вклю- чає у себе різновидність модулів для авто- матизації аукціонів. За допомогою шабло- нів та широкого обсягу налаштувань у си- стемі можливо створювати аукціони для різних видів товарів та послуг. Однак у да- ному фреймворку відсутня можливість оголошувати аукціон відкритого типу, що безумовно є ключовим у електронних за- купівлях. На відміну від закритого аукціо- ну, спостерігачам нашої платформи нада- ється можливість переглядати інформацію за пропозиціями до закупівлі та постача- льниками. Таким чином ми забезпечуємо найбільш можливу прозорість закупівлі та відкриту конкуренцію. Аналіз різновидностей аукціонів показує що існує декілька типів зворотньо- го відкритого аукціону, а саме: Голансь- кий, Японський, Американський та Анг- лійський [5]. Останній тип – найбільш по- ширений у системах електронних закупі- вель, тому в нашій статті ми зосередимося на проектуванні та реалізації даного виду аукціону за допомогою кінцевого автомату станів Stateless [6]. Зворотній Англійський аукціон дозволяє постачальникам напряму взаємодіяти із замовником. Такий аукціон припиняється коли залишається лише один постачальник або час проведення завершу- ється. Нарешті перемагає пропозиція з найбільш вигідною ціною для замовника, але замовник також матиме можливість обрати переможця за іншими неціновими критеріями. На сервері також використовується стандарт RESTFul API [7] забезпечує сумі- сність системи з більшістю сучасних клієн- тів та дозволяє працювати з сутностями че- рез обмін моделей даних у форматі JSON. 1. Формування вимог до системи Система має надавати можливість замовнику оголошувати закупівлі на певні товари або послуги, запрошувати до участі постачальників. Замовник зможе створю- вати лоти та позиції товарів, критерії для відбору пропозицій (цінові та нецінові). До кожної позиції замовник може вказувати галузь закупівлі та місце поставки товарів. У свою чергу, система також по- винна автоматично запрошувати перевіре- них постачальників у галузі, якщо корис- тувач обрав таку можливість. Електронний документообіг та укладання договорів че- рез електронний цифровий підпис також мають бути передбачені у системі. Замов- ники зможуть завантажувати документи до закупівлі, а також переглядати документи завантажені постачальником. Замовники та постачальники змо- жуть спілкуватися та обговорювати умови закупівлі через систему обговорень. Заку- півлі мають проводитися відкрито, тобто будь-хто зі спостерігачів матиме можли- вість зайти до системи та переглянути ак- тивні тендери. Діаграми використання системи для таких ролей користувача, як замовник, по- стачальник, та спостерігач (не авторизова- ний користувач) показано на рис. 1–3. Розроблена діаграма використання відображає базовий набір функцій, які дос- тупні не авторизованому користувачу сис- теми автоматизації електронних закупі- вель, а саме спостерігачу. Оскільки система призначена для зареєстрованих користувачів, то функціо- нал спостерігача обмежено переглядом іс- нуючих закупівель, пошуку тендера за но- мером, ключовими словами або назвою. Таким чином, спостерігач має доступ до перегляду усіх наявних у системі закупі- вель, які він може фільтрувати за такими критеріями як галузь, бюджет, ЄДРПОУ замовника, статус, дата початку та завер- шення. У спостерігача наявна можливість зареєструватися у системі як замовник для подальшої роботи та отримання повноцін- ного функціоналу. Система орієнтована на потреби замовника в процесі автоматизації елект- ронних закупівель, та надає такі можливо- сті, як оголошення закупівлі, перегляд власних закупівель, перегляд пропозицій, обговорення та обмін документами, вибір переможця та підписання договору. Інструментальні засоби та середовища програмування 5 Рис. 1. Діаграма використання спостерігачем Рис. 2. Діаграма використання замовником Інструментальні засоби та середовища програмування 6 Рис. 3. Діаграма використання постачальником Постачальник включає всі можливості спостерігача у системі та доповнює їх мо- жливістю подавати пропозиції до закупі- вель, лоті та позицій, переглядати подані пропозиції, спілкуватися з замовником та підписувати контракт. Після формування варіантів вико- ристання системи для різних ролей корис- тувачів, було виділено основні сутності та атрибути для проектування рівня доступу до даних. Перелік сутностей та атрибутів наведено у табл. 1. Таблиця 1. Сутності та атрибути Сутність Атрибути Тендери Статус, Назва, Опис, Бю- джет, Валюта, ПДВ, Початок прийому пропозицій, Кінець прийому пропозицій, Інфор- мація про компанію, Контак- тна особа, Тип закупівлі, Додаткові атрибути, Список нецінових показників, Спи- сок документів, Список кри- теріїв, Дата створення, Дата модифікації, Видалений Лоти Тендер, Етап, Назва, Опис, ПДВ, Статус, Додаткові ат- рибути, Список нецінових показників, Список докуме- нтів, Список критеріїв, Дата створення, Дата модифікації, Видалений Пропозиції Тендер, Лот, Статус, Поста- чальник, Email, ЕДРПОУ, Назва компанії, Додаткові параметри, Видалена Контракти Пропозиція, Постачальник, Статус, Сума Позиції Лот, Назва, Опис, Кількість, Одиниці виміру, Додаткові атрибути, Список нецінових показників, Список докуме- нтів, Список критеріїв, Дата створення, Дата модифікації, Виделено Етапи Номер етапу, JSON тендера Інструментальні засоби та середовища програмування 7 Проектування рівня доступу до да- них починається з побудови логічної мо- делі БД. Незалежно від моделі даних, по- будова логічної моделі БД на практиці виконується з урахуванням двох основних вимог: виключити надмірність і максима- льно підвищити якість даних. Ці вимоги випливають із вимоги колективного вико- ристання даних групою користувачів. На даному етапі потрібно перетворити об’єкти та зв’язки між ними у логічну мо- дель даних – реляційну модель. В ній об’єкти та зв’язки між ними представлені у вигляді таблиць (відношень), які скла- даються із стовпців та рядків. Кожне поле має ім’я та тип. Тип задає спосіб предста- влення поля. Також визначимо для атри- бутів чи обов’язково вони повинні місти- ти дані, чи допускаються нульові значен- ня. Для системи автоматизації електрон- них закупівель визначені наступні поля, значення, типи даних та обмеження, які наведені у таблицях 2–5. Таблиця 2. Фізична модель закупівлі Назва поля Значення Тип даних Об ме- жен ня 1 2 3 4 Id Ідентифікатор BIGINT PK, NN Guid Унікальний ідентифікатор UNIQUEI DENTIFIE R NN Status Статус INT NN Title Назва закупівлі NVARCH AR(1500) NN Descri ption Опис закупівлі NVARCH AR(2500) - Budge t Бюджет заку- півлі MONEY DEFAULT (0) - Curren cyIso Код валюти у форматі ISO INT NN IsVat Закупівля з ПДВ BIT DEFAULT (0) - StartBi d Дата та час по- чатку прийому пропозицій DATETIM EOFFSET( 7) - 1 2 3 4 EndBi d Дата та час кі- нця прийому пропозицій DATETIM EOFFSET( 7) - InfoCo mpany JSON інформа- ції про компа- нію NVARCH AR(MAX) NN Contac tPerso n JSON інформа- ції про контак- тну особу NVARCH AR(MAX) NN Tender Type Тип закупівлі: аукціон, редукціон, за- пит цінових пропозицій INT NN Additi onalAt tribute s JSON будь- яких додатко- вих властивос- тей закупівлі (для підтримки нових підклю- чень) NVARCH AR(MAX) - ListFe atures JSON списку нецінових показників NVARCH AR(MAX) - ListDo cumen ts JSON списку документів до закупівлі NVARCH AR(MAX) - ListCri teriaGr oups JSON критеріїв закупівлі, встановлених замовником NVARCH AR(MAX) - DateC reate Дата оголошення закупівлі DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) NN DateM odified Дата внесення змін до закупі- влі DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) - IsRem oved Чи було вида- лено закупівлю із системи BIT DEFAULT (0) - Інструментальні засоби та середовища програмування 8 Таблиця 3. Фізична модель лотів закупівлі Назва поля Значення Тип даних Об ме- жен ня 1 2 3 4 Id Ідентифікатор BIGINT PK, NN Tender Id Ідентифікатор пов’язаного тендера BIGINT FK, NN Guid Унікальний ідентифікатор UNIQUEI DENTIFIE R NN Status Статус INT NN Title Назва лоту NVARCH AR(1500) NN Descri ption Опис лоту NVARCH AR(2500) - IsVat Закупівля з ПДВ BIT DEFAULT (0) - Additi onalAt tribute s JSON будь- яких додатко- вих властивос- тей лота (для підтримки но- вих підклю- чень) NVARCH AR(MAX) - ListFe atures JSON списку нецінових по- казників NVARCH AR(MAX) - ListDo cumen ts JSON списку документів до лота NVARCH AR(MAX) - ListCri teriaGr oups JSON критеріїв лота, встанов- лених замов- ником NVARCH AR(MAX) - DateC reate Дата створення лота DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) NN 1 2 3 4 DateM odified Дата внесення змін до лота DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) - IsRem oved Чи було вида- лено лот із сис- теми BIT DEFAULT (0) - Таблиця 4. Фізична модель пропозицій до закупівлі Назва поля Значення Тип даних Об ме- жен ня 1 2 3 4 Id Ідентифікатор BIGINT PK, NN StageI d Ідентифікатор пов’язаного етапу BIGINT FK, NN Tender Id Ідентифікатор пов’язаного тендеру BIGINT FK, NN LotId Ідентифікатор пов’язаного лоту BIGINT FK, NN Guid Унікальний ідентифікатор UNIQUEI DENTIFIE R NN Status Статус пропо- зиції INT NN UserId Ідентифікатор постачальника BIGINT NN Email Email постача- льника NVARCH AR(50) NN Edrpo u Код постачаль- ника у реєстрі NVARCH AR(15) NN Comp anyNa me Назва компанії постачальника NVARCH AR(50) NN BidPar ameter s JSON списку додаткових па- раметрів заку- півлі NVARCH AR(MAX) - Інструментальні засоби та середовища програмування 9 1 2 3 4 DateC reate Дата створення пропозиції DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) NN DateM odified Дата внесення змін до пропо- зиції DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) - IsRem oved Чи було вида- лено пропози- цію із системи BIT DEFAULT (0) - Таблиця 5. Фізична модель контрактів для закупівлі Назва поля Значення Тип даних Об ме- жен ня Id Ідентифікатор BIGINT PK, NN StageI d Ідентифікатор пов’язаного етапу BIGINT FK, NN Tender Id Ідентифікатор пов’язаного тендеру BIGINT FK, NN LotId Ідентифікатор пов’язаного лоту BIGINT FK, NN ItemId Ідентифікатор пов’язаної по- зиції BIGINT FK, NN BidId Ідентифікатор пов’язаної пропозиції BIGINT FK, NN UserId Ідентифікатор постачальника BIGINT FK, NN Status Статус догово- ру INT NN Rate Сума договору DECIMAL NN Додатково були розроблені збере- жені процедури для створення та оновлен- ня пропозицій, отримання списку пропо- зицій по закупівлі, лоту, позиції, створення та редагування контрактів, отримання кон- трактів закупівлі. Первинні та зовнішні ключі забезпечують цілісність даних у БД. У таблицях 6 та 7 представлено фізичну модель товарів та етапів закупівлі відпо- відно. Таблиця 6. Фізична модель товарів для закупівлі Назва поля Значення Тип даних Об ме- жен ня 1 2 3 4 Id Ідентифікатор BIGINT PK, NN LotId Ідентифікатор пов’язаного лоту BIGINT FK, NN Guid Унікальний ідентифікатор UNIQUEI DENTIFIE R NN Title Назва позиції NVARCH AR(1500) NN Descri ption Опис позиції NVARCH AR(2500) - Quanti ty Кількість това- рів у позиції FLOAT DEFAULT (0) NN UnitId Ідентифікатор одиниць вимі- рювання INT NN Additi onalAt tribute s JSON будь- яких додатко- вих властивос- тей позиції (для підтримки нових підклю- чень) NVARCH AR(MAX) - ListFe atures JSON списку нецінових по- казників NVARCH AR(MAX) - ListDo cumen ts JSON списку документів до позиції NVARCH AR(MAX) - Інструментальні засоби та середовища програмування 10 1 2 3 4 ListCri teriaGr oups JSON критеріїв лота, встанов- лених замов- ником NVARCH AR(MAX) - DateC reate Дата створення позиції DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) NN DateM odified Дата внесення змін до позиції DATETIM EOFFSET( 7) DEFAULT (SYSDAT ETIMEOF FSET()) - IsRem oved Чи було вида- лено позицію із системи BIT DEFAULT (0) - Таблиця 7. Фізична модель етапів закупівлі Назва поля Значення Тип даних Об ме- жен ня Id Ідентифікатор BIGINT PK, NN Stage Numb er Номер етапу закупівлі INT NN Tender Id Ідентифікатор пов’язаного тендеру BIGINT FK, NN Tender Json JSON інформа- ції про закупів- лю на минуло- му етапі NVARCH AR(MAX) - 2. Реалізація бізнес-логіки У системі бізнес-логіка зосереджена в мікросервісах, які спілкуються з клієн- том у форматі обміну даних JSON. Мікро- сервіси викликаються через контролери- маршрутизатори, що робить її закритими від зовнішнього світу. Крім цього при за- питах на модифікацію даних передаються відповідні заголовки авторизації для уник- нення несанкціонованого доступу. Сервіс TenderService призначено для роботи з закупівлями, наприклад, створення нової закупівлі, отримання іс- нуючої закупівлі, отримання документів, видалення закупівлі. Клас сервісу склада- ється з таких методів: - UpsertTender. Метод виконує логіку створення нової закупівлі або онов- лення вже існуючої. Закупівлю може ство- рити лише замовник, який зареєстрований у системі та авторизований. Вхідним па- раметром є об’єкт типу TenderDTO, який містить дані для коректного створення за- купівлі. Валідація параметру проводиться на контролері, тому сервіс лише викликає збережену процедуру для створення або оновлення закупівлі; - DeleteTender. Метод виконує логіку видалення закупівлі за ідентифіка- тором. Для забезпечення можливості пере- гляду архівних закупівель, дані із бази не видаляються, замість цього у базі даних за допомогою збереженої процедури встано- влюється поле isRemove для закупівлі у значення true; - GetTenderById. Метод повертає закупівлю за ідентифікатором. Виклика- ється збережена процедура, яка збирає із бази даних інформацію по тендеру та по- вертає результат у форматі JSON. Після чого метод за допомогою конверторів створює модель закупівлі TenderDTO та повертає її на контролер, який потім пове- ртає цю модель клієнту; - GetTenderDocumentsById. Ме- тод містить логіку для отримання списку документів до закупівлі. Викликає збере- жену процедуру, що повертає документи за типом об’єкта (тендер, лот, позиція) з параметром тендер. Результат збереженої процедури оброблюється через конвертор і створюється список DocumentDTO, який містить інформацію по кожному докумен- ту: назва, тип, посилання, дата створення. Список повертається контролеру, який по- вертає його клієнтові. За аналогічною схемою реалізовано класи для роботи з лотами (LotService) та позиціями (ItemService) закупівлі. Патерн Dependency Injection [8] ду- же широко використовується в даному проекті. Як ціль було прийнято відійти від Інструментальні засоби та середовища програмування 11 використання конкретними класами, а ко- ристуватися лише інтерфейсами, зменши- ти використання ключового слова new та полегшити тестування проекту. Для цих цілей використано стандартний механізм DI в .NET Core. Вибір обгрунтовується зрозумілим API, розгорнутою та повною документацією. В даному проекті викори- стано стандартні механізми фреймворку .NET Core для реєстрації контролерів та підтримки режиму часу життя сутностей на протязі одного запиту до WebApi. Це дає нам можливість розробляти бізнес- логіку не звертаючи увагу на час життя сутності, тому що він визначається в ре- єстрації сутності. Сервіс StateService призначено для роботи з статусами та етапами закупівель, переведення закупівлі на новий етап, зміну статуса. Клас складається з наступних ме- тодів: - GetStateByTenderId. Метод міс- тить логіку для отримання статуса закупі- влі за ідентифікатором. Викликає відпові- дну збережену процедуру, яка знаходить закупівлю у БД і повертає її статус; - ChangeStateTender. Метод ви- конує логіку по зміні статуса тендера на вказаний. Викликає збережену процедуру, яка змінює статус для закупівлі у БД на вказаний; - MoveToNextStage. Метод пере- водить закупівлю за ідентифікатором на наступний етап (наприклад на підписання контракту). Викликається збережена про- цедура, яка перевіряє поточний етап тен- дера та змінює його на наступний. Для реалізації станів закупівлі та переходу між ними використано фрейм- ворк Stateless та Hangfire. Клас StateService використовується машиною станів TenderStateMachine. Спочатку ство- рено базовий клас для кінцевого автомату BaseStateMachine: internal abstract class BaseStateMachine: BaseService { public readonly IStateService _stateService; public BaseStateMachine(IStateService stateService,IPublishService publishService):base(publishService) { _stateService = stateService; } public abstract object ChangeState(object model); } За допомогою механізму наслідування бу- ло створено реалізацію: internal class TenderStateMachine : BaseStateMachine { … // <summary> /// Configuration state /// </summary> private void ConfigureStateMachine() { _machine = new StateMachine<TenderStateMachineStatus, TenderStateMachineTrigger>(() => _TenderStateMachineStatus, s => _TenderStateMachineStatus = s); _triggerParams = _machine.SetTriggerParameters<TenderSync>(Tender StateMachineTrigger.ChangeStatus); _machine.Configure(TenderStateMachineStatus.New) .PermitIf(TenderStateMachineTrigger.ChangeStatus, TenderStateMachineStatus.Planned); _machine.Configure(TenderStateMachineStatus.Planne d) .Permit(TenderStateMachineTrigger.ChangeStatus, TenderStateMachineStatus.AcceptanceOfOffers) .OnEntryFrom(_triggerParams, model => AcceptanceOfOffers(model)); _machine.Configure(TenderStateMachineStatus.Accep tanceOfOffers) .PermitTenderStateMachineTrigger.ChangeStatus, TenderStateMachineStatus.DataProcessing) .OnEntryFrom(_triggerParams, model => AcceptanceOfOffers(model)); _machine.Configure(TenderStateMachineStatus.DataP rocessing) .Permit(TenderStateMachineTrigger.ChangeStatus, TenderStateMachineStatus.Completed) .OnEntryFrom(_triggerParams, model => DataProcessing(model)); Інструментальні засоби та середовища програмування 12 _machine.Configure(TenderStateMachineStatus.Compl eted) .OnEntryFrom(_triggerParams, model => Task.Run(async () => await PushAwards(model))) .OnEntryFrom(_triggerParams, model => Task.Run(async () => await UpdateState(model))); } /// <summary> /// Changed Status /// </summary> /// <param name="state"></param> private async Task UpdateState(Tender model) { model.Status = (int)_machine.State; var result = await _stateService.InsertOrUpdate(new StateTender() { TenderId = model.Id, StageNumber = model.StageNumber, StatusId = (int)_machine.State, JobId = _currentTenderState?.JobId, TenderJson = JsonConvert.SerializeObject(model) }); await _stateService.UpdateStatusTender(model); } … } Стани закупівлі можна побачити у перерахуванні TenderStateMachineStatus: public enum SmartStateMachineStatus { New=0, // Нова закупівля Planned=1, // Заплановані торги AcceptanceOfOffers = 2, // Подача пропозицій DataProcessing = 3, // Аналіз пропозицій Completed =4 // Завершено } Таким чином реалізовано кінцевий авто- мат станів для закупівлі. 3. Дизайн Web API За допомогою онлайн інструменту для проектування та документації API – SwaggerEditor [9] згенеровано документа- цію основних методів та моделей. Інстру- мент призначений для конструювання API та автоматичної генерації шаблонного ко- ду для основних мов програмування: C#, JavaSript, Python, Swift. Web API реалізовано на основі тех- нологій ASP .NET Core MVC [10], контро- лери виконують роль маршрутизаторів та перенаправляють запити на відповідні мік- росервіси [11]. У табл. 8 наведено перелік основних методів дії для закупівлі. Таблиця 8. Перелік основних методів Web API Шлях Опис Повертаєме значення -GET- Tender/G etList Отрима- ти список закупі- вель StatusCode 200 – OK + список TenderDTO StatusCode 204 – NoContent StatusCode 500 – помилка сервера -GET- Tender/G etTender ById/{ten derId} Отрима- ти заку- півлю за ідентифі- катором StatusCode 200 – OK + TenderDTO StatusCode 404 – NotFound StatusCode 500 – помилка сервера -POST- Tender/U psert Додати нову за- купівлю або оно- вити іс- нуючу StatusCode 201 – Created StatusCode 403 – Forbidden (немає доступу) StatusCode 500 – помилка сервера -DEL- Tender/D elete/{ten derId} Видалити закупів- лю StatusCode 200 – OK StatusCode 403 – Forbidden (немає доступу) StatusCode 500 – помилка сервера -PATCH- TenderSta te/Change State/{ten derId/{sta teId} Змінити статус тендера на зада- ний StatusCode 200 – Created StatusCode 404 – Not Found StatusCode 500 – помилка сервера -PATCH- TenderSta te/MoveT oNextSta ge Перевес- ти заку- півлю на наступ- ний етап StatusCode 200 – OK StatusCode 404 – Not Found StatusCode 500 – помилка сервера Інструментальні засоби та середовища програмування 13 В ході розробки було прийняте рі- шення викликати валідацію у методах кон- тролерів на сервері – у місці, де дані пер- шими приходять від клієнта. Таким чином забезпечується коректність даних з самого початку їх обробки. Оскільки перенавантажувати моделі даних логікою валідації вважається недо- цільним, була розроблена власна система валідації на основі методів розширення для моделей та набору правил. Кожна мо- дель у системі матиме метод IsValid, який буде викликати всі правила валідації для моделі, повертатиме булеве значення ус- пішності валідації, а також масив помилок у форматі ключ-значення, де ключ – це на- зва поля моделі, а значення – опис помил- ки. У разі неуспішної валідації клієнту бу- де повертатися масив помилок, що буде оброблено та відповідним чином відобра- жено у браузері. Подібний підхід до процесу валіда- ції дозволив розподілити відповідальність, очистити модель від непотрібних атрибу- тів або наслідування та покращити надій- ність програми. 4. Тестування Тестування – це невд’ємна складова впровадження будь-якої програмної сис- теми, тому під час розробки приділена значна увага покриттю коду тестами для швидкого виявлення та виправлення по- милок, а також постійного контролю за роботоздатністю продукту. Під час тесту- вання широко використовувались такі за- соби, як unit- та mock-тести. Для модульного тестування викори- стовувалась бібліотека xUnit [12]. Це без- коштовний інструмент, що базується на відкритому до змін коді, який написано розробниками NUnit v2. Даний фреймворк призначено для тестування коду на C#, F#, VB.NET та інших мовах програмування .NET. У фреймворку існує два поняття те- стів: Fact та Theory. Fact – це окремий мо- дульний тест, що не приймає параметрів. Theory – це тест, який приймає параметри та може містити декілька сценаріїв. Пара- метри до методу тесту можуть передавати- ся двома способами: через атрибути InlineData та MemberData. За допомогою модульного тесту- вання була перевірена робота системи ва- лідації моделей, створені тестові методи для валідації кожної сутності у програмі. У кожному тесті на валідацію об'явлено два варіанта моделі: валідна та невалідна, а та- кож два Theory-методи, які перевіряють валідацію. Також у даному тесті присутній Fact-метод, який перевіряє валідацію null- моделі. За допомогою фреймворка Moq у системі розроблені тести для сервісів по роботі з закупівлями, лотами та позиці- ями. Для того, щоб перевірити CRUD- операції з основними сутностями системи створено мок-об’єкти відповідних сервісів- залежностей. Moq – це фреймворк для створення моків для .NET, який розроблено з підтри- мкою специфічних можливостей .NET, та- ких як вирази LINQ та лямбди. Все це ро- бить бібліотеку найбільш продуктивною, строго типізованою та дружньою до рефа- кторингу серед аналогів на ринку. Наприклад, TenderController відпо- відає за основні операції для роботи із за- купівлями, у нього є залежність – поле ITenderService, у якому знаходиться біз- нес-логіка роботи з БД. Замість того, щоб при тестуванні створювати справжній об’єкт, ми створюємо мок ITenderService, який може працювати з тестовою базою даних або просто повертати потрібний ре- зультат. Після чого вже з використанням xUnit були написані модульні тести, які використовували створені у Moq моки сервісів. Спираючись на результати прове- дених випробувань, можна зробити висно- вок про надійність системи та окремих її модулів. Відсоток покриття тестами стано- вить 95 %, що підтверджує високу стій- кість системи до збоїв. Висновки Реалізовано програмний засіб для автоматизації електронних закупівель з використанням новітніх технологій RESTful API та відкритих специфікацій Інструментальні засоби та середовища програмування 14 OpenAPI v3.0. Надано можливість автори- зувати користувачів системи, а саме пос- тачальників та замовників основуючись на стандарті Oauth. Бібліотека для роботи з розподіленим кешем Redis використо- вувалась для прискорення роботи системи та кешування даних на рівні доступу до БД. Для моніторингу стану закупівлі та переходу між станами реалізовано кінечний автомат станім за допомогою бібліотеки Stateless. Тестування розробле- ної системи проведено unit- та integration тестами. На відміну від комплексних систем автоматизації аукціонів по типу PHP Pro Bid, у яких клієнт є невідє’мною частиною сервера, що робить використан- ня сервера неможливим для інших клієнтів (наприклад, мобільних додатків). У нашій системі електронних закупівель кожен модуль реалізовано як RESTFul API мікро- сервіс. Такий підхід до проектування серверної частини дозволив нам розподі- лити відповідальності між модулями та відділити сервер від клієнта. Використо- вуючи стандартний формат даних JSON, будь-який клієнт – веб-сайт або мобільний додаток, зможе повноцінно працювати з нашим API. Література 1. Doroshenko A.Yu., Bodak B.V. (2019) .The impact and unforeseen challenges of E- procurement systems in Canada. Winter InfoCom Advanced Solutions. P. 9–10. 2. Business Dictionary, Reverse auction [Online] – Available from: https://financial- dictionary.thefreedictionary.com/Reverse+auc tion. 3. PHP Pro Bid Auction features [Online] – Available from: https://www.phpprobid.com/features/auctions. 4. iLance Auction Software [Online] – Available from: https://www.ilance.com/auction- software/. 5. Mubark A., Haggren A. (2017). Computer Science Optimization Of Reverse Auctions. 6. Stateless 3.0 – A State Machine library for .NET Core [Online] – Available from: https://www.hanselman.com/blog/stateless- 30-a-state-machine-library-for-net-core/. 7. What is a RESTful API [Online] – Available from: https://searchapparchitecture.techtarget.com/d efinition/RESTful-API 8. Architectural Styles and the Design of Network-based Software Architectures [Online] – Available from: https://www.ics.uci.edu/~fielding/pubs/dissert ation/top.htm. 9. About Swagger specification [Online] – Available from: https://swagger.io/docs/specification/about/. 10. Repository and UnitOfWork in ASP.NET Core [Online] – Available from: http://www.c- sharpcorner.com/article/repository-pattern-in- asp-net-core/ 11. Doroshenko A.Yu., Bodak B.V. (2020) The implementation of RESTful API for social media events platform. Summer InfoCom Advanced Solutions. P. 11–12. 12. Build, test, and deploy .NET Core apps [Online] – Available from: https://docs.microsoft.com/en- us/azure/devops/pipelines/ecosystems/dotnet- core?view=azure-devops. References 1. Doroshenko A.Yu., Bodak B.V. (2019) .The impact and unforeseen challenges of E- procurement systems in Canada. Winter InfoCom Advanced Solutions. P. 9–10. 2. Business Dictionary, Reverse auction [Online] – Available from: https://financial- dictionary.thefreedictionary.com/Reverse+auc tion. 3. PHP Pro Bid Auction features [Online] – Available from: https://www.phpprobid.com/features/auctions. 4. iLance Auction Software [Online] – Available from: https://www.ilance.com/auction- software/. 5. Mubark A., Haggren A. (2017). Computer Science Optimization Of Reverse Auctions. 6. Stateless 3.0 – A State Machine library for .NET Core [Online] – Available from: https://www.hanselman.com/blog/stateless- 30-a-state-machine-library-for-net-core/. 7. What is a RESTful API [Online] – Available from: https://searchapparchitecture.techtarget.com/d efinition/RESTful-API Інструментальні засоби та середовища програмування 15 8. Architectural Styles and the Design of Network-based Software Architectures [Online] – Available from: https://www.ics.uci.edu/~fielding/pubs/dissert ation/top.htm. 9. About Swagger specification [Online] – Available from: https://swagger.io/docs/specification/about/. 10. Repository and UnitOfWork in ASP.NET Core [Online] – Available from: http://www.c-sharpcorner.com/ article/repository-pattern-in-asp-net-core/ 11. Doroshenko A.Yu., Bodak B.V. (2020) The implementation of RESTful API for social media events platform. Summer InfoCom Advanced Solutions. P. 11–12. 12. Build, test, and deploy .NET Core apps [Online] – Available from: https://docs.microsoft.com/en- us/azure/devops/pipelines/ecosystems/dotnet- core?view=azure-devops. Одержано 20.01.2021 Про авторів: Дорошенко Анатолій Юхимович, доктор фізико-математичних наук, професор, завідувач відділу теорії комп'ютерних обчислень Інституту програмних систем НАН України, професор кафедри автоматики і управління в технічних системах НТУУ "КПІ імені Ігоря Сікорського". Кількість наукових публікацій в українських виданнях – понад 190. Кількість наукових публікацій в іноземних виданнях – понад 80. Індекс Гірша – 6. http://orcid.org/0000-0002-8435-1451, Бодак Богдан Вікторович, аспірант кафедри автоматики і управління в технічних системах НТУУ "КПІ імені Ігоря Сікорського". Кількість наукових публікацій в українських виданнях – 2. Місце роботи авторів: Інститут програмних систем НАН України, 03187, м. Київ-187, проспект Академіка Глушкова, 40. Тел.: (044) 526 3559. E-mail: doroshenkoanatoliy2@gmail.com, bohdan.bodak@outlook.com

Designing RESTful API for the e-procurement system in private sector

Репозитарії

Схожі ресурси