Интеграция SAP с мобильным приложением

Интеграция SAP с мобильным приложением

SAP — корпоративная система уровня enterprise с десятками продуктов (SAP S/4HANA, SAP ECC, SAP SuccessFactors, SAP Ariba), и каждый имеет свой API. Ошибка — начинать разработку мобильного приложения без предварительного аудита того, какой именно SAP-продукт у заказчика и какие API открыты. «SAP интеграция» — это не одна задача, это категория задач с принципиально разными подходами.

SAP API: три поколения

BAPI / RFC — старый стандарт на ABAP. Вызов через SAP JCo (Java Connector) или SAP NCo (.NET Connector). Для мобильного — только через middleware, который транслирует RFC в HTTP. Прямого RFC из iOS/Android нет и быть не может.

SAP Gateway / OData — поколение SAP NetWeaver и ECC 6.0. RESTful интерфейс поверх OData v2/v3. Данные в формате Atom XML или JSON (если клиент запрашивает $format=json). OData v2 — устаревший стандарт с многочисленными quirks: Edm.DateTime вместо ISO 8601, специфическая фильтрация, __deferred для lazy-loaded навигационных свойств.

SAP Business Technology Platform (BTP) + CAP — современный подход для S/4HANA Cloud. CAP (Cloud Application Programming Model) публикует OData v4 сервисы. Чище, предсказуемее, но доступен не у всех клиентов.

SAP Mobile Services

SAP предоставляет собственный middleware для мобильных — SAP Mobile Services (ранее SAP Mobile Platform / Kapsel). Функции: аутентификация, offline sync, push-уведомления, шифрование данных на устройстве. Интеграция через SAP BTP SDK for iOS и SAP BTP SDK for Android.

SAP BTP SDK for Android — Kotlin, wrapper над SAP Mobile Services API:

val serviceManager = ServiceManager(
    applicationContext,
    SAPServiceManager.configUrl,
    object : ServiceManager.ServiceManagerListener {
        override fun onServiceManagerReady() {
            // Готов к работе
            initializeODataService()
        }
    }
)

ODataRequestExecutor выполняет запросы к OData-сервисам с автоматическим CSRF-токеном, retry при 401, offline-буферизацией. Это закрывает большую часть типичных проблем интеграции, но привязывает к SAP-экосистеме.

Аутентификация: SAML и OAuth

SAP S/4HANA Cloud использует OAuth 2.0 с SAP Identity Authentication Service (IAS) как IdP. Мобильное приложение проходит Authorization Code Flow через IAS, получает JWT, передаёт в API S/4HANA.

SAP ECC на NetWeaver — часто SAML 2.0 или базовая аутентификация. SAML на мобильном — через WebView с перехватом редиректа и извлечением сессионного токена. Это хрупко: при изменении IdP-конфигурации на стороне SAP мобильная авторизация ломается.

Рекомендация: добавить OAuth 2.0 прокси через SAP BTP или Keycloak с SAML-SAP бридж. Мобильный клиент использует стандартный OAuth, сложность SAML скрыта в middleware.

CSRF-токен — типичная боль

SAP OData требует CSRF-токен для всех модифицирующих запросов (POST, PUT, DELETE, PATCH). Схема:

1. GET /odata/sap/.../$metadata с заголовком X-CSRF-Token: Fetch
2. SAP возвращает токен в заголовке X-CSRF-Token: {token_value}
3. Все следующие POST/PUT/DELETE включают X-CSRF-Token: {token_value}

Токен живёт в рамках сессии. При разрыве сессии (timeout, повторная аутентификация) нужно получить новый. Обёртка в HTTP-клиенте, которая автоматически получает CSRF при 403 CSRF token validation failed и повторяет запрос — стандартный паттерн.

На Retrofit — Interceptor, который перехватывает ответ с 403, делает fetch CSRF, добавляет заголовок и retry оригинального запроса.

Offline и SAP OData

SAP Fiori Elements поддерживает offline через OData Offline Store в SAP BTP SDK. Offline Store — SQLite-кэш OData-запросов с двусторонней синхронизацией. Пользователь работает с локальной копией, при сети — sync с SAP.

Конфликты в SAP offline: ETag механизм. Перед PUT SAP возвращает ETag записи, клиент включает If-Match: {etag} при обновлении. Если запись изменилась на сервере — SAP вернёт 412 Precondition Failed. SDK предоставляет conflict resolution callback.

Типичные сложности

Производительность OData v2. $expand для навигационных свойств делает JOIN на стороне SAP ABAP — может выполняться 5-15 секунд. Альтернатива: параллельные запросы без expand или middleware, который кэширует и агрегирует.

Различия между S/4HANA и ECC. API для одного и того же объекта (например, заказ покупателя) в S/4HANA OData (API_SALES_ORDER_SRV) и ECC Gateway (ZSHOP_SRV) абсолютно разные. Абстрактный слой в middleware обязателен, если нужна поддержка обоих вариантов.

Pagination в OData v2. $skip + $top или server-side paging через sap-pagesize заголовок. $skip с большими значениями на SAP ABAP медленный — каждый раз полный расчёт. Серверная пагинация через SAP skiptoken предпочтительнее.

Сроки

Аудит SAP landscape клиента и доступных API: 3-5 дней. Прототип интеграции (чтение данных через OData, аутентификация): 1-2 недели. Полноценная интеграция с offline-поддержкой, CSRF-handling, разрешением конфликтов: 2-4 месяца. Стоимость зависит от версии SAP, объёма интегрируемых объектов и требований к offline. Рассчитывается индивидуально.