OData против BAPI в среде SAP

БАПИ

• SAP-собственный
• Основан на RFC, собственном протоколе SAP.
• Фиксированная структура ввода (без URL с гибкими параметрами запроса)
• Фиксированная структура вывода (структуры, таблицы, но не динамический номер каждой)
• Ручная документация описывает структуру службы только для людей.
• Вывод: хорошо подходит для соединения систем SAP друг с другом

OДата

• Открытый стандарт
• Основан на REST, де-факто стандартном веб-протоколе для интеграции приложений.
• Гибкий язык запросов (фильтрация, сортировка, развертывание, связывание, поиск)
• Гибкий вывод (сущность, набор сущностей, расширенная сущность)
• Документ метаданных объясняет структуру сервиса в машиночитаемом формате
• Вывод: хорошо подходит для подключения систем SAP к SAPUI5 и аналогичным пользовательским интерфейсам.

Основное преимущество OData по сравнению с BAPI — это гибкость, открытые стандарты и машиночитаемость. Это может быть ценой скорости.

Это сравнение немного некорректно. В то время как BAPI был изобретен для подключения серверов, OData скорее используется для подключения серверов к клиентам. Несмотря на то, что изобретатели OData, возможно, имели в виду подключения к серверу, чистый REST стал стандартом де-факто для подключения этого уровня. Поэтому было бы чище сравнить BAPI с REST и, возможно, родственными стандартами, такими как веб-сервисы.

Можно эмулировать OData через интерфейс BAPI: (URL-запрос) ввод строки, (результат JSON) вывод строки. Таким образом, вы можете сделать вывод, что они эквивалентны с точки зрения мощности. Однако базовый протокол отличается, и системы с большей вероятностью распознают HTTP-протокол под REST, чем проприетарный RFC-протокол SAP.

с точки зрения функциональности BAPI может быть более конкретным и адаптированным к вашему варианту использования, чем OData источник данных. Но OData — это стандарт, а это означает, что вы бесплатно получаете множество инструментов во время разработки клиента, например, клиентскую библиотеку OData js. Вы можете использовать платформы, которые могут использовать источники данных OData, вместо того, чтобы программировать отдельные BAPI, созданные вами или предоставленные SAP.

Разработчики клиентов могут не знать тонкостей каждой подсистемы, из которой им приходится извлекать данные. У вас есть бизнес-знания, о которых вам нужно позаботиться, и технические зависимости, которые необходимо соблюдать. Вы могли бы предоставить набор стандартных BAPI, чтобы добраться до аналогичной точки (если вы проигнорировали все, что не является SAP), но OData — это именно то, что вам нужно. Стандартный интерфейс, где хотя бы техническая часть разделена между источниками данных.

Видите ли вы значение в OData, зависит от того, откуда вы пришли. Если вам требуется разработать одно узкоспециализированное клиентское приложение, которое считывает и записывает данные из системы SAP и в нее, BAPI вполне могут быть самым простым выбором. Но если вам нужно настроить какую-то панель мониторинга генерального директора, которая объединяет несколько источников данных и отображает все виды операционной статистики, такие как данные о продажах, производственные перерывы, движение денежных средств и все, что вы можете придумать, вам будет легче интегрировать Источники данных OData в стандартные приложения, которые, вероятно, используются для настройки такой панели мониторинга.

На данный момент, если вы просматриваете центр API из SAP https://api.sap.com/package/SAPS4HANACloud?section=Artifacts для S/4 HANA Cloud, вы увидите, что SAP продвигается в направлении ОТКРЫТОГО протокола, такого как oData и SOAP. И вы можете легко превратить свой BAPI в сервис oData Serivce или SOAP.