← На главную

При активном использовании расширений в платформе 1С:Предприятие 8.3 разработчики нередко сталкиваются с загадочным поведением системы: после загрузки расширения в рабочую базу и попытки внести в него даже малейшие правки, оно бесследно «исчезает». В списке расширений конфигуратора его больше нет, а пользователи теряют доступ к разработанному функционалу. Ситуация становится по-настоящему критической, если расширение содержало новые объекты метаданных (справочники, документы, регистры) с уже накопленными данными.

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

Выясняем причину: почему расширение пропадает?

Рассмотрим детально, какие внутренние механизмы платформы 1С:Предприятие приводят к такому поведению. Как показывает практика, «исчезновение» происходит из-за двух основных факторов:

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

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

Решение 1. Правильный регламент переноса изменений

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

Давайте разберем правильный цикл разработки по шагам:

1. Выполняем все доработки и тестирование расширения в специально выделенной тестовой информационной базе (базе разработки).
2. После успешного тестирования в конфигураторе тестовой базы выбираем пункт меню Конфигурация — Расширения конфигурации, выделяем нужное расширение и нажимаем кнопку «Сохранить конфигурацию расширения в файл». Получаем файл с расширением .cfe.
3. В рабочей базе данных открываем список расширений и, не внося никаких изменений вручную, выбираем команду «Загрузить конфигурацию из файла», указав наш сохраненный файл.
4. При необходимости обновляем конфигурацию базы данных (клавиша F7). При этом перезапуск пользователей и монопольный режим чаще всего не требуются (если изменения не затрагивают структуру данных).

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

Решение 2. Настройка и отключение защиты от опасных действий

Для предотвращения блокировок со стороны системы безопасности 1С необходимо правильно настроить параметры защиты. Рассмотрим, как это сделать.

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

1. Откройте Конфигуратор рабочей базы под правами администратора.
2. Перейдите в меню Администрирование — Пользователи.
3. Откройте свойства учетной записи администратора, выполняющего обновление, и на вкладке «Основные» снимите флаг «Защита от опасных действий».

Для клиент-серверных баз радикальным и надежным решением является отключение этой защиты на уровне всего сервера приложений. Для этого в файле конфигурации conf.cfg (который обычно располагается в каталоге установки платформы на сервере 1С, например, C:\Program Files\1cv8\conf) необходимо прописать специальный параметр:

DisableUnsafeActionProtection=.*

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

Решение 3. Принудительный сброс кэша и восстановление «пропавшего» расширения

Что делать, если расширение уже исчехло из режима «1С:Предприятие», хотя в Конфигураторе оно вроде бы числится как активное? Рассмотрим лайфхак по принудительному обновлению кэша метаданных:

1. В Конфигураторе рабочей базы откройте конфигурацию исчезнувшего расширения.
2. Откройте любой модуль (например, модуль управляемого приложения расширения или модуль любого заимствованного объекта).
3. Внесите фиктивное изменение: добавьте пустую строку или пробел в конце любого метода.
4. Сохраните изменения и запустите обновление конфигурации базы данных с помощью клавиши F7 (или синей кнопки на панели инструментов).

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

Также в сложных случаях помогает запуск процедуры Тестирования и исправления с активным пунктом «Проверка логической целостности расширений конфигурации».

Решение 4. Использование Хранилища конфигурации расширений

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

Создание хранилища для расширения происходит аналогично созданию хранилища основной конфигурации. В конфигураторе при открытом расширении выберите меню Конфигурация — Хранилище конфигурации — Создать хранилище. Подключение остальных разработчиков к этому хранилищу обеспечит строгое версионирование и защитит конфигурацию расширения от случайных затираний и сбоев кэша метаданных.

Безопасность данных: что происходит с собственными объектами расширения при его исчезновении?

Теперь ответим на самый важный вопрос, который волнует каждого разработчика: что произойдет с данными, если в расширении были созданы новые справочники, документы или реквизиты, и оно вдруг «исчезло»?

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

Сценарий А: Расширение просто «отвалилось» (баг кэша или снят флаг «Активно»).
В этом случае физические таблицы в СУБД (SQL-сервере) никуда не пропадают. Платформа 1С хранит таблицы созданных расширением объектов с особыми суффиксами (например, содержащими идентификатор расширения _ext). Пока запись о расширении физически присутствует в списке конфигуратора (даже если оно неактивно или сбоит), таблицы СУБД остаются в целости и сохранности. Как только вы примените фиктивное изменение (как описано в Решении 3) или загрузите исправленный файл .cfe поверх старого расширения, платформа мгновенно восстановит связь, и все накопленные данные снова станут доступны пользователям. Никакие данные при этом не теряются!

Сценарий Б: Вы физически удалили расширение из списка и создали его заново.
А вот этот сценарий несет смертельную опасность для вашей базы данных. Если вы решите удалить «пропавшее» расширение кнопкой «Удалить» (красный крестик в списке расширений) для того, чтобы затем просто создать чистое расширение и загрузить туда старый файл .cfe — все накопленные в объектах расширения данные будут безвозвратно уничтожены! При физическом удалении расширения платформа инициирует процедуру полной реструктуризации базы данных и отправляет в СУБД SQL-команду на удаление (DROP TABLE) всех связанных таблиц расширения. Повторная загрузка файла .cfe создаст новые, абсолютно пустые таблицы. Восстановить утерянные данные в таком случае можно будет только из резервной копии всей базы данных (бэкапа СУБД).

Золотые правила безопасной работы с расширениями

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

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

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