Как дорабатывать конфигурации в 1С:Fresh: особенности кастомизации и прохождения аудита

← На главную

Переход из традиционных локальных («коробочных») версий систем «1С:Предприятие» в облачную инфраструктуру «1С:Fresh» (1С:Предприятие через Интернет) часто вызывает множество вопросов и даже опасений у разработчиков и системных интеграторов. Бытует ошибочное мнение, что облачная среда абсолютно «закрыта» для кастомизации и не позволяет адаптировать программу под уникальные бизнес-процессы клиента. Однако это не так.

В этой статье мы подробно разберем, как устроена технология доработки в сервисе «1С:Fresh», проанализируем ключевые ограничения безопасного режима, рассмотрим пошаговый процесс подготовки внешних обработок и расширений, а также детально изучим процедуру прохождения обязательного технического аудита фирмы «1С».

Главные особенности и ограничения архитектуры 1С:Fresh

Для начала давайте разберемся с базовым понятием. Сервис «1С:Fresh» работает по модели SaaS (Software as a Service — программное обеспечение как услуга). Это так называемое «коммунальное» облако: множество информационных баз различных клиентов физически функционируют на едином мощном кластере серверов фирмы «1С». Из этого вытекают жесткие требования к стабильности и безопасности всей системы. Ошибка одного разработчика в неоптимальном коде не должна замедлить работу сотен других компаний на сервере или, что еще хуже, привести к утечке конфиденциальных данных.

Из-за такой архитектуры накладываются принципиальные технические ограничения:

Отсутствие Конфигуратора: Разработчик не может просто открыть базу клиента через Конфигуратор и внести изменения напрямую в основную конфигурацию. Работа ведется исключительно через тонкий клиент или веб-браузер.
Использование только типовых конфигураций: Сама конфигурация (например, «1С:Бухгалтерия» или «1С:УНФ») остается строго типовой и обновляется фирмой «1С» в автоматическом режиме централизованно.
Кастомизация через расширения и внешние инструменты: Любые изменения бизнес-логики, новые печатные формы, документы, справочники и отчеты должны создаваться исключительно с помощью механизма расширений конфигурации, дополнительных отчетов и обработок.

Технические требования к коду: почему обычные обработки не подойдут

Давайте проанализируем, почему стандартную обработку или расширение, написанные для локальной базы, нельзя просто так загрузить во «Фреш». При попытке интеграции система потребует обязательного прохождения аудита, к которому предъявляются очень жесткие требования безопасности. Рассмотрим основные из них:

1. Работа исключительно в безопасном режиме

Все расширения и внешние обработки запускаются в облаке в безопасном режиме (БезопасныйРежим = Истина). В этом режиме платформа блокирует потенциально опасные операции:

Запрещен прямой вызов COM-объектов. Вы не сможете написать конструкцию типа Новый COMОбъект("Excel.Application") для загрузки или выгрузки данных.
Запрещено прямое обращение к файловой системе сервера (чтение и запись файлов на диски сервера, создание временных папок методами операционной системы).
Запрещено использование некоторых методов платформы, способных нарушить стабильность системы или безопасность данных.

2. Клиент-серверное разделение и асинхронность

Поскольку пользователи работают в веб-клиенте, код должен быть адаптирован под веб-стандарты. Любые интерактивные действия (выбор файла на компьютере пользователя, открытие диалогов, предупреждения) должны выполняться строго асинхронно с использованием неблокирующих методов.

Давайте посмотрим на пример правильной организации загрузки файла на сервер в асинхронном режиме:


&НаКлиенте
Процедура НачатьЗагрузкуФайла(Команда)
    ПараметрыЗагрузки = Новый ПараметрыПомещенияФайла;
    ОписаниеОповещения = Новый ОписаниеОповещения("ПослеПомещенияФайла", ЭтотОбъект);
    НачатьПомещениеФайлаНаСервер(ОписаниеОповещения, , , ПараметрыЗагрузки, УникальныйИдентификатор);
КонецПроцедуры

&НаКлиенте
Процедура ПослеПомещенияФайла(Результат, Адрес, ВыбранноеИмяФайла, ДополнительныеПараметры) Экспорт
    Если Результат Тогда
        ОбработатьФайлНаСервере(Адрес);
    Иначе
        ПоказатьПредупреждение(, "Файл не был загружен!");
    EndIf;
КонецПроцедуры

3. Использование уникальных префиксов

Чтобы избежать конфликтов имен (коллизий), когда разные разработчики создают свои расширения для одной и той же базы данных, фирма «1С» требует использовать уникальные префиксы. Все создаваемые вами новые реквизиты, справочники, документы, общие модули, процедуры и переменные должны начинаться с префикса, назначенного вашей компании (например, ПрефиксРазработчика_ИмяРеквизита).

4. Исключительная открытость кода

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

5. Ограничения при работе с запросами (RLS)

При написании любых запросов к базе данных разработчик обязан использовать ключевое слово РАЗРЕШЕННЫЕ. Это гарантирует, что запрос не вызовет критическую ошибку прав доступа, если у текущего пользователя ограничены права на уровне записей (Row-Level Security).

Как подготовить разработку к публикации: пошаговый алгоритм

Давайте разберем по шагам весь процесс подготовки внешней обработки к загрузке в «1С:Fresh».

Шаг 1. Разработка и адаптация

Создаем внешнюю обработку или расширение в локальной базе (которая должна иметь точно такую же версию конфигурации, как и база в облаке). Код пишется в строгом соответствии с требованиями стандартов разработки фирмы «1С». Особое внимание уделяем функции СведенияОВнешнейОбработке() в модуле объекта. Именно в ней декларируются параметры регистрации обработки в системе.

Рассмотрим пример правильного заполнения этой функции для безопасного режима:


Функция СведенияОВнешнейОбработке() Экспорт
    ПараметрыРегистрации = ДополнительныеОтчетыИОбработок.СведенияОВнешнейОбработке("2.2.2.1");
    ПараметрыРегистрации.Вид = ДополнительныеОтчетыИОбработкиКлиентСервер.ВидОбработкиДополнительнаяОбработка();
    ПараметрыРегистрации.Наименование = "Безопасный импорт данных";
    ПараметрыРегистрации.Версия = "1.0.0.1";
    ПараметрыРегистрации.БезопасныйРежим = Истина;
    
    НоваяКоманда = ПараметрыРегистрации.Команды.Добавить();
    НоваяКоманда.Представление = "Открыть помощник импорта";
    НоваяКоманда.Идентификатор = "ОткрытьПомощник";
    НоваяКоманда.Использование = ДополнительныеОтчетыИОбработкиКлиентСервер.ТипЗапускаОткрытиеФормы();
    
    Возврат ПараметрыРегистрации;
КонецФункции

Шаг 2. Использование специальной утилиты подготовки

Напрямую файл формата .epf или .erf отправить на аудит нельзя. Для этого используется специальная обработка от фирмы «1С» под названием ПодготовкаДополнительныхОтчетовИОбработокКПубликацииВМоделиСервиса.epf. Партнеры сервиса скачивают её непосредственно при инициализации процедуры добавления разработки клиента.

С помощью этой утилиты мы:

Указываем наш файл обработки.
Заполняем подробное описание назначения разработки.
На выходе получаем заархивированный пакет (файл формата .zip), внутри которого находится сам исполняемый файл разработки и технический файл манифеста в формате .xml, содержащий описание и параметры регистрации.

Шаг 3. Загрузка в Менеджер сервиса

Подготовленный .zip-архив загружается через личный кабинет (Менеджер сервиса). На этом этапе система автоматически выполняет первичный автоматический анализ структуры архива на предмет критических ошибок заполнения манифеста.

Прохождение технического аудита: как устроен процесс

После успешной загрузки пакета в Менеджер сервиса он отправляется в очередь на технический аудит, выполняемый сотрудниками фирмы «1С».

Этапы проверки кода аудиторами:

Проверка безопасности: Эксперты детально анализируют код на отсутствие попыток обхода безопасного режима, несанкционированного доступа к данным других пользователей облака и деструктивных действий.
Анализ производительности: Запросы проверяются на оптимальность (наличие индексов, отсутствие соединений с виртуальными таблицами в циклах и т.д.). Бесконечные циклы или запросы, способные «положить» сервер базы данных, гарантированно приведут к отклонению заявки.
Проверка логики работы: Оценивается корректность интеграции с типовыми механизмами БСП (Библиотеки стандартных подсистем).

Обычно ручной аудит занимает от 2 до 3 рабочих дней. По результатам проверки возможны два исхода:

Успешное прохождение: Разработка получает статус «Одобрено», после чего её можно централизованно подключить к нужным информационным базам пользователей прямо из панели администрирования Менеджера сервиса.
Отклонение с замечаниями: Разработчик получает на электронную почту и в личный кабинет подробный протокол с указанием строк кода, содержащих ошибки или несоответствия стандартам. После исправления замечаний процедура подготовки архива и отправки на аудит повторяется.

Современные инструменты для ускорения аудита

Чтобы сберечь время программистов, фирма «1С» внедрила современные инструменты автоматизации:

Плагин для 1С:EDT (Enterprise Development Tools): Данная среда разработки оснащена встроенным плагином валидации кода под стандарты «1С:Fresh». Он позволяет «подсветить» опасные конструкции и запрещенные методы еще на этапе написания кода в IDE, минимизируя вероятность отклонения при реальном аудите.
Частично автоматический аудит обновлений: Если вы отправляете на аудит новую версию расширения, в котором изменилась лишь небольшая часть кода, интеллектуальная система сравнивает изменения с предыдущей, уже одобренной версией. Если измененные модули не содержат опасных вызовов, обновление одобряется в автоматическом режиме за считанные минуты.

Альтернативное решение: Автономное рабочее место

Что делать, если у клиента есть критически важная и очень сложная локальная обработка (например, завязанная на работу со специфическим торговым оборудованием по COM-порту), которую технически невозможно или экономически нецелесообразно переписывать под строгие требования облака?

Для таких сценариев в «1С:Fresh» предусмотрено изящное архитектурное решение — Автономное рабочее место. Схема его работы выглядит следующим образом:

На локальном компьютере пользователя создается копия базы данных.
Эта база регулярно и незаметно для пользователя синхронизируется в фоновом режиме с основным облаком «1С:Fresh».
Пользователь запускает локальную копию базы, спокойно выполняет в ней работу со своими сложными локальными обработками и оборудованием без каких-либо облачных ограничений.
После завершения операций измененные данные автоматически реплицируются (передаются) обратно в облачную базу «1С:Fresh».

Подводя итог, можно с уверенностью сказать: разработка под «1С:Fresh» требует от программиста более высокой культуры написания кода и четкого следования стандартам проектирования систем. Однако эти требования полностью оправданы надежностью, безопасностью и масштабируемостью, которые получает бизнес при переходе на облачные технологии.