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 ;)
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 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.
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.
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.
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.
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.
> 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.
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)
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)
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!
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.
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?
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.
> 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_
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.
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.
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.
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.
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.
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 ;)