При настройке синхронизации данных через веб-сервисы, особенно когда мы используем современный формат EnterpriseData, часто возникает резонный вопрос: как система понимает, что данные успешно доставлены в базу-приемник, и в какой момент происходит очистка регистрации изменений (снятие «колокольчиков» с объектов)?
Многие разработчики ошибочно полагают, что снятие с регистрации должно происходить мгновенно после вызова метода отправки данных. Однако в архитектуре 1С:Предприятие и Библиотеки стандартных подсистем (БСП) заложен более надежный механизм — квитирование. В этой статье мы подробно разберем, как работает этот процесс, почему не стоит бояться «потери» новых изменений и как правильно использовать методы типового веб-сервиса EnterpriseDataExchange.
Давайте проанализируем, как вообще работает план обмена. Каждый пакет данных, который формирует 1С, имеет свой уникальный порядковый номер. Этот номер фиксируется в узле плана обмена для конкретной базы-корреспондента. Процесс обмена через веб-сервис — это не разовая акция, а итерационный цикл.
Рассмотрим стандартную схему взаимодействия:
GetData или PutData.ПланыОбмена.УдалитьРегистрациюИзменений(Узел, 10).Важный момент: Снятие с регистрации происходит не в момент выгрузки, а в момент получения квитка (подтверждения) от партнера. Это гарантирует, что если в процессе передачи произойдет обрыв связи или ошибка на стороне приемника, данные не будут сняты с регистрации и уйдут повторно при следующем обмене.
Многие разработчики путаются в методах типового сервиса. Давайте разберем их назначение подробнее, чтобы понять, где именно «прячется» обработка результата.
Типовой сервис обычно содержит методы:
ConfirmReceivedData — специализированный метод для передачи номера принятого сообщения.PutData — метод для передачи данных в базу.GetData — метод для запроса данных из базы.Обратите внимание на метод ConfirmReceivedData. Его часто критикуют за то, что в коде БСП он может обращаться к логике «файлового обмена». Но давайте выясним причину. БСП написана максимально универсально. Для системы нет разницы, пришел ли квиток из XML-файла в папке FTP или через параметр веб-сервиса. Внутри веб-сервиса «файлом» фактически выступает поток данных в оперативной памяти или временное хранилище.
Если вы используете кастомное решение, вам необходимо убедиться, что вы вызываете стандартную процедуру очистки:
// Пример логики на стороне источника при получении подтверждения
Процедура ПринятьПодтверждение(УзелОбмена, НомерПринятогоСообщения)
Если НомерПринятогоСообщения > 0 Тогда
// Удаляем регистрацию только для тех изменений,
// которые вошли в пакет с указанным номером
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, НомерПринятогоСообщения);
КонецЕсли;
КонецПроцедуры
Рассмотрим ситуацию, которая часто беспокоит программистов: что если во время долгого процесса выгрузки пользователь изменил объект? Не снимется ли он с регистрации ошибочно, если мы подтвердим пакет?
Система 1С решает это через механизм нумерации сообщений в планах обмена. Давайте проанализируем последовательность:
ПланыОбмена.ВыбратьИзменения(Узел, НомерСообщения). В этот момент 1С «помечает» все текущие изменения этим номером.УдалитьРегистрациюИзменений(Узел, НомерСообщения), удаляются только те записи, у которых номер совпадает с переданным.Таким образом, новые изменения, появившиеся «в процессе», никуда не денутся — они просто дождутся следующей итерации обмена.
Если вы работаете с типовой конфигурацией 1С:ERP, вам не нужно изобретать велосипед. Проверьте, передает ли ваша внешняя система или вторая база 1С параметр ConfirmationMessageNum (номер принятого сообщения). В формате EnterpriseData этот атрибут обычно находится в заголовке сообщения.
Если вы вызываете веб-сервис из стороннего приложения (например, на Python или C#), ваш алгоритм должен быть таким:
GetData.MessageNo (номер этого сообщения).ConfirmReceivedData, передав туда полученный ранее MessageNo.Пример вызова метода подтверждения (псевдокод для понимания логики):
// Логика на стороне внешней системы
НомерПоследнегоПакета = МояБД.ПолучитьПоследнийОбработанныйНомер();
// Инициализация прокси веб-сервиса
Прокси = СформироватьПрокси("EnterpriseDataExchange");
// Вызываем подтверждение, чтобы ERP знала, что мы всё получили
Прокси.ConfirmReceivedData(КодЭтойБазы, НомерПоследнегоПакета);
Рассмотрим архитектурную причину, по которой PutData не всегда возвращает результат обработки сразу. Обмен EnterpriseData может быть асинхронным и очень объемным. Обработка пакета может занимать минуты или даже часы (если включена фоновая загрузка). Поэтому архитектура разделена: один вызов передает данные, другой — подтверждает их получение после фактической записи в информационную базу.
Подведем итог: Чтобы корректно снимать объекты с регистрации в 1С:ERP через веб-сервисы, нужно использовать стандартный механизм номеров сообщений планов обмена. Не пытайтесь очищать регистрацию вручную через УдалитьРегистрациюИзменений(Узел) без указания номера сообщения — это приведет к потере данных, измененных во время сессии обмена. Используйте метод ConfirmReceivedData или передавайте номер подтверждения в заголовках стандартных методов GetData/PutData.