При разработке модульных решений для тиражных конфигураций (например, УТ 11, КА 2, ERP 2) мы часто сталкиваемся с задачей красивой интеграции нашего функционала в интерфейс пользователя. Представим ситуацию: у нас есть линейка продуктов для работы с маркетплейсами. Мы хотим продавать их по отдельности (модуль для Wildberries, модуль для Ozon, модуль аналитики), но в интерфейсе пользователя все они должны отображаться в одной общей подсистеме, например, "Маркетплейсы".
Однако при попытке создать подсистему с одним и тем же именем в двух разных расширениях и подключить их к одной базе, платформа выдает ошибку: Критичная: Уже существует объект с именем Подсистема.ИмяПодсистемы
В этой статье мы подробно разберем, почему возникает эта ошибка, и рассмотрим несколько архитектурных подходов для решения задачи объединения функционала из разных расширений в единое рабочее пространство.
Давайте разберемся, почему платформа не позволяет нам создать две одинаковые подсистемы в разных расширениях. Механизм расширений конфигурации работает таким образом, что каждое расширение добавляет свои объекты в общее пространство имен метаданных.
Когда мы создаем объект Подсистема с именем "Маркетплейсы" в Расширении №1, платформа регистрирует этот идентификатор. Когда мы пытаемся применить Расширение №2, где также создан объект Подсистема с именем "Маркетплейсы", возникает коллизия. Для платформы это два разных объекта (у них разные внутренние идентификаторы UUID), которые претендуют на одно и то же имя в дереве метаданных. Платформа 1С не умеет автоматически "склеивать" две подсистемы из разных расширений в одну визуальную сущность.
Рассмотрим варианты, как мы можем обойти это ограничение и предоставить пользователю удобный интерфейс.
Если наша цель — избежать создания сложной архитектуры зависимостей и обеспечить максимально простую установку модулей клиентам, мы можем отказаться от идеи создания собственной корневой подсистемы.
Вместо этого мы будем использовать существующие подсистемы типовой конфигурации (например, "Главное", "Продажи" или "Закупки").
Как это реализовать:
Подсистема.Главное.Этот метод, к которому пришел автор вопроса, является наиболее безопасным с точки зрения отсутствия конфликтов. Пользователь увидит ваши команды в привычном разделе меню. Визуально функционал будет сгруппирован, но технически конфликта имен подсистем не произойдет, так как мы используем уже существующий объект конфигурации.
Более академически правильный, но сложный в логистике подход — это разделение логики и интерфейса.
Мы можем создать одно "Базовое расширение" (Core), которое будет содержать:
Все остальные расширения (функциональные модули) будут подключаться поверх базового. Они будут добавлять свои команды в подсистему, определенную в базовом расширении.
Преимущества:
Недостатки:
Если мы хотим, чтобы интерфейс выглядел современно и "бесшовно", мы можем реализовать подход "Единого окна". Вместо добавления множества подсистем, мы добавляем в интерфейс (например, на Начальную страницу или в раздел "Продажи") всего одну команду — "Рабочее место Маркетплейсов".
Эта команда открывает ОбщуюФорму, которая программно определяет, какие модули подключены, и отрисовывает соответствующие кнопки.
Алгоритм реализации:
ОбщегоНазначенияКлиент.ПодсистемаСуществует, если мы внедрили сведения о подсистеме).Пример логики проверки (псевдокод):
// В модуле формы рабочего места
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверяем наличие функционала WB
Если ЕстьФункционалWB() Тогда
ДобавитьКнопку("Загрузить заказы WB", "КомандаЗагрузкиWB");
КонецЕсли;
// Проверяем наличие функционала Ozon
Если ЕстьФункционалOzon() Тогда
ДобавитьКнопку("Загрузить заказы Ozon", "КомандаЗагрузкиOzon");
КонецЕсли;
КонецПроцедуры
Самый простой способ избежать ошибки "Объект уже существует" — это дать подсистемам разные имена, используя префиксы. Например:
Подсистема.ВБ_МаркетплейсыПодсистема.Озон_МаркетплейсыОднако, как справедливо замечено в обсуждении, это приведет к появлению множества отдельных подсистем в панели разделов пользователя ("Маркетплейсы ВБ", "Маркетплейсы Озон" и т.д.), что засоряет интерфейс и ухудшает пользовательский опыт.
Проанализировав задачу, мы видим, что идеального решения "из коробки", позволяющего склеивать подсистемы из разных расширений, платформа 1С пока не предоставляет из-за архитектуры пространства имен.
Для коммерческой разработки тиражных решений наиболее жизнеспособными вариантами являются:
Выбор между этими методами зависит от объема функционала и того, насколько критично для вас наличие отдельной "брендированной" иконки в главном меню программы.