There is a Gateway for that …
For decades, SAP customers and the partners in the ecosystem have been building solutions that access SAP data. For a long time, such access was only possible via a number of proprietary technologies offered by SAP such as RFC, BAPI, IDocs and even Enterprise Services.
With the recent popularity of REST (Representational state transfer) against SOA (Service-oriented architecture) which is typically based on the SOAP (Simple Object Access Protocol), SAP is embracing OData (Open Data Protocol) as the protocol to provide standards based access to SAP data.
Concept Gateway
Concept Gateway is the vision for a harmonized integration layer by which all SAP solutions can be accessed via OData. To do that individual solutions provide design-time tools for exposing their data as OData services based on their native platforms. The concept also suggest that based on OData services coming from various SAP solutions, a consistent user-experience can be provided by leveraging standards like HTML5 and CSS3 – e.g. SAP UI5.
Following diagram depicts “Concept Gateway” inside SAP’s ever increasing solutions portfolio.
SAP NetWeaver Gateway
Built on the traditional ABAP technology, SAP NetWeaver Gateway is a technology solution that provides design-time and runtime features to expose SAP Business Suite data as OData services (i.e. RESTful APIs).
SAP NetWeaver Gateway became generally available in October 2011 and by the end of 2013, in about two years it was adopted by more than 7000 customers, productively.
With SAP NetWeaver Gateway, customers can build OData services based on existing SAP APIs such as RFC, BAPI, BOR, BOL, MDX, SAP HANA and others. Furthermore, SAP NetWeaver Gateway comes with design-time tools to allow modeling of OData services as well as provisioning of such services from scratch by custom coding, in ABAP.
While SAP NetWeaver Gateway is great for exposing SAP data from an ABAP based SAP system, it does not provide tools for exposing data from non-ABAP based SAP systems.
Integration Gateway
Over the last 40 years, SAP’s solutions portfolio has grown from traditional ERP to cover 10+ LoBs, 20+ industries in 100+ countries (i.e. localizations) through technology innovations and acquisitions. As a result, a harmonized design-time (as well as user experience) and a harmonized Integration Layer across the portfolio have become essential to bring the benefits that SAP NetWeaver Gateway offers SAP Business Suite customers.
Integration Gateway is a technology component that provides design-time tools and the associated run-time for modeling, composing and provisioning OData services based on one or more APIs from various SAP and non-SAP data sources. Among the data sources supported today are, SOAP (Simple Object Access Protocol), JPA (Java Persistence API) and JDBC (Java Database Connectivity) to access non-SAP data sources as well as OData Channel (ODC) for accessing OData services provisioned via SAP NetWeaver Gateway.
Integration Gateway has been first delivered inside SAP Mobile Platform 3.0 as an on-premise solution. In this version, Integration Gateway has been fully implemented in Java and it runs on SAP Lean Java Server, a lightweight OSGi (Open Services Gateway) based application server.
In the future, Integration Gateway will be included in other on-premise or cloud based SAP solutions in their native platforms. However, at this time there are no plans to deliver it as a standalone solution.
Integration Gateway and SAP NetWeaver Gateway – Two sides of a coin
SAP NetWeaver Gateway focuses on exposing SAP data from an ABAP based SAP solution as OData services. Hence, it has design-time tools that natively support creating OData services, based on existing SAP APIs (RFCs, BAPIs, etc.) as well as from scratch.
Integration Gateway however, takes SAP one step closer to realizing the vision of “Concept Gateway” by bringing OData provisioning beyond SAP Business Suite by supporting several integration protocols and technologies that are well accepted in the industry. Furthermore, when it comes to accessing an SAP Business Suite backed (ABAP based), it relies on the OData services provisioned by SAP NetWeaver Gateway as it supports the ODC (OData Channel) protocol.
Answers to frequently asked questions
Q: I need to build an app that will access both SAP and non-SAP data (legacy, solutions from other vendors). Which Gateway do I need?
A: You will need both SAP NetWeaver Gateway and Integration Gateway.
Q: I am building a mobile app and I don’t need to access SAP backend. Do I need SAP NetWeaver Gateway?
A: No. If you don’t need to access SAP Business Suite backend, you may only need Integration Gateway.
Q: Where can I download Integration Gateway?
A: Integration Gateway is not available as a standalone solution. Currently, it only comes with SAP Mobile Platform 3.0.
Q: Where can I download SAP NetWeaver Gateway?
A: SAP NetWeaver Gateway is included in SAP NetWeaver 7.40. For earlier versions (starting from SAP NetWeaver 7.0) you will need to download it as an Add-on from SAP Service Marketplace – http://service.sap.com/swdc (SAP Service Marketplace username password required).
Best regards,
Mustafa.
Thanks Mustafa .. Very informative 🙂
Thanks Mustafa, I have few clarification.
SAP and non-SAP data sources are being exposed using Integration Gateway at the API level, in the form of oData endpoints -- I call this, data consumption model, where various clients consuming the data as long as they can talk oData.
I specifically said API level because I believe SMP 30 requires access to DB for storing and retrieving Master look up data, Mobile App related data and other data that SMP 30 needs to keep the SMP30 run-time environment up and running -- for this type of access SMP 30 should not require Integration Gateway -- this would be an internal direct JDBC access right?
The way I see Integration Gateway is about exposing a harmonized data consumption model in the form of oData.
Currently IGW only exposes oData endpoints (correct me) to consume the data, therefore if I want to model a process workflow in SMP 30 e.g. designing a service/process that would potentially consume an event placed in a message queue (message broker), based on the event type, call an external service to notify and then update the local database (do we need oData or a direct JDBC access would suffice -- since this is an internal working of the service) and possibly again notify an external service by placing either placing a message on the queue or calling a SOAP/REST endpoint at the completion of the workflow -- This is just an example to help describe a process integration to understand an integration scenario using SMP 30 tools. How can we accomplish this use case?
Sorry about the too much verbiage -- I like to get a clear understanding, hoping to get a reply.
Thanks for your article.
Amir Zaidi
Hi Amir,
Thank you for reading my blog and for your comments and question.
In fact, you are right that Integration Gateway (inside SMP 3.0) does provide API level access to data residing potentially in a number of different backends.
Please note that Integration Gateway is an integral part of SMP 3.0. Thus the capabilities it offers are native to SMP 3.0 including the JDBC access.
In its current version, Integration Gateway in SMP 3.0 doesn't support workflow scenarios. Hopefully, we will add such capability in the future.
Best regards,
Mustafa.
THanks Mustafa, So for workflow scenarios which product do we position for SMP 30? is it SAP PI?
BR
Amir
Hi Amir,
While I am not an expert of PI, I believe it should support your scenario.
Best regards,
Mustafa.
Mustafa, but this would required having SAP Netweaver Server -- Seems like currently SMP 30 lacks in the implementation of Workflow scenarios -- I believe this is going to be a problem in on-premise deployments -- hopefully Mobile on HANA would solve this problem by exposing Integration as a service which would also cater to Workflow scenarios.
Thanks
amir
Hi Mustafa,
your Blog gives a great and useful overview about these topics!
Thanks,
Carlos
Thanks Carlos.
Thanks Mustafa for the Blog and for the today's webinar.
I have a question.
One of the Deployment options of SAP Netweaver Gateway, is Central HUB Deployment. In this option all I do in HUB is registration of the service. If I have SMP, I do not see the need to have this HUB server itself. What do you say?
May be the 'Multi Origin Composition' is the only feature I might miss.
regards
Krishna
Hi Krishna,
I believe, in general, you are right. But again, you might want to verify this based on a specific usage scenario.
Regards,
Mustafa.
Then there is another Gateway, for cloud. 🙂
HCI oData provisioning. May be just for provisioning, not a full fledged Gateway though.
Hi Krishna,
That is right. In fact, we will further improve the OData capabilities in HCI in the coming months.
Regards,
Mustafa.
very well exposed and described! Thanks
Emiliano
Hi Mustafa,
Is it safe to say that SMP3.0 comes with Integration Gateway (to consume non-SAP data) but SAP Gateway (formerly known as SAP NetWeaver Gateway) does not come with SMP3.0?
If correct, you will always need to have the SAP Gateway installed separately, with associated license costs for that component to be added?
Thanks for your help,
Eka
Hi Eka,
you are correct:
Integration Gateway is a part of SMP 3.0 and enables you to consume SAP (via SAP Gateway) and non-SAP (SOAP, JPA, JDBC) data sources.
SAP Gateway is a separate product and does not come with SMP 3.0. The deployment options for SAP Gateway are explained in Andre's blog: SAP Gateway deployment options in a nutshell
Regarding the licenses I suggest you to get in touch with your account manager.
Kind regards
Bjoern
Hi,
Thanks for the info. Have one query here. Is it possible to consume SAP data without using Netweaver Gateway? Is it suggested to convert RFC/BAPI from SAP to SOAP web services and consume it in Integration Gateway?
Thanks
Vishnupriya
Hi Vishnupriya,
yes, it would be possible to convert an RFC/BAPI into a SOAP service and consume that in Integration Gateway.
However, I would rather recommend that you expose your RFC as an OData service using the SAP Gateway. My colleague Volker has published an excellent step-by-step guide to do so.
SAP Gateway services can easily be used in the Integration Gateway and can be combined with data from other data sources.
Kind regards
Björn
Thanks Bjorn.
Could you please let me know the downsides/drawbacks in converting the RFC/BAPI to SOAP services and consuming it in Integration Gateway?? Rather what are the advantages of using Netweaver Gateway??I am just thinking from the license cost perspective involved with Netweaver Gateway..
Thanks
Vishnupriya
Hi Vishnu,
I think the handling of an OData service is much leaner compared to a SOAP service. Also, there are some restrictions when using SOAP via Integration Gateway, that don't exist for the SAP Gateway (ODC) Data Source.
Regarding the licensing, my colleague Martin Bachmann made the following statement:
I hope this helps.
Kind regards
Björn
Thanks Bjorn!