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

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

Что изменилось в мобильной разработке за неделю 27 июля — 2 августа

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

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

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

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

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

Если это не чинить, компания теряет не абстрактную эффективность, а конкретные заказы. Один сорванный выезд курьера — это час его рабочего времени и клиент, который в следующий раз закажет у конкурента, потому что ему второй раз подряд привезли не то, что показывало приложение. При 3-4 таких случаях в неделю на сеть из десятка точек это уже заметная часть оттока и штрафные строки в договорах с оптовыми клиентами за срыв поставки.

Как исправить обрыв синхронизации без остановки работы склада

Быстрое решение не требует переписывать интеграцию заново — оно снимает симптом, пока готовится архитектурное исправление.

• ✓увеличьте тайм-аут HTTP-запроса на стороне приложения с типовых 10-15 секунд до 40-60: сервер 1С под нагрузкой отвечает медленно, но чаще всего отвечает, если его не обрывать раньше времени;
• ✓перейдите с полной выгрузки каталога на дельта-синхронизацию — приложение запрашивает только позиции, изменённые с момента последнего успешного обмена, а не весь справочник заново;
• ✓кэшируйте последний успешный ответ на устройстве и показывайте пользователю метку вида «остатки обновлены 12 минут назад», а не молча выдавайте устаревшие данные как актуальные — курьер должен видеть, что информации можно доверять не на сто процентов;
• ✓вынесите тяжёлые запросы — полный каталог, историю заказов — на фоновую очередь с повторными попытками, а не выполняйте их синхронно при каждом открытии приложения.

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

Что делать, если ошибка синхронизации повторяется каждую неделю

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

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

Если через тот же канал обмена идут телефоны и адреса клиентов — курьерское приложение получает такие данные по умолчанию, — обмен обязан быть защищён по требованиям 152-ФЗ: TLS-соединение на всех участках, ограниченный доступ к логам сервиса обмена и отдельный контур хранения для персональных данных, а не общий кэш вперемешку с остатками товара.

Как предотвратить сбои интеграции приложения с 1С на будущее

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

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

Мониторинг обмена, чтобы сбой не повторился незаметно

Архитектурное решение снимает симптом, но без наблюдения за обменом та же проблема соберётся заново через полгода, когда вырастет число пользователей. Разумный минимум — логировать каждую попытку синхронизации с отметкой времени и результатом, ставить алерт, если доля неудачных обменов за час превышает условные 5%, и раз в месяц смотреть на графике, не растёт ли среднее время ответа сервера. Это дешевле, чем ждать жалобы от курьера или клиента и разбираться постфактум, что именно сломалось и когда.

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

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

Диагностика причины обрыва — тест Гилёва на боевом сервере, разбор регламентных заданий, проверка кода HTTP-сервиса — укладывается в работу сисадмина и специалиста по 1С, услуги сопровождения 1С и системного администрирования стоят от 3800 руб/час. Часто на полную диагностику и точечные правки уходит 3-6 часов.

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

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

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

Почему мобильное приложение показывает неактуальные остатки из 1С?

Чаще всего сервер 1С в момент запроса занят регламентными заданиями или отчётностью и не успевает ответить вовремя, а приложение показывает последние данные, которые получило раньше. Это не ошибка приложения, а перегрузка базы 1С в пиковые часы — проверяется тестом Гилёва на сервере.

Можно ли пользоваться приложением, если 1С временно недоступна?

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

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

Диагностика причины обрыва через сопровождение 1С стоит от 3800 руб/час, аренда более мощного сервера под обмен — от 3300 руб/мес. Архитектурное решение с очередью сообщений, дельта-синхронизацией и кэшем на устройстве — это уже разработка мобильного приложения, стоимость начинается от 500 000 руб.

1С:Мобильная платформа подходит для готового приложения или нужно писать с нуля?

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

Как понять, что причина сбоя — сервер 1С, а не само мобильное приложение?

Нужно прогнать тест Гилёва на боевом сервере в момент пиковой нагрузки и сравнить время отклика с системными требованиями 1С для активного обмена. Если сервер не укладывается в норму, проблема в железе, а не в коде мобильного приложения или логике синхронизации данных.