Using SAP Application Router with Kyma runtime
SAP BTP, Kyma runtime is used to develop applications and extensions.
This also brings in the following requirements:
- Serve static content
- Authenticate and authorize users
- Forward to the appropriate identity provider for login
- Rewrite URLs
- Dispatch requests to other microservices while propagating user information
All these and more capabilities are provided by SAP Application Router.
There are two options to use the Application Router capabilities in SAP BTP, Kyma runtime.
- Managed Application Router
- Standalone Application Router deployed on Kyma runtime.
Both options can be used by the customers, and they can choose either one of them depending on their requirements, business use-cases, and TCO.
Managed Application Router
With this option, the Application Router as a component is operated and maintained by SAP. It is part of the HTML5 applications runtime capability provided by one of the following services:
- SAP Work Zone
- SAP Launchpad Service
- SAP Cloud Portal
In the context of Kyma runtime, you can, for example, deploy your HTML5 applications in the HTML App Repository, and configure the site with the Launchpad service. Then, the microservices running on Kyma runtime are accessed using the Destination Service. See the following example scenario with such a setup:
Advantages of this setup:
- No software maintenance for Application Router components
- Seamless integration into cFLP. There is a single session provided and managed by the Application Router.
- High availability and external session management provided out of the box
Disadvantages of this setup:
- To integrate or forward requests to backing microservices running on Kyma runtime, they must be exposed with API Rules. That’s because managed Application Router is not running inside the Kyma runtime.
- The Application Router capabilities cannot be extended. Thus, for example, injecting a custom middleware won’t be possible.
Standalone Application Router
In this setup, you deploy a dockerized version of the Application Router npm package on the Kyma runtime.
See the following example setup:
Advantages of this setup:
- Freedom to extend the Application Router with any custom processing as required
- Control over the version of the Application Router
- Only the Application Router is exposed with an API Rule. All backing microservices are running inside Kyma runtime, and the Application Router dispatches and forwards the request to them.
Disadvantages of this setup:
- An additional software component must be maintained and operated
- To achieve high availability and zero downtime, you must maintain multiple replicas and externally store the session. That way, the session is not lost when a Pod restarts. For external storage, you can, for example, use Redis as session storage. SAP BTP, Hyperscaler Redis is not yet consumable from Kyma runtime (on Roadmap for Q1 2022). As current alternatives, you can either use a hyperscaler Redis or run a Redis server within Kyma runtime.
- No integration in cFLP (Portal service is not supported in Kyma runtime)
In summary, both approaches are applicable and have their relevance depending upon the requirements and use cases to be implemented.
Great post Gaurav!
I'll leave this link to a sample project that uses the managed approuter for future readers here.
PS: The link to the "example scenario" above is broken 🙂
Thanks, I updated it and linked it to the dev261 official sample repo.
Hi Abbi, nice blog.
I have a question regarding the HTML5 Repository Service Component. In your diagram it shows it is on the subaccount level. While I was also checking Marius's earlier post, it shows the HTML5 repository sits inside the kubernetes/Kyma environment.
Could you please explain a bit further, does it mean it can be two options? I do see the options of Plan/Runtime when creating a HTML5 Application Repository instance. Thanks.
That could be just the way it is represented in the diagram. The HTML5 Repository Service Component exists only at the subaccount level. It is not offered as a service inside Kyma.
I found from the doco, which sort of explains why I saw this in my BTP cockpit
Use this service plan to deploy HTML5 applications to the repository.
Use this service plan to consume HTML5 applications stored in the repository.
Hi Kevin Hu,
Yes, you can create the instance from Kyma and that is what we did in the TechEd session.
However, the actual instance gets provisioned inside BTP. From Kyma, you trigger the instance creation. You have credentials and access data available for instances created from Kyma, It does not reside inside your Kyma cluster.
Thanks for this blog,
Do you have a reference project which uses standalone application router for UI deployment to HTML5 application repository.
Also, which is the best way to deploy UI component of a CAP application, considering CAP is now supported on Kyma with CAP helm chart.
I would recommend checking out the TechEd 2021 sample. It deploys to the HTML5 application repository using a job from Kyma runtime.
Thanks Gaurav for the reply.
I was looking for a sample project in Kyma where the UI endpoint is exposed with a standalone approuter as given in the second example setup. It would be helpful if you can direct me to one.
For your scenario, where is the UI app is deployed. On HTML5 Application repository or directly on Kyma?
I have deployed the UI application on HTML5Application repository, and configured an approuter(with HTML5 repo runtime instance) in kyma with below routes,
With this configuration, after xsuaa authentication an authentication pop up comes up in browser. My credentials/XSUAA secrets doesn't work, and the metadata fails to load if I cancel the pop up.
If I remove the xsuaa authentication from approuter, this pop up doesn't come
I was trying out the similar setup and observed the following error.
VError: xs-app.json/routes/0: Format validation failed (A route requires access to html5-apps-repo-rt service but the service is not bound.)
I am following up with the app router team to see if there are any further configurations required.
Make sure you are using the same xsuaa instance for the app router and the service and also check that you have the service destination property HTML5.forwardAuthToken set to true.
I got a working sample. I do not have it yet published. For now, let me share my configuration that I used.
I can confirm that post successful xsuaa authentication, I can access the html5 app.
As Jamie Cawley , you will need to use the same XSUAA instance for your app router and the service. Could you also check the app router logs to see if there are any logs that can point to the issue?
Thanks Gaurav for confirming the approuter configuration, my approuter is working fine with the configuration.
I narrowed down my issue to the JAVA CAP component's XSUAA configuration, Before, Springboot mockuser security configuration was enabled which caused the Authentication pop up.
Now I added XSUAA dependancy in pom.xml as per https://cap.cloud.sap/docs/java/security#authentication (which is expected to do an automatic XSUAA configuration), which resolved the pop up issue, but still the XSUAA authentication is not happening in the CAP java service.
I have verified Destination and XSUAA instances as Jamie Cawley suggested, but no luck in enabling XSUAA authentication in CAP service.
I am new to CAP service, and I have added XSUAA instance using the volume mount for service binding secret for the CAP service. Any leads to a similar configuration would be really helpful.
This is done in your service.cds file as described at https://cap.cloud.sap/docs/java/security#spring-boot
I have a sample cap app which shows how to run the approuter in kyma at
This only requires the user to be authenticated as defined at /app/srv/orders-service.cds
For specific roles you can define as
Thanks Jamie for the git sample for approuter deployment. It really helped to make use of CAP Helm chart along with standalone approuter.
On applying XSUAA authentication on the CAP component, will the Odata/v2/CAPService/$batch (get/post to HDI Container) be authenticated with XSUAA, Considering HANA HDI Container is created in a Cloud foundry environment?
Also, Does a CAP implementation in Kyma work with an HDI Container created in a different Subaccount, with/without XSUAA? Do we need to have any additional configuration if the HANA DB is in different Subaccount.
The communication to the CAP service uses xsuaa. The communication between the CAP service and hana uses the hdi user/password which exists in the db secret, so it could exist in a different subaccount. You can now create hdi instances inside of kyma, but I haven't updated the example for this yet, see