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

см. ФоновыеЗадания

(1) А у меня внешняя обработка, с фоновым заданием можно использовать?

http://v8.1c.ru/o7/201412async/index.htm
но по-моему это все-таки не совсем то. В общем это стыдоба какая-то, что мобильное приложение которое может выполняться на 2-х АРМ ядрах способно к асинхронным вызовам, а дексктопное, которое например работает на проце с 8 ядрами - не умеет.

(2)да в общем-то тоже возможно, но нужно в каком нибудь общем серверном модуле заместить вспомогательную процедуру

(4) В принципе через модуль объекта внешней обработки я смогу запустить фоновое задание, только вот обратиться с модуля формы к процедуре модуля объекта не получается

(5) а я понял, как ее вызывать
короче, попробую так, спасибо

(2) БСП есть - см. http://catalog.mista.ru/public/525648/

(4)+ поправка: не "заместить", а разместить

(3) Спасибо, не то что мне нужно, но тож полезно, не знал про методы "Начать*"

(7) (8) Все работает, всем спасибо

(3)Стыдоба в том что вызовы к ОС теперь можно делать асинхронно, а вызовы к СОБСТВЕННОМУ серверу нельзя.

Им надо вводить директиву компиляции &НаСервереБезКонтекстаАсинхронно

плюс вызов такой процедуры обеспечить объектом ОписаниеОповещения

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

А еще надо бы потенциально долгие вызовы к ОС (получение файлов, выполнение HTTP запроса) обеспечить сообщениями прогресса, для реализации градусника.

2(11) А ХТТПЗапрос можно отправить асинхронно?
Потому что это вообще именно соль любого мобильного приложения. Слой нетворкинг работает почти всегда асинхронно. Ну и можно к своему же серверу, на котором определены ХТТП Сервисы такие отправлять. Но вопрос - они будут выполняться асинхронно? Или пока не выполнятся или не отвалятся по таймауту форма будет фризится?

(15) Ну ты ведь ХТТП-запрос будешь отправлять через ХТТП-соединение, а его метод возвращает ответ, поэтому пока код выполняется - конечно будет фриз

(15) Не надо отправлять хттп запросы с клиента.
В вебклиенте это будет адский ад с кроссдоменами.

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

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

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

(18) Тогда модная асинхронность не укладывается в эту парадигму.

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

для истинной асинхронности нужно либо держать сессию в течение всего длительного процесса - что плохо, ибо сессий ограниченное количество, либо превращать клиента в сервер, который тоже должен уметь ждать соединения. А если клиент висит на GPRS и у него соединение прыгает и IP из пула DHCP каждые три минуты новый?

а если клиент вообще за натом и в принципе не может получать соединения по своей инициативе? Короче, никак. Все правильно 1С делает.

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

(24) Кстати, а в чем проблема держать ОДНО соединение от клиента к серверу? С keep-alive и с восстановлением при необходимости. Всякие аськи так всю жизнь работали.

(26) ну, аська создавалась в те времена, когда деревья были большими, а инеты маленькими. И сейчас про нее уже далеко не все вообще помнят, что она была. А новые веяния, как я понимаю, в том чтобы запросил, получил и до свидания. Держать соединение без надобности не очень принято.

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

(28) именно так.

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

(30) Ну и сколько потенциальных клиентов у одного сервера 1с? У аськи кстати был нехилый кластер в своё время. А установка соединения тоже жрет ресурсы, кстати. И как бы не большие, чем кип-алив.
Для ниши 1с это вообще не аргумент, любой самый дохлый сервачок легко потянет десяток тысяч tcp-коннектов.

(31) в свое время физически не было столько интернет-клиентов, сколько сейчас, потому что интернет тогда стоил денег, а не копеек. А уж с учетом всех смартфонов и планшетов отличие, думаю, даже не в разы, а как бы не в десятки раз...
Что касается тонкого клиента в виде отдельного приложения, то конкретно для него, мне кажется, можно было бы сгородить механизм, о котором вы говорите. Но ведь есть еще браузеры. Мне почему-то сдается, что как раз тут основная загвоздка.

(16,17,19). А в любом нативном мобильном ioS|Android приложении к любому бэкэнд-серверу, у которого есть рестфул-апи - можно.