В версии платформы «1С:Предприятие 8.3.8» появилась возможность выгружать внешние обработки и отчеты в виде набора XML-файлов. Эта функциональность предназначена для системы 1С:EDT, но может быть использована для решения любых других задач.
С ее помощью можно настроить версионирование внешних обработок и решить многие сложности, связанные с хранением и сравнением разных версий *.epf-файлов, отслеживанием изменений.
О чем эта статья
В этой статье мы:
- Рассмотрим процедуру выгрузки внешних обработок в XML-файлы
- Подключим систему управления версиями Git
- Научимся версионировать внешние обработки и просматривать историю их изменения.
Сложности при работе с внешними обработками
Внешние обработки — это обработки, которые не включены в состав конфигурации и хранятся в виде файлов с расширением *.epf.
Во внешние обработки обычно выносят программный код, который не привязан прямо к конкретному прикладному решению или требует многократного запуска и отладки.
Версионирование обработок, входящих в состав прикладного решения, реализуется с помощью стандартного хранилища платформы, но он не позволяет работать с внешними файлами. И в ситуации, когда обработка неоднократно меняется и интенсивно используется в работе, могут возникнуть сложности:
- Не ясно, что поменялось по сравнению с прошлой версией;
- Не понятно, когда именно были выполнены изменения. Это можно узнать только из комментариев, если они есть;
- Нет возможности быстро вернуться на прошлую версию обработки, если она не была предусмотрительно скопирована и не сохранена с другим названием или в другой папке;
- По прошествии некоторого времени сложно разобраться среди множества однотипных файлов.
- Чтобы безвозвратно не потерять изменяемую логику, приходится оставлять большие участки закомментированного кода (хотя комментарии должны только пояснять работу программного кода);
Частично сложностей можно избежать, если включать обработки в состав конфигурации или расширения, подключенных к хранилищу (подключение расширения к хранилищу возможно в версии платформы 8.3.12 и старше).
При этом обработка перестает быть «внешней» и теряет одно из своих главных преимуществ: удобство быстрой доработки и отладки. Но даже в этом случае сравнение версий происходит достаточно медленно из-за особенностей внутренней структуры хранилища. Подробнее о его работе можно прочитать в статье Важные вопросы про хранилище.
Выгрузка внешних отчетов и обработок в XML
Начиная с версии 8.3.8, платформа научилась выгружать внешние отчеты и обработки в файлы формата XML, проще говоря — конвертировать файлы *.epf и *.erf в набор файлов XML и BSL.
В виде XML-файлов выгружаются формы и описание обработки, а расширение BSL используется для файлов с исходным текстом модулей.
Рисунок 1. Конвертация файлов
При такой конвертации на диск сохраняется следующий набор файлов:
- Файл с описанием обработки или отчета в формате XML.
- Файлы с описанием всех форм обработки в формате XML.
- Файлы с исходным кодом модуля формы и модуля обработки или отчета в виде BSL-файлов.
С файлами такого формата могут работать все существующие системы контроля версий.
Используем систему контроля версий
Система контроля версий — это программа, которая умеет хранить множество различных версий файлов, сравнивать их между собой, переключаться между версиями, откатывать изменения, объединять эти версии и много другое.
Такие системы рассчитаны на работу с файлами в виде исходного программного кода и воспринимают файлы платформы 1С с расширениями *.epf и *.erf как двоичные, т.е. просто как набор нулей и единиц и поэтому не умеют их переводить в «читаемый» формат.
Рисунок 2. Так видит файл с расширением*.epf сторонняя программа
Существует множество различных систем контроля версий, а одной из самых распространенных является Git.
Система Git используется в качестве инструмента версионирования и групповой разработки в среде EDT (подробнее про это было описано в статье Системы контроля версий в EDT), поэтому именно она будет рассмотрена ниже.
Приступаем к настройке
Для того, чтобы настроить версионирование файлов обработки, нам понадобятся следующие инструменты:
- Git — программа для работы с системой управления версиями
- SourceTree — визуальный клиент для работы с Git
- Araxis Merge — программа для сравнения и объединения программного кода.
Рисунок 3. Необходимые программы
Выбор именно этих программных решений не является принципиальным — в качестве визуального клиента можно использовать другое приложение, например GitHub Desktop или TortoiseGit, а Araxis Merge можно заменить программами KDiff3, WinMerge или любой другой. Цель данной статьи — продемонстрировать подход к версионированию файлов платформы «1С:Предприятие», а не показать готовое решение.
Для демонстрационного примера будет использована внешняя обработка «ЗагрузкаСпецификации.epf», расположенная в папке «c:\Обработки\». В папке «c:\Repo1C\» будет создан проект Git, в котором будет храниться история разработки.
Рисунок 4. Исходный набор файлов
Интерактивная выгрузка
Чтобы выгрузить обработку в XML вручную, нужно выполнить следующие действия:
- Открыть обработку в конфигураторе платформы версии 8.3.8 и старше
- Открыть контекстное меню обработки
- Выбрать пункт «Выгрузить в файлы» и указать нужную папку.
Рисунок 5. Интерактивная выгрузка обработки
После выгрузки в выбранной папке можно увидеть выгруженные файлы: описание обработки, формы и текст модуля формы.
Рисунок 6. Выгруженные файлы
Недостаток ручного способа состоит в том, что нужно выполнять много действий — открывать основную форму обработки, открывать меню, выбирать папку. Если обработок будет несколько, процедура выгрузки и вовсе может затянуться.
Процесс выгрузки обработки можно автоматизировать. Для этого нужно запустить конфигуратор в пакетном режиме.
Пакетный режим
Пакетный режим предполагает выполнение действий без участия пользователя, при этом конфигуратор запускается из командной строки с указанием специальных параметров.
Чтобы произвести выгрузку обработок, нужно запустить исполняемый файл 1cv8.exe с указанием ключа DumpExternalDataProcessorOrReportToFiles.
После этого ключа нужно указать следующие параметры:
- Полный путь к файлу обработки («что выгрузить»)
- Путь к папке, в которую будут выгружены xml-файлы («куда выгрузить»)
- Формат выгрузки: иерархический или линейный. При иерархическом формате файлы будут выгружены с учетом структуры элементов, при линейном — простым списком, при этом тексты модулей будут сохранены с расширением *.txt.
Выполнять такой запуск нужно из командной консоли Windows. Чтобы запустить командную консоль, нужно открыть меню «Пуск — Выполнить» (или нажать сочетание клавиш Win+R), написать«cmd» и нажать Enter.
Откроется командная строка, в которой нужно написать следующую команду (путь к исполняемому файлу 1cv8.exe может быть другим, в зависимости от установленной версии платформы):
Рисунок 7. Командная строка
После выполнения указанной команды в папку «C:\Repo1C» будут выгружены файлы, а в файле out.txt появится такая запись:
Рисунок 8. Выгрузка прошла успешно
Чтобы каждый раз не открывать командную строку и не набирать команду вручную, можно сохранить команды выгрузки в командный файл.
Командный файл
Командный файл — это текстовый файл с расширением «*.bat», который содержит последовательность команд для выполнения в системе Microsoft Windows.
Чтобы создать такой файл, нужно открыть Блокнот (или любой другой текстовый редактор: Notepad++, AkelPad), скопировать в него следующий текст и сохранить с расширением «.bat»:
SET EXT="c:\Обработки\ЗагрузкаСпецификации.epf"
SET SRC="c:\Repo1C"
SET OUT="c:\Repo1C\out.txt"
%PATH1C% DESIGNER /DumpExternalDataProcessorOrReportToFiles %SRC% %EXT% /Out %OUT%
Из-за особенностей работы командного процессора в названии обработки желательно не использовать пробелы. Также может оказаться, что при запуске bat-файла неверно распознается кодировка. В этом случае нужно пересохранить файл в OEM-866.
На изображение ниже показано, как выбрать кодировку в текстовом редакторе Notepad++.
Рисунок 9. Сохранение файла в кодировке OEM-866
После того как выгрузка файлов настроена, можно приступить к установке Git и созданию репозитория.
Создание репозитория
Для начала работы с системой Git, следует загрузить с официального сайта дистрибутив программы и установить ее на компьютер. При установке можно оставить значения всех параметров по умолчанию.
Чтобы Git мог отслеживать изменения файлов в определенной папке, нужно указать что эта папка является репозиторием. Git фиксирует изменения всех файлов, которые находятся в репозитории (если специально не указать обратное).
Наш тестовый репозиторий будет размещаться в папке, в которую мы выгружаем обработку – «c:\Repo1C».
Создать репозиторий можно через командную консоль, но проще воспользоваться программой SourceTree — ее также необходимо скачать с официального сайта и установить. При установке нужно указать адрес электронной почты (либо учетную запись Google) и пройти процедуру регистрации. Для создания репозитория нужно нажать на кнопку «Create» в главной панели SourceTree и указать полный путь к папке:
Рисунок 10. Создание репозитория в SourceTree
После создания репозитория в папке появляется скрытая директория «.git» — наличие ее означает, что Git теперь отслеживает изменения файлов в этой папке.
Поскольку в папке с:\Repo1C уже находились выгруженные файлы, Git сразу же предложит зафиксировать их в хранилище.
Чтобы изменения файлов попали в хранилище, файлы нужно проиндексировать — указать, что изменения действительно должны быть включены в новый «снимок состояния».
Рисунок 11. Помещение измененных файлов в индекс
Для фиксирования изменений нужно нажать кнопку «Закоммитить» (или сочетание клавиш Shift+Ctrl+C). Команда commit (с англ. — «совершать, фиксировать») помещает изменения файлов в служебное хранилище системы Git. Аналогичным действием в хранилище 1С является команда «Поместить в хранилище».
Рисунок 12. После заполнение комментария нужно нажать на кнопку “Закоммитить”
Попробуем теперь поменять что-то в нашей обработке и перевыгрузить файлы.
Например, после добавления в форму процедуры ПроверитьНастройкиВТаблицеДанных(),
Git снова отобразит информацию о том, что произошли изменения, и в этот раз покажет, какие именно части программного кода были изменены.
Рисунок 13. Git отображает изменения файлов обработки
Чтобы не делать коммит вручную, можно добавить команды сохранения изменений в наш командный файл:
set /P txtcommit="Введите текст комментария: "
git add .
git commit -m "%date% %time%: %txtcommit%"
Смотрим историю изменений
С помощью программы SourceTree можно увидеть историю изменений файла. Также можно «откатиться» на нужную версию файлов обработки. Для этого нужно дважды нажать на нужной строке в журнале изменений, после чего файлы в папке будут заменены на те, которые находились в ней до выбранного коммита.
Чтобы посмотреть историю изменений конкретного файла, нужно спозиционироваться на него и открыть меню «Журнал для выбранного»:
Рисунок 14. Просмотр изменений конкретного файла
Для сравнения версий файлов между собой будем использовать внешнюю утилиту сравнения Araxis Merge.
Предварительно нужно настроить SourceTree — указать, что именно Araxis нужно использовать в качестве внешнего средства сравнения.
Рисунок 15. Настройка внешней утилиты сравнения
Рисунок 16. Чтобы сравнить версии, нужно выбрать «Внешняя утилита сравнения»
В открывшемся окне программы Araxis Merge можно увидеть наглядное сравнение версий модуля формы.
Рисунок 17. Araxis Compare сравнивает версии файла
На изображении видно, что Araxis показал изменения в файлах и помог узнать, что именно происходило с программным модулем. Например, видно, что в последней версии модуля процедура ДобавитьКолонку() переименована в ДобавитьКолонкуПоТипу(), а также удалены два блока кода. Если в момент использования обработки возникли ошибки, то просматривая по шагам историю доработки, можно обнаружить момент, когда они были сделаны.
Дорабатываем командный файл
Если усовершенствовать наш командный файл и добавить в него обход всех файлов из выбранной папки, то не придется создавать его копию для каждой обработки. Достаточно будет указать в настройках (переменная EXT_FOLDER) нужную директорию, и все обработки и отчеты из нее будут выгружены в наш репозиторий и размещены по отдельным каталогам. При этом в лог-файл out.txt будет сохранена информация о результатах выгрузки всех файлов.
Окончательный вариант bat-файла будет выглядеть так:
SET EXT_FOLDER="c:\Обработки"
SET SRC="c:\Repo1C"
SET OUT="c:\Repo1C\out.txt"
cd /D %EXT%
del /f /q %OUT%
FOR %%F IN (*.epf *.erf) DO (
%PATH1C% DESIGNER /DumpExternalDataProcessorOrReportToFiles %SRC% %%F /OUT %OUT% -NoTruncate
)
set /P txtcommit="Введите текст комментария: "
git add .
git commit -m "%date% %time%: %txtcommit%"
В предложенном примере текст коммита вводится один раз для всех обработок, но можно перенести команды системы Git в цикл FOR и вводить описание для каждого файла.
Подведем итоги. Теперь мы можем:
- Фиксировать новые версии обработки в хранилище системы контроля версий. Например, это можно делать в конце рабочего дня или перед началом работы над новым блоком программного кода.
- Просматривать историю версий и внесенные изменения, чтобы быстро понять, когда и что было добавлено, изменено или удалено.
- Сравнивать версии обработки между собой. К примеру, можно увидеть, чем именно отличается версия недельной давности от текущей. Или в какой момент был неверно выбран алгоритм для решения задачи — и при необходимости вернуться в исходную точку.
При наличии удобных инструментов такие вопросы решаются быстрее и эффективнее.
Заключение
Мы рассмотрели основы работы с Git и общий способ версионирования внешних обработок, который заключается в следующем:
- Обработку нужно выгрузить в формате *.xml.
- Выгруженные файлы должны быть помещены в репозиторий системы контроля версий.
- Сравнение версий выполняется внешними инструментами сравнения.
Платформа 1С также предоставляет возможность обратной загрузки — формирования внешней обработки отчета из набора XML-файлов. Для этого существует команда «Загрузить из файлов» и ключ LoadExternalDataProcessorOrReportFromFiles.
Также за рамками статьи остались другие возможности, которые предоставляет система Git: облачное хранение репозитория, совместная работа над проектом и многое другое. Они тоже могут использованы при работе с внешними файлами системы «1С:Предприятие».
Об авторе
Автор статьи – Сергей Калеников
г. Москва
Доброго вечера.
Добавлю ещё комментарий.
Когда я пыталась сохранить все обработки из папки, то выгрузка не происходит, если у имени файла содержится пробел.
Я заменила все пробелы на _, переименовав файлы и всё нормально выгрузилось.
Благодарю за отличную идею
Добрый день!
Отлично, что получилось решить Вашу задачу.
Доброго дня.
Вроде всё также же, как и Вас в примере написано. Поставила кодировку необходимую, только данные к сожалению не выгружаются. Даже файл out.txt не формируется :(
CHCP 1251
SET PATH1C = “c:\Program Files\1cv8\8.3.16.1063\bin\1cv8.exe”
SET EXT = “” “d:\Program\1c\претензия и иск\ИСК\Исковое заявление 8.3.epf”
SET SRC = “d:\Program\1c\Repo1C”
SET OUT = “d:\Program\1c\Repo1C\out.txt”
%PATH1C% DESIGNER /DumpExternalDataProcessorOrReportToFiles %SRC% %EXT% /Out %OUT%
Добрый день!
Создал следующий bat-файл:
SET PATH1C="c:\Program Files\1cv8\8.3.17.1549\bin\1cv8.exe"
SET EXT="d:\ОткрытьОтчет.epf"
SET SRC="z:\Temp\IB"
SET OUT="z:\Temp\IB\out.txt"
%PATH1C% DESIGNER /DumpExternalDataProcessorOrReportToFiles %SRC% %EXT% /Out %OUT%
Выгрузка внешней обработки в файлы прошла успешно. Содержимое файла out.txt:
Входной бинарный файл: d:\ОткрытьОтчет.epf
Каталог или корневой файл выгрузки: z:\Temp\IB
Формат: Иерархический
Выгрузка завершена. Суммарное время выполнения операции: 2660 миллисекунд.
В Вашем примере удалил пробелы в строках с командами SET. Также в строке с установкой переменной EXT удалил лишние кавычки.
Благодарю Вас за совет и замечания.
Получилось. :)
в 5 строке ошибка, правильно так:
cd /D %EXT_FOLDER%
Спасибо за статью. А подскажите, а если попробовать автоматизировать выгрузку в таком плане, что при записи внешней обработки/отчета в справочник.ВнешниеОбработки запускать пакетный режим, не будет ли это лишняя нагрузка на систему? И если у нас уже запущен конфигуратор, то пакетный режим не сработает?
Описанная выгрузка работает только с файловой системой.
Если при записи сделать сохранение файла обработки на диск, а потом запустить .bat файл – из конфигуратора выходить не нужно (т.к. по сути в базу никто не ломится).
Большое спасибо за статью!
You are welcome! :)
А какие рекомендации можете дать по репозиторию? Что лучше – создавать отдельный для внешних обработок или тащить их в репозиторий конфигурации?
Огромное спасибо! Какая интересная статья! Как хорошо написана! О такой возможности прежде не слышала, даже не ожидала, что такое возможно
Благодарю за статью!
А почему бы и нет, так тоже можно. Останавливает от использования данного способа постоянная выгрузка в xml, даже с использованием пакетного режима. Т.е. трудоемкий процесс помещения изменения и создания commit. Если стоит задача хранить версии внешних обработок и просмотра версий и ничего более сложного как merge и т.д., то я свой выбор остановил на tortoise svn. Есть папка Repo, которая версионируется. Она синхронизируется с облаком. Изменяешь обработку, фиксируешь изменение (commit). Далее, если нужно посмотреть изменения в версиях, в настройках tortoise svn для epf и ert указан скрипт, который написан на замечательном инструменте OneScript. Скрипт запускает служебную базу, где на входе 2 файла разных версий, в этой базе единственная обработка v8reader (еще один мощный инструмент с большим потенциалом) которая опубликована на infostart, с с помощью этой обработки и происходить сравнение версий. Немного сложно изначально для настройки, зато затем процесс фиксации изменений и просмотра версий простой.
Каждый раз с восторгом открываю статьи про 1С и Git, и каждый раз расстраиваюсь. Ничего полезней 1С в выгрузке внешних обработок в файлы не смогла придумать, как выгрузить в читаемом виде для текстового редактора модуля объекта, а модулей формы вы бинарник! “Это же так информативно!”
Именно по этому эта выгрузка в файлы не несёт особого смысл.
Я в гит сохраняю сам *epf-файл и в текстовые файлы с расширением *.bsl ручками содержание модулей форм. Так удобно отслеживать изменения в модулях, а на случай необходимости посмотреть остальное уже приходится доставать два варианта обработки и сравнивать. Это куда продуктивней и понятней для работы обычного смертного не из матрицы, который не умеет видеть картинки в потоке единичек и нулей.
Для практического применения инструкция требует доработки. При выгрузке внешних обработок штатными средствами необходимо указывать базу данных содержащих конфигурацию со всеми объектами, на которые ссылаются реквизиты обработки или реквизиты формы этой обработки.
Иначе все ссылочные реквизиты в результате выгрузки будут иметь тип “Строка”:
http://prntscr.com/lq54de
Для больших конфигураций типа ERP это делает приведенный скрипт неприменимым на практике, так как для 10 обработок потребуется запустить конфигуратор с актуальной базой ERP 10 раз.
Помочь при этом может режим агента конфигуратора : https://wonderland.v8.1c.ru/blog/rezhim-agenta-konfiguratora/
Владимир, спасибо за замечание. Если во внешней обработке есть ссылки на объекты метаданных, в запуск конфигуратора нужно добавить ключ /IBName с указанием пути к базе.
Про режим конфигуратора — не понятно, уточните, пожалуйста, как именно его можно использовать для решения нашей задачи?
И еще — а зачем запускать скрипт 10 раз? Если у вас 10 обработок, достаточно поместить их в одну папку и запустить скрипт один раз.
Много тонкостей, которые встретятся, не показаны.
Выгрузка обычных форм и т.п.
– А использовать Gitsync, Гит-Конвертер и т.п.?
– Нет, не слышали! :(
Коллеги, историям с коллективной работе 1C через Git уже много лет.
Уже описано на многих сайтах.
Зачем эта статья?
Артур, у этой статьи есть своя аудитория.
Давайте обсудим – может быть, Вы готовы написать статью для нашего сайта? Отправила по этому поводу письмо на Ваш e-mail.
– групповая разработка в Гите под редакцией М.Радченко? (https://edt.1c.ru/upload/docs_git/EDT&GIT.html)
– не, не слышали…
“в интернете кто-то неправ” :)
Артур, Вы правы, платформа 1С уже достаточно давно поддерживает выгрузку в XML-файлы.
Правда, на деле эту возможность используется достаточно редко. Причин много: нет официальных инструкций от фирмы 1С; не все знают, что так вообще можно; не всем понятно ясно с чего начать; нет общего понимания зачем это надо и т.д.
Цель же данной статьи — на конкретном примере показать, как именно работает выгрузка метаданных в файлы и как работает версионирование. Если хотите — это такой небольшой шаг в сторону EDT и полноценной работе с GIT. Всему свое время, а начинать всегда лучше с азов :)
А вот упомянутые Вами Gitsync и Гит-Конвертер используются немного для других целей (для синхронизации хранилища 1С с репозиторием) и с внешними обработками не работают. К теме статьи бы больше подошел, например, Vanessa-runner, но и для работы с ним нужно обладать начальными знаниями и общим пониманием возможностей системы.
> нет официальных инструкций от фирмы 1С
Кажется выше дали ссылку на документацию по групповой разработке в гите с помощью EDT под редакцией тов. Радченко, но я повторюсь
https://edt.1c.ru/upload/docs_git/EDT&GIT.html
Так же могу посоветовать ознакомиться с докладом:
https://its.1c.ru/video/erp_train2018_d3_10_20
Ваша ссылка на тов. Радченко в самом обычном стиле 1С даёт ошибку 404.
Вообще иногда поражает зажравшесть нашей аудитории – им пишут ценные материалы, бесплатно, а им ещё и не нравится, они хотят, чтобы им такие статьи не писали.
А ссылка на видео находится в закрытом платном разделе. Но нет, нам не нужны бесплатные материалы, мы одинэсники!
Форма вместе с текстом модуля формы выгрузилась не в bsl файл, а в bin
Платформа 8.3.12.1595
обычная форма?
Да
Денис, это особенность платформы.
Управляемая форма может быть представлена в виде XML-документа, а обычная форма — нет, она выгружается просто как двоичные данные.
Спасибо за статью.
У меня идея. Почему бы не использовать отдельное хранилище от самой 1с для внешних обработок и отчетов?
Если внешние отчеты и обработки помещать в отдельное хранилище как отчеты и обработки “пустой” конфигурации, то в этой конфигурации потребуется также создавать и метаданные для тех типов, которые указаны у реквизитов внешних отчетов/обработок. Т.е. если в “рабочей” конфигурации есть справочник “Контрагенты”, а во внешней обработке есть реквизит с типом СправочникСсылка.Контрагенты, то при загрузке этой обработки в “пустую” конфигурацию тип реквизита “потеряется”, если в пустой конфигурации будет отсутствовать справочник Контрагенты.
Поздравляю, Вы только что изобрели расширения)
Вот только их уже давно все используют…
А проблема с модулем менеджера обработки остается? Он не выгружается из конфигурации в файл?
Catseye, спасибо за вопрос. Это не совсем проблема, просто у внешних обработок на самом деле не существует модуля менеджера.
Давайте вспомним теорию: модуль менеджера представляет собой описание «статических» методов объекта конфигурации — таких, которые можно использовать без создания экземпляра самого объекта. Например, так:
мРеквизиты = Справочники.Контрагенты.ПолучитьСписокОбязательныхРеквизитов(ВидКонтрагента).
Тут мы просто обращаемся в справочник, без указания конкретного контрагента.
А вот к внешней обработке мы так обратиться не сможем: поскольку описание ее метаданных не хранится в базе, то для обращения к ее функциям сначала нужно создать экземпляр с помощью ВнешниеОбработки.Создать().
И получается нестыковка — модуль менеджера нужен для вызова функций БЕЗ создания экземпляра объекта, а внешняя обработка БЕЗ создания экземпляра вообще не может существовать.
В общем, поэтому модуль и не выгружается :)
Спасибо! Хорошая статья. А курс по EDT будет? Или уже не стоит надеяться? :-)
Добрый день, Айдар!
Пока не видим необходимости записывать курс. Сам продукт отслеживаем, ждем пока ситуация с ним более-менее стабилизируется.