Развертка: закрываем расхождения и открываем исходники
Разработка - DevOps и автоматизация разработки
В прошлой статье я показал результаты выгрузки пяти конфигураций и пообещал вынести конвертер в отдельный продукт. В таблице тогда оставались неприятные строки: ERP загружалась с 89 отказами, ЗУП — с 19, а старая Бухгалтерия не собиралась вовсе.
Теперь эти отказы закрыты. ERP и ЗУП совпали с эталонами и при выгрузке XML, и при сравнении записей после загрузки. Собранные файлы прошли дополнительный круг через платформу.
Отдельный продукт тоже появился: Развертка / cf-unwrapper. В репозитории — библиотека на Rust, консольная утилита, тесты и инструкции для сборки. Ниже расскажу, что пришлось исправить, что именно означает результат «100%» и где проекту нужна помощь сообщества.
Что изменилось в цифрах
Сначала три строки из прошлой публикации и их нынешнее состояние:
| Конфигурация | Было при выгрузке | Стало при выгрузке | Отказов при загрузке: было → стало |
|---|---|---|---|
| ERP 2.5.22.186 | 121 701 из 121 712 | 121 712 из 121 712 | 89 → 0 |
| ЗУП 3.1.37.54 | 40 322 из 40 560 | 40 560 из 40 560 | 19 → 0 |
| БП 3.0.107.34 | 68 742 из 68 742 | 68 742 из 68 742 | 11 302 → 0 |
И полная таблица после общей регрессии:
| Конфигурация | Выгрузка: совпало файлов | Загрузка: совпало записей | Отказов загрузки |
|---|---|---|---|
| Клиент ЭДО 2.9 | 21 758 из 21 758 | 17 626 из 17 626 | 0 |
| БП 3.0.171.23 | 90 385 из 90 385 | 77 265 из 77 266* | 0 |
| БП 3.0.107.34 | 68 742 из 68 742 | 58 637 из 58 637 | 0 |
| ЗУП 3.1.37.54 | 40 560 из 40 560 | 33 966 из 33 966 | 0 |
| ERP 2.5.22.186 | 121 712 из 121 712 | 102 375 из 102 375 | 0 |
Проверки выполнены с платформой 8.5.1.1529. При выгрузке сравниваются файлы XML-выгрузки с результатом платформы. При загрузке — внутренние записи с записями файла, который платформа собрала из того же XML. Служебная запись versions со случайными GUID из этой сверки исключена: таблица не означает побайтового равенства всего .cf.
В свежей Бухгалтерии остался описанный в прошлой статье макет Reports/ПраваРолей/Макет: платформа объединяет одинаковые оформления с учетом адресов картинок в памяти. Это мешает воспроизвести ее результат побайтово. Эту строку я оставляю в таблице как есть.
Почему последние расхождения заняли столько работы
Когда совпадает больше ста тысяч файлов, оставшиеся несколько выглядят небольшой задачей. Но за одним файлом может стоять отдельный механизм платформы.
В ERP пришлось доделать диаграммы: шкалы, рамки и палитры серий. У динамических списков — восстановить роли полей своего запроса и особенности виртуальных таблиц. На длинных списках обнаружилась еще одна деталь: важно не только содержимое ServerState, но и то, как писатель разбивает его на буферы и части. Эквивалентного содержимого недостаточно для совпадения внутренней записи.
Старая Бухгалтерия потребовала учитывать возраст формата. Например, в ее формах отсутствует пространство имен схемы компоновки данных, которое конвертер раньше считал обязательным. Другие поля появляются только начиная с определенных версий. Пришлось восстановить эти границы и убрать ожидание, что все входные формы устроены как свежие.
В ЗУП оставались особенности метаданных: история данных старых записей регистров сведений, стандартный реквизит PredefinedDataName, создание справочников при вводе, свойства старых web- и HTTP-сервисов, история выбора. Это уже не большие новые типы объектов, а небольшие различия, разбросанные по выгрузке.
Принцип загрузки сохранился: если хотя бы один входной файл отвергнут, итоговый файл конфигурации не создается и существующий результат не заменяется. После исправлений все пять конфигураций собираются без отказов.
Проверка, которую нельзя заменить сравнением записей
После совпадения записей остается практический вопрос: примет ли файл сама платформа?
Для ERP и ЗУП я выполнил два одинаковых круга:
Исходный XML U94; Развертка U94; наш CF U94; база U94; XML №1
Исходный XML U94; платформа U94; эталонный CF U94; база U94; XML №2
Оба файла загружались через ibcmd, затем платформа выгружала конфигурацию в XML. Между результатами этих кругов:
- ERP — 121 712 совпавших файлов из 121 712.
- ЗУП — 40 560 из 40 560.
Если сравнить их с самым первым XML, появляются отличия: 16 файлов у ERP и 7 у ЗУП. Но они одинаковы в обоих кругах. В ERP это свойство командной панели в формах с диаграммами Ганта. В ЗУП — порядок стандартных реквизитов планов обмена и отдельные свойства управляемых форм.
То есть сама платформа меняет часть выгрузки при повторном сохранении. Без второго, эталонного круга эти изменения можно было бы ошибочно приписать конвертеру.
Поэтому «100%» здесь относится к перечисленным проверкам конкретных релизов ERP и ЗУП. Следующая версия или небольшая чужая обработка вполне может принести случай, которого еще не было в тестах.
Теперь это отдельный репозиторий
Раньше форматный движок жил внутри constructor рядом с интерфейсом и другими инструментами. Чтобы использовать только выгрузку, приходилось иметь дело со всем проектом. Теперь у Развертки свой репозиторий cf-unwrapper и две части:
cf-unwrapper
_00;^72;^72; crates/cf-unwrapper библиотека форматов
^92;^72;^72; crates/cf-unwrapper-cli консольная утилита
В библиотеке находятся контейнеры, метаданные, XML, формы, макеты и вспомогательный разбор запросов для динамических списков. CLI вызывает ту же библиотеку. Ее можно использовать и в других инструментах, не дублируя реализацию форматов.
GUI, отладчик и BSL-сервер остались в constructor. Подключение constructor к новой библиотеке — отдельная следующая работа.
Код перенесен в новый репозиторий без истории исходного проекта и без проверочных конфигураций. Для автономных проверок подготовлены синтетические тесты; CI настроен на Windows и Linux. Происхождение встроенных ресурсов описано в аудите. Исходный код объявлен под MIT; для платформенных seed/default templates происхождение и ограничения указаны отдельно.
Важная граница: таблица выше получена на исходном движке до выделения. Самостоятельный workspace прошел синтетические проверки, включая сборку пакета. Повторного прогона всех пяти типовых конфигураций уже из нового репозитория пока не было. Такой прогон будет полезной ближайшей проверкой переноса.
Как попробовать
Понадобятся Git и Rust stable. Платформа для сборки и работы самой утилиты не нужна:
git clone https://github.com/RunetX/cf-unwrapper.git
cd cf-unwrapper
cargo build --release --locked --bin cf-unwrapper
Исполняемый файл появится в target/release/: cf-unwrapper.exe на Windows, cf-unwrapper на Linux. После добавления каталога в PATH:
cf-unwrapper export 1Cv8.cf src
cf-unwrapper import src rebuilt.cf
cf-unwrapper export rebuilt.cf src-again
cf-unwrapper xml-diff src-again src 3
Для старых версий XML остался выбор формата:
cf-unwrapper export 1Cv8.cf src-2.20 --format 2.20
cf-unwrapper export 1Cv8.cf src-2.17 --format 2.17
По умолчанию используется 2.21. Также есть распаковка и сборка контейнера, дерево метаданных, просмотр модулей, поиск и создание минимальной внешней обработки. Полный список — в README и cf-unwrapper --help.
Одна деталь для скриптов: xml-diff и import-check возвращают код 0, если сравнение выполнено, даже при найденных различиях. Проверять нужно счетчики отчета. Отказы загрузки у import дают ненулевой код.
Что предлагаю делать вместе
Следующий шаг — расширять проверку за пределы моих пяти конфигураций. Для этого не обязательно писать на Rust.
Проверить свою конфигурацию. Указать релиз, платформу, режим совместимости, коммит утилиты и результат сравнения. Особенно интересны расширения, внешние обработки, старые версии и редкие свойства форм. Успешный результат тоже полезен: он показывает, где движок уже работает.
Свести ошибку к небольшому примеру. Сообщение «моя ERP не собирается» трудно превратить в тест. Одна синтетическая форма, один макет или одна конструкция запроса с тем же отказом позволяют разобраться гораздо быстрее. Рабочие конфигурации и данные клиентов выкладывать не нужно.
Доработать движок. Исправить формат, добавить regression test, проверить поведение на другой ОС или улучшить документацию. Предложения и результаты можно оставлять в issues, изменения — присылать pull request.
Хочется, чтобы Развертка стала общей библиотекой для инструментов вокруг файлов конфигураций: с проверяемыми правилами формата и небольшими тестами на найденные случаи. Теперь для этого есть отдельное место и код, который можно взять в работу.
Если попробуете на своей конфигурации — напишите, что получилось. И какой сценарий стоит развивать первым: расширения, выборочную работу с объектами или интеграцию в ваши сборочные инструменты?
Иллюстрации созданы с помощью нейросети.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
