2. Deploy as SaaS

After having built the application let's now turn it into a SaaS application. Basically this means that we have to fulfill these requirements:

• Multitenancy — The single deployed application shall be used by multiple customers (tenants) in parallel.
• Tenant Provisioning — When tenants subscribe, tenant-specific resources have to be provided, such as new messaging channels, or database schemas or containers.
• Tenant Isolation — Incoming requests have to be served in isolation, e.g. using separate databases with separate connection pools.
• Dynamic Extensibility — all customers need to tailor applications to their specific needs, for example, by adding new fields and entities. Since SaaS applications serve multiple tenants, code modification is not possible. Instead everything must happen dynamically at runtime.

Let's see how to accomplish that in a CAP-based application...

Enable MTX

The good news is that CAP applications are intrinsically multitenant-enabled, as well as supporting dynamic extensibility out of the box. We only have to switch on multitenancy, and extensibility, for example, by running this on the command line:

cds add mtx

Do so in Business Application Studio (or VSCode) as follows:

1. Switch back to the browser tab of our incidents project:

   

2. Open a new terminal: Menu > Terminal > New Terminal

   

3. Copy & paste the above command line into the terminal and press Return:

   

   In case you get an error messages about packages not yet installed. Run npm install before running cds add mtx again.

   All this does is adding the following lines to our project's package.json, nothing else required, no changes to our content:

   

4. Run npm install to install the new dependency to @sap/cds-mtxs, which is the CAP package that implements all capabilities for multitenancy, toggles, and extensibility:

   npm install

Restart the Server

Since cds 6, with the new, streamlined @sap/cds-mtxs implementation, CAP allows test-driving fully-fledged multitenant applications in local mock environments, with a SQLite database. (Before, this always required deployment into a productive environment with HANA databases, which was very complex, expensive, and time consuming).

1. Simply restart our server by clicking on the Restart button in the floating debug bar at the top of our editor window:

   

2. In response to that you should see this output in your Terminal:

   

Note the new lines, informing us about the multitenancy services served now in addition to to the Incidents Service, as well as the fact that no application database is bootstrapped so far, as this is deferred to tenant subscriptions time.

Subscribing Customers

With our server running in multitenancy mode now, it waits for tenant subscriptions. So, lets subscribe three tenants, t1, t2, and t3. While this will usually be done via the SAP BTP's SaaS Provisioning Service in production, we can use the cds subscribe command to do that during development.

Let's do that in a split terminal to see reactions in our server log...

1. With our server output displayed in the terminal click on the Split Terminal button at the top of the terminal panel and then select bash:

   

2. Copy & paste these commands to the right-hand-side terminal:

   cds subscribe t1 --to http://localhost:4004 -u alice
   cds subscribe t2 --to http://localhost:4004 -u carol
   cds subscribe t3 --to http://localhost:4004 -u erin

3. See the left-hand-side terminal's showing the server's reactions:

   

Customers vs Tenants

We frequently use the terms "customer" and "tenant" in combination, sometimes also in some in-precise stand-ins for each others. Therefore let's clarify these terms in detail here:

• SaaS customers are BTP customers, which subscribe to SaaS applications
• Each subscription creates a new tenant → tenants represent subscriptions
• Tenants live in isolation → each has a separate database, separate extensions
• SaaS customers can create multiple subscriptions → hence have multiple tenants, e.g. for test and production.

Adding Users

In production users would be added by SaaS customers individually via respective identity provider services. During development though, CAP servers run with so-called mocked authentication using statically registered users.

For the sake of simplicity and to speed up things we've added these users in the incidents project's .cdsrc.json upfront.

{
   "requires": {
      "auth": {
         "users": {
            "alice": { "tenant": "t1", "roles": [ "cds.Subscriber", "admin" ] },
            "bob":   { "tenant": "t1", "roles": [ "cds.ExtensionDeveloper" ] },
            "carol": { "tenant": "t2", "roles": [ "cds.Subscriber", "admin" ] },
            "erin":  { "tenant": "t3", "roles": [ "cds.Subscriber", "admin" ] }
         },
         "tenants": {
            "t2": { "features": [] },
            "t3": { "features": ["solar"] }
         }
      }
   }
}

Note 1: .cdsrc.json contains configurations, similar to package.json, but not meant for production.

Note 2: This is just for your understanding, nothing to do in addition.

Summary

We've now built an application that is deployed as a SaaS solution and subscribed to two SaaS customers, as tenants t1 and t2.

CAP Spotlights:

• Intrinsic Multitenancy and Extensibility — When building a CAP application you don't care about multitenancy or extensibility, but just focus on your domain tasks at hand. No extension points need to be prepared. Later on you can simply deploy it as a multitenant SaaS application, with simple switches turned on or off. CAP cares for all tenant isolation as well as provisioning of tenant-specific resources out of the box.
• Streamlined MTX — While running multitenant SaaS software frequently means to do so in productive environments only, with complex and tedious setups, and poor turn-around times, CAP's streamlined MTX services allow to run your apps in multitenant mode and test extensibility while staying with minimum setup and mimimized costs.

In the next exercise 3 — Custom Extensions we will slip into the shoes of an individual SaaS customer, adding extensions to tailor it to the customer's specific needs.