1с как передать форму на сервер

Обновлено: 06.07.2024

<Источник> (обязательный). Тип - Строка. Адрес ресурса на сервере.
<ИмяВыходногоФайла> (обязательный). Тип - Строка. Имя файла на диске, в который
помещаются данные, полученные от сервера (ответ сервера).
<Заголовки> (необязательный). Тип - Строка. Заголовки, добавляемые к запросу на сервер.
Текстовые пары вида <Заголовок>:<Значение>, разделенные комбинацией ВК + ПС.
(подробнее о заголовках будет сказано ниже).
Рассмотрим параметры процедуры Получить() более подробно:

В поле ИмяВыходногоФайла указывает имя файла на диске, в который будут сохранены данные, полученные от сервере в результате запроса. Так, например, если сервер возвращает список пользователей в формате XML, то на диск в указанный файл будет сохранен XML файл со списком пользователей.

О заголовках более подробно будет сказано ниже.

Так же, при запросе к веб-серверу зачастую передаются дополнительные данные (параметры) для этого запроса. Параметры от адреса источника отделяются символом "?". Каждый параметр задается в формате <Имя_Параметры>=<Значение_Параметры>. Параметры от адреса источника отделяются символом "?". Сами же параметры отделяются друг от друга символом "&". В результате строка адреса источника может выглядеть следующим образом: getUsers.php?owner_id=263544&count=100.

Ниже приведен пример, поясняющий все выше сказанное.
Код 1C v 8.х

Все заголовки разделяются на четыре основных группы:

Поле АдресРесурса аналогично полю Источник процедуры Получить(), т.е. указывается строка с адресом запроса, идущая после имени домена и символа "/".

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

О заголовках было упомянуто выше. Напомню лишь, что для метода POST обычно указываются заголовки Content-Type и Content-Length. В качестве параметра заголовка Content-Length указывается размер файла-источника, преобразованный с помощью функции XMLСтрока().

Ниже приведен пример, поясняющий все выше сказанное.
Код 1C v 8.х

<?xml version="1.0" encoding="UTF-8"?>
<request>
<user_id>ID_Пользователя</user_id>
<post_id>ID_Материала</post_id>
<message>Текст_Комментария</message>
</request>

где:
<ID_Пользователя> - id пользователя на сайте, от имени которого добавляется комментарий;
<ID_Материала> - id материала на сайте, к которому добавляется комментарий;
<Текст_Комментария> - текст комментария.

Предположим, что нам уже известны id пользователя и материала и они хранятся в переменных user_id и post_id. Ниже приведен пример, решающий нашу задачу.
Код 1C v 8.х

Bounday можно сформировать, например, таким образом
Код 1C v 8.х

Все данные отделяются друг от друга разделителем boundary. Начинать разделитель нужно с "--":
Код

--<boundary>
Content-Disposition: form-data; name="<имя_переменной>"
<пустая_строка>
<значение_переменной>
Для отправки файла необходимо еще добавить тип и имя файла:

--<boundary>
Content-Disposition: form-data; name="<имя_переменной>"; filename="<имя_файла>"
Content-Type: <тип_файла> (например image/jpeg или text/plain)
<пустая_строка>
<данные_файла>

В конце данных нужно закрыть разделитель, добавили в конце разделителя "--", т.е. вид будет "--<boundary>--".

Итак, например, нам нужно передать на веб-сервер текстовый файл через параметр "text", его описание через параметр "desc" и id пользователя через параметр "uid", для которого будет загружен наш файл.

Предположим, что файл содержит следующий текст:
Мороз и солнце; день чудесный!
Еще ты дремлешь, друг прелестный -
Пора, красавица, проснись:
Открой сомкнуты негой взоры
Навстречу северной Авроры,
Звездою севера явись!

Описание должно содержать "Стих А.С. Пушкина", а id пользователя равно "0123456". Тогда файл должен быть сформирован следующим образом (для упрощения предположим, что bounday мы уже сформировали и он равен "ccf8111910")
Код

--ccf8111910
Content-Disposition: form-data; name="uid"

0123456
--ccf8111910
Content-Disposition: form-data; name="desc"

Стих А.С. Пушкина
--ccf8111910
Content-Disposition: form-data; name="text"; filename="stih.txt"
Content-Type: text/plain

Мороз и солнце; день чудесный!
Еще ты дремлешь, друг прелестный -
Пора, красавица, проснись:
Открой сомкнуты негой взоры
Навстречу северной Авроры,
Звездою севера явись!
--ccf8111910--

А теперь перейдем непосредственно к 1С. Пусть у нас будет форма с реквизитами "Пользователь", "Описание" и "ИмяФайла". Реализуем отправку данных, описанным выше способом
Код 1C v 8.х

Передача текстовых файлов таким способом проблем не вызывает. Сложнее дело обстоит с файлами, содержащими двоичные данные (изображения, архивы и т.п.). Все дело в том, что в 1С просто нет методов для чтение двоичных файлов в строку. Если мы делаем обмен со своим сайтом, которые сами и разрабатывали, то можно просто преобразовать файл в строку Base64 при помощи процедуры Base64Строка(), а на стороне сервера преобразовать строку Base64 обратно.
Код 1C v 8.х

А как же быть если мы загружаем файл на сторонний сервер, который принимает файл как есть без преобразование его в строку Base64(). В это случае можно пойти на хитрость. В 1С есть процедура ОбъединитьФайлы(), которая объединяет несколько файлов на диске в один результирующий файл
Код 1C v 8.х
<ИменаЧастей> (обязательный). Тип - Массив. Массив имен частей файлов, которые
требуется объединить. Объединение будет происходить в порядке, в котором заданы
имена файлов в массиве.
<ИмяРезультирующегоФайла> (обязательный). Тип - Строка. Имя файла, который будет
создан в результате объединения файлов.
Т.е. мы можем сформировать текстовый файл с запросом, объединить его с файлом(-ами), которые необходимо передать на веб-сервер и передать уже файл, получившийся в результате объединения исходных файлов. Ниже демонстрируется процесс передачи двух zip архивов на сервер с дополнительными параметрами user_id и post_id.
Код 1C v 8.х

Ну вот, вроде бы, и все, что я хотел рассказать о способах передачи файлов и данных на веб-сервер из 1С. Если что-то не понятно, что-то хотите уточнить или нашли ошибки - пишите в комментариях.
Автор: Павел

Пусть у нас есть есть документ ПриходнаяНакладная с табличной частью Состав . Для этого документа необходимо реализовать подбор номенклатур в табличную часть. Должна быть возможность переносить в документ несколько номенклатур за раз. То есть сначала пользователь подбирает номенклатуры в определенную таблицу, а затем по команде «Перенести в документ» данные из этой таблицы переносятся в табличную часть документа. При переносе в табличную часть, если номенклатура уже была добавлена ранее, нужно увеличить количество в этой строке на значение, указанное в подборе.

Рассмотрим два способа решения этой задачи: без обращения к серверу и с обращением к серверу.

Без обращения к серверу

Создадим форму списка у справочника Номенклатура не назначая ее основной. Добавим реквизит формы ПодобранныеНоменклатуры (тип ТаблицаЗначений ) и разместим соответствующий элемент формы. Для полей динамического списка ЭтоГруппа и Ссылка установим флаг ИспользоватьВсегда . Чуть позже станет понятно, для чего.

Все действия выбора будут сводиться к добавлению строки в таблицу ПодобранныеНоменклатуры элементов динамического списка. Если элемент уже был добавлен в таблицу, то увеличиваем его количество. Код обработки выбора элемента списка номенклатуры:

Форма подбора номенклатур вызывается из формы документа ПриходнаяНакладная по команде Подбор :

Когда в форме выбора необходимые номенклатуры подобраны, выполняется команда ПеренестиКлиент :

Теперь подобранные номенклатуры доступны в обработчике ОбработкаВыбора элемента формы документа:



С обращением к серверу

Отличия в реализации подбора будут в этом случае только в передаче данных в документ и, затем, обработки подобранных номенклатур в документе. Вот таким образом будет выглядеть команда передачи данных в документ из подбора:


1С 8.3 Передача Таблицы Значений с сервера на клиент


Пример 1. Передать ТЗ на клиент с сервера (через процедуру ОбщегоНазначения) в 1С 8.3:

Процедура ПередатьТаблицуЗначенийНаКлиент ( Элемент ) Экспорт

ОбщегоНазначения . ТаблицаЗначенийВМассив ( ТаблицаЗначений );

Пример 2. Передать ТЗ на клиент с сервера (через Временное хранилище) в 1С 8.3:

Процедура ПередатьТаблицуЗначенийНаКлиент ( ТаблицаЗначений ) Экспорт

АдресХранилищаСТЗ = ПоместитьВоВременноеХранилище ( ТаблицаЗначений , ЭтаФорма . УникальныйИдентификатор );
ПереносТЗ = ПолучитьИзВременногоХранилища ( АдресХранилищаСТЗ );

Пример 3. Передать ТЗ на клиент с сервера (через ЗначениеВСтрокуВнутр и ЗначениеИзСтрокиВнутр) в 1С 8.3:

&НаКлиенте
Процедура ПолучитьТаблицуНаСервере ( Команда )

ТЗ_Стр = ПолучитьТЗНаСервере (); // Получаем данные на сервере
ТаблицаЗначений = ЗначениеИзСтрокиВнутр ( ТЗ_Стр );

&НаСервере
Функция ПолучитьТЗНаСервере ( ТЗ )

Возврат ЗначениеВСтрокуВнутр ( ТЗ );

Пример 4. Передать ТЗ на клиент с сервера (через реквизит формы в 1С 8.3:

&НаСервере
Функция ПередатьТаблицуЗначенийНаКлиент ( ОбъектСсылка , ИмяТабличнойЧасти )

ОбъектЗначение = ОбъектСсылка . ПолучитьОбъект ();
ОбъектТЧ = ОбъектЗначение [ ИмяТабличнойЧасти ]. Выгрузить ();

МассивРеквизитов = Новый Массив ;
МассивСтарыхРеквизитов = Новый Массив ;
МассивКолонок = Новый Массив ;

ИдКоллекции = "РеквизитФормыТЗ" ; // Реквизит формы с типом Табл.Значений

ТаблицаФормы = РеквизитФормыВЗначение ( ИдКоллекции );

Для Каждого Колонка Из ТаблицаФормы . Колонки Цикл
МассивСтарыхРеквизитов . Добавить ( ИдКоллекции + "." + Колонка . Имя );
КонецЦикла;

Для Каждого Колонка Из ОбъектТЧ . Колонки Цикл
МассивРеквизитов . Добавить ( Новый РеквизитФормы ( Колонка . Имя , Колонка . ТипЗначения , ИдКоллекции ));
МассивКолонок . Добавить ( Колонка . Имя );
КонецЦикла;

// Добвляем новые и удаляем старые колонки
ЭтаФорма . ИзменитьРеквизиты ( МассивРеквизитов , МассивСтарыхРеквизитов );

// Помещаем значение в реквизит формы
ЗначениеВРеквизитФормы ( ОбъектТЧ , ИдКоллекции );

Пример 5. Передать ТЗ на клиент с сервера (через Массив из структур) в 1С 8.3:

// Преобразуем ТаблицуЗначений в Массив из структур.
Функция ПреобразоватьТЗвМассив ( ТЗ ) Экспорт

МассивТЗ = Новый Массив ;
Для Каждого СтрокаТЗ Из ТЗ Цикл

СтруктураТЗ = Новый Структура ;
Для Каждого ИмяКолонки Из ТЗ . Колонки Цикл
СтруктураТЗ . Вставить ( ИмяКолонки . Имя , СтрокаТЗ [ ИмяКолонки . Имя ]);
КонецЦикла;

МассивТЗ . Добавить ( СтруктураТЗ );

// Преобразуем Массив из структур в ТаблицуЗначений
Функция ПреобразоватьМассивВТЗ ( МассивТЗ ) Экспорт

ТЗ = Новый ТаблицаЗначений ;

Для Каждого ЭлементМассива Из МассивТЗ Цикл

// Колонки для таблицы значений
Если ТЗ . Колонки . Количество () = 0 Тогда
Для Каждого ЗнМассив Из ЭлементМассива Цикл
ТЗ . Колонки . Добавить ( ЗнМассив . Ключ );
КонецЦикла;
КонецЕсли;

// Заполняем таблицу значений данными
НоваяСтрока = ТЗ . Добавить ();
Для Каждого ЗнМассив Из ЭлементМассива Цикл
НоваяСтрока [ ЗнМассив . Ключ ] = ЗнМассив . Значение ;
КонецЦикла;
КонецЦикла;

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


Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере.

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

Немного базовой теории

Перед тем, как перейти к содержательной части, договоримся о некоторых ограничениях:

Далее, освежим в памяти немного теории.

Директивы, в имени которых упоминается «Клиент», устанавливают ограничение на обращение к базе данных.

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

Опережая вопрос «Для чего же директива с самым длинным названием, если она ограничивает и использование контекста форм, и обращения к базе данных?», напомню: любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.

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

Теперь про серверный вызов

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

Всё очень просто:

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

Кроме этого, передача данных между клиентом и сервером возможна только посредством серверного вызова.

Видим, что на стороне клиента у нас будут доступны процедуры и функции, написанные под двумя директивами из четырёх, а на стороне сервера – под тремя из четырёх.

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

И в этом нам помогут наши новые друзья, знакомьтесь!

Это процесс клиентской части приложения «1С:Предприятие 8». Он запускается на компьютере пользователя и сожительствует в оперативной памяти с другими процессами (38 вкладок браузера, поток аудио из социальной сети, telegram и другие). Может порождать серверный вызов.
Это процесс серверной части приложения «1С:Предприятие 8». Он существует на сервере 1С. Знает, какие клиентские сеансы в данный момент запущены, но самостоятельно не может инициировать взаимодействие с ними. Работает с клиентской частью только через полученный от неё серверный вызов. А это серверный вызов. Как было сказано выше, он порождается процессом клиентской части и призван «прислуживать» ему. Он передает запросы со стороны клиента на сторону сервера, а также занимается транспортировкой данных с клиента на сервер и обратно.

Итак, давайте рассмотрим несколько особенностей работы программного кода в «1С:Предприятие 8», написанного под разными директивами.

Действие 1. Открытие пользователем формы с данными.

В момент нажатия Пользователем кнопки открытия формы из интерфейса, происходит передача управления на Сервер. По переданным параметрам получаются необходимые для построения данные из БД и происходит формирование контекста формы, который затем отправляется на клиентскую часть. У пользователя на экране отображается запрошенная форма.

Действие 2. Получение из открытой Пользователем формы дополнительных данных из Базы данных.

После выполнения метода на сервере, весь этот «пакет» транспортируется обратно. Таким образом, форма со всеми элементами и данными дважды проходит через самое узкое место системы.

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

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

Действие 3. Обработка данных табличной части формы с получением дополнительной информации из Базы данных.

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

При таком построении программного кода происходит множественное обращение со стороны клиента на сервер – по количеству элементов цикла, запущенного на стороне клиента.

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

В данном случае количество серверных вызовов сведено к минимуму за счёт предварительной подготовки параметров.

Большое количество текущих серверных вызовов может свидетельствовать о неоптимальном программном коде.

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

Действие 4. Выполнение обработки данных.

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

Та-дам!

Для копирования у нас есть ксерокс. Но куда его поставить? На сторону клиента или сервера? Под какой директивой его разместить?

Как было озвучено ранее – любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.

Но что произойдёт, если потребность в копировании возникнет на стороне сервера? Например, для подготовки данных, передаваемых на сторону клиента, потребуется сделать копию? Напомню – процесс серверной части не имеет возможности самостоятельно инициировать клиентские вызовы.

Вроде бы результат достигнут – и с сервера, и с клиента доступно копирование. Но для того, чтобы получить копию данных, используемых на клиенте, приходится делать серверный вызов. А это опять ведет к лишней нагрузке на соединение и временным затратам.

Не углубляясь в детали, отметим, что метод, описанный под данной директивой управления, создаётся в двух копиях – и на стороне клиента, и на стороне сервера. Это позволяет выполнить необходимые действия там, где появилась потребность в них (клиент/сервер), без лишних серверных вызовов.

С точки зрения выполнения программы результат будет одинаков. Но объяснение «почему так не надо делать» – это уже совершенно другая тема…

Вместо заключения

В данной статье мы на наглядных примерах рассмотрели влияние различных директив компиляции на такое явление системы «1С:Предприятие 8», как серверный вызов. Как видно, основная причина для выбора правильной директивы – производительность транспортировки данных между клиентской и серверной частью.

Придерживайтесь при разработке следующих правил:

  • По возможности не передавайте контекст формы на сторону сервера
  • Минимизируйте количество текущих серверных вызовов
  • Длительные и ресурсоёмкие задачи запускайте на выполнение на стороне сервера (при возможности – в фоновом режиме).

Учитывайте потребность в доступности тех или иных видов данных, обоснованность передачи управления и не стесняйтесь при необходимости дробить процедуры и функции. И будет Вашему серверному вызову всегда легко, а Вы от пользователей Вашей программы получите «молчаливую благодарность»!

Так ли это важно думать об оптимизации? Тут имеет смысл вспомнить одну историю.

Программист Иван при доработке 1С на своём предприятии сделал ошибку в выборе директивы компиляции. Из-за неё длительность одного из серверных вызовов была больше возможной на полсекунды.

Пользователей, применяющих этот функционал, – 25 человек, и каждый из них за рабочий день в среднем совершает 110 таких операций. Всего впустую за рабочий месяц потрачено 28875 секунд (21 рабочий день * 25 человек * 110 операций * 0,5 секунды) = 8,02 часов.

Иван, каково тебе осознавать, что за месяц ты задолжал своему предприятию целый рабочий день?

Читайте также: