How to call API endpoint on BTP nodejs app from another BTP app?

[Qualiture]

Hi all,

I have a BTP NodeJS application (A) which needs to make a REST call to another BTP application (B) at a regular interval.

In the mta.yaml file for app (A) I have specified the following resource which links to the exposed service of app (B):

  - name: app_a_using_app_b_api
    type: configuration
    parameters:
      provider-nid: mta
      provider-id: <app B name>:<app B exposed service>
      version: ">=0.0.0" 

This resource has been added as a required resource for app (A) module:

  - name: app_a_srv
    type: nodejs
    path: .
    requires:
      - name: app_a_db
      - name: app_a_using_app_b_api
        group: destinations       
        properties:
          forwardAuthToken: false
          name: app_b_api
          url: ~{url}         
          timeout: 30000

In app (A) package.json I then specified the destination: 

  "cds": {
    "requires": {
      "middlewares": true,
      "app_b_api": {
        "kind": "destination",
        "credentials": {
          "destination": "app_b_api"
        }
      }
    }
  }

Within app (A), at a regular interval, the following function is then called:

    async doRequestToAppB() {
        try {
            const destination = await getDestination({ destinationName: "app_b_api" });
            const data = await executeHttpRequest(destination, {
                method: 'GET',
                url: "/api/ping"
            });

            logger.info(`Request OK: ${JSON.stringify(data)}`);
        } catch (err) {
            logger.error(`Request FAILED: ${err}`);
        }
    }

This request now fails with the following error in the catch-clause:

[app_a] - Request FAILED: TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'TLSSocket'
    | property '_httpMessage' -> object with constructor 'ClientRequest'
    --- property 'socket' closes the circle

I have tried many ways, but somehow I don't seem to be able to have app (A) automatically do a request to app (B), failing with the above error...

I also tried to debug the executeHttpRequest function from within BAS, but that did not give me any clues either.

If anyone has any clues, ideas, directions or tips on how to solve this, that will be highly appreciated!

Thanks in advance,

Robin van het Hof

[gregorw]

Hi Robin, can you provide some more insights about your XSUAA setup? If you use two different XSUAA instances then you need to configure a destionation that does a Token Exchange.

[Qualiture]

Hi Gregor, I think maybe that is related indeed... The app (A) which is sending the request does not appear to have XSUAA setup, whereas app (B) which receives the request, does have XSUAA setup. Thanks, at least it seems some config was forgotten. Will try it out and update later, thanks!

[Qualiture]

Hi Gregor, I have added uaa to the calling app (A), but to no avail... I think the problem is that app (A) calls app (B) without being triggered by a logged in user, but it runs on its own. Therefor, I don't have a token to forward which may causes the request to fail with a circular JSON parse error. But I would assume it should somehow be possible

[Qualiture]

Ok, I guess I'll have to buy you a 🍻 Gregor, for taking up your valuable time. The error turned out to be between chair and keyboard..... The circular JSON error I wasn't able to pinpoint in the NPM module turned out to be originating from this line in my code:

logger.info(`Request OK: ${JSON.stringify(data)}`);

because apparently executeHttpRequest returns the whole response object, not just the response data. Changing it to

logger.info(`Request OK: ${JSON.stringify(data.data)}`);

returned the expected response just fine and apparently I have wasted quite some hours debugging something that already worked just fine... 🤡

[Qualiture · Accepted solution]

Well, apparently it was working correctly all along:

The error turned out to be between chair and keyboard. The circular JSON error I wasn't able to pinpoint in the NPM module turned out to be originating from this line in my code:

logger.info(`Request OK: ${JSON.stringify(data)}`);

because apparently executeHttpRequest returns the whole response object, not just the response data.

Changing it to

logger.info(`Request OK: ${JSON.stringify(data.data)}`);

returned the expected response just fine and apparently I have wasted quite some hours debugging something that already worked just fine...