Отладка СКД

Меня зовут Шемякин Павел, я работаю ведущим разработчиком в компании Programming Store (сокращенно PROSTO). Мы занимаемся удаленной разработкой на 1С, Axapta и на Python. В докладе я хочу продолжить тему отладки СКД, начатую в цикле наших статей.

Почему я выбрал тему отладки СКД.

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

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

  • Есть консоль компоновки, которая доступна для всех на сайте 1С:ИТС.

  • Есть инструкция по работе с консолью в разделе методических рекомендаций ИТС – вы можете найти эту инструкцию на ИТС по ключевым словам «Отладка схем компоновки данных».

  • Также есть пример по работе с консолью в книге Хрусталевой «Разработка сложных отчетов» – он также доступен на сайте ИТС, но требует коммерческого или партнерского доступа.

• И третья банальная причина – коллеги по работе попросили меня написать инструкцию по работе с консолью компоновки данных. Поэтому я решил в докладе совместить приятное с полезным.

Что такое процесс отладки в СКД

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

В СКД тоже есть свой «черный ящик», которому мы передаем запрос с настройками, с параметрами, с отборами, а на выходе получаем измененный запрос, который выполняется самой платформой.

Но иногда, когда мы пытаемся проверить наш отчет в консоли запросов, он возвращает совсем другие данные, чем отчет СКД с аналогичным запросом. Это происходит из-за того, что мы пытаемся отладить другой «черный ящик» – запрос, который выполняется платформой, и смотрим на результат запроса, который получается на выходе. А в случае отладки в СКД нам нужно проверять правильность передаваемого запроса в зависимости от различных вариантов отчета.

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

Я в этом докладе буду делать акцент именно на эти две стрелки:

• запрос, который подается на вход СКД;

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

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

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

Еще иногда бывает, что запрос в СКД при одних настройках будет работать правильно, а при других настройках – неправильно. Это самый неприятный момент, и хорошо, если сам нашел эту ошибку – нехорошо будет, если тебе об этом скажут пользователи.

Управление «оптимизацией» запроса в СКД с помощью расширения языка запросов для СКД

Почему СКД «портит» запросы?

Когда мы в первый раз сталкиваемся с этой проблемой, нам кажется, что ошибка именно в платформе, и СКД сама «портит» запросы. На самом деле, это не так.

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

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

• И есть оптимизация неожиданная – например, когда из запроса выкидываются поля или даже таблицы. Программисты, которые в первый раз с этим сталкиваются, не ожидают такого подвоха от СКД.

• И самый плохой вариант неожиданной оптимизации – это неуправляемая неожиданная оптимизация. В этом случае запрос не просто получается некорректный, но и мы никакими настройками не можем заставить СКД выдать правильный запрос. В этом случае приходится искать какие-то другие обходные пути.

• Есть также управляемая оптимизация – ее можно назвать скорее ожидаемой. В этом случае вы производите какие-то специальные настройки и поэтому ожидаете получить корректный результат. Хотя есть также и неожиданная управляемая оптимизация – она обычно связана с ошибками в платформе.

Эти термины я, конечно, взял не из какой-то официальной документации, а просто для себя хотел классифицировать различные варианты поведения СКД. И дальше я хочу остановиться подробнее на управляемой оптимизации.

Одним из элементов управления изменением запросов СКД является расширение языка запросов для СКД. Прочитать о нем можно:

• во-первых, во встроенной справке, которая вызывается по F1 – как в конфигураторе, так и в режиме 1С:Предприятие;

• в цикле наших статей – там мы рассматриваем работу с запросами и более подробно рассматриваем различные варианты, как выглядит конструкция расширения языка запросов для СКД;

• на диске ИТС.

Расширение языка запросов для СКД – это специальные расширяющие конструкции, заключенные в фигурные скобки.

На слайде можно увидеть три примера, как выглядит эта конструкция в фигурных скобках:

• в первом примере показано, как заданы необязательные условия;

• во втором – необязательная таблица;

• и в третьем примере – необязательный параметр, или правильнее это называть «связь параметров компоновки данных с параметрами виртуальной таблицы».

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

Варианты управления оптимизацией

С помощью расширения языка запросов можно указать для СКД:

• является ли какая-то таблица в запросе или условие обязательными;

• можно управлять местом применения отбора;

• можно управлять связью параметров в СКД с параметрами виртуальных таблиц в запросе.

Еще к элементам управляемой оптимизации относится флажок «Обязательное» в диалоге редактирования колонки «Роль» для поля набора данных.

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

Управлять изменениями запроса можно также специальными «шаманскими пассами» над ним. Например, чтобы какое-то поле не выбрасывалось из запроса, нужно установить ему флажок «Обязательное», но, чтобы этот флажок установить, поле должно присутствовать в последнем пакете запроса. Однако, часто бывает так, что нужно оставить поле не в последнем пакете запроса, а в какой-то промежуточной временной таблице (СКД может выкидывать поля также и из промежуточных временных таблиц). Получается, что это поле нужно из этой временной таблицы вытаскивать до самого последнего запроса в пакете.

Недавно я узнал еще один способ решения этой проблемы, и он гораздо проще. Чтобы поле одной из временных таблиц пакета не исключалось из запроса, нужно оставить его в секции «СГРУППИРОВАТЬ», но убрать из секции «ВЫБРАТЬ». В этом случае поле из секции «СГРУППИРОВАТЬ» не исключается, а именно это часто является одной из частых проблем некорректной оптимизации.

Вот два текста запроса – здесь у нас формируется промежуточная временная таблица, и из этой временной таблицы производится выборка. Как можно заметить, во втором запросе пакета у нас выбираются только Контрагент и СуммаДокумента. Поле ЗаказПокупателя не выбирается. И СКД это поле выбросит из секции ВЫБРАТЬ, и, что самое плохое, она выбросит его из секции СГРУППИРОВАТЬ.

Рабочий запрос должен выглядеть так – мы убираем это поле из секции ВЫБРАТЬ, но оставляем его в секции СГРУППИРОВАТЬ. В этом случае оно СКД выкидываться не будет. Это такой интересный лайфхак, который нигде, естественно, в документации не рассматривается.

Расскажу еще про два важных флажка, которые могут влиять на изменение текста запроса:

• флажок «Автозаполнение» в описании набора данных – он обычно используется для заполнения полей в наборе данных, но, как оказывается, влияет не только на заполнение полей в наборе, но и также на изменение текста запроса;

• флажок «Использовать группировки если возможно», который появился в платформе 8.3.14 – про него можно прочитать в статье из нашего цикла или в статье проекта

Что мы можем проверить при отладке? И что нам нужно проверить?

• Нам нужно проверить правильность измененного запроса

• Правильность передаваемых параметров в запрос

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

Инструменты для отладки в СКД

Каким же инструментом можно отлаживать СКД? Такой инструмент называется «Консоль компоновки данных».

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

• В консоли компоновки данных мы можем также посмотреть параметры и другую дополнительную информацию – все то, что нам нужно проверить при отладке СКД.

Какими возможностями обладает консоль компоновки данных?

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

• В такой консоли можно отладить все варианты отчета.

• Можно заполнить пользовательские настройки, которые консоль может взять прямо из схемы.

• В каких-то консолях можно вызвать конструктор компоновки данных и «на лету» внести какие-то изменения в схему – проверить, как они работают.

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

На слайде выше перечислено четыре инструмента, с помощью которых можно отлаживать СКД. Тремя из них я пользовался, поэтому коротко о них расскажу.

Консоль компоновки данных с сайта ИТС

Первая консоль – это «родная» консоль системы компоновки данных от фирмы «1С».

• Я упоминал ее в самом начале доклада, она расположена на диске ИТС, в общем доступе.

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

• Вообще-то она жутко неудобная – текст запроса в ней смотреть неудобно, как и все остальное тоже.

• Зато в ней можно смотреть тексты всех наборов данных.

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

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

Управляемая консоль запросов

Следующая консоль, которой я пользовался – это управляемая консоль запросов. Про нее подробно рассказал Евгений Люлюк в своем докладе.

• По интерфейсу она гораздо удобнее.

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

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

Консоль с перехватом запросов

Следующая консоль – это консоль с перехватом запросов. Ее можно скачать из публикации //infostart.ru/public/1128758/.

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

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

Сравнение инструментов для отладки СКД

На этом слайде я сделал сравнение трех рассмотренных консолей. Хочу повторить, что это сравнение актуально на апрель 2020 года – может быть, что-то здесь поменялось. Как можно видеть, больше всего плюсов здесь в «Управляемой консоли запросов».

Инструкция по работе с консолью компоновки данных

Дальше я переключусь в конфигуратор и покажу основной сценарий по работе с консолью фирмы «1С», к которой я привык.

Вот есть такой простой пример:

• здесь мы выбираем данные из регистра сведений «Цены» по определенному выбранному виду цен;

• также к этой таблице мы присоединяем остатки из регистра накопления «Остатки»;

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

Для работы схемы с консолью фирмы 1С нам нужно сохранить схему компоновки в файл.

Дальше мы переключаемся в режим «Предприятие» и открываем консоль:

• добавляем отчет и загружаем в него сохраненный файл – в поле справа у нас начинает показываться схема компоновки данных;

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

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

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

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

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

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

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

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

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

Также здесь указываются значения параметров – видно, что значение параметра ВидЦен – ссылка на справочник.

Дополнительные материалы

Напоследок хочу перечислить дополнительные материалы, которые помогут разобраться в теме отладки СКД:

• Ссылка //infostart.ru/1c/articles/1219807/ ведет на первую статью цикла наших статей по работе с запросами в СКД.

• Нюансы преобразования запроса СКД

• Использование характеристик на сайте ИТС

• Особенности работы с параметрами виртуальных таблиц

• Особенности использования отборов в системе компоновки данных

• Особенности использования системы компоновки данных

• Расширение языка запросов для СКД на ИС

• Отладка СКД в ИР

Вопросы

Поделитесь примером, когда в результате работы компоновщика макета СКД итоговый запрос работает быстрее, чем исходный.

Если у нас есть поле «Остаток», и мы это поле настройками из запроса исключаем, то потом соединение не используется, естественно, это скажется положительно на производительности. Точно так же, как и любой отбор, который пользователь выберет в запросе – этот отбор будет перенесен в текст запроса, и понятно, что запрос будет работать быстрее.

Это я назвал «оптимизацией», но это оптимизация не в терминах оптимизации производительности, это оптимизация, помогающая программисту 1С. Установка каких-то отборов, исключение лишних таблиц, исключение лишних полей. Это не оптимизация производительности.

Я хотел сказать, что какой-то глубокой оптимизации, которая кардинально меняет текст запроса – СКД такого не делает.

Какой смысл сравнения запроса из схемы и исполняемого запроса, если они никогда не будут равны, так как СКД, как минимум, добавляет представления.

Смысл в сравнении всегда есть. Если в запросе добавились только представления – это не страшно, самое главное – не упустить что-то важное в этом сравнении. Когда ты сравниваешь их наглядно, видишь, какое поле есть, какое поле после сравнения пропадает, какое соединение пропадает – это всегда помогает в разборе различных проблем.

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

Как сделать отбор по полям из разных наборов данных? Например, «Набор1.Цена = 0» и «Набор2.Остаток = 0».

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

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

Подробнее о проблеме, которую вызывает галочка «Автозаполнение» можно прочитать в цикле наших статей на Инфостарте. Там 50 страниц текста А4, я не могу подробно это рассказать.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Практика применения СКД".