При обновлении конфигураций 1С, особенно таких распространенных как «Бухгалтерия предприятия», мы часто сталкиваемся с двухэтапным процессом. Сначала обновляется конфигурация базы данных в конфигураторе (в этом процессе вам может пригодиться помощник оператора обновления КБД), а затем, при первом запуске в режиме «Предприятие», запускаются обработчики обновления. Обычно этот процесс проходит гладко, но иногда случается так, что одна из процедур (дополнительная обработка данных) «зависает» на долгое время, не выдавая явных ошибок, или вовсе не заканчивается. В этой статье мы подробно разберем, почему это происходит, как диагностировать причину «бесконечного» выполнения и как найти конкретный документ, из-за которого стопорится обновление.
Ситуация выглядит следующим образом: список процедур обновления выполняется успешно (зеленые галочки), но на одном из пунктов, например, 13-м из 13, процесс замирает. Прогресс-бар может крутиться часами, нагрузка на сервер есть, но результат нулевой. В Журнале регистрации при этом может быть чисто — ни ошибок, ни предупреждений.
Давайте разберемся в механике этого явления. Процедуры отложенного обновления работают с порциями данных. Механизм 1С выбирает пакет документов (например, 100 штук), которые зарегистрированы в специальном Плане обмена, и пытается их обработать в рамках одной транзакции.
Если при записи одного из документов возникает ошибка (например, не заполнено обязательное поле, сработала проверка корректности данных или возник конфликт блокировок), транзакция отменяется целиком. Изменения откатываются. Поскольку документ не был успешно обработан, он остается зарегистрированным в плане обмена.
Система, видя, что работа не закончена, запускает процедуру снова. Запрос опять выбирает тот же пакет с тем же проблемным документом, снова пытается его записать, снова падает и откатывается. Получается бесконечный цикл («петля»), который внешне выглядит как зависание.
Первым делом нам нужно понять, какая именно процедура вызывает задержку. В окне обновления программы, где отображается список выполняемых задач, необходимо обратить внимание на зависший пункт.
Если в форме прогресса обновления дважды кликнуть по картинке (иконке) напротив выполняемой процедуры (или нажать кнопку «Подробнее»/«Журнал», в зависимости от релиза БСП), мы можем увидеть техническое имя метода. Обычно поле называется Имя обработчика.
Запомним это имя. Оно укажет нам, с какими данными работает система. Например, если имя процедуры похоже на ЗаполнитьСчетНаОплатуВРасшифровкеПлатежаПриОбновлении, становится очевидно, что проблема кроется в документах оплаты (платежных поручениях).
Все объекты, требующие обработки при обновлении, регистрируются в служебном Плане обмена. Чаще всего он называется ОбновлениеИнформационнойБазы. Чтобы найти конкретный документ, на котором «спотыкается» обновление, нам понадобится удобная «Консоль запросов» или простая внешняя обработка, позволяющая выполнить произвольный запрос.
Предположим, мы выяснили, что проблема в документе ПлатежноеПоручениеВходящее (исходя из имени зависшего обработчика). Нам нужно посмотреть таблицу изменений этого документа в плане обмена.
Выполним следующий запрос в консоли:
ВЫБРАТЬ
ВыборкаДанных.Узел КАК Узел,
ВыборкаДанных.НомерСообщения КАК НомерСообщения,
ВыборкаДанных.Ссылка КАК Ссылка
ИЗ
Документ.ПлатежноеПоручениеВходящее.Изменения КАК ВыборкаДанных
Обратите внимание на виртуальную таблицу .Изменения. Этот запрос покажет нам список ссылок на документы, которые система считает необработанными. Если список пуст, значит, мы ошиблись с типом документа, и нужно проверить другие документы, связанные с логикой зависшего обработчика.
Если запрос возвращает одну или несколько строк — поздравляем, вы нашли виновников. Обычно это один-единственный «битый» документ, который не дает завершиться всему процессу.
Если визуальный осмотр найденного документа не выявил явных проблем (например, все поля заполнены), нам придется заглянуть в код. Для этого откроем конфигуратор.
Нам нужно найти Модуль менеджера того документа, который мы подозреваем (или общего модуля, если обработчик находится там). В модуле менеджера ищем процедуру, имя которой мы узнали на Шаге 1.
Обычно код обновления выглядит примерно так:
ОбновлениеИнформационнойБазы.ВыбратьСсылкиДляОбработки().ОбновлениеИнформационнойБазы.ОтметитьВыполнениеОбработки(Выборка.Ссылка).Внутри этой процедуры часто можно найти запрос, который отбирает данные с наложением дополнительных условий. Давайте рассмотрим примерный алгоритм анализа:
Процедура ЗаполнитьРеквизитыПриОбновлении(Параметры) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ...
|ИЗ Документ.ВашДокумент.Изменения ...
|ГДЕ ..."; // Здесь могут быть условия
// Анализируем текст этого запроса
КонецПроцедуры
Попробуйте скопировать текст запроса из кода модуля в консоль запросов в режиме «Предприятие» и выполнить его (не забыв подставить параметры, если они есть). Это позволит увидеть именно ту выборку, которую пытается «переварить» 1С.
Иногда простого взгляда на документ недостаточно. Ошибки могут возникать в подписках на события при записи или из-за строгих проверок платформы. Рассмотрим варианты действий в сложных случаях.
Вариант А: Ручной запуск кода
Вы можете создать внешнюю обработку, в которую скопируете код проблемной процедуры обновления. Запустив её вручную для найденного проблемного документа (без транзакции и фонового выполнения), вы сразу получите окно с ошибкой. Это может быть:
Вариант Б: Проверка окончания обработки
В конце процедур обновления часто стоит проверка:
Параметры.ОбработкаЗавершена = Не ОбновлениеИнформационнойБазы.ЕстьДанныеДляОбработки(Параметры.Очередь, ПолноеИмяДокумента);
Если ваш запрос к таблице изменений (из Шага 2) показывает, что данные есть, значит ОбработкаЗавершена всегда будет Ложь, и цикл продолжится.
Когда проблемный документ найден, у нас есть два пути решения:
Для этого:
ОбновлениеИнформационнойБазы).После удаления регистрации процедура обновления пропустит этот документ при следующем запуске и успешно завершится, перейдя к следующим этапам.
Зависание дополнительных процедур обработки — это чаще всего не сбой платформы, а некорректные данные в вашей базе, которые не проходят проверку новыми правилами, введенными в обновлении. Механизм транзакций откатывает изменения, создавая бесконечный цикл. Используя запросы к таблицам изменений (.Изменения) и анализ кода менеджера объекта, вы всегда сможете локализовать проблему и устранить её.