Consume External Service using Application Router

In my previous blog posts:

• CAP Consume External Service – Part 1
• CAP Consume External Service – Part 2

I discussed about consuming external service within the backend service using Cloud Application Programming (CAP) Model. This is the approach you need to use if you need to process the data or do some manipulation before you provide the data to your consumer application.

But what if you don’t need to process the data? Instead, you want to use the data directly in your web application!

In this blog post, I will show the setup on how to consume a destination configuration from a Cloud Foundry Destination Service via the App Router module.

Use Cases

• Consumption of external services (non-SAP systems)
• Consumption of external services from S/4HANA Cloud
• Consumption of external services from on-premise SAP systems

Prerequisites

• SAP Cloud Platform Account
• SAP Business Application Studio / Visual Studio Code

Setup Destination Configuration

For the destination configuration, we will be using the popular NorthWind service:

https://services.odata.org/Experimental/OData/OData.svc/

For the setup of destination in SCP Cloud Foundry, I have already discussed this in detail in my previous blog post:

CAP Consume External Service – Part 2

So go ahead and refer to that post specifically in the Setup Destination Configuration section and come back to this blog post once you’re done with the setup.

Create the MTA Project

It’s now time to create our MTA Project! For this case, it’s not necessary to create a CAP Model project. This is actually applicable whether you are using CAP Model or not.

• 1. The mta.yaml file configuration:

_schema-version: "3.1"
ID: demo.approuter
version: 0.0.1
description: "Demo on consuming destination service via app router"
parameters:
  enable-parallel-deployments: true

modules:
  - name: demo-app-router
    type: approuter.nodejs
    path: app-router
    parameters:
      disk-quota: 256M
      memory: 256M
    requires:
      - name: demo-destination
      - name: demo-uaa

resources:
  - name: demo-uaa
    type: org.cloudfoundry.managed-service
    parameters:
      path: ./xs-security.json
      service-plan: application
      service: xsuaa

  - name: demo-destination
    type: org.cloudfoundry.existing-service

In the resources section, we need to configure our UAA service because this is required by the destination service. Another configuration is for our destination service where we configured the NorthWind destination.

In the modules section, we defined our app-router module where we make use of our destination and UAA service.

• 2. Creating the app-router module from scratch is very simple, we just need to setup our package.json as below:

{
	"name": "app-router",
	"description": "Node.js based application router service",
	"engines": {
		"node": "^8.0.0 || ^10.0.0"
	},
	"dependencies": {
		"@sap/approuter": "6.8.0"
	},
	"scripts": {
		"start": "node node_modules/@sap/approuter/approuter.js"
	}
}

Make sure that you create this file under the app-router folder because this is how our mta.yaml is setup.

• 3. The app-router module needs to have the routing configuration inside the file xs-app.json:

{
	"authenticationMethod": "route",
	"routes": [{
		"source": "/Experimental/OData/OData.svc/(.*)",
		"target": "$1",
		"destination": "NorthWind"
	}]
}

In this routing configuration, we take any queries from path /Experimental/OData/OData.svc/ and redirect it to our NorthWind destination. This is as simple as it can get for our basic routing configuration demo.

"csrfProtection": false

• 4. Setup the basic xsuaa security configuration in file xs-security.json (this should be in the root folder of our project):

{
	"xsappname": "demo-uaa",
	"tenant-mode": "dedicated",
	"description": "Security profile of called application",
	"role-templates": [
		{
			"name": "Token_Exchange",
			"description": "UAA",
			"scope-references": [
				"uaa.user"
			]
		}
	]
}

Note that all users of the UAA service requires the uaa.user scope, and this is why we have this configured in here.

At this point, our MTA project should have a structure like the screenshot below:

• 5. The last step, of course, is to build and deploy this project to SCP Cloud Foundry. For this demo, I’m using a cloud foundry trial account.

Test the App Router service

• 1. After successfully deploying the app router to SCP Cloud Foundry, test the service by calling the app-router service with below path using your favourite web browser:

<app-router-hostname>/Experimental/OData/OData.svc/Products

By seeing the data returned by the app-router service, we can conclude that we are able to connect to the destination service and make use of the configured NorthWind destination.

Closing

Now you see how easy it is to setup a destination using the SCP Cloud Foundry destination service and consume it using Application Router. This external service can then be fed into a UI5 application that is hosted in SCP. This is usually the case for a side-by-side extension of an SAP delivered solution.

Please do take note that the setup is a simple configuration of an external service that doesn’t require a username and password credentials. Most services that you will probably encounter have basic authentication security and this can be easily setup in the destination service just by choosing the Basic Authentication from the dropdown list and then provide the username and password.

Another thing to note here is that, if the source external service is from an on-premise environment like S/4HANA, you need to setup an SAP Cloud Connector and Connectivity Service in order for you to be able to connect to that on-premise web service.

~~~~~~~~~~~~~~~~

Appreciate it if you have any comments, suggestions, or questions. Cheers!~