Особенности разработки нативного мобильного приложения с бэкендом на 1С

Меня зовут Матвей Серегин, последние 7 лет я руковожу командой продуктовой разработки.

Моя основная специализация – это облачные решения на базе технологии 1cFresh для клиентов со всей страны, где пользователи работают в разных регионах и в разных часовых поясах.

Особенность нашей разработки – широкая линейка интеграций с веб-приложениями:

• это и использование веба внутри 1С;

• и интеграция с различными сайтами;

• и интеграция с мобильными приложениями.

Сегодня я более подробно расскажу про наш опыт разработки нативных мобильных приложениях – как мы пытались «подружить» с ними 1С.

• Во-первых, поговорим о причинах – что нас сподвигло сделать мобильное приложение не на 1С, при этом остаться бэкендной частью на 1С

• Далее немного поговорю про выбор инструмента, с помощью которого можно делать нативные мобильные приложения. Сначала у нас был выбор между 1С и не-1С – вроде два варианта. А потом, когда мы решили, что будем делать мобильное приложение не на 1С, список вариантов сразу же превратился в очень широкий с достаточно сложным выбором.

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

• И про некоторые технические решения на стороне 1С, которые, если вы пойдете по тому же пути, позволят вам сэкономить силы, нервы, время и т.д.

В каких случаях лучше использовать нативные мобильные приложения

Начну с того, почему мы решили делать мобильное приложение на нативных технологиях. Существуют же мобильные приложения на 1С и мобильный клиент 1С – что в них не так?

• Первое, что нас остановило и стало критичным при принятии решения – это возможности интерфейса. Заказчик ставил задачу реализовать приложение с понятным UI/UX, чтобы у клиента был легкий онбординг. Само приложение подразумевалось к выкладке в сторах, чтобы пользователи разных возрастов с разным опытом, видя это приложение наряду с остальными своими приложениями соцсетей, мессенджерами, банковскими приложениями, испытывали примерно те же эмоции от использования нашего.

• Кроме этого, у 1С-ных мобильных приложений практически нет каких-то библиотечных решений для реализации – мы их не нашли. Безусловно, можно считать библиотечной «Библиотеку стандартных подсистем», она содержит многие решения. Кроме этого, существует инструмент от сообщества Коннектор, который тоже сильно облегчает взаимодействие со стороны приложения с HTTP-сервисами. Несмотря на то, что эти инструменты очень интересны, они не покрывали достаточного количества наших кейсов.

Когда 1С-никам имеет смысл выбирать нативные технологии для реализации мобильного приложения.

• Исходя из наличия ресурсов. Если в команде только 1С-разработчики и нет дополнительного финансирования, чтобы привлечь стороннюю команду либо нанять специалистов, знакомых с нативной разработкой, естественно, в нативную разработку идти смысла нет, потому что это – достаточно дорого и ресурсоемко.

• И второе – если важен UI/UX, который не обеспечивается решениями на 1С.

Бэкенд на 1С:Предприятии. Преимущества и недостатки

Следующий вопрос, который был заявлен в теме – это бэкенд на 1С. Собственно, почему бэкенд на 1С? Здесь тоже все достаточно просто.

• У нас уже есть существующее прикладное решение, работающее в модели сервиса, работающее под большой нагрузкой, в котором содержится вся бизнес-логика и все данные, которые нам нужно транслировать в мобильное приложение;

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

• Наличие технологии 1cFresh позволяет быстро масштабировать эти решения – сама по себе технология позволяет разделить области клиентов – каждое мобильное приложение подключается к своей области. При этом само масштабирование, создание новых областей уже вшито в технологию 1cFresh и не требует от нас каких-то дополнительных затрат.

С другой стороны, есть определенные минусы:

• Для 1С нет библиотеки для работы с HTTP-сервисами. Если мы посмотрим на стандартные решения в разработке по бэкенду – python, PHP, Node.js – там практически вся внутрянка (формирование HTTP-ответов различных типов, подстановка mime-типов, работа с заголовками) хорошо завернута в библиотеки, и зачастую бэкенд-разработчик на Python и PHP разбирается в нюансах протокола HTTP гораздо меньше, чем разработчик 1С, который реализует бэкенд на HTTP-сервисах – только потому, что 1С предоставляет достаточно низкоуровневые возможности для работы с ними, а всю логику приходится писать руками и изучать стандарты.

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

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

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

Варианты реализации нативного мобильного приложения

Как мы выбирали, на чем сделать нативное мобильное приложение?

Есть различный выбор.

• Самые низкоуровневые технологии – это Kotlin, Swift, Java. Родные языки программирования для мобильной разработки. Соответственно, они обеспечивают максимальную возможность взаимодействия с операционными системами, с железом устройства, с интерфейсом, но требуют двух команд разработки – у вас должна быть и команда по iOS-разработке, и команда по Android-разработке, что довольно дорого.

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

• Следующие, уже хорошо зарекомендовавшие себя кроссплатформенные фреймворки – например, ReactNative, VueNative. Они позволяют разрабатывать на языке JavaScript. Далее – собирать мобильные приложения. Соответственно, у вас получается язык, которые в принципе, знают достаточно много фронтенд-разработчиков, но уже гораздо меньше интеграций с операционной системой. С другой стороны, так как это – веб, возможности по графическому оформлению практически не ограничены.

• И самый простой вариант – это Progressive Web Application (PWA). Здесь идет полностью веб-разработка, которая иногда компилируется в мобильное приложение.

Мы у себя выбрали первый вариант – у нас приложение разработано отдельно под каждую платформу на языках Swift и Kotlin.

Проектирование бизнес-логики и API – нюансы взаимодействия между командами разработки

Расскажу, как «подружить» мобильных и 1С-разработчиков.

Основная проблема здесь в том, что 1С-разработчики привыкли, что они в принципе умеют все делать сами. Мы реализуем базу данных, бизнес-логику на стороне сервера и интерфейс клиентского приложения – навыка договариваться с другими техническими командами практически нет.

С другой стороны, когда мы работаем с мобильным приложением, нам приходится договариваться. Мы предоставляем просто программный интерфейс в виде HTTP-сервиса, который со стороны мобильного приложения будет вызывать другая команда. И алгоритмы тоже будет писать другая команда. Поэтому, в первую очередь важным является документирование этого программного интерфейса (API).

Что должно быть описано?

• Во-первых, для каждой сущности мы описываем объектную модель. Например, у нас есть сущность «Контрагент», документ «Счет на оплату» или договор контрагента. И мы описываем, какие у этой сущности есть атрибуты – какие атрибуты обязательные, какие могут иметь значение NULL, какие могут отсутствовать, как они друг с другом взаимосвязаны, что является уникальным ключом для того или иного объекта. Все это в конечном счете мобильные разработчики транслируют в объектную модель внутри приложения со своим объектно-ориентированным программированием и в модель хранения данных внутри приложения. И если мы на своей стороне документировали неверно, где-то допустили ошибку, где-то что-то недодумали, то зачастую, при очередной новой фиче, которую мы делаем на бэкенде, у нас вроде просто – мы добавляем реквизит, добавляем по нему поиск – вроде ничего страшного. А мобильный разработчик на это смотрит и говорит: «Я это буду делать две недели». Соответственно, грамотное продумывание заранее архитектуры модели данных крайне важно.

• Следующее – это структура конечных точек или структура функций, которые будет вызывать мобильное приложение. Это касается получения и отправки каких-то данных – дай мне список контрагентов, запиши нового контрагента, запиши новый документ, поменяй статус какого-то документа и т.д. Опять же, со ссылками на конкретные объекты, которые разработчик мобильного приложения должен передать нам. То же самое – относительно конкретных объектов, которые мы ему отдадим в ответ.

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

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

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

Какие инструменты здесь могут помочь?

• Во-первых, если мы любим писать текстом, здесь можно воспользоваться языком разметки YAML и скормить его Swagger. Он автоматически сгенерирует красивый список методов, объектную модель и средства для отладки – можно будет даже подергать методы HTTP-сервисов.

• Stoplight – примерно то же самое, но уже не придется вручную писать текст, а потыкать объектную модель – заполнить поля, указать типы, проставить галочки.

• И APImatic – еще более мощный инструмент примерно с теми же функциями.

Единственное, что Stoplight и APImatic для совместного использования платные – причем, цены на них не очень демократичные.

Отладка и тестирование API

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

Поэтому контроль работоспособности API полностью на зоне разработки – он тоже становится достаточно важной задачей.

• Здесь в качестве инструмента ручного тестирования хорошо подходит Postman – на сегодняшний день он обеспечивает возможность не только у себя на компьютере развернуть программу и подергать различные методы HTTP-сервисов, но и подергать их из облака. Это позволит вашей команде бэкенд-разработчиков отлаживать эти методы вместе. Вы внесли изменения – подергали, ваш коллега внес изменения и по этим же сценариям подергал – проверил, что все работает.

• Далее, когда ручная отладка закончена, можно воспользоваться автоматизацией тестирования Newman for Postman и, например, упаковать это в контур CI/CD, чтобы API тестировалось автоматически.

• Небольшой нюанс в сторону CORS – если пользоваться не Postman, а тем же Swagger или Stoplight, то современные браузеры достаточно ревностно относятся к безопасности и не дают, находясь на одном домене, дергать методы другого. Т.е. если вы находитесь на сайте Инфостарта, и вам нужно дернуть сайт фирмы «1С», нужно, чтобы сайт фирмы «1С» сказал браузеру: «Меня можно дергать с Инфостарта». Если браузер от сайта фирмы «1С» такого разрешения не получит, он вам скажет «нельзя». Аналогично, если вы на сайте Swagger хотите дергать свое API, вам нужно, чтобы ваше API сказало, что его можно дергать. А это требует дополнительной настройки и веб-сервера nginx, и дополнительных доработок HTTP-сервисов. Т.е. ваш сервер должен удовлетворять требованиям CORS – это нужно иметь в виду. В этой части Postman гораздо более прост.

• Средства отладки – если ничего не помогает. Довольно часто случаются ситуации, когда мы через Postman дергаем API, все работает. А с мобильного приложения коллеги вызывают то же самое, передают те же самые параметры – не работает. Здесь помогут инструменты перехвата трафика. Мы используем Fiddler, который стоит на сервере и просто ловит те запросы, идущие от мобильного устройства. Мы можем их смотреть – что именно там пришло. Довольно часто там просто формат тела немного поменялся в процессе передачи. Формат заголовка поменялся в процессе передачи. Тут уже разбираемся – либо на своей стороне докручиваем алгоритм обработки этого запроса. Либо коллегам говорим, что они что-то не так передают.

Технические решения для бэкенда

Несколько технических решений, которые нам помогают реализовать бэкенд.

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

При работе с HTTP-сервисом есть следующие варианты открытия сеансов:

• Сеансы могут создаваться на каждый вызов.

• Сеансы могут автоматически жить какое-то время – в этом случае на каждый вызов приложения клиентом не будет создаваться новый сеанс. Соответственно, первый вызов идет 2-3 секунды, которые тратятся на открытие сессии, последующие вызовы проходят практически мгновенно.

• И есть еще возможность ручного управления сеансами. Это когда клиент сначала отправляет специальную команду на сервер 1С: «Открой мне сеанс, я сейчас буду с тобой взаимодействовать». А затем он отправляет запросы, а потом вручную дает команду: «Все, я закончил с тобой взаимодействовать, закрывай сеанс».

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

  • С другой стороны, это обеспечивает наиболее оптимальную нагрузку на сервер 1С – там не висит лишних сеансов, которые жрут ресурсы сервера.

  • Кроме этого, когда мобильное приложение начинает отправлять запросы пакетно (обычно не один запрос отправляется), ответ оно получает максимально быстро.

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

Дальше – момент по схеме HTTP-ответов. Когда мы возвращаем от HTTP-сервиса ответ, у нас есть код ответа. Иногда разработчики отправляют все в теле ответа. Иногда мы кодом все-таки отправляем какой-то статус. Соответственно, мы используем такую схему кодов:

• 200-е ответы – это ОК;

• 400-е ответы – это проблема на стороне клиента, он отправил запрос с неправильным форматом;

• 500-е ответы сообщают об ошибке на стороне сервера – это может быть ошибка исполнения либо это может быть временная недоступность, связанная с работой обработчиков обновления.

Интересный нюанс с HTTP-заголовками.

RFC – это стандарт обмена по протоколу HTTP – позволяет делать заголовки регистронезависимыми. Заголовок, в котором x-auth-token написано маленькими буквами и заголовок, где X-Auth-Token написано так, что первые буквы слов большие – это, в принципе, одинаковое имя токена с точки зрения стандарта.

При этом 1С превращает заголовки в соответствия. А в соответствии поиск по ключу регистрозависимый. И если мы ищем второй вариант написания, а клиент нам отправляет первый вариант написания, то мы ничего не найдем.

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

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

Журналирование работы HTTP-сервисов

Вот так примерно выглядит шаблон метода HTTP-сервиса.

• Мы сначала проверяем, не заблокирована ли база работой обработчиков обновления. Если мы не проверим, возможно, ответ и уйдет, но обработчик обновления развалится, потому что будет висеть сеанс HTTP-сервиса, который не даст установить монопольный режим обработчикам обновления и приложение останется висеть необновленным неизвестное время.

• Затем делаем замер производительности – для этого используется стандартная подсистема БСП.

• Окончание замера оборачиваем в «Попытка… Исключение», чтобы явно записать исключение в журнал регистрации, если на нашей стороне ошибка, и вернуть 500-й ответ.

• И далее передаем запрос в модуль «Мессенджеры» на выполнение конкретного метода.

Здесь показан пример взаимодействия с оценкой производительности. Здесь достаточно просто – мы через прослойку вызываем методы БСП.

И регистрация ошибок. Опять же, просто пишем в журнал регистрации и готовим 500-й HTTP-ответ, чтобы сообщить мобильному приложению, что на нашей стороне что-то не так.

Если мы в продуктиве работаем со сложными ошибками, есть дополнительные возможности журналирования – например, запись всех HTTP-запросов в отдельный регистр сведений.

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

Авторизация

Авторизацию мы выполняем через токен.

HTTP-сервис опубликован на стороне 1С в анонимной публикации. В файле default.vrd на веб-сервере прописан логин и пароль служебного пользователя – при этом в basic-аутентификации логина и пароля со стороны мобильного приложения не передается.

Чтобы нам понять, какой пользователь делает вызов, мобильное приложение передает в заголовках токен – при первом вызове передается логин-пароль, в ответ система возвращает токен. И далее в рамках сессии мобильное приложение с сервером взаимодействует через этот токен.

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

Плюс – это дает возможность, например, завершить сессию на одном устройстве или на всех устройствах. Реализовать такие сценарии, что пользователь нажимает: «Завершить сессию на всех устройствах», мы просто по его логину все токены убиваем. Следующий запрос с любого из приложений потребует повторной авторизации.

Нюансы взаимодействия 1С и мобильного приложения

Со стороны клиента 1С умеет обрабатывать только short polling – т.е. это когда мы дернули HTTP-сервис, и он сразу либо за время какой-то своей обработки вернул ответ.

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

• Long polling – это уже довольно устаревшая технология.

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

• Push-уведомления можно делать:

  • либо непосредственно через API вендоров – но тогда, опять же, придется делать отдельно для iOS, отдельно для Android;

  • либо есть достаточно большое количество агрегаторов для отправки уведомлений. Мы пользуемся firebase – он предоставляет общее API для отправки как в iOS, так и в Android.

Есть нюанс по передаче файлов – мы на своем опыте столкнулись с проблемой, связанной с обработкой multipart/form-data.

Протокол HTTP позволяет передать в рамках одного запроса много файлов, объединяя их через специальные разделители в теле запроса. При этом, если 1С на уровне платформы пробует обработать такой запрос, он не обрабатывается – к нам приходят либо двоичные данные, либо текст. И, если попробовать это парсить встроенным языком программирования, это занимает достаточно много времени – по сравнению с передачей аналогичных файлов последовательно, время увеличивается почти в 20 раз.

Соответственно, файлы в теле запроса передаем по-отдельности, как двоичные данные. И далее – финальный запрос с командой: «Вот эти файлы, которые я тебе передал, объедини – прикрепи к одному документу и т.д.»

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

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

Если мы говорим про API, где нам нужно на клиент также отдавать сотни тысяч документов, нам эту пагинацию нужно делать вручную. Соответственно, у запроса должны быть параметры – сколько элементов клиент запрашивает от нас, в каком направлении должна быть сортировка – по возрастанию или по убыванию. И начиная с какого элемента – первые 20 элементов, следующие 20, начиная с 20, следующие 20, начиная с 40 и т.д.

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

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

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

Заключение

Итого, выводы:

• Разработка бэкенда для мобильных приложений на 1С – это не универсальное решение.

• Основные причины, почему можно это сделать:

  • если данные уже хранятся в существующем решении на 1С в нужной структуре;

  • если в 1С реализована нужная бизнес-логика;

  • если мы делаем прототип командой 1С-разработчиков – как средство прототипирования, платформа со своими возможностями быстрой разработки отлично подходит.

  • \