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

Пример 1: доработка типовой конфигурации для работы в сервисе

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

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

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

Пример работы в веб-клиенте

Постановка задачи

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

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

Длительная операция, работающая на сервере

Постановка задачи

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

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

Регламентное задание

Постановка задачи

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

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

Поэтому, необходимо заменить разделенные регламентные задания по следующему сценарию:

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

Так регламентные задания будут выполняться поочередно в автоматическом режиме и не допустят перегрузку системы.

Поставляемые данные

Постановка задачи

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

С внедрением технологии 1cFresh у сети нет необходимости так мелко делить статьи затрат, так как в системе есть специальная подсистема поставляемых данных, с помощью которой часть НСИ (нормативно-справочной информации) может быть получена из внешних источников. Причем происходит это централизованно, сразу для всех областей данных (всех предприятий холдинга), всех прикладных решений, которые заинтересованы в получении этого вида данных. Для более простой загрузки статей затрат, они будут перенесены вручную администратором менеджера сервиса из xml-файла.

Пример 2: доработка нетиповой конфигурации для работы в сервисе

Во втором варианте, представим, что у нас существует собственная нетиповая конфигурация, которая нравится пользователям и отлично работает в локальном режиме. Соответственно, мы хотим в сервис 1cFresh, чтобы с ней могли работать в модели сервиса как можно больше пользователей. Увы, но просто перенести конфигурацию не получится. Для успешного переноса необходимо внедрить БСП (библиотеку стандартных подсистем) и БТС (библиотеку технологий сервиса), которые содержат нужные объекты и функциональность для работы приложения в сервисе. Также конфигурация должна отвечать требованиям, которые выдвинуты для работы в модели сервиса.

Для примера возьмем конфигурацию - Практическое пособие разработчика.

Для переноса нетиповой конфигурации, нам необходимо:

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

Внедрение БСП и БТС

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

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

Настройка перенесенных объектов БСП

На первом этапе мы выполнили перенос объектов из БСП и БТС. Далее, нам нужно их настроить согласно документации БТС. На этом этапе мы выполняем настройку перенесенных объектов из БТС согласно документации, которая находится в подкаталоге ExtFiles в составе дистрибутива БТС.

Доработка командного ролевого интерфейса, начальной страницы и основного раздела

Так как в нашей системе появились новые роли, нам необходимо скорректировать командный интерфейс.

Роль "Полные Права" настроена под получение прав всеми пользователями, которые имеют статус администратора в локальном режиме и модели сервиса. Здесь изменения не требуются

Роль "Базовые Права" дает права на просмотре подсистемы Контактная Информация. Здесь мы добавляем права на просмотр общей формы Персональные Настройки и формы Описание Изменений Программы.

Роль "Работа С Папками Файлов" даем права на просмотр подсистемы Файлы.

Проверка функционирования конфигурации в локальном режиме

Добавление пользователей

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

Для этого нужно следовать следующему сценарию:

• в панели навигации основного раздела выполним команду Пользователи.
• выполним команду списка пользователей Еще – Пользователи информационной базы (так мы увидим всех пользователей)
• выделяем в этом списке нужного пользователя
• в его карточке снимем фильтр Только выбранные роли и назначаем этому пользователю еще роли Базовые права и Добавление и изменение видов контактной информации
• нажмем кнопку Записать и закрыть. 

Проверка функционирования приложения в сервисе

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

Пример 3: приложение сервиса в качестве бэк-энда мобильных приложений

В третьем примере мы рассмотрим вариант взаимодействия с сервисом не самим пользователем. а через приложения. Такое взаимодействие реализовано в типовом мобильном приложении "1С:Управление небольшой фирмой" (УНФ), выпускаемом фирмой "1С". Мобильное приложение УНФ подходит для постоянного резервного копирования данных и для полного обмена данными между несколькими мобильными приложениями. Давайте рассмотрим работу приложения УНФ более подробно.

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

Заключение

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