5. Feature Toggled Extensions

In the previous exercise, we explored how 3rd party vendors can provide pre-built verticalization packages as extensions to SaaS applications for reuse by multiple SaaS customers.

In this chapter, we will switch roles and focus on the perspective of the SaaS Provider. Our goal is to add these pre-built extensions as part of the base application itself, allowing them to be feature-toggled on a per-tenant basis.

In this exercise, as the SaaS provider, we will offer the same extension we built earlier as a toggled feature specifically designed for customers in the solar panel industry.

Create the Extension

Toggled features are part of the base application, and their content — primarily CDS models — is stored in a specific folder within CAP-based projects. By default, this folder is ./fts/<feature>. So let's go ahead and create the extension:

1. Switch to the browser tab of the incidents project.

2. Create a new folder for your feature by clicking on the "New Folder" button at the top of the Explorer pane. Enter fts/solar in the inline input field and press Return.

   

3. Add your extension content to the newly created folder. Instead of recreating the files, let's copy the ones we created before by running the following command in the Terminal:

   cp ../t1x/app/* fts/solar

4. Fix the errors on line 1 in the copied ./fts/extension.cds file to import the base model from the local ./db/schema.cds file. Modify the line as follows:

   using { sap.capire.incmgt.Incidents } from '../../db/schema';

5. Fix the errors on line 5 in the copied ./fts/fiori.cds to import the SAP Fiori Elements model from the local ./app/fiori.cds file as follows:

   using { IncidentsService } from '../../app/fiori';
   using from './extensions'; 

Toggling Features

In a production environment, special feature toggle services would be used to dynamically enable or disable features for individual tenants. However, in our exercise using mocked-auth, we simulate this behavior by statically adding a corresponding feature assignment to the configuration for tenant t3. Let's proceed with the following steps:

1. Edit the package.json file and add the following setting to the cds configuration:

   {
     "cds": {
       "requires": {
         "auth": { ...,
           "tenants": {
             "t2": { "features": [] },
             "t3": { "features": ["solar"] }
           }
         ...

2. Re-subscribe t3 to activate the toggled extension. Enter the following command in the Terminal:

   cds subscribe t3 --to http://localhost:4005 -u erin

3. Restart the app server. Follow the steps outlined in exercise 2).

4. Switch to the LaunchPad for AD264 browser tab.

5. Click on the [ Erin (t3) ] button → This will open a new tab with the Incidents list view in which we see the Components column, this time delivered through the toggled feature for tenant t3.

6. Go on testing the UI as in the exercises before.

Summary

So in this exercise, we took the same extension we developed before and turned it into a toggled feature of the base application.

CAP Spotlights:

• Feature Toggles — allows SaaS providers to have pre-built extensions bundled with their SaaS applications to provide industry-specific verticalizations and other extensions out-ouf-the-box, and toggle them easily per customer tenant, user or even single requests.

Go on to the exercise 6 — Sandboxed Logic section of this hands-on walkthrough.