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

Part 5: Destination and Connectivity Services on BTP

Photo by Christopher Gower on Unsplash

Contents

• Part 1: Setting Up a Destination on Business Technology Platform
• Part 2: Setting Up a CAP Java Development Environment and Generating a New App
• Part 3: Importing an oData Service from an On Premise System
• Part 4: Defining Services and Service Handlers
• Part 5: Destination and Connectivity Services on BTP
• Part 6: Connecting to the On Premise System in Local Development

This is Part 5 of my SAP tutorial on serving data from on-premise systems in CAP Java applications. Up to now, we’ve learned how to register our on-premise system on BTP, how to generate a new application and import an oData service from our on-premise system, and how to create an application service and service handler to proxy our connection to the on-premise system. However, without actually deploying to BTP, we can’t actually utilize our destination on BTP to connect to the on-premise system. This is because we require instances of SAP’s Destination Service and Connectivity Services, which can only be created and bound to an application on BTP. In the following tutorial, we’ll learn how to generate and bind these services to our application.

Step 1

The first step in preparing for deployment to BTP is adding a HANA database configuration. If we don’t, the app won’t run in the cloud — it’s a requirement for CAP apps. Enter the following command to automatically add the configuration:

cds add hana

That’s all for the database!

Step 2

Next we need to generate an MTA.yaml file. This file contains the instructions to BTP about how to construct our application. Generate one automatically with the following command:

cds add mta

If you check the root folder, you’ll find that the following file was generated:

Step 3

Next, we have to make sure we have the trial version of HANA set in our MTA file since we’re deploying to a trial account. If we don’t do this, the deployment will fail. In the MTA file, under “resources”, look for the com.sap.xs.hid-container and set the service to “hanatrial”.

Step 4

Now we need to declare our Destination and Connectivity Services. For reference, the Destination Service exposes the destinations your registered on BTP to your application (you can also register a destination to only one application using one of these if you don’t want that destination exposed to all of your applications bound to a destination service). The Connectivity Service handles authentication, so you don’t have to worry about that at all. For more information about the Destination Service, click here and for more info on the Connectivity Service, click here.

Add the following code to your MTA.yaml file:

- name: sbstutorial-dest
    type: org.cloudfoundry.managed-service
    parameters:
      service: destination
      service-plan: lite
  - name: sbstutorial-conn
    type: org.cloudfoundry.managed-service
    parameters:
      service: connectivity
      service-plan: lite

When you deploy, these three services will be automatically created. If they already exist, they will be left as they are. name can be anything you choose. Under parameters.service you state which service you want. The service plan has to do with how you’ll be billed. “lite” is the free version.

Step 5

Next, we have to add the dependency to our server module so that the app will be bound when it is deployed. Simply declaring the services creates them, but doesn’t associate them with the application.

- name: sbstutorial-dest
- name: sbstutorial-conn

It’s just a list of the resources you defined earlier. Make sure the names match.

Step 6

Next we need to add a little more to our application.yaml. In Part 4 we defined our destination in the default profile. However, when we deploy to the cloud it will run under the “cloud” profile. Therefore, we need to define the cloud profile and add our destination definition there as well.

Add the following code to the bottom of application.yaml:

---
spring:
  config.activate.on-profile: cloud
cds:
  remote.services:
    - name: "ZTEST_PROJECT_SRV"
      destination:
        name: "myonprem"
        suffix: "sap/opu/odata/sap/"
        type: "odata-v2"

The remote service definition should be identical do the one your defined before.

Step 7

Next we generate our deployment package. Run the following command:

mbt build

You’ll see that mta_archives folder was generated, along with an .mtar file inside. We will deploy this file in the next step.

Step 8

Next run login to your Cloud Foundry account with the following command.

cf login

After that, enter your username and password for your BTP account. Note: if you have never logged in to the Cloud Foundry CLI before, you may need to link your BTP account. Please refer to this documentation for information about setting up the CLI.

Step 9

Run the following command:

cf deploy mta_archives/<your mtar file’s name>

This will take some time.

Step 10

Open your BTP account. Find your application and open it.

You should see the following page:

Click the link. You should see data from your on-premise system, as shown below:

Conclusion

If all went well, you can now do side-by-side development. However, there’s a problem. When we develop applications, we need to be able to test them locally. Deploying every change to test would very inefficient, wouldn’t it? In the next part we’ll see how to set up our local environment to connect to the on-premise system.

Contents

• Part 1: Setting Up a Destination on Business Technology Platform
• Part 2: Setting Up a CAP Java Development Environment and Generating a New App
• Part 3: Importing an oData Service from an On Premise System
• Part 4: Defining Services and Service Handlers
• Part 5: Destination and Connectivity Services on BTP
• Part 6: Connecting to the On Premise System in Local Development

Support

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