Интеграция терминалов сбора данных (ТСД) с учетной системой 1С часто преподносит сюрпризы разработчикам. Особенно остро проблемы встают при использовании многоуровневых схем обмена. Классическая (хотя на сегодняшний день и устаревшая) схема интеграции Клеверенс (Mobile SMARTS) выглядит так: Сервер Mobile SMARTS — [COM-соединение] — Промежуточная конфигурация 1С — [V8x.COMConnector] — Рабочая конфигурация 1С. При этом загрузка документов в основную базу выполняется посредством запуска внешней обработки из-под фонового COM-сеанса.
Основная сложность здесь заключается в том, что стандартный отладчик 1С «из коробки» не видит точку останова во внешней обработке (файл формата .epf), когда она выполняется внутри COM-сессии. В этой статье мы подробно разберем, как преодолеть это ограничение, настроить сервер и среду для полноценной отладки, а также проанализируем современные архитектурные решения обмена с ТСД.
Прежде чем пытаться подключиться к какому-либо сеансу, нам необходимо убедиться, что сам сервер 1С:Предприятия запущен в режиме отладки. Проанализируем, как это сделать:
regedit).HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3... (наименование зависит от версии платформы).ImagePath и проверим наличие ключа -debug.-debug в конец параметров. Например:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug
services.msc.Для операционных систем семейства Linux включение режима отладки производится путем добавления переменной SRV1CV8_DEBUG=1 в конфигурационный файл службы (например, /etc/default/srv1cv83 или через конфигурацию systemd-юнита).
По умолчанию внешние соединения (COM) не передают отладочную информацию на сервер отладки. Чтобы исправить это поведение, нам потребуется вручную создать или отредактировать конфигурационный файл comcntrcfg.xml.
Этот файл должен располагаться в каталоге конфигурационных файлов платформы на компьютере, где физически инициализируется COM-соединение (в нашей схеме — это сервер, где установлена промежуточная конфигурация). Путь к файлу на сервере Windows обычно выглядит следующим образом: C:\Program Files\1cv8\Conf\comcntrcfg.xml.
Разберем пример содержимого этого файла:
<config xmlns="http://v8.1c.ru/v8/comcntrcfg">
<debugconnectionpointconfiguration>
<host>localhost</host>
<port>1560</port>
<protocol>tcp</protocol>
</debugconnectionpointconfiguration>
</config>
В параметре host укажем сетевое имя или IP-адрес компьютера, на котором запущен Конфигуратор с исходным кодом. В параметре port задается диапазон портов отладчика (по умолчанию для протокола TCP это порт 1560 и далее). В современных версиях платформ также поддерживается протокол HTTP.
Для того чтобы отладчик перехватывал фоновые сессии COM-соединений, выполним следующую последовательность действий в Конфигураторе рабочей базы:
Также важно настроить параметры запуска клиентского приложения. Перейдем в меню Сервис -> Параметры -> Запуск 1С:Предприятия -> Дополнительно и установим флаг Начинать отладку при запуске. Это гарантирует инициализацию необходимых механизмов отладки при старте приложения.
Даже при успешном подключении к COM-сеансу отладчик часто игнорирует точки останова внутри файлов .epf. Это происходит потому, что когда внешняя обработка запускается программно из двоичного потока (например, из временного хранилища или справочника базы данных), среда выполнения не сопоставляет ее с физическим файлом обработки, открытым на вашем компьютере.
Рассмотрим надежный обходной путь решения этой проблемы. Мы внедрим в начало ключевой экспортной процедуры обработки (например, в процедуру ДокументЗавершен) специальный код-коммутатор, который будет принудительно перенаправлять выполнение на физический файл обработки, сохраненный на диске сервера.
Проанализируем пример такого программного перенаправления:
Процедура ДокументЗавершен(ПараметрыДокумента, ДанныеТСД) Экспорт
// Путь к файлу обработки на диске сервера, где ведется отладка
АдресФизическогоФайла = "D:\DebugExchange\MobileSmartExchange.epf";
// Проверяем, совпадает ли имя запущенного объекта с физическим файлом
Если Найти(ЭтотОбъект.ИспользуемоеИмяФайла, "MobileSmartExchange.epf") = 0 Тогда
// Если обработка запущена из временной папки или памяти,
// создаем новый экземпляр непосредственно из отладочного файла на диске
Попытка
ОбъектОтладки = ВнешниеОбработки.Create(АдресФизическогоФайла, Ложь);
ЗаполнитьЗначенияСвойств(ОбъектОтладки, ЭтотОбъект);
// Перенаправляем вызов метода в физический файл
ОбъектОтладки.ДокументЗавершен(ПараметрыДокумента, ДанныеТСД);
Возврат;
Исключение
ЗаписьЖурналаРегистрации("Отладка_COM",
УровеньЖурналаРегистрации.Ошибка, , ,
"Не удалось инициализировать файл отладки: " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
// --- Оригинальный исполняемый код загрузки документа ---
// Здесь мы устанавливаем точку останова в Конфигураторе,
// предварительно открыв файл D:\DebugExchange\MobileSmartExchange.epf
ЗаполнитьРеквизитыДокумента(ПараметрыДокумента, ДанныеТСД);
КонецПроцедуры
Благодаря этому приему при вызове процедуры из промежуточной базы через COM-соединение выполнение немедленно перейдет в физический файл MobileSmartExchange.epf. Отладчик, в котором этот файл открыт, мгновенно сработает на установленной точке останова внутри оригинального исполняемого кода.
Использование промежуточных конфигураций 1С и каскадных COM-соединений — это тяжелое наследие старых систем автоматизации. В современных реалиях Клеверенс (Mobile SMARTS версии 15 и выше) предоставляет бесшовную интеграцию напрямую через HTTP-сервисы и механизм расширений конфигурации 1С.
Давайте выясним основные преимущества отказа от промежуточных баз и перехода на HTTP-сервисы:
Для перехода на современную схему достаточно скачать актуальный интеграционный пакет Mobile SMARTS, установить стандартное расширение в рабочую конфигурацию 1С и опубликовать HTTP-сервис MobileSMARTS на веб-сервере.
При интеграции ТСД с 1С (особенно в сфере маркировки ЕГАИС, Честный Знак, МДЛП) разработчики часто сталкиваются с тем, что при сканировании штрихкодов формата GS1 DataMatrix теряются управляющие символы разделения групп данных — символ GS (код ASCII 29).
Эта проблема наиболее ярко проявляется, когда складские сотрудники работают на ТСД через терминальный доступ (RDP) в режиме эмуляции клавиатуры. RDP-клиент не способен корректно транслировать символ с кодом 29 во внутреннюю сессию 1С, из-за чего штрихкод «склеивается» и становится нечитаемым для алгоритмов проверки.
Рассмотрим два надежных пути решения этой проблемы:
| или решетку #). На стороне 1С в процедуре обработки сканирования пишется код обратной замены:
// Функция предобработки штрихкода перед валидацией в 1С
Функция ВосстановитьСимволыРазделителей(Знач ВходнойШтрихкод) Экспорт
// Восстанавливаем символ GS (ASCII 29) из маскировочного символа "|"
Результат = СтрЗаменить(ВходнойШтрихкод, "|", Символ(29));
Возврат Результат;
КонецФункции
Применение этой несложной функции гарантирует, что система маркировки в 1С без проблем распознает структуру кода маркировки и успешно сопоставит товар на складе.
При автоматизации крупных складов разработчики часто сталкиваются с бизнес-требованием: один большой документ (например, заказ на сборку фуры объемом 40 000 позиций) должны одновременно собирать несколько кладовщиков. Пытаться реализовать это стандартными методами 1С — тупиковый путь, ведущий к бесконечным блокировкам СУБД.
В решениях Клеверенс («Склад 15») эта задача решена на уровне платформы через механизм коллективного документа:
Использование этого функционала требует лицензии уровня «Омни» и качественного бесшовного Wi-Fi покрытия на складе, однако полностью избавляет 1С от лишней транзакционной нагрузки.