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

Мобильное приложение для сотрудников, клиентов или торговых представителей часто должно получать из 1С остатки, цены, заказы, статусы документов и персональные данные. Простого подключения к базе недостаточно: требуется понятный программный интерфейс, который определяет состав данных, правила авторизации и порядок обработки ошибок. Подробнее о Razrabotka Otcheta Na Skd S Dinamicheskimi Gruppirovkami Po Proizvol Nym Polyam.

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

Основой решения становится HTTP-сервис 1С. Он принимает запросы в формате JSON, проверяет права пользователя, выполняет прикладную операцию и возвращает унифицированный ответ. Для передачи больших объемов данных добавляют постраничную выборку, фильтры и механизм синхронизации по дате изменения.

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

Архитектура обмена и границы ответственности

Типовая схема состоит из мобильного приложения, HTTP-сервиса 1С и информационной базы. Клиент отправляет HTTPS-запрос, сервис передает его в общий модуль, а тот вызывает прикладные процедуры. Ответ формируется в JSON и содержит результат операции, служебный код и сообщение для клиента.

Для каждой операции стоит заранее описать метод, HTTP-тип, обязательные параметры и структуру ответа. Например, GET /api/v1/products возвращает товары с фильтрами по группе и дате изменения, а POST /api/v1/orders создает заказ по переданному составу. Версия /v1/ помогает менять контракт постепенно, не ломая старые версии приложения.

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

Контракт данных и формат ответов

JSON должен быть предсказуемым. Имена полей, типы значений, формат дат и правила передачи пустых данных фиксируют в спецификации. Денежные суммы лучше возвращать числом с согласованной точностью, даты — в едином формате ISO 8601, а ссылки на объекты 1С — в виде устойчивых идентификаторов, а не представлений.

Успешный ответ может содержать поля success, data, meta и requestId. В meta передают общее количество записей, размер страницы и признак наличия следующей страницы. Ошибка должна включать машинный код, понятное описание и, при необходимости, список ошибочных полей. Текст, предназначенный пользователю, не стоит смешивать с диагностикой сервера.

При проектировании выборок удобно использовать фильтр по ДатаИзменения и уникальный идентификатор объекта. Это позволяет мобильному клиенту запрашивать только новые или измененные данные. Для удаления записей нужен отдельный признак: например, поле isDeleted либо журнал изменений, поскольку исчезновение объекта из очередной выборки само по себе не объясняет причину.

Реализация HTTP-сервиса в 1С

В конфигураторе создают HTTP-сервис, задают шаблоны URL и привязывают их к обработчикам. В обработчике получают тело запроса, преобразуют JSON в структуру, выполняют валидацию и вызывают общий серверный модуль. Ответ формируют через объект HTTP-сервиса с установленным кодом состояния и заголовком Content-Type: application/json.

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

Сложные отчеты и мобильные срезы данных лучше выносить в отдельные процедуры. Практические приемы построения отчета на СКД помогают организовать динамические отборы и группировки, однако для API следует дополнительно ограничивать объем результата и исключать визуальные настройки, не нужные приложению.

Авторизация и защита мобильного клиента

Для рабочих систем используют HTTPS, короткоживущий access-токен и механизм обновления сессии. Пароли пользователей нельзя передавать в каждом запросе или хранить в открытом виде на устройстве. Токен проверяют до выполнения прикладной операции, а права сопоставляют с ролями пользователя в 1С.

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

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

Синхронизация, тестирование и сопровождение

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

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

После запуска контролируют ошибки HTTP-сервиса, длительные запросы, рост очереди и объем передаваемых данных. Версии контракта документируют, изменения проводят обратно совместимо, а устаревшие методы выводят из эксплуатации по заранее объявленному графику. Для крупных решений полезно вынести кэширование и очереди на отдельный интеграционный сервер.

Собственный API становится устойчивым, когда его проектируют вокруг бизнес-операций, а не вокруг таблиц 1С. Зафиксируйте контракт, разделите уровни, добавьте авторизацию, журналирование и повторяемую синхронизацию. Такой фундамент позволит связать мобильное приложение с учетной системой, KUBiK или другими сервисами без постоянной переработки конфигурации. Начните с одного сценария — например, каталога и создания заказа — и расширяйте интерфейс после проверки безопасности и нагрузки.