Каталог решений - Удержание СОМ-соединения между вызовами сервера

Уже много лет COM-технология "отмирает", да всё никак не отомрёт. Несмотря на всякие там кроссплатформенности и модные способы обмена.

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

Проблема известна давно: при чётком разделении клиента и сервера переменная, хранящая указатель на СОМ-сервер, не может быть сериализована, сохранена во временное хранилище, присвоена реквизиту или параметру управляемой формы. Также она не всегда корректно обрабатывается параметром сеанса и не всегда — функцией модуля повторного использования. Тем более, временные есть временные — 20 минут, а то и сброс… Предпринятые в разное время попытки, например, вот эта, уже давно неактуальны. В большинстве случаев стараются или всё сделать за один серверный вызов, если СОМ-клиент создаётся на сервере 1С, или работают с клиента 1С. Между тем, есть довольно простой способ единожды создать серверное СОМ-подключение и обращаться к нему, сколько понадобится; и этот способ не зависит от капризов релизов и тонкостей реализации платформы.

Идея простейшая: на каждое СОМ-соединение запускаем фоновое задание, в методе которого создаётся собственно соединение, а дальше идёт бесконечный цикл. В этом цикле мы ждём команды от вызывающего сеанса — я их передаю через константу, но при желании можно извратиться как угодно, хоть регистр замутить — обрабатываем эти команды, т.к. весь контекст COMObject’а у нас в рамках процедуры есть. Результаты отдаём вызывающему — я сделал через сообщения пользователю, но опять же, можно всяко. Когда соединение становится ненужным, даём команду, и фоновое задание прекращается изнутри (либо отменяем его извне, как его авторы). Также смотрим из фонового, если вызывающий сеанс закончился, то и из бесконечного цикла выходим и фоновое завершаем. Хотя, конечно, лучше завершать в явном виде, т.к. в режиме отладки, ещё и в файловой версии, такой сеанс может и заклинить, в т.ч. с утечкой памяти.

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

Итак.