Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
laszlo_kajan2
Active Participant

tl;dr


Update of 17-June-2020:

With a CAPM app, as long as your destination is named only with characters matching [a-z0-9-], standard destinations (see Liat's comment below) will work using the App Studio proxy at 127.0.0.1:8887. Use the following "destinations" definition in your .env1 file:



destinations=[{"name":"<name-of-destination>","proxyHost":"http://127.0.0.1","proxyPort":"8887","url":"http://<name-of-destination>.dest"}]

Note: this solution will not use, and will work without, the destination and connectivity service your deployed app is bound to.


The problem ("dial tcp: lookup dest_name.dest on 100.64.0.10:53: no such host") seems to be a lowercase transliteration of the destination name - e.g. from 'MY_DEST' to 'my_dest' - before the HTTP request is constructed, which causes the proxy to fail to find a matching destination.







At the moment (02-June-2020), when running a CAPM (Node.js) application in a 'SAP Cloud Business Application' dev space, it seems impossible to reach, from the Business Application Studio (BAS), an on-premise OData service that is exposed to the SCP via the cloud connector. The solution offered here is to use 'cf ssh' to tunnel traffic that is destined to the connectivity proxy.

Do this to reach an on-premise OData service via the cloud connector, from the Business Application Studio:

  1. Copy your deployed service app's 'VCAP_SERVICES' to 'default-env.json' at the root of your CAPM application.

    • There should be sections for 'connectivity', 'destination' and 'xsuaa' in 'VCAP_SERVICES'.



  2. Set, in the top 'default-env.json' file, 'connectivity'.'credentials':

    1. "onpremise_proxy_host": "127.0.0.1".



  3. Authorize ssh in your CF space, authorize ssh to '-srv' app, restart '-srv' app:

    1. In BAS terminal:
      cf allow-space-ssh <spacename> && cf enable-ssh <app-srv> && cf restart <app-srv>



  4. Open SSH tunnel to 'connectivityproxy.internal.cf.eu10.hana.ondemand.com':

    1. In BAS terminal:
      cf ssh <app-srv> -N -T -L 20003:connectivityproxy.internal.cf.eu10.hana.ondemand.com:20003



  5. Launch application router app '-app', and service app '-srv':

    1. In BAS terminal:

      (cd app && node node_modules/@sap/approuter/approuter.js)


    2. In another BAS terminal:
      cds watch




Goal


As presented in 'Building Applications with SAP Cloud Application Programming Model' Week 4 Unit 2: 'Connecting to R..., the CAPM makes it easy to connect to an on-premise OData service. While this works readily when the multi-target application (MTA) is deployed, when the app is run in the Business Application Studio (BAS) during development, with bindings (i.e. 'VCAP_SERVICES') copied from the deployed service app, the OData service is not reached (as of 02-June-2020).

Solution


The reason for this is that the connectivity proxy host 'connectivityproxy.internal.cf.eu10.hana.ondemand.com' used by the deployed application (configured in the 'connectivity' section of VCAP_SERVICES), is not reachable from the Business Application Studio.

A deployed service app - e.g. 'capire-bookshop-srv' - reaches the back-end OData like this:


In order to make the connectivity proxy reachable from the BAS during development, an ssh tunnel can be used, along with a modification of the 'onpremise_proxy_host' in the environment defined in 'default-env.json'. That leads to this:


Perform the following steps:

  1. Make sure you have copied your deployed service app's 'VCAP_SERVICES' environment to 'default-env.json' at the root of your CAPM application.

    • There should be sections for 'connectivity', 'destination' and 'xsuaa' in 'VCAP_SERVICES'.



  2. Set, in the top 'default-env.json' file, 'connectivity'.'credentials':

    1. "onpremise_proxy_host": "127.0.0.1".



  3. Authorize ssh:

    1. In your CF space:

      1. cf allow-space-ssh <spacename>



    2. For service app:

      1. cf enable-ssh <app-srv>



    3. Restart service app with ssh enabled:

      1. cf restart <app-srv>





  4. Open SSH tunnel to 'connectivityproxy.internal.cf.eu10.hana.ondemand.com':

    1. In BAS terminal:
      cf ssh <app-srv> -N -T -L 20003:connectivityproxy.internal.cf.eu10.hana.ondemand.com:20003



  5. Launch application router app '-app', and service app '-srv':

    1. In BAS terminal:

      (cd app && node node_modules/@sap/approuter/approuter.js)


    2. In another BAS terminal:
      cds watch




The following launch configuration can be used to debug the service application in the BAS:
{
"name": "Run bookshop",
"request": "launch",
"type": "node",
"runtimeExecutable": "npx",
"runtimeArgs": ["--node-arg"],
"args": ["--", "cds", "run"],
"skipFiles": ["<node_internals>/**"]
}

The service application now reaches the on-premise OData service.

Summary


In this blog I showed you how to overcome the difficulty of reaching an on-premise OData service from the Business Application Studio. The solution is to tunnel this OData traffic through an ssh tunnel to the internal connectivity proxy.

Author and motivation


Laszlo Kajan is a full stack Fiori/SAPUI5 expert, present on the SAPUI5 field since 2015, diversifying into the area of SCP development.

The motivation behind this blog post is to provide a solution for developing with on-premise OData services in the Business Application Studio.

Further reading


10 Comments
laszlo_kajan2
Active Participant

The ssh tunnel (‘cf ssh’) in the BAS terminal must be left running as long as the tunnel is needed, even though the command appears to hang.

liat_b
Advisor
Advisor
Hi Laszlo,

Thanks for taking the time to contribute to our community ? however it is much more simple to reach on-premise OData service from Business Application Studio.

Since CF connectivity service is not publicly visible outside of CF, any service outside CF cannot access it directly, and this is also true for App Studio. Therefore, we had to solve this issue to ensure simplicity in the connectivity  to on-prem systems. The solution in App Studio is based on standard destination usage.

More details can be found here:  https://help.sap.com/viewer/9d1db9835307451daa8c930fbd9ab264/Cloud/en-US/e72930c96b664e3ea4ce5288eb8..., https://help.sap.com/viewer/9d1db9835307451daa8c930fbd9ab264/Cloud/en-US/c93afb5743a04b62afea0fe1def...

 

Thanks,

Liat
laszlo_kajan2
Active Participant
0 Kudos

Dear Liat!

Indeed, the instructions in ‘Accessing On Premise Systems‘ provide an elegant and simple solution for the ‘SAP Fiori’ development case. There is no need to tunnel anything. I have amended the blog post.

At the moment (09-Jun-2020), the CAPM connectivity issue remains, afaik.

Best regards,
Laszlo

laszlo_kajan2
Active Participant
0 Kudos

New development: see the update of 17-June-2020 at the top of the blog post.

kay
Advisor
Advisor
0 Kudos

Hey Laszlo,

Thanks for figuring this out!

It helped me immediately to start my application on BAS with a destination, before this was not possible. Anyway, if the application tries to reach the destination, it ends up in an technical error saying the following

“dial tcp: lookup <name-of-dest>.dest on 100.xx.0.xx:5x: no such host\n”

Did you face this issue? If yes, how did you resolve it?

 

Best regards and thanks in advance

Kay

laszlo_kajan2
Active Participant
0 Kudos

Dear Kay!

I get this “dial tcp: lookup name-of-dest.dest on 100.64.0.10:53: no such host” error in this specific case:

  • I try to use the proxy of the App Studio: 127.0.0.1:8887,
  • with a destination that includes upper-case characters, like ‘NAME-OF-DEST’.

See my note “The problem seems to be a lowercase transliteration …” above.

When using the proxy of the App Studio, the only thing that worked was to use a destination name that matches this pattern: [a-z0-9-].

You should still be able to reach a destination that doesn’t conform to that pattern using a tunnel to the ‘connectivityproxy’, as I describe above.

Best regards,

Laszlo

vimadaan
Explorer
0 Kudos
I have changed name of my destination into lower case but still getting below error:

"dial tcp: lookup <CC_Destination_URL> on 100.64.0.10:53: no such host".

 

What are other possibilities of such error?

I am using SapCfAxios to connect and destination/connectivity services details are maintained in the default-env.json.

Please help.

 

 
laszlo_kajan2
Active Participant
0 Kudos

Dear Vikas,

try

curl http://localhost:8887/reload

in the App Studio terminal after changing the destination: this will make the App Studio (proxy) ‘see’ the new destination.

Best regards,
Laszlo

gadirov
Participant
0 Kudos

laszlo.kajan.roche.com

Hi Laszlo,

thank you for your post!

Unfortunately, I tried several things out and I am not able to get any access from my BAS in the cloud to a destination (no matter if principal propagation or "No Authentication" has been set up).

I tried the following command:

cf ssh <app-srv> -N -T -L 20003:connectivityproxy.internal.cf.eu10.hana.ondemand.com:20003

But the terminal tells me that "Error getting SSH code: Authorization server did not redirect with one time code".

We have the OnPremise Destination exposed via Cloud Connector. I also tried this curl command

curl http://localhost:8887/reload.

After deployment to CF, the external services are being retrieved correctly. I am using internal app router and xsuaa which is bound successfully to the application. The same for destination and connectivity service. We are using a destination on subaccount level.

BR and thank you.

Rufat

 

P.S. @liat.borenshtein

Maybe you could also have a look at this issue? We tried both cds connect and SAP CF Axios Library by Joachim. Thank you all in advance.

 

 

former_member724290
Participant
0 Kudos
Hi!

I up the cloud connector and created a remote on-premis system. At the same moment, Fiori in Business Application Studio perfectly shows the data.

But the next day, the fiori application no longer starts and shows a error 500 (Internal Server Error) while calling the $metadata. In the cockpit, the connector and destination is tested normally. Also, when creating a new project through this distination, all entities in the BAP are visible normally, but the application does not open. That is, the BAP sees the connection from the remote, but the application in the sandbox is not.

Tell me, what could it be?

Thanks!
Labels in this area