4. Pre built Extensions

Use Case: Industry-specific Verticalization

In the chapter before we learned about how extend a CAP-based SaaS application in order to tailor it to the needs of an individual customer.

In this chapter we slip into the shoes of an SAP Partner who builds and share a pre-built verticalization package for reuse.

The task given is as follows:

• Customer t1 also happens to be an SAP Partner, and after having built the extension as in exercise 3 for themselves, they decide to share and sell this as a reusable pre-built verticalization package to incidents management app for other solar panel vendors.
• Customer t2, another solar panel vendor buys the pre-built extension and activates it for their usage, saving the efforts to do the same custom extensions.

Create the Extension

Pre-built reusable extensions are created in the very same way as custom extensions. So, as we already created the custom extension in exercise 3 before, as customer and SAP Partner t1 , we have a head start and just go on from there ...

Package it ...

To share a pre-built extension, for example, by uploading it to some marketplace, we would create an .tgz archive, which we already did before as well

The only thing we should do in addition is to ...

1. Add publication details to ourpackage.json, such as:

   • a description
   • a version
   • author
   • license

2. Rebuild the extension archive:

   cds build

   → produces ./gen/extension.tgz archive.

Share it (e.g. as SAP Partner)

With the extension archive generated we would now upload it to some marketplace. As there is no standard one yet offered by SAP BTP, we just mimic this step by copying the archive to a different place:

1. Ensure to be in browser tab for project x-t1

2. Run this command in the Terminal:

   cp gen/extension.tgz ../shared-ext.tgz

Reuse it (as SaaS Customer)

Now, a consumer would buy and download a pre-built extension package and activate it in their subscriptions. Again, as we don't have a standard maretplace for this session, we mimic this for customer t2. But first, in steps 1+2, we will show the non-extended app for t2.

1. Switch to the Launchpad for AD264 browser tab

2. Click on the [ Carol (t2) ] button → opens a new browser tab showing the list of Incidents without the Components column:

   

3. Now, switch to browser tab for project incidents (but actually doesn't matter)

4. Activate the pre-built extension for tenant t2:

   cds push ../shared-ext.tgz --to http://localhost:4004 -u carol

5. Return to the application tab we opened before (if you don't find it just go via the Launchpad page again) and Refresh the page (e.g. via Cmd/Ctrl-R shortcut) → et voilà: here's the Components columns, now also for customer/tenant t2, directly in production tenant:

   

6. Go ahead, open the License details page on an entry, and [ Edit ] the data, enter some values, [ Save ] your changes, see them displayed in the details page, go back to the list and see your entered value in Component column of the first row.

Summary

You've now learned how to easily create, share and reuse pre-built extension package.

CAP Spotlights:

• Uniform Programming Model — we've seen that CAP offers a very consitent, uniform programming model: Adding individual custom extension is done in very much the same way than building CAP applications in general. Same applies to creating pre-built extension packages. Basically just the steps to deploy differ.
• Extend, Reuse & Compose — CAP intrinsically supports sharing and reusing pre-built application packages, be it base applications, extensions or content packages. This in turn allows consumers of those packages to flexibly compose own solutions instead of building everything from scratch.

In the next exercise 5 — Feature-Toggled Extensions, you will see how SaaS application providers themselves can provide similar pre-built extensions and enable or disable them for individual tenants using the technique of feature toggles.