Skip to Content
Technical Articles

How to Access On-premise OData from the Business Application Studio – CAPM Development

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 Remote Services’, 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

6 Comments
You must be Logged on to comment or reply to a post.
  • 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.

  • 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/e72930c96b664e3ea4ce5288eb84075f.html, https://help.sap.com/viewer/9d1db9835307451daa8c930fbd9ab264/Cloud/en-US/c93afb5743a04b62afea0fe1def00062.html

     

    Thanks,

    Liat

    • 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

  • 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

  • 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