Как организовать надежный обмен данными между базами 1С и избежать потери объектов при ошибках?

При настройке обмена данными между нетиповыми конфигурациями 1С разработчики часто сталкиваются с проблемой: стандартный механизм Планов обмена автоматически удаляет регистрацию изменений сразу после успешной выгрузки файла. Если на стороне приемника происходит ошибка (разрыв связи, ошибка записи объекта, невалидные данные), объект считается «ушедшим», и повторно отправить его стандартными средствами без ручной перерегистрации становится крайне сложно.

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

Решение 1: Использование промежуточного регистра сведений и подтверждения приема

Суть метода заключается в отказе от немедленного удаления регистрации. Вместо этого мы внедряем «трехфакторную» структуру обмена.

1. Создание промежуточного хранилища. Создайте Регистр сведений в базе-источнике, куда будут сохраняться сформированные файлы обмена (или сериализованные данные). В качестве ключа используйте уникальный идентификатор сеанса обмена.
2. Отложенная отправка. При выгрузке данных база-источник сохраняет файл в Регистр сведений и отправляет базе-приемнику только ссылку (идентификатор) на этот файл.
3. Подтверждение получения. База-приемник после успешного получения и обработки файла отправляет ответ (квитанцию) в базу-источник.
4. Очистка регистрации. База-источник удаляет регистрацию из Плана обмена и очищает запись в Регистре сведений только после получения подтверждения успеха.

Если в процессе обработки произошла ошибка, база-приемник сообщает об этом, и объект остается в очереди на следующую попытку отправки.

Решение 2: Переход на архитектуру HTTP-сервисов и JSON

Современным и более гибким подходом является использование HTTP-сервисов вместо классических Web-сервисов. Это позволяет управлять статусами ответов и делает обмен более прозрачным.

Преимущества подхода:

• Использование стандартных кодов ответов HTTP (200 OK — успех, 400 Bad Request — ошибка данных, 500 — ошибка сервера).
• Возможность реализовать логику «Запрос-Ответ», где источник уведомляет о наличии данных, а приемник сам инициирует их получение.
• Гибкая обработка ошибок: если база-приемник вернула ошибку, база-источник может пометить объект как «ошибочный» и выставить уведомление администратору.

Пример логики работы через статус-коды:

// На стороне базы-приемника
Функция ОбработкаPOSTЗапроса(Запрос)
    Данные = ПрочитатьJSON(Запрос.ПолучитьТелоКакСтроку());
    Попытка
        ЗаписатьОбъектыВБазу(Данные);
        Возврат Новый HTTPОтвет(200); // Успех
    Исключение
        ЗаписатьЛогОшибки(ОписаниеОшибки());
        Возврат Новый HTTPОтвет(500); // Ошибка на стороне сервера
    КонецПопытки;
КонецФункции

Решение 3: Реализация транзакционности обмена

Часто ошибки возникают не из-за сети, а из-за того, что данные не соответствуют бизнес-правилам приемника (например, не заполнена аналитика). Чтобы избежать «зависания» обмена, рекомендуем использовать Лог обмена — специальный Регистр сведений, где фиксируются:

• Ссылка на объект.
• Дата попытки обмена.
• Статус (Успешно, Ошибка).
• Текст ошибки.

Это позволит вам реализовать механизм повторных попыток отправки Регламентным заданием. В случае ошибки, база-источник не удаляет регистрацию объекта в Плане обмена до тех пор, пока администратор или автоматический скрипт не устранит причину невалидности данных.

Ключевые рекомендации по настройке

1. Разделяйте технический сбой и бизнес-ошибку. Технические сбои (сеть) должны автоматически инициировать повтор. Бизнес-ошибки (ошибки пользователя при заполнении) должны блокировать обмен и требовать исправления данных в источнике.
2. Не удаляйте регистрацию до подтверждения. Сделайте Удаление регистрации транзакционным событием, которое происходит строго после успешного завершения записи в приемнике.
3. Используйте очереди. Если объем данных большой, очередь сообщений (Message Queue) станет более масштабируемым решением, чем синхронный вызов методов сервиса.

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