The new SAP NetWeaver Gateway Service Builder: Build new OData Services in 3 Quick Steps

With this blog we would like to introduce the new Service Builder in SAP NetWeaver Gateway and its various options for building OData services for SAP NetWeaver and SAP Business Suite data.

Why the need to build OData services?

OData is an evolving standard for RESTful service for exposing business data to any kind of app, whether it runs natively on a smart device or is a flexible, HTML based client. Now that OData also has entered the OASIS standardization process and with a growing number of software vendors endorsing it, it could become the Lingua Franca for bringing business data to any Internet device.

Consuming OData in any kind of app is fairly easy. OData SDKs are available for all relevant client technology and for the most important ones there are already dedicated developer tools, which help any kind of developer to jump-start his app development by consuming available OData services. To get started with OData consumption for SAP NetWeaver Gateway, SDN includes several toolkits for instance for iOS, Android, JSE, PHP or HTML5.

What easily gets overlooked is the fact, that nearly always the right OData service first has to be built before it can be consumed. The number of out-of-the-box OData services is and may remain limited. When you think about it, this quite logical, because OData services by nature are fine granular and mostly tailored to the use case. In that sense they are quite different from comprehensive Enterprise Services in A2A scenarios, where resources like bandwidth, memory and CPU power are less critical. Learnings from app development projects show that up to 50% of development time can go into building the right OData service.

Introducing the Service Builder

Gateway Service Builder (transaction “SEGW”) is available as of Release 2.0 Support Package 4/5 and it greatly accelerates the OData service development process. In many cases you don’t even need to write a single line of ABAP code – unless of course you prefer to do so. It is no longer mandatory that you have deep ABAP OO skills. And the development time for a new OData service can be reduced to hours rather than days.

In Service Builder you need to do 3 main steps to build an OData service:

1. Define or import the data model
2. Implement or generate the runtime logic for the service operations
3. Activate and run the service

The picture below shows the various options that are covered in SEGW:

Step 1: Define the data model

First, when building a mobile or Web app you determine which SAPdata you need. Then you retrieve the data where they usually are: somewhere in the SAP Business Suite. We call this “outside-in approach”. Gateway Service Builder is optimized (but not limited) for this approach.

For the definition of a new data model you will find different options inside SEGW. You can define all elements of the OData service step by step using the various editors within the transaction. If your data model is similar to an existing data structure (like an RFC or BAPI) inside of the DDIC, you can also import that structure. Alternatively,  if you already have an existing OData model definition in  appropriate EDMX format, you can import that from a file. At any time, you can check the consistency of the data model and SEGW will show you existing issues and guide you there. Also, as soon as you have a valid data model you can already activate the service and display  the service document and the metadata in a browser.

Things become very interesting, when you have the right business framework in your SAP Business Suite landscape. If there is any data object available which contains the data that you are looking for, you actually can ask SEGW to generate an OData service from that object. Guided by wizards you simply select the data (entity types and properties) that you need and rename (“redefine”) them to make them look OData style. Redefinition is already supported for BW Easy Query, SPI, GenIL and BOL with thousands of well-defined business objects. With the redefine option you will also get the implementation of the service operations for free and can immediately execute the resulting OData service.

Step 2: Implement the service operations

Having the right data model definition you then need to provide the runtime logic for the different service operations, usually CRUDQ. Also for this Gateway Service Builder offers you several paths. For both the Model Provider Class (MPC) and the Data Provider Class (DPC) Service Builder always generates a base class, that will be overwritten during the next generation step,  and an extension class (name ends with “_EXT”), where you can put your own code extensions. You now can write the ABAP code for the service operations into the stub classes that SEGW generates.

But perhaps already one of the many thousand RFCs or BAPIs in the SAP Business Suite already does the right job. Then you can map the RFC or BOR operations to your data model. In that case SEGW generates the entire ABAP runtime logic.

As soon as you have a valid data model you can already activate the service and check out the service document and the metadata.

Step 3: Publish and run the OData service

Last step in the process is that you register, activate and run the OData services. Would be great to do all this from SEGW, right? This is how SEGW now behaves. Gateway lets you have various different deployment options and the service could be registered on the Suite backend but also in an Gateway hub. Therefore from SEGW you can navigate to the Activate and Maintain Service transaction on the right system and from there to all the other useful functions, like Service Explorer, Gateway Client and Error Log.

The truth is in the code

So far you haven’t seen a single line of code in this blog, right? Our objective with the Service Builder was to provide comprehensive support for building services in a declarative way or by re-using existing business objects in the SAP system. However, we know that there always are limitations to what can be declared and generated. Advanced OData features may need to be implemented manually or certain operations are not available in a redefined business object. Therefore the result of what you do in Service Builder will always end up in those ABAP classes mentioned above, which are based on the powerful OData Channel programming model of SAP NetWeaver Gateway. So, if you want to do some drill-down to understand what is going on during service execution or if, for whatever reason, you want to tweak the code, you can just go ahead and do it. This way you get great development support and still retain the freedom to decide the ideal development approach.

Building OData services has never been easier

Service Builder is a new transaction in available as of SP4 and and further enhanced in SP5 to make life easier for experienced ABAP developers  and SAP experts who are less into writing code. It is now available as part of the software component IW_BEP for SAP NetWeaver Gateway SP5 and can be deployed as an add-on to SAP NetWeaver 7.0 or higher. We will publish additional blogs in the coming weeks an months and drill down into special topics. In any case, try it out and let us know what you like or dislike about this new developer tool.

We can’t wait to hear your views and suggestions.