Что делать, если в 1С:Документооборот 3.0 остановился процесс согласования документов?

← На главную

При работе в крупной корпоративной информационной системе на базе «1С:Документооборот 3.0 КОРП» администраторы иногда сталкиваются с ситуацией, когда после аварийного завершения работы сервера (например, внезапного отключения питания, сбоя СУБД или принудительного перезапуска процессов) полностью останавливается процесс маршрутизации. Пользователи замечают, что новые задачи по согласованию договоров перестают приходить, а старые зависают в неопределенном статусе. При этом регламентные задания могут выполняться без видимых системных ошибок в консоли администрирования.

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

Архитектурные особенности: почему «встает» согласование в 1С:ДО 3.0

Для того чтобы понять природу этой неисправности, проанализируем ключевое отличие редакции 3.0 от предыдущих версий (2.1). В новой редакции «1С:Документооборот» механизмы маршрутизации процессов и создания новых задач выполняются асинхронно. Это сделано для повышения отзывчивости интерфейса у конечных пользователей.

Когда сотрудник нажимает кнопку «Согласовано», система не пытается мгновенно рассчитать всю цепочку процесса и создать следующую задачу в рамках текущей транзакции. Вместо этого происходит следующее:

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

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

Анализ ошибки в модуле Справочник.Файлы

Рассмотрим детально стек ошибки, который часто фиксируется в журнале регистрации в такие моменты:


Неверный первый параметр Ссылка в функции ОбщегоНазначения.ЗначенияРеквизитовОбъекта: 
Значение должно быть ссылкой или именем предопределенного элемента.
{ОбщийМодуль.ОбщегоНазначения.Модуль(180)}:ВызватьИсключение (СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(
{Справочник.Файлы.МодульМенеджера(164)}:РеквизитыВерсииФайла = ОбщегоНазначения.ЗначенияРеквизитовОбъекта(
{ОбщийМодуль.ОбновлениеКэширующихДанных.Модуль(307)}:Менеджер.ОбновитьКэширующиеДанные(Выборка);
{ОбщийМодуль.ОбновлениеКэширующихДанных.Модуль(355)}:ЕстьОбработанныеДанные = ОбработатьОчередьОбновленияКэширующихДанных(Долгое);

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

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

Почему кнопка «Сбросить ошибки» в очереди заданий бывает неактивна?

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

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

Пошаговое руководство по решению проблемы

Рассмотрим последовательность действий, которая позволит оперативно восстановить процесс согласования документов в системе.

Шаг 1: Остановка фоновых процессов

Для того чтобы безопасно провести манипуляции с очередью заданий, необходимо исключить конкурентный доступ и попытки перезапуска задач со стороны сервера. Для этого выполним следующие действия:

Откроем консоль администрирования кластера серверов 1С.
Заблокируем регламентные задания для проблемной информационной базы.
Если блокировка через консоль не помогает, временно остановим службу сервера «1С:Предприятия» (например, через оснастку services.msc в Windows или команду systemctl stop srv1cv83 в Linux) и запустим ее снова, чтобы гарантированно завершить зависшие рабочие потоки.

Шаг 2: Удаление проблемных записей из очереди заданий

После остановки фоновой активности необходимо очистить зависшие и ошибочные элементы. Перейдем в базу данных под правами администратора с отключенными регламентными заданиями:

Через функции для технического специалиста найдем справочник Очередь заданий документооборота (или регистр сведений Очередь обновления кэширующих данных).
Найдем записи, содержащие статус ошибки или ссылающиеся на неопределенные объекты. Как правило, в поле описания ошибки будет фигурировать стек, связанный со справочником файлов.
Удалим непосредственно те элементы очереди, которые вызывают сбой. Поскольку данные задачи уже повреждены из-за отсутствия самих физических объектов (файлов), их удаление не нарушит логическую целостность существующих корректных документов.

Шаг 3: Программный сброс ошибок (альтернативный вариант)

Если удаление объектов кажется вам небезопасным, или вы хотите попытаться перезапустить задачи, для которых физические объекты существуют, воспользуемся внешней обработкой для программного сброса счетчика попыток. Для этого можно выполнить в контексте сервера следующий код:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Очередь.Ссылка КАК Ссылка
    |ИЗ
    |	Справочник.ОчередьЗаданийДокументооборота КАК Очередь
    |ГДЕ
    |	Очередь.Состояние = ЗНАЧЕНИЕ(Перечисление.СостоянияЗаданий.Ошибка)";

Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    ОбъектЗадания = Выборка.Ссылка.ПолучитьОбъект();
    ОбъектЗадания.КоличествоПопыток = 0;
    ОбъектЗадания.Состояние = Перечисления.СостоянияЗаданий.ВОчереди;
    Попытка
        ОбъектЗадания.Записать();
        ИнформационноеСообщение("Задание успешно сброшено: " + Выборка.Ссылка);
    Исключение
        Предупреждение("Не удалось перезаписать задание: " + КраткоеПредставлениеОшибки(ОписаниеОшибки()));
    КонецПопытки;
КонецЦикла;

Шаг 4: Очистка серверного кэша

Часто после аварийного завершения работы сеансов конфигурация продолжает хранить некорректные метаданные в кэше сервера приложений. Выполним очистку кэша сервера:

Остановим службу сервера 1С.
Перейдем в каталог локального кэша службы (по умолчанию для Windows это C:\srvinfo\reg_1541\).
Найдем папки с уникальными идентификаторами баз данных и удалим внутри них папки snccg и srvinfo (или просто очистим содержимое каталогов временных файлов Local Settings\Temp пользователя, от имени которого запускается служба сервера 1С).
Запустим службу сервера 1С.

Шаг 5: Проведение тестирования и исправления информационной базы

Чтобы гарантированно устранить последствия сбоя транзакции, запустим утилиту тестирования и исправления (ТиИ) через Конфигуратор:

Запустим конфигуратор под учетной записью администратора.
Откроем меню «Администрирование» — «Тестирование и исправление...».
Установим флажки на пунктах «Проверка логической целостности» и «Проверка ссылочной целостности».
В группе переключателей «При наличии битых ссылок» обязательно выберем пункт «Очищать» (это позволит автоматически вырезать некорректные ссылки на несуществующие файлы из очередей и регистров).
Нажмем кнопку «Выполнить» и дождемся завершения процесса.

Меры профилактики: как избежать повторения проблемы

Чтобы минимизировать риски возникновения подобных сбоев при последующей эксплуатации системы, рекомендуем выполнить следующие рекомендации:

Обновление конфигурации: Настоятельно рекомендуется обновить «1С:Документооборот» до версии 3.0.16 и выше. Начиная с этого релиза, разработчики фирмы «1С» исправили логику работы сброса ошибок, а также разделили очередь обновления кэширующих данных на оперативную (быструю) и фоновую (долгую). Это снижает вероятность полной блокировки процессов при возникновении локальных ошибок с правами.
Настройка СУБД: Проверьте параметры времени ожидания блокировок в настройках вашей СУБД (MS SQL Server или PostgreSQL) и убедитесь, что регламентные операции СУБД (реиндексация, обновление статистики) не пересекаются с периодами пиковой нагрузки пользователей.
Резервное копирование: Настройте регулярное резервное копирование базы данных (оптимально — создание транзакционных бэкапов каждый час) для возможности быстрого восстановления на момент перед падением сервера.

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