Как включить и настроить механизм истории данных в 1С 8.3.11, если история остается пустой

Начиная с версии платформы 8.3.11, разработчикам стал доступен мощный встроенный инструмент — Механизм истории данных. Он призван заменить громоздкие подсистемы версионирования из БСП, работая на уровне платформы и обеспечивая более высокую производительность. Однако многие специалисты сталкиваются с ситуацией, когда настройки в метаданных выполнены, кнопка «История» в интерфейсе появилась, но список изменений остается пустым. Разберем по шагам, как правильно активировать этот механизм и почему данные не попадают в него мгновенно.

Понимание архитектуры механизма истории данных

Для начала проанализируем ситуацию: почему при включении всех настроек в Конфигураторе история не заполняется? Ответ кроется в архитектуре решения. В отличие от старых методов, которые записывали версию объекта непосредственно в момент его сохранения (увеличивая время транзакции), новый механизм работает асинхронно. Процесс разделен на два этапа:

1. Запись в очередь: Как только пользователь нажимает «Записать», платформа фиксирует факт изменения и помещает данные в специальную служебную таблицу-очередь (DataHistoryQueue). Это происходит мгновенно внутри транзакции записи объекта.
2. Обработка очереди: Данные из этой промежуточной таблицы должны быть обработаны и перенесены в основное хранилище истории. Только после этого они станут доступны для просмотра через интерфейс или программно.

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

Шаг 1. Настройка в Конфигураторе

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

1. Откройте свойства нужного объекта (например, справочника ДоговорыКонтрагентов).
2. На закладке «Основные» найдите свойство История данных и установите значение Использовать.
3. Перейдите на закладку «Данные», нажмите кнопку История данных... и выберите реквизиты, изменения которых нужно отслеживать. Здесь можно указать уровень использования: Использовать или Использовать для сравнения.
4. Проверьте права доступа: у соответствующих ролей должно быть разрешено право Просмотр истории данных и Чтение истории данных.

Шаг 2. Программная настройка и управление составом полей

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

Настройки = Новый НастройкиИсторииДанных;
Настройки.Использование = Истина;

// Укажем конкретные поля, которые хотим версионировать
Настройки.ИспользованиеПолей.Вставить("СуммаДоговора", Истина);
Настройки.ИспользованиеПолей.Вставить("ДатаЗаключения", Истина);

// Применяем настройки к объекту метаданных
ИсторияДанных.УстановитьНастройки(Метаданные.Справочники.ДоговорыКонтрагентов, Настройки);

Важно: Программные настройки, установленные методом УстановитьНастройки(), имеют приоритет над настройками, заданными в конфигураторе. Это полезно, например, в распределенных информационных базах (РИБ), когда на разных узлах требуется разная глубина логирования.

Шаг 3. Запуск обработки очереди (Решение проблемы пустой истории)

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

Разберем пример кода для процедуры регламентного задания:

Процедура ОбработатьОчередьИсторииДанных() Экспорт
    // Метод переносит данные из очереди в таблицы истории
    ИсторияДанных.ОбновитьИсторию();
КонецПроцедуры

Настройте расписание этого задания (например, раз в 5-10 минут). Если вы тестируете механизм прямо сейчас и хотите увидеть результат немедленно, просто выполните ИсторияДанных.ОбновитьИсторию() в консоли кода или во внешней обработке. Сразу после завершения метода вкладка «История» в форме объекта заполнится записями.

Шаг 4. Программное чтение данных и сравнение версий

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

Например, чтобы получить список всех версий объекта, используем метод Выбрать():

Выборка = ИсторияДанных.Выбрать(СсылкаНаДоговор);
Пока Выборка.Следующий() Цикл
    Сообщить("Версия №" + Выборка.НомерВерсии + " от " + Выборка.ДатаВерсии);
КонецЦикла;

Если нам нужно понять, что именно изменилось между двумя версиями, мы можем применить метод ПолучитьРазличия(). Это возвращает структуру, в которой зафиксированы только измененные реквизиты, что гораздо эффективнее, чем сравнивать полные копии объектов вручную.

Ограничения и рекомендации по эксплуатации

Проанализируем несколько критических нюансов, которые помогут избежать проблем при эксплуатации механизма:

• Транзакционность: Запись в историю происходит только при успешном завершении транзакции основного объекта. Если в ПередЗаписью или ПриЗаписи возникнет отказ, запись в очередь истории также будет отменена.
• Очистка данных: История имеет свойство расти. Платформа не очищает её автоматически. Для поддержания оптимального размера базы данных необходимо периодически вызывать метод ИсторияДанных.Удалить(), передавая в него дату, старше которой версии не нужны.
• Типы данных: Помните, что механизм оптимизирован для простых типов. Хранение огромных бинарных данных в реквизитах, включенных в историю, может быстро привести к взрывному росту объема базы.
• Регистры сведений: Механизм поддерживает и регистры сведений, но требует тщательной настройки состава ключей для корректного сопоставления записей.

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