Как настроить обмен данными между 1С и мобильным приложением

1С связывается с мобильным приложением через веб-сервер: базу публикуют на Apache или IIS, а приложение забирает и отправляет данные по HTTP. Телефон напрямую к файловой или серверной базе не подключается — между ними всегда стоит опубликованная точка входа.

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

Какой протокол выбрать для связи 1С и приложения

У платформы 8.3 четыре механизма, через которые мобильное приложение достаёт данные из 1С. Они отличаются объёмом настройки и гибкостью.

Для большинства задач «приложение показывает остатки и цены, принимает заказы» выбирают HTTP-сервис: он отдаёт компактный JSON и полностью управляется кодом. OData берут, когда приложение стороннее и умеет работать с протоколом «из коробки». SOAP остался для систем, которым нужен жёсткий описанный контракт.

Отдельно стоит мобильная платформа 1С. На ней собирают самостоятельное приложение (файл apk или ipa) из конфигурации, заточенной под телефон. У такого приложения своя локальная база на устройстве, а с основной базой 1С оно обменивается через те же веб- или HTTP-сервисы. Это путь для случая, когда приложение должно работать офлайн и иметь интерфейс, отличный от десктопного.

Публикация базы на веб-сервере — без неё ничего не работает

Это главный шаг, который часто пропускают. Пока база не опубликована, ни HTTP-сервис, ни OData недоступны по сети. Публикацию делают в конфигураторе.

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

После публикации адреса складываются по схеме:

• HTTP-сервисы — https://сервер/имя_публикации/hs/корневой_url/...
• OData — https://сервер/имя_публикации/odata/standard.odata/
• Web-сервисы — https://сервер/имя_публикации/ws/имя_сервиса

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

Проверить публикацию просто: откройте в браузере корневой адрес OData. Платформа вернёт служебный документ со списком доступных сущностей. Если список пуст — состав не задан; если адрес не открывается — проблема в публикации или веб-сервере.

Как создать HTTP-сервис в конфигураторе

HTTP-сервис — объект метаданных, который принимает запросы приложения и возвращает ответ. Создаётся в дереве конфигурации в ветке Общие → HTTP-сервисы.

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

Метод получает объект запроса и возвращает HTTPСервисОтвет. Простой обработчик на чтение:

Функция ТоварыGET(Запрос)
    Ответ = Новый HTTPСервисОтвет(200);

    МассивТоваров = Новый Массив;
    Выборка = Справочники.Номенклатура.Выбрать();
    Пока Выборка.Следующий() Цикл
        Строка = Новый Структура;
        Строка.Вставить("code", Выборка.Код);
        Строка.Вставить("name", Выборка.Наименование);
        МассивТоваров.Добавить(Строка);
    КонецЦикла;

    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, МассивТоваров);

    Ответ.УстановитьТелоИзСтроки(ЗаписьJSON.Закрыть(), КодировкаТекста.UTF8);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Возврат Ответ;
КонецФункции

После сохранения конфигурации и обновления опубликованной базы сервис доступен по адресу https://сервер/имя_публикации/hs/exchange/goods.

Обмен данными в формате JSON: запись и чтение

JSON — основной формат для мобильного обмена: он легче XML и нативно разбирается на любой платформе телефона. В 1С за него отвечают объекты ЗаписьJSON, ЧтениеJSON и функции ЗаписатьJSON, ПрочитатьJSON.

На запись функция ЗаписатьJSON сериализует простые типы: Структура превращается в объект JSON, Массив — в массив, Соответствие — в объект с произвольными ключами. Пример выше возвращает массив товаров.

На чтение приложение присылает тело запроса, которое надо разобрать. Для POST-метода, принимающего заказ:

Функция ЗаказPOST(Запрос)
    ТелоСтрокой = Запрос.ПолучитьТелоКакСтроку();

    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(ТелоСтрокой);
    ДанныеЗаказа = ПрочитатьJSON(ЧтениеJSON);

    // ДанныеЗаказа — Соответствие: ключи JSON → значения
    Клиент = ДанныеЗаказа["client"];
    Сумма  = ДанныеЗаказа["total"];

    // здесь создаём и проводим документ Заказ

    Ответ = Новый HTTPСервисОтвет(201);
    Возврат Ответ;
КонецФункции

ПрочитатьJSON по умолчанию возвращает Соответствие, так что к полям обращаются по ключу. Даты в JSON приходят строкой — их разбирают отдельно, формат задают при чтении параметром или вручную через XMLЗначение.

Чтобы договориться с разработчиком приложения, какое поле JSON куда ложится в 1С, удобно держать карту соответствий:

Онлайн и офлайн сценарии синхронизации

Два режима работы приложения требуют разной логики обмена.

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

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

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

• 📅 По дате изменения. В объектах хранят реквизит с датой правки, приложение шлёт «дай всё, что менялось после такого-то времени». Просто, но не ловит удаления.
• 🔁 Через план обмена. В конфигурации создают план обмена, узел для мобильного приложения регистрирует изменения автоматически. 1С отдаёт порцию изменений и после подтверждения помечает их принятыми. Этот способ надёжнее: он отслеживает и новые, и изменённые, и удалённые объекты.

Крупные справочники передавайте порциями. Если номенклатуры десятки тысяч позиций, одним ответом её слать нельзя — мобильная сеть оборвёт запрос по таймауту. Добавьте в HTTP-сервис параметры смещения и размера порции (например, /goods?offset=0&limit=500), и приложение заберёт данные страницами. Первая синхронизация при этом идёт дольше, зато надёжно; последующие тянут только изменения и проходят за секунды.

Защита канала и авторизация приложения

Обмен идёт через интернет, поэтому канал закрывают, а запросы проверяют.

🔒 HTTPS обязателен. Голый HTTP передаёт логины, пароли и данные открытым текстом. На веб-сервере ставят SSL-сертификат, публикацию открывают только по https://. Внутри default.vrd можно запретить доступ без шифрования.

🔑 Аутентификация. У платформы есть два базовых варианта:

• Basic-аутентификация. Приложение передаёт логин и пароль пользователя информационной базы в заголовке Authorization. Работает только поверх HTTPS. Заведите для обмена отдельного пользователя с минимальными правами — ровно на те справочники и документы, что нужны приложению.
• Токен. В HTTP-сервисе вы сами проверяете заголовок с токеном, который приложение получает при входе. Полный контроль, но логику пишете вручную.

Дополнительно ограничьте доступ к точке публикации по списку адресов на веб-сервере, если приложение ходит с известных IP, — например, через фильтрацию на уровне Apache или IIS.

Отладка и мониторинг обмена

Когда данные не доходят, проблему локализуют по слоям — от веб-сервера до кода сервиса.

1. Проверьте адрес в браузере. Откройте GET-метод прямо в браузере. Если отвечает — публикация и веб-сервер живы. Ошибка 404 чаще означает, что база не опубликована или имя публикации набрано неверно.
2. Пошлите запрос из Postman или curl. Так проверяют POST и заголовки авторизации до того, как подключать приложение. Ошибка 401 — не прошла аутентификация, проверьте логин, пароль и что включён HTTPS.
3. Включите отладку HTTP-сервиса. В конфигураторе в Сервис → Параметры → Запуск 1С:Предприятия → Отладка разрешите отладку, затем подключите отладчик к рабочему процессу веб-сервера. Станут видны переменные внутри обработчика.
4. Смотрите журнал регистрации. Ошибки проведения документов и исключения в коде сервиса пишутся туда. Отбор по времени и пользователю обмена быстро выводит на причину.

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

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