В практике разработчика 1С нередко возникает ситуация, когда расширение конфигурации, казалось бы, настроено верно, режим совместимости совпадает, а безопасный режим отключен, но система игнорирует его работу. Особенно часто это встречается в тяжелых решениях, таких как 1С:ERP Управление предприятием в связке с модулем CRM. Самое неприятное в этой ситуации — отсутствие каких-либо диагностических сообщений или записей в Журнале регистрации.
В данной статье мы разберем, почему расширение может «молчать» при подключении, как выявить скрытые конфликты метаданных и какую роль в этом процессе играют права доступа. Проанализируем ситуацию на примере платформы 8.3.18 и выясним, как докопаться до истины, когда стандартные методы не помогают.
Когда расширение не подключается ни в режиме «1С:Предприятие», ни через конфигуратор, первым делом нам необходимо воспользоваться штатным механизмом проверки. Часто разработчики ограничиваются простым добавлением расширения в список, но забывают запустить глубокий анализ метаданных.
Рассмотрим по шагам, как выполнить эту операцию:
Конфигурация — Расширения конфигурации.Именно этот инструмент позволяет платформе выполнить полную компиляцию изменений и сопоставить их с основной конфигурацией. Если расширение содержит ошибки, которые блокируют его загрузку в память, система выведет детальный список конфликтов в окно сообщений. Как показывает практика, именно этот метод позволяет обнаружить ошибки в Ролях или Формах, которые не видны при обычном визуальном осмотре.
Выясним причину, почему именно роли часто становятся «камнем преткновения». Роли в расширениях работают по специфическим правилам, и любая неточность может привести к тому, что расширение будет помечено системой как неактивное. Проанализируем основные факторы риска:
1. Конфликт прав на уровне сеанса. Если в расширении вы создаете новую роль, помните, что она не назначается пользователям автоматически. Система может успешно подключить расширение, но если у текущего пользователя нет прав на новые объекты, добавленные в этом расширении, визуально будет казаться, что ничего не изменилось.
2. Дублирование имен и заимствование. Если имя роли в расширении совпадает с именем роли в основной конфигурации, но при этом состав прав или объекты метаданных различаются, платформа может войти в клинч при попытке объединения прав. Рекомендуется использовать уникальные префиксы для ролей расширения.
3. Ошибки в шаблонах ограничений (RLS). Рассмотрим ситуацию: в роли расширения прописаны шаблоны ограничений доступа на уровне записей, которые обращаются к объектам, не включенным в это же расширение. В этом случае проверка возможности применения выдаст критическую ошибку, так как система не сможет скомпилировать запрос RLS.
4. Флаг «Устанавливать основные роли конфигурации». Проанализируем настройки свойств расширения. Если установлена галочка «Устанавливать основные роли конфигурации», это может кардинально изменить модель безопасности системы, что иногда блокирует применение расширения из-за конфликтов с профилями групп доступа в ERP.
Многие системные администраторы ожидают увидеть отчет об ошибке в Журнале регистрации, но при проблемах с расширениями это происходит крайне редко. Разберем почему:
Журнал регистрации фиксирует события уже запущенного приложения. Если расширение не проходит проверку на этапе инициализации метаданных (до старта сеанса или в момент обращения к таблице расширений), запись в журнал просто не успевает сформироваться. Для диагностики таких «тихих» отказов мы рекомендуем использовать Технологический журнал.
Для настройки техжурнала необходимо создать файл logcfg.xml и добавить в него отслеживание событий EXCP (исключения) и ERR (ошибки). Пример структуры файла для поиска проблем инициализации:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\EXTENSIONS" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="ERR"/>
</event>
<property name="All"/>
</log>
</config>
В полученных логах следует искать упоминания расширений и ошибки обращения к схемам данных.
Связка ERP + CRM является крайне тяжелой с точки зрения объема метаданных. Платформа 8.3.18 имеет свои особенности работы с кэшем конфигурации на сервере. Посмотрим на возможные причины сбоев:
snccntx и configsave на сервере приложений.Подведем итог и составим план действий для восстановления работоспособности системы:
RLS.XML и поиск по тексту на предмет некорректных ссылок.Следуя этим рекомендациям, мы сможем диагностировать даже самые сложные случаи «молчаливого» отказа системы от работы с расширениями метаданных.