1с авторизация при входе в мобильное приложение. История одного приложения: мобильное «1С: Управление нашей фирмой

Введение

В новой версии платформы 1С (8.3.5) появилось много нового функционала. Кстати, для тех кто не знает, есть ресурс , на котором разработчики 1С описывают появляющиеся новшества в платформе. Одним из таких является механизм . Он привлек мое внимание, захотелось что-то реализовать for fun. Сразу пришла идея сделать что-то похожее на сайт, но с этой идеей меня не поняли бы даже на инфостарте, поэтому я выкинул ее из головы. Казалось, что выкинул, но идея трансформировалась в нечто не такое маштабное, что-то такое, что может найти реальное применение в жизни - мобильное веб-приложение.
Я считаю, что малонагруженное и простое мобильное веб-приложение, для ограниченного количества пользователей, например, сотрудников, может быть реализовано в 1С с помощью HTTP-сервисов.

Мобильное веб-приложение "Контакты"

Начну с результата. Мобильное веб-приложение "Контакты" выглядит просто, собственно таковым и является. В начале вы видите только поле для поиска контакта.

Поищем кого-нибудь (для того чтобы поиск начался нужно ввести не меньше 3 символов). Кто-то нашелся.

Позвоним Алексею.

Напишем письмо Тимофею.

Вот и всё мобильное веб-приложение.

Кстати, его очень просто адаптировать под любую конфигурацию.

Немного о реализации

Используемые средства:
- Механизм HTTP-сервисов платформы 1С (начиная с версии 8.3.5)
- JavaScript библиотека jQuery (http://jquery.com)
- JavaScript библиотека jQuery mobile (http://jquerymobile.com)
- 1С:JSON ()

HTTP-сервис "Конткаты" принимает все запросы и передает их в обработку "КонтактыМВП". В обработке "КонтактыМВП" сосредоточена вся логика мобильного веб-приложения.

Так выглядит обработка запроса.

Функция ОбработатьЗапрос(Запрос) Экспорт Если СоответствуетРесурсу(Запрос, "/index.html") Тогда Возврат ПолучитьРесурсIndexHTML(); ИначеЕсли СоответствуетРесурсу(Запрос,"/application.js") Тогда Возврат ПолучитьРесурсApplicationJS(); ИначеЕсли СоответствуетРесурсу(Запрос,"/contacts.json") Тогда Возврат ПолучитьРесурсContactsJSON(Запрос); КонецЕсли; КонецФункции

А так, например, выглядит возврат страницы index.html.

Функция ПолучитьРесурсIndexHTML() Ответ = Новый HTTPСервисОтвет(200); Текст = ПолучитьМакет("IndexHTML").ПолучитьТекст(); Ответ.УстановитьТелоИзСтроки(Текст); Ответ.Заголовки.Вставить("Content-Type", "text/html"); Возврат Ответ; КонецФункции

Ничего сложного. Более детально вы можете изучить механизм загрузив КонтактыМВП.dt

Особенности публикации

При публикации HTTP-сервиса возникли небольшие сложности, чтобы вам было проще изложу некоторые замечания:
- В есть достаточно подробные описания о публикации - читайте внимательнее.
- Не забывайте перед публикацией запустить конфигуратор от имени администратора.
- Запустить HTTP-сервис удалось только с файловой версией, с клиент-серверной возникала какая-то ошибка.
- Для того чтобы мобильное веб-приложение работало без запроса авторизации, если в базе есть заведенные пользователи, то после публикации, в файле default.vrd в строку подключения (point.ib) необходимо добавить параметры Usr и Pwd.

Заключение

Надеюсь материал статьи будет вам полезен.

Спасибо за внимание.

Предварительные настройки

Перед началом работы на мобильном устройстве необходимо установить корневой сертификат сервиса «1С: Линк».

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

Особенности настройки мобильных приложений1С: Заказы

• В информационной базе перейдите в раздел "Администрирование", выберите пункт меню "CRM и продажи", поставьте галочку "Разрешить синхронизацию данных с мобильным приложением 1С: Заказы клиентов", нажмите на ссылку "Настройки синхронизации" и добавьте настройку для пользователя.
• Логин: логин пользователя 1С
• Настройка "1С:ЛИНК" включена
• Имя туннеля:
• Настройка "SSL" должна быть включена для работы с ИБ по протоколу HTTPS и выключена для работы по HTTP
• Каталог:

Мобильный Документооборот

• В настройках информационной базы включите работу с мобильным клиентом.
  Для этого зайдите в информационную базу под пользователем с правами администратора, выберите пункт меню "Настройка и администрирование" - "Настройка программы" - "Обмен данными" и поставьте галочку "Использовать мобильные клиенты"
• Адрес подключения: https://.сайт/
• Логин: логин пользователя 1С
• Пароль: его пароль

Обратите внимание, что для работы с мобильным приложением у вас должна быть установлена версия 1С: Документооборота 8 не ниже, чем 1.3.1.3 КОРП

1С: УНФ

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

1С: Монитор ERP

• Логин: логин пользователя 1С
• Пароль: его пароль
• Настройка "1С:ЛИНК" включена
• Имя туннеля:
• Каталог:

​

Клиент бухгалтерии 1cfresh

Для синхронизации с Бухгалтерией предприятия, опубликованной в 1С: Линк можно воспользоваться мобильным приложением "Клиент бухгалтерии 1cfresh".

• В настройках мобильного приложения "Клиент бухгалтерии 1cfresh" перейдите в раздел "Другой сервис"
• В поле "адрес базы для подключения" укажите https://имя туннеля.link.1c.ru/путь-веб-приложения (без ru_RU)
• Укажите логин и пароль пользователя информационной базы и нажмите кнопку подключиться.

​
​

Практика разработки мобильного приложения 1С 8.3 (часть 1)

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

Изначально был выбран «неправильный» подход с компилированием приложения и закидыванием его на планшетник вручную. Напомню, что для сборки мобильных приложений используется «Помощник создания мобильного приложения» (MobileAppWizzard ). Затем на одном из форумов было найдено красивое решение с использованием мобильного приложения для разработки. Это приложение входит в комплект установки мобильной платформы. На момент разработки использовалась платформа версии 8.3.3.24. В папке «Android » можно найти файл 1cem.apk. Это и есть мобильное приложение для разработки. Его огромнейший плюс, сэкономивший нам уйму времени — в том, что можно опубликовать мобильное приложение на веб-сервере, а на планшетнике указать путь вида http://[ Адрес веб-сервера ]/[ Имя мобильного приложения ].

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

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

Что требовалось:

1. Настроить обмен между центральной базой и мобильным устройством.

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

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

На этапе тестирования использовалась промежуточная база «Управляемое приложение», ввиду того что демо-приложение 1С:Заказы изначально заточено на обмен именно с Управляемым приложением.

Первый блин вышел комом. В прямом смысле. Для обмена с центральной базой был использован v82.ComConnector. Не буду вдаваться в подробности его настройки, об этом есть куча отдельных материалов. Пройдусь только по тем трудностям, с которыми столкнулся.

1. Использование com- объектов на 64-битной серверной ОС. Для решения проблемы была использована обертка COM+ Applications, которая настраивается в Component Services.

2. Удаленный вызов Com с другого сервера. Вызываемый сервер должен иметь роль Application Server, и у него должно быть настроено COM+ Network Access. Кроме того, сервер Apache должен иметь соответствующие права (т. е. запускаться как сервис от имени авторизованного пользователя)

Намучившись с Ком-соединениями, решили переводить рабочую базу на web- сервисы.

О публикации веб-сервисов также написано очень много, но там написано о том, как работает. Как НЕ работает, поделюсь ниже.

Рабочая база развернута на платформе 8.2, мобильное приложение, соответственно, на 8.3.

При публикации вначале приложения 8.3, а затем 8.2. периодически выхватывали глюк «Ошибка формата потока» в веб-клиенте 8.3, либо сообщение об ошибке «различаются версии платформы клиента и сервера». Перепубликация не помогает, равно как и перезапуск Apache. А вот отключение публикации и подключение заново — помогает.

Далее, поймал забавную ошибку при авторизации пользователя (при создании ws Определения). При тестировании на компьютере, авторизация с длинным ФИО проходит легко. При попытке авторизации этого же пользователя с планшетника под управлением Android, авторизация заканчивалась, не начавшись. Экспериментальным путем удалось вычислить, что кириллицей длина логина ограничена 22 символами. При этом сочетание кириллических символов и цифр дало авторизоваться с логином длиной 27 символов. Есть подозрение, что это связано с преобразованием кириллических символов. Так, например, в браузере Firefox строка из Википедии « иво» преобразуется в « ».

Технологически, мобильная платформа 8.3.3 на текущий момент имеет ряд ограничений. Самое ожидаемое, на мой взгляд, нововведение — это поддержка запросов. Но, поскольку произвольные запросы в динамических списках мобильная платформа пока не поддерживает, пришлось «пойти другим путем».

Для решения задачи отображения справочника номенклатуры с ценами и остатками был использован следующий подход:

1. В форме справочника номенклатуры созданы две таблицы. Первая — динамический список, собственно сам справочник. Фильтр динамического списка настроен так, чтобы выводились только группы. Вторая таблица — собственно остатки и цены. При активизации строки динамического списка, на сервере происходит заполнение таблицы значений, которая затем и выводится во вторую таблицу. При получении цен и остатков использовалась объектная модель. Все эти танцы с бубном были исполнены только потому, что привычного по толстому клиенту метода «при выводе строки» или «при получении данных» нет, и динамически нарисовать цифры в колонке нельзя.

Аналогичный подход использовался и в форме подбора

2. Для вывода строки с текущими ценами отлично подошла ФорматированнаяСтрока.

Ниже — пример кода.

&НаСервереБезКонтекста Функция ОстаткиПриАктивизацииСтрокиНаСервере(ном) НаборЗаписей = РегистрыСведений.ЦеныТоваров.СоздатьНаборЗаписей(); НаборЗаписей.Отбор.Товар.Значение = ном; НаборЗаписей.Отбор.Товар.Использование = Истина; НаборЗаписей.Прочитать(); МассивФорматированныхСтрок = Новый Массив; Для Каждого СтрокаНабора Из НаборЗаписей Цикл МассивФорматированныхСтрок.Добавить(Новый ФорматированнаяСтрока(СтрокаНабора.ВидЦен.Наименование,WebЦвета.Синий)); МассивФорматированныхСтрок.Добавить(Новый ФорматированнаяСтрока(" " + Строка(СтрокаНабора.Цена) + " ")); КонецЦикла; Возврат Новый ФорматированнаяСтрока(МассивФорматированныхСтрок); // Вставить содержимое обработчика. КонецФункции

3. Для загрузки справочников, остатков и цен в мобильное приложение был использован веб-сервис, который на входе получает структуру параметров, а на выходе возвращает хранилище значения. Еще одним неприятным открытием стал вылет обмена при слишком длительной обработке на стороне сервера. Сложилось впечатление, что имеется какой-то таймаут, после которого приложение «считает», что связь прервана (хотя на самом деле все еще идет обработка данных в рабочей базе через ws -соединение), и прекращает обмен с ошибкой.

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

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

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

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

Как и большинство мобильных приложений, написанных на кросс-платформенной мобильной платформе 1С:Предприятия, мобильный УНФ доступен на iOS, Android и Windows.

Задача была поставлена так: сделать мобильное приложение, поддерживающее часть сценариев работы «большого» УНФ. Приложение должно уметь работать как автономно, так и синхронизировать данные с «большим» УНФ (далее слово «большой» применительно к клиент-серверной версии УНФ я буду писать без кавычек, чтобы не перегружать текст). В случае работы с большим УНФ должны поддерживаться сценарии «мобильных» сотрудников – торгового представителя, сервисного инженера, продавца.

Первая версия была создана за 1 человеко-месяц. При создании мобильного приложения часть объектов метаданных (справочники, документы) была реализована на основе объектов большого УНФ. Но часть функциональности пришлось программировать с нуля, например, процесс обмена данными с большим УНФ. Правда, применительно к обмену данными собственно программировать пришлось немного – мы использовали стандартные механизмы платформы (в частности, планы обмена), сводящие написание кода к минимуму.

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

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

Мобильный УНФ широко использует функциональность мобильного устройства, в частности:

• Встроенную камеру устройства можно использовать для фотографирования товара при заполнении карточки товара, для чтения штрих- и QR-кодов
• Счет на оплату можно отправить клиенту по емейл или через SMS
• Контрагента можно выбрать из адресной книги мобильного устройства
• Если у контрагента задан телефон – можно одним касанием позвонить контрагенту или послать SMS, если задан емейл – отправить письмо, если задан адрес – показать его на карте
• Можно печатать документы на принтерах через WiFi и Bluetooth

Есть опция бэкапа и восстановления базы мобильного УНФ на Яндекс.Диск и отправка базы по почте.

Конфигурация мобильного УНФ выглядит достаточно спартански (см. скриншот ниже):

• 8 справочников (в большом УНФ – 273 справочника)
• 7 документов (в большом УНФ – 125)
• 3 журнала документов (в большом УНФ – 24)
• 3 регистра сведений (в большом УНФ – 357)
• 4 регистра накопления (в большом УНФ – 64)

Основные объекты мобильного УНФ

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

Интересная особенность мобильного УНФ – это то, что им зачастую начинают пользоваться люди, до этого про 1С не слыхавшие (да-да, есть в нашей стране и такие), те, которым понадобилось мобильное приложение для ведения учета их маленького бизнеса (например, домашнего крафтинга). Они просто нашли его поиском в Google Play или AppStore, почитали отзывы – и начали работать.

Автономная работа Этот сценарий работы предназначен для совсем маленьких организаций, когда весь учет ведется исключительно на мобильном устройстве. Это может быть, например, «домашний» бизнес – изготовление украшений на дому и их продажа на страничке ВКонтакте. А может быть даже и небольшой магазин – лично видел случай, когда магазин игрушек, специализирующийся на продаже конструкторов Lego, вел учет исключительно на мобильной версии УНФ. Учитывая, что мобильный УНФ умеет печатать на WiFi и Bluetooth принтерах, с его помощью можно решать довольно большое количество задач. Мобильный УНФ поддерживает обработку заказов, ввод приходных и расходных накладных, учет поступления и расход денег.Работа в режиме синхронизации с сервером (первые версии) В режиме синхронизации с сервером в мобильном УНФ в ранних версиях становилась недоступна учетная функциональность, и работа в нем велась в основном с заказами (прием и выполнение заказов) и сопутствующей этому деятельности (ведение справочников контрагентов, товаров и услуг и т.п.).

Синхронизировались с большим УНФ справочники товаров и услуг, контрагентов, и заказы.

Обмен данными мобильного и большого УНФ в первых версиях

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

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

Немного про синхронизацию данных Обмен данными между мобильным и большим УНФ идет через веб-сервисы; мобильный УНФ вызывает веб-сервисы, развернутые на стороне большого УНФ. Структуры данных в большом и мобильном УНФ различаются; при проектировании архитектуры мы рассматривали 2 варианта обмена данными:

Создать структуру данных в большом УНФ, дублирующую структуру данных мобильного УНФ, и обмениваться данными с мобильным УНФ «один-в-один». При изменении данных в большом УНФ нужно новые/изменённые данные перенести в эту дублирующую структуру, а после обмена данными с мобильным УНФ – сконвертировать данные, пришедшие с мобильного устройства и размещенные в дублирующей структуре, в формат большого УНФ.

Обмениваться данными непосредственно со структурами большого УНФ, осуществляя конвертацию данных «на лету» по правилам обмена.

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

Механизмы обмена данными, реализованные в платформе, берут на себя бОльшую часть работы по формированию пакетов для синхронизации данных, позволяя свести написание кода к минимуму. В процессе обмена используется стандартный механизм платформы 1С:Предприятия – механизм обмена данными ; для каждого мобильного УНФ в большом УНФ создается узел обмена данными, в большом и мобильном УНФ задействуется служба регистрации изменений для отслеживания данных, измененных со времени последней синхронизации и т.д.

Мобильное приложение инициирует обмен данными, с помощью механизмов платформы формирует пакет обмена (содержащий идентификатор мобильного приложения и данные, обновленные на мобильном УНФ со времени последней синхронизации) и пересылает его в большой УНФ. Исходя из информации в стартовом пакете, большой УНФ готовит для мобильного УНФ данные, измененные в большом УНФ со времени последней синхронизации, и упаковывает их в пакеты. Пакеты в формате XDTO - это объекты метаданных 1С, сериализованные в XML; размер каждого пакета – не более 500 объектов.

Мобильный УНФ забирает эти данные пакет за пакетом. После загрузки последнего пакета мобильный УНФ начинает обрабатывать полученные данные – проводить документы, записывать справочники и т.д. В случае разрыва связи поддерживается докачка пакетов; механизм докачки мы написали для УНФ самостоятельно (в платформе его нет), но, поскольку мобильный УНФ поставляется в исходных кодах, разработчики могут посмотреть на реализацию механизма и позаимствовать ее для своих приложений.

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

Полный список объектов, которыми обмениваются мобильный и большой УНФ:

• Справочники:
  • Номенклатура
  • Контрагенты
  • Список пользователей
• Документы:
  • Заказы покупателей
  • Поступление в кассу
  • Расход из кассы
  • Приходная накладная
  • Расходная накладная
  • Производство
• Регистры (но не полностью все цены, а только основные):
  • ЦеныПоставщиков
  • ЦеныТоваров
• Сведения об организации:
  • Наименование
  • Информация о налогообложении

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

Карточка товара с изображением товара

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

В первых версиях мобильного УНФ сценарий переезда был достаточно прямолинейным – данные, введенные в мобильном УНФ, копировались в базу большого УНФ, и пользователь должен был отныне вести учет на компьютере. Мобильный УНФ в этом случае будет работать в режиме работы с заказами, а вести учет (как на автономной версии мобильного УНФ) на нем уже будет нельзя.

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

Поэтому мы расширили список сценариев работы мобильного УНФ. В этом нам помогло появление нашего облачного сервиса http://1cfresh.com , основанного на облачной технологии 1cFresh . Появилась возможность размещать большой УНФ в облаке. Мы расписали три сценария использования мобильного приложения по мере роста бизнеса пользователя:

Совсем маленький бизнес. Учет ведется на одном мобильном устройстве.

Бизнес растет – появились сотрудники. Можно поставить мобильный УНФ на мобильные устройства сотрудников. При этом нужно уметь обмениваться данными между мобильными устройствами для синхронизации данных; для этого мы решили использовать не обмен через файлы, а задействовать для синхронизации (а заодно и для бэкапа) версию большого УНФ, расположенную в облаке http://1cfresh.com . При включении этого сценария в облаке http://1cfresh.com создается экземпляр большого УНФ, база которого будет использоваться для синхронизации данных между мобильными устройствами. Использование в таком сценарии одного мобильного устройства – бесплатно, за каждое дополнительное устройство мы берем 75 руб/месяц, использовать в этом сценарии можно не больше трех устройств. При этом пользователям мобильных устройств можно задать предопределенные роли – торговый представитель, сервисный инженер, продавец (возможна также детальная настройка ролей); соответствующим образом будет ограничена функциональность мобильного приложения. Можно также работать через веб-клиент или тонкий клиент с большим УНФ, размещенным в облаке, но функциональность облачного УНФ будет урезана до функциональности мобильного УНФ. Но работать непосредственно в облачном УНФ необязательно – вся работа может вестись только с мобильных устройств.

Бизнес вырос до размера средней фирмы. В этом случае имеет смысл арендовать в облаке полноценную версию большого УНФ, чтобы получить (через веб-клиент или тонкий клиент) дополнительную функциональность - CRM (в планах – включение CRM в мобильный УНФ, но пока доступен только в большой версии), управление складом, расширенное формирование цен, возможность работы с банками и . В этом случае количество мобильных устройств, работающих с большим УНФ, не ограничено (за каждое устройство взимается дополнительная плата согласно тарифу , как за одно рабочее место; 1 лицензия на УНФ во Фреше или на «коробочный» УНФ дает право бесплатного пользования и 1 мобильным приложением).

Опыт монетизации приложения Мобильное приложение УНФ, как я уже писал – бесплатное. Некоторое время назад мы решили монетизировать наше приложение (с помощью функциональности встроенных покупок, реализованной в мобильной платформе 1С:Предприятия версии 8.3.8), продавая дополнительную функциональность – производство, и возможность синхронизации с дополнительными мобильными устройствами.

Покупка функциональности «Производство» - разовая, а возможность синхронизации с дополнительными мобильными устройствами оформлена как подписка, которую нужно продлевать каждый месяц. Интересно, что уже через 3 недели после добавления функциональности покупок мобильный УНФ попал в топ 15 Google Play по продажам приложений для бизнеса.Заключение Мобильный УНФ – сравнительно небольшой (с точки зрения объема исходного кода), но довольно популярный продукт. Надеемся, рассказ о его эволюции будет полезен создателям мобильных end-user продуктов как на технологиях 1С, так и на других средствах разработки.

Нелишним будет напомнить, что на мобильной платформе 1С можно делать приложения, взаимодействующие не только с 1С-серверным backend-ом; протоколы, используемые для обмена данными в мобильных приложениях на платформе 1С – платформенно-независимые (web- и HTTP-сервисы, поддержка XML и JSON и т.п.). Так что если вам нужно быстро и динамично развивать кросс-платформенный (Android, iOS, Windows) мобильный клиент, причем с возможностью офлайн работы без постоянного подключения к Интернет для вашего бизнес-приложения, то мобильная платформа 1С вполне может быть оптимальным выбором для вас.

Данный прототип был создан с помощью Moqups – простого и удобного сервиса создания макетов и концептов. Вполне подойдет для быстрого прототипирования небольших Android – приложений. Для прототипирования более серьезных проектов лучше использовать Photoshop и Android UI Design Kit! .

Описание приложения

Приложение состоит из 3 экранов:

“Основной экран приложения” – при запуске отображается список задач (срок исполнения, наименование задачи и признак ее исполнения). По факту выполнения задачи она отмечается как исполненная в списке.

По кнопке “Обмен данными” сотрудник может запустить процедуру получения с сервера новых задач немедленно. Обмен данными с сервером также производится в автоматическом режиме 1 раз в день, согласно заданному в настройках расписанию.

“Настройки программы” – здесь задаются параметры авторизации и адрес сервера 1С, а также отображается уникальный идентификационный номер этого устройства. Здесь же может быть установлено расписание автоматического обмена.

Структура данных, которыми обменивается мобильный клиент с сервером 1С

Путь это будет таблица значений (в терминах 1С), которая содержит 3 колонки:

Создание шаблона мобильного приложения в 1С

Запустите 1С и выберите справочник “Мобильные приложения”, добавьте новый элемент, где:

В поле “Идентификатор” укажите SAMPLE_APP_TASKS (или придумайте любой другой) , это уникальный идентификатор приложения в рамках вашей конфигурации. Нужен для однозначной идентификации приложения в процессе обмена, т.к. на одном мобильном устройстве один и тот же сотрудник может использовать несколько приложений.

В поле “Наименование” укажите название вашего мобильного приложения, например Задачи .

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

Выделите в списке “Метаданные” группу “Внешние данные” и нажмите кнопку “Добавить ” на панели инструментов. Заполните параметры новой таблицы как показано на рисунке:

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

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

Для необъектных таблиц, таких как «регистр сведений» или «внешняя таблица», программе надо указать, как его следует заполнять. Один из вариантов – это установка флага «Индексировать» для одной или нескольких колонок таблицы, что и было сделано в нашем примере для колонок «СрокИсполнения» и «Задача». Это значит, что в таблице не может быть двух одинаковых задач на одну и ту же дату.

Нажмите ОК , таблица будет добавлена в дерево метаданных, для мобильного приложения имена автоматически переводятся в латиницу.

[Одно из правил FBA: в 1С исходный код пишем на русском, в Java на латинице. Отсутствие русских букв в идентификаторах, именах переменных и классах позволит избежать многих проблем при проектировании мобильного клиента]

Переименуйте имена из латиницы в английский. В принципе, можно было оставить и латиницу, но мы уже определились с именами (выше в таблице).

Сохраните изменения и нажмите на кнопку “Шаблон мобильного приложения ” на панели инструментов.

«Каталог шаблонов» – укажите путь к каталогу, в котором будут сохранены сгенерированные файлы шаблона мобильного приложения.

На закладке «Основные» укажите имя пакета, это должен быть уникальный идентификатор. Если у вас есть сайт, используйте его для генерации префикса. В нашем примере это ru.profi1c.samples.tasks

На закладке «Web-сервис» адрес сервера указан 10.0.2.2, по умолчанию это адрес вашего компьютера при доступе с Android-эмулятора.

В поля «Имя веб-сервиса» и «Подкаталог приложения» введите данные которые были указаны при публикации веб-сервиса.

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

Нажмите Создать , шаблон Android-проекта будет сгенерирован. Закройте окно мастера генерации шаблона, сохраните изменения и закройте элемент справочника «Мобильные приложения»