SAP Graph: API Sandbox on preview | Hacker News Reader

SAP Graph: API Sandbox on preview

beta.graph.sap

92 pointszxienin53 comments

I’ve worked with this and in the context of the SAP enterprise world and all of its ancient and weird stuff this is quite a step forward.

It is however unfortunate that they choose to use OData which is horrible to work with, and the API itself suffers from common REST inefficiencies such as chattiness.

Another thing that bugged me is that this is not just a reverse proxy towards other SAP SaaS api’s, but an actual abstraction layer on top of those. Which makes me believe this probably won’t scale very well into more complex cases.

The best way to look at this I think, is probably as an API for simple in-house apps at companies which use more than one SAP SaaS solution. At least you won’t be using SOAP anymore ;)

> I’ve worked with this

How? (this appears to be preview with “sandbox APIs”)

Would you mind expanding on your experience working with this?

> It is however unfortunate that they choose to use OData

Had the same sentiments. They take good step forward and then chose OData (bummer)

We worked with SAP on a tech talk about Graph, you can watch it over here: https://events.sap.com/teched/en/session/51579

Ah, am sure that app wasn’t built in minutes :-)

Keeping in mind you are 45 strong company setup, is your shop seriously getting onboard with this?

And sell own apps within SAP customer base using these APIs?

Building your stuff is one piece. Really, to sell it within SAP customer base, is battle in itself. Unless you are Accenture, Capgemini, IBM etc.

So even if Graph makes some improvement on technology front, why would a smaller scale shop be willing to build anything if they can’t tap easily into that customer base.

SAP committed itself to oData. With Fiori Elements you can generate UIs from oData endpoints. Their super crappy frontend framework UI5 also integrates with it quite strongly.

Yeah, UI5 is quite a nightmare. Working with OData is a dream with it. I always found it really difficult to make the dreams of designers work with SAPUI5. Hard to customise components or write custom ones.

Why do you find OData horrible to work with? I've used it with in a personal project and found it to be a very easy way to make my API queryable.

In many relational db implementations OData is a serialization of SQL in a URL. A human factor problem with that is poorly optimized SQL. An architectural problem is that db schema changes break URLs.

To add on this. When you are working with HTTP APIs, do you really need to go full SQL like?

Well, there is a balance. In many circumstances, the same service used by different applications may over-fetch or under-fetch data [0]. OData allows the application to describe exactly what they need including things like filtering, ordering and aggregation that might be less efficient to perform on the application side [1]. Having performed the OData.org Basic Tutorial [2] using just curl, I was positively impressed by the concept and simplicity.

0. https://towardsdatascience.com/graphql-grafana-and-dash-7aa9...

1. https://www.progress.com/blogs/rest-api-industry-debate-odat...

2. https://www.odata.org/getting-started/basic-tutorial/

> OData allows the application to describe exactly what they need including things like filtering ..

I hear this frequently. I have _never_ faced the need to have complex set of capabilities (OData) promising to solve a problem that I do not have.

I simply craft my APIs very well.

Did you find twilio, stripe, fb.. use OData out in the open?

When you offer the real choice to API developer, API consumer and they naturally gravitate to OData, then we're talking. You think developers within SAP ecosystem get choice? Its shoved down their throat.

And this is why I believe SAP Graph team is not really serious about "zero SAP knowledge required" crowd.

I have worked with SAP Gateway for a long time but I don't think it's a major issue that it used OData. Maybe it's because our ABAP developer had a good sense. Compared to the Dynamics CRM it made more sense.

When you use SAP Gateway, you are already so locked into the tooling, that protocol, syntaxes appear less undesirable element.

Yeah, that's true. You already part of the SAP dark side, lol Especially, if you messing around with ABAP which is just an odd language

Gosh OData is so poorly designed that the only way something like that can even think that it is relevant is if one or two paper pushers inside a big corporate company will force its devs to use it. And so they did.

I've never used it. What's so bad about it?

> Zero SAP knowledge necessary

That’s a tall claim. If one has ever worked (or tried to) within SAP world, you know what I am talking about.

Also no mention of testing, which from my experience is the last, and hardest barrier to overcome.

So ... You can integrate against compatible product using their GRAPH.

Should you become a powerful startup which SAP enterprises love to use, how much does it take for upstream SAP to change the API or remove API features, which will kill your company? (Rhetorical question)

To be fair it is more likely that this will be used by existing enterprise customers of SAP who otherwise would consider migrating off.

I just played with preview APIs. Can’t imagine what edge enterprise customers get over anyone else who’s willing to use it

> upstream SAP to change the API or remove API features

Valid in equal measure with any API provider though.

> powerful startup which SAP enterprises love to use

you mean a startup which provides “enterprise grade”, definition of which SAP itself helped to make? (also rhetoric)

My thinking is that SAP doesn't have that kind of culture like Amazon has, nor do they operate at Amazon-like speeds, so I would say the risk would be minimal for a decent startup. Hell they might even try to buy you at first, not the worst thing in the world!

The goal here is to ease integrations with both the SAP ERP and CRM solutions.

Historical integrations relied on middleware, proprietary libraries, and likely custom ABAP code.

Are you part of SAP Graph team?

If so, can you expand on above, wrt to workforce person, skills, travel request API resources in the explorer? These aren’t part of either CRM or ERP. Mostly, they come from SAP acquisition products (SuccessFactors and Concur)

It’s more for Indian outsourcing companies to build spaghetti code line of business applications for large-cap B2B companies.

I am a developer deeply ingrained in the SAP (abap) world, and it makes me happy to have a consolidated API. There is production level stuff here: https://api.sap.com/ with a high degree of complexity and diversity; and mostly for cloud systems.

If I come with “zero SAP knowledge”, I can’t make head or tails of api.sap.com

Thanks SAP for letting me feel like it's 2010, when everyone fell in love with REST (again).

Agree, although I feel like I never fell out of love. Honest question, why has excitement waned? Or has it?

I don't see how... what's replaced REST? Maybe other technologies have added to it (like graphql and gRPC?)

Excitement has waned a bit.

Seen as verbose.

Also it's been used in places it shouldn't have been, so 'REST sucks'

Over the past few years, APIs I've had to use have been around a 50/50 split between REST & RPC-ish things.

And in the last month... 1 SOAP interface (!)

How relevant is SAP still? Is it still big? It's been years since I worked with any SAP system. Do big corps still use them or many of them have moved away to more "modern" systems?

They’re $30B, with YoY growth in teen double digits.

https://www.sap.com/docs/download/investors/2020/sap-factshe...

Acquisitions gave them some breather.

(Disclosure: I work at SAP.)

> How relevant is SAP still? Is it still big?

Our marketing likes to throw this phrase around that 80% of all transactions worldwide touch an SAP system at some point.

> [Have big corps] moved away to more "modern" systems?

What does "more modern" mean to you? Honest question.

When people talk ask for "modern" software, most times it's either about being buzzword-compliant (cloud-native FaaS on Kubernetes or whatever) or about throwing away old idiosyncrasies (or both). Obviously the traditional SAP system (i.e. R/3 or more recently S/4 HANA) has a metric ton of idiosyncrasies, much of it stemming from its 40+ years long lineage. But personally, I'm pretty sure that a full-on rewrite with modern tools would accumulate a similar amount of baggage on the way to feature parity. Business processes just are very complex. Just think about the large number of stakeholders involved in each process, along with the legal requirements the processes must fulfil.

And by the way, a significant part of the baggage is due to stakeholders wanting to make the system more modern. These days, you don't need the SAP GUI desktop app to access an SAP system. There are web-based UI frameworks in there as well. But of course, the old stuff often has to stay because of compatibility requirements or because no one dares to touch the working part of the system. Windows is another example of such a layered architecture with the new-fangled stuff laying on top of the older components.

I'm not saying this to belittle the idea of a more "modern" system. Heck, my team runs an internal cloud solution using OpenStack deployed on Kubernetes, so we're pretty buzzword-compliant already. :)

I just think that if you define "modern" as "the project started less than X years ago", that's not a very useful metric for evaluating the merits of such a system.

I absolute agree with this sentiment. Software can only be simple if it covers a narrow set of use cases. ERP software for large companies that works across borders and industries will always have to handle a million edge cases and accumulate "weirdness" along the way.

SAP _Graph_ and then it's a REST API? Not GraphQL?

I mean, both types of API have their use cases but that's just an attempt at riding the latest hype.

https://beta.graph.sap/docs/beta

> What is SAP Graph? SAP Graph is a network of connected data objects that are stored and owned across different SAP solutions and technologies. The data objects that are made accessible through SAP Graph in an interconnected data model can be consumed through an HTTP-based API, which exposes data from multiple SAP systems in a unified schema.

Use of term Graph, in API context, seems to default to GraphQL assumption. But I don’t see anywhere GraphQL mentioned.

Above snippet better explains the term Graph in _SAP Graph_

Facebook's "Graph" API was REST only when it came out in late 2000s.

You know it‘s an SAP website when the term “programming model” is used...

Spoken from experience? You may have something there.

Put hundreds of PhDs in one place. Then even a simple SPA will have programming models (plural) behind.

Quickly reading through, I thought these are GraphQL APIs. Missed opportunity?

Is the implication that wrt adoption curve: GraphQL > REST?

Nope, OData REST APIs. This is part of a bigger initiative to standardize data across Microsoft, Adobe, and SAP.

OData. That’ll surely take them far within developers. Maybe SAP brainwashed devs, who are willing to bear any level complexity SAP throws out. Not beyond.

Why position “zero SAP knowledge required” and then throw odata in?

> This is part of a bigger initiative to standardize data across Microsoft, Adobe, and SAP

I doubt it. You’re referring to ODI [1], which seems unrelated to this.

[1] https://www.microsoft.com/en-us/open-data-initiative

What exactly is the problem with OData, and what do you recommend instead? This is an area I'm unfamiliar with.

If you've already spent time working with REST (or "REST like") APIs, either as API developer OR app dev consuming a one, best way to understand the problem, is now (try) to work with OData.

Search HN, there are enough discussions on this.

Outside SAP and Microsoft circles, it's easy to forget such a thing even exists.

I've worked with SAP way too much - it's at least as horrible as you imply.

But I've also worked with both OData and GraphQL at lot, and I don't understand your beef with OData, and certainly don't get your claim that it's more complex than GrahpQL. IMO, OData is quite a lot simpler than GraphQL, and I actually prefer it.

where is GraphQL v/s OData above?

Not sure if I've misinterpreted your comment then?

The GP asked if these were GraphQL APIs, then you said:

"OData. That’ll surely take them far within developers. Maybe SAP brainwashed devs, who are willing to bear any level complexity SAP throws out"

and also:

"Why position “zero SAP knowledge required” and then throw odata in?"

can't seem to reply to your comment below (no 'Reply' option for me, likely HN feature to avoid too deep nested threads)

> Not sure if I've misinterpreted your comment then?

Yes, misinterpreted. Refer: https://news.ycombinator.com/item?id=22807146

Sorry, but I still don't get what you're trying to say - I've read the comment you linked to, and I understand it as an implication that OData is problematic somehow.

In another comment in reponse to someone complaining about OData, you also said:

"Had the same sentiments. They take good step forward and then chose OData (bummer)"

Stil scratching my head about what I'm misinterpreting here.

Microsoft Graph is also based on OData [1].

I‘d say it is more about enterprise than just SAP.

Granted, SAP is strongly invested in OData. The SAPUI5 framework [2] has a ton of built in UI components and quite a few provide complex functionality „for free“* when bound to properly annotated OData models.

1: https://docs.microsoft.com/en-us/graph/overview

2: https://sapui5.hana.ondemand.com

* the cost and complexity is moved closer to the data layer, away from UI development. not free as in free beer.

disclosure: I work at SAP, but I am not involved with the topics discussed here.

Reply on news.ycombinator.com