SAP NetWeaver Gateway – some thoughts on the future
Some time has passed since SAP NetWeaver Gateway was released to our customers and partners in late 2011. Many, many things happened in the meantime. At SAP many areas started to use SAP NetWeaver Gateway as the communication layer for user interaction scenarios. Examples are the Productivity Apps, some HANA Solutions like the SAP Customer Engagement Intelligence, SAP Fraud Management or SAP Liquidity Risk Management, many SAP UI5 based applications, Duet Enterprise for Microsoft SharePoint integration – and still many more.
The last two years the majority of our activities and efforts went into the ABAP-based part of the SAP Solutions where we worked hard to provide the best possible developer experience and feature support required to create own OData services as easy, as fast and as sustainable as possible. I can only mention a few topics as examples like the Service Builder, JSON Support, MDX / Easy Query for BW integration, Gateway Client for supportability… and many more minor or major improvements.
As the ABAP-based side is now relatively well covered, we are now evaluating the next level of OData support for SAP-related business scenarios.
Imagine the following scenario – as a customer you need in a project context a solution to include external participants for project confirmation, status updates or updating the project plan. And of course all the typical constraints apply – your IT department is busy with other projects, the requesting department needs a solution tomorrow and of course you cannot compromise on security.
For such a case the Gateway team is considering the following solution approach:
- The key-users from the involved departments note down the desired process flow and already sketch down UI mockups – which is then directly the input for the new planned OData Model Editor. In this Eclipse-based tool it is now becoming very easy and comfortable to describe how the data model should look like via a graphical user interface.
- The result of the OData modeling is then the starting point to create the required services inside the SAP Business Suite. This results in a mapping of the OData Model from the Eclipse-based modeling tool with e.g. the available RFCs / BAPIs from the SAP Business Suite. The tool to be used is the central Service Builder within the ABAP-based SAP NetWeaver Gateway 2.0, SP6. User Management, authorizations, logging or application logic still remains inside the SAP Business Suite.
- Now via the SAP Cloud Connector the modeled services can directly be connected to Gateway as a Service inside the SAP HANA Cloud, where for example a SAP UI5-based User Interface can be used to involve the external participants. The planned productivity accelerator is then helping with the generation of the HTML5-pages based on the SAP UI5 framework.
- To make it even easier one could also think of providing an Add-On for Microsoft Excel for the external participants – based on the same OData service. So the external users would then have the choice between various channels to enter the requested data. As the underlying OData Service is the same for various user-interface channels the required effort would decrease with every attached technology.
What you could already see in this simple exemplary scenario is the following:
- SAP NetWeaver Gateway consists (simplified) out of two parts: the backend enablement (IW_BEP) and the Gateway Server component. The Gateway Server component is planned to be available also in the SAP HANA Cloud as an alternative deployment option. Still the implementations of the backend
component (IW_BEP) can be connected via the SAP Cloud Connector to Gateway as a Service – no re-writing of the already existing content in the backend is required.
- Productivity accelerators will help with the OData modeling and the generation of source code for several frontend technologies like Microsoft Outlook, Android, iOS, PHP, Java or HTML5 (jQuery or SAP UI5). Idea of the generated source code is to provide a solid and reliable connectivity layer that then allows customer-specific innovations focusing on the user-interface. Of course – similar to the already existing outside consumption tools – it will be easy to switch from supporting OData directly or using the capabilities of the SAP Mobile Platform.
Such a solution approach would allow SAP NetWeaver Gateway to grow without disruption – from SAP Business Suite-based OData enablement to an enabler of SAP HANA Cloud-based scenarios to the better support of frontend-development directly in their native SDKs.
So stay tuned for further updates on this topic.
Hi Martin - Thanks for sharing some insights on where you have, and are planning to take Gateway. I still believe the product's power is somewhat under rated, and not as commonly accepted as it should be. I also believe the direction you seem to be taking the product, from my POV, sounds promising.
I like the concept of "Modeling" the services in Eclipse though a visual editor (isn't this what the edmx import did previously?).
Since I am more on the consumption side of the process for OData services (developing custom apps), it would be very helpful to have a set of predefined services either a.) be downloadable or b.) included with the core product - similar to how BAPI's/RFC come with the core system, I would expect certain common predefined services (Sales, Customers, Vendors, Production, Service, etc.) already available.
As a partner, I am finding it a challenge to have get my GW content certified (both from a process side and cost), for exposing a single standard BAPI, simply exposed as a OData service. I believe that you will find a considerably larger 3rd party development community will come to the table when the "data is accessible".
Thanks again, Paul
thanks for your feedback!
Yes, the content question is a tricky one - and a frequently asked one as well. We are positioning GW as a tool to support scenario specific solutions - so typically all the GW-based solutions from SAP have no reuse, every App / Solution has optimized own GW services. One exception to this rule is the workflow where we are providing standard OData Services. In my opinion the typical objects from SAP are so rich (and customers also tend to enhance them) - so in order to cover everything we would end up with really huge and complex GW service. Looking e.g. at the Material master you have many 100eds of fields, attached documents, classification, stock overview, plant specific data, .... And reading all this data from dozends of tables just to support a 3-field App? Maybe I chose an extreme example and there are easier ones...
But the request is a really valid one and we spent a lot of effort to make the service creation as easy / automated / coding-free /... as possible. So in the BW space we are supporting Easy Query and MDX. Here you will get the GW Services without any manual ABAP coding. We also provide generators for SPI, BOL / GenIL and more are on the roadmap. Based on these generators we are currently evaluating to have the GW services for a new UI5 application built at SAP without manual coding at all - just via the generators inside Service Builder. So those applications that have good frameworks underlying will make it much easier for not-ABAP-centric partners (and us...) to generate the required services on-demand.
In addition I also see teaming up of various partner types for customer projects - the more ABAP-centric ones with the consumption centric ones.
As partners are crucial for the success of Gateway we are also active here - Mustafa just posted some days ago more details on our offerings here in SCN.
Again - thanks for your feedback and looking forward for more 🙂
I hope you are doing well.
I will try to answer your following comment: "... As a partner, I am finding it a challenge to have get my GW content certified (both from a process side and cost), for exposing a single standard BAPI, simply exposed as a OData service. I believe that you will find a considerably larger 3rd party development community will come to the table when the "data is accessible"."
I believe your point is that, especially for our partners who are purely focusing on building end-user applications (i.e. apps to consume existing SAP functionality), it is preferable, if there are available OData services provided by SAP (and others). To me, this is a fair point and hard to disagree. However, in SAP NetWeaver Gateway Solution/Product team, our current focus is to provide the technology that makes it easy to build and consume such (OData/REST) services. Therefore, currently we are not planning to deliver OData Services from SAP NetWeaver Gateway Solution Management.
Furthermore, as SAP NetWeaver Gateway is being adopted both inside SAP (by LoB and Industry Solutions) and outside (i.e. customers and partners), more and more such services will be available. Just last week, I talked with a partner who has built a number of such services and seeking a way to offer them to other partners and customers. I believe this will soon be a trend and we are strategizing on how to facilitate and manage it.
Regarding your point on certification; please note that it is not required for a partner to have their OData services certified. But in order to receive the associated, marketing benefits and go-to-market benefits, many of our partners choose to have their solutions or Odata services certified. Similarly, as solution management we also prefer our partners to have their solutions certified, as it helps us identify and recognize such solutions as well as track the adoption of our technology. Therefore, we are running campaigns to sponsor such efforts. I really hope that you also consider participating in our 2013 Partner-built Solutions Drive.
Hope to see you next week at SAPPHIRENOW Orlando.
Hello Mustafa and Martin - thanks for taking the time to respond and give some nice feedback to my comment.
@Martin - I do agree with you that there are hundreds of fields and this would be unreasonable to provision and "cater" to everyone's unique requirement. You have a very relevant example, but I still feel certain "base" data services should be available for either download/import and not necessarily be a part of the core product, maybe an offering? (And it sounds like Mustafa suggested some of this from a partner). I do agree that sometimes I overlook the fact everyone's needs are different, however, based on other "API" type of open platforms which have seen huge developer adoption, e.g. Facebook, Netflix, iOS, etc. they have all provided "data access" more so than data provisioning tools. A great example is the Gateway Demo system - how many examples, POC's and demo's are based on "Flight data" or "Sales Orders"? There are many. All too often innovation is spured when the data is there, but form/function/location/modification/simplicity is necessary. Most importantly, I believe that this is not the responsibility of the Gateway Team or product, but I believe this product is really the enabler and has the potential to turn the SAP Ecosystem into a huge opportunity for the developer community at large and ultimately the customers.
@Mustafa - I will consider the Solutions Drive, I did the mobile drive last year which was good success. Like many, I have great ideas, but never enough time! I look forward to seeing you next week in Orlando.