#4476: Синхронизация очистки реквизитов при обмене данными адаптером

Отредактирована: 20 дней назад

Проектное решение. Описание будущей реализации. Функционал еще не внедрен в продакшен и может измениться.

Контекст

Для обмена справочниками, документами и регистрами между «1С:Предприятие» и внешними информационными системами или мобильными устройствами используется БИТ.Адаптер. Сообщения обмена формируются в формате JSON.

Проблема

Если в базе-источнике очистить реквизиты объекта, который уже был передан в базу-приемник, при повторной отправке эти реквизиты не попадут в исходящее сообщение. Причина — Адаптер передает только заполненные реквизиты.

Из-за этого в базе-приемнике такие реквизиты не очищаются и сохраняют прежние значения. В результате данные в базе-источнике и базе-приемнике расходятся.

Решение

Передавать информацию об очищенных реквизитах в исходящем сообщении.

Реализация

При анализе изменений объекта в обработчике «ПередЗаписью» формировать список очищенных реквизитов, которые участвуют в обмене.
При регистрации исходящего сообщения сохранять этот список в данных сообщения.
При подготовке исходящего сообщения к отправке получать список очищенных реквизитов из данных сообщения и включать его в тело сообщения.

Рассмотренные варианты

Рассматривались два варианта решения.

Передавать информацию об очищенных реквизитах в исходящем сообщении, сформированном в обработчике «ПередЗаписью».

Для получения информации использовать существующие функции Адаптера, которые анализируют изменения записываемого объекта по сравнению с его текущей версией в базе.
Использовать JSON Schema при обмене в формате JSON.

Чтобы база-приемник могла учитывать состав реквизитов объекта в базе-источнике, источник должен формировать и передавать в приемник схемы данных, на основе которых создаются сообщения.

От использования JSON Schema отказались по следующим причинам:

в текущей архитектуре много источников и один приемник, поэтому потребуется сопровождать и согласовывать множество схем данных от разных источников;
схемы могут пересекаться в одинаковых пространствах имен, что усложнит поддержку;
в перспективе планируется полный отказ от схем данных, включая обмен в формате XML.

Обоснование выбранного решения

Выбран вариант с передачей информации об очищенных реквизитах в исходящем сообщении, сформированном в обработчике «ПередЗаписью».

Такой подход выбран по следующим причинам:

в текущем функционале Адаптера обработчик «ПередЗаписью» уже анализирует изменения записываемого объекта по сравнению с его текущей версией в базе;
регистрация исходящих сообщений из кода используется редко;
если при такой регистрации информация об очищенных реквизитах не будет передана, это не станет существенным ограничением;
при первичной регистрации в базе-приемнике обычно создается новый объект, поэтому старые значения очищать не требуется;
в базе-приемнике почти нет исторических данных, которые могли бы вызвать значимые расхождения при первичной загрузке.