Как реализовать обмен данными в формате EnterpriseData без использования БСП

Реализация обмена данными по формату EnterpriseData (ED) традиционно ассоциируется с внедрением подсистемы «Обмен данными» из состава Библиотеки стандартных подсистем (БСП). Однако на практике часто возникают ситуации, когда конфигурация является самописной или клиент категорически против добавления сотен объектов БСП ради одной задачи. В этой статье мы разберем, как реализовать полноценную выгрузку в формате EnterpriseData, используя только штатные средства платформы 1С и механизмы XDTO, сохраняя при этом совместимость с типовыми решениями (например, «Бухгалтерия предприятия 3.0»).

Понимание архитектуры EnterpriseData

Для начала проанализируем, что представляет собой сообщение в формате EnterpriseData. По сути, это обычный XML-файл (или JSON), структура которого строго описана в XSD-схемах. В платформе 1С эти схемы представлены в виде XDTO-пакетов. Основная сложность при отказе от БСП заключается в том, чтобы вручную сформировать «конверт» сообщения и корректно сериализовать данные объектов согласно правилам выбранной версии формата.

Любое сообщение EnterpriseData состоит из двух ключевых частей:

1. Заголовок (Header): Содержит служебную информацию (версию формата, отправителя, получателя, номера сообщений для квитирования).
2. Тело (Body): Содержит непосредственно данные объектов (справочники, документы), обернутые в теги соответствующих типов из пространства имен версии ED.

Шаг 1: Формирование заголовка сообщения

Рассмотрим структуру заголовка. Если мы не используем БСП, нам необходимо самостоятельно сформировать XML-структуру, которую ожидает принимающая сторона (например, БП 3.0). Рассмотрим пример того, как должен выглядеть XML-заголовок (в примере ниже приведен фрагмент логики формирования структуры):

// Пример формирования заголовка сообщения EnterpriseData
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.ОткрытьФайл(ПутьКФайлу, "UTF-8");
ЗаписьXML.ЗаписатьОбъявлениеXML();

ЗаписьXML.ЗаписатьНачалоЭлемента("msg:Message", "http://www.1c.ru/SSL/Exchange/Message");
ЗаписьXML.ЗаписатьСоответствиеПрефикса("msg", "http://www.1c.ru/SSL/Exchange/Message");
ЗаписьXML.ЗаписатьСоответствиеПрефикса("xs", "http://www.2001/XMLSchema");
ЗаписьXML.ЗаписатьСоответствиеПрефикса("xsi", "http://www.w3.org/2001/XMLSchema-instance");

ЗаписьXML.ЗаписатьНачалоЭлемента("msg:Header");

ЗаписьXML.ЗаписатьЭлемент("msg:Format", "http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.0");
ЗаписьXML.ЗаписатьЭлемент("msg:CreationDate", Формат(ТекущаяДата(), "ДФ=yyyy-MM-ddTHH:mm:ss"));

ЗаписьXML.ЗаписатьНачалоЭлемента("msg:Confirmation");
ЗаписьXML.ЗаписатьЭлемент("msg:ExchangePlan", "СинхронизацияДанныхЧерезУниверсальныйФормат");
ЗаписьXML.ЗаписатьЭлемент("msg:To", "КодПолучателя");
ЗаписьXML.ЗаписатьЭлемент("msg:From", "КодОтправителя");
ЗаписьXML.ЗаписатьЭлемент("msg:MessageNo", "1");
ЗаписьXML.ЗаписатьЭлемент("msg:ReceivedNo", "0");
ЗаписьXML.ЗаписатьКонецЭлемента(); // msg:Confirmation

ЗаписьXML.ЗаписатьЭлемент("msg:AvailableVersion", "1.1");
ЗаписьXML.ЗаписатьКонецЭлемента(); // msg:Header

ЗаписьXML.ЗаписатьНачалоЭлемента("Body", "http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.0");

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

Шаг 2: Использование XDTO для выгрузки объектов

Вместо того чтобы писать формирование каждого тега вручную (что крайне трудоемко и чревато ошибками), мы воспользуемся механизмом XDTO. В конфигурации должен присутствовать XDTO-пакет EnterpriseData_X_X_X. Рассмотрим подробнее процесс выгрузки конкретного объекта, например, «Номенклатуры».

Для реализации выгрузки без БСП мы можем использовать два пути:

1. Ручное создание объектов XDTO: Мы создаем объект типа XDTO, заполняем его свойства и записываем в XML.
2. Использование менеджеров обмена из КД 3.0: Это наиболее рациональный путь. Мы можем разработать правила в «Конвертации данных 3.0», выгрузить модуль менеджера обмена и перенести его в нашу конфигурацию как обычный общий модуль.

Выясним причину, по которой модули из КД 3.0 не работают «из коробки» без БСП. В коде менеджера обмена присутствуют вызовы процедур БСП, таких как ОбменДаннымиСервер. Чтобы решить эту проблему, нам нужно создать в своей конфигурации «заглушку» — общий модуль с аналогичным названием, где реализовать только необходимые функции (например, преобразование типов или поиск GUID), либо заменить эти вызовы в тексте модуля менеджера на стандартные методы 1С.

Шаг 3: Пример формирования данных объекта

Проанализируем пример кода, который формирует данные номенклатуры через XDTO:

// ТипОбъектаXDTO берется из пакета EnterpriseData нужной версии
ТипНоменклатура = ФабрикаXDTO.Тип("http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1", "Справочник.Номенклатура");
ОбъектXDTO = ФабрикаXDTO.Создать(ТипНоменклатура);

// Заполнение ключевых свойств
КлючевыеСвойства = ФабрикаXDTO.Создать(ТипНоменклатура.Свойства.Получить("КлючевыеСвойства").Тип);
КлючевыеСвойства.НаименованиеПолное = "Товар тестовый";
КлючевыеСвойства.КодВПрограмме = "00001";
ОбъектXDTO.КлючевыеСвойства = КлючевыеСвойства;

ОбъектXDTO.Наименование = "Товар тестовый";
ОбъектXDTO.ТипНоменклатуры = "Товар";
// Сериализация в XML
ФабрикаXDTO.ЗаписатьXML(ЗаписьXML, ОбъектXDTO);

Важно помнить, что EnterpriseData требует заполнения определенных обязательных полей. Если вы пропустите поле, которое по схеме XSD является обязательным (например, ставку НДС или единицу измерения), принимающая сторона выдаст ошибку при загрузке. Поэтому использование модуля менеджера из КД 3.0 предпочтительнее — там вся логика обязательных полей уже прописана.

Шаг 4: Транспорт и загрузка в приемник

После того как файл сформирован и закрыт тегами </Body> и </msg:Message>, его необходимо передать в «1С:Бухгалтерию». Поскольку мы отказались от БСП в источнике, мы можем использовать один из следующих методов доставки:

• HTTP-сервис: В типовой БП 3.0 есть встроенные веб-сервисы для обмена. Мы можем отправить наш файл POST-запросом.
• Файловый каталог: Если у баз есть общая папка, достаточно положить файл туда. БП 3.0 в рамках регламентного задания синхронизации увидит файл и обработает его.
• COM-соединение: Мы можем программно подключиться к базе БП и вызвать процедуру загрузки данных, передав ей путь к нашему файлу.

Преимущества и недостатки подхода без БСП

Разберем ситуацию с точки зрения дальнейшей поддержки. Плюсы очевидны: конфигурация остается «чистой», количество новых объектов минимально (один-два модуля и XDTO-пакет). Однако есть и риски:

1. Версионность: При обновлении БП 3.0 может измениться поддерживаемая версия EnterpriseData. Вам придется вручную обновлять XDTO-пакет и корректировать логику заполнения полей в своем модуле.
2. Регистрация изменений: Без БСП вам придется самостоятельно реализовывать механизм отслеживания измененных данных (например, через подписки на события или простейший план обмена), чтобы не выгружать всю базу целиком каждый раз.
3. Обработка ошибок: БСП предоставляет мощный лог мониторинга обмена. В случае самописного решения вам придется реализовывать журналирование ошибок самостоятельно.

Заключение

Мы убедились, что реализовать обмен в формате EnterpriseData без БСП вполне реально. Основная работа заключается в корректном формировании XML-конверта и использовании XDTO-пакетов для сериализации данных. Этот путь отлично подходит для небольших задач по односторонней выгрузке данных, когда скорость внедрения и «чистота» конфигурации приоритетнее использования стандартных универсальных механизмов.