Как ускорить обмен данными между базами 1С и заменить медленное COM-соединение на HTTP-сервисы?

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

Почему COM-соединение работает медленно?

Прежде чем переходить к решениям, выясним причину задержек. Основная проблема COM заключается в так называемом «холодном старте». При каждом создании объекта COMConnector системе требуется:

1. Инициировать запуск полноценного сеанса 1С.
2. Выполнить проверку лицензий.
3. Загрузить конфигурацию и все необходимые метаданные.
4. Отработать код в модуле сеанса и модуле управляемого приложения.

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

Вариант 1. Использование HTTP-сервисов (рекомендуемый способ)

HTTP-сервисы — это наиболее эффективный способ обмена данными в среде 1С. Они работают через веб-сервер (Apache или IIS) и позволяют передавать данные в легком формате JSON.

Рассмотрим алгоритм реализации HTTP-сервиса в базе ЗУП через расширение:

1. Создаем расширение в базе-источнике (ЗУП).
2. Добавляем новый объект HTTP-сервис.
3. Определяем шаблон URL (например, /get_data/{TabNumber}) и метод GET.
4. Прописываем логику получения данных в модуле сервиса.

Разберем пример кода для обработчика метода GET, который должен возвращать данные сотрудника по табельному номеру:

Функция ДанныеСотрудникаGet(Запрос)
    ТабельныйНомер = Запрос.ПараметрыURL.Получить("TabNumber");
    
    // Логика поиска сотрудника и получения расчетного листка
    Данные = Новый Структура;
    Данные.Вставить("ФИО", "Иванов Иван Иванович");
    Данные.Вставить("Оклад", 50000);
    Данные.Вставить("Статус", "Рассчитано");
    
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, Данные);
    СтрокаJSON = ЗаписьJSON.Закрыть();
    
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(СтрокаJSON);
    Возврат Ответ;
КонецФункции

Преимущество: HTTP-сервисы позволяют изменять структуру передаваемых данных «на лету» без жесткой привязки к XDTO-пакетам, что значительно упрощает разработку и отладку.

Вариант 2. Веб-сервисы (SOAP)

Если вам важна строгая типизация данных, рассмотрим использование классических Web-сервисов. Они используют протокол SOAP и XML для передачи сообщений.

Проанализируем ситуацию: веб-сервис удобен тем, что 1С автоматически генерирует описание типов (WSDL), и в базе-приемнике вы сможете работать с объектами XDTO, которые платформа понимает нативно. Однако парсинг XML и работа с XDTO могут быть чуть медленнее и сложнее в реализации, чем работа с JSON в HTTP-сервисах.

Вариант 3. Оптимизация архитектуры через кэширование

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

Разберем, как это работает:

1. В «Самописной» базе создается регистр сведений КэшДанныхСотрудников.
2. Регламентное задание раз в час (или по расписанию) забирает измененные данные из ЗУП через HTTP-сервис и наполняет этот регистр.
3. Когда сотрудник прикладывает пропуск к терминалу, запрос идет к локальному регистру «Самописной» базы.

Это обеспечит мгновенный отклик интерфейса, так как сетевое взаимодействие в момент обращения пользователя полностью исключается.

Вариант 4. Формирование расчетного листка в HTML

Для инфокиоска очень эффективным решением будет формирование макета не на стороне терминала, а на стороне ЗУП. Выясним, как это реализовать:

В HTTP-сервисе на стороне ЗУП мы можем сформировать отчет «Расчетный листок», сохранить его в формат HTML и передать эту строку в базу-приемник. В «Самописной» базе достаточно будет вывести полученную строку в поле HTML-документа на форме. Это гарантирует, что оформление листка будет в точности соответствовать стандартам ЗУП, а нагрузка на клиентское приложение терминала будет минимальной.

Вариант 5. Использование OData (REST-интерфейс)

Если вы не хотите писать код в ЗУП, можно воспользоваться встроенным механизмом OData. Рассмотрим этот вариант подробнее:

В настройках публикации базы на веб-сервере необходимо включить флажок «Публиковать стандартный интерфейс OData». После этого вы сможете получать данные из справочников и регистров ЗУП обычными HTTP-запросами. Однако для сложных расчетов (таких как получение данных расчетного листка) этот метод может потребовать слишком много запросов, поэтому создание собственного HTTP-сервиса остается более предпочтительным.

Подведение итогов

Для решения задачи ускорения обмена с 22 секунд до приемлемых значений, мы рекомендуем выполнить следующие шаги:

1. Опубликовать базу ЗУП на веб-сервере (Apache или IIS).
2. Создать HTTP-сервис в расширении ЗУП, который будет принимать табельный номер и возвращать нужные данные в формате JSON или готовую верстку в HTML.
3. В базе терминала заменить вызов COMConnector на объект HTTPСоединение.

Использование HTTPСоединение не требует инициализации сеанса каждый раз, так как веб-сервер поддерживает пул активных соединений с базой 1С. Это сократит время получения данных до 1–2 секунд, что обеспечит комфортную работу сотрудников с терминалами самообслуживания.