Skip to Content
Technical Articles
Author's profile photo Gaurav Abbi

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.

Assigned Tags

      18 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Marius Obert
      Marius Obert

      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 🙂

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      Thanks, I updated it and linked it to the dev261 official sample repo.

      Author's profile photo Kevin Hu
      Kevin Hu

      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.

      https://blogs.sap.com/2021/03/01/deploy-serverless-sap-fiori-apps-from-the-kyma-runtime/

      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.

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      Hi Kevin,

      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.

      Author's profile photo Kevin Hu
      Kevin Hu

      I found from the doco, which sort of explains why I saw this in my BTP cockpit

      https://help.sap.com/products/BTP/65de2977205c403bbc107264b8eccf4b/845389cdda154a0db45aa403c4bb072b.html?locale=en-US

      app-host plan

      Use this service plan to deploy HTML5 applications to the repository.

      app-runtime plan

      Use this service plan to consume HTML5 applications stored in the repository.

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      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.

       

      Best regards,

      Gaurav Abbi

      Author's profile photo Priya Sreedevi
      Priya Sreedevi

      Hi Gaurav,

      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.

      Thanks,

      Priya

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      Hi Priya,

      I would recommend checking out the TechEd 2021 sample. It deploys to the HTML5 application repository using a job from Kyma runtime.

       

      Best regards,

      Gaurav

      Author's profile photo Priya Sreedevi
      Priya Sreedevi

      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.

       

      Thanks,

      Priya Nair

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      Hi Priya,

      For your scenario, where is the UI app is deployed. On HTML5 Application repository or directly on Kyma?

       

      Thanks,

      Gaurav

      Author's profile photo Priya Sreedevi
      Priya Sreedevi

      Hi Gaurav,

      I have deployed the UI application on HTML5Application repository, and configured an approuter(with HTML5 repo runtime instance) in kyma with below routes,

      {
      "authenticationMethod": "route",
      "routes": [
      {
      "source": "^/CAPM_SRV_DESTINATION/(.*)$",
      "target": "$1",
      "destination": "CAPM_SRV_DESTINATION",
      "csrfProtection": false
      },
      {
      "source": "^(.*)$",
      "target": "$1",
      "service": "html5-apps-repo-rt",
      "authenticationType": "xsuaa"
      }
      ],
      "welcomeFile": "/<html5 resource folder>"
      }

      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

       

      Thanks,

      Priya Nair

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      Hi Priya,

      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.

       

      Thanks,

      Gaurav

      Author's profile photo Jamie Cawley
      Jamie Cawley

      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.

      Regards,

      Jamie

      Author's profile photo Gaurav Abbi
      Gaurav Abbi
      Blog Post Author

      Hi Priya,

      I got a working sample. I do not have it yet published. For now, let me share my configuration that I used.

      xs-app.json

      apiVersion: v1
      data:
        xs-app.json: |-
          {
              "authenticationMethod": "route",
              "sessionTimeout": 10,
              "routes": [
              {
                "source": "^(.*)$",
                "target": "$1",
                "service": "html5-apps-repo-rt",
                "authenticationType": "xsuaa"
              }
              ]
          }
      kind: ConfigMap
      metadata:
        name: xs-app

       

      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

      Author's profile photo Priya Sreedevi
      Priya Sreedevi

      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.

      Thanks,

      Priya

      Author's profile photo Jamie Cawley
      Jamie Cawley

      Hi Priya,

       

      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

      https://github.com/SAP-samples/kyma-runtime-extension-samples/blob/main/cap-orders-service

      This only requires the user to be authenticated as defined at /app/srv/orders-service.cds

      For specific roles you can define as

      https://github.com/SAP-samples/cloud-cap-samples-java/blob/main/srv/admin-service.cds

      Regards,

      Jamie

      Author's profile photo Priya Sreedevi
      Priya Sreedevi

      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.

      Thanks,

      Priya

       

      Author's profile photo Jamie Cawley
      Jamie Cawley

      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

      https://blogs.sap.com/2022/12/15/consuming-sap-hana-cloud-from-the-kyma-environment/

      Regards,

      Jamie