[myspy]

The problem with SAP APIs and services is that each user that uses the system is billed individually. When you try to build an app that helps one department you have to pay for each of the user accounts despite the fact they just use your app, not all the other stuff. On top, there are no real pricing schemes to know what is coming at you. Either 100$ per user per month or 5000$. Depends. The cloud solution doesn't make that easier.

[Arwill]

I think the logic is that the Web API's are for apps doing things you would otherwise do in SAP's own GUI.

But i agree, SAP is not for those who are sensitive to license prices. Most commonly the solution is a third-party custom built software, that interfaces the data into the back-end SAP system.

The OP's comment was about scraping data from pages generated from SAP Web apps. I tried to point out that it make little sense, as there are proper ways of interfacing data (even over HTTP).

[myspy]

We did that, with one technical user to share data between our backend and SAP, but got the news that it's not legal and must be licensed per user that's using our app. Even over http you can't access data in SAP without paying your fees accordingly.

[Arwill]

It is legal to do that. Its the question how tight your app was doing it? If you just send user actions and answers over HTTP back and forth using a technical user, that's like sharing the user. But if you have your own billing software (for example), and submit finished bills with a SOAP request (for example) to SAP, that is completely ok.

[lucasverra]

ehh if you have access throught http(hopefullly)s into a webbrowser and consume it with your eyes, can't i just puppeteer it ? heck event print screen and OCR ?