Перемикання каналів: яка операція яким шляхом іде (у роботі)

У роботі: що вже є, а що пишеться

Уся комутація - проєкт адаптера. Перемикачів ORDERS_CREATE_VIA і ORDERS_CHANGE_VIA, поля channel у рядку черги і клієнта сервісу в main ще немає: це пишеться зараз.
Суцільні стрілки - шлях, яким операції йдуть сьогодні. Він лишається типовим положенням odata обох перемикачів.
Пунктир - положення service. Портал викликає сервіс 1С /hs/portal: POST /orders, POST /orders/{id}/items і POST /orders/{id}/cancel. У розширенні 1С ці маршрути вже є, для адаптера там нічого не змінюється.
Обидва перемикачі задаються лише на порталі і діють незалежно один від одного. Невідоме значення діє як odata.
«Виконано» і корекція рядків лишаються на OData: дії «завершити» в сервісі немає, а PUT .../lines не приймає ціну і переоцінює всі рядки. Патч з lines іде через OData цілком, разом зі статусом («Погодити і виставити рахунок»).
Читання не перемикається: замовлення і каталог ідуть з репліки порталу, а борг і замовлення перед зміною читаються наживо з OData.

Канал закріплено за рядком черги

ORDERS_CREATE_VIA читається в момент постановки. Для service у payload рядка кладеться channel: service, для odata поле не пишеться.
Повтор того самого ключа канал не змінює. Рядки, поставлені до перемикання, доходять своїм каналом.
Рядок бере лише виконавець, що вміє його канал. При збої переходу на інший канал немає.
Причина: OData шукає дубль у Комментарий, сервіс - у своєму регістрі прт_КлючіІдемпотентності. Канали не бачать ключів один одного.

Перемикач увімкнено, а сервіс не налаштовано

Налаштування сервісу - BAS_SERVICE_URL і BAS_SERVICE_TOKEN у кожному процесі, що доставляє або змінює. Портал читає їх при побудові провайдера, тож зміна діє з нового деплою.
ORDERS_CREATE_VIA=service, а налаштувань немає в жодного виконавця: рядки чекають у queued, одне попередження в лозі порталу.
ORDERS_CHANGE_VIA=service, а налаштувань немає на порталі: позиція і скасування повертають 503 «нічого не змінено», сервіс не викликається, OData не підміняє.
Проміжний статус сервісу не викликає; відмову 503 проєкт описує лише для позиції і скасування.
Окремо від налаштувань, у положенні service: скасування вже «виконаного» замовлення портал відхиляє сам (409), сервіс не викликається.

Порядок увімкнення і відкат

1. Реліз коду з порожніми змінними: спершу портал, потім раннер.
2. Перевірки на стенді.
3. BAS_SERVICE_URL і BAS_SERVICE_TOKEN у виконавців; перевірити dispatch.channels у звіті раннера.
4. ORDERS_CREATE_VIA=service на порталі.
5. ORDERS_CHANGE_VIA=service - окремо, коли читання скасування за ВариантЗавершения вже викладено на порталі і на раннері.
Відкат: повернути перемикач в odata. Рядки каналу service доходять сервісом, тож його налаштування лишаються у виконавців, доки такі рядки не проведено.
Код нижче цього релізу не відкочувати, поки є непроведені рядки каналу service або рядки в новому стані rejected.