1с история данных в запросе
История данных в 1С
В технологической платформе 8.3.11 был введен специальный механизм — «История данных». Этот механизм видится достаточно полезным, так как предоставляет ту функциональность, которую не редко приходится реализовывать вручную. В этой статье я попробую рассказать о том, что это за механизм, для чего он нужен и как с ним работать.
Общая информация
Начнем с общей теоретической информации о том, что такое история данных и как она устроена.
Описание и возможности
История данных — это механизм позволяющий хранить в базе данных упорядоченные по времени версии объектов конфигурации. Под версией понимаются данные, которые были в объекте на момент редактирования и состояние метаданных на момент редактирования. Хранить историю можно как для всего объекта целиком, так и для отдельных реквизитов — имеется возможность тонкой настройки работы механизма для каждого реквизита, в том числе табличные части.
Включать и выключать историю можно как из конфигуратора, так и средствами встроенного языка, все это дает возможность управлять историей для каждого пользователя отдельно.
Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:
На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:
Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.
Устройство механизма
История данных хранится в специальных таблицах информационной базы. Кроме самих данных в этих таблицах хранятся метаданные прежних версий объектов. Версии метаданных создаются в момент изменения этих самых метаданных у объекта и никак не связаны с изменением данных объекта.
Также следует помнить, что на данный момент система не отличает включение версионирования для реквизита от создания реквизита и отключение версионирования реквизита от удаления реквизита.
Создание версии объекта состоит из двух этапов. Сначала, автоматически или с помощью специального метода, фиксируется факт изменения объекта и информация об этом изменении попадает в очередь. Перенос данных из очереди в таблицы базы выполняется методом ОбновитьИсторию(), этот метод можно выполнять асинхронно, например регламентным заданием. Идущие подряд изменения одного объекта не «склеиваются» и фиксируются отдельно, вне зависимости от периодичности обновления истории данных.
Настройка версирования объектов осуществляется либо из конфигуратора либо при помощи встроенного языка. Конфигуратор логично использовать в тех случаях, когда история данных потребуется во всех режимах работы приложения или на нее завязана какая-то прикладная логика. Использование встроенного языка потребуется для реализации более гибкой системы, например когда пользователя потребуется самому выбирать для каких объектов хранить историю данных.
Для управления историей данных объектов в конфигураторе реализовано свойство «История данных», оно присутствует как у основных объектов (у справочников, например) так и у подчиненных — реквизиты, табличные части с их реквизитами, ресурсы регистров сведений.
По умолчанию свойство «История данных» установлено в значение «Использовать» у:
Использование механизма
Для обращения к истории данных используется свойство глобального контекста ИсторияДанных, методы этого этого свойства будут рассмотрены ниже.
Управление использованием истории данных
Ниже приведены примеры того, как, средствами встроенного языка, можно управлять использованием истории данных. Отмечу, что значения свойства ИсторияДанных (полученные «через точку») берутся из конфигуратора и могут не соответствовать действительности, для получения актуальной информации нужно пользоваться методом ПолучитьНастройки().
Запуск встроенного в платформу механизма История данных для ленивых
В последних версиях платформы 1С появился замечательный механизм Истории данных. О нем уже много написано к примеру можно посмотреть тут и вот тут.
Если кратко, механизм позволяет сохранять историю, просматривать, сверять и самое приятное, это восстанавливать любую версию объекта. А самое главное, чтобы это заработало, не нужно продумывать, писать и поддерживать тонны кода, все уже сделано за нас.
Возникает вопрос: Как запустить механизм Истории данных для справочника,документа.
-Все что нужно, это в свойствах объекта для свойства «История данных» установить «Использовать» и всё. Больше ничего делать не надо, совсем ничего.
Вести историю механизм позволяет по многим объектам метаданных (справочники, документы, бизнес-процессы, задачи), в том числе и по регистрам сведений.
Единственное, если вы решите вести историю по объекту, в котором уже создана куча элементов, вам потребуется для всех элементов создать первую запись/версию. В противном случае, первой записью будет первое изменение элемента пользователем.
Для массового заполнения истории по всем элементам, по которым нет истории, была написана обработка. Обработка при запуске определяет все объекты метаданных, у которых история данных установлена в использовать. Остается только выбрать объекты, по которым нужно создать версию. Обработка будет работать, если в конфе есть справочник Пользователи и у него имеется реквизит ИдентификаторПользователяИБ, а так же в ПараметрахСеанса имеется ТекущийПользователь. Обработка создает версию, только для элементов, у которых версии нет. Если справочник, договор и т.д. содержит кучу элементов, то придется подождать продолжительное время, т.к. при создании версии платформа для каждого элемента автоматом создает запись в журнал регистрации.
Ещё нужно учитывать, что автоматом изменения не помещаются в таблицы истории, изменения копятся в очереди на добавление, и чтобы они из очереди попали таблицы истории нужно обновлять историю. Для этого была написана доп. обработка. Если у вас есть механизм БСП: Дополнительные отчеты и обработки, то вы можете добавить эту доп обработку и настроить на неё регламентное задание.
Обработка протестирована на платформе 1С:Предприятие 8.3 (8.3.14.1630).
Тонкости настройки Истории данных
Про настройки хранения истории данных написано много. Но мало информации о том, как же это все работает. Итак, при включении режима использования истории данных,
все реквизиты объекта записываются в метаданные, но для того чтобы увидеть сохраненную версию, необходимо выполнить команду
Данная команда выполняется только с правами Администратор.
Если необходимо для конкретного объекта создать версию данных принудительно, то необходимо выполнить после записи объекта код:
Так как же это все таки работает.
Все версии данных, при сохранении объектов попадают в очередь (таблица dbo._DataHistoryQueue0 на сервере SQL), и накапливаются там, пока не выполнится команда
Далее записи перемещаются в dbo._DataHistoryVersions, собственно из этой таблицы мы и видим данные, когда заходим в клиенте в раздел «История изменений» 
Вроде бы ничего сложного, можно пользоваться.
Оказывается, есть нюансы:
А) Необходимо вести историю данных, причем сохранять изменения, которые делали пользователи, а не регламентные задания.
Б) Так же необходимо учесть, если объект пересоздается в другом месте БД, необходимо перенести и его историю. Например: оборудование демонтировали. В БД есть два объекта 1) Оборудование подразделения и 2) Демонтированное оборудование подразделения. При демонтаже в первом объекте запись удаляется, а во-втором создается путем копирования части реквизитов (структуры объектов не одинаковые).
Решение:Для решения пункта А) нам необходимо в объектах использовать процедуру
, где Ссылка на объект – ссылка на объект, для которого необходимо записать версию, т.е. объект, которые мы только что записали.
Почему после записи?
Потому что версия формируется не из формы, а из сохраненной записи БД.
Почему не используется
Потому что изменения, вызванные регламентными заданиями (например перезапись объекта), если таковые имеются, создадут версию данных. При каждом выполнении регламентного задания будет создаваться версия данных и помещаться в очередь. Соответственно при выполнении
все эти версии будут привязаны к объекту.
Для решения Б) нам придется немного схитрить. Дело в том, что готовой функции переноса истории с объекта в объект нет. Так что будем переписывать историю
После записи во-второй объект («Демонтированное оборудование подразделения»), нам необходимо его получить и добавить историю, которая была у объекта Источника:
, где Ссылка на объект – ссылка на объект источника, историю которого мы хотим передать новому объекту.
После переноса истории данных, во-втором объекте будут видны только те поля истории, которые совпадают по наименованию и типу с первым объектом.
Поля, которые нужны только для отображения истории первого объекта, и не используются во-втором объекте можно скрыть от пользователей и не заполнять при переносе из первого объекта.
Вроде бы задача решена, но что нам делать с очередью ИсторииДанных, которая продолжает расти, увеличивая нашу базу не по дням, а по часам.
К сожалению, во встроенной функции ИсторияДанных такой команды нет, поэтому пришлось делать костыльное решение. В SQL создал плановое задание из двух шагов:
Первый шаг, чистить таблицу очереди истории данных
Второй шаг, сжимает БД.
Если второй шаг не выполнять, БД не уменьшится в размерах.
В итоге размер БД сократился в 20 раз. Именно столько накопилось в очереди за 2 месяца использования истории данных.
Специальные предложения
А у Вас тут прям какие-то совершенно непонятные проблемы!
История данных в 8.3.12
Процесс создания версии данных состоит из двух этапов. Сначала, когда вы записываете объект (например, документ), формируется специальное сообщение, которое помещается в очередь. Этот этап выполняет платформа, разработчик в нём не участвует.
А вот второй этап инициируется разработчиком. Второй этап заключается в том, что при обработке очереди эти данные извлекаются, помещаются в хранилище версий, и становятся доступными для работы с ними.
Для того чтобы таким образом обработать очередь, у менеджера истории данных (МенеджерИсторииДанных) есть метод ОбновитьИсторию(). Мы предполагаем, что вы будете использовать его так же, как похожий метод, предназначенный для обновления индекса полнотекстового поиска. То есть обновлять историю вы будете в некотором регламентном задании, которое выполняется с определённой периодичностью.
Мы полагаем, что в результате такой асинхронной работы будет обеспечена как эффективная запись объектов, так и минимизация потерь производительности.
(3)А на русский кто нибудь может это перевести, про второй этап?
Что конкретно надо сделать? Написать какую-то обработку?
Здесь на форуме недавно кто-то говорил что «история данных» работает прям из коробки, без доп.кода.
«Обработка изменения данных
Процесс создания версии данных состоит из двух этапов. Сначала, когда вы записываете объект (например, документ), формируется специальное сообщение, которое помещается в очередь. Этот этап выполняет платформа, разработчик в нём не участвует.
А вот второй этап инициируется разработчиком. Второй этап заключается в том, что при обработке очереди эти данные извлекаются, помещаются в хранилище версий, и становятся доступными для работы с ними.
Для того чтобы таким образом обработать очередь, у менеджера истории данных (МенеджерИсторииДанных) есть метод ОбновитьИсторию(). Мы предполагаем, что вы будете использовать его так же, как похожий метод, предназначенный для обновления индекса полнотекстового поиска. То есть обновлять историю вы будете в некотором регламентном задании, которое выполняется с определённой периодичностью.
Мы полагаем, что в результате такой асинхронной работы будет обеспечена как эффективная запись объектов, так и минимизация потерь производительности.»
История изменений появилась.
Интерфейс для истории данных (платформенное версионирование) в режиме обычных форм
Итак, основные черты функционала «История данных» by 1с.
1. Версионироваться могут: справочники, документы, бизнес-процессы, задачи и регистры сведений(!).
2. Версионирование объекта метаданных включается либо на уровне конфигурации (на вкладке «Прочее» набора свойств объекта метаданных), либо программно. Программно можно назначить версионирование как всего объекта, так и только(!) отдельных(!) реквизитов объекта метаданных.
3.Платформа сохраняет информацию о различиях между версиями, а не объект целиком. Это позволяет сильно экономить место.
4. Версионирование асинхронно. При изменении объекта, задача на формировании версии кладется в стек. А извлечение из стека и формирование версии осуществляется методом менеджера истории данных «ИсторияДанных.ОбновитьИсторию()». 1с рекомендует организовать периодический вызов метода через регламентное задание. Таким образом версия для просмотра и работы с ней становится доступной только после изъятия данных о ней из некоего стека и последующего складирования этих данных в СУБД.
Возможности обработки
1. Универсальный выбор любого объекта метаданных, для которого включено версионирование на уровне конфигурации.
2. Просмотр списка версий
3. Просмотр данных версии
4. Сравнение 2х версий.
5. Построение объекта на основании данных о версии (его можно потом просто записать, тем самым совершив откат к определенной версии).