Using SaaS Provisioning Service to develop Multitenant application on SAP Cloud Platform, Cloud Foundry Environment

In the context of Cloud Computing, Multitenancy allows an application provider to serve applications and services to multiple tenants – a set of users. End users of the application access it through a URL dedicated to that tenant.

A tenant-aware application has the capability to separate data securely per tenant, can share resources across the tenants, and can serve features from a single code repository.

This blog elaborates on the process to build a multitenant application on SAP Cloud Platform in the Cloud Foundry environment. For multitenancy on the Neo environment, please see this blog.

Understanding Software as a Service (SaaS) Provisioning service

In the SAP Cloud Platform Cloud Foundry environment service marketplace, we can see SaaS Provisioning service as shown in the image below.

To make our SaaS Application available to multiple tenants we must set up a registry for our application. The SaaS Provisioning service is where we, as a SaaS Application provider, register our app. The SaaS Provisioning service enables us to automate the subscription process. It also maintains a list of all dependencies and subscriptions of an application.

A SaaS Application provider creates a subaccount to deploy the application. Inside this subaccount, the provider creates a space and deploys the SaaS Application. The provider then registers the application with a SaaS registry. The SaaS registry service on SAP Cloud Platform creates a new entry. Through this service, any sub-account, within the same global account, will see an entry of the provider application in the subscriptions tiles. The consumer then can subscribe to the application by just a click of a button. Each subaccount has a unique subdomain and identity zone id.

Understanding the concept through an example

Let’s look at how one can use SaaS Provisioning service to build a simple ‘Hello World’ multitenant application.

There is a SaaS Application provider – Provider ZZZ. Provider ZZZ would like to build an application that displays a hello message. The hello message will display the logged in user’s name and the tenant from which the user has logged in – as shown in the image

As ZZZ, we will build a ‘Hello World’ application to display the ‘hello message’. Also, since each tenant will access the application from a unique URL, we will build an app router app to resolve the URL, authorize the request and forward the request to our application.

Overview of the Steps Involved

1.     Develop A SaaS Application

In our application’s default end-point (GET – ‘/’) we will return a hello statement displaying the username, tenant subdomain, and tenant identity zone.

We deploy this application on our (provider’s) sub-account and test the application. Once we are satisfied with the development, we add the configurations required to make our application available across tenants.

2.     Add Configurations For Multitenancy

To make our application available to SaaS Provisioning service and to automate the subscription process we must add the following configuration to our SaaS Application.

The SaaS Provisioning service requires us to define the following API end-points.

• PUT – ‘callback/v1.0/tenants/*
  • To onboard a tenant, i.e. when a consumer subscribes to the application

• DELETE – ‘callback/v1.0/tenants/*’
  • To off-board a tenant, i.e. when a consumer unsubscribes to the application

Each consumer accesses the SaaS Application through a unique URL. To ensure that these requests come to the target application, we define a tenant host pattern for our app router app in the MTA.yaml file. Click here for the detailed documentation.

We specify the SaaS Application name, description, app category while creating a SaaS Provisioning service instance. We mention these details in a config.json

{

  "appId": "<XS-App Name>",

  "displayName": "Hello World",

  "description": "A sample hello world app to explain the concepts of Multitenancy",

  "category": "Provider ZZZ",

  "appUrls": {

    "onSubscription": "<Your back-end app URL>/callback/v1.0/tenants/{tenantId}"

  }

}

3.     Register the SaaS Application to SaaS Provisioning

Upon completing our configuration, we create a SaaS Provisioning service and bind it to our SaaS Application. To complete this set of actions we require Cloud Foundry Command Line Interface.

We start this process by creating a new SaaS Provisioning service instance.

cf cs saas-registry application <Service name> -c <Path to config.js file>

Next, we bind our SaaS Application to the newly created SaaS Provisioning service instance.

cf bs <SaaS Provider Application Name> <SaaS Provisioning Service Name>

Once we bind our application to this service instance we will be prompted to restage our application. To do so, we execute the following command.

cf restage mt-hw-node-app

4.     Subscription of the SaaS Application by a Consumer

A consumer can subscribe to the application either through the SAP Cloud Platform Cockpit or through REST APIs.

Subscription through SAP Cloud Platform Cockpit

In your global account, create a new subaccount and go to the Subscriptions tab. The SaaS registry service shows the applications that have been registered with it. Here, you will find the provider’s application.

Click on the application tile and click on the subscribe button.

Subscription through REST APIs

You will require a client that can make REST API calls (such as Postman).

We first get the application authorization token. Using your Cloud Foundry Command Line Interface tool execute the following command

cf env <Name Of You SaaS App>

Create a new request in your client with the following setup. Copy the corresponding values from the environment variables.

HTTP Method – POST

URL – <"System-Provided"."VCAP_Services"."saas-registry"."credentials"."url">

Parameters

Key: grant_type

Value: client_credentials

Authentication Type – Basic Authentication

Username - <"System-Provided"."VCAP_Services"."saas-registry"."credentials"."clientId">

Password - <"System-Provided"."VCAP_Services"."saas-registry"."credentials"."clientSecret">

You will receive the following as a response.

{

  "access_token": "xxxxxx",

  "token_type": "bearer",

  "expires_in": 43199,

  "scope": "yyyyyy",

  "jti": "zzzzz"

}

We use the access_token returned to call the subscription API in the next step.

HTTP Method – PUT

URL - <"System-Provided"."VCAP_Services"."saas-registry"."credentials"."tenant_onboarding_url">/api/v2.0/subscription/tenants/{tenantId}

tenantId – Tenant Zone Identity

Parameters

Key: jobUuid

Value: A newly generated GUID

Authentication Type – OAuth 2.0

Access Token – Access token copied from the response of the earlier API

In upcoming blogs, we will take a look at the different APIs that can be used.

5.     Mapping Consumers’ Routes

In the last step, the provider needs to add a new route to ensure that a consumer’s request goes to the app router.

You can now launch the app for the consumer

In upcoming blogs, we will take a closer look at methods that we can adopt to automate the process of route mapping.

Please find the code for a ‘Hello World’ sample application here. This application has been developed using node.js. For further information and a step by step guide, please go through the Readme.MD file. If you prefer a video, please check out this playlist by SAP HANA Academy.

Now that you have an understanding of SaaS Provisioning and steps involved in building a multitenant application you can go through this blog to see how can we achieve multitenancy at persistence layer through SAP Cloud Platform, Cloud Foundry environment. The blog explains the concepts through a sample product inventory management application. To gain a deeper understanding of the architecture please read this blog.