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

ПодключитьОбработчикОжидания()

работает. Но меня несколько смущает, что поскольку в процедуру, которая находится в обработчике параметры передать нельзя (а без параметров - точных адресов ответа не обойтись), то приходится параметры хранить в реквизитах формы обработки, откуда производится запрос. Поэтому, собсно и вопрос: существуют ли другие красивые варианты?

Внешняя компонента со слипом...

(1) Вряд ли получится. Клиент вряд ли захочет ставить ВК в достаточно сильнозагруженную базу :-(

(0) я бы сказал насчет микросервиса но пуканы разорвет

(2) А что её ставить-то?

(0) модно? Асинх

(3) Пощади

(0) задачу уточни
запрос к сайту это некое фоновое или это в юзер интерфейсе интерактивно?

(0) с чем работаете? Если это что-то типа APIшки, где делается запрос, на выходе токен, а по этому токену результат через какое то время, то проще рег заданиями это дело настроить и регистром для токенов.

(8) Юзер делает запрос интерактивно, а вот ответ получает ХЗ когда, но опять таки юзер. По получению ответа, запросы прекращаются...

(8)->(7)

ФЗ (насчет модности не уверен)

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

(12) Константы, справочники - еще хуже. А вот регистр - думаю. Может и правда стоит...

(13) Если между разными формами не надо обмениваться данными, то хватит и реквизитов формы. Если претят реквизиты - можно во временное хранилище поместить.

(14) У временного хранилища надо будет как-то передавать адрес :-( , а это по сути опять реквизит формы... Просто вместо нескольких строковых параметров будет один...

(14) Хотя ты прав :-) , пожалуй, я себя уже почти уговорил :-) - уже начал думать, что, дескать, пусть будет. Погляжу еще регистр с измерением Пользователь и ресурсами нужные данные, но то, что работает - вроде как работает неплохо.

(9) тогда ПодключитьОбработчикОжидания() самое простое и правильное
только параметры храни в структуре одной в одном реквизите а не куче

настроить очередь сообщений, это можно, как и сервисы на ГО

(17),(18) Ok. Спасибо за советы!!!

(15) Адресом будет УИД формы - в этом случае хранилище существует до тех пор, пока жива форма.

(0) модно - делать фоновое выполнение кода. но так даже 1с ленится делать, когда речь идёт о вебсервисах типа ЧестногоЗнака.

(20) Да. Пожалуй это лучший вариант. Спасибо.

(22) если у тебя есть форма и обработчик ожидания то нафик не надо временное хранилище

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

(0) ОбщегоНазначенияБТС.Пауза(ВремяВСек).

(25) а там в кишках ФоновоеЗадание.ОжидатьЗавершения(Секунд)
А в СП по этому дело написано:
Использование в версии:
Доступен, начиная с версии 8.1.
Не рекомендуется использовать, начиная с версии 8.3.13.
Описание изменено в версии 8.3.15.

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

(26) > Не рекомендуется использовать, начиная с версии 8.3.13
Так это потому, что они его заменили на ОжидатьЗавершенияВыполнения().
А с ним, как я понимаю, тот же самый фокус провернуть можно.
Я бы как раз на серверной паузе сабж и делал.

Эх. А если бы еще на клиента асинхронную паузу завезли, то можно было бы вообще через Ждать сделать...

(28) точно, в новой БСП там уже ОжидатьЗавершенияВыполнения )

(24) То, что выполнение всех отчетов и полнотекстовый поиск в динамических списках через фоновые идет - значит никого не смущает. А несчастный запрос к сайту в фоне сразу кластер положит.

(31) так все и начинают, сначала пауза в запросе к сайту, потом в РЗ, потом еще куда-нибудь.
И потом смотришь на количество фоновых и офигиваешь

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

(33) "тормоза запуска фоновых и регламентных при отсутствии пользователей дикие до сих пор" - проблемы файловых баз как-то мало связаны с "количестве сеансов выше тысячи".

(32) Странная аргументация. А как еще организовывать асинхронное выполнение, как не через фоновые? Если это проблема - то надо ее анализировать. Если это не проблема - то надо просто перестать офигивать. И что такое "тормоза запуска фоновых"? Все вот знают и даже на партнерке обсуждают, а я как-то проспал.

А! Дошло. Речь про "холодные старты" фоновых при отсутствии пользователей в базе? Пускай это будет моей самой большой проблемой.

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

(37) а потом в догонку кучка тикетов - шо ви таки мешаете приносить гешефт по ночам.

(38) несмотря на согласованный и трижды опубликованный график работ.

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

В 21 релизе бущ асинхронные http запросы

(41) наконец-то,давно пора,а то,все асинхронное,а то,что у всех асинхронное из коробки,у 1с синхронное.
Правда,асинхронность у 1с только на клиенте,на сервер асинхронность не завозили.

Фоновое задание прекрасно по таймауту ждет само себя.

(3) А что нет то вещай. В бСП вроде есть уже ,  но все же хочется раздирающий пуканы увидеть.

(43) + cod