Обновление BDUI (Backend-Driven UI): формы обращения, каталога и карточек объектов собираются из схемы на сервере. Клиент — портал, рабочее место агента, мобильный — только отображает и шлёт значения. Менять экран можно без релиза фронтенда.
Что изменилось в конфигураторе форм
- Секции и порядок полей задаются в схеме услуги, не в шаблоне страницы.
- Условия показа от роли, этапа, типа обращения, значения другого поля.
- Валидации (обязательность, маска, ссылка на CI) живут в схеме и одинаковы во всех клиентах.
- Виджеты: справочник, CI-lookup, вложения, чек-лист runbook, блок согласования.
- Версия схемы: черновик в Sandbox, публикация в прод, откат к предыдущей версии.
Агент и заявитель видят разные наборы полей из одной схемы с правилами видимости — не две разъехавшиеся формы.
Зачем это службе
Раньше новое поле в карточке часто ждало релиза UI. Теперь владелец услуги добавляет поле, условие и подпись в конфигураторе, прогоняет в Sandbox и публикует. Портал, агент и API получают ту же структуру.
Для интеграций схема формы совпадает с контрактом конфигуратора API: внешняя система заполняет те же ключи, что видит человек.
Практика настройки
- Открыть услугу → схема формы (BDUI).
- Собрать секции: заявитель, суть, CI, согласование.
- Повесить условия: поле «номер пропуска» только для услуги АХО.
- Проверить роли в Sandbox.
- Опубликовать; агенты получают форму при следующем открытии карточки.
Сложный виджет (карта, редактор схемы сети) по-прежнему может быть pro-code компонентом, зарегистрированным в каталоге виджетов. BDUI решает 90% полей каталога, а не запрещает исключения.
Связь с low code
BDUI — слой отображения поверх той же модели объектов, что маршруты и SLA. Форма не живёт отдельно от процесса: смена этапа может открыть секцию «резолюция» без новой страницы.
Итог: конфигурирование форм стало предсказуемым пакетом (схема + версия + песочница), а не правкой трёх фронтендов. Это ускоряет новые услуги и держит портал, агента и API в одной модели.