SAP private linky swear with Azure – how do I debug and test with live data via SAP Private Link Service?

[Martin-Pankraz]

This post is part 4 of a series sharing service implementation experience and possible applications of SAP Private Link Service on Azure.

Find the table of contents and my curated news regarding series updates here.

Looking for part 5?

Find the associated GitHub repos here.

Dear community,

Continuing with the implementation journey of SAP Private Link we will have a closer look at debugging and testing today.

Connectivity and integration capabilities for deployed apps are great. But what about the developer who needs to draft the app? There are few things more frustrating and time consuming than to wait for a build and “cf push” to finally notice that you forgot renaming your BTP destination. And don’t get me started on log printouts, because of missing debug capabilities. If you are not Chuck Norris, you are looking to your IDE to provide that.

source: 9gag.com

Next important topic is test data. It is often crucial for efficient prototyping. Mock OData services can be a feasible workaround, but often disregard the “actual” state of your data objects on the backend. Sometimes you are in for a surprise once you move away from the mock data 😉.

So, best case scenario would be consuming data from your target system directly. Unfortunately, SAP Private Link requires an app binding to allow traffic flow. That locks our IDE and dev environment out. Or does it?

Fig.1 Pinkie rocking debug with live SAP data

Luckily, SAP and CloudFoundry (CF) already provide means to enable remote debug by accessing deployed apps on BTP. We can use ssh tunnelling to connect for our calls from our IDE (Integrated Development Environment) of choice. We tested with SAP Business Application Studio (BAS) and Visual Studio Code (VSC).

For local development with VSC you need to install CloudFoundry CLI and ensure that you are all set to run your programming language specifc runtime. For my example case that means maven and Java.

Let’s have a look at the moving parts

This challenge is not unique to private link and discussed in SAP tutorials and other blog posts at length already. I will focus on guidance to get you started in the context of private link, so you can connect the dots more easily.

First, we need one cf app deployed, that is bound the to SAP Private Link Service. That could be your initial project scaffolding for instance.

We continue with the ssh setup for my Java app "az-private-linky", that is bound to the SAP Private Link Service named "az-private-link".

//check enablement

cf space-ssh-allowed <space name>

cf allow-space-ssh <space name>

//enable on app

cf enable-ssh az-private-linky

//restage to reflect activation

cf restage az-private-linky

//…sign in into your space, where the cf app runs, that is bound to your private link

//in one terminal open tunnel on desired local port (e.g. 8443), private link IP address and SAP backend port

cf login -a https://api.cf.eu20.hana.ondemand.com

cf ssh az-private-linky -L 8443:your-pls-hostname:44321

Be aware that this ssh session can time out. If you encounter connectivity issues during your debugging, check the tunnel too.

Fig.2 Screenshot from VSC with ssh tunnel to cf app

Remember, the target service config resides in our Destination on CF. For local calls it is easiest to create an environment variable within the scope of the IDE.

On SAP BAS you can run:

export destinations='[{"type": "HTTP","name": "s4basic","url": "https://localhost:8443","proxyType": "Internet","authentication": "BasicAuthentication","user": "<your user>","password": "<your pass>","forwardAuthToken": "true","TrustAll":"true"}]'

On VSC on Windows you can run:

$env:destinations = '[{"name": "s4basic","url": "https://localhost:8443","proxyType": "Internet","authentication": "BasicAuthentication","user": "<your user>","password": "<your pass>","forwardAuthToken": "true","TrustAll":"true"}]'

With that we are ready to startup the local web server in debug mode on a different terminal than the one where you opened the ssh tunnel before.

mvn tomee:debug -pl application

You see the process to start listening on port 5005 (maintained on run config: project root >> .vsc folder >> launch.json) and attempting to connect to port 8080.

Fig.3 Screenshot from VSC after mvn:debug command

The connect attempt is our trigger to attach the remote debugging process. If the entry is missing on your config, you can add the following snippet to your launch.json (under .vsc folder)

{

   "type": "java",

   "name": "Attach to Remote Program",

   "request": "attach",

   "hostName": "localhost",

   "port": 5005

}

Fig.4 Screenshot from VSC after attach to remote process was fired and break point got hit (top left play button)

As a result, you will see the process picking up the debug process. Folks, your break points are armed now 😊

From your local PC you can simply navigate to https://localhost:8080 to access your app. On BAS you need to resolve to the IDE path. I usually do that by scrolling up till I find the log print-out for the target URL. It reads localhost:8080 too, but points to an SAP generated URL.

In my example I am hitting the route “BTPAzureProxyServlet” and inspect the response from my S4 on Azure.

Fig.5 Trigger breakpoint

If everything went to plan, you are not only debugging but also retrieving OData live from your SAP backend via the private link. Check fig.4 code line 75 and the variables on the top left.

The last mile with the cf approuter

For a fully fledged debug setup we would need to add authorization to the mix. In CF that is usually done by adding an approuter. On the flip-side that increases the complexity of the debug process further, because we need to spin up an additional app and ensure proper local routing.

Would you even go that far?

Above debug example relies on an “unguarded” cf app, but gets you up and debugging reasonably quick.

@Community: Do you bypass the approuter during development time for simplicity if your test does not involve any authorization specifics?

Final Words

Phew, dodged that metaphorical bullet of debugging by log printouts by an inch. Today, you saw how you can get your private-link-enabled BTP app development with online debugging and live backend data to the next level. This is a standard process defined by CloudFoundry and SAP and therefore can be applied to your private-link-enabled development out-of-the-box. Not too bad, right?

Any further inputs from you @Developers?

In part five of this series, we will look at principal propagation. Any other topic you would like to be discussed in relation to the private link service? Just reach out via GitHub or on the comments section below.

Find the related GitHub repos here. Find your way back to the table of contents of the series here.

@Kudos to Matthias, Josua and gowrisankar.m2 for introducing me to cf ssh

 

As always feel free to ask lots of follow-up questions.

 

Best Regards

Martin