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

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

2. Рекомендуем ознакомиться со статьей о наиболее распространенных ошибках и затруднениях при подготовке расширений конфигурации, дополнительных отчетов и обработок.

Содержание

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

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

3. Использование форм

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

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

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

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

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

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

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

10.1. Примеры расширений конфигурации

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

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

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

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

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

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

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

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

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

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

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

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

3. Использование форм

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

   Исключением могут быть расширения конфигурации, предназначенные только для использования в тонком клиенте.

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

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

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

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

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

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

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

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

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

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

3. Если определить ресурсы сети Интернет, к которым будет выполняться обращение, невозможно, то:

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

   • для расширений конфигурации, не содержащих форм (например, предназначенных для использования в качестве регламентного задания), рекомендуется:

     • по умолчанию не выполнять операцию в коде серверной команды;
     • создавать дополнительную команду с типом вызова Открытие формы, в которой реализовывать запрос подтверждения;
     • начинать выполнение операции в серверном коде только после подтверждения пользователем выполнений операций.

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

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

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

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

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

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

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

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

10.1. Примеры расширений конфигурации

Примеры расширений конфигурации приведены в статье по ссылке.

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

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

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

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

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

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

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

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

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

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

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

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

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