← На главную

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

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

Шаг 1. Выбор формата данных: JSON против XML

Первый вопрос, который возникает при проектировании обмена, — это формат данных. Основные кандидаты — XML и JSON.

XML (eXtensible Markup Language) — это общепризнанный стандарт для обмена данными, имеющий строгую структуру. Однако его синтаксис с открывающими и закрывающими тегами делает его избыточным (многословным). Для больших объемов данных это приводит к значительному увеличению размера файла, что замедляет его передачу по сети и требует больше ресурсов для разбора (парсинга) на мобильном устройстве.

JSON (JavaScript Object Notation) — более современный и легковесный формат. Его структура "ключ-значение" компактнее, чем у XML, что уменьшает размер передаваемых данных. Большинство мобильных платформ имеют встроенные, высокопроизводительные парсеры JSON, которые работают быстрее и требуют меньше памяти. Для мобильной разработки JSON является стандартом де-факто.

Вывод: Для обмена с мобильным приложением, особенно при больших объемах данных, однозначно выбираем JSON. Он обеспечит более быструю передачу и обработку данных.

Для задач, требующих максимальной производительности, существуют и более продвинутые бинарные форматы, такие как Protocol Buffers (Protobuf) в связке с фреймворком gRPC. Они еще компактнее и быстрее, но требуют более сложной настройки и освоения как на стороне 1С, так и на стороне мобильного приложения.

Шаг 2. Стратегия загрузки: не выгружайте все данные сразу

Самая большая ошибка — пытаться выгрузить 40 000 позиций одним запросом. Мобильное приложение не должно "вычерпывать" всю базу данных. Оно является клиентом, который должен запрашивать данные по мере необходимости. Рассмотрим правильные подходы.

Решение 1: Разбивка на пакеты (пагинация)

Это самый распространенный и правильный метод для первоначальной загрузки больших объемов данных. Суть в том, чтобы запрашивать данные небольшими порциями (пакетами или страницами).

1. Мобильное приложение отправляет первый запрос на сервер, например: GET /api/products?page=1&limit=500.
2. Сервер 1С формирует и отдает JSON только с первыми 500 товарами.
3. Вместе с данными сервер может вернуть информацию для получения следующей порции. Это может быть номер следующей страницы или специальный токен. Например, ответ может содержать поле "next_page_token": "a1b2c3d4".
4. Приложение, обработав первую порцию, делает следующий запрос, используя полученный токен: GET /api/products?token=a1b2c3d4&limit=500.
5. Процесс повторяется до тех пор, пока сервер не вернет пустой ответ или специальный маркер, означающий конец данных.

Преимущества пагинации:

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

Решение 2: "Ленивая" загрузка (Lazy Loading)

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

1. Во время первоначальной синхронизации загружаем только минимально необходимую информацию для отображения списка: ID товара, наименование, артикул, возможно, цена и URL основной картинки. Эти данные весят немного, и даже 40 000 таких записей можно загрузить относительно быстро (используя пагинацию).
2. Когда пользователь открывает карточку конкретного товара, приложение делает отдельный запрос на сервер для получения полной информации: всех свойств, подробного описания, остатков, ссылок на дополнительные изображения.

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

Шаг 3. Оптимизация работы с изображениями: только ссылки

Передача изображений — одно из самых узких мест. Категорически нельзя хранить картинки в базе данных мобильного приложения или передавать их в JSON в виде текста (кодировка Base64). Это приведет к огромному размеру базы данных на устройстве и колоссальному расходу трафика.

Правильный подход:

1. Передаем только URL. В JSON-объекте товара должно быть поле, содержащее не саму картинку, а только ссылку (URL) на нее. Например: "imageUrl": "https://your.server.com/images/product123.jpg".
2. Загрузка по необходимости. Мобильное приложение загружает изображение по этому URL только в тот момент, когда оно должно появиться на экране пользователя.
3. Кэширование на устройстве. Чтобы не загружать одну и ту же картинку многократно, приложение должно реализовывать механизм кэширования. Загруженное изображение сохраняется в локальном хранилище устройства. При следующем обращении к этой картинке она будет взята из кэша, что экономит трафик и ускоряет отображение. Современные мобильные библиотеки (например, Glide для Android или Kingfisher для iOS) делают это автоматически.

Шаг 4. Последующие обновления: используем планы обмена

После того как первоначальная загрузка каталога завершена, нет необходимости каждый раз выгружать все 40 000 позиций. Нужно передавать только те данные, которые изменились с момента последней синхронизации.

Для этой задачи в платформе 1С существует встроенный механизм — Планы обмена. Он позволяет отслеживать изменения (создание, изменение, удаление) объектов в базе данных.

Алгоритм работы следующий:

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

Этот подход кардинально сокращает объем передаваемых данных и время синхронизации при последующих обменах.

Шаг 5. Ускорение подготовки JSON на стороне 1С

Даже при пакетной выгрузке формирование JSON для 500 сложных позиций может занимать заметное время. Если стандартные механизмы сериализации 1С (ЗаписьJSON, СериализаторXDTO) работают медленно, можно применить следующие техники:

Ручное формирование JSON-строки. Вместо использования объектов-сериализаторов можно формировать строку JSON вручную, перебирая данные в цикле. Это менее удобно и требует аккуратности с экранированием спецсимволов, но часто дает существенный прирост в производительности.

Фоновая подготовка данных. Можно создать регламентное задание, которое будет по расписанию (например, раз в час) заранее формировать готовые JSON-пакеты для выгрузки и сохранять их в каком-либо хранилище (например, в регистре сведений). Когда мобильное приложение сделает запрос, HTTP-сервис 1С не будет генерировать данные "на лету", а просто отдаст уже готовый, заранее сформированный пакет. Это сделает отклик API практически мгновенным.

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