6 ms·

SAP Graph: API Sandbox on preview

92 points by zxienin 7y ago

zxienin 7y ago
> 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 7y ago
  Also no mention of testing, which from my experience is the last, and hardest barrier to overcome.
hrpnk 7y ago
Quickly reading through, I thought these are GraphQL APIs. Missed opportunity?
- zxienin 7y ago
  Is the implication that wrt adoption curve: GraphQL > REST?
- rpncreator 7y ago
  Nope, OData REST APIs. This is part of a bigger initiative to standardize data across Microsoft, Adobe, and SAP.
  - zxienin 7y ago
    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
    - ntsplnkv2 7y ago
      What exactly is the problem with OData, and what do you recommend instead? This is an area I'm unfamiliar with.
      - zxienin 7y ago
        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.
    - GordonS 7y ago
      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 7y ago
        where is GraphQL v/s OData above?
        GordonS 7y ago
        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?"
      - zxienin 7y ago
        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
unixhero 7y ago
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)
- evadne 7y ago
  To be fair it is more likely that this will be used by existing enterprise customers of SAP who otherwise would consider migrating off.
  - zxienin 7y ago
    I just played with preview APIs. Can’t imagine what edge enterprise customers get over anyone else who’s willing to use it
- zxienin 7y ago
  > 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)
- headcanon 7y ago
  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!
- rpncreator 7y ago
  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 7y ago
jrudolph 7y ago
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 7y ago
  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_
- pritambarhate 7y ago
  Facebook's "Graph" API was REST only when it came out in late 2000s.
throwaway8291 7y ago
Thanks SAP for letting me feel like it's 2010, when everyone fell in love with REST (again).
- mrtimo 7y ago
  Agree, although I feel like I never fell out of love. Honest question, why has excitement waned? Or has it?
  - atonse 7y ago
    I don't see how... what's replaced REST? Maybe other technologies have added to it (like graphql and gRPC?)
  - rukuu001 7y ago
    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 (!)
rvanmil 7y ago
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 7y ago
  > 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)
  - rvanmil 7y ago
    We worked with SAP on a tech talk about Graph, you can watch it over here: https://events.sap.com/teched/en/session/51579 https://events.sap.com/teched/en/session/51579
    - zxienin 7y ago
      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.
  - brodo 7y ago
    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.
_glass 7y ago
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 7y ago
  If I come with “zero SAP knowledge”, I can’t make head or tails of api.sap.com
brodo 7y ago
You know it‘s an SAP website when the term “programming model” is used...
- zxienin 7y ago
  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.
sideproject 7y ago
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?
- zxienin 7y ago
  They’re $30B, with YoY growth in teen double digits. https://www.sap.com/docs/download/investors/2020/sap-factsheet-jan2020-en.pdf https://www.sap.com/docs/download/investors/2020/sap-factshe... Acquisitions gave them some breather.
- majewsky 7y ago
  (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.

92 points by zxienin 7y ago

> 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 7y ago
Also no mention of testing, which from my experience is the last, and hardest barrier to overcome.

hrpnk 7y ago

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

zxienin 7y ago
Is the implication that wrt adoption curve: GraphQL > REST?
rpncreator 7y ago
Nope, OData REST APIs. This is part of a bigger initiative to standardize data across Microsoft, Adobe, and SAP.
- zxienin 7y ago
  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
  - ntsplnkv2 7y ago
    What exactly is the problem with OData, and what do you recommend instead? This is an area I'm unfamiliar with.
    - zxienin 7y ago
      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.
  - GordonS 7y ago
    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 7y ago
      where is GraphQL v/s OData above?
      - GordonS 7y ago
        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?"
    - zxienin 7y ago
      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

unixhero 7y ago

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)

evadne 7y ago
To be fair it is more likely that this will be used by existing enterprise customers of SAP who otherwise would consider migrating off.
- zxienin 7y ago
  I just played with preview APIs. Can’t imagine what edge enterprise customers get over anyone else who’s willing to use it
zxienin 7y ago
> 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)
headcanon 7y ago
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!
rpncreator 7y ago
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 7y ago

jrudolph 7y ago

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 7y ago
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_
pritambarhate 7y ago
Facebook's "Graph" API was REST only when it came out in late 2000s.

throwaway8291 7y ago

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

mrtimo 7y ago
Agree, although I feel like I never fell out of love. Honest question, why has excitement waned? Or has it?
- atonse 7y ago
  I don't see how... what's replaced REST? Maybe other technologies have added to it (like graphql and gRPC?)
- rukuu001 7y ago
  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 (!)

rvanmil 7y ago

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 7y ago
> 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)
- rvanmil 7y ago
  We worked with SAP on a tech talk about Graph, you can watch it over here: https://events.sap.com/teched/en/session/51579 https://events.sap.com/teched/en/session/51579
  - zxienin 7y ago
    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.
- brodo 7y ago
  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.

_glass 7y ago

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 7y ago
If I come with “zero SAP knowledge”, I can’t make head or tails of api.sap.com

brodo 7y ago

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

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

sideproject 7y ago

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?

zxienin 7y ago
They’re $30B, with YoY growth in teen double digits. https://www.sap.com/docs/download/investors/2020/sap-factsheet-jan2020-en.pdf https://www.sap.com/docs/download/investors/2020/sap-factshe... Acquisitions gave them some breather.
majewsky 7y ago
(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.