Как реализовать обмен данными через JSON с подтверждением получения в 1С?

← На главную

При переходе от стандартного обмена через XML к формату JSON многие разработчики сталкиваются с отсутствием прямых аналогов методов НачатьЗапись() и ЗакончитьЗапись(). В этой статье мы подробно разберем, как выстроить надежный процесс обмена, обеспечив контроль доставки пакетов и корректную регистрацию изменений.

Почему стандартные методы не подходят для JSON

Платформа 1С жестко связывает методы ПланыОбмена.НачатьЗапись() и ПланыОбмена.ЗакончитьЗапись() с объектами ЗаписьXML и ЧтениеXML. Эти методы не только формируют структуру файла, но и автоматически управляют блокировками таблицы регистрации изменений и инкрементируют номер сообщения. Поскольку JSON не является «родным» форматом для этих методов, нам приходится либо эмулировать этот процесс, либо использовать более современные подходы к интеграции.

Решение 1: Создание собственной системы очереди сообщений

Если вы хотите сохранить строгий контроль над каждым пакетом, самым надежным вариантом будет использование регистра сведений. Это позволит избежать «изобретения велосипеда» при попытках манипулировать номерами сообщений в ПланахОбмена.

Создайте регистр сведений, например, ОчередьСообщений.
В структуре регистра предусмотрите измерения для идентификации узла и статуса сообщения (например, «К отправке», «Отправлено», «Подтверждено»).
При выгрузке формируйте пакет в формате JSON, сохраняйте его в регистр и помечайте как «К отправке».
После того как внешняя система пришлет ответ (подтверждение), переводите статус записи в «Подтверждено».

Этот подход дает преимущество: если подтверждение не получено, пакет остается в очереди, и при следующем запуске регламентного задания вы можете повторно отправить именно те данные, которые не дошли до получателя.

Решение 2: Использование внешних брокеров (RabbitMQ и аналоги)

Если проект позволяет внедрить промежуточное звено, рассмотрите использование брокера сообщений. В этом случае 1С передает данные в очередь, а брокер гарантирует их доставку до конечной системы.

Важный совет: не пытайтесь заставить 1С дожидаться подтверждения от конечной системы через цепочку «Брокер -> Система-получатель». Ваша ответственность заканчивается на моменте успешной передачи данных брокеру. Получив подтверждение от брокера, можно безопасно помечать данные в 1С как отправленные.

Как реализовать блокировку данных

При использовании стандартного ПланаОбмена для XML 1С автоматически блокирует запись в таблице регистрации изменений. При работе с JSON нам нужно позаботиться об этом самостоятельно. Используйте явные транзакции:


НачатьТранзакцию();
// Блокируем объект или таблицу для предотвращения конфликтов
Блокировка = Новый БлокировкаДанных;
// Добавьте необходимые элементы блокировки
Блокировка.Заблокировать();

// Формируем JSON, пишем данные...

ЗафиксироватьТранзакцию();

Как обеспечить повторную отправку при сбое

Если произошел сбой и пакет не был подтвержден, нам нужно снова выбрать изменения. В 1С запрос к таблицам изменений позволяет получить данные, которые еще не были удалены:


ВЫБРАТЬ
    Изменения.Ссылка
ИЗ
    ПланОбмена.ВашПланОбмена.Контрагенты.Изменения КАК Изменения
ГДЕ
    Изменения.НомерСообщения = 0

Помните, что метод ВыбратьИзменения() при каждом вызове присваивает записям текущий номер сообщения. Если вы хотите переотправить пакет, вам нужно либо очистить регистрацию УдалитьРегистрациюИзменений(), либо, что более предпочтительно, оперировать статусами в собственном регистре сведений, о котором мы говорили ранее.

Итоги и рекомендации

При реализации обмена через JSON:

Откажитесь от идеи полного копирования логики XML — это ведет к сложным и трудноотлаживаемым решениям.
Используйте регистры сведений для хранения истории статусов сообщений.
Реализуйте идемпотентность на стороне принимающей системы: если один и тот же пакет придет дважды, система не должна создавать дубли или ошибки. Это снимет вопрос «гарантированной доставки» как критически сложной задачи.
Делегируйте гарантии доставки специализированному ПО (брокерам сообщений), если масштаб проекта это позволяет.

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