Через служебный вход: какие вызовы БСП проверить перед обновлением 1С

Доработка типовой или расширение на продажу вызывает методы БСП. После обновления типовой часть таких вызовов перестаёт работать: метод удалили, он ушёл в служебные, у него появился обязательный параметр, а перехваченное тело изменилось. Я выписала из выгрузки УТ 11.5 «договор» БСП 3.1.11.202, то есть какие методы она объявляет программным интерфейсом, какие служебными и какие устаревшими, и проверила по нему доработки: собственный код УТ, контрольное расширение с заложенными дефектами, слепой набор и синтетический новый релиз. Через проверки платформы прогнала контрольное расширение BspDirty.

Стенд

Второго релиза БСП на стенде нет. Поэтому сравнение релизов я проверяла на синтетическом: копии БСП с пятью правками, которые обычно приносит обновление. Это оговорено в каждом месте, где речь о сравнении.

Как БСП объявляет свой интерфейс

Сначала я проверила по текстам модулей, как устроена разметка. В общих модулях БСП три верхние области:

Экспортных методов вне этих областей нет. Устаревшие методы лежат во вложенной области УстаревшиеПроцедурыИФункции внутри программного интерфейса. У 211 из них стоит и область, и слово «Устарела.» в комментарии, у 24 только область, у одного только комментарий. Замену словами «Следует использовать ...» указали у 172 устаревших методов из 236, у остальных 64 формулировка другая или замены нет.

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

Договор БСП 3.1.11.202

Команда contract собирает из выгрузки договор релиза: для каждого общего модуля БСП его экспортные методы с видом, параметрами (сколько всего, сколько обязательных), областью, отметкой «устарел», заменой из комментария и контрольной суммой тела. Тела методов в договор не попадают.

1

python bsp_contract.py contract <выгрузка> --out contract.json

contract на выгрузке УТ 11.5: сводка договора БСП 3.1.11.202

Агент сопоставил десять методов разных видов с текстом модулей: вид, параметры, область и замена совпали у всех десяти. Договор на всю УТ 11.5 строится за 9–29 с в зависимости от того, прогрет ли диск.

УТ 11.5 о самой себе

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

1

python bsp_contract.py check <выгрузка доработки> --contract contract.json --out report

Первым делом я прогнала check на самой УТ 11.5: 10 162 модуля не из БСП, 80 495 вызовов модулей БСП.

Из 3 068 устаревших вызовов 2 053 приходятся на ОбщегоНазначенияКлиентСервер.СообщитьПользователю. Для 2 645 вызовов замена в комментарии указана.

Двадцать находок по разным методам (12 из C1, 8 из C2) разобрал субагент с цитатами из кода, пять из них повторно проверил ведущий агент. По этим разборам все двадцать признаны настоящими; независимой человеческой проверки выборки не было. Первый прогон дал 4 ложные находки C4: в коде УТ обязательный аргумент пропускается запятой, вида ЕстьРеквизитОбъекта(, Метаданные...). Решение считать такой пропуск допустимым основано на наличии вызовов в типовой УТ; отдельного прогона компиляции контрольного вызова не было. Правило исправлено с учётом этой оговорки.

Прогон занимает 215 с на свободной машине и до 444 с, когда параллельно работают другие программы. Наши собственные доработки с исходниками BSL (21 каталог) находок не дали. Зато на них нашлась ложная C3: в «Нано-УТ» есть свой модуль ОтчетыСервер, имя которого совпадает с модулем БСП. Теперь в конфигурации без БСП одноимённый модуль считается своим.

Контрольное расширение: что видит платформа

Расширение BspDirty я собрала на выгрузке УТ 11.5 и записала список заложенного до первого прогона. В нём 17 рискованных вызовов и перехватов, а также ловушки: вызов в комментарии, вызов в строке, правильные вызовы программного интерфейса, пропуск аргумента запятой, локальная переменная с именем модуля БСП, свой модуль с тем же именем метода и обращение через поле структуры.

Расширение загружено в копию демобазы УТ 11.5 и применено (/LoadConfigFromFiles -Extension, /UpdateDBCfg -Extension, оба кода 0). Затем /CheckModules со всеми контекстами и -ExtendedModulesCheck и /CheckConfig с полным набором ключей, обе с -Extension BspDirty.

check на расширении BspDirty: 17 находок, код возврата 2

Проверка модулей платформы по BspDirty: три сообщения «Возможно ошибочный метод», код 101

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

Перехват несуществующего метода и разошедшуюся копию тела в 27.1 на «Нано-УТ» находила команда /CheckCanApplyConfigurationExtensions. На копии демобазы УТ 11.5 она отвечала «Ошибка формата потока» даже на базе без расширений, с ключом -Extension, без него и с -AllExtensions. Поэтому в таблице её нет.

Слепой набор

Второй набор, BspBlind, собирал отдельный субагент: 14 дефектов по правилам C1–C5 и ловушки, причём формы вызовов он придумывал сам, не читая инструмент. Список он записал в запечатанный файл до прогона. Инструмент нашёл 14 из 14, ловушки не сработали.

Синтетический релиз

Чтобы проверить сравнение релизов, я сделала копию БСП и записала заранее пять правок, какие приносит обновление: удалён метод программного интерфейса, метод перенесён в служебный, добавлен обязательный параметр, метод помечен устаревшим, изменено тело метода, который перехватывает BspDirty. Версию в копии сменила на 3.1.12.1.

1

python bsp_contract.py diff contract.json contract-new.json

diff договоров: удалённый метод, смена интерфейса, новый обязательный параметр, устаревший метод, изменённые тела

diff нашёл все пять правок за 0,6 с. Изменённых тел он показал два: второе – метод с номером версии БСП, который я поменяла вместе с релизом.

Проверка BspDirty против нового договора добавила по одной находке в C2, C3 и C4, перехват D5a теперь указывает на служебный метод, а у копии &ИзменениеИКонтроль, которая раньше совпадала с оригиналом, появилась отметка «тело не совпадает». Ошибок стало 10 вместо 7.

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

Пределы

• Второго настоящего релиза БСП на стенде нет: diff и проверка доработки против нового релиза испытаны на синтетическом релизе с пятью правками.
• Вызовы через Выполнить и ОбщегоНазначения.ОбщийМодуль("...") инструмент не видит.
• Договор охватывает общие модули БСП. Справочники, регистры и формы БСП в нём не описаны.
• У 64 устаревших методов замена записана в другой форме, и инструмент показывает их без замены.
• Пропуск обязательного аргумента запятой инструмент считает допустимым, потому что так написан работающий код УТ. Отдельно компиляцией контрольного вызова это не проверялось.
• Разбор агентами охватил 20 из 3 795 находок по УТ; это не независимая человеческая приёмка.

Что проверить у себя

1. Выгрузите типовую того релиза, на который переходите: 1cv8.exe DESIGNER /F <база> /DumpConfigToFiles <каталог>. Постройте договор: python bsp_contract.py contract <каталог> --out new.json.
2. Проверьте доработку по новому договору: python bsp_contract.py check <выгрузка расширения или каталог модулей> --contract new.json. Находки C3 и C4 проверьте по исходникам и исправьте подтверждённые ошибки до обновления: при выполнении таких вызовов возможен сбой.
3. Если есть договор текущего релиза, сравните: python bsp_contract.py diff old.json new.json. Удалённые методы и новые обязательные параметры совпадут с находками C3 и C4.
4. Пройдите C5: перехваты методов БСП, особенно &ИзменениеИКонтроль с отметкой «тело не совпадает».
5. Вызовы C1 и C2 переведите на программный интерфейс и указанные замены, когда будет время: они работают сейчас, но гарантий на следующие релизы у них нет.
6. После загрузки расширения в обновлённую базу запустите /CheckModules -ExtendedModulesCheck -Extension <имя> и /CheckCanApplyConfigurationExtensions -Extension <имя>.

Файлы к статье

Инструмент bsp-compat-27-3-tool.zip. Проверка доработки перед обновлением БСП: contract строит договор из вашей выгрузки с БСП (проверено на 3.1.11.202; для других релизов нужно сверить состав подсистемы и разметку областей), check проверяет по нему расширение, внешние обработки или всю конфигурацию, diff сравнивает два релиза и перечисляет удалённые методы, смену интерфейса, новые параметры, устаревшие методы и изменённые тела. Отчёт выходит в Markdown и JSON, а ненулевой код возврата при ошибках позволяет поставить проверку в сборку перед обновлением. Внутри README и 78 тестов, платформа 1С для работы не нужна. Распаковывайте Проводником Windows, 7-Zip или Python: unzip из Git Bash портит кириллические имена файлов. Тесты из чистой распаковки:

1

python -I -m unittest discover -s tests

Архив к статье bsp-compat-27-3-companion.zip. Сводка договора БСП 3.1.11.202 и список её 236 устаревших методов, с извлечёнными заменами у 172; отчёты проверки УТ 11.5, BspDirty, слепого набора и проверки против синтетического релиза; таблица «платформа против инструмента»; чек-лист подготовки доработки к обновлению; команды и скрипты стенда; расширенная PDF-версия статьи с полными таблицами.

Итог

БСП сама говорит, на какие методы можно опираться: программный интерфейс лежит в своей области модуля, а служебный и устаревший отделены. По этой разметке договор релиза строится из выгрузки за полминуты, и по нему видно, где доработка рискует при обновлении. Даже код самой УТ 11.5 вызывает служебный интерфейс БСП 727 раз, а устаревший 3 068.

Проверка модулей платформы нашла в контрольном расширении 3 риска из 17, только вызовы того, чего нет или что не экспортировано. Инструмент нашёл 17 из 17 и 14 из 14 на слепом наборе, а сравнение договоров нашло все пять правок синтетического релиза. Порядок перед обновлением: договор нового релиза, проверка доработки, сравнение с текущим релизом, затем загрузка в базу и проверки платформы.

Выводы относятся к одному релизу БСП 3.1.11.202 в УТ 11.5.22.77, синтетическому второму релизу и платформе 8.3.27.2130.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S