Как безопасно хранить и переносить данные расширений в 1С 8.3?

С развитием механизма расширений в платформе 1С:Предприятие 8.3 разработчики получили мощный инструмент для кастомизации прикладных решений без изменения типовой конфигурации. Начиная с определенных версий платформы, в расширениях стало возможно создавать собственные объекты метаданных: справочники, документы, регистры сведений и другие. Однако вместе с новыми возможностями пришли и новые риски. У пользователей и начинающих разработчиков часто возникают закономерные опасения: насколько надежно хранятся данные внутри расширений, что произойдет с ними при очередном обновлении и как правильно перенести накопленную информацию в другую базу или в основную конфигурацию?

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

Как физически хранятся данные расширений в СУБД

Для того чтобы уверенно работать с объектами расширений, нам необходимо понимать, как платформа организует их хранение на уровне СУБД. Когда мы добавляем в расширение собственный справочник или регистр сведений, платформа 1С не использует какие-то временные хранилища или файлы. Она создает полноценные физические таблицы в базе данных SQL.

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

Главный риск: отличие обновления от удаления

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

Проанализируем две разные ситуации:

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

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

Что делать, если расширение перестало применяться?

Рассмотрим ситуацию, когда после обновления основной конфигурации (например, типовой бухгалтерии или ERP) наше расширение «слетело» и выдает ошибку применимости. Это может произойти из-за конфликта заимствованных процедур, изменения типов реквизитов в основной конфигурации или несоответствия режима совместимости.

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

Проблема распределенных баз данных (РИБ)

Если в вашей системе используется распределенная информационная база (РИБ), то использование собственных объектов внутри расширений требует удвоенного внимания. Синхронизация изменений структуры расширений между главным и подчиненными узлами может происходить с задержками или сбоями. Если в одном из узлов версия расширения обновится некорректно или произойдет рассинхронизация метаданных, это может привести к невозможности прочитать данные расширения или даже к их частичному повреждению при коллизиях обмена. Для РИБ настоятельно рекомендуется минимизировать создание уникальных структур данных внутри расширений.

Перенос данных расширений через XML

Рано или поздно возникает задача перенести данные расширения в другую базу (например, в тестовую или при разделении учета). На форумах часто советуют использовать стандартные инструменты XML-обмена, но здесь разработчиков подстерегают неочевидные подводные камни. Разберем два основных способа выгрузки.

Способ А: Использование обработки «Выгрузка и загрузка данных XML»

Стандартная обработка Vld83.epf (Выгрузка и загрузка данных XML) предназначена для обмена между полностью идентичными конфигурациями. Однако, если мы запустим её обычным образом в базе с активным расширением, мы обнаружим, что обработка просто «не видит» объекты, созданные в расширении. Они отсутствуют в списке доступных для выгрузки таблиц.

Разберем по шагам лайфхак, который позволяет обойти это ограничение:

1. Открываем конфигуратор нашей базы данных и заходим в наше расширение.
2. Добавляем обработку Vld83.epf непосредственно в состав самого расширения (в ветку «Отчеты и обработки»).
3. Запускаем сеанс «1С:Предприятие».
4. Открываем обработку не через файл, а непосредственно из интерфейса нашего расширения (куда мы ее предварительно вывели).

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

Способ Б: «Универсальный обмен данными в формате XML» (по правилам обмена)

Если нам нужно перенести данные с трансформацией или в базу, где структуры немного отличаются, мы используем конфигурацию «Конвертация данных 2.1» и обработку универсального обмена. Но здесь часто возникает ошибка при попытке выгрузить документы или регистры расширения.

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

1. Неактуальная структура метаданных: Для настройки правил обмена в «Конвертации данных» используется выгрузчик метаданных MD83Exp.epf. Если выгрузить структуру только основной базы, КД 2.1 не получит информацию об объектах расширения. Решение: запускайте выгрузку метаданных только из той базы, где расширение активно, и обязательно используйте самую последнюю версию обработки MD83Exp.epf, которая умеет корректно считывать структуру расширений.
2. Пространства имен XML: При записи объектов расширения в XML-файл платформа 1С автоматически присваивает им уникальные пространства имен (URI-схемы), жестко привязанные к имени конкретного расширения. Если в базе-приемнике расширение имеет хотя бы одну отличающуюся букву в названии или префиксе, XML-парсер при чтении выдаст критическую ошибку Тип не определен. Следите за тем, чтобы имена и префиксы расширений в обеих базах совпадали символ в символ.
3. Проблема COM-соединения: Если обмен настроен напрямую через COM-подключение между базами, обращение к объектам расширений почти всегда будет падать в ошибку. При COM-соединении расширения часто не инициализируются платформой должным образом. Решение: откажитесь от прямого подключения и выполняйте обмен строго через промежуточный XML-файл (выгрузка в файл в одной базе — загрузка из файла в другой).

Альтернативный безопасный путь: Миграция данных в основную конфигурацию

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

Рассмотрим подробный алгоритм, как выполнить эту процедуру без потери информации:

1. В основной конфигурации создаем точно такие же структуры данных. Например, если в расширении у нас был регистр сведений РегистрСведений.расш_НастройкиПользователей, мы создаем в основной конфигурации регистр РегистрСведений.НастройкиПользователей с абсолютно идентичным набором измерений и ресурсов.
2. Пишем и запускаем специальную обработку переноса. Нам нужно программно прочитать данные из таблиц расширения и записать их в новые таблицы основной конфигурации.

Посмотрим на пример кода, реализующего такой перенос для регистра сведений:

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

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

1. Убедиться, что количество записей в новой таблице полностью совпадает со старой.
2. Перенаправить все запросы, формы и алгоритмы в кодовой базе с объектов расширения (префикс расш_) на новые объекты основной конфигурации.
3. Только после детальной проверки работы системы в тестовом и рабочем режимах можно безопасно удалить расширение из базы данных.

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