Поддержка COM-соединения. Часть №3. Золотая середина

11 апреля 2013

Файлы для загрузки:

"Рабочая" конфигурация с примером

"Служебная" конфигурация с примером

Предисловие

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

Три способа кэширования COM-соединения

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

И так, приступим.

Отличия решения

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

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

Особенности кэширования COM-соединения во временном хранилище сервера 1С:Предприятия

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

Реализация по шагам

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

Глобальный модуль в служебной конфигурации

В рабочей конфигурации через COM-соединение нам необходимо вызывать эту функцию. Для инициализации COM-объекта соединения написан следующий программный код в серверном модуле "МодульСервер" с возможностью вызова с клиентской стороны:

Текст модуля "МодульСервер" на сервере с возможностью вызова с клиента

Таким образом, у нас есть следующие процедуры и функции:

  1. "Подключить()" - создает новый объект COM-соединения.
  2. "СохранитьСоединение()" - процедура сохраняет соединение во временное хранилище.
  3. "ПолучитьСоединение()" - функция создает COM-соединение, если оно отсутствует, или получает его из временного хранилища.

В разрезе сеанса пользователя адрес COM-соединения во временном хранилище находится в параметре сеанса "АдресCOMСоединения" с типом строка. Все готово для реализации механизма кэширования соединения. 

Для тестирования создадим обработку "РаботаЧерезCOM". На ее основной форме по команде "Получить" выполняется инициализация COM-объекта соединения и выполняется глобальный метод "CurDate()" служебной конфигурации. Возвращенный результат помещается в строковой реквизит формы "Результат". При повторном выполнении команды метод "CurDate()" вызывается для уже созданного объекта соединения. Следовательно, все последующие вызовы метода из другой конфигурации будут отрабатывать значительно быстрее. Напомню, что при первой инициализации COM-соединения происходит полная загрузка служебной конфигурации, на что требуется время (при низкоскоростных каналах связи и больших конфигурациях время инициализации можем быть весьма значительным).

Думаю, что наиболее наглядной демонстрацией результатов проделанной работы будет сравнение времени выполнения первого и последующих вызовов метода "CurDate()".

Замер производительности при первом и последующих вызовов метода "CurDate()"

Как мы видим, вызов COM-соединения до его кэширования составляет 5,13 секунд. После сохранения объекта соединения во временном хранилище, обращение к COM-объекту соединения составляет всего 0,12 секунды. Такая большая разница появляется из-за отсутствия при последующих вызовах загрузки конфигурации базы, к которой мы подключаемся.

В итоге задача решена, COM-соединение кэшируется нами во временном хранилище сервера 1С:Предприятия.

Минусы и плюсы

На следующей схеме представлены минусы и плюсы предложенного механизма кэширования COM-объекта соединения.

Плюсы и минусы

В схеме приведены лишь основные плюсы и минусы данного подхода кэширования COM-соединения. Остальные положительные и отрицательные моменты вытекают из них.

Выводы

В результате мы создали достаточно надежный и более-менее универсальный механизм кэширования COM-соединения. По сравнению со способом хранения соединения на веб-сервере - мы исключили посреднеческое звено веб-сервера и, таким образом, увеличили относительную надежность системы. Однако вместо одной лицензии при кэшировании мы будем использовать то количество, сколько сеансов будут использовать подключение к другой базе. Конечно, это меньше, чем при кэшировании в глобальной переменной модуля формы, но с вариантом хранения соединения на отдельном веб-сервере никак не сравнится.

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


comments powered by Disqus