Обновлено: 07.07.2024

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

Применимость

В статье рассматривается платформа 1C 8.3.5. Материал актуален и для текущих релизов платформы.

Запись во внешние источники данных в «1С:Предприятие 8»

В платформе 8.2.14 в дерево метаданных был добавлен новый объект – внешние источники данных. Назначение этого механизма – получение данных из внешних баз по отношению к 1С.

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

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

Все действия выполнялись на СУБД Microsoft SQL Server 2008 R2.

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

Эта возможность позволяет запускать хранимые процедуры на стороне SQL Server, а при их помощи обращаться к данным внешних источников, в том числе и на запись.

Разберем пример. Создадим при помощи SQL Management Studio новую базу данных с именем kursy_test. Все дальнейшие эксперименты будут выполняться на ней.

В этой базе создадим таблицу nomenklatura, для этого напишем скрипт следующего содержания:

USE [ kursy_test ]
GO
CREATE TABLE [ dbo ] . [ nomenklatura ](
[ id ] [ int ] NOT NULL ,
[ description ] [ nvarchar ]( 150 ) NOT NULL ,
[ price ] [ numeric ]( 15 , 2 ) NULL ,
CONSTRAINT [ PK_id ] PRIMARY KEY ([ id ])
)
GO

В результате выполнения будет создана таблица следующей структуры:

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

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

USE [ kursy_test ]
GO
CREATE PROCEDURE insert_nomenklatura
@id int ,
@description nvarchar ( 150 ),
@price numeric ( 15 , 2 )
AS
BEGIN
INSERT INTO [ kursy_test ] .dbo. [ nomenklatura ] ([ id ], [ description ] ,[ price ])
VALUES ( @id , @description , @price )
END
GO

Вторая процедура с именем update_nomenklatura будет выполнять обновление уже существующей в таблице записи. Чтобы ее создать, был запущен такой скрипт:

USE [ kursy_test ]
GO
CREATE PROCEDURE update_nomenklatura
@id int ,
@description nvarchar ( 150 ),
@price numeric ( 15 , 2 )
AS
BEGIN
UPDATE [ kursy_test ] .dbo. [ nomenklatura ]
SET [ description ]= @description ,[ price ]= @price
WHERE [ id ]= @id
END
GO

В Обозревателе объектов созданная таблица и две хранимые процедуры выглядят следующим образом:

Все подготовительные действия на стороне Microsoft SQL Server мы выполнили, теперь переходим в конфигуратор “1С:Предприятие 8”.

Создаем новый внешний источник данных с именем Nomenklatura. При создании новой таблицы в этом источнике данных указываем следующие параметры подключения к источнику данных:

Строку соединения укажем следующую:

Driver = ; Server =( local ); Database = kursy_test ; User Id = sa ; Password =;

При наличии пароля у пользователя sa его необходимо указать в параметре Password строки соединения.

Если все параметры подключения указаны корректно, при нажатии на кнопку ОК, откроется окно, содержащее таблицы, доступные в источнике данных:

Для увеличения нажмите на изображение.

Отмечаем галочками интересующие нас поля таблицы. При нажатии кнопки Готово во внешнем источнике данных Nomenklatura будет создана таблица dbo_nomenklatura:

Теперь переключаемся на закладку “Функции” нашего источника данных.

При помощи аналогичного мастера производим добавление двух хранимых процедур:

Получаем следующий внешний вид закладки “Функции”:

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

В форме списка на командной панели расположим кнопку “Добавить” со следующим обработчиком:

В форме объекта разместим кнопку “Сохранить”, при нажатии на которую выполняется следующий код:

&НаКлиенте
Процедура Сохранить ( Команда )
СохранитьНаСервере ();
КонецПроцедуры

&НаСервере
Процедура СохранитьНаСервере ()
Если Объект.Ссылка.Пустая () Тогда
ВнешниеИсточникиДанных.Nomenklatura.dbo_insert_nomenklatura
( Объект.id , Объект.description , Объект.price );
Иначе
ВнешниеИсточникиДанных.Nomenklatura.dbo_update_nomenklatura
( Объект.id , Объект.description , Объект.price );
КонецЕсли ;
КонецПроцедуры

В режиме предприятия форма списка выглядит следующим образом:

Форма объекта представлена ниже:

Для увеличения нажмите на изображение.

После нажатия на кнопку “Сохранить” вызывается хранимая процедура на SQL Server, в таблицу базы данных будет добавлена новая запись.

Таким образом, при помощи хранимых процедур мы реализовали запись во внешние источники данных.

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

Данные можно редактировать как программно, так и интерактивно. И для нашего примера прибегать к конфигурированию не придется.

В командных панелях и в меню “Еще” можно увидеть стандартные кнопки, такие как “Создать”, “Скопировать”, “Изменить” и т.д.

Для увеличения нажмите на изображение.

А в форме объекта появились кнопки “Записать” и “Записать и закрыть”:

Как видно, теперь работа с внешними источниками похожа на работу со справочниками, документами и т.д.

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

Если это свойство установлено в Истина, запись данных в эту таблицу средствами платформы невозможна.

Поле таблицы данных обладает теперь свойствами:

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

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

Для этого у объектов ВнешнийИсточникДанныхТаблицаНаборЗаписей и ВнешнийИсточникДанныхТаблицаОбъект были реализованы новые методы Записать() и Удалить().

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

&НаКлиенте
Процедура СоздатьПрограммно ( Команда )
СоздатьПрограммноНаСервере ();
КонецПроцедуры

В модуле объекта таблицы внешнего источника данных теперь можно задать обработчики событий, возникающих при записи, такие как ПередЗаписью(), ПриЗаписи() и т. д.:

В данной статье были рассмотрены два варианта записи данных во внешние источники данных – при помощи хранимых процедур и при помощи новых механизмов платформы 8.3.5.

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

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

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

В редакции 8.3.8, наконец, стало возможным определение того факта, что внешний источник данных находится в состоянии транзакции. Эта функциональность представлена новым методом ВнешнийИсточникДанныхМенеджер.ТранзакцияАктивна()

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

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

PDF-версия статьи для участников группы ВКонтакте

Статья в PDF-формате

Для объекта ДинамическийСписок реализовано свойство КомпоновщикНастроек, аналогичное соответствующему свойству отчетов.

В режиме совместимости с версией 8.3.2 поведение не изменилось.

Для элемента формы Кнопка реализовано свойство Параметр, доступный только в том случае, если кнопка связан с командой СоздатьПоПараметру.

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

В режиме совместимости с версией 8.3.3 поведение не изменилось.

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

В версии 8.2 основной реквизит формы типа Объект не отключался даже если функциональной опцией (любой) был отключен соответствующий объект конфигурации.
В версии 8.3 основной реквизит формы типа Объект отключался, если функциональной опцией был отключен соответствующий объект конфигурации. При этом анализировались все функциональные опции.

В предыдущих версиях «1С:Предприятия» основной реквизит типа ДинамическийСписок отключался в том случае, если функциональной опцией был отключен объект конфигурации, который указан в качестве основной таблицы динамического списка. При этом анализировались все функциональные опции.

Реализован элемент управляемой формы ДополнениеЭлементаФормы, предназначенный для отображения дополнительных свойств элементов форм.

Реализованы расширения дополнения элемента формы для отображения строки поиска, состояния просмотра, управления поиском.

Для элемента управляемой формы ТаблицаФормы реализованы предопределенные элементы СтрокаПоиска, СостояниеПросмотра, УправлениеПоиском, а также свойства ПоложениеСтрокиПоиска, ПоложениеСостоянияПросмотра, ПоложениеУправленияПоиском.

История поиска хранится в хранилище системных настроек с ключом Общее/ИсторияПоискаТаблицы/ . .

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

При установке из встроенного языка отбора, упорядочивания или группировки по полю, отсутствующего в тексте запроса, будет выдана ошибка о ненайденном поле.

Изменен список ограничений для запросов, использующихся при формировании динамического списка.

Описаны особенности упорядочивания динамического списка.

Изменено описание способов получения данных динамическим списком.

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

При невозможности преобразовать отбор динамического списка в конструкцию языка запросов, выдается ошибка.

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

На сторону клиента не передаются данные колонок динамического списка, которые помечены свойством Использовать всегда, но для которых у текущего пользователя отсутствует право Просмотр. Доступ к данным таких колонок (с помощью свойства ТекущиеДанные и метода ДанныеСтроки()) на стороне клиента невозможен.

Отборы, которые автоматически накладываются динамическим списком на стандартные поля Владелец, Родитель, Дата, Период и ЭтоГруппа, применяются средствами системы компоновки данных.

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

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

Более подробное описание указанных особенностей приведено в документации.

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

При установке из встроенного языка отбора на поле, отсутствующее в тексте запроса, отбор мог быть успешно применен или проигнорирован. При установке из встроенного языка упорядочивания или группировки по полю, отсутствующему в тексте запроса, такое поле игнорировалось.

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

Список особенностей упорядочивания динамического списка был не документирован.

Описание способов получения данных динамическим списком было другим.

Если в тексте запроса динамического списка есть поля с псевдонимами, совпадающими с именами стандартных реквизитов, используемые для формирования стандартной картинки, они использовались для формирования стандартной картинки (кроме реквизита ЭтоГруппа).

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

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

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

На сторону клиента передавались данные колонок динамического списка, которые помечены свойством Использовать всегда, но для которых у текущего пользователя отсутствовало право Просмотр. В качестве значения таких колонок выступали значения по умолчанию для соответствующего типа.

Отборы, автоматически накладываемые динамическим списком на ключевые поля и стандартные поля Владелец, Родитель, Дата, Период, ЭтоГруппа, всегда применялись путем непосредственного добавления условия в текст запроса.

В режиме совместимости с версией 8.3.7 поведение не изменилось.

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

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

Поля, имеющие несколько вариантов пути (на разных вариантах встроенного языка), доступны только на текущем варианте встроенного языка.

В режиме совместимости с версией 8.3.7 и более ранними, поведение не изменилось.

В режиме совместимости с версией 8.3.9 поведение не изменилось.

Не поддерживается передача реквизита типа ДинамическийСписок в качестве параметра метода или возвращаемого значения клиент-серверного взаимодействия.

Реализовано свойство динамического списка АвтоЗаполнениеДоступныхПолей.

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

В режиме совместимости с версией 8.3.11 поведение не изменилось.

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

Динамический список некорректно отрабатывал установку списка значений для параметра запроса.

При выполнении команды Установить стандартные настройки форм отчетов и динамических списков выполняются следующие действия:

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

В режиме совместимости с версией 8.3.12 поведение не изменилось.

При открытии форм отчетов и динамических списков, если в хранилище отсутствуют пользовательские настройки, наблюдалось следующее поведение:
Из основных настроек динамического списка и настроек варианта отчета, отмеченных как пользовательские, не удалялись элементы с недоступными и отсутствующими полями.
Из пользовательских настроек, сформированных по умолчанию, не удалялись элементы, содержащие недоступные и несуществующие поля.
Не вызывались обработчики событий ПередЗагрузкойПользовательскихНастроекНаСервере и ПриЗагрузкеПользовательскихНастроекНаСервере.
При выполнении команды Установить стандартные настройки форм отчетов и динамических списков наблюдалось следующее поведение:

Запросы в динамических списках

Область применения: управляемое приложение, мобильное приложение.

Методическая рекомендация (полезный совет)

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

1. Нужно стараться делать простые запросы для динамических списков. Для этого в первую очередь нужно оптимизировать архитектуру хранения данных, чтобы их было просто отображать в динамических списках.

Пример

В динамическом списке документов-распоряжений на отгрузку нужно вывести состояние отгрузки. Состояние зависит от остатков регистра накопления, и статусов двух документов другого типа.

НЕПРАВИЛЬНО

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

ПРАВИЛЬНО

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

2. Необходимо выбрать один из трех режимов работы динамического списка:

• Динамическое считывание данных включено (рекомендуется). Используются запросы, выбирающие записи в количестве приблизительно соответствующем количеству видимых строк в таблице;
• Динамическое считывание данных выключено, задана не виртуальная основная таблица или одна из следующих таблиц: СрезПервых, СрезПоследних, ЗадачиПоИсполнителю, КритерииОтбора, ДвижениеСубконто. Используются запросы, выбирающие по 1000 записей в буфер на сервере, по мере необходимости данные передаются на клиент. Менее эффективно, чем динамическое считывание;
• Динамическое считывание данных выключено, основная таблица не задана. Запрос выполняется «как есть». В буфере накапливаются данные, начиная с 1000 записей. Чем ближе к концу списка, тем больше записей. Можно использовать только для заведомо маленьких выборок.

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

• По которым выполняется соединение в запросе;
• На которые наложены условия в запросе;
• Выведенных в качестве быстрых отборов;
• По которым выполняется упорядочивание или предусмотрена группировка;
• По которым ожидается, что пользователь будет часто упорядочивать (группировать).

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

4. Настоятельно не рекомендуется использовать конструкции, «утяжеляющие» запрос:

• конструкции РАЗЛИЧНЫЕ и СГРУППИРОВАТЬ ПО;
• конструкции ВЫБОР в предложении ГДЕ или в условиях соединения;
• упорядочивание по полю, полученному при помощи конструкции ВЫБОР, в том числе и пользовательское.

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

Не рекомендуется выполнять соединения:

• с большим количеством реальных таблиц. Ориентироваться стоит на количество не более 4 таблиц;
• с вложенными запросами;
• с виртуальными таблицами.

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

• допустимо соединение с виртуальными таблицами СрезПоследних (СрезПервых), если регистр сведений содержит
  заведомо небольшое количество записей. Например, получение текущего курса валют по данным регистра сведений КурсыВалют;
• при обращении к виртуальной таблице будут использованы хранимые итоги регистра сведений (см. Разрешение итогов для периодических регистров сведений);
• запрос к виртуальной таблице Остатки будет преобразован платформой в простое чтение хранимой таблицы итогов без группировок (см. Эффективное обращение к виртуальной таблице «Остатки»).

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

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

5.3.2. В частности, если не удается переделать запрос динамического списка, используя виртуальные таблицы с ограничениями (см. п. 5.2), или вообще отказавшись от их использования, то вместо соединения с ними следует использовать соединения с временными таблицами.

5.3.3. Если последний запрос динамического списка выбирает данные только из ранее созданной временной таблицы, то это уже не динамический список и следует перепроектировать его запрос и, скорее всего, метаданные, используемые запросом.

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

5.5. При работе со списком под неполными правами, в которых настроены ограничения доступа к данным (RLS) к таблицам, участвующим в запросе*, также автоматически присоединяются условия ограничения доступа к данным, которые замедляют работу списка. Именно в этом режиме работы следует проверять скорость работы динамических списков.

* примечание: к тем таблицам, к которым предусмотрен RLS в конфигурации.

6. Предусмотреть оптимизацию при работе с полями составного типа

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

7. Запрос динамического списка рекомендуется менять «на лету» на более оптимальный, если это возможно.

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

8. Если применение вышеизложенных рекомендаций не возможно, либо оно не дает должного эффекта, то можно рассмотреть следующие пути оптимизации:

8.1. Отказаться от части возможностей динамического списка.

• От вывода не столь значимой информации, получение которой приводит к усложнению запроса;
• От реализованных сервисных возможностей по группировке списка.

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

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

Данный способ применим, если выполняется одно из условий:

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

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

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

Кроме того, для корректной работы динамического списка требуется явно ограничить выполнение отбора, сортировки и группировки по вспомогательным колонкам с помощью методов динамического списка УстановитьОграниченияИспользованияВГруппировке , УстановитьОграниченияИспользованияВПорядке и УстановитьОграниченияИспользованияВОтборе .

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

Однако при разработке на 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 часов.

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

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

  
• Tp link archer t2u как установить драйвера
  
• Может ли заголовок располагаться в конце страницы в ворде
  
• Как в автокаде обрезать линию
  
• Как в фотошопе разделить лист на равные части
  
• Stalker anomaly запуск программы невозможен так как на компьютере отсутствует