Как правильно организовать выгрузку XML из 1С на сайт, если используется формат Конвертации Данных (КД)?

В практике 1С-программиста часто возникают задачи интеграции с внешними сервисами, сайтами или аналитическими системами. Одна из распространенных ситуаций: сервис требует выгрузку данных в формате XML, но документации мало, или она отсутствует. Рассмотрим кейс, когда при анализе требований выясняется, что требуемый формат подозрительно похож на стандартный обмен между базами 1С. Разберем, как идентифицировать такой обмен и почему ручное формирование XML-файла в этом случае — тупиковый путь.

Анализ структуры требуемого файла

Первым шагом при любой интеграции является анализ формата данных. Допустим, мы получили (или подсмотрели в логах сервиса) следующий заголовок XML-файла:

<?xml version="1.0" encoding="UTF-8"?>
<ФайлОбмена Комментарий="Выгрузка" ИдПравилКонвертации="EFD80137-DDFF-929B-3A8C-3A2DF44C4653" 
    ИмяКонфигурацииПриемника="БухгалтерияПредприятия" 
    ИмяКонфигурацииИсточника="БухгалтерияПредприятия" 
    ВерсияФормата="2.0" >
 <ПравилаОбмена>
 <ВерсияФормата>2.01</ВерсияФормата>
 ...

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

1. ИдПравилКонвертации (GUID): Это уникальный идентификатор правил обмена. Он генерируется в конфигурации «Конвертация данных 2.0» (КД 2). Это явный признак того, что принимающая сторона ожидает файл, сформированный именно по этим правилам.
2. ВерсияФормата="2.01": Указывает на использование классического механизма обмена через XML (не EnterpriseData/XDTO, где версии обычно 1.X, а именно формат КД 2.0).
3. Источник и Приемник: Указывают на то, что сервис маскируется под конфигурацию 1С (например, «БухгалтерияПредприятия»), чтобы стандартные механизмы 1С могли корректно загрузить или выгрузить данные.

Вывод: Перед нами не произвольный XML-формат, придуманный разработчиками сайта, а стандартный пакет обмена 1С, созданный с помощью технологии «Конвертация данных 2.0». Это кардинально меняет подход к разработке.

Почему нельзя формировать такой XML «руками»?

У начинающих разработчиков часто возникает соблазн использовать объект ЗаписьXML и просто воспроизвести структуру тегов вручную. Рассмотрим, почему в данном случае это является грубой ошибкой.

Формат КД 2.0 — это сложная, иерархическая структура, которая описывает не только значения полей, но и метаданные типов, ссылки на объекты и правила их поиска.

Основные проблемы ручной сборки:

1. Сложность ссылочной целостности: В 1С объекты ссылаются друг на друга через УИД (GUID). В файле обмена КД сначала идет описание объекта, а затем ссылки на него. Если вы будете писать текст XML линейно, вам придется самостоятельно реализовывать механизм кэширования выгруженных объектов, чтобы не выгружать один и тот же справочник (например, «Валюты» или «Контрагенты») тысячи раз внутри каждого документа.
2. Идентификация правил: Атрибут ИдПравилКонвертации должен строго соответствовать тому файлу правил (Rules.xml), который загружен на стороне приемника (сайта). Если вы ошибетесь хоть в одном теге структуры, загрузка на сайте упадет с ошибкой чтения.
3. Трудоемкость поддержки: Если на сайте изменится состав полей, вам придется переписывать код формирования XML. При использовании правильного подхода достаточно лишь обновить файл правил.

Правильный подход: Использование правил обмена

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

Шаг 1. Поиск готового решения от поставщика услуг

В большинстве случаев, если сервис (сайт) умеет принимать данные в формате 1С, разработчики сервиса предоставляют готовую внешнюю обработку или расширение. Внутри этих решений уже «зашиты» нужные правила обмена.

Вам необходимо:

• Запросить у техподдержки сайта файл интеграции (обработку .epf или расширение .cfe).
• Если файл предоставлен, использовать его. Обычно там есть кнопка «Выгрузить», которая делает всё автоматически.

Шаг 2. Извлечение правил конвертации (если нужна кастомизация)

Если готовая обработка вас не устраивает (например, нужно настроить фоновое выполнение, а обработка требует ручного запуска), вы можете извлечь из нее самое главное — Правила конвертации.

Как это сделать:

1. Откройте полученную обработку или расширение в Конфигураторе.
2. Перейдите в ветку Макеты.
3. Найдите макет с типом «Двоичные данные» (обычно он называется ПравилаОбмена или ПравилаОбменаXML).
4. Выгрузите данные макета в файл с расширением .xml.

Теперь у вас есть файл правил, который понимает принимающая сторона.

Шаг 3. Настройка автоматической выгрузки

Имея файл правил, мы можем использовать типовую обработку УниверсальныйОбменДаннымиXML (она есть практически во всех типовых конфигурациях или на диске ИТС) или написать свой код, использующий менеджер обмена.

Рассмотрим пример программного кода, который можно поместить в регламентное задание для автоматической выгрузки:

// Пример программной выгрузки данных по правилам обмена
Процедура ВыполнитьВыгрузкуНаСайт()
    
    ИмяФайлаПравил = "C:\Exchange\Rules.xml"; // Файл, который мы достали из макета
    ИмяФайлаДанных = "C:\Exchange\Upload.xml"; // Файл, который отправим на сайт
    
    ОбработкаОбмена = Обработки.УниверсальныйОбменДаннымиXML.Создать();
    ОбработкаОбмена.РежимОбмена = "Выгрузка";
    ОбработкаОбмена.ИмяФайлаПравилОбмена = ИмяФайлаПравил;
    ОбработкаОбмена.ИмяФайлаОбмена = ИмяФайлаДанных;
    
    // Загружаем правила
    ОбработкаОбмена.ЗагрузитьПравилаОбмена();
    
    // Устанавливаем параметры (если они есть в правилах)
    ОбработкаОбмена.Параметры.Вставить("ДатаНачала", НачалоДня(ТекущаяДата()));
    ОбработкаОбмена.Параметры.Вставить("ДатаОкончания", КонецДня(ТекущаяДата()));
    
    // Выполняем выгрузку
    Попытка
        ОбработкаОбмена.ВыполнитьВыгрузку();
    Исключение
        ЗаписьЖурналаРегистрации("ОбменСайт", УровеньЖурналаРегистрации.Ошибка, , , ОписаниеОшибки());
        Возврат;
    КонецПопытки;
    
    // Далее код отправки полученного файла ИмяФайлаДанных на сайт (через HTTP или FTP)
    ОтправитьФайлНаСайт(ИмяФайлаДанных);

КонецПроцедуры

Альтернатива: Отказ от XML в пользу HTTP-сервисов

Если вы разрабатываете интеграцию «с нуля» и сервис поддерживает другие методы, стоит рассмотреть отказ от файлового обмена через XML в пользу HTTP-запросов (REST API).

Современные сервисы часто принимают данные в формате JSON. Формировать JSON из 1С намного проще и нагляднее, чем XML формата КД.

Пример простой отправки данных, если сервис это поддерживает:

// Формируем JSON вручную (здесь это оправдано простотой структуры)
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписьJSON.ЗаписатьНачалоОбъекта();
ЗаписьJSON.ЗаписатьСвойство("OrgName", "ООО Ромашка");
ЗаписьJSON.ЗаписатьСвойство("Sum", 1000);
ЗаписьJSON.ЗаписатьКонецОбъекта();
СтрокаJSON = ЗаписьJSON.Закрыть();

// Отправка
Соединение = Новый HTTPСоединение("api.kub-24.ru", 443, , , , , Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/api/upload");
Запрос.УстановитьТелоИзСтроки(СтрокаJSON);
Ответ = Соединение.ОтправитьДляОбработки(Запрос);

Резюме

1. Если вы видите в примере файла атрибуты ИдПравилКонвертации и ПравилаОбмена — это Конвертация Данных 2.0.
2. Ни в коем случае не пишите XML вручную. Это приведет к ошибкам в структуре GUID и сложностям с ссылочными типами.
3. Ищите готовое расширение или обработку от поставщика сервиса.
4. Если нужна автоматизация, извлеките файл правил (XML) из макета готового решения и используйте его через объект Обработки.УниверсальныйОбменДаннымиXML в фоновом задании.