Проблема интеграции «наследственных» (legacy) систем, таких как Управление торговлей 10.3, УПП 1.3 или глубоко кастомизированные самописные конфигурации на обычных формах, с современными решениями вроде ERP 2.5 или Комплексная автоматизация 2, является одной из самых сложных задач для разработчика 1С. Основная сложность заключается в концептуальном различии архитектур: старые системы работают на «толстом клиенте», в то время как новые полностью базируются на Библиотеке стандартных подсистем (БСП) и универсальном формате обмена EnterpriseData.
В этой статье мы подробно разберем несколько проверенных стратегий интеграции, проанализируем их плюсы и минусы, а также выясним, какой инструмент лучше выбрать в зависимости от объема данных и требований к скорости обмена.
Несмотря на появление КД 3.0, вторая версия остается наиболее популярным инструментом для разовых или периодических обменов между разнородными базами. Рассмотрим, как правильно встроить этот механизм в связку «Старая база — ERP».
Разберем основные шаги реализации:
ПланыОбмена. Это позволит регистрировать только измененные данные, а не выгружать всю базу целиком.УПП 1.3 и ERP 2 сильно различаются.КД 2.0 можно запустить через универсальную обработку обмена данными XML. Однако для автоматизации лучше использовать подсистему ОбменДанными.Проанализируем программный вызов выгрузки через КД 2.0. Часто бывает необходимо инициировать обмен кодом:
// Пример программного запуска выгрузки по правилам КД 2.0
ОбработкаОбмена = Обработки.УниверсальныйОбменДаннымиXML.Создать();
ОбработкаОбмена.ИмяФайлаПравил = "C:\Rules\ExchangeRules.xml";
ОбработкаОбмена.ИмяФайлаСообщенияОбмена = "C:\Data\MessageToERP.xml";
ОбработкаОбмена.РежимОбмена = "Выгрузка";
ОбработкаОбмена.ЗагрузитьПравилаОбмена();
ОбработкаОбмена.ВыполнитьВыгрузку();
Преимущества: Понятная логика, высокая гибкость настройки сопоставления полей через обработчики событий.
Недостатки: Низкая скорость работы на больших объемах данных из-за использования формата XML и последовательного чтения/записи DOM.
Если требуется частый или практически мгновенный обмен (Real-time), формат XML становится «узким местом». Рассмотрим альтернативу — HTTP-сервисы. Современная платформа 1С позволяет передавать данные в легковесном формате JSON, который в разы быстрее парсится и занимает меньше места.
Выясним, как организовать такую передачу. Мы создаем на стороне ERP HTTP-сервис, который будет принимать данные. В старой конфигурации мы пишем код отправки через объект HTTPСоединение.
Посмотрим на пример формирования JSON-пакета в старой базе:
// Сериализация данных в JSON для отправки в ERP
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ДанныеОбъекта = Новый Структура;
ДанныеОбъекта.Вставить("GUID", Строка(Ссылка.УникальныйИдентификатор()));
ДанныеОбъекта.Вставить("Наименование", Ссылка.Наименование);
ДанныеОбъекта.Вставить("ИНН", Ссылка.ИНН);
ЗаписатьJSON(ЗаписьJSON, ДанныеОбъекта);
СтрокаJSON = ЗаписьJSON.Закрыть();
// Отправка через HTTP
Соединение = Новый HTTPСоединение("erp-server.local");
Запрос = Новый HTTPЗапрос("/v1/integration/sync_partner");
Запрос.УстановитьТелоИзСтроки(СтрокаJSON);
Ответ = Соединение.ОтправитьДляОбъекта(Запрос);
Этот метод позволяет передавать данные порциями. Главное преимущество здесь — потоковая обработка. Используя ЧтениеJSON и ЗаписьJSON, мы можем обрабатывать огромные массивы данных, не перегружая оперативную память сервера.
Многие разработчики боятся Конвертации данных 3.0, так как она требует реализации логики на стороне каждой базы. Однако для старых типовых конфигураций (УТ 10.3, УПП) существуют готовые решения — модули, которые добавляют поддержку EnterpriseData (ED) в старую конфигурацию.
Рассмотрим, почему это выгодно:
Если ваша самописная конфигурация сильно отличается от типовой, придется внедрить в нее минимальный набор объектов из БСП (планы обмена, несколько общих модулей) и настроить правила обработки данных в формате XDTO. Это трудозатратно в начале, но максимально надежно в долгосрочной перспективе.
Проанализируем ситуацию, когда нам нужно быстро получить данные из ERP в старую базу, не создавая правил обмена. Для этого идеально подходит REST-интерфейс (OData), который включается одной галочкой в свойствах конфигурации ERP.
Разберем по шагам, как это работает:
http://server/erp/odata/standard.odata/Document_ЗаказКлиента.Этот метод хорош для справочников или получения остатков. Однако для передачи документов он требует осторожности, так как запись через OData не всегда корректно отрабатывает сложную бизнес-логику проведения (могут потребоваться дополнительные вызовы процедур через Actions).
При любом способе интеграции мы неизбежно столкнемся с проблемой сопоставления объектов. В старой базе контрагент может иметь один внутренний идентификатор, а в новой — другой (например, если база ERP создавалась с нуля перечеркиванием старых данных).
Рекомендуемое решение: Создайте в ERP (или в промежуточной базе) Регистр Сведений СоответствиеОбъектовИнформационныхБаз. Структура регистра должна быть следующей:
Перед загрузкой любого объекта мы сначала проверяем наличие записи в этом регистре. Если запись найдена — обновляем существующий объект, если нет — создаем новый и записываем связь. Это предотвратит дублирование данных при повторных обменах.
Выясним итоги нашего анализа. Выбор технологии зависит от ваших ресурсов и задач:
Помните, что качественная интеграция — это не только перенос данных, но и грамотная обработка ошибок, квитирование (подтверждение) приема и логирование каждого этапа обмена. Совмещая современные методы (JSON, HTTP) со стабильностью классических планов обмена, вы сможете построить отказоустойчивую систему взаимодействия между поколениями программных продуктов 1С.