Публикации

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

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

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

Содержание

Общие требования
Использование безопасного режима
Требования для проведения аудита
Требования к ресурсоемкости
Требования к работоспособности
Требования к передаче данных за пределы сервиса
Юридические требования
Требования к тестированию
Методические рекомендации

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

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

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

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

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

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

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

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

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

В частности, не допускается:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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