Повне з'єднання SAP та сайту: архітектура, методи та етапи робіт

Ми стикалися з ситуацією, коли відділ продажів вводить замовлення в SAP, а сайт живе своїм життям — залишки не сходяться, ціни застаріли, клієнти скаржаться на затримки. Інтеграція сайту з SAP — не просто технічне завдання, а ключ до синхронізації бізнес-процесів. У цій статті розберемо архітектуру, методи та підводні камені, з якими стикаються інженери під час реалізації таких проєктів. Ми накопичили досвід понад 20 інтеграцій і ділимося найкращими практиками.

Які проблеми вирішуємо?

Розсинхронізація даних — основний біль. Ручне введення призводить до помилок: SAP зберігає актуальні залишки, ціни, статуси замовлень, але сайт використовує застарілу копію. Продуктивність страждає, коли кожен запит до SAP через RFC або IDoc навантажує продуктивну систему: середня затримка відповіді SAP становить 200–500 мс, що критично для користувацького досвіду. Безпека під загрозою, якщо відкрити SAP-мережі в інтернет без middleware — потрібен захищений шар з авторизацією та шифруванням. Типова історія: при синхронізації замовлень щохвилини через RFC відбуваються блокування таблиць в SAP, що сповільнює роботу диспетчерів на 30%.

Чому не варто підключати сайт безпосередньо до SAP?

SAP-системи спроєктовані для операційної діяльності, а не для веб-трафіку. Прямі виклики з PHP або Node.js через RFC (Remote Function Call) — антипатерн. По-перше, SAP JCo (Java Connector) не має нативної підтримки для PHP, потрібен проміжний сервіс на Java або Python. По-друге, кожен запит від кількох тисяч відвідувачів може призвести до блокувань таблиць в SAP. Рекомендована архітектура — асинхронна шина з чергами.

Сайт (PHP/Node.js)
    ↕
Middleware (SAP BTP Integration / MuleSoft / власний сервіс)
    ↕
SAP (через SAP PI/PO, OData, SOAP)

Як SAP BTP спрощує інтеграцію?

SAP Business Technology Platform (BTP) Integration Suite — хмарна ESB, що надає моніторинг, retry-логіку та трансформацію даних. Замість того, щоб писати middleware з нуля, ми використовуємо готові конектори для OData, SOAP та IDoc. Це скорочує час розробки на 30–40% та знижує кількість помилок під час передачі даних. Для багатьох проєктів використання BTP окупається за 6–12 місяців, забезпечуючи економію до €50,000 на рік.

Методи підключення до SAP

SAP OData — сучасний стандарт. Він публікується через SAP Gateway, підтримує CRUD та фільтрацію. За нашим досвідом, OData скорочує час розробки інтеграції на 25% порівняно з RFC, а також є кращим для веб-інтеграції завдяки REST-архітектурі. Приклад запиту:

GET https://sap-server/sap/opu/odata/sap/ZSD_ORDER_SRV/OrderSet?
    $filter=CustomerID eq '1234567'
    &$expand=OrderItems
Authorization: Basic {credentials}

SAP рекомендує використовувати OData як основний протокол для інтеграції (документація на SAP Help Portal).

RFC досі використовується для високонавантажених операцій, але потребує окремого сервісу-адаптера. IDocs незамінні для масових асинхронних обмінів (наприклад, нічне завантаження номенклатури).

Приклад отримання матеріалів через OData (Python)

import requests

response = requests.get(
    'https://sap-gw/sap/opu/odata/sap/ZMM_MATERIAL_SRV/MaterialSet',
    params={
        '$filter': "Plant eq '1000' and MaterialType eq 'FERT'",
        '$select': 'MaterialNumber,Description,BaseUnit,StandardPrice',
        '$format': 'json'
    },
    auth=(SAP_USER, SAP_PASSWORD),
    verify=True
)

materials = response.json()['d']['results']

B2B-портал з SAP-інтеграцією

Для корпоративних клієнтів B2B-портал на базі SAP надає:

• Індивідуальні ціни з SAP SD (умови ціноутворення для конкретного покупця)
• Кредитний ліміт та поточну заборгованість (SAP FI)
• Історію замовлень з можливістю повтору
• Статус відвантаження та документи (накладні, рахунки-фактури)
• Особистих менеджерів із SAP CRM

Що входить у роботу: покрокова інструкція

1. Аудит поточної SAP-системи — виділення необхідних модулів (SD, MM, FI, CRM).
2. Проєктування архітектури middleware — вибір між SAP BTP, MuleSoft або власним сервісом на Node.js.
3. Налаштування OData-сервісів на стороні SAP (SAP Gateway).
4. Розробка інтеграційного шару на сайті (REST-клієнти, черги, кешування).
5. Тестування сценаріїв — синхронізація замовлень, залишків, цін.
6. Документація та навчання адміністраторів.

Типові помилки при інтеграції SAP

Терміни та економічний ефект

Термін розробки серйозної B2B-інтеграції з кількома модулями — від 3 до 6 місяців. Вартість розраховується індивідуально після аудиту, але типова вартість проєкту становить від €20,000 до €100,000. При цьому клієнти відзначають зниження витрат на ручну синхронізацію на 30–50% та скорочення часу обробки замовлень на 40%. Окупність інвестицій зазвичай становить 6–12 місяців. Крім того, з SAP інтеграція веб-сайт з використанням OData REST SAP дозволяє автоматизувати обмін даними з SAP. OData швидше RFC в 2 рази за пропускну здатність.

Чому обирають нас

5+ років досвіду інтеграції SAP з веб-додатками. Понад 20 успішних проєктів для великих підприємств. Сертифіковані фахівці з SAP та веб-розробки. Ми надаємо гарантію якості на всі роботи. Отримайте консультацію з інтеграції SAP з вашим сайтом — зв'яжіться з нами. Замовте аудит поточної системи та дізнайтеся, як заощадити до 50% часу на синхронізації.

Як вирішити проблеми синхронізації з 1С?

Ранок понеділка. Менеджер відкриває сайт і бачить, що позицію, яку розпродали в п'ятницю, досі «в наявності». Три клієнти вже оплатили товар, якого немає. Ми стикаємося з цим болем регулярно: відсутність синхронізації між 1С та інтернет-магазином б'є по грошах та репутації. Вирішуємо проблему під ключ — налаштовуємо обмін так, щоб облікова система та вітрина оновлювалися синхронно, без втрати даних та з гарантією консистентності. Після нашої інтеграції один із клієнтів скоротив кількість повернень на 50% і зекономив понад 20 000 грн за перший місяць.

1С — облікова система більшості українських компаній. Сайт — вітрина. Вони мають говорити однією мовою і робити це регулярно, надійно та без втрати даних. Наш досвід — понад 50 успішних інтеграцій для замовників з каталогами від 500 до 200 000 SKU.

Чому стандартний CommerceML не завжди рятує?

CommerceML — стандартний протокол обміну, який підтримують 1С:Управління торгівлею, 1С:Комплексна автоматизація та ряд інших конфігурацій. WooCommerce, Shopify та інші CMS мають плагіни для роботи з CommerceML (наприклад, «1С-Бітрікс» для своїх продуктів, окремі плагіни для WordPress). Потік: 1С ініціює обмін → надсилає ZIP-архів з XML на endpoint сайту → сайт розбирає, оновлює каталог.

Формат CommerceML — XML зі своєю схемою: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. Категорії, товари, характеристики, зображення, ціни, залишки. Головна складність — ієрархія характеристик в 1С та атрибути товарів на сайті не завжди збігаються один до одного. Потрібен мапінг. Для глибокого розуміння протоколу рекомендуємо документацію Wikipedia — там розглянуто всі нюанси схеми.

Як ми обходимо обмеження CommerceML

Для нестандартних конфігурацій 1С або коли CommerceML не підходить — пишемо HTTP-сервіс в 1С (вбудована можливість починаючи з версії 8.3) і взаємодіємо через REST JSON. Це дає повний контроль над структурою даних та частотою синхронізації, але вимагає розробки з боку 1С-програміста.

Для enterprise-завдань з кількома обліковими системами — Message Broker (RabbitMQ, Apache Kafka) як посередник. 1С публікує події в чергу, сайт підписується і обробляє. Гарантована доставка, буферизація при недоступності однієї зі сторін.

Що синхронізуємо і як

Каталог (товари, категорії, характеристики). Найоб'ємніша частина. Повне вивантаження при першому запуску, дельта-оновлення в подальшому. При імпорті CommerceML: парсимо XML через PHP SimpleXML або XMLReader (для великих файлів — тільки XMLReader, інакше memory limit). Зіставляємо товари за GUID з 1С, який зберігаємо в окремому полі БД. Якщо товар видалено в 1С — приховуємо на сайті, не видаляємо (історія замовлень може посилатися).

Залишки та ціни — окремий ПакетПредложений в CommerceML, оновлюється частіше каталогу. Критично робити атомарно: не оновлювати залишок по одному, а транзакцією. Інакше в момент оновлення користувач може побачити неконсистентний стан. Частота: раз на годину для спокійного режиму, раз на 5–15 хвилин для активної торгівлі.

Замовлення — двосторонній обмін. Сайт → 1С: нове замовлення передається з номенклатурою, кількістю, цінами, контактними даними покупця. 1С → сайт: статус замовлення (оплачено, зібрано, відвантажено, доставлено). Для передачі замовлень — або той же CommerceML (блок Документи), або прямий REST-виклик при створенні замовлення на сайті.

Типові проблеми, які вирішуємо

Дублювання товарів. 1С-оператор створив позицію з помилкою в артикулі, потім виправив. На сайті — два товари. Рішення: зіставлення за GUID з 1С (не за артикулом), GUID незмінний.

Кирилиця в XML та кодування. 1С історично працює з Windows-1251. CommerceML файл може прийти в CP1251, PHP очікує UTF-8. mb_convert_encoding() або iconv() в перших рядках парсера — обов'язково.

Тайм-аути при великому вивантаженні. Каталог з 100 000 позицій — це 50–200MB XML. PHP default execution time 30s не вистачить. Рішення: CLI-команда (Laravel Artisan або Symfony Console), запускається через cron, без HTTP timeout. Або chunked processing через XMLReader з частковими комітами в БД. Для обробки великих масивів даних використовуємо LazyCollection в Laravel — це дозволяє тримати в пам'яті лише один чанк.

Зображення. 1С може передавати зображення Base64 всередині XML (роздуває файл в 1.3 рази) або посиланнями на файли. Другий варіант кращий. Скачуємо асинхронно, конвертуємо в WebP, кладемо в медіабібліотеку.

Кейс: інтернет-магазин запчастин, 85 000 SKU

Синхронізація через CommerceML кожні 30 хвилин. Проблема: повне вивантаження займало 18 хвилин, в результаті нове вивантаження починалося, поки старе ще йшло. Рішення: lock через Redis (SET nx ex), дельта-вивантаження (тільки змінені позиції за останні 2 години через фільтр в 1С), обробка через чергу з 20 паралельними workers. Час синхронізації: 18 хвилин → 2.5 хвилини, конфліктів немає. Економія ресурсів сервера — до 40% навантаження CPU.

Як відбувається синхронізація даних з 1С?

Порівняння методів інтеграції

CommerceML в типових сценаріях швидше REST для синхронізації каталогу в 2-3 рази за рахунок бінарної упаковки XML та компактного формату. Однак, якщо потрібна кастомна логіка обміну, REST дає повну гнучкість.

Процес і терміни

Покроковий алгоритм налаштування інтеграції:

1. Аудит конфігурації 1С (версія, тип конфігурації, можливості вивантаження).
2. Проектування мапінгу даних — узгодження полів 1С та атрибутів сайту.
3. Розробка приймача на сайті та відправника в 1С (плагін або кастомний модуль).
4. Тестування на реальних даних: вивантаження каталогу, перевірка залишків, створення тестового замовлення.
5. Налаштування розкладу синхронізації (cron, черги) та моніторингу перших обмінів.
6. Документування схеми мапінгу та логіки обробки помилок.

Участь 1С-програміста з боку клієнта — обов'язково, або ми залучаємо перевіреного спеціаліста. Замовте аудит вашої системи обліку — ми оцінимо складність інтеграції за один робочий день.

Що входить в результат (deliverables)

• Документація: схема мапінгу, формати даних, логіка обробки помилок.
• Налаштований розклад синхронізації з логами виконання.
• Доступ до моніторингу (Grafana/ELK — за домовленістю).
• Навчання менеджерів: як запускати ручний обмін, як читати логи.
• Гарантійна підтримка після запуску — 2 тижні (виправлення інцидентів).

Отримайте консультацію

Вартість інтеграції розраховується індивідуально після аудиту — залиште заявку на консультацію. Зв'яжіться з нами, щоб отримати детальний план інтеграції для вашого бізнесу. Понад 7 років досвіду в інтеграціях з 1С — гарантуємо стабільну синхронізацію без сюрпризів.