
SAP Graph: API Sandbox on preview - zxienin
https://beta.graph.sap
======
rvanmil
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 ;)

~~~
zxienin
> 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)

~~~
brodo
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.

~~~
wdb
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.

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

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

------
unixhero
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)

~~~
rpncreator
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.

~~~
zxienin
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)

------
_glass
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/](https://api.sap.com/) with a high degree of complexity
and diversity; and mostly for cloud systems.

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

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

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

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

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

~~~
majewsky
(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.

~~~
dx034
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.

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

~~~
zxienin
[https://beta.graph.sap/docs/beta](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_

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

~~~
zxienin
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.

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

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

~~~
zxienin
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](https://www.microsoft.com/en-us/open-data-initiative)

~~~
GordonS
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.

~~~
zxienin
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](https://news.ycombinator.com/item?id=22807146)

~~~
GordonS
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.

