← На главную

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

Анализ архитектуры взаимодействия

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

1. HTTP-публикация: Прямая связь веб-сервера (Apache или IIS) с конкретной базой 1С.
2. Конфигурационные файлы: Настройки внутри контейнеров или на уровне API, определяющие адрес публикации HTTP-сервиса.
3. Динамические переменные: Данные, передаваемые в заголовках запросов или хранящиеся в базе настроек самого API.

Решение 1: Изменение параметров файла публикации (default.vrd)

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

Выполним следующие действия:

1. Найдите каталог, в котором размещена публикация текущей базы на веб-сервере.
2. Откройте файл default.vrd в текстовом редакторе.
3. Найдите параметр ib, который указывает на путь к информационной базе (например, Ref="NameOfBase" или путь к файловой базе).
4. Измените значение этого параметра на путь к необходимой вам базе данных.
5. Сохраните изменения и обязательно перезапустите службу веб-сервера (например, systemctl restart apache2 в Linux), чтобы настройки вступили в силу.

Решение 2: Поиск конфигурационных файлов middleware

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

Рассмотрим, как найти и изменить эти параметры:

• Проверка переменных окружения: Используйте команду docker inspect для проверки того, какие переменные передаются в контейнер. Ищите ключи вида 1C_URL, DB_CONNECTION_STRING или BASE_PUBLICATION_URL.
• Анализ примонтированных томов: Проверьте файл docker-compose.yml. Раздел volumes покажет, какие файлы конфигурации (например, .json, .yaml, .env) пробрасываются внутрь контейнера. В этих файлах может быть жестко прописан URL, по которому API стучится в 1С.
• Изменение конфигурации: После обнаружения нужного файла, скорректируйте адрес на целевой URL публикации 1С и выполните пересоздание или перезапуск контейнеров с помощью команды docker-compose up -d.

Решение 3: Проверка логики API на предмет динамической маршрутизации

Иногда система настроена сложнее: например, middleware может поддерживать работу с несколькими базами сразу, выбирая нужную по параметрам запроса от мобильного клиента.

Рассмотрим, что стоит проверить:

• Изучите исходный код API на наличие обращения к функциям формирования URL. Если адрес берется из заголовков запроса (например, X-Base-ID), вам не нужно править конфиги, достаточно передавать нужный идентификатор со стороны мобильного клиента.
• Убедитесь, что middleware не использует собственную базу данных (например, PostgreSQL или Redis) для хранения таблицы маршрутизации баз 1С. В таком случае необходимо будет изменить запись в этой таблице с помощью SQL-запроса или административного интерфейса.

Итоговые рекомендации по отладке

Чтобы убедиться, что вы нашли правильное место «сцепки», рекомендуем выполнить следующие шаги:

1. Проанализируйте логи веб-сервера (access.log и error.log), чтобы увидеть, на какой именно адрес уходят запросы в момент активности мобильного клиента.
2. Если используется API Gateway (например, Nginx или Traefik), проверьте правила rewrite или настройки proxy_pass. Часто перенаправление происходит на уровне прокси, еще до того, как запрос попадет в контейнер с бизнес-логикой.
3. Всегда делайте резервную копию конфигурационных файлов перед внесением изменений.

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