Переход на новые версии технологической платформы 1С — это всегда ответственный шаг, требующий детального планирования, предварительного тестирования и понимания возможных рисков. В конце 2019 года фирма 1С инициировала масштабную волну обновлений типовых конфигураций (таких как Бухгалтерия предприятия версии 3.0.75 и Зарплата и управление персоналом версии 3.1.12), главным условием работы которых стал отказ от режима совместимости с предыдущими версиями платформ и переход на обязательное использование версии 8.3.14 и выше.
В этой статье мы подробно рассмотрим, с какими скрытыми трудностями столкнулись пользователи и разработчики при этом переходе, проанализируем известные критические баги платформ того периода и разберем надежные методы их обхода и исправления.
Давайте проанализируем ситуацию, которая сложилась с выходом релизов БП 3.0.75 и ЗУП 3.1.12. Изначально разработчики ориентировали пользователей на платформу 8.3.14.1694. Однако реальная практика эксплуатации преподнесла администраторам баз данных сюрпризы:
Бухгалтерия предприятия 3.0.75.37 в файле описания изменений жестко потребовал версию платформы не ниже 8.3.15.1747 (рекомендованной стала 8.3.15.1778). Это обусловлено внедрением новой версии библиотеки стандартных подсистем (БСП 3.1.2), стабильная работа которой гарантировалась только на ветке 8.3.15.8.3.14.1694 конфигурация могла успешно запуститься, но при попытке использовать склонение через внешние веб-сервисы (например, популярный сервис «Морфер») система выдавала ошибки выполнения. Для корректной интеграции требовалась сборка не ниже 8.3.14.1970.Чтобы избежать экстренных обновлений в рабочий период, нам необходимо программно контролировать версию платформы у пользователей. Напишем простую процедуру для проверки текущего релиза платформы перед запуском критических процедур:
СистемнаяИнформация = Новый СистемнаяИнформация;
ВерсияПлатформы = СистемнаяИнформация.ВерсияПриложения;
Если ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ВерсияПлатформы, "8.3.15.1747") < 0 Тогда
ВызватьИсключение "Для корректной работы системы требуется платформа версии не ниже 8.3.15.1747! Пожалуйста, обратитесь к системному администратору.";
КонецЕсли;
При переходе на платформу 8.3.15 многие технические специалисты столкнулись с нестабильным поведением информационных баз, использующих обычные формы (например, крупных кастомизированных баз на базе Управление производственным предприятием). Выясним причину этого поведения:
8.3.15 без видимых сбоев и зависаний.8.3.15 и выше необходимо полностью переходить на 64-битную версию клиентского приложения. 64-битный клиент более эффективно распределяет оперативную память и избавляет систему от утечек памяти при работе со сложными механизмами обычного интерфейса.Для тех, кто решает перепрыгнуть сразу на ветку 8.3.16, крайне важным становится знание об одном из самых массовых багов этого релиза (зарегистрированном под кодом 10212820 / HL-32892). Рассмотрим его суть:
При печати документов из терминальных сессий (через подключение по RDP) на принтеры марок Kyocera, Canon, а также на некоторые модели HP, платформа 1С аварийно прекращает работу с ошибкой: «Ошибка при получении характеристик принтера».
Посмотрим на практические способы решения этой проблемы, поскольку официальные рекомендации долгое время сводились к отказу от терминального доступа, что для крупных компаний неприемлемо:
8.3.16.1030 сетевые принтеры, содержащие кириллические символы в имени, переставали печатать без вывода ошибок. Решением является переименование принтеров на сервере печати с использованием исключительно латинских символов.8.3.14 (например, стабильной сборки 8.3.14.2095) или переход на доработанные релизы ветки 8.3.15, где этот баг еще не проявился так остро.Снятие режима совместимости (перевод свойства конфигурации РежимСовместимости в значение «Версия 8.3.14») несет в себе глубокие изменения во внутренней структуре базы данных.
Разберем по шагам ключевые риски для разработчиков:
РасширениеКонфигурации) не может быть выше, чем режим совместимости основной конфигурации. После обновления базы до БП 3.0.75 старые кастомные расширения, созданные с совместимостью под 8.3.12 или ниже, просто откажутся подключаться при запуске, блокируя работу пользователей.Для предотвращения падения базы при обновлении из-за расширений, мы можем написать служебную обработку, которая программно проверяет и корректирует режим совместимости всех установленных в системе расширений перед обновлением:
Для Каждого ТекущееРасширение Из РасширенияКонфигурации.Получить() Цикл
Если ТекущееРасширение.РежимСовместимости <> РежимСовместимости.Версия8_3_14 Тогда
ЗаписьПредупреждения = Новый ЗаписьТекста("C:\temp\extensions_log.txt", КодировкаТекста.UTF8, , Истина);
ЗаписьПредупреждения.ЗаписатьСтроку("Расширение " + ТекущееРасширение.Имя + " требует ручной адаптации под 8.3.14!");
ЗаписьПредупреждения.Закрыть();
КонецЕсли;
КонецЦикла;
Многие системные администраторы, выбравшие для перехода платформу 8.3.16, столкнулись с глухим зависанием рабочих процессов сервера (rphost) или файловой сессии. Выясним причину этой проблемы:
Данный сбой происходит из-за конфликта механизмов автоматического обновления полнотекстового индекса в фоновом режиме. Для устранения зависаний выполним следующие действия:
Для автоматизации этого процесса (например, при выполнении ночных регламентных работ) мы можем использовать следующий программный код:
Если ПолнотекстовыйПоиск.Разрешен() Тогда
ПолнотекстовыйПоиск.ОчиститьИндекс();
ПолнотекстовыйПоиск.ОбновитьИндекс(Истина, Ложь); // Истина - полное обновление, Ложь - не в фоновом режиме
КонецЕсли;
Подводя итоги, сформулируем оптимальную стратегию перехода на платформу 8.3.14/8.3.15:
8.3.14 (сборка 8.3.14.2095 или выше), так как она содержит минимум критических ошибок при работе с очередями печати.БП 3.0.75+) безальтернативно требует 8.3.15, выбирайте исключительно 64-битные клиентские приложения для всех пользователей во избежание утечек памяти и аварийных вылетов интерфейса.