Механизм проверки конфигурации позволяет выявить ошибки, которые не являются критичными для функционирования прикладного решения в принципе, но наличие которых может существенно снизить скорость работы прикладного решения или даже привести к возникновению ошибок при работе в некоторых специальных режимах.
Выполнение данных проверок не является обязательным (как, например, в случае синтаксического контроля), но является желательным, например, для проверки конфигурации перед поставкой заказчику, перед выпуском тиражного решения, для проверки после массированного удаления объектов или после объединения конфигураций.
Механизм проверки конфигурации включает в себя несколько тестов. Часть этих тестов доступна и в других режимах конфигуратора, а остальные специально разработаны для этого механизма.
Рассмотрим особенности этих тестов:
Проверка логической целостности конфигурации включает в себя ряд стандартных проверок целостности прикладных объектов, которые обычно выполняются автоматически перед обновлением конфигурации базы данных.
Например проверка того, что все объекты метаданных в пределах одной ветки имеют уникальные имена.
Конфигурация на платформе 1С:Предприятие 8.1 представляет собой набор взаимосвязанных объектов. Каждый объект определяется его свойствами. Эти свойства могут содержать ссылки на другие объекты метаданных.
Ссылки бывают прямые (например, свойство справочника ОсновнаяФорма ссылается на объект метаданных Форма) или косвенные. К косвенным относятся, например, ссылки на типы, относящиеся к объекту метаданных, например СправочникСсылка.Номенклатура или ссылки на предопределенные значения объекта.
Свойства объектов метаданных можно разделить на простые и сложные. К простым, например, относятся Имя, Синоним, Тип, ОсновнаяФорма и другие. Сложными свойствами являются Форма, Макет, Интерфейс, Права, СправочнаяИнформация.
Логика работы платформы 1С:Предприятие 8.1 построена таким образом, что наличие некорректных (неразрешимых) ссылок в простых свойствах в режиме 1С:Предприятие не допускается. При стандартных операциях редактирования, конфигуратор не позволит возникнуть таким ссылкам.
Например, нельзя удалить форму, если ссылка на нее содержится в свойстве справочника.
Впрочем, получить конфигурацию, которая такие ссылки содержит все же возможно. Например, при объединении конфигурации, если пометить к объединению только один объект метаданных и не помечать объекты, на которые он ссылается. При этом будет выдано предупреждение, но его можно игнорировать и выполнить объединение. Подобное поведение реализовано для облегчения процесса объединения конфигураций. Предполагается, что после объединения разработчик вручную поправит неразрешимые ссылки. Обязательная проверка простых свойств на корректность выполняется при обновлении конфигурации.
Сложные свойства ведут себя несколько иначе. Отслеживание всех ссылок во всех формах представляет собой слишком ресурсоемкий процесс, поэтому наличие неразрешимых ссылок в них допустимо. Допустимо в том смысле, что программа будет работать, однако ее функциональность может быть нарушена.
Например, в форме окажется поле ввода не связанное с данными или в справочной информации будет "переход в никуда".
Для поиска и исправления таких ситуаций предназначен механизм поиска некорректных ссылок. Он позволяет определить только факт наличия неразрешимых ссылок в той или иной форме. Их поиск и исправление возлагается на разработчика.
Ниже приведены некоторые рекомендации, которые могут помочь в данном процессе.
Если неразрешимые ссылки обнаружены в модуле справки, то для их локализации и исправления следует проверить работоспособность всех ссылок, находящихся в указанном модуле.
Если ссылка не работает, но существует объект, на который она ссылается - нужно скорректировать ссылку. Если объект, на который указывает ссылка, отсутствует - нужно, как минимум, очистить ссылку и, возможно, удалить соответствующий текст справки.
Если неразрешимые ссылки обнаружены в форме объекта, то для их локализации прежде всего следует проверить на непустое значение свойства формы и свойства элементов формы (например такие свойства, как Цвет, Шрифт, Рамка и т.д.). Для табличного поля следует также проверить свойства колонок и элементов управления, расположенных в колонках.
Для всех этих свойств значение в палитре свойств не должно быть пустым, т.е. должно отображаться либо какое-то конкретное значение, либо значение Авто. Все остальные случаи определяются как неразрешимые ссылки.
Для исправления такой ссылки следует либо задать для свойства необходимое значение, либо очистить значение (что приведет к установке значения Авто).
Также довольно распространенным случаем некорректных ссылок может быть неправильный перечень реквизитов объекта в свойстве формы Сохраняемые значения. Для исправления таких ссылок необходимо открыть окно настройки этого свойства, и ничего не меняя нажать ОK.
Также следует проверять связи с данными. Например, для свойств Связь по владельцу и Связь по типу нужно убедиться, что в окне формы настройки связи будет выбрано конкретное значение. Если нет - нужно заново выбрать нужное значение.
Неразрешимые ссылки также могут возникать в предопределенных элементах. Для исправления таких ссылок может оказаться достаточным установки признака модифицированности списка предопределенных элементов, и последующего сохранения объекта метаданных.
Для автоматизации поиска неразрешимых ссылок можно использовать Проверку конфигурации (команда Конфигурация - Проверка конфигурации в Конфигураторе).
Самый лучший способ борьбы с неразрешимыми ссылками - по возможности не допускать их появления.
Например, как было указано, при удалении объекта конфигуратор проверит наличие ссылок на удаляемый объект, но только в простых свойствах. Поэтому перед удалением рекомендуется провести полный поиск. Обратите внимание, что начиная с релиза 8.1.10, при выполнении команды "Поиск ссылок на объект" (и "Поиск ссылок в объекте") можно указать поиск во всех свойствах.
Механизм проверки конфигурации предоставляет расширенные возможности синтаксического контроля модулей. Они позволяют проверить работоспособность конфигурации во всех режимах, предусмотренных разработчиком. Для того, чтобы понять назначение каждого из режимов, рассмотрим подробнее особенности исполнения модулей в платформе 1С:Предприятие 8.1.
Конфигурация может исполняться в двух сеансах - клиентского приложения и внешнего соединения. Кроме этого, конфигурация может быть развернута в файловом варианте и клиент-серверном варианте. Различия режимов определяются составом объектов и их свойств. Не все объекты доступны при исполнении на сервере 1С:Предприятия и в режиме внешнего соединения.
Все модули, с точки зрения режимов исполнения, можно разделить на 5 групп. Это общие модули, модуль приложения, модуль внешнего соединения, модули хранимых объектов (обобщенное название, сюда относятся модули объектов, наборов записей) и модули форм.
Общие модули могут выполняться на клиенте, на сервере и в режиме внешнего соединения. Доступность конкретного общего модуля в каждой из этих сред определятся соответствующим свойством.
Модуль приложения всегда исполняется на клиенте.
Модуль внешнего соединения всегда исполняется в режиме внешнего соединения.
Модули хранимых объектов могут исполняться везде. Это зависит того, где был создан соответствующий объект.
Модули форм всегда исполняются только на клиенте.
Важной особенностью 1С:Предприятия 8.1 являются различия между файловым вариантом работы и клиент-серверным. В файловом варинате для всех исполняемых модулей доступен контекст как сервера так и клиента или внешнего соединения, в зависимости от типа сеанса. То есть, даже если у общего модуля в свойствах указано исполнение только на сервере, в файловом варианте работы в нем можно создавать объекты, доступные только на клиенте. Однако при развертывании данной конфигурации в режиме клиент-сервер, выполнение подобного модуля приведет к ошибке.
Для выявления подобных "тонких" случаев, механизм проверки конфигурации предоставляет проверки модулей во всех пяти вариантах среды исполнения.
Синтаксический контроль модулей в режиме эмуляции сеанса клиентского приложения в файловом варианте работы.
Синтаксический контроль модулей в режиме эмуляции сеанса внешнего соединения в файовом варианте работы.
Среди наиболее часто встречающихся ошибок при тестировании работы в режиме внешнего соединения, можно выделить следующие:
Для исправления подобных ошибок следует использовать разрешенные методы, свойства и объекты.
Для исправления подобных ошибок следует установить свойство Внешнее соединение общего модуля, либо, если вызываемая процедура используется только в режиме внешнего соединения, перенести ее в отдельный общий модуль с установленным свойством Внешнее соединение. Также, для исправления подобных ошибок, можно использовать директивы препроцессора, в явном виде указывающие контекст исполнения участка кода. Например, модули отчетов и обработок можно полностью ограничивать операторами #Если Клиент Тогда … #КонецЕсли.
Для исправления подобных ошибок в модуле внешнего соединения необходимо продублировать экспортные переменные, а также, при необходимости, процедуры их заполняющие.
Синтаксический контроль модулей в режиме эмуляции сеанса клиентского приложения в клиент-серверном варианте.
Синтаксический контроль модулей в режиме эмуляции сеанса внешнего соединения в клиент-серверном варианте.
Синтаксический контроль модулей в режиме эмуляции среды сервера 1С:Предприятия.
Среди наиболее часто встречающихся ошибок при тестировании работы на сервере 1С:Предприятия, можно выделить следующие:
Для исправления подобных ошибок следует использовать разрешенные методы, свойства и объекты.
Для исправления подобных ошибок следует установить свойство Сервер общего модуля, либо, если вызываемая процедура используется только на сервере, перенести ее в отдельный общий модуль с установленным свойством Сервер. Также, для исправления подобных ошибок, можно использовать директивы препроцессора, в явном виде указывающие контекст исполнения участка кода.
Для исправления подобных ошибок следует использовать параметры сеанса, содержащие аналогичные значения экспортных переменных модуля приложения.
Например: Переменная модуля приложений - глТекущийПользователь и ПараметрСеанса - ТекущийПользователь.
Важно учитывать, что время получения значения параметра сеанса значительно превышает время получения значения переменной модуля приложения. Поэтому, полный отказ от использования переменных модуля приложения в пользу параметров сеанса является неправильным. Следует применять комбинированный метод: - в модулях объектов следует применять только параметры сеанса, поскольку это решит проблему недоступности объектов на сервере - в модулях форм следует применять только переменные модуля приложения, поскольку здесь более важным является быстродействие кода, кроме того модуль формы заведомо не будет выполняться на сервере.
Для обеспечения работоспособности модулей в различных режимах можно использовать директивы препроцессора (такие как #Если Клиент Тогда ... #КонецЕсли).
Для того чтобы учесть отличие файлового варианта работы от клиент-серверного, можно использовать тот факт, что в клиент-серверном варианте работы для случая, например, сеанса клиентского приложения будет определен только один контекст: либо клиента, либо сервера, а в файловом варианте работы оба контекста будут определены одновременно. Ну и, наконец, следует учитывать, что контексты клиента и внешнего соединения одновременно не будут определены никогда.
В группе тестов синтаксического контроля модулей представлен также тест создания файлов поставки и обновления. В настройках поставки можно указать поставку модулей объекта без исходных текстов, однако для того чтобы воспользоваться этой возможностью, модуль не должен содержать директив препроцессора, что и проверяется этим тестом.
Представляет собой набор дополнительных (не связанных с синтаксическим контролем) тестов модулей.
Сами по себе неиспользуемые (никогда не вызываемые) процедуры и функции ошибкой не являются, однако их наличие может косвенно свидетельствовать об ошибках в логике конфигурации. В частности, с помощью этого теста можно найти потерянные, в том числе и случайно, обработчики событий элементов управления в формах.
Самой главной особенностью этого теста является то, что анализ использования выполняется в пределах модуля, где данная процедура расположена, дополнительно анализируется возможное использование процедуры в качестве обработчика какого-либо события. Процедуры и функции, которые объявлены как экспортные, никогда не считаются неиспользуемыми. Это связано с их возможным вызовом из внешнего соединения. Поэтому невозможно использовать данный тест для обнаружения потерянных обработчиков команд интерфейсов, поскольку такие обработчики должны быть объявлены как экспортные.
Следует учитывать, что в некоторых случаях определение процедуры или функции как неиспользуемой может выполняться некорректно. Это относится к случаям динамического назначения обработчиков событий при помощи объекта Действие и методов УстановитьДействие() и ПодключитьОбработчикОжидания().
Проверяется существование обработчиков, на которые ссылаются элементы управления в формах, команды в интерфейсах и элементы графических схем.
Полезность этого теста заключается в том, что в режиме 1С:Предприятие отсутствие обработчика не вызовет ошибки, - просто ничего не будет выполнено. В итоге локализация ошибки конфигурации может быть затруднена.
Пустой (ничего не исполняющий) обработчик события формально не является ошибкой, однако наличие таких обработчиков может негативно сказаться на производительности конфигурации, особенно если соответствующее событие возникает регулярно, например событие При выводе строки табличного поля.