Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to leverage this with Gateway service developed using SEGW #41

Open
NareshSAP opened this issue Dec 15, 2018 · 13 comments
Open

How to leverage this with Gateway service developed using SEGW #41

NareshSAP opened this issue Dec 15, 2018 · 13 comments

Comments

@NareshSAP
Copy link

Hello Team,
I am very delightful to know about this open source project and it is quite useful for ABAPers who are working on SAP REST services as a provider to outside world. Thanks and much appreciated.
However, I am wondering is there any way to leverage to REST services developed using SEGW transaction in SAP to run and test the service directly through Swaggger UI by IIB/.Net (non-SAP) developers in order to create client interface out of it.
I would appreciate if someone point me to the discussion if it was already closed to verify once.
Thanks, Naresh

@larshp
Copy link
Owner

larshp commented Dec 16, 2018

no, its 2 different approaches/technologies

@NareshSAP
Copy link
Author

Thanks larshP for your quick reply on this.
So, it means that SEGW based REST services can't leverage this project in terms of converting the meta data of the service into Swagger Spec.
Any suggestions/alternative ways of doing this in SAP (NetWeaver 7.5) please?

@larshp
Copy link
Owner

larshp commented Dec 16, 2018

try some of these:
https://github.com/shadhini/OData-OpenAPI-Converter
https://github.com/elasticio/odata2openapi

however I recommend sticking to your technology choice either to odata or swagger, guess there will be some issues if trying to combine it

@thesourav123
Copy link

You can use SEGW's generic Rest Enablement for the ICF Handler, but cannot utilize the advantages of the Object Relational Mapping(ORM) or the toolkit provided by OData out of the box.

@NareshSAP
Copy link
Author

Thanks for your comments!
There is a requirement to provide a SAP ODATA service to a non-SAP consumer and the expectation is to provide swagger spec along with it since it is an industry standard across technologies to have it for REST services; there no is WSDL file to generate for SAP based REST services like we do get for SOAP based ones (also, service document and meta data files are no use to consumers of REST service). Hence, end up finding alternative ways to generate one or prepare it manually by writing a program in YAML. I hope you it clarifies the actual reason of this issue.
@larshp: The links given by you seem promising but not quite sure in terms of their usage.

@sdfraga
Copy link

sdfraga commented Feb 19, 2020

Hello @NareshSAP , @thesourav123 and @larshp ,

I'm currently facing the exact same requisite in the context of API Management.
We decided to use Apigee to centralize all group API's. A lot of teams are involved in this project, where only SAP Team publishes OData, where others publish "true" RESTful services.

How did you manage your request @NareshSAP ?

What would be the way to provide true RESTful services that expose business data from SAP Backends?

  • Full blown ABAP development has explained by @larshp ?
  • Go through CAP and use Java/Node.js to build a RESTful service ?
  • Use Cloud Platform Integration to and use REST adapter to expose the service ?
  • Build an OData service with SAP GW and there use some "magic" to convert it to true RESTful?

This issue is a little bit older but I hope I can get some info from you guys that already felt this challenge.

It's a brand new world and I'm trying hard to understand SAP Positioning on this matter, where OData is the chosen protocol, but in API Management context, the majority of developers speak native REST..

Thank you!

@larshp
Copy link
Owner

larshp commented Feb 19, 2020

ABAP-Swagger is an OpenAPI based tool, not related to OData/Gateway

SAP odata is great if you are building a SAP UI

however, for restful services I personally prefer more control/flexibility than odata, it exposes a lot of stuff that is not really there/not implemented

@larshp
Copy link
Owner

larshp commented Feb 19, 2020

technology-wise, I typically recommend customers to have as few steps/platforms as possible.

CAP is nice, but for calling the ABAP backend its just an extra step

CPI is nice, but for calling the ABAP backend its just an extra step, especially if you need to pass everything through apigee anyhow

odata is not supported by all API platforms(I dont know about apigee), so its just an extra intermediate format

@sdfraga
Copy link

sdfraga commented Feb 19, 2020

Thanks @larshp ,
I agree with your suggestion but I'm having management pressure that we should be able to re-use what already exists instead of re-inventing the wheel..

Another question is for mashup scenarios.
What would you suggest if I need to expose a service that combines data from ERP (Products) and CRM (Client data)?

Thanksssss

@larshp
Copy link
Owner

larshp commented Feb 19, 2020

pressure management to choose the SAP equivalent solution of apigee, then you have one vendor of the ecosystem to ask. Mixing and matching software gives work

ERP and CRM: depends on the long term plan, I dont remember the SAP roadmap for CRM. But build it in one place that corresponds to your long term strategy

@sdfraga
Copy link

sdfraga commented Feb 19, 2020

Understood, even if SAP API Management tool was picked, it would not solve the issue of RESTish(OData) vs RESTful.
Anyway, thanks A LOT for your insights @larshp !
You're one of the true SAP Heroes!!

@larshp
Copy link
Owner

larshp commented Feb 19, 2020

SAP API mgt, would solve as to which direction management points, if they ask you, point to SAP as the vendor

@sdfraga
Copy link

sdfraga commented Feb 19, 2020

yes but the idea behind APImgt is that any stack/vendor should be able to publish their services in one common single point so that external devs can consume public data agnostically

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants