Переход на новые версии технологической платформы «1С:Предприятие» — это всегда компромисс между стабильностью текущей работающей системы и желанием (или необходимостью) использовать новые технические возможности. Особенно остро этот вопрос встает, когда на предприятии используется крупная и кастомизированная конфигурация на обычных формах, такая как «Управление производственным предприятием» (УПП 1.3). В рамках данной статьи мы подробно проанализируем все за и против обновления платформы с устаревшей версии 8.3.10 до более современных релизов (вплоть до 8.3.17), разберем ключевые технологические новшества и скрытые угрозы, с которыми могут столкнуться разработчики и системные администраторы.
Переход через несколько мажорных релизов платформы приносит разработчикам множество долгожданных инструментов, которые значительно упрощают разработку, оптимизируют производительность запросов и облегчают кастомизацию систем без снятия их с поддержки.
А. Передача менеджера временных таблиц (МВТ) в СКД
До версии 8.3.17 интеграция заранее подготовленных во внешнем коде временных таблиц в Систему компоновки данных (СКД) была нетривиальной задачей. Разработчикам приходилось прибегать к механизму Набор данных - объект, что требовало вручную описывать структуру таблицы, типы полей, связи и роли непосредственно в схеме компоновки. Это усложняло код и снижало гибкость отчетов.
Начиная с версии 8.3.17, разработчики могут передавать готовый МенеджерВременныхТаблиц напрямую в процессор компоновки. Это позволяет использовать временные таблицы непосредственно в тексте запроса СКД, связывая их через стандартные операторы соединения с физическими таблицами базы данных.
Рассмотрим практический пример реализации этого механизма в коде:
// Шаг 1. Создаем менеджер временных таблиц и наполняем его данными
МенеджерВТ = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВТ;
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура.Ссылка КАК Товар,
| ЕСТЬNULL(Цены.Цена, 0) КАК БазоваяЦена
|ПОМЕСТИТЬ ВТ_ЦеныНоменклатуры
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних КАК Цены
| ПО Цены.Номенклатура = Номенклатура.Ссылка";
Запрос.Выполнить();
// Шаг 2. Инициализируем СКД и передаем Менеджер ВТ в процессор компоновки
СхемаКомпоновки = ПолучитьМакет("ОсновнаяСхемаКомпоновкиДанных");
Настройки = СхемаКомпоновки.НастройкиПоУмолчанию;
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновки, Настройки);
ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
// Четвертый параметр метода Инициализировать - МенеджерВременныхТаблиц
ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, , , Истина, МенеджерВТ);
// Шаг 3. Вывод данных в табличный документ
ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
ТабличныйДокумент = Новый ТабличныйДокумент;
ПроцессорВывода.УстановитьДокумент(ТабличныйДокумент);
ПроцессорВывода.Вывести(ПроцессорКомпоновки);
Важный нюанс: Чтобы компоновщик настроек СКД корректно работал с полями из переданной временной таблицы, в тексте запроса схемы СКД настоятельно рекомендуется явно типизировать поля с помощью функции ВЫРАЗИТЬ() или обрабатывать их функцией ЕСТЬNULL(). В противном случае система может некорректно накладывать быстрые отборы.
Б. Подписки на события в расширениях конфигурации
Внедрение полноценной поддержки подписок на события в расширениях — одно из важнейших архитектурных новшеств. Ранее для перехвата событий объектов (например, при проведении документов или записи элементов справочников) разработчикам приходилось переопределять процедуры модулей через директивы &Перед, &После или крайне небезопасную &Вместо. Это часто приводило к конфликтам при одновременной работе нескольких расширений.
Теперь мы можем создать отдельную подписку на событие внутри расширения, связать её с нужным типом объекта основной конфигурации и назначить обработчик. При этом основная конфигурация остается полностью на замке, что существенно упрощает её последующее обновление.
В. Режим технического специалиста
В управляемом интерфейсе режим, ранее известный как «Все функции», получил не только новое название «Режим технического специалиста», но и важные диагностические функции:
ОткрытьФорму().Несмотря на обилие «бантиков и рюшечек», переход с версии 8.3.10 на 8.3.17 таит в себе серьезные инфраструктурные риски, которые могут парализовать работу крупного предприятия.
А. Жесткие ограничения лицензий уровня ПРОФ
Пожалуй, самым критичным моментом при переходе со старых платформ является принудительное разделение функций на уровне лицензий ПРОФ и КОРП, которое фирма «1С» жестко заблокировала на техническом уровне в новых релизах. Если на платформе 8.3.10 лицензии ПРОФ позволяли использовать практически весь доступный функционал сервера, то на новых платформах вас ждут следующие ограничения:
rphost (например, ограничение памяти на один вызов) на лицензиях ПРОФ принудительно сбрасываются в «0» (без ограничений). В случае утечки памяти в коде это может привести к падению всего сервера вместо перезапуска одного процесса.Б. Прекращение поддержки старых журналов регистрации (формат .elf)
Начиная с версии 8.3.17, платформа полностью прекращает поддержку старых файлов журналов регистрации версий 8.0 и 8.1 (формат .elf). Если на вашем предприятии хранятся архивные файлы журналов в этом формате, система просто не сможет их прочитать. Перед переходом необходимо выполнить конвертацию этих файлов в последовательный формат базы данных SQLite (.lgd) с помощью промежуточных версий платформы или выгрузить их в сторонние хранилища данных.
В. Проблемы с локальным кэшем метаданных
Масштабный прыжок через несколько версий платформы гарантированно приводит к конфликтам кэша на клиентских машинах. Это проявляется в виде немотивированных падений программы, ошибок формата потока или некорректного отображения интерфейсных элементов. Системному администратору потребуется централизованно настроить очистку локального кэша для всех пользователей (например, через скрипты автозапуска или использование параметра запуска /ClearCache).
Многие специалисты ошибочно полагают, что для старых конфигураций, таких как УПП 1.3, обновление платформы не требуется. Однако это не так, и вот почему:
8.3.14 или 8.3.15.8.3.16, и на 8.3.17. Тем не менее, при работе в режиме совместимости с версией 8.2 на поздних платформах могут возникать специфические СУБД-блокировки при групповом проведении документов.По мнению большинства практикующих специалистов, если вам важна максимальная стабильность при работе со старыми конфигурациями, наиболее оптимальным и проверенным выбором на данный момент является переход на платформу 8.3.15 или 8.3.16. Платформа 8.3.17 дает отличные инструменты для разработчиков (такие как МВТ в СКД), но требует тщательного предварительного тестирования в вашей конкретной инфраструктуре.
Для принятия окончательного решения проанализируем баланс преимуществ и рисков:
| Плюсы перехода | Минусы и риски перехода |
|---|---|
| Возможность использовать МВТ непосредственно в запросах СКД. | Принудительное включение лимитов ПРОФ-лицензий (ядра, сеансы, лимиты памяти). |
| Создание чистых подписок на события в расширениях. | Необходимость массовой очистки кэша на всех рабочих местах. |
| Удобная отладка форм через режим технического специалиста. | Потеря совместимости со старыми файлами журнала регистрации (.elf). |
| Исправление старых платформенных ошибок и багов СУБД. | Возможное падение производительности при первом запуске системы после обновления. |
Вывод очевиден: сидеть на платформе 8.3.10 бесконечно не получится из-за требований обновлений конфигураций под актуальное законодательство. Однако совершать переход на 8.3.17 нужно обдуманно, предварительно взвесив ограничения вашей лицензии (ПРОФ или КОРП) и проведя полное тестирование функционала на копии базы данных.