• Логіка міграції обʼєктів ЦБД2 на ЦБД-нову
  • Обʼєкти, які мігруємо:
  • Основні правила роботи з мігрованими обʼєктами
• Відображення мігрованих Обʼєктів
  • Procedure
    • Кількість процедур
    • Структура моделі
    • Мапінг Класифікаторів
    • Мапінг Cancellations
    • Особливості міграції документів
  • API Endpoints
    • Таблиця GET endpoints для отримання одиничних сутностей:
  • Auction Module
• Приклади обʼєктів ДО\ПІСЛЯ
  • Asset, Announcement, Redemption, Executon

Логіка міграції обʼєктів ЦБД2 на ЦБД-нову

Мета: Для спрощення управління та підтримки системи, а також щоб зменшить ризик помилок та збільшити ефективність обробки даних для користувачів БД, було прийнято рішення мігрувати legacy обʼєкти ЦБД2 на існуючу ЦБД-нову з подальшим закриттям ЦБД2.

Обʼєкти, які мігруємо:

• Procedure
• Auction Module
• Registry objects (assets)
• Lots objects (announcements, redemptions)
• Contracts objects (executions)
• Document service objects

А також протоколи аукціонів будуть відображатися згідно логіки ЦБД-нової (без білінгових розрахунків)

Основні правила роботи з мігрованими обʼєктами

Керування мігрованими обʼєктами доступне тільки через Адміністративний інтерфейс ЦБД-нова (далі - Адмінка), що залишається на стороні Prozorro.Sale

Для Майданчиків доступні тільки запити на отримання мігрованих обʼєктів (GET запити)

В Адмінці розроблена можливість: 

• додати документи до мігрованого обʼєкта
• змінити статус мігрованого обʼєкта

Якщо у Майданчика (чи особи, яку представляє Майданчик) зʼявляється потреба додати документ чи змінити статус для мігрованого обʼєкта - необхідно звернутися до представника Prozorro.Sale

Відображення мігрованих Обʼєктів

1. Якщо на стороні Майданчика прийнято рішення не відображати мігровані з ЦБД2 на ЦБД-нову обʼєкти, то:
1. Якщо користувач Вашого порталу по прямому посиланню переходить на сторінку мігрованого обʼєкта, необхідно його переадресувати на сторінку Порталу Prozorro.Sale: https://prozorro.sale/auction/{{object_id}}
2. Якщо користувач Вашого порталу шукає обʼєкт по id, що відповідає id обʼєкта ЦБД2 (починається на UA-PS-*), необхідно запропонувати йому перейти (відобразити кнопку переходу) на https://prozorro.sale/auction/?aid={{object_id}}
2. Якщо прийнято рішення відображати мігровані обʼєкти, нижче описана логіка, яка використовувалася для міграції:

Мігровані обʼєкти будуть повертатися у Search (відпрацьовують всі існуючі запити, що використовуємо на ЦБД-новій) та Mirror ЦБД-нової.

Procedure

Мігруються обʼєкти процедур в їх поточному стані, в якому вони перебувають на момент міграції.

Історія змін обʼєкта не мігрується.

Кількість процедур

У ЦБД2 також присутні Процедури у статусі draft, active.tendering, pending.activation. Їх не мігруємо на ЦБД-нову. (Аналіз показав, що active.tendering - це тестові процедури, pending.activation - статус прирівняний до draft)

Мігруємо обʼєкти у статусах: active.qualification, active.awarded, complete, cancelled, unsuccessful

Не мігруємо всі Процедури, у яких параметр "mode": "test" та всі повʼязані Аукціони (МА) тестових обʼєктів.

Назви Статусів Процедур (Procedure.status) змінюємо для мігрованих об'єктів і приводимо до логіки ЦБД-нової:

Тобто, повна відповідність назв статусів, які використовуються для обʼєктів ЦБД-нової.

Назви Статусів Біда (procedure.bids[*].status) приводимо до логіки ЦБД-нової:

Назви Статусів Аварда (procedure.awards[*].status) змінюємо для мігрованих об'єктів і приводимо до ЦБД-нової логіки:

Структура моделі

Міграція Процедур ЦБД2 відбувається на нову Swagger модель, а не на існуючі по напрямкам:

Переніс сутностей не має впливати на структуру, логіку існуючих моделей ЦБД-нова. (Ми не маємо нічого змінювати в існуючих на ЦБД-новій процедурах), але неможливо перенести Об'єкти не змінюючи структуру, валідаційну логіку поточних напрямків ЦБД-нової. Наприклад, для збереження ID процедур необхідно змінювати логіку формування ID (regExp) ЦБД-нової.

Саме тому було прийнято рішення мігрувати процедури “окремим напрямком” згідно Swagger моделі.

Питання-відповіді:

• Що робили з полями, які присутні в обʼєктах ЦБД2, але відсутні відповідники в моделі ЦБД-нова: Поля які не кладуться на логіку структури обʼєкта ЦБД-нова - не переносили;
• Що робили з полями, які відсутні у обʼєкта ЦБД2, але вони обов'язкові в моделі ЦБД-нова: Поля у моделі Процедур, що мігруємо не обов'язкові для заповнення у мігрованому обʼєкті. Тобто, якщо в обʼєкті ЦБД2 немає значення поля, то в мігрованому обʼєкті його також не буде. Ніякими default значеннями не заповнювали.
• id обʼєктів ЦБД2 мапляться на поле legacyId ЦБД-нова, значення ЦБД-нова поля _id генерується ЦБД унікальним новим. endpoints працюють як з legacyId так і з новоствореним id. Тобто, отримати мігрований обʼєкт є можливість по старому і по новому id:

Повна логіка мапінгу полів тут

Swagger модель тут 

Для мігрованих обʼєктів процедур додається поле sellingMethod, яке було відсутнє на ЦБД2. Логіка визначення “напрямку” була проаналізована і мігровані процедури отримали наступні sellingMethods:

• Поля, які на ЦБД-нова наслідують модель base.MultiLang заповнюються тільки uk_UA (на ЦБД2 не було мультимовної моделі)

Наприклад, title ЦБД2 виглядає як "title": "Окреме майно»"

Намапили на "title": {"uk_UA": "Окреме майно"}

Зв'язок сутностей Малої Приватизації (relatedEntities) сформовано згідно структури ЦБД-нова.

Наприклад, зв'язок Процедури і Інформаційного Повідомлення на ЦБД2 реалізовано через поле "merchandisingObject": "b3ef63ddea3c4d1384c350986cf49c89"

При міграції трансформували в

"relatedEntities": [

     {

          "type": "announcement",

          "_id": "b3ef63ddea3c4d1384c350986cf49c89",

          "objectId": "UA-LR-SSP-2022-10-06-000007-3",

          "url": "/api/jobber/announcements/jas/b3ef63ddea3c4d1384c350986cf49c89"

     }

]

Назви регіонів (областей) на ЦБД2 задавались довільним рядком. Привели до ЦБД-нової значень regions.

Для частини обʼєктів не вдалося визначити Регіон, для них поле залишили не заповненим (значення регіону, яке не відповідало словнику і не вдалося визначити - не перенесли)

Мапінг Класифікаторів

Існують процедури, у яких Класифікатор має не довідникове значення.

Класифікатори процедур перенесли as-is без змін.

Так як, наприклад, на Порталі фільтр по Класифікатору формується із довідника, а не із можливих у Процедурах значень, то допустимий варіант, що мігровані Процедури, у яких ID класифікатора не відповідає довідниковому не будуть “шукатися” цим фільтром.

Мапінг Cancellations

Для процедур, які містять більше одного Cancellations мігруємо тільки останній, у якого date найбільший. Приклад Процедури з декількома cancellations[]

Особливості міграції документів

Документи вивантажувалися із обʼєкта ЦБД2, зберігалися на DocumentService ЦБД-нової зі збереженням id документа. Кожен документ отримав нове посилання (url).

Особливості при міграції документів:

• якщо у моделі документа ЦБД2 присутнє поле "url" де у значенні http адреса, то
• якщо адреса відкривається - скачуємо HTML, запаковуємо в архів і вантажимо в DS як документ
• якщо адреса не відкривається - скіпаємо весь документ.
• якщо у моделі документа ЦБД2 відсутнє поле "url", то
• перевіряємо чи є в моделі цього документа поле "accessDetails" з заповненим значенням:
• якщо є, то створюємо текстовий файл, куди записуємо текст із "accessDetails": , зберігаємо цей файл на DS і кріпимо в стандартну модель ЦБД-нова документа (таким чином максимально зберігаємо "наповнення" документа ЦБД2)
• якщо поле "accessDetails" відсутнє - скіпаємо цей документ і не переносимо.

У ЦБД2 історичні документи процедури містяться в обʼєкті самої процедури. Приклад

Ми переносимо id документа в тому вигляді, який він є на ЦБД2.

На ЦБД-нова Документи зберігаються в базі як "ключ-обʼєкт документа"

Ключі завжди унікальні, тому ми не зберігаємо два документа з одним ключем. Останній просто замінить попередній.

Аналізуючи обʼєкт з двома документами, через endpoint, який дозволяє бачити документ по його id, бачимо, що другий дублюючий документ відображається як "історичний"

Для випадку, коли в обʼєкті є два документи з однаковим id, брали тільки той документ, у якого dateModified більше. А з більш раннім dateModified - скіпали.

Аналогічна логіка для документів інших сутностей обʼєкту: bids[].documents, awards[].documents і т.д.

Повні таблиці мапінгу полів, який використовувався за посиланням

API Endpoints

Доступні запити тільки на GET.

Так як для мігрованого обʼєкта існує два id ( “стара” id мігрована в поле “lecacyId”, нова в полі “_id”) обʼєкт можна отримати по обом id:

https://procedure-sandbox.prozorro.sale/api/procedures/{{legacyId}}

https://procedure-sandbox.prozorro.sale/api/procedures/{{_Id}}

Доступні всі GET запити, які працюють для обʼєктів ЦБД-нової.

Мігровані обʼєкти також повертаються у search

Mirror буде повертати мігровані обʼєкти разом з іншими обʼєктами ЦБД-нової

NOTE: для відображення мігрованих обʼєктів на Порталі prozorro.sale, необхідно згрупувати по sellingMethod обʼєкти одного напрямку (наприклад, basicSell-english == legacyBasicSell-english) і так як поля приведені до логіки ЦБД-нової, обʼєкти відобразилися без додаткового мапінгу.

На Прикладі Порталу: Search повернув всі мігровані обʼєкти в структурі ЦБД-нової, чистимо індекс, щоб видалити “старі” обʼєкти ЦБД2 у їй старому вигляді, робимо мапінг sellingMethods, щоб відобразити legacy обʼєкти в існуючих “Напрямках роботи”.

З часом endpoints ЦБД2 будуть відключені, а мігровані обʼєкти можна буде отримати по endpoints ЦБД-нова.

Таблиця GET endpoints для отримання одиничних сутностей:

У мігрованих обʼєктів може відрізнятися структура від типового обʼєкта ЦБД-нової тим, що відсутні певні поля. Це призводить до того, що деякі GET запити можуть повертати 404, якщо у обʼєкта немає поля, яке має повернутися в цьому запиті.

Наприклад, legacy_execution не має полів order, completion. Якщо зробити GET запит до /api/registry/legacy_execution/{execution_id}/order/documents/{doc_id}

то відповідь 404 отримуємо через те, що у legacy_execution взагалі в моделі відсутній order, як обʼєкт моделі.

Auction Module

Для відображення модулю аукціона в дизайні ЦБД-нова також було виконано перемапінг, та мігровані обʼєкти МА.

Аукціон доступен за посиланням, яке використовується для аукціонів ЦБД-нової.

На стороні Майданчика не потрібно робити окремої логіки.

Приклади обʼєктів ДО\ПІСЛЯ

• Процедура Англ ДО міграції тут
• Процедура Англ ПІСЛЯ міграції тут
• Процедура Голл ДО міграціїї тут
• Процедура Голл ПІСЛЯ міграції тут
• Процедура Інфініті ДО міграції тут
• Процедура Інфініті ПІСЛЯ міграції тут
• МА Англ ДО міграції тут (його API тут)
• МА Англ ПІСЛЯ міграції тут (його АРІ тут)
• МА Голл ДО міграції тут (його API тут)
• МА Голл ПІСЛЯ міграції тут (його API тут)
• МА Інфініті ДО міграції тут (його API тут)
• МА Інфініті ПІСЛЯ міграції тут (його API тут)

Asset, Announcement, Redemption, Executon

Використовувалась логіка перемапінгу полів на модель ЦБД-нової за аналогічним принципом.

Структура обʼєкта приведена до вигляду обʼєктів ЦБД-нової.

Ознайомитись з повним переліком полів можна в документі на закладці legacyAsset, legacyAnnouncement, legacyRedemption, legacyExecution

На відмінність від Процедур, обʼєкти МП мігруються на інші endpoints.

Приклади обʼєктів для наглядного розуміння:

Це необхідно для збереження існуючої логіки ЦБД-нової обʼєктів.

На SEARCH використовуються endpoints:

• https://procedure-sandbox.prozorro.sale/api/search/legacy_asset/byDateModified/{{ dateModified }}
• https://procedure-sandbox.prozorro.sale/api/search/legacy_announcement/byDateModified/{{ dateModified }}
• https://procedure-sandbox.prozorro.sale/api/search/legacy_redemption/byDateModified/{{ dateModified }}
• https://procedure-sandbox.prozorro.sale/api/search/legacy_execution/byDateModified/{{ dateModified }}

на MIRROR додаються окремі ns:

• /api/mirror/jobber:
  • jobber.legacy_announcement
  • jobber.legacy_redemption
• /api/mirror/registry:
  • registry.legacy_asset
  • registry.legacy_execution