Request proxied differently thought called from the same application

[JérémyChabert]

Hello all,

Sum up of the issue:

Request are not proxied the same between my OData service (SAP ECC) and another service (Node.js) whereas both declared in xs-app.json and destination defined in destination subaccount and/or service instance.

This call succeeds : 200 OK

https://myawesomecompany-scp-cf-dev.launchpad.cfapps.eu10.hana.ondemand.com/myappservicecontract.mya...

This one, however ...

https://myawesomecompany-scp-cf-dev.launchpad.cfapps.eu10.hana.ondemand.com/cp.portal/srv-api/liveli...

Both calls are triggered from the same app, but we noticed :

• /myappservicecontract.myappcontractharmodtl/~100321121416+0000~/

is missing in the second call. We don't understand why !!!

↓↓↓ The explanation of my doing ↓↓↓:

Here's the build:

• appRouter Managed application
• Node.js service
• A Fiori Element Application

The HTML5 application is calling through destination service the Node.js service

Below the mta of my application.

_schema-version: "3.2"
ID: servicecontract
version: 0.0.1
modules:
  # --------------------- SERVER MODULE ------------------------
- name: api_proxy_brain
    # ------------------------------------------------------------
  type: nodejs
  path: srv
  build-parameters:
    ignore: ['package-lock.json', 'node_modules/']
    builder: custom
    commands: []
  requires:
    - name: servicecontract_xsuaa-service
  provides:
    - name: srv-api
      public: true
      properties:
        srv-url: ${default-url}
  
- name: servicecontract-destination-content
  type: com.sap.application.content
  requires:
  - name: servicecontract_xsuaa-service
    parameters:
      service-key:
        name: servicecontract_uaa-key
  - name: servicecontract_html_repo_host
    parameters:
      service-key:
        name: servicecontract_html_repo_host-key
  - name: servicecontract_destination-service
    parameters:
      content-target: true
  parameters:
    content:
      subaccount:
        destinations:
        - Name: my_app_servicecontract_servicecontract_html_repo_host
          ServiceInstanceName: servicecontract_html5-app-host-service
          ServiceKeyName: servicecontract_html_repo_host-key
          sap.cloud.service: my.app.servicecontract
        - Authentication: OAuth2UserTokenExchange
          Name: my_app_servicecontract_uaa_servicecontract
          ServiceInstanceName: servicecontract_xsuaa-service
          ServiceKeyName: servicecontract_uaa-key
          sap.cloud.service: my.app.servicecontract
        existing_destinations_policy: update
  build-parameters:
    no-source: true
- name: servicecontract-deployer
  type: com.sap.application.content
  path: .
  requires:
  - name: servicecontract_html_repo_host
    parameters:
      content-target: true
  build-parameters:
    build-result: resources
    requires:
    - artifacts:
      - myappcontractharmogrp.zip
      name: myappcontractharmogrp
      target-path: resources/
- name: myappcontractharmogrp
  type: html5
  path: contractharmogrp
  build-parameters:
    build-result: dist
    builder: custom
    commands:
    - npm install
    - npm run build:cf
    supported-platforms: []
resources:
- name: servicecontract_destination-service
  type: org.cloudfoundry.managed-service
  parameters:
    config:
      HTML5Runtime_enabled: true
      init_data:
        instance:
          destinations:
            - Authentication: NoAuthentication
              HTML5.ForwardAuthToken: true
              Name: api_proxy_brain-srv-api
              ProxyType: Internet
              Type: HTTP
              URL: ~{srv-api/srv-url}
          existing_destinations_policy: ignore
      version: 1.0.0
    service: destination
    service-name: servicecontract_destination-service
    service-plan: lite
  requires:
    - name: srv-api
- name: servicecontract_html_repo_host
  type: org.cloudfoundry.managed-service
  parameters:
    service: html5-apps-repo
    service-name: servicecontract_html5-app-host-service
    service-plan: app-host
- name: servicecontract_xsuaa-service
  type: org.cloudfoundry.managed-service
  parameters:
    path: ./xs-security.json
    service: xsuaa
    service-name: servicecontract_xsuaa-service
    service-plan: application
build-parameters:
  before-all:
  - builder: custom
    commands:
    - npm install

This build basically follows the build designed by c3d1947136cd4c748a7aa794001af496 Split MTA into backend & frontend (Thanks Wouter!)

Now in my xs-app.json, we have the following:

{
    "welcomeFile": "/manifest.json",
    "authenticationMethod": "route",
    "routes": [
        {
            "source": "^/sap/(.*)$",
            "target": "/sap/$1",
            "destination": "GATEWAY_PP",
            "csrfProtection": false,
            "authenticationType": "xsuaa"
        },
        {
            "source": "^/srv-api/(.*)$",
            "target": "$1",
            "destination": "api_proxy_brain-srv-api",
            "csrfProtection": false,
            "authenticationType": "xsuaa"
        },
        {
            "source": "^(.*)$",
            "target": "$1",
            "service": "html5-apps-repo-rt",
            "authenticationType": "none"
        }
    ]
}

And finally, the call we try to do in the HTML5 app

 fetch("srv-api/livelinkContent/v1/nodes/32932/content")
          .then(async (response) => {
            if (!response.ok) {
              //throw an error;
            }
            return response.blob()
          })
          .then(blob => {
           // do something with the blob
          })
          .catch(error => console.log("Oh oh something went wrong"));

When we attempt to call with :

• /srv-api (note the slash before), it throws a 502 Bad Gateway
• srv-api, it throws a 404 Not found.

[WouterLemaire]

Hi,

I don’t know exactly why, but your fetch call generated the wrong request. The routes are part of your app and like you can see in the successful request it contains the service id and app id. It should look like this: ( maybe as a test you can add it manually)

myappservicecontract.myappcontractharmodtl/dev-api/....

[JérémyChabert]

Hello Wouter,

Sure, adding this "prepath" in my call fixes the issue, but it is a manual way of doing it whereas for other routes, it is automatic.

I had the same issue in another F.E app, where I was giving an URL for a pdfViewer source in the controller

pdfViewer.setSource(`sap/opu/odata/sap/myService/${entity}(${paremeters})/$value`)

I was able to fix it this time by using this trick

const serviceURL = this.getView().getModel().sServiceUrl
pdfViewer.setSource(`${serviceURL}/${entity}(${paremeters})/$value`)

which gives the URL with serviceId and appId.