При работе с расширениями в 1С:Предприятии разработчики часто сталкиваются с проблемой актуализации кода расширений после обновления основной конфигурации. Это особенно актуально, когда модули основной конфигурации, которые были изменены в расширении с помощью аннотаций, меняются при очередном обновлении типового решения. Стандартные проверки, такие как "Проверка возможности применения всех расширений", не всегда обнаруживают эти изменения, что приводит к появлению ошибок уже в режиме пользователя, например: "Текст модуля для метода "" изменился". Давайте разберем эту проблему подробнее и выясним, какие подходы существуют для ее решения.
К сожалению, в конфигураторе 1С:Предприятия отсутствует встроенный инструмент для прямого сравнения основной конфигурации с подключенным к ней расширением. Это означает, что функционал сравнения и объединения, который мы привыкли использовать для двух конфигураций (например, основной и конфигурации поставщика), или для двух расширений, не применим к паре "основная конфигурация — расширение". Поэтому нет и заветной кнопки "Перенести неизменный код из основной в расширения", которую многие из нас хотели бы видеть. Этот факт является одним из основных недостатков механизма расширений с точки зрения удобства поддержки кода.
Данная особенность требует от нас использования косвенных методов и внешних инструментов для отслеживания и актуализации изменений.
Основная задача заключается в том, чтобы до запуска системы обнаружить, какие именно модули или процедуры в основной конфигурации были изменены и как эти изменения повлияли на наш код в расширении. Рассмотрим доступные подходы.
Использование аннотации &ИзменениеИКонтроль
Аннотация &ИзменениеИКонтроль является мощным, хотя и не всегда исчерпывающим, механизмом для контроля изменений. Если процедура или функция в расширении помечена этой аннотацией, то при выполнении команды "Проверка возможности применения всех расширений" система попытается найти расхождения с аналогичной процедурой или функцией в основной конфигурации. В идеале, она должна указать на места, где код основной конфигурации изменился, и это изменение затрагивает или противоречит коду в расширении.
Однако, как показывает практика, эта проверка не всегда "ловила" все изменения, особенно когда текст модуля менялся, но не приводил к прямым конфликтам, при этом ломая логику работы. Тем не менее, это первый и самый важный инструмент, который мы должны регулярно использовать. Помимо &ИзменениеИКонтроль, аннотации &Перед, &Вместо, &После также играют ключевую роль в доработке типового кода, позволяя вклиниваться или заменять его, и их корректность также проверяется.
Внешние инструменты (например, CfeUpdater)
Сообщество 1С-разработчиков создает внешние обработки, которые призваны упростить работу с расширениями. Некоторые из них, например, CfeUpdater (хотя его название может меняться, и могут появляться новые аналоги), разработаны для анализа различий между модулями расширения и базовой конфигурации. Эти инструменты обычно работают на уровне методов, сравнивая их текст и помогая выявить проблемные места. Мы можем использовать такие обработки для получения более детальной информации об изменениях, чем предоставляет стандартная проверка платформы.
Выгрузка в файлы и ручное сравнение
Это один из наиболее трудоемких, но в то же время наиболее надежных методов для выявления изменений. Он заключается в следующем:
.cf, который затем можно развернуть в набор XML-файлов)..cfe, который также можно развернуть в XML-файлы).Этот подход позволяет увидеть все различия, вплоть до каждого символа, и тем самым точно определить, что изменилось в типовом коде и как это влияет на наше расширение.
Хранилище конфигураций
Если мы используем хранилище конфигураций, оно может стать ценным источником информации. В хранилище отслеживается история изменений каждого объекта конфигурации. Мы можем просматривать историю изменений как по всей конфигурации в целом, так и по отдельным модулям. Это позволяет нам косвенно выявлять изменения в типовой конфигурации, которые потенциально могут повлиять на наше расширение. Например, если мы знаем, что наш код в расширении затрагивает ОбщийМодуль_Х, мы можем просмотреть историю этого модуля в хранилище основной конфигурации, чтобы понять, что в нем менялось после предыдущего обновления.
"Экстрактор 1С"
Существуют специализированные инструменты, такие как "Экстрактор 1С", которые предназначены для отслеживания изменений в базе 1С и их автоматической выгрузки во внешнее хранилище. Подобные системы могут помочь автоматизировать процесс сравнения версий и выявления изменений, предоставляя структурированные данные для анализа.
После того как мы идентифицировали изменения в основной конфигурации, следующим шагом является актуализация кода в нашем расширении. Здесь, как правило, требуется ручное вмешательство.
Ручное обновление кода
Это самый распространенный и часто неизбежный метод. После выявления изменений в типовом коде нам, скорее всего, придется вручную корректировать код в расширении. Это может включать:
Этот процесс требует глубокого понимания как типового решения, так и нашей доработки.
Команда "Обновить из файла"
Эта команда используется для обновления самого файла расширения (.cfe). Если мы вносили изменения в расширение вне конфигуратора (например, в текстовом редакторе или с помощью специализированных утилит), или если получили новую версию расширения, то команду "Обновить из файла" можно использовать для загрузки этих изменений в конфигуратор. Однако важно понимать, что эта команда обновляет структуру расширения, но не решает автоматически проблемы с измененным кодом модулей, конфликтующим с основной конфигурацией.
Обновление форм
Если в нашем расширении присутствуют заимствованные формы (например, форма элемента справочника или документа), то после обновления основной конфигурации их также необходимо актуализировать. Для каждой такой формы рекомендуется выполнять команду "Обновить расширение формы". Эта команда позволяет получить актуальный макет формы из основной конфигурации и применить его к заимствованной форме в расширении, сохраняя при этом наши доработки.
Актуализация режима совместимости
При обновлении как основной конфигурации, так и платформы, важно также актуализировать режим совместимости расширения. Если режим совместимости расширения не соответствует режиму совместимости основной конфигурации или платформы, это может привести к ошибкам и невозможности подключения расширения. Мы должны убедиться, что режимы совместимости гармонизированы, чтобы избежать проблем с функциональностью.
Работа с расширениями имеет свои нюансы, которые мы должны учитывать, чтобы минимизировать риски и упростить процесс поддержки.
Платформа 8.3.18 и выше
Начиная с платформы 8.3.14 (и особенно в более поздних версиях, таких как 8.3.18), механизм расширений был значительно улучшен. Разработчики 1С постоянно работают над повышением стабильности и функциональности расширений. В новых версиях платформы стало возможно не включать в расширение большое количество объектов типовой конфигурации, а захватывать только самые необходимые для доработки элементы. Это помогает уменьшить объем кода, требующего контроля и обновления, но не полностью снимает проблему актуализации измененных модулей.
Проблемы с "пустыми строками"
В некоторых ранних версиях платформы (до 8.3.18) существовала специфическая проблема, связанная с различиями в "пустых строках" в модулях, которая могла вызывать ложные срабатывания проверок или ошибки. Хотя пользователь уточнил, что это не его основная проблема, важно знать, что в версии 8.3.18 эта проблема была успешно решена, что повысило общую стабильность работы расширений.
Контролируемые свойства расширения
При создании расширения автоматически копируются и помечаются как контролируемые такие свойства, как "Основной режим запуска", "Назначение использования", "Основной язык", "Режим совместимости интерфейса" и "Режим совместимости". Если значения контролируемого свойства в расширении не совпадают со значением в расширяемой конфигурации, расширение не будет подключено. Мы должны внимательно следить за этими свойствами и при необходимости актуализировать их в расширении.
Сложность доработки и разрешения конфликтов
Несмотря на все удобства расширений, позволяющие сохранять конфигурацию на поддержке, при изменении типовых механизмов всё равно требуется высококвалифицированный специалист для обновления и разрешения конфликтов. Иногда, при значительных изменениях в типовом решении, приходится принимать решение о полной переработке или даже создании нового расширения под новую конфигурацию и платформу.
Возможные "глюки" и ошибки
В работе с расширениями могут возникать различные "глюки" или нестандартные ситуации. Например, может теряться связь расширения с основной конфигурацией, что проявляется в некорректном поведении. В таких случаях иногда помогает установка флага "Проверять значение при подключении расширения" и выполнение действий по исправлению. Также после обновления основной конфигурации могут возникать ошибки типа "Метод объекта не обнаружен", если в ней были перенесены, переименованы или удалены процедуры или функции, на которые ссылается наше расширение. Это требует тщательного анализа стека вызовов и ручной корректировки кода.
В целом, механизм расширений 1С облегчает адаптацию конфигурации без снятия с поддержки, но он не полностью автоматизирует процесс обновления измененных модулей. Мы, как разработчики, должны внимательно отслеживать изменения в типовых решениях и вручную адаптировать наши расширения, используя все доступные инструменты и глубокое понимание особенностей платформы 1С:Предприятие.