При работе с интеграцией ВЕТИС (система «Меркурий») в типовых конфигурациях, таких как 1С:Бухгалтерия предприятия 3.0 КОРП, пользователи и администраторы часто сталкиваются с ситуацией, когда процесс обмена данными кажется бесконечным. Сообщения в очереди не исчезают, а идентификаторы запросов постоянно обновляются. Разберем подробно, почему это происходит, как устроена внутренняя логика обмена и что делать, если синхронизация «застряла» на дате многомесячной давности.
Проанализируем стандартное поведение подсистемы интеграции с ВЕТИС. Все запросы к шлюзу фиксируются в регистре сведений ОчередьСообщенийВЕТИС. В нормальном режиме сообщение создается со статусом «К отправке», уходит в систему «Меркурий», получает ответ и после обработки удаляется из очереди (или помечается как обработанное).
Однако в случаях, когда обмен не выполнялся длительное время (например, с марта по май), операции Запрос измененных ВСД (getVetisDocumentList) и Запрос измененных записей складского журнала (getStockEntryList) начинают вести себя специфически. Рассмотрим, что видит специалист при мониторинге:
Выясним причину такого поведения. Это не ошибка кода и не сбой серверов ВетИС. Это работа механизма итеративного получения данных, известного как «курсор» или «смещение» (offset).
Протокол обмена ВЕТИС.API версии 2.1 (и выше) не позволяет выгрузить миллион записей одним пакетом — это создало бы критическую нагрузку на серверы. Поэтому система возвращает данные порциями (обычно по 100 или 1000 записей).
Когда 1С запрашивает изменения за большой период, она формирует внутреннюю таблицу, которую можно условно назвать ТаблицаЭлементовПоДатам. В эту таблицу попадают все дни, за которые необходимо подтянуть данные по конкретному Хозяйствующему Субъекту (ХС) и его предприятиям. Рассмотрим алгоритм, по которому идет обработка:
// Пример упрощенной логики перебора дат в типовом модуле
Для Каждого СтрокаДаты Из ПараметрыОбмена.ТаблицаЭлементовПоДатам Цикл
Если СтрокаДаты.СтатусОбработки = Перечисления.СтатусыОбработкиСообщенийВЕТИС.НеОбработано Тогда
ИдентификаторЗапроса = СформироватьЗапросКВЕТИС(СтрокаДаты.Дата, ПараметрыОбмена.ХС);
// После получения ответа система не закрывает общую задачу,
// а переходит к следующей итерации или следующему пакету данных
КонецЕсли;
КонецЦикла;
Проблема «цикла» заключается в том, что пока система не обработает абсолютно все документы за конкретный день или период, она не обновит дату последней успешной синхронизации в константах или регистрах настроек. Если в процессе обработки произойдет обрыв связи или пользователь прервет обмен, при следующем запуске 1С начнет всё сначала — с той самой даты, на которой синхронизация прервалась в прошлый раз (например, с 31 марта).
Посмотрим на ситуацию глазами системы. Если за пропущенный период накопилось 50 000 ветеринарно-сопроводительных документов (ВСД), а за один запрос возвращается 1000, то системе нужно выполнить минимум 50 итераций только по одной операции. Если при этом по каждому ХС запрашиваются еще и записи складского журнала (самая «тяжелая» операция), количество запросов удваивается.
Важный нюанс: счетчик в окне обмена часто привязан к количеству обрабатываемых Организаций или Предприятий, а не к количеству порций данных. Поэтому пользователь видит «застывшую» цифру, хотя в фоновом режиме регистр ОчередьСообщенийВЕТИС постоянно обновляется.
Рассмотрим несколько способов выхода из ситуации «бесконечной» синхронизации.
Самый безопасный способ — оставить обмен включенным на длительное время (возможно, на ночь или на сутки, если разрыв в датах составляет несколько месяцев). Чтобы убедиться, что процесс идет, проанализируем содержимое регистра ОчередьСообщенийВЕТИС. Если вы видите, что идентификаторы сообщений меняются, а в XML-ответах приходят данные за разные даты (можно увидеть в теле сообщения через отладку или в консоли запросов), значит, система просто «выкачивает» историю.
Если ждать невозможно, и вы готовы пожертвовать историей изменений в 1С (при этом в самом «Меркурии» на портале данные останутся актуальными), можно вручную «продвинуть» дату синхронизации вперед.
Проанализируем, где хранятся эти метки. В типовых решениях за это отвечает регистр сведений, хранящий настройки обмена для каждой пары «ХС — Предприятие». Обычно это СинхронизацияОбъектовВЕТИС или настройки в справочнике НастройкиРегламентныхЗаданийВЕТИС.
ОчередьСообщенийВЕТИС от зависших записей по операциям Запрос измененных ВСД и Запрос измененных записей складского журнала.Внимание: После этого шага документы, созданные в период пропуска, не попадут в 1С автоматически. Их придется загружать вручную по номеру или через поиск за конкретный период, если возникнет такая необходимость. Для таких операций подойдёт обработка для автономного гашения и инвентаризации ВСД.
Иногда система не успевает обработать ответ из-за слишком короткого времени ожидания. В настройках интеграции ВЕТИС (раздел Администрирование — Настройки ВЕТИС — Параметры оптимизации) можно попробовать изменить следующие параметры:
Выясним, нет ли скрытых ошибок при записи данных. Бывают случаи, когда 1С получает данные от ВетИС, но не может записать их в базу из-за дублей GUID или ошибок в расширениях. В коде это может выглядеть так:
Попытка
ЗаписатьОбъектВБазу(ПолученныеДанные);
Исключение
// Если здесь пустой блок или ошибка не выводится в лог,
// сообщение останется в очереди навсегда
ЗаписатьЛогОшибок(ИнформацияОбОшибке());
КонецПопытки;
Проверьте Журнал регистрации. Если вы видите регулярные ошибки при записи объектов ВСД_ВЕТИС или ЗаписьСкладскогоЖурналаВЕТИС, значит, итерация не завершается именно из-за невозможности сохранить данные. В этом случае нужно устранять причину ошибки в данных (например, битые ссылки на контрагентов или номенклатуру).
Подводя итог: если вы столкнулись с «зацикливанием» ВЕТИС в БП 3.0, первым делом проверьте глубину просрочки обмена. Скорее всего, 1С просто добросовестно пытается восстановить хронологию событий за каждый день, создавая сотни последовательных запросов к API.