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

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

1. Выбор технологии обмена данными (Какое API использует 1С?)

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

REST API (HTTP-сервисы 1С) — Современный и рекомендуемый подход

Суть и Архитектура

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

1. Публикация Endpoints: В конфигураторе 1С в ветке "Общие" -> "HTTP-сервисы" создаются специальные сервисы. Каждый URL-шаблон (например, /api/mobile/v1/catalog/products) становится конечной точкой API.
2. Обработчики Запросов: Для каждого метода (GET, POST и т.д.) в этих сервисах пишется код на языке 1С в виде функций. Этот код выполняет ровно одну бизнес-задачу:
   • GET /api/catalog/products → Функция, которая возвращает список товаров в JSON.
   • POST /api/orders → Функция, которая создает новый заказ, принимая JSON-тело запроса.
3. Процесс взаимодействия:
   • Мобильное приложение отправляет HTTP-запрос на конкретный URL.
   • Платформа 1С вызывает связанную с этим URL функция-обработчик.
   • Функция выполняет логику (чтение данных, проведение документа и т.д.).
   • Функция возвращает результат, который 1С автоматически конвертирует в JSON и отправляет клиенту.

Пример кода обработчика в 1С для REST API:

// Обработчик для GET /api/mobile/v1/catalog/products
Функция ПолучитьСписокТоваров(Знач Запрос) Экспорт

Преимущества (Детализация)

• Стандартизация: Вы опираетесь на общепринятые практики HTTP: коды состояния (200 OK, 404 Not Found, 400 Bad Request), методы (GET, POST, PUT, DELETE), заголовки. Это делает API понятным для любых разработчиков.
• Кроссплатформенность: Не имеет значения, на чем написано мобильное приложение. Любая платформа, умеющая выполнять HTTP-запросы и работать с JSON (а это все современные платформы), сможет работать с вашим API.
• Гибкость: Это ключевое преимущество. Вы не ограничены внутренней структурой данных 1С. Вы создаете "фасад", который:
• Агрегирует данные: Один запрос может вернуть данные из нескольких документов и справочников, идеально подходящие для экрана мобильного приложения.
• Упрощает модель: Вы можете исключить ненужные мобильному приложению поля и реквизиты.
• Реализует сложную логику: Endpoint POST /api/orders может не просто записать документ, но и выполнить проверки, расчеты, отправить уведомления — всю необходимую бизнес-логику.
• Производительность: JSON является бинарно более компактным и менее многословным, чем XML, что ускоряет передачу по сети и парсинг на мобильном устройстве.

OData — Стандартизированный протокол

Суть и Архитектура

OData — это не то, что вы "проектируете", а то, что вы "включаете". Это стандартный протокол для запросов к данным.

1. Автоматическая Публикация: В конфигураторе 1С в разделе "Общие" -> "OData-сервисы" вы просто выбираете объекты метаданных (справочники, документы, регистры сведений), которые хотите опубликовать. 1С автоматически создает для них набор стандартных endpoints.
2. Стандартизированные Endpoints: Для справочника "Товары" 1С создаст endpoint вида /odata/standard.odata/Catalog_Товары. Структура URL и параметров строго регламентирована стандартом OData.
3. Богатые Возможности Запросов: Клиент может строить очень гибкие запросы прямо из URL, используя специальные параметры:
   • Фильтрация: $filter=Цена gt 1000 and startswith(Наименование, 'Акку')
   • Сортировка: $orderby=Наименование desc
   • Пагинация: $top=20&$skip=40
   • Выбор полей: $select=Наименование,Цена

Пример запроса к OData из мобильного приложения:

GET http://server/odata/standard.odata/Catalog_Товары?$filter=Цена lt 1000&$orderby=Наименование&$top=10

1С обработает этот запрос, преобразует его в собственный запрос к базе данных и вернет результат в стандартном формате OData (JSON).

Преимущества

• Максимальная стандартизация: Единый стандарт для всех операций. Вы можете использовать готовые клиентские библиотеки (например, Simple.OData.Client для .NET), которые сами умеют строить такие запросы.
• Подходит для простых CRUD-операций: Если ваша задача — просто отображать, фильтровать, сортировать и редактировать данные из стандартных объектов 1С, OData является самым быстрым решением "из коробки". Не нужно писать код обработчиков.

• Негибкость для сложной бизнес-логики:
  • Сложные вычисления: Если для мобильного приложения нужны агрегированные или вычисляемые данные, которых нет в объекте, стандартный OData не поможет.
  • Кастомные операции: Невозможно создать endpoint POST /api/orders/submit, который будет не только создавать заказ, но и проверять наличие товаров, резервировать их и проводить документ. Вам придется эмулировать это несколькими вызовами или писать собственные сервисы.
  • "Утечка" внутренней структуры: Клиент вынужден работать с внутренними именами объектов и реквизитов 1С (например, Catalog_Товары, Description), которые могут быть неудобными для внешнего API.

1. Основа на WSDL: В 1С публикуется "Веб-сервис" (не HTTP-сервис). Для него автоматически генерируется WSDL (Web Services Description Language) — XML-документ, который жестко описывает контракт API: доступные методы, структуры принимаемых и возвращаемых данных.
2. Строгая Типизация и Сложность: Все сообщения (запросы и ответы) упаковываются в "конверт" SOAP — строго структурированный XML-документ с заголовками и телом. Это обеспечивает высокий уровень стандартизации и безопасности, но создает большую нагрузку.
3. Процесс взаимодействия:
   • Разработчик мобильного приложения импортирует WSDL.
   • Инструменты (например, для Android — ksoap2) генерируют шаблонный код для вызовов.
   • Приложение формирует XML-запрос, обернутый в SOAP-конверт, и отправляет его на единственный URL сервиса (например, /ws/example.1cws).
   • Сервер 1С разбирает SOAP-конверт, находит нужный метод и выполняет его.

• Тяжеловесность: XML по своей природе многословен. Добавление SOAP-конверта делает сообщения в 2-5 раз больше, чем аналогичные в JSON. Для мобильных сетей, где важна экономия трафика, это критично.
• Сложность: Работа с SOAP требует больше кода и усилий на стороне клиента. Нужно работать с низкоуровневыми XML-парсерами или подключать сторонние библиотеки.
• Производительность: Парсинг объемного XML на мобильном устройстве потребляет больше CPU и времени по сравнению с легковесным JSON.
• Меньшая гибкость: Любое изменение в API (добавление поля в ответ) требует обновления WSDL и перегенерации клиентского кода.
• Прямое соединение через Native API (COM, .NET) — Категорически не для мобильных приложений.
• Суть: Работает только в рамках Windows и для толстых клиентов. Для iOS и Android неприменим.

2. Проектирование клиентской части мобильного приложения

А. Слоистая Архитектура (Layered Architecture)

Разделите код на независимые слои:

1. Слой UI (ViewController / Activity / Widget): Отвечает только за отображение и действия пользователя.
2. Слой Бизнес-логики (Bloc, ViewModel, Presenter): Обрабатывает события от UI, принимает решения, передает запросы на слой данных.
3. Слой Данных (Repository / Data Source):
   • Локальный источник: База данных на устройстве (SQLite, Room, Realm).
   • Удаленный источник (API Client): Клиент для взаимодействия с API 1С.

Б. Модели данных

Создайте классы-модели (Data Classes, POJO) в мобильном приложении, которые mirror-ят структуры данных, получаемые от 1С.

• Важно: Не используйте сырой JSON в бизнес-логике. Парсите его в объекты вашего языка (Kotlin, Swift, Dart) сразу upon получении.
• Сериализация/Десериализация: Используйте библиотеки типа Gson/Moshi для Android или Codable/JSONDecoder для iOS для автоматического преобразования JSON в объекты и обратно.