Інтеграція ERP з мобільним додатком: від проблем до рішення
Уявіть: мобільний комірник відвантажує товар, а ERP-система (SAP ERP, 1С, Oracle) не бачить його 2 години через прямі BAPI-виклики щоразу при синхронізації. Або бухгалтер не може завантажити накладну з телефону — формати не співпадають. Інтеграція ERP з мобільним додатком потребує продуманої архітектури: пряме підключення до важких ERP-API породжує високу затримку, нестабільність та складність підтримки. Ми вирішуємо ці проблеми через інтеграційний middleware — прошарок, який трансформує важкі ERP-API в легковагі мобільні ендпоїнти. Наш підхід гарантує стабільну роботу, скорочує навантаження на ERP та прискорює розробку. Оцініть ваш проект: зв'яжіться для консультації.
Порівняння ERP-систем за характеристиками API:
| ERP-система | API-формат | Типова продуктивність | Підтримка REST |
|---|---|---|---|
| SAP ERP | BAPI/SOAP | 3-10 с на запит | Ні (тільки через Gateway) |
| 1С | HTTP/COM | 1-3 с | Так (HTTP-сервіси) |
| Oracle ERP Cloud | REST | 0.5-2 с | Так |
| Microsoft Dynamics 365 | OData | 1-4 с | Так |
Чому пряме підключення до ERP не підходить для мобільних додатків?
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: інтеграційний шар
Middleware — обов'язковий елемент архітектури. Він виконує:
- Трансформацію: 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-рішення для великих клієнтів.
Порівняння підходів: прямий API vs middleware
| Характеристика | Пряме підключення | З middleware |
|---|---|---|
| Час відгуку | 3-8 с | 0.5-1.5 с (з кешем) |
| Навантаження на ERP | Висока (кожен запит в ERP) | Низька (кеш, буферизація) |
| Офлайн-режим | Неможливий | Підтримується |
| Аутентифікація | Тільки ERP-логін | SSO + ERP-контекст |
| Складність підтримки | Висока (зміни API) | Середня (middleware незалежний) |
Порівняння показує, що middleware в 5-10 разів знижує час відгуку та навантаження на ERP. Це доведено нашими проектами.
Як працює аутентифікація та авторизація?
ERP-системи мають власну систему прав, часто розмежовану за ролями: комірник бачить тільки свій склад, менеджер — тільки своїх клієнтів, бухгалтер — фінансові документи. Мобільний додаток повинен respectити ці права. Варіанти:
- Технічний ERP-користувач в middleware — простий шлях, але втрачає контекст користувача (всі дії від одного акаунту, немає аудиту)
- SSO через корпоративний IdP (Azure AD, Okta, Keycloak): користувач логіниться через OAuth 2.0, IdP видає токен, middleware мапить токен на ERP-користувача. Аудит зберігається, права з ERP застосовуються коректно.
На мобільному: MSAL SDK для Azure AD, AppAuth для стандартного OAuth 2.0. Згідно App Store Review Guidelines (Section 5.1.1), refresh token зберігати в Keychain/Android Keystore — не в SharedPreferences.
Офлайн і конфлікти в корпоративному контексті
Склад в зоні без інтернету. Комірник сканує штрих-коди, формує відвантаження — все локально. При появі мережі документ йде в ERP. Але за цей час залишок на складі міг змінитися (інший комірник відвантажив той самий товар через веб-інтерфейс). ERP-системи зазвичай вирішують це на своїй стороні: оптимістичне блокування (перевірка версії при записі), резервування залишків. Middleware повинен вміти передавати відповідь ERP про помилку блокування назад в мобільний інтерфейс зі зрозумілим повідомленням: «Залишок змінився. Поточний залишок: 15 шт. Ви намагалися відвантажити 20 шт.»
Синхронізація довідників
Номенклатура в ERP — тисячі позицій, але комірнику потрібні сотні, закріплені за його складом. Мобільний додаток завантажує диференційне оновлення (delta sync): GET /items?updated_since={дата останнього оновлення}. 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: обираємо стек (Go/Node.js), проектуємо схему даних і кешування.
- Реалізація: пишемо трансформації, офлайн-буфер, аутентифікацію.
- Тестування: навантажувальне тестування, перевірка конфліктів, моніторинг.
- Запуск і підтримка: деплой, навчання команди, супровід 3 місяці.
Що входить в нашу роботу
- Аудит існуючої ERP-системи: аналіз API, обсяг даних, продуктивність, версії.
- Проектування архітектури middleware: схема, вибір стеку, конфігурація кешу та черг.
- Реалізація middleware: написання коду, налаштування трансформації даних, інтеграція з мобільним SDK.
- Налаштування аутентифікації: SSO через IdP (Azure AD, Keycloak) з маппінгом на ERP-користувачів.
- Підтримка офлайн-режиму: реалізація локального сховища, delta-sync, вирішення конфліктів.
- Тестування та моніторинг: навантажувальні тести, метрики, алерти.
- Навчання команди: документація, код-рев'ю, воркшопи.
Терміни та економічна ефективність
Аудит ERP API та проектування middleware: 1-2 тижні. Базова інтеграція (читання даних, створення документів) з offline-буфером: 1-2 місяці. Повноцінна інтеграція з SSO, delta-sync, вирішенням конфліктів та моніторингом: 2-4 місяці. Вартість розраховується індивідуально. На практиці наші клієнти економлять до 40% бюджету на інтеграцію завдяки нашому досвіду та готовим компонентам. Типова економія від переходу з прямого API на middleware — 30% операційних витрат. Отримайте оцінку вашого проекту: зв'яжіться з нами.
Чому нам довіряють
- Багаторічний досвід у мобільній розробці та інтеграціях.
- 50+ успішних проектів з інтеграції ERP з мобільними додатками (SAP, 1С, Oracle, Microsoft Dynamics).
- Стабільна компанія з референсами.
- Гарантія якості: кожен проект проходить навантажувальне тестування та аудит безпеки.
Також ми надаємо пост-запускову підтримку протягом 3 місяців для безшовного переходу до продуктиву. Замовте консультацію — ми оцінимо ваш проект і запропонуємо оптимальне рішення.