Automation in e-procurement system with auction module
The article focuses on design and development around automation processes in complex e-procurement system with auction module. The complex system was built based on microservices architecture using latest server-side and client-side technologies. Data synchronization and integration amongst system’s...
Збережено в:
| Дата: | 2023 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут програмних систем НАН України
2023
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/571 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-571 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/92/67e801cdf90f96bbfb34b08321042c92.pdf |
| spelling |
pp_isofts_kiev_ua-article-5712024-04-26T21:28:48Z Automation in e-procurement system with auction module Автоматизація в системі електронних закупівель з модулем аукціону Bodak, B.V. Doroshenko, А.Yu. e-procurement; auction, e-procurement automation; REST API; Blazor; Web Sockets; Identity Service; OAuth 2.0; Docker; ELK UDC 681.3 електронні закупівлі; аукціон; автоматизація закупівель; модульна архітектура; мікросервіси; REST API; Blazor; Web Sockets; Identity Service; OAuth 2.0; Docker; ELK УДК 681.3 The article focuses on design and development around automation processes in complex e-procurement system with auction module. The complex system was built based on microservices architecture using latest server-side and client-side technologies. Data synchronization and integration amongst system’s various modules was implemented in real time via Web Socket protocol and database triggers. Web client notification methods involved SignalR technology. Data was stored in a distributed database and cached to dramatically improve query execution time. Authentication and authorization for users, modules, and subsystems was designed according to OAuth 2.0 standard with a proprietary implementation of the Proof Key Code Exchange algorithm and Backend for Frontend approach. The web client was built as a single page application using a strongly typed managed language to simplify development and debugging process. The client application was optimized with the help of lazy-loading algorithms for key modules, among them supplier, buyer, and common module. The system was composed into a Docker container to be ready to publish on cloud services or physical servers and support any operating system. A set of unit, integration, and system tests was created for each subsystem and module. Monitoring of the complex includes a technology stack to log, store, and visualize request statuses, latency, uptime, and overall health of the system. Existing automation flows for build and deployment were improved to accommodate the needs of the complex e procurement system. The system was designed and built for key stakeholders such as private enterprises acting as buyers and people or companies acting as suppliers.Problems in programming 2023; 2: 91-100 Розроблено комплексну систему автоматизації електронних закупівель з інтегрованим модулем аукціону. Комплекс побудовано на базі мікросервісної архітектури з використанням новітніх технологій для сервера та клієнта. Взаємодія між модулями системи та синхронізація даних реалізована у реальному часі через протоколи Web Socket. Для збереження даних використовується розподілена база даних з кешуванням для прискорення часу доступу до даних. Авторизацію користувачів та підсистем між собою створено на основі останнього стандарту OAuth 2.0 та додаткового використання нової власної реалізації алгоритму безпечної аутентифікації відкритого клієнта. Програмний комп- лекс скомпоновано у форматі Docker-контейнера, готового до публікації у хмарних сервісах або на фізичних серверах будь-якої операційної системи без зміни програмного коду. Створено набір засобів тестування, а саме модульних тестів та інтеграційних тестів для кожної підсистеми. Моніторинг комплексу автоматизації і його модулів реалізовано через стек технологій для запису та візуалізації стану, помилок, навантаження у системі. Вдосконалено автоматизовані процеси побудови та публі- кації системи електронних закупівель з модулем аукціону та системою моніторингу.Problems in programming 2023; 2: 91-100 Інститут програмних систем НАН України 2023-08-04 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/571 10.15407/pp2023.02.091 PROBLEMS IN PROGRAMMING; No 2 (2023); 91-100 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2023); 91-100 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2023); 91-100 1727-4907 10.15407/pp2023.02 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/571/622 Copyright (c) 2023 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2024-04-26T21:28:48Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
e-procurement; auction e-procurement automation; REST API; Blazor; Web Sockets; Identity Service; OAuth 2.0; Docker; ELK UDC 681.3 |
| spellingShingle |
e-procurement; auction e-procurement automation; REST API; Blazor; Web Sockets; Identity Service; OAuth 2.0; Docker; ELK UDC 681.3 Bodak, B.V. Doroshenko, А.Yu. Automation in e-procurement system with auction module |
| topic_facet |
e-procurement; auction e-procurement automation; REST API; Blazor; Web Sockets; Identity Service; OAuth 2.0; Docker; ELK UDC 681.3 електронні закупівлі аукціон автоматизація закупівель модульна архітектура мікросервіси REST API Blazor Web Sockets Identity Service OAuth 2.0 Docker ELK УДК 681.3 |
| format |
Article |
| author |
Bodak, B.V. Doroshenko, А.Yu. |
| author_facet |
Bodak, B.V. Doroshenko, А.Yu. |
| author_sort |
Bodak, B.V. |
| title |
Automation in e-procurement system with auction module |
| title_short |
Automation in e-procurement system with auction module |
| title_full |
Automation in e-procurement system with auction module |
| title_fullStr |
Automation in e-procurement system with auction module |
| title_full_unstemmed |
Automation in e-procurement system with auction module |
| title_sort |
automation in e-procurement system with auction module |
| title_alt |
Автоматизація в системі електронних закупівель з модулем аукціону |
| description |
The article focuses on design and development around automation processes in complex e-procurement system with auction module. The complex system was built based on microservices architecture using latest server-side and client-side technologies. Data synchronization and integration amongst system’s various modules was implemented in real time via Web Socket protocol and database triggers. Web client notification methods involved SignalR technology. Data was stored in a distributed database and cached to dramatically improve query execution time. Authentication and authorization for users, modules, and subsystems was designed according to OAuth 2.0 standard with a proprietary implementation of the Proof Key Code Exchange algorithm and Backend for Frontend approach. The web client was built as a single page application using a strongly typed managed language to simplify development and debugging process. The client application was optimized with the help of lazy-loading algorithms for key modules, among them supplier, buyer, and common module. The system was composed into a Docker container to be ready to publish on cloud services or physical servers and support any operating system. A set of unit, integration, and system tests was created for each subsystem and module. Monitoring of the complex includes a technology stack to log, store, and visualize request statuses, latency, uptime, and overall health of the system. Existing automation flows for build and deployment were improved to accommodate the needs of the complex e procurement system. The system was designed and built for key stakeholders such as private enterprises acting as buyers and people or companies acting as suppliers.Problems in programming 2023; 2: 91-100 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2023 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/571 |
| work_keys_str_mv |
AT bodakbv automationineprocurementsystemwithauctionmodule AT doroshenkoayu automationineprocurementsystemwithauctionmodule AT bodakbv avtomatizacíâvsistemíelektronnihzakupívelʹzmodulemaukcíonu AT doroshenkoayu avtomatizacíâvsistemíelektronnihzakupívelʹzmodulemaukcíonu |
| first_indexed |
2024-10-02T04:06:53Z |
| last_indexed |
2024-10-02T04:06:53Z |
| _version_ |
1818568506175651840 |
| fulltext |
91
Інструментальні засоби і середовища програмування
Актуальність комплексу
електронних закупівель
Проведення закупівель за допомо-
гою електронних торговельних майданчи-
ків не є новим для України. В епоху швид-
кого розвитку інформаційних систем та
технологій усе більше процесів піддаються
автоматизації та спрощенню, що в цілому
підвищує їхню ефективність. Не є винят-
ком процес тендерних закупівель, який, на
жаль, вважається найбільш заангажованим
та корумпованим у бізнесі. Одним із кро-
ків на шляху до вирішення цієї проблеми
може стати проведення закупівель через
електронні системи автоматизації.
Подібні системи, орієнтовані на про-
зорість, продуктивність, зручність та до-
ступність, уже набули популярності у сфері
закупівель для державного сектору. Най-
більш розповсюдженою системою для здій-
снення державних електронних закупівель
є «Prozorro» [1], яка розпочала свою роботу
у лютому 2015 р. завдяки цій системі, вда-
лося значно зменшити часові та матеріальні
витрати, систематизувати документообіг у
електронному форматі, а також підвищити
прозорість державних торгів.
Спираючись на досвід системи
«Prozorro» [2] і подібних [3, 4], та показники
економії коштів у використанні електронних
систем закупівель [5] було ухвалено рішен-
ня реалізувати комплексну систему автома-
тизації електронних закупівель для бізнесу.
Комплекс призначено для використання
приватними підприємствами, фізичними та
юридичними особами, зацікавленими у про-
веденні відкритих торгів або постачанні пев-
них товарів/послуг для інших підприємств.
1. Архітектура комплексу
Комплексна система автоматиза-
ції електронних закупівель складається
з таких модулів: центральна база даних
(ЦБД), мікросервіси з REST API інтер-
фейсом, модуль аукціону, сервіс аутенти-
фікації та авторизації, веб-клієнт. Основні
компоненти системи та зв’язки між ними
представлено на Рис. 1.
База даних побудована на технології
Microsoft SQL Server та включає основні
сутності системи, такі як закупівлі, лоти,
пропозиції, контракти, аукціони, етапи та
інші. Цілісність БД забезпечується через
первинні та зовнішні ключі, а використан-
ня індексів для кожної сутності пришвид-
шує виконання запитів до таблиць зі зна-
чною кількістю даних. Діаграма основних
сутностей БД зображена на Рис. 2.
УДК 004.4’24 http://doi.org/10.15407/pp2023.02.091
Б.В. Бодак, А.Ю. Дорошенко
АВТОМАТИЗАЦІЯ В СИСТЕМІ ЕЛЕКТРОННИХ
ЗАКУПІВЕЛЬ З МОДУЛЕМ АУКЦІОНУ
Розроблено комплексну систему автоматизації електронних закупівель з інтегрованим модулем аук-
ціону. Комплекс побудовано на базі мікросервісної архітектури з використанням новітніх техноло-
гій для сервера та клієнта. Взаємодія між модулями системи та синхронізація даних реалізована у
реальному часі через протоколи Web Socket. Для збереження даних використовується розподілена
база даних з кешуванням для прискорення часу доступу до даних. Авторизацію користувачів та під-
систем між собою створено на основі останнього стандарту OAuth 2.0 та додаткового використання
нової власної реалізації алгоритму безпечної аутентифікації відкритого клієнта. Програмний комп-
лекс скомпоновано у форматі Docker-контейнера, готового до публікації у хмарних сервісах або на
фізичних серверах будь-якої операційної системи без зміни програмного коду. Створено набір засо-
бів тестування, а саме модульних тестів та інтеграційних тестів для кожної підсистеми. Моніторинг
комплексу автоматизації і його модулів реалізовано через стек технологій для запису та візуалізації
стану, помилок, навантаження у системі. Вдосконалено автоматизовані процеси побудови та публі-
кації системи електронних закупівель з модулем аукціону та системою моніторингу.
Ключові слова: електронні закупівлі, аукціон, автоматизація закупівель, модульна архітектура, мі-
кросервіси, REST API, Blazor, Web Sockets, Identity Service, OAuth 2.0, Docker, ELK.
© Б.В. Бодак, А.Ю. Дорошенко, 2023
ISSN 1727-4907. Проблеми програмування. 2023. №2
92
Інструментальні засоби і середовища програмування
Рис. 1. Діаграма модулів комплексу електронних закупівель
Рис. 2. Діаграма бази даних
93
Інструментальні засоби і середовища програмування
БД містить збережені процедури
для роботи із закупівлями, аукціонами,
контрактами, та іншими таблицями. Ви-
користання збережених процедур дозво-
лило у подальшому спростити рівень до-
ступу до даних у мікросервісах і реалізу-
вати потенціал MS SQL Server для оброб-
ки складних запитів. Приклад збереженої
процедури Tender_GetById для отримання
закупівлі представлено нижче:
CREATE PROCEDURE [dbo].[Tender_
GetById]
(
@Id BIGINT
)
AS
BEGIN
SET NOCOUNT ON;
SELECT T.[Id]
,[dbo].[Stage_Get](@Id,0)
AS ‘StageNumber’
,T.[Guid]
,T.[TenderId]
,T.[Status]
,T.[Title]
,T.[Description]
,T.[Budget]
,T.[CurrencyIso]
,T.[StartBid]
,T.[EndBid]
,T.[InfoCompany]
,T.[ContactPerson]
,T.[TenderType]
,T.[AdditionalAttributes]
,T.[ListFeatures]
,T.[ListDocuments]
,T.[ListCriteriaGroups]
,T.[DateCreate]
,T.[DateModified]
,T.[IsRemoved]
,T.[PlatformId]
,(SELECT [dbo].
[ShortLot_GetByTenderId](@Id)) AS
ListShortLotsOrItems
FROM [dbo].[Tenders] AS T
WHERE T.[Id] = @Id AND
ISNULL(T.[IsRemoved], 0) = 0
END
Приведена вище процедура вибирає
дані одразу з декількох таблиць та видає у
результаті повноцінну модель закупівлі,
готову до використання у мікросервісі.
Переходи між станами закупівлі у
період аукціону реалізовано на рівні БД
через Hangfire, що являє собою надбудо-
ву над стандартними тригерами БД та за-
безпечує синхронізацію даних, що вкрай
важливо у аукціоні. Модуль аукціону до-
повнює тригери на рівні БД через фрейм-
ворк Stateless, реалізовуючи скінчений
автомат станів для переходу між етапами
закупівлі – TenderStateMachine.
Мікросервіси використовують
micro-ORM Dapper та мають дос туп
до бази даних через репозиторій
DatabaseRepository, який уможливлює
зчитування, оновлення, вставки, вида-
лення даних, а також виклик збережених
процедур. Даний компонент являє собою
абстракцію бази даних та працює із сер-
вером БД, на якому розгорнута база даних
MS SQL. У порівнянні з розповсюдженим
Entity Framework, Dapper має обмежені
можливості, проте значно вищу швид-
кість обробки запитів [6], що є ключовим
у контексті застосування в розробленому
комплексі електронних закупівель.
Серверна частина комплексу напи-
сана на C# .NET Core API та структурно
складається з набору мікросервісів, які
обмінюються між собою даними у форма-
ті JSON об’єктів через REST протокол.
Для обміну даними у реальному
часі на критичних етапах закупівлі, а та-
кож для оповіщення клієнта про зміни
(наприклад, статусу закупівлі) використо-
вується протокол Web Sockets [7]. Даний
протокол дозволяє встановити зв’язок між
сервісом та клієнтом (або між двома серві-
сами) для обміну даними у реальному часі
з мінімальними затримками. Програмна
реалізація протоколу Web Sockets на рів-
ні мікросервісів створена з використан-
ням інструменту SignalR [8] від Microsoft.
Приклад налаштування SignalR у модулі
аукціону та сповіщення про зміну статусу
закупівлі наведено нижче:
private readonly IHubContext<TenderHub,
ITenderHubClient> _tenderHubContext;
await_tenderHubContext.
94
Інструментальні засоби і середовища програмування
Clients.Group(TenderHub.
GetTenderGroupName(tenderId)).
StatusChanged(status);
Кожен із мікросервісів містить сто-
рінку з документацією, детальним описом
API методів та параметрів, згенеровану ав-
томатично інструментом для документації
– Swagger [9]. Документація методів та мо-
делей написана у форматі XML коментарів
у коді сервісів. Приклад документації ме-
тодів наведено нижче у розділі.
Аутентифікація та авторизація ко-
ристувачів реалізована на основі Microsoft
Identity Service [10] відповідно до стан-
дарту OAuth 2.0. Система підтримує фор-
мат Single Sign On (SSO), тобто користу-
вач має авторизуватися лише один раз для
використання усіх можливих підсистем
комплексу електронних закупівель. Від-
повідно до вимог [11], у системі існує дві
основні ролі – замовник та постачальник.
Процес реєстрації користувачів, доступ-
ний функціонал та повноваженння різ-
няться відповідно до ролі. Додатково вве-
дена роль адміністратора, котрій доступ-
ний повний функціонал системи. Авто-
ризація здійснюється на основі JSON Web
Token (JWT) [12], який містить повнова-
ження та іншу інформацію про користува-
ча (Claims). Валідація токену проводиться
на сервері при кожному запиті. Приклад
JWT постачальника виглядає так:
{
«sub»: «37483811»,
«name»: «Bohdan Bodak»,
«aud»: «https://bbtender.azurewebsites.net»,
«iat»: 1685490321,
«exp»: 1717026321,
«sub»: «bohdan.bodak@outlook.com»,
«GivenName»: «Bohdan»,
«Surname»: «Bodak»,
«Email»: «bohdan.bodak@outlook.com»,
«Role»: [
«Supplier»,
«Project Administrator»
]
}
За аутентифікацію, авторизацію,
реєстрацію та роботу з користувачами в
цілому у системі відповідає мікросервіс
AuthService, що є обгорткою над Microsoft
Identity Service та надає REST API для
зручного використання клієнтом чи інши-
ми сервісами. Інтерфейс API сервісу авто-
ризації зображено на Рис. 3.
Клієнтський додаток написаний на
Blazor Web Assembly [13] додатково ви-
користовує власну реалізацію алгоритму
Proof Key for Code Exchange (PKCE) [14]
для безпечної авторизації публічного клі-
єнту. Детальніше про клієнта та його ав-
торизацію написано у розділі 2.
Рис. 3. API сервісу авторизації
95
Інструментальні засоби і середовища програмування
2. Клієнт Blazor Web Assembly
Клієнт комплексної системи елек-
тронних закупівель представляє собою
модульну-компонентну архітектуру та
використовує технологію одно сторінко-
вих додатків Blazor Web Assembly. Окрім
існуючих переваг одно сторінкових веб-
сайтів, дана технологія дозволяє розроб-
никам створювати код популярною стро-
го типізованою мовою C#. На відміну від
JavaScript, C# надає розробникам клієнт-
ських додатків доступ до більшості мож-
ливостей фреймворку .NET: класів, ін-
терфейсів, Dependency Injection, спрощує
процес розробки, полегшує налагоджен-
ня, а також пошук помилок.
Для зменшення часу завантаження
клієнтського додатку у браузері, був ви-
користаний підхід розподілення окремих
частин клієнта на модулі. У комплексній
системі електронних закупівель було ви-
ділено 3 модуля з такими основними ком-
понентами:
• Модуль замовника: створення за-
купівлі, лотів, позицій, вибір пропозиції,
підписання договору.
• Модуль постачальника: подача
пропозиції, підписання договору.
• Спільний модуль / модуль неав-
торизованого користувача: перегляд заку-
півель та їхніх подробиць, сторінка авто-
ризації та реєстрації.
Завантаження цих модулів відбу-
вається за потребою, через так званий
“Lazy Loading” [15]. За замовчуванням
завантажується спільний модуль з осно-
вним функціоналом: перегляд закупівель
та деталей. Коли користувач, скажімо, у
ролі замовника, звертається до специфіч-
ної сторінки з іншого модулю, наприклад,
до сторінки створення закупівлі, то цей
модуль буде завантажено. Такий підхід
дозволяє значно прискорити завантажен-
ня головних сторінок додатку та створити
комфортний інтерфейс з мінімальною за-
тримкою для користувачів.
Аутентифікація користувачів у
клієнті відповідає стандарту OAUTH 2.0
для відкритих клієнтів. Використовується
власна бібліотека для аутентифікації та ав-
торизації за алгоритмом PKCE [16], базо-
ва реалізація якого передбачає, що клієнт
надає серверу авторизації доказ того, що
код авторизації належить саме йому, щоб
сервер видав клієнтові код доступу. Для
генерації коду доступу та коду підтвер-
дження використовується PkceGenarator
із власної бібліотеки.
PkceGenerator pkceGenerator = new ();
string codeVerifier = pkceGenerator.
CodeVerifier;
string codeChallenge = pkceGenerator.
CodeChallenge;
Було вдосконалено метод збере-
ження коду підтвердження, замінивши
сховище браузера на HttpOnly Cookie,
що у свою чергу підвищило стійкість
процесу авторизації до перехоплення ко-
дів. Логіка процесу аутентифікації та
авторизації зосереджена у двох класах:
CustomAuthenticationStateProvider та
SignInManager. Перший має посилання
на другий і наслідує та реалізовує стан-
дартний AuthenticationStateProvider із
фреймворку Blazor, котрий має два ме-
тоди: GetClaimsPrincipalAsync (для отри-
мання поточного користувача) та Notify
(для сповіщення змін у стані авториза-
ції). Другий надає повноцінний інтерфейс
для роботи з авторизацією: Login, Logout,
GetClaimsPrincipalAsync.
Авторизація користувачів для пев-
них сторінок задано через стандартний
атрибут @attribute [Authorize(Role =
“Supplier”)] (для постачальника або Role
= “Buyer” для замовника). Деякі сторін-
ки системи, такі як список закупівель не
потребують авторизації та позначаються
атрибутом @attribute [AllowAnonymous],
надаючи доступ до них без авторизації.
Для умовного показу контенту для
авторизованих користувачів на сторінках
використовується тег <Authorized>. При-
клад умовного показу кнопки подачі про-
позиції для авторизованого постачальни-
ка:
<AuthorizeView>
<h1>Деталі закупівлі</h1>
…
<Authorized Role=”Supplier”>
<MudButton Variant=»Variant.Filled»
Color=»Color.Primary»>
96
Інструментальні засоби і середовища програмування
Подати пропозицію
</MudButton>
</Authorized>
</AuthorizeView>
Клієнт використовує бібліотеку
компонентів MudBlazor [17], яка набуває
популярності серед розробників Blazor, та
має широкий набір різних компонентів і
стилів для побудови сучасного, швидкого
та привабливого інтерфейсу користувача.
Приклад сторінки з інформацією про за-
купівлю зображено на Рис. 4.
3. Публікація комплексної
системи через Docker контейнер
та моніторинг ELK
Для підтримки постійного впро-
вадження змін у системі та стабільнос-
ті використовуються 3 середовища: Dev
(для розробників), Stage (копія реальної
системи) та Prod (активна версія реальної
системи). Усі середовища незалежні один
від одного та побудовані на базі операцій-
ної системи Linux. Публікація комплексу
включає у себе 2 етапи: побудова Docker-
контейнеру [18] з вихідного коду (так зва-
ного артефакту) та розгортання контейне-
ру в обраному середовищі.
Процес побудови артефакту описа-
но через Azure Build Pipeline та включає в
себе завантаження коду з активної гілки
репозиторію, виконання команд з побудо-
ви проекту, запуск автоматичних тестів та
пакування Docker контейнеру. Таким чи-
ном, якість системи постійно контролю-
ється через автоматичні тести. Новий ар-
тефакт створюється після будь-яких змін в
основній гілці репозиторію, а також один
раз на день (nightly build).
Створений Docker контейнер публі-
кується у Dev середовищі для перевірки.
Публікація на Stage та Prod виконується
вручну після ретельного тестування та до-
даткових перевірок. Для публікації вико-
ристовується Azure Release Pipeline.
Окрему увагу було приділено моні-
торингу комплексної системи. Для моні-
торингу системи за такими параметрами
як швидкість виконання запитів, кількість
активних користувачів, критичні та не
критичні помилки, завантаженість, за-
гальний стан системи та інших викорис-
товувався стек технологій Elasticsearch,
Logstash та Kibana (ELK) [19].
Стек ELK – це найбільш популяр-
на у світі платформа для аналізу та об-
робки лог-файлів із відкритим кодом. Да-
ний набір технологій прийшов на заміну
багатьом власним реалізаціям та швидко
став стандартом індустрії. Серед корис-
тувачів стеку ELK можна зазначити такі
популярні платформи як Netflix, LinkedIn,
StackOverflow та інші. З розвитком мікро-
сервісів та серверних даних у цілому, лог-
файли стають усе більш важливими, не
тільки для пошуку потенційних проблем,
а й для моніторингу системи та оптиміза-
ції продуктивності.
Рис. 4. Сторінка інформації про закупівлю
97
Інструментальні засоби і середовища програмування
Основні компоненти стеку ELK:
• Elasticsearch: зберігає та індек-
сує дані оброблені Logstash.
• Logstash: збирає інформацію про
події, метадані та лог-файли. Оброблює
та трансформує дані перед відправкою до
Elasticsearch.
• Kibana: інструмент для ві-
зуалізації даних, який працює разом з
Elasticsearch та надає користувачам мож-
ливість аналізувати інформацію та буду-
вати складні звіти.
Слід зазначити, що для успішного
відображення даних Kibana досить на-
віть одного кластера Elasticsearch. Од-
нак завантаження інформації до пошу-
кового ядра Elasticsearch – це складне
завдання. На перший погляд може здава-
тися, що можливо завантажувати дані до
Elastisearch через простий RESTful API.
Але у такому разі система не буде працю-
вати з конкурентними запитами, де кіль-
кість запитів доходитиме до декількох со-
тень на секунду. В нашій системі електро-
нних закупівель присутні як конкурентні
запити, так і висока кількість запитів на
секунду від різних користувачів. Для того,
щоб забезпечити якісний моніторинг усіх
запитів та побудувати систему, здатну
розширятися у майбутньому, ми буде-
мо використовувати технологію Logstash
[20], котра збирає дані (лог-файли, події,
аналітику) з різних джерел, обробляє їх і
передає у Elasticsearch.
Для передачі даних у Logstash ми
використовуємо Azure Event Hubs, що яв-
ляє собою чергу низку повідомлень типу
“fire-and-forget” та має можливість розши-
рення до мільйонів повідомлень на секун-
ду [21]. Оскільки Azure Events Hubs – це
черга повідомлень, не має потреби фізич-
ного зв’язку між сервером ELK та мікро-
сервісами нашої системи, що задовольняє
критерії для публікації через Docker кон-
тейнер.
Створення лог-файлів та запис по-
дій у системі реалізовано через провай-
дер Serilog, що підтримує інтеграцію з
Azure Event Hubs [22]. Serilog надає стан-
дартну реалізацію .NET Core інтерфейсу
ILoggerFactory, через який у системі за-
писуються усі події, виключення, та мета-
дані про запит. Налаштування провайдеру
Serilog в одному із мікросервісів нашої
системи наведено нижче:
services.AddMvc(opt =>
{
opt.Filters.Add<LogResultFilter>();
});
Log.Logger = new
LoggerConfiguration()
. Wr i t e To . A z u r e E v e n t H u b ( n e w
JsonFormatter(), eventHubConfig.GetValue
<string>(«connectionString»),eventHubCon
fig.GetValue<string>(«entityName»))
.CreateLogger();
Код створює новий екземпляр кла-
су Logger та записує дані до Azure Event
Hub. Для підтримки даних у компонен-
ті Elasticsearch використовується клас
JsonFormatter. Параметри конфігурації
“connectionString” та ‘entityName” за-
дані у створеному Event Hub на порталі
Azure.
Для запису інформації про кожен
запит на сервері була написана реалі-
зація інтерфейсу IAsyncResourceFilter.
Даний метод викликається для кожно-
го запиту та передає інформацію про за-
пит через Serilog до Azure Event Hub для
подальшої індексації через ELK стек та
Рис. 5. Публікація системи через Azure
98
Інструментальні засоби і середовища програмування
відображення на сторінці моніторингу.
Приклад реалізації простого моніторингу
для кожного запиту наведено нижче:
public class LogResultFilter :
IAsyncResourceFilter
{
public async Task
OnResourceExecutionAsync(
ResourceExecutingContext context,
ResourceExecutionDelegate next)
{
await next();
var data = new
{
Action = context.ActionDescriptor.
RouteValues[«action»],
Controller = context.ActionDescriptor.
RouteValues[«controller»],
Url = context.HttpContext.Request.Path,
StatusCode = context.HttpContext.
Response.StatusCode
};
Log.Information(«Request completed: {@
data}», data);
}
}
У додаток до стандартної інформа-
ції про запит, переданої нами у прикладі,
провайдер Serilog автоматично передає
такі метадані як час виконання запи-
ту, навантаження на сервер або кластер,
кількість виділених потоків, та інше. Це
робить моніторинг системи надзвичайно
зручним та корисним.
Публікація ELK стеку виконується
у форматі окремого Docker контейнера
на виділеному сервері для використан-
ня іншими мікросервісами та модулями
комплексу. Процес публікації ідентичний
описаному вище у розділі, за винятком до-
Рис. 6. Компоненти стеку ELK
Рис. 7. Візуалізація моніторингу
99
Інструментальні засоби і середовища програмування
даткових стандартних процесів побудови
та публікації для стеку ELK.
У результаті ми розробили модуль
моніторингу для нашої комплексної сис-
теми електронних закупівель, через який
розробники можуть спостерігати за ста-
ном системи, переглядати детальну ін-
формацію про кожен запит, швидкість об-
робки, завантаженість серверу, та важливі
події у системі.
Висновки
Реалізовано комплекс автоматизації
електронних закупівель з модулем аукці-
ону на базі REST API мікросервісів, бази
MS SQL, та клієнту Blazor Web Assembly.
Надана можливість авторизувати користу-
вачів системи, а саме постачальників та
замовників на основі стандарту OAuth 2.0
через Microsoft Identity Server. Бібліотека
для роботи з розподіленим кешем Redis
використовувалась для прискорення ро-
боти системи та кешування даних на рів-
ні доступу до БД. Зміни етапів закупівлі
було реалізовано через тригери Hangfire
та кінечний автомат Stateless. Сповіщен-
ня про важливі зміни у реальному часі
виконано через протокол Web Sockets та
SignalR. Програмний комплекс підготов-
лено до публікації у Microsoft Azure, ін-
ших хмарних сервісах або на фізичних
серверах Windows/Linux через Docker
контейнер. Забезпечено моніторинг сис-
теми та модулів через стек Elasticsearch,
Logstash та Kibana (ELK) для візуалізації
стану, помилок, навантаження.
References
1. ProZorro open-source government e-pro-
curement system [Online] – Available from:
https://prozorro.gov.ua/en.
2. ProZorro results report 2022 [Online] –
Available from: https://infobox.prozorro.
org/articles/richniy-zvit-prozorro-za-rezul-
tatami-2022-roku.
3. Doroshenko, A.Yu., Bodak B.V. (2019). The
impact and unforeseen challenges of E-pro-
curement systems in Canada. Winter Info-
Com Advanced Solutions. pp. 9 10.
4. SmartTender for commercial customers [On-
line] – Available from: https://smarttender.
biz/etm/pro-kompaniyu.
5. How much money does a e-procurement sys-
tem save, Centre of Excellence in Procure-
ment [Online] – Available from: https://cep.
kse.ua/article/impact-of-prozorro/impact-
of-prozorro.pdf
6. Dapper performance benchmark, Dapper
GitHub [Online] – Available from: https://
github.com/DapperLib/Dapper/blob/main/
Readme.md.
7. Fette I, Melnikov A. (2011). The WebSocket
protocol [Online] – Available from: https://
datatracker.ietf.org/doc/html/rfc6455.
8. Overview of ASP.NET Core SignalR, Mi-
crosoft Documentation [Online] – Available
from: https://learn.microsoft.com/en-us/
aspnet/core/signalr/introduction.
9. About Swagger specification [Online] –
Available from: https://swagger.io/docs/
specification/about/.
10. Identity Server Documentation, Duende
[Online] – Available from: https://docs.du-
endesoftware.com/identityserver/v6/over-
view/.
11. Doroshenko A.Yu., Bodak B.V. (2021). De-
signing RESTful API for the e-procurement
system in private sector. Problems of pro-
gramming No 1. pp. 3 15. DOI: https://doi.
org/10.15407/pp2021.01.003.
12. Jones M., Bradley J., Sakimura M. (2015).
JSON Web Token (JWT) [Online] – Avail-
able from: https://datatracker.ietf.org/doc/
html/rfc7519.
13. ASP.NET Core Blazor, Microsoft Documen-
tation [Online] – Available from: https://
learn.microsoft.com/en-us/aspnet/core/
blazor.
14. Proof Key for Code Exchange, IETF [On-
line] – Available from: https://datatracker.
ietf.org/doc/html/rfc7636.
15. Lazy load assemblies in ASP.NET Core
Blazor Web Assembly, Microsoft Documen-
tation [Online] – Available from: https://
learn.microsoft.com/en-us/aspnet/core/
blazor/webassembly-lazy-load-assemblies.
16. Bodak B.V., Doroshenko A.Yu. (2022). Pro-
tecting public clients using an authorization
algorithm. Problems of programming No 3-4.
pp. 409 416. DOI: https://doi.org/10.15407/
pp2022.03-04.409.
17. Getting started with MudBlazor [Online] –
Available from: https://mudblazor.com/get-
ting-started/installation.
100
Інструментальні засоби і середовища програмування
18. Building a Docker image for ASP.NET
Core, Microsoft Documentation [Online] –
Available from: https://learn.microsoft.com/
en-us/aspnet/core/host-and-deploy/docker/
building-net-docker-images.
19. What is ELK Stack, Elastic [Online] – Avail-
able from: https://www.elastic.co/what-is/
elk-stack.
20. Logstash introduction, Elastic [Online] –
Available from: https://www.elastic.co/
guide/en/logstash/current/introduction.html.
21. About Azure Event Hubs – A big data
streaming platform, Microsoft Documenta-
tion [Online] – Available from: https://learn.
microsoft.com/en-us/azure/event-hubs/
event-hubs-about.
22. How to log events to Azure Event Hubs in
Azure API Management, Microsoft [Online]
– Available from: https://learn.microsoft.
com/en-us/azure/api-management/api-man-
agement-howto-log-event-hubs.
Одержано: 18.05.2023
Про авторів:
Дорошенко Анатолій Юхимович,
доктор фізико-математичних наук,
професор, завідувач відділу теорії
комп’ютерних обчислень Інституту
програмних систем НАН України,
професор кафедри інформаційних систем
та технологій НТУУ «КПІ імені Ігоря Сі-
корського».
Кількість наукових публікацій в
українських виданнях – понад 200.
Кількість наукових публікацій в
іноземних виданнях – понад 100.
Індекс Гірша – 6.
http://orcid.org/0000-0002-8435-1451,
Бодак Богдан Вікторович,
аспірант кафедри інформаційних систем
та технологій НТУУ «КПІ імені Ігоря Сі-
корського».
Кількість наукових публікацій в
українських виданнях – 4.
http://orcid.org/0000-0002-4854-2314.
Місце роботи:
Інститут програмних систем
НАН України,
03187, м. Київ-187,
проспект Академіка Глушкова, 40.
|