Разберем актуальную задачу: у нас есть сервер 1С, работающий под управлением операционной системы Linux, и база данных PostgreSQL. В системе развернуто множество информационных баз «1С:Бухгалтерия предприятия 3.0». Нам необходимо организовать получение данных из этих баз (например, остатки по счетам или реестр документов) без фактического входа в каждую базу через пользовательский интерфейс. При этом мы ограничены условиями: использование COM-соединения невозможно (так как сервер на Linux), а публикация баз на веб-сервере запрещена службой безопасности или техническими условиями задачи.
Рассмотрим по шагам доступные механизмы, проанализируем их плюсы и минусы и выберем наиболее подходящий способ реализации.
Этот метод является одним из наиболее эффективных, так как он позволяет работать в привычной среде 1С, используя язык запросов. Платформа 1С:Предприятие поддерживает объект ВнешниеИсточникиДанных, который позволяет подключаться к сторонним базам данных через драйвер ODBC.
Проанализируем алгоритм настройки на Linux:
unixODBC и официальный драйвер PostgreSQL ODBC (psqlODBC)./etc/odbcinst.ini и /etc/odbc.ini, прописав в них параметры подключения к базам-источникам.ВнешниеИсточникиДанных.После этого мы сможем обращаться к таблицам другой базы 1С так же, как к обычным справочникам или регистрам. Однако здесь есть важный технический нюанс: 1С хранит данные в таблицах с именами вроде _InfoReg1234. Чтобы понять, какая таблица соответствует нужному нам объекту метаданных, воспользуемся следующим кодом в базе-источнике (один раз для получения карты соответствия):
ТаблицаМетаданных = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТаблицы Из ТаблицаМетаданных Цикл
Если СтрокаТаблицы.ИмяТаблицы = "Справочник.Номенклатура" Тогда
Сообщить("Реальное имя в SQL: " + СтрокаТаблицы.ИмяТаблицыХранения);
КонецЕсли;
КонецЦикла;
Если нам не хочется настраивать Внешние источники данных в метаданных, мы можем реализовать подключение программно. Выясним, как это сделать. Мы можем использовать объект ADOConnection (только для Windows) или, что более правильно для Linux, настроить прямое выполнение запросов к PostgreSQL из кода 1С через промежуточные библиотеки или скрипты.
Посмотрим на ситуацию со стороны администратора базы данных. Чтобы упростить работу программисту 1С, в PostgreSQL можно создать Представления (Views). Эти представления будут собирать данные из сложных таблиц 1С и представлять их в «человекочитаемом» виде. Например, можно объединить данные из таблиц заголовков и табличных частей документов, переименовав поля из _Fld123 в SummaDoc.
Пример SQL-запроса для получения данных (выполняется в консоли Postgres или через скрипт):
SELECT
_fld100 AS Number,
_fld101 AS Date,
_fld105 AS TotalSum
FROM
_Document200
WHERE
_fld101 > '2023-01-01';
Если прямой доступ к SQL кажется слишком сложным или небезопасным (так как структура таблиц 1С может меняться при обновлениях), рассмотрим вариант с запуском сеанса 1С в «невидимом» режиме. Платформа 1С позволяет запускать исполняемый файл с параметром /Execute, который выполнит внешнюю обработку без участия пользователя.
Разберем этот процесс по шагам:
.epf), которая в процедуре ПриОткрытии (или в модуле объекта при использовании Автономного сервера) собирает нужные данные и записывает их в JSON-файл.ЗапуститьПриложение.Пример командной строки для запуска на Linux:
/opt/1cv8/x86_64/8.3.22.1709/1cv8s ENTERPRISE /S "ServerName\BaseName" /N "Admin" /P "Password" /Execute "/home/user/GetData.epf" /C "ПараметрыПереданныеВОбработку"
Внутри обработки мы можем прочитать параметры через функцию ПараметрыЗапуска(), выполнить запрос внутри базы и выгрузить результат в общую папку.
Поскольку сервер 1С находится на Linux, мы имеем отличную возможность использовать мощь системных скриптов. Проанализируем сценарий, в котором Python выступает в роли сборщика данных. Это решение часто оказывается быстрее и надежнее, чем настройка ODBC внутри 1С.
Мы можем написать небольшой скрипт, использующий библиотеку psycopg2. Скрипт подключается к нужным базам PostgreSQL, выполняет тяжелые аналитические запросы и возвращает результат в центральную базу 1С (например, через временный файл или стандартный поток вывода stdout).
Рассмотрим пример логики такого скрипта:
Это позволяет центральной базе 1С:Бухгалтерия получать данные из «соседних» баз за миллисекунды, не создавая лишних сеансов 1С и не нагружая сервер приложений.
Если базы конфигурационно идентичны (все они — БП 3.0), мы можем задействовать штатный механизм синхронизации. Хотя обычно он используется для полноценного обмена, его можно настроить на одностороннюю выгрузку через локальный каталог.
Выясним преимущества: нам не нужно писать сложный код на SQL. Мы просто настраиваем в целевых базах расписание выгрузки данных в формате EnterpriseData (XML или JSON) в определенную папку на сервере. Центральная база по расписанию сканирует эту папку и загружает данные. Это «чистое» решение с точки зрения архитектуры 1С, которое не требует публикации баз на веб-сервере и работает на Linux из коробки.
Подведем итог: для быстрого получения простых данных лучше всего подходят прямые SQL-запросы или Python-скрипты. Для получения сложных данных с учетом бизнес-логики 1С (например, остатков с учетом итогов) оптимально использовать пакетный режим запуска или Внешние источники данных. Выбор зависит от ваших компетенций в администрировании Linux и готовности поддерживать SQL-запросы при изменении структуры метаданных 1С.