Покращення та виправлення дефектів у релізі 1.9.8

ЗМІСТ

URL не змінювався у ресурсах після налаштування доменного імені для Keycloak

Суть:

При додаванні власного DNS і виборі його у налаштуваннях Keycloak, запити до зовнішніх систем отримували статус-коди 401 через некоректне оновлення URL у ресурсах.

Що виправлено:

  1. Додано логіку для автоматичного оновлення DNS у наступних ресурсах:

    • Search—KongPlugin:

      • external-system-bp-gateway-nopublic-oidc

      • external-system-datafactory-nopublic-oidc

    • Search—RequestAuthentication:

      • registry-rest-api-ext-request-auth

  2. Оновлено налаштування інтеграції з зовнішніми системами, щоб запити коректно передавали токени.

Результат:

  1. Запити до бізнес-процесів в іншому реєстрі (POST) повертають код відповіді 200.

  2. Запити до зовнішньої системи (GET/POST) також повертають код відповіді 200.

Неможливо автентифікуватися до кабінету користувача, якщо в ключі відсутній атрибут EDRPOU

Суть:

Якщо адміністратор реєстру налаштував автентифікацію через id.gov.ua та увімкнув можливість для автентифікації фізичних осіб у кабінет користувача, при спробі автентифікуватись в Officer Portal фізичною особою, виникала помилка.

Що виправлено:

  • Скориговано механізм обробки токенів автентифікації для фізичних осіб, який дозволяє фізичним особам автентифікуватися без необхідності EDRPOU в ключі.

Результат:

  1. Фізичні особи можуть успішно автентифікуватися в Officer Portal без наявності EDRPOU у ключі.

  2. Система коректно обробляє всі запити автентифікації через id.gov.ua.

Дублікати сутностей у БД через таймаут kafka-api

Суть:

При виконанні задачі зі збереженням сутності у БД, якщо Kafka не встигала обробити запит протягом 30 секунд, REST API отримував таймаут-помилку. Через невизначеність результатів запита, існувала ймовірність дублювання сутностей у БД.

Що виправлено:

  • Додано можливість змінювати конфігурацію таймаута для bpms.

  • Додано можливість налаштувати таймаут звернення rest-api до kafka.

    Детальніше про налаштування значень таймауту див. на сторінці Налаштування таймауту для BPMS та Rest API.

Результат:

Зменшена вірогідність створення дублікатів сутностей у БД та виникнення помилок.

Користувачі з доступом до redash-viewer можуть редагувати запити

Суть:

Користувачі, автентифіковані через Officer Portal, мали змогу редагувати та зберігати наявні запити у розділі Звіти  redash-viewer, що не відповідало політикам доступу.

Що виправлено:

  • Впроваджено обмеження доступу для ролі redash-viewer, що унеможливлює редагування та збереження запитів.

  • Перевірено коректність налаштувань доступу для інших ролей.

Результат:

Користувачі з роллю redash-viewer можуть лише переглядати запити без можливості їх редагування.

Делегат getUsersByRoleFromKeycloak повертає до 100 записів

Суть:

Делегат getUsersByRoleFromKeycloak повертав максимум 100 записів про користувачів з Keycloak, що обмежувало доступ до повного списку користувачів.

Що виправлено:

  • Реалізовано можливість повертати необхідну кількість користувачів.

  • Додано нові поля до шаблону делегата: Limit та Offset.

  • Реалізовано пагінацію.

Ознайомтеся детальніше із налаштуваннями делегата на сторінці Отримання користувачів за роллю з Keycloak: Get users by role from keycloak.

Результат:

Делегат тепер може повертати вказану кількість користувачів, залежно від налаштувань параметрів.

Застарілий URL для ІІТ-віджету

Суть:

Стара версія ІІТ-віджету https://eu.iit.com.ua/sign-widget/v20200922/ застаріла (deprecated) з квітня 2024 року. Необхідно оновити URL на нові версії.

Що виправлено:

Оновлено URL для ІІТ-віджету у коді: https://eu.iit.com.ua/sign-widget/v20240301/

Результат:

  • Всі інтеграції використовують актуальні версії ІІТ-віджету.

Помилка при додаванні Search Condition із назвою, ідентичною назві таблиці

Суть:

При додаванні критерію пошуку (Search Condition) із назвою, яка збігається з назвою наявної таблиці, після розгортання регламенту сервіс registry-rest-api ламався з помилкою через конфлікт назв POST-ендпоінтів.

Що виправлено:

Виправлено генерацію ендпоінтів для SC: уникнуто створення POST ендпоінтів для SC з назвами, що збігаються з назвами наявних таблиць.

Див. детальніше про функціональність у розділі Оператор in / notIn.

Результат:

  1. Сервіс registry-rest-api більше не ламається через конфлікти назв ендпоінтів.

  2. Додавання SC із назвами, що збігаються з назвами таблиць, виконується коректно.

Шаблон делегата Create Keycloak Officer User не підтримує введення даних фізичних осіб

Суть:

Шаблон делегата Create Keycloak Officer User дозволяв створювати користувачів тільки для юридичних осіб, оскільки параметр ЄДРПОУ був обов’язковим. Це обмежувало можливість створення користувачів для фізичних осіб.

Що виправлено:
Залучені компоненти:

  • bpms

  • registry-configuration

Результат:

Уповноважені особи можуть створювати користувачів як для фізичних, так і для юридичних осіб.

Помилка при додаванні нової ролі після відновлення реєстру з резервної копії

Суть:

Після відновлення реєстру з бекапу та додавання нової ролі у регламент, виникала помилка unable to put roles batch: one of batch role already exists у ресурсі KeycloakRealmRoleBatches, що заважало створенню нової ролі у відповідному Keycloak реалмі.

Обхід проблеми:

Видалення створених Keycloak ролей в OpenShift призводить до їх успішної реконсиляції та перестворення у відповідному Keycloak-реалмі.

Результат:

Нова роль додається у відповідний Keycloak-реалм без помилок.

Неможливо створити користувача "фізичну особу", якщо існує користувач "юридична особа" з подібними атрибутами

Суть:

При створенні фізичної особи через делегат keycloakCreateOfficerUserConnectorDelegate, якщо вже існує юридична особа з тими ж атрибутами, зокрема fullName та DRFO, виникала валідаційна помилка: Found 2 users with the same attributes. Це блокувало створення користувача-фізичної особи.

Що виправлено:

  • Додано перевірку атрибутів під час створення користувача, щоб розрізняти фізичних та юридичних осіб.

  • Впроваджено унікальність обробки атрибутів, яка дозволяє успішно створювати користувачів фізичних осіб навіть при схожих атрибутах у юридичних осіб.

Результат:

  1. Користувачі, фізичні та юридичні особи, можуть бути створені без конфліктів.

  2. Делегат keycloakCreateOfficerUserConnectorDelegate коректно обробляє випадки з однаковими атрибутами.

Покращення: повідомлення про підтримувані браузери для Diia.Engine

Суть:

Diia.Engine гарантовано працювала лише у браузері Chrome. В інших браузерах (Firefox, EDGE, Safari) була можлива некоректна робота або відображення елементів. Починаючи з релізу 1.9.8, додано підтримку браузера Safari.

Що реалізовано:

Додано popup-нотифікацію на сторінки кабінетів користувача, отримувача послуг та адміністратора регламенту з повідомленням про підтримувані браузери.

Опис повідомлення:

  • UA: "Застосунок може працювати некоректно у поточному браузері, який не підтримується для вашого пристрою. Будь ласка, перейдіть у підтримуваний Chrome-браузер".

  • EN: "App may not function appropriately in the current browser on your device. Please try in supported Chrome browser."

Кнопка:

  • UA: Зрозуміло

  • EN: Understood

Налаштована логіка відображення:

  • У браузерах Chrome та Safari: нотифікація не відображається.

  • В інших браузерах:

    • Нотифікація відображається.

    • Після натискання кнопки Зрозуміло / Understood, popup-нотифікація закривається.

    • При переході на іншу сторінку, оновленні поточної або відкритті за прямим посиланням, popup-нотифікація знову відображається.

Результат:

  1. Користувачі отримують чітке повідомлення про підтримувані браузери для коректної роботи Diia.Engine.

  2. Покращено взаємодію з користувачами у браузерах, які не підтримуються.

Тимчасова БД не містить поточних змін у БД версії-кандидата

Суть:

Зміни, внесені до БД версії-кандидата (наприклад, створення нових таблиць), не застосовувались у тимчасовій БД, створеній у рамках цієї версії, що унеможливлювало тестування змін.

Що виправлено:
Результат:

  1. Зміни у БД версії-кандидата, зокрема створення нових таблиць, автоматично застосовуються у тимчасовій БД.

  2. Таблиця, створена у версії-кандидаті, доступна у тимчасовій БД для тестування.

Покращення: налаштування обов’язковості параметрів запита для критеріїв пошуку

Суть:

Раніше, якщо параметри не були задані під час виконання пошукового запита, система повертала всі доступні значення. Це могло призвести до небажаних наслідків, таких як витік персональних або конфіденційних даних, що зберігаються в реєстрі. Крім того, стара реалізація вимагала від бізнес-процесу створення окремих гілок для кожного можливого набору параметрів, що значно ускладнювало його конфігурацію та підтримку.

Що реалізовано:

  • Додано можливість для моделювальників під час налаштування Search Condition позначати окремі параметри як обов’язкові.

  • Якщо обов’язкові параметри не надійшли, запит повертає помилку з описом проблеми.

Результат:

  1. Зменшено ризик витоку конфіденційних даних через некоректні запити.

  2. Забезпечено контроль і безпеку даних у реєстрах завдяки обов’язковим параметрам у запитах.

  3. Моделювальники отримали гнучкий інструмент для визначення важливості параметрів запиту.

Ознайомтеся зі змінами більш детально на сторінці Атрибут required.

Покращення: налаштування RBAC ролей для критеріїв пошуку окремо від таблиці

Суть:

Раніше RBAC-ролі, встановлені для таблиці, автоматично розповсюджувались на всі критерії пошуку (Search Conditions, SC), що обмежувало можливість гнучкого управління доступом.

Що реалізовано:

Додано можливість налаштовувати RBAC-ролі для критеріїв пошуку окремо від таблиці.

Результат:

  1. Адміністратори можуть окремо визначати доступ для таблиць та/або критеріїв пошуку.

  2. Забезпечено гнучке управління правами доступу відповідно до бізнес-вимог.

Ознайомтеся зі змінами більш детально на сторінці Моделювання доступу до даних за допомогою RBAC.

Таймаут при очищенні Redis через велику кількість ключів

Суть:

При завершенні бізнес-процесу (БП), якщо у Redis зберігалось понад 200 тисяч ключів, процес очищення даних міг тривати понад 30 секунд. Це спричиняло таймаут-помилку і перешкоджало коректному завершенню БП.

Що виправлено:

Змінено логіку генерації ключів:

  • Під час створення нового інстансу БП створюється сутність у Redis з ID інстансу.

  • Масив ключів додається до цієї сутності, а видалення виконується шляхом отримання масиву ключів за ID інстансу.

Залучені компоненти:

  • bpms

  • user-task-management

  • registry-configuration

  • form-data-storage

Результат:

  1. Таймаут-помилки при завершенні БП усунено завдяки асинхронному очищенню.

  2. Оптимізовано логіку очищення даних у Redis для зменшення навантаження.

  3. Адміністраторам надано можливість керувати процесом очищення через налаштування toggles.

  4. Всі покращення доступні у новому інсталяторі релізу 1.9.8.

Актуальні оновлення документації та налаштування, пов’язані з очищенням застарілих бізнес-процесів та залежних компонентів, можна переглянути на сторінках розділу Видалення застарілих бізнес-процесів.

Видалення тимчасових даних БП з Redis працює нестабільно і не запускається у певних сценаріях

Суть:

Процес видалення тимчасових даних бізнес-процесів (БП) з Redis не запускався у певних сценаріях:

  • Завершення саб-процесів, які запускаються за подіями: помилка, повідомлення, таймер.

  • Видалення процес-інстансу через Camunda cockpit.

Бізнес-процеси, де виникала проблема:

  • sub-process by error: підпроцес, що ініціюється помилкою (catch error event).

  • sub-process by message: процес, що отримує повідомлення 'message event' для ініціалізації підпроцесу.

  • sub-process by timer: підпроцес, який запускається за подією таймера.

Що виправлено:

  • Оновлено бібліотеку ddm-starter-juel-function до актуальної версії.

  • Застосовано зміни до компонентів bpms, bp-admin-portal, та control-plane-gerrit.

Залучені компоненти:

  • bpms

  • bp-admin-portal

  • control-plane-gerrit

  • ddm-starter-juel-function

Результат:

  1. Процес видалення тимчасових даних БП з Redis стабільно запускається у всіх сценаріях.

  2. Враховано залежність із послідовністю виправлення на Таймаут при очищенні Redis через велику кількість ключів.

Покращення: налаштування timeout для redash-viewer

Суть:

У компоненті redash-viewer, при завантаженні звіту з великою кількістю колонок (>700) і записів (~1770), процес завершувався з помилкою через таймаут у 30 секунд.

Що реалізовано:

Додано можливість налаштування таймаута для компонентів:

  • redash

  • Для компонентів kong та common-web-app таймаут за замовчуванням залишився без змін, але його також можна змінити.

Див. детальніше на сторінці: Налаштування таймаутів для Redash, Kong та Common Web App.

Залучені компоненти:

  • redash

  • kong

  • common-web-app

Результат:

  1. Адміністратори та розробники реєстру можуть налаштовувати таймаут для завантаження великих звітів.

  2. Звіти з великою кількістю колонок і записів успішно завантажуються без помилок.

Помилка "Could not parse BPMN process" при відкритті бізнес-процесу з HTTP SOAP Connector у Camunda Cockpit

Суть:

При спробі адміністратора регламенту відкрити бізнес-процес (БП), що використовує загальний делегат HTTP SOAP Connector, у Camunda Сockpit виникала помилка:

ENGINE-09005 Could not parse BPMN process. Errors: One of the attributes 'class', 'delegateExpression', 'type', or 'expression' is mandatory on serviceTask. If you are using a connector, make sure the connect process engine plugin is registered with the process engine.

Що виправлено:

  • Оновлено версію плагіну camunda-engine-plugin-connect до 7.20.0.

  • Додано залежність:

    <dependency>
    <groupId>org.camunda.bpm</groupId>
    <artifactId>camunda-engine-plugin-connect</artifactId>
    <version>${camunda-engine-plugin-connect.version}</version>
</dependency>
Результат:

  1. Адміністратори можуть успішно відкривати БП, що використовують HTTP SOAP Connector, у Camunda Cockpit без помилок.

  2. Забезпечено стабільну роботу з процесами, які використовують універсальні делегати.

Неможливість виконати розсилку великим групам користувачів

Суть:

При розсилці нотифікацій на великі групи користувачів (наприклад, 5000 користувачів) через ddm-notification-service, після кількох батчів сервіс ламався із помилкою java.lang.OutOfMemoryError. Це спричиняло зупинку процесу розсилки та накопичення не відправлених повідомлень у Kafka.

Що виправлено:

  • Оптимізовано використання пам’яті у ddm-notification-service.

  • Оптимізовано обробку батчів, щоб уникнути перевищення лімітів ресурсів.

  • Впроваджено механізм поступової обробки повідомлень у батчах, що дозволяє проходити до 50000 повідомлень одним батчем без перевантаження системи.

  • Перевірено стабільність роботи сервісу при високих навантаженнях.

Результат:

  1. ddm-notification-service тепер успішно обробляє до 50000 повідомлень одним батчем.

  2. Розсилки на великі групи користувачів виконуються стабільно без помилок.

  3. Не відправлені повідомлення у Kafka більше не накопичуються.

Помилка парсингу JSON при використанні атрибуту searchType="in" у searchCondition

Суть:

Використання атрибута searchType="in" у searchCondition спричиняло помилку парсингу JSON, якщо передавалося значення без обгортання у масив, що порушувало зворотну сумісність. Атрибут очікував вхідний масив навіть для одного елемента.

Що виправлено:

  • Внесено зміни для обробки одиничних значень як масивів, забезпечуючи стабільну роботу searchType="in" незалежно від кількості переданих значень.

  • Додано логіку, яка автоматично загортає одиничне значення у масив перед передачею до searchCondition.

Результат:

  1. Атрибут searchType="in" коректно працює як з одиничними значеннями, так і з масивами.

  2. Уникнуто помилок парсингу JSON при формуванні запитів.

  3. Забезпечено стабільну роботу searchCondition у всіх сценаріях використання.

Ознайомтеся детальніше з атрибутом searchType на сторінці Атрибут searchType.

Помилка при розгортанні registry-rest-api після додавання RLS addReadRule та addWriteRule

Суть:

При додаванні правил рівня безпеки (RLS), addReadRule та addWriteRule, для таблиць виникала проблема, через яку процес збірки registry-rest-api завершувався з помилкою.

Що виправлено:

  • Оновлено бібліотеку service-generation-utility до актуальної версії, яка враховує сумісність із функціональністю релізу 1.9.8.

  • Актуалізовано dataplatform-jenkins-agent для інтеграції з оновленою версією service-generation-utility.

Залучені компоненти:

  • dataplatform-jenkins-agent

  • service-generation-utility

  • registry-rest-api

Результат:

  1. Розгортання registry-rest-api успішно виконується після додавання RLS-правил.

  2. Забезпечено стабільну роботу компонентів, навіть за наявності інших виправлень у релізі 1.9.8.

Ознайомтеся з деталями налаштування RLS на сторінці Ієрархічна модель.

Неможливість відправлення email із крапкою перед @

Суть:

Email-адреси, у яких перед символом @ присутня крапка (наприклад, name.surname@gmail.com), помилково потрапляли до blacklist через налаштування regex для валідації пошти, що унеможливлювало їх відправлення з вебпорталів.

Що виправлено:

  • Оновлено regex для валідації email-адрес на бекенді, щоб дозволити адреси з крапкою перед @.

  • Виправлено логіку валідації у делегаті SendUserNotificationByAddress, щоб виключити помилкове внесення таких адрес у blacklist.

Результат:

  1. Email-адреси з крапкою перед @ більше не блокуються.

  2. Повідомлення успішно надсилаються на такі адреси.

Детальніше про особливості налаштування blacklist для надсилання повідомлень див. на сторінці Відправлення сповіщень на електронні адреси з фільтрацією Blacklist.

Налаштування апаратного ключа зникають із values.yaml після внесення змін у Control Plane

Суть:

Після внесення змін у реєстр через Control Plane (наприклад, додавання адміністратора), налаштування для апаратного ключа ("Гряда") зникають із файлу values.yaml.

Що виправлено:

  • Усунуто видалення налаштувань апаратного ключа при оновленні реєстру через Control Plane.

  • Забезпечено збереження всіх налаштувань апаратного ключа у файлі values.yaml після внесення змін у реєстр.

Залучені компоненти:

  • control-plane

  • registry-configuration

Результат:

  1. Налаштування апаратного ключа більше не видаляються після оновлення реєстру через Control Plane.

  2. Забезпечено стабільність конфігурації файлу values.yaml.

Опція автозаповнення для компонентів TextField, Number, Email за замовчуванням увімкнена

Суть:

При додаванні компонентів TextField, Number, Email на форму у конструкторі форм, опція autocomplete за замовчуванням була увімкнена (on) замість очікуваного значення off.

Що виправлено:

  • Змінено поведінку за замовчуванням для опції autocomplete, яка тепер встановлюється у значення off для компонентів TextField, Number, Email при їх додаванні на форму.

Залучені компоненти:

  • form-builder

Результат:

  1. При додаванні компонентів TextField, Number, Email на форму, опція autocomplete за замовчуванням вимкнена (off).

  2. Адміністратори регламенту більше не потребують ручного вимкнення цієї опції.

Помилка "Crypto library initialization failed: Incorrect parameter" при автентифікації через id.gov.ua з використанням апаратного ключа "Гряда"

Суть:

При оновленні реєстру з попередньої версії, виникала помилка Crypto library initialization failed: Incorrect parameter при автентифікації через id.gov.ua з використанням апаратного ключа "Гряда". У Keycloak та DSO-логах фіксувалися відповідні помилки:

  • Keycloak: "Crypto library initialization failed: Incorrect parameter"

  • DSO: "Could not obtain user profile from idgovua."

Причина:

Невірна реалізація використання апаратних ключів у "Гряді" у сценарії з декількома ключами на Платформі. Проблема потребувала рефакторингу компонентів DSO та Control Plane.

Що виправлено:

  • Виконано рефакторинг використання апаратних ключів у "Гряді".

Залучені компоненти:

  • digital-signature-ops

  • control-plane-console

  • edp-library-stages-fork

  • keycloak

  • common-web-app

Результат:

Автентифікація через id.gov.ua з використанням апаратного ключа "Гряда" працює стабільно після оновлення Платформи.

Посилання на реєстровий Jenkins у Gerrit містять стару назву платформи після міграції

Суть:

Після міграції реєстру з Платформи А на нову платформу Б, посилання на збірки Code Review та MASTER-Build реєстрового Jenkins у Gerrit залишалися із назвою Платформи A.

Що виправлено:

  • Додано автоматичне оновлення URL Jenkins після міграції через створення нового скрипту change_url.groovy для ініціалізації актуальної URL у Jenkins.

  • Оновлено логіку відновлення у файлі restore-registry.sh, щоб під час відновлення забезпечити коректну зміну URL у Jenkins.

Залучені компоненти:

  • backup-management

  • Jenkins

  • restore-registry.sh

Результат:

  1. Після міграції платформи посилання на Jenkins у Gerrit автоматично оновлюються відповідно до нової платформи.

  2. Забезпечено стабільність і коректність URL для код збірок Code Review та MASTER-Build.

Детальніше про міграцію реєстрів ви можете дізнатися на сторінці Міграція реєстрів.

Обмеження доступу адміністраторів реєстрів до ключів шифрування

Суть:

Адміністратори реєстрів при налаштуванні реєстрової інтеграції з id.gov.ua могли бачити всі ключі шифрування, додані адміністратором Платформи, замість доступу лише до ключів, дозволених для їхнього реєстру.

Що виправлено:

Виправлено логіку, яка обмежує доступ до ключів шифрування. Адміністратор реєстру бачить лише ключі, які дозволені для його реєстру адміністратором Платформи.

Ознайомтеся детальніше із налаштуваннями реєстрової інтеграції з id.gov.ua на сторінках:

Результат:

  1. Адміністратор реєстру бачить тільки дозволені для його реєстру ключі шифрування.

  2. Налаштування реєстрової інтеграції з id.gov.ua стало більш безпечним і контрольованим.

Оптимізація логіки роботи init stage для пайплайну публікації регламенту реєстру

Суть:

Покращено логіку роботи init stage для пайплайну публікації регламенту реєстру.

Що реалізовано:

Скорочено імена ресурсів, до яких виконується запит через oc-клієнт, що зменшило час виконання stage.

Результат:

  1. Знижено час виконання init stage у пайплайні публікації регламенту.

  2. Забезпечено більш ефективну роботу пайплайну.

Актуалізація налаштувань виділення ресурсів для Keycloak

Суть:

Оптимізовано виділення ресурсів для платформного сервісу Keycloak, щоб забезпечити стабільність роботи та оптимальне використання пам’яті й CPU.

Що покращено:

  • Переглянуто співвідношення requests і limits для пам’яті та CPU, щоб забезпечити достатню кількість ресурсів для пікових навантажень.

  • Оновлено параметри JVM для більш ефективного управління пам’яттю та налаштування мережевих таймаутів.

Результат:

  1. Забезпечено стабільну роботу Keycloak при високих навантаженнях.

  2. Оптимізовано використання ресурсів платформи.

Помилка "Send failed; nested exception is TimeoutException" у process-history-service-api

Суть:

У сервісі process-history-service-api (user-process-management) періодично виникала помилка: Send failed; nested exception is org.apache.kafka.common.errors.TimeoutException: Topic audit-events not present in metadata after 60000 ms.. Проблема проявлялась при активній навігації на сторінках завершених бізнес-процесів у кабінетах отримувачів або надавачів послуг.

Що виправлено:

Додано відповідну політику до kafka-cluster-kafka-bootstrap-policy: політика з міткою app: user-process-management.

Залучені компоненти:

  • process-history-service-api

  • user-process-management

  • Kafka

Результат:

  1. Усунуто таймаут помилки при роботі з topic audit-events.

  2. Стабілізовано роботу сервісів при навігації на сторінках завершених бізнес-процесів.

Проблеми з відновленням Kafka під час відновлення реєстру

Суть:

Під час відновлення реєстру виникали дві основні проблеми, які перешкоджали коректному відновленню Kafka:

  1. Періодичне застрягання подів Kafka та Nexus через недостатність ресурсів для Restic. Логи містили повідомлення:

    Restic is not initialized in pod kafka-cluster-kafka-0

    Restic is not initialized in pod nexus-77d99c94b4-2plct

  2. Неможливість відновлення образів (volumes) Kafka через особливості зберігання даних у форматі sparse files, що призводило до значної різниці між номінально зайнятим та фактичним місцем.

Що виправлено:

Оптимізовано процедуру відновлення Kafka:

  • Виключення Kafka зі списку ресурсів на початковому етапі відновлення для створення порожніх PVC.

  • Додано окремий етап відновлення StatefulSet Kafka з використанням Restic для запису даних із бекапу на PVC.

  • Забезпечено коректне відновлення CustomResource Kafka після завершення відновлення PVC та StatefulSet.

  • Налаштовано управління ресурсами для Restic під час відновлення, щоб уникнути "застрягання" подів.

Залучені компоненти:

  • Kafka

  • Nexus

  • Velero

  • Restic

Результат:

  1. Забезпечено стабільне відновлення Kafka та Nexus під час відновлення реєстру.

  2. Усунуто проблеми із відновленням sparse files у Kafka.

  3. Відновлення реєстру завершується успішно без втрат даних.

Не обробляється помилка "Jwt is expired (401)" при взаємодії bpms з registry-rest-api через конектори

Суть:

При взаємодії bpms з registry-rest-api через конектори, у разі використання токена, час дії якого сплив, або токена з мінімальним часом дії (expire), помилка Jwt is expired (401) не обробляється. Це призводило до виникнення помилки 500 у логах без відображення релевантної інформації.

Що виправлено:

  • Додано обробку помилки 401 у DataFactoryErrorDecoder, щоб забезпечити відповідне відображення помилки JWT token expired у логах.

  • Оптимізовано механізм обробки виключень у Feign-конфігурації для коректного інформування про помилки аутентифікації.

Залучені компоненти:

  • bpms

  • registry-rest-api

  • ddm-data-factory-feign-config

Результат:

  1. Помилка Jwt is expired (401) обробляється коректно.

  2. У логах сервісів відображається релевантна інформація про помилку JWT token expired.

Покращення: впровадження логіки використання єдиного облікового запису для автентифікації користувачів

Суть:

Впроваджено нову логіку автентифікації "Single Identity" для кабінетів користувачів, що забезпечує контроль унікальності облікового запису користувача на основі атрибутів fullName та drfo. Це дозволяє уникнути конфліктів під час автентифікації різних типів користувачів (фізичних осіб, ФОП та юридичних осіб), які можуть мати однакові атрибути.

Що реалізовано:

  • Додано налаштування SingleIdentityEnabled у файлі deploy-templates/values.yaml, яке дозволяє вмикати або вимикати логіку "Single Identity".

  • Нова логіка автентифікації передбачає:

    • використання одного облікового запису Keycloak для автентифікації користувачів із ролями legal, entrepreneur, individual;

    • незмінність атрибутів в обліковому записі Keycloak незалежно від типу користувача;

    • блокування автентифікації, якщо у системі Keycloak існує декілька облікових записів з однаковими fullName та drfo.

  • Зміни інтегровані у конфігурацію KeycloakAuthFlow з параметром SingleIdentityEnabled.

Результат:

  1. Забезпечено унікальність облікового запису користувача в Keycloak.

  2. Підвищено безпеку та надійність автентифікації.

  3. Зменшено ризик помилок через дублювання акаунтів з однаковими атрибутами.

Ознайомтеся з налаштуваннями функціональності на сторінці Використання єдиного облікового запису в системі.

Покращення: налаштування та відображення посилання на службу підтримки у Кабінетах користувачів

Суть:

Реалізовано функціональність налаштування та відображення посилання на канал зв’язку зі службою підтримки, що дозволяє користувачам швидко отримувати допомогу.

Що реалізовано:

  • В Адміністративному порталі додано нове поле Посилання на канал зв’язку зі службою підтримки (параметр supportChannelUrl) для налаштування одного посилання на службу підтримки.

  • Поле включає стандартні правила валідації посилання для забезпечення коректного введення.

  • У Кабінетах надавача та отримувача послуг додано відображення налаштованого посилання на службу підтримки:

    • Посилання відображається у header-частині кабінету на всіх сторінках: стартова сторінка, сторінка автентифікації Keycloak, всі внутрішні сторінки кабінету, форми задач, профіль тощо.

    • Посилання клікабельне; при натисканні система перенаправляє користувача на вказаний ресурс.

Результат:

  1. Спрощено доступ користувачів до служби підтримки через кабінети.

  2. Забезпечено єдиний канал зв’язку для оперативного розв’язання проблем.

  3. Підвищено зручність використання системи для кінцевих користувачів.

Ознайомтеся з більш детальною інформацією про налаштування у розділі Посилання на канал зв’язку зі службою підтримки.

Покращення: оновлення AMI для компонентів MS logging, storage, registry-tenant-template

Суть:

Оновлено AMI для забезпечення працездатності компонентів системи та уникнення проблем із видаленою версією AMI.

Що реалізовано:

  • Видалену стару версію AMI: ami-094fe1584439e91dd;

  • Встановлено нову версію AMI: ami-06dac8f4521e7ec39.

Результат:

Забезпечено стабільну роботу компонентів системи шляхом переходу на нову версію AMI.

Покращення: оновлення CLI та оптимізація init stage у пайплайнах публікації регламенту

Суть:

Оновлено інструменти та оптимізовано логіку роботи в пайплайнах публікації регламенту для підвищення продуктивності та зручності.

Що реалізовано:

  • Оновлено версії oc та kubectl CLI у пайплайнах публікації регламенту.

  • Оптимізовано логіку роботи init-етапу шляхом скорочення імен ресурсів, до яких виконується запит oc-клієнта.

Результат:

  1. Підвищено продуктивність та ефективність виконання пайплайнів.

  2. Забезпечено актуальність інструментів CLI для роботи з Kubernetes.

  3. Зменшено час виконання запитів завдяки оптимізації імен ресурсів.

Покращення: рівномірний розподіл навантаження на поди Keycloak

Суть:

Впроваджено налаштування для забезпечення рівномірного розподілення навантаження на поди сервісу Keycloak.

Що реалізовано:

  • Оптимізовано механізм балансування навантаження для подів Keycloak.

Результат:

  1. Підвищено стабільність та продуктивність Keycloak завдяки рівномірному розподілу запитів.

  2. Зменшено ризик перевантаження окремих подів.

Покращення: оновлення метрик Keycloak і відповідних дашбордів Grafana

Суть:

Реалізовано функціональність збору статистичних даних про використання ресурсів Keycloak за допомогою плагіна keycloak-metrics-spi. Це дозволяє забезпечити більш детальний моніторинг та аналіз роботи Keycloak.

Що реалізовано:

  • Оновлено версію плагіна keycloak-metrics-spi.

  • У конфігурації statefulset.yaml додано новий параметр DISABLE_EXTERNAL_ACCESS для забезпечення додаткового контролю доступу до метрик.

  • У values.yaml додано новий параметр metrics.externalAccessDisabled, який дозволяє обмежити зовнішній доступ до метрик.

  • Налаштовано Event Listeners у Keycloak, додано новий metrics-listener для збору метрик.

  • Внесено зміни у файли Helm та Jenkins-пайплайнів для підтримки нової функціональності.

Результат:

  1. Забезпечено можливість збору та аналізу статистичних даних Keycloak для покращення продуктивності та стабільності системи.

  2. Підвищено безпеку доступу до метрик шляхом контролю зовнішнього доступу.

Покращення: послідовність Kafka-повідомлень у межах бізнес-процесу

Суть:

Усунено проблему неконсистентного стану, яка виникала через непослідовне потрапляння Kafka-повідомлень у різні topic-и в межах одного бізнес-процесу (наприклад, при створенні витягу).

Що виправлено:

  • Для забезпечення послідовності Kafka-повідомлень реалізовано наступні зміни в логіці:

    • Повідомлення тепер спрямовуються у topic на основі унікального ідентифікатора процесу (dto.getProcessInstanceId). Це гарантує, що всі повідомлення, пов’язані з одним бізнес-процесом, потрапляють до одного topic-а.

    • Додатково повідомлення розподіляються за ідентифікатором активності (dto.getActivityInstanceId). Це забезпечує точний контроль послідовності всередині процесу.

    • Оновлено метод send, який відправляє повідомлення до Kafka:

  • У разі успішного відправлення записується DEBUG-лог із деталями повідомлення і топіка.

  • У разі помилки записується WARNING-лог з інформацією про невдале відправлення та причину збою.

Результат:

  1. Усі Kafka-повідомлення в рамках інстансу бізнес-процесу тепер потрапляють у відповідний топік послідовно.

  2. Забезпечено консистентний стан даних під час виконання бізнес-процесів.

Покращення: оптимізація конфігурації ресурсів для Ceph

Суть:

Під час аналізу використання ресурсів Ceph у виробничих середовищах було прийнято рішення оптимізувати параметри ресурсів requests/limits для підвищення ефективності збереження файлів.

Що реалізовано:

Оновлено значення requests і limits для CPU та пам’яті:

  • mds:

    • CPU: збільшено limits з 3 до 4, а requests з 1 до 2.

    • Memory: збільшено limits з 8Gi до 12Gi.

  • rgw:

    • CPU: збільшено limits з 2 до 4, а requests з 1 до 2.

    • Memory: збільшено limits з 4Gi до 12Gi.

  • storageDeviceSets:

    • CPU: збільшено limits з 2 до 4, а requests з 1 до 2.

    • Memory: збільшено limits з 5Gi до 16Gi, а requests з 5Gi до 8Gi.

Результат:

  1. Покращено швидкість та ефективність процесу збереження файлів у Ceph.

  2. Підвищено продуктивність системи завдяки оптимізованому використанню ресурсів.

  3. Забезпечено стабільність та зменшено ймовірність затримок під час обробки великих обсягів даних.

Покращення: Додавання local time fixer до CEPH

Додано toleration, щоб local time fixer працював на storage-нодах CEPH:

- key: node.ocs.openshift.io/storage
  operator: Equal
  value: "true"
  effect: NoSchedule

Покращення: Відображення Kong cookie lifetime

У порталах тепер видно значення lifetime для Kong session cookie (за замовчуванням 3600).

Помилка в Edit Grid при пошуку

Виправлено помилку TypeError: (n || "").toLowerCase is not a function, яка виникала під час пошуку у Edit Grid.

Покращення: Retrying помилок при інтеграції з "Гряда"

Оновлено бібліотеку ІІТ, налаштовано таймаут endUser, усунуто потребу перезапуску сервісу.

  • Додано підтримку file context.

  • Розширено можливості retrying.

Покращення: Моніторинг Kafka

Додано нові метрики:

  • Загальна кількість повідомлень у топіку.

  • Under-replicated partitions.

  • Варіанти реалізації Consumer Lag.