Как включить и настроить механизм «История данных» в 1С 8.3.12: почему не отображаются изменения?

← На главную

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

Разбираем двухэтапный процесс работы истории данных

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

Этап формирования очереди: Когда пользователь нажимает кнопку «Записать» в документе или справочнике, платформа автоматически формирует специальное сообщение с данными об изменениях и помещает его во временную таблицу — очередь (DataHistoryQueue). Этот этап выполняется платформой незаметно и очень быстро, не нагружая основную транзакцию записи.
Этап обработки очереди: На этом этапе данные извлекаются из очереди, анализируются, упаковываются и переносятся в постоянное хранилище версий (DataHistoryVersions). Только после завершения этого этапа данные становятся доступны для просмотра через стандартную команду «История изменений».

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

Программная активация: метод ОбновитьИсторию()

Для того чтобы данные переместились из очереди в хранилище, в языке 1С предусмотрен специальный менеджер МенеджерИсторииДанных. Рассмотрим основной метод, который решает проблему пустой таблицы истории:


// Пример простого вызова обновления истории
ИсторияДанных.ОбновитьИсторию();

Рассмотрим подробнее, как и где следует вызывать этот код. В реальных информационных системах нецелесообразно запускать это обновление вручную. Правильным подходом является создание регламентного задания, которое будет выполнять этот метод с определенной периодичностью (например, раз в 10–15 минут или раз в сутки, в зависимости от интенсивности работы пользователей).

Проанализируем пример кода для серверного модуля, который можно назначить обработчиком регламентного задания:


Процедура ОбновитьИсториюДанныхНаСервере() Экспорт
    // Метод обрабатывает накопившуюся очередь сообщений
    // Рекомендуется запускать вне транзакции
    Попытка
        ИсторияДанных.ОбновитьИсторию();
    Исключение
        ЗаписьЖурналаРегистрации("ИсторияДанных", УровеньЖурналаРегистрации.Ошибка, , , 
            "Ошибка при обновлении истории: " + ОписаниеОшибки());
    КонецПопытки;
КонецПроцедуры

Важно помнить: метод ОбновитьИсторию() обрабатывает данные порциями. Если в базе данных накопилось огромное количество изменений (например, после массовой обработки документов), может потребоваться несколько вызовов метода или определенное время для полной очистки очереди.

Настройка метаданных для корректной работы

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

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

Полезный совет: начиная с версии платформы 8.3.14, разработчики добавили стандартную обработку «Управление историей данных» (доступна через «Все функции» или «Функции для технического специалиста»). Она позволяет увидеть размер очереди и запустить обновление без написания кода, что очень удобно для администраторов.

Отображение данных истории в формах списков

Часто возникает задача вывести информацию о последнем авторе или дате изменения прямо в форму списка документов. Рассмотрим ситуацию: напрямую обращаться к таблицам истории данных в динамическом списке — плохая идея с точки зрения производительности. Платформе придется выполнять сложные соединения с системными таблицами истории при каждой прокрутке списка.

Проанализируем два способа решения этой задачи:

Использование события ПриПолученииДанныхНаСервере: Этот метод позволяет программно дозаполнить колонки в списке.


&НаСервере
Процедура СписокПриПолученииДанныхНаСервере(ИмяЭлемента, Настройки, Строки)
    Для Каждого СтрокаСписок Из Строки Цикл
        // Получаем последнюю версию объекта
        ПоследняяВерсия = ИсторияДанных.ПолучитьПоследнююВерсию(СтрокаСписок.Ключ);
        Если ПоследняяВерсия <> Неопределено Тогда
            СтрокаСписок.Данные["АвторИзменения"] = ПоследняяВерсия.Пользователь;
            СтрокаСписок.Данные["ДатаИзменения"] = ПоследняяВерсия.Дата;
        КонецЕсли;
    КонецЦикла;
КонецПроцедуры

Используйте этот метод осторожно, так как он создает дополнительную нагрузку на сервер при интерактивной работе со списком.

Дублирование данных в реквизиты: Более эффективный способ для высоконагруженных систем. При записи объекта программно записывайте текущего пользователя и дату в скрытые реквизиты ПоследнийАвтор и ДатаПоследнегоИзменения. Тогда в списке эти данные будут отображаться мгновенно без обращения к механизму истории.

Управление хранением и очистка данных

Механизм «История данных» может существенно увеличить размер базы данных, если не ограничивать срок хранения версий. По умолчанию данные хранятся вечно. Посмотрим, как можно ограничить аппетиты системы программно, используя метод УстановитьНастройкиСрокаХранения():


// Установим срок хранения истории для документа "РеализацияТоваровУслуг" в 365 дней
НастройкиХранения = ИсторияДанных.ПолучитьНастройкиСрокаХранения(Метаданные.Документы.РеализацияТоваровУслуг);
НастройкиХранения.Вариант = ВариантСрокаХраненияИсторииДанных.СрокВ Днях;
НастройкиХранения.СрокВ Днях = 365;

ИсторияДанных.УстановитьНастройкиСрокаХранения(Метаданные.Документы.РеализацияТоваровУслуг, НастройкиХранения);

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