Кэширование COM-соединения. Три способа
Разработка - Практика программирования
Предисловие
Решали ли Вы задачи интеграции на платформе 1С:Предприятие? Если да, то Вам наверняка приходилось настраивать обмен данными между информационными базами 1С:Предприятия или с другими информационными системами через COM-соединение. С ростом интенсивности использования подобного обмена начинает вставить вопрос оптимизации - сокращение времени на выполнение обмена или даже создания обмена в реальном времени.
В подобных условиях использовать COM-объект соединения становится проблематичным, ведь при каждом подключении к другой базе он полностью загружает конфигурацию. А если в качестве конфигурации выступает, скажем, "Управление производственным предприятием", где размер конфигурации давно превысил 200 МБ? Тогда время на инициализацию соединения будет значительным. А использовать COM-соединение для обмена по "тонким" каналам связи будет вообще не возможно!
В статье рассмотрим три способа кэширования COM-объекта соединения с целью оптимизации скорости подключения и обмена.
Подробнее
Для наглядного представления путей решения подобной задачи обратимся к следующей схеме:
Самым простым, но наименее универсальным является способ кэширования объекта соединения в глобальной переменной модуля формы. Такой способ подойдет, если COM-соединение используется редко в какой-либо обработке или другом объекте конфигурации. Для постоянного использования соединения этот способ вряд ли подойдет, ведь при открытии формы будет необходимо вновть инициализировать соединение, что займет значительное время из-за загрузки конфигурации подключаемой базы. Практический пример использования такого способа Вы можете посмотреть в статье "Поддержка COM-соединения. Часть №1".
В противовес первому способу по сложности предлагается кэшировать COM-соединение на отдельной машине, веб-сервере. Например, можно создать веб-сервис, который будет инициализировать соединение через COM-объект при первом обращении. Далее подключаемые к веб-сервису клиенты смогут работать с кэшированным соединением, выполняя все необходимые методы объекта. С точки зрения производительности и экономии лицензий сервера 1С:Предприятия это идеальный вариант, но его выбор обоснован только в том случае, если в дальнейшем работа с этим соединением будет интенсивным. Иначе получится, что мы поставим купим и настроим отдельную машину с веб-сервером, который будет кэшировать соединение для нескольких пользователей. А это не рационально. Статью о практической реализации такого способа кэширования COM-соединения Вы можете посмотреть здесь: "Поддержка COM-соединения. Часть №2".
Но что, если использоваться COM-соединение будет часто, но не настолько, чтобы тратиться на реализации последнего предложенного варианта, при этому использовать глобальные переменные модуля формы также не вариант - соединение должно кэшироваться не для одной формы, а для нескольких объектов (обработка, отчет, документ). Тогда более правильнее было бы использовать вариант "золотой середины" - кэшировать соединение во временном хранилище в рамках каждого отдельного сеанса, которому это соединение необходимо. Этот вариант действительно подходит для большинства возникающих подобных задач. Небольшой пример его использования продемонстрирован в статье "Поддержка COM-соединения. Часть №3. Золотая середина".
Заключение
Использование COM-соединение для интеграции прикладных решений на платформе 1С:Предприятие между собой и с другими программными продуктами позволяет решать сложнейшие задачи по созданию единой информационной системы предприятия.
Надеюсь, что статья поможет Вам найти решение по оптимизации работы COM-соединения и совершенствовании интеграции на Вашем предприятии.
См. также
Специальные предложения
Да, в рамках сеанса, но на стороне клиента. А последнее отрицательно влияет на стабильность. Мало ли какая у клиента линия связи, а COM-соединение такого ой как не любит =)
К тому же тогда необходимо регистрировать COM-объект соединения на клиентской машине.
А временное хранилище сохранит его на стороне сервера.
Кстати, для меня не явилось очевидным, что по третьему способу и регистрация COM-соединения проходит на стороне сервера...
да простят меня за оффтопик, но это заявление уже напоминает бородатый анекдот:
в сокращении:
- Гиви, вот представь, пошел ты в лес, а навстречу тебе медведь. Что будешь делать?
...
- Ну на дерево залезу.
- А нету дерева.
- Как нету дерева?? Это ведь лес!!
- Ну вот такой лес!!
...
За ответы спасибо. Вашу позицию я понял.
200 пользователей, из них у части скорость в локальной сети не блещет стабильностью. Вот тогда будете задумываться о правильной реализации.
А если в локалке 10 юзеров, то смысла кэшировать соединение вообще нету)
...имеет смысл задумываться о построении сети, а не пытаться исправить чужие огрехи???
Да, для меня это анекдот... У нас 120 пользователей одновременно. Три больших здания. Сеть проводная плюс WiFi-сегмент. Скорость стабильна. Две работающих системы. COM-соединения присутствуют. Кэшируются в переменной модуля приложения. Пока работает стабильно.
Я же сказал "Вашу позицию я понял". Спасибо!
Вот подробнее:
Вы же говорите о кэшировании любого COM-объекта, в частотности для чтения XLS. В принципе описанный подход тоже подойдет, проблем с этим не вижу. Обратите внимание на первые два способа. Думаю последний с веб-сервером будет излишним, чтобы прочитать файл XLS =)
PS в 8.2 проблем нет
Вообще, согласно документации, во временное хранилище можно помещать только те значения, которые серилизуются. COM-объект соединения (да и вообще любой COM-объект) серилизовать нельзя.
В платформе 8.2 не смотря на это можно было сохранить соединение во временное хранилище. Так сказать, недокументированные возможности платформы.
Ну а в версии 8.3 видимо это дело прикрыли.
Автор, уж извините за неграмотность, но если Вы уже используете веб-сервер, зачем Вам вообще com-соединение? Ну наваяйте в 1с свой веб-сервис с нужными методами и разом избавитесь от всех проблем с com-соединением.
Ваш метод:
1. Не кросплатформенный.
2. Отдельное шаманство в случае нескольких установленных платформ - к примеру, несколько версий 8.3
3. Ресурсоёмкость - по факту запускается полный экземпляр приложения.
4. Нестабильность com - на своём опыте познали прелесть подвисающих com-подключений
5. Лицензия потребляется на время жизни com-объекта.
Да и зачем вот это всё, если у вас же публикация: ?
Создаем общий клиентский модуль, устанавливаем Повторное использование возвращаемых значений "На время сеанса", создаем функцию, типа этой:
Функция ПолучитьСоединениеСБД(СтрокаПодключения) Экспорт
COM = Новый COMОбъект("V82c.Application");
COM.Connect(СтрокаПодключения);
COM.Visible = Ложь;
Возврат COM;
КонецФункции
И каждый раз, когда нужен COM, обращаемся к ней. Если нужно убить COM - делаем ОбновитьПовторноИспользуемыеЗначения(). Не забываем вызвать эту функцию перед завершением работы системы, а то отладка не будет отпускать сервер. ПРОФИТ :)
По сути получалось, что ждет только 1-й пользователь, пока установится соединение, остальные получали уже готовое соединение.
Просмотры 34652
Загрузки 0
Комментарии 33
Создание 11.04.13 22:20
Обновление 11.04.13 22:20
№ Публикации 182414
Рубрики Практика программирования Перенос данных из 1С7.7 в 1C8.X Внешние источники данных Интеграция с WEB
Кому
Системный администратор ,
Программист
Тип файла Нет файла
Платформа Платформа 1С v8.x (все механизмы)
Конфигурация Не имеет значения
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
Код открыт Да
|
Выгрузка электронных документов в формате ФНС 5.01
|
