Как отследить и перенести исполняемый код из одной конфигурации 1С в другую?

Часто перед разработчиками встает задача переноса определенного функционала из одной конфигурации, например, типовой, в другую — самописную. Проблема в том, что при выполнении одного действия, скажем, по нажатию кнопки, может вызываться целая цепочка процедур и функций из разных модулей. Выделить весь этот код вручную — трудоемкая и чреватая ошибками задача. Рассмотрим, какие существуют подходы для автоматизации этого процесса и какие архитектурные решения можно применить.

Подход 1: Автоматизированный сбор исполняемого кода

Этот метод подходит, если наша цель — именно скопировать код в целевую конфигурацию. Идея заключается в том, чтобы сначала отследить все вызываемые процедуры, а затем автоматически извлечь их тексты из исходных файлов конфигурации.

Основной инструмент — Замер производительности. Это встроенный механизм платформы, который логирует последовательность вызовов кода.

Разберем процесс по шагам:

1. Включаем замер производительности в исходной базе данных.
2. Выполняем целевое действие, например, нажимаем кнопку, функционал которой нужно перенести.
3. Останавливаем и сохраняем отчет о производительности. В результате мы получаем детальный список всех вызванных процедур и функций с указанием их модулей.
4. Выгружаем конфигурацию в файлы. Это стандартная операция, которая позволяет получить исходный код всех модулей в виде текстовых файлов.
5. Парсим отчет и извлекаем код. На этом этапе понадобится написать небольшой скрипт (например, на OneScript или с помощью средств 1С), который будет читать отчет замера, находить в нем имена процедур/функций и вырезать их тексты из соответствующих файлов выгруженной конфигурации.

Важные моменты и сложности:

• Контекст вызова: Необходимо учитывать, где выполняется код — на &НаКлиенте или &НаСервере. Это повлияет на то, в какие модули целевой конфигурации его нужно будет помещать.
• Зависимости от метаданных: Перенесенный код почти наверняка будет обращаться к объектам метаданных (справочникам, документам, регистрам), которые также потребуется перенести в целевую конфигурацию.
• Повторяющиеся имена: В разных модулях могут существовать процедуры с одинаковыми именами. Скрипт должен уметь корректно обрабатывать такие ситуации.
• Библиотека стандартных подсистем (БСП): Если функционал завязан на БСП, перенос может потянуть за собой огромное количество зависимых модулей.

Как видим, это не простое решение, и оно требует серьезных навыков программирования. Более мощным, но и более сложным в настройке инструментом для анализа является Технологический журнал.

Подход 2: Архитектурные решения для взаимодействия баз

Вместо прямого копирования кода можно организовать взаимодействие между базами, чтобы целевая конфигурация вызывала нужный функционал из исходной. Это позволяет избежать проблем с зависимостями.

HTTP-сервисы

Современный и наиболее гибкий подход. В исходной конфигурации публикуется HTTP-сервис, который предоставляет доступ к нужным экспортным функциям. Целевая "самописная" конфигурация отправляет HTTP-запрос с параметрами и получает результат в формате JSON или XML.

Преимущества:

• Слабая связанность систем: Базы могут работать на разных версиях платформы и обновляться независимо.
• Кроссплатформенность: Взаимодействие возможно через интернет, не ограничиваясь локальной сетью.

Недостатки:

• Необходимо передавать все данные в виде простых типов, сериализуя сложные объекты (например, документы или справочники).

COM-соединение

Классический способ для взаимодействия баз данных в пределах одного сервера или локальной сети. Он позволяет напрямую обращаться к экспортным процедурам и функциям другой базы.

// Пример вызова функции из другой базы через COM
Попытка
    V83COM = Новый COMОбъект("V83.COMConnector");
    Соединение = V83COM.Connect("Srvr=""ИмяСервера"";Ref=""ИмяБазы"";Usr=""Пользователь"";Pwd=""Пароль"";");
    
    // Вызываем экспортную функцию общего модуля
    Результат = Соединение.ИмяОбщегоМодуля.ИмяЭкспортнойФункции(Параметр1, Параметр2);
    
    Сообщить(Результат);
Исключение
    Сообщить(ОписаниеОшибки());
КонецПопытки;

Преимущества:

• Прямой вызов функций, что может быть проще в реализации для простых случаев.

Недостатки:

• Жесткая привязка к версии платформы и расположению базы.
• Работает только в ОС Windows и не подходит для веб-клиента.
• Потенциальные проблемы с производительностью и безопасностью.

Подход 3: Использование расширений конфигурации

Если целевая конфигурация находится на поддержке, и мы хотим избежать ее изменения, лучшим решением будет вынести переносимый функционал в расширение. Весь новый код, а также заимствованные или созданные объекты метаданных, инкапсулируются в расширении. Это значительно упрощает последующее обновление основной конфигурации и поддержку решения.

В заключение отметим, что простого "магического" способа вытащить исполняемый код не существует. Для изолированных и небольших функций подойдет ручное копирование с анализом зависимостей. Для сложного функционала лучше рассмотреть архитектурные решения, такие как HTTP-сервисы, или использовать современный механизм расширений, чтобы сделать интеграцию более гибкой и надежной.