Можно ли работать в одной базе данных с двумя разными конфигурациями (УПП и мобильный клиент)?

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

Почему «одна база — две конфигурации» не работает

В экосистеме 1С:Предприятие база данных и конфигурация связаны неразрывно. Метаданные (структура таблиц, реквизиты, регистры) определяют структуру хранения данных в SQL. Если вы попытаетесь запустить две разные конфигурации (например, УПП и некую мобильную конфигурацию) на одной базе данных, произойдет следующее:

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

Следовательно, попытка «подсунуть» вторую конфигурацию в уже рабочую базу УПП приведет к нарушению целостности данных или невозможности старта системы.

Архитектурное решение: Мобильное приложение + HTTP-сервисы

Вместо создания невозможной связки «одна база — две конфигурации», мы рекомендуем использовать классический паттерн интеграции: **Мобильное приложение (как отдельная конфигурация) + HTTP-сервисы в УПП**. Этот подход позволяет работать с данными основной базы, не затрагивая её стабильность и не снимая режим совместимости.

Рассмотрим по шагам, как организовать такое взаимодействие:

1. Разработка API на стороне УПП

Основная база УПП будет выступать в роли сервера данных. Для этого в конфигураторе УПП создаются HTTP-сервисы. Они представляют собой набор URL-шаблонов, которые отвечают за получение или запись данных.

Рассмотрим пример реализации простого запроса на получение остатков товара:

// В обработчике метода HTTP-сервиса (GET)
Функция ОстаткиТоваровНаСкладе(Запрос)
    Склад = Запрос.ПараметрыЗапроса.Получить("Склад");
    
    Запрос = Новый Запрос;
    Запрос.Текст = "ВЫБРАТЬ Остатки.КоличествоОстаток ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки(,&Склад = &Склад) КАК Остатки";
    Запрос.УстановитьПараметр("Склад", Склад);
    
    Результат = Запрос.Выполнить().Выгрузить();
    
    // Преобразуем результат в JSON
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, Результат);
    
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(ЗаписьJSON.Закрыть());
    Возврат Ответ;
КонецФункции

2. Реализация мобильного приложения

Ваше мобильное приложение создается как отдельная конфигурация на Мобильной платформе 1С. Оно не зависит от версии УПП и не требует изменения режима совместимости основной базы. Приложение обращается к серверу УПП через HTTP-запросы (используя объект HTTPСоединение).

Основные преимущества этого метода:

• Автономность: Мобильное приложение можно обновлять независимо от «тяжелой» УПП.
• Безопасность: Вы сами контролируете, какие данные отдавать в HTTP-сервис, ограничивая доступ к конфиденциальной информации.
• Производительность: Использование HTTP-сервисов позволяет выполнять тяжелые запросы на сервере УПП, возвращая клиенту только готовый результат в формате JSON.

Использование промежуточного слоя данных (Read-Only)

Если задача заключается только в чтении данных для отчетов (например, чтобы пользователи в полях видели актуальные остатки или долги), можно рассмотреть вариант с SQL View:

1. На уровне SQL Server создается представление (View), которое выбирает данные из таблиц регистров УПП.
2. Создается отдельный веб-сервис (на Node.js, Python или даже отдельная маленькая 1С), который опрашивает это представление.
3. Мобильное приложение получает данные из этого сервиса.

Это полностью снимает нагрузку с основной базы УПП, так как обращения к SQL View не блокируют записи в основной конфигурации.

Заключение: что выбрать?

Мы проанализировали ситуацию и выяснили, что попытка «объединить» две конфигурации в одной базе — тупиковый путь. Вместо этого, создайте отдельное Мобильное приложение, которое будет общаться с УПП через HTTP-сервисы. Это стандартный, поддерживаемый и наиболее эффективный способ интеграции, который позволит вам сохранить работоспособность УПП и обеспечить пользователей удобным мобильным функционалом.