[greatartiste]

Years ago I was involved in a project to scrape certain info out of a SAP system with a web interface. It would have been easier to do it with a API but my conversations with the SAP people at work were going nowhere (is it me or do SAP IT people have no concept of how things are done outside the world of SAP ?).

Anyway I started looking through the Javascript the browser automatically downloads and found there was 10s of MBs of un optimised code only a tiny percentage of which was being used. It was horrific and it was easy to understand why the system was so mind blowingly slow.

[zxienin]

> is it me or do SAP IT people have no concept of how things are done outside the world of SAP ?

SAP has strong NIH syndrome. They could get away with it due to their dominance. So these guys are in echo chamber of own. It reflects and explains the observation you have here.

> 10s of MBs of un optimised code only a tiny percentage of which was being used

frameworks! they try to scale development with frameworks, and end up in dilbert-esque side effects like these.

[Arwill]

There are/were 5 different Web technologies over the years you could use to make Web apps for SAP. There are also standard WebService (XML SOAP) and REST interfaces over HTTP. There are also SAP native interfaces for specifically transferring data.

There are ways to do stuff in SAP, lots of implementation problems arise from the fact that people don't know how to do it right, and just try to apply whatever they do know. There is documentation and there are books.

[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 ?

[OldGuyInTheClub]

We figured out how to get at least some reports to export into Excel. Some others implemented MS Access dbs to postprocess exported SAP data. Browser tricks were also part of the mix. Then the directives came down that working outside of SAP was not acceptable and amounted to criticizing SAP.

I think SAP views APIs as a threat. That COBOL-like ABAP language is part of their lock in.

[hef19898]

Working outside SAP for things you are using SAP is one of the worst ideas, ever. You create data redundancy, jeopardize compliance, erode user trust and make migration and even simple changes near impossible. So yes, forbidding that is a good idea. One I enforced more than once. Well, at least I tried. Might even have worked once or twice.

Reasons why people started working outside of SAP:

- because they didn't know the system well enough and didn't receive proper training. Sometimes also out of pure spite.

- sometimes because SAP didn't have that functionality yet. Ship planning for example was an issue in the early 2000s IIRC

- because people wanted and had to use a SAP-standard process, but couldn't because somepone else ripped that standard appart to do something differetn. Either because the original standard for that was itself ripped appart by someone else. Or because people refuse to follow the standard out of reasons. Misusing standards is beast in SAP. Once you start with a single process, that spirals out of control and cannot be stopped. Part of the reason a lot SAP implementations just suck. Not purelySAPs fault so.

[benhurmarcel]

> because they didn't know the system well enough and didn't receive proper training

A lot of the interactions that simple employees have with SAP shouldn't require training though.

I shouldn't have to get a training to be able to fill a small list of hours, and it shouldn't take me 30 minutes to do so. I shouldn't have to get a training to be able to read a received request and validate it.

[tastroder]

While I get that sentiment I don't really see the ecosystem much worse than vendor lockin at any of the modern PaaS providers from a tech perspective. They always allowed integrators relatively extensive API access to their table model, last time I had to integrate that years ago the only hurdle was a bit of interfacing between the report / ABAP world and exposing it as a web service. Even management / security facilities were, albeit usually clunky, what you expect from a modern ecosystem. These days they seem to offer relatively modern and off the shelf APIs for quite a few of these tasks, especially for their cloud based offerings. I'm not sure that they see it as a threat, rather they want to be the single point of truth and lots of projects (completely separated from any tech aspect) would circumvent that.

Now was that a pain? Yes, sure. Especially the whole legal/certification/consultant crap you need to buy into alongside the software. But honestly, at least here in Germany, SAP ABAP/Java developers and consultants are easy to come by. Most of the problems I've seen in SAP related integrations are process related, not as much tech. If you're dealing with a customer that's already up and running in that ecosystem chances are that they already know their pain points, it's not really any different than any other large B2B integration in the space.

[zxienin]

> I think SAP views APIs as a threat. That COBOL-like ABAP language is part of their lock in.

This bit is changing now. They're still not there, but internal engineering teams are slowly getting it. There are high priority API first development projects underway.