Порядок розгортання обміну на робочій 1С

Встановлення і публікація

Пакетно: LoadConfigFromFiles, UpdateDBCfg, CheckModules з ключами Server і AllExtensions (без другого розширення не перевіряються); після кожної команди читати /Out-лог, а не лише код повернення
Перед завантаженням завершити сеанси користувачів: зайнята база оновлення не прийме. Після оновлення перезапустити веб-сервер публікації
Після публікації і заповнення прт_Налаштування - два curl-тести: запит боргу без Bearer дає відмову (401), з Bearer - керовану відповідь; далі приймальний чек-лист
прт_Налаштування: порожній ТокенВхідний - відмова всім запитам; порожній GUID організації, складу чи валюти - сервіс A відповідає 500 і документа не створює
На робочій - дві окремі публікації (vrd): OData під Basic і HTTP-сервіс під portal_service з роллю прт_РольСервісів; обліковий запис із повними правами у vrd, як на стенді розробки, не переносити
Якщо в базі діє контроль закупівельної ціни при продажу, зняти його для portal_service і odata.user (питання 8 зі SPEC)

Перевірити на тестовій базі

Сервіси під portal_service з мінімальними правами: на стенді розробки вони йшли під повноправним користувачем, де помилки прав не видно; привілейований режим обробники вмикають самі
Контроль залишків: на стенді розробки константу КонтролироватьОстаткиПриПроведении вимкнено, тож успішний прогін там нічого не каже про робочу базу. Перед робочою - Истина, закрити питання 2 зі SPEC, стан константи писати в кожен звіт прогону
Позначки «ПЕРЕВІРИТИ НА СТЕНДІ» в чек-листі: куди пишеться коментар клієнта (A0), код відповіді на невідомий GUID (B5), механіка скасування (D5)
Відкат прт_Портал пройти на копії до вікна. Контрольне замовлення на робочій окремо не описане: робити за зразком A0, контрагента і скасування документа узгодити заздалегідь
Ще з known-deltas.md: тип ресурсу Документ у прт_КлючіІдемпотентності, коди WEIGHT_MISSING і ORDER_CLOSED у специфікації; на іншій версії платформи наново перевірити, що відповіді 422 доходять

Відкат

Якщо нову публікацію виведено назовні через DNS або проксі, відкат починається зі зняття їх
Зняття публікації - найшвидший крок під час інциденту: виклики отримують 404, OData і решта бази не зачіпаються
Розширення вимикати лише після зняття публікації: інакше замість керованого 404 буде технічна помилка «сервіс не знайдено»
Повне видалення - лише остаточне рішення: разом зникають регістри прт_ з налаштуваннями і ключами ідемпотентності
Об'єктів основної конфігурації розширення не змінює; після відкату повторити два curl-тести і перевірити, що публікація OData працює незалежно

У роботі (пунктир) і OData

У main порталу звернень до /hs/portal ще немає: до 1С портал ходить лише через OData
Адаптер у роботі: перемикачі ORDERS_CREATE_VIA і ORDERS_CHANGE_VIA (типово odata), клієнт сервісу, стан черги rejected
Доки адаптера немає, перевірку з порталом виконати нічим; запитами curl сервіс перевіряється вже зараз
OData потрібен і з розширенням: каталог, ціни, залишки і контрагентів сервіси A, B, D, E не віддають, а сервіс C (push з 1С) у збірку не входить
odata.user: читання лише переліку зі sklad.json; запис у Document_ЗаказПокупателя лишити, доки записи замовлень не переведено на сервіс, потім прибрати
Склад OData зберігається в даних бази: задається штатною формою БСП або одноразовим розширенням прт_Сетап (поставити, викликати, видалити). прт_Сетап замінює склад цілком, тож наявний перелік спершу прочитати й об'єднати