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

      6 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 (Sydney, AU)
      Kevin Hu (Sydney, AU)

      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