Skip to Content
Technical Articles
Author's profile photo Franz Reitmayer

How to create an openApi Rest Service from an oData v4 Rest Service with SAP Netweaver ABAP

Motivation and Introduction:

Rest Services are very popular and widely used. But Rest is only a programming paradigm and or an architectural approach as such it doesn’t set up any contract how services are offered, and which format the payload will have finally.

To address this contract there are a lot of service descriptions available meanwhile. You can have a look on how many there are at wikipedia.The ones I came accross the last years very frequently are oData and openApi.

SAP Netweaver comes with great support of oData and as both service descriptions have the same paradigm (Rest) underneath the differences between oData and openApi are not that great as one maybe think about.

Although it’s possible to write Restful Services with ABAP with some framework classes of package SREST you won’t have the service infrastructure of SAP Netweaver Gateway at hand and nonfunctional requirements, like technical error logging and tracing capabilities become crucial with distributed applications.

The OASIS group is maintaining a toolset to generate an openApi description from oData service description document.

Here I’d like to dive into that and see how to build a simple java client from such an openApi description which transparently accesses an oData service. That becomes especially interesting with oData v4, as the payload is ‘plain json’ there. So we’ve a good chance to see that working and leverage the SAP Netweaver Gateway features for openApi services built on the ABAP stack.


In order to do that we will:

  1. Build and deploy a simple v4 oData service
  2. Download and install the toolset to generate the openApi description
  3. Generate the openApi description the oData services description
  4. Download and build the swagger code generator
  5. Generate and install the openapi client from the openApi description
  6. Build and run a simple java program which uses the openapi client generated.



To follow the steps here the following software need to be available/installed:

  • Nodejs
  • Git SCM
  • JDK (here 1.8)
  • Apache Maven
  • SAP Netweaver ABAP 750 SP4


Build and Deploy a simple v4 oData service

Go to Transaction “SEGW” and click “New” button to create a new service


Create the project with the settings shown at the screenshot. Especially choose Project type “OData 4.0 Service” and store as local object.


Expand the node „Data Model“ double click on Entity Types, press the New button on the right pane, enter Entity Type Name „contractType“ and press enter.


  1. Expand the node „contractType“, double click on properties
  2. Press the New button two times.
  3. Set the first properties name to „contractId“, check the checkbox for „Key“, select type kind to „Core Type“ and choose data type „Edm.String“
  4. Set the second properties name to „contractName“, select „type kind to „Core Type“ and choose data type „Edm.String“
  5. Press „Save“


Double click on entity sets, press the new button on the right pane, set entity set name to „contract“ and entity type name to „contractType“, press enter and save


Press Generate


Leave the class names as provided and save as local object in the next dialogs.


  1. Expand the runtime artifacts
  2. Double click on „ZCL_ZTEST_SERVICE_V4_DPC_EXT“
  3. And double click on „ZCL_ZTEST_SERVICE_V4_DPC_EXT“ on the right pane in order to open the class editor.


Add the following method to ZCL_ZTEST_SERVICE_V4_DPC_EXT

    clear ET_CONTRACTS.

    <fs_contract>-CONTRACTID = 1.
    <fs_contract>-CONTRACTNAME = 'Sample contract 1'.

    <fs_contract>-CONTRACTID = 2.
    <fs_contract>-CONTRACTNAME = 'Other contract'.

    <fs_contract>-CONTRACTID = 3.
    <fs_contract>-CONTRACTNAME = 'Test contract '.

    <fs_contract>-CONTRACTID = 4.
    <fs_contract>-CONTRACTNAME = 'Special contract'.

    <fs_contract>-CONTRACTID = 5.
    <fs_contract>-CONTRACTNAME = 'Final contract'.



Redefine the method CONTRACT_READ_LIST as follows:

*    IO_REQUEST  =
*    .

      ET_CONTRACTS = data(lt_contracts)
*    catch /IWBEP/CX_GATEWAY.    "

        ls_proc_info type /IWBEP/IF_V4_REQU_BASIC_CREATE=>TY_S_TODO_LIST.





Goto Transaction /IWBEP/V4_ADMIN


Click on Register Group


Create a service group with the following settings:

Service Group: ZTEST_SERVICE_V4

Description: Odata V4 Sample Services

Package: $TMP


Click on register


Register the service as shown in the screenshot


Finally you should see the Service we’ve created assigned to the service group we’ve created.




Goto Transaction /IWFND/V4_ADMIN

Click on “Publish Service Groups”


Choose System alias „LOCAL“ and press button „Get Service Groups“


Select the Service Group „ZTEST_SERVICE_V4“ (the group we’ve created) and press „Publish Service Groups“


Leave the settings as they are at the „Publish Service Group“ dialog and click „Ok“. Then create a new transport request an save the settings.


You should see a success message.


Go back to /IWBEP/V4_ADMIN find the service group and select the service and press the button „Service Test“


Choose local gateway system


Now you see the Gateway Client with the metadata url. Press „Execute“ to retrieve the services metadata.


Now we’ve the oData Service description document. Right click in the browser and save it as „odata_v4_service_description.xml“


Additionally we can do some testing. Use the url „/sap/opu/odata4/sap/ztest_service_v4/default/sap/ztest_v4_service/0001/contract“ and Execute


So we see the sample data we’ve provided at the mock data method.


For now, we’ve our oData v4 Test Service and the according service description document. So we can go on to translate the oData Service description to a openApi description.


Download and install the toolset to generate the openApi description

Here we will install the toolset from

Open a command window go to a directory of you choice to download/clone the toolset from github:


C:\user\project> git clone
Cloning into 'odata-openapi'...
remote: Enumerating objects: 206, done.
remote: Counting objects: 100% (206/206), done.
remote: Compressing objects: 100% (82/82), done.
remote: Total 4291 (delta 157), reused 164 (delta 120), pack-reused 4085
Receiving objects: 100% (4291/4291), 6.50 MiB | 28.68 MiB/s, done.
Resolving deltas: 100% (3613/3613), done.


As the toolset is cloned to you local repository change into the odata-openapi subfolder an use npm to install the tool locally:

C:\user\project>cd odata-openapi
C:\user\project\odata-openapi> npm install -g
C:\Users\Administrator\AppData\Roaming\npm\odata-openapi3 -> C:\Users\Administrator\AppData\Roaming\npm\node_modules\oda
+ odata-openapi@0.0.0
added 4 packages from 2 contributors in 1.819s
PS C:\user\project\odata-openapi>


With that we have the toolset installed locally and we can continue and create the openApi specification from the oData Service description.


Generate the openApi description the oData services description

Now give the the oData v4 service description document to the tool odata-openapi3 in order to generate the openApi specification from.

C:\user\project\oDataServiceAsOpenApi> odata-openapi3 --host hostname:port .\odata_v4_service_description.xml
Hint: You can get the hostname from Transaction SICF when searching for service „odata4“ and test the service. You see the host and port at the browser then.


The tool created a file „odata_v4_service_description.openapi3.json“

Open this file in an editor copy the content and go to and paste the files content into the editor pane:


Now we see the v4 oData service described by an openApi description


In order to support at least basic authentication with the java client we will generate apply security settings manually at the openApi specification in the swagger editor. I converted to YAML for convenience.


add the following to the components section:

    basicAuth:     # <-- arbitrary name for the security scheme
      type: http
      scheme: basic


and the following security constraint at the end of file so it’s used for the whole service:

  - basicAuth: [basicAuth]  # <-- use the same name here 


After the security configuration it’s also necessary to care about the service-root path at the service description. So change the following default …/service-root:

to the actual path of our oData service:


Save the modified openApi specification in order to use it later to generate the java client.



Download and build the swagger code generator

To generate the java client from the openApi specification we will next download and build the swagger code generator tool. The tool is available at:


Go to a directory of your choice and clone the repository of the swagger code generator:

git clone


Change into the subfolder swagger-codegen and checkout the version 3.0.9

cd swagger-codegen
git checkout tags/v3.0.9


When checkout is finished start building and packaging with maven

mvn clean package -DskipTests


Building swagger-codegen can take a while, at the you should see a message that the Build was successful. Now we’re ready to generate the java client using the code generator.


Generate and install the openapi client from the openApi description

Although that’s not the best practice we’ll use the generator from its project folder (swagger-codegen) and place the files and output folders there to keep things simple.

To create the java client we create a java-config.json file in the swagger-codegen project folder with the following content:

    "modelPackage" : "com.sample.test.model",
    "apiPackage"   : "com.sample.test.api",
    "invokerPackage" : "com.sample.test.client",
    "groupId" : "com.sample.test",
    "artifactId"  : "sample-openapi-client",
    "fullJavaUtil" : true,
    "dateLibrary" : "java8"


We also copy the modified openApi specification into that folder. Here I renamed the file to odata-v4-service-description.openapi.yaml

It’s also necessary to create the empty output folder where the java client is generated to:

mkdir java-sample-client


Then we can call the code generator using the following command:

java -jar .\modules\swagger-codegen-cli\target\swagger-codegen-cli.jar 
generate -i odata-v4-service-description.openapi.yaml 
-l java -c .\java-config.json -o java-sample-client


After that we can see the generated client at the subfolder java-sample-client

To build and install the client to the repository go into this folder and use:

mvn clean install


After that you should see a success message:


As we’ve now created the client and installed it we can now write a program which uses this client to access the oData Rest service running on our abap netweaver.


Build and run a simple java programm which uses the openapi client generated

To create the test program here eclipse with M2Eclipse is used to make usage of maven as simple as possible.

Start eclipse and create a new Project:


Choose Maven project to create a new Maven project.


Check to create a simple project without archetype selection and press next.


Choose your attributes for the artifact and press finish.


Find the pom.xml in the project and add the dependency to the client we generated:

<project xmlns=""
	<name>OpenApi Test Client</name>
	<description>OpenApi Test Client</description>



Hint: The group id “com.sample.test” and the artifact-id “sample-openapi-client” are the ones we’ve set at the java-client.json configuration we used to generate the client


Use Maven->Update Project to work with the latest repository status



Next create a class with Test program:

package test;

import com.sample.test.api.ContractApi;
import com.sample.test.client.ApiClient;
import com.sample.test.client.ApiException;
import com.sample.test.model.CollectionOfContractType;

public class SampleClient {

	public static void main(String[] args) throws ApiException {

		ContractApi api = new ContractApi();
		ApiClient apiClient = new ApiClient();
		CollectionOfContractType list = 


Replace username and password.


Use maven to build the test program.


Choose the goals “clean package” and run the build.


After successful build run the sample client class as Java Application


Now we can see the mock data we’ve provided in our oData Service retrieved from a java program. The access is transparently. The java client uses openApi standards only and doesn’t need to be aware of the oData implementation behind the scenes.



For a very simple example it could be verified to access an oData service through an openApi specification transparently. I’ll try to set up examples for create delete and update also in future. The overall approach applied for service definition is inside-out. Hence you need to take care of naming while setting up the oData model. Although the toolset state is POC at oasis I think it looks quite promising so far.


Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.