СОДЕРЖАНИЕ
ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ ОБРАБОТОК
ПОВТОРНОЕ ИCПОЛЬЗОВАНИЕ ФУНКЦИОНАЛА ПРОВЕРОК ДЛЯ РАЗНЫХ РЕШЕНИЙ
Далее по тексту мы будем для краткости под «решением» понимать несамостоятельное прикладное решение, требующее для своего исполнения некоторую конфигурацию. Например: внешняя обработка, расширение, правила обмена, встраиваемая подсистема и т.д.
Обработки этой публикации тестировались на платформе 8.3.12.1685, но совместимы с более ранними версиями платформы.
Допустим, вы разработали решение для УТ 11 и выложили его на Инфостарте.
При разработке вы исходили из некоторых предположений о структуре конфигурации («в конфигурации должен быть справочник Номенклатура с такими-то реквизитами»), об активности каких-либо функциональных опций, использовали обращения к общим модулям и т.д.
Своё решение вы тестировали на некотором наборе версий конфигурации УТ 11. В других версиях или в других видах конфигураций структура метаданных может отличаться.
Вы хотите предоставить клиенту возможность самостоятельно протестировать решение перед покупкой на совместимость с его версией конфигурации. Или, например, потенциального клиента интересует, будет ли решение совместимо с УНФ 1.6.
Для этого вы подготавливаете некие правила проверки конфигурации, прикрепляете их и обработку тестирования к своей публикации (в виде бесплатных файлов).
Клиент скачивает правила и обработку тестирования, запускает обработку тестирования на своей базе (или копии базы в целях безопасности), загружает в обработку правила проверки, выполняет проверку, результаты проверки (файл Excel), если они содержат ошибки, отправляет вам.
Настоящая публикация включает обработки для создания правил проверки и тестирования конфигурации по этим правилам.
Публикация включает архив, состоящий из следующих файлов:
1. Обработка «Редактор правил проверки»
2. Обработка «Тестирование конфигурации»
3. Файлы функций проверки
4. Руководство пользователя обработок
1. Обработки предназначены для управляемых форм.
2. Виды метаданных, которые проверяются обработками: общий модуль, общая форма, общий макет, пакет XDTO, план обмена, константа, справочник, документ, перечисление, отчет, обработка, план видов характеристик, план счетов, регистр сведений, регистр накопления, регистр бухгалтерии, реквизит, измерение, ресурс, стандартный реквизит, общий реквизит, табличная часть, значение перечисления, форма, макет.
3. Механизм автоматического построения правил проверки по файлам модулей, xml-файлам форм и макетов СКД анализирует метаданные первого уровня: справочники, документы и т.д. и не анализирует метаданные следующих уровней типа «реквизит», «табличная часть» и т.д.
ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ ОБРАБОТОК
Подробно функционал обработок описан в прикреплённом к публикации руководстве пользователя.
Обработка «Редактор правил проверки» предназначена для создания правил тестирования конфигурации на совместимость с прикладным решением.
Функциональные возможности редактора правил:
- Создание правил проверки структуры конфигурации – проверки существования объектов метаданных разных уровней (справочники, реквизиты, общие модули и т.д.)
- Автоматическое построение правил по исходному коду модулей, xml-файлам форм и макетов СКД
- Добавление программных проверок (произвольный код) для метаданных разных уровней
- Загрузка функций для программных проверок из файлов
- Добавление условий выполнения проверок
- Группировка правил проверок
- Установка разных уровней важности для проверок (ошибка/предупреждение/информация)
- Выгрузка /загрузка правил проверок в файл/из файла.
Обработка «Тестирование конфигурации» предназначена для тестирования конфигурации по правилам проверки.
Функциональные возможности обработки тестирования:
- загрузка файла проверок
- формирование отчёта о результатах проверок
- выгрузка отчёта в файл Excel
Результат тестирования – табличный документ на форме обработки, в который выводятся обнаруженные ошибки, предупреждения, информационные сообщения и статистика о количестве обнаруженных проблем.
Процесс создания/тестирования по правилам проверки может выглядеть так:
1. Разработчик создаёт правила проверки:
- Выгружает тестируемое решение в файлы через конфигуратор. Например, внешнюю обработку можно выгрузить в файлы .xml (файлы обработки и её форм) и .bsl (файлы модулей)
- Загружает файлы в редактор проверок
- Редактор автоматически извлекает структуру метаданных, используемых в текстах модулей и xml-файлах решения.
- Редактор автоматически строит структуру проверки метаданных
- При необходимости разработчик дополняет структуру теми метаданными, которые не были извлечены автоматически
- При необходимости добавляет для некоторых метаданных программные проверки – пишет произвольный код или использует предопределённые функции проверки, загруженные из файлов
- При необходимости указывает для проверок их уровни важности: ошибка/предупреждение/информация.
- Сохраняет правила проверки в файл.
2. Разработчик передаёт правила проверки и обработку тестирования клиенту
Клиент запускает обработку тестирования, загружает в неё правила, запускает тестирование.
Если результаты содержат полезную информацию (ошибки, предупреждения или информационные сообщения), клиент сохраняет результаты в файл Excel и отправляет разработчику.
3. Разработчик анализирует обнаруженные проблемы и дорабатывает своё решение для совместимости с другой версией или другим видом конфигурации.
Затем разработчик вносит изменения в правила проверки, выделяя в них ветки-условия, которые будут выполняться только для определённых конфигураций.
4. Например, рассмотрим простейший случай
В конфигурациях УТ 11.4 и УНФ 1.6 есть справочник Номенклатура.
В УТ у номенклатуры есть реквизит «ВидНоменклатуры», в УНФ – «КатегорияНоменклатуры».
Изначально решение было разработано для УТ, для этой же конфигурации были подготовлены правила проверки - выполнялась проверка существование справочника Номенклатура с реквизитом ВидНоменклатуры.
Клиент протестировал его на УНФ и получил ошибку «Отсутствует реквизит ВидНоменклатуры».
Разработчик внёс изменение в решение. Теперь оно в зависимости от конфигурации использует тот или иной реквизит.
Разработчик также внёс изменение в правила проверки, теперь:
- существование справочника Номенклатура проверяется всегда
- существование реквизита КатегорияНоменклатуры проверяется только при условии, что тестирование выполняется в конфигурации УНФ
- существование реквизита ВидНоменклатуры проверяется только при условии, что тестирование выполняется в конфигурации, отличной от УНФ – в это условие попадает УТ, оно же применяется и для остальных конфигураций в предположении, что реквизит в этих конфигурациях тоже будет называться ВидНоменклатуры (например, Розница 2.2)
ПОВТОРНОЕ ИCПОЛЬЗОВАНИЕ ФУНКЦИОНАЛА ПРОВЕРОК ДЛЯ РАЗНЫХ РЕШЕНИЙ
1) ГРУППЫ ПРОВЕРОК
Редактор правил позволяет создавать, загружать и сохранять группы проверок.
Например, вы разработали «Решение 1», которое использует функционал:
- дополнительных реквизитов номенклатуры
- характеристик номенклатуры
- присоединённых файлов номенклатуры
И разработали «Решение 2», которое использует функционал:
- заказов клиентов
- дополнительных реквизитов номенклатуры
Оба решения используют функционал дополнительных реквизитов номенклатуры.
При разработке правил проверки для «Решения 1» вы можете вынести в отдельную группу правила, относящиеся к дополнительным реквизитам номенклатуры, и сохранить эту группу правил в файл.
При разработке правил проверки для «Решения 2» вы можете добавить в список правил эту группу правил.
Формат файла группы проверок аналогичен формату файла правил, поэтому его можно использовать и как самостоятельные правила.
2) ФУНКЦИИ ПРОВЕРКИ
Редактор правил позволяет задавать собственные проверки в виде произвольного программного кода.
Также с помощью программного кода задаются условия выполнения некоторой ветки дерева проверок (например, «Выполнять для конфигурации УТ» или «Выполнять для платформы версии ниже 8.3.9»).
Для повторного использования программных проверок в разных правилах редактор позволяет загружать файлы, содержащие программный код проверок.
То есть, например, разработчик может подготовить в виде отдельного файла функцию «Проверка типов», которая будет содержать код проверки типов для реквизита (ресурса, измерения и т.д.), к которому прикреплена проверка.
Эту функцию затем он может использовать в разных правилах проверки.
Файл исходного кода функции – текстовый файл, содержащий:
- назначение функции (например, только для регистров сведений)
- уровень важности (ошибка/предупреждение/информация)
- признак того, является ли код функции статичным или содержит код, который в свою очередь генерирует код проверки
- код функции
Пример статичного кода – код условия «Выполнять для конфигурации УТ», например:
Результат = Найти(Метаданные.КраткаяИнформация, "Управление торговлей") <> 0;
Этот код не зависит от контекста, неважно, в каком именно условии он применяется.
Пример кода, генерирующего код проверки – это функция проверки типа реквизита.
В зависимости от реквизита код будет разным.
Например, для реквизита «Наименование» - этот код будет проверять, является ли тип реквизита строковым.
Для реквизита «Номенклатура» - проверять, является ли тип реквизита ссылкой на справочник Номенклатура.
Подробнее про функции проверки см. в руководстве пользователя, примеры функций проверки прикреплены к публикации.
