Интеграция ERP-системы с мобильным приложением
ERP-интеграция — одна из наиболее технически сложных задач в корпоративном мобайле. ERP-системы (SAP, Microsoft Dynamics, Oracle ERP, 1C) проектировались не для мобильного доступа: тяжёлые модели данных, синхронные транзакции, SOAP/XML API вместо REST, жёсткая бизнес-логика на стороне ERP. Подключить к этому мобильное приложение напрямую — почти всегда провал.
Почему прямое API не работает
SAP ERP на ABAP отдаёт RFC-вызовы или SOAP BAPI. Один запрос данных по материалу может инициировать цепочку из 5-7 внутренних RPC внутри SAP, занимать 3-8 секунд и возвращать XML на 200 КБ с полями, которые не нужны мобильному клиенту.
Microsoft Dynamics 365 имеет OData API — формально «современный», но ответ на список записей с expand-вложенностями разбухает до мегабайт. На мобильном устройстве с 4G парсинг такого ответа в main thread = ANR на Android, блокировка UI на iOS.
Oracle ERP Cloud — REST API есть, но версионируется агрессивно. Oracle может выпустить breaking change в минорной версии, и существующая интеграция ломается после очередного обновления Oracle-инстанса клиента.
Middleware: интеграционный слой
Обязательный элемент архитектуры — интеграционный middleware между ERP и мобильным приложением. Функции:
- Трансформация: XML/SOAP → JSON, тяжёлые объекты → мобильные DTO
- Кэширование: справочники (склады, номенклатура, контрагенты) обновляются редко — кэш с TTL 15-60 минут снимает нагрузку с ERP
- Оркестрация: одно действие в мобильном (провести накладную) → несколько вызовов к ERP
- Буферизация: мобильный пользователь без сети создаёт документ → middleware принимает и отправляет в ERP синхронно позже
Middleware реализуется на Node.js, Go, .NET или Java Spring. Apache Camel — если нужна маршрутизация между несколькими ERP. MuleSoft/Dell Boomi — enterprise-решения для крупных клиентов.
Аутентификация и авторизация
ERP-системы имеют собственную систему прав, часто разграниченную по ролям: кладовщик видит только свой склад, менеджер — только своих клиентов, бухгалтер — финансовые документы. Мобильное приложение должно respectить эти права.
Варианты:
- Технический ERP-пользователь в middleware — простой путь, но теряет контекст пользователя (все действия от одного аккаунта, нет аудита)
- SSO через корпоративный IdP (Azure AD, Okta, Keycloak): пользователь логинится через SAML/OAuth 2.0, IdP выдаёт токен, middleware маппит токен на ERP-пользователя. Аудит сохраняется, права из ERP применяются корректно.
На мобильном: MSAL SDK для Azure AD, AppAuth для стандартного OAuth 2.0. Refresh token хранить в Keychain/Android Keystore — не в SharedPreferences.
Офлайн и конфликты в корпоративном контексте
Склад в зоне без интернета. Кладовщик сканирует штрих-коды, формирует отгрузку — всё локально. При появлении сети документ уходит в ERP. Но за это время остаток на складе мог измениться (другой кладовщик отгрузил тот же товар через веб-интерфейс).
ERP-системы обычно решают это на своей стороне: оптимистическая блокировка (проверка версии при записи), резервирование остатков. Middleware должен уметь передавать ответ ERP об ошибке блокировки обратно в мобильный интерфейс с понятным сообщением: «Остаток изменился. Текущий остаток: 15 шт. Вы пытались отгрузить 20 шт.»
Синхронизация справочников
Номенклатура в ERP — тысячи позиций, но кладовщику нужны сотни, закреплённые за его складом. Мобильное приложение скачивает дифференциальный обновление (delta sync): GET /items?updated_since=2025-01-01T00:00:00Z. ERP-системы не всегда поддерживают delta-запросы — middleware вычисляет delta на своей стороне через собственную реплику справочника.
Room (Android) + CoreData (iOS) хранят локальную копию справочников. Фоновая синхронизация каждые N минут обновляет их. Пользователь работает с локальной копией — быстро, без ожидания ответа ERP.
Производительность и мониторинг
ERP-вызовы медленные. Middleware логирует каждый вызов с duration, ERP-endpoint и результатом. Prometheus + Grafana или Datadog показывают перцентили ответов: если p95 > 5 секунд на конкретный ERP-метод — кэш обязателен.
Timeout strategy: мобильный клиент ждёт ответа максимум 10 секунд, потом показывает ошибку с кнопкой retry. Middleware не убивает вызов к ERP — завершает его и кэширует результат для следующего запроса.
Сроки
Аудит ERP API и проектирование middleware: 1-2 недели. Базовая интеграция (чтение данных, создание документов) с offline-буфером: 1-2 месяца. Полноценная интеграция с SSO, delta-sync, разрешением конфликтов и мониторингом: 2-4 месяца. Стоимость рассчитывается индивидуально.