Как организовать взаимодействие между конфигурациями 1С для опроса оборудования через COM или фоновые процессы?

← На главную

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

В чем разница между V83.COMConnector и V83.Application

Для прямого взаимодействия между базами на уровне платформы 1С:Предприятие 8.3 применяются два основных COM-объекта: V83.COMConnector (внешнее соединение) и V83.Application (OLE Automation). Проанализируем ключевые различия в их работе:

V83.COMConnector — работает в невидимом режиме непосредственно в адресном пространстве вызывающего процесса. Запуск выполняется быстро, потребление оперативной памяти минимально. Однако соединение функционирует в специальном контексте внешнего соединения. В нем полностью отсутствуют клиентские механизмы (окна, пользовательский интерфейс, методы ожидания вроде ПодключитьОбработчикОжидания()), а также невозможно подключение внешних компонент и драйверов оборудования, скомпилированных только под клиентское окружение.
V83.Application — запускает полноценный клиентский процесс платформы (аналогично запуску исполняемого файла 1cv8.exe). Доступен полный функционал тонкого или толстого клиента, включая работу с внешними компонентами драйверов и обработчиками ожидания. Минусы: сеанс занимает отдельную пользовательскую лицензию, требует длительной инициализации и может зависнуть при появлении любого модального диалога или сообщения об ошибке.

Посмотрим на пример попытки программного подключения через OLE-клиент:


СтрокаПодключения = "File=""" + ПутьКФайловойБазе + """; Usr=""" + ИмяПользователя + """; Pwd=""" + ПарольПользователя + """;";
Попытка
    Соединитель = Новый COMObject("V83.Application");
    мСоединение = Соединитель.Connect(СтрокаПодключения);
Исключение
    Сообщить("Не удалось подключиться: " + ОписаниеОшибки());
КонецПопытки;

Почему не запускаются фоновые и регламентные задания в файловой базе

При использовании файлового режима работы информационных баз разработчики часто сталкиваются с тем, что параметр SchJobDn=N в строке соединения не приводит к автоматическому запуску регламентных заданий. Выясним причину такого поведения.

В файловой информационной базе отсутствует серверный кластер с отдельным менеджером кластера и пулом фоновых потоков. Диспетчеризация регламентных задач по расписанию возможна только тогда, когда запущен выделенный интерактивный клиентский сеанс. COM-соединение V83.COMConnector не запускает внутренний планировщик платформы. Метод ФоновыеЗадания.Выполнить() в файловом режиме либо отрабатывает строго синхронно, блокируя сеанс, либо вовсе завершается ошибкой при попытке параллельного вызова. Поэтому рассчитывать на фоновый опрос устройств через регламентные задания внутри COM-сессии в файловом варианте нельзя.

Как настроить отладку внешнего соединения

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

В конфигураторе открываем меню Сервис — Параметры, переходим на вкладку Отладка и убеждаемся, что включен флажок Внешние соединения в списке разрешенных типов отладки.
Для серверов и COM-компонентов создаем специальный конфигурационный файл comcntrcfg.xml. Он должен располагаться в каталоге conf платформы 1С:Предприятие (например, C:\Program Files\1cv8\conf\).
Внутри файла comcntrcfg.xml прописываем протокол отладки и адрес отладчика:


<config xmlns="http://v8.1c.ru/v8/config">
    <debug protocol="tcp" auto="true" debuggerURL="tcp://localhost:1560"/>
</config>

Важный момент: если в вызываемом модуле внешнего соединения или процедуре ПриНачалеРаботыСистемы() возникает необработанное исключение, соединение немедленно разрывается. Отладчик не успевает показать строку сбоя, если точка останова установлена позже места возникновения ошибки. Чтобы найти сбойный участок, установите точку останова в самое начало процедуры подключения либо временно очистите блок инициализации, выполнив контрольный запуск.

Оптимальные архитектурные варианты решения

Рассмотрим, как наиболее стабильно выстроить архитектуру опроса физических устройств без зависаний сеансов и блокировок файловой базы.

Вариант 1. Постоянно запущенный скрытый сеанс опроса и чтение через COMConnector

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


WshShell = Новый COMObject("WScript.Shell");
КомандаЗапуска = """C:\Program Files\1cv8\8.3.X.X\bin\1cv8.exe"" ENTERPRISE /F """ + ПутьКБазе + """ /N """ + ИмяПользователя + """ /P """ + Пароль + """ /DisableStartupMessages";
WshShell.Run(КомандаЗапуска, 0, Ложь);

Основная конфигурация при этом не пытается запустить слушатель из-под себя, а лишь периодически считывает готовые накопленные данные из таблиц вспомогательной базы через быстрый V83.COMConnector:


Соединитель = Новый COMObject("V83.COMConnector");
Соединение = Соединитель.Connect("File=""" + ПутьКБазе + """; Usr=""" + ИмяПользователя + """; Pwd=""" + Пароль + """;");
Результат = Соединение.СлужебныйМодуль.ПолучитьПоказанияПрибора();

Вариант 2. Публикация HTTP-сервиса во вспомогательной базе

Файловую базу со сборщиком данных публикуем на веб-сервере (IIS или Apache). Во вспомогательной базе создаем объект конфигурации HTTP-сервис. Основная база отправляет стандартные GET- или POST-запросы через HTTPСоединение, получая накопленные данные или передавая управляющие команды в формате JSON. Это полностью исключает проблемы с разрядностью библиотек COM (x86/x64) и снижает риск файловых взаимоблокировок.

Вариант 3. Вынос опроса оборудования в системную службу

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