Интеграция мобильного приложения с 1С Предприятие

Связать мобильное приложение с 1С можно тремя путями: опубликовать базу на веб-сервере и обращаться к ней по HTTP-сервисам или интерфейсу OData, собрать мобильный клиент прямо на платформе 1С или сделать автономное приложение с обменом через план обмена. Выбор зависит от того, нужна ли работа без интернета и на чём пишется сам клиент — на мобильной платформе 1С или на стороннем стеке (нативный код, Flutter, React Native).

Общее у всех вариантов одно: 1С выступает сервером, а смартфон — клиентом, который шлёт HTTP-запросы и получает JSON. Поэтому фундамент интеграции — публикация информационной базы на веб-сервере. Ниже разберём, как опубликовать базу, поднять HTTP-сервис и OData, настроить авторизацию, организовать синхронизацию с офлайн-режимом, закрыть соединение по безопасности и как всё это протестировать.

Всё описанное относится к платформе 8.3 (интерфейс «Такси»). Веб-сервер — Apache или IIS на Windows Server 2016 и новее.

Чем связать: сравнение методов обмена

Прежде чем настраивать, выберите транспорт. Их четыре, и они не взаимозаменяемы.

Для большинства мобильных приложений выбирают HTTP-сервис (полный контроль над форматом) или OData (когда достаточно читать и писать типовые объекты). SOAP остаётся для legacy-интеграций и здесь подробно не нужен.

Отдельная развилка — а на чём вообще писать клиент:

Публикация базы и первый HTTP-сервис

Без публикации на веб-сервере снаружи базу не видно. Порядок такой.

1. На сервере установите веб-сервер (Apache или IIS) и модуль расширения веб-сервера — он входит в поставку платформы.
2. Откройте базу в Конфигураторе.
3. Меню Администрирование → Публикация на веб-сервере.
4. Задайте имя публикации (оно станет частью URL), каталог и веб-сервер.
5. На вкладках публикации отметьте, что публикуется: HTTP-сервисы, Web-сервисы, Стандартный интерфейс OData.
6. Нажмите Опубликовать. Платформа создаст файл default.vrd и настроит виртуальный каталог.

После этого база доступна по адресу вида http://<сервер>/<имя_публикации>/.

Теперь сам HTTP-сервис. Он создаётся как объект конфигурации.

1. В дереве конфигурации: ветка Общие → HTTP-сервисы, добавьте новый.
2. Задайте корневой URL (например, mobile) — это префикс всех его адресов.
3. Внутри сервиса добавьте шаблон URL (например, /goods) и в нём метод с указанием HTTP-метода: GET, POST, PUT, DELETE.
4. Для метода укажите имя обработчика — функцию в модуле сервиса.

Обработчик принимает запрос и возвращает объект HTTPСервисОтвет:

Функция ТоварыGET(Запрос)
    Ответ = Новый HTTPСервисОтвет(200);
    ДанныеJSON = СформироватьСписокТоваров();
    Ответ.УстановитьТелоИзСтроки(ДанныеJSON);
    Ответ.Заголовки["Content-Type"] = "application/json; charset=utf-8";
    Возврат Ответ;
КонецФункции

Готовый адрес метода: http://<сервер>/<публикация>/hs/mobile/goods. Префикс hs платформа добавляет к HTTP-сервисам автоматически.

Для приёма данных со смартфона в POST-методе читайте тело запроса через Запрос.ПолучитьТелоКакСтроку() и разбирайте его чтением JSON (ЧтениеJSON + ПрочитатьJSON). Не забудьте после изменения модуля или состава сервиса обновить конфигурацию базы (F7) — иначе наружу уедет старая версия.

OData: доступ к данным без программирования

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

Включается в два шага:

1. В публикации отметьте Стандартный интерфейс OData.
2. Явно разрешите состав — какие объекты отдаются наружу. Через Администрирование → Настройка стандартного интерфейса OData в Конфигураторе или программно методом УстановитьСоставСтандартногоИнтерфейсаOData. По умолчанию наружу не отдаётся ничего — пока объект не добавлен в состав, запрос к нему вернёт ошибку.

Корневой адрес: http://<сервер>/<публикация>/odata/standard.odata/.

Имена сущностей собираются из типа и имени объекта. Примеры:

• справочник «Номенклатура» → Catalog_Номенклатура;
• документ «Заказ покупателя» → Document_ЗаказПокупателя;
• регистр сведений → InformationRegister_<Имя>.

Чтобы получить JSON вместо XML, добавьте параметр $format=json:

GET http://server/base/odata/standard.odata/Catalog_Номенклатура?$format=json

OData понимает фильтры и отбор: $top=20, $skip=40, $filter, $select, $orderby. Например, вернуть только активные позиции:

.../Catalog_Номенклатура?$format=json&$filter=ПометкаУдаления eq false&$top=50

Создание и изменение объектов идёт теми же адресами методами POST и PATCH с телом JSON. Это удобно, но помните: OData открывает структуру базы «как есть», поэтому к нему особенно важно применить ограничения прав (см. раздел про безопасность).

Авторизация и запросы со смартфона

Опубликованная база по умолчанию спрашивает логин и пароль пользователя информационной базы. Самый распространённый способ для мобильных клиентов — HTTP Basic: логин и пароль в заголовке.

Authorization: Basic <base64("Логин:Пароль")>

То есть мобильное приложение кодирует строку логин:пароль в Base64 и кладёт в заголовок каждого запроса. Отдельного пользователя под интеграцию заводят в Конфигураторе (Администрирование → Пользователи) и дают ему только нужные роли.

Типичный GET-запрос к HTTP-сервису из клиента выглядит так (псевдокод, подходит для любого стека):

GET /base/hs/mobile/goods HTTP/1.1
Host: server
Authorization: Basic bW9iaWxlOnMzY3JldA==
Accept: application/json

Если авторизация провалилась, 1С вернёт 401 Unauthorized. Если пользователю не хватает прав на объект — 403 или прикладную ошибку из вашего кода.

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

Синхронизация и работа без интернета

Тут всё решает один вопрос: должно ли приложение работать в офлайне.

Онлайн-сценарий. Мобильный клиент 1С или сторонний клиент на HTTP-сервисах держит данные на сервере и каждый раз ходит за ними по сети. Локальной базы нет, конфликтов версий тоже. Минус очевиден: без связи приложение бесполезно. Подходит для склада с устойчивым Wi-Fi, офисных задач, просмотра отчётов.

Офлайн-сценарий. Автономное мобильное приложение на мобильной платформе 1С хранит данные в локальной базе на самом смартфоне. Синхронизация с центральной базой идёт порциями через план обмена поверх HTTP-сервиса обмена. Схема работы:

1. На центральной базе создаётся план обмена и HTTP-сервис обмена (типовой механизм платформы).
2. В мобильном приложении настраивается узел этого плана обмена.
3. По кнопке или по расписанию приложение выгружает накопленные изменения и загружает встречные.

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

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

Безопасность соединения

Публикуя базу наружу, вы открываете её в интернет. Минимальный набор мер:

• 🔒 Только HTTPS. Basic-авторизация без шифрования передаёт пароль фактически открытым текстом. Настройте TLS-сертификат на веб-сервере и публикуйте по https://.
• 👤 Отдельный пользователь под интеграцию с минимальными ролями. Не подключайте мобильное приложение под учётной записью с правами администратора.
• 🧩 Ограничение прав на уровне записей (RLS), если разные пользователи должны видеть разные данные — например, торговый представитель только своих клиентов.
• 🚫 Не публикуйте лишнее. Если OData не нужен — не включайте его в публикации. Открытый наружу odata/standard.odata с составом «всё подряд» — это выгрузка базы одним запросом.
• 🛡️ Фаервол и обратный прокси. Закройте прямой доступ к веб-серверу, пустите трафик через nginx/Apache как reverse proxy, ограничьте доступ по IP там, где это возможно.

Для сервисов, где пароль в приложении нежелателен, вместо Basic применяют токены: мобильное приложение получает токен отдельным методом HTTP-сервиса (по логину-паролю один раз), а дальше шлёт его в заголовке. Валидацию токена пишете в коде сервиса сами.

Тестирование и отладка интеграции

Проверяйте связку снизу вверх — от базы к клиенту.

Проверка публикации. Откройте в браузере корневой адрес OData http://<сервер>/<публикация>/odata/standard.odata/. Если отдаётся список сущностей (или просит логин) — публикация жива. Пустая страница или ошибка веб-сервера — проблема на уровне публикации, до 1С дело ещё не дошло.

Проверка HTTP-сервиса. GET-методы тестируйте прямо в браузере, остальное — в Postman или curl. Пример:

curl -u mobile:s3cret https://server/base/hs/mobile/goods

Журнал регистрации. Все обращения и ошибки прикладного кода видны в Администрирование → Журнал регистрации. Если клиент получает 500, причину ищите там — туда падает текст исключения из обработчика.

Отладка кода сервиса. В Конфигураторе включите отладку по HTTP (в настройках публикации должен стоять флажок отладки), поставьте точку останова в модуле HTTP-сервиса и подключитесь к предмету отладки. Запрос со смартфона или из Postman остановится на точке — дальше смотрите переменные как в обычной отладке.

Перед запуском в бой пройдитесь по короткому списку:

Частая причина «ничего не работает » после переноса на боевой сервер — забыли обновить конфигурацию базы (F7) или не повторили публикацию. Код в Конфигураторе есть, а наружу уехала старая версия.

Частые вопросы