Свой движок выгрузки конфигураций 1С в XML, часть 2: вся БСП байт в байт

В первой части я рассказывал, зачем пишу свой движок выгрузки конфигураций 1С в XML: без базы, без платформы и с тем же результатом, что у штатной выгрузки, байт в байт. Тогда счёт был скромный: внешние обработки, 18 из 208 совпадали со штатной выгрузкой, остальные движок честно не брал.

С тех пор поменялся сам масштаб. Теперь на входе не внешняя обработка, а CF конфигурации целиком, и первая конфигурация пройдена полностью:

БСП 3.1: 9 174 из 9 174 файлов совпадают со штатной выгрузкой байт в байт. Ошибок 0.

Формат выгрузки 2.20, платформа 8.3.27. Ниже — как я к этому шёл, на чём держится результат, где брать полный список свойств формата, сколько это стоит по времени и что дальше.

Как шёл

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

Рост числа совпавших файлов БСП по этапам

Самые большие скачки дали не самые сложные этапы, а самые массовые: стили, картинки и подсистемы (+1 930), объекты с табличными частями (+1 618), модули и справка (+1 595). А вот Form.xml шёл маленькими шагами в несколько заходов: в формах больше всего видов элементов и свойств, и почти каждая форма БСП приносила что-то новое. Последние формы упёрлись в идентификаторы стандартных команд полей, которые не выводятся ни из одной выгрузки: их пришлось выяснить опытом на самой платформе.

Главный принцип: честный отказ

Об этом правиле я писал и в первой части, но именно оно сделало этот путь возможным, поэтому подробнее.

Честный отказ: в XML попадает только то, что сверено со штатной выгрузкой

Движок разбирает CF по слоям: контейнер, внутри него — записи в скобочном формате {…}. Каждую запись он сопоставляет с образцом: известной формой структуры с местами для значений. Если запись совпала с образцом, она превращается в XML. Если в ней есть хоть что-то, что я ещё не сверял со штатной выгрузкой (незнакомое свойство, значение перечисления, лишний элемент списка), движок не выдаёт «почти правильный» файл. Он завершается с кодом возврата 10 и пишет, какой объект и какое место структуры он не узнал.

Отсюда два следствия:

• Ошибок 0 на каждом шаге, а не только в конце. Когда совпадало 1 689 файлов, неверных файлов тоже было ноль: всё остальное было отказами.
• Список отказов — это готовый список задач. Стенд собирает отказы по всей конфигурации и группирует их по месту. Самая частая причина — следующая задача. Когда отказов не осталось, этап закончен.

Для того, кто встраивает движок в свои скрипты, код 10 означает простое правило: получил 10 — выгружай штатно.

Где взять полный список свойств

Здесь была главная методическая проблема. В Form.xml свойство со значением по умолчанию не пишется. Поэтому, сколько форм ни выгружай, видны только те свойства, которые кто-то поменял. На БСП я узнаю всё, что встречается в БСП, но не узнаю, чего в ней нет. А в УТ или ERP оно может встретиться в первой же форме.

Полный список есть у самой платформы: это XSD-схемы формата выгрузки. Их можно получить штатными средствами, без сторонних файлов:

1. В глобальной ФабрикаXDTO нужных пакетов не видно. Поэтому на сервере собирается своя ФабрикаXDTO с пакетами http://v8.1c.ru/8.3/MDClasses (объекты метаданных) и http://v8.1c.ru/8.3/xcf/logform (формы).
2. Для каждого пространства имён вызывается ЭкспортСхемыXML, результат записывается в файл через ЗаписьDOM.

&НаСервере
Процедура ЗаписатьСхемы(Фабрика, URI, Каталог)
	// Фабрика — своя ФабрикаXDTO с пакетами MDClasses и xcf/logform
	Номер = 0;
	Для Каждого Схема Из Фабрика.ЭкспортСхемыXML(URI) Цикл
		Номер = Номер + 1;
		Схема.ОбновитьЭлементDOM();
		Запись = Новый ЗаписьXML;
		Запись.ОткрытьФайл(Каталог + "schema-" + Номер + ".xsd", "UTF-8");
		ЗаписьDOM = Новый ЗаписьDOM;
		ЗаписьDOM.Записать(Схема.ЭлементDOM, Запись);
		Запись.Закрыть();
	КонецЦикла;
КонецПроцедуры

Что получается для 8.3.27:

630 умолчаний в формах — это и есть список того, чего не видно в выгрузке. Для 8.5.1 (формат 2.21) logform даёт 940 элементов и 697 умолчаний. Удалений между версиями нет, только добавления, так что поддержка 2.21 — это надстройка над 2.20, а не переделка.

Откуда полный список свойств

По схемам я построил карту полноты: какие виды объектов, свойства, элементы форм и умолчания движок уже знает, а каких нет. Она отрезвляет. БСП пройдена целиком, но из 51 вида объектов полностью поддержано 21, частично 16, не поддержано 14. Из 40 видов элементов форм движок знает 34, из 630 умолчаний применяет 489. БСП просто не использует всё, что умеет платформа. Карта показывает, чем заниматься дальше, ещё до того, как это встретится в чьей-то конфигурации.

Как проверяю

Критерий тот же, что в первой части, только на всей конфигурации. Эталон — штатная выгрузка ibcmd config export из базы с этой конфигурацией. Движок выгружает тот же CF без базы. Потом стенд сравнивает каталоги файл в файл и раскладывает результат на четыре группы:

• совпало — файл есть в обеих выгрузках и одинаков побайтово;
• отличается — файл есть в обеих, но разный. Это ошибка движка, и здесь должен быть ноль;
• нет у движка — файл, который движок не выдал из-за отказа;
• лишнее — файл, которого нет в штатной выгрузке. Тоже ошибка, тоже ноль.

На БСП сейчас 9 174 совпало и ноль во всех остальных группах.

Чтобы не подгонять движок под одну конфигурацию, часть видов я сразу проверяю и на типовых. Например, регистры накопления на УТ 11.6: все 103 регистра, 418 файлов, ни одного отличия.

Время

Цель с самого начала была не только «так же», но и «быстрее». Замеры на БСП, одна машина, одна серия:

Полная выгрузка — 9 174 файла, 191 МБ, запись на рабочий диск. Первый прогон серии занял 11,2 с, следующие два — по 4,3 с. Это в 5,3 раза быстрее ibcmd.

Штатная выгрузка против своего движка на БСП

Отдельное наблюдение: запись в %TEMP% на системном диске в 3–4 раза медленнее, чем на рабочий диск. Те же 6 420 файлов пишутся 12–18 секунд вместо 3,2–3,8. Выгрузку на тысячи файлов меряйте на том диске, куда она пишет в работе.

Что дальше

1. Типовые: УТ, УНФ, ERP. В них есть то, чего нет в БСП: бухгалтерия (планы счетов, регистры бухгалтерии), расчёт (планы видов расчёта, регистры расчёта, перерасчёты), мелкие виды объектов и свойства уровня конфигурации.
2. Расширения (CFE).
3. Внешние обработки и отчёты (EPF/ERF) целиком, с формами: с них я начинал, теперь есть чем их закончить.
4. Формат 2.21 (8.5). По схемам это только добавления к 2.20.
5. Стенд с «мутациями». Свойства, которых нет ни в одной типовой, можно проверить только на специально собранной конфигурации: поменять свойство, выгрузить штатно, сравнить.
6. Чтение напрямую из базы, без промежуточного CF.

Когда пройду типовые, будет третья статья: время на УТ, УНФ и ERP против ibcmd.