Почему я решил писать эту статью?
Какие способы регистрации изменений есть в платформе?
Недостатки старых подходов при организации интеграций.
На что способна История данных?
Создадим конфигурацию с расширениями.
Включим программно Историю данных.
Пример 1: Первое знакомство с пост обработкой.
Пример 3: Включаем автоматику, чистку отработанных версий и отключаем ненужные реквизиты.
Почему я решил писать эту статью?
1 Я уже рассказывал, как в 2021 году провел 100 собеседований за 3 месяца и увидел, что 50% собеседуемых не слышали про Историю данных, 20% что-то слышали, но не знают, чем она отличается от БСП Версионирования данных.
Как по мне — это пугающая статистика.
В связи с чем я поставил себе цель на 2023 год – «Максимально донести информацию по данной технологии платформы». Я спланировал все кубики пазла и это последний кубик, который я планировал рассказать, как часть доклада. В докладе был пункт «Плановый переход с планов обмена на историю данных». Доклада не случилось, поэтому последний кубик будет в виде статьи.
2 Спойлер. Начал писать цикл статей по интеграции, связанных с Шиной, и пришел к выводу, что без данной статьи получится очень громоздко.
Какие способы регистрации изменений есть в платформе?
- Первое, что приходит в голову, «Планы обмена».
- Второе, различные вариации на тему Регистров сведений.
Есть варианты отлова изменений прямо на SQL, но это уже совсем другая история.
Для начала я рекомендую почитать или посмотреть выступление Дмитрия Жичкина, так как он уже подробно описал архитектуру и основные недостатки планов обмена -> Планы обмена 1С
На последнем INFOSTART EVENT 2023 он же выступал с докладом «Тюнинг планов обмена», в котором пытался оживить Планы обмена за счет своей разработки DaJet. Уверен многие из нас делали регистрацию изменений на Регистрах сведений и часть проблем уходило, но проблем все равно много.
Недостатки старых подходов при организации интеграций.
- Блокировки. Про подробности читайте статью -> Планы обмена 1С
- Регистрируется сам факт изменения.
Мы не знаем, что поменялось в объекте, соответственно даже если поменялся только комментарий, мы потащим объект целиком, даже если в объекте может быть много таблиц.
Представьте, что вы приходите к врачу за справкой, а с вас требуют все ваши документы, которые у вас появились за все время жизни, плюсом требуют рассказать все, чем вы занимаетесь, про ваши хобби, вкусовые предпочтения и т.д.
- Все или ничего.
Нельзя собирать изменения только по части объекта.
Хотя… Можно, но для этого в подписке «ПередЗаписью» придётся сделать проверку изменений до и после только по определенным реквизитам, а потом еще дорабатывать, когда пересмотрите свои взгляды на первоначальные настройки.
- Мы не знаем автора изменений.
Это вытекает из предыдущих недостатков. На помощь может прийти Версионирование объектов или можно изобразить свой велосипед.
- Последовательность.
Мы не знаем, в какой последовательности изменялись данные.
Это решается при использовании Регистров сведений и поля а ля timestamp.
Либо выставляется приоритет загрузки\выгрузки, но этот велосипед устарел…
- Изменение состава через доработки.
Хотите регистрировать новый объект?
Добавьте его в состав.
Хотите, чтобы он попадал в обмен не всегда?
Необходимо запретить Авторегистрацию и написать код в «ПередЗаписью».
И, кстати, не забудьте дать права.
И только после обновления конфигурации и добавления узла рег
Вступайте в нашу телеграмм-группу Инфостарт
