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

Содержание

1. Общие требования

Расширения конфигурации создаются на локальном компьютере разработчика с помощью конфигуратора «1С:Предприятие 8» и сохраняются в файл с расширением имени cfe.

Расширение конфигурации необходимо разрабатывать:

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

Для разработки и использования расширений конфигурации необходима технологическая платформа «1С:Предприятие 8» версии 8.3.6 или более новая (рекомендуется версия «1С:Предприятия 8» 8.3.8 или более новая).

2. Использование безопасного режима

1. Расширение конфигурации должно быть полностью работоспособно при исполнении в безопасном режиме и в небезопасном режиме (если требуется) с учетом требований работы с внешними ресурсами.

3. Требования для проведения аудита

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

   • поставлять модули без исходных текстов или с установленным паролем на модуль;
   • использовать средства запутывания (обфускации) исходных текстов.

4. Требования к ресурсоемкости

1. Расширение конфигурации не должно приводить к чрезмерной нагрузке на компоненты сервиса или клиентское приложение.

2. Предельные значения для каждого серверного вызова в расширении в сервисе 1cfresh.by:

   Параметр	Предельное значение
   Длительность серверного вызова	2 400 c
   Процессорное время серверного вызова	600 c
   Длительность вызовов СУБД	1 200 с
   Длительность вызовов сервисов	600 с
   Объем используемой памяти	4 194 304 Кбайт
   Объем информации, записанной на диск	20 971 520 Кбайт

   При превышении предельных значений серверный вызов прерывается (но сам сеанс продолжает жить).

5. Требования к работоспособности

1. Расширение конфигурации не должно нарушать корректную работу приложения, в котором оно установлено.
2. Все длительные операции в расширении конфигурации должны использовать механизм длительных операций из БСП (при длительности 10 секунд и более).
3. Если расширение конфигурации предназначено только для использования в тонком клиенте, то при запуске в веб-клиенте они должны корректно уведомлять пользователя об этом ограничении, а не завершаться с ошибками.

6. Требования к передаче данных за пределы сервиса

1. Если в расширении конфигурации выполняется передача любых данных за пределы сервиса, то эти операции должны подтверждаться пользователем.
2. Если передача данных за пределы сервиса выполняется из кода, выполняемого на сервере, то при добавлении расширения необходимо запросить разрешения на отправку данных и указать адреса, по котором будут выполняться запросы. Передача данных за пределы сервиса из кода, выполняемого на сервере, на адреса, не указанные при добавлении расширения, не поддерживается.
3. Если передача данных за пределы сервиса выполняется из кода, выполняемого на клиенте, то необходимо запросить разрешение у пользователя перед фактической отправкой запроса. Ответ пользователя можно сохранить и при повторном обращении к тому же внешнему ресурсу разрешение не запрашивать.

7. Расширения, изменяющие структуру данных

Если расширение конфигурации изменяет структуру данных, то необходимо:

1. Заимствовать в расширение план обмена МиграцияПриложений.
2. Включить все добавленные расширением объекты в состав плана обмена МиграцияПриложений, установив для режима регистрации этих объектов Авторегистрация значение Запретить.

8. Юридические требования

Расширение конфигурации не должно содержать:

1. Кода, который может повлечь несанкционированное уничтожение, блокирование, модификацию или неправомерное копирование компьютерной информации.
2. Кода, который может дестабилизировать работоспособность сервиса.
3. Кода и данных, которые могут нарушать права третьих лиц, в том числе их авторское право.
4. Охраняемые законом сведения, в том числе коммерческую тайну или персональные данные третьих лиц.

9. Требования к тестированию

После того, как расширение конфигурации разработано, разработчик должен их проверить. Для проверки необходимо:

1. Развернуть сервер «1С:Предприятия 8» версии, максимально близкой к используемой в сервисе.
2. Развернуть клиент-серверную информационную базу той конфигурации, для которой предназначено расширение конфигурации, и той версии конфигурации, которая используется в сервисе.
3. Выполнить веб-публикацию этой информационной базы (кроме случая, когда расширение конфигурации предназначено только для работы в тонком клиенте).
4. Для каждого профиля пользователя, под которым в модели сервиса будет выполняться расширение конфигурации, необходимо создать в информационной базе пользователя с таким же набором ролей, но без роли АдминистраторСистемы (эта роль при работе в модели сервиса у обычных, т. е. разделенных, пользователей недопустима).

Для каждого пользователя, созданного в п. 4, необходимо проверить работоспособность и корректность выполнения функционала, заложенного в расширение конфигурации.

10. Методические рекомендации

10.1. Рекомендации по разработке

1. При разработке расширения конфигурации рекомендуется применять версию платформы «1С:Предприятие 8» и версию конфигурации прикладного решения, используемые в сервисе.
2. Используйте программный интерфейс БСП и прикладных конфигураций. При этом вам не придется переписывать код расширения конфигурации каждый раз после обновления типовых конфигураций.
3. Если расширение конфигурации содержит формы, «выдерживайте» их в стиле конфигурации, для которой разработано расширение. Например, если в конфигурации принято команду «Записать и закрыть» располагать в верхней части формы, не размещайте ее в нижней части формы расширения конфигурации.
4. Имена расширений конфигурации должны быть уникальными. Присваивайте расширениям конфигурации имена, которые не совпадут с именами, которые могут использовать другие разработчики расширений конфигурации.
5. Соблюдайте стандарты разработки (см. по ссылке).

10.2. О копировании кода из типовой конфигурации

1. Если в типовой конфигурации есть готовая функция, которую можно вызвать, копировать ее в расширение конфигурации не нужно.

2. Если код, который есть в типовой конфигурации, подходит не полностью, очень осмотрительно подходите к вопросу копирования существующего кода:

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

10.3. Работа с базой данных

1. При связанном изменении нескольких элементов данных, которое должно происходить атомарно, используйте транзакции.
2. При изменении данных, которые могут редактироваться пользователями параллельно с выполнением расширения конфигурации, устанавливайте объектные блокировки.
3. Обязательно уделяйте внимание оптимальности запросов: учитывайте, что, в отличие от локального режима, информационная база в сервисе используется большим количеством пользователей. Подробнее об оптимизации запросов см. в статьях 1С:ИТС по ссылке.

10.4. Работа в веб-клиенте

1. Если действия на сервере могут выполняться продолжительное время, используйте механизм длительных операций БСП. В противном случае приложение может закрыться по ошибке таймаута веб-сервера.
2. Если расширение конфигурации могут использоваться при работе в веб-клиенте, то все ключевые возможности расширения конфигурации должны быть доступны пользователям без использования расширения работы с файлами.

10.5. О безопасности данных пользователя

1. Не предоставляйте конечному пользователю такие расширения конфигурации, с помощью которых он сможет испортить данные в своем приложении. Примеры:

   • универсальные «перенумераторы» и «перепрефиксаторы»;
   • поиск и замена значений;
   • универсальные редакторы значений реквизита;
   • удаление помеченных объектов без контроля ссылочной целостности.
2. Желательно четко ограничивать функциональность расширений конфигурации, которые меняют данные пользователя. Например, если пользователю нужно перенумеровать кассовые документы, сделайте расширение конфигурации, которая будет делать именно это, без лишней универсальности.