Вопрос по управляемой форме как передать из клиента на сервер
1с 8.3 ут 11.1
Есть внешняяобработка в ней идет обработка Документов(заказ клиента)
В ней модуль
Параметры1 =Новый Структура(«Ключ»,ЗаказОбъект);
Форма1 = ПолучитьФорму(«Документ.ЗаказКлиента.ФормаОбъекта»,Параметры1);
Детали = ЗаполнитьОбеспечениеВУстановленномПорядке(ВыбранноеЗначение,ЗаказОбъект,Форма1);
Форму получает при передаче
<Форма.Форма.Форма(409)>: Ошибка при вызове метода контекста (ЗаполнитьОбеспечениеВУстановленномПорядке)
Детали = ЗаполнитьОбеспечениеВУстановленномПорядке(ВыбранноеЗначение,ЗаказОбъект,Форма1);
по причине:
Ошибка передачи данных между клиентом и сервером. Значение недопустимого типа.
по причине:
Ошибка преобразования данных XDTO:
Запись значения свойства ‘param’:
форма: Элемент
имя:
по причине:
Ошибка отображения типов:
Отсутствует отображение для типа ‘УправляемаяФорма’
Как я понял Основная проблема в том что я передаю Управляемую Форму на Сервер
&НаСервере
Функция ЗаполнитьОбеспечениеВУстановленномПорядке(ПорядокОбеспечения,ЗаказОбъект1,Форма1)
ЗаказОбъект = ЗаказОбъект1.ПолучитьОбъект();
ЭтаФорма1 = Форма1;
ДанныеДляОбеспечения = Документы.ЗаказКлиента.ПодготовитьДанныеДляОбеспечения(ЗаказОбъект, ЭтаФорма1, «СтрокиТовары»);
ТаблицаОбеспечения = ОбеспечениеСервер.ТаблицаОбеспечения(ДанныеДляОбеспечения, ПорядокОбеспечения);
ТекстОповещения = Документы.ЗаказКлиента.ЗаполнитьВариантОбеспечения(
Объект, ЭтаФорма1, «СтрокиТовары», ТаблицаОбеспечения, ЗаказОбъект.ПараметрыУказанияСерий, ЗависимыеРеквизиты());
РассчитатьИтоговыеПоказателиЗаказа(ЭтаФорма1);
СтруктураИтогов = Новый Структура(«РазличныеСклады, ЕстьИзЗаказов»);
ОбойтиТаблицуОбновитьЗависимыеРеквизиты(СтруктураИтогов,ЭтаФорма1);
Возврат Новый Структура(«Ошибки, Оповещение», ДанныеДляОбеспечения.Ошибки, ТекстОповещения);
Что посоветуете как можно обойти или другой вариант реализации передачи формы?
Или как можно обратиться к форме например по УникальномуИндефикатору?
Если можно напишите с командами заранее БЛАГОДАРЕН
(0) НЕ НАДО передавать УФ на сервер
Клиент и сервер это 2 в одном флаконе в исполнении 1С, не важно что оно на одном компе к примеру работает, всегда лучше считать что оно раздельно пашет и сервер это там далеко куда надо отправлять данные и получать а не передавать млин формы на сервер
Если надо передать форму то нужно использовать специальные механизмы придуманные на этот случай (ЗначениеВРеквизитФормы и РеквизитФормыВЗначение)
но лучше просто передать данные из формы а не всю форму.
помнится аналогичный геморой был, когда надо было создать новый документ в обработке и чтобы отработали все процедуры из формы.
по-моему передавал не форму, а структуру с минимальным набором реквизитов
Как передать форму на сервер
На клиенте нужно создать документ и заполнить его.
Проблема в том что заполнением занимается серверная процедура в которую передается форма этого документа.
Т.е. с клиента вызываю серверную процедуру которая создает документ, далее если там же попытаться получить форму чтобы её передать в другую процедуру получаю ошибку «Интерактивные операции недоступны».
Пошел по другому пути, возвращаю с сервера ссылку на клиент, пытаюсь по ней ПолучитьФорму выходит ошибка «метод объекта не обнаружен».
Как правильно сделать?
(2) Xershi, мне не нужно открывать форму, создал документ, заполнил, записал и забыл.
Можно поподробнее что и где делать?
P.S. платформу да, обновил до 1933.
(6) sssss_aaaaa_2011, для начала вам нужно построить атомный реактор, а потом элементарно включаете вилку в розетку 
Ну а если без шуток, то процедура довольно сложная, вызывается из формы документа, переделать-то конечно можно всё, но хочется малой кровью.
Сейчас просто мне важно понять или я не правильно что-то делаю и не могу получить что мне надо, или же это принципиально не возможно и надо искать другое решение.
В общем касаемо моей задачи. Вижу тут много без меня копий поломали
Я приводил конкретный документ который мне необходимо заполнять, приводил название типовой конфигурации, если на самом деле кому интересен код можете глянуть, его не так уж и много. не моя как говорится идея делать такое заполнение документа, пользуюсь тем что есть.
Вот как выглядит вызов из формы документа УчетРабочегоВремениРасширенныйФормы.ТабельЗаполнитьСотрудникамиОрганизации(ЭтаФорма);
ну и далее в общем модуле ТабельЗаполнитьСтрокиПоСотруднику()
На самом деле можно изменить часть процедур(ы), по тексту видно что через форму идет обращение непосредственно к объекту (Форма.Объект), но есть и обращение к реквизитам формы, которых нет у объекта.
Резюме. Писать новую свою процедуру заполнения (с выкидыванием заполнения реквизитов формы) на основании типовой я посчитал нецелесообразным, поэтому решение задачи в таком виде прекратил.
Заметки из Зазеркалья
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.11.2867.
Во время длительной серверной операции пользователь всегда хочет видеть на клиенте ход её выполнения. Для того чтобы оценить, сколько времени осталось до её завершения, или насколько быстро она выполняется. Чтобы это реализовать, необходимо каким-то образом передавать информацию с сервера на клиента. Но и раньше, и сейчас взаимодействие между клиентской и серверной частью 1С:Предприятия происходит только по инициативе клиента. Сервер 1С:Предприятия сам, по своему желанию, не может вызвать какое-либо клиентское приложение и передать ему информацию.
Однако с появлением системы взаимодействия возник ещё один способ «общения» клиентских приложений и сервера между собой. В ней сообщения могут отправляться не только интерактивно, но и программно, причём по инициативе любого из участников. Мы доработали систему взаимодействия и реализовали возможность передачи информации с сервера в клиентское приложение на её основе.
Основные возможности и сценарии
Передача информации происходит по инициативе сервера. Поскольку в качестве транспорта используется система взаимодействия, то способы адресации определяются её возможностями. Вы можете адресовать информацию либо всем клиентским приложениям, либо только тем приложениям, которые запущены перечисленными пользователями. Клиентское приложение может подписаться на сообщения сервера и программно обрабатывать их по мере появления.
В клиентское приложение вы можете передавать данные, имеющие XDTO-сериализацию. Естественно типы передаваемых данных должны быть доступны на клиенте. Вы можете использовать передачу информации с сервера в клиентское приложение в самых разных сценариях. Например:
Пример использования
Проще всего объяснить новый механизм на конкретном примере, когда длительная операция, выполняемая на сервере, состоит из нескольких этапов. По мере выполнения очередного этапа вы хотите извещать клиентское приложение об этом. Чтобы клиентское приложение некоторым образом показывало пользователю ход выполнения этой операции.
Общая схема очень простая. Вы создаёте отдельное обсуждение, в котором передаёте сообщения клиенту. Назовём такое обсуждение служебным. Клиентское приложение автоматически обрабатывает новые сообщения в этом обсуждении и выполняет нужные действия.
Дальше начинаются нюансы. Если ваша задача предполагает, что все клиентские приложения должны каким-то образом автоматически реагировать на информацию, поступающую с сервера, тогда вы можете создать единственное служебное сообщение, и добавить в состав его участников специальный идентификатор, обозначающий всех пользователей. Такой идентификатор можно получить с помощью нового типа СтандартныеПользователиСистемыВзаимодействия.ВсеПользователиПриложения. В таком обсуждении сообщения будут доставляться всем пользователям системы, и тем, которые есть сейчас, и тем, которые появятся в будущем.
Но если ваша задача состоит в том, чтобы информацию с сервера передавать именно тому приложению, которое инициировало длительную серверную операцию, то в этом случае лучше создать несколько служебных обсуждений, для каждого пользователя своё.
Разница заключается в следующем. Сервер взаимодействия удерживает соединение с каждым клиентским приложением. Когда вы отправляете сообщение в обсуждении, в котором участвуют все пользователи, сервер взаимодействия задействует все соединения с клиентскими приложениями.
Если же в обсуждении участвует один пользователь, то будет задействовано одно соединение с его клиентским приложением.
Правды ради нужно сказать, что от имени одного пользователя может быть запущено несколько приложений. Но сути дела это не меняет. Если информацию с сервера нужно передать в то приложение, которое инициировало серверную операцию, эффективнее использовать отдельные служебные обсуждения для каждого пользователя, чем «пулять» по всем клиентам в одном общем служебном обсуждении. В этом случае ресурсы сервера взаимодействия будут использоваться бережнее, а нагрузка на него будет меньше.
Итак, для каждого пользователя нужно создать своё служебное обсуждение. Это можно представить следующей схемой:
Приятным моментом является то, что сделать это нужно всего лишь один раз. Удобнее всего это делать в том месте прикладного решения, в котором создаются новые пользователи. Для идентификации обсуждения можно использовать новое свойство Ключ.
| Процедура СоздатьСлужебноеОбсуждение(КлючСлужебногоОбсуждения) Экспорт Если СистемаВзаимодействия.ПолучитьОбсуждение(КлючСлужебногоОбсуждения) = Неопределено Тогда Обсуждение = СистемаВзаимодействия.СоздатьОбсуждение(); Обсуждение.Отображаемое = Ложь; Обсуждение.Ключ = КлючСлужебногоОбсуждения; Обсуждение.Участники.Добавить(СистемаВзаимодействия.ИдентификаторТекущегоПользователя()); Обсуждение.Записать(); КонецЕсли; КонецПроцедуры Функция КлючСлужебногоОбсуждения() Экспорт Возврат «Сообщения сервера » + СистемаВзаимодействия.ИдентификаторТекущегоПользователя(); КонецФункции |
Ключ может быть любым, но важно, чтобы он был уникальным в пределах информационной базы, и каким-то образом связан с конкретным пользователем. Например, в ключе можно использовать идентификатор пользователя. На сервере этот ключ поможет определить, в какое обсуждение отправлять сообщения, а на клиенте этот ключ поможет понять, на какое обсуждение нужно подписаться.
Ещё одно новое свойство обсуждения будет вам полезно – Отображаемое. Для служебных обсуждений его лучше устанавливать в Ложь, тогда они не будут показаны в пользовательском интерфейсе.
Итак, создание служебного обсуждения это действие, которое нужно сделать один раз, при создании нового пользователя. А вот что нужно делать при каждом запуске клиентского приложения, так это подписываться на служебное обсуждение, предназначенное текущему пользователю. Для этого менеджеру системы взаимодействия мы добавили новый метод НачатьПодключениеОбработчикаНовыхСообщений():
Метод асинхронный, поэтому его запись выглядит немного громоздко. Но ничего сложного в нём нет. Всё, что он делает, это подключает вашу процедуру (ОбработкаСообщенийСервера) в качестве обработчика новых сообщений обсуждения, на которое указывает ключ, передаваемый во втором параметре.
Теперь вы можете на сервере отправить сообщение в служебное обсуждение, и приложение, подписанное на это обсуждение, автоматически его обработает.
В настоящее время в Библиотеке стандартных подсистем (БСП) реализован механизм выполнения длительных операций на сервере, который использует фоновые задания. Это позволяет распараллелить исполнение прикладного кода на сервере и освободить пользовательский сеанс.
В этом примере необходимо использовать ту же самую механику.
Длительную операцию, которая должна исполняться на сервере, нужно запустить как фоновое задание. Каждое фоновое задание исполняется в отдельном системном сеансе. В результате после того, как вы запустите фоновое задание, исполнение кода в пользовательском сеансе вернётся на клиента, и клиент будет готов к дальнейшим действиям. Например, к тому, чтобы обрабатывать сообщения, появляющиеся в служебном обсуждении.
Тут желательно учесть ещё один момент. От имени одного и того же пользователя может быть одновременно запущено несколько клиентских приложений. Все они подписаны на служебное обсуждение этого пользователя. Значит, все они отреагируют на сообщение, которое появится в этом обсуждении. А это нехорошо.
Поэтому при запуске фонового задания желательно снабдить его уникальным идентификатором, который передать в само фоновое задание, и кроме этого вернуть на клиента. Тогда клиент будет знать «свои» фоновые задания, а фоновое задание, посылая сообщение, сможет однозначно себя идентифицировать.
Запуск фонового задания может выглядеть таким образом:
Идентификатор фонового задания, возвращённый на клиента, вы можете сохранить в глобальном массиве, чтобы он был доступен процедуре, обрабатывающей новые сообщения.
А длительная операция, выполняемая на сервере, может выглядеть так:
Здесь на каждом этапе длительного алгоритма посылается сообщение в служебное обсуждение, а в конце посылается сообщение, сигнализирующее о завершении задания. В данных сообщения передаётся идентификатор этого задания, какое-либо значение, которое нужно обработать на клиенте, и способ его обработки. Способ обработки может понадобиться потому, что этот механизм вы можете использовать в разных алгоритмах своего прикладного решения. В одном алгоритме, например, нужно передвинуть полосу индикатора, а в другом – вывести надпись в форму.
И, наконец, на клиенте процедура, обрабатывающая новые сообщения, может выглядеть так:
| &НаКлиенте Процедура ОбработкаСообщенийСервера(Сообщение, ДополнительныеПараметры) Экспорт // Наше ли фоновое задание. ИндексЗадания = ИдентификаторыЗаданий.Найти(Сообщение.Данные.ИдентификаторЗадания); Если НЕ ИндексЗадания = Неопределено Тогда // Как обрабатывать это сообщение. Если Сообщение.Данные.СпособОбработки = «Индикатор» Тогда Состояние(«Выполняется обработка данных», Сообщение.Данные.Значение); ИначеЕсли Сообщение.Данные.СпособОбработки = «НеОтслеживать» Тогда ИдентификаторыЗаданий.Удалить(ИндексЗадания); КонецЕсли; КонецЕсли; КонецПроцедуры |
Сначала вы определяете, «ваше» ли это фоновое задание (его идентификатор сохранён в глобальном массиве), затем смотрите, как нужно обработать переданное значение. В одном случае, для примера, вы передвигаете индикатор, а в другом удаляете идентификатор из массива отслеживаемых заданий, потому что задание завершилось.
Заключение
Как вы видите механизм довольно гибкий. И это позволяет использовать его для самых разных задач. Приведённый пример это лишь один из сценариев, как говорится, «в лоб».
Существуют и другие, более изощрённые сценарии. Например, когда длительная операция (загрузка данных) инициируется одним из пользователей, а известить о ходе её выполнения нужно группу пользователей, которые с этими данными работают.
Другая область задач связана с тем, что информация не просто доставляется в клиентское приложение, а сервер некоторым образом «отдаёт команды» приложениям, заставляя их выполнить те или иные действия. Например, обновить итоговые данные, отображаемые в отдельном окне, или схему выполнения некоторого глобального прикладного процесса. Или корректно завершить работу клиентского приложения, если администратору системы нужно перезагрузить сервер, а пользователя нет на рабочем месте.
Поэтому после выпуска этого функционала мы с интересом познакомимся с примерами его реального использования и будем готовы рассматривать и обсуждать ваши пожелания и замечания к этому механизму.
Данные формы и оптимизация обмена с сервером
Поскольку поведение этих моделей отличается в разных версиях платформы, возьмём 8.2.19.106 и 8.3.5.1119; д ля чистоты эксперимента создадим для каждой версии совсем пустую конфигурацию и будем гонять в режиме тонкого клиента, безо всяких совместимостей, замеряя производительность с помощью штатных средств платформы.
К сожалению, разработчики платформы не дали нам возможности избирательно управлять передачей контекста формы между клиентом и сервером. Флаг «Использовать всегда» для реквизитов этих моделей вообще не играет роли, а другого и нет, и в результате вызов сервера превращается в тормоза и недопустимо высокий объём отправляемых данных.
Всякие «ХранилищеОбщихНастроек.Сохранить» или «ЗначениеВСтрокуВнутр» неприменимы на клиенте и отпадают.
Но в 8.3 нас ждёт неприятный сюрприз: 8.3.4 просто заявляет, что подобные объекты «не могут быть помещены в хранилище», а 8.3.5 громко падает с ошибкой. Скромно осмелюсь полагать, что это просто временная недоработка писателей платформы, ибо если данные можно было передавать в 8.2, то что мешает повторить достигнутое? Поэтому надеюсь, что примерно к 8.3.10 это аккуратно доделают, а не оставят как сейчас и не объявят «фичей», подогнав заумное обоснование.
Что делать? А делать сериализацию своими силами. Это даже лучше, всё под нашим контролем. Приведу кусок кода с контекстным и внеконтекстным вызовами, которые дали мне статистику.
В результате получаем адекватную передачу «ДанныеФормыКоллекция» на сервер, и опять же, избирательно, что экономит нам объёмы и время. Причём это именно полноценный объект, с которым вполне можно работать, хотя мы даже не указали сериализатору тип значения, читаемого из xml, он сам догадался.
Заметим, что объём передаваемых данных в нашем случае порождён обычной строкой, куда свернулся xml, а значит, её тоже можно чем-нибудь «ужать», и вопрос, как всегда, во времязатратах относительно выигрыша по размеру.
Однозначного рецепта нет, решать приходится по ситуации, но способ максимально облегчить обмен, поработать на сервере только с нужными моделями коллекций, и взятыми из них реальными коллекциями, у нас есть. Успеха!
Как передать ДанныеФормыЭлементКоллекции на Сервер или считать все имена ДФК?
Вопрос: Как передать ДанныеФормыЭлементКоллекции на Сервер?
Если без структуры в общем случае не обойтись, тогда
Вопрос 2: Как автоматически создать структуру по всем колонкам ДанныеФормыКоллекция?
Как программно считать все имена колонок ДанныеФормыКоллекция?
у меня получилось как-то так:
Если это УФ и ТаблицаФормы, которая программно создаётся запросом и выводится на форму, то потом считать её содержимое можно через такой вариант:
ЭтаФорма.ИмяРеквизитаТакКакВыЕгоНазвалиПриВыводеНаФорму.Выгрузить()
вы вывели на УФ вот такой процедурой какую-то таблицу созданную заранее запросом или руками:
// Делаем описание типа ТаблицаЗначений
МассивТипов = Новый Массив;
МассивТипов.Добавить(Тип(«ТаблицаЗначений»));
ОписаниеТипа = Новый ОписаниеТипов(МассивТипов);
// Создаём описание реквизита на основании этого типа
НовыеРеквизиты = Новый Массив;
НовыеРеквизиты.Добавить(
Новый РеквизитФормы(«ТабРеквизит», ОписаниеТипа)
);
// Создаём этот реквизит (с именем ТабРеквизит)
ЭтаФорма.ИзменитьРеквизиты(НовыеРеквизиты);
// Создаём элемент на форме с именем ТабНаФорме
// и связываем его с реквизитом ТабРеквизит
ТаблицаПолейВыбора = ЭтаФорма.Элементы.Добавить(«ТабНаФорме», Тип(«ТаблицаФормы»),ГруппаФормы);
ТаблицаПолейВыбора.ПутьКДанным = «ТабРеквизит»;
ТаблицаПолейВыбора.Отображение = ОтображениеТаблицы.Список;
ТаблицаПолейВыбора.УстановитьДействие(«ПриНачалеРедактирования», «ТабРеквизитПриНачалеРедактирования»);
ТаблицаПолейВыбора.УстановитьДействие(«ПередОкончаниемРедактирования», «ТабРеквизитПередОкончаниемРедактирования»);
// реквизит ТабРеквизит и соответствующий
// ему элемент формы ТабНаФорме созданы
// нами программно выше
// 1. добавляем колонки из ТабВкоде в реквизит ТабРеквизит
НовыеРеквизиты = Новый Массив;
Для Каждого Колонка Из ТабВКоде.Колонки Цикл
НовыеРеквизиты.Добавить(
Новый РеквизитФормы(
Колонка.Имя, Колонка.ТипЗначения,
«ТабРеквизит»
)
);
КонецЦикла;
// 2. добавляем колонки из ТабВКоде в элемент ТабНаФорме
Для Каждого Колонка Из ТабВКоде.Колонки Цикл
НовыйЭлемент = ЭтаФорма.Элементы.Добавить(
«ТабРеквизит» + «_» + Колонка.Имя, Тип(«ПолеФормы»), ЭтаФорма.Элементы[«ТабНаФорме»]
);
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
НовыйЭлемент.ПутьКДанным = «ТабРеквизит» + «.» + Колонка.Имя;
Если Колонка.Имя = «ВРезервеПоСпецификации» Тогда
// 3. наконец, передаём данные из ТабВКоде в ТабРеквизит