Вопрос организации обмена данными между конфигурациями 1С часто упирается в архитектурные ограничения. Рассмотрим подробно, как подступиться к задаче, если вы не имеете возможности менять правила или структуру базы-источника, и в чем заключается разница между поколениями инструментов для обмена.
При использовании Конвертация данных 2.0 важно осознавать, что правила обмена данными (ПВД, ПКД) по своей сути «заточены» под конкретную пару конфигураций. Когда вы выгружаете данные из базы-источника, файл XML уже формируется с учетом специфики структуры приемника.
Если у вас нет доступа к базе-источнику, вы не можете «прицепить» туда правила. В этом случае стоит рассмотреть следующие стратегии работы:
XML-сообщение. Если формат выгрузки неизменен, вы можете программно модифицировать полученный файл перед загрузкой или перехватить процесс обработки через собственные алгоритмы.XML в структуру, понятную вашей базе. Это позволяет не зависеть от логики источника.Универсальный обмен данными в формате XML является открытой, вы можете создать на её основе собственную внешнюю обработку. В ней можно реализовать программную логику перехвата узлов XML и принудительного изменения правил создания или сопоставления объектов в вашей базе.Многие разработчики переходят на Конвертация данных 3.0 (EnterpriseData), так как она предлагает иную концепцию. Давайте разберем, как это работает:
В основе КД 3.0 лежит использование промежуточного универсального формата, базирующегося на XDTO-пакетах. Это позволяет:
Планы обмена и БСП, исключая необходимость ручной работы с файлами.В отличие от КД 2.0, здесь вы не «вешаете» правила на источник, а описываете маппинг объектов на промежуточный формат, который является стандартом для обеих баз. Это значительно упрощает поддержку интеграции при обновлении одной из сторон.
Если конфигурации идентичны (например, две базы Бухгалтерия предприятия одной версии), использование КД 2.0 часто является избыточным. Мы рекомендуем рассмотреть более простые инструменты:
Воспользуйтесь стандартной обработкой Выгрузка и загрузка данных XML. Она позволяет переносить справочники, документы и регистры накопления без написания сложных правил, используя прямое соответствие метаданных.
Если же задача требует глубокой интеграции без доступа к конфигуратору источника, рассмотрите использование современных протоколов:
Использование OData (REST API):
Вместо экспорта файлов, база-приемник может выступать в роли клиента. Вы можете настроить прямое чтение объектов из базы-источника через стандартный интерфейс OData. Это позволит вам самостоятельно выбирать, какие данные и когда забирать, не полагаясь на сторонние правила выгрузки.
Пример программного обращения к данным через HTTP-запрос:
// Пример логики получения данных через REST API
Соединение = Новый HTTPСоединение("ИмяСервера", 80, "Пользователь", "Пароль");
Запрос = Новый HTTPЗапрос("/odata/standard.odata/Catalog_Номенклатура");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
Данные = Ответ.ПолучитьТелоКакСтроку();
// Обработка полученного JSON или XML
КонецЕсли;
Приступая к задаче, проанализируйте текущие возможности систем:
EnterpriseData. Это промышленный стандарт, который экономит время при обновлении типовых решений.Помните, что выбор метода зависит от частоты обмена и требований к надежности. Для разовых задач лучше использовать простые методы, для регулярных обменов между типовыми базами — штатные инструменты БСП и КД 3.0.