Мобильная разработка за неделю #640: почему приложение теряет связь с 1С

Мобильное приложение компании теряет связь с 1С в момент пиковой нагрузки — при закрытии смены, обходе склада или массовой рассылке заказов курьерам. Причина обычно не в коде приложения, а в сервере 1С: он не успевает обработать очередь запросов от API. Решение — не переписывать приложение, а разгрузить бэкенд: тест производительности, донастройка регламентных заданий, перенос базы на сервер с запасом ресурсов.

дайджест недели: что чаще всего спрашивали про мобильные B2B-приложения 20-26 июля

За неделю в заявках на разработку и поддержку мобильных приложений повторялся один сценарий. Бизнес заказывает приложение для склада, курьеров или торговых представителей, привязывает его к 1С — и через месяц-два эксплуатации приложение начинает обрывать синхронизацию именно в часы пиковой нагрузки. Разработчики грешат на Wi-Fi или на сам код приложения, но проверка логов почти всегда показывает другое место сбоя. Разберём эту механику подробно и покажем, что с ней делать — не общими советами, а конкретными шагами.

Для малого и среднего бизнеса в Москве эта проблема особенно чувствительна: мобильное приложение обычно подключают на этапе, когда штат уже вырос до 15-30 человек в поле — курьеров, кладовщиков, торговых представителей. Именно на этом рубеже нагрузка на сервер 1С перестаёт быть теоретической и превращается в утренний ритуал технической поддержки.

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

Склад работает по будням с 8 до 17, у операторов на руках терминалы с приложением приёмки. В 9:05, когда десять человек одновременно сканируют накладные и отправляют данные в 1С, приложение зависает на отправке — не у одного, а сразу у всех. К 9:20 всё само рассасывается. Кажется, что дело в Wi-Fi, но проверка логов показывает другое: запросы доходят до сервера 1С, но очередь на обработку растягивается на минуты, потому что сервер в это время обслуживает и бухгалтерию, и обмен с сайтом, и вот теперь ещё мобильные терминалы.

Мобильное приложение в этой схеме не источник проблемы, а индикатор. Оно первым упирается в таймаут, потому что мобильные HTTP-запросы обычно ждут ответ не дольше 30-60 секунд, а десктопный клиент 1С готов ждать дольше и не показывает ошибку так быстро. Поэтому приложение выдаёт сбой раньше, чем его заметит бухгалтер за компьютером.

какие ошибки видят пользователи

На экране терминала это обычно выглядит как «сервис временно недоступен», HTTP 502 или 504, либо просто зависший индикатор отправки без текста ошибки. Разработчики нередко списывают это на нестабильный интернет на складе — и тратят время на замену роутера, хотя дело в очереди на сервере.

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

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

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

Первый шаг — не трогать код приложения, а измерить сервер. Тест производительности Гилёва за 15-20 минут показывает, сколько операций в секунду база реально выдерживает, и сразу видно, упирается ли сервер в диск, процессор или память в момент нагрузки.

Дальше — три рабочих способа снять нагрузку без переписывания приложения:

• ✓вынести обмен с мобильными терминалами в отдельный HTTP-сервис или отдельную информационную базу, чтобы очередь склада не конкурировала с бухгалтерскими проводками;
• ✓перенести регламентные задания — закрытие месяца, обновление цен, обмен с сайтом — на ночное время, когда терминалы не работают;
• ✓временно увеличить таймаут ожидания в самом приложении до 90-120 секунд, пока сервер не разгружен — это не устраняет причину, но убирает ложные ошибки у операторов.

что проверить до звонка в поддержку

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

если дело не в сервере

Если тест Гилёва показывает, что сервер упирается в железо — процессор загружен на 90%+ в пиковые минуты, а памяти под 1С выделено меньше, чем требуют системные требования 1С для текущего числа пользователей, — донастройкой уже не обойтись, нужен более мощный сервер. Стоит проверить и логику самого приложения: агрессивный повторный опрос сервера при неудачной отправке добавляет нагрузку сам по себе и может маскировать реальную причину сбоя.

что делать, если ошибка повторяется после каждого обновления приложения

Бывает так: приложение обновили, ошибку вроде убрали, а через неделю-две обрывы синхронизации возвращаются. Это признак того, что чинили симптом, а не причину — увеличили таймаут или добавили повторные попытки отправки, но нагрузка на сервер осталась прежней и выросла вместе с числом активных пользователей приложения.

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

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

как предотвратить сбои синхронизации в мобильном B2B-приложении

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

Для бизнеса с постоянным ростом числа пользователей — склад, курьеры, торговые представители — разумнее сразу закладывать архитектуру, которая не упрётся в потолок через полгода. Мы делаем это на базе 1С:Мобильной платформы либо через собственный API-слой — выбор зависит от того, сколько у вас пользователей сейчас и какой рост планируете на год вперёд. Если приложение уже разрабатывается с нуля, разумнее сразу закладывать масштабируемую архитектуру — это дешевле, чем перестраивать обмен через год после запуска.

При выборе подрядчика на разработку или доработку такого приложения стоит сразу спрашивать не про дизайн экранов, а про архитектуру обмена: как приложение поведёт себя при 30, 50 и 100 одновременных пользователях, что произойдёт при потере связи и кто отвечает за нагрузочное тестирование перед запуском. Ответы на эти вопросы обычно точнее всего показывают, столкнётесь вы с обрывами синхронизации через полгода или нет.

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

Разработка мобильного приложения для бизнеса с интеграцией 1С у нас начинается от 500 000 руб — сумма зависит от числа сценариев (приёмка, отгрузка, инвентаризация, работа с курьерами) и от того, нужен ли офлайн-режим. Для B2B-приложений с интеграцией 1С это обычно означает несколько месяцев разработки с постепенным подключением сценариев.

Если проблема не в приложении, а в сервере, на котором держится 1С, — аренда сервера под 1С обойдётся от 3300 руб/мес, а разовая настройка регламентных заданий и перенос обмена на ночное время — от 3800 руб/час работы сисадмина. Для компаний, которые ещё не готовы к собственному серверу, есть аренда самой 1С от 1100 руб/мес с уже настроенным окружением. На практике диагностика сервера, перенос регламентных заданий и первая проверка результата на пиковой нагрузке укладываются в одну-две недели — без остановки работы склада или курьерской службы.

Полный список тарифов на разработку и сопровождение — на странице цен. Если нужен разбор конкретной ошибки в вашем приложении — присылайте лог обрыва синхронизации, за 20-30 минут скажем, дело в сервере или в архитектуре обмена.

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

Почему приложение зависает именно по утрам, а не весь день?

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

Можно ли решить проблему без замены сервера?

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

Сколько времени занимает диагностика причины обрыва синхронизации?

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

Что дешевле: чинить текущую интеграцию или переходить на 1С:Мобильную платформу?

Зависит от масштаба: точечные правки дешевле в моменте, но при росте числа пользователей архитектура на 1С:Мобильной платформе обходится дешевле в долгосрок за счёт меньшего числа повторных доработок и устойчивости к росту нагрузки.

Наше приложение делала другая студия — вы возьмётесь чинить синхронизацию?

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