При сопровождении и развитии информационных систем на платформе 1С:Предприятие разработчики часто сталкиваются с ситуацией, когда одна из баз (например, сильно кастомизированная старая конфигурация) работает на устаревшей версии Библиотеки Стандартных Подсистем (БСП) 2.1, а вторая база обновляется на современную версию с БСП 3.x. Возникает закономерный вопрос: сломается ли настроенный между ними обмен данными, и как минимизировать риски при переходе на новые релизы?
В этой статье мы подробно разберем, как устроена обратная совместимость в БСП, что происходит с обменами КД 2 и EnterpriseData при смене версий библиотек, и какие превентивные меры необходимо предпринять, чтобы интеграция продолжала работать бесперебойно.
Среди разработчиков 1С популярен миф о том, что фирма «1С» постоянно переименовывает процедуры и функции ради самого процесса, нарушая обратную совместимость (backward compatibility) программного кода. Давайте разберемся, почему это происходит на самом деле и как защитить свои доработки от поломок при обновлении БСП.
В официальных стандартах разработки «1С» четко прописано разделение кода на программный интерфейс и служебный код. В общих модулях БСП программный интерфейс выделяется специальными тегами препроцессора:
#Область ПрограммныйИнтерфейс
// Выполняет регистрацию изменений объектов для узла обмена.
Процедура ЗарегистрироватьИзмененияCоответствия(УзелИнформационнойБазы, Данные) Экспорт
// Код процедуры
КонецПроцедуры
#КонецОбласти
Все методы, расположенные вне этой области (даже если у них стоит ключевое слово Экспорт), считаются служебными. Разработчики БСП имеют полное право изменять их структуру, переносить в другие модули или удалять без предупреждения в любом новом релизе. Если в ваших правилах обмена или обработках вызывается служебный метод, ваш код гарантированно сломается при обновлении БСП.
Для методов из области ПрограммныйИнтерфейс действует строгое правило: они не могут быть удалены мгновенно. Если метод планируется вывести из эксплуатации, разработчики БСП помечают его как устаревший с помощью специального комментария:
// Устарела. Следует использовать ОбменДаннымиСлужебный.НовыйМетодРегистрации.
Процедура СтарыйМетодРегистрации() Экспорт
По регламенту такие устаревшие функции обязаны оставаться в коде и корректно функционировать в течение не менее двух лет с момента объявления их устаревшими. Это дает разработчикам достаточно времени для безболезненного перевода своих интеграций на новые методы.
Если обмен данными между конфигурациями БСП 2.1 и БСП 3.x реализован через веб-сервисы, стабильность работы напрямую зависит от архитектуры решения:
Exchange): БСП поддерживает версионирование интерфейсов веб-сервисов. В составе конфигурации могут одновременно сосуществовать несколько версий веб-сервисов (например, Exchange_2_0_1_6). Однако при колоссальном разрыве версий (с 2.1 до 3.x) поддержка совсем старых версий интерфейсов в новой БСП может быть полностью прекращена. В таком случае веб-сервис на стороне новой базы просто откажется принимать запросы старого формата.EnterpriseDataWebService): Это наиболее надежный и отказоустойчивый вариант обмена. Начиная с версии БСП 2.3, обмен в универсальном формате стал стандартом. В данном сценарии базы общаются через XML-сообщения определенной структуры (XDTO-пакеты). При установке соединения базы согласуют версию формата. Если база на БСП 2.1 поддерживает схему EnterpriseData_1.3, а новая база на БСП 3.x поддерживает версии от 1.3 до 1.15, они автоматически выберут для работы версию 1.3. Разница в версиях БСП здесь роли не играет.Формат КД 2 использует классический XML-обмен по правилам, которые загружаются непосредственно в информационную базу или хранятся в макетах. Фирма «1С» сохраняет поддержку КД 2 (в БСП этот механизм называется «Обмен по правилам обмена») даже в самых свежих версиях БСП 3.x. Однако здесь кроются другие опасные нюансы:
Проблема безопасного режима (Safe Mode): В БСП 3.x существенно ужесточились требования к безопасности исполняемого кода. По умолчанию правила обмена КД 2 могут запускаться в безопасном режиме платформы. Если ваши старые правила обмена КД 2 содержали сложный алгоритм во встроенных обработках (например, в обработчиках «Перед выгрузкой» или «После загрузки» выполнялись прямые обращения к файловой системе, COM-соединениям или неэкспортным процедурам модулей конфигурации), то в БСП 3.x такой обмен завершится критической ошибкой безопасности. Вам придется либо переписывать код внутри правил КД 2, либо настраивать профили безопасности для этого обмена.
Правила регистрации объектов (ПРО): Логика регистрации изменений претерпела значительные изменения при переходе на БСП 3.x. Использование старых файлов ПРО (правил регистрации объектов) в новой БСП может приводить к дублированию регистрации или, наоборот, к полной тишине в планах обмена.
Проанализируем основные технические сложности, с которыми сталкиваются специалисты при организации совместной работы столь разных поколений библиотек:
ИдентификаторыОбъектовМетаданных. В БСП 3.x алгоритмы заполнения и структура этого справочника изменились. При прямых обменах (особенно через COM-соединение) вызовы функций вида ОбщегоНазначения.ИдентификаторОбъектаМетаданных() могут возвращать ошибки, если в базах не завершены процедуры отложенного обновления данных.Чтобы минимизировать риски «смерти» обмена при обновлении одной из конфигураций до БСП 3.x, рекомендуем выполнить следующие действия:
EnterpriseData. Это полностью изолирует логику обмена от внутренних изменений конфигураций.