SAP Tutorial: Serving Data from an On Premise System in a CAP Java Application (Part 3)

Part 3: Importing an oData Service from an On Premise System

6 min readApr 4, 2021

Welcome to Part 3 of Serving Data from an On-Premise System in a CAP Java Application. In Part 1 we learned how to define the connection to your on-premise system using a destination on Business Technology Platform (BTP). In Part 2, we set up our local CAP Java development environment and generated a new application.

Now, in Part 3 we will import an oData definition from our on-premise system. The CAP framework will use this definition to automatically generate requested to the backend based on its own CQN query notation — in other words, from CAP you can communication with your own premise system exactly as you would with any other CAP service. Convenient, right? Let’s get started.

Step 1

Login to GUI. Be sure to use the same username and password you used when you defined your service. This ensures that your destination will have the correct access rights for the oData service that you import

Step 2

Open transaction SEGW (SAP Gateway) and click the open icon on the menu bar.

Step 3

Select any oData service. For this tutorial I’m using a simple test service that I made myself, but you can use any service you want. Just make sure it has some data attached so you can verify that your application is running as expected. If you’re just practicing now and don’t know which service to use, I recommend trying API_SALES_ORDER_SRV.

Step 4

After you selected your service, open the services dropdown and navigate to Service Maintenance. There you can open the context menu of the system displayed there and navigate to SAP Gateway Client, as shown below.

Step 5

Next we’re going to retrieve the service definition of our oData service. From Gateway Client, click Add URI Option on the header bar, and from the popup select $metadata, then finally click the checkbox icon as shown below.

Step 6

Click Execute on the header bar to retrieve the definition. You’ll see it in the bottom-right viewport as shown below.

Step 7

Next, we need to extract this definition into a file so we can import it into our CAP application. The easiest way to do this is to open this response in the browser, so click Response in Browser as shown below.

Step 8

Open the response in the browser of your choice and then save it to your CAP project’s root folder. Make sure to name your this file the same as the API endpoint for your oData service. If the names don’t match exactly, it won’t work.

Step 9

Next, import the file to the project using cds import <your_file_name>.xml in the command line. You should see the following output:

This command will generate two files in the filepath “serv/external” (see below). The CDS SDK converted our service definition into the format that it uses natively. It also deleted the original file, so if it’s some thing that you want to keep around, take note.

Step 10

Now that we have our service definition, we have to tell our CAP application to generate a service from it. To do so, create a new CDS file in the “srv” folder. Write the following code:

using {<your_service_name>} from './external/<filename>.csn';

Note that <your_service_name> is the name for your service as defined in the .csn file that was generated when you imported your service, which should be the same as the service defined in your on-premise system. If you need to verify, open the .csn file and locate the service name.

If you’re new to CDS and need an explanation of what this code does, check out the documentation.

Step 11

Now it’s time to test our application so far and make sure it’s working as we planned. Run the following commands:

mvn clean install
mvn spring-boot:run

The first command will install all of your dependencies. The second command will compile your application and launch a server on port http://localhost:8080. If you open it in your browser, you should see a page like the one below:

CAP automatically generates this page as a convenient way to test your app’s Application Services. Here you should see the root path for your service, a link generating the service’s metadata, and a list of all the entities defined by this service. Clicking one of these entity links will generate the following response:

Naturally, it’s an empty array since we haven’t connected to our on-premise system yet — there’s no data to display.

Conclusion

This brings us to the end of Part 3 of Serving Data from an On Premise System in a CAP Java Application. In this part we learned how to import an oData service from our on-premise system. In Part 4 we will learn how to create the services and service handler necessary to link our application to the on-premise system.

Support

Did you like this blog? Want to make sure I can keep creating them? Then consider subscribing on Patreon!