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