Здравствуйте товарищи!

В модуле УФ 8.3 получаю COM объект на сервере.
Далее нужно использовать этот сом объект для получения данных из других процедур модуля формы.
переменные формы не работаю, экспортные тоже.
Вот нашел статью: Книга знаний: Хранение COM Объектов на Сервере ТонкогоКлиента
вроде всё понятно, берешь и пихаешь во временное хранилище.
Вот только что то не пихается.

Делаю так:

&НаСервере
Процедура ЗаполнитьВнешниеДанныеСервер(ОписаниеОшибки)
    ВнешняяБаза = ПланыОбмена.MAG.ПолучитьПодключениеКБазе(УзелОбменаСсылка,ОписаниеОшибки);
    //
    Если ВнешняяБаза = Неопределено Тогда
        Возврат;
    КонецЕсли;
    //
    АдресВнешнейБазы = ПоместитьВоВременноеХранилище(ВнешняяБаза,Новый УникальныйИдентификатор());
...
...........

Ошибка:
    
{Форма.Форма.Форма(2366)}: Ошибка при вызове метода контекста (ПоместитьВоВременноеХранилище)
    АдресВнешнейБазы = ПоместитьВоВременноеХранилище(ВнешняяБаза,Новый УникальныйИдентификатор());
по причине:
Переданное значение не может быть помещено во временное хранилище


////
Что не так?

есть подозрение, что в 8.3.Сколькототам это починили и теперь com во временное хранилище больше не уложишь. Статься про 8.2

(1) Есть даже подтверждение тому. В 8.3 нельзя положить в хранилище объект, которые не сериализуется. Были предложения возвращать такой сом-объект функцией из общего модуля с повторным использованием результата, вроде как при этом не происходит каждый раз его инициализация, но эту гипотезу надо проверять.

(2) пробовал так с ком-экселем - полная хрень происходит, он иногда куда то теряется... )

(1) баян

  АдресВнешнейБазы = ПоместитьВоВременноеХранилище(Новый Структура("ВнешняяБаза", ВнешняяБаза), Новый УникальныйИдентификатор());

можно попробовать COM-объект положить в структуру, а уже структуру - в хранилище. Но, во-первых, не факт, что сработает, а, во-вторых, это все равно временно - когда-то и это починят.

(4) требую фотофиниша!

http://forum.infostart.ru/forum86/topic118827/ разве не ?

Для интереса эксперимента закинул в структуру как писал (5), сработало. Но на сколько это продолжительно... неизвестно.

Завернул в структуру как подсказал (4) спасибо, всё ок!
Заработало!

Спасибо!
Вроде пишут живет 20 минут, если её не трогать.

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

(10) живет дольше, если передать уид объекта-привязки, емнип

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

(13) Поэтому кол-во обращений с использованием COM-объекта нужно стараться минимизировать... и стремиться к одному вызову

> Были предложения возвращать такой сом-объект функцией из общего модуля с повторным использованием результата, вроде как при этом не происходит каждый раз его инициализация, но эту гипотезу надо проверять.

Вполне работает.

(15) Это радует.

(14) Да кто бы спорил.. но не для всех задач это возможно. Пример - онлайновая синхронизация данных в двух конфигурациях. Чтобы например из подписки на событие в рабочей базе что-то писалось в подключенную. Здесь вызовов много, а инициализировать com на каждом - нереально медленно.

(17) Ну так надо в нужном случае использовать нужный инструмент. Что вы так в этот ком вцепились, как будто других средств интеграции не знаете?

(18) Вам за каждый пост в оправдание и защиту 1с деньги платят?

(19) Помню, в середине двухтысячных некоторые на форуме кричали в ответ недовольным "DCOM это правильно, 1с всё верно делает, а мультиплатформенный нативный сервер никому не нужен", прошло пара лет - и в 1с выпустили 8.1 с нативным сервером, послав нафиг виндовый DCOM. И эти же деятели начали с восторгом восхищаться мудрым решением.

(19) Нет конечно. Просто за пост. Вот и сейчас копеечка капнула - правда здорово?

А по теме - очень не хватает в 1с серверных "несериализуемых" переменных, сохраняемых между вызовами. Разумеется, при распределенном сервере это невозможно. Может быть, следовало бы создать флажок на общем модуле "фиксированный рабочий процесс" - чтобы при обращении к этому ОМ всегда выбирался один РП и соответственно можно было хранить переменные сеанса.

(22) а еще лямбда замыканий, наследования и прямой работы с диском.

Кстати, а какие средства интеграции вы можете предложить как альтернативу COM? Требования - работа онлайн и универсальность для файловой и клиент-серверной базы.

(23) Прием демагогии - доведение до абсурда

(24) прям навскидку - вызов хттп сервиса

(26) Его же надо заранее приготовить на "той" стороне, разве нет? А если база, в которую надо грузить данные, типовая?

(25) Ну ты первый страдать начал - "как бы хорошо было, если бы вдруг от дома провести подземный ход или чрез пруд выстроить каменный мост, на котором бы были по обеим сторонам лавки, и чтобы в них сидели купцы и продавали разные мелкие товары, нужные для крестьян. При этом глаза его делались чрезвычайно сладкими и лицо принимало самое довольное выражение; "

(27) кто там, что про демагогию говорил - условия на ходу задачи менять?

А если, а вот...

(29) Ну извините. Я просто забыл указать важное условие. Разумеется, для синхронизации нетленок уйма способов. Речь именно о связи с типовыми.

(28) Высказывать "хотелки" и пожелания - неотъемлемое право любого участника форума. Это же наши кухонные посиделки, разве нет?

Просто 1с рванула "в облака" и на уровень крупных компаний, совершенно забыв наши любимые ларьки и их потребности..

(31) То есть дорабатывать исходную базу, откуда ты обмен инициировать собрался, тоже нельзя?

(34) Прием демагогии - утопить в деталях

(35) Отлично!

Чисто женский прием - высказывать уточнения по ходу задачи, чтобы потом воскликнуть: "Ну и вот что ты сделал?"

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

(36) Чисто франчовый подход - "платите деньги, а мы тут накурочим в типовой чего изволите"

(37) кто там в (20) про дком пример приводил? Именно он и был! Все остальное костыли!

(38) чисто фикси-фишка - как же можно работать, когда в космосе хаос?

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

все остальное - это костыли для квадратных колес

(41) То есть дрючить сервер циклическим опросом внешнего приложения - это не костыли?

(41) А вот Serginio1 за сокеты агитирует. Где же правда? :)

(42) каким опросом? Какого приложения? Твои данные накапливаются в регистре, после чего регламентное, обнаружив, что есть данные, запихивает их все через твой любимый ком в целевую базу.
Дополнительный плюс - если целевая база развалилась или там монопольно сидит фикси с отладчиком, то изменения не теряются.

(43) я когда был молодым и зеленым то-же агитировал, и даже делал...

но когда понял две вещи, то перестал...
1. пользователей бывает много, тут и ресурсы и блокировки и сложности окружения и еще куча чего...
2. транзакционный механизм не работает, соединить корректно откат в двух базах невозможно, всегда есть момент времени когда в одной база зафиксировано а в другой нет...

для ларьков - это не страшно, но для серьезных систем уже все...

Таити, Таити. Нас и тут неплохо кормят. (цы)
Смысл тут "на кухоньке" плакаться об отсутствии того или иного функционала? Что есть, то и пользовать.

(44) Не, суть задачи в том что целевые данные должны обновляться в реальном времени, а не с каким-то интервалом

http://catalog.mista.ru/public/198766/

(47) это невозможно сделать в двух независимых транзакционных системах, о чем я написал в (45)

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

как ты думаешь почему в скуле тригеры (в общем случае) не имеют отката транзакции на свои действия?

(0) у меня работает вот такая схема:
Соединение (тип Произвольный) и ХранилищеКомпоненты (тип Строка) - реквизиты Обработки

Процедура ИнициализироватьХранилищеКомпоненты()
    
    ПодключитьсяКБазеИсточнику(ИмяСервераБД, ИмяБД);
    
КонецПроцедуры    

Функция ПодключитьсяКБазеИсточнику(ИмяСервераБД, ИмяБД) Экспорт
    
    Если ЗначениеЗаполнено(ХранилищеКомпоненты) Тогда
        Попытка
            Структура = ПолучитьИзВременногоХранилища(ХранилищеКомпоненты);
            Соединение = Структура.Объект;
            Если Не ТипЗнч(Соединение) = Тип("COMОбъект") Тогда
                Соединение = ПодключитьсяКБазеИсточнику_Непосредственно();
            КонецЕсли;
        Исключение
            Соединение = ПодключитьсяКБазеИсточнику_Непосредственно();
        КонецПопытки;            
    Иначе          
        Соединение = ПодключитьсяКБазеИсточнику_Непосредственно();
    КонецЕсли;
    
    Возврат Соединение;
    
КонецФункции

Функция ПодключитьсяКБазеИсточнику_Непосредственно()
    
    АвторизацияWindows = Ложь;
    
    СтрокаСоединения = "Srvr=""" + ИмяСервераБД + """;Ref=""" + ИмяБД + """;Usr="""+ ИмяПользователяБД + """;Pwd=""" + ПарольПользователяБД + """;";
    V83COMConnector= Новый COMОбъект("V83.COMConnector");
    Попытка
        Соединение = V83COMConnector.Connect(СтрокаСоединения);
        
        Структура = Новый Структура("Объект", Соединение);        
        ХранилищеКомпоненты = ПоместитьВоВременноеХранилище(Структура, Новый УникальныйИдентификатор);
    Исключение
        Сообщить(ОписаниеОшибки());
        Соединение = Неопределено;
    КонецПопытки;
    
    Возврат Соединение;
    
КонецФункции


(47) ты сам себя загоняешь в тупик таким подходом. В реальном времени = в одной базе. Все остальные технологии имеют недостатки не позволяющие работать в реальном времени в определенных условиях.
Веб-сервисы, HTTP-сервисы, OData, COM-Соединение - везде существенные таймауты на операции. Применимо но в определенных условиях.