Вправа з n8n та SAP: отримання даних замовлень на продаж і сповіщення
Редакційна вправа з n8n і SAP: отримайте дані замовлень, перетворіть їх і запустіть сповіщення, з оновленням сесії та обробкою помилок.
Перевірено за наведеними джерелами .
Редакційна вправа: огляд завдання та мета навчання
Це редакційна вправа для SAP-архітекторів та розробників інтеграцій, які хочуть перевірити, як n8n SAP-процес міг би отримувати дані замовлень на продаж, перш ніж будувати такий процес для промислового використання. Завдання: підключити n8n до пісочниці SAP Business One Service Layer або до пісочниці SAP S/4HANA Sales Order OData, увійти в систему, отримати пакет записів замовлень на продаж, перетворити їх у чисту структуру та запустити етап подальшого сповіщення, використовуючи лише вузол HTTP Request n8n та документовані API SAP, з оновленням сесії та обробкою помилок, вбудованими в процес.
Ми розробили цю вправу на основі документованих можливостей SAP та n8n; ми самі не створювали, не запускали і не перевіряли її, тож сприймайте це як схему для випробування у вашій власній пісочниці, а не як перевірений рецепт. Мета навчання вужча, ніж просто підключення n8n до SAP: вона полягає у визначенні того, чого сесійний корпоративний API очікує від того, хто його викликає, і де закінчується робота n8n, а де починається роль SAP як системи обліку.
Передумови: доступ до пісочниці, облікові дані та інструменти
Для SAP Business One власний навчальний матеріал SAP щодо Service Layer показує запит на вхід через базову автентифікацію (Basic Authentication), який надсилає назву бази даних компанії, ім'я користувача та пароль на кінцеву точку Login, використовуючи як приклад демонстраційну базу даних. Для спроби в пісочниці потрібні ті самі три значення для будь-якої доступної вам бази даних компанії, а також мережевий доступ до цього екземпляра Service Layer звідки б не запускався n8n. З боку n8n загальні варіанти облікових даних вузла HTTP Request включають Basic auth, Custom auth та Digest auth — будь-який з них може нести запит на вхід або отриману сесію.
Для SAP S/4HANA Business Accelerator Hub від SAP пропонує згенеровану ШІ пісочницю API для випробування REST та OData API, включно з кінцевими точками Sales Order, без реального бекенду; вона обмежена 20 викликами на користувача на місяць і повертає імітовані відповіді. Для реальних даних та реальної поведінки сесій функція Configured Environment у Hub дозволяє розробнику випробувати API на власній ліцензованій продуктивній або тестовій системі, підтримуючи OAuth 2.0 поряд з Basic та автентифікацією за ключем API. Таблиця нижче показує, що дає кожен варіант, перш ніж ви почнете будувати.
| Варіант | Автентифікація | Дані | Найкраще для |
|---|---|---|---|
| SAP Business One Service Layer (демо-БД) | CompanyDB, ім'я користувача, пароль через кінцеву точку Login | Реальні демо-дані компанії | Перевірка реального входу, тайм-ауту сесії та поведінки 401 |
| Згенерована ШІ пісочниця API S/4HANA | Нічого крім доступу до Hub | Імітовані, згенеровані ШІ відповіді | Лише формування структури запиту та відповіді |
| S/4HANA Configured Environment | Basic, ключ API або OAuth 2.0 | Дані вашого власного ліцензованого тестового орендаря | Перевірка на даних власного ліцензованого орендаря |
На нашу думку, початок з демонстраційної бази даних Business One є практичним вибором для цієї вправи: поведінка входу, тайм-ауту та повідомлень про помилки документована найповніше з усіх трьох варіантів, тоді як імітована пісочниця S/4HANA корисна лише для формування запитів, а не для спостереження за реальним закінченням сесії.
Sources: Logging In and Out Using Basic Authentication with Service Layer, Managing Service Layer Settings | SAP Help Portal, 3383703 - SAP Business One Service Layer returns "Invalid session or session already timeout" error | SAP Knowledge Base Article, HTTP Request | Nodes | n8n Docs, Trying Out APIs in a AI-generated API Sandbox | SAP Help Portal, Trying Out APIs in a Configured Environment | SAP Help Portal
Вхідні дані та обмеження: лише документовані API
Жодна з пісочниць не надає прямого доступу до бази даних, тож процес повинен проходити через документовані кінцеві точки та дотримуватися тієї версії протоколу, яку SAP наразі підтримує для кожної з них. Список нижче описує, що це означає для цієї вправи з n8n та SAP, охоплюючи Service Layer, інтерфейс Sales Order A2X у S/4HANA, пагінацію та обмеження публічних пісочниць.
- Використовуйте сутність Orders у Service Layer або інтерфейс Sales Order A2X у S/4HANA, але ніколи — прямий запит до бази даних.
- SAP припинила підтримку OData версії 3 у Service Layer починаючи з пакета функцій SAP Business One 2405, зробивши OData версії 4 основним протоколом там.
- Сервіс Orders також визначає спеціальні дії, наприклад дію скасування, для операцій, які звичайні виклики створення-читання-оновлення-видалення не можуть виразити.
- Документація API SAP S/4HANA версії 2608 наводить інтерфейс Sales Order як у варіанті OData V4, так і у варіанті OData V2.
- Власний посібник SAP щодо Service Layer присвячує окремий розділ пагінації результатів запитів замовлень, окремо від одностраничного GET.
- Вузол HTTP Request у n8n може самостійно проходити послідовні сторінки за допомогою режиму пагінації «Update a Parameter in Each Request».
- Сприймайте публічну імітовану пісочницю S/4HANA лише як засіб для формування запитів; опис старішої публічної пісочниці 2017 року як доступної лише для читання, востаннє оновлений у 2024 році, може не відображати сьогоднішні варіанти на основі Hub.
Sources: Service Layer API Reference, Working with SAP Business One Service Layer, Sales Order (A2X, OData V4) | SAP Help Portal, Sales Order (A2X, OData V2) | SAP Help Portal, HTTP Request | Nodes | n8n Docs, S/4HANA Cloud Sandbox is now available in SAP API ... - SAP Community
Створення n8n SAP-процесу: автентифікація, отримання даних, перетворення та сповіщення
Автентифікація стоїть на першому місці для цього n8n SAP-процесу. Для Service Layer вузол HTTP Request надсилає базу даних компанії, ім'я користувача та пароль на кінцеву точку Login, дотримуючись шаблону базової автентифікації, який показує власний навчальний матеріал SAP, а відповідь містить сесію, яку повторно використовують наступні виклики. Для Configured Environment у S/4HANA OAuth 2.0 є одним з доступних варіантів автентифікації поряд з Basic та ключем API, тож натомість обмін токенами може зберігати тип облікових даних OAuth2 вузла.
Отримання записів — це другий вузол HTTP Request, GET-запит до сутності Orders або інтерфейсу Sales Order A2X, що використовує параметри запиту OData для вибору полів, впорядкування результатів та обмеження розміру сторінки. Публікація 2025 року в SAP Community від консультанта SAP Business One будує подібний GET-запит до Service Layer як один з етапів більшого процесу звітності; її приклад шляху використовує застарілий маршрут v1, тож натомість спрямовуйте запит на шлях v4. Для понад однієї сторінки режим пагінації вузла «Update a Parameter in Each Request» може проходити через послідовні запити.
Перетворення записів звідси — звичайна робота в n8n: вузол Edit Fields або Code перетворює необроблене корисне навантаження OData на поля, потрібні решті процесу, замінюючи внутрішні назви полів SAP на ті, які шаблон сповіщення може читати безпосередньо.
Наступний крок — електронний лист, повідомлення в чаті або запис у таблицю відстеження — читає саме ці перетворені дані, а не напряму з SAP, тож повільний або невдалий виклик SAP ніколи не залишить сповіщення напівготовим.
Sources: Logging In and Out Using Basic Authentication with Service Layer, HTTP Request | Nodes | n8n Docs, Trying Out APIs in a Configured Environment | SAP Help Portal, Automating SAP Business One Sales Reporting with n... - SAP Community
Оновлення сесії та обробка помилок
Документація з конфігурації Service Layer від SAP встановлює стандартний тайм-аут неактивної сесії на 30 хвилин, і це налаштування можна змінити. Коли сесія закрита або іншим чином недійсна, власний навчальний матеріал SAP показує, що наступний запит повертає HTTP 401 з повідомленням «Invalid session or session already timeout», а база знань SAP підтверджує, що те саме повідомлення може з'явитися на будь-якому запиті після закінчення сесії в SAP Business One 10.0, версія для SAP HANA. Процес, який очікує успіху на кожному виклику, зламається вже при першому тайм-ауті посередині виконання.
За замовчуванням вузол HTTP Request у n8n вважає успішними лише відповіді 2xx, але його опція «Never Error» дозволяє процесу самостійно читати код стану та розгалужуватися: при 401 знову викликати кінцеву точку Login, а потім повторити вихідний запит отримання даних. Блог постачальника від розробника конкуруючого community-вузла SAP OData стверджує, що сервіси OData SAP також вимагають отримання токена CSRF перед кожною операцією запису; ми б радили сприймати це як власний опис постачальника, який варто перевірити за документацією самого SAP, перш ніж покладатися на нього для чогось понад цю вправу лише для читання.
Sources: Logging In and Out Using Basic Authentication with Service Layer, Managing Service Layer Settings | SAP Help Portal, 3383703 - SAP Business One Service Layer returns "Invalid session or session already timeout" error | SAP Knowledge Base Article, HTTP Request | Nodes | n8n Docs, How I Built the First Real SAP OData Node for n8n | Avanai
Критерії завершення та підсумки
Вважайте вправу завершеною, коли процес входить в систему й отримує записи замовлень на продаж із документованої кінцевої точки, застосовує етап перетворення, що створює чисті, передбачувані поля, надсилає подальше сповіщення, сформоване з цих полів, і виявляє відповідь 401 або тайм-аут та повторно автентифікується перед повторною спробою, а не просто мовчки падає.
Протягом усієї цієї вправи SAP залишається системою обліку для самого замовлення на продаж; n8n ніколи не замінює власною копією дані SAP. Ми вважаємо, що саме такий розподіл зазвичай найкраще працює на практиці для інтеграцій n8n і SAP: SAP продовжує володіти записом замовлення та його бізнес-правилами, тоді як n8n послідовно виконує вхід, повторні спроби, перетворення та все, що відбувається з даними після того, як вони залишають SAP.
